このドキュメントは

Platform for Privacy Preferences (P3P1.0) Syntax Specification
W3C Working Draft 9-November-1998
http://www.w3.org/TR/1998/WD-P3P-19981109/syntax

の和訳です。赤色文字の部分は、1998-7-2版からの変更点です。

このドキュメントには和訳上の誤りがありえます。
内容の保証はいたしかねますので、必ずW3C Webサイトの正式版ドキュメントを参照して下さい。
また、著作権については本ドキュメントに含まれる記述に加え、こちらも必ず参照してください。

WD-P3P-19981109/syntax

Platform for Privacy Preferences (P3P1.0)
Syntax Specification

W3C Working Draft 9-November-1998

This Version: http://www.w3.org/TR/1998/WD-P3P-19981109/syntax
Latest Version:: http://www.w3.org/TR/WD-P3P/syntax
Previous Version:: http://www.w3.org/TR/1998/WD-P3P10-syntax-19980702/
Editors: Massimo Marchiori, W3C (massimo@w3.org); Dan Jaye, Engagetech (djaye@engagetech.com)

Status of This Document

このドキュメントはW3Cメンバと関連者向けのP3P1.0 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/).

Index

Introduction（はじめに）

Problem space
About this specification（この仕様書について）
Conformance requirements（準拠要求事項）
Operational description and design（オペレーションに関する記述と設計）
Terminology（専門用語）
Assumptions（仮定）

Agreement scenarios（同意のシナリオ）

No existing agreement, site sends proposal and requests PUID(同意は存在しない。サイトはプロポーザルを送りPUIDを要求する。)
Existing realm agreement(レルム同意が存在する。）
Existing realm agreement, new proposal(レルム同意が存在し、新しいプロポーザルが発生する。)
Service wants data from client repository(サービスがクライアントのレポジトリからデータを要求する。)

Transport, primitives and reason codes

Data transport
P3P requests
Negotiation primitives(交渉の原語）

Success (OK)
Here's A Proposal (PROP)
Sorry (SRY)
Transmit Data (TXD)
Ending negotiation with final
Syntax of negotiation primitives

Reason codes definition

Success コード
Rejection コード
Error コード

P3P markup and processing

Example proposal（プロポーザル例）

English language proposal（英語版プロポーザル）
XML/RDF encoding of プロポーザル

Proposals（プロポーザル）

Proposal structure: the PROP element（プロポーザル構造：PROP要素）:
Processing Realms and URI's
Soliciting user info: the source attribute（ユーザー情報の懇談：ソース属性）
Attesting to a proposal: the ASSURANCE element:（プロポーザルの証明：保証要素）

Statements

Privacy statements: the STATEMENT element
General disclosures: the VOC:DISCLOSURE element

Data References

Referencing data: the <DATA:REF> element
Prefixing references: the <WITH><DATA:PREFIX> elements
The VOC:category 属性
Client side writes: the action 属性
Unambiguous（明らかな） optional elements and purposes（明確なオプション要素と目的）
Creating new data sets

Data definition
Data schema format

Appendices（付録）

Appendix 1: References

Appendix 2: Fingerprints and Canonicalization

Appendix 3: Line-flow Scenario

Appendix 4: ABNF Notation

Appendix 5: Working Group Contributors

1. Introduction（はじめに）

P3P(The Platform for Privacy Preferences)は、Webサイトが自分たちのプライバシープラクティスを表現し、ユーザがそれらのプラクティスに対するプリファレンスを実行することを可能にする。 P3P準拠の製品は、ユーザが（マシンと人間の両方が解読できる書式で）サイトのプラクティスを知ること、適切ならばコンピュータに決定を委ねること、そして特定サイトに結びつけることを許す。ユーザのプリファレンスに適合したサイトのプラクティスは、ユーザの選択によりシームレスにアクセスすることができる。そうでない場合は、ユーザはサイトのプラクティスを通知され、それらに同意する機会を与えられてブラウジングを続けることができる。

P3Pは、ユーザがWeb上で十分に説明された決定を行う能力と、彼らの情報の使用を制御する能力を与える。サイトはP3Pを、サービス品質の向上・コンテンツのカスタマイズ・サイトアクセスの簡略化だけでなく、サービス内での信頼ユーザの場所のレベルを上げるために使うことができる。

P3Pは、構造化データの交換と宣言のために [XML]（とりわけ[RDF]）を使う。 P3Pは将来のデジタル認証とデジタル署名の能力もサポートする予定。 P3Pはブラウザ、プラグイン、サーバ、もしくはクライアントとサーバ間のプロキシサーバに組み込むことができる。

1.1 Problem Space

P3P Specは、以下のメカニズムを与える:

ユーザエージェントがサイトのデータ収集とプライバシープラクティスを通知されるメカニズム。
For a user agent and service to automatically negotiate and to come to an agreement satisfactory to both parties; alternatively, for the user agent to notify the user and take instruction concerning proposed data exchanges from the user.
ユーザエージェントとサービスが自動的に交渉し、双方にとって満足な合意に至るメカニズム。代案として、ユーザエージェントがユーザに通知して、ユーザから要求されたデータ交換に関する指示を受け取るメカニズム。

P3Pは、上記のProblem spaceを扱うためのメカニズムを提供している間、
いくつかの手段はすべての特定された操作と特徴をサポートしなければならない。 [see next section]

1.2 About This Specification（この仕様書について）

このドキュメント（各章、各規準参照）は、統一されたP3Pアプリケーションのインプリメントに必要な全ての仕様を含む。この仕様書は過去のワーキンググループの実績の上に築かれ、以下にあげるものを含んでいる。

プロトコルの原型
プロトコルのスキーマ（プロポーザルのプライバシープラクティス用語を含む）
プロトコルの文法と記号化（データの構造と書式を含む）

このドキュメントは、P3P仕様のメインとなる部分を含んでいます。プライバシーデスクロージャー用語の語議論の詳細（natural language）は、以下の章で見る事が出来ます。

http://www.w3.org/TR/1998/WD-P3P-19981109/vocab

基本データセットの文法とデータタイプの詳細は以下の章で見る事が出来ます。

http://www.w3.org/TR/1998/WD-P3P-19981109/basedata

注意：この用語の使用がP3P1.0の応諾を必要としている間、XMLの容易さ（namespaces [XML-name] ）は追加または補足的な用語を簡単に紹介できることを許可する。
文章のステータスを表現するために以下の規約を用いる。

ABNF表記法の中のスキーマ定義

簡易インプリメントメモ.

この仕様書で使われたABNF表記法は、RFC2234 で規定されている。

1.3 Conformance requirements（準拠要求事項）

このドキュメントはインターオペラビリティ（interoperability）、feature sets、意味に関するポリシー（policy related semantics）についての要求事項について説明します。インターオペラビリティの必要事項は、プロトコルは "shared"プロトコルステートマシンに従って動作すること、情報は任意に喪失されない、もしくは混同されないこと等です。このドキュメントで feature setsに関する必要事項をさらに説明する。というのは、プロトコルを壊さないfeature をインプリメントしない一方で、それは、どの機能がサポートされているかという相手又はユーザの期待を裏切ることになります。その上、このアプリケーションの重要なpolicy implicationの為、P3PはXML/RDFのための natural language semantics を含んでいます。例をあげると、インターオペラビリティの要求事項はすべてのパーティーにプロトコル原型とレスポンスをサポートすることです。
この要求事項を与えられ、エージェントはいつも“SORRY”を返す事が出来ます。しかし、このことは、全てのエージェントが単にsorryを返すように実行されている場合、合意に至ることができるというサービスの期待を裏切ることになる。この例を広げてみると、もしそのような事をするエージェントが存在しない場合、サービスは、マルチプルポリシーや交渉した決定事項を好んで実行しないだろう。いずれにしても、機能のサポート不足によりプロトコルインターオペラビリティーを裏切らない。

この広域なそれらの必要事項は不規則なものではあるが、P3Pがプロトコル以上の物であり、HTTPやXMLのような既存の標準アプリケーションであるので必要である。さらに、この文書では、まだ実装されていないまたは、仕様書の一部として作る必要のない機能、しかしP3Pユーザの経験の一部として重要と思われる機能についても予想して書かれている。

このため、conformance（準拠）は以下の３つのレベルに分けられ、各レベルは前のレベルに含まれる。

1.Level 1:インプリメンテーションは、他のレベルとインターオペラブルなプロトコルとなり、P3Pと"privacy notification "feature setの基本コンセプトを含む。
2.Level 2:　インプリメンテーションはデータ交換をサポートする。
3.Level 3:　インプリメンテーションはP3P cookie replacement mechanism、複数暗号化、伝達方法、拡張可能なdata set(external to the base)をサポートする。

あるレベルのインプリメンテーションは以前のレベルを含み、ここに列記した全ての機能・動作をサポートしなければならない。

Level 1: The Privacy Notifer: プライバシーフレンドリーなpratice notifer。たとえば、子供に適している。

セクション	機能/動作	説明
2.0 Agreement scenarios	propID	propIDは、どのようなプライバシープロポーザルも認識する。
3.1 Data transport	the HTML LINK tag	Agent及びサービスはこの場所にプロポーザルを設置する事ができる必要がある。
	the HTTP 拡張機能	Agent及びサービスはこの場所にプロポーザルを設置する事ができる必要がある。
	propURI	プロポーザルは、ある外部URIに位設置する事ができる必要がある。
4.1.2 XML/RDF encoding	XML 解析	プロポーザルとデータシンタックスは、速やかに処理されるか、ユーザに提出される。RDFデータモデルは、必要なgrammar/シンタックスを構成するために使用されるが、アプリケーションは、その必要を感じない場合は必ずしもRDFをサポートする必要はない。
4.4 Data References	data reference syntax	Agentは、送信を請求されている情報のシンタックスを理解できなければならない。
Base 3.0 Abstract Elements	abstract elements	P3P以外の方法で交換されたreferences dataの方法
Harmonized Vocab	harmonized vocabulary	必要条件については、harmonized vocabularyを参照。この必要条件を満たさなければならない。満たさない場合、インプリメンテーションがprivacy公開を適切なレベルでできなくなってしまう。

Level 2: Privacy and Information Agent: ユーザが受け入れ可能なpracticesを持つsiteとの関係を管理するのをアシストするためユーザのプロフィールとprivacy agreementを記憶することができるagent

2.0 Agreement scenarios	propID repository	完全なプロポーザルをコンパクトに表現する事ができ、すでに同意ができている場合は、新規の交渉や同意を必要としない。
	データリポジトリ	頻繁に要求されるユーザプロフィールはユーザがセーブ、管理する事ができる。
3.3 Negotiation primitives	protocol primitives (OK,SRY, PROP, TXD)	交渉、複数プロポーザル、counter プロポーザルが受けられる。
3.4 理由コード	S-?, R-?, E-?	同意に達する必要がある。もし理由コードが提供されない場合は、暗示のセマンティクスがある。結果として、このセマンティクスは必要となり、codeの存在は、任意となる。
	postCGI	CGIメソッド（P3P, HTML agent）が情報を返却する。

Level 3: Sophisticated P3P Agent: P3Pの全ての機能を実装するAgent

2 Agreement Scenarios	PUID/TUID	P3Pの管理下の効果的なanonymous clickstream tracking
3.1 データ転送	HTTP、postURIによる XML 暗号化データ	データは、ヘッダーや特定のURIにXMLデータとして返却される
4.4.1 データ定義	新規スキーマ・インスタンス生成	Base set以外のスキーマはagent によりインスタンス生成又はサポートされる。
4.2.4 source attribute	source attribute	Agentは複数の拡張可能な機能をサポートし、それにより情報は送信を請求される。
	client access DOM	?

注：以下のキーワードは文書全体を通じて使用され、レベル１のinteroperability 要求事項として読まれなければならない。このキーワードはRFC2119 [KEY] で定義される。以下にそのキーワードを示す。

MUST: これは、「必要とされる、しなければならない」という意味で、仕様書中、絶対的に守るべき事項に付加される。
SHOULD: この言葉は、「推奨される、した方がよい」という意味で、無視することができるある特定の状況が存在する場合もあるが、レベル１インプリケーションのために別の方法をとるまえに完全な意味を理解し、注意深く状況を判断すべきである。
MAY: この言葉は、「任意に選んで良い、してもよい」という意味で、選択する余地がある場合に用いられる。あるベンダーは、ある特定の市場はそれを必要としているから、或いは製品を向上させるからという理由で、そのアイテムを選んでもよい。例えば、別のベンダーは同じアイテムをレベル１インプリメンテーションで省略するかもしれない。

複数のMUSTの要求事項を満足しない場合は、そのインプリメンテーションはレベル１に準拠しない。

1.4 Operational Description and Design（オペレーションに関する記述と設計）

P3Pプロポーザルは、１つまたはそれ以上のステートメントから成り立っている。各々のステートメントは一連のデータエレメントに対するプライバシープラクティスを表現する。 P3Pプロポーザルはすべての関連したデータエレメントとプラクティスを含まなければならない。もしサービスがデータエレメントを集めたければ、プロポーザルの中で述べなければならない。 P3Pのほとんどの宣言文は断定的で、やらないことよりもむしろやることを述べることに注意。

P3P Specの中心コンセプトは、P3P同意のそれである。P3P同意はサービスとユーザエージェントの双方に同意されたプロポーザルである。ユーザエージェントはプロポーザルで規定されたプライバシープラクティスとユーザのプリファレンスを比較して、合意に入るかどうかを決定する。 1つの同意は特定のレルム内でユーザエージェントとサービス間で交換される全データに当てはまる。レルムは1つのURIで参照されるWeb資源かもしくは複数のURIで参照されるWeb資源である。

いったん同意に達すると、同意したプロポーザルに含まれるデータエレメント群はサービスからのデータ要求ユーザエージェントに解釈されるべきである。データエレメントを参照しない同意も可能である。そのような同意は"情報は集めない"と述べる。

プライバシープラクティスがユーザのプリファレンスと一致しない場合には、両サイドは代わりのプロポーザルを交換することで同意に到達することができる。あらゆるプロポーザルはユーザが見ることができる一連の"結果"を持つことができる。それは提案されたプラクティスが、たとえユーザが通常は同意しなくてもある特定の場合に大切であるかも知れないという理由を説明するものである。我々はユーザエージェントが、合意に達した同意を同意IDという同意のフィンガープリントで表示された形で記録することを期待する。

サイトは、接触のたびに新しいプロポーザルをユーザエージェントに送るのではなく、既存の同意IDを送っても良い。これは、 1)サービスとユーザエージェントが既に合意に達していることを示す、 2)どのプロポーザルとプライバシープラクティスがの下で動いているかを合図する、 3)同意で参照されているデータエレメントを要求する、という意味がある。ユーザエージェントは断っても良いし、要求されたデータで応じても良いし、あるいは該当同意の記録がないか新しく欲しければ、完全なプロポーザルを要求しても良い。

サイトはまた、プロポーザルの一部として、テンポラリIDあるいはペアワイズID（TUID／PUID）をユーザエージェントが戻った時に自動的にサイトに送るよう要求する能力がある。PUIDはクッキーに似ているがP3P制御下にあり、数値に限られている。

我々の設計ではアプリケーションは、複数のやり取り、プロポーザルの保存能力、ユーザエージェントやサーバ側のデータレポジトリの使い方、同意レポジトリのサイズに関する我々の仮定や期待とは独立したインプリメントが十分に可能である。

1.5 Terminology（専門用語）

Assuring Party(保証機関)

P3P内部において、保証機関は合法的な実体（個人または団体）であり、プロポーザルに関して保証を行うものである。保証はサービス、または第三機関からくるものです。保証機関は、プロポーザル内において、保証文の一部として、何を証明するか、特定されたURI、またはメタデータスキーマの意味を明らかにしなければならない。 Agreement(同意)

サービスとユーザーエージェント双方が同意したプロポーザル。この同意はレルム内におて使用され、しばしば同意ID として用いられる。このような同意性は、将来のP3Pにおける証明書や電子署名の将来性のサポートにより強固になります。 AgreementID(同意ID)

ある共通のプロポーザルに対してお互いのパーティーが同意に至った事を示す小さな単位情報。同意IDは、プロポーザルを受け入れた事に対するフィンガープリントです。P3Pヘッダー内の同意IDの存在は、与えられたレルムにとって同意が実施されていると言う決定的な宣言となります。 Data Element(データエレメント) 個々のデータ要素。例えば、名字、電話番号など。国際的利用のため、P3P1.0では、基本的なデータエレメントを指定しています。 Data Category(データカテゴリ)

データエレメント属性、またはTrust Engineがどんなエレメントタイプが審議中であるか決定するために使われるデータセット。例えば、"Contact Information."。 P3P1.0では、10個の基本データカテゴリーを指定しています。 Data Set(データセット)

グループ化されたデータエレメント。例えば、"User.Home.Postal."。データセットはピリオドの区切りにっよって表現されている。P3P1.0ではいくつかの基本データセットを指定しています。 Fingerprint(Hash, Digest)(フィンガープリント)

あるいくつかのデータをハッシュ関数にかけた結果として出来た固定サイズの値。フィンガープリントは簡単に計算できますが、ちょっとした変化を元の情報に加えても事実上予期できない値が結果として出来てきます。したがって、フィンガープリントは、しばしばテーブルやデータベースへ入るキーまたは情報の安全保障の手段として用いられます。我々は、[MD5]というアルゴリズムをP3Pフィンガープリント用に使用しています。これは、128-bitの値を生み出し、P3Pのコミュニケーションのなかでその値は、暗号化され交換されています。 Preference

ユーザーエージェントがどんな行動をするか、何時会話に入ることを許可するか、またはサービスとの交渉等に関する規則（規則集）。プリファレンスは形式の整った計算できる文で表現される。（例：APPEL プリファレンスは言語を交換する）この文書のなかで、プリファレンスはユーザーエージェントとサービス間に達するいろんな同意を管理します。 Proposal

プロポーザルは、いくつかのプライバシーステートメント（主張された身元、URI、保証等の情報）の集まりです。プロポーザルは常にサービスの観点から作り出されるもので、サービスにとっての情報の確認を含んでいます。しかし、プロポーザルは、ユーザーによって作り出され、サーバーに許可のために送られる事もあります。 PUID

PUID := hash(UUID(Realm, agreementID)). PUIDは、長期間、特定の同意のもとに、自分自身をサービスに対しユーザーであると分からせるためのオプション。直接、特殊なレルムと同意に相当する。また、Get 要求と一緒に ReturnID の一部として、P3Pヘッダー内で送られる。 Realm(レルム)

レルムは、与えられた同意が発行された元に要求したエクスペリエンススペースです。レルムはプロポーザルを適用した領域として、広い意味で定義されています。レルムは、いくつかのURIから参照されます。どの同意がURIで実施されているかの最終判断は、同意IDの存在によって決定されます。それぞれのURIは、URIによって限定された特殊なリソースを名前付けます。例えば、 HTTP スキーマの中で、オブジェクト（home.html）で終了しているURIは、特殊なオブジェクトを適用します。また、URIが path http://www.w3.org/P3P/ の場合、URIは、path 配下の system tree を参照します。もしプロポーザルに電子署名が無い場合、それぞれのURIはオリジナルのサーバーとドメインが同一でなければなりません。ドメインマッチングは、HTTP state management mechanism internet draft [STATE] に含まれています。 Repository

複数の個人情報をまとめて保存しておくファイルやデータベース。プリファレンスビューロは、この個人情報テーブルと同意ＩＤテーブルから構成されている。 ReturnID

agreementID

PUID

TUID

Service

プロポーザルを発行しデータを要求するプログラム。この定義では、サービスはサーバー（サイト）、ローカルアプリケーション、ローカルなアクティブコード（ActiveX や Java applet）または他のユーザーエージェントである。 Statement(ステートメント)

P3Pステートメントは、データエレメント、データセット、カテゴリの集まりに関連がある privacy practice disclosures の集まりです。列挙された要素は、埋め込まれたデータ要求のように動きます。データを参照しないステートメントは、データを要求しません。 TUID

TUID := hash(UUID(session salt))。セッションで使うためにサービスに返すための、ユーザエージェントで作られるテンポラリのIDである。新しいTUIDは、各サービスと各セッション毎に作られなければならない。もし、サービスが別のセッションにまたがって持続させたいならば、サービスはPUIDを要求すべきである。 URI

propURI：プロポーザルを発行するURI。
postURI：情報をどこに送るかを示すURI。
discURI：プロポーザルのプライバシーステートメントを自然言語で記述したURI。

User Agent

利用者が定義したプリファレンスをもとに、サービスと利用者間の仲介を行うことを目的としたプログラムである。利用者は１つ以上のユーザエージェントを持つかもしれない。また、利用者のディスクトップにある必要はない。しかし、どのエージェントも利用者だけが制御し、使えなければならない。利用者とそのユーザエージェント間との信頼関係は、P3Pの範囲外で管理されるものである。例えば、エージェントは利用者のＯＳまたはWebクライアントの一部、またはISPかプライバシーProxyの状況により信頼される。 UUID

UUID

1.6 Assumptions（仮定）

P3Pは、動作する環境と解決すべき問題についていくつかの仮定を行っている。

P3Pは、サービスがそれ自身の身元情報をプロポーザルに含むことを許す。登録したドメインのオーナーがサービス本体と一致しない場合もあるので、この情報は必ず提供されなければならない。
身元や同意に関する強い承認が、プロトコルの将来のバージョンで提供される。この際P3Pには、使用されるはっきりした／有力なPKIモデルは存在しない。将来的にはユーザとサービス両方が署名と認証を必要とするかも知れない。
我々は、通信のセキュリティがP3P自身以外の手段で達成されると仮定している。（参考：[SSL]）そのためP3Pでは、ディスクや通信中の暗号化による情報の保護については、そのメカニズムを提供していない。
P3P同意は、端末間のもの。つまりユーザーとサービス間のもの。回線プロバイダやインターネットプロバイダ、プロキシのような仲介者は、サービスとユーザ間のデータ交換に関係しているかも知れないが、プラクティスについては、同意に含まれていない。
P3Pが[HTTP1.1]を元にしたプロトコル拡張 [MANDA]を有効に利用することができる一方で、P3Pは [HTTP1.0]サーバ／プロキシで動作できなければならない。実際、XMLプロポーザルとデータはいかなる転送方法でも交換する事ができる。しかし、我々は、HTTPに現れたときにreturnIDから派生する機能を指定するだけである。(複数の目的を使用するときAgreementID、clickstream の為にPUIDとTUID)
P3Pは、HTTP経由で発生したり交換された全てのデータを扱う。[rethink]

2. Agreement Scenarios（同意のシナリオ）

以下のシナリオは、P3Pが使われる可能性のあるいくつかの場面を図解するために設計されている。各シナリオは、それぞれ異なるP3Pの特徴を強調している。シナリオ１はどのようにして基本的なP3P同意が確立されるかを示す。シナリオ２、３は既に同意に達しているサイトにユーザが戻った際に何が起きるかを示す。シナリオ４、５は同意を与えられたデータレポジトリの使用について強調している。

これらのシナリオは交渉が発生しない場合の相互作用を図解している。しかしどのシナリオもサイトが初めから複数のプロポーザルを行うシナリオに拡張されたり、サイトとユーザ間で一連のプロポーザルやカウンタープロポーザルが交わされるシナリオに拡張される可能性がある。 Appendix 1 のシナリオ拡張例は、交渉の一例を含んでいる。

以下の表は、各シナリオの特徴をまとめたもの。表中の"-"は、そのシナリオでは仮定されない(中立な) という意味を表す。

Scenario Existing Agreement New Proposal PUID Requested Data Requested Data Written

1 No Yes Yes - -

2 Yes No No - -

3 Yes Yes Yes - -

4 - - - Yes No

5 - - - Yes Yes

シナリオ1）同意は存在しない。サイトはプロポーザルを送りPUIDを要求する。

ユーザは、CoolCatalogのホームページ(CoolCatalog/*)に行く。彼女はそこに1度も行ったことがないが、そこはP3P準拠である。
CoolCatalogがプロポーザルを作る。そこにはプライバシープラクティス、情報開示、そしてそれらが当てはまるデータエレメントの情報が含まれている。この例では、サービスは自動的にReturnIDの一部として将来PUIDが与えられることを要求する。
ユーザはプロポーザルに合意し、プロポーザルに規定されたレルムに対する今後すべての要求上でReturnIDの中にPUIDを含めて送ることに合意する。

プロトコルシナリオ：クライアントはOPTヘッダー（[MANDA])参照）をサーバに送る。サーバがP3Pをサポートしていない場合は、内容のみを送り返す。（この内容とは、従来のCGIメソッドを使って情報をサーバに送るHTMLフォームになるだろう。）サーバがP3Pをサポートしていてかつ関連のプロポーザルを持っている場合は、サーバは409コードとP3Pクライアントに対するプロポーザルをHTMLヘッダーもしくはURI参照の形で返す。

シナリオ2）レルム同意が存在する。

ユーザは前にシナリオ1を終了している。
ユーザはCoolCatalogのページに戻り（既存の同意に従いながら）同意のレルム中のすべてのページ要求にReturnIDを与える。

プロトコルシナリオ：クライアントはサーバにOPTヘッダとすべての関連したReturnIDを送る。サーバは関連した内容を返し、それに続くP3Pデータ要求（同意ID付きTXD）を送ることができる。

シナリオ3）レルム同意が存在し、新しいプロポーザルが発生する。

ユーザは前にシナリオ1を完了している。
ユーザはCoolCatalogに戻りすべてのページ要求に同意(1)のReturnIDを与える。
ユーザはCoolCatalogの注文ページ（CoolCatalog/Order/*）に行き、同意(1)のReturnIDを送る。サービスは注文ページのポリシーがサイトの他のページと異なるため、新しいプロポーザルを作る。この場合、実際の注文情報を要求する。
ユーザは新しいプロポーザルを考慮する。2つの場合があり、それらは（ReturnIDの一部としての）新しいPUIDが要求されるかどうかで異なる。

Case1

新しいプロポーザルは新しいReturnIDの要求を含まない。プロポーザルは同意される。
注文ページへの将来の要求は（CoolCatalog/*）のプロポーザルのReturnIDだけを含む。

Case2

新しいプロポーザルは新しいReturnIDの要求を含む。このプロポーザルは同意される。
注文ページへの全ての将来の要求は（CoolCatalog/*）と（CoolCatalog/Order/*）のReturnIDの両方を含む。

シナリオ4）サービスがクライアントのレポジトリからデータを要求する。

シナリオ1、2のどちらかがクライアントの最初の要求に当てはまる。
データを要求するために、サービスは2つのオプションを持っている。

オプション1. 同意IDを送る。

クライアントがIDを知っている場合（このクライアントが入力した有効な同意を調べることで）、クライアントは要求されたデータをサーバに送り返す。（TXD）
クライアントがIDを知らない時（このサービスに関して同意したことがないか、単にログの空きが足りない場合）、クライアントはSRY(Sorry)コードと理由コードのR-1コード(承認されていない同意) を送る。サーバはそれから以下のオプション2にあるような完全なプロポーザルを送る。

オプション2. 完全なプロポーザルを送る。

クライアントはプロポーザルを検査し、ユーザのプリファレンスに合わせるかユーザに同意を促すかして、その後TXDを使ってデータを送り交渉するかもしくは交渉をやめる。

シナリオ5）クライアントが情報をサービスに書き込む。

これはシナリオ4の追加ステップで、サービスのプロポーザルに、クライアントのデータレポジトリに１つまたは複数のデータエレメントを書き込むことが含まれる。
この場合、ユーザが同意を１度受け入れたら、サービスは適切なデータエレメントを送る。それらは　ユーザエージェントによってユーザが意識することなく保存される。

プロトコルシナリオ：シナリオ5はシナリオ4の延長であり、 シナリオ4でユーザエージェントがサーバにOKと任意にTXD を送って終了したものと仮定している。今、サーバは自らのTXDと共に適切なデータエレメントをクライアントに送る。もし成功すれば、ユーザエージェントはOK/S-0理由コードで応答する。失敗した場合にはクライアントはSRY/E-0理由コードで応答する。

3. Transport, Primitives and Reason Codes

以下のセクションは、同意を形成したりその後のデータを転送するのに必要な原型を規定している。

3.1 Data Transport

P3Pは、原型とP3P HTTP拡張のヘッダの内容を交換するように設計されている。しかし、何らかのHTTPインプリメント（例えば巨大なグラフィック画像）において、PROPやTXD の原型がヘッダの予定した長さを越えてしまう場合が考えられる。よってRDF/XMLのアプリケーションとして、P3Pインプリメントは、 RDF/XML交換の方法が完全に規定されている時、その方法に従うことができなければならない。それらの方法とは、以下のものが考えられる。

HTTP拡張ヘッダ内。
クライアントまたはサーバがHTTP GETリクエストで得る特定のURI。
XMLまたはHTMLの中身の一部分として。HTMLであれば古いインプリメントで返されるべきではない。

P3P 1.0インプリメントは、上記1-3のそれぞれをサポートしなければならない。シナリオを使ってそれらを解説する。以下の表は各シナリオの特徴、propURI、postURIを使うかどうか、プロポーザルが内容に組み込まれているかどうかをまとめたもの。

Scenario	Proposal-URI	Post-URI	Proposal Embedded in Content
6	Yes	-	No
7	No	-	Yes
8	-	Yes	-

また、情報交換の方法については、source attribute の説明の（注）参照。

シナリオ6）サービスがURIでプロポーザルを参照する。

サービスは、中継プロキシのキャッシュが長いHTTPヘッダを切り取るかあるいは、サービスのプロポーザルがプロキシに保存されることを願っている。

ユーザはサービスにGETを送り、プロポーザルを要求する。
サービスは、propURIを含んだpropメッセージを送る。

<PROP agreeID="94df1293a3e5"

propURI="http://www.CoolCatalog.com/P3P.RDF" />

ユーザは、propURIにGETを送る。
propURIでサービスはプロポーザルを送る。

propURIはレルムの定義に関係ない。レルムに基づいて信用を決定する必要のあるインプリメントは、プロポーザルで定義されているレルムまたはシナリオ1で取って来た本来のURIについて、決定しなければならない。

シナリオ7）サービスがHTMLコンテント内のプロポーザルを参照する。

コンテンツプロバイダは、修正したHTTPヘッダなしで簡単なプライバシープラクティスを宣言したがるかも知れない。そのような場合、サイトはHTML HEADタグ内のP3Pプロポーザルに参照を埋め込んでもよい。これは、以下のようにHTML LINKタグを使用する事で実行できる。

<LINK rel="p3p-prop" href="URI" ?agreeID=""?>

ここで、URIはP3Pプロポーザルをさしており、P3P-propはこの特別なP3Pリンクを見分けるために使用される関連名である。

注）どのようなレルムに対してもただ１つのプロポーザルしか作成されない。重複したプロポーザルは認められない。

従って、

ユーザはサービスにGETを送り、オプションのヘッダーの存在を通してプロポーザルを要求する。
サービスは、ヘッダなしで内容を返す。
ユーザエージェントはP3P-propリレーションとのリンクを探すためにHTMLの内容のHEADタグを調べなければならない。
そのようなヘッダを発見すると、URIからプロポーザルを取ってくる。

注意：内容の中でプロポーザルを探さなければならないのでプロポーザルをとってくる待ち時間が大きくなる。しかし、そのようなプロポーザルはキャッシュされることができる。とにかく、この方式は、 1)P3Pデータ方式を使わない2)少数でシンプルで重複しないプロポーザルを持つサイトのみで使用されるべきである。

シナリオ8)クライアントがURIに情報をポストする。

サービスは大きなバイナリーファイルを要求するか、またはFORM/CGIのようにデータを処理することを好む。そしてPOSTを使用して提供された情報を求める。

ユーザはサービスにGETを送り、プロポーザルを要求する。
サービスはpostURIを含むプロポーザルを送る。
ユーザはRDF/XMLでエンコードされた情報をポストする。

postURIはレルムの暗黙の部分である。従ってたとえURIがレルムURIの中にないとしても、情報は同意IDの下で提供されたpostURIに送られる。

3.2 P3P Requests

ユーザエージェントは、"GET"、"POST"などの標準的なHTTP方式を使ったサーバと通信する。 P3Pはエージェントとサービス間でデータを転送するために命令拡張メカニズム[MANDA]を使う。サーバに最初の要求を設定する際、ユーザエージェントは自身がP3P準拠であることを知らせるためにp3p-opt-headerを含んで良い。もしユーザエージェントがOPTヘッダを送り、サーバがP3Pプロトコルをインプリメントする場合には、サーバは以下を必ず行わなければならない。

サーバがP3Pを理解することを示すOPTヘッダを送る。
サーバが問題のページを含むプロポーザルを持っている場合、それを送らなければならない。

[1]	`p3p-request`	`=`	`start-line` `message-header` `"OPT" ":" p3p-opt-header CRLF` `[p3p-header-prefix "-P3P1.0: " 1p3p-content CRLF]` `[message-body]` `; start-line, message-header, CRLF, and` `; message-body are as defined in the` `; HTTP 1.1 specification [HTTP1.1].`
[2]	p3p-opt-header	=	p3p-extension ";" "ns-" p3p-header-prefix
[3]	p3p-extension	=	`"` "http://www.w3.org/TR/1998/WD-P3P-19981109/" `"`
[4]	p3p-header-prefix	=	1*digit
[5]	`digit`	`=`	`"0"\|"1"\|"2"\|"3"\|"4"\|"5"\|"6"\|"7"\|"8"\|"9"`
[6]	`number`	`=`	`1*digit`
[7]	`yesno`	`=`	`"` ("0"\|"1") `"` ; 0 = No, 1 = Yes

3.3 Negotiation Primitives（交渉の原語）

以下の表は、P3Pプリミティブの意味とその関連と項、内容、HTTP理由コードをまとめたもの。すべてのプリミティブはサービスまたはエージェントにサポートされる必要があり、かつ、それらから送られるだろう。

Message	Meaning	After Receiving	Expected Response	Data in Message	Optional in Message	HTTP Return Code
OK	Proposal acceptable or data transfer successful	PROP or TXD	none	MD5 hash of agreement or data transferred		2xx
PROP	Here's a Proposal	Any time	OK, SRY, or PROP	Text of a proposal	Signature of initiator, fingerprint of previous Proposal	409
SRY	Sorry - request not processed	PROP, TXD	PROP or none	Reason code and MD5 hash of proposal or data transferred	Which practices are unacceptable	409
TXD	Transfer Data	Any time	none, OK or SRY	Data element names and values to be written, as requested	Agreement	2xx

このセクションでは各動作を説明し、誰が(ユーザまたはサービス)どんな状況で動作を始めることができるかを規定する。

3.3.1 Success (`OK`)

このメッセージは参加者がプロポーザルに同意した時またはデータ転送が成功した時に送られる。プロポーザルに対する返答がOKの場合、OKメッセージは同意IDを含む。OKが TXDメッセージに答えて送られる場合、OKメッセージはすでに転送されたデータの MD5ハッシュ値を含む。

3.3.2 Here's A Proposal (`PROP`)

どんな場合でも、いずれかの参加者は相手側に1つかそれ以上のプロポーザルを送ることができ、これらは、prop-msgの中で送られる。プロポーザルの条件は、片方がそれらに合意するまで（OK またはTXD 原語を使って返答することによって）固まっていない。プロポーザルはもしそう望めば、それを作成する者が署名して良い。さらにPROPは、片方から受け取ったプロポーザルの同意IDを含まなければならない（これによって片方は交渉の記録をたどることができる）。サイトがデータエレメントが任意であることを表したい場合は、プロポーザル内でそれを行っても良い。ユーザエージェントは、適切だと判断した時に任意のエレメントを返す。任意の目的やクオリファイヤを持つプロポーザルに関する同意ははっきりしないが、ユーザエージェントが一方の目的が合意に達し、一方は合意しなかったと表現するための明確な方法はない。従って、任意の目的やクオリファイヤは複数のはっきりしたプロポーザルを通して表現されなければならない。

プロポーザルがユーザエージェントに自動的に受領されない場合、3つのオプションがある。ユーザエージェントはどの返答が適切かどうかを決定するために、ユーザにガイダンスを指示することを含みながら何らかの方法でプログラムされていなければならない。

プロポーザルを拒否する(SRY)。これは、サービスから新しいプロポーザルを受けたいということを意味する。もし、ユーザエージェントがSRYメッセージを送り続ければたとえ同じプロポーザルが繰り返し送られても、無限ループの可能性があるということに注目しなければならない。ユーザエージェントは、交渉の回数が十分であるかを決定した後、この場合を検知しその他の技術を使って答えるための十分な状態を維持する責任がある。ユーザエージェントが十分に手におえない状態に見えたら、サービスは結局プロポーザルを変更することを選択する。
それ自身のプロポーザルを返す。これは拒否を意味するが、サービスが受け入れた場合ユーザが受け入れ可能と考えられるような代案を提供する。サービスにはユーザが喜んでそれを受けるように申し込むことを仮定する権利がある。

注意：ユーザエージェントによるカウンタープロポーザルの作成は、P3P1.0準拠には必要ではない。

交渉をやめる。ユーザエージェントが返答する必要は全くない。ユーザエージェントは、サービスに新たな要求を送らない。

もしプロポーザルがユーザエージェントに承認されれば、ユーザエージェントはOKとともにデータをサービスに送らなければならない。同意IDのもとでデータを送ることで、ユーザエージェントはプロポーザルを承認したことを示す。 TXDには承認されたプロポーザルの同意IDが含まれ、サービスは送られたデータを調べることで、ユーザがどのデータエレメントを送ったのかを確定することができる。

3.3.3 Sorry (`SRY`)

このメッセージは、プロポーザル(PROP) またはデータ送信(TXD)に対し送られる。これは、要求が処理されなかったことを示す。拒否には、理由コードと同意IDの2つの情報が含まれている。理由コードはどのようなタイプの要求が拒否されたのか、なぜ拒否されたのかを示す。複数のプロポーザルが送られるため、同意IDはどの要求が拒否されたのかを知る必要がある。プロポーザル拒否の特定の原因は理由コードにある。

最後に、SRYメッセージは、データ送信が失敗した時にデータ送信(TXD)メッセージに対して使うことができる。送信者は、TXDメッセージを再試行すべきではない。

注意：P3P1.0は、プロポーザルが拒否された場合プロポーザルのどの部分が拒否されたのかをはっきりと指摘することはできない。そのような機能はP3Pプロトコルの将来版に追加される予定である。P3P1.0では、詳細な交渉を要求するサービスやユーザエージェントのための可能な予備システムは、カウンタープロポーザルを送り、受け入れられない元々のプロポーザルの部分を修正、除去することである。インプリメントする人は、ユーザのプライバシープリファレンスを公開することに配慮が必要である。

3.3.4 Transmit Data (`TXD`)

プロポーザルを受け取った後、ユーザエージェントは要求されたデータを送る。ユーザエージェントは、同意IDを含む必要がある。サービスは、同意がまだ有効であるならそれを与えなければならない。同意IDが有効でないまたは存在しない同意の時は、サービスはSRYメッセージと共にレスポンスコードをR-1(Unrecognized Agreement)に設定してTXDに返さなければならない。

プロポーザルが任意のエレメントを要求した場合、TXDは要求されたデータエレメントの全てを含まないかもしれない。これらのうちいくつを転送するかを決定するのはユーザエージェントによる。同意は、ユーザにオプション項目を送った結果（おそらく報酬）を知らせてもよい。

3.3.5 Ending negotiation with final

交渉を終わらせるための原語はない。代わりに、この機能は、P3Pメッセージのクオリファイヤを通して提供される。どんなPROPやSRYメッセージも finalクオリファイヤに1を設定できる。サービスがfinal="1"クオリファイヤと共に PROPを受け取る時、それは、 OKまたはSRYで返答しなければならない。この返答は、要求されたオブジェクトは同意なしでは返却されないと書かれているHTMLドキュメントと同じくらい簡単かも知れないが、 content本文を含んでいなければならない。ユーザエージェントがfinal="1"のクオリファイヤと共に PROPを受け取る時、ユーザエージェントは、サービスがその"最終申し込み"を提示し、交渉を続けることは無意味であることを理解しなければならない。

3.3.6 Syntax of Negotiation Primitives

[8]	p3p-content	=	OK-msg \| PROP-msg \| SRY-msg \| TXD-msg
[9]	OK-msg	=	"<OK" message-attribute "/>"
[10]	SRY-msg	=	"<SRY" [" final=" yesno] ; default is 0 (No) message-attribute "/>"
[11]	TXD-msg	=	"<TXD" message-attribute ">" data-xfer "</TXD>"
[12]	message-attribute	=	agreementid-attribute \| reason-attribute \| data-hash-attribute
[13]	agreementid-attribute	=	" agreeID=" `"` agreement-id `"`
[14]	reason-attribute	=	" r=" `"` reason-code `"`
[15]	data-xfer	=	<XML formatted data element name-value pairs>
[16]	agreement-id	=	<base64 of 128 bit MD5 digest of proposal as per RFC 1864>
[17]	data-hash-attribute	=	" dh=" `"` <base64 of MD5 digest of data-xfer> `"` ; used to acknowledge the receipt of data

3.4 Reason Codes Definitions

理由コードはP3Pヘッダの中でオプションとして送られるかもしれない。全てのSRYメッセージは暗黙のR-0理由コードを持ち、その他すべてのメッセージは、暗黙のS-0理由コードを持っている。これらのデフォルトを無効にするメッセージの中の理由コードも含まれる。したがって、不足しているコードと関連した意味の値がなければならない。理由コードは大きく３つのクラスに分けられる。Successコード、rejectionコード、errorコードである。これらのクラスについての詳細を以下に示す。

3.4.1 Successコード

理由コードのこのクラスは、要求が正しく受け取られ、理解され、了承されたことを示す。

S-0 OK

この理由コードは、PROPやTXDメッセージに答えて OKやTXDメッセージで送ることができる。これは、 OK、PROP、 TXDメッセージ用のデフォルトコードである。

3.4.2 Rejectionコード

理由コードのこのクラスは、要求が正しく受け取られ、理解されたが、了承されなかったことを示す。これらのコードは SRYメッセージでのみ送られなければならない。

R-0 Other Rejection

この理由コードは、以下に定義された他のrejectionコードのどれもが適当でない時、SRY メッセージで使用されるかも知れない。これは、SRYメッセージ用のデフォルトコードである。ユーザエージェントとサービスは、可能ならばrejectionコードの1つを使用することが望ましい。

R-1 Unrecognized Agreement

この理由コードは、PROPやTXDメッセージに答えてSRYメッセージで送られるかも知れない。この理由コードは、同意IDが既知のまたは有効な同意を参照しない時、TXDの受取人により送られなければならない。

R-2 Agreement Expired

この理由コードは、PROPメッセージに答えてSRY メッセージで送られるかも知れない。それは、同意IDが参照した同意が期限切れになったことを示す。

R-3 Proposal Rejected

この理由コードは、PROPメッセージに答えてSRY メッセージで送られるかも知れない。それは、プロポーザルがSRY メッセージを送る実体に受け入れられないことを示す。

R-4 Data Unavailable

この理由コードは、PROPメッセージに答えてSRY メッセージで送られるかも知れない。それは、ユーザエージェントが要求されたデータを持たないことを示す。

R-5 Data Not Accepted

この理由コードは、TXDメッセージに答えてSRYメッセージで送られるかも知れない。これは、受領者が提供された情報を受け入れられないことを示す。

3.4.3 Errorコード

理由コードのこのクラスは、要求が正しく受け取られなかったか、または受け入れられたが理解されなかったことを示す。これらのコードはSRYメッセージでのみ送られなければならない。

E-0 Other Error

この理由コードは、以下に定義された他のErrorコードのどれもが適当でない時、SRY メッセージで使用されるかも知れない。ユーザエージェントとサービスは、可能ならば他のErrorコードの１つを使用することが望ましい。

E-1 Invalid Format

この理由コードは、全てのメッセージに対してSRY メッセージで送られることができる。受領されたP3Pメッセージは、文法的に有効でないか、あるいは意味的に役に立たないことを示す。例えば、不正な文法, 曖昧さ、矛盾がプロポーザルのstatementの中にある場合、ユーザエージェントは、E-1 理由コードでそのプロポーザルを拒否する。

E-2 Data Transfer Unsuccessful

この理由コードは、TXDメッセージに答えて SRYメッセージで送られることができる。それは、データ転送要求が受領され、それが文法的に有効で、有効な同意が適用されるが、データが何らかの理由で保存されなかったことを示す。

[18]

reason-code

S-0 | R-0 | R-1 | R-2 | R-3 | R-4 | R-5 | E-0 | E-1 | E-2

4. P3P markup and processing

このセクションでは、1) P3Pプロポーザル 2) データ転送のスキーマを説明する。プロポーザルで使用される英語の用語説明は、 [HARMV]に、より詳しく記載されている。

4.1 Example proposal

4.1.1 English language proposal

以下の文をコード化する。ここでプロポーザルは1つ、ステートメントは2つでそれぞれに論理ANDを含んでいる。 "Other disclosures"は自動的にプロポーザル全体に当てはまる。

PrivacyAssuredのメンバーであるCoolCatalogは、Webページhttp://www.CoolCatalog.com/catalogue/に以下のstatementを載せている。
私たちは、あなたの名前、年齢、性別を集める。それは、あなたが興味を持ちそうな衣服のタイプを見つけたり、または当方のリサーチ、商品開発の目的でエントリーカタログページをカスタマイズするためである。この情報を身元が確認できるような方法では使用しない。また、注文品を届けるためにあなたのお届け先情報を収集する。これは、当然であるが身元が判明する。この情報は社外に再び出ることはない。あなたからの情報にアクセスできる可能性は提供しない。しかし、保持および脱退方針をもっている。詳しくは、当方のプライバシーページhttp://www.CoolCatalog.com/PrivacyPractice.htmlを参照のこと。

以下は良い形式的な記述である。コメントがセミコロンの後ろにある:

in proposal schema
www.CoolCatalog.com makes ; entity
this statement for http://www.CoolCatalog.com/catalogue/ ; realm
with assurance from PrivacyAssured

we read ; read is default
   (User.Name.First) ; required is default
   (User.Bdate.Year optional)
   (User.Gender)
    for the purpose of (2 3) ; Customization of the Site to Individuals, R&D
    in (0) ; Non-Identifiable Form
    and the recipients are (0) ; only ourselves and agents
    with consequence of ("a site with clothes you'd
                                        appreciate.") ; optional
we read&write
    (User.Shipping.) ; this is a whole data set.
    for the purpose of (0) ; Completing the Current Transaction
    in (1) ; Identifiable Form
    and the recipients are (0) ; only ourselves and agents
access disclosure (3) ; no access to identifiable data
other disclosures (0,1) ; we make disclosures
         regarding changing agreement and retention
at http://www.CoolCatalog.com/PrivacyPractice.html

4.1.2 XML/RDF encoding of プロポーザル

以下の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/1998/WD-P3P-19981109/" 
 xmlns:VOC="http://www.w3.org/TR/1998/WD-P3P-19981109/vocab"
 xmlns:DATA="http://www.w3.org/TR/1998/WD-P3P-19981109/basedata"
 realm="http://www.CoolCatalog.com/catalogue/" 
 entity="http://www.CoolCatalog.com" agreeID="94df1293a3e5">
  <USES>
  <STATEMENT VOC:purp="2,3" VOC:recpnt="0" VOC:id="0"
   consq="a site with clothes you'd appreciate.">
    <WITH><DATA:PREFIX name="User.">
     <DATA:REF name="Name.First"/>
     <DATA:REF name="Bdate.Year" optional="1"/>
     <DATA:REF name="Gender"/>
    </DATA:PREFIX></WITH>
  </STATEMENT>
  </USES>
  <USES>
  <STATEMENT action="read&write" VOC:purp="0" VOC:recpnt="0" VOC:id="1">
    <DATA:REF name="User.Shipping."/>
  </STATEMENT>
  </USES>
  <VOC:DISCLOSURE discURI="http://www.CoolCatalog.com/PrivacyPractice.html" 
   access="3" other="0,1"/>
  <ASSURANCE org="http://www.TrustUs.org" 
   text="third party" image="http://www.TrustUs.org/Logo.gif"/>
</PROP>/STATES>
</RDF:RDF>

4.2 Proposals

このセクションでは、あるプロポーザルで動作するためのキーエレメント、属性、processing heuristicsについて定義する。全てのプロポーザルは[UTF-8] を使用して暗号化される。

4.2.1 Proposal structure: the `PROP` element.

xmlns="http://www.w3.org/TR/1998/WD-P3P-19981109/syntax"

<PROP>: 1つかそれ以上のstatementを含む。各ステートメントはデータエレメントに適用されるような情報開示を含む。
agreeID: 同意ID（受け入れられたプロポーザルのフィンガープリント）。
final: 交渉の最終結果を示す。
propURI: プロポーザルが引き出されるURI。
postURI: 情報が送られるURI。
realm: プロポーザルが適用されるURIのリスト。
entity: プロポーザルに含まれるプライバシープラクティスを表示するlegal entityに関連するドメインネームとPathを参照するURI
agrexp: 同意が期限切れになる日付。デフォルトは6ヶ月。同意の期間終了は、同意に基づいてユーザエージェントがサービスにデータを転送することができる最後の日である。サービスは、同意に基づいて　集められたデータに対し、期限切れの後でさえ同意の制限を受ける。プロポーザルは、HTTPヘッダの"EXPIRES"に示された時間後に期限切れとなる。デフォルトは1時間。
optional: プロポーザルがオプションかどうかを示す。（セクション４.３.５参照）

[19]

PROP-msg

`<P3P xmlns="http://www.w3.org/TR/1998/WD-P3P-19981109/" 
 xmlns:VOC="http://www.w3.org/TR/1998/WD-P3P-19981109/vocab"
 xmlns:DATA="http://www.w3.org/TR/1998/WD-P3P-19981109/basedata">` 
 1*(short-proposal | long-proposal) `</P3P>`|
 (`<RDF:RDF xmlns:RDF="http://www.w3.org/TR/WD-rdf-syntax/">`
  `<P3P xmlns="http://www.w3.org/TR/1998/WD-P3P-19981109/" 
   xmlns:VOC="http://www.w3.org/TR/1998/WD-P3P-19981109/vocab"
   xmlns:DATA="http://www.w3.org/TR/1998/WD-P3P-19981109/basedata">`
   1*(short-proposal | long proposal ) `</P3P>`
  `</RDF:RDF>`))

ショートプロポーザルは、サイトがエージェントが同意を知っていると仮定したいとき、あるいはエージェントにpropURIで示される完全なプロポーザルを参照させたいときに送られる。

[20]
short-proposal

=

`<STATES><PROP ` (("agreeID=" `"` quoted-string `"` ">") | ("propURI=" quoted-URI ">")) "</PROP></STATES>"

ロングプロポーザルは必要な属性のすべてを含んでいる。

[21]
long-proposal

=

`<STATES><PROP` [" final=" yesno] ; default is 0 (No) [agreementid-attribute] [" agrexp=" `"` datetime `"`] ;default is six months " realm=" `"` URI *(" " URI) `"` " entity=" quoted-URI [" postURI=" quoted-URI] [" optional=" yesno] ;default is 0 (No) ">" 1*statement-block disclosure 1*assurance "</PROP></STATES>"

[22]
schemaURI

=

`"` "http://www.w3.org/TR/1998/WD-P3P-19981109/" `"`

[23]
quoted-string

=

`"` string `"`

[24]
string

=

<[UTF-8] string (with " and & escaped)>

[25]
quoted-URI

=

`"` URI `"';`

[26]
URI

=

<URI as per RFC 2068 [URI]>

[27]
datetime

=

<date/time as per section 3.3 of RFC 2068>

4.2.2 Processing Realms and URI's

realm(レルム)属性は、同意の範囲を定義する。これは、ユーザエージェントにより使われるが、例えば、ReturnIDを自動的に送るかや、データ転送要求に応じるかなどの決定を行う。プロポーザルがデジタル方式でサインされない場合は、各レルムのURIは、サーバのドメインと、"domain-match"[Kristo参照] （ドメインが一致）しなければならない。プロポーザルがデジタル署名される場合は、元々のレルムの外のサーバが既存の同意に基づいてデジタル署名したプロポーザルを作成した時はいつでも、レルムは拡大され現在の要求URIを含む。

注意点として、ユーザエージェントは現在の要求URIが既存の同意に影響されるのかどうかを決定するためにレルムを使う。ユーザエージェントは、もし有効な同意がReturnIDを要求した場合、その要求とともに自動的にReturnIDを転送する。このことは、サービスが状態を保持したり、客レベルの統計を保存したりする機能を与えている。

Schemes（スキーマ）

P3Pは、HTTPと関連するschemes (HTTPSのような）用に設計されている。そのプロトコルは、将来拡大され、 FTPやNNTPなどのその他のスキーマを使ってデータ交換、交渉をサポートする可能性がある。特にHTTP、HTTPSの場合、 HTTPを使用して届いた同意は、HTTPS schemesを使用するURI要求をサポートする。例えば、ユーザがrealm="http://www.romulus.com/"に同意した場合、 "https://www.romulus.com"は、レルムの一部と考えられる。しかし、ユーザーがrealm="http://www.romulus.com/"に同意した場合、 "https://www.romulus.com"は、その同意の影響を受けない。

entity（実体）

entity属性は、legal entityと連携可能なドメイン名とパスを参照する。デジタル署名がない場合、この機能はドメイン名登録から供給される権威のない確認メカニズムとドメイン名の責任機関を経由して legal entityの記録をたどる唯一の方法である。さらにentity属性は、証明がrealm属性として使用されていない時に、 realm内のURIがドメイン一致[KRISTOL]しなければならない"root" ドメインとして使用される。さらに、客が要求したURIは、entity属性にドメイン一致しなければならない。

realm（レルム）

HTTP要求のための与えられたURIが特定の同意に従うかどうかを決定するために使用される URIを表すrealm属性。Realmは、entity属性にドメイン一致する1つまたは複数の URIであるか、あるいはURIのrealmのセットを表すデジタル認証を示す URI。以下のシナリオを考えてみてもらいたい。

ユーザがhttp://www.romulus.comを要求する。
サービスがrealm="http://maps.romulus.com/ http://www.romulus.com/"とentity="romulus.com"のプロポーザルを返却する（www.romulus.com とmaps.romulus.com.は、要求URI のドメインのルートである romulus.com. とドメイン一致することに注目してもらいたい）。プロポーザルは、PUID（ID.PUID）、ユーザのニックネーム（User.Name.Nickname）、家の住所(User.Home.Postal.)誕生年月日(User.Bdate.Year と User.Bdate.Month) を要求するが、これはサイト管理とユーザの経験への適合を目的とした身元のわからない使用のためである。
ユーザは、プロポーザルを受入れ、同意 ID=Xで同意する。
ユーザは、同意 ID=Xの realmに当てはまるmaps.romulus.comを訪れ、自動的にPUIDを　maps.romulus.com.に送る。

4.2.3 Soliciting user info: The `source` 属性

この属性は、ネイティブなP3Pエージェントのインタフェースではなく、フォームを通して情報を求めることができる。これは、プロポーザルのエレメント名を連携したHTMLフォーム(HTTP content) のフォームのINPUT名と関連させることにより達成される。HTMLクライアント/P3Pエージェントは、適宜値を自動入力する可能性がある。

以下の場合にP3Pエレメントが要求される。

source 属性は"フォーム"と同等で、フォームのなかのエレメントの1つは、Form.Data_のabstract データエレメントである。
HTMLフォームフィールドのINPUT名は、プロポーザルの中のデータエレメント名に該当する。

このフィールドの許容値は、以下の通りである。

agent.. デフォルト値。P3Pエージェントは、ユーザを要求しなければならない。
form.. 要求は、連携したHTML内容の暗黙のフォームを通して起こる。
URI.. 与えられた情報は、与えられたURIのresourceによって要求される。

例えば、サービスは自分の具象的な制御の下で要求を持ちたがる。また、サービスはデータをシナリオ8に書かれているpostメカニズムを通して受けたがっていると仮定する。

<RDF:RDF xmlns:RDF="http://www.w3.org/TR/WD-rdf-syntax/">
<P3P xmlns="http://www.w3.org/TR/1998/WD-P3P-19981109/" 
 xmlns:VOC="http://www.w3.org/TR/1998/WD-P3P-19981109/vocab"
 xmlns:DATA="http://www.w3.org/TR/1998/WD-P3P-19981109/basedata">
<STATES>
<PROP realm="http://www.CoolCatalog.com/catalogue/"
 entity="http://www.CoolCatalog.com" agreeID="94df1293a3e5"
 postURI="http://www.CoolCatalog.com/cgi-bin"/>
<USES>
   <STATEMENT action="rw" VOC:purp="2,3" VOC:recpnt="0" VOC:id="0"
    source="form"
    consq="a catalogue of shoes that fit you.">
     <WITH><DATA:PREFIX name="Cool." xmlns:DATA="http://www.CoolCatalog.com/productschema.html">
     <DATA:REF name="ShoeSize"/>
     </DATA:PREFIX></WITH>
     <DATA:REF name="Form.Data_"/>
   </STATEMENT>
   </USES>
  <ASSURANCE org="http://www.TrustUs.org" 
   text="third party" image="http://www.TrustUs.org/Logo.gif"/>
</PROP>
</STATES>
</P3P>
</RDF: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="P3P_User_First"
  size="20" value="Your Name Here"> Shoesize <input type="text" name="Cool.ShoeSize"
  size="20" value="9 1/2"></p>
</form>

</body></html>

注意：これは、プロポーザルの中でinformation beyond that which is enumerated と表現されていたアブストラクトエレメントForm.Data…とは異なる。（例：HTMLやJava式で）Source 属性はプロポーザルに列挙された情報はどのように送信請求されるかを指定する。情報は、そのsource方式に関連した方法を元に返却される。例えば、If source="form"の場合、情報はHTML/HTTP postによって返却される。Ifsource="agent"情報は、P3P-HTTP-extensionか指定すれば postURIで返却される。Java appletでの情報送信請求が通常の方法になってきた場合、自らの方式で情報を返す可能性がある。

4.2.4 Attesting to a proposal: the `ASSURANCE` element

<ASSURANCE>

entityがそのプロポーザルを守る事を証明するサービスで、データの処理においてガイドラインに従うか、あるいはその他の関係ある主張に従う。

service

Assurance serviceのURI

text

Assurance serviceのタイプの短い原文通りの説明 (e.g., third party, legal, etc.)

image

Assurance serviceのimage logoのURI

width

Image logoのピクセル幅

height

Image logo のピクセル高さ

alt

Image logoの短い原文通りの説明

[36]

assurance

"<ASSURANCE"
" service=" quoted-URI
[" text=" quoted-string]
[" image=" quoted-URI
 [" width=" `"` number `"`]
 [" height=" `"` number `"`]
 [" alt=" quoted-string] ]
"/>"

注意：ASSURANCEの複数の発生により指定される複数のassurance serviceが存在する。

4.3 Statements

このセクションでは、P3P Harmonized Vocabularyを使用してprivacy statementやdisclosuresを作るためのキーエレメントや属性について定義する。我々が参照目的でこの文書内に{purp, recpnt, id}属性名を　指定する場合、規範的な定義や値は以下に定義される。

http://www.w3.org/TR/1998/WD-P3P-19981109/vocab

4.3.1 Privacy statements: the `STATEMENT` element

xmlns="http://www.w3.org/TR/1998/WD-P3P-19981109/syntax" xmlns:VOC="http://www.w3.org/TR/1998/WD-P3P-19981109/vocab"

<STATEMENT>: データエレメントに適用される目的とqualifier

VOC:purp

Webに適切なデータプロセッシングの目的

VOC:recpnt

データが配布されるかもしれないサービスプロバイダーやエージェントを越えたorganizational areaとドメイン。

VOC:id

個人的な身元確認可能な方法で使用されるデータ。他のソースからのあなたに関する身元確認可能な情報とのリンクを含む。

action

データ読み込み又は読み込みと書き込み

source

native P3Pエージェントインターフェース以外の方法を通して情報の送信を請求する。

[28]	statement-block	=	"<USES>" "<STATEMENT" [" action=" `"` action `"`] " VOC:purp=" `"` purpose ("," purpose) `"` " VOC:recpnt=" `"` recipients ("," recipients) `"` " VOC:id=" yesno [" consq=" quoted-string] [" source=" `"` ("agent"\|"form"\|URI) `"`] ; default is agent ">" *(datablock) "</STATEMENT>" "</USES>"
[29]	action	=	("r" \| "rw") ; r=read, rw=read&write, デフォルトはread
[30-32]の値は参照目的で記載する。仕様については、harmonized vocabulary文書を参照のこと。
[30]	purpose	=	"0" \| ; 現在のactivityの完成およびサポート "1" \| ; ウェブサイトとシステムアドミニストレーション "2" \| ; 個人に対するサイトのカスタマイズ "3" \| ; 研究開発 "4" \| ; サービスや製品のマーケティングの為の訪問者との接触 "5" [" (" string ")"] ; その他の使用法
[31]	recipient	=	"0" \| ; 社内事項とエージェント "1" \| ; 他社のプラクティスに従う組織 "2" \| ; 無関係の第三者およびパブリックフォーラム "3" ; 無関係の第三者およびパブリックフォーラム
[32]	id	=	yesno

注意：これらのエレメントや属性の多くはvocabulary namespaceに関連している。もともとかなり保守的なデフォルト値が選ばれ("0")、サービスにこれらのデフォルトに対抗して、これらのプラクティスに正直であるように強制していた。しかし、これにより意味相互運用性(semantic interoperability)に結びつく可能性がある。サービスはある属性が任意であると思い、ユーザがそれらに（？）暗黙の/デフォルトの意味に基づいた情報をあたえる。もっと良いアプローチは、デフォルト値をかなり高く設定することである。 (すなわち、recipient属性が含まれていない場合は、データが公共に分配されていることを意味する。)しかし、我々は、optional属性とdefault semanticを持つ必要な属性との混同を避けるためにデフォルト値を提供しないことに徹底しすぎている。

4.3.2 General disclosures: the `VOC:DISCLOSURE` element

xmlns:VOC="http://www.w3.org/TR/1998/WD-P3P-19981109/vocab"

<VOC:DISCLOSURE>

サービスのアクセス能力に関する簡単な情報開示能力で、entityがすでに集められたデータの同意の変更やデータの保持方法についての情報開示を行うかどうかに関するバイナリ値。

discURI

プロポーザルのわかりやすいURI。これは、質問などでサービスにコンタクトする時の方法についても含んでいる。

access

個人情報、住所に関する質問、サービスプロバイダーへの憂慮事項等を個人が参照できること。

other

サイトはそのdiscURIで知られる同意の変更や保持に関してそのポリシーを作るのか？

[33-35]の値は参照目的で記載している。仕様についてはharmonized vocabulary文書を参照。
[33]	disclosure	=	"<VOC:DISCLOSURE" " discURI=" quoted-URI " access=" `"` access-disclosure `"` [" other=" `"` other-disclosure *("," other-disclosure) `"`] "/>"
[34]	access-disclosure	=	"0" \| ; Identifiable Data is Not Used "1" \| ; Identifiable Contact Information "2" \| ; Other Identifiable Information "3" \| ; None
[35]	other-disclosure	=	"0" \| ; change agreement "1" ; retention

4.4 Data References

xmlns:VOC="http://www.w3.org/TR/1998/WD-P3P-19981109/basedata"

4.4.1 Referencing data: the `<DATA:REF>` タグ

data sets/elementsに対する参照は全て<DATA:REF>タグを使用したstatement内に囲まれている。 <DATA:REF>タグは、以下の属性を持っている。 name、xmlns:DATA、value、optional、type、 typeschema、short、long、category、size。

name属性は、data element/setの名前を意味する文字列である。Setとelementは、セットされたnameの後のドット（．）の存在により文法的に識別される。例えば、セットUser.Homeを示す場合、文字列はUser.Home.になる。便利な方法としては、data sets/elementsの名前は、厳密ではない。（そのため、例えば、User.HomeはUSER.HOME.やuser.home.に相当する。）さらに、名前の中では、ドットの後に数字を入れることができる。最後に、下線("_")が最後につく名前には特別な意味がある。（それらはabstract elementsと呼ばれる。P3P Base Data Set 仕様のセクション 3参照）
xmlns:DATA属性は、dataスキーマの名前を意味するURIである。空の文字列と同等である欠落したxmlns:DATA属性は、PROPエレメントにあるxmlns:DATA属性によって参照される基本的なものである。
value属性は、NAME属性に指定されるデータエレメントの実際の値を意味する文字列である。データエレメント要求の場合は、value属性はない。
optional属性は、"0" または"1"である。"0"はデータエレメントが必要だということを示す。"1"は、データエレメントが必要でないことを示す。Default は0。optionalフィールドは、データエレメント要求の場合のみ使用される。
The ext attribute denotes an URI pointing to an action (like e.g. protecting security, soliciting mobile information from the computer rather than the user, etc.) which the user agent must be able to understand if it wants to accept the proposal and transfer the data element.

以下の6つの属性は新しい（P3P1.0ベースには定義されない）データエレメントやセットが参照された時のみに使用される。

type属性は、data element/setのタイプを意味する文字列。
typeschema属性は、type属性で指定されたタイプが定義されるdataスキーマを意味するURI。
short属性は、data element/set の短縮名を意味する文字列。
long属性は、data element/set のより長い記述を意味する文字列。
category属性は、データエレメントのcategories （属性）を意味する文字列。
size属性は、データエレメントに保存するために必要なbytesの最大値を意味する。　デフォルト値の0は、データエレメントが任意に大きくできることを示す。

[37]

data-reference

"<DATA:REF" " name=" quoted-string [" xmlns:DATA=" quoted-URI] 
[" optional=" yesno] [" value=" quoted-string] 
[" type="quoted-string] [" typeschema=" quoted-URI] 
[" template=" yesno] [" VOC:category=" categories] 
[" short=" quoted-string] [" long=" quoted-string]
[" size=" `"` number `"`] ; default is 0 (unlimited size)
[" ext=" quoted-URI]
"/>"

例として、ユーザのお届け先情報の都市名、User.Business.の全エレメント、そして（オプションとして）User.Home.Info.Phone. の全エレメントを要求するために、サービスはP3Pプロポーザルの中で以下のようなreferenceを送る。

<DATA:REF name="User.Shipping.Postal.City"/>
<DATA:REF name="User.Home.Telecom.Phone." optional="1"/>
<DATA:REF name="User.Business."/>

ユーザがcity, business情報,自宅の電話番号の国際コードとローカルエリアコードのみを返すことに同意する場合、txdタグの中で以下のreferenceを送る。

<DATA:REF name="User.Shipping.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.) ...

4.4.2 Prefixing references: `<WITH><DATA:PREFIX>`

データ参照の1セット中の多くのエレメント名は、１つのparentを共有する。例えば、上記にあるように"User"は、referenceのなかに共通して発生する。<WITH><DATA:PREFIX>タグは、文字列 prefixをref タグのすべての属性と連携させるのに使用することができる。従って、これは、名前の長さを短くしたり、新しいdata sets と elementsに参照文をつけるのに使うことができる。<DATA:REF>タグの一続きが<WITH><DATA:PREFIX> タグ内にある場合、そのブロックは入っている<WITH><DATA:PREFIX>タグが省略されたブロックと同等で、<DATA:REF>タグの各属性の値が<DATA:PREFIX>タグの属性の該当する値の前につけられる。例えば、上の例は以下のように書き換えることができる。

<WITH><DATA:PREFIX name="User.">
<DATA:REF name="Shipping.Postal.City" value="Boston"/>
<DATA:REF name="Home.Telecom.Phone.IntCode" value="1"/>
<DATA:REF name="Home.Telecom.Phone.LocCode" value="617"/>
<DATA:REF name="Business.Postal.Street" value="12 Main St."/>
<DATA:REF name="Business.Postal.City" value="Cambridge"/>
... (the other values of User.Business.) ...
</DATA:PREFIX></WITH>

<WITH><DATA:PREFIX> は、一揃いになることができる。Prefix は、最も奥の<WITH><DATA:PREFIX> ...</DATA:PREFIX></WITH>の組み合わせの前につけること（ここで"最も奥"は、タグの中には他の<WITH><DATA:PREFIX>が無いことを意味する）。そのため、上記の例は以下の方法でもっとコンパクトに書き換えることができる。

<WITH><DATA:PREFIX name="User.">
<DATA:REF name="Shipping.Postal.City" value="Boston"/>
<WITH><DATA:PREFIX name="Home.Telecom.Phone.">
<DATA:REF name="IntCode" value="1"/>
<DATA:REF name="LocCode" value="617"/>
</DATA:PREFIX></WITH>
<WITH><DATA:PREFIX name="Business.Postal.">
    <DATA:REF name="Street" value="12 Main St."/>
    <DATA:REF name="City" value="Cambridge"/>
    ... (the other values of User.Business.Postal.) ...
</DATA:PREFIX></WITH>
... (the other values ofUser.Business.) ...
</DATA:PREFIX></WITH>

注意：1つのタグ（<DATA:PREFIX>だけ）の代わりに2つのタグ（<WITH><DATA:PREFIX>）を使う理由は、技術的にRDFデータモデルを用いているからである。

[38]
datablock

=

*datareference | ( *datareference "<WITH><DATA:PREFIX" " name=" quoted-string [" xmlns:DATA=" quoted-string] [" optional=" quoted-string] [" value=" quoted-string] [" type=" quoted-string] [" typeschema=" quoted-string] [" template=" yesno] [" VOC:category=" quoted-string] [" short=" quoted-string] [" long=" quoted-string] ">" datablock "</DATA:PREFIX></WITH>" datablock )

4.4.3 The `VOC:category` 属性

このセクションでは、データエレメントやセットを表現するために使われるカテゴリを定義する。category属性を参照目的で指定し、規範となる定義は以下にある。

http://www.w3.org/TR/1998/WD-P3P-19981109/vocab/#Categories

Category は、データエレメントの属性であり、ユーザとユーザエージェントにデータの意図した使い方のヒントを与える。Categoryは、P3P ユーザエージェントの実施や使用を簡単にするために必要である。これにより、ユーザがデータの交換においてより一般的なプリファレンスやルールを表現することができる。Categoryは、新しいエレメントを定義したり、データを作るために参照したりする時にしばしば含まれる。

Categoryの中のデータエレメントのメンバーシップは、一般的にばらばら（disjoint）である。ほとんどのデータエレメントは、１つのcategoryに属さなければならないが、必要であればそれらは複数のcategoryに属する場合もある。さらに、データセットは、エレメントが属する全てのcategoryに属する。基本データエレメントは全てP3P仕様書のデフォルトcategoryに割り当てられている。サービスが新しいデータエレメントをproposeする時、そのプロポーザルは、デフォルトcategoryかエレメント用の categoryを含んでいなければならないが、ユーザやユーザエージェントは、category割り当てに対する最終的な制御権を持っている。

[39]
categories

=

`"` *(number ",") number `"`

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を参照のこと。

4.4.4 Client side writes: the `action` 属性

サービスはユーザレポジトリに情報を書き込むように命令する能力を持っている。P3Pエージェントが以下のリクエストをプロポーザルの一部として受け取った場合を考えてみてもらいたい。

<STATEMENT action="r" VOC:purp="2" VOC:recpnt="0" VOC:id="0"/>
    <DATA:REF name="ID.PUID"/>
    <DATA:REF name="User.Name.First"/>
</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" />
</STATEMENT>

ユーザは、このプロポーザルに同意するかどうか聞かれたら、指示するかも知れない。そして、User.PersonName.First auto-filled(ユーザがそれを前に入力したと仮定して)とのインタフェースのフォームとFineShoes.shoesize用の空のフィールドが表示される。ユーザは、この情報を入力し、TXDを送信する。

The user sends:

<TXD r="S-0" agreeID="94df1293a3e5">
<DATA:REF name="User.Name.First" value="Josephine"/>
<DATA:REF name="ID.PUID" value="1234567"/>
<DATA:REF name="FineShoes.Shoesize" xmlns:DATA="http://www.FineShoes.com/Schema1.0" value="7"/>
</TXD>

属性"rw"がデータエレメントに適用される場合や新しい値がユーザから提供される場合は必ずユーザエージェントはデータレポジトリへの書き込みをやってみなければならない。もし、これに失敗したらエージェントは、適切なレスポンスコードを戻さなければならない。この自動書き込みによってサービスがユーザエージェントに情報を戻す手間が省ける。しかし、サービスは、いつでも(TXD)を送るかも知れない。例えば、ユーザが靴サイズ７という情報を提供しても、サービスは、ヨーロッパサイズに変換し、その値を代わりに書き込む。

4.4.5 Unambiguous（明らかな） Optional Elements and Purposes

P3Pに期待される特徴というのは、サービスが任意にエレメントに対し、行動（read & waite）を要求することができるということと、間接的にオプション的なクオリファイヤ(purposes, recipients, identifiable usage)をエレメントに適用することである。

エレメントに対する任意のaction(read or read & write) というのは記述しやすい。オプション的な要素は、<DATA:REF>タグのoptional属性によって表される。読み取りや書き込みのためにオプション的に要求されるが、クライアントは受け入れられないこれらのエレメントは、単に作用しない。データは戻されたり書き込まれたりしない。

オプションのクオリファイヤを表示するのは問題がある。エレメントが処理を終了するのに必要とされるがオプションでダイレクトマーケティングのために要求される場合は、エレメントを単に返却することはユーザが何に同意したかのあいまいな表現になる。従って、あいまいさを避けるために以下のことが必要になる。

エレメントがオプションの場合、プロポーザル内に一度しか現れない。
さもなければ、オプションのクオリファイヤは、複数の、曖昧でないプロポーザルを使用することにより表現されなければならない。

例えば、あるサービスが取引を成立させるためにお届け先情報を必要とし、またオプション的にこのデータの全てをマーケティング目的に使いたい場合、以下の２つのプロポーザルを送る必要がある。

<P3P xmlns="http://www.w3.org/TR/1998/WD-P3P-19981109/" xmlns:VOC="http://www.w3.org/TR/1998/WD-P3P-19981109/vocab" xmlns:DATA="http://www.w3.org/TR/1998/WD-P3P-19981109/basedata">
<STATES>
<PROP xmlns="http://www.w3.org/TR/1998/WD-P3P-19981109/" xmlns:VOC="http://www.w3.org/TR/1998/WD-P3P-19981109/vocab" xmlns:DATA="http://www.w3.org/TR/1998/WD-P3P-19981109/basedata" agreeID="1e3a5d71297d>"
realm="http://www.CoolCatalog.com/catalogue/">
<USES>
   <STATEMENT VOC:purp="2" VOC:recpnt="0" VOC:id="1"
    consq="We can ship your order to your door step">
      <DATA:REF name="User.ShipTo."/>
   </STATEMENT> </USES>
<VOC:DISCLOSURE text="http://www.CoolCatalog.com/PrivacyPractice.html"
access="3" other="0,1"/>
</PROP></STATES> <STATES>
<PROP agreeID="2e3a5d71297d"
realm="http://www.CoolCatalog.com/catalogue/" optional="1"> ; note optional is in header.
<USES>
   <STATEMENT VOC:purp="4" VOC:recpnt="0" VOC:id="1"
    consq="We will send you our world-renown catalogue!">
      <DATA:REF name="User.ShipTo."/>
   </STATEMENT> </USES>
<VOC:DISCLOSURE text="http://www.CoolCatalog.com/PrivacyPractice.html"
access="3" other="0,1"/>
</PROP></STATES> </P3P>

１つの複雑なプライバシーポリシーを表示するのに複数のプロポーザルを使用する場合は、以下のルールに従う必要がある。

1つのプロポーザルにオプション的なエレメントだけがある場合、全体のプロポーザルのオプションフラグは1に設定されていること。
1つのサイトが一人のユーザに複数のプロポーザルを送る時、ユーザが同意したいなら、ユーザは、1 つないし複数のオプションでないプロポーザル用の、または0ないし複数のオプションプロポーザル用の同意IDを返さなければならない。もし、ユーザが1つのオプションプロポーザルだけに同意するならば、サイトはそのレルムへのアクセスを拒否しても良い。

我々の例では、ユーザが取引の完成のお届け先情報を使用するプロポーザルだけに同意する場合、その同意IDに基づいた情報を返す。

<TXD r="S-0" agreeID="1e3a5d71297d" />
<WITH><DATA:PREFIX name="User.ShipTo.">
      <DATA:REF name="Postal.Name" value="Josephine Hound"/>
      ...
      <DATA:REF name="Telecom.Phone.Number" value="2532442"/>
</DATA:PREFIX></WITH>

この解決策が、複数のプロポーザルとデータ転送において、冗長な情報の転送を引き起こす可能性があることに注意。しかしこれは、彼らが同意した曖昧なプロポーザルの一部を送り返すことよりも望ましい

4.4.6 Creating New Data Sets

4.4.6.1 Data Definition

プロポーザルの中で、新しいデータエレメントとデータセットを作成することができる。これは、未知のデータエレメントまたはデータセットの参照がそのプロポーザルの中で生じた時に起こる。そのような場合、ユーザーが同意すれば、新しいデータエレメントはユーザのレポジトリの中で作成される。新しいデータエレメントを作成するためには、エージェントは以下のことが必要になる：名前、付属するデータスキーマ,カテゴリ、データタイプ（タイプが定義されたデータスキーマ）、ショートディスプレイネーム（表示用の短縮名）。

また、サービスは特別なスキーマ定義の形でデータエレメントを詳細に説明する。この情報は、以下の２通りの方法で提供される。

category, type, typeschema, short（次のサブセクションを参照）などの属性を使って、<DATA:REF> 　タグ内で内部表示。
xmlns:DATA属性から提供されたデータスキーマの定義内で外部表示。

情報が内部表示で元のサーバURIがデータスキーマURIと一致しない場合、メインデータスキーマ内の情報は、情報の一貫性を証明するためにチェックされなければならない。もしくは、メインデータスキーマ内の情報は、一貫性を証明するためにチェックされても良い。一致しない場合、E-1理由コード (Invalid Format)は返却されなければならない。ユーザーが必要な情報を再構築することができない理由が他にある場合、R-4理由コード (Data Unavailable)が返されなければならない。

4.4.6.2 Data Schema Format

新しいデータスキーマの書式は、特別なフォーム記述である。


<P3P xmlns="http://www.w3.org/TR/1998/WD-P3P-19981109/" 
 xmlns:VOC="http://www.w3.org/TR/1998/WD-P3P-19981109/vocab"
 xmlns:DATA="http://www.w3.org/TR/1998/WD-P3P-19981109/basedata">
<STATES>
<PROP>
<USES><STATEMENT>
  ....
</STATEMENT></USES></PROP></STATES></P3P>

データブロックは、<data>タグの中に入っており、データエレメントの参照を含んでいる。参照は、 <DATA:REF>タグとその属性を使用して作ることができる。

name (データエレメントの名前を定義する。)
category （categoryを定義する。）
type (type を定義する。)
typeschema (type が定義されているdata スキーマを定義する。)
short (short display nameを定義する。127[UTF-8]字未満。)
long (データ項目のより長い表現を提供する。1023 [UTF-8]字未満。)
size (データのバイト形式で最大サイズを提供する。)

<DATA:PREFIX>タグは、データ転送のように共通のprefixと多くの<DATA:REF>属性を連携させることによってスキーマ定義を短くするために使うことができる。

各データ転送のために、long以外の情報は全て必要である。属性の１つが欠けていた場合、空の文字列と共に存在すると考えられる。typeschemaの場合は、空の文字列は特別な意味を持ち、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

それから、この会社は、以下のコードをhttp://www.HyperSpeed.com./models-schemaに置くことができる。


<P3P xmlns="http://www.w3.org/TR/1998/WD-P3P-19981109/" 
 xmlns:VOC="http://www.w3.org/TR/1998/WD-P3P-19981109/vocab"
 xmlns:DATA="http://www.w3.org/TR/1998/WD-P3P-19981109/basedata">
<STATES>
<PROP>
<USES><STATEMENT VOC:purp="4" VOC:recpnt="0" VOC:id="0">
<WITH><DATA:PREFIX name="car." short="Car" VOC:category="7" size="63">
 <DATA:REF name="model" type="Text" short="Model"/>
 <DATA:REF name="color" type="Text" short="Color"/>
 <WITH><DATA:PREFIX name="built." short="Construction data">
  <DATA:REF name="year" type="Number" short="Year"/>
  <DATA:REF name="where." type="Postal."/>
 </DATA:PREFIX></WITH>
</DATA:PREFIX></WITH>
<DATA:REF name="bike." type="car." typeschema="http://www.HyperSpeed.com/models-schema" short="Bike "/>
</USES></STATEMENT></PROP></STATES></P3P>

データセットが作成されるたびにそれは上記のcar.の場合のように暗黙にtypeとして使用されることができる。しかし、いくつかの状況において、elementをユーザのレポジトリに作成せずにtypeを定義したい場合もある。このような時は、<DATA:REF>の中にtemplate属性を使うこと。値をyes, つまりtemplate="1"(defaultは"0"で意味は"no")に設定することは、対応するデータエレメントがtype定義の一部であることを意味し、実際に関連した値を持つデータエレメントを表現しているわけではない。例えば、HyperSpeedは汎用のGenericModel.タイプを定義したがっていて、それをcar.とbike.で例示したがっている。これは、以下のスキーマで表現することができる。


<P3P xmlns="http://www.w3.org/TR/1998/WD-P3P-19981109/" 
 xmlns:VOC="http://www.w3.org/TR/1998/WD-P3P-19981109/vocab"
 xmlns:DATA="http://www.w3.org/TR/1998/WD-P3P-19981109/basedata">
<STATES>
<PROP>
<USES><STATEMENT VOC:purp="4" VOC:recpnt="0" VOC:id="0">
<WITH><DATA:PREFIX name="GenericModel." template="1" VOC:category="7" size="63">
 <DATA:REF name="model" type="Text" short="model"/>
 <DATA:REF name="color" type="Text" short="color"/>
 <WITH><DATA:PREFIX name="built." short="Construction data">
  <DATA:REF name="year" type="Number" short="Year"/>
  <DATA:REF name="where." type="Postal."/>
 </DATA:PREFIX></WITH>
</DATA:PREFIX></WITH>
<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></STATES></P3P>

注意：新しいデータセットに大事なデータを確実に保存させるコマンドはない。これは重要データは暗号化したり、reference URIを使用して安全に保存することができるからである。

5. Appendices（付録）

Appendix 1: References （Normative:規範）

[DSIG]: Y. Chu, P. DesAutels, B. LaMacchia, P. Lipp. "DSig 1.0 Signature Labels Specification: Using PICS 1.1 Labels for Making Signed Assertions," World Wide Web Consortium, Recommendation. 03-April-1998.
[RDF]: O. Lassila, R. Swick. "Resource Description Framework (RDF) Model and Syntax Specification." World Wide Web Consortium, Working Draft. 14-August-1998.
[HARMV]: J. Reagle. "P3P Harmonized Vocabulary Specification," World Wide Web Consortium, Working Draft. 30-March-1998. (Working Draft)
[HTTP1.0]: T. Berners-Lee, R. Fielding, H. Frystyk Nielsen, "RFC1945 -- Hypertext Transfer Protocol -- HTTP/1.0," W3C/MIT, UC Irvine, W3C/MIT, May 1996.
[HTTP1.1]: R. Fielding, J. Gettys, J.C. Mogul, H. Frystyk, T. Berners-Lee, "RFC2068 -- Hypertext Transfer Protocol -- HTTP/1.1," UC Irvine, Digital Equipment Corporation, MIT.
[ISO3166]: "ISO3166: Codes for The Representation of Names of Countries." International Organization for Standardization.
[KEY]: S. Bradner. "RFC2119 -- Key words for use in RFCs to Indicate Requirement Levels." March 1997.
[MANDA]: H. Frystyk Nielsen, P. Leach, S. Lawrence. "Mandatory Extensions in HTTP," (draft-ietf-http-ext-mandatory-00). March 1998. IETF Internet Draft.
[MD5]: R. Rivest. "RFC 1321 -- The MD5 Message-Digest Algorithm," MIT. April 1992.
[MIME]: N. Freed, N. Borenstein. "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies." November 1996.
[SSL]: A. Freier, P. Karlton, P. Kocher. "SSL 3.0 Specification." (http://home.netscape.com/eng/ssl3/index.html)
[STATE]: Network Working Group, D. Kristol, Bell Laboratories, Lucent Technologies; Category: Standards Track HTTP State Management Mechanism. (ftp://ftp.isi.edu/in-notes/rfc2109.txt)
[URI]: T. Berners-Lee, R. Fielding, and L. Masinter. "Uniform Resource Identifiers (URI): Generic Syntax and Semantics." 1997. (Work in progress; see updates to RFC1738.)
[UTF-8]: F. Yergeau. "RFC2279 -- UTF-8, a transformation format of ISO 10646." January 1998.
[UUID]: The Open Group. "Universal Unique Identifier. Appendix CAE Specification C706." DCE 1.1: Remote Procedure Call. 1997.
[VCARD]: "RFC2426 -- vCard MIME Directory Profile", September 1998.
[XML]: T. Bray, J. Paoli, C. M. Sperberg-McQueen. "Extensible Markup Language (XML) 1.0 Specification." World Wide Web Consortium, Recommandation. 10-February-1998.
[XML-Data]: A. Layman et al. "XML-Data." World Wide Web Consortium, Note. 05-January-1998.
[XML-Name]: T. Bray, D. Hollander, A. Layman. "Namespaces in XML." World Wide Web Consortium, Working Draft. 16-September-1998.

Appendix 2: Fingerprints and Canonicalization (Normative:規範)

P3Pはプロポーザルやデータセットを確認する手段としてフィンガープリント（Message Digest,Hash）を用いる。これらのフィンガープリントはハッシュ関数を一連のデータに適用することで得られるある一定サイズの値を与える。フィンガープリントは容易に計算できるが、元の情報にほんの少しだけ修正を加えても、フィンガープリントは異なった値になる。従って、フィンガープリントはしばしば情報の完全性を保証する手段として用いられる。我々はP3Pのフィンガープリント用にMD5ダイジェストアルゴリズムを用いる。ことはP3P通信の中で暗号化され交換される128ビットの値を与えるものである。エージェントとサービスの双方は、与えられたプロポーザルの参照と処理の完全性を保証するために（フィンガープリントに対するプロポーザルの正当性を確認しながら）これらのフィンガープリントを用いることができる。

フィンガープリントを生み出すプロセスは相当シンプルなものである。フィンガープリントが同一であるためには、送信者と受信者によってフィンガープリント化されるデータが同一でなければならない。我々の目的は、仲介者のあらゆる改ざん努力を無駄にさせるため、データが標準形式（正規化）にフィンガープリント化されるよう推し進めることである。そうなれば我々はフィンガープリントを生成するために、正規化されたバージョンのプロポーザルを使うことになる。同じプロポーザルが与えられれば、サービスとエージェントの双方は同じフィンガープリント値に到達できなければならない。

プロポーザルの正規化ルール：

プロポーザルの最初の要素は、<PROP...>要素である。
すべての要素は大文字で、"<"で始まる。頭のスペースはすべて取り除かなければならない。
"<"とname要素の間にスペースがあってはならない。

要素が開く時、name要素は大文字で"<"の直後に書かれる。
要素が閉じる時、"<"の直後に"/"が書かれ、大文字のname要素が続く。

属性付きの要素について。

もし、PROPエレメントのagreeID属性がある時は、それは脱落する。
要素名と属性の間にスペースが1つ挿入される。
属性名は小文字でなければならず、直後に"="が続きさらに引用符で囲まれた属性データが続く。属性データは属性がnameの時は小文字に変換される。そうでない場合は文字通りと受け取られ、いかなる変更も許されない。

"/"は属性データの最後の引用句の直後になければならない。
すべての要素は"/"または引用符で囲まれたデータの直後の">"で閉じなければならない。
すべての">"の直後にCRLFがなければならない。
プロポーザルは</PROP>要素で終了する。

一例として、次のXMLを検討してもらいたい。

<rdf:rdf>
<P3P xmlns="http://www.w3.org/TR/1998/WD-P3P-19981109/" 
 xmlns:VOC="http://www.w3.org/TR/1998/WD-P3P-19981109/vocab"
 xmlns:DATA="http://www.w3.org/TR/1998/WD-P3P-19981109/basedata">
<STATES>
<PROP agreeID="94df1293a3e5" 
 realm="http://www.CoolCatalog.com/catalogue/" entity="htp://www.CoolCatalog.com" >
  <USES>
  <STATEMENT consq="A site with clothes you'd appreciate."
   VOC:purp="2,3" VOC:recpnt="0" VOC:id="0">
    <WITH><DATA:PREFIX name="User.">
      <DATA:REF name="Name.First"/>
      <DATA:REF name="Bdate.YEAR" optional="1"/>
      <DATA:REF name="Gender"/>
    </DATA:PREFIX></WITH>
  </STATEMENT>
  </USES>
  <USES>
  <STATEMENT ="rw" VOC:purp="0" VOC:recpnt="0" VOC:id="1">
    <DATA:REF name="User.shipping."/>
  </STATEMENT>
  </USES>
  <VOC:DISCLOSURE discURI="http://www.CoolCatalog.com/PrivacyPractice.html" 
   access="3" other="0,1"/>
  <ASSURANCE org="http://www.TrustUs.org" 
   text="third party" image="http://www.TrustUs.org/Logo.gif"/>
</PROP>
</STATES>
</P3P>
</rdf:rdf>

正規化の後、次のようになる。

<PROP realm="http://www.CoolCatalog.com/catalogue/" entity="http://www.CoolCatalog.com" > <USES> <STATEMENT consq="A site with clothes you'd appreciate." VOC:purp="2,3" VOC:recpnt="0" VOC:id="0"> <WITH> <DATA:PREFIX name="user."> <DATA:REF name="name.first"/> <DATA:REF name="bdate.year" optional="1"/> <DATA:REF name="gender"/> </DATA:PREFIX> </WITH> </STATEMENT> </USES> <USES> <STATEMENT ="rw" VOC:purp="0" VOC:recpnt="0" VOC:id="1"> <DATA:REF name="user.shipping."/> </STATEMENT> </USES> <VOC:DISCLOSURE discuri="http://www.CoolCatalog.com/PrivacyPractice.html" access="3" other="0,1"/> <ASSURANCE org="http://www.TrustUs.org" text="third party" image="http://www.TrustUs.org/Logo.gif"/> </PROP>

MD5フィンガープリントの生成

いったんプロポーザルが正規化されると、P3Pフィンガープリントを生成するためにMD5アルゴリズムが使われる。このセクションではMD5の概略の提供と、いかにしてMD5ダイジェストが暗号化されるかの説明を行う。

MD5 概略

MD5ハッシュアルゴリズムは以下で定義されている。

The MD5 Message Digest Algorithm, R.L. Rivest, RFC 1321, April 1992

MD5（Message Digest 5）は、暗号化メッセージ要約アルゴリズムである。

MD5はRon Rivestにより設計された。彼は1991年のRSAの"R"でもある。MD5はRFC1321に記述されている。CのソースコードがRFCに含まれている。MD5は基本的には"安全ベルト"付きのMD4であり、MD4よりわずかに速度が遅いがセキュリティ度は高い。アルゴリズムは4つの異なるラウンドから成り、それらはMD4のものとはわずかに異なる設計になっている。メッセージ要約サイズは同じ。

MD5アルゴリズムは、入力として任意の長さのメッセージを受け取り、出力として128ビットの"フィンガープリント"または入力の"メッセージ要約"を生成する。同じメッセージ要約を持つ2つのメッセージを作ることや、前もって指定されたメッセージ要約を持つメッセージを作ることは、コンピュータでできないものと思われる。MD5アルゴリズムはデジタル署名アプリケーションを意図している。そこでは大きなファイルは、RSAやPGPのような公開鍵暗合方式の下で個人（秘密）鍵によって暗号化される前に、あるセキュアな方法で圧縮されなければならない。

MD5のさらに詳しい情報は、以下を参照のこと。

P3P暗号化

MD5要約で計算すると、4つの32ビット値が生じる。すべての値は、2の補数表現を含むバイト列を標準的なBase64の表現で暗号化される。このバイト列の最初のバイトはhigh-orderバイトである。最小限の数のバイトが値を表現するために使われているため、使われないバイトが含まれていてはいけない。

以下のBNFはどのようにしてMD5要約がP3P用に暗号化されるかを示している。

resource-hash     = '"base64-string encoding of 128 bit MD5 message
                      digest of the information resource."'
base64-string     = as defined in RFC-1521, section 5.2.

Appendix 3: Line-flow Scenario (Non-normative)

このシナリオは、シナリオ1,5および3に基づいており交渉を含んでいる。

ユーザはブラウザでCoolCatalogのホームページに行く。彼女は以前に一度もそこに行ったことがない。彼女は、自分のブラウザがP3Pを理解することを伝えることにより、要求の一部としてP3Pプロポーザルを要求する。

GET / HTTP/1.1
Accept: */*
User-Agent: BugblatterBeast/3.02 (RT-11; English)
Host: www.CoolCatalog.com
OPT: "http://www.w3.org/TR/1998/WD-P3P-19981109/"; ns-42

CoolCatalogはプロポーザルを送信する。それはプライバシープラクティス、情報開示、それらが当てはまるデータエレメントを含んでいる。この例では、サービスは将来自動的にReturnIDの一部としてPUIDが与えられることを要求し、ユーザレポジトリからユーザの性別を要求する。

HTTP/1.1 409 Agreement required
Server: Marvin/2.0.1
OPT: "http://www.w3.org/TR/1998/WD-P3P-19981109/"; ns-1944
1944-P3P1.0: 
<P3P xmlns="http://www.w3.org/TR/1998/WD-P3P-19981109/" 
 xmlns:VOC="http://www.w3.org/TR/1998/WD-P3P-19981109/vocab"
 xmlns:DATA="http://www.w3.org/TR/1998/WD-P3P-19981109/basedata">
<STATES>
<PROP realm="http://www.CoolCatalog.com/" entity="http://www.CoolCatalog.com" >
  <USES>
  <STATEMENT VOC:purp="2" VOC:id="0" VOC:recpnt="0" consq="a personalized site!"/> 
    <DATA:REF name="Web.PUID"/>
    <DATA:REF name="User.Gender"/>
  </STATEMENT>
  </USES>
  <VOC:DISCLOSURE text="http://www.CoolCatalog.com/PrivacyPractice.html" 
   access="3" other="0,1"/>
  <ASSURANCE org="http://www.TrustUs.org" 
   text="third party" image="http://www.TrustUs.org/Logo.gif"/>
</PROP>
</STATES>
</P3P>
Content-Type: text/html
Content-Length: 110

<html><body>
<h1>HTTP/1.1 409 Agreement Required</h1>
<p>We need an agreement before we can continue.</p>
</body></html>

[注意：プロポーザルは読みやすいように複数の行にまたがって分割されている。ネットワーク上で、一対のCRLFが</PROP>だけの後ろに追加される。以下の例でも同様。]

ユーザはこのプロポーザルを拒否する。上記のプロポーザルの同意ID(hash)が "e3a5d71297d104f1"だと仮定する。ユーザの次のHTTP要求は次のようになるだろう。

GET / HTTP/1.1
Accept: */*
User-Agent: BugblatterBeast/3.02 (RT-11; English)
Host: www.CoolCatalog.com
OPT: "http://www.w3.org/TR/1998/WD-P3P-19981109/ "; ns-1776
1776-P3P: <SRY r="R-3" agreeID="e3a5d71297d1" />

サイトは新たなプロポーザルを提供し、今度は自動的なReturnIDを要求し、ユーザレポジトリからファーストネーム（名前）およびオプションで年齢を、共にサイトをカスタマイズする目的で要求する。

HTTP/1.1 409 Agreement required
Server: Marvin/2.0.1
OPT: "http://www.w3.org/TR/1998/WD-P3P-19981109/"; ns-1492
1492-P3P1.0: 
<P3P xmlns="http://www.w3.org/TR/1998/WD-P3P-19981109/" 
 xmlns:VOC="http://www.w3.org/TR/1998/WD-P3P-19981109/vocab"
 xmlns:DATA="http://www.w3.org/TR/1998/WD-P3P-19981109/basedata">
<STATES>
<PROP realm="http://www.CoolCatalog.com/" entity="http://www.CoolCatalog.com" >
  <USES>
  <STATEMENT VOC:purp="2" VOC:id="0" consq="a personalized site!">
    <WITH><DATA:PREFIX name="User.">
      <DATA:REF name="Name.First"/>
      <DATA:REF name="Bdate.Year" optional="1"/>
    </DATA:PREFIX></WITH>
    <DATA:REF name="Web.PUID"/>
  </STATEMENT>
  </USES>
  <VOC:DISCLOSURE text="http://www.CoolCatalog.com/PrivacyPractice.html" 
  access="3" other="0,1"/>
  <ASSURANCE org="http://www.TrustUs.org" 
   text="third party" image="http://www.TrustUs.org/Logo.gif"/>
</PROP>
</STATES>
</P3P>
Content-Type: text/html
Content-Length: 110

<html><body>
<h1>HTTP/1.1 409 Agreement Required</h1>
<p>We need an agreement before we can continue.</p>
</body></html>

ユーザは自動的なReturnIDとカスタマイズだけのためにファーストネームを用意することに同意する。上記のプロポーザルの同意IDが"94df1293a3e519bb"だと仮定する。

GET / HTTP/1.1
Accept: */*
User-Agent: BugblatterBeast/3.02 (RT-11; English)
Host: www.CoolCatalog.com
OPT: "http://www.w3.org/TR/1998/WD-P3P-19981109/"; ns-1861
1861-P3P1.0: <TXD r="S-0" agreeID="94df1293a3e5" >
 <DATA:REF VOC:purp="2" name="User.Name.First" value="Josephine"/>
 <DATA:REF VOC:purp="2" name="User.PUID" value="1234567"/>
</TXD>

この時点で、サービスはCoolCatalogのホームページを返す。

HTTP/1.1 200 OK 
Server: Marvin/2.0.1
OPT: "http://www.w3.org/TR/1998/WD-P3P-19981109/"; ns-1950
1950-P3P: <OK DH="s24fd20kuqexg5xk" />
Content-Type: text/html
Content-Length: xxx
[content of the CoolCatalog homepage]

ユーザは1日後サイトに戻り、自動的にReturnIDを送る。

GET / HTTP/1.1
Accept: */*
User-Agent: BugblatterBeast/3.02 (RT-11; English)
Host: www.CoolCatalog.com
OPT: "http://www.w3.org/TR/1998/WD-P3P-19981109/ "; ns-2001
2001-P3P: <TXD agreeID="94df1293a3e5" >
 <DATA:REF name="User.PUID" value="1234567"/>
</TXD>

しかし、サーバは再びユーザのファーストネームを必要とし、以前の同意の下でそれを要求する。

HTTP/1.1 409 Agreement required
Server: Marvin/2.0.1
OPT: "http://www.w3.org/TR/1998/WD-P3P-19981109/"; ns-2010
2010-P3P: <PROP agreeID="94df1293a3e5"/>
</PROP>
Content-Type: text/html
Content-Length: 70

<html><body>
<h1>HTTP/1.1 400 Agreement Required</h1>
</body></html>

ユーザは自分のファーストネームとPUIDを返す。

GET / HTTP/1.1
Accept: */*
User-Agent: BugblatterBeast/3.02 (RT-11; English)
Host: www.CoolCatalog.com
OPT: "http://www.w3.org/TR/1998/WD-P3P-19981109/"; ns-1968
1968-P3P1.0: <TXD agreeID="94df1293a3e5" >
 <DATA:REF name="User.Name.First" value="Josephine"/>
 <DATA:REF name="User.PUID" value="1234567"/>
</TXD>

サービスはその後、以前のようにホームページで応答する。

HTTP/1.1 200 OK 
Server: Marvin/2.0.1
OPT: "http://www.w3.org/TR/1998/WD-P3P-19981109/"; ns-1950
1950-P3P1.0: <OK DH="s24fd20kuqexg5xk" />
Content-Type: text/html
Content-Length: xxx
[content of the CoolCatalog homepage]

Appendix 4: ABNF Notation (Non-normative)

P3Pの正式な文法は、http://info.internet.isi.edu/in-notes/rfc/files/rfc2234.txtで定義されたABNFを若干修正したものを使いながらこの仕様書の中に示されている。以下は、ABNFの簡単な表現である。

name = (element): <name>が規則の名前であれば、<element>は1つまたはそれ以上の規則名もしくは端末を指し、以下のオペランドで結び付けられている。規則名は大文字/小文字を区別しない。
(element1 element2): 複数のエレメントはカッコでくくられており、1つのエレメントとして扱われる。規則名は大文字/小文字を区別しない。。
<a>*<b>element: 少なくとも<a>、多くとも<b>だけエレメントが発生する。; （1*4<element>は1～4つのエレメントの意味する。）
<a>element: 正確に<a>のエレメントが発生する。; （4<element>は正確に4つのエレメントを意味する。）
<a>*element: <a>以上のエレメント。; （4*<element>は4つ以上のエレメントを意味する。）
*<b>element: 0から<b>のエレメント。; （*5<element>は0～5つのエレメントを意味する。）
*element: 0以上のエレメント。; （*<element>は0～無限のエレメントを意味する。）
[element]: オプション的なエレメント。*1(element)と同等。; （[element]は0または１個のエレメントを意味する。）
"string" or 'string': 引用符内の文字列と一致。

その他の表記として、

; または /* ... */: コメント。

Appendix 5: Working Group Contributors (Non-normative)

Lorrie Cranor	AT&T
Philip DesAutels	Matchlogic
Melissa Dunn	Microsoft
Daniel Jaye (Editor)	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

この作業は他のドキュメントに基づいた。特に、

同様に、

Scenario	Existing Agreement	New Proposal	PUID Requested	Data Requested	Data Written
1	No	Yes	Yes	-	-
2	Yes	No	No	-	-
3	Yes	Yes	Yes	-	-
4	-	-	-	Yes	No
5	-	-	-	Yes	Yes

[21]	long-proposal	=	`<STATES><PROP` [" final=" yesno] ; default is 0 (No) [agreementid-attribute] [" agrexp=" `"` datetime `"`] ;default is six months " realm=" `"` URI (" " URI) `"` " entity=" quoted-URI [" postURI=" quoted-URI] [" optional=" yesno] ;default is 0 (No) ">" 1statement-block disclosure 1*assurance "</PROP></STATES>"
[22]	schemaURI	=	`"` "http://www.w3.org/TR/1998/WD-P3P-19981109/" `"`
[23]	quoted-string	=	`"` string `"`
[24]	string	=	<[UTF-8] string (with " and & escaped)>
[25]	quoted-URI	=	`"` URI `"';`
[26]	URI	=	<URI as per RFC 2068 [URI]>
[27]	datetime	=	<date/time as per section 3.3 of RFC 2068>