この文書は、W3Cメンバと他の利害関係者によってレビューされており、ディレクタによってW3C推薦として指定されている。 W3C推薦の文書は、別の文書で参考資料として使われるか、規範的参照として引用されるものである。 推薦を作る際のW3Cの役割は、仕様へ注意を引き、広範囲にわたる展開を促進することである。これは、Webの機能性と操作性を高めるものである。

http://www.w3.org/pub/WWW/TR/ で、現在のW3C推薦と、他の技術的な文書のリストを見つけることができる。

この文書は、PICS(Platform for Internet Content Selection)技術分科会によって作成された。 これはPICSラベルとラベルを転送する3つの方法の一般的なフォーマットを定義したものである。

• HTML文書に記述して転送する
• RFC-822ヘッダーを使うプロトコル経由で文書とともに転送する
• 文書とは独立して転送する

PICSラベルとラベルリストの意味

HTML埋込みラベル

HTTPを使用したラベル付き文書の要求

MICsとディジタル署名

付録Ａ： ラベルビューロのロケーティングアルゴリズム

付録B： ラベルビューロの要求と応答のサンプル

この文書は、PICS(Platform for Internet Content Selection)の技術分科会によって作成された。 これはPICSラベルとラベルを転送する3つの方法の一般的なフォーマットを定義したものである。

• HTML文書に記述して転送する
  既存のMETAタグを用いてHTML文書(のヘッダー)に1つ以上のラベルを埋込む機構について記述している。
  
• RFC-822ヘッダーを使用するプロトコル経由で文書とともに転送する
  RFC-822ヘッダーを使用するどのプロトコルを使用してでも、ラベルを転送することができる。加えて、文書とともに(存在するならば)そのラベルを転送する要求をHTTPクライアント(Webブラウザ)に許可するよう、HTTPプロトコルの拡張を定義する。他のネットワークプロトコルが類似の方法で拡張されることをPICS技術分科会は希望する。
  
• 文書とは独立して転送する
  クライアントはHTTPプロトコルにしたがって動作する“ラベルビューロ”にラベルを要求することができる。ftp(gopherあるいはnetnews)のようなHTTP以外のプロトコルでもURL(RFC-1738を参照)を持っていれば、その文書のラベルを参照することができる。PICSはIRCチャットルーム(レイティングサービスとレイティングシステムを参照)を参照するための新しいURLスキームを定義していることに注意しなければならない。ラベルビューロの最も簡単な実施は、特別なCGIスクリプトを走らせているoff-the-shelf HTTPサーバである。
  

ラベルはサービス識別子、ラベルオプション、およびレイティングで構成されている。サービス識別子とは、ユニークな識別子としてレイティングサービス(“レイティングサービスとレイティングシステム”を参照)が選択しているURLである。ラベルオプションには、文書を評価した時間のようなレイティングされている文書の属性を記述する。レイティングは、1つ以上の次元に沿って文書を記述する一連の属性値対である。1つ以上のラベルがリストとしてに配布されてもよい。ラベルリストの一般的なフォームは以下のとおりである(エラーステータスコードは表示していない)。

specificラベルは１つの文書にのみ適用される。HTMLで記述された文書は、外部参照(例えば、<A href=...>タグを用いて)によって他の文書を参照するかもしれなく、また、インライン表示(例えば、<img...>または<object ...>タグを用いて)を要求するかもしれない。ラベルはその文書にのみ適用されるもので、参照する文書には適用されない。

genericラベル(genericオプションの使用によって識別される)は、(forオプションで指定した)特定の文字列で始まるURLで示されるすべての文書に適用される。genericラベルは、specificラベルによって無効にすることができる“デフォルト”ラベルとしての意味を持たない。クライアントが両方のラベルにアクセスすることで、specificラベルがgenericラベルを無効にするが、クライアントに2つのラベルが別々に配布されてしまうため、 genericラベルにのみアクセスしてしまうかもしれない。サーバはデフォルトの値を持ち、これをもとにしたローカルデータベースで無効にされないspecificラベルを作成することができる。しかしながら、サイト、あるいはディレクトリでそれがすべて文書に当てはまれば、サイトあるいはディレクトリのためのgenericラベルが配布されるべきである。

レイティングサービスは、与えられたURLをプレフィクスとしてgenericラベルを規定することができ、また、そのURLに１つのspecificラベルを規定することもできる。文書のspecificラベルが見つけられた場合、それはどんなgenericラベルよりも優先して使われるべきである。いくつかのPICSクライアントソフトウェアは、genericラベルの使用を制限するかもしれない。例えば、2つ以上のURLツリーレベルのノード上に文書が位置する場合、クライアントは、genericラベルを無効にするかもしれない。

ラベルオプションは3つのグループに分割することができる。最初のグループは、ラベルが付けられた文書についての情報を供給する。第2のグループは、ラベル自身についての情報を供給する。最後のグループは、その他の情報を供給する。

1. ラベル付けられている文書についての情報
   at quoted-ISO-date
   レイティングが適用された日付、レイティングが実施された時刻。重要でないが信頼できる値でなければならない、これは、message integrity check(MIC)オプションの代用にするができる。
   
   MIC-md5 "Base64-string"
   -or- md5 "Base64-string"
   評価結果のmessage integrity check(MIC)。MD5メッセージ ダイジェストアルゴリズム(RFC1321を参照)が、MICを計算するために使われている。メッセージダイジェストを作成する1つの方法は、RSA研究所から、無料でこの目的に利用するRSAREF(バージョン２.０)ソフトウェアの提供を受けることである。 “MICsとディジタル署名”を参照。
   
