PICSRules 1.1

要約

概論

• プロファイルの共有とインストール。エンドユーザにとって、ユーザインターフェースがよくでき ている場合でも、洗練されたプロファイルを定義することは難しい。ある組織が一定の年齢層のこど もに対する推奨プロファイルを作成することができる。ユーザがその組織を信頼する場合には、プロ ファイルを一から自分で作成するのではなく、推奨プロファイルをインストールすることができる。 １台のコンピュータ上でアクティブなプロファイルを変更することや、新しいコンピュータにプロフ ァイルを導入することは容易である。
• エージェント、検索エンジン、プロキシ、その他サーバとの通信。さまざまなサーバは、プロフ ァイルに記述されたユーザの選択を満たす結果を出すように調整する。例えば、検索エンジンは、 質、プライバシー、年齢による適不適、あるいはダウンロードするコードの安全性に基づいた基準を 指定するユーザプロファイルに一致するリンクのみを返す。
• フィルタリング製品間の移植性。すべてのPICSルール互換の製品で同じプロファイルが動作する。

定義

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

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

SHOULD（〜するべきである）

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

MAY （〜してもよい）

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

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

PICSRules 言語：例

例１：特定URL へのアクセスの禁止

 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にはアクセス可能である。

例２：PICSラベルに基づいたアクセスの禁止

 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 )

例３：PICSラベルに基づいたアクセスの許可：その他のものをすべてブロックする

 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 )

例４：より複雑な例

 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. その他のものにはアクセスできる。

詳細構文

まず初めに 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 '

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

文字列内でその他の引用文字が使用される場合がある。文字列内でシングルおよびダブルクォーテーショ ンマークを使用するために、以下の慣例を適用する。

1. "は %22 としてコード化する
2. 'は %27 としてコード化する
3. %は %25 としてコード化する
4. % の後に22,27,25 以外のものが後に続くものは、構文的に無効である

国際化

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

すべての属性名は大文字/小文字を区別しないが、値の case は保存されなければならない。しかし、個々 の節かつ／または属性は、それらの値を大文字/小文字を区別しないと定義してもよい。

コメント

コメントの構文は以下の通りである。

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

comment-text:: any characters except '}'

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

PICSRules ルール

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ではここで説明した構文を正確に
     必要とする。時間や時間帯のどちらが省略されてもいけないし、
     代替フォーマットも許されない。区切りもここで示した通りで
     なければならない。

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

一般的な意味

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

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

個々の節の意味と詳細

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

この節は、提示されているルールに、人間が読める形式の短い名前を与える。これらの名前は、ロードさ れているルール、そのアクティブ／インアクティブなどを操作者に表示するために、ユーザエージェント のユーザインターフェースで使用されるものである。

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

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

source

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

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

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

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

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

serviceinfo

この節は、レイティングサービス(serviceinfo)に関する情報を指定する。この節には、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

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（解析者）を壊 さないように、上記の属性−値の構文を使用しなければならないことを意味する。ユーザエージェントは 認識できない属性と値の組み合わせを廃棄するため、オプションの拡張を使用するという宣言は冗長であ るように見えることに注意が必要である。ユーザエージェントはまた、ルールを使用する前にユーザが確 認できるように、ルールが使用するオプションの拡張の名前を表示してもよい。

req-extension-clause

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

req-extension-clause を含むルールを使用してURLの受理の可能性に関する処理を求められた場合は、ユー ザエージェントはエラーを表示するべきである。

verMajor

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

verMinor

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

制限

1. name節とsource節は、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（解析者）は、ルール内で指定された属性の値（あるいは値の一覧）の順序を維持 しなければならない。

URLに基づいたフィルタリング

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])

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

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

パターンがインターネットスキームとして解釈不可能な場合には、それはスキーム名とスキームに固有な 部分とに分割される。スキーム名での "*" は、すべてのURLのスキームと一致する。それ以外は、完全な 文字列の一致が必要である。この比較は大文字/小文字を区別しない。スキームに固有な部分の先頭や最後の "*" は、URL文字列の何文字とでも一致する。パターンの先頭や最後の '%*' は、URL文字列の '*' という １文字に一致する。パターンの中の文字はURL文字列の文字と完全に一致しなければならない。この比較は 大文字/小文字を区別しない。
 
注意：URL文字列の文字 '%*' に完全に一致するURLpattern を記述するのは不可能である。しかしこれは パターンマッチング言語の制限ではない。なぜなら、有効なURLにおいて、'%'文字には2つの16進数が続か なければならないからである。つまり、'%*' という文字列を含むURLは存在しない。

既知の制限

あいにく、パターンを比較を行う前に常に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-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'

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

上の定義のように、単純な表現はどんなタイプのデータに対してもすべての演算子を使用することができ る。より明確には、表現の評価の意味は次のようになる。

• The degenerate-expression otherwise は true と評価される。
• op節で定義されるすべての演算子は、数字による、値をひとつだけ持つカテゴリーとして有効である。 視察により、明らかにすべきであるという意味において、値としては、 true または false.を返すだろう。
• 値をひとつだけ持つカテゴリーに定義される唯一の演算子は = である。
• 単純な表現の結果が 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 となる。

 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 )

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