REC-PICSRules-971229

Ｗ３Ｃ勧告 1997年12月29日

http://www.w3.org/TR/REC-PICSRules-971229

http://www.w3.org/TR/REC-PICSRules

http://www.w3.org/TR/REC-PICSRules-971222

Martin Presler-Marchall, IBM <mpresler@us.ibm.com>

Christpher Evans, Microsoft <cevans@microsoft.com>

Clive D.W. Feather, Deamon Internet Ltd. <clive@demon.net>

Alex Hopmann, Microsoft <alexhop@microsoft.com>

Martin Presler-Marchall, IBM <mpresler@us.ibm.com>

Paul Resnick, University of Michigan <presnick@umich.edu>

このドキュメントは W3Cのメンバーやその他の組織によってレビューされ、理事によって W3C勧告としての承認を受けた。これは確定したドキュメントであり、参考資料として利用されたり、他のドキュメントから規範的な参考として引用される場合がある。勧告を作成する上での W3Cの役割は、仕様への関心を引きつけ、それが広く採用されることを促進することである。これにより、ウェブの機能性や相互運用性が強化される。

このドキュメントは、W3C(http://www.w3.org)メタデータ活動の一環である。

現在の W3C勧告とその他の技術ドキュメントの一覧は、http://www.w3.org/TRで入手できる。

このドキュメントでは、URL を説明するPICSラベルに基づいてそれらの URLへのアクセスの許可やブロックを行うフィルタリングルールである、プロファイル記述のための言語を定義する。この言語は伝送フォーマットを意図したものである。つまり、それぞれの実装においてはこの言語でその仕様の読み書きが可能でなければならないが、内部的にはこのフォーマットを使用する必要はない。

• プロファイルの共有とインストール。エンドユーザにとって、ユーザインターフェースがよくできている場合でも、洗練されたプロファイルを定義することは難しい。ある組織が一定の年齢層のこどもに対する推奨プロファイルを作成することができる。ユーザがその組織を信頼する場合には、プロファイルを一から自分で作成するのではなく、推奨プロファイルをインストールすることができる。１台のコンピュータ上でアクティブなプロファイルを変更することや、新しいコンピュータにプロファイルを導入することは容易である。

• エージェント、検索エンジン、プロキシ、その他サーバとの通信。さまざまなサーバは、プロファイルに記述されたユーザの選択を満たす結果を出すように調整する。例えば、検索エンジンは、質、プライバシー、年齢による適不適、あるいはダウンロードするコードの安全性に基づいた基準を指定するユーザプロファイルに一致するリンクのみを返す。

• フィルタリング製品間の移植性。すべてのPICSルール互換の製品で同じプロファイルが動作する。

この言語は、２つの既存のPICS仕様を補足する。それらは、レーティングサービス記述のためのマシン読み取り可能なフォーマットを提供することと、ラベルフォーマットとそれを配布する３つの方法を提供することである。特にPICSRules ルールでは、使用するPICSレーティングサービス、ラベルを問い合わせるためのPICSラベルビューロー、そして受け付けるか拒否するかの決定を行うために必要なコンテンツのラベルに関する基準を定義することができる。PICSRules にはDSigデジタル署名の照合を処理する構造が含まれていないが、PICSRules 言語が署名照合に適応するために必要な拡張をどの部分に組み込むかに関して、実装者に対するヒントは提供されている。

この仕様では、個々の必要条件の重要性を定義するために、RFC1123〔RFC1123〕と同じ単語を使用する。その単語は以下の通りである。

MUST（〜しなければならない）

この単語または形容詞“required（必須である）”は、この項目が仕様にとって絶対必要条件であることを意味する。

SHOULD（〜するべきである）

この単語または形容詞“recommended(推奨される）”は、特定の状況ではこの項目を無視するようなさまざまな理由があるかもしれないが、その場合には内容を完全に理解して、注意深く検討することが必要である。

MAY （〜してもよい）

この単語または形容詞“optional（オプションである）”は、この項目が全く任意であることを意味している。例えば、ベンダーによっては特定の市場がこの項目を必要とするから、あるいは製品を強化するからという理由でこれを実装するかもしれないし、別のベンダーは同じ項目を省略するかもしれない。

実装するプロトコルがMUSTの必要条件をひとつでも満たしていない場合は、その実装は仕様に対応しているとはいえない。すべてのMUST条件とSHOULD条件を満たしている場合は、その実装は「無条件に仕様に対応している」といえる。MUST条件はすべて満たしているが、SHOULD条件をすべて満たしてはいない実装は、「条件付きで仕様に対応している」といえる。PICSRules を処理するユーザエージェントは、MUST条件のどれかを満たしていない構造のためにどの解釈を選択するかは全く自由である。

このドキュメントでは、読者がPICS-1.1の知識を持っていることを前提としている。ここで述べられるすべてのラベルは、PICS-1.1対応ラベルのことである。詳細については、参考文献〔PicsService〕と〔PicsLabels〕を参照すること。

1 (PicsRule-1.1

2 (

3 Policy (RejectByURL ("http://*@www.grody.com:*/*"

"http://*@www.gross.net:*/*"))

4 Policy (AcceptIf "otherwise")

5 )

6 )

この例は、PICSラベルを使用することなく特定の URLセットへのアクセスを禁止するものである。ホストwww.grody.com またはwww.gross.net を指定するすべての URLは、ユーザ名、ポート番号、URL で指定された特定のファイルパスに関わらずブロックされる。その他の URLにはアクセス可能である。

1 (PicsRule-1.1

2 (

3 serviceinfo (

4 "http://www.coolness.org/ratings/V1.html"

5 shortname "Cool"

6 bureauURL "http://labelbureau.coolness.org/Ratings"

7 UseEmbedded "N"

8 )

9 Policy (RejectIf "((Cool.Coolness <= 3) or (Cool.Graphics >= 3))")

10 Policy (AcceptIf "otherwise")

11 )

12 )

このルールは、"Cool"レーティングサービス("http://www.coolness.org/ratings/V1.html")にしたがってドキュメントに与えられたレーティングをチェックする。ラベルはラベルビューロー "http://labelbureau.coolness.org/Ratings" から取得される。ドキュメントの作成者による彼ら自身のcoolnessの評価が信頼できないため、ドキュメントに埋め込まれたラベルは無視される。充分にcoolでない、あるいは画像が多すぎるドキュメントはブロックされる。ラベル付けされていないドキュメントを含むその他のものはすべてアクセス可能である。

1 (PicsRule-1.1

2 (

3 ServiceInfo (

4 name "http://www.coolness.org/ratings/V1.html"

5 shortname "Cool"

6 bureauURL "http://labelbureau.coolness.org/Ratings"

7 )

8 Policy (RejectUnless "(Cool.Coolness)")

9 Policy (AcceptIf "((Cool.Coolness > 3) and (Cool.Graphics < 3))")

10 Policy (RejectIf "otherwise")

11 )

12 )

このルールもまた、"Cool"レーティングサービスにしたがってドキュメントに与えられたレーティングをチェックする。この場合は、UseEmbeddedが指定されていないため、ラベルビューローからしゅとくしたラベルだけでなく埋め込まれたラベルも使用する。８行目は、"Cool"レーティングシステムの"Coolness"スケール上のレーティングを持っていなければ、ドキュメントはブロックされるという意味である。９行目は、充分に"Cool"で、画像が多すぎないドキュメントは通過することを意味する。10行目は、それ以外のドキュメントはすべてブロックされることを意味する。

1 (PicsRule-1.1

2 (

3 name (rulename "Example 4"

4 description "Example 4 from PICSRules spec; simply shows

how PICSRules rules are formed. This rule is

not actually intended for use by real users.")

5 source (sourceURL

"http://www1.raleigh.ibm.com/pics/PICSRulz/Example1.html")

6 ServiceInfo (name "http://www.coolness.org/ratings/V1.html"

7 shortname "Cool"

8 bureauURL "http://labelbureau.coolness.org/Ratings")

9 ServiceInfo ("http://www.kid-protectors.org/ratingsv01.html"

10 shortname "KP")

11 Policy (RejectByURL ("http://*@www.badnews.com:*/*"

"http://*@www.worsenews.com:*/*"

"*://*@18.0.0.0!8:*/*"))

12 Policy (AcceptByURL "http://*rated-g.org/movies*")

13 Policy (AcceptIf "(KP.educational = 1)"

Explanation "Always allow educational content.")

14 Policy (RejectIf "(KP.violence >= 3)"

Explanation "Blood's a %22scary%22 thing.")

15 Policy (RejectUnless "(Cool.Graphics < 4)" )

16 Policy (AcceptIf "otherwise")

17 )

18 )

行番号 説明

1 この構造を PICSRulesルールとして定義し、バージョン番号を付ける。

3 このルールに、簡潔で人間に読める形式の名前を付ける。この名前が一意である必要はない。これは何らかのユーザインターフェースでルールを扱う場合に、ユーザの記憶を補助するものである。

4 このルールに、より長い、人間に読める形式の説明を加える。これはこのルールの意味を説明するためのものであり、何らかのユーザインターフェースでルールを扱う場合に、ユーザを助けるものでもある。

5 「ルールの出所」を特定する。このURLは、ルールの作成者、作成理由、更新の可能性など、このルールに関する情報を持つウェブページを示すためのものである。

6-8 レーティングサービス "http://www.coolness.org/ratings/V1.html" に Cool という shortname を定義し、ラベルを取得するためのラベルビューローを識別する。

9-10 レーティングサービス "http://www.kid-protectors.org/ratingsb01.html" に KP というshortname を定義する。このサービスにはラベルビューローは定義されておらず、埋め込まれたラベルのみが使用される。

11 www.badnews.comおよびwww.worsenews.comホストからのすべての HTTP URL と、先頭の8ビットに IPアドレス 18を持つホスト（これらは mit.edu に対応するアドレスである）を指定するすべてのURLを拒否する。

12 ドメイン名が rated-g.org で終わり、パス名が "movies" であるURLを受け付けるが、それはユーザ名やポート番号が指定されていない場合に限られる。例えば、"http://www.mystuff.rated-g.org/movies/hello"は受け付けられるが、"http://joe@www.mystuff.rated-g.org/movies/hello"や"http://www.mystuff.rated-g.org:8009/movies/hello"は、ルール処理のこの時点では受け付けられない。（これらが後に続くポリシーステートメントによって受け付けられる場合もあるかもしれない。）

13 （先に定義された）KPレーティングサービスで educational のレーティングが1であるドキュメントが許可されることを指定する。このレーティングシステムでのレーティングを持たないドキュメント、あるいは１以外のレーティングを持つドキュメントは、以降のルールに従って調べられる。

14 （先に定義された）KPレーティングサービスで violence のレーティングが3以上のドキュメントはブロックされることを定義する。これにはユーザエージェントがユーザに表示するための説明文がついている。デコードすると Blood's a "scary" thing となる。このレーティングシステムでのレーティングを持たないドキュメント、あるいは3未満のレーティングを持つドキュメントは、以降のルールに従って調べられる。

15 （先に定義された）Coolレーティングサービスで Graphics のレーティングが3以上のドキュメントはブロックされることを定義する。Coolシステムでのレーティングを持たないドキュメント、あるいはレーティングにGraphicsのカテゴリーが含まれないドキュメントはブロックされる。Graphicsのレーティングが3未満のドキュメントは、以降のルールに従って調べられる。

16 上記のフィルタールールにパスしなかった、あるいはブロックされたドキュメントはパスすることを定義する。

1. 2つのサイトからのものを拒否する。そうでなければ、rated-g.orgドメインからのその他の特定のものは受け付ける。

2. 教育的なページは、その中に暴力や好ましくない内容が含まれているかどうかに関わらず許可される。

3. 多くの暴力が示されるページは、それらが教育的でなければブロックされる。

4. 教育的ページ以外は、画像が多すぎるページはブロックされる。

5. その他のものにはアクセスできる。

この構文は、MIMEタイプの application/pics-rules として登録される。

まず初めに PICSRules ルールの基本となる土台を考え、次にルールの一般フォーマット、そして最後にフィルター節における表現フォーマットについて考えよう。

PICSRules ルールは、S-expression の限られた形式、つまり括弧で囲まれた属性と値のペアに基づいている。値は、クォーテーションマークで囲まれた文字列か、括弧で囲まれた追加属性と値のペアのリストのいずれかであり、ネストが可能である。ある属性に対する値がさらにペアのリストである場合、「第一属性」という概念がある。第一属性の名前は読みやすさのために省略される場合があるので、第一属性の値のみが指定される。Parser（解析者）は構文的に属性と値を区別することが可能である。（値はクォーテーションマークか左括弧のどちらかで始まる。）属性名と対になっていない値は自動的に第一属性のものであると考えられる。ある属性に対する値がペアのリストの場合、そのリストには第一属性とその値のペア（第一属性の名前はあってもなくてもよい）が必ず含まれていなければならない。それには追加の属性と値のペアが含まれていてもよい。これらの限られたS-expressionの一般文法は以下の通りである。

attrvalpair:: attribute whitespace value | value

attribute:: alphanumstr

value:: quotedstring |'(' attrvalpair+ ')'

quotedstring:: '"'notdoublequotechar*'"' | "'"notsinglequotechar*"'"

alphanumstr:: (alphanum | '.')+

whitespace:: ' ' | '\t' | '\r' | '\n'

alphanum:: '0' - '9' | 'A' - 'Z' | 'a' - 'z'

notdoublequotechar :: any Unicode character except "

notsinglequotechar :: any Unicode character except '

文法では文字列をクォーテーションマークで囲む場合に " を使用するが、代わりに ' を使用してもよい。その場合には、初めと終わりが同じ文字であること。つまり、

"string"

'string'

"string'

'string"

BNFの残りの部分を簡潔に表記するために、すべてのクォーテーションマークで囲まれた文字列に対して「ダブルクォーテーションマーク」を使用するが、シングルクォーテーションマークも区切り文字として同等に有効であることを理解されたい。また、同じく簡潔な表記のために、notquotechar は現在の文字列で使用される引用の区切り文字（ " または '）以外の Unicode文字を意味するものとする。

1. "は %22 としてコード化する

2. 'は %27 としてコード化する

3. %は %25 としてコード化する

4. % の後に22,27,25 以外のものが後に続くものは、構文的に無効である

", ', % は、URL内の特殊文字のために使用する % hex hex のコード化ルールを使用してコード化されるが、その他の % hex hex の組み合わせは無効であり、それらがその他の文字をコード化するものとして扱わないことに注意すること。

PICSルール内の文字列	解析されデコードされた文字列
"string"	string
'string'	string
'This is "quoted" text.'	This is "quoted" text.
"It's nice to quote."	It's nice to quote.
"It%27s nice to %22quote.%22"	It's nice to "quote."
"50%25 of test scores are above the median"	50% of test scores are above the median
"50% are below the median"	構文として無効

HTMLの国際化に関するRFC 2070 [RFC2070]は、内部的な文字コード化と外部的な文字コード化のより一般的なSGML区別について記述している。それによると、UnicodeがPICSRulesルールの内部的な文字セットである。Unicodeは、ほとんどの言語の文字を含む16ビットの文字セットである。PICSRulesの公式な外部コード化には UTF-8を指定する。UTF-8 [UTF-8] には、すべてのUSASCII文字がそれ自身によっでて表現できることと、その他のコード化の一部として現れないという有利な性質がある。これは、8-bitバイトの先頭ビットを取り除かない限り、ほとんどの処理はUTF-8について知る必要がないことを意味する。

PICSRulesルールを正確に解釈するためには、ルールをUnicode文字シーケンスに変換するために最初にUTF-8の変換が行われることに注意すること。次に、クォーテーションマークで囲まれたそれぞれの文字列は、%22を " に、%27を ' に、%25を % に変換するコンバータを通らなければならない。

すべての属性名は case insensitive であるが、値の case は保存されなければならない。しかし、個々の節かつ／または属性は、それらの値を case-insensitive と定義してもよい。

以下に示す PICSRules構文には、ユーザエージェントの動作に影響するさまざまなステートメントだけでなく、ユーザに表示する説明文のための機能がある。しかし、「ソースレベルの」コメント、つまりルールの作成や編集のためのコメントだが、エンドユーザには表示しないコメントをつけることは有益である。これは、ソースコードにコメントを付けることと似ている。ルールの作成者に明確なルール作成を奨励するために、コメントをPICSRulesルール内に付けるための機能を提供する。

comment:: '{' comment-text* '}'

comment-text:: any characters except '}'

コメントは、PICSRulesルールのどの部分に現れてもよい。ユーザエージェントは、ルールの語彙分析中にコメントを削除してもよい。コメント内の文章は、いかなる方法でもルールの解釈に影響を及ぼしてはならない。また、PICSRulesルールの生成やエクスポートを行うユーザエージェントは、ルールを生成、エクスポート、伝送する前にコメントを取り除いてもよい。

修正BNF におけるPICSRules ルールの一般フォーマットは以下の通りである。"policy-expression" や "URLpattern" のように、エレメントによっては、ここで使用されていてもドキュメントの後の部分で定義されるものもある。

rule:: '(' 'PicsRule-'verMajor'.'verMinor rule-body ')'

verMajor :: integer

verMinor :: integer

rule-body :: '(' rule-clauses ')'

rule-clauses :: rule-clause+

rule-clause :: policy-clause |

name-clause |

source-clause |

service-clause |

opt-extension-clause |

req-extension-clause |

extension-aval

policy-clause :: 'Policy' '(' policy-attribute+ ')'

policy-attribute :: ['Explanation'] quotedstring |

'RejectByURL' URL-strings |

'AcceptByURL' URL-strings |

'RejectIf' policy-string |

'RejectUnless' policy-string |

'AcceptIf' policy-string |

'AcceptUnless' policy-string |

extension-aval

URL-strings :: URL-string | '(' ['patterns'] URL-string+ ')'

URL-string :: '"'URLpattern'"'

policy-string :: '"'policy-expression'"'

name-clause :: 'name' '(' name-attribute+ ')'

name-attribute :: ['Rulename'] quotedstring |

'Description' quotedstring |

extension-aval

source-clause :: 'source' '(' source-attribute+ ')'

source-attribute :: ['SourceURL'] quotedURL |

'CreationTool' quotedstring |

'author' quoted-address |

'LastModified' quoted-date |

extension-aval

service-clause :: 'serviceinfo' '(' service-attribute+ ')'

service-attribute :: ['Name'] quotedURL |

'shortname' quotedstring |

'BureauURL' quotedURL |

'UseEmbedded' yes-no |

'Ratfile' quotedstring |

'BureauUnavailable' pass-fail |

extension-aval

yes-no :: '"'Y-N'"'

Y-N :: 'Y' | 'N'

pass-fail :: '"'P-F'"'

P-F :: 'PASS' | 'FAIL'

opt-extension-clause :: 'optextension' '(' extension-name+ ')'

extension-name :: ['extension-name'] quotedURL | 'shortname' quotedstring |

extension-aval

req-extension-clause :: 'reqextension' '(' extension-name+ ')'

extension-aval :: attrvalpair

quotedURL :: '"'URL'"'

URL :: as defined in RFC-1738 for URLs.

quoted-address :: '"'e-mail-address'"'

e-mail-address :: as defined in RFC-822 for addresses.

quoted-ISO-date :: '"'YYYY'-'MM'-'DD'T'hh':'mmStz'"'

based on the ISO 8601:1988 date and time standard, restricted

to the specific form described here:

YYYY :: four-digit year

MM :: two-digit month (01=January, etc.)

DD :: two-digit day of month (01 through 31)

hh :: two digits of hour (00 through 23) (am/pm NOT allowed)

mm :: two digits of minute (00 through 59)

S :: sign of time zone offset from UTC ('+' or '-')

tz :: four digit amount of offset from UTC

(e.g., 1512 means 15 hours and 12 minutes)

例えば、"1994-11-05T08:15-0500" は、1994年11月5日午前8時15分（合衆国東部標準時）を表す有効な quoted-ISO-date である。

注意：ISOの標準では、ここで説明したものよりかなり柔軟なものも認められている。PICSではここで説明した構文を正確に必要とする。時間や時間帯のどちらが省略されてもいけないし、代替フォーマットも許されない。区切りもここで示した通りでなければならない。

注意：PICS-1.1 ラベルフォーマットの仕様では、不注意にもISO日付フォーマットとはわずかに互換性のないフォーマットを使用した。特にその仕様では、年と月や月と日の区切りに‘−’ではなく‘．’を使用する。この仕様ではその誤りを修正したためPICS-1.1 ラベルの仕様の日付フォーマットとの互換性はないが、ISO日付フォーマットとは互換性がある。

アプリケーションプログラムは、ルールとURL、そしてURLに関連するドキュメント内に埋め込まれた、あるいはURLに関連するドキュメントとともにHTTPヘッダーで渡されたラベルを提供するルール評価者(rule evaluator)を呼び出す。Yes（受理）またはNo（拒否）の回答が返される。ルール評価者はまた、最終的な回答を決定するポリシー節に関連する説明文がある場合には、その説明文も返すべきである。

Serviceinfo節は、指定されたURLにともなうラベルを見つける方法（ラベルビューローから取得するのか、ドキュメントに埋め込まれているのか）を特定する。Policy節は、回答を受理とするのか拒否とするのかを決定する。Extension節（必須またはオプション）は、追加ラベルの収集や廃棄を行ったり、あるいはルールの意味を変更する。ルールの意味は、指定されたすべてのソースからラベルを取得するために最善を尽くし、取得したすべてのラベルをpolicy節の評価に使用するユーザエージェントに基づいて定義される。しかしユーザエージェントは、指定されたURLで提供されるラベルと同じものを持つローカルソース（キャッシュやCD-ROM）に問い合わせたり、ラベルによってルールの結果が変わらない場合にはラベルを収集しないような最適化を行う。

このドキュメントの後の部分で、実装者が特定の評価順序を採用するような提案を行う。実装者は、この評価順序の提案から逸脱する場合にはとても注意深く行う必要がある。ラベルの受信において単調でないルールを作成することも可能であることに注意すること。より多くのラベルを受信すると、結果が受理から拒否になったりその逆になったりする場合がある。しかし場合によっては、追加ラベルがルールの結果を変更できないようにすることも可能である。例えば、最初のpolicy節で、ラベルに関わらず指定されたURLだけに基づいてその特定のURLを受理すると指定する。最適化として、ユーザエージェントはserviceinfo節で指定されるすべてのソースでラベルが使用可能になる前に回答を決定するように、policy節を使用するかもしれない。しかし、追加ラベルが評価結果を変更できないような場合だけこれを行うように、実装者は注意しなければならない。

Policy節には定義された属性が７つある。それらは RejectByURL, AcceptByURL, RejectIf, AcceptIf, RejectUnless, AcceptUnless, explanation である。最初の2つは、URLだけに基づいて項目の受理や拒否を行うものであるが、その説明については URLフィルタリングのセクションを参照すること。次の4つは、項目を表現するラベルに基づいて受理や拒否を行うものであるが、その説明についてはラベルフィルタリングのセクションを参照すること。主要な属性は explanation であり、これには既定値がない。すべてのPolicy節には｛RejectByURL, AcceptByURL, RejectIf, AcceptIf, RejectUnless, AcceptUnless｝のセットから必ず1つの属性が必要である。Policy節にこれらの属性が複数個含まれていてはならない。制限の組み合わせを行うためには、ルール内でPolicy節を複数回繰り返すことになる。

ルール内で複数のPolicy節が指定されている場合は、それらの節はルール内で指定された順に評価される。評価は最初に節が満たされた場合に終了し、それに伴うアクションが実行される。次の表は、属性と、それが満たされる条件、その意味を表したものである。

節の属性	満たされる条件	アクション
RejectByURL	URLが指定されたパターンのいずれかに一致	ドキュメントをブロックする
AcceptByURL	URLが指定されたパターンのいずれかに一致	ドキュメントをパスする
RejectIf	expression = true	ドキュメントをブロックする
AcceptIf	expression = true	ドキュメントをパスする
RejectUnless	expression = false	ドキュメントをブロックする
AcceptUnless	expression = false	ドキュメントをパスする

Policy節がどれも満たされない場合は、ドキュメントはパスされる。これは、最後のpolicy節を AcceptIf "otherwise" とするのと同等である。

Name節では、rulename とdescription という2つの属性が定義されている。RulenameはName節の第一属性であり、その値はこのルールの人間が読める形式の名前である。Descriptionの値は nameをより詳細にしたものである。これ提示されているルールにういての人間が読める形式の説明である。これは、ルールの作成者やその意味などを操作者に示すために、ユーザエージェントのユーザインターフェースで使用されるものである。Descriptionの値の内容は、ルールの作成者に一任される。

このメカニズムは、複数言語をサポートするためのトランスペアレントな方法を提供していないことに注意が必要である。これはPICSRulesの現バージョンでは意図的に述べられていないものである。複数言語でPicsRules-1.1 ルールを作成する場合には、ルールを複数作成して、それぞれを各言語で表現しなければならない。

この節はルールの出所に関する説明である。SourceURL, creationTool, author, lastModified という4つの属性が定義されている。第一属性は sourceURL である。

SourceURL属性は、“ルールのURL”である。このルールを使用する人が、このルールや作成者に関する情報を得るためのURLを提供する。この属性の値は、ユーザがこのルールに関する人間が読める形式の説明を取得するためのURLである。

CreationTool属性は、このルールの作成に使用されたツールがある場合に、それを識別するためのものである。これはHTTPでの User-Agent と同じものである。この属性の値はクォーテーションマークで囲まれた文字列である。この文字列は、"Cool-PICS-Rule-Editor/1.04" のように、ツール名／バージョンの形式になる。

Author属性は、このルールを作成した個人や組織の電子メールアドレスである。この属性の値はクォーテーションマークで囲まれた電子メールアドレスでなければならない。

LastModified属性は、このルールの最終更新の日時である。この値は、PICS-1.1ラベル構文と通信プロトコルで定義された通り、quoted-ISO-date でなければならない。

この節は、レーティングサービスに関する情報を指定する。この節には、name, shortname, bureauURL, UseEmbedded, ratfile, bureauUnavailable という6つの属性が定義されている。

Name属性は、レーティングサービスの servicename URL である。その値は、表示されているサービスの名前を特定する。

Shortname属性は、このレーティングサービスに短い名前を与える。これは、filter節を記述する際に使用され、その値は文字列である。例えば、"http://coolness.raleigh.ibm.com/ratings/V1.html"というレーティングサービスのshortname は "Cool"である。

BureauURL属性は、このレーティングサービスからのレーティングを持つラベルビューローのURLを指定する。この属性の値は、ラベルビューローのURLである。この属性は複数回指定されてもよい。ユーザエージェントは、指定されたすべてのURLからラベルを取得し、ポリシーの評価にそれらすべてのラベルを使用しなければならない。

UseEmbedded属性は、ドキュメントとともにHTTPヘッダで伝送されたラベルやMETAエレメントを使用してHTMLドキュメントに埋め込まれたラベルを使用するかどうかを決定する。この属性が省略されている場合は、既定値でそれらのラベルを使用する。この属性の値が "N" の場合は、ドキュメントに埋め込まれたこのサービスに対するラベルは、HTTPヘッダで伝送されたラベルと同様に無視される。これは、ルールの作成者がドキュメントの作成者が提供するラベルが信頼できず、ラベルビューローのラベルがより信頼できる場合に有効である。

BureauUnavailable属性は、bureauURL属性で指定されたどのラベルビューローにもアクセスできない場合にどうするかを指定する。この属性に対する値は "PASS"と"FAIL"であり、その他のラベルが見つけられたかどうかに関わらず、ルールは対応する値を返す。

Ratfile属性は、このレーティングサービスが使用する、マシン読み取り可能なレーティングシステムの説明（"RAT file"として知られているもの）を示す。これは、次の2つの方法のうちどちらかで指定される。それは、値をマシン読み取り可能なサービス説明のすべてをクォーテーションマークで囲んだものとするか、"[RATFile-URL]"の構文で、 RATFile-URLの部分をレーティングシステム説明のURLにするかのどちらかである。ユーザエージェントは、このURLを逆参照すると application/pics-service のタイプのドキュメントになることを想定するべきである。Ratfile属性に既定値はない。クォーテーションマークで囲まれた文字列がマシン読み取り可能なサービス説明である場合は、上の説明のようにエスケープされなければならない。

Opt-extension-clause と req-extension-clause は、PICSRulesの拡張メカニズムである。これらは、PICSラベルフォーマットの拡張メカニズムの後でモデル化された。拡張メカニズムに関する詳細な情報を以下に示す。

Opt-extension-clause には、extension-nameとshortnameという2つの属性がある。extension-name属性の値は、このルールで使用される拡張の名前を指定する。拡張の名前は、quotedURLである。このURLは、人間に読める形式でこの拡張の説明を示すものである。URLは、central naming body を必要としないで拡張名の一意性を確実にするためのものである。Shortname属性の値はクォーテーションマークで囲まれた文字列であるが、有効な属性名文字 (a-z, A-Z, 0-9) のみを使用しなければならない。Shortnameは、この拡張で定義される属性を識別するために、属性名の接頭辞として使用される。

認識できない optextension を含むルールを受信した場合には、ユーザエージェントは認識できない節をすべて無視してルールを処理するべきである。これは、オプションの拡張は既存のparser（解析者）を壊さないように、上記の属性−値の構文を使用しなければならないことを意味する。ユーザエージェントは認識できない属性と値の組み合わせを廃棄するため、オプションの拡張を使用するという宣言は冗長であるように見えることに注意が必要である。ユーザエージェントはまた、ルールを使用する前にユーザが確認できるように、ルールが使用するオプションの拡張の名前を表示してもよい。

この節には、extension-nameとshortnameという2つの属性がある。extension-name属性の値は、このルールで使用される拡張の名前を指定する。拡張の名前は、quotedURLである。このURLは、人間に読める形式でこの拡張の説明を示すものである。URLは、central naming body を必要としないで拡張名の一意性を確実にするためのものである。Shortname属性の値はクォーテーションマークで囲まれた文字列であるが、有効な属性名文字 (a-z, A-Z, 0-9) のみを使用しなければならない。Shortnameは、この拡張で定義される属性を識別するために、属性名の接頭辞として使用される。ユーザエージェントが認識できないreq-extension-clauseを含むルールを使用してURLの受理の可能性に関する処理を求められた場合は、ユーザエージェントはエラーを表示するべきである。

このルールが対応しているPICSRulesのメジャーバージョン番号。PICSRulesの現バージョンのメジャーバージョン番号は１である。

このルールが対応しているPICSRulesのマイナーバージョン番号。PICSRulesの現バージョンのマイナーバージョン番号は１である。

1． Name節とclause節は、PICSERulesルール内では1度しか使用してはならない。

2．Optextension, reqextension, serviceinfo の各節は PICSRulesルール内で複数回使用してもよい。

3．それぞれのpolicy節には、｛AcceptIf, RejectIf, AcceptUnless, RejectUnless, AcceptByURL, RejectByURL｝のセットから必ず1つの属性が必要である。

4．ルールにはpolicy節がいくつ含まれていてもよい。

5．policy節には explanation属性が複数含まれていてはならない。

6．Extension節あるいは service節のshortname属性は、値としてクォーテーションマークで囲まれた文字列を持つが、その文字には属性名で使用可能な文字以外が含まれていてはならない。

7．PICSRulesのparser（解析者）は、ルール内で指定された属性の値（あるいは値の一覧）の順序を維持しなければならない。

Policy節では、AcceptByURL属性およびRejectByURL属性がURLpatternエレメントを使用するが、そのBNFを以下に示す。

URLpattern :: internet-pattern | other-pattern

internet-pattern :: internet-scheme '://'

[user '@'] hostoraddr [':' port] ['/' pathmatch]

internet-scheme :: '*' | 'ftp' | 'http' | 'gopher' | 'nntp' |

'irc' | 'prospero' | 'telnet'

user :: ['*' | '%*'] notquotechar* ['*' | '%*']

hostoraddr :: ['*' | '%*'] host | ipwild ['!' bitlength]

ipwild :: ipcomponent '.' ipcomponent '.' ipcomponent '.' ipcomponent

ipcomponent :: integer between '0' and '255' inclusive

bitlength :: integer between '0' and '32' inclusive

host :: substring of a fully qualified domain name as described

in Section 3.5 of [RFC1034]

port :: '*' | integerorwild [ '-' integerorwild ]

pathmatch :: ['*' | '%*'] notquotechar* ['*' | '%*']

integerorwild :: digit+ | '*'

digit :: '0' - '9'

other-pattern :: scheme : ['*' | '%*'] notquotechar* ['*' | '%*']

scheme :: '*' | schemechar+

schemechar :: 'a' - 'z' | 'A' - 'Z' | digit | '+' | '.' | '-'

(as specified in [RFC1738])

RejectbyURL policy節により、URLの一致が TRUE の場合に「拒否する」というルールになる。同様に、AcceptbyURL policy節により、URLの一致が TRUE の場合に「受理する」というルールになる。どちらの場合も、policy節に関連する説明が返される。URLパターンのリストが提供されている場合には、パターンのどれかが一致すればURLの一致は TRUE になる。URLの一致が FALSE の場合には、policy節は無視され、続いて次のpolicy節の評価が行われる。

URLパターンとURLの比較を行う場合、ルールのインタープリターはURLの unencode を行ってはならない（つまり %2F を / に変換してはならない）。パターンがインターネットパターンとして解釈できる場合には、パターンはコンポーネント部分に分割され、パターンに含まれるすべてのコンポーネントが一致する場合に、URLはパターンに一致することになる。

パターンの '*' はすべてのスキームに一致する。そうでなければ、完全な文字列の一致が必要だが、この比較は case-insensitiveである。スキームのコンポーネントはパターンから省略されてはならない。

パターンの先頭や最後の '*' は、URL文字列の何文字とでも一致する。パターンの先頭や最後の '%*' は、URL文字列の '*' という１文字に一致する。パターンの中の文字はURL文字列の文字と完全に一致しなければならない。この比較は case-sensitiveである。パターン内の '*' というuserコンポーネントもまた、userコンポーネントを省略するURLと一致する。パターンでuserコンポーネントが省略されている場合は、userコンポーネントがURLからも省略されている場合に限り一致する。

PICSRulesパターンではpasswordを指定しない。パターンはどんなパスワードを指定するURLとも一致するし、passwordコンポーネントが省略されたURLとも一致する。

パターン内の hostoradress がIPアドレスである場合、URLの対応するhostコンポーネントが最初にIPアドレスのセットに分解される。IPアドレスのどれかに一致すればパターンは一致する。!とbitlengthが指定されている場合、パターンとURLの両方が10進表記から2進表記に変換され、文字列の最初のbitlengthビットが比較される。したがって、'!'は、サブネットやCIDRブロックを指定する場合に、通常は'/'が持っているのと同じ意味を持つ。!を使うのは、/ を誤って区切り文字と解釈する場合があるからである。比較は最初の16ビットのみで行われるので、18.23.7.22!16 は 18.23.0.0!16 と同じである。

パターンの先頭の '*' は、URL文字列の何文字とでも一致する。パターンの先頭の '%*' は、URL文字列の '*' という１文字に一致する。パターンで後に続く文字は、URL文字列の残りの文字と完全に一致しなければならない。この比較は case-insensitiveである。パターンがホスト名（またはワイルドカードを含むホスト名）を指定する場合は、パターン内のホスト名がURL内のIPアドレスに分解されるとしても、それはIPアドレスを指定するURLとは一致しないことに注意すること。これにより、URL内のIPアドレスに基づいてDNSを逆に探す作業をわざわざ行う必要がなくなる。URLパターンでは、host または ipwildのコンポーネントのどちらかが必ず指定されていなければならない。

パターンで2つの番号が指定されている場合、その範囲内のすべてのポート番号と一致する。例えば、パターンのportコンポーネントが "80-82" の場合、それはポート番号が 80, 81, 82 であるURLと一致する。範囲の一部としてワイルドカード * が指定されている場合は、極限値を表している。つまり、パターンのportコンポーネントが "*-82" の場合は82以下のすべてのポート番号と一致し、"80-*" の場合は、80以上のすべてのポート番号と一致する。パターンのportコンポーネントが単に "*" の場合は、portコンポーネントを省略するURLを含めて、すべてのポート番号を持つURLと一致する。パターンのportコンポーネントが省略されている場合は、ポート番号を省略したURLとのみ一致する。

パターンの先頭や最後の '*' は、URL文字列の何文字とでも一致する。パターンの先頭や最後の '%*' は、URL文字列の '*' という１文字に一致する。パターンの中の文字はURL文字列の文字と完全に一致しなければならない。比較は case-sensitiveである。パターン内の '*' というpathコンポーネントもまた、pathコンポーネントを省略したURLと一致する。パターンでpathコンポーネントが省略されている場合は、pathコンポーネントがURLからも省略されている場合に限り一致する。

警告：パターン内でコンポーネントが指定されていない場合は、パターンが省略されたURLとのみ一致する。URLのあるコンポーネントを無視する場合には、そのパターンコンポーネントに "*" を指定する必要がある。例えば、pathname に "buy" という文字列を含むすべてのURLへのアクセスをブロックするためには、正しいパターンは "*://*@*:*/*buy*" となる。パターンを "*://*/*buy*" あるいは "*buy*" とするのが自然なように思えるが、前者の場合、usernameとポート番号を省略するURLとのみ一致するし、後者は有効なパターンとはいえない。

パターンがインターネットスキームとして解釈不可能な場合には、それはスキーム名とスキームに固有な部分とに分割される。スキーム名での "*" は、すべてのURLのスキームと一致する。それ以外は、完全な文字列の一致が必要である。この比較はcase-insensitive である。スキームに固有な部分の先頭や最後の "*" は、URL文字列の何文字とでも一致する。パターンの先頭や最後の '%*' は、URL文字列の '*' という１文字に一致する。パターンの中の文字はURL文字列の文字と完全に一致しなければならない。この比較は case-sensitiveである。

注意：URL文字列の文字 '%*' に完全に一致するURLpattern を記述するのは不可能である。しかしこれはパターンマッチング言語の制限ではない。なぜなら、有効なURLにおいて、'%'文字には2つの16進数が続かなければならないからである。つまり、'%*' という文字列を含むURLは存在しない。

URLで %を使用してコード化された文字は比較の前に unencode されないので、PICSルールの評価者はそれらをシノニムとして扱わないが、サーバは２つのURLをシノニムとして扱うかもしれない。つまり、サーバがURLパスのunencodingルールに従うと、

<http://www.student1.mit.edu/sex>, <http://www.student1.mit.edu/%73%65%78>, < http://www.student1.mit.edu/se%78>に対して、サーバは同じページを返すのである（%73は's'、%65は'e'、%78は'x'になる）。

あいにく、パターンを比較を行う前に常にURLをunencoding する代替のマッチングルールは、曖昧さをもたらす。例えばHTTPでは、通常の ? は問い合わせ文字列の区切り文字として扱われ、? は %3F としてコード化される。Unencoding後は、通常の ? と問い合わせ文字列の区切り文字を識別することは不可能になる。シノニムを犠牲にしても、パターンマッチングを正確にする方がよいと思われる。

その他にも、URL内のIPアドレスがルールパターンの比較のためにホスト名に変換されないという同様の制限がある。これは、ホスト名に基づいたパターンがIPアドレスに基づくURLの特定のシノニムと一致しなくなることを意味する。http://*.mit.edu というパターンは、http://18.0.0.0!8 というパターンよりも一致するURLが少なくなる。後者のパターンは、mit.edu で終わるウェブサイト（これらはIPアドレスが18で始まるもになる）と一致する。IPアドレスを含むURLがドメイン名を指定するパターンと一致しない理由は、URLでIPアドレスを逆に探すことはルーチンとして実行するにはコストの大きい動作だからである。したがって、それを行うことが効果的である場合には、ルールではホスト名の一致よりもIPアドレスの一致を指定するだろう。しかし、これにはホスト名が別のIPアドレスに変更されるたびにルールを更新する必要があることに注意しなければならない。

Policy節の AcceptIf, RejectIf, AcceptUnless, RejectUnlessのそれぞれの属性はすべて、引数として policy-expression をとる。これはさまざまなラベルで動作する表現である。このセクションではそれらの表現の構文と意味を定義する。

policy-expression :: simple-expression |

or-expression |

and-expression |

degenerate-expression

simple-expression :: '(' service ['.' category [op constant ] ] ')'

service :: any shortname defined in a serviceinfo clause within this rule

category :: transmit-name-char+ ['/' category]

注意：[PicsLabels]の仕様のように、レーティングサービスが階層的にネストされたカテゴリーを定義している場合は、一番外側のカテゴリー名が左に来て、スラッシュが続き、次のカテゴリー名が続くようになる。

transmit-name-char :: alphanumpm | '.' | '$' | ',' | ';' | ':'

| '&' | '=' | '?' | '!' | '*' | '~' | '@'

| '#' | '_' | '%' hex hex

alphanumpm :: 'A' | ... | 'Z' | 'a' | ... | 'z' | '0' | ... | '9' | '+' | '-'

hex :: '0' | ... | '9' | 'A' | ... | 'F' | 'a' | .... | 'f'

op :: '>' | '<' | '=' | '>=' | '<='

constant :: [sign] alphanum* ['.' alphanum*]

or-expression :: '(' policy-expression [or policy-expression]+ ')'

or :: 'or'

and-expression :: '(' policy-expression [and policy-expression]+ ')'

and :: 'and'

sign :: '-'

degenerate-expression :: 'otherwise'

節の評価を行う場合、ユーザエージェントは指定されたレーティングサービスのラベルを、使用しない、1つ使用する、複数個使用する場合がある（詳細については、コントロールフローのセクションを参照すること）。単純な表現では、指定されたサービスのラベルがひとつでも表現の条件を満たせば、trueと評価される。直感的に、ルールの評価者は使用可能なすべてのラベルに基づいて、表現が満たされていることを証明しようとする。

単純な表現がラベルから値を呼び出すときに、ラベルが使用できない場合や、指定されたカテゴリーについて使用可能なラベルが値を持たない場合を考慮しなければならない。そのような場合には、単純な表現はfalseと評価される。これは直感的な意味になる。つまり、単純な表現に関連するラベルがない場合には、その表現は表現によって要求を証明するための証拠にはなり得ないということである。

・degenerate-expression otherwise はtrue と評価される。

・op節で定義されるすべての演算子は、数字による、値をひとつだけ持つカテゴリーとして有効である。

・値をひとつだけ持つカテゴリーに定義される唯一の演算子は = である。

・単純な表現の結果が and や or と組み合わされている場合には、ブール理論が使用される。

・multivalue true 属性セットを持つカテゴリーでは、与えられた条件をラベルの値のどれかが満たす場合には、単純な表現は true と評価される。例えば、ラベルに (s (2 4))という値が含まれている場合、単純な表現 (Service.s < 3) は true と評価される。ここではラベルの値が2であるものは条件を満たすが、4であるものは満たさない。

・service のみを含む単純表現（category や op定数を持たないもの）は、指定されたレーティングサービスからのラベルの存在を主張する。service で指定されたレーティングサービスから有効なラベルが使用できる場合にはtrue となり、使用できない場合には false となる。

・service や category は含まれるが、演算子を含まない（op定数がない）単純な表現は、指定されたレーティングサービスから指定されたカテゴリーを含むラベルの存在を主張する。service で指定されたレーティングサービスから有効なラベルが使用でき、指定された category に対してラベルが少なくとも1つの値を持つ場合には、trueとなる。それ以外の場合、表現は false となる。

PICSRules-1.0 の初期のドラフトには、直感的に有効と思われる演算子 != が含まれていた。これは、値がない場合や値が複数ある場合にも、!= の直感的な意味はその他の演算子の意味と矛盾するため、この演算子は削除された。例えば、s という dimension に 2 と 3の値を持つ、(s (2 3))を含むラベルを考えてみる。3未満の値が存在するので、このラベルはポリシー表現 (Service.s < 3) を満たす。しかし、!= の直感的な意味は、すべての値が3以外であることを必要とする。経験的な定量化（3未満の値が存在する）と普遍的な定量化（すべての値が3以外である）が混在すると、混乱が生じることが分かった。さらに、"x != 3" は通常、"(( x < 3 ) or ( x > 3 ))" と同じ意味である。しかし複数の値が存在する場合には、この関係は保持されない。非直感的な意味を持つ演算子があることはよくないと考え、PICSRules-1.1 からは削除された。

注意深く読んでいただけば、max, min, forall のような普遍的な定量化の演算子が欠如しているだけでなく、ブール演算子 not もないことに気付かれるであろう。これらの省略は、!= の省略理由と同様に、熟考されたものである。特定のカテゴリーに対してラベルが値を持たない、あるいは複数の値を持つ場合には、このような演算子が無制限に使用されるとルールを理解することがとても難しくなる。そこで、下記のように、AcceptIf, AcceptUnless, RejectIf, RefectUnless という属性を使用して、否定や普遍的定量化の演算子はトップレベルでのみ使用するという制限を設けた。しかし、制限された言語ではあるが、"forall x, g(x) holds" が数学的に「g(x)が保持されないような x は存在しない」という意味を持つという事実を利用することで、表現力は豊かである。例えば、すべてのラベルが s-value の値が3であるURL をすべて受理したい場合を考えてみる。その時のpolicy節は

Policy (AcceptUnless "(Service.s < 3) or (Service.s > 3)" )

上記のルールの構文と意味は、ルールに何を入れるのかを定義し、それらの構造の意味を定義している。これらのルールを処理するため、ユーザエージェントはここで説明する内部的なデータフローを採用するべきである。これにより、PICSRulesが正式なものになったときに、それに対して必要な拡張を実装することが容易になる。

PICSRulesルールを処理する標準的なユーザエージェントは、rule parser, label sourse, label validators, rule evaluator という、4つの重要なコンポーネントを備えているべきである。それらの役割は以下の通りである。

PICSRulesルールを解析する。保存された構成情報やネットワークを介してロードされる場合もある。プロキシサーバのような複数のルールを保存するユーザエージェントでは、このコンポーネントはそれぞれの要求に対してどのルールを使用するかの決定も行う。以降のモジュールでは、ルールは1つだけ適用されることが前提である。

このコンポーネントはラベルを探す。これは評価の対象となっているルールから入力情報を受け取る。ラベルを探してラベルビューローと連絡を取るために、この情報を使用してもよい。また、HTMLドキュメントに埋め込まれたラベルや、ラベル伝送をサポートするデータストリーム（HTTP, NNTP）で伝送されたラベルを見つけてもよい。このコンポーネントによる出力は、問題のドキュメントに適用されるラベルのセットである。ラベルソースは複数あるため、ラベルソースコンポーネントはあるドキュメントに対してあるサービスから複数のラベルを生成する場合がある。しかし、ラベルソースコンポーネントは「最適な」ラベルを選択するものである。（一般的なラベルから明確なラベルを選び、一般的なラベルが複数ある場合にはもっとも明確なものを選ぶのである。）ラベルソースは、ラベルそのものだけでなく、ラベルがどのように取得されたか（コンテンツに埋め込まれたもの、ラベルビューローから得たものなど）について、その他のコンポーネントに明示する必要がある。

ラベル認証は、どのラベルを受け入れることができるかを決定する。PICSRules言語では認証は定義されていないが、その拡張において定義されるだろう。例えば、デジタル署名を持たないラベルを拒否するようなラベル認証が定義されるかもしれない。別の認証の可能性としては、信頼のおける第三者によってラベルの作者が保証されているかどうかを調べることができるものが考えられる。

ルール評価は、認証を通過したラベルと、ルール解析がルール内で見つけたPolicy節を入力として受け取る。これは、許可や禁止の表現を評価し、合格／不合格の決定を行う。

うまく設計されたネットワークプロトコルでは、拡張メカニズムが提供されている。ここでは、PICSRulesで提供されている拡張メカニズムを示す。

PICSRulesは、属性と値の組み合わせがネスト構造になったものである。認識できない属性キーワードはユーザエージェントによって無視され、それに伴う値はPICSRules解析によって廃棄される。PICSRulesを拡張する基本メカニズムは、新しい節や属性と値の組み合わせと、その文脈や意味を定義することである。新しい属性と値の組み合わせには、指定された拡張が伴う。拡張の名前は URLなので、世界的に識別することができる。PICSRuleで使用されるときには、属性名の潜在的な矛盾を避けるために、拡張属性名の前には その属性を定義する拡張のshortname がつく。

1．その拡張がオプションか必須かを決定する。オプションの拡張は、拡張を認識しないユーザエージェントによって無視されてもよい。拡張を「オプション」とするためには、拡張が無視された場合でもこの拡張を使用するルールの意味が変更されてはならない。

2．拡張に名前を付ける。拡張には一意のURLが指定されなければならない。URLでは、その拡張を詳細に説明する人間に読める形式のドキュメントを指定するべきである。拡張名の一意性を保証するため、URLはその拡張の作成者が制御するドメイン内になければならない。

3．拡張で新しい節の名前が必要な場合は、new-clause-name属性を使用して、この拡張で定義されるそれぞれの新しい節に使用される extension-clause-nameを定義する。

4．この拡張が定義する新しい属性と値の組み合わせを定義し、その組み合わせがどの節で使用されるのかを定義する。

5．この拡張で定義される新しい属性と値の組み合わせの意味を定義する。特に、拡張がPICSRulesの既存部分を無効にする場合は、この動作は正確に記述されなければならない。拡張がPICSRulesの既存の意味を無効にする場合には、これは必須の拡張となる（optextension ではなく reqextension を使用する）。

オプションの拡張を使用するPICSRulesルールの例は次のようになる。

1 (PicsRule-1.1

2 (

3 ServiceInfo (

4 "http://www.coolness.org/ratings/V1.html"

5 shortname "Cool"

6 bureauURL "http://labelbureau.coolness.org/Ratings"

7 )

8 Policy (AcceptIf "((Cool.Coolness < 3) or (Cool.Graphics < 3))" )

9 Policy (RejectIf "otherwise")

10 optextension (

"http://www.si.umich.edu/~presnick/pics/extensions/PRsample.htm"

11 shortname "extension1")

12 extension1.SampleAttribute (

13 UseExpired "YES"

14 GroupFile "/etc/ics.grp"

15 )

16 )

17 )

この例では、http://www.si.umich.edu/~oresbucj/pics/extensions/Prsample.htmという名前の付けられたオプションの拡張を利用する。この拡張では、SampleAttributeというキーワードを定義している。この拡張を理解できないユーザエージェントは、単に extension1.SampleAttribute節とその属性と値の組み合わせ（12から14行目）を無視することができる。

拡張を宣言するのは１つの「レベル」だけだが、拡張で定義された属性と値の組み合わせはPICSRulesルールのどの場所でも使用できる。つまり、すべての拡張はその rule-clauseで optextension またはreqextension節で宣言を行うべきだが、拡張で定義された属性と値の組み合わせはルール内のネストされた複数の層で使用してもよい。

[PicsLabels]

Jim Miller, editor. "PICS Label Distribution Label Syntax and Communication Protocols". http://www.w3.org/PICS/labels.html.

[PicsServices]

Jim Miller, editor. "Rating Services and Rating Systems (and Their Machine Readable Descriptions)". http://www.w3.org/PICS/services.html.

[RFC1034]

Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, USC/Information Sciences Institute, November 1987. http://ds.internic.net/rfc/rfc1034.txt

[RFC1123]

R. Braden, editor. "Requirements for Internet Hosts -- Application and Support". http://ds.internic.net/rfc/rfc1123.txt.

[RFC1738]

Tim Berners-Lee et al, "Uniform Resource Locators". http://ds.internic.net/rfc/rfc1738.txt.

[RFC2070]

F. Yergeau, G. Nicol, G. Adams, and M. Duerst. "Internationalization of the Hypertext Markup Language". http://ds.internic.net/rfc/rfc2070.txt.

[RFC822]

David H. Crocker, editor. "Standard for the Format of ARPA Internet Text Messages". http://ds.internic.net/rfc/rfc822.txt.

[UNICODE]

The Unicode Consortium, "The Unicode Standard -- Worldwide Character Encoding -- Version 1.0", Addison- Wesley, Volume 1, 1991, Volume 2, 1992, and Technical Report #4, 1993.

[UTF-8]

ISO/IEC 10646-1:1993 AMENDMENT 2 (1996). UCS Transformation Format 8 (UTF-8).

このドキュメントの作成に当たって、以下の各氏のご協力に感謝します。彼らの助けなくしてはこれを成し遂げることはできませんでした。構文の変更や例のテストを可能にする解析コードを作成したDavid Shapiro 氏には、特に感謝しております。

Scott Berkun, Microsoft

Jonathan Brezin, IBM

Yang-hua Chu, MIT

Lorrie Cranor, AT&T

Jon Doyle, MIT

Ghirardelli Chocolate Co.

Brian LaMacchia, AT&T

Breen Liblong, NetShepherd

Jim Miller, W3C

Mary Ellen Rosen, IBM

Rick Schenk, IBM

Bob Schloss, IBM

David Shapiro, MIT

Ray Soular, SafeSurf