Platform for Privacy Preferences(P3P) Syntax Specification
W3C Working Draft 7 April 1999
の和訳です。
なお、このドキュメントには和訳上の誤りがありえます。
内容の保証はいたしかねますので、必ずW3C Webサイトの正式版ドキュメントを参照して下さい。
正式版のURL:
http://www.w3.org/TR/1999/WD-P3P-19990407/syntax.html
Copyright (C) 1999 W3C (MIT, INRIA, Keio), All Rights Reserved. W3C 責任、登録商標、, 文書の使用、 そして ソフトウエアライセンスに関する規則が適用される。
Copyright © 1999 W3C
(MIT,
INRIA,
Keio), All Rights Reserved. W3C
liability,
trademark,
document
use and
software
licensing rules apply.
このドキュメントは P3P specification の中でも、核心部分に関するもっとも長いドキュメントです。 ドキュメント内において、必要条件、了解事項、そしてP3Pプロトコル、伝達方法、データ構造のシンッタックスと エンコーディングにつての明確化を行っています。
このドキュメントはW3Cメンバと関連者向けのP3P specificationの補足仕様書である。このドキュメントはP3P活動の一環で作られ、将来的にはW3C勧告となりうるものである。この文書は、P3P活動の一部として作成 されて来たものであり、最終的にはW3C勧告案に昇格する。W3Cのワーキングドラフトを参考資料として使ったり、"進行中の作業"としてではない引用を行うことは好ましくない。このドラフトの基本コンセプトは かなりしっかりとしており、我々は仕様へのフィードバックのために実験的な実装やプロトタイプの開発を行うことを奨励する。しかしこのワーキンググループでは、今後のバージョンの文書を変更する可能性の ある早期の実装は認めないであろう。
このドラフトはW3C processに従い、W3Cとそのメンバーにより考えられている。この文書はP3Pの実装、承認、採用に影響を与えそうな問題に関して、W3Cの会員およびスタッフに送られるコメントを受け取る目的で公開されている。
コメントがある方は以下にお願いしたい。
www-p3p-public-comments@w3.org
(アーカイブは以下
http://lists.w3.org/Archives/Public/www-p3p-public-comments/).
___
Copyright © 1999 W3C (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
P3P(The Platform for Privacy Preferences)は、Webサイトが自分たちのプライバシープラクティスを表現し、 ユーザがそれらのプラクティスに対するプリファレンスを実行することを可能にする。 P3P準拠の製品は、ユーザが(マシンと人間の両方が解読できる書式で)サイトのプラクティスを知ること、 適切ならばコンピュータに決定を委ねること、そして特定サイトに結びつけることを許す。 ユーザのプリファレンスに適合したサイトのプラクティスは、ユーザの選択によりシームレスにアクセスすることができる。 そうでない場合は、ユーザはサイトのプラクティスを通知され、それらに同意する機会を与えられてブラウジングを続けることができる。
P3Pは、ユーザがWeb上で十分に説明された決定を行う能力と、彼らの情報の使用を制御する能力を与える。 サイトはP3Pを、サービス品質の向上・コンテンツのカスタマイズ・サイトアクセスの簡略化だけでなく、 サービス内での信頼ユーザの場所のレベルを上げるために使うことができる。
P3Pは、構造化データの交換と宣言のために [XML](とりわけ[RDF])を使う。 P3Pは将来のデジタル認証とデジタル署名の能力もサポートする予定。 P3Pはブラウザ、プラグイン、サーバ、もしくはクライアントとサーバ間のプロキシサーバに組み込むことができる。
The P3P specification は以下の機構を提供します。:
このドキュメント(各章、各規準参照)は、統一されたP3Pアプリケーションのインプリメントに必要な全ての仕様を含む。 この仕様書は過去のワーキンググループの実績の上に築かれ、以下にあげるものを含んでいる。
このドキュメントは、P3P仕様のメインとなる部分を含んでいます。 プライバシーデスクロージャー用語の語議論の詳細 <natural language>は、以下の章で見る事が出来ます。
基本データセットの文法とデータタイプの詳細は以下の章で見る事が出来ます。
注意: この用語の使用がP3P1.0の応諾を必要としている間、XMLの容易さ(namespaces [XML-name] )は追加 または補足的な用語を簡単に紹介できることを許可する。
文章のステータスを表現するために以下の規約を用いる。
ABNF表記法の中のスキーマ定義. |
この仕様書で使われたABNF表記法は、RFC2234 で規定されている。また、Appendix 2に要約されている。
利用者がWebサイトを訪れた時、サイトはプライバシープラクティスを宣言し、その上利用者からの個人情報を 要求する。
P3Pプロポーザルは複数のステートメントを含み、データエレメントセットに関するプライバシープラクティスを表記している。
また、P3Pプロポーザルは全ての適切なデータエレメントとプラクティスをカバーしなければならない。(サイトがデータエレメントを
収集したい場合、プロポーザルにおいて、その旨を宣言しておかなければならない)
注意:P3Pでのプロポーザル宣言は、肯定的でなければならない。(”何をしない”ではなく”何をする”と言うような表現)
P3P specification での中心的概念は P3P agreement(同意)です。P3P agreement とは、
サービスとユーザーエージェント双方で一致するプロポーザルのことである。
ユーザーエージェントは同意を始めるかどうかを決定するために、プロポーザルに宣言してあるプライバシープラクティスと利用者のプリファレンス
を比較する。同意は特定のレルム内において、ユーザーエージェントとサービス間での全てのデータ交換に適用する。
(レルム:唯一のURIまたはURIのリストから参照されるWebリソースのリストから参照されるWebリソースまたはTree構造のWebリソース)
一度同意に至ると、合意プロポーザル(agreed-to proposal)に含まれたデータエレメント郡は、ユーザーエージェントにより、サービスからリクエストされたデータとして説明されるべきである。同意において情報を収集しない場合、データエレメントの参照なしで同意に至る事は可能である。
レルムに複数のプロポーザルが存在することが可能である。またサービスも代替手段やオプショナルなプロポーザルを提供する能力を持っている。 プロポーザルは利用者の目に見える形で、なぜ利用者が普段許可しないようなプラクティスでさえも提案したプラクティスが特定の場合に重要であるかの説明を掲げることが出来る。ユーザーエージェントは同意に至った事を同意のfingerprintごとに記録に残すべきである。
サイトは毎回ユーザーエージェントに新規のプロポーザルを送る代わりに、既存の同意のpropIDを送る事が可能である。これは、1)サービスとユーザーエージェントが既にプロポーザルに同意していることが明白である。2)どのプロポーザルとプライバシープラクティスが使用されているかの表示。3) 同意に基づくデータエレメントの要求。同意に対する記録が無い、または新規に要求したい場合、ユーザーエージェントは拒否、要求されたデータへの応答、全てのプロポーザル要求が可能である。
プロポーザル(プロポーザルへのポインタ)はトランスポートメカニズム(HTTP)や内容・資源(HTMLページ)内において送られる。複数のプロポーザル代替手段は、目的の柔軟性のために存在することが可能である。サービスはHTTP内において、P3P-extension multiple times や、HTML内において multiple links を使用することが出来る。
エージェントは固有の伝達方法・コンテントモデルに関する情報を返却しなければならない。 我々はHTTP方式で情報の交換を成し遂げる方法を定義する。また、他の方法で情報を返却するための拡張メカニズムを特定する。
以下に、我々が独自に提供する拡張メカニズムに関する2つの注目すべきエリアを示す。
我々の設計は次のようなものである。独自の想定において効果的に実装できるアプリケーションやマルチラウンド通信の待ち時間、キャシュ可能なプロポーザル、ユーザーエージェントやサーバー側のデータレポジトリの使用、同意レポジトリのサイズに等に関する期待である。
P3Pは、動作する環境と解決すべき問題についていくつかの仮定を行っている。
このドキュメントはインターオペラビリティ(interoperability)、feature
sets、意味に関するポリシー(policy related semantics)についての要求事項について説明します。インターオペラビリティの必要事項は、プロトコルは
"shared"プロトコル ステート マシンに従って動作すること、情報は任意に喪失されない、もしくは混同されないこと等です。
このドキュメントで feature setsに関する必要事項をさらに説明する。 というのは、プロトコルを壊さないfeature
をインプリメントしない一方で、それは、どの機能がサポートされているかという相手又はユーザの期待を裏切ることになります。
その上、このアプリケーションの重要なpolicy implicationの為、P3PはXML/RDFのための natural language semantics
を含んでいます。例をあげると、インターオペラビリティの要求事項はすべてのパーティーにプロトコル原型とレスポンスをサポートすることです。
この要求事項を与えられ、エージェントはいつも“SORRY”を返す事が出来ます。
しかし、このことは、全てのエージェントが単にsorryを返すように実行されている場合、合意に至ることができるというサービスの期待を裏切ることになる。
この例を広げてみると、もしそのような事をするエージェントが存在しない場合、サービスは、マルチプルポリシーや交渉した決定事項を好んで実行しないだろう。
いずれにしても、機能のサポート不足によりプロトコル インターオペラビリティーを裏切らない。
この広域なそれらの必要事項は不規則なものではあるが、P3Pがプロトコル以上の物であり、HTTPやXMLのような既存の標準アプリケーションであるので必要である。さらに、この文書では、まだ実装されていないまたは、仕様書の一部として作る必要のない機能、しかしP3Pユーザの経験の一部として重要と思われる機能についても予想して書かれている。
以下のキーワードは文書全体を通じて使用され、interoperability要求事項として読まれなければならない。
このキーワードはRFC2119
[KEY] で定義されている。以下にそのキーワードを示す。
以下のテーブルは、要求に関しての機能/動作をまとめたものです。クライアントとサービス、クライアントまたはサービスに対する要求かどうかは、このspecificationの左側に記載されています。
セクション | 機能/動作 | Key Word | 説明 |
Terminology |
propID | MUST | propID は、どのようなプライバシープロポーザルも認識する。 |
the HTML LINK tag | MUST | エージェント及びサービスはこの場所にプロポーザルを設置することが出来る必要がある。 | |
HTTP拡張メカニズム | MUST | エージェント及びサービスはこの場所にプロポーザルを設置することが出来る必要がある。 | |
postURI/CGI | MUST | データはHTTP post経由でいくつかのURIに送り返すことが可能でなければならない。 | |
XML 解析 | MUST | プロポーザルとデータシンタックスは、速やかに処理されるか、ユーザに提出される。 RDFデータモデルは、必要なgrammar/シンタックスを構成するために使用されるが、 アプリケーションは、その必要を感じない場合は必ずしもRDFをサポートする必要はない。 | |
完全なXMLとXML-namespaceのサポート | MUST | 実装時、使用されるだけでなく、完全に XML と namespacesをサポートしなければならない。 | |
Data References | base data reference syntax | MUST | エージェントは請求されている情報のシンタックスを理解できなければならない。 |
Abstract Elements | abstract elements | MUST | P3P以外の方法で交換されたreference dataの方法 |
Harmonized Vocab | harmonized vocabulary | MUST | 必要条件に関しては、harmonized vocubarlyを参照。この必要条件を満たさなければならない。満たさない場合、インプリメンテーションがprivcy公開を適切なレベルで出来なくなってしまう。 |
Reason Codes | (OK, SRY-, ERR-, SRY, ERR) | MUST | 同意に達する必要がある。もし理由コードが提供されない場合は、暗示のセマンティクスがある。結果として、このセマンティクスは必要となり、codeの存在は、任意となる。 |
Operational Description | propID repository | SHOULD | 完全なプロポーザルはコンパクトに表示されることが出来る。同意がすでにある場合、新規の交渉、同意は不必要である。 |
service can write to the data repository | SHOULD | 利用者の承諾があれば、サービスは利用者レポジトリに情報を書き込むことが出来る。 | |
data repository | MAY | 頻繁に要求される利用者プロフィール情報は利用者によって保存/管理される。 | |
Data Definitions | new schema instantiation | MAY | base setとは異なったスキーマは、エージェントにより例示/サポートされることが可能である。 |
Source Attribute | source attribute | MAY | エージェントは複数の拡張可能な機能をサポートし、それにより情報は送信を請求される。 |
簡易P3PユーザーエージェントはP3Pプロポーザルを受け取って、利用者にそれらを提示するぐらいの機能を有し、 情報要求があった場合、ユーザーエージェントは利用者に決定権を委ねる。そのため、ユーザーエージェントは利用者、自動的な利用者情報の転送(クリックストリームのような受動的に生成されたものは除く)のための決定権を持っていない。
利用者、自動的な利用者情報の転送のための決定権を持っているユーザーエージェントは、"trust engine."を含まなければならない。 trust engineはP3Pプロポーザルと利用者のプリファレンスセット(規則として記録されている)を入力やどのようなアクション (シームレスな受託、拒否、情報プロンプト、警告プロンプト、その他のアクション)をとるかと言うことで取得することが可能でなければならない。 利用者のプリファレンスは[APPEL]や他の言語で暗号化されることが可能である。プリファレンス言語はドキュメント化されるべきであり、 その言語によって規則を作成するユーザーインターフェイスを提供すべきである。ユーザーエージェントは利用者自身が作成した もしくは他人から手に入れた規則をインポートする方法を提供すべきである。また、利用者が規則の作成/変更可能な機能も提供すべきである。
ユーザーエージェントは初期の段階では、何も設定されていない状態(利用者が利用する前に設定ができるように)もしくはデフォルトの規則の設定 がなされている状態である。しかし、利用者の有効な同意なしに個人情報をサービスプロバイダに転送するようなデフォルトの設定をしてはならない。(シームレスな受託)
以下のシナリオは、P3Pが使われる可能性のあるいくつかの場面について説明してあります。 各シナリオは、それぞれ異なるP3Pの特徴を強調しています。シナリオ1はどのようにして基本的なP3P同意が確立されるかを示しています。 シナリオ2、3は既に同意に達しているサイトにユーザが戻った際に何が起きるかを示しています。シナリオ4、 5は同意を与えられたデータレポジトリの使用について強調しています。
これらのシナリオは交渉が発生しない場合の相互作用を図解している。 しかしどのシナリオもサイトが初めから複数のプロポーザルを行うシナリオに拡張されたり、サイトとユーザ間で一連のプロポーザルやカウンタープロポーザルが交わされるシナリオに拡張される可能性がある。 Appendix 1 のシナリオ拡張例は、交渉の一例を含んでいる。
以下の表は、各シナリオの特徴をまとめたもの。表中の"-"は、そのシナリオでは仮定されない(中立な)という意味を表す。
Scenario | Existing Agreement | New Proposal | Data Requested | Data Written |
1 | No | Yes | - | - |
2 | Yes | No | - | - |
3 | Yes | Yes | - | - |
4 | - | - | Yes | No |
5 | - | - | Yes | Yes |
プロトコルモデルは単一の相互作用を基本としている。我々は、コンパクトなデータ(普通は単一行)はHTTPヘッダ内に 置くべきであるという経験から得た法則従って以来、しばしば要求に対するレスポンスはクライアントが実際のプロポーザルを 取ってくるべき場所になる。(HTMLクライアントがページ内の画像を取ってくるのに数回リクエストをするようなもの)この 単一相互作用(複数回のHTTPリクエストを含む)は、必要であれば複数回の相互作用(または"交渉")に拡張する事が出来る。 どう言うことかと言うと、複数回の相互作用は単一の相互作用の上に作る事が可能で、単一の相互作用には何の影響も与えないからです。 注意:proposed protocolの相互作用は、P3Pを認識しているまたは、認識していない中間キャシュに正しく作用するために、厳密にHTTPの request/responce の表記法に従う。
基本的なプロトコルの動作は以下のようにまとめることが出来る。
クライアントは要求を発行する時に、以下の動作をいつでもすぐに行うことが出来る。
サーバーは以下のアクションを行うことが出来る。
HTTP Extension Framework[HTTP-EXT]を使用するためには、 拡張(拡張宣言)を識別するためのグローバルなユニークURIを規定することが要求される。 P3Pの拡張宣言は以下のURIを参照して下さい。
http://www.w3.org/TR/WD-P3P/
P3P extensions は以下のようなものである。
クライアントはP3Pについての知識があると言うことを明言した要求を発行することにより、 サーバーへのプロポーザル要求を行う。この要求はP3P extension declaration(http://www.w3.org/TR/WD-P3P/)を 使用し、HTTP Extension Framework(HTTPの拡張構成)経由で実行される。Optional extensionもしくはMandatory extensionの使用は実装次第である。
例:クライアントはOPTIONSを使用し、サーバーがP3P準拠であるかどうか確認できる。
OPTIONS some.resource HTTP/1.1 Host: some.host Opt: "http://www.w3.org/TR/WD-P3P/"
または標準の GET 要求
GET some.resource HTTP/1.1 Host: some.host Opt: "http://www.w3.org/TR/WD-P3P/"
もちろんMandatory extensionがOptionalの代わりに使用された場合、M-OPTIONS、M-GET メソッドを使用しなければならない。([HTTP-EXT])
クライアントが既に特定のリソースに対しての同意を得ている、またはクライアントが提供されたプロポーザル に同意したい時、リクエスト内に含まれたデータのためにこのプロポーザルを使用することを、サーバーに要請することが出来る。 これは、Mandatory P3P extension declarationのM-POSTメソッドを使用することにより成し遂げられ、おのおの のプロポーザルのために以下のP3P extension を設ける。
サーバーがこのポリシーに従いたくない場合、サーバーはデータを無視し、エラーを返さなければならない。
例1:クライアントがpropID(94df1293a3e5)を用いて、提供されているプロポーザルに対して同意したい場合、クライアントは 以下のものを送る。
M-POST / HTTP/1.1
Host: www.CoolCatalog.com
Man: "http://www.w3.org/TR/WD-P3P/"; ns='15-'
15-status: OK
15-propID: "md5:94df1293a3e5"
15-data: <TXD xmlns="http://www.w3.org/TR/WD-P3P/syntax" xmlns:VOC="http://www.w3.org/TR/WD-P3P/vocab" xmlns:DATA="http://www.w3.org/TR/WD-P3P/basedata">
15-data: <DATA:REF name="User.Name.First" value="Sheila">
15-data: <DATA:REF name="User.Name.Second" value="Doherty">
15-data: </TXD>
...
[Content]
例2:クライアントがpropID(94df1293a3e5)で、提供されているプロポーザルに対して同意し、 propID(AAbbAAbbAAbb)でプロポーザルに同意したい場合、クライアントは以下のものを送る。
M-POST / HTTP/1.1
Host: www.CoolCatalog.com
Man: "http://www.w3.org/TR/WD-P3P/"; ns='15-'
Man: "http://www.w3.org/TR/WD-P3P/"; ns='22-'
15-status: OK
15-propID: "md5:94df1293a3e5"
15-data: <TXD xmlns="http://www.w3.org/TR/WD-P3P/syntax" xmlns:VOC="http://www.w3.org/TR/WD-P3P/vocab" xmlns:DATA="http://www.w3.org/TR/WD-P3P/basedata">
15-data: <DATA:REF name="User.Name.First" value="Sheila">
15-data: <DATA:REF name="User.Name.Second" value="Doherty">
15-data: </TXD>
22-status: OK
22-propID: "md5:AAbbAAbbAAbb"
22-data: <TXD xmlns="http://www.w3.org/TR/WD-P3P/syntax" xmlns:VOC="http://www.w3.org/TR/WD-P3P/vocab" xmlns:DATA="http://www.w3.org/TR/WD-P3P/basedata">
22-data: <DATA:REF name="User.Business.Postal.City" value="Cambridge">
22-data: </TXD>
...
[Content]
サーバーは何時でも複数のリソースに対し、どのポリシーが使われるか示すことが出来る。 複数のプロポーザルが提供された場合、そのプロポーザルは複合代替プロポーザルとして 考慮される。“代替”とはどういう意味かというと、提供されるかも知れない多くのプロポーザルの中から クライアントはひとつのプロポーザルを選択すべきであるという事です。プロポーザルの提供には 二つの方法がある。一つ目はHTTPレベルで、HTTP Extension frameworkを使用する方法で、二つ目はHTMLレベルで、 HTMLLINKタグを使用する方法です。 これらの二つの方法は排他的ではない:二つの方法が同時に使用された場合、解釈は複合代替プロポーザル群が行う。
Optional P3P extension declarationを使用することによって行われ、各々の提案されたプロポーザルのために以下の P3P extensionsを設ける。
規定のrealm(レルム)は現行のRequest-URIのみです。
例:
HTTP/1.1 200 OK
Opt: "http://www.w3.org/TR/WD-P3P/"; ns='14-'
14-propID: "md5:94df1293a3e5"
14-proposal: "http://www.privacy.org/P3PProposal"
...
[Content]
複合(この場合三つ)の代替プロポーザルがある場合:
HTTP/1.1 200 OK
Opt: "http://www.w3.org/TR/WD-P3P/"; ns='15-'
Opt: "http://www.w3.org/TR/WD-P3P/"; ns='18-'
Opt: "http://www.w3.org/TR/WD-P3P/"; ns='20-'
15-propID: "md5:94df1293a3e5"
15-proposal: "http://www.privacy.org/P3PProposal"
18-propID: "md5:23as53aw12w2"
18-proposal: "http://www.privacy.org/P3PProposal2"
20-propID: "md5:56ew89qwht14"
20-proposal: "http://www.privacy.org/P3PProposal3"
...
[Content]
これは、各々の提供された代替プロポーザルに対し、以下の方法でHTML LINKタグ を使用したことによって遂行される:
<LINK rel="p3p:md5:hash" href="URI">
ここでURIはP3Pプロポーザルを指し示す。"p3p:md5:hash" は この特殊なP3Pリンクを区別するための関連名で、md5を使用してプロポーザルのhash(ハッシュ)値を とるためのものです。例えば、http://www.privacy.org/P3PProposalでプロポーザルはハッシュ値94df1293a3e5 を持っている場合、<LINK rel="p3p:md5:94df1293a3e5"href="http://www.privacy.org/P3PProposal"> という風に記述します。
注意:HTMLのコンテント内部をすぐに検索しなければならないので、プロポーザルのフェッチに 時間がかかる可能性がある。しかし、そのようなプロポーザルはキャッシュされることができる。この方法は次のような サイトでのみ使用されるべきである。1)P3Pのデータメソッドを使用していないサイト 2)少量、簡潔、重複なしのプロポーザル を持っているサイト
クライアントがM-POSTメソッドを使用してプロポーザル要求を行った場合、サーバーは それを受け入れるか失敗しなければならない:これはMandatoryが機能的要求の特性です。[HTTP-EXT] サーバーがプロポーザルを受け入れた場合、それ以上の応答は必要ありません。サーバーがプロポーザルを受け入れなかった場合、 サーバーはクライアントから受け取ったであろう全てのM-POSTメッセージを無視しなければならない。また、プロポーザルを 受け入れることが出来るというポリシーを提唱しているエラーを発行しなければならない(これによってクライアントは リトライするかどうか決めることが出来る)。これは、Optional P3P extension declarationを使用することによって行われ、 以下のP3P extensionsを設ける:
もちろん、新規プロポーザルが提供された場合、propID extensionを設けなければならない。 規定のrealm(レルム)は現行のRequest-URIのみです。
例えば、以前の同意が期限切れの場合:
HTTP/1.1 200 OK
Opt: "http://www.w3.org/TR/WD-P3P/"; ns='14-'
14-status: SRY-AE
14-propID: "md5:94df1293c1p8"
14-proposal: "http://www.privacy.org/newP3PProposal"
...
[Content]
理由コードはstatus extention headers(ステータスエクステンションヘッダ)内で送られ、プロポーザルやデータの状態を 表す(可能性として、以前の相互作用の状況内で)。全てのP3Pエクステンションは特定された値やextension URIと一緒に ステータスヘッダを含まなければならない。ステータスエクステンションを理解できないアプリケーションはP3Pメッセージを 無視しなければならない。
Reason Token(理由の標章) | Explaination(説明) |
OK | ok, プロポーザルの内容やデータエクステンションの受け取りが完全に成功した。 |
SRY-AU | 同意(agreement)が不明(unkown)であるから。(データエクステンションの内容に応じて送られた) |
SRY-AE | 同意(agreement)が期限切れ(expired)であるかあら。(データエクステンションの内容に応じて送られた) |
SRY-PR | プロポーザル(proposal)が拒否(rejected)されたため。(データエクステンションの内容に応じて送られた) |
SRY-DU | データ(data)が利用できない(unavailable)。(データエクステンションの内容に応じて送られた) |
SRY-DR | データ(data)を受け入れることができなかった。もしくはレポジトリ(repository)に 書き込めなかった。(データエクステンションの内容に応じて送られた) |
SRY | (sorry), プロポーザルの内容やデータエクステンションの受け入れに失敗。このコード は他のSRY-コードが適用できない時にプロポーザルエクステンションに応じて送られる。 |
ERR-IF | (invalid format), 受け取ったP3Pメッセージが文法的に不適切、または意味が通じない。 |
ERR-TF | データ転送失敗(data transfer failed), 文法的に正しく、正しい同意 がある転送要求が受け取られたが、何かの理由でデータを保存できなかった。 |
ERR | (error)要求は理解されなかった、または正しく受け取られた。このコードはその他全てのERR-コード が当てはまらない時に送られる。 |
注意:もしプライバシーの理由でクライアントがプロポーザルを拒否する理由を漏らしたくない時、クライアントは特定の“SRY- ”コード ではなく一般的な“SRY"コードをリプライすることが出来る。可能であれば何時でもERR-IF と ERR-TFコードが使用されることを推奨するが、 エラーコードも同様に特定の“ERR- ”コードではなく一般的な“ERR"コードを使うことが出来る。
1. 利用者がオーダーのページに行き、プロポーザルを要求:
GET store1.com/catalog/page1.html HTTP/1.1
Host: store1.com
Opt: "http://www.w3.org/TR/WD-P3P/"
2. もしくはサービスは要求されたURIに対してRDFによって構築された代替のプロポーザルのロケーションを返却する。
HTTP/1.1 200 OK
Opt: "http://www.w3.org/TR/P3P/"; ns='12-'
12-propID: "md5:aaaaaa"
12-proposal: "http://www.store1.com/P3PProposal1.RDF"
Opt: "http://www.w3.org/TR/P3P/"; ns='4253-'
4253-propID: "md5:ababab"
4253-proposal: "http://www.store1.com/P3PProposal2.RDF"
...
Content-Type: text/html
Content-Length: 110
<html><body>
<h1>Welcome to Cool Catalogue</h1>
<p>We'd love to have the following information to
customize our online catalogue to you.</p>
<form method="POST" action="http://www.CoolCatalog.com/cgi-bin">
<p><input type="submit" value="Submit" name="B1">
<input type="reset" value="Reset" name="B2">
First Name <input type="text" name="User.Name.First" size="20" value="Your First Name Here">
Second Name <input type="text" name="User.Name.Second" size="20" value="Your Second Name Here">
</form>
</body>
</html>
3. 利用者は返却されたデータと適切なpropIDを返却することにより同意する。 abstract data elements(抽出されたデータ項目)([BASEDATA]を参照)による同意は サービスとの交流が続いて起こっているかのように見せかけられる。
M-POST store1.com/catalog/page1.html HTTP/1.1
Host: store1.com
Man: "http://www.w3.org/TR/WD-P3P/" ns='23-'
23-propID: "md5:aaaaaa"
23-status: "OK"
23-data: <TXD xmlns="http://www.w3.org/TR/WD-P3P/syntax" xmlns:VOC="http://www.w3.org/TR/WD-P3P/vocab" xmlns:DATA="http://www.w3.org/TR/WD-P3P/basedata">
23-data: </TXD>
Man: "http://www.w3.org/TR/WD-P3P/" ns='78-'
78-propID: "md5:ababab"
78-status: "OK"
78-data: <TXD xmlns="http://www.w3.org/TR/WD-P3P/syntax" xmlns:VOC="http://www.w3.org/TR/WD-P3P/vocab" xmlns:DATA="http://www.w3.org/TR/WD-P3P/basedata">
78-data: <DATA:REF name="User.Name.First" value="Sheila">
78-data: <DATA:REF name="User.Name.Second" value="Doherty">
78-data:
...
[Content]
このセクションではユーザーエージェントとサービス間で転送された利用者データのブロックと同様に、 P3Pプロポーザルの文法や意味論について説明します。プロポーザルで使用される英語の用語説明は、 [HARMV]に、より詳しく記載されている。
英語版プライバシーポリシーと、Section 4.1でのP3Pプロポーザルについての例から始めます。 P3Pプロポーザルは、プロポーザル全体に適用される一般的な主張を含みます。同様に、statements(ステートメント) と呼ばれる特殊な主張は、data referencesにより参照された特定のデータタイプを操作する時のみ適用されます。 Section 4.2では、プロポーザル要素とプロポーザルにおける主張のレベルについて説明します。Section 4.3では、 データブロック(data blocks)を転送する時に使用されるTXD要素について、Section 4.4では、 ステートメントとデータの参照について説明します。
以下のセクションに中で、いくつかのXML要素を紹介しています。各々のXML要素は適切な属性とXML name space(xmlns)を伴って <>内に書かれてあります。全ての掲げてある属性はmandatoryとしてタグで囲まれている時を除いては、 任意のものである。
以下の例は、我々がP3Pプロポーザルとして記号化したい英語版のプライバシーポリシーの例です。
CoolCatalogはhttp://www.CoolCatalog.com/catalog/でのWebページの為に以下のステートメントを作成。cookieを使用し、利用者の性別と、(任意に)利用者が興味のある洋服のタイプや研究と製品の向上の為に カタログの入り口ページをカスタマイズするかどうかの、利用者の好みについての情報を収集する。 我々は、この情報をidentifiable form(確認可能なフォーム)内において使用しない。
我々はまた、どのページが訪れられたかや、利用者のWebブラウザのタイプについての情報を含んだログを サーバーに保持する。この情報は我々のWebサイトの保持、向上の為に使用される。 我々は、この情報をidentifiable form(確認可能なフォーム)内において使用しない。
我々は、利用者から得た情報に対してのアクセス権を与えない、しかし我々は情報を確実に保持し、そして プライバシーポリシーに関するページhttp://www.CoolCatalog.com/PrivacyPractice.htmlにおいて利用者が もっとポリシーについて読むことが出来るopt-out policiesを持っている。第三機関であるPrivacySeal.orgによって 我々がこの同意に従っている事の証明が提供される。
以下の例は、P3P要素と属性名を使用した括弧内に数値を持っているより正式な説明です。
Entity: http://www.CoolCatalog.com/
Realm: http://www.CoolCatalog.com/catalog/
Disclosure URI: http://www.CoolCatalog.com/PrivacyPractice.html
Access to Identifiable Information: none (3)
Assurance: PrivacySeal.org
Other disclosures: Change agreement, retention (0,1)We collect:
Cookies_
User.Gender
Form.Data_ (category=8, optional)
For purpose: Customization of the site to individuals, research and development (2.3)
Identifiable use: No (0)
Recipients: Only ourselves and our agents (0)
Consequence: A site with clothes you would appreciateWe collect:
ClickStream.Server_
HTTP.UserAgent_
For purpose: Web site and system administration, research and development (1,3)
Recipients: Only ourselves and our agents(0)
以下の[RDF]は、上記にあるような情報を捕捉する。 P3Pプロポーザルとは、[RDF]および、 有効でよく形成されたXMLの構文モデルに基づいて 正しく表現された文章でなければならない。しかしプロポーザルを短くするために使われる、 P3Pプロポーザルと標準RDFをわずかに区別する2つの仮定がある。もし、XML/RDFデータがP3Pと同種のものからなっているとき、 囲んでいるRDFタグは、任意に省略してもよい。より多くのプロポーザル文法については以下に続くセクションで説明されている。
<RDF:RDF xmlns:RDF="http://www.w3.org/TR/WD-rdf-syntax"> <PROP xmlns="http://www.w3.org/TR/WD-P3P/syntax" xmlns:VOC="http://www.w3.org/TR/WD-P3P/vocab" xmlns:DATA="http://www.w3.org/TR/WD-P3P/basedata" entity="http://www.CoolCatalog.com"> <ASSURANCE org="http://www.PrivacySeal.org" text="third party" image="http://www.PrivacySeal.org/Logo.gif"/> <REALM uri="http://www.CoolCatalog.com/catalog/"> <VOC:DISCLOSURE discURI="http://www.CoolCatalog.com/PrivacyPractice.html" access="3" other="0,1"/> <USES> <STATEMENT VOC:purp="2,3" VOC:recpnt="0" VOC:id="0" consq="a site with clothes you would appreciate"> <DATA:REF name="Cookies_" source="0"/> <DATA:REF name="Form.Data_" VOC:category="8" optional="1" source="0"/> <DATA:REF name="User.Gender" source="1"/> </STATEMENT> </USES> <USES> <STATEMENT VOC:purp="1,3" VOC:recpnt="0" VOC:id="0"> <DATA:REF name="ClickStream.Server_" source="0"/> <DATA:REF name="HTTP.UserAgent_" source="0"/> </STATEMENT> </USES> </PROP> </RDF:RDF>
このセクションでは、あるプロポーザルで動作するためのキーエレメント、属性、processing heuristicsについて定義する。全てのプロポーザルは[UTF-8]を使用して記号化される。
[1] | PROP-msg |
= |
(`<RDF:RDF xmlns:RDF="http://www.w3.org/TR/REC-rdf-syntax/">` proposal "</RDF:RDF>")| proposal |
[2] | proposal |
= |
`<PROP xmlns="http://www.w3.org/TR/WD-P3P/syntax" xmlns:VOC="http://www.w3.org/TR/WD-P3P/vocab" xmlns:DATA="http://www.w3.org/TR/WD-P3P/basedata"` [" agrexp=" `"` datetime `"`] ;default is six months " entity=" quoted-URI [" postURI=" quoted-URI] ">" 1*statement-block disclosure [assurance] 1*realm `</PROP>` |
entity(実体)の属性は、プロポーザル内にあるプライバシープラクティスの表現を作成する合法的な 実体と結びつけることが出来るドメイン名やパスを参照する。デジタル署名がない場合に、このentityはドメイン名 の登録所によって提供されている権威のない証明メカニズムとドメイン名に対して責任ががある団体のレコードによって 合法的な実体(legal entity)を追跡する唯一のメカニズムです。その上、entity(実体)属性は "root"ドメインとして使用され、"root"ドメインはレルム(realm)属性として認証が使用されない時 にレルム(realm)内のURIsと一致しなければならない(domain-match [KRISTOL])。
[3] | realm |
= |
"<REALM" " uri=" quoted-URI "/>" |
注意:REALM(レルム)要素の複合発生によって特定された複合レルムができることがある。
同意の範囲を設定したREALMにより特定されたURI("realm")。 この情報はユーザーエージェントにより使用される。例えば、サービスに既存の同意があるかどうか等。 各々のレルムURIsはサーバーのドメインと一致しなければならない("domain-match" [KRISTOL])。
ユーザーエージェントはどの同意が同意に至ったか、またそれに対応するpropIDと供にレルムを記録しなければならない。 そして、同意のレルムが有効である限り(実行可能な限り)それらの情報を保存しなければならない。 以前訪れた時のレルムのいかなる部分を返却する時、ユーザーエージェントは適切なpropIDをサービスへのリクエストに 含まなければならない。
Schemes(スキーマ)
P3Pは、HTTPと関連するschemes (HTTPSのような)用に設計されている。 特にHTTP、HTTPSの場合、HTTPを使用して同意に至った同意は、必然的にHTTPS schemesを使用するURI要求をサポートする。 例えば、利用者がレルム"http://www.romulus.com/"で同意に至った場合、https://www.romulus.com"がレルムの一部として考慮される。 しかし、利用者がレルム"https://www.romulus.com/"で同意に至った場合、"http://www.romulus.com" は同意を受け取る必要がない。 FTPなどのその他のスキーマを含むレルムに関して、同意に至ることがあるが、HTTP/HTTPSプロトコルを使用する、または HTMLコンテントに埋め込まれたリンクからによって同意に至らなければならない。 プロトコルはFTPやNNTP等のスキーマを使用したデータ交換や交渉(negotiation)をカバーするために将来拡張されるだろう。
The values of [4-6] are provided for reference only. The normative specification is in the harmonized vocabulary document. | |||
[4] | disclosure |
= |
"<VOC:DISCLOSURE" " discURI=" quoted-URI " access=" `"` access-disclosure `"` [" other=" `"` other-disclosure *("," other-disclosure) `"`] "/>" |
[5] | access-disclosure |
= |
"0" | ; Identifiable Data is Not Used(認識可能なデータは使用されていない) "1" | ; Identifiable Contact Information(認識可能なコンタクト情報) "2" | ; Other Identifiable Information(その他の認識可能な情報) "3" | ; None(なし) |
[6] | other-disclosure |
= |
"0" | ; change agreement(同意の変更) "1" ; retention(保持) |
[7] | assurance |
= |
"<ASSURANCE" " service=" quoted-URI [" text=" quoted-string] [" image=" quoted-URI [" width=" `"` number `"`] [" height=" `"` number `"`] [" alt=" quoted-string] ] "/>" |
注意:ASSURANCEの複数の発生により指定される複数のassurance serviceが存在する。
クライントはヘッダ内にXML/RDFメッセージを伝えることにより、特定の同意を参照したデータをサービス(Section 3.3.2を参照)に送る。 またサービスは、同じようなメッセージを利用者のデータレポジトリに保存してあるデータ要求の為にユーザーエージェントへ送ることが出来る。
[8] | TXD-msg |
= |
(`<RDF:RDF xmlns:RDF="http://www.w3.org/TR/WD-rdf-syntax">` txd-block `</RDF:RDF>`)| txd-block |
[9] | txd-block |
= |
`<TXD xmlns="http://www.w3.org/TR/WD-P3P/syntax" xmlns:VOC="http://www.w3.org/TR/WD-P3P/vocab" xmlns:DATA="http://www.w3.org/TR/WD-P3P/basedata" `>` *(data-reference) `</TXD>` |
TXDメッセージがHTTPヘッダの一部として送信された場合、改行を全ての >の後に入れなければならない。
その上、特有の接頭句をすべての行に入れなければならない。
例:
42-data: <TXD xmlns="http://www.w3.org/TR/WD-P3P/syntax"
xmlns:VOC="http://www.w3.org/TR/WD-P3P/vocab"
xmlns:DATA="http://www.w3.org/TR/WD-P3P/basedata">
42-data: <DATA:REF name="User.Name.First" value="Sheila"/>
42-data: <DATA:REF name="User.Name.Last" value="Doherty"/>
42-data: <DATA:REF name="User.Name.Title" value="Miss"/>
42-data: </TXD>
ステートメントは特定タイプのデータに適用されるデータプラクティスについて説明する。
[10] | statement-block |
= |
"<USES>" "<STATEMENT" [" action=" `"` action `"`] " VOC:purp=" `"` purpose *("," purpose) `"` " VOC:recpnt=" `"` recipients *("," recipients) `"` " VOC:id=" yesno [" consq=" quoted-string] ">" *(data-reference) "</STATEMENT>" "</USES>" |
[11] | action |
= |
("r" | "rw") ; r=read, rw=read&write, default is read |
The values of [12-15] are provided for reference only. The normative specification is in the harmonized vocabulary document. | |||
[12] | purpose |
= |
"0" | ; Completion and Support of Current Activity(現在の活動の終了と支持) "1" | ; Web Site and System Administration(サイトとシステム管理者) "2" | ; Customization of the Site to Individuals(個人のためのサイトのカスタマイゼーション) "3" | ; Research and Development(研究開発) "4" | ; Contacting Visitors for Marketing of Services or Products(サービスや製品のマーケティングのために利用者とコンタクトを取る) "5" [" (" string ")"] ; Other Uses(その他の使用) |
[13] | recipient |
= |
"0" | ; only ourselves and our agents(我々とエージェントのみ) "1" | ; organizations following our practices(我々のプラクティスに従う団体/組織) "2" | ; organizations following different practices(その他のプラクティスに従う団体/組織) "3" ; unrelated third parties or public forum(関係の無い第三機関や公共のフォーラム) |
[14] | id |
= |
yesno |
[15] | yesno |
= |
"1" | "0" ; 1 stands for "Yes", 0 for "No" |
注意: もともとサービスにこれらのデフォルトに対抗して、これらのプラクティスに正直であるように強制するために かなり保守的なデフォルト値は("0")となっていた。しかし、これは意味相互運用性(semantic interoperability) に結びつく可能性があった。サービスはある属性が任意であると思い、ユーザがそれらに(?)暗黙の/デフォルトの 意味に基づいた情報をあたえる。もっと良いアプローチは、デフォルト値をかなり高く設定することである。 (すなわち、recipient属性が含まれていない場合は、データが公共に分配されていることを意味する) しかし、我々は、任意属性と規定の意味論を持った要求されている属性の混同を避けるために規定値を提供しない立場 をとりつつある。
サービスは利用者のレポジトリに情報が書きこまれたかどうか問う権限がある。 P3Pエージェントが以下の要求をプロポーザルの一部として受け取ったと考えてください:
<STATEMENT action="r" VOC:purp="2" VOC:recpnt="0"
VOC:id="0"/>
<DATA:REF name="User.Name.First"
source="1"/>
</STATEMENT>
<STATEMENT ="rw" VOC:purp="2" VOC:recpnt="0" VOC:id="0">
<DATA:REF name="FineShoes.shoesize"
xmlns:DATA="http://www.FineShoes.com/Schema1.0"
source="1"/>
</STATEMENT>
利用者はこのプロポーザルに対して同意したかどうか尋ねられ、User.Name.Firstが自動的に 記入(利用者は以前に入力していたと仮定する)されていて、FineShoes.shoesizeの部分は 無記入のフォームのような物を見せられる。利用者は無記入の欄を記入しTXDを使用して データを転送するだろう。
利用者は以下のものを転送する:
43-data: <TXD xmlns="http://www.w3.org/TR/WD-P3P/syntax"
xmlns:VOC="http://www.w3.org/TR/WD-P3P/vocab"
xmlns:DATA="http://www.w3.org/TR/WD-P3P/basedata">
43-data: <DATA:REF name="User.Name.First" value="Sheila"/>
43-data: <DATA:REF name="User.Name.Second" value="Doherty"/>
43-data: <DATA:REF
name="FineShoes.Shoesize" xmlns:DATA="http://www.FineShoes.com/Schema1.0"
value="7"/>
</TXD>
データエレメントが"rw"属性になっていて、利用者によって新規の値が提供された場合、 ユーザーエージェントはデータレポジトリへの書きこみを試みなければならない。 書きこみが失敗した場合、ユーザーエージェントは適切なレスポンスコードを返却しなければならない。 この自動書き込み機能は、サービスがユーザーエージェントに対し情報を再転送する必要性を省く。 しかし、サービスは何時でもTXDメッセージを送ることが出来る。例えば、利用者は靴のサイズを "7"として提供したけれども、サービスはヨーロッパでの靴のサイズに変換して書き込みたい。
xmlns="http://www.w3.org/TR/WD-P3P/syntax"
xmlns:VOC="http://www.w3.org/TR/WD-P3P/basedata"
[16] | data-reference |
= |
"<DATA:REF" " name=" quoted-string " source=" `"` source `"` [" xmlns:DATA=" quoted-URI] [" optional=" yesno] [" value=" quoted-string] [" type="quoted-string] [" typeschema=" quoted-string] [" template=" yesno] [" VOC:category=" categories] [" short=" quoted-string] [" long=" quoted-string] [" size=" `"` number `"`] ; default is 0 (unlimited size) "/>" |
[17] | source |
= |
"0" | ; service "1" | ; agent "2" | ; matched-form "3" ; extension |
[18] | categories |
= |
`"` *(number ",") number `"` |
例:利用者の町、User.Business.のデータセットの全てのエレメントと (任意に)User.Home.Telecom.Phoneのデータセットの全てのエレメントを要求し 一致したフォームを参照することにより情報を収集。;サービスはP3Pプロポーザル内で 以下の内容を送信する。
<DATA:REF name="User.Home.Postal.City" source="2"/>
<DATA:REF name="User.Home.Telecom.Phone." optional="1"
source="2"/>
<DATA:REF name="User.Business." source="2"/>
利用者が町、ビジネス情報、国際電話番号と市外局番のみを返信することに同意した場合、 txdタグ内において、以下の物を返信する。
<DATA:REF name="User.Home.Postal.City" value="Cambridge"/>
<DATA:REF name="User.Home.Telecom.Phone.IntCode" value="1"/>
<DATA:REF name="User.Home.Telecom.Phone.LocCode"
value="617"/>
<DATA:REF name="User.Business.Postal.Street" value="254 Windsor
St."/>
<DATA:REF name="User.Business.Postal.City"
value="Cambridge"/>
... (the other values of User.Business.) ...
Category は、データエレメントの属性であり、ユーザとユーザエージェントにデータの意図した使い方のヒントを与える。Categoryは、P3P ユーザエージェントの実施や使用を簡単にするために必要である。これにより、ユーザがデータの交換においてより一般的なプリファレンスやルールを表現することができる。Categoryは、新しいエレメントを定義したり、データを作るために参照したりする時にしばしば含まれる。
Categoryの中のデータエレメントのメンバーシップは、一般的にばらばら(disjoint)である。ほとんどのデータエレメントは、1つのcategoryに属さなければならないが、必要であればそれらは複数のcategoryに属する場合もある。さらに、データセットは、エレメントが属する全てのcategoryに属する。 基本データエレメントは全てP3P仕様書のデフォルトcategoryに割り当てられている。サービスが新しいデータエレメントをproposeする時、そのプロポーザルは、デフォルトcategoryかエレメント用のcategoryを含んでいなければならないが、ユーザやユーザエージェントは、category割り当てに対する最終的な制御権を持っている。
P3Pの現在のバージョンでは以下の数字がデータカテゴリを示すために使用されている:
"0" ; Physical Contact Information "1" ; Online Contact Information "2" ; Unique Identifiers "3" ; Financial Account Identifiers "4" ; Computer Information "5" ; Navigation and Click-stream Data "6" ; Transaction Data "7" ; Preference Data "8" ; Demographic and SocioEconomic Data "9" ; Content
categoryに関する詳しい説明はP3P Harmonized Vocabulary Specificationを参照して下さい。
source属性は、ユーザーエージェントからサービスへのデータ転送のためのメカニズムを明記します。 我々は3つのスタンダードメカニズムを定義し、拡張可能なメカニズムは、将来的に新規のデータ転送メカニズムを受け入れる。 スタンダードメカニズムは以下のようなものである:
またサービスは、ここで定義されていない他の機構(electronic commerce wallet(電子財布)など)を使用してデータを転送したいかもしれない。 その場合、サービスはその機構を使用してデータが収集される事を示すためにsource="3"を明記しなければならない。
DATA:REF エレメントは常にデータスキーマの定義内にある時を除いて、source attribute(ソース属性) を一つだけ含まなければならない。属性が完全に省かれた場合、属性は一つまたは複数の値を取るだろう。
サービスはデータ要求が任意である事を示すために任意の属性を使用するだろう。 ユーザーエージェントは利用者のプリファレンスに従って、任意の属性を送信または無視するだろう。
注意:P3Pは確かなデータプラクティスが任意であるか特定するための機構を含んでいない。 もしサービスが利用者にデータプラクティスの選択権を与えたいならば(例えば、データがマーケティングに使用されるかどうか)、 利用者が選択できる複合代替プロポーザルを提供することによって選択権を与えることが出来る。
サービスはデータスキーマを作成することにより新規データエレメントを宣言/使用でき、 DATA namespace(xmlns:DATA)を使用することによってプロポーザル内のデータエレメントを参照できる。 基本データセット[BASEDATA]に定義されていないデータエレメントがプロポーザル内で参照された時、 DATA:REF エレメントは以下の属性のための値を含まなければならない: name, category, type, typeschema, short (typeschema は DATAnamespaceと同じ値を持つ場合、省略できる) データスキーマのURIがオリジナルのサーバーのURIとの間で、ドメインの一致をしない場合、ユーザーエージェントは 情報の一貫性を確かめるためにデータスキーマを確認しなければならない。または、メインデータスキーマの情報は 情報の一貫性を確かめるために確認されるだろう。 ドメインが一致しない場合、ERR-IF(Invalid Format)コードまたは一般的なERRコードが返却されなければならない。 何かの理由で利用者が必要とされた情報を再構築できない場合、SRY-DU(Data Unavailable)コードまたは一般的な SRYコードが返却されなければならない。
新規データスキーマのフォーマットはフォームの特殊なプロポーザルです。
<PROP xmlns="http://www.w3.org/TR/WD-P3P/syntax" xmlns:VOC="http://www.w3.org/TR/WD-P3P/vocab" xmlns:DATA="http://www.w3.org/TR/WD-P3P/basedata"> <USES><STATEMENT> .... </STATEMENT></USES></PROP>
データブロックは<STATEMENT>タグで囲まれており、新規データエレメントの参照を含んでいる。 参照は、<DATA:REF>タグと以下の属性を使用して作成されることが出来る: name, type,typeschema, template, VOC:category, short, long, size, source.
全てのデータエレメントについて、全ての情報(longとsourceは除く)は必須である。 もしsourceが存在する場合、エレメントは特定のデータ転送機構を用いてのみ収集されなければならない。 もしsourceが無い場合、どのようにエレメントが収集されるかについての制限はない。 もし属性が無い場合、空の文字列が存在すると考えられる。 typeschemaの場合、空の文字列はタイプスキーマがxmlns:DATAの属性値と一致する事を意味する。
例えば、HyperSpeed社は以下のようなデータスキーマを構築したいと想定する:
car.model
car.color
car.built.year
car.built.where. (of basic type Postal.)
car.price
bike.model
bike.color
bike.built.year
bike.built.where. (of basic type Postal.)
bike.price
それからHyperSpeed社は、以下のコードをhttp://www.HyperSpeed.com/models-schemaに置く。
<PROP xmlns="http://www.w3.org/TR/WD-P3P/syntax" xmlns:VOC="http://www.w3.org/TR/WD-P3P/vocab" xmlns:DATA="http://www.w3.org/TR/WD-P3P/basedata"> <USES><STATEMENT VOC:purp="4" VOC:recpnt="0" VOC:id="0"> <DATA:REF name="car.model" type="Text" short="Model" VOC:category="7" size="63"/> <DATA:REF name="car.color" type="Text" short="Color" VOC:category="7" size="63"/> <DATA:REF name="car.built.year" type="Number" short="Construction Year" VOC:category="7" size="63"/> <DATA:REF name="car.built.where." type="Postal." short="Construction Place" VOC:category="7" size="63"/> <DATA:REF name="bike." type="car." typeschema="http://www.HyperSpeed.com/models-schema"/> </USES></STATEMENT></PROP>
注意:データセットが作られる度に、必然的にデータセットはタイプ(上記のcar.のように)として使用される。 しかし、何らかの状況で、利用者のレポジトリ内で特定のエレメントを作成すること無しに、タイプを定義したいと望むだろう。 これは、<DATA:REF>内でtemplate属性を使用することにより成し遂げられることが出来る。 値を"yes"、template="1" (規定値は "0")に設定すると、一致するデータエレメントはタイプの定義の一部のみである事を意味する。 そして、それは実際には提携された値のデータエレメントを示していない。 例えば、HyperSpeed社はGenericModel.を一般的な実用品として定義したい。それから、car. と bike. を具体的な物としたい。これは以下のスキーマに従うことで可能である:
<PROP xmlns="http://www.w3.org/TR/WD-P3P/syntax" xmlns:VOC="http://www.w3.org/TR/WD-P3P/vocab" xmlns:DATA="http://www.w3.org/TR/WD-P3P/basedata"> <USES><STATEMENT VOC:purp="4" VOC:recpnt="0" VOC:id="0"> <DATA:REF name="GenericModel.model" type="Text" short="Model" template="1" VOC:category="7" size="63"/> <DATA:REF name="GenericModel.color" type="Text" short="Color" template="1" VOC:category="7" size="63"/> <DATA:REF name="GenericModel.built.year" type="Number" short="Construction Year" template="1" VOC:category="7" size="63"/> <DATA:REF name="GenericModel.built.where." type="Postal." short="Construction Place" template="1" VOC:category="7" size="63"/> <DATA:REF name="car." type="GenericModel." typeschema="http://www.HyperSpeed.com/models-schema" short="Car"/> <DATA:REF name="bike." type="GenericModel." typeschema="http://www.HyperSpeed.com/models-schema" short="Bike"/> </USES></STATEMENT></PROP>
新規にスキーマを作成する者はソース属性(例えば source=0 や、 利用者のレポジトリにデータを保存しない拡張 機構の使用)に制限を設けない限り、ユーザーエージェントは利用者が新規スキーマのエレメントを書きこんだ後に、自動的にレポジトリに それらのエレメントを保存する事を理解していなければならない。 いくつかの実装はセンシティブなデータの保存に対しての適切なセキュリティーを設けていない利用者レポジトリを持っているものも ある。
正式なP3Pの文法については、このスペック内にありhttp://info.internet.isi.edu/in-notes/rfc/files/rfc2234.txtで定義されているABNFを少し修正した物を使用している。以下はABNFの簡単な説明です。
name = (element)
(
element1 element2)
<a>*<b>element
<a>element
<a>*element
*<b>element
*element
[element]
"string"
or 'string'
使用されているその他の記号法は:
Lorrie Cranor | AT&T |
Philip DesAutels | Matchlogic |
Melissa Dunn | Microsoft |
Daniel Jaye | Engage Technologies |
Steve Lucas (Chair) | Matchlogic |
Massimo Marchiori (Editor) | W3C |
Maclen Marvit | Narrowline |
Max Metral | Firefly Network Inc. |
Paul Perry | Firefly Network Inc |
Martin Presler-Marshall | IBM |
Joseph Reagle (Project Manager) | W3C |
Drummond Reed | Intermind |