2. ラベル自身についての情報
   by quotedname
   このラベルの作成に責任があった人、あるいはレイティングサービスの実体の識別子。これは、読解可能な形式であるか、あるいはラベルの署名を証明するため、(base64エンコードした)認証と他の情報のセットとを含んだものである。
   for quotedURL
   レイティングを適用するアイテムのURL(または、URLのプレフィクス文字列)。このオプションは、genericラベルと他の限られたケース(“ラベル要求”を参照)で必要である(そのたでは任意)。１つの文書が多くのURLを持つことができるので、ラベルのforオプションのURLが要求したものと異なることがある。このURLはその文書を参照するために使用する。
   generic boolean
   -or- gen boolean
   このオプションがtrueにセットされた場合、ラベルはforオプションで与えられたプレフィクスでスタートしているURLに適用される。これは、レイティングをサイト全体、あるいはサイトのサブセットに対して適用するために使われる。また、すべてのgenericラベルはforオプションを含んでいなければならない。先に述べたように、もし、forオプションで指定されたプレフィクスで始めるURLのすべての文書に正しく適用することができないのであれば(specificラベルが存在するにしても)、genericラベルは作成されるべきではない。
   on quoted-ISO-date
   レイティングが発行された日付
   signature-RSA-MD5 "Base64-string"
   ラベルを含むRSAディジタル署名。署名は、ラベルを発行したレイティングサービスによってMD5アルゴリズムを用いて計算される。署名を作成する1つの方法は、RSA研究所から、無料でこの目的に利用するRSAREF(バージョン２.０)ソフトウェア提供を受けることである。“MICsとディジタル署名”を参照。
   until quoted-ISO-date
   -or- exp quoted-ISO-date
   レイティングが無効となる日付
   
3. その他の情報
   comment quotedname
   ラベルを見る人間のための情報;。関連情報はない。
   complete-label quotedURL
   -or- full quotedURL
   このURLを使用して参照すると、代わりとなる完全なラベルを返す。完全なラベルは、多くの属性値を持っている。短いラベルがパフォーマンス目的のために送られるが、これは追加の情報を利用する時に使われる。URLが参照された場合、１つのラベルからなるラベルリストを含むタイプapplication/pics-labelsのアイテムを返す。
   extension (optional quotedURL data*)
   -or- extension (mandatory quotedURL data*)
   将来、拡張するための機構。拡張時の名称の重複を避けるために、それぞれの拡張がquotedURLによって識別される。URLを参照すると、拡張に関する読解可能な記述を得ることができる。拡張が任意(optional)で、ソフトウェアが拡張を理解しない場合、無視することができる。拡張が強制(mandatory)で、ソフトウェアが拡張を理解しない場合、ラベルは供給されなかったものとして扱う。データのそれぞれのアイテムは、詳細なシンタックスで記述するように、simple-to-parseデータ型式でなければならない。http://w3.org/PICS/extensions/で現在使用されている拡張機能を参照することができる。

“PICSレイティングサービスとレイティングシステム”で記述するレイティングシステムの例として、２つの文書のラベルリストが、次のとおりであったとする。(すべての例で、スペーシングとインデンテーションが読みやすいように入れられている。複数のスペースは１つのスペースとして扱う。)

同じラベルリストは、よりコンパクトにすべての改行とインデント文字を１つのスペースに変換し、単語“labels”を“l”に、“ratings”を“r”というように長いオプション名称を省略形で置き換えて転送してもよい。それは、転送のため、さらに、すべてのオプション情報を別の文書に取り去り、URLによってその文書を参照するように圧縮してもよい。

以下にmodified BNFを使用したラベルの文法を記述する。

1. versionで記述する文字列“PICS-1.1”は、“PICSレイティングサービスとレイティングシステム”のPICS仕様のバージョン番号１.１に相当する。ラベルそれ自身が“PICS-1.1”を使い、サービス記述が“PICS-version１.１”の表記を使うのはエレガントでないが、これは意識的なものである。
   
2. スペースはクォートされた場合を除いて無視される。複数の連続したスペースは１つのスペースとして扱われる。
   
3. Transmit-namesとクォートされた文字列はcase sensitiveである。オプション名称とBNF文法の他のトークンでは、case insensitiveである。
   
4. この仕様では、クライアントからサーバへ転送される情報について、US-ASCIIを使用することを厳格に求めている。クライアントが他の文字セットを用いた記述へ、どのようにしてtransmit-namesを配置するかを、関連文書“PICSレイティングサービスとレイティングシステム”で記述する。クライアントは、効率的にラベルの情報をユーザに提供するため、レイティングサービスの記述をキャッシュするよう提示されている。
   
5. service-infoで示されるオプションは、すべてラベルに当てはまる。そして、service-infoは、specificラベルのオプションによって無効になる。 すなわち、適切なオプションを理解する目的で、service-infoの内側でラベルはネストされている。これは、by、generic、on、untilオプションや、将来のオプションの実験で有効であろう。上の最初の例では、最初のラベルのservice-infoでbyオプションが(“John Doe”の値で)提示されているが、第２のオプション(値“Jane Doe”によって)で無効にされている。
   
6. PICSラベル中の数値は、 IEEEの単精度浮動小数点数で規定されたものより大きな値、あるいは精度であることはない。 インプリメンタは、浮動小数点での比較を心配し、内部的にはASCII文字列で数を記述するかもしれない。
   
7. multi-valueシンタックスは、複数の値をもつようなカテゴリで使われなくてはならない。これは、１つの値しかない場合でも使われてよい。また、よりコンパクトなバージョンでは使われるかもしれない。値がない時、カテゴリは完全に省略しても、multi-valueシンタックスを用いて転送しても良い。
   
8. 個々のsingle-labelあるいはservice-infoで複数回記述される可能性のあるオプションは、commentとextensionである。もしextensionオプションが複数回記述されれば、拡張を定義しているquotedURLsは別個のものでなければならない。
   
9. レイティング情報のカテゴリは、どんな順序で現われるか決まっていない。application/pics-serviceで現われる順序に合致する必要はない。
   
10. 解析のため、括弧で括られたカテゴリと値のリストは ”ratings”か “r” のどちらかで終わることに注意しなければならない。もしこれがラベルリストの終わりでないなら、それは、新しいサービスURL (引用符によって囲まれていることで認識できる)あるいはエラー(”error”で始まる)のいずれかのラベル(おそらくオプションでスタートする)である。

quotedURL :: '"' URL '"' “レイティングシステムとレイティングサービス”で拡張したものをを記述している。

ISO8601:1988の日付と時間の基準を基礎として、フォームを限定した。

YYYY	::	4桁の年
MM	::	2桁の月 (01=1月、etc.)
DD	::	2桁の日 (01〜31)
hh	::	2桁の時間 (00〜23) (am/pmは許していない)
mm	::	2桁の分 (00〜60)
S	::	UTCからのタイムゾーンオフセットの符号 (‘+’ or ‘-‘)
tz	::	4桁のUTCからのオフセット
		(例えば、1512は15時間12分を意味する)

例えば、”1994.11.05T08:15-0500”は、米国東部標準時で1994年11月5日8:15を示す、quoted-ISO-dateである。

注意: ISO基準は、ここで記述したものより大きな柔軟性を許している。 PICSはここで記述されたシンタックスを正確に必要とする。──時間も時間帯も省略されてはならない、互換フォーマットは許されてなく、ここで指定したように句読点がなければならない。

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

注意: シングルあるいは2重引用符、あるいは括弧を挿入するために”%”エスケープ(%のあとに、ASCII文字セットで文字を表わす２つのHex数字を付加する)を使用する。

ラベルリストがPICSラベルの集まりを転送するために使用される。 ここで記述するフォーマットは、MIMEタイプ ”application/pics-labels” としてIANAで登録されるものである。 これは、ラベルとラベルが存在しない場合その理由を転送するときに使用する。また、ラベルを文書と一緒の転送、またはPICSラベルビューロから転送しなければならない時に使用するフォーマットである。ラベルリストは、常に括弧によって囲まれ、PICSバージョン番号(この仕様での1.1)で始まる。

ラベルリストは、ラベルが存在しない(例えば、“error(no-rating ...)”)、または、セクションに分けられたラベル(セクションはそれぞれレイティングサービスに該当する)のいずれかである。 それぞれのサービスのURLは、(serviceIDで)指定されなければならない。そして、なぜそのサービスにラベルが存在しないか(service-error)を示すエラーメッセージ、あるいは、すべてのオプション情報(option*)、キーワード “labels”(または “l”)、そしてサービスから渡されたlabelsのどちらかが続く。サービスから渡されたオプション情報は、もしspecificラベルで無効にしなければ、すべてのラベルに適用される。

ラベルには３つの種類がある。最初は、個々のURLでラベルを参照した時のエラーである(label-error)。第二は、もっとも一般的なものであるが、単語 ”ratings”(または “r”)とレイティング結果自身(カテゴリ名と値のリスト)で構成されるオプション(サービスで記述したものを無効にする)を含むsingle-label。最後に、文書全体のツリーの評価が要求された場合の特別な例であるが、括弧で囲まれたいくつかのsingle-labelsを転送することができる。このケースは、“ラベル要求”のセクションでより詳細に記述されている。

ラベルは特定のURLに対応するものか、あるいはgenericである。genericラベルは、プレフィクスで指定されたすべてのURLの暗黙の評価を行う。例えばURL“http://w3.org”のgenericラベルは、そのサイトのすべての文書に暗黙の評価を与える。同じURL“http://w3.org”のspecific(genericでない)ラベルは暗黙の評価を与えない。それは単に、ホストw3.org.へHTTPで、”GET /”を送信して持ってくるホームページを評価したものである。genericラベルは、どのURLにラベルを適用するかを指定する ”for” オプションを含んでいなければならない。上で言及したように、もし、ラベルのforオプションで指定された文字列から始まるURLのすべての文書に評価を正当に適用することができるならば、genericラベルが使用されるべきである。

multi-valueで値が渡される場合、数と数の範囲(”:”で範囲の終わりを記述する)のどんな組み合わせでも指定されてよい。

すべてのsubjectは、0.5と1.5の(両方の端点を含めて)の間のすべての値、か2となる。“レイティングサービスとレイティングシステム”で記述したサービスの例では、“water”(subject value 1)と“soapdish” (subject value 2)の2つのsubjectが採用される。3番目の“soap”はsubject valueが0であるため、採用されない。

電子インターネットメール、ハイパテキスト転送プロトコル、USENETニュースのような多くのプロトコルが、RFC-822で記述されているUS-ASCIIヘッダーを使用している。 そのようなプロトコルで使用するため、我々は、この文書でラベルについて記述した新しいヘッダー“PICS-Label”を定義する。文法は次の通りである。

labellistの部分の文法は上に記述している。 RFC-822で提示された仕様にしたがって、行頭は連続した空白で始まってよい。

HTML記述で定義されているMETA要素を使用し、 ラベルをmeta情報としてHTMLファイルに埋め込んでもよい。 埋め込みには、HTTPヘッダー機構を使用する。

content属性の記述にシングルクォートを使うことに注意しなければならない。なお、PICSラベルの文法では、ダブルクォートを使用している。contentに記述する以下の文字は、SGMLで指定した方法でエスケープしなければならない。

‘	&#39	/* single quote */
&	&amp	/* ampersand */
>	&gt	/* greater than */

“HTML2.0標準提案”を参照のこと。

通常、ラベルは指定されたURLに適用されるため、文書に埋め込まれているラベルでは“for”オプションを省略するかもしれない。文書に埋め込まれたspecific(genericでない)ラベルは、その文書に位置付ける時に使用したURLとは無関係に、その文書に適用される。genericラベルが “ホーム” URL(URLパスが‘/’で終了する)で参照することができる文書に埋め込まれている時、ホームURLをプレフィクスに含んでいるすべてのURLに適用される。

例えば、クライアントが文書“http: //www.greatdocs.com/foo/bar/bat.htm”のラベルに興味を持った場合、最初に、その文書がspecificラベルを埋め込んでいるか否かチェックする。もしなければ、クライアントは文書“http: //www.greatdocs.com/foo/bar/”の文書を要求する。サーバは、foo/barのホーム文書を送り返す。これが、foo/bar/index.html、foo/bar/home.html、あるいは他の何かであるかはサーバに依存する。もしその文書が埋め込まれたgenericラベルを含んでいれば、クライアントは、文書bat.htmに適用できると解釈する。もしクライアントがgenericラベルを見つけることができなければ、“http: //www.greatdoc.com/foo/”、あるいは“http://www.greatdocs.com/”というようにさらに上へ階層をチェックすることになる。

Webサイトオペレータは、そのWebサイトHTML文書にspecificラベルが埋め込まれることを望むであろうし、また、そのサイト、あるいはサイトのサブ部分について、できるだけ多くのレベルの階層のホーム文書がgenericラベルを含んでいることを望むであろう。次のセクションで記述するが、HTTPヘッダーでラベルを送信する場合、より優雅で機能的な方法を使うように奨励されている。

クライアントが、1つ以上のラベルを含む文書を要求するための簡単な拡張をHTTPに規定する。ここではHTTPプロトコルだけ取り扱う。 他のプロトコルでも同様の拡張が実施されることを希望する。HTTPサーバは、クライアントから要求されたときのみ、ヘッダーにPICSラベルを含んでいるべきで、また、クライアントが要求したサービスのラベルのみを含んでいるべきである。クライアントは、ラベルの“for”オプションで指定されたURLには無関係に、要求した文書のHTTPヘッダーで帰されたラベルを、文書に埋め込まれたラベルと仮定することができる。

Date: Thu、 30 Jun 1995 17:51:47 GMT

Last-modified: Thursday、 29-Jun-95 17:51:47 GMT

by "George Sanderson、 Jr."

クライアントは文書foo.htmlを要求し、加えて、レイティングサービス ”http: //www.gcf.org/v2.5” についての文書のfullラベルを要求する。サーバは、文書と同様にPICS-Labelヘッダーでラベルを送り返す。文書に(いくつかの)ラベルが存在しない時、サーバがHTTPエラーステータスを生成するのは不適当である。このため、 PICS-Labelヘッダーフィールド(labellist)のフォーマットでは、サーバがラベルか、ラベルが利用できない説明のどちらかを応答することを許可している。

通常のHTTPでのHEADとGETとの違いにしたがって、完全な文書を参照する前にレイティング値を調べることを望むクライアントは、要求する時の単語GETをHEADに置き換えることができる。 サーバは正確に上に示されたヘッダーを返答するが、foo.htmlの文書は送り返さない。

以下に、modified BNFで、文書と関連するラベルを要求するためにHTTPのヘッダーラインに追加した文法を記述する。

token-or-quoted-stringの先頭は'services'ではない。

minimalラベルが要求された場合、 genericラベルが返されるのでなければ、すべてのオプションが省略される。genericラベルが返される場合、genericオプションとforオプションがラベルに含まれていなければならない。shortラベルは、 minimalラベルに含まれているすべてに加え、サーバが適切と考える追加のオプションを含んでいる。complete-label(または full)オプションで、fullラベルが要求された場合、可能な限りの情報がラベルで返却される。ただし、signature-RSA-MD5オプションは必要とされていない。

signedラベルが要求された場合、 fullラベルのすべての情報がラベルのディジタル署名と共に送られる。signedラベルは、ラベルの一部として(署名を計算した値を含んだ)情報が転送されなければならない。 complete-label(またはfull)オプションは送られてもよいが、それは余分であろう。 ラベルの署名についての詳細を、セクション“MICsとディジタル署名”に記述している。

サーバにとって、オプションが送信されないことで、completenessを無視することは好ましいことである。もしcompletenessが省略された場合、minimalが与えられたように扱われる。将来の拡張で、completenessオプションの値として、どんな英数字の文字列でも使われるかわからない。completenessの値を受け取るサーバがこれを認識することができない場合、minimal指定されたように扱わなければならない。

extensionは、将来、プロトコルを拡張のためにある。 サーバが認識できない拡張は無視しなければならない。 実験的拡張では 拡張の記述を参照するURLを最初のtoken-or-quoted-stringとして使用することが推奨されている。

serviceに記述されているquotedURLには、クライアントが文書のラベルを要求したレイティングサービスが記述される。 たくさんのレイティングサービスから１つのHTTP要求で複数のラベルを要求することが可能であって、 serviceに要求と同数のquotedURL部の繰り返しがあるかもしれない。

2つの追加ヘッダーを記述する。

参照する文書とは切り離し、PICSラベルのみを参照することができる。この方法でラベルを要求するためには、クライアントはラベルビューロにアクセスする。ラベルビューロは、以下に記述する特殊な参照文を認識するHTTPサーバである。ラベルビューロは、HTTP以外のプロトコルを通して文書にアクセスし、他のサーバに存在する文書のラベルを供給する。 多くのレイティングサービスについて作り出されたラベルを、“有名な”ラベルビューロが(おそらく有料で)分配すると予測される。

レイティングサービスは、自身のラベルへのオンラインアクセスを提供することで、ラベルビューロとして動作するよう推奨されている。既定値では、レイティングサービスの識別子であるURLは、ラベルビューロの識別子である。クライアントがレイティングサービスのURLを要求すれば、“レイティングサービスとレイティングシステム”で記述するように、人間が判読可能なサービスの説明が返却される。一方、クライアントが同じURLで、以下に定義する問い合わせパラメータを含んだ要求を実施すれば、それはラベルを要求したものと認識される。しかしながら、レイティングサービスは、ラベルビューロとして動作することを要求されていない。そして、ラベルビューロとしての動作は、異なったURL(たぶん異なったHTTPサーバで)で実現するかもしれない。

(さらに複雑な問い合わせと応答は、付録Bを参照)

ここでは、http://www.labels.org/RatingsのURLで識別される、レイティングサービスを仮定している。このレイティングサービスは、(少なくとも)自身の文書のラベルを配布するために、ラベルビューロを動作させている。次の問い合わせのサンプルは、HTTPサーバwww.labels.orgへの要求の実例である(改行が提示目的のため挿入されている)。

http://www.labels.org/Ratingsに対して、サイトwww.questionable.org.の階層imagesのすべてに適用されるsingle labelを送信するよう問い合わせている。要求するラベルは、サービスhttp://www.gcf.org/v2.5によって作られたものである。“:”の表示に%3Aを、“/”の表示に%2Fを使用していることに注意しなければならない。これは、URLの文字をエンコードしたものである。RFC-1738を参照のこと。

ラベルビューロは、タイプ“application/pics-labels”の文書を返送する。返却されるラベルは、できるだけ多くのオプションを含んでいるか、complete-label(またはfull)オプションが与えられたときのように、完全であるべきである。

以下に、modified BNFで、ラベルビューロに対して要求するGETとPOSTの文法を記述する。POST要求の使用方法は、GET要求を取り扱うことのできないHTTPサーバとの互換性のためだけに記述している。POSTの使用は、HTML2.0仕様(”for use in submitting forms”、セクション8.2.1と8.2.3を参照)で批判されている。

url-fragment :: HTTP1.0で指定された、ホスト名のあとのオリジナルURLの部分。

crlf :: 改行(hex D) 復帰 (hex A)

tokenは、opt、format、u、またはsのいずれかではない。また、token-or-quoted-stringは、RFC-1738で記述した規則でクォートされたものである。

and :: '&' 問い合わせが ’?’の直後につづくものでなければ、これがなければならない。

encodedURL :: クォートされたURL。RFC-1738にあるように、URL中の引用符といくつかの特殊文字は、”%xx” という表記法を用いてエンコードされる。アルファベット文字、数字、および特殊文字 $_-.+!*'() はクォートする必要はないが、他の文字はクォートしなければならない。コロン(:)を%3Aに、スラッシュを%2Fにエンコードしなければならないのは、このためである。

formencodeddata ::getで記述した問い合わせ、ただし、HTML2.0のセクション8.2.1、8.2.3で記述してあるように、MIMEタイプapplication/x-www-form-encodedにエンコードされている。

• ラベルビューロは、MIMEタイプ “application/pics-labels” の文書を返送することで応答する。
  
• もし文書が総合的なエラーを示しているのでなければ、問い合わせたレイティングサービスそれぞれに1つのservice-infoが格納されている。個々のservice-infoは、要求するURLについて、エラーメッセージ、あるいはラベル(“tree”問い合わせの場合のラベルのリスト)を含んでいる。
  
• 問い合わせでの順序は、応答でも保持されなければならない。すなわち、レイティングサービスの情報は、問い合わせで現れるレイティングサービスの順序でなければならない。また、各サービスで現れるURLは、問い合わせであらわれるURLの順序でなければならない。もし、レイティングサービス、あるいはラベルが提供されていないならば、エラーメッセージは、service-info、あるいはラベルと同じ位置に現れる。順序が保持されているので、それは、評価したURLを示すオプション“for”は、ラベルから省略することが(以下に示した場合を除き)好ましい。クライアントは、レイティング値を要求したURLの位置によって、ラベルを検出するべきである。
  
• 定義。 URL(例えば、“http://www.greatdocs.com/foo/”)が与えられた場合、descendant URLは、あたえられたURLをプレフィクスとして含んでるURL(例えば、“http://www.greatdocs.com/foo/bar/bat.htm”)である。child URLは、descendant URLのうち、与えられたURLに追加の “/”文字を含まないURL(例えば、“http://www.greatdocs.com/foo/ba”)である。ancestor URLは、与えられたURLプレフィクスの部分的なURL(例えば、“http://www.greatdocs.com/f”)である。URLの上下関係は、HTML文書に現われるリンクによるURLの参照ではなく、URL文字列のcase-sensitiveによる比較で決定されることに注意しなければならない。コロン“:”を示す%3A、あるいはスラッシュ“/”を示す%2Fのようなクォーテーションは、URL文字列の比較の前にアンエンコードされることに注意しなければならない。
  
• opt=normal、あるいはoptの省略は、指定されたURLのspecificラベルを問い合わせる。specificラベルが存在しない場合、サーバは要求されたURL、またはancestor URLのgenericラベルを送信する。例えば、URL “http://w3.org/PICS/Overview.html”に対するラベル要求の場合、URL “http://w3.org/PICS”(あるいは、“http://w3.org”)のgenericラベルが返却される。この場合、どのURLのレイティング値が返却されたのか明確にするため、ラベル中に“for”オプションと、“generic”オプションが含まれている必要がある。“for”オプションが問い合わせたURLとは異なるURLを示すのは、おそらく、サーバが同じ文書の異なるURLの存在を知っているためである、ということに注意しなければならない。この場合、サーバは要求されたURLに適用されるラベルを返却しているにもかかわらず、疑い深いクライアントが返却された情報を採用しないかもしれない。
  
• opt=genericはgenericラベルを問い合わせる。これは、サイト全体、あるいはサイトの一部の評価を問い合わせる場合に有用である。問い合わせした個々のURLについて、問い合わせたURLとすべてのdescendant URLに適用されるgenericラベルが返答される。問い合わせたURLのgenericラベルや、ancestor URLのgenericラベルは、問い合わせたURLをプレフィクスとして含んでいるすべてのURLのgenericラベルとして適用することができる。もしそのようなgenericラベルが存在しないならば、サーバは、specificラベルを返却するのではなく、”no-label” メッセージを返却する。
  
• opt=treeはラベルツリーを問い合わせる。これは、サイト、あるいはサイトの一部に適用されるすべてのラベルを問い合わせる方法である。問い合わせ個々のURLについて、下位のURLの一連のラベル(specificとgenericの両方)が返答される。応答には、すべてのラベルが、括弧で囲まれたsimple-labelsの集まりとして返却されることが期待される。括弧で囲むことで、クライアントは要求した1つのURLのラベルセットに位置付けることができる。返却されるすべてのラベルには、forオプションを含んでいなければならない。期待することのできる最小の応答は、問い合わせたURLのすべてのchildに対して、opt=normalを指定した問い合わせが発行された場合に作成されるラベルの集まりである。また、加えて、childよりも下の階層のchild URL、およびancestor URLのgenericラベルを返却することができる。
  
• opt=generic+treeは、opt=tree問い合わせと同様であるが、genericラベルのみが返却される。opt=treeと同様に、サーバは、詳細の量を選択することができる。期待することのできる最小の応答は、問い合わせたURLのすべてのchildに対して、opt=genericを指定した問い合わせが発行された場合に作成されるラベルの集まりである。加えて、ancestor URLのgenericラベルを返却することができる。この問い合わせで返却されるすべてのラベルにはforオプションが含まれていなければならない。
  
• 問い合わせに対して、1つ以上のURLおよび(または)サービスの情報を返却することが許されている。u個の URLとsサービスが問い合わせされた場合、u×s個のラベルが作成される(treeとgeneric+tree問い合わせの場合、ラベルセットになる)。
  
• format=には、ラベルと一緒に返却されるオプション情報について記述する。デフォルトはfull(minimalではなく)であるという点を除いて、文書サーバへ送られるcompleteness(“ラベル付き文書要求のためのHTTPの詳細な文法”を参照)と同じキーワードを取り扱う。サーバが受信したcompletenessの値が認識できないものであったならば、デフォルト値のfullが指定されたものとして動作する。この問い合わせで返却されるすべてのラベルにはforオプションが含まれていなければならない。

この仕様では、 PICSシステムで発生すると思われる問題を防止するため、2つの独立したセキュリティ機能を記述している。2つの機能は単独で使用してもよいし、一緒に使用してもよい。2つの機能は特許を取得した暗号化技術に頼っており、その使用がいろいろな法律の制限(米国からの輸出制限を含む)受けやすいものである。PICS技術分科会は、コード、あるいはアルゴリズムの正確な法律的な問題について、情報を提供することができない。

米国のRSA研究所(100 Marine Parkway、 Redwood City、 CA、 94065-1031)は、PICS仕様中の暗号化コンポーネントを実装するとき必要となるすべてのコードを提供する、RSAREFと呼ばれるソースコードキットを配布している。RSAデータセキュリティ社 社長のJim Bidzos氏は、我々に“RSAREFをPICS仕様の実装に使用する場合は、費用なしで利用できるだろう”と語った。法律問題などについての質問は、Bidzos氏にすること。

最初の問題は、文書が検査されラベルが作成されたのち、文書がラベルを更新せずに修正された場合に発生する。これは正当な(例えば、タイムワーナーは、タイム誌の最新号のページに更新し、ラベルはまだ有効と考えている)ことかもしれないし、権限を与えられていない者によって文書が勝手にいじられた結果かもしれない。PICSラベルは、この種の問題の防止のため、3つのオプションフィールドを持っている。

Until または exp

MIC-md5またはmd5

第2の問題は、ラベルを勝手に変更することと、捏造することである。ここに記述する問題は、エンドユーザに対して、受け取ったラベルが要求したレイティングサービスで作成され、その後、変更されなかったことを何らかの方法で保証することである。PICSは、ラベルに “ディジタル署名をする” ことを要求している。ディジタル署名は、現在のところ法律的に認知されていないが、厳密に保証することのできる暗号化テクニックである。RSA署名テクニックは、次のように動く。

• ラベルに署名する手段としては、まず、レイティングサービス(または、サービスのラベル作成を許可された人)は “public key pair” を必要とする。(RSAREFソフトウェアは、これらの対を作り出すためにルーチンを含んでいる。)一方のkey(private key)は、サービスが隠し持っている。もう一方のキー(public key)は、サービスのラベルで署名を確認する人に配布されなければならない。
  
• ラベルを作り出した後、サービスは、ラベルを下に記述する特殊フォームに変換し、MD5メッセージダイジェストを計算する。ダイジェストの暗号化には、サービスのprivate keyを使用する。ダイジェストを暗号化したものがディジタル署名となる。そして、ディジタル署名は、上で記述したbase64エンコーディングを使用してUS-ASCIIに変換される。(1行60文字に分割された)US-ASCII文字列は、ラベルのsignature-rsa-md5オプションに格納され、クライアントに転送される。(RSAREFソフトウェアには、署名を作成し、US-ASCIIに変換するルーチンが含まれている。)
  
• クライアントはラベルを受け取り、受け取った署名と、ラベルの特殊フォームから変換して作成される署名との確認を行う。クライアントは、メッセージダイジェストをラベルの特殊フォームを使用して再計算する。そして、signature-rsa-md5オプションの内容を取りだし、すべての改行を1つのUS-ASCII文字列に結合し、base64文字列からオリジナル(２進数)のフォームに変換し、サービスのpublic keyを使用して復号する。もしメッセージダイジェストが計算したものと異なれば、署名は無効である。(RSAREFは、この動作に関して、行を結合すること以外のすべての機能のルーチンが含まれている。)

keyの配布に関する問題(そして、もし、サービスのkeyが危険になった場合無効にする)は、商業的競争の領域である。今日、確立された利用可能な解決策は存在しないため、PICSはそれぞれのサービスが何らかの方法でpubic keyを配布すると仮定している。また、キーは無効にされる必要はないと仮定している。これは、明らかに完全な解決ではないが、特定の独占されている技術に依存することなく、今日実現できる限界であると考えている。

以上に概説したディジタル署名で、１つ、追加される問題がある。もし、レイティングサービスが、他者にその名前で、ラベルを作成することを許すならば(例えば、サービスがコンテンツ製作者による、セルフレイティングをサポートする)、ラベルはサービスとコンテンツ製作者の両者が署名する必要があるであろう。これ(おのおのが他者の署名なしにラベルに署名すること)は実現できるが、署名を確認するために必要なpublic keyを配布することが難しくなる。PICS仕様は、この問題の解決案も提案していない。(これも、商業的競争の領域である。)

1. PICSは、MD5メッセージダイジェストにRSA署名アルゴリズムを使用することを要求している。異なったアルゴリズムをサポートした場合、新しいラベルオプションを追加することで、PICS仕様を簡単に変更することができる。そのとき、このシステムは旧式のものとなる。
   
2. PICSは、ディジタル署名に使われるキー長さを指定しない。個々のサービスは法律問題や技術的な選択肢を調査する必要があり、その結果を採用するであろう。１つの回答を共通のものとし、詳細をこの仕様に書き入れて、再発行してもよい。
   
3. 署名に使用されるラベルの特殊フォームは、次のように計算される。

• サービスは、どのオプションを転送する署名ラベルに含めるかを決定しなくてはならない。署名の計算では、転送されなかったオプションを使用することはできない。我々は、signature-rsa-md5を除いたすべての既知のオプションを含まれていることを推奨する。どのオプションでも省略されてもよいが、オプションmic-md5(または、md5)と、full(または、complete-label)が省略されることは共通であろう。signature-rsa-md5オプションは、オプションリストに含めてはならない。
  
• 選択されたオプションは、そのもっとも短い名称(すなわち、complete-labelの代わりにfullを使う)でアルファベット順にソートする。もし、選ばれたオプションがデフォルト値を持っており、それがラベルで使われる値と同じであれば、オプションはリストから削除される。
  
• リスト中の各々のオプションは、ラベルに短いオプションの名称、1つの空白、オプションの値、空白の順に格納される。オプションの値は、もっとも短くなる形式が使用され、もしそれらがcase insensitiveであれば文字列は小文字で出力である。
  
• すべてのオプションを出力したのち、文字“r (”を出力する。
  
• 出力する転送名称とその値は、名称のアルファベット順(“アルファベット順”にはUS-ASCII文字の参照順序を用いる)で、転送名称と値を1つの空白で分けて出力する。値の出力には、multi-valueアイテムを分けるために1つの空白を使用することを除いて、空白は許されていない。
  
• “)”を出力する。
  

4. クライアントは、上に記述した特殊なラベルフォームを計算するとき、single-labelとservice-infoのすべてのオプションを使うだろう。これは、転送されるデータにどのオプションを含むかを決定するという、サーバの制限の影響を受けることを意味している。転送されるデータは、サーバがservice-infoで転送する、service-infoで記述した値か、ラベルのオプションの既定値のどちらかの、すべてのオプションを含んでいなければならない。

カテゴリ(category)

コンテントラベル(content label)

コンテントレイティング(content rating)

次元(dimension)

文書(document)

ハイパテキスト(hypertext)

ラベル(label)

ラベルビューロ(label bureau)

レイティング(rating)

レイティングサーバ(rating server)

レイティングサービス(rating service)

レイティングシステム(rating system)

スケール(scale)

転送名称(transmission name)

1. PICS， Rating Services and Rating Systems， Internet Draft， "draft-pics-services-00.txt"， 11/21/95.
2. R. Rivest， "The MD5 Message-Digest Algorithm"， RFC 1321， 04/16/1992.
3. N. Borenstein， N. Freed， "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies"， RFC 1521， 09/23/1993.
4. T. Berners-Lee， D. Connolly， "Hypertext Markup Language - 2.0"， RFC 1866， 11/03/1995.
5. T. Berners-Lee， L. Masinter， M. McCahill， "Uniform Resource Locators (URLs)"， RFC 1738， 12/20/94.

Bob Atkinson， Microsoft

Anselm Baird-Smith， W3C

Brenda Baker， Lucent

Scott Berkun， Microsoft

Tim Berners-Lee， W3C

Roxana Bradescu， AT&T

Daniel W. Connolly， W3C

Roy Fielding， W3C

Jay Friedland， SurfWatch

Henrik Frystyk Nielsen， W3C

Philip Gladstone， Raptor Systems

Michael Gordon， Prodigy

Wayne Gramlich， Sun

Woodson Hobbs， NewView

David Karger， MIT

Rohit Khare， W3C

Charlie Kim， Apple

John C. Klensin， MCI

Breen Liblong， IFSI

Ann McCurdy， Microsoft

Rich Petke， CompuServe

Eric Prud'hommeaux， W3C

Dave Raggett， W3C

Gordon Ross， NetNanny

Bob Schloss， IBM

David Singer， IBM

Ray Soular， SafeSurf

Michael Smith， Prodigy

Marcy Swenson， Providence Systems

Jason Thomas， MIT

PICSの使用が増加するにしたがい、我々は総合的なネットワークパフォーマンスへの影響を考慮しなければならない。概して、追加するPICSヘッダーは、通常、数100バイトのデータを含み、文書自身は、ほとんどが数千バイトのデータであるので、文書でラベルを転送するPICSテクニックは、ネットワークにほんの少しのトラフィックを増加させる。さらに、ラベルは文書と同じソースから受け取ることができるので、PICSによってネットワーク上のホットスポット (人気のあるサーバ自身は、既にホットスポットである)が作られることはない。

しかしながら、ラベルビューロは、PICSによって提案された新しいコンポーネントである。そして、もし、1つのラベルビューロに人気がでるようになれば、そこがホットスポットになり、PICSシステムのパフォーマンスボトルネックとなるという重大な危険性がある。インターネットはこの問題に対するよい解決策を必要としている。長期的に見ると問題を解決するかもしれない仕事が進行している。

しかしながら、短期的に見ると本当によい解決はない。次の提案は、MIT David Karger教授によるものである。これは、システムの負荷を分配するためのいくつかの有名なアルゴリズムを変形したものである。

最初に、人気のあるラベルビューロがネットワーク上に多くのミラーサイトを設立することができると仮定する。これは、既に一般的な認識であり、サイトを決定する方法や、新しいラベルが作成されたとき、それらを更新する方法の詳細について提案する必要はない。我々のアルゴリズムは単純で、ミラーサイトが存在し、等価なもので、そしてネットワークのドメインネイムシステム(DNS)が、通常の方法で、ラベルビューロの1つの名称から、複数のインターネットアドレスへ位置付けるレコードを持っていると仮定している。

クライアントソフトウェアがスタートする時、クライアントソフトウェアは、DNSを通して、使用する(我々は１つのラベルビューロを仮定しているが、アルゴリズムは既知の手法で複数のビューロに展開している)ラベルビューロの名前を解析するべきである。もし、複数のホストアドレスを受け取った場合、それを完全なリストとして保存し、“プライマリ”、”セカンダリ” とラベル付けしたビューロをランダムに2つ選択する。これらは、ソフトウェアがスタートしたとき有効とされるクライアントソフトウェアのコンフィギュレーションパラメータとなるかもしれない。そして、60分をラベルビューロとして受け取ったアドレス総数で割り、この値をタイマにセットし“敷居”値とする。

おそらく、遠からず、このアルゴリズムの簡単な変形が、実現されるだろう。HTTPプロトコルが、サーバに対して、“keep alive” 接続を許すよう変更される時、PICSクライアントは、可能な限りプライマリラベルビューロへの接続を保持するようになる。そのときには、(より注意深く測定しなければならないが)最初の応答をプライマリビューロのものと、単純に解釈する。問い合わせを送り、応答を受け取るまでの所要時間は、全体の処理時間よりも測定しなければならないものである。接続のセットアップコストは高価である。そして、もし、すでに接続されているプライマリビューロとの往復時間と、接続設立を含めたセカンダリビューロとの往復時間を比較してしまえば、測定はゆがめられたものになってしまう。

次に述べる問い合わせと応答は、クライアントと、文書とは別にラベルを配布するラベルビューロとの相互作用の特徴を説明したものである。3つの同じサービスによって供給され、3つのサービスが提供する3文書について、4種類の問い合わせを行う。問い合わせは、問い合わせモード(Generic、Normal、Tree、Generic+Tree)だけで異なっている。

次のURLのラベルを問い合わせる。

• http://www.w3.org/pub/WWW/
• http://www.w3.org/pub/WWW/TheProject.html
• http://www.w3.org/unknown

• http://www.ages.org/our-service/v1.0/
• http://www.rsac.org/v1.0
• http://unknown.com

• Agesレイティングサービス

1. "http://www.w3.org/pub" (generic)
2. "http://www.w3.org/pub/WWW/" (generic)
3. "http://www.w3.org/pub/WWW/Daemon" (generic)
4. "http://www.w3.org/pub/WWW/PICS" (generic)
5. "http://www.w3.org/pub/WWW/Overview.html"

• RSACレイティングサービス

1. "http://www.w3.org/pub/WWW" (generic)
2. "http://www.w3.org/pub/WWW/Daemon" (generic)
3. "http://www.w3.org/pub/WWW/PICS" (generic)
4. "http://www.w3.org/pub/WWW/Daemon/Overview.html"
5. "http://www.w3.org/pub/WWW/TheProject.html"

• unknown.comレイティングサービス

問い合わせは、印刷して判読することができるものを応答する。’;’ で始まる注釈は、応答の説明を加えたものである。問い合わせと応答は提示のため複数行に分割しているが、実際は(非常に長い)1行で送信される。

この問い合わせは、3つの文書に当てはまるfull genericラベルについてのものである。

"http://www.ages.org/our-service/v1.0/" ; 第一のサービス

ratings (age 11) ; 第二のラベルの末尾

; 第三の文書のラベルは存在しない

;; 第三のサービスにラベルは存在しない

この問い合わせは、各々の文書のfull specificラベルについてのものである。

;; specificラベルが存在しないため、genericラベルを返却する。

;; specificラベルが存在しないため、genericラベルを返却する。

;; specificラベルが存在しないため、genericラベルを返却する。

;; ここではspecificラベルを返却する。

この問い合わせは、要求されたプレフィクスURLを持っているすべてのURLのfull specificラベルを要求するものである。 このラベルビューロは、問い合わせされたツリーについて、カレントディレクトリの文書のラベルのみを返却する。

;; いくつかのラベルが()で区切られている

;; ディレクトリhttp://www.w3.org/pub/WWW/ のラベルの末尾

この問い合わせは、要求されたプレフィクスURLを持っているすべてのURLのすべてのgenericラベルを要求するものである。ここでは、(genericの場合についてのみ)直前のの問い合わせで返却されたラベルのサブセットが返却されている。