Copyright (C) 2000 W3C (MIT, INRIA, Keio), All Rights Reserved. W3C 責任、登録商標、, 文書の使用、 そして ソフトウエアライセンスに関する規則が適用される。
Copyright (C)2000 W3C(R) (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
本仕様書は、「プライバシー情報取り扱いに対する個人の選好を支持する技術基盤（Platform for Privacy Preferences、P3P）」 の仕様書である。標準書作成手順に従い、本文書は、相互互換性のあるP3Pアプリケーションのインプリメントに必要な総ての仕様を規定している。
この節では、文書の発行時における当該文書の位置付けについて記述する。しかし、この記述内容は、他の文書で置き換えられる可能性がある。本文書シリーズの最新の位置付けは、W3Cが決めている。
本文書は、W3Cのメンバーにレビューしてもらう為のW3Cワーキングドラフトである。本文書は、P3Pアクティビティの一つであるP3P仕様書ワーキンググループに依って作成されたものであり、また、1999年11月2日に発行されたラストコールドラフト(http://www.w3.org/TR/1999/WD-P3P-19991102)の改訂３版である。改訂内容を分かりやすくする為、その 改訂履歴を本文書の最後に示す。本文書のラストコールの期限は、2000年4月30日である。本文書の改訂版は、少なくとも2つの相互互換性のあるインプリメンテーションのデモンストレーションが実施されたならW3C勧告になる予定である。
本仕様書は、他の仕様書によりいつでも改版・置換・陳腐化の可能性のあるドラフトの仕様書である。従って、W3Cのワーキングドラフトを"進行中の作業"ではないとして参考文献資料やその他として参照することは不適切である。現在のW3Cワーキングドラフトはhttp://www.w3.org/TR/で参照可能である。
コメントをwww-p3p-public-comments@w3.orgに送って欲しい。（http://lists.w3.org/Archives/Public/www-p3p-public-comments/に記録されている）。もしくは、コメントを公にしたくないならば、p3p-comments@w3.orgに送って欲しい。この場合、あなたのコメントはW3Cのメンバからのみアクセス可能となる（そのアドレスはhttp://lists.w3.org/Archives/Member/p3p-comments/である）。
The Platform for Privacy Preferences Project (略称P3P)は、Webサイトが標準形式でそのサイトのプライバシープラクティスを表現することを可能にし、その標準形式データをユーザエージェントが自動的に取りこんだり、簡単に処理したりすることを可能にする。P3Pユーザエージェントはサイトのプライバシープラクティスを利用者に(マシンリーダブルの形式、及び人間が読むことのできる（ヒューマンリーダブルの）形式で)通知することができ、プライバシープラクティスが適切ならば、自動意思決定を行うことも可能である。P3Pユーザエージェントのこの自動意思決定機能を用いれば、利用者は、アクセスするサイトの総てのプライバシーポリシーを逐一読む必要が無くなる。
P3Pは、利用者が、個人情報を受け渡す前にサイトのプライバシーポリシーを知ることを可能にするメカニズムを提供するが、そのサイトがそのポリシーに従った行動をすることを保証するメカニズムを提供するものではないことに注意されたい。本仕様書の内容を実装した幾つかのプロダクトは、そのような保証の支援メカニズムを有するかもしれないが、それは、個々の実装上の都合によるものであり、本仕様の範囲外である。しかしながら、P3Pは、プライバシーに関する法律や自主規制プログラムを補完するものであり、それらを強化するメカニズムを提供することができる。更に付け加えるならば、P3Pは、データ転送のメカニズムを提供するものではなく、また、データの保管を安全に行うためのメカニズムを提供するものでもない。P3Pは、データ転送を可能にするツールの中に組み込まれ、それらのツールは、適切な機密保護機構を有しているべきである。
P3P1.0仕様書は、P3Pプライバシーポリシー（P3Pポリシー）のためのシンタックスとセマンティクスとを定義しており、そして、Webリソースにポリシーを付加するためのメカニズムを定義している。P3Pポリシーは、プライバシーに関する処理を如何に行うかを表現する為に用いられるP3Pボキャブラリを使って組み立てられるステートメントから構成されている。P3Pポリシーは、P3P基本データスキーマの要素を使用する。P3P基本データスキーマとは、データ要素の一つの標準集合のことを言い、総てのP3Pユーザエージェントは、これを処理できなければならない。P3P仕様書は、新たなデータ要素やデータ集合を定義可能とするメカニズムを規定しており、また，P3Pボキャブラリを増やすことを可能とする簡単なメカニズムも規定している。
P3Pバージョン1.0は、Webサイトがデータ収集を如何に行うかをWeb利用者に通知することを目的に設計されたプロトコルである。P3Pバージョン1.0は、Webサイトがデータ収集と収集したデータの処理とをどの様に行うかをマシンリーダブルのXML形式のP3Pポリシーにコード化する方式を提供する。P3P仕様書は、次の定義を行っている。
P3P1.0の最終目的は、次の二つである。最初の一つは、Webサイトがデータ収集を如何に行うかを標準化され、マシンリーダブルで、且つ、簡単な方法で、提示することを可能とすることである。二つ目は、Web利用者がアクセスするWebサイトが、どんなデータを収集し、どの様にデータが使われるかWeb利用者が知ることができ、どのデータやどんな利用をWeb利用者が"オプトイン"または"オプトアウト"することが可能か知ることができるようにすることである。
P3Pを理解する為、P3Pを利用する一つの事例を考えてみよう。 花子さんは、CatalogExample社(そのURLがhttp://www.catalog.example.com/)と呼ばれるあるサイトを見ようと思ったと仮定し、そのCatalogExample社は総てのページにP3Pポリシーを附加しているものと仮定する、更に、花子さんは、P3P対応のブラウザを利用しているものとする。
花子さんが、ブラウザ上でCatalogExample社のURLを指定したとすると、CatalogExample社からホームページ情報を返すとき、花子さんのWebブラウザは自動的にそのページに対応したP3Pポリシーを持って来る。そのポリシーには、当該ページでは標準のHTTPアクセスログに含まれるデータのみを収集すると記述しているものとする。花子さんのブラウザは、そのポリシーを予め花子さんがブラウザに与えておいたプリファレンスと照合し、そのポリシーが受け入れ可能か、又は、花子さんに通知すべきかチェックする。そのポリシーが受け入れ可能だったと仮定すると、この場合、ホームページは、如何なるポップアップメッセージも表示されること無しに表示される。多分、ウィンドウの片隅に小さなアイコンが表示され、サイトからプライバシーポリシーが提示され、そのポリシーは、彼女のプリファレンスに合致していることを示すであろう。
次に、花子さんが、当該サイトのオンラインカタログのリンクを選択したとすると、当該サイトのカタログ部分で少し複雑なソフトウェアが実行されるようになっていて、このソフトウェアがショツピングカート機能を実現する為に、クッキーを用いていたとすると、当該Webサイトのこの部分は、より多くの情報を収集するので、Webサーバは、花子さんのブラウザに新しいP3Pポリシーを送信する。この場合においても、当該ポリシーが花子さんのプリファレンスに合致したと仮定すると、何のポップアップメッセージが表示されることなく、花子さんは、操作を継続でき、何かを購入したりして、最後にチェックアウトページに進むことができる。
CatalogExample社のチェックアウトページは、何らかの追加情報を必要とする。例えば、花子さんの名前、住所、クレジットカード番号及び電話番号等である。この場合、当該Webサイトは、どんなデータをここで収集し、ここで収集した彼女のデータは、彼女の注文を処理する為にのみ使用すること等を記述した新しいP3Pポリシーを送信する。
花子さんのブラウザは、このP3Pポリシーを調べ、例えば、花子さんが、ブラウザにもしも、電話番号の要求があったならば、警告を通知するよう設定しているならば、ポップアップメッセージで、電話番号が要求されていることを通知し、且つ、P3Pステートメントの内容についても説明する。そこで、花子さんは、要求されたものが受け入れ可能か否か判断することができ、もし、受け入れ可能であるならば、彼女は、注文操作を継続することができ、受け入れることができないならば、トランザクションをキャンセルすることができる。
上記の場合と異なり、花子さんが、ブラウザに「サイトが電話番号を要求し、そして、その情報を第三者に渡し、そして／または、現在の注文処理以外に用いるならば、警告する」ように設定しているならば、花子さんは、如何なるポップアップメッセージが表示されることなく、注文操作を完了することができる。
(注)本シナリオは、あくまでも仮想のインプリメンテーションであり、ユーザインターフェースは、上記以外のものも可能である。
P3Pポリシーは、ポリシーの中にプライバシー情報を如何に処理するか表記している組織を識別するためP3PボキャブラリのXMLエンコーディングを用い、収集されるデータ型とデータ要素を列挙し、そして、どの様にデータが使われるか説明する。更に、ポリシーは、データの受領者を明確にし、係争解決のための情報のような情報開示にまつわる諸々のものを作成可能にし、当該サイトの人間が読むことのできるプライバシーポリシーの存在場所(URL)の通知を行う。P3Pポリシーは、関係する総てのデータ要素とそれをどう使うかカバーしなければならない。(しかし、法の執行の際に必要とされる情報に関する法律的問題はこの仕様書では関知しない。：例えば、公権力によって要求された場合、第三者に提供しないはずのデータがポリシーの規定に反して、他の組織に提供されることがあるかもしれない。)P3Pの記述は、ポジティブな記述であるべきである。すなわち、或るサイトが何々をしないと記述するよりは、何々を行うと記述することが望ましい。P3Pボキャブラリは、或る特殊な法律や行動規範に準拠するためのインディケータと言うより、サイトがプライバシー情報を如何に取り扱うかを記述することを目的に設計されている。しかしながら、幾つかのユーザエージェントは、サイトのプライバシー情報の取り扱い方が法律や行動規範に合っているか否かテストするために、開発されるかもしれない。
P3Pポリシーは、サイトがプライバシー情報を如何に取り扱うかを表現する。しかし、電気通信プロバイダやISP、プロキシ業者、その他の中間業者が、サイトと利用者との間のプライバシーデータ交換に関与するが、それらの中間業者が何を行っているかについて、サイトのポリシーは関与しない。
P3P1.0ユーザエージェントは、Webブラウザか、ブラウザプラグインか、プロキシサーバに組み込まれることができる。また、それらはJavaアプレットもしくは、JavaScriptで実装され、電子財布や自動フォーム入力やその他の利用者データ管理機能の中に組み込まれるかもしれない。P3Pユーザエージェントは、HTTP応答の中にあるP3Pヘッダ及びHTMLコンテンツの中に埋め込まれているP3P LINKタグを捜す。これらの特殊ヘッダとタグとは、関係するP3Pポリシーの存在場所を示している。ユーザエージェントは、示された存在場所からポリシーを取り込み、それを解析し、シンボルを表示したり、音を鳴らしたり、サイトのP3Pプライバシープラクティスを示すプロンプトメッセージを生成したりする。更に、ユーザエージェントはP3Pポリシーを利用者が設定したプライバシープリファレンスの集合と比較し、適切な処理を行うことが可能である。P3Pは、電子財布や自動フォーム入力のようなデータ転送メカニズムにおけるある種の"ゲートキーパー"の機能を行うこともできる。或るP3Pユーザエージェントは、P3Pポリシーを検索したり、利用者のプリファレンスと比較したり、次の二つの条件を満たしたときデータを送出するメカニズムの何れか中に統合されるかもしれない。a)ポリシーが、利用者のプリファレンスと一致している。そして、b)要求されたデータ転送が、ポリシーと一致している。もしも、これらの条件の何れかに合致していないならば、利用者に、不一致の通知と、データを送出するか否か選択する機会が与えられるべきである。
Webサイトは、利用者に文章で開示しているプライバシーポリシーをP3Pシンタックスに翻訳し、それを公開することにより、P3P1.0を実装することができる。自動化ツールにより、この翻訳を行うサイトの運営者を支援することが可能である。P3P1.0はソフトを特に追加したりアップグレードすることなく、現在のHTTP1.1準拠のWebサーバにおいて構築できる。サーバは周知の存在場所からプライバシーポリシーを構築できるし、あるいはLINK タグを使ったHTMLコンテンツでP3Pポリシーを参照するかも知れない。または、互換性のあるサーバHTTP拡張フレームワークを用いて、HTTP応答中に、サイトのP3Pポリシーの存在場所を示すP3P拡張ヘッダを挿入するようサーバを構築できるであろう。
Webサイトは、サイト全体に一つのP3Pポリシーを付与することもできるし、そのサイトの異なる部分に異なるポリシーを指定するといったこともできる。ある一つのP3Pポリシーは、そのサイトへの訪問者とHTTPでやりとりする際に生成されたり、交換されたりするすべてのデータをカバーするものでなければならない。更に言うと、幾つかのサイトは、データがどの様に収集されたかにかかわらず、総てのデータをカバーするP3Pポリシーを作ることを望むかもしれない。
P3P仕様書ワーキンググループは、当面の、P3Pの早期の実装と普及を促進するため、初期のP3P1.0 仕様書に記述してあった重要な機能を削除している。当該グループは、P3P1.0が普及した時点で、 P3Pの次期仕様書を公開することを予定している。次期仕様書には、実装経験や普及時の経験を反映させるとともに、P3P1.0から落とされた、次の４つの重要な機能を盛り込む予定である。
W3Cの正式仕様書作成手順に従い、本仕様書は、相互互換性のあるP3Pアプリケーションの作成に必要とされる総ての仕様を包含している。
本仕様書で用いられている[ABNF]記述は、RFC2234に従ったものであり、その概略を付録 6に示す。しかし、その構文は、XML構文で示される単なる一つの文法であることに注意されたい。そうであるけれども、XMLで表現できる構文の意味するところの総てを理解することができるであろう。例えば、空白規則、引用符(')や二重引用符(")を用いた引用、エスケープ文字、コメント、各部分での記述方法などである。
更に、属性と要素は、任意の順序で使えることに注意されたい。本仕様書は、必要性の程度を表す為、RFC2119 [KEY]に定義されている次の用語を用いる。次の重要な用語が、相互互換性を実現する為に、本文書全体を通して用いられている。
ワーキンググループはP3P1.0で必要な追加の特徴が明確になる実装チームからのインプットによることを決定した。ワーキンググループは必要となる追加の特徴を決めたが、このドラフトの執筆の時点でその特性を指定することについての仕事が完了しなかった。その特徴を実装可能なガイダンスとして以下に列挙する。
P3Pポリシーを参照することは、P3Pプロトコル工程における初期段階のステップである。サービスは、どのP3Pポリシーが特定のどのURI、またはURIの集合に適用するかを述べる為にポリシー参照を使用する。ユーザエージェントは、ページに適用されたプライバシーポリシーを発見する為にポリシー参照を使用する。従って、ユーザエージェントは、利用者のためにポリシーを処理することが出来る。
ポリシー参照は、パフォーマンスの最適化として使われる。プライバシーポリシーを参照しているURIは、通常100バイト以下であるが、プライバシーポリシーは通常、数キロバイトのデータである。帯域幅の節約に加えて、ポリシー参照は、コンピュータの演算処理の必要性を軽減する：ポリシーは、URIとユニークに関連付けられることが出来る。従って、ユーザエージェントは、ポリシーが適用されているドキュメント毎にポリシーを処理する必要はなく、一度ポリシーを解析し、処理すればよい。さらに、中央集権化された場所に、関連のあるポリシーに関する情報を置くことによって、Webサイトの管理が簡素化される。
ポリシー参照ファイル（policy reference file）は、ポリシーとURIを関連付ける為に使用される。ポリシー参照ファイルの存在場所は、二つの方法のうち一つを使用して指定することができる。ポリシー参照ファイルは、"周知の"存在場所としてあらかじめ定義された中で位置付けられるかも知れない。あるいは、ドキュメントはHTMLのLINKタグ、または、HTTP拡張フレームワーク（HTTP Extension Framework）を使用することによって、ポリシー参照ファイルを指し示すかも知れない。ポリシー参照ファイルは、ドキュメントや他のURIなどに適用されるP3Pポリシーを指定する。ポリシー参照ファイルは、[RDF]/[XML]ファイルであり、単一のWebドキュメントや、Webサイトの幾つかの部分、又はWebサイト全体の為のポリシーを指定することが出来る。ポリシー参照ファイルは、複数のP3Pポリシーを参照するであろう。この事は、異なるP3Pポリシーが、サイトの異なる部分に適用されているにもかかわらず、単一の参照ファイルのみでサイト全体をカバーする事を許可する。
ポリシーは、HTTPの実体と同等に利用されることに注意すること。URIをフェッチする事によって取得された実体は、実体に関連したP3Pポリシーを持っている。利用者から見た"ページ"は、複数のHTTPの実体によって作成されているだろう。個々の実体は、それ自体に関連した独自のP3Pポリシーを持つだろう。しかしながら、現実的な注意点として、単一のページ上にある異なる実体に、多くの異なるP3Pポリシーを置くことはページを表現するが、ユーザエージェントが利用者に関連するポリシーを知らせる事を困難にする。加えてサービスは、作成したいかなる"ページ"をもカバーする単一のポリシー参照ファイルを念入りに作成する事を試みるべきである。
ユーザエージェントが所定の組織に適用されるポリシーを処理するためには、その組織のポリシー参照ファイルの位置を定めなければならず、そのポリシー参照ファイルを取って来て、ポリシー参照ファイルを解析し、必要とされる全てのP3Pポリシーを取って来て、そしてP3Pポリシーまたはポリシーを解析する。
HTTP以外の方法で取得されたドキュメントとP3Pポリシーとをどの様にして関連付けるかに関し、このドキュメントにおいては指定していない。しかしながら、他のプロトコルの上で運ばれてきたドキュメントとP3Pポリシーを結び付けることに対してはメカニズムの将来の開発を妨げない。
この節では、二つのサポートされているメカニズムを使用して、ポリシー参照を作成する為に使用されるシンタックスを説明する。
P3Pを使っているWebサイトはポリシー参照ファイルを"周知の"存在場所に置くことを決めるかもしれない。このために、ポリシー参照ファイルはそのサイトのルートディレクトリにp3p.xmlという名前で置かれるだろう。それによって、ユーザエージェントは/p3p.xmlのリソースを要求するGETリクエストを使ってポリシー参照ファイルを要求することができる。
サイトがこのメカニズムを使う必要がないことに注意。さらに、もしサイトがこのメカニズムを使うことに決めるなら、周知の存在場所に位置しているポリシー参照ファイルが全部のサイトをカバーする必要はない。例えば、内容のすべてがひとつの組織の管理下にあるわけではないサイトは、このメカニズムを使わないことを決めるかもしれない。あるいはそのサイトで限られた部分のみをカバーするポリシー参照ファイルを置くことを決めるかもしれない。
ポリシー参照ファイルのために周知の存在場所を使うことは、ポリシー参照ファイルを指定するような他のメカニズムの使用を妨げるものではない。サイトの一部においては、一義性条件が満たされる範囲において、ポリシー参照ファイルを指定する他のメカニズムを使うかもしれない。
例えば、MallExample社のWebサイトショッピングモールを考えると、そのWebサイト（mall.example.com）において、そのモールで商品あるいはサービスを提供している会社は/companies/company-nameのパスで表せるような、そのサイト特定のサブツリーを得るだろう。そのMallExample社はポリシー参照ファイルを、/companiesサブツリーを除いた全てをカバーするような周知の存在場所に置くことを決めるかも知れない。その場合、ShoeStoreExamples社は、/companies/shoestoreexampleといったコンテンツを持つが、その会社は、mall.example.comサイトの一部をカバーするポリシー参照ファイルの存在場所を示すその他のメカニズムを使うこともできる。
ポリシー参照ファイルのために周知の存在場所を使うことが特に有効であると予想される1つのケースとしては、アプリケーションサーバを分散するようなケースにある。ポリシー参照ファイルの存在場所を指定することを許す他のメカニズムは、アクセスされたホスト上においてポリシー参照ファイルの存在場所を持ってくるアクションURIが必要である。しかしながら、周知の存在場所を示すメカニズムは、そのような必要がない。www.example.comに位置するHTMLフォームの例を考えてみる。サーバcgi.example.comを指すフォームが動作するURIを考える。そのフォームをカバーするポリシー参照ファイルは、フォームを処理するためのアクションURIに関するどんなステートメントも作ることができない。しかしながら、サイト管理者はアクションURIをカバーすることができるhttp://cgi.example.com/p3p.xmlでポリシー参照ファイルを公開する。それにより、フォームのコンテンツを提出する前に、ユーザエージェントが容易にアクションURIに相当するP3Pポリシーを見つけることができるようにする。
P3PはHTTP拡張フレームワーク[HTTP-EXT]を使用する。HTTP拡張フレームワークでは、新規のHTTPヘッダを定義し、使用することができる。リクエストやレスポンスにおいて、作成された拡張と関連付けられた全てのHTTPヘッダには、任意の２桁のネーム空間識別子が前置される。この2桁の識別子は、メッセージ毎に実装者によって選択されるであろう。この事は、拡張ヘッダにおけるユニークなネーム空間を保証する。加えて、拡張は、ネーム空間を宣言する時に、自分自身を（URIと）同じものとして扱わなければならない。
HTTP拡張フレームワークは、拡張（拡張宣言（extension declaration））を示す世界的にユニークなURIを必要とする。P3Pでの拡張宣言は、以下のURIである：
http://www.w3.org/2000/P3Pv1
HTTPによって取得されるドキュメントは、新規のレスポンスヘッダであるPolicyRefヘッダを使用することによって、ポリシー参照ファイルを指し示すであろう。PolicyRefヘッダは、ポリシー参照ファイルのURIを含み、それは同様に参照ファイルと、もしかすると他のものを指し示したドキュメントをカバーしているP3Pポリシーを述べるだろう。このURIは、P3Pポリシーを確認、参照する目的以外で使用してはならない。
P3Pを利用できるサーバが、HEADとOPTION要求に応答する場合を含む、適切な要求に対して応答する場合は、必ずP3P拡張宣言とポリシーヘッダ参照を挿入すべきである。
P3Pを利用できないユーザエージェントが、適切に解釈を行い、P3Pポリシー参照を含んだレスポンスを処理することが可能である為、P3Pは、HTTP拡張フレームワークの点からして"任意"のものである。ポリシー参照は、応答の連鎖に従って、いかなる存在場所においてもユーザエージェントによって処理されるので、P3Pは端と端をつなぐHTTP拡張である。従って、P3P拡張を宣言する為に使用されるヘッダは、Optであるだろう。
ポリシー参照ヘッダのシンタックスは:
| [1] | policy-reference-header |
= |
nsprefix `-PolicyRef: ` URI |
| ここでURIはRFC 2396[URI]に従って定義されている。nsprefixは[HTTP-EXT]に従って、メッセージ内において、P3Pヘッダの為に選択された2桁のネーム空間宣言である。このネーム空間は、レスポンスにおいて他のネーム空間宣言と重複しない2桁の数字であればいかなるものでもよい。 | |||
ヘッダのPolicyRef部分は、他のHTTPヘッダ規則に従っていかなる字体で書かれてもよい。（例えば大文字/小文字の区別はしない）
例 2.1: １．クライアントはGET要求を行う。２．サーバはコンテンツとポリシーのページを指し示すPolicyRefヘッダを返信する。GET /index.html HTTP/1.1 Host: catalog.example.com Accept: */* Accept-Language: de, en User-Agent: WonderBrowser/5.2 (RT-11)
HTTP/1.1 200 OK Opt: "http://www.w3.org/2000/P3Pv1"; ns=11 11-PolicyRef: http://catalog.example.com/P3P/PolicyReferences.xml Content-Type: text/html Content-Length: 7413 Server: CC-Galaxy/1.3.18
サーバは、適切なP3Pポリシー参照ファイルの存在場所を示したlinkタグが埋め込まれたHTMLコンテンツを提供するだろう。このP3Pの使用方法は、P3Pに準拠したサーバを必要としない：コンテンツは、サーバの運用方法の変更なしに、埋め込みlinkタグを含むように変更されるだろう。
linkは、P3PのPolicyRefヘッダを使用して表現される情報を記号化する。linkタグは以下の形式をとる：
| [2] | p3p-link-tag |
= |
`<link rel="P3Pv1" href="` URI `">` |
| ここで、URIはRFC 2396 [URI]に従って定義されている。 | |||
例えば、例2.1のように、HTTPヘッダを使用して表現されているポリシー参照は、http://catalog.example.com/index.htmlのWebページ内に、以下のHTML部分を含むことによって同等に表現できる：
<link rel="P3Pv1"
href="http://catalog.example.com/P3P/PolicyReferences.xml">
HTMLドキュメントに埋め込まれたp3p-link-tagの文字エンコーディングは、HTMLドキュメントと同じになる。P3Pポリシーとポリシー参照ドキュメント（2.3章と下の3章)とを対照すると、p3p-link-tagは[UTF-8]を使ってエンコードする必要はない。
ユーザエージェントがHTMLを処理する場合、ユーザエージェントは両方のメカニズム（HTTPヘッダ内のポリシー参照又はlinkタグ）を互換的に処理しなければならないことに注意すること。両方のメカニズムは、互いにオーバーライドしない。一義性の要求事項も参照すること。
ポリシー参照ファイルは、P3PポリシーとURI空間の決まった領域とを関連付ける為に使用される。ドキュメントがポリシー参照ファイルにリンクするために使うメカニズムにかかわらず、その参照ファイルのシンタックスは同じのままである。ポリシー参照ファイルは、以下のステートメントの幾つか、又は全てを作成するために使用される：
最初の四つのステートメントは、ポリシー参照ファイルのボディー部に作成され、最後のステートメントはポリシー参照ファイルにHTTP expirationヘッダを使用して作成される。
Webサイトが以下のステートメントを作成したいというケースを考えた場合：
上記のステートメントは以下の[RDF]によって表記される：
例 2.2:
<POLICY-REFERENCES
xmlns="http://www.w3.org/2000/P3Pv1"
xmlns:web="http://www.w3.org/1999/02/22-rdf-syntax-ns#" >
<web:RDF>
<POLICY-REF web:about="/P3P/Policy1.p3p">
<PREFIX>/</PREFIX>
<EXCLUDE>/catalog/</EXCLUDE>
<EXCLUDE>/cgi-bin/</EXCLUDE>
<EXCLUDE>/servlet/</EXCLUDE>
</POLICY-REF>
<POLICY-REF web:about="/P3P/Policy2.p3p">
<PREFIX>/catalog/</PREFIX>
</POLICY-REF>
<POLICY-REF web:about="/P3P/Policy3.p3p">
<PREFIX>/cgi-bin/</PREFIX>
<PREFIX>/servlet/</PREFIX>
<EXCLUDE>/servlet/unknown</EXCLUDE>
</POLICY-REF>
</web:RDF>
</POLICY-REFERENCES>
このポリシー参照ファイルへのクレームの有効期間が8時間であることを示す為に、このページを提供するサーバは、このファイルと共にCache-Control: max-age=28800ヘッダを返信するだろう。代替案として、このサーバはレスポンスにおいて、Dateヘッダから8時間後を示したExpiresヘッダを生成するだろう。
この節では、P3Pポリシー参照ファイルのシンタックスとセマンティクスを定義する。全てのポリシーは、[UTF-8]を使用してコード化されなければならない。P3Pサーバは、このシンタックスを使用してポリシー参照をコード化しなければならない。P3Pユーザエージェントは、このシンタックスを解析できなければならない。
ポリシー参照ファイルのシンタックスに関しての重要なポイントは、ここで定義されているシンタックスは、拡張機能を持たないという事である。P3Pポリシーのシンタックスは強力な拡張機能（powerful extension mechanism）を持っているが、ポリシー参照ファイルは、この機能をサポートしていない。
ポリシー参照ファイルの有効期限は、ユーザエージェントに対し、参照ファイル内のクレームがどれくらいの期間有効であるかを告げる。例えば、ポリシー参照ファイルが16時間の有効期限を持っている場合、ユーザエージェントは16時間ファイルをリロードする必要がなく、参照ファイルからの参照は16時間有効であると仮定することが出来る。単一のポリシー参照ファイルから参照される全てのポリシーは、同じ有効期限を持つであろう。P3Pプライバシーポリシーの為に異なる有効期限を指定したい場合の唯一の方法は、個々のP3Pポリシー毎に、異なるポリシー参照ファイルを使用する事である。
ポリシー参照ファイルの有効期限は、参照ファイルと共に提供されたHTTP cache controlヘッダによって決定される。しかし、ユーザエージェントは参照ファイルの有効期限を算出する為に、ファイルの更新日を基にした有効期限の算出を使用してはならない。ユーザエージェントは、参照ファイルと共に提供される "Expires"、"Cache-Control"、"Pragma" ヘッダが利用可能であるならば、それらのヘッダを基にポリシー参照ファイルの有効期限を算出しなければならない。それらのヘッダのセマンティクスは、[HTTP]によって定義されている。もしそれらのヘッダが利用できない場合、有効期限はサーバがドキュメントを送信した時点から24時間にセットされなければならない。サーバは、ポリシー参照ファイルの有効期限を明白に提供する為に、上記のヘッダの一つを使用すべきである。
ネットワーク上でのキャッシュの存在の可能性と、HTTPでの有効期限の自己発見機能は、有効期限の考慮をかなり複雑なものとする。キャッシュの有効期限がサーバによって明白に定義されていないポリシー参照ファイルの場合を考えた場合（例：レスポンス内に上記のいかなるヘッダも含まれていない）、ネットワークキャッシュは、間違いなく更新日を基にポリシー参照ファイルのキャッシュ有効期限を算出するであろう；結果としてのキャッシュの有効期限は、24時間より非常に長くなるであろう。もしユーザエージェントがこのポリシー参照ファイルをHTTP 1.0 cacheから取得した場合、ユーザエージェントはどのくらいの期間この参照ファイルがキャッシュされていたかを知る方法はない。従って、ユーザエージェントは、参照ファイルの有効期限が既に切れているかどうか、又はいつ有効期限が切れるかを知ることは不可能である。HTTP 1.1に準拠したキャッシュは、キャッシュから要求を満たす時に、Ageヘッダを送信しなければならないので、HTTP 1.1 cacheでは、ややこの状況を改善している。しかしこれだけでは十分ではない；キャッシュは、ここで定義されている24時間の有効期限を越えたファイルを返信することが出来きるので、結果として意味のないポリシー参照ファイルとなる。この問題を回避する為、ユーザエージェントは、ポリシー参照ファイルを取得する時に、最新のファイルをロードすることを保証しなければならない。従って、ユーザエージェントは、ポリシー参照ファイルを取得する時に、Pragma: no-cache又はCache-Control: no-cache要求ヘッダのどちらかを含まなければならない。HTTP 1.0 chacheとの互換性の為、Pragma: no-cache要求ヘッダの方が推奨される。
クライアントが、HTTP要求に影響を及ぼす遅延を正確に予測することは不可能であることに注意すること。従って、もし要求をカバーするポリシー参照ファイルの有効期限がすぐに切れる場合、クライアントは利用者に注意を促し、（又は）要求の遂行を続ける前にポリシー参照ファイルを再検証することを望んでも良い。
POLICY-REFERENCES要素は、完全なポリシー参照ファイルを含む。ポリシー参照ファイル内には、必ず一つのPOLICY-REFERENCES要素がなければならない。この要素は、RDF要素を一つ含まなければならない。
| [3] | policies |
= |
`<POLICY-REFERENCES xmlns="http://www.w3.org/2000/P3Pv1" ` rdf-ns-def `>` rdf `</POLICY-REFERENCES>` |
| [4] | rdf-ns-def |
= |
xmlns `:` rdf-ns-prefix `="http://www.w3.org/1999/02/22-rdf-syntax-ns#"` |
| [5] | rdf-ns-prefix |
= |
NCName |
| ここで、NCNameはNamespaces in XML [Namespace]で定義されている。 | |||
RDF要素は、ポリシー参照ファイル内のRDF表記をカプセル化する。この要素は複数のPOLICY-REF要素（ポリシー参照）を含まなければならない。
| [6] | rdf |
= |
`<` rdf-ns-prefix `:` `RDF>` policy-ref `</` rdf-ns-prefix `:` `RDF/>` |
ポリシー参照ファイルは、個々の情報を指定することによって、複数のP3Pポリシーを参照するだろう。POLICY-REF要素はRDFリソースであり、単一のP3Pポリシー属性を記述する。POLICY-REF要素内の要素は、ポリシーの存在場所を提供し、個々のポリシーがカバーするURI空間の領域を指定する。
| [7] | policy-ref |
= |
`<POLICY-REF ` rdf-ns-prefix `:` `about="` URI `">` *prefix *exclude *method-element `</POLICY-REF>` |
| ここで、URIはRFC 2396 [URI]に従って定義されている。 | |||
個々のPREFIX要素又はEXCLUDE要素は、単一のローカルURI-prefixを指定する。それらの要素は、含まれているPOLICY-REF要素によって示されるポリシーによってカバーされるWebサイトの一部を特定する為に使用される。
PREFIX要素（任意でEXCLUDE）がPOLICY-REF要素内に存在する場合、POLICY-REF要素のspace属性において指定されているポリシーは、要求したホストにおいて、PREFIXによって指定されているlocal-URIに一致する全てのURIに適用される事を意味し、EXCLUDE要素によって指定されたURIは含まない。
METHOD要素が一つ以上のポリシー参照を含むことを規定する。それはつまり、記述されなかった全てのメソッドが、必然的にこのP3Pポリシーによってカバーされないことを意味する。この場合、これは与えられたURI-refixのためのポリシー参照だけとなり、ユーザエージェントは、メソッドがポリシー参照ファイルで記述されなかった全てにポリシーが実施されないとみなさなければならない。
PREFIX要素がPOLICY-REF要素内に含まれていない場合、hrefによって与えられたポリシーは、ポリシー参照ファイルにリンクされているリソースに対して適用されると無条件に仮定されなければならない。ポリシー参照ファイルがPREFIX要素なしに、二つ以上のPOLICY-REF要素を持つことは誤りである。PREFIX要素なしにEXCLUDE要素を提供する事は、間違いではないが、意味のないことである；この場合EXCLUDE要素は、ユーザエージェントによって無視されなければならない。
ポリシー参照ファイルは、参照ファイルとして、同一ホスト上のURIのみをカバーすることが出来る。従ってPREFIX要素とEXCLUDE要素は、ローカルURIのプレフィックスを指定しなければならない；それらの要素は、他のホスト上にあるURIを参照してはならない。この要求事項は、P3Pポリシーファイル（POLICY-REF要素におけるweb:about属性）の存在場所には適用されない。
ポリシー参照ファイルは、いかなる正規表現の種類もサポートしていないことに注意すること。POLICY-REF要素内において唯一提供されている機能は、最新のドキュメント（PREFIX要素を含まないことによって必ず）を参照することや、相対URI-Prefixを使用することである。例えば、".asp"という拡張子で終わっている全てのURIに適用される確実なP3Pプライバシーポリシーや、't'という文字を3個以上含んでいるURIに適用される確実なP3Pプライバシーポリシーを述べることは不可能である。
さらに、PREFIXとEXCLUDEのマッチングは単純な文字列上のマッチングで行う。結果として、ディレクトリの末尾の“/”が欠けたりした場合、予期しない結果がもたらされるかもしれない。例えば、<EXCLUDE>/images/logos</EXCLUDE>要素（hrefの末尾に'/'が欠けている事に注意）は、/images/logos/サブディレクトリ内の全てのリソースを排除するだけでなく、例えば、相対的なURIの/images/logoschool.jpgファイルも排除するであろう。
| [8] | prefix |
= |
`<PREFIX>` URI`</PREFIX>` |
| [9] | exclude |
= |
`<EXCLUDE>` URI `</EXCLUDE>` |
| ここで、URIはRFC 2396 [URI]に従って定義されている。 | |||
ディフォルトでは、ポリシー参照は、リソースにアクセスする為に使用されるメソッドに関係なく指定されたURIに適用される。しかしWebサイトは、リソースに適用されるメソッドに応じて、異なるP3Pポリシーを定義したいかもしれない。例えばサイトは、利用者がGETメソッドを行っている時よりは、PUTやDELETEメソッドを行っている時に、より多くの利用者情報を収集したいと望むかもしれない。
ポリシー参照ファイル内のMETHOD要素は、含まれているポリシー参照が、参照されるリソースにアクセスする為に、指定されたメソッドが使用された時のみ有効である事を示す為に使用される。METHOD要素は、複数の適用できるメソッドを示す為に繰り返されるであろう。METHOD要素がPOLICY-REF要素内にない場合、POLICY-REF要素は、リソースにアクセスするメソッドに関係なく、示されたリソースをカバーする。
従って、/P3P/Policy1.p3pが、GETとHEADメソッドの時に/docs/サブディレクトリ内の全てのドキュメントに適用し、一方で、/P3P/Policy2.p3pは、PUTとDELETEメソッドの時に適用される事を示す場合、以下のポリシー参照ファイルを記述することが出来る：
例 2.3:<POLICY-REFERENCES
xmlns="http://www.w3.org/2000/P3Pv1"
xmlns:web="http://www.w3.org/1999/02/22-rdf-syntax-ns#" >
<web:RDF>
<POLICY-REF web:about="/P3P/Policy1.p3p">
<PREFIX>/docs/</PREFIX>
<METHOD>GET</METHOD>
<METHOD>HEAD</METHOD>
</POLICY-REF>
<POLICY-REF web:about="/P3P/Policy2.p3p">
<PREFIX>/docs/</PREFIX>
<METHOD>PUT</METHOD>
<METHOD>DELETE</METHOD>
</POLICY-REF>
</web:RDF>
</POLICY-REFERENCES>
GETとHEADリクエスト要求は同じふるまいをすることに注意。 つまり、メソッド毎に異なったP3Pポリシーを指定することは不適当である。 METHOD要素のシンタックスは:
| [10] | method-element |
= |
`<METHOD>` Method `</METHOD>` |
| ここで、Methodは [HTTP1.1]の5.1.1節に定義されている | |||
サービスは直接ポリシーを参照してもよいし、間接的に参照してもよい。ポリシーの直接参照とは、取得されたポリシーURIがそのポリシーの本体となるXML文書を返す場合の、ポリシーURIのことである。ポリシーの間接参照とは、取得されたポリシーURIが新たなポリシーURIを返す場合の、ポリシーURIのことである。間接参照によって返されるこの新たなポリシーURIは、それ自体が間接参照であってもよいが、このことはパフォーマンス上の理由から薦められない。
直接参照と間接参照は、それらが取得される際にサーバによって与えられるHTTPのリターンコードによって識別がされる。直接参照のポリシーURIが取得された場合、サーバは200番台のHTTPリターンコードか、301 (Moved Permanently)のリターンコードか、あるいは（適当であれば）エラーコードを返すべきである。サーバは302(Found)や303 (See Other) 、 307 (Temporary Redirect)のリターンコードを返してはならない。間接参照のポリシーURIが取得された場合、エラーコード(400番台または500番台のコード)が適当な場合でないかぎり、サーバは302や303、307のリターンコードを返さなければならない。302や303、307のリターンコードが返される場合は、そのリターンコードは実際のポリシーURIを与えるLocation応答ヘッダを含まなければならない。
サービスは、適切な方法として、直接ポリシー参照と間接ポリシー参照のどちらを使用するか選択することができる（ポリシーの不変性の要求事項を尊重するかぎりにおいて）。直接参照は、これらのポリシーを処理するユーザエージェントにとって最良のパフォーマンスをもたらす。ポリシーの不変性の規則により、ユーザエージェントがすでに取得済みのポリシーURIへの直接参照を受信した場合、それ以上の通信活動を行うことなく、ポリシーの処理を行うことができる。このことはユーザエージェントの応答時間を短縮する効果をもたらす。
間接参照は、実際のポリシーの所在を突きとめるために、さらに少なくとも一往復の通信活動を行うことが必要となる。このことはユーザエージェントのパフォーマンスを下げる結果となる。しかし、間接参照を用いることで、ある種の組織はより柔軟性のあるポリシーの配置を行うことができる。以下にその一例を挙げる：
CatalogExample社という架空の企業は、世界的規模でWebサイトを開設している。この企業の大本のWebサイトwww.catalog.example.comはいくつもの国別サイトへのリンクを提供している。ここでは、CatalogExample社が皮切りに、usa.catalog.example.com (米国)、www.CatalogExample.co.uk(英国)、www.catalog.example.com.ru(ロシア)、 www.catalog.example.co.jp(日本)という4つのローカルなサイトを立ち上げたと仮定する。また、これらのサイトは各々、サイトのコンテンツをローカルに開発していると仮定する。このことにより、各サイトはローカルな閲覧者により適合したサイトを構築することができる。
しかし、CatalogExample社は、世界中の自社のサイト全てに適用する単一のプライバシーポリシーを所持することを決定した。CatalogExample社は大本のWebサイト（www.catalog.example.com）にこのプライバシーポリシーを掲載し、ローカルなサーバ上の各ページにはこのプライバシーポリシーを参照させることで、この決定を実行することができるだろう。ここで、CatalogExample社がポリシーを更新しようとする場合、ポリシーの不変性の規則により、CatalogExample社は自社のプライバシーポリシーを新しいURIに掲載しなければならない。したがって、CatalogExample社は自社の全てのWebサイト上のポリシー参照を変更しなければならない。このためには、世界各地のWeb管理者の作業が必要となるだろう。この問題は、CatalogExample社がより事業を拡大し、20とか50とかのローカルなWebサイトを所持した時にはいっそう困った問題となる。
間接参照はこのような運用上の問題に対するソリューションとして意図されたものである。CatalogExample社の各ローカルサイトは大本のCatalogExample社のサーバを指し示したポリシーURIを表明することができる。このポリシーURIを取得すると、現在適用されているプライバシーポリシーへのポリシー参照が与えられる。例えばCatalogExample社が顧客にその週の特別供給品のリストを送付するために顧客の電子メールアドレスを収集しようとしていると仮定する。各ローカルサーバは間接的なポリシーURIであるhttp://www.catalog.example.com/privacy/P3P/policy-weeklyspecialを使用することができる。このURIを取得すると、実際のプライバシーポリシー（それはhttp://www.catalog.example.com/privacy/P3P/policy-weeklyspecial-3.xmlであるかもしれない）へのリンクが与えられる。CatalogExample社がプライバシーポリシーを更新しようとする場合、そのプライバシーポリシーを参照しているローカルサーバの台数に関わりなく、大本のサーバ上でのみ更新を行えばよい。
一般に、サービスは直接ポリシー参照の使用が可能な場合には、そちらを使用するべきである。間接ポリシー参照については、沢山の多様なWebサイトを持つ組織のみが使用することが望ましい。
サービスは、ポリシーステートメントの正確性を保証するために、同一の組織運営下にあるURI間でのみ間接ポリシー参照を行うべきであることに注意すること。しかし、この要求事項を守らせるための技術的手段はない。間接ポリシー参照は、組織のWebサイトの構造によっては、他のホスト上のURIや他のドメイン内のURIに対してさえ参照を行うことができる。
ユーザエージェントがポリシー参照を受信したときに、それが直接参照なのか間接参照なのかを区別する方法はない。ポリシーを適切に処理するためには、ユーザエージェントはそのポリシー参照で規定されたURIを取得しなければならない。この参照が302(Found)、303(See Other)、または 307 (Temporary Redirect)というリターンコードを返した場合は、ユーザエージェントは、実際のポリシーの存在場所を指し示すLocationヘッダにおいて与えられるURIを取得しなければならない。ポリシーが一たび直接参照により取得されると、（ユーザエージェントがこの情報を記録しつづけるかぎり）2度目以降は取得される必要がなくなることに注意すること。しかし、間接参照では、（ExpiresまたはCache-ControlHTTPヘッダによってポリシーが変更されていないことが示されないかぎり）、ポリシーが変更されていないことを確認するために再チェックを行う必要がある。
HTML ページは時に、画像イメージ、音、レイヤあるいはフレームのような、ページに直接埋め込まれた他のリソースへのリンクを含んでいる。 従って、そのようなページを表現するために、ユーザエージェントは、現在使われているページにおけるポリシーによってカバーされるか、しないかといった追加のリクエストを行う必要がある。
2.3 ポリシー参照ファイルのシンタックスとセマンティクスで記述されるように、このような事態のための望ましい方法はひとつのポリシー参照ファイルの<PREFIX>と<EXCLUDE>要素を使い、影響するすべてのポリシーを仮宣言することである。2.3.1 ポリシー参照ファイルの例における例2.2、それと同様に良い例として2.3.2 ポリシー参照ファイルの定義を参照のこと。
もし、ユーザエージェントが埋め込みコンテンツにリンクするような与えられたURIのプレフィックスに一致するものが見つけれなかったら (例えばIMGタグのsrc属性)、それは与えられたリソースに関係するようなP3Pポリシーは存在しないものとすべきである。しかしながら、影響するようなポリシーを見つけるために、リソースを実際に求める前に、ユーザエージェントが現在のページのヘッダでカバーされた埋め込みURIにHEADのリクエストを発行することを望んでもよい。
フォームは、HEADリクエストを使わないと思われる、CGIスクリプトへのリンクや、その他のサーバ側アプリケーションへのURIなど、埋め込みコンテンツにおける特別な型である。
もし、ユーザエージェントが、そのページから参照されるポリシー参照ファイルで定義されたaction URIに相当するプレフィックスを見つけれないならば、それは有効なポリシーが全くない とすべきである。このような事情から、ユーザエージェントは、アクションURIをカバーするポリシー参照ファイルを見つける試みのためのアクションURIにあるホスト上の周知の存在場所をチェックすべきである。もし、アクションURIをカバーするP3Pポリシーを提供するものでなければ、ユーザエージェントはHEADリクエストを、その結果としてポリシーを見つけるための何らかのデータ送信の前のアクションURIとして実行してもよい。サーバ側では、アプリケーションがHEADのようなリクエストに適切に答え、該当するポリシー参照のリンクヘッダを返すよう、明確にすべきである。このようにアプリケーションの下にあるケースの場合、HEADリクエストがわからず、問題となっているアクションURIを示す仮宣言されたポリシーが全くないことになり、ユーザエージェントは有効なポリシーが全くないとしなければならず、そしてユーザにこれについて確認し、ユーザの選択に従って通信手段を取るようにすべきである。
サービスが、POSTやGETなど、サポートされるメソッドのサブセットをカバーすることだけを行うサーバ側のアプリケーションのためのポリシーを宣言するための<METHOD>要素を利用することを望むかもしれないことに注意。このような事情において、問題となっているアプリケーションがポリシー参照ファイルで与えられた方法をサポートするだけであることは適切である（すなわち、HEADリクエストはサポートされる必要はない）。もし、関連するメソッドがフォームのそのページのポリシー参照ファイルで適切に仮宣言されたmethod属性の中で規定されたならば、ユーザエージェントはアクションURIにHEADリクエストを問題点として試みるべきでない。
ある場合には、異なったデータがフォームの中で選択されたものに応じて同じアクションURIで集められる。例えば、探索サービスが（名前あるいは電子メールなどで）人と（独断的な）イメージにおいて検索を試みようとするかもしれない。フォームでラジオボタンを使うとき、ひとつのサーバ側のアプリケーションはひとつに決められ、そして同じアクションURIは両方のケースを処理して、そして探索に必要な必要情報を集める。
もしサービスがサーバ側のアプリケーションのデータ収集の処理を仮宣言することを望むなら、それは現在ただひとつのポリシーファイル（アクションURIにマッチする宣言の<PREFIX>を使った）に対してのデータ収集の処理のすべてを宣言することについてのオプションを持っているだけである。実際上、ユーザエージェントは状況に応じたすべてのデータ要素が集められると想定しなくてはならない。このソリューションはひとつのポリシーでは便利さを提供する。しかしただリストされたデータ要素の一部だけが一度に集められるという事実を適切に反映しないかもしれない。（選択されたラジオボタンの値が特に存在しないという理由なしで）サービスがアクションURIへの単純なヘッドのリクエストがすべてのケースをカバーするようなポリシーを返すであろうことを明確にすべきである。
フォーム送信はGETメソッドを使うことに注意。<PREFIX>属性において送信データ（そのデータはGETメソッドのアクションURIに添付される）の一部を含むことができる。これは可能であるけれども、このメソッドは次の理由のために反対される：
ポリシー参照の第一の規則は、一義性である。Webサイト上の各リソースに対し、ある時点で有効なプライバシーポリシーはたかだか一つでなければならない。このようにサイトにおけるポリシー参照ファイルは、同じリソースに対して2つ以上の異なるポリシーURIが参照されてはならない。
ひとつのポリシー参照ファイルが明らさまに曖昧であることをチェックする必要性があれば、ユーザエージェントWebサイト全体にわたってポリシー宣言を探してもよい。
時間的な一義性（不変性）に関する議論として、ポリシーの不変性の節も参照すること。
同一のポリシーの多言語版（翻訳版）は、そのポリシーが特定の言語によってエンコーディングされていることを正確に示すために、HTTPの"Content-Language"ヘッダを用いることによって、サーバによって提供することができる。このことは、「組織（entity）」や「結果(consequence)」のような人間が読むことのできる箇所を様々な言語で表現することができるので有用である。
同一URI上で多言語で提供されている複数のポリシーを区別するためにContent-Languageが使用される場合は、常にそれらのポリシーは各言語を通して同一の意味を持たなければならない。
2つのポリシー（または2つのデータスキーマ）が同じであるためにはポリシーとデータスキーマ両方が不変である必要があるときから（下の2.4.3 ポリシーの不変性と比較）、変換は大変に注意して行わなければならない。もし、変換エラーがあったために変更が必要であるなら、新しいポリシーURIが使われなければならない。これはさらにもっと多くの注意がデータスキーマ変換に必要であることを意味する。
Accept-Languageメカニズムの利用を通して、P3Pを実装する人は、もしポリシーあるいはデータスキーマの新しい言語バージョンが加えられたなら、ユーザエージェントが送信することにもかかわらず異なった言語バージョンで、同じAccept-Languageリクエストヘッダを見るかもしれないことに注意しなければならない。
ポリシーの重要な要求事項として、いわゆるポリシーの不変性がある。これは、一つの例外を除いて、あるURIで直接参照されるポリシーは変更してはならないというものである。このようにして、ポリシーのURIはポリシーの一意的な識別子のようにふるまうため、いかなる新たなポリシーも新たな異なるURIを使用しなければならない。この一般原則に対する一つの例外とは、同一のポリシーの多言語版（翻訳版）が、HTTPの"Content-Language"タグを用いることにより、サーバによって提供される場合である。
P3Pクライアントは、キャッシュ上のポリシー（および、Content-Languageが表明されている場合にはそのContent-Language）と新たに取得したポリシー（および、Content-Languageが表明されている場合にはそのContent-Language）とを比較することにより、ポリシーの不変性をチェックしてもよい。ユーザエージェントが2つの異なるポリシーが同一のURIを持つことを発見した場合、それらが2つの異なるContent-Language 値を持つのでないかぎり、ユーザエージェントはその変更されたポリシーがカバーするページについてはP3Pポリシーを持たないものとして取り扱わなければならない。
ポリシーの不変性は、直接参照されるポリシーにのみ当てはまることに注意すること。間接参照に関しては、間接ポリシー参照が取得されたときに返される実際のポリシーURIは、時間の経過とともに変えることができる（これが間接ポリシー参照の背後にある目的である）。間接ポリシー参照は、直接ポリシー参照に変更されてはならない。このようなことを望む場合には、新たなポリシーURIが使用されなければならない。
P3Pを利用可能な全てのユーザエージェントとサービスは、P3Pプライバシーポリシーを取得する行為の一部として行われる全ての通信は、そこにおいては最小限のデータ収集のみ行い、収集したデータを個人特定不可能な方法でのみ使用することを意味する特別な“セーフゾーン”の一部であることを保証するべきである。特に、ポリシー参照ファイルのための周知の存在場所のりクエストはこれらの"セーフゾーン"によってカバーされるべきである。
このセーフゾーンをサポートするために、P3Pユーザエージェントはサイトのポリシーが取得されるまで、サイトのポリシーを発見する目的に不必要なデータの送信を控えるべきである。従ってユーザエージェントはP3Pポリシーを要求する間、HTTPのRefererヘッダ、クッキー、またはユーザエージェント情報を送信するべきではない。ユーザエージェントを実装する人は、P3Pポリシーをリクエストするとき、Accept-LanguageHTTPヘッダを使うことで、プライバシ交換があることを知っている必要がある。正しいAccept-Languageヘッダを送ることは、利用者が好む自然言語でP3Pポリシーを取ってくることを許すだろう（もし、利用可能ならば）。しかし、それはとあるユーザの識別についての情報を見せることになる。ユーザエージェントは、Accept-Languageヘッダを送るべきか利用者が決めるように聞くことを望むかもしれない。
加えてP3Pユーザエージェントは、他の要求を行う前に適切なポリシーの存在場所を知るために、サイトに対しHEAD要求を送信してもよいだろう。この方法はデータの送信を必要とする要求を行う事なしに、サイトのポリシーを取得するのに有効である。しかしながら、サイトが Accept-Languageヘッダ（［HTTP1.1］仕様の15.1.4 Privacy Issues Connected to Accept Headersと比較されたし） によりユーザの識別を検出することが可能であるかもしれないときから、ポリシーのマシンリーダブルな一部を受けとるためのAccept-LanguageヘッダなしでHEADリクエストが発行されるかもしれない、そしてそれが合理的に満足がいく場合に限り、もし必要なら、適切な言語でのポリシーは取り出される。
サーバはポリシーを提供するために、HTTPRefererヘッダや、クッキー、ユーザエージェント情報、要求に対する応答に不必要なその他の情報の受領を要求するべきではない。加えてサーバは、ポリシーを提供している間や、HEAD要求に応答している間に収集した全ての情報を、個人を認識可能な用途で使用するべきではない。
サーバは、P3Pポリシーが要求された時に、応答ヘッダ内にPolicyRefヘッダを含んで応答してもよい。しかしPolicyRefヘッダは無視されなければならない事に注意することが重要で、上記で説明された“セーフゾーン”の要求事項が代わりに用いられる。この様な場合にPolicyRefヘッダを返すことは、管理者がサーバ上にある全ての文書に対して一つのP3Pポリシーを簡単に適用させることができ、かつPolicyRefヘッダなしにポリシーを要求することがサイトの管理者の負担を増加させるかもしれない事情に鑑みて許可されることである。
セーフゾーン要求は、サイトが個人を特定可能な情報を保持することが出来ないと言っている訳ではなく、ポリシーを提供している間に収集した情報を、個人を特定可能な用途に使用してはならない事のみを言っている。サービスへのアタックに関するトラックダウン拒否は、個人を特定可能な情報を使用する為の合法的な理由となり、“使用してはならない”を無視出来る事になる。
サーバ側に対して2つの重要な追加要求がある：
P3PポリシーとP3Pポリシーへの参照内に、いかなる機密情報をも含むべきではない。この事は、P3Pプライバシーポリシーが関連付けられた文書の要求事項の枠を超えて、P3Pプライバシーポリシーへの参照を送信する事に関するセキュリティーの追加要求事項が無いことを意味する。従って、通常HTML文書が暗号化なしのセッシションを通して提供されている場合、P3Pプロトコルは、文書に含まれているP3Pプライバシーポリシーを参照する時に、暗号化されたセッションを通して文書が提供されることを要求しない。
P3PポリシーはXMLでエンコードされる。それはRDFデータモデルを使うことを意味する。しかし、RDFでの表現については、この仕様書には含まれていない（ワーキンググループは、P3PをProposed Recommendationとして出す前に、W3Cノートとして利用可能なようにする計画である）。
3.1節では、自然言語で書かれたポリシーとそれに対応するP3Pポリシーの実例を挙げる。P3Pポリシーの中には、ポリシー全体に適用される全般的な主張と、参照データにおいて言及された特定のデータ型の取扱いのみに適用される特定の主張（これをステートメントと呼ぶ）とがある。3.2節では、policy要素とポリシーレベルの主張について説明する。3.3節ではステートメントと参照データについて説明する。
以下の節では、XML要素を紹介していく。各要素は <>ブランケット（例えば、<POLICY>）で表記され、その後に有効な属性がリストアップされる。「必須の属性」と付記された属性以外は、全てオプショナルな属性である。開始タグと終了タグが隔てられているBNFで示されている多くのXML要素は、要素内に任意の要素を含むことが出来る事に注意が必要である。何も要素が含まれていない場合XML規則に従い、代わりに、自己終結要素（self-closing element）が使用される。
以下の文章は自然言語で書かれたプライバシーポリシーの2つの例である。後節で、このポリシーをP3Pポリシーにコード化する。どちらのポリシーもひとつの会社、CatalogExample社の例であり、彼らのサイトを閲覧している人むけのポリシーと、実際に商品を購入している人むけのポリシーといった異なったポリシーを持っている。
データの保管:
定期的に集める閲覧情報の整理をします。
例3.1をP3P要素と属性名を使った正式な記述は以下のとおりである。 [容易な参照のために仕様書の章をカッコでくくっている]:
あなたが商品購入を選んだ場合、以下のようなもっと多くの情報を要求します。:
以下の2つの例にあげた[XML]文書は上記の自然言語ポリシーをXMLで表現したものである。ポリシーは、XML.によって正確に表現されたステートメントのことである。ポリシーのシンタックスについては、後節でより詳細に説明する。
例3.1のXMLエンコード方法:
<POLICY xmlns="http://www.w3.org/2000/P3Pv1"
discuri="http://www.catalog.example.com/PrivacyPracticeBrowsing.html">
<ENTITY>
<DATA-GROUP>
<DATA ref="#business.name">CatalogExample</DATA>
<DATA ref="#business.contact-info.postal.street.line1">4000 Lincoln Ave.</DATA>
<DATA ref="#business.contact-info.postal.city">Birmingham</DATA>
<DATA ref="#business.contact-info.postal.stateprov">MI</DATA>
<DATA ref="#business.contact-info.postal.postalcode">48009</DATA>
<DATA ref="#business.contact-info.postal.countrycode">USA</DATA>
<DATA ref="#business.contact-info.online.email">catalog@example.com</DATA>
<DATA ref="#business.contact-info.telecom.telephonenum.intcode">1</DATA>
<DATA ref="#business.contact-info.telecom.telephonenum.loccode">248</DATA>
<DATA ref="#business.contact-info.telecom.telephonenum.number">3926753</DATA>
</DATA-GROUP>
</ENTITY>
<DISPUTES-GROUP>
<DISPUTES resolution-type="independent"
service="http://www.PrivacySeal.example.org"
short-description="PrivacySeal.example.org">
<REMEDIES><correct/></REMEDIES>
<IMG src="http://www.PrivacySeal.example.org/Logo.gif"/>
</DISPUTES>
</DISPUTES-GROUP>
<ACCESS><nonident/></ACCESS>
<STATEMENT>
<PURPOSE><admin/><develop/></PURPOSE>
<RECIPIENT><ours/></RECIPIENT>
<RETENTION><stated-purpose/></RETENTION>
<DATA-GROUP>
<DATA ref="#dynamic.clickstream.server"/>
<DATA ref="#dynamic.http.useragent"/>
</DATA-GROUP>
</STATEMENT>
</POLICY>
例3.2のXMLエンコード方法:
<POLICY xmlns="http://www.w3.org/2000/P3Pv1"
discuri="http://www.catalog.example.com/PrivacyPracticeBrowsing.html">
<ENTITY>
<DATA-GROUP>
<DATA ref="#business-info.name">CatalogExample</DATA>
<DATA ref="#business-info.contact-info.postal.street.line1">4000 Lincoln Ave.</DATA>
<DATA ref="#business-info.contact-info.postal.city">Birmingham</DATA>
<DATA ref="#business-info.contact-info.postal.stateprov">MI</DATA>
<DATA ref="#business-info.contact-info.postal.postalcode">48009</DATA>
<DATA ref="#business-info.contact-info.postal.countrycode">USA</DATA>
<DATA ref="#business-info.contact-info.online.email">catalog@example.com</DATA>
<DATA ref="#business.contact-info.telecom.telephonenum.intcode">1</DATA>
<DATA ref="#business-info.contact-info.telecom.telephonenum.loccode">248</DATA>
<DATA ref="#business-info.contact-info.telecom.telephonenum.number">3926753</DATA>
</DATA-GROUP>
</ENTITY>
<DISPUTES-GROUP>
<DISPUTES resolution-type="independent"
service="http://www.PrivacySeal.example.org"
short-description="PrivacySeal.example.org">
<REMEDIES><correct/></REMEDIES>
<IMG src="http://www.PrivacySeal.example.org/Logo.gif"/>
</DISPUTES>
</DISPUTES-GROUP>
<ACCESS><contact_and_other/></ACCESS>
<STATEMENT>
<PURPOSE><admin/><develop/></PURPOSE>
<RECIPIENT><ours/></RECIPIENT>
<RETENTION><stated-purpose/></RETENTION>
<DATA-GROUP>
<DATA ref="#dynamic.clickstream.server"/>
<DATA ref="#dynamic.http.useragent"/>
</DATA-GROUP>
</STATEMENT>
<STATEMENT>
<PURPOSE><current/></PURPOSE>
<RECIPIENT><ours/></RECIPIENT>
<RETENTION><stated-purpose/></RETENTION>
<DATA-GROUP>
<DATA ref="#user.name"/>
<DATA ref="#user.home-info.postal"/>
<DATA ref="#user.home-info.telecom.phone"/>
<DATA ref="#user.business-info.postal"/>
<DATA ref="#user.business-info.telecom.phone"/>
<DATA ref="#user.home-info.online.email"/>
<DATA ref="#miscdata>
<CATEGORIES><financial/><CATEGORIES/>
</DATA>
</DATA-GROUP>
</STATEMENT>
<STATEMENT>
<PURPOSE>
<contact change_preferences="yes"/>
<customization change_preferences="yes"/>
<targeting change_preferences="yes"/>
</PURPOSE>
<RECIPIENT><ours/><same/></RECIPIENT>
<RETENTION><stated-purpose/></RETENTION>
<DATA-GROUP>
<DATA ref="#user.name" optional="yes"/>
<DATA ref="#user.home-info.address" optional="yes"/>
<DATA ref="#user.home-info.postal" optional="yes"/>
<DATA ref="#user.home-info.telecom.phone" optional="yes"/>
<DATA ref="#user.business-info.postal" optional="yes"/>
<DATA ref="#user.business-info.telecom.phone" optional="yes"/>
<DATA ref="#user.home-info.online.email" optional="yes"/>
</DATA-GROUP>
</STATEMENT>
<STATEMENT>
<CONSEQUENCE>Lets you access your own information</CONSEQUENCE>
<PURPOSE><customization change_preferences="yes"/></PURPOSE>
<RECIPIENT><ours/><same/></RECIPIENT>
<RETENTION><stated-purpose/></RETENTION>
<DATA-GROUP>
<DATA ref="#dynamic.miscdata">
<CATEGORIES><uniqueid/></CATEGORIES>
</DATA>
</DATA-GROUP>
</STATEMENT>
<STATEMENT>
<CONSEQUENCE>A site with products you would appreciate</CONSEQUENCE>
<PURPOSE>
<customization change_preferences="yes"/>
<targeting change_preferences="yes"/>
</PURPOSE>
<RECIPIENT><ours/><same/></RECIPIENT>
<RETENTION><stated-purpose/></RETENTION>
<DATA-GROUP>
<DATA ref="#user.bdate.ymd.year" optional="yes"/>
<DATA ref="#user.gender" optional="yes"/>
</DATA-GROUP>
</STATEMENT>
<STATEMENT>
<CONSEQUENCE>A site with clothes you would appreciate</CONSEQUENCE>
<PURPOSE><customization/><develop/></PURPOSE>
<RECIPIENT><ours/></RECIPIENT>
<RETENTION><indefinitely/></RETENTION>
<DATA-GROUP>
<DATA ref="#dynamic.cookies"><CATEGORIES><state/></CATEGORIES></DATA>
<DATA ref="#dynamic.miscdata"><CATEGORIES><preference/></CATEGORIES></DATA>
</DATA-GROUP>
</STATEMENT>
</POLICY>
本節では、P3Pポリシーのシンタックスとセマンティクスを定義する。全てのポリシーは[UTF-8]を用いて表現しなければならない。P3Pサーバはこのシンタックスを用いて自らのポリシーを表現しなければならない。P3Pユーザエージェントはこのシンタックスを解析できなければならない。
POLICY要素（ポリシー要素）には、完全なP3Pポリシーが含まれる。各P3Pポリシーには、一つのPOLICY要素が正しく含まれなければならない。POLICY要素には、そのポリシーに含まれるプライバシープラクティスの代表者となる法人組織を特定するような組織属性が含まれなければならない。さらに、POLICY要素にはACCESS要素（情報公開要素）、少なくとも一つのSTATEMENT要素（ステートメント要素）が含まれなければならない。また、オプショナルなものとしてDISPUTES-GROUP要素（係争解決グループ要素）、その他一つ以上のextension（拡張）が含まれてもよい。
| [11] | policy |
= |
`<POLICY xmlns="http://www.w3.org/2000/P3Pv1"
discuri=` quoted-URI `>`
*extension
[dataschema]
entity
access
[disputes-group]
1*statement-block
*extension
`</POLICY>`
|
| [12] | quoted-URI |
= |
`"` URI `"` |
| ここではURIはRFC 2396 [URI]によって定義される。 | |||
ENTITY要素は、プライバシープラクティス表記を行っている合法組織に関する正確な説明を提供する。
ENTITY要素は、ビジネスデータ集合の（全て又は一部の）フィールドを参照しているDATA 要素から成る合法組織の説明を含んでいる。: 利用者が、ある組織のプライバシーポリシーについて連絡を取る際に使うであろう住所、電話番号、電子メールアドレスおよびその他の情報などの問い合わせ情報は、実在する名称でなければならない。 また、ある法律や規則の指導では、郵便番号やその他の特有の情報を問い合わせ情報に含める必要があることに注意すること。
| [13] | entity |
= |
"<ENTITY>" *extension entitydescription *extension "</ENTITY>" |
| [14] | entitydescription |
= |
<DATA-GROUP> `<DATA ref="#business.name"/>` PCDATA </DATA> *(`<DATA ref="#business." string `/>` PCDATA </DATA>) </DATA-GROUP> |
| ここで文字列は、ビジネスデータ集合によって許される数字の間、連続する文字（" や & で回避された）で定義される。PCDATAは[XML]で定義されている。 | |||
サービス提供者は、discuriで示されたWeb以外の手段で収集された情報にアクセスする許可を与えてもよい。しかし、P3Pステートメントが扱う範囲はHTTPまたは他のWeb転送プロトコルを通して収集されるデータに限られる。また、アクセスがWeb経由で提供される場合は、セキュリティの問題は本文書の範囲外ではあるが、そのようなアクセスのために強固な認証とセキュリティメカニズムを使用することを推奨する。
ACCESS要素は、以下の要素の中から一つ構成されなければならない。:
| [15] | access |
= |
"<ACCESS>" access_disclosure *extension </ACCESS> |
| [16] | access-disclosure |
= |
"<nonident/>" | ; 個人特定可能なデータは使われていない。 "<ident_contact/>" | ; 個人特定可能なコンタクト情報 "<other_ident/>" | ; その他の個人特定可能な情報 "<contact_and_other/>" | ; 個人特定可能、およびその他のコンタクト情報 "<all/>" | ; 個人特定可能な全ての情報 "<none/>" ; なし |
ポリシーは、一つ以上の DISPUTES要素（係争解決要素）から成る、DISPUTES-GROUP要素（係争解決グループ要素）を含むべきである。DISPUTES 要素は、サービスのプライバシープラクティスに関して係争が生じた際に行われる係争解決手続きを記述している。どのDISPUTES要素も、LONG-DESCRIPTION要素とIMG要素、REMEDIES要素をオプションとして含んでも良い。複数の係争解決の手段を持つサービスプロバイダは、それぞれに分けたDISPUTES要素を使うべきである。もし複数使うならば、異なる係争手段は係争解決手段も分かれており、それぞれのDISPUTES要素はそれぞれのLONG-DESCRIPTIONやIMGタグ、REMEDIES要素が必要になると思われる。
DISPUTES要素には、人間が読むことができるLONG-DESCRIPTION要素を含むことができる。 それは適当に合法的に公開されるか、法律に適用された、または第三者的組織の名前、あるいはサービスURIにおいて示されていない利用者へのサービスとなるコンタクト情報などを含まなければならない。
| [17] | disputes-group |
= |
"<DISPUTES-GROUP>" *extension 1*dispute *extension "</DISPUTES-GROUP>" |
| [18] | dispute |
= |
"<DISPUTES"
" resolution-type=" '"'("service"|"independent"|"court"|"law")'"'
" service=" quoted-URI
[" verification=" quoted-string]
[" short-description=" quoted-string]
"/>"
[longdescription]
[image]
[remedies]
*extension
"</DISPUTES>"
|
| [19] | longdescription |
= |
<LONG-DESCRIPTION> PCDATA </LONG-DESCRIPTION> |
| [20] | image |
= |
"<IMG src=" quoted-URI [" width=" `"` number `"`] [" height=" `"` number `"`] [" alt=" quoted-string] "/>" |
| [21] | quoted-string |
= |
`"` string `"` |
| ここで文字列は連続する文字（" や & で回避された）で定義される。PCDATAは[XML]で定義されている。 | |||
サービスは複数の保証サービスを持つことができ、それらはDISPUTES-GROUP要素に含まれる 複数のDISPUTES要素の記載を通して特定できることに注意すること。ある組織のプライバシープラクティスが自組織内で保証されたものも含み、第三者機関によて監査されたり、または法的な監督機関の管轄下にあったりすることを説明することによって、このDISPUTES-GROUP要素のフィールドが様々な方法で使用されることを期待する。
個々のDISPUTES要素は、ポリシーに関する違反があった場合に、可能である賠償方法を指定しているREMEDIES要素を含むべきである。
REMEDIES要素は、以下の1つ以上含まなければならない。
| [22] | remedies |
= |
"<REMEDIES>" 1*remedy *extension "</REMEDIES>" |
| [23] | remedy |
= |
"<correct/>" |
"<money/>" |
"<law/>"
|
ステートメントは、特定のデータの型に適用されるデータプラクティスを説明する。
STATEMENT要素（ステートメント要素）は、PURPOSE要素（目的要素）、RECIPIENT要素（受領者要素）、RETENTION（保有要素）、DATA-GROUP要素（データグループ要素）、オプショナルなものとしてCONSEQUENCE要素（結果要素）と一つ以上の拡張を束ねたものである。DATA-GROUP要素で参照された全てのデータは、ステートメントに含まれたその他の要素から成る情報公開に従って取り扱われる。このように、サイトは同じ方法で取り扱われる要素をグループ化し、各グループに対してステートメントを作成することができる。サイトが収集するデータの種類に合わせて個々の目的とその他の情報を公開したい場合は、各データ要素に合わせて別々のステートメントを作成することによって、そのような公開を行うことができる。
| [24] | statement-block |
= |
"<STATEMENT>" *extension [consequence] purpose recipient retention 1*data-group *extension "</STATEMENT>" |
プラクティスの宣言を簡潔化するために、サービス提供者はデータ要素に関するステートメント内で情報公開（目的、受領者、個人特定可能な利用）を集合化することができる。サービス提供者は、このような集合化は付加的な作業として行わなければならない。例えば、利用者の年齢は「当組織および当組織の業務委託先」に提供するが、利用者の郵便番号は「当組織と無関係な第三者」に提供するようなサイトは、利用者の名前と郵便番号を「当組織および当組織の業務委託先」および「当組織と無関係な第三者」に提供すると表明してもよい。そのようなステートメントでは、実際に行っている以上に多くのデータを第三者に提供しているように見える。自サイトの情報公開を詳細なものとするか簡潔なものとするかどうかを決定するのは、サービス提供者次第である。
また、サービス提供者は常に、適用される全てのオプションを公開しなければならない。例えば、「サービスまたは製品のマーケティングのためにサイト訪問者と連絡をとる」という目的のみで情報を収集するサイトを考えてみる。サイトがこの「サービスまたは製品のマーケティングのためにサイト訪問者と連絡をとる」ことを「現在の活動の遂行とサポート」の目的によるものだとみなしている場合でも、サイトは両方の目的を表明しなければならない。情報を「サービスまたは製品のマーケティングのためにサイト訪問者と連絡をとる」目的で「当サイトおよび当サイトの業務委託先」に提供し、「現在の活動の遂行とサポート」の目的で「公のフォーラム」に提供するサイトは、「当サイトおよび当サイトの業務委託先」と「公のフォーラム」の両方の受領者を表明しなければならない。
STATEMENT要素（ステートメント要素）には、利用者に対し、サイトのプラクティスに関して追加的な説明を与えることができるCONSEQUENCE要素（結果要素）を任意に含むことが出来る。
| [25] | consequence |
= |
"<CONSEQUENCE>" PCDATA "</CONSEQUENCE>" |
各STATEMENT要素（ステートメント要素）には、一つ以上のデータ収集目的またはデータ利用目的を含むPURPOSE要素（目的要素）が含まれなければならない。サイトは自らのデータプラクティスを、6つの特定化された目的のうちの一つ以上の目的に分類しなければならない。
PURPOSE要素には、以下の目的の中から一つ以上が含まれなければならない:
各々の目的には、以下のオプショナルな属性を付加することができる：
| [26] | yesno |
= |
"yes" | "no" |
| [27] | purpose |
= |
"<PURPOSE>" 1*purposevalue *extension "</PURPOSE>" |
| [28] | purposevalue |
= |
"<current" [change] "/>" | ; 現在の活動の遂行とサポート "<admin" [change] "/>" | ; Webサイトとシステムの管理 "<develop" [change] "/>" | ; 調査と開発 "<contact" [change] "/>" | ; サービスまたは商品のマーケティングのためにサイト訪問者と連絡をとる "<customization" [change] "/>" | ; 肯定的なカスタマイズ "<targeting" [change] "/>" | ; その場限りのターゲット化 "<profiling" [change] "/>" | ; 個人のプロファイリング "<other-purpose" [change] " >" PCDATA "</other-purpose>"; その他の利用 |
| [29] | change |
= |
" change_preferences=" `"` yesno `"` |
ワーキンググループは、サイトが実行するかもしれない目的と実行することになっている目的との区別をサイトに許可することの可能性を、長時間議論してきた。ワーキンググループの総評は、そのような区別は必ずしも必要ないというものであった。しかし、この結論に同意しない何人かのメンバーは以下のように述べている：
ボキャブラリにおける応答の選択肢としては、「はい」、「いいえ」、および 「かもしれない（may）」の全てが必要である。もし選択肢が「いいえ」と「かもしれない」 しかなかったならば、「かもしれない」の意味は「はい」に等しいということになり、意味の乱れが 生じてしまう。「かもしれない」はその真の意味（「はい」または「いいえ」）を反映した一つの 選択肢でなければならない。もし「かもしれない」がデフォルトとして「はい」を意味している としたら、「はい」は応答の選択肢に含まれていないため、消費者は欺かれることになるだろう。 「かもしれない」は、プライバシーポリシーを理解するために消費者が参照できるこの用語 （「かもしれない」）の背後に一連の規則があることを含意するために使用されるべきである。 もし「かもしれない」が「はい」を意味するとしたら、消費者がクリックを通じてWebサイトの プライバシーポリシーを調査する可能性はもっと低くなるだろう。この「いいえ」と「かもしれない」 という一見簡素な解決策は、消費者が「いいえ」と「かもしれない」だけに絞られた選択肢の意味に おいて混乱をきたすので、電子商取引にとって重大な障壁となる可能性がある。3つの選択肢全てを 提供することはWebサイトの消費者を欺く企てにつながると主張するメンバーたちは、論点を外して いる。プライバシー保護の領域では、プライバシーポリシーを表明する際の正確性こそが、 情報の利用方法に関して消費者の信用と信頼を勝ち得るための決定的な要因なのだ。ソフトウェアの 簡潔性のために、消費者のプリファレンスの選択肢を「いいえ」と「かもしれない」に 限定することは、消費者への害悪となると同時に、プライバシーポリシーに関して消費者と正確な 意思疎通を心がけているWebサイトへの害悪ともなるだろう。
各STATEMENT要素（ステートメント要素）には、収集データの一つ以上の受領者を含むRECIPIENT要素（受領者要素）が含まれなければならない。サイトはデータの受領者を、6つの特定化された受領者のうちの一つ以上の受領者に分類しなければならない。
RECIPIENT要素には、以下の受領者の中から一つ以上が含まれなければならない。
| [30] | recipient |
= |
"<RECIPIENT>" 1*recipientvalue *extension "</RECIPIENT>" |
| [31] | recipientvalue |
= |
"<ours/>" | ; 当組織および／または当組織の業務委託先 "<same/>" | ; 当組織のプラクティスに従う法人組織 "<other-recipient/>" | ; 当組織とは異なるプラクティスに従う法人組織 "<delivery/>" | ; 当組織とは異なるプラクティスに従う可能性のある配送サービス "<public/>" | ; 公のフォーラム "<unrelated/>" ; 当組織と無関係な第三者 |
サービス提供者は適合する全ての受領者を公開しなければならない。ただし、上記の6つの受領者のセットでは、データの全ての受領者が完全には表示されない場合があることに注意すること。例えば、運送業者や決済業者は、取引活動を遂行し支援するために必要であるが、異なるプラクティスに従う場合もあり、このような業務処理促進業者に関する点が問題になっていた。現在のところ、明示的にポリシー内で示すことができるのは配送サービスだけである。その他の業務処理促進業者については、元のサービス提供者との関係において彼らのプラクティスを最も正確に反映しているカテゴリにおいて表明されなければならない。ワーキンググループは配送サービスに対して特別の区分を設けることにしたが、（銀行やクレジットカード会社のような）決済業者に対しては以下のような理由でそのような措置をとらなかった：金融機関は、典型的に、金融データの使用に関して顧客と個々に合意している一方で、配送サービスの受領者はたいてい、配送サービスのプライバシーポリシーを検討する機会をもたないためである。
<delivery/>要素は、配送を遂行するためにサービス提供者の代行としてのみデータを使用することに同意している配送サービスに対して使われるべきではないことに注意すること。
各STATEMENT要素（ステートメント要素）には、そのステートメントで参照されたデータに当てはまる保有ポリシーを示すRETENTION要素（保有要素）が含まれなければならない。
RETENTION要素には、以下のうちの1つが含まれなければならない：