Platform for Privacy Preferences(P3P) Syntax Specification
W3C Working Draft 26 August 1999
http://www.w3.org/TR/1999/WD-P3P-19990826/syntax
の和訳です。
このドキュメントには和訳上の誤りがありえます。
内容の保証はいたしかねますので、必ずW3C Webサイトの正式版ドキュメントを参照して下さい。
また、著作権については本ドキュメントに含まれる記述に加え、こちらも必ず参照してください。
Copyright (C) 1999 W3C (MIT, INRIA, Keio), All Rights Reserved. W3C 責任、登録商標、, 文書の使用、 そして ソフトウエアライセンスに関する規則が適用される。
Copyright(C) 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勧告案に昇格する。W3Cのワーキングドラフトを参考資料として使ったり、"進行中の作業"としてではない引用を行うことは好ましくない。このドラフトの基本コンセプトはかなりしっかりとしており、我々は仕様へのフィードバックのために実験的な実装やプロトタイプの開発を行うことを奨励する。しかしこのワーキンググループでは、今後のバージョンの文書を変更する可能性のある早期の実装は認めないであろう。
このドラフトはW3C processに従い、W3Cとそのメンバーにより考えられている。この文書はP3Pの実装、承認、採用に影響を与えそうな問題に関して、W3Cの会員およびスタッフに送られるコメントを受け取る目的で公開されている。
コメントがある方は以下にお願いしたい。
www-p3p-public-comments@w3.org
（アーカイブは
http://lists.w3.org/Archives/Public/www-p3p-public-comments/）
P3P(The Platform for Privacy Preferences)プロジェクトは、Webサイトが自分たちのプライバシープラクティスを表現し、ユーザがそれらのプラクティスに対するプリファレンスを実行することを可能にする。P3P準拠の製品は、ユーザが（マシンと人間の両方が解読できる書式で）サイトのプラクティスを知ること、適切ならばコンピュータに決定を委ねること、そして特定サイトに結びつけることを許す。ユーザのプリファレンスに適合したサイトのプラクティスは、ユーザの選択によりシームレスにアクセスすることができる。そうでない場合は、ユーザはサイトのプラクティスを通知され、それらに同意する機会を与えられてブラウジングを続けることができる。
P3Pは、ユーザがWeb上で十分に説明された決定を行う能力と、彼らの情報の使用を制御する能力を与える。サイトはP3Pを、サービス品質の向上、コンテンツのカスタマイズ、サイトアクセスの簡略化だけでなく、サービス内での信頼ユーザの地位レベルを上げるために使うことができる。
P3Pは、 [XML]（ [RDF]データモデルを使用）を、構造化されたデータと主張の交換の為に使用する。P3Pは将来のデジタル認証とデジタル署名の能力もサポートする予定である。P3Pはブラウザ、プラグイン、サーバ、もしくはクライアントとサーバ間のプロキシサーバに組み込むことができる。
The P3P specification は以下の機構を提供します：
このドキュメント（各章、各規準参照）は、統一されたP3Pアプリケーションのインプリメントに必要な全ての仕様を含んでいます。
このドキュメントは、P3P仕様のメインとなる部分を含んでいます。プライバシーデスクロージャー用語の語議論の詳細 ＜natural language＞は、[HARMV]で見ることができます。文法と基本データセットのデータ・タイプの詳細は、[BASEDATA]で見ることができます。
注意：P3P1.0に準拠する為には、上記の用語を使用することが要求される。同時に、XML-namespaces [XML-name]の利便さは、付加または補足的な用語を容易に取り入れることを可能にする。
文章のステータスを表現するために以下の規約を用いる：
| ABNF表記法の中のスキーマ定義 |
この仕様書で使われたABNF表記法は、RFC2234で規定されている。また、Appendix 2に要約されている。しかし、そのようなシンタックスは、XMLシンタックス文法の典型だけであることに注意してください。また、XMLの全ての統語的な適応性は無条件で含まれる。例えば、「空白に関する規則」、「クォートする場合に、シングルクォート(')または、ダブルクォート(")の何れかを使用する」、「character escaping」、「大文字・小文字の区別」などです。
利用者がWebサービスに遭遇した場合、Webサービスは、個人情報の取り扱い方に関しての宣言を行い、利用者にP3P プロポーザルのURIと、propIDと呼ばれるプロポーザルの識別子を送る事によって、利用者からの情報を求めるだろう。プロポーザルとpropIDは、HTTPの転送メカニズムを拡張した物を使用して転送される。
P3Pプロポーザルは複数のステートメントを含み、データエレメントセットに関するプライバシープラクティスを表記している。また、P3Pプロポーザルは全ての適切なデータエレメントとプラクティスをカバーしなければならない。（サイトがデータエレメントを収集したい場合、プロポーザルにおいて、その旨を宣言しておかなければならない）
注意：P3Pでのプロポーザル宣言は、肯定的でなければならない。（”何をしない”ではなく”何をする”と言うような表現）
P3P specification での中心的概念は P3P agreement（同意）です。P3P agreement とは、サービスとユーザーエージェント双方で同意したプロポーザルのことである。ユーザーエージェントは同意を始めるかどうかを決定するために、プロポーザルに宣言してあるプライバシープラクティスと利用者のプリファレンスを比較する。同意は一つ以上の指定されたレルム内において、ユーザーエージェントとサービス間での全てのデータ交換に適用する。
（レルム：唯一のURIから参照されるWebリソース、またはTree構造のWebリソース）
ユーザエージェントが受諾可能なプロポーザルを見つけた場合、エージェントは、プロポーザル識別子を送り返す事で、Webサイトに同意を示すことができる。もしプロポーザルがP3Pデータ転送方法を使用したデータ転送要求を含んでいる場合、一致するデータはプロポーザル識別子と共に返却される。
サーバーは個々のレルムに対して、多種多様な代替のプロポーザルを提供するだろう。すべてのプロポーザルは、なぜ提案されたプラクティスが、普段利用者が受け入れないようなプラクティスであるにもかかわらず、ある特定の場合に重要であるかを、利用者の目に見える形で説明することができる帰結のセットを持つことができる。ユーザエージェントは、同意に至ったこと（propIDと呼ばれる、同意の識別子によってインデックス化）を記録すべきである。毎回の交渉で、ユーザエージェントに新規のプロポーザルURIとpropIDを送るよりは、サイトは、既存の同意のpropIDを送るだろう。
またサービスは、P3Pプロポーザルを参照する<LINK>タグをHTMLのコンテンツ内部に埋め込むだろう。これは、サービスがP3P準拠のサーバーの使用にかかわらず、P3Pプロポーザル内に明記してある個人情報の取り扱い方に従っていることを主張することを許可する。
我々が現実的に提供する拡張的メカニズムについて、二つの注目すべきエリアがある。
我々の設計は次のようなものである。独自の想定において効果的に実装できるアプリケーションやマルチラウンド通信の待ち時間、キャシュ可能なプロポーザル、ユーザーエージェントやサーバー側のデータレポジトリの使用、同意レポジトリのサイズに等に関する期待である。
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 | エージェント及びサービスはこの場所にプロポーザルを設置することが出来る必要がある。 | |
| XML 解析 | MUST | プロポーザルとデータシンタックスは、速やかに処理されるか、ユーザに提出される。RDFデータモデルは、必要なgrammar/シンタックスを構成するために使用されるが、アプリケーションは、その必要を感じない場合は必ずしもRDFをサポートする必要はない。 | |
| 完全なXMLとXML-namespaceのサポート | MUST | 使用されるだけでなく、完全に XML と namespacesをサポートしなければならない。 | |
| Data References | base data reference syntax | MUST | エージェントは請求されている情報のシンタックスを理解できなければならない。 |
| Harmonized Vocab | harmonized vocabulary | MUST | 要求事項に関しては、harmonized vocubarly[HARMV] を参照。この必要条件を満たさなければならない。満たさない場合、インプリメンテーションがプライバシー公開を適切なレベルで出来なくなってしまう。 |
| Reason Codes | (OK, SRY-, ERR-, SRY, ERR) | MUST | 同意に達するために必要。 |
| propID レポジトリ | SHOULD | 完全なプロポーザルはコンパクトに表現されることができる。同意が既に存在する場合、新規のネゴシエーションと同意は必要ない。 | |
| データ レポジトリ | MAY | 頻繁に要求される利用者プロフィール情報は利用者によって保存/管理される。 | |
| Data Definitions | new schema instantiation | MAY | base setとは異なったスキーマは、エージェントにより例示/サポートされることが可能である。 |
| Source Attribute | source attributes "matched-form" and "extension" | MAY | base setとは異なったスキーマは、エージェントにより例示/サポートされることが可能である。 |
注意：サービスは、ユーザエージェントに利用可能なP3Pプロポーザルを作成するために、P3P準拠のサーバーを使用する必要はない。
簡易P3PユーザーエージェントはP3Pプロポーザルを受け取って、利用者にそれらを提示するぐらいの機能を有し、情報要求があった場合、ユーザーエージェントは利用者に決定権を委ねる。そのため、ユーザーエージェントは利用者の自動的な利用者情報の転送（クリックストリームのような受動的に生成されたものは除く）のための決定権を持っていない。
利用者の自動的な利用者情報の転送のための決定権を持っているユーザーエージェントは、"trust engine"を含まなければならない。trust engineはP3Pプロポーザルと利用者のプリファレンスセット（規則として記録されている）の入力や、どのようなアクション（シームレスな受託、拒否、情報プロンプト、警告プロンプト、その他のアクション）をとるかと示すことで取得することが可能でなければならない。利用者のプリファレンスは[APPEL]や他の言語で記号化されることが可能である。プリファレンス言語はドキュメント化されるべきであり、その言語によって規則を作成するユーザーインターフェイスを提供すべきである。ユーザーエージェントは利用者自身が作成した、もしくは他人から手に入れた規則をインポートする方法を提供すべきである。また、利用者が規則の作成/変更可能な機能も提供すべきである。
ユーザーエージェントは初期の段階では、何も設定されていない状態（利用者が利用する前に設定ができるように）、もしくはデフォルトの規則の設定がなされている状態である。しかし、利用者の有効な同意なしに個人情報をサービスプロバイダに転送するようなデフォルトの設定をしてはならない。（シームレスな受託）
以下のシナリオは、P3Pが使われる可能性のあるいくつかの場面について説明してあります。各シナリオは、それぞれ異なるP3Pの特徴を強調しています。シナリオ１はどのようにして基本的なP3P同意が確立されるかを示しています。シナリオ２、３は既に同意に達しているサイトにユーザが戻った際に何が起きるかを示しています。シナリオ４は同意を与えられたデータレポジトリの使用について強調しています。
これらのシナリオは交渉が発生しない場合の相互作用を図解している。しかしどのシナリオもサイトが初めから複数のプロポーザルを行うシナリオに拡張される可能性がある。
以下の表は、各シナリオの特徴をまとめたもの。表中の"-"は、そのシナリオでは仮定されない(中立な)という意味を表す。
| Scenario | Existing Agreement | New Proposal | Data Requested |
| 1 | No | Yes | - |
| 2 | Yes | No | - |
| 3 | Yes | Yes | - |
| 4 | - | - | Yes |
プロトコルモデルは、クライアントがアクション（プロポーザルを要求するような）を起こし、そしてサーバーは、他のアクション（例えば、プロポーザルの返却を提案する）で相互作用を完結する、単一の相互作用を基本としている。我々は、コンパクトなデータ（普通は単一行）はHTTPヘッダ内に置くべきであるという経験から得た法則に従って以来、しばしば要求に対するレスポンスはクライアントが実際のプロポーザルを取ってくるべき場所からになる。（HTMLクライアントがページ内の画像を取ってくるのに数回リクエストをするようなもの）この単一相互作用（複数回のHTTPリクエストを含む）は、必要であれば複数回の相互作用（または"交渉"）に拡張する事が出来る。すなわち、複数回の相互作用は単一の相互作用の上に作る事が可能で、単一の相互作用には何の影響も与えないからです。注意：proposed protocolの相互作用は、P3Pを認識している、または認識していない中間キャシュに正しく作用するために、厳密にHTTPの request/responce の表記法に従う。
基本的なプロトコルの動作は以下のようにまとめることが出来る。
クライアントは要求を発行する時に、以下の動作をいつでもすぐに行うことが出来る。
サーバーは以下のアクションを行うことが出来る。
P3Pプロトコルは、HTTP Extension Framework[HTTP-EXT]を使用する。P3Pは、いかなるスタンダードなHTTP要求に追加することができるであろう四つの拡張ヘッダを含んでいる。HTTP Extension Frameworkを使用するためには、拡張（拡張宣言）を識別するための、グローバルなユニークURIを規定することが要求される。P3Pの拡張宣言は以下のURIを参照して下さい。
http://www.w3.org/TR/WD-P3P/
P3P extensions は以下のようなものである。
このセクションでは、P3Pに準拠したクライアントとサーバーが、HTTPプロトコルの拡張としてP3Pプロトコルを実施するために、どのようなアクションをするかについて説明します。またこのセクションでは、このプロトコルを実施する場合に報告しなければならない様々なエラーコードへの参照も含んでいる。それらのエラーコードについての詳細は、はセクション3.4.で、定義、議論されています。
P3P クライアントは、以下の事柄を行うことができなければならない：
Opt: "http://www.w3.org/TR/WD-P3P/"
or Man: "http://www.w3.org/TR/WD-P3P/"
一般的には、Optヘッダが使用されるべきである。しかしながら、クライアントが、P3Pのサポートを要求するという事を述べたい場合、必須の拡張が、M-GET、 M-POSTメソッドと共に使用されるだろう。P3P準拠のサーバーは、ManとOptヘッダを同等に取り扱わなければならない。
P3P-HTTPヘッダ拡張を含む全ての要求は、暗黙のプロポーザル要求である。P3P準拠のサーバーは、適切なプロポーザルが有効である時に、常にpropIDとP3P拡張ヘッダproposalを送信するだろう。
クライアントが、単にプロポーザルだけを要求したい場合（内容は含まない）、クライアントは、OPTIONSまたは、HEAD要求を発行するだろう。
クライアントが、プロポーザルと内容を同時に要求したい場合、クライアントは、GET要求（または、その他の適切な要求）を発行しなければならない。サーバーが、P3Pの同意に至った事に関係なく、内容を提供することを望んでいる場合、サーバーは、propIDとP3P拡張ヘッダプロポーザルにそって、適切な内容を提供するだろう。サーバーが、同意に至るまでは、内容を提供しない場合、サーバーは、P3Pstatusヘッダ内のSRY-ARコード、あるいはHTTP 510エラーコードで返答するだろう。プロポーザルが受諾可能な場合、クライアントは、適切なpropIDと共に拡張ヘッダを含んだオリジナルの要求を再び行わなければならない。
注意：利用者が、P3P準拠のユーザ・エージェントを、データの交換を行う以前に、Webサイトと同意に至るように仕向けた場合、クライアントは、対応するP3Pの同意が無いURIに対してデータを送ってはならない。従って、POST要求もまた暗黙のプロポーザル要求であるけれども、同意無しではデータを送らないように設定されているクライアントから、そのような方法は使用すべきではない。代わりに、OPTIONS や HEAD要求が行われるべきである。以前に、propIDを獲得しているならば、POST要求を行うことができる。同様に、同意無しではデータを送らないように設定されているクライアントは、同意が存在しないレルムへのフォームデータ（一般的にそのような要求はクエスチョンマークを含んでいるだろう）を含むGET要求を送る前に、OPTIONS や HEAD要求を発行しなければならない。加えて、同意に至るより重要な、データを送らないことに関する注意が必要である、クライアント実装ケースがあるだろう。
クライアントは、リクエスト内に与えられたpropIDを含む初回に、要求された何れかのデータをサブミットしなければならない。クライアントが、propIDを含むリクエストをサブミットし、要求されたデータをサブミットしなかった場合、サーバーは、statusヘッダ内にP3P SRY-DR、もしくはHTTP 510エラーを送ることによって、データを要求するだろう。クライアントが、SRY-DRを受け取った場合で、クライアントがまだ要求したリソースにアクセスすることを望む場合、クライアントは、要求されているデータと共に、リクエストを再び行わなければならない。
P3P サーバーは、以下の事柄を行うことができなければならない：
クライアントが、proposalヘッダ、P3PLINKタグ、またはプロポーザル内のdiscURIタグによって示されているURIに対してGET要求を発行する事によって、プロポーザルまたは、人間が読める形のプライバシーポリシーを要求した時、サーバーは、同意要求無しで、要求を満たさなければならない。
複数のプロポーザルに伴うエラーを報告する場合、サーバーは、一つのエラーと、そのエラーが適用された全てのpropIDのリストを報告するか、もしくは個々のpropIDのエラーを報告するだろう。異なったエラーが個々のpropIDに適用された場合、エラーは個別に報告されなければならない。
以下は、どのようにP3P準拠のクライアントとサーバー間での相互作用が、通常発生するかの例です。クライアントとサーバーの動作の例は、影つきの箱内に示しています。
1. クライアントがGETまたはPOSTまたは、なにかしら有効な方法を使用してリソースを要求する。また、クライアントは、P3P利用可能であることを示すために、P3P拡張ヘッダを送る。
GET coolcatalog.com/index.html HTTP/1.1 Host: coolcatalog.com Opt: "http://www.w3.org/TR/WD-P3P/" |
2a. サーバーが、P3P同意を要求しない場合、サーバーは、内容、propIDとproposalヘッダを返信する。複数のpropIDとproposalヘッダの組は、サーバーが複数の代替えプロポーザルからの選択権を申し出ていることを示すことに使用されるだろう。（内容を表示する前に、クライアントは任意にフェッチし、個々のプロポーザルを評価するだろう）[全てのプロポーザルが受け入れられない場合、ステップ３ｂへスキップしてください。そうでなければ、ステップ５へスキップしてください。]
HTTP/1.1 200 OK Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1 1-propID: Ed3Oorq/ZJbTpVaFRD4qfA== 1-proposal: http://coolcatalog.com/P3PProposal1.xml Opt: "http://www.w3.org/TR/WD0P3P/"; ns=2 2-propID: 9Pfx3KzqthhRfWxxW1gLnQ== 2-proposal: http://coolcatalog.com/P3PProposal2.xml . . . Content-Type: text/html . . . |
2b. サーバーがP3P同意を要求する場合、一つまたは複数のpropID/proposalヘッダ、status: SRY-ARヘッダ、そして任意にHTTP 510エラー・コードを返却する。
HTTP/1.1 510 Not Extended Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1 1-propID: Ed3Oorq/ZJbTpVaFRD4qfA== 1-proposal: http://coolcatalog.com/P3PProposal1.xml 1-status: SRY-AR Opt: "http://www.w3.org/TR/WD-P3P/"; ns=2 2-propID: 9Pfx3KzqthhRfWxxW1gLnQ== 2-proposal: http://coolcatalog.com/P3PProposal2.xml 2-status: SRY-AR . . . |
（クライアントが、プロポーザルを評価する必要がある場合、クライアントは、proposalヘッダによって示されているURIに対してGET要求を発行する事によってプロポーザルを取得してくる。プロポーザルを取得した後、クライアントは、任意に利用者と、プロポーザルが受諾可能か、そして/または利用者に情報を表示するかを決定するために、互いに伝達し合うだろう。）
GET coolcatalog.com/P3PProposal1.xml HTTP/1.1 Host: coolcatalog.com Opt: "http://www.w3.org/TR/WD-P3P/" |
3a. プロポーザルが受け入れ可能ならば、クライアントは、要求をサブミットしなおす。この時は、propIDと要求されたデータを含む。（複数のプロポーザルが有効な場合、クライアントは、一つを選択し、それに対応するpropIDをレスポンスの中に含まなければならない）
GET coolcatalog.com/index.html HTTP/1.1 Host: coolcatalog.com Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1 1-propID: Ed3Oorq/ZJbTpVaFRD4qfA== 1-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"> 1-data: <DATA:REF name="user.name.first" value="Sheila"> 1-data: <DATA:REF name="user.name.second" value="Doherty"> 1-data: </TXD> . . . |
3b. プロポーザルが受け入れられない、もしくは他のエラーがある場合、クライアントは適切なSRYまたはERRヘッダと一緒にリクエストを再送信する。（リクエストが成功しない限り、POST要求や、他の要求を繰り返すと望ましくない副作用をもたらすだろう）[ステップ２に戻ってください。しかし、クライアントは、クライアントの要求が数回失敗した後には、無限ループを避けるために、要求をあきらめなければならない。]
GET coolcatalog.com/index.html HTTP/1.1 Host: coolcatalog.com Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1 1-propID: Ed3Oorq/ZJbTpVaFRD4qfA== 1-status: SRY-PR Opt: "http://www.w3.org/TR/WD-P3P/"; ns=2 2-propID: 9Pfx3KzqthhRfWxxW1gLnQ== 2-status: SRY-PR |
他の手段として、以下のものは書かれています:
GET coolcatalog.com/index.html HTTP/1.1 Host: coolcatalog.com Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1 1-propID: Ed3Oorq/ZJbTpVaFRD4qfA== 1-propID: 9Pfx3KzqthhRfWxxW1gLnQ== 1-status: SRY-PR |
4a. propIDが有効で問題がなければ、サーバーは内容とproposal/propIDヘッダ を返却する。
HTTP/1.1 200 OK Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1 1-propID: Ed3Oorq/ZJbTpVaFRD4qfA== 1-proposal: http://coolcatalog.com/P3PProposal1.xml . . . Content-Type: text/html . . . |
4b. 何か他の問題（例えば、クライアントが要求されたデータを確かに送らなかった）がある場合、サーバーは、適切なSRYまたはERRコードを含むstatusヘッダとproposal/propIDヘッダを返却する。そのサーバーは、要求が遂行されなかった場合には、任意にHTTP 510エラーコードを返却するだろう。[ステップ３に戻って、もう一度やり直してください。しかし、クライアントは、クライアントの要求が数回失敗した後には、無限ループを避けるために、要求をあきらめなければならない。]
HTTP/1.1 510 Not Extended Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1 1-propID: Ed3Xorq/ZJbTpVaFRD4qfA== 1-status: SRY-DR 2-propID: Ed3Oorq/ZJbTpVaFRD4qfA== 2-proposal: http://coolcatalog.com/P3PProposal1.xml Opt: "http://www.w3.org/TR/WD-P3P/"; ns=2 3-propID: 9Pfx3KzqthhRfWxxW1gLnQ== 3-proposal: http://coolcatalog.com/P3PProposal2.xml . . . |
[time passes]
5. クライアントが、以前と同じリソースを要求する。その要求には、プロポーザルに同意する事を示すために、propIDヘッダが含まれる。
GET coolcatalog.com/index.html HTTP/1.1 Host: coolcatalog.com Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1 1-propID: "Ed3Oorq/ZJbTpVaFRD4qfA==" . . . |
6a. 同意がまだ有効で、サーバーが再度データを必要としない（もしくは、サーバーがP3P同意を要求しない）場合、サーバーは、単にproposal/propIDヘッダと一緒に内容（ステップ４にあるように）を返す。
HTTP/1.1 200 OK Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1 1-propID: Ed3Oorq/ZJbTpVaFRD4qfA== 1-proposal: http://coolcatalog.com/P3PProposal1.xml . . . Content-Type: text/html . . . |
6b. 同意はまだ有効だけれども、サーバーがデータを再び必要とする場合、サーバーは、status: SRY-DRヘッダと任意のHTTP 510エラー・コードを送ることによって、データを再送信させることを、クライアントに求める。[ステップ３へ続く]
HTTP/1.1 510 Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1 1-propID: Ed3Oorq/ZJbTpVaFRD4qfA== 1-proposal: http://coolcatalog.com/P3PProposal1.xml 1-status: SRY-DR . . . |
6c. 何か問題がある場合、サーバーは、適切なSRYまたはERRコードを伴うstatusヘッダ、proposal/propIDヘッダ、そして任意のHTTP 510エラーコードを返却する。[ステップ５に戻って、もう一度やり直してください。しかし、クライアントは、クライアントの要求が数回失敗した後には、無限ループを避けるために、要求をあきらめなければならない。]
HTTP/1.1 510 Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1 1-propID: Ed3Oorq/ZJbTpVaFRD4qfA== 1-status: ERR-IF 1-proposal: http://coolcatalog.com/P3PProposal1.xml . . . |
それぞれのプロトコル動作は、様々な理由でエラーを引き起こす。例えば、プロポーザルが奇形であったり、参照された同意が不明なものだったりです。error messageは、以下の拡張P3Pを使用して発行されます：
理由コードはstatus extention headers（ステータスエクステンションヘッダ）内で送られ、プロポーザルやデータの状態を表す（可能性として、以前の相互作用の状況内で）。P3Pエクステンションは、エラーを報告する場合、ステータスヘッダのみを含まなければならない。その他全ての場合（プロポーザルの内容やデータエクステンションの受け取りが成功している時）、ステータスヘッダを含んではならない。ステータスエクステンションを理解できないアプリケーションはP3Pメッセージを無視しなければならない。
| Reason Token（理由の標章） | Description（記述） | Sent by（送り主） | Explaination（説明） |
| SRY-AR | 同意（agreement）が要求（required）されている | server | もし以前の同意（propIDに一致する）が要求された場合に（propIDと共に）送信。クライアントは、プロポーザルを評価（クライアントは前もってプロポーザルをダウンロードする必要がある）し、利用者のプリファレンスに従って、（データと共に、またはデータなしに）サブミットしなおし、SRY(-PR)を送信、またはコミュニケーションを終了する。 |
| SRY-AU | 同意（agreement）が不明（unkown） | server | クライアントが、要求と共に不明なpropIDを送信した場合に送信。同意を必要とする新規のプロポーザルが可能な場合、サイトはSRY-AR（上記にあるように）を送信しなければならない。"SRY-AR"が存在しない場合、クライアントは、propIDの参照なしで要求をサブミットしなおすことが出来る。 |
| SRY-DR | データ（data）が要求（required）されている | server | クライアントがagreement（一致するpropIDによって参照された）に同意したが、適切なデータを送信しなかった時に送信。クライアントがリソースにアクセスしたい場合、クライアントは要求されたデータ（プロポーザルに応じた）を含む同じリクエストをサブミットしなおす必要があるだろう。 |
| SRY-DU | データ（data）が利用できない（unavailable） | client | データが利用できないので、クライアントが要求されたデータを提供出来なかった時に送信。 |
| SRY-PR | プロポーザル（proposal）が拒否（rejected）された | client | プロポーザルが受け入れられない時に送信。サーバーはこれについてログを取り、任意にクライアントに送り返したり、異なったページ/プロポーザルを申し出ることができる。 |
| SRY | sorry | server または client | 文法的に正しいにもかかわらず、プロポーザルまたはデータエクステンションの内容の受け取りに失敗、そして他の全てのSRY-コードが利用できない、またはプライバシに関する理由（後に説明）の場合に送信。 |
| ERR-IF | 不適切（invalid）なフォーマット（format） | server または client | 受け取ったP3Pメッセージが文法的に不適切、または意味が通じない。 |
| ERR-TF | データの転送（transfer）が失敗（failed）した | server または client | 文法的に正しく、有効な同意にカバーされている転送要求を受け取ったが、何かの理由でデータを保存することができなかった。 |
| ERR | error | server または client | 要求が理解されない、または正しく受け取られなかった。このコードはその他全てのERR-コードが当てはまらない時、またはプライバシに関する理由（後に説明）により送られる。 |
注意：もしプライバシーの理由でクライアントがプロポーザルを拒否する理由を漏らしたくない時、クライアントは特定の“SRY- ”コードではなく一般的な“SRY"コードをリプライすることが出来る。可能であれば何時でもERR-IF と ERR-TFコードが使用されることを推奨するが、エラーコードも同様に特定の“ERR- ”コードではなく一般的な“ERR"コードを使うことが出来る。
サーバーは最低でもSRY-ARとERRを送らなければならない。クライアントは最低でもサーバーから送られてくる三つの特定のSRY-エラーコードを理解しなければならない。言い換えると、クライアントは、（利用者が望む場合）プロポーザルを受け入れ（propIDを送ることによって）、必要であれば（利用者の判断で）データを送信することが可能でなければならない。SRY-AUの場合、クライアントは、リクエストを（期限切れまたは不明である）propIDの参照なしにサブミットしなおすことが可能でなければならない。
最後に、エラー・ステータスを特定するために、複数の理由コードを使用することが可能であることを覚えといてください：例えば、クライアントが、サーバーが提案したプロポーザルへのレスポンスとして、SRY-DUを要求したデータが利用できないことを示すために、そしてERR-IFをプロポーザルの一部が文法的に間違っていることを示すために返却することができるだろう：
HTTP/1.1 200 OK
Opt: "http://www.w3.org/TR/WD-P3P/"; ns=14
14-status: SRY-DU
14-status: ERR-IF
14-propID: 94df1293c1p8
14-proposal: http://www.privacy.org/newP3PProposal
...
[Content]
制限されたP3Pプロトコルは、HTTPヘッダ拡張メカニズムを使用しないで実行されるだろう。代わりに、サーバーは適切なP3Pプロポーザルの場所を示すLINKタグを埋め込んだHTMLコンテンツを提供するだろう。このプロトコル制限は、P3Pを理解するクライアントを必要とするが、P3Pを理解するサーバーは必要としない（コンテンツは、サーバーの動作方法を変えることなく、埋め込まれたlinkタグを含むために修正されるだろう）。
limited protocolを使用しているサービスは、HTMLドキュメントの<HEAD>エリア内に、以下のフォームのLINKタグを埋め込むことによって、与えられたP3Pプロポーザルに従うことを宣言するだろう：
<LINK rel="p3p:propID" href="URI">
URI はP3Pプロポーザルの場所を示し、"p3p:propID"は、この特別なP3P linkとプロポーザルのpropIDの記号化を区別するために使用される関連名です。例えば、 http://www.privacy.org/P3PProposalにあるプロポーザルが、propIDx3tYwafhfKSqGV0Q+eSOZw==を持っているとすると、次のようになる：
<LINK rel="p3p:md5:x3tYwafhfKSqGV0Q+eSOZw==" href="http://www.privacy.org/P3PProposal">
P3P準拠のクライアントは、propIDとproposalヘッダを含まないHTMLコンテンツを返却する要求をした場合は必ず、LINKタグを捜さなければならない。加えて、P3P準拠のクライアントは、いつでもHTMLコンテンツ内に埋め込まれているLINKタグを捜すだろう。クライアントが、同じドキュメント内にP3P LINKタグに加えて、propIDとproposalヘッダを見つけた場合、クライアントは、それらを複数の代替プロポーザル参照とみなすべきである。
limited protocolは、データ収集の為にP3Pの方法を使用することを望んでいたり、プロポーザルの選択を申し出ること、プロポーザルへの明白な同意を求めることを望んでいるサービスには適していない。
以下は、どのような相互作用がP3P準拠のクライアントと非P3P準拠のサーバー間で、典型的に進められるかの例です。クライアントとサーバーのアクション例は、影つきの部分に示されています。
1. クライアントが、GETやPOST、または他の要求を満たす方法を使用して、リソースを要求。また、クライアントは、P3Pが利用可能であることを示すために、P3P拡張ヘッダを送信。
GET coolstore.com/index.html HTTP/1.1 Host: coolstore.com Opt: "http://www.w3.org/TR/WD-P3P/" |
2. サーバーは、P3P利用不可能なので、P3P拡張ヘッダ（それが必須の拡張と、（または）サーバーは拡張利用が不可能な場合以外、サーバーは、P3P利用不可能であることを、クライアントに報告する）を無視し、要求されたコンテンツを送る。
3. クライアントは、属性rel="p3p:propID"と共に埋め込まれたlinkタグを、返却されたコンテンツから調べる。もしそのようなlinkタグが無く、クライアントが既に同意したレルム内に、要求されたリソースが無い場合、クライアントは、P3Pプロポーザルが利用できないと判断し、それに応じた行動をとることが出来る。linkタグが有る場合、クライアントは、linkタグのhref属性によって示されているURIへのGET要求を発行する事によってプロポーザルを取得し、評価し、それに応じた行動をするだろう。
注意：プロポーザルを評価した後の適切な行動と、（または）プロポーザルが存在しないと決定する全てのケースは、利用者のプリファレンスと、どのようにクライアントが設定されているかによる。クライアントは、要求、情報表示、利用者への問いかけ、またはその他の行動をとることを続けるだろう。
このセクションではユーザーエージェントとサービス間で転送された利用者データのブロックと同様に、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ページのために以下のステートメントを作成。Webフォーム経由で、cookieを使用し、入り口のページのカスタマイズと製品の研究と向上のために、性別と（任意に）実家の住所を収集する。この情報は、確認可能なフォームのためには使用しない。
我々はまた、どのページが訪れられたかや、利用者のWebブラウザのタイプについての情報を含んだログをサーバーに保持する。この情報は、我々のWebサイトの保持、向上のために使用される。我々は、この情報を利用者情報が確認可能な手段に使用しない。
我々は、利用者から得た情報に対してのアクセス権を与えない、しかし我々は情報を確実に保持し、そしてプライバシーポリシーに関するページ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
Assurance: PrivacySeal.org
Other disclosures: Change agreement, retentionWe collect:
dynamic.cookies
user.gender
user.home. (optional)
For purpose: Customization of the site to individuals, research and development
Identifiable use: No
Recipients: Only ourselves and our agents
Consequence: A site with clothes you would appreciateWe collect:
dynamic.clickstream.server
dynamic.http.useragent
For purpose: Web site and system administration, research and development
Identifiable use: No
Recipients: Only ourselves and our agents
以下の[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="none" retention="yes" change_agreement="yes"/> <USES> <STATEMENT VOC:id="nonid"> <CONSQ v="a site with clothes you would appreciate"/>
<VOC:RECPNT v="ours"/>
<VOC:PURPOSE v="uniqueid"/>
<VOC:PURPOSE v="financial"/> <DATA:REF name="dynamic.cookies" source="service"/> <DATA:REF name="user.gender" source="matched-form"/> <DATA:REF name="user.home." optional="yes" source="matched-form"/> </STATEMENT> </USES> <USES> <STATEMENT VOC:id="nonid">
<VOC:RECPNT v="ours"/>
<VOC:PURPOSE v="admin"/>
<VOC:PURPOSE v="develop"/> <DATA:REF name="dynamic.clickstream.server" source="service"/> <DATA:REF name="dynamic.http.useragent" source="service"/> </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"` " entity=" quoted-URI ">" 1*statement-block disclosure [assurance] 1*realm `</PROP>` |
| [3] | realm |
= |
"<REALM" " uri=" quoted-URI "/>" |
同意の範囲を設定したREALMにより特定されたURI（"realm"）。この情報はユーザーエージェントにより使用される。例えば、サービスに既存の同意があるかどうか等。各々のレルムURIsはサーバーのドメインと一致しなければならない（"domain-match" [STATE]）。
個々のURIは特定のリソースや、URIによって限定されたリソースの組を指定するだろう。HTTP URIスキーマにおいて、"/"で終わるURIは、path配下のファイル・システム・ツリーを参照する。（例えば、"http://www.w3.org/P3P/"は"http://www.w3.org/P3P/foo/schema.html"を同様に用いるだろう）一方で、"/"で終わっていないURIは、特定のリソースだけに適応される。（例えば、"http://www.w3.org/P3P/data.html"は、"http://www.w3.org/P3P/foo/schema.html"に適応されないだろう）
ユーザーエージェントは、どの同意が同意に至ったか、またそれに対応する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 [5] are provided for reference only. The normative specification is in the harmonized vocabulary [HARMV] document. | |||
| [4] | disclosure |
= |
"<VOC:DISCLOSURE" " discuri=" quoted-URI " access=" `"` access-disclosure `"` [" retention=" `"` yesno `"`] |
| [5] | access-disclosure |
= |
"nonident" | ; Identifiable Data is Not Used "contact" | ; Identifiable Contact Information "other" | ; Other Identifiable Information |
| [6] | yesno |
= |
"yes" | "no" |
| [7] | assurance |
= |
"<ASSURANCE" " service=" quoted-URI [" text=" quoted-string] [" image=" quoted-URI [" width=" `"` number `"`] [" height=" `"` number `"`] [" alt=" quoted-string] "/>" |
注意：ASSURANCEの複数の発生により指定される複数のassurance serviceが存在することが出来る。
Webサイトが、P3Pプロポーザルへのリンクをはっている場合、WebサイトはHTTPリクエストのヘッダ内に、プロポーザルをWebサイトに参照する要求を送るユーザエージェントのためのプロポーザルを喜んで守るということを掲げている。
Webサイトが、複数のP3Pプロポーザルへのリンクをはっている場合、Webサイトは、ユーザエージェントが複数のプロポーザルから選択したP3Pプロポーザルによってのみ拘束されていることを意味する。ユーザエージェントは、ヘッダ内にプロポーザルへの参照を送信する事によって、特定のP3Pプロポーザルを選択したことを知らせる。
たとえWebサイトが、P3Pプロポーザルを一つしか持っていなくても、ユーザエージェントが要求ヘッダ内にP3Pプロポーザルを参照しないならば、Webサイトは、何れのP3Pプロポーザルにも拘束されない。そのため、P3Pをサポートしていないユーザエージェントは、Webサイトと、いかなる特定のP3Pプロポーザルを結び付けない。さらに、最初のユーザエージェントからWebサイトへのリクエストは、ユーザエージェントは多分、リクエストのヘッダ内の参照するP3Pプロポーザルが何であるか分かっていないので、いかなるP3Pプロポーザルによってもカバーされない。
Webサーバ上のP3PをサポートしていないWebサイトは、複数のプロポーザルへのリンクは避けるべきである、なぜなら多分Webサイトは、どのプロポーザルをユーザエージェントが選択したか判別する方法を知らないからです。このアドバイスにもかかわらず、Webサイトが複数のプロポーザルにリンクをはっている場合、Webサイトは、Webサイト上にどんな困難さが設置してあるにもかかわらず、ユーザエージェントが選択したプロポーザルを、どうにかして守るために拘束される。
クライアントはヘッダ内のXML/RDFメッセージを伝えることにより、特定の同意を参照したデータをサービス(Section 3.3.2を参照)に送る。
| [8] | TXD-msg |
= |
(`<RDF:RDF>` 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" |
| The values of [11-13] are provided for reference only. The normative specification is in the harmonized vocabulary [HARMV] document. | |||
| [11] | purposevalue |
= |
"current" | ; Completion and Support of Current Activity（現在の活動の終了と支持）
"admin" | ; Web Site and System Administration（サイトとシステム管理者）
"custom" | ; Customization of the Site to Individuals（個人のためのサイトのカスタマイゼーション）
"develop" | ; Research and Development（研究開発）
"contact" | ; Contacting Visitors for Marketing of Services or Products（サービスや製品のマーケティングのために利用者とコンタクトを取る）
"other" [" (" string ")"] ; Other Uses（その他の使用）
|
| [12] | recipientvalue |
= |
"ours" | ; only ourselves and our agents（我々とエージェントのみ） "same" | ; organizations following our practices（我々のプラクティスに従う団体/組織） "other" | ; organizations following different practices（その他のプラクティスに従う団体/組織） "published" ; unrelated third parties or public forum（関係の無い第三機関や公共のフォーラム） |
| [13] | idvalue |
= |
"nonid" | ; non identifiable |
複数の結果は、複数のCONSQエレメント（一つの結果を伴っている）を使用して示すことができる。このようにして、多国後バージョンの結果は、xml:lang属性を使用して記号化することができる。
| [14] | consequence |
= |
"<CONSQ v=" quoted-string [xml:lang= LanguageID ] "/>" |
xml:lang と、そのLanguageID の値のタイプは、[XML] specification内に定義してある。 |
|||
複数の値（value）は、multiple PURPOSE elementsを使用する事によって表すことが出来る。個々のエレメントは一つの値を伴う。
| [15] | purpose |
= |
"<VOC:PURPOSE v=" `"` purposevalue `"` "/>" |
| The values of [16] are provided for reference only. The normative specification is in the harmonized vocabulary [HARMV] document. | |||
| [16] | purposevalue |
= |
"current" | ; Completion and Support of Current Activity（現在の活動の終了と支持）
"admin" | ; Web Site and System Administration（サイトとシステム管理者）
"custom" | ; Customization of the Site to Individuals（個人のためのサイトのカスタマイゼーション）
"develop" | ; Research and Development（研究開発）
"contact" | ; Contacting Visitors for Marketing of Services or Products（サービスや製品のマーケティングのために利用者とコンタクトを取る）
"other" [" (" string ")"] ; Other Uses（その他の使用）
|
複数の値（value）は、multiple RECPNT elementsを使用する事によって表すことが出来る。個々のエレメントは一つの値を伴う。
| [16] | recipient |
= |
"<VOC:RECPNT v=" `"` recipientvalue `"` "/>" |
| The values of [17] are provided for reference only. The normative specification is in the harmonized vocabulary [HARMV] document. | |||
| [17] | recipientvalue |
= |
"ours" | ; only ourselves and our agents（我々とエージェントのみ） "same" | ; organizations following our practices（我々のプラクティスに従う団体/組織） "other" | ; organizations following different practices（その他のプラクティスに従う団体/組織） "published" ; unrelated third parties or public forum（関係の無い第三機関や公共のフォーラム） |
以下の6つの属性は、新規のデータエレメントやセット(P3P1.0 ベース [BASEDATA]には定義されていない) が参照された時のみに使用される。
加えて、REFのnamespaceは、例えば、nameが属する場所で指定されたデータスキーマ、データエレメント/セットの名前を意味するURIを持った一列のxmlns属性を使用することで、オーバーライドが可能です。規定のDATA namespaceはPROPエレメントの中で宣言される。しかし、それはDATA:REFエレメント内でのローカルなnamespace宣言を使用し、オーバーライドされることが可能です。
| [18] | data-reference |
= |
"<DATA:REF" " name=" quoted-string " source=" `"` sourcevalue `"` [" optional=" yesno] [" value=" quoted-string] [" type=" quoted-string] [" typeschema=" quoted-string] [" template=" yesno] [" VOC:category=" category] [" short=" quoted-string] [" long=" quoted-string] [" size=" `"` number `"`] ; default is 0 (unlimited size) "/>" |
| [19] | sourcevalue |
= |
"service" | "agent" | "matched-form" | "extension" |
例：利用者の実家の町、User.Business.のデータセットの全てのエレメントと（任意に）User.Home.Telecom.Phoneのデータセットの全てのエレメントを要求し一致したフォームを参照することにより情報を収集。；サービスはP3Pプロポーザル内で以下の内容を送信する。
<DATA:REF name="user.home.city" source="matched-form"/>
<DATA:REF name="user.home.phone." optional="yes"
source="matched-form"/>
<DATA:REF name="user.business." source="matched-form"/>
利用者が町、ビジネス情報、国際電話番号と市外局番のみを返信することに同意した場合、txdタグ内において、以下の物を返信する。
<DATA:REF name="user.home.city" value="Cambridge"/>
<DATA:REF name="user.home.phone.intcode" value="1"/>
<DATA:REF name="user.home.phone.loccode" value="617"/>
<DATA:REF name="user.business.street" value="254 Windsor
St."/>
<DATA:REF name="user.business.city" value="Cambridge"/>
... (the other values of user.business.) ...
あるケースにおいて、データセット内の幾つかの値のみが値を持っている。（例えば、利用者がホームページ、Fax、ミドルネーム等を持っていない）言い換えると、幾つかのエレメントは、利用者のレポジトリ内に定義された値を持っていない。そのような場合、エレメントはヌル値を持っていると言える。クライアントが、エレメントがヌル値を持っていることを示す方法は、単に一致するDATA:REF参照を省略すれば良い。例えば、クライアントが全ての利用者名に関する情報（user.name.）を提供することに同意した場合、以下のものを送信する：
<DATA:REF name="user.name.first." value="Sheila"/>
<DATA:REF name="user.name.last" value="Doherty"/>
<DATA:REF name="user.name.formatted" value="Sheila Doherty"/>
この場合、多の全てのフィールド（prefix, suffix, middle name, nickname）は利用者のレポジトリ内に定義されていないことを意味する。
source属性は、ユーザーエージェントからサービスへのデータ転送のためのメカニズムを明記します。我々は3つのスタンダードメカニズムと、将来的に、規定される拡張可能な新規データ転送メカニズムを定義する。スタンダードメカニズムは以下のようなものである：
<REF> エレメントは、データ・スキーマ定義内に存在する時以外は、常に一つの値を持ったソース属性を含まなければならない。この場合、属性は完全に省かれるか、値を一つ、または複数取るだろう。（値を取る場合、同じデータを参照しているが、異なるソースを持つ複数の<REF>エレメントから取得される）
Category は、データエレメントの属性であり、ユーザとユーザエージェントにデータの意図した使い方のヒントを与える。Categoryは、P3Pユーザエージェントの実施や使用を簡単にするために必要である。これにより、ユーザがデータの交換においてより一般的なプリファレンスやルールを表現することができる。Categoryは、新しいエレメントを定義したり、利用者に記入するように問いかけたデータを参照したりする時にしばしば含まれる。（利用者のデータ・レポジトリに保存してあるデータとは対照的に）
P3Pの現在のバージョンでは、以下のトークンがデータカテゴリを示すために使用されている：
| [20] | category |
= |
"physical" | ; Physical Contact Information（物理的なコンタクト情報） "online" | ; Online Contact Information（オンラインのコンタクト情報） "uniqueid" | ; Unique Identifiers（ユニークな識別子） "financial" | ; Financial Account Identifiers（金融機関のID番号） "computer" | ; Computer Information（コンピュータ情報） "navigation" | ; Navigation and Click-stream Data（ナビゲーションとクリックストリームのデータ） "interactive" | ; Interactive Data（インタラクティブデータ） "pref" | ; Preference Data（嗜好データ） "demograph" | ; Demographic and SocioEconomic Data（人口統計学的・社会経済学的データ） "content" ; Content（文章の内容） |
我々は、参照目的のカテゴリ属性を指定している。規範的な定義と値、個々のcategoryに関する詳しい説明は P3P Harmonized Vocabulary Specification[HARMV]を参照して下さい。
P3Pは、利用者とユーザエージェントに、サービスから、どんなタイプの情報が要求されたかを知る追加的なヒントを与えるために、categoriesを使用する。大部分の基本データセットのデータは、既に知られているカテゴリ（または知られているカテゴリの組）内にあると同時に、幾つかのデータエレメントは、状況によって幾つかの異なるカテゴリ内にあることが出来る。最初の分は、fixed-category data elements（不変カテゴリ・データ・エレメント）（また短く"fixed data elements"（不変データエレメント））と呼ばれ、2番目は、variable-category dataelements（可変カテゴリデータエレメント）（"variable data elements"（可変データエレメント））と呼ばれる。以下の二つの章で、これらのエレメント・タイプについて簡単に説明する。
基本データセットの大部分のエレメントは"固定"（fixed）データエレメントと呼ばれる：それらのエレメントは、一つ、または二つまでのカテゴリ・クラスに属する。基本データセットのエレメントを不変にカテゴリに割り当てることによって、サービスと利用者は、簡単に一致するカテゴリを参照する事によって、全体のグループを参照することが可能である。例えば、APPEL（privacy preferences exchange language）を使うことによって、利用者は、特定のカテゴリのデータエレメントを、ユーザエージェントが配布することを防ぐ規則を書くことが出来る。
固定データエレメントのために、新規のデータスキーマを作成（参照： "Creating New Data Sets（新規データセットの作成）"）する時、スキーマの作成者は、エレメントが属するカテゴリを明白に列挙しなければならない。例えば：
<DATA:REF name="postal.street.line1" type="text"
short="Street Address, Line 1" VOC:category="physical" template="yes"/>
複数のカテゴリの場合、同じデータを参照している複数のエレメントを使用することが出来る。（個々のエレメントは、異なるカテゴリに属す）例えば、User.Name.のデータ・エレメントに"physical"と"demograph"と言うカテゴリを持たせたい場合、以下のように使用することが出来る：
<DATA:REF name="user.name." type="personname."
short="User's Name" VOC:category="physical" template="yes" /><DATA:REF name="user.name." type="personname."
short="User's Name" VOC:category="demograph" template="yes" />
固定のデータエレメントのカテゴリクラスをオーバーライドすることは出来ない。例えば、固定の基本データエレメントに対して、異なるカテゴリを割り当てるような規則、またはプロポーザルを書くことによって。ユーザエージェントは、そのようなカテゴリを無視しなければならず、代わりにスキーマ定義内にリストされているオリジナルのカテゴリ（またはカテゴリの組）を使用する。ユーザエージェントは利用者に対して、固定のデータエレメントが、非標準的なカテゴリクラスと一緒に使用されていることを、警告することが出来る。
基本データセットの全てのデータエレメントが、すでに決定されているカテゴリクラスに属するわけではない。幾つかのエレメントは、特定の状況において、幾つかのカテゴリからの情報を含むことが出来る。そのようなエレメントは、variable-category data elements（または短く"variable data element"）と呼ばれる。P3P基本データセットの大部分の可変データエレメントは、dynamic.エレメントセットと結び付けられているが、それらの可変データエレメントは、どのデータセット内（fixed-category data elementsと混ざってもいても）にあっても良い。
そのようなエレメントのスキーマ定義を作成する時、スキーマの作成者は明白に述べられたカテゴリ属性をリストしてはならない。もしそうでなければ、エレメントは、固定（fixed）データエレメントになる。例えば、状況（例えば、クレジットカードの有効期限の日付に使用 VS. 誕生日の日付に使用）に応じて幾つかのカテゴリを取ることが出来る、"Year"データタイプを指定する時、以下のスキーマ定義が使用される：
<DATA:REF name="date.year" type="number" size="6"
short="Year" template="yes"/> <!-- Variable Data Element -->
これは、そのような可変カテゴリデータタイプを参照する新規拡張スキーマが、新規スキーマの使用法に応じて、エレメントを引き出すための特定のカテゴリを割り当てることを許可する。例えば、拡張E-commerceスキーマは、以下のようにクレジットカードの有効期限を以下のように定義することが出来る：
<DATA:REF name="Card.ExpDate." type="date."
short="Card Expiration Date" VOC:category="financial" template="yes"/>
それらの状況下において、可変データタイプのdate.は、クレジットカードの有効期限を指定するために使われているので、固定カテゴリのFinancial Account Identifiersとして割り当てられた。より詳しい情報は、次章"Creating New Data Sets（新規データセットの作成）"を見てください。
利用者のプリファレンスは、そのような可変データエレメントを、追加のカテゴリ情報（このエレメントのいかなる使用法を通して、有効に表現されたプリファレンス）なしでリストすることが出来るので、サービスは常に特定のプロポーザル内に、可変データエレメントの使用法を適用するカテゴリを明白に指定しなければならない。この情報は、属性として、プロポーザルにリストされている一致するDATA:REFエレメントになければならない。例えば：
<P3P:PROP>
...
<DATA:REF name="dynamic.cookies" VOC:category="uniqueid">
...
</P3P:PROP>
サービスは、このサイトでcookieが利用者を特定するために使用されることを宣言する。（例：カテゴリUnique Identifiers）
サービスはデータスキーマを作成することにより新規データエレメントを宣言/使用でき、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の場合、空の文字列はタイプスキーマが、対応するREFエレメントのnamespaceに一致しているという特別な意味を持つ。
例えば、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:id="nonid">
<VOC:RECPNT v="ours"/> <VOC:PURPOSE v="contact"/> <DATA:REF name="car.model" type="text" short="Model" VOC:category="pref" size="63"/> <DATA:REF name="car.color" type="text" short="Color" VOC:category="pref" size="63"/> <DATA:REF name="car.built.year" type="number" short="Construction Year" VOC:category="pref" size="63"/> <DATA:REF name="car.built.where." type="postal." short="Construction Place" VOC:category="pref" size="63"/> <DATA:REF name="bike." type="car." typeschema="http://www.HyperSpeed.com/models-schema"/> </USES></STATEMENT></PROP>
注意：データセットが作られる度に、必然的にデータセットはタイプ（上記のcar.のように）として使用される。しかし、何らかの状況で、利用者のレポジトリ内で特定のエレメントを作成すること無しに、タイプを定義したいと望むだろう。これは、<DATA:REF>内でtemplate属性を使用することにより成し遂げられることが出来る。値を"yes"、template="yes" (規定値は "no")に設定すると、一致するデータエレメントはタイプの定義の一部のみである事を意味する。そして、それは実際には提携された値のデータエレメントを示していない。例えば、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:id="nonid">
<VOC:RECPNT v="ours"/> <VOC:PURPOSE v="contact"/> <DATA:REF name="GenericModel.model" type="text" short="Model" template="yes" VOC:category="7" size="63"/> <DATA:REF name="GenericModel.color" type="text" short="Color" template="yes" VOC:category="7" size="63"/> <DATA:REF name="GenericModel.built.year" type="number" short="Construction Year" template="yes" VOC:category="7" size="63"/> <DATA:REF name="GenericModel.built.where." type="postal." short="Construction Place" template="yes" 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="service" や、利用者のレポジトリにデータを保存しない拡張機構の使用)に制限を設けない限り、ユーザーエージェントは利用者が新規スキーマのエレメントを書きこんだ後に、自動的にレポジトリにそれらのエレメントを保存する事を理解していなければならない。いくつかの実装はセンシティブなデータの保存に対しての適切なセキュリティーを設けていない利用者レポジトリを持っているものもある。
データスキーマファイルの多国語サポートを提供する為に、サーバーは、HTTPヘッダのAccept-Languageを元に、正しい選択肢を供給することができる。
P3Pは、利用者名と住所などの頻繁に要求される情報をクライアント側のレポジトリ内に保存することを許す。P3P基本データセット[BASEDATA]（拡張スキーマの多くも同様に）の多くのデータは、多分レポジトリに保存されるが、P3Pはまた、レポジトリに保存されないデータ（non-repository data）もサポートする。そのようなデータは、けしてレポジトリには保存されず、毎回エレメントが要求されたときに利用者が手で打ち込まなければならない情報か、クリックストリーム情報やブラウザを特定する文字列のようなユーザエージェントまたはオペレーティングシステムによってダイナミックに生成された情報を構成するデータです。
新規のスキーマ定義を作成する時、スキーマの設計者は、利用者のレポジトリ内に一致するフィールドを設けることを、ユーザエージェントが試みなければならないということを（従って、情報の繰り返された転送を促進する）指定することが出来る。もしくは、スキーマの設計者は、エレメントが動的で、レポジトリ内に含まれるべきではない、ということを指定することが出来る。以下のサブセクションでは、それら二つのより詳しいコンセプトを説明している。
スキーマ定義内のいかなるエレメントは、利用者レポジトリの一部として仮定される。従って、（固定）レポジトリエレメントのスタンダードなスキーマ定義は、以下のようになる：
<DATA:REF name="personname.first" type="text"
short="First Name" VOC:category="physical" template="yes"/>
しかし、エレメントは利用者レポジトリの一部だけれども、レポジトリ内の利用可能なデータを無視して、P3Pプロポーザルが利用者に手動でエレメントを入力させることを明白に指定することが出来るだろう。（例えば、HTMLフォームを通して）
<P3P:PROP>
...
<DATA:REF name="user.name.first" source="service">
...
</P3P:PROP>
もちろん、アプリケーションは、Webサイトがレポジトリデータを要求していなかったにもかかわらず、レポジトリを元にした自動入力機能を提供することが出来る。また、新規のレポジトリに保存されているデータスキーマに遭遇した時、どんな行動をとるかを決定するのは、ユーザエージェントの実装方法によることを注意してください。例えば、利用者のレポジトリ（空の値を伴って）にエレメントを自動的に追加することが出来る実装だったり、利用者に、どうするかを決めてもらうために問いかけを行う実装です。
以前に説明したように、データスキーマ定義内の属性値のセットは、オーバーライドされることは出来ない。従って、常に確かなデータエレメントを利用者レポジトリの外に置くためには、スキーマの設計者は単に、source属性をserviceに設定しなければならない：
<DATA:REF name="dynamic.clickstream.client"
short="Click-stream collected on the client"
type="boolean" source="service"
VOC:category="navigation" template="yes"/>
上記の例は、Dynamic.Clickstream.Serverは、利用者レポジトリの一部にはなり得ないことを保証しますが、代わりに、手動で情報を収集（HTMLフォームを通して）または、コネクションの一部として、暗黙の内に送信される（クリックストリームデータの場合）。どちらの場合にせよ、P3Pユーザエージェントは利用者に、（利用者のプリファレンスによる）データエレメントと、その用語について知らせるだろうが、エージェントはデータの転送に関して、それ以上何もしない。
正式な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'
使用されているその他の記号法は:
以下の個人は、P3P Specification Working Groupに参加した人たちです。
[後で記入]
P3P Specification Working Group は、以前のP3P working groupsから大部分のスペックを受け継いでいる。 Working Groupは、以前のグループのメンバの貢献に感謝したい：
[後で記入]