この文書は、W3Cメンバと他の利害関係者によってレビューされており、ディレクタによってW3C推薦として 指定されている。W3C推薦の文書は、別の文書で参考資料として使われるか、規範的参照として引用される ものである。推薦を作る際のW3Cの役割は、仕様へ注意を引き、広範囲にわたる展開を促進することである。 これは、Webの機能性と操作性を高めるものである。
http://www.w3.org/pub/WWW/TR/.で、現在のW3C推薦と、他の技術的な文書のリストを見つけることができ る。
この文書は、PICS(Platform for Internet Content Selection)技術分科会によって作成された。 これは PICSラベルとラベルを転送する3つの方法の一般的なフォーマットを定義したものである。
目次
この文書は、PICS(Platform for Internet Content Selection)の技術分科会によって作成された。 これは PICSラベルとラベルを転送する3つの方法の一般的なフォーマットを定義したものである。
ラベルはサービス識別子, ラベルオプション, およびレイティングで構成されている。サービス識別子と は、ユニークな識別子としてレイティングサービス(レイティングサービスとレイティングシステムを 参照)が選択しているURLである。ラベルオプションには、文書を評価した時間のようなレイティングされて いる文書の属性を記述する。レイティングは、1つ以上の次元に沿って文書を記述する一連の属性値対であ る。1つ以上のラベルがリストとしてに配布されてもよい。ラベルリストの一般的なフォームは以下のとお りである(エラーステータスコードは表示していない)。
(PICS-1.1
<service url> [option...]
labels [option...] ratings (<category> <value> ...)
[option...] ratings (<category> <value> ...)
...
<service url> [option...]
labels [option...] ratings (<category> <value> ...)
[option...] ratings (<category> <value> ...)
...
...)
A 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のグループは、ラベル自身についての情報を供給する。最後のグループ は、その他の情報を供給する。
PICSレイティングサービスとレイティングシステムで記述するレイティングシステムの例として、２つ の文書のラベルリストが、次のとおりであったとする。(すべての例で、スペーシングとインデンテーショ ンが読みやすいように入れられている。複数のスペースは１つのスペースとして扱う。)
(PICS-1.1 "http://www.gcf.org/v2.5"
by "John Doe"
labels on "1994.11.05T08:15-0500"
until "1995.12.31T23:59-0000"
for "http://w3.org/PICS/Overview.html"
ratings (suds 0.5 density 0 color/hue 1)
for "http://w3.org/PICS/Underview.html"
by "Jane Doe"
ratings (subject 2 density 1 color/hue 1))
同じラベルリストは、よりコンパクトにすべての改行とインデント文字を１つのスペースに変換し、単語 “labels”を“l”に、“ratings”を“r”というように長いオプション名称を省略形で置き換えて転送し てもよい。それは、転送のため、さらに、すべてのオプション情報を別の文書に取り去り、URLによってそ の文書を参照するように圧縮してもよい。
(PICS-1.1 "http://www.gcf.org/v2.5" l
full "http://www.gcf.org/labels/13242123"
r (suds 0.5 density 0 color/hue 1)
full "http://www.gcf.org/labels/123412278"
r (subject 2 density 1 color/hue 1))
最後に、ラベルの情報内容を減らして転送量をより小さくするため、オプション情報はすべて省略してもよ い。そのとき、結果として作成されるラベルリストは、以下のようになる。
(PICS-1.1 "http://www.gcf.org/v2.5"
l r (suds 0.5 density 0 color/hue 1)
r (subject 2 density 1 color/hue 1))
以下にmodified BNFを使用したラベルの文法を記述する。どのラベルが特定のプロトコル内に埋め込まれるかという方法を以下に示す。
ノート:
labellist :: '(' version service-info+ ')'
version :: 'PICS-1.1'
service-info :: 'error' '(no-ratings' explanation* ')'
| serviceID service-error | serviceID option* labelword label*
serviceID :: quotedURL
labelword :: 'labels' | 'l'
label :: label-error | single-label | '(' single-label* ')'
single-label :: option* ratingword '(' rating+ ')'
ratingword :: 'ratings' | 'r'
quotedURL :: '"' URL '"' as described and extended in
レイティングシステムとレイティングサービス.
option :: labeloption | documentoption | otheroption
labeloption ::
'by' quotedname
| 'generic' boolean | 'gen' boolean
| 'for' quotedURL
| 'on' quoted-ISO-date
| 'signature-RSA-MD5' "base64-string"
| 'until' quoted-ISO-date | 'exp' quoted-ISO-date
documentoption ::
'at' quoted-ISO-date
| 'MIC-md5' "base64-string" | 'md5' "base64-string"
otheroption ::
'comment' quotedname
| 'complete-label' quotedURL | 'full' quotedURL
| 'extension' '(' mand/opt quotedURL data* ')'
mand/opt :: 'optional' | 'mandatory'
data :: quoted-ISO-date | quotedURL
| number | quotedname | '(' data* ')'
quoted-ISO-date :: '"'YYYY'.'MM'.'DD'T'hh':'mmStz'"'
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はここで記述されたシンタ
ックスを正確に必要とする。──時間も時間帯も省略されてはならない、互換フォーマットは許されてな
く、ここで指定したように句読点がなければならない。
rating :: transmit-name number | transmit-name '(' multi-value* ')'
multi-value :: number | number ':' number
transmit-name :: transmit-name-char+ ['/' transmit-name]
number :: [sign]unsignedint['.' [unsignedint]]
sign :: '+' | '-'
unsignedint :: [0-9]+
quotedname :: '"' urlchar-or-space+ '"'
alphanumpm :: 'A' | ... | 'Z' | 'a' | ... | 'z' | '0' | ... | '9' | sign
transmit-name-char :: alphanumpm | '.' | '$' | ',' | ';' | ':'
| '&' | '=' | '?' | '!' | '*' | '~' | '@'
| '#' | '_' | '%' hex hex
注意: シングルあるいは2重引用符、あるいは括弧を挿入するために”%”エスケープ(%のあとに、ASCII文
字セットで文字を表わす２つのHex数字を付加する)を使用する。
urlchar :: transmit-name-char | '(' | ')'
hex :: '0' | ... | '9' | 'A' | ... | 'F' | 'a' | ... | 'f'
urlchar-or-space :: urlchar | ' '
base64-string :: as defined in RFC-1521.
service-error :: 'error' '(' 'request-denied' explanation* ')'
| 'error' 'service-unavailable'
label-error :: 'error' '(' 'request-denied' [quotedURL explanation*] ')'
| 'error' '(' 'not-labeled' quotedURL* ')'
explanation :: quotedname
labellistがPICSラベルの集まりを転送するために使用される。 ここで記述するフォーマットは、MIME タイプ ”application/pics-labels” としてIANAで登録されるものである。 これは、ラベルとラベルが存 在しない場合その理由を転送するときに使用する。また、ラベルを文書と一緒の転送、またはPICSラベルビ ューロから転送しなければならない時に使用するフォーマットである。labellistは、常に括弧によって 囲まれ、PICSバージョン番号(この仕様での1.1)で始まる。
ラベルリストは、ラベルが存在しない(例えば、“error(no-rating ...)”)、または、セクションに分けら れたラベル(セクションはそれぞれレイティングサービスに該当する)のいずれかである。 それぞれのサー ビスのURLは、(serviceIDで)指定されなければならない。そして、なぜそのサービスにラベルが存在しない か(service-error)を示すエラーメッセージ、あるいは、すべてのオプション情報(option*)、キーワード “label”(または “l”)、そしてサービスから渡されたlabelsのどちらかが続く。サービスから渡された オプション情報は、もしspecificラベルで無効にしなければ、すべてのラベルに適用される。
labelには３つの種類がある。最初は、個々のURLでラベルを参照した時のエラーである(label-error)。第 二は、もっとも一般的なものであるが、単語 ”ratings”(または “r”)とレイティング結果自身(カテゴ リ名と値のリスト)で構成されるオプション(サービスで記述したものを無効にする)を含むsingle-label。 最後に、文書全体のツリーの評価が要求された場合の特別な例であるが、括弧で囲まれたいくつかの single-labelを転送することができる。このケースは、“ラベル要求”のセクションでより詳細に記述さ れている。
ラベルは特定のURLに対応するものか、あるいはgenericである。genericラベルは、プレフィクスで指定さ
れたすべてのURLの暗黙の評価を行う。例えばURLw3.orgのgenericラベルは、そのサイトのすべ
ての文書に暗黙の評価を与える。同じURLw3.orgのspecific(genericでない)ラベルは暗黙の評
価を与えない。それは単に、ホストw3.org.へHTTPで、”GET /”を送信して持ってくるホームページを評価
したものである。genericラベルは、どのURLにラベルを適用するかを指定する ”for” オプションを含ん
でいなければならない。上で言及したように、もし、ラベルのforオプションで指定された文字列から始ま
るURLのすべての文書に評価を正当に適用することができるならば、genericラベルが使用されるべきであ
る。
multi-valueで値が渡される場合、数と数の範囲(”:”で範囲の終わりを記述する)のどんな組み合わせでも 指定されてよい。
(PICS-1.1 "http://www.gcf.org/v2.5" l r (suds 0.5 density 0 color/hue 1 subject (0.5:1.5 2)))
すべての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”を定義する。文法は次の通りで ある。
PICS-Label: <labellist>
labellistの部分の文法は上に記述している。 RFC-822で提示された仕様にしたがって、行頭は連続した空 白で始まってよい。
HTML記述で定義されているMETA要素を使用し、 ラベルをmeta情報としてHTMLファイルに埋め込んでもよ い。 埋め込みには、HTTPヘッダー機構を使用する。
<META http-equiv="PICS-Label" content='labellist'>
content属性の記述にシングルクォートを使うことに注意しなければならない。なお、PICSラベルの文法で は、ダブルクォートを使用している。contentに記述する以下の文字は、SGMLで指定した方法でエスケープ しなければならない。
' ' /* single quote */
& & /* ampersand */
> > /* 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ヘッダーで帰されたラベルを、文書に埋め込まれた ラベルと仮定することができる。
クライアントからPICS機能を持つHTTPサーバwww.greatdocs.comに送信：
GET /foo.html HTTP/1.0
Protocol-Request: {PICS-1.1 {params full
{services "http://www.gcf.org/v2.5"}}}
サーバからクライアントへの応答：
HTTP/1.0 200 OK
Date: Thu, 30 Jun 1995 17:51:47 GMT
Last-modified: Thursday, 29-Jun-95 17:51:47 GMT
Protocol: {PICS-1.1 {headers PICS-Label}}
PICS-Label:
(PICS-1.1 "http://www.gcf.org/v2.5" labels
on "1994.11.05T08:15-0500"
exp "1995.12.31T23:59-0000"
for "http://www.greatdocs.com/foo.html"
by "George Sanderson, Jr."
ratings (suds 0.5 density 0 color/hue 1))
Content-type: text/html
...contents of foo.html...
クライアントは文書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のヘッダーラインに追加した文法を 記述する。
request-header ::
'Protocol-Request: {PICS-1.1 {params ' [completeness]
extension*
services '}}'
completeness :: 'minimal' | 'short' | 'full' | 'signed'
extension :: '{' token-or-quoted-string+ '}'
where the first token-or-quoted-string is not 'services'.
token-or-quoted-string :: token | quotedname
token :: alphanumpm+
services :: '{' 'services' quotedURL+ '}'
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つの追加ヘッダーを記述する。
protocol-header :: 'Protocol: {PICS-1.1 {headers PICS-Label}}'
label-header :: 'PICS-Label: ' labellist
参照する文書とは切り離し、PICSラベルのみを参照することができる。この方法でラベルを要求するために は、クライアントはラベルビューロにアクセスする。ラベルビューロは、以下に記述する特殊な参照文を 認識するHTTPサーバである。ラベルビューロは、HTTP以外のプロトコルを通して文書にアクセスし、他のサ ーバに存在する文書のラベルを供給する。 多くのレイティングサービスについて作り出されたラベルを、 “有名な”ラベルビューロが(おそらく有料で)分配すると予測される。
レイティングサービスは、自身のラベルへのオンラインアクセスを提供することで、ラベルビューロとして 動作するよう推奨されている。既定値では、レイティングサービスの識別子であるURLは、ラベルビューロ の識別子である。クライアントがレイティングサービスのURLを要求すれば、 レイティングサービスとレ イティングシステムで記述するように、人間が判読可能なサービスの説明が返却される。一方、クライア ントが同じURLで、以下に定義する問い合わせパラメータを含んだ要求を実施すれば、それはラベルを要求 したものと認識される。しかしながら、レイティングサービスは、ラベルビューロとして動作することを要 求されていない。そして、ラベルビューロとしての動作は、異なったURL(たぶん異なったHTTPサーバで)で 実現するかもしれない。
(さらに複雑な問い合わせと応答は、 付録Bを参照)
ここでは、http://www.labels.org/RatingsのURLで識別される、レイティングサービスを仮定している。こ のレイティングサービスは、(少なくとも)自身の文書のラベルを配布するために、ラベルビューロを動作さ せている。次の問い合わせのサンプルは、HTTPサーバwww.labels.orgへの要求の実例である(改行が提示目 的のため挿入されている)。
GET /Ratings?opt=generic&
u="http%3A%2F%2Fwww.questionable.org%2Fimages"&
s="http%3A%2F%2Fwww.gcf.org%2Fv2.5"
HTTP/1.0
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を参照)で批判されている。
request :: get | post
get :: 'get' url-fragment '?' [opt] [format]
extension* url+ service+
post :: 'post' url-fragment crlf crlf formencodeddata
url-fragment :: HTTP1.0で指定された、ホスト名のあとのオリジナルURLの部分
crlf :: carriage return (hex D) followed by line feed (hex A)
opt :: 'opt=' option
option :: 'generic' | 'normal' | 'tree' | 'generic+tree'
format :: [and] 'format=' form
form :: 'minimal' | 'short' | 'full' | 'signed'
extension :: tokenは、opt、format、u、またはsのいずれかではない。また、token-or-quoted-stringは、RFC-1738で
記述した規則でクォートされたものである。
token-or-quoted-string :: token | quotedname
token :: alphanumpm+
url :: [and] 'u=' encodedURL
service :: [and] 's=' encodedURL
boolean :: 't' | 'f' | 'true' | 'false'
and :: '&' 問い合わせが ’?’の直後につづくものでなければ、これがなければならない。
encodedURL :: クォートされたURL。RFC-1738にあるように、URL中の引用符といくつかの特殊文字
は、”%xx” という表記法を用いてエンコードされる。アルファベット文字、数字、および特殊文字
$_-.+!*'() はクォートする必要はないが、他の文字はクォートしなければならない。コロン(:)を%3Aに、
スラッシュを%2Fにエンコードしなければならないのは、このためである。
formencodeddata :: getで記述した問い合わせ、ただし、HTML 2.0.のセクション8.2.1、8.2.3で記述してあ
るように、MIMEタイプapplication/x-www-form-encodedにエンコードされている。
この仕様では、 PICSシステムで発生すると思われる問題を防止するため、2つの独立したセキュリティ機能 を記述している。2つの機能は単独で使用してもよいし、一緒に使用してもよい。2つの機能は特許を取得し た暗号化技術に頼っており、その使用がいろいろな法律の制限(米国からの輸出制限を含む)受けやすいもの である。PICS技術分科会は、コード、あるいはアルゴリズムの正確な法律的な問題について、情報を提供す ることができない。
米国のRSA研究所(100 Marine Parkway、 Redwood City、 CA、 94065-1031)は、PICS仕様中の暗号化コンポ ーネントを実装するとき必要となるすべてのコードを提供する、RSAREFと呼ばれるソースコードキットを配 布している。RSAデータセキュリティ社 社長のJim Bidzos氏は、我々に“RSAREFをPICS仕様の実装に使用す る場合は、費用なしで利用できるだろう”と語った。法律問題などについての質問は、Bidzos氏にするこ と。
最初の問題は、文書が検査されラベルが作成されたのち、文書がラベルを更新せずに修正された場合に発生 する。これは正当な(例えば、タイムワーナーは、タイム誌の最新号のページに更新し、ラベルはまだ有効 と考えている)ことかもしれないし、権限を与えられていない者によって文書が勝手にいじられた結果かも しれない。PICSラベルは、この種の問題の防止のため、3つのオプションフィールドを持っている。
第2の問題は、ラベルを勝手に変更することと、捏造することである。ここに記述する問題は、エンドユー ザに対して、受け取ったラベルが要求したレイティングサービスで作成され、その後、変更されなかったこ とを何らかの方法で保証することである。PICSは、ラベルに “ディジタル署名をする” ことを要求してい る。ディジタル署名は、現在のところ法律的に認知されていないが、厳密に保証することのできる暗号化テ クニックである。RSA署名テクニックは、次のように動く。
keyの配布に関する問題(そして、もし、サービスのkeyが危険になった場合無効にする)は、商業的競争の領 域である。今日、確立された利用可能な解決策は存在しないため、PICSはそれぞれのサービスが何らかの方 法でpubic keyを配布すると仮定している。また、キーは無効にされる必要はないと仮定している。これ は、明らかに完全な解決ではないが、特定の独占されている技術に依存することなく、今日実現できる限界 であると考えている。
以上に概説したディジタル署名で、１つ、追加される問題がある。もし、レイティングサービスが、他者に その名前で、ラベルを作成することを許すならば(例えば、サービスがコンテンツ製作者による、セルフレ イティングをサポートする)、ラベルはサービスとコンテンツ製作者の両者が署名する必要があるであろ う。これ(おのおのが他者の署名なしにラベルに署名すること)は実現できるが、署名を確認するために必要 なpublic keyを配布することが難しくなる。PICS仕様は、この問題の解決案も提案していない。(これも、 商業的競争の領域である。)
次の方々からのコメントと提案に深く感謝する。
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のラベルを問い合わせる。
次のサービスの問い合わせを行う。
サーバは、次の関連したラベルを持っている。
問い合わせは、印刷して判読することができるものを応答する。’;’ で始まる注釈は、応答の説明を加え たものである。問い合わせと応答は提示のため複数行に分割しているが、実際は(非常に長い)1行で送信さ れる。
この問い合わせは、3つの文書に当てはまるfull genericラベルについてのものである。
クライアントからサーバへの問い合わせ：
GET /ratings?opt=generic&format=full& u="http%3A%2F%2Fwww.w3.org%2Fpub%2FWWW%2F+&" u="http%3A%2F%2Fwww.w3.org%2Fpub%2FWWW%2FTheProject.html&" u="http%3A%2F%2Fwww.w3.org%2Funknown&" s="http%3A%2F%2Fwww.ages.org%2Four-service%2Fv1.0%2F&" s="http%3A%2F%2Fwww.rsac.org%2Fv1.0&" s="http%3A%2F%2Funknown.com" HTTP/1.0
サーバからクライアントへの応答:
HTTP/1.0 200 OK
Content-Length: 550
Content-Type: application/pics-labels
Server: Jigsaw 0/0
Date: 15 Apr 1996 18:20:47 GMT
(PICS-1.1
"http://www.ages.org/our-service/v1.0/" ;第一のサービス
labels
for "http://www.w3.org/pub/WWW/"
generic true
by "abaird@w3.org"
ratings (age 11) ;第一のラベルの末尾。'ratings' は常にラベルの最終部である。
;同じgenericラベルがhttp://www.w3.org/pub/WWW/TheProject.html
;で始まるすべてのURLに適用される。
for "http://www.w3.org/pub/WWW/"
generic true
by "abaird@w3.org"
ratings (age 11) ;第二のラベルの末尾
error (not-labeled "http://www.w3.org/unknown")
;第三の文書のラベルは存在しない
;要求された3つのサービスについて、第一のサービスは終了した
"http://www.rsac.org/v1.0"
labels
for "http://www.w3.org/pub/WWW"
generic true
by "abaird@w3.org"
ratings (v 0 s 0 n 0 l 0)
for "http://www.w3.org/pub/WWW"
generic true
by "abaird@w3.org"
ratings (v 0 s 0 n 0 l 0)
error (not-labeled "http://www.w3.org/unknown")
;;第三のサービスにラベルは存在しない
error (no-ratings "unknown service"))
この問い合わせは、各々の文書のfull specificラベルについてのものである。
クライアントからサーバへの問い合わせ：
GET /ratings?opt=normal&format=full& u="http%3A%2F%2Fwww.w3.org%2Fpub%2FWWW%2F+&" u="http%3A%2F%2Fwww.w3.org%2Fpub%2FWWW%2FTheProject.html&" u="http%3A%2F%2Fwww.w3.org%2Funknown&" s="http%3A%2F%2Fwww.ages.org%2Four-service%2Fv1.0%2F&" s="http%3A%2F%2Fwww.rsac.org%2Fv1.0&" s="http%3A%2F%2Funknown.com" HTTP/1.0
サーバからクライアントへの応答：
HTTP/1.0 200 OK Content-Length: 569 Content-Type: application/pics-labels Server: Jigsaw 0/0 Date: 15 Apr 1996 18:20:54 GMT (PICS-1.1 "http://www.ages.org/our-service/v1.0/" labels ;;specificラベルが存在しないため、genericラベルを返却する。 for "http://www.w3.org/pub/WWW/" generic true by "abaird@w3.org" ratings (age 11) ;;specificラベルが存在しないため、genericラベルを返却する。 for "http://www.w3.org/pub/WWW/" generic true by "abaird@w3.org" ratings (age 11) error (not-labeled "http://www.w3.org/unknown") "http://www.rsac.org/v1.0" labels ;;specificラベルが存在しないため、genericラベルを返却する。 for "http://www.w3.org/pub/WWW" generic true by "abaird@w3.org" ratings (v 0 s 0 n 0 l 0) ;;ここではspecificラベルを返却する。 for "http://www.w3.org/pub/WWW/TheProject.html" generic false by "abaird@w3.org" ratings (v 0 s 0 n 0 l 0) error (not-labeled "http://www.w3.org/unknown") error (no-ratings "unknown service"))
この問い合わせは、要求されたプレフィクスURLを持っているすべてのURLのfull specificラベルを要求す るものである。 このラベルビューロは、問い合わせされたツリーについて、カレントディレクトリの文書 のラベルのみを返却する。
クライアントからサーバへの問い合わせ：
GET /ratings?opt=tree&format=full& u="http%3A%2F%2Fwww.w3.org%2Fpub%2FWWW%2F+&" u="http%3A%2F%2Fwww.w3.org%2Fpub%2FWWW%2FTheProject.html&" u="http%3A%2F%2Fwww.w3.org%2Funknown&" s="http%3A%2F%2Fwww.ages.org%2Four-service%2Fv1.0%2F&" s="http%3A%2F%2Fwww.rsac.org%2Fv1.0&" s="http%3A%2F%2Funknown.com" HTTP/1.0
サーバからクライアントへの応答:
HTTP/1.0 200 OK Content-Length: 1075 Content-Type: application/pics-labels Server: Jigsaw 0/0 Date: 15 Apr 1996 18:21:00 GMT (PICS-1.1 "http://www.ages.org/our-service/v1.0/" labels ;;いくつかのラベルが()で区切られている () (for "http://www.w3.org/pub/WWW/" generic true by "abaird@w3.org" ratings (age 11) for "http://www.w3.org/pub/WWW/Overview.html" by "abaird@w3.org" generic false ratings (age 12) by "abaird@w3.org" for "http://www.w3.org/pub/WWW/PICS" generic true ratings (age 5) by "abaird@w3.org" for "http://www.w3.org/pub/WWW/Daemon" generic true ratings (age 5)) ;;ディレクトリhttp://www.w3.org/pub/WWW/ のラベルの末尾 ;;http://www.w3.org/pub/WWW/TheProject.htmlをプレフィクスとするラベ ;;ルは存在しない error (not-labeled "http://www.w3.org/pub/WWW/TheProject.html") error (not-labeled "http://www.w3.org/unknown") "http://www.rsac.org/v1.0" labels (for "http://www.w3.org/pub/WWW" generic true by "abaird@w3.org" ratings (v 0 s 0 n 0 l 0) for "http://www.w3.org/pub/WWW/TheProject.html" generic false by "abaird@w3.org" ratings (v 0 s 0 n 0 l 0) for "http://www.w3.org/pub/WWW/Daemon" generic true by "abaird@w3.org" ratings (v 0 s 0 n 0 l 0) for "http://www.w3.org/pub/WWW/PICS" generic true by "abaird@w3.org" ratings (v 0 s 0 n 0 l 0)) error (not-labeled "http://www.w3.org/pub/WWW/TheProject.html") error (not-labeled "http://www.w3.org/unknown") error (no-ratings "unknown service"))
この問い合わせは、要求されたプレフィクスURLを持っているすべてのURLのすべてのgenericラベルを要求 するものである。ここでは、(genericの場合についてのみ)直前のの問い合わせで返却されたラベルのサブ セットが返却されている。
クライアントからサーバへの問い合わせ：
GET /ratings?opt=generic%2Btree& format=full& u="http%3A%2F%2Fwww.w3.org%2Fpub%2FWWW%2F+&" u="http%3A%2F%2Fwww.w3.org%2Fpub%2FWWW%2FTheProject.html&" u="http%3A%2F%2Fwww.w3.org%2Funknown&" s="http%3A%2F%2Fwww.ages.org%2Four-service%2Fv1.0%2F&" s="http%3A%2F%2Fwww.rsac.org%2Fv1.0&" s="http%3A%2F%2Funknown.com" HTTP/1.0
サーバからクライアントへの応答：
HTTP/1.0 200 OK Content-Length: 872 Content-Type: application/pics-labels Server: Jigsaw 0/0 Date: 15 Apr 1996 18:38:28 GMT (PICS-1.1 "http://www.ages.org/our-service/v1.0/" labels (for "http://www.w3.org/pub/WWW/" generic true by "abaird@w3.org" ratings (age 11) by "abaird@w3.org" for "http://www.w3.org/pub/WWW/PICS" generic true ratings (age 5) by "abaird@w3.org" for "http://www.w3.org/pub/WWW/Daemon" generic true ratings (age 5)) error (not-labeled "http://www.w3.org/pub/WWW/TheProject.html") error (not-labeled "http://www.w3.org/unknown") "http://www.rsac.org/v1.0" labels (for "http://www.w3.org/pub/WWW" generic true by "abaird@w3.org" ratings (v 0 s 0 n 0 l 0) for "http://www.w3.org/pub/WWW/Daemon" generic true by "abaird@w3.org" ratings (v 0 s 0 n 0 l 0) for "http://www.w3.org/pub/WWW/PICS" generic true by "abaird@w3.org" ratings (v 0 s 0 n 0 l 0)) error (not-labeled "http://www.w3.org/pub/WWW/TheProject.html") error (not-labeled "http://www.w3.org/unknown") error (no-ratings "unknown service"))Copyright (C) 1996 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
Webmaster
$Date: 2000/09/08 16:13:45 $