このドキュメントは

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification
W3C Candidate Recommendation 15 December 2000
http://www.w3.org/TR/2000/CR-P3P-20001215

の和訳です。

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

Platform for Privacy Preferences 1.0 (P3P1.0) 仕様書

W3C勧告候補 2000年12月15日

この版:: http://www.w3.org/TR/2000/CR-P3P-20001215
最新公開版:: http://www.w3.org/TR/P3P
旧版:: http://www.w3.org/TR/2000/WD-P3P-20001018
編集者:: Massimo Marchiori, W3C/MIT/UNIVE, (massimo@w3.org)
著者:: Lorrie Cranor, AT&T; Marc Langheinrich, ETH Zurich; Massimo Marchiori, W3C/MIT/UNIVE; Martin Presler-Marshall, IBM; Joseph Reagle, W3C/MIT

要旨

本仕様書は、「プライバシー情報取り扱いに対する個人の選好を支持する技術基盤（Platform for Privacy Preferences、P3P）」の仕様書である。標準書作成手順に従い、本文書は、相互互換性のあるP3Pアプリケーションのインプリメントに必要な総ての仕様を規定している。

本文書の位置付け

この節では、文書の発行時における当該文書の位置付けについて記述する。しかし、この記述内容は、他の文書で置き換えられる可能性がある。本文書シリーズの最新の位置付けは、W3Cが決めている。

本書はPlatform for Privacy Preferences 1.0 (P3P1.0) Specificationのプラットフォーム2000年12月15日の勧告である。これはＰ３Ｐ仕様書のワーキンググループ（メンバーのみ）がこの仕様書を固定させることを考慮し、この期間に実装とこの仕様書に関してのコメントを促している。勧告レビュー期間は以下の部分がアーカイブされると終了する。実装者の入力は2001年3月15日中までは可能である。

アーカイブされる部分は：

この仕様書で必要かつ推奨される機能すべてを含むHTMLファイルを取り出すことのできるHTTPユーザエージェントに組み込まれているP3Pユーザエージェントの実装が少なくとも一つ。
各指定された機能の二番目のP3Pユーザエージェント実装。（この機能はP3Pの部分のいくつか、または二番目の完全なP3Pで説明されることがある。）
P3Pポリシーとポリシー参照ファイルを作成するための特別な目的のツールが少なくとも一つ。
完全なP3Pポリシーを簡潔なポリシーへ変換するためのツールが少なくとも一つ。
P3P可能なウェブサイトが少なくとも１０個。
ミニポリシーを使用する一つのウェブサイトとこのP3P1.0仕様書の2.5章にあるシナリオの例を説明する少なくとも一つのウェブサイト。（これら二つはプロダクションウェブサイトまたはデモンストレーションウェブサイトである）

さらに、勧告レビュー期間にワーキンググループは：

P3Pポリシーとポリシー参照ファイルを表すRDFデータモデルを記述しているW3C Noteを準備する。
P3Pヘッダを記述しているIETFへインターネットドラフトを提示し、このヘッダを文書化してRFCを発行することを要求する。
ユーザエージェント実装者が、実装が正しく行われている事を確認するために使用するテストポリシーとポリシー参照ファイルのセットを準備する。これには構文エラーを含むポリシーの例を入れるべきである。
ユーザエージェントが無効な構文を使用したポリシーを見つけた場合の適切な振る舞いを指定する。

また、ワーキンググループは実装者に[APPEL] 言語を使用してユーザプリファレンスをインポートできる実装と、プロキシとモバイル機器での実装ができるかを調査することを促進する。

www-p3p-public-comments@w3.org (一般にアーカイブしている) へレビューコメントをお送り下さい。

この仕様書は実装が非常に難しく、実行しがたいので、ワーキンググループはドキュメントをワーキングドラフト状態に戻し、変更を行う。そうでない場合、ワーキンググループはW3Cディレクターにこのドキュメントを提案した勧告へ進捗するように要求することを期待する。

便宜上、2000年10月18日の分からの変更についての要約の変更ログはこの文書の終わりに述べている。

現行のパブリックW3Cワーキングドラフトはhttp://www.w3.org/TRで見ることができる。

必須機能の要約：

ユーザエージェントは以下のことが可能でなければならない：

周知の場所にポリシー参照ファイルがあるかどうかを確認する。
HTTPレスポンスヘッダにポリシー参照ファイルがあるかどうかを確認する。
埋め込みLINKタグにポリシー参照ファイルがあるかどうかを確認する。（HTMLファイルを取り出すポリシー参照ファイルのみに必要）
ポリシー参照ファイルを取り出す。
ポリシー参照ファイルを構文解析し、適切なポリシーの場所を認識する --また、インラインポリシーを処理できなければならない。
P3Pポリシーを取り出す。
データスキーマを取り出し、構文解析する。
ポリシーを構文解析し、ユーザプリファレンスと比較する。（そして、ポリシーとプリファレンスを元に適切な行動を取る）
いつ新しいポシリーおよびポリシー参照を取り出さなければならないのかを決める為にポリシーとポリシー参照ファイルの有効期限を使用する。
必要なポリシーとポリシー参照ファイルすべてを取り出し、複数のオブジェクト（異なるプライバシーポリシーを伴っているかもしれない）と埋め込みコンテンツをもつWebページを適切に処理し振舞う。
文書化されたメカニズムを使用してユーザプリファレンスをインポートする。

推奨される機能の要約：

ユーザエージェントは以下のことが可能であるべきである：

ユーザエージェントのガイドラインすべてに従う。
ユーザプリファレンスをエクスポートする。
セーフゾーン必要事項を実行する。（クッキーとヘッダを止める）
簡潔なポリシーを認識、構文解析し、適切な処理を行う。

序論
ポリシー参照
ポリシーの構文とセマンティクス
簡潔なポリシー
データスキーマ
付録
 付録 1：参考文献（標準準拠）
付録 2：参考文献（標準非準拠）
付録 3：P3P基本データスキーマ定義（標準準拠）
付録 4：XMLスキーマ定義（標準準拠）
付録 5：XML DTD 定義（標準準拠）
付録 6：ABNF表記法（標準非準拠）
付録 7：P3Pガイドライン（標準非準拠）
付録 8：ワーキンググループ貢献者（標準非準拠）

1. 序論

Platform for Privacy Preferences Project (略称P3P)は、Webサイトが標準形式でそのサイトのプライバシープラクティスを表現することを可能にし、その標準形式データをユーザエージェントが自動的に取りこんだり、簡単に処理したりすることを可能にする。P3Pユーザエージェントはサイトのプライバシープラクティスを利用者に(マシンが読むことができる形式、及び人間が読むことのできる（ヒューマンリーダブルの）形式で)通知することができ、プライバシープラクティスが適切ならば、自動意思決定を行うことも可能である。P3Pユーザエージェントのこの自動意思決定機能を用いれば、利用者は、アクセスするサイトの総てのプライバシーポリシーを逐一読む必要が無くなる。

P3Pは、利用者が、個人情報を受け渡す前にサイトのプライバシーポリシーを知ることを可能にするメカニズムを提供するが、そのサイトがそのポリシーに従った行動をすることを保証するメカニズムを提供するものではないことに注意されたい。本仕様書の内容を実装した幾つかのプロダクトは、そのような保証の支援メカニズムを有するかもしれないが、それは、個々の実装上の都合によるものであり、本仕様の範囲外である。しかしながら、P3Pは、プライバシーに関する法律や自主規制プログラムを補完するものであり、それらを強化するメカニズムを提供することができる。更に付け加えるならば、P3Pは、データ転送のメカニズムを提供するものではなく、また、データの保管を安全に行うためのメカニズムを提供するものでもない。P3Pは、データ転送を可能にするツールの中に組み込まれ、それらのツールは、適切な機密保護機構を有しているべきである。

1.1 P3P1.0仕様書

P3P1.0仕様書は、P3Pプライバシーポリシー（P3Pポリシー）のための構文とセマンティクスとを定義しており、そして、Webリソースにポリシーを付加するためのメカニズムを定義している。P3Pポリシーは、プライバシーに関する処理を如何に行うかを表現する為に用いられるP3Pボキャブラリを使って組み立てられるステートメントから構成されている。P3Pポリシーは、P3P基本データスキーマの要素を使用する。P3P基本データスキーマとは、データ要素の一つの標準集合のことをいい、総てのP3Pユーザエージェントは、これを処理できなければならない。P3P仕様書は、新たなデータ要素やデータ集合を定義可能とするメカニズムを規定しており、また，P3Pボキャブラリを増やすことを可能とする簡単なメカニズムも規定している。

1.1.1 P3P1.0の最終目的と可能性

P3Pバージョン1.0は、Webサイトがデータ収集を如何に行うかをWeb利用者に通知することを目的に設計されたプロトコルである。P3Pバージョン1.0は、Webサイトがデータ収集と収集したデータの処理とをどの様に行うかをマシンが読むことができるXML形式のP3Pポリシーにコード化する方式を提供する。P3P仕様書は、次の定義を行っている：

Webサイトが収集する可能性のあるデータの標準スキーマ、これは"P3P基本データスキーマ"と呼ばれる。
利用、受領者、データカテゴリ、及び、その他のプライバシー情報の開示に用いられる標準集合。
プライバシーポリシーの記述に用いられるXML形式。
Webリソースやサイトにプライバシーポリシーやクッキーを付加する方法。
HTTPを使ってP3Pポリシーを転送する仕組み。

P3P1.0の最終目的は、次の二つである。最初の一つは、Webサイトがデータ収集を如何に行うかを標準化され、マシンが読むことができ、かつ、簡単な方法で、提示することを可能とすることである。二つ目は、Web利用者がアクセスするWebサイトが、どんなデータを収集し、どの様にデータが使われるかWeb利用者が知ることができ、どのデータやどんな利用をWeb利用者が"オプトイン"または"オプトアウト"することが可能か知ることができるようにすることである。

1.1.2 P3P利用例

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ステートメントの内容についても説明する。そこで、花子さんは、要求されたものが受け入れ可能か否か判断することができ、もし、受け入れ可能であるならば、彼女は、注文操作を継続することができ、受け入れることができないならば、トランザクションをキャンセルすることができる。

上記の場合と異なり、花子さんが、ブラウザに「サイトが電話番号を要求し、そして、その情報を第三者に渡し、そして／または、現在の注文処理以外に用いるならば、警告する」ように設定しているならば、花子さんは、如何なるポップアップメッセージが表示されることなく、注文操作を完了することができる。

(注)本シナリオは、あくまでも仮想のインプリメンテーションであり、ユーザインターフェースは、上記以外のものも可能である。

1.1.3 P3Pポリシー

P3Pポリシーは、ポリシーの中にプライバシー情報を如何に処理するか表記している組織を識別するためP3PボキャブラリのXMLエンコーディングを用い、収集されるデータ型とデータ要素を列挙し、そして、どの様にデータが使われるか説明する。更に、ポリシーは、データの受領者を明確にし、係争解決のための情報のような情報開示にまつわる諸々のものを作成可能にし、当該サイトの人間が読むことのできるプライバシーポリシーの存在場所(URL)の通知を行う。P3Pポリシーは、関係する総てのデータ要素とそれをどう使うかカバーしなければならない。(しかし、法の執行の際に必要とされる情報に関する法律的問題はこの仕様書では関知しない。：例えば、公権力によって要求された場合、第三者に提供しないはずのデータがポリシーの規定に反して、他の組織に提供されることがあるかもしれない。)P3Pの記述は、ポジティブな記述であるべきである。すなわち、あるサイトが何々をしないと記述するよりは、何々を行うと記述することが望ましい。P3Pボキャブラリは、ある特殊な法律や行動規範に準拠するためのインディケータというより、サイトがプライバシー情報を如何に取り扱うかを記述することを目的に設計されている。しかしながら、幾つかのユーザエージェントは、サイトのプライバシー情報の取り扱い方が法律や行動規範に合っているか否かテストするために、開発されるかもしれない。

P3Pポリシーは、サイトがプライバシー情報を如何に取り扱うかを表現する。しかし、電気通信プロバイダやISP、プロキシ業者、その他の中間業者が、サイトと利用者との間のプライバシーデータ交換に関与するが、それらの中間業者が何を行っているかについて、サイトのポリシーは関与しない。

1.1.4 P3Pユーザエージェント

P3P1.0ユーザエージェントは、Webブラウザか、ブラウザプラグインか、プロキシサーバに組み込まれることができる。また、それらはJavaアプレットもしくは、JavaScriptで実装され、電子財布や自動フォーム入力やその他の利用者データ管理機能の中に組み込まれるかもしれない。P3Pユーザエージェントは、周知の存在場所にあるP3Pへの参照とHTTP応答の中にあるP3Pヘッダ及びHTMLコンテンツの中に埋め込まれているP3P linkタグを捜す。これらの参照は、関係するP3Pポリシーの存在場所を示している。ユーザエージェントは、示された存在場所からポリシーを取り込み、それを解析し、シンボルを表示したり、音を鳴らしたり、サイトのP3Pプライバシープラクティスを示すプロンプトメッセージを生成したりする。更に、ユーザエージェントはP3Pポリシーを利用者が設定したプライバシープリファレンスの集合と比較し、適切な処理を行うことが可能である。P3Pは、電子財布や自動フォーム入力のようなデータ転送メカニズムにおけるある種の"ゲートキーパー"の機能を行うこともできる。あるP3Pユーザエージェントは、P3Pポリシーを検索したり、利用者のプリファレンスと比較したり、次の二つの条件を満たしたときデータを送出するメカニズムの何れか中に統合されるかもしれない。a)ポリシーが、利用者のプリファレンスと一致している。そして、b)要求されたデータ転送が、ポリシーと一致している。もしも、これらの条件の何れかに合致していないならば、利用者に、不一致の通知と、データを送出するか否か選択する機会が与えられるべきである。

1.1.5 サーバ上でのP3Pの実装

Webサイトは、利用者に文章で開示しているプライバシーポリシーをP3P構文に翻訳し、ポリシーへ適用しているサイトの一部を示すポリシー参照と一緒に、その結果のファイルを公開することにより、P3P1.0を実装することができる。自動化ツールにより、この翻訳を行うサイトの運営者を支援することが可能である。P3P1.0はソフトを特に追加したりアップグレードすることなく、現在のHTTP/1.1準拠のWebサーバにおいて構築できる。サーバは周知の存在場所からポリシー参照ファイルを構築でき、あるいはlink タグを使ったHTMLコンテンツでP3Pポリシー参照ファイルを参照するかもしれない。または、サイトのP3Pポリシー参照ファイルの存在場所を示すHTTPレスポンスへP3P拡張ヘッダを挿入するような互換性のあるサーバを構築できるであろう。

Webサイトは、サイト全体に一つのP3Pポリシーを付与することもできるし、そのサイトの異なる部分に異なるポリシーを指定するといったこともできる。ある一つのP3Pポリシーは、そのサイトへの訪問者とHTTPでやりとりする際に生成されたり、交換されたりするすべてのデータをカバーするものでなければならない。更にいうと、幾つかのサイトは、データがどの様に収集されたかにかかわらず、総てのデータをカバーするP3Pポリシーを作ることを望むかもしれない。

1.1.6 P3Pの将来バージョン

P3Pの早期の実装と最初の普及を容易にするために、前回のP3P1.0使用書から重要な章を削除した。当該グループは、P3P1.0が普及した時点で、 P3Pの次期仕様書にこれらの機能を組み込むことがある。このような仕様書には、実装経験や普及時の経験を反映させるとともに、P3P1.0から落とされた、次の4つの重要な機能を盛り込む予定である。

サイトに、サイト利用者がP3Pポリシーを選択させることを可能にする機能。
サイト利用者が、(ユーザエージェントを介して)あるP3Pポリシーに明示的に合意することを可能にする機能。
サイト利用者とWebサイトの間で結ばれた合意の否認を防止する機能。
ユーザエージェントがサービスにデータを転送する機能。

1.2 本仕様書について

W3Cの正式仕様書作成手順に従い、本仕様書は、相互互換性のあるP3Pアプリケーションの作成に必要とされる総ての仕様を包含している。

本仕様書で用いられている[ABNF]記述は、RFC2234に従ったものであり、その概略を付録 7に示す。しかし、その構文は、XML構文で示される単なる一つの文法であることに注意されたい。そうであるけれども、XMLで表現できる構文の意味するところの総てを理解することができるであろう。例えば、空白規則、引用符(')や二重引用符(")を用いた引用、エスケープ文字、コメント、各部分での記述方法などである。XMLが要素属性の順番付けには柔軟性を与えているが、要素の順番つけには柔軟性を与えていないということに注意されたい。XML要素は文書タイプの定義（DTD）に示されている順番になっていなければならない。

以下の節では幾つものXML要素が紹介されている。各エレメントは有効な属性のリストに従って、かぎかっこ("<element>")の中に示されている。リストされている属性は必須であると決められていない限り、すべて選択が自由である。多くのXML要素がオプション要素を取り入れられるように、独立した最初と終わりのタグを持つBNF内に示されていることに注意されたい。XML規則に従って、エレメントがまったく含まれない場合は、セルフクロージング（自動的に終了する）エレメントが代わりに使用されることがある。

本仕様書は、必要性の程度を表す為、RFC2119 [KEY]に定義されている次の用語を用いる。次の重要な用語が、相互互換性を実現する為に、本文書全体を通して用いられている。

「～しなければならない」もしくは「～してはならない」: この用語または形容詞"要求される"は、当該アイテムが本仕様書において絶対的に必要なものであることを意味する。
「～するべきである」もしくは「～するべきでない」: この用語または形容詞"推奨される"は、当該アイテムが正当な理由のもとに、ある状況下において無視できることを意味する。しかし、完全実装の場合、実装すべきものであり、実装しない場合、注意深く検討すべきものである。
「～してもよい」: この用語または形容詞"オプショナル"は、当該アイテムがあっても無くてもよいものであることを意味する。例えば、あるベンダーは、プロダクトを魅力あるものとする為、マーケット戦略的にこのアイテムを含めるかもしれないが、他のベンダーはこのアイテムを落とすかもしれない。

1.3 専門用語

文字: [XML]のXML勧告で定義された連続する0個以上の文字からなる文字列。P3Pの中のひとつの文字は、それに一致するひとつの抽象化されたUnicode値と同じになる（[UNICODE]参照）。
データ要素: 名字や電話番号といった個々のデータの実体を意味する。相互互換性のため、P3P 1.0はデータ要素の基本集合を定めている。
データカテゴリ: 「実社会における連絡先情報」などのような、データ要素やデータ集合のある重要な属性を指し、トラストエンジンにより、どのデータ型が処理中なのか判断する為に用いられる。P3P 1.0は、データカテゴリの集合を定めている。
データ集合: "user.home.postal"といった、データ要素の一般的なグループのことである。このP3P 1.0は、幾つかの基本データ集合を定めている。
等価なプラクティス: オリジナルのプラクティスと比較して、目的、受領者、個人を特定別可能な利用などが同じか、もしくは、より制約されているプラクティスであり、更に、その他の情報開示事項が本質的に異ならないものをいう。例えば、異なる業界ガイドラインに準拠しているが、似ているプラクティスを有する二つのサイトをいう。
個人特定可能情報: 個人に関するか、個人を特定可能な任意の情報
ポリシー: 一つ、もしくは複数のプライバシーステートメントの集まりであり、所有者、URI、保証や当該のポリシーによってカバーされるサービスの係争解決手続きなどと一緒になっている。
プラクティス: データの利用の仕方、目的、受領者やその他の情報公開事項などを述べている情報公開の集合。
プリファレンス: ユーザエージェントが行うべきアクションを決める一つの規則、もしくは、規則の集合。あるプリファレンスは、形式定義の算定可能なステートメント(例；プリファレンス交換言語[APPEL])により記述されるかもしれない。
目的: データ収集とデータ利用の理由。
レポジトリ: ユーザエージェントの管理下で、利用者情報を格納しておくメカニズムをいう。
セーフゾーン: サービスプロバイダーが最低限のデータ収集をおこなうWebサイトの一部であり、収集されたあらゆるデータが識別不可能な方法の場合にのみ使用される。
サービス: ポリシーを発行し、必要ならデータ要求を行うプログラムをいう。この定義に従えば、サービスは、サーバ(サイト)、ローカルアプリケーション、ローカルに動くアクティブコード(ActiveXコントロールやJavaアプレット等)や他のユーザエージェントであってもよい。
サービス提供者(データ管理者、組織): Webサイトを使って情報やプロダクトを提供し、情報を収集し、プラクティスステートメントを作成し掲示する人、もしくは、組織をいう。
ステートメント: P3Pステートメントは、データ要素の収集を行うときに開示されるプライバシープラクティスの集合である。
URI: Webリソースを特定する為に用いられるUniform Resource Identifierをいう。 URIの構文及びセマンティクスに関する詳細は付録の[URI]を参照されたい。XMLやHTMLに書かれたURIは、[CHARMODEL]のCharacter Encoding in URI References章で定義されたように取り扱われるとみなす。このことは、HTTPヘッダに含まれるURI参照を適用するものではなく、URIはHTTPヘッダでいつも逃れるべきである。
利用者: サービスを利用し、個人情報を有する個人(または、単体の様に行動する人々のグループ)をいう。
ユーザエージェント: 利用者の代りに、ユーザプリファレンスに基づいて、サービスとのやりとりを仲介することを目的に作られたプログラムをいう。一人の利用者が複数のユーザエージェントを持つことができ、また、ユーザエージェントは、必ずしもデスクトップ上に存在しなければならないことはないが、 総てのユーザエージェントは利用者だけの利益のために動作し、利用者の制御下になければならない。 このような利用者とユーザエージェントの信頼関係は、P3P外部の制約によって左右されるかもしれない。例えば、あるユーザエージェントは、オペレーティングシステムやWebクライアントの一部として、また、ISPやプライバシー代行業者の契約条項の一部として、信頼されるかもしれない。

2. ポリシー参照

2.1 ポリシー参照の概要と目的

P3Pポリシーを設置することは、P3Pプロトコル工程における初期段階のステップである。サービスは、どのP3Pポリシーが特定のどのURI、またはURIの集合に適用するかを述べる為にポリシー参照を使用する。ユーザエージェントは、ページに適用されたプライバシーポリシーを発見する為にポリシー参照を使用する。従って、ユーザエージェントは、利用者のためにポリシーを処理することができる。

ポリシー参照は、パフォーマンスの最適化として使われる。プライバシーポリシーを参照しているURIは、通常100バイト未満であるが、P3Pポリシーは通常、数キロバイトのデータである。帯域幅の節約に加えて、ポリシー参照は、コンピュータの演算処理の必要性を軽減する：ポリシーは、URIとユニークに関連付けられることができる。従って、ユーザエージェントは、ポリシーが適用されている文書毎にポリシーを処理する必要はなく、一度ポリシーを解析し、処理すればよい。さらに、中央集権化された場所に、関連のあるポリシーに関する情報を置くことによって、Webサイトの管理が簡素化される。

ポリシー参照ファイルはURLスペースのある領域とP3Pポリシーの対応づけのために使用される。また、ポリシー参照ファイルは以下のどれか、もしくはすべてのステートメントを作成するために使用される。

P3Pポリシーが発見されたURI
P3PポリシーでカバーされているURIスペースのURIもしくは領域
P3PポリシーでカバーされていないURIスペースのURIもしくは領域
P3Pポリシーでカバーされている別のサーバ上の埋め込みコンテンツのURIスペースの領域
P3Pポリシーでカバーされているまたはカバーされていないクッキー
P3Pポリシーが適用できるアクセスメソッド
上記の要求が有効だと考えられる時期

これらのステートメントのすべてはポリシー参照ファイルの主要部分に作成されている。一番最後のステートメントは、また、HTTP期間終了ヘッダを使って、ポリシー参照ファイル上に作成することができる。その例と説明は2.3節を参照されたい。

2.2 ポリシー参照ファイルの存在場所

この節では、ポリシー参照ファイルの設置場所を示す為に使用されるメカニズムを説明する。サポートされているメカニズム用に構文の詳細も示す。

ポリシー参照ファイルの存在場所は三つのメカニズムの内、一つを使って示す事ができる。ポリシー参照ファイルは周知の場所にあるか、 HTML LINKタグまたは、HTTPヘッダを通してポリシー参照ファイルを示している。ポリシー参照ファイルはその文書に適用しているP3Pポリシーを指定する。または、そのP3Pポリシーは同様に別のURIに適用する可能性もある。このポリシー参照ファイルは一つのWeb文書、Webサイトの一部またはWebサイト全体の為のポリシーを指定することのできるXMLファイルである。（［XML］を参照のこと）　ポリシー参照ファイルは一つ以上のP3Pポリシーを参照することがある。従って、たとえ異なるP3Pポリシーがサイトの異なる部分に適用されているとしても、一つのポリシー参照ファイルで全部のサイトをカバーすることができる。

ユーザエージェントがHTTPを使用してHTMLコンテンツの取得をサポートする場合、ユーザエージェントは上記の三つのメカニズムすべてを互換的に処理しなければならないことに注意すること。どのメカニズムも他の二つをオーバーライドしない。一義性の要求事項も参照すること。

ポリシーはHTTPの実体レベルで適用されることに注意されたい。URIを取り出すことによって取得された実体には、実体に対応づけられているP3Pポリシーがある。ユーザの相対的見地からの"ページ"は複数のHTTPの実体で構成されていることがある。各実体には、関連した独自のP3Pポリシーがあるかもしれない。しかし、実質的な注釈として、一つのページ上の異なる実体に、多くの異なるP3Pポリシーを置くことは、そのページをレンダリングし、ユーザに適切なポリシーがユーザエージェントに対して困難である事をしらせることがある。また、サービスは一つのポリシー参照ファイルが、与えられた"ページ"をカバーできるようにポリシー参照ファイルを作成しようとするべきである。そうすれば、ユーザのブラウジングが早くなるのである。

実体に適用されたポリシーを処理するユーザエージェントのために、実体用のポリシー参照ファイルを発見し、そのポリシー参照ファイルを取り出し、ポリシー参照ファイルを解析し、必要なP3Pポリシーを取得し、P3Pポリシーまたはポリシーを解析しなければならない。

この文書はHTTP以外の方法で取り出された文書にP3Pポリシーがどのように関連しているかについては述べてはいない。しかし、他のプロトコルで取り出された文書と対応づけられているP3Pポリシーのメカニズムの今後の開発は除外していない。さらに、HTTPを使用して取り出した文書と対応づけられているP3Pポリシーの追加的な方法は今後開発されるかもしれない。

2.2.1 周知の存在場所

P3Pを使っているWebサイトはポリシー参照ファイルを"周知の"存在場所に置くべきである。このために、ポリシー参照ファイルはそのサイトの/w3cディレクトリにp3p.xmlという名前で置かれるだろう。従って、ユーザエージェントはリソース/w3c/p3p.xmlに対しGET要求を使ってポリシー参照ファイルを要求することができる。

サイトがこのメカニズムを使う必要がないことに注意。しかし、このメカニズムを使って、サイトは他のリソースがそのサイトからリクエストされる前に、 P3Pがユーザエージェントにアクセス可能になることを保証できる。このことによって、ユーザエージェントがセーフゾーンプラクティスを使ってサイトにアクセスする必要性が低減する。さらに、もしサイトがこのメカニズムを使用する場合、周知の存在場所に位置しているポリシー参照ファイルが全部のサイトをカバーする必要はない。例えば、内容のすべてがひとつの組織の管理下にあるわけではないサイトは、このメカニズムを使用しないかもしれない。あるいはそのサイトで限られた部分のみをカバーするポリシー参照ファイルを置くかもしれない。

ポリシー参照ファイルのために周知の存在場所を使うことは、ポリシー参照ファイルを指定するような他のメカニズムの使用を妨げるものではない。サイトの一部においては、一義性条件が満たされる範囲において、ポリシー参照ファイルを指定する他のメカニズムを使うかもしれない。

例えば、MallExample社のWebサイトショッピングモールを考えると、そのWebサイト（mall.example.com）において、そのモールで商品あるいはサービスを提供している会社は/companies/company-nameのパスで表せるような、そのサイト特定のサブツリーを得るだろう。そのMallExample社は/companiesサブツリーを除いた全てをカバーするようなポリシー参照ファイルを、周知の存在場所に置くことを決めるかもしれない。その場合、ShoeStoreExamples社は、/companies/shoestoreexampleといったコンテンツを持つが、その会社は、mall.example.comサイトの一部をカバーするポリシー参照ファイルの存在場所を示すその他のメカニズムを使うこともできる。

ポリシー参照ファイルのために周知の存在場所を使うことが特に有効であると予想される1つのケースとしては、一つのサイトが複数のホスト上に分割したコンテンツを持っているようなケースである。例えば、静的なHTMLコンテンツよりもWebベースのアプリケーションすべての異なる論理ホストを使用するサイトの例を考えてみる。ポリシー参照ファイルの存在場所を指定することを許す他のメカニズムは、アクセスされたホスト上においてポリシー参照ファイルの存在場所を持ってくるアクションURIが必要である。しかしながら、周知の存在場所を示すメカニズムは、そのような必要がない。 www.example.comに位置するHTMLフォームの例を考えてみる。フォーム上のアクションURIがサーバcgi.example.comを指していたとする。そのフォームをカバーするポリシー参照ファイルは、フォームを処理するためのアクションURIに関するどんなステートメントも作成することができない。しかしながら、サイト管理者はアクションURIをカバーするポリシー参照ファイルを http://cgi.example.com/w3c/p3p.xmlで公開することにより、フォームのコンテンツを送信する前に、ユーザエージェントはアクションURIに適用されている P3Pポリシーを容易に発見できる。

2.2.2 HTTPヘッダ

HTTPで取り出したあらゆる文書は新しいレスポンスヘッダ、P3Pヘッダ（[P3P-HEADER]）を使用して、ポリシー参照ファイルを示してもよい。もしサイトがP3Pヘッダを使用している場合、HEADやOPTIONSの要求を含むすべての適切な要求方法のために、レスポンスヘッダにP3Pヘッダを組み込むべきである。

P3Pヘッダは一つ以上のコンマで区切られた命令を提供する。以下がその構文である。

[1]
p3p-header

=

`P3P: ` p3p-header-field *(`,` p3p-header-field)

[2]
p3p-header-field

=

policy-ref-field | compact-policy-field | extension-field

[3]
policy-ref-field

=

`policyref="` URI `"`

[4]
extension-field

=

token [`=` (token | quoted-string) ]

ここで、URIはRFC 2396[URI]によって定義され、 tokenとquoted-stringは[HTTP1.1]によって定義されている。

その他のHTTPヘッダに従うために、いかなる場合でもこのヘッダのP3P部分を書き込まれることがある。

このpolicyrefの命令はポリシー参照ファイルを指定するURIをもたらす。そして、このポリシー参照ファイルは他のファイルと同じようにこのファイルを示している文書をカバーしている P3Pポリシーを表している。 policyrefに与えられているURIを取り出す事が300クラスHTTPリターンコード（リダイレクション）でもよいことに注意されたい。ユーザエージェントはこれらが普通のHTTPセマンティクスと同様にリダイレクトすると解釈しなければならない。もちろん、リダイレクトの使用によって、ユーザエジェントがポリシーを発見し、解釈するために必要な時間が増えるという事にサービスは注意するべきである。 P3Pポリシーを識別し、参照する以外の目的のためにpolicyref URIを使用してはならない。

"簡潔なポリシー"を指定する為にcompact-policy-fieldが使用される。この件に関しては4章に述べている。

（extension-fieldsにおいて）認識されていない命令を発見したユーザエージェントは、その認識されていない命令を無視しなければならない。そうすることによって、今後のP3Pの普及を簡単にすることができる。

例 2.1:

1. ClientがGETリクエストをおこなう。

GET /index.html HTTP/1.1
Host: catalog.example.com
Accept: */*
Accept-Language: de, en
User-Agent: WonderBrowser/5.2 (RT-11)

2. サーバはコンテンツとポリシーのページを示すP3Pヘッダを返信する。

HTTP/1.1 200 OK
P3P: policyref="http://catalog.example.com/P3P/PolicyReferences.xml"
Content-Type: text/html
Content-Length: 7413
Server: CC-Galaxy/1.3.18

2.2.3 HTML `link`タグ

サーバは、適切なP3Pポリシー参照ファイルの存在場所を示したlinkタグが埋め込まれたHTMLコンテンツを提供してもよい。このP3Pの使用方法は、サーバの動作を変更する必要はない。

linkタグは、P3Pヘッダを使用して表現される情報を記号化する。linkタグは以下の形式をとる：

[5]
p3p-link-tag

=

`<link rel="P3Pv1" href="` URI `">`

ここで、URIはRFC 2396 [URI]に従って定義されている。

例を使ってlinkタグを説明するために、HTTPヘッダを使用して例2.1に示されているポリシー参照を考える。その例は以下のHTMLの一部分を有するリンクタグを使用して、同様に表現できる。

<link rel="P3Pv1"
    href="http://catalog.example.com/P3P/PolicyReferences.xml">

最後に、p3p-link-tagはHTML文書に埋め込まれているので、その文字エンコーディングはHTML文書の文字エンコーディングと同じになる。 P3Pポリシーとポリシー参照文書（下の2.3章と3章)とを対照すると、p3p-link-tagは[UTF-8]を使ってエンコードする必要はない。

2.3 ポリシー参照ファイルの構文とセマンティクス

この節ではポリシー参照ファイルの詳細を説明する。

2.3.1 ポリシー参照ファイルの例

Webサイトが以下のステートメントを作成したいというケースを考えた場合：

P3Pポリシー /P3P/Policy1.xmlを、/catalog、/cgi-bin、/servletサブディレクトリを除くサイト全体に適用する。
P3Pポリシー /P3P/Policy2.xmlを、/catalogディレクトリ（サブディレクトリも含む）内の全ての文書に適用する。
P3Pポリシー /P3P/Policy3.xmlを、/servlet/unknownディレクトリを除く、/cgi-binと/servletディレクトリ（サブディレクトリも含む）内の全ての文書に適用する。
/servlet/unknownディレクトリに、どのP3Pポリシーが適用されるかのステートメントはない。
ステートメントは2日間有効である。

上記のステートメントは以下のXMLによって表記される：

例 2.2:

<META xmlns="http://www.w3.org/2000/12/P3Pv1">
 <POLICY-REFERENCES>
  <EXPIRY max-age="172800"/>

    <POLICY-REF about="/P3P/Policy1.xml">
      <INCLUDE>/*</INCLUDE>
      <EXCLUDE>/catalog/*</EXCLUDE>
      <EXCLUDE>/cgi-bin/*</EXCLUDE>
      <EXCLUDE>/servlet/*</EXCLUDE>
    </POLICY-REF>

    <POLICY-REF about="/P3P/Policy2.xml">
      <INCLUDE>/catalog/*</INCLUDE>
    </POLICY-REF>

    <POLICY-REF about="/P3P/Policy3.xml">
      <INCLUDE>/cgi-bin/*</INCLUDE>
      <INCLUDE>/servlet/*</INCLUDE>
      <EXCLUDE>/servlet/unknown</EXCLUDE>
    </POLICY-REF>

 </POLICY-REFERENCES>
</META>

この例に文書の中に適切な有効期限がある。その有効期限もHTTPヘッダを通して表す事ができる：

このページを提供しているサーバがこのファイルと共にCache-Control:max-age=172800ヘッダを返す事ができる、または、
このサーバがレスポンスのにおいて、Dateヘッダから2日間後を示したExpiresヘッダを生成できる。

2.3.2 ポリシー参照ファイルの定義

この節では、P3Pポリシー参照ファイルの構文とセマンティクスを定義する。全てのポリシーは、[UTF-8]を使用してコード化されなければならない。 P3Pサーバは、この構文を使用してポリシー参照をコード化しなければならない。 P3Pユーザエージェントは、この構文を解析できなければならない。

ポリシー参照ファイルの構文に関しての重要なポイントは、ここで定義されている構文は、拡張機能を持たないという事である。 P3Pポリシーの構文は強力な拡張機能（extension mechanism）を持っているが、ポリシー参照ファイルは、この機能をサポートしていない。

2.3.2.1 ポリシー参照ファイルの処理

2.3.2.1.1 順序の意義

ポリシー参照ファイルは複数のPOLICY-REF要素を含んでいるかもしれない。ポリシー参照ファイルが二つ以上の要素を持っている場合、ユーザエージェントはファイルに書かれている順番でその要素を処理しなければならない。ユーザエージェントがどのポリシーを与えられたURIに適用するかを決めようとする時は、そのURIに適用するポリシー参照ファイルにある最初のPOLICY-REF要素を使用しなければならない。

2.3.2.1.2 ポリシー参照ファイルのワイルドカード

ポリシー参照ファイルは与えられたURIにどのポリシーを適用するかを示す。ポリシー参照ファイルはURIスペースの領域についてのステートメントを作成する為の単純なワイルドカード文字をサポートしている。文字アスタリスク("*")は0文字以上の文字列を表すために使用されている。他の文字（正規表現にあるような）はサポートしていない。アスタリスクはまた、URI([[URI]])においても適切に使用されている文字なので、ポリシー参照ファイルの"拡張URI"のエンコード時には、いくつかの特別な規則を守らなければならない：

policy-refファイルに表されているURIを、[URI]で書かれているように適切にエスケープしなければならない。
P3Pユーザエージェントは、ポリシーにURIを合わせようとする前に[URI]に従って、エスケープすべき文字をエスケープしなければならない。
P3Pユーザエージェントは、ポリシーEXCEPTにURIを合わせようとする前に[URI]に従って、エスケープされたURIで適切に使用されている文字列をアンエスケープしなければならない。
P3Pユーザエージェントは、ポリシーにURIを合わせようとする前に、URIのリテラルな'*'をエスケープしなければならない。
P3Pユーザエージェントは、[URI]に適応しないあらゆるURIパターンを無視しなければならない。

ワイルドカード文字はINCLUDE および EXCLUDE 要素、 EMBEDDED-INCLUDE および EMBEDDED-EXCLUDE 要素、 COOKIE-INCLUDE および COOKIE-EXCLUDE 要素で使用されるかもしれない。

2.3.2.2 `META` および `POLICY-REFERENCES` 要素

META要素は、完全なポリシー参照ファイルを含む。ポリシー参照ファイル内には、必ず一つのPOLICY-REFERENCES要素がなければならない。任意に一つのPOLICIES要素はあとに続くことができる。また、P3P1.0ユーザエージェントはその他のXMLマークアップを無視しなければならないが、その他のXMLマークアップはPOLICY-REFERENCES（もしあれば、POLICIES）に従ってもよい。

<POLICY-REFERENCES>: この要素は一つ以上のPOLICY-REF（ポリシー参照）を含んでいるかもしれない。また一つのEXPIRY要素（その有効期限を示している）とインラインポリシーも含んでいるかもしれない。

[6]
prf

=

`<META xmlns="http://www.w3.org/2000/12/P3Pv1">` policyrefs [policies] PCDATA "</META>"

[7]
policyrefs

=

"<POLICY-REFERENCES>" [expiry] *policyref "</POLICY-REFERENCES>"

ここで、PCDATAは[XML]で定義されている。

2.3.2.3 ポリシー参照ファイルの有効期限と`EXPIRY`要素

2.3.2.3.1 モチベーションとメカニズム

サーバがユーザエージェントに参照ファイルのクレームがどのくらいの期間有効であるかを知らせる事が望ましい。クライアントがポリシー参照ファイルのコンテンツをキャッシュ可能にすることによって、 Webページに関連したプライバシーポリシーを処理する時間を短縮する。また、これによってネットワークのロードも縮小できる。さらに、URIに有効なポリシー参照のないクライアントは要求に対して、"セーフゾーン" プラクティスを使う必要がある。有効であるポリシー参照ファイルをクライアントが持ってる場合、処理方法に関し、情報に基づく決定をしやすくなる。

ポリシー参照ファイルの有効期限はユーザエージェントに参照ファイルのクレームがどのくらいの期間有効であるかを知らせる。たとえば、ポリシー参照ファイルに3日間の有効期限がある場合、ユーザエージェントは3日間ファイルをリロードする必要がなく、参照ファイルからの参照は3日間有効であると仮定することができる。一つのポリシー参照ファイルで参照されるすべてのポリシーは同じ有効期限をもつであろう。 P3Pポリシーのために異なる有効期限を指定するための唯一の方法は、個々のポリシー毎に異なるポリシー参照ファイルを使用することである。

ポリシーとポリシー参照ファイルの有効期限を決定する場合、サイトは二つの事柄を考慮する有効期限を選ぶ必要がある。その一つはユーザエージェントがキャッシングから十分な利益をうけることができるくらいの長さが有効期限として必要であること。もう一つは、有効期限の終了を非常に長く待たずに、サイトがポリシーを変更できるということである。上記二つを満たすのに妥当な有効期限は1～7日の間であると思われる。ポリシーを更新する際、サイトはポリシー改版要求事項を記憶する必要がある。

ポリシー参照ファイルの有効期限が終了したら、ユーザエージェントはポリシー参照ファイルを再び有効にするまで、もしくは、ポリシー参照ファイルの新しいコピーを取り出すまでは、ポリシー参照ファイルの情報を使用してはならない。

2.3節で述べたように、ポリシー参照ファイルの有効期限を設定するのに二つのメカニズムがある。二つの異なるメカニズムはサイトにポリシー参照ファイルを作成するのに更なる柔軟性をもたらすために提供される。ポリシー参照ファイルにはファイルに有効期限をもたらすEXPIRY要素を含んでもよい。ポリシー参照ファイルにEXPIRY要素がなければファイルに関連しているHTTPキャッシュ管理ヘッダはポリシー参照ファイルの有効期限を与える。

ユーザエージェントが有効期限の切れていないポリシー参照ファイルまたはポリシーファイルを再び取り出す必要はないが、 "セーフゾーン" プラクティスを使用する必要性を避ける為に、ポリシー参照ファイルの有効期限が切れる前にファイルを更新してもよい。

2.3.2.3.2 `EXPIRY` 要素

ポリシー参照ファイル（またはポリシーが）がいつまで有効かという事を示すためにEXPIRY要素はポリシー参照ファイルおよび/またはP3Pポリシーで使用できる。有効期限の有効期は絶対的有効期限または相対的有効期限として与えられる。絶対的有効期限は、GMTによって与えられる期間であり、ポリシー参照ファイル（またはポリシーが）が有効であるまでの期間である。相対的有効期限はポリシー参照ファイル（またはポリシーが）が有効であるための時間（秒）を与える。この相対的有効期限はサーバから送られたレスポンスの時間に相当する。（Date:レスポンスのヘッダで述べたように）

[8]
expiry

=

"<EXPIRY" (absdate|reldate) "/>"

[9]
absdate

=

`date="` HTTP-date `"`

[10]
reldate

=

`max-age="` delta-seconds `"`

ここで, HTTP-dateは[HTTP1.1]の3.3.1節で定義されており、delta-seconds は[HTTP1.1]の3.3.2節で定義されている。

2.3.2.3.3 HTTPヘッダの使用

ポリシー参照ファイルがEXPIRY要素を含んでいない場合、ポリシー参照ファイルで提供されているHTTPヘッダはその有効期限を決定する。しかしながら、ユーザエージェントはポリシー参照ファイルの有効期限を算出するために最近修正されたものをベースとした自己発見機能の有効期限を使用してはならない。ポリシー参照ファイルの有効期限を決定するためにHTTPヘッダを使用する場合、ユーザエージェントは、Expires, Cache-Control,または使用可能であれば、ファイルと共に提供されるPragmaヘッダをベースとして、ポリシー参照ファイルの有効期限を算出しなくてはならない。こういったヘッダのセマンティクスは[HTTP]によって定義されている。これらのヘッダが利用できない場合、有効期限はサーバが文書を送信した時点から24時間にセットされなければならない。サーバはポリシー参照ファイルの有効期限を明白にする為に、上記のEXPIRY要素またはHTTPヘッダの一つを使用するべきである。

ネットワーク上のキャッシュ存在の可能性と、HTTPでの有効期限の自己発見機能は、有効期限の考慮をかなり複雑なものとする。キャッシュの有効期限がサーバによって明白に定義されていないポリシー参照ファイルの場合を考えた場合（例：レスポンス内に上記のいかなるヘッダも含まれていない）、ネットワークキャッシュは、間違いなく更新日を基にポリシー参照ファイルのキャッシュ有効期限を算出するであろう；結果としてのキャッシュの有効期限は、24時間より非常に長くなるであろう。キャッシュがHTTP/1.0を実装し、ユーザエージェントがこのポリシー参照ファイルを取得した場合、ユーザエージェントはどのくらいの期間この参照ファイルがキャッシュされていたかを知る方法はない。従って、ユーザエージェントは、参照ファイルの有効期限が既に切れているかどうか、又はいつ有効期限が切れるかを知ることは不可能である。 HTTPプロトコルは、HTTP/ 1.1に準拠したキャッシュがキャッシュから要求を満たす時に、Ageヘッダを送信しなければならないと述べているので、HTTP/ 1.1 cacheでは、ややこの状況を改善している。しかしこれだけでは十分ではない；キャッシュは、ここで定義されている24時間の有効期限を越えたファイルを返信することができるので、結果として意味のないポリシー参照ファイルとなる。この問題を回避する為、ユーザエージェントは、ポリシー参照ファイルを取得する時に、最新のファイルをロードすることを保証しなければならない。従って、ユーザエージェントは、ポリシー参照ファイルを取得する時に、Pragma: no-cache又はCache-Control:no-cache要求ヘッダのどちらかを含まなければならない。 HTTP/ 1.0 chacheとの互換性の為、Pragma: no-cache要求ヘッダの方が推奨される。

クライアントが、HTTP要求に影響を及ぼす遅延を正確に予測することは不可能であることに注意すること。従って、要求をカバーするポリシー参照ファイルの有効期限がすぐに切れる場合、クライアントは利用者に注意を促し、（又は）要求の遂行を続ける前にポリシー参照ファイルを再検証することを望んでもよい。

2.3.2.3.4 ポリシー参照ファイル有効期限のためのエラー処理

特別に定義されたセマンティクスが以下のようなの状態の時にある。

ポリシー参照ファイルにEXPIRY要素があり、前記の2.3.2.3.3で述べたHTTPヘッダの内のひとつで提供されている場合、 EXPIRYヘッダはポリシー参照ファイルの有効期限を決定することを優先する。
過去の絶対的有効期日によって、ポリシー参照ファイルは失効となる。 Expires:の日付をこれがカバーする。HTTPヘッダもEXPIRY要素の有効期限の属性と同様である。
相対的であれ、絶対的であれ、無効もしくは規定外の有効期日は過去のものだと考えるべきである。無効もしくは規定外の有効期日によって、ポリシー参照ファイルは失効となる。
二つ以上のEXPIRY要素がある場合、ポリシー参照ファイルの有効期限を決めるのには、最初にある日付を優先する。

2.3.2.4 `POLICY-REF`要素

ポリシー参照ファイルは、個々の情報を指定することによって、複数のP3Pポリシーを参照するだろう。 POLICY-REF要素は単一のP3Pポリシー属性を記述する。POLICY-REF要素内の要素は、ポリシーの存在場所を提供し、個々のポリシーがカバーするURI空間の領域を指定する。

POLICY-REF: 単一のP3Pプライバシーポリシーに関する情報を含む。
about (必須の属性): P3PプライバシーポリシーのURI。もしこれが相対URLであれば、ポリシー参照ファイルのURIに関するものとして解釈される。これは、ポリシー参照ファイルに含まれているポリシーへの参照としてもよい。そのために、ポリシーURIは#policy-nameによって与えられ、 policy-nameは、このポリシー参照ファイルのポリシーの name属性で値を与えられたものである。

[11]	policy-ref	=	`<POLICY-REF about="` URI `">` include exclude cookie-include cookie-exclude embedded-include embedded-exclude *method-element `</POLICY-REF>`
ここで、`URI`はRFC 2396 [URI]に従って定義されている。

2.3.2.5 `INCLUDE`要素および`EXCLUDE`要素

個々のINCLUDE要素又はEXCLUDE要素は、単一のローカルURIまたはローカルURIの集合を指定する。ワイルドカード文字(*)がURIパターンで使用されれば、ローカルURIの集合が指定される。このような要素は、含まれているPOLICY-REF要素によって示されるポリシーによってカバーされるWebサイトの一部を特定する為に使用される。

INCLUDE要素（任意でEXCLUDE）がPOLICY-REF要素内に存在する場合、POLICY-REF要素のabout属性において指定されているポリシーは、要求したホストにおいて、INCLUDEによって指定されているlocal-URIに一致する全てのURIに適用される事を意味し、EXCLUDE要素によって指定されたURIは含まない。

METHOD要素（2.3.2.8節）が一つ以上のポリシー参照を含むことを規定する。それはつまり、記述されなかった全てのメソッドが、必然的にこのP3Pポリシーによってカバーされないことを意味する。この場合、これは与えられたURI-refixのためのポリシー参照だけとなり、ユーザエージェントは、メソッドがポリシー参照ファイルで記述されなかった全てにポリシーが実施されないとみなさなければならない。

INCLUDE要素なしにEXCLUDE要素を供給することは合法的ではあるが、無意味である。その場合、ユーザエージェントはEXCLUDE要素を無視しなくてはならない。

ポリシー参照ファイルは、参照ファイルと同様のホスト上のURIのみをカバーすることができる。従って INCLUDE要素とEXCLUDE要素は、ローカルURIのプレフィックスを指定しなければならない；それらの要素は、他のホスト上にあるURIを参照してはならない。この要求事項は、P3Pポリシーファイル（POLICY-REF要素におけるabout属性）の存在場所には適用されない。

INCLUDE要素とEXCLUDE要素で指定されたURIの集合は、そのURI の内のひとつを要求するときにおこるだろうクッキーを含まないことに注意されたい。クッキーとポリシーを対応づけるためには、COOKIE-INCLUDE と COOKIE-EXCLUDE要素が必要である。

[12]
include

=

"<INCLUDE>" relativeURI "</INCLUDE>"

[13]
exclude

=

"<EXCLUDE>" relativeURI "</EXCLUDE>"

ここで、相対URIはsection 2.3.2.1.2節で定義されているように、'*' 文字がワイルドカードとして取り扱われている事と共にRFC 2396 [URI]に従って定義されている。

2.3.2.6 `EMBEDDED-INCLUDE` と `EMBEDDED-EXCLUDE` 要素

HTMLページは、時に、イメージ、音、レイヤあるいはフレームのような、ページに直接埋め込まれた他のリソースへのリンクを含んでいる。従って、そのようなページを表現するために、ユーザエージェントは、現在使われているページにおけるポリシーによってカバーされるか、しないかといった追加のリクエストを行う必要がある。埋め込まれたコンテンツは第三のサーバによって提供されなければならないので、（また、INCLUDEとEXCLUDEはローカルURIプレフィックスのみを指定しなければならない）、付加的な要素はそのコンテンツと対応付けられなければならない。

各EMBEDDED-INCLUDEまたはEMBEDDED-EXCLUDE要素は第三の絶対URI（[URI]を参照のこと）を指定する。これらのプレフィックスはポリシー参照ファイルが存在するWebサイト上の文書にコンテンツが埋め込まれている時に about属性によって指定されているポリシーがカバーしている第三のサーバを設定する為に使用される。（これはINCLUDEおよびEXCLUDEと同様である）しかしながら、絶対URIが"埋め込み"と考えられる時期の範囲を制限するために、 HTTP Refererヘッダを利用する：

EMBEDDED-INCLUDE（と任意にEMBEDDED-EXCLUDE）要素がPOLICY-REF要素にある場合、 埋め込まれているポリシー参照ファイルがカバーしているリソースからのURIを含むRefererヘッダを使用して正常にURIが要求されれば、 POLICY-REF要素のabout属性に設定されているこのポリシーはEMBEDDED-INCLUDE要素で合わせられているURIすべてに適用し、 EMBEDDED-EXCLUDEによっては合わせられていないというを意味する。

この事はこのポリシーが埋め込まれるかリンクしているオブジェクトに適用されることを意味するが、オブジェクトは埋め込まれていない。プロキシの実装はRefererオブジェクトを適用しているポリシーを持つユーザエージェントによって作成された Refererヘッダを調査し、埋め込まれたコンテンツポリシーが有効であるかを決める。

P3PユーザエージェントはWebサイトへRefererヘッダを送るのに必要ではない。事実、これはユーザのプリファレンスとセーフゾーンの問題であり、ユーザエージェントはEMBEDDED-INCLUDEポリシーが適用するかどうかを決める為に Refererを使用したあと、そのRefererを放棄することがある。

ユーザエージェントは、ユーザエージェントが取得するかもしれない第三のコンテンツを適用するポリシーを決める為に、ポリシー参照ファイルのEMBEDDED-INCLUDE要素とEMBEDDED-EXCLUDE要素を解釈しなければならない。

例2.5は /P3P/Policy1.xmlがサブツリー/docs/とファイル/other/index.htmlの文書すべてに適用しているという事を示している。加えて、このポリシーはadserver.example.comドメインのホストの/ads/ディレクトリ（/network/サブディレクトリは含まない）から要求された埋め込み文書に適用している。

Example 2.5:

<META xmlns="http://www.w3.org/2000/12/P3Pv1">
 <POLICY-REFERENCES>
    <POLICY-REF about="/P3P/Policy1.xml">
      <INCLUDE>/docs/*</INCLUDE>
      <INCLUDE>/other/index.html</INCLUDE>
      <EMBEDDED-INCLUDE>http://*.adserver.example.com/ads/*</EMBEDDED-INCLUDE>
      <EMBEDDED-EXCLUDE>http://*.adserver.example.com/ads/network/*</EMBEDDED-EXCLUDE>
    </POLICY-REF>
 </POLICY-REFERENCES>
</META>

EMBEDDED-INCLUDEおよびEMBEDDED-EXCLUDE要素の構文は:

[16]
embedded-include

=

"<EMBEDDED-INCLUDE>" absoluteURI "</EMBEDDED-INCLUDE>"

[17]
embedded-exclude

=

"<EMBEDDED-EXCLUDE>" absoluteURI "</EMBEDDED-EXCLUDE>"

ここで、相対URIはsection 2.3.2.1.2節で定義されているように、'*' 文字がワイルドカードとして取り扱われている事と共にRFC 2396 [URI]に従って定義されている。

サイトは埋め込みコンテンツのいくつかまたは、すべてのポリシーを指定しないように選択するかもしれないことに注意されたい。そのような場合、P3Pユーザエージェントはその埋め込みコンテンツをホストしているサイトから直接P3Pポリシーの取得を試みるべきである。

また、INCLUDEとEXCLUDEの場合のように、EMBEDDED-INCLUDEとEMBEDDED-EXCLUDEで指定されたURIの集合にはURIの一つの要求時におこるであろうクッキーがないことに注意。クッキーとポリシーを対応付けるにはCOOKIE-INCLUDEおよびCOOKIE-EXCLUDE要素が必要である。

2.3.2.7 `COOKIE-INCLUDE` と `COOKIE-EXCLUDE` 要素

COOKIE-INCLUDEおよびCOOKIE-EXCLUDE要素はポリシーとクッキーを関連づけるために使用される。

クッキーポリシーはそのクッキーに格納されるかまたはクッキーを通じてリンクされているあらゆるデータ（P3Pの範囲内で）をカバーしなければならない。また、クッキーに格納されるか、または、クッキーを通じてリンクされているかまたは、クッキーが可能にしているデータに関連するすべての目的を参照しなければならない。また、クッキーに格納されているかまたはそれを通じてリンクされているデータ/目的はクッキーポリシーに入れられなければならない。さらに、そのリンクされたデータがHTTPによって収集された場合、 GET/POST、どのリクエストをもカバーしているポリシーはそのデータ収集をカバーしなければならない。例えば、CatalogExampleが顧客に名前と取り引き、出荷情報をフォームに書くよう要求をすれば、そのフォームの提出をカバーするP3PポリシーはCatalogExampleがこのデータの収集を公開し、どのように使用されたかを明らかにする。 CatalogExampleが顧客を認識し、その顧客のウェブサイトでの行動を監視できるようにクッキーを設定すれば、このクッキーに対する独立したのポリシーを持つことになるだろう。しかしながら、このクッキ-がユーザの名前と取り引き、出荷情報にリンクされていれば、 --恐らくCatalogExampleは顧客の住んでいる場所を元にして顧客カタログページを作成できる--そのデータもクッキーポリシーで公開されなければならない。

この仕様書の目的として、ステート管理メカニズムはSET-COOKIEまたはSET-COOKIE2ヘッダを使用し、クッキーネーム空間はName、Domain、およびPath属性（[COOKIES] と [STATE]で述べている）の値として定義されている。

各COOKIE-INCLUDEおよびCOOKIE-EXCLUDE要素は、空白文字で分割している三つのトークンで構成されているクッキーネーム空間を指定する。これら三つのトークンは、ポリシー参照ファイルが存在するウェブサイトのドキュメントからクッキーが設定される時にabout属性によって指定されているポリシーがカバーしているクッキーネーム空間を表して、クッキーのNAME、Domain、Pathコンポーネントを照合するために使用される。

COOKIE-INCLUDE（および任意でCOOKIE-EXCLUDE）要素はPOLICY-REF要素に存在している時、 POLICY-REF要素のabout属性に指定されているポリシーがCOOKIE-INCLUDEに合わせ、 COOKIE-EXCLUDEに合わせられていないクッキーネーム空間をもつクッキーすべてに適用する。

クッキーがそのサイトに存在しているか、または、そのサイトに埋め込まれている要素からクッキーが設定されている場合以外（2.3.2.6節に述べている様に）は、サイトはクッキー用のポリシーを宣言できない。ユーザエージェントはクッキーを適用しているポリシーを決めるためにポリシー参照ファイルにある COOKIE-INCLUDEおよびCOOKIE-EXCLUDE 要素をそれに応じて解釈しなければならない。 COOKIE-INCLUDEおよびCOOKIE-EXCLUDE要素はポリシーとポリシー参照ファイルのクッキーを対応づけるための唯一のメカニズムであることに注意されたい。（4章を参照のこと）

ポリシーの有効期限が終了するまで、クッキーを適用しているポリシーは有効である。クッキーと対応しているポリシーの期限が終了していたり、ユーザエージェントのプリファレンスが変更されていれば、ユーザエージェントはクッキーを送信する前にクッキーポリシーを再度評価するべきである。

例2.3では/P3P/Policy1.xmlがクッキーすべてに適用していることを示している。

例2.3:

<META xmlns="http://www.w3.org/2000/12/P3Pv1">
 <POLICY-REFERENCES>
    <POLICY-REF about="/P3P/Policy1.xml">
       <COOKIE-INCLUDE>* * *</COOKIE-INCLUDE>
    </POLICY-REF>
 </POLICY-REFERENCES>
</META>

例2.4ではネーム値"obnoxious-cookie"、ドメイン値".example.com"、パス値"/"を持つクッキーを除いて、 /P3P/Policy1.xmlがクッキーすべてに適用していることと、/P3P/Policy2.xml がクッキー名"obnoxious-cookie"、ドメイン値".example.com"、パス値"/"を持つクッキーすべてを適用していること.を示している。

例 2.4:

<META xmlns="http://www.w3.org/2000/12/P3Pv1">
 <POLICY-REFERENCES>
    <POLICY-REF about="/P3P/Policy1.xml">
       <COOKIE-INCLUDE>* * *</COOKIE-INCLUDE>
       <COOKIE-EXCLUDE>obnoxious-cookie .example.com /</COOKIE-EXCLUDE>
    </POLICY-REF>
    <POLICY-REF about="/P3P/Policy2.xml">
       <COOKIE-INCLUDE>obnoxious-cookie .example.com /<COOKIE-INCLUDE>
    </POLICY-REF>
 </POLICY-REFERENCES>
</META>

[14]
cookie-include

=

"<COOKIE-INCLUDE>" token ; matches the cookie's NAME " " token ; matches the cookie's Domain " " token ; matches the cookie's Path "</COOKIE-INCLUDE>"

[15]
cookie-exclude

=

"<COOKIE-EXCLUDE>" token ; matches the cookie's NAME " " token ; matches the cookie's Domain " " token ; matches the cookie's Path "</COOKIE-EXCLUDE>"

ここでは、2.3.2.1.2節で定義されているように、 token の'*' 文字がワイルドカードとして取り扱われている付加で token 、NAME、Domain とPathはRFC 2965 [STATE]に従って定義されている。

[STATE]と同じ様に、はっきりと定義されたDomain値がピリオド(".")で始まっていなければ、ユーザエージェントはピリオドを付けなければならないことに注意。また、すべてのPathは"/" シンボルで始まることにも注意されたい。

2.3.2.8 `METHOD` 要素

デフォルトでは、ポリシー参照は、リソースにアクセスする為に使用されるメソッドに関係なく指定されたURIに適用される。しかしウェブサイトは、リソースに適用されるメソッドに応じて、異なるP3Pポリシーを定義したいかもしれない。例えばサイトは、利用者がGETメソッドを行っている時よりは、 PUTやDELETEメソッドを行っている時に、より多くの利用者情報を収集したいと望むかもしれない。

ポリシー参照ファイル内のMETHOD要素は、含まれているポリシー参照が、参照されるリソースにアクセスする為に、指定されたメソッドが使用された時のみ有効である事を示す為に使用される。 METHOD要素は、複数の適用できるメソッドを示す為に繰り返されるであろう。 METHOD要素がPOLICY-REF要素内にない場合、POLICY-REF要素は、リソースにアクセスするメソッドに関係なく、示されたリソースをカバーする。

従って、/P3P/Policy1.xmlが、GETとHEADメソッドの時に/docs/サブディレクトリ内の全ての文書に適用し、一方で、/P3P/Policy2.xmlは、PUTとDELETEメソッドの時に適用される事を示す場合、以下のポリシー参照ファイルを記述することができる：

例 2.6:

<META xmlns="http://www.w3.org/2000/12/P3Pv1">
 <POLICY-REFERENCES>
    <POLICY-REF about="/P3P/Policy1.xml">
      <INCLUDE>/docs/*</INCLUDE>
      <METHOD>GET</METHOD>
      <METHOD>HEAD</METHOD>
    </POLICY-REF>
    <POLICY-REF about="/P3P/Policy2.xml">
      <INCLUDE>/docs/*</INCLUDE>
      <METHOD>PUT</METHOD>
      <METHOD>DELETE</METHOD>
    </POLICY-REF>
 </POLICY-REFERENCES>
</META>

HTTPにおいて、GETとHEADリクエスト要求は同じふるまいをすることに注意。つまり、メソッド毎に異なったP3Pポリシーを指定することは不適当である。 METHOD要素の構文は:

[18]
method-element

=

`<METHOD>` Method `</METHOD>`

ここで、Methodは [HTTP1.1]の5.1.1節に定義されている

2.3.3 ポリシーをURIへ適用

ポリシー参照ファイルは与えられたURIに適用するポリシーを指定する。これは、示されているポリシーはその与えられたURIに対するポリシー参照ファイルのリストにある方法のいずれかを行うことの影響をすべて述べているということを意味している。

URIをカバーするP3Pポリシーの表していることを述べている一般的な規則がある。参照されたポリシーは、ユーザのクライアントソフトウェアがそのURIを要求した結果として行うと考えられている行動をカバーしなければならない。明らかに、このポリシーはURIへの要求処理の結果としてサイトが行ったデータ収集すべてについて述べなければならない。従って、与えられたURIがGET要求の言葉のためにカバーされれば、ポリシー参照ファイルが与えたポリシーはURIが取り出された時にサイトが行ったデータ収集についてすべて述べなければならない。同様に、URIがPOST要求のためにカバーされれば、フォームやURIへの他のコンテンツをポストする結果として起こるデータ収集はこのポリシーで述べなければならない。

"クライアントソフトウェアが行うと考えられている行動"という概念には、クライアント側のクッキーやレスポンスによって呼び出されるステート管理メカニズムの設定が含まれている。 URIが要求された時、実行可能なコードが返されれば、URIをカバーしているP3Pポリシーはコード実行時に起こるある行動をカバーしなければならない。そのカバーされた行動はユーザがはっきりと呼び出さずにできた行動のことである。明確なユーザの行動がデータ収集を引き起こせば、その行動のためにURIをカバーしている P3Pポリシーはデータ収集を公開するだろう。

明確な例:

URIを取り出すとフォームを含むHTMLページが返され、ユーザが"Submit"ボタンをクリックすると、そのフォームコンテンツは二番目のURIへ送られる。この二番目のURIをカバーしているP3Pポリシーはそのフォームが収集したすべてのデータを開示しなければならない。最初のURI（ここからそのフォームがロードされている）をカバーしている P3Pポリシーはフォームに収集されるデータを公開してもよいし、しなくてもよい。
HTMLページはそのページがどのくらい表示されたかとそのページ上のあるオブジェクトの上にユーザがマウスを動かしたかどうかを追跡するJavaScriptコードを含んでいる。ページがアンロードされると、JavaScriptコードはHTMLページが始まるサーバにその情報を送る。 JavaScriptコードの行動はHTMLページのP3Pポリシーによってカバーされなければならない。その推論は、この行動は、ユーザが知らないうちに起こったり、またはユーザの同意なしに起こり、ページのロードの結果として自動的に起こるというものである。
レスポンスは電子メールプログラムのインストール可能なイメージである。この電子メールプログラムを使用する為にユーザはインストールプログラムを起動し、電子メールプログラムを起動させ、この機能を使用する。電子メールプログラムがダウンロードされたURIをカバーしているP3Pポリシーは、この電子メールプログラムを使用して収集する事のできるデータについてのステートメントを作成する必要がない。この電子メールプログラムをインストールし、起動することはウェブブラウジングをすることとは明らかに違うものであるので、この仕様書ではカバーしていない。異なるプロトコルのダウンロードを可能にしたアプリケーションをP3Pに表すことができるようにデザインする事ができたが、この仕様書には述べない。
フォームを含んでいるHTMLページはカスタムクライアントコントロールを提供する実行可能なものへの参照を含む。このコントロールにあるデータはフォームが提示された時にサイトへ提示される。この場合、HTMLページのURIとカスタムコントロールのURIは、カスタムコントロールが表示しているデータについてのステートメントを作成する必要がない。しかしながら、フォームコンテンツがあるURIは、フォームを処理する事で他のデータをカバーするように、カスタムコントロールからのデータをカバーしなければならない。このふるまいは、HTMLフォームが標準のHTMLコントロールを使用する時のHTMLの処理方法と類似している。このコントロール自身はデータを収集することはなく、このフォームが知らされた時にデータが収集される。この例はユーザが積極的に"Submit"やそれに類似したボタンを押すとこのフォームが通知されるだけであるということを仮定していることに注意されたい。フォームが自動的に通知されれば、（例えばこのページのJavaScriptコードで）この例は例#2と類似するだろう。そして、フォームから収集されたデータはHTMLフォームをカバーしているP3Pポリシーに記述されなければならない。
URIへの要求は第三者ヘリダイレクトされる。第一者が以前収集した個人データを照会列やリダイレクトURIの他の部分に埋め込めば、第一者のURIのプライバシーポリシーは転送されたデータ種類を記述しなくてはならないし、第三者を受領者としてとりこまなければならない。

2.3.4 フォームおよび関連するメカニズム

フォームは、CGIスクリプトへのリンクや、その他のサーバ側アプリケーションへのURIなど、特別な考察に値する。時にこれらのアクションURIはフォーム自身よりも異なるポリシーによってカバーされることがある。

もし、ユーザエージェントが、そのページから参照されるポリシー参照ファイルで定義された action URIに相当するプレフィックスを見つけられないならば、それは有効なポリシーが全くないとするべきである。このような事情から、ユーザエージェントは、アクションURIをカバーするポリシー参照ファイルを見つける試みのためのアクションURIにあるホスト上の周知の存在場所をチェックするべきである。もし、アクションURIをカバーするP3Pポリシーを提供するものでなければ、ユーザエージェントはHEADリクエストを、その結果としてポリシーを見つけるための何らかのデータ送信の前のアクションURIとして実行してもよい。サーバ側では、アプリケーションがHEADのようなリクエストに適切に答え、該当するポリシー参照のリンクヘッダを返すよう、明確にするべきである。このようにアプリケーションの下にあるケースの場合、HEADリクエストがわからず、問題となっているアクションURIを示す仮宣言されたポリシーが全くないことになり、ユーザエージェントは有効なポリシーが全くないとしなければならず、そしてユーザにこれについて確認し、ユーザのプリファレンスに従って通信手段を取るようにするべきである。

サービスが、POSTやGETなど、サポートされるメソッドのサブセットをカバーすることだけを行うサーバ側のアプリケーションのためのポリシーを宣言するための <METHOD>要素を利用することを望むかもしれないことに注意。このような事情において、問題となっているアプリケーションがポリシー参照ファイルで与えられた方法をサポートするだけであることは適切である（すなわち、HEADリクエストはサポートされる必要はない）。もし、フォームのmethod属性で指定された関連するメソッドがそのページのポリシー参照ファイルで適切に仮宣言されたならば、関連するメソッドがフォームのそのページのポリシー参照ファイルで適切に仮宣言されたならば、ユーザエージェントはアクションURIへのHEADリクエストを問題点として試みるべきでない。

ある場合には、異なったデータがフォームの中で選択されたものに応じて同じアクションURIで集められる。例えば、探索サービスが（名前あるいは電子メールなどで）人と（独断的な）イメージにおいて検索を試みようとするかもしれない。フォームでラジオボタンを使うとき、ひとつのサーバ側のアプリケーションはひとつに決められ、そして同じアクションURIは両方のケースを処理して、そして探索に必要な必要情報を集める。もしサービスがサーバ側のアプリケーションのデータ収集の処理を仮宣言することを望むなら、それは一つのポリシーファイルのデータ収集すべてを（アクションURIにあわせている<INCLUDE>宣言を使用して）宣言するかもしれない。この場合、ユーザエージェントはデータ要素すべてが、あらゆる状況で収集されることを仮定しなければならない。このソリューションは一つのポリシーでは便利さを提供する。しかし、ただリストされたデータ要素の一部だけが一度に集められるという事実に適切に反映しないかもれない。サービスがアクションURIへの単純なヘッド要求（すなわち、選択されたラジオボタンの値が特に存在しないという理由なしに）はすべてのケースをカバーするようなポリシーを返すであろうことを明確にすべきである。

フォームがGETメソッドの使用を通して処理されれば、アクションURIはユーザが選択したフォーム要素の選択に反映することに注意。同じアクションを処理するURIの異なる使用に対して異なるポリシーを指定するために、ポリシー参照ファイルで許可されたワイルドカード構文を使用する事が可能である場合がある。それゆえ、ユーザエージェントはポリシー参照ファイルでINCLUDEとEXCLUDEを比較する時に URIの質問列部分を含まなければならない。

2.4 追加要求事項

2.4.1 一義性

ポリシー参照の第一の規則は、一義性である。ウェブサイト上の各リソースに対し、ある時点で有効なプライバシーポリシーはたかだか一つでなければならない。このようにサイトにある有効期限が終了していないポリシー参照ファイル二つは、同じリソースに対して2つ以上の異なるポリシーURIを宣言してはならない。

周知の場所にあるポリシー参照ファイルが与えられたURIの有効期限が終了していないポリシーを宣言すれば、 HTTPヘッダまたはHTML link タグを通して引用された相反するポリシー参照ファイルに関わりなく、このポリシーは適用をおこなう。

2.4.2 多言語

同一のポリシーの多言語版（翻訳版）は、そのポリシーが特定の言語によってエンコーディングされていることを正確に示すために、 HTTPの"Content-Language"ヘッダを用いることによって、サーバによって提供することができる。このことは、「組織（entity）」や「結果(consequence)」のような人間が読むことのできる箇所を様々な言語で表現することができるので有用である。データスキーマの多言語版を提供するために、同じメカニズムも使用することができる。

同一URI上で多言語で提供されている複数のポリシーを区別するためにContent-Languageが使用される場合は、常にそれらのポリシーは各言語を通して同一の意味を持たなければならない。2つのポリシー（または2つのデータスキーマ）が同じであるためには

（自然言語ではない）すべての形式的なプロトコル要素が意味的に同一であること（すなわち、属性オーダとデフォルト値の有無は重要ではない、しかし属性値が重要である）。
すべての自然言語プロトコルの要素が1対1で対応する。そしてそれぞれの対応のため、1つは他の1つと確実に対応しているような変換でなければならない。

Accept-Languageメカニズムの利用を通して、P3Pを実装する人は、もしポリシーあるいはデータスキーマの新しい言語バージョンが加えられたなら、同じAccept-Languageリクエストヘッダを送信しても、ユーザエージェントはポリシーまたはポリシー参照ファイルの異なった言語バージョンを見る事になるかもしれないことに注意しなければならない。

2.4.3 セーフゾーン

P3Pを利用可能な全てのユーザエージェントとサービスは、 P3Pプライバシーポリシーを取得する行為の一部として行われる全ての通信は、そこにおいては最小限のデータ収集のみ行い、収集したデータを個人特定不可能な方法でのみ使用することを意味する特別な"セーフゾーン"の一部であることを保証するべきである。特に、ポリシー参照ファイルのための周知の存在場所のりクエストはこれらの"セーフゾーン"によってカバーされるべきである。

このセーフゾーンをサポートするために、P3Pユーザエージェントはサイトのポリシーが取得されるまで、サイトのポリシーを発見する目的に不必要なデータの送信を控えるべきである。従ってユーザエージェントはP3Pポリシーを要求する間、HTTPのRefererヘッダを送信したり、クッキーを受信したりするべきではない。ユーザエージェントはまた、P3Pポリシーが要求されている時、ユーザエージェント情報や前回のセッションで受け入れられているクッキーの送信を控えたがるかもしれない。ユーザエージェントを実装する人は、P3Pポリシーをリクエストするとき、Accept-Language HTTPヘッダを使うことで、プライバシ交換があることを知っている必要がある。正しいAccept-Languageヘッダを送ることは、利用者が好む自然言語でP3Pポリシーを取得することを許すだろう（もし、利用可能ならば）。しかし、それはとあるユーザの識別についての情報を見せることになる。ユーザエージェントは、Accept-Languageヘッダを送るべきか利用者が決めるように聞くことを望むかもしれない。

サーバはポリシーまたはポリシー参照ファイルを提供するために、HTTP Refererヘッダや、クッキー、ユーザエージェント情報、要求に対する応答に不必要なその他の情報の受領を要求するべきではない。加えてサーバは、ポリシーやポリシー参照ファイルを提供している間や、 HEAD要求に応答している間に収集した全ての情報を、個人を認識可能な用途で使用するべきではない。

サーバは、P3Pポリシーが要求された時に、応答ヘッダ内にP3Pヘッダを含んで応答してもよい。しかし、P3Pヘッダは無視されなければならない事に注意することが重要で、上記で説明された"セーフゾーン"の要求事項が代わりに用いられる。この様な場合にP3Pヘッダを返すことは、管理者がサーバ上にある全ての文書に対して一つのP3Pポリシーを簡単に適用させることができ、かつP3Pヘッダなしにポリシーを要求することがサイトの管理者の負担を増加させるかもしれない事情に鑑みて許可されることである。

セーフゾーン要求は、サイトが個人を特定可能な情報を保持することができないといっている訳ではなく、ポリシーを提供している間に収集した情報を、個人を特定可能な用途に使用するべきでない事のみをいっている。サービスへのアタックに関するトラックダウン拒否は、個人を特定可能な情報を使用する為の合法的な理由となり、この勧告を無視できる事になる。

2.4.4 ポリシーの非差別化

サーバはユーザエージェントがP3Pポリシーを探すのに最大の助力をするべきである。特に、サーバはできる限りP3Pポリシーを周知の場所に置くべきである。 P3P HTTPヘッダが代わりに使用される時は特にサーバ以下をするべきである：

全ての要求に対してポリシーを参照する:: P3Pに準拠したサーバは、可能である場合には必ず、ウェブリソースに対するポリシー参照ファイルへのリンクを含むべきである。
HTTP HEAD 要求のサポート: P3Pに準拠したサーバは、GET要求によって取得できる全ての文書のためにHEAD 要求をサポートするべきである。なお、技術的に実行可能な場合は、サーバは通常、他のHTTPメソッド（POSTなど）によってアクセス可能である文書のために、 HEAD 要求に対しての有効な応答を提供しなければならない。

2.4.5 ポリシーの送信に関するセキュリティ

P3PポリシーとP3Pポリシーへの参照内に、いかなる機密情報をも含むべきではない。この事は、P3Pプライバシーポリシーが関連付けられた文書の要求事項の枠を超えて、 P3Pプライバシーポリシーへの参照を送信する事に関するセキュリティーの追加要求事項が無いことを意味する。従って、通常HTML文書が暗号化なしのセッシションを通して提供されている場合、 P3Pプロトコルは、文書に含まれているP3Pプライバシーポリシーを参照する時に、暗号化されたセッションを通して文書が提供されることを要求しないし、推奨もしない。

2.4.6 ポリシーの改版

ウェブサイトがP3Pポリシーを変更すると、変更前のポリシーは変更が実行された時に、収集されたデータを適用することに注意。変更が行われたら、その日付に従って、過去のP3Pポリシーとポリシー参照ファイルを記録し続け、それらのポリシーを適切に適用することはサイトの責任である。

もし、サイトが新しいP3Pポリシーを以前に収集されたデータに適用したいと思えば、サイトはユーザが法律と一致する新しいポリシーや工業ガイドライン、またはサイトが作成したその他のプライバシーに関する同意書を受け入れる様に、適切な注意や機会を提供しなければならない。

2.5 シナリオの例

P3Pを普及するサイトへの補助として、これらのサイトでP3Pの使用されている方法の記述に従って、いくつかのシナリオの例を紹介する。

シナリオ 1: ウェブサイトbasic.example.comはさまざまなイメージを使用し、それらすべてをホストする。また、basic.example.comにはいくつかのフォームがあり、そのフォームはすべてサイトに直接提示される。このサイトはすべてのサイトに対する一つのP3Pポリシーを宣言する事ができる。（または、異なるプライベートポリシーがサイトの異なる部分へ適用すれば、複数のP3Pポリシーを宣言することができる。）ディレクトリにあるイメージとフォームアクションURIのすべてがサイトのP3Pポリシーでカバーされている限り、ユーザエージェントは自動的にそのイメージとフォームがそのサイトのポリシーにカバーされていると認識するだろう。

シナリオ 2: ウェブサイトbusy.example.comはサーバ上のロードを減少させるためにイメージをホストするcdn.example.comというコンテンツ配布ネットワークを使用している。従って、このサイトのイメージすべてにはcdn.example.comでURIがある。この状況でCDNはBusyへのエージェントとして動作し、ログデータ以外は収集しない。このログデータはBusyが契約しているサービス提供をサポートするウェブサイトおよびシステムアドミニストレータのためにしか使用されない。BusyのプライバシーポリシーはCDNがホストするイメージに適用するので Busyは、そのP3Pポリシーがcdn.example.com によって提供される埋め込みコンテンツに適用していると述べるためにポリシー参照ファイルのEMBEDDED-INCLUDE要素を使用することがある。また、cdn.example.comには、任意に、busy.example.comのプライバシーポリシーがこれらのイメージに適用していると宣言するポリシー参照ファイルがある。

シナリオ 3: また、busy.example.com はサイトに目立つ広告を提供するためclickads.example.comという広告会社と契約をしている。この契約によって、各ユーザが3回を超える広告を見る事ができないようにする為にClickadsはクッキーを設定することができる。Clickadsはユーザが何回その広告を見たかという統計を収集し、商品が広告されている会社にその統計を報告する。しかし、この報告は各個人について明らかにしているものではない。シナリオ2のケースの様に、BusyのプライバシーポリシーはClickadsがホストしている広告に適用しているので、 BusyはP3Pポリシーがclickads.example.comから提供されている埋め込みコンテンツへ適用していることを述べるために、ポリシー参照ファイルのEMBEDDED-INCLUDE要素を使用する。clickads.example.comには任意に、busy.example.comがこれらの広告を適用していることを宣言しているポリシー参照ファイルがある。商品宣伝広告されている会社が受け取るデータが総合されているので、その会社は、Busyのプライバシーポリシーに述べられる必要はない。

シナリオ 4: ユーザのためのチャットルームをホストする為にウェブサイトbusy.example.comはfunchat.example.comと契約する。ユーザがチャットルームへ参加すると、実際にはBusyサイトからは離れていく。しかしながら、このチャットルームにはBusyのロゴがあり、Busyのプライバシーポリシーでカバーされている。この場合、Funchatは、シナリオ3と違って、Busyのエージェントとして動作しているが、このコンテンツはBusyサイトには埋め込まれていない。この時、BusyがFunchatをそのポリシー参照ファイルに組み込むことはない。しかしながら、BusyはFunchatにBusyのP3Pポリシーを示しているサイトにポリシー参照ファイルを置くよう指示すべきである。

シナリオ 5: ウェブサイトbigsearch.example.comにはユーザが検索問い合わせに入力し、他のサイトのサーチエンジンを選んで作動させることができるフォームがある。ユーザが"submit"ボタンをクリックすれば、検索問い合わせは実際にそのサーチエンジンに直接提示される。アクションURIはbigsearch .example.com上にはないが、ユーザが選択したサーチエンジン上にはある。フォームアクションは埋め込みコンテンツではないので、Bigsearchはこれらのサーチエンジンのプライバシーポリシーを宣言することはできない。だから、ユーザが"submit"ボタンをクリックすると、ユーザエージェントは適切なサーチエンジンへ作動し、データが通知される前にプライバシーポリシーをチェックする。この検索選択メカニズムを操作させるために、BigsearchはサイトにアクションURIを持つフォームを有することがある。そして、適切なサーチエンジンにリダイレクトする。この場合、ユーザエージェントはリダイレクトレスポンスを受け取ることに関するサーチエンジンプライバシーポリシーをチェックすべきである。

シナリオ 6: ウェブサイトbigsearch.example.comにはユーザが検索問い合わせに入力し、同時に10の異なるサーチエンジンを作動させることができるフォームがある。Bigsearchはその問い合わせを提示し、各サーチエンジンからその結果を受け取り、複写を削除し、その結果をユーザに提示する。この場合、ユーザは自分のBigsearchのみと対話する。したがって、P3Pに関わっているのは、Bigsearch ウェブサイトをカバーしているものだけである。しかしながら、Bigsearchはこれらのサーチエンジンと契約し、そのサーチエンジンがBigsearchへのエージェントとして動作している場合以外は、ユーザの検索問い合わせを第三者と共有していることを開示しなくてはならない。

シナリオ 7: ウェブサイトbigsearch.example.comにはAdnetworkという会社が提供した目立つ広告がある。Adnetworkはさまざまに異なるウェブサイトのユーザに関するプロファイルを展開するためにクッキーを使用する。そのため、Adnetworkはユーザの興味により適した広告を提供する事ができる。ユーザがアクセスしたサイトについてのデータはBigsearch ウェブサイトに広告を提供する目的以外に使用されているので、Adnetworkはこのコンテキストのエージェントと考えることはできない。どのコンテンツを適用しているかを示すために、Adnetworkは自身のP3Pポリシーを作成し、自身のポリシー参照ファイルを使用する。さらに、BigsearchはAdnetworkP3Pポリシーがその広告を適用していることを示すために、ポリシー参照ファイルのEMBEDDED-INCLUDE要素を任意に使用することがある。もし、AdnetworkがどのP3Pポリシーをその広告に適用しているかを述べ、ポリシー参照ファイルに変更があればBigsearchに知らせることに合意したなら、BigsearchはEMBEDDED-INCLUDE要素だけを任意に使用すべきである。

シナリオ 8: ウェブサイトbusy.example.comはウェブサイトにクッキーを使用している。クッキーポリシーを公開し、これらのクッキーをカバーするために通例のP3Pポリシーからクッキーポリシーを独立させている。また、クッキーに対して適切なポリシーを宣言するためにポリシー参照ファイルにCOOKIE-INCLUDE要素を使用している。性能最適化として、ウェブサイトbusy.example.comはクッキーが設定されると必ず簡潔なポリシーを含むＰ３Ｐヘッダを送信して、簡潔なポリシーを有効にしている。

シナリオ 9: ウェブサイトconfig.example.comは各ユーザのコンピュータとインターネット構成をもとにあらゆるウェブコンテンツを最適化するサービスを提供している。ユーザはそのConfigウェブサイトにアクセスし、コンピュータやモニター、インターネット接続に関する質問に答える。Configはその回答を暗号化し、クッキーに格納する。その後、ユーザがBusy-Configと契約しているウェブサイト-を訪れている時、ブラウザが最適化できるコンテンツ（あるイメージやオーディオファイルなど）を要求する時は必ずBusyはユーザをConfiguにリダイレクトする。そしてそのConfigはユーザのクッキーを読み取り、適切なコンテンツに配信する。この場合、Configは収集され、クッキーに格納されたデータの種類とデータの使用される方法を宣言べきである。また、そのクッキーのポリシーを宣言するポリシー参照ファイルでCOOKIE-INCLUDEを使用すべきである。Configはシナリオ２のCDNの行動と同じように動作している時、配信された実際のイメージやオーディオファイルのBusyのP3Pポリシーを参照する。Busyは恐らくConfig配信コンテンツのポリシーを参照するためにポリシー参照ファイルのEMBEDDED-INCLUDE要素を使用する。

3. ポリシーの構文とセマンティクス

P3PポリシーはXMLでエンコードされる。それはRDFデータモデル[RDF]を使うことを意味する。しかし、RDFでの表現については、この仕様書には含まれていない（そういった表現は、適切なポリシー参照ファイルのRDFエンコーディングと共にP3PをProposed Recommendationとして出す前に、W3Cノートとして利用可能なようにする計画である）。

3.1節では、自然言語で書かれたポリシーとそれに対応するP3Pポリシーの実例を挙げる。P3Pポリシーの中には、ポリシー全体に適用される全般的な主張と、参照データにおいて言及された特定のデータ型の取扱いのみに適用される特定の主張（これをステートメントと呼ぶ）とがある。3.2節では、POLICY要素とポリシーレベルの主張について説明する。3.3節ではステートメントと参照データについて説明する。

3.1 ポリシーの例

3.1.1 自然言語のポリシー

以下の文章は自然言語で書かれたプライバシーポリシーの2つの例である。後節で、このポリシーをP3Pポリシーにコード化する。どちらのポリシーもひとつの会社、CatalogExample社の例であり、彼らのサイトを閲覧している人むけのポリシーと、実際に商品を購入している人むけのポリシーといった異なったポリシーを持っている。例3.1はP3P要素と属性名を使用して自然言語を正式な記述で提供している。

例 3.1: CatalogExample社の閲覧者向けプライバシーポリシー

CatalogExample社はあなたのプライバシーを大切にします。あなたが記事を探すために私達のサイトに来られたときには、私達はサイトを改善するためだけにその情報を使います。そして、身元確認可能な方法で保管することはありません。

CatalogExample社はPrivacySealExampleプログラムの認可を持っています。 PrivacySealExampleは、ウェブサイト使用権利者に高いプライバシー基準を取得させ、そして会計監査人と一緒にこれらの情報の業務がフォローされていることを確認することにより、あなたのプライバシーを保証しています。

このステートメントに関する質問はこちら：
CatalogExample社

4000 Lincoln Ave.

    Birmingham, MI 48009 USA

    email: catalog@example.com

    Telephone 248-EXAMPLE (248-392-6753)

もし私達があなたの問合せに返答しなかったか、あるいはあなたの問合せが満足に扱われなかったときには、http://www.privacyseal.example.orgによってPrivacySealExampleと連絡を取ることができます。CatalogExample社はプライバシーポリシーに関連し発生しうるすべてのエラーあるいは不法な行動を修正します。

私達が集める情報とその理由:
あなたが私達のサイトを閲覧することによって集める情報：

あなたのPCとの確実な接続を確実にすることとセキュリティを目的とした基本情報。
私達のサイトを改善するため、どのページにアクセスされるか、あるいは訪問するかといった集計情報。

データの保管:
隔週ごとに集める閲覧情報の整理をします。

例3.1をP3P要素と属性名を使った正式な記述は以下のとおりである。 [容易な参照のために仕様書の章をカッコでくくっている]:

情報公開URI(Disclosure URI): http://www.catalog.example.com/PrivacyPracticeBrowsing.html
[3.2.2 Policy]
組織(Entity): CatalogExample社
4000 Lincoln Ave.
Birmingham, MI 48009
USA
catalog@example.com
+1 (248) 392-6753
[3.2.4 Entity]
個人特定情報へのアクセス: なし(None)
[3.2.5 Access]
係争解決(Disputes):
係争解決タイプ: 独立機関(independent)
サービス: http://www.privacyseal.example.org
表記: PrivacySealExample
[3.2.6 Disputes]
救済(Remedies): 私達はあらゆる間違った行動による害を正します。
[3.2.7 Remedies]
当組織が集める情報:
dynamic.clickstream
dynamic.http
[4.5 Base Data Schema]
目的: ウェブサイトとシステム管理、調査と開発
[3.3.4 Purpose]
受領者(Recipients): 当組織および当組織の業務委託先
[3.3.5 Recipients]
保有期間(Retention): 明記された目的にそう適切な期間
[3.3.6 Retention]
（また、サイトの人間が読む事のできるプライバシーポリシーはデータが隔週で整理されることを述べるか、この情報へのリンクを提供しなければならないことに注意。）

例 3.2: CatalogExample社の商品購入者むけのプライバシーポリシー

CatalogExample社はあなたのプライバシーを大切にします。私達はあなたのクレジットカード番号やその他の金融情報を第三者と共有することはありません。あなたの許可があった場合に限り、あなたが過去に特別な提供をしたか、過去の購入の習慣などのプリファレンス（嗜好）を、慎重に選んだマーケティングパートナーとのみ情報を共有します。あなたの好みと嫌いなものを知ることによって、ニーズに応じたよりよい申し出（情報）を提供することができます。

CatalogExample社はPrivacySealExampleプログラムの認可を持っています。 PrivacySealExampleは、ウェブサイト使用権利者に高いプライバシー基準を取得させ、そして会計監査人と一緒にこれらの情報の業務がフォローされていることを確認することにより、あなたのプライバシーを保証しています。

このステートメントに関する質問はこちら：
CatalogExample社

4000 Lincoln Ave.

    Birmingham, MI 48009 USA

    email: catalog@example.com

    Telephone +1 248-EXAMPLE (+1 248-392-6753)

もし私達があなたの問合せに返答しなかったか、あるいはあなたの問合せが満足に扱われなかったときには、http://www.privacyseal.example.orgによってPrivacySealExamp leと連絡を取ることができます。CatalogExample社はプライバシーポリシーに関連し発生しうるすべてのエラーあるいは不法な行動を修正します。

あなたが私達のサイトを閲覧することによって集める情報：

あなたのPCとの確実な接続を確実にすることとセキュリティを目的とした基本情報。そして
私達のサイトを改善するため、どのページにアクセスされるか、あるいは訪問するかといった集計情報。

あなたが商品購入を選んだ場合、以下のようなもっと多くの情報を要求します。:

あなたの名前、住所です。それによって商品の発送が可能となり、また将来的に私達はあなたと連絡を取ることができます。;
あなたの電子メールアドレスと電話番号です。それによって私達はあなたと連絡を取ることができます。;
あなたの情報を将来、いつでも更新することができるようにするためのログイン名とパスワードです。;そして、
購入の手続きのためのあなたの金融情報です（将来の利用のために保存することを選ぶこともできます）。
任意ですが、その他の人口統計学的な情報を入力することもできます。それによって私達は将来、あなたに合わせたサービスを行うことができます。

同じく、このページによって、CatalogExample社からかあるいは私達と相当のプライバシーの習慣に遵守するような慎重に選んだマーケティングパートナーからの電子メール、電話あるいは書面のサービスを受け取るか否かについて、あなたは選択をすることができます。もしこれらの懇願を受け入れたいなら、適切なボックスにチェックしてください。またあなたはプリファレンス（嗜好）を変えることによって、この参加をいつでもやめることができます。

個人情報の変更と更新
http://catalog.example.com/preferences.htmlに示すCatalogExample社のプリファレンス（嗜好）セクションに行くことにより、そのすべての個人情報を変更することができます。あなたは、住所、電話番号、電子メールアドレス、パスワードをあなたのプライバシー設定に合うように変更することができます。

クッキー
CatalogExample社はあなたが過去にCatalogExample社の顧客だったか否かをみるためだけにクッキーを使います。もし顧客ならば、過去の購入や習慣に基づき、サービスをカスタマイズします。私達はクッキーの中の個人データを当社で保存することはありません。また、他の企業・団体や関係会社に、情報を提供したり販売したりすることはありません。

データの保管
私達の顧客である間、あなたとあなたの購入に関する情報を保持します。もし、あなたが一年間私達へ注文をなさらなければ、あなたの情報を私達のデータベースから抹消します。

3.1.2 ポリシーのXMLコード化

以下の2つの例にあげた[XML]文書は上記の自然言語ポリシーをXMLで表現したものである。ポリシーは、XML.によって正確に表現されたステートメントのことである。ポリシーの構文については、後節でより詳細に説明する。

例3.1のXMLエンコード方法:

<POLICY xmlns="http://www.w3.org/2000/12/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">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.country">USA</DATA>
   <DATA ref="#business.contact-info.online.email">catalog@example.com</DATA>
   <DATA ref="#business.contact-info.telecom.telephone.intcode">1</DATA>
   <DATA ref="#business.contact-info.telecom.telephone.loccode">248</DATA>
   <DATA ref="#business.contact-info.telecom.telephone.number">3926753</DATA>
  </DATA-GROUP>
 </ENTITY>
 <ACCESS><nonident/></ACCESS>
 <DISPUTES-GROUP>
  <DISPUTES resolution-type="independent"
    service="http://www.PrivacySeal.example.org"
    short-description="PrivacySeal.example.org">
   <IMG src="http://www.PrivacySeal.example.org/Logo.gif" alt="PrivacySeal's logo"/>
   <REMEDIES><correct/></REMEDIES>
  </DISPUTES>
 </DISPUTES-GROUP>
 <STATEMENT>
  <PURPOSE><admin/><develop/></PURPOSE>
  <RECIPIENT><ours/></RECIPIENT>
  <RETENTION><stated-purpose/></RETENTION> <!-- サイトの人間が読むことのできるプライバイシーはデータが二週間後とにパージされること、あるいはこの情報へのリンクを提供することを述べなければならない -->
  <DATA-GROUP>
   <DATA ref="#dynamic.clickstream"/>
   <DATA ref="#dynamic.http"/>
  </DATA-GROUP>
 </STATEMENT>
</POLICY>

例3.2のXMLエンコード方法:

<POLICY xmlns="http://www.w3.org/2000/12/P3Pv1"
    discuri="http://www.catalog.example.com/Privacy/PrivacyPracticeShopping.html"
    opturi="http://catalog.example.com/preferences.html">
 <ENTITY>
  <DATA-GROUP>
   <DATA ref="#business.name">CatalogExample</DATA>
   <DATA ref="#business.contact-info.postal.street">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.country">USA</DATA>
   <DATA ref="#business.contact-info.online.email">catalog@example.com</DATA>
   <DATA ref="#business.contact-info.telecom.telephone.intcode">1</DATA>
   <DATA ref="#business.contact-info.telecom.telephone.loccode">248</DATA>
   <DATA ref="#business.contact-info.telecom.telephone.number">3926753</DATA>
  </DATA-GROUP>
 </ENTITY>
 <ACCESS><contact-and-other/></ACCESS>
 <DISPUTES-GROUP>
  <DISPUTES resolution-type="independent"
    service="http://www.PrivacySeal.example.org"
    short-description="PrivacySeal.example.org">
   <IMG src="http://www.PrivacySeal.example.org/Logo.gif" alt="PrivacySeal's logo"/>
   <REMEDIES><correct/></REMEDIES>
  </DISPUTES>
 </DISPUTES-GROUP>
 <STATEMENT>
  <CONSEQUENCE>
    貴方のリクエストに答え、ウェブサイトを保護し、向上するために情報をいくつか記録します
  </CONSEQUENCE>
  <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>
  <CONSEQUENCE>
    お買い上げ頂くと私共はこの情報を使用します。
  </CONSEQUENCE>
  <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.telephone"/>
   <DATA ref="#user.business-info.postal"/>
   <DATA ref="#user.business-info.telecom.telephone"/>
   <DATA ref="#user.home-info.online.email"/>
   <DATA ref="#dynamic.miscdata">
    <CATEGORIES><purchase/></CATEGORIES>
   </DATA>
  </DATA-GROUP>
 </STATEMENT>
 <STATEMENT>
  <CONSEQUENCE>
    ご依頼により、貴方が興味をお持ちになると思われるマーケティングを慎重に選びお送りします。
  </CONSEQUENCE>
  <PURPOSE>
   <contact required="opt-in"/>
   <customization required="opt-in"/>
   <tailoring required="opt-in"/>
  </PURPOSE>
  <RECIPIENT required="opt-in"><ours/><same/></RECIPIENT>
  <RETENTION><stated-purpose/></RETENTION>
  <DATA-GROUP>
   <DATA ref="#user.name" optional="yes"/>
   <DATA ref="#user.home-info.postal" optional="yes"/>
   <DATA ref="#user.home-info.telecom.telephone" optional="yes"/>
   <DATA ref="#user.business-info.postal" optional="yes"/>
   <DATA ref="#user.business-info.telecom.telephone" optional="yes"/>
   <DATA ref="#user.home-info.online.email" optional="yes"/>
  </DATA-GROUP>
 </STATEMENT>
 <STATEMENT>
  <CONSEQUENCE>
    御自身の情報にアクセスできるようパスワードを設定できます。
  </CONSEQUENCE>
  <PURPOSE><customization required="opt-in"/></PURPOSE>
  <RECIPIENT><ours/></RECIPIENT>
  <RETENTION><stated-purpose/></RETENTION>
  <DATA-GROUP>
   <DATA ref="#dynamic.miscdata">
    <CATEGORIES><uniqueid/></CATEGORIES>
   </DATA>
  </DATA-GROUP>
 </STATEMENT>
 <STATEMENT>
  <CONSEQUENCE>
    ご依頼により、サイトを作成し、貴方の趣味にあわせた製品に焦点をあてます。
  </CONSEQUENCE>
  <PURPOSE>
    <customization required="opt-in"/>
    <tailoring required="opt-in"/>
  </PURPOSE>
  <RECIPIENT><ours/></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>
    貴方の過去の訪問を元にサイトを作成します。
  </CONSEQUENCE>
  <PURPOSE><tailoring/><develop/></PURPOSE>
  <RECIPIENT><ours/></RECIPIENT>
  <RETENTION><stated-purpose/></RETENTION>
  <DATA-GROUP>
   <DATA ref="#dynamic.cookies">
    <CATEGORIES><state/></CATEGORIES>
   </DATA>
   <DATA ref="#dynamic.miscdata">
    <CATEGORIES><preference/></CATEGORIES>
   </DATA>
  </DATA-GROUP>
 </STATEMENT>
</POLICY>

3.2 ポリシー

本節では、P3Pポリシーの構文とセマンティクスを定義する。全てのポリシーは[UTF-8]を用いて表現しなければならない。 P3Pサーバはこのエンコーディング(表現)を用いて自らのポリシーを表現しなければならない。 P3Pユーザエージェントはこの構文を解析できなければならない。

ポリシーは一つのファイルに（POLICY要素を使って）独立して置く事ができるし、 POLICIES要素を使って一緒に集めることもできる。

3.2.1 `POLICIES` 要素

POLICIES要素は一つのファイルに複数のP3Pポリシーを集めるのに使用される。 POLICIES要素はネットワークの行き来とキャッシングを向上させ、性能の最適化として提供される。ポリシーの多くは一つの要求で集める事ができる。すなわち、POLICIES要素は周知の場所、META要素の中、に置く事ができる。この場合、ユーザエージェントはポリシー参照ファイルとポリシーの両方を持っている一つのファイルを取り出すことだけが必要である。

POLICIES要素にあるポリシーは、ファイル内に唯一のname属性を持たなければならない。この事によって、（POLICY-REF要素の）ポリシー参照はそのポリシーにリンクすることができる。

例 3.3:

http://www.example.com/Shop/policies.xmlにあるファイルは以下のコンテンツを持つ事ができた。:

<POLICIES xmlns="http://www.w3.org/2000/12/P3Pv1">
   <POLICY discuri="http://www.example.com/disc1" name="policy1"> .... </POLICY>
   <POLICY discuri="http://www.example.com/disc2" name="policy2"> .... </POLICY>
   <POLICY discuri="http://www.example.com/disc3" name="policy3"> .... </POLICY>
</POLICIES>

http://www.example.com/Shop/CDs/*.xml のファイルはhttp://www.example.com/w3c/p3p.xmlにある以下のポリシー参照ファイルを使用して2番目のポリシー("policy2") を関連することができる。:

<META xmlns="http://www.w3.org/2000/12/P3Pv1">
<POLICY-REFERENCES>
    <POLICY-REF about="/Shop/policies#policy2">
      <INCLUDE>/Shops/CDs/*</INCLUDE>
    </POLICY-REF>
 </POLICY-REFERENCES>
</META>

[19]
policies

=

`<POLICIES xmlns="http://www.w3.org/2000/12/P3Pv1">` *policy "</POLICIES>"

3.2.2 `POLICY` 要素

POLICY要素（ポリシー要素）には、完全なP3Pポリシーが含まれる。各P3Pポリシーには、一つのPOLICY要素が正しく含まれなければならない。 POLICY要素には、そのポリシーに含まれるプライバシープラクティスの代表者となる法人組織を特定するようなENTITY属性が含まれなければならない。さらに、POLICY要素にはACCESS要素（情報公開要素）が含まれなければならない。また、オプショナルなものとして、STATEMENT要素（ステートメント要素）DISPUTES-GROUP要素（係争解決グループ要素）、 EXPIRY要素（ポリシーの有効期限を示している）、P3Pデータスキーマ、そして一つ以上のextension（拡張）が含まれてもよい。

<POLICY>: 一つ以上のステートメントを含む。各ステートメントは一組のデータ要素に適用される一組の情報開示(DISCLOSURE)要素を含む。
discuri (必須の属性): 自然言語のプライバシーステートメントのURI。
opturi: ユーザが特別な目的（opt_inまたはopt_out）のために使用されるデータを要求したり、拒否したりする際に従うことのできるURIの指示のこと。この属性はopt-in または opt-outに設定されている必要な属性と一緒に purposeを含むポリシーに必須である。
name: このポリシーの名前。ポリシーを参照することのできるフラグメント識別子。ポリシーがPOLICIES要素にあれば、この属性は必須である。

[20]

policy

`<POLICY xmlns="http://www.w3.org/2000/12/P3Pv1"
         discuri=` quoted-URI 
         [` opturi=` quoted-URI]
         [` name=` quotedstring] `>`
*extension
[test]
[expiry]
[dataschema]
entity
access
[disputes-group]
*statement-block
*extension
`</POLICY>`

[21]

quoted-URI

`"` URI `"`

ここではURIはRFC 2396 [URI]によって定義される。

3.2.3 `TEST` 要素

TEST要素はテストを目的として使用される：ポリシーにTESTが存在するということはそのポリシーが単なる例であるという事を意味するのでそれは無視しなければならないし、有効なP3Pポリシーと考えてはいけない。

[22]
test

=

"<TEST/>"

3.2.4 `ENTITY` 要素

ENTITY要素は、プライバシープラクティス表記を行っている合法組織に関する正確な説明を提供する。

<ENTITY>: ポリシー内にあるプラバシープラクティスの表記を行う合法組織を識別する。

ENTITY要素は、ビジネスデータ集合の（全て又は一部の）フィールドを参照しているDATA 要素から成る合法組織の説明を含んでいる。: 利用者が、ある組織のプライバシーポリシーについて連絡を取る際に使うであろう住所、電話番号、電子メールアドレスおよびその他の情報などの問い合わせ情報は、実在する名称でなければならない。また、ある法律や規則の指導では、郵便番号やその他の特有の情報を問い合わせ情報に含める必要があることに注意すること。

[21]
entity

=

"<ENTITY>" *extension entitydescription *extension "</ENTITY>"

[22]
entitydescription

=

"<DATA-GROUP>" `<DATA ref="#business.name"/>` PCDATA "</DATA>" *(`<DATA ref="#business.` string `"/>` PCDATA "</DATA>") "</DATA-GROUP>"

ここで文字列は、ビジネスデータ集合によって許される数字の間、連続する文字（" や & で回避された）で定義される。PCDATAは[XML]で定義されている。

3.2.5 `ACCESS` 要素

ACCESS要素は、情報の様々な種類にアクセスする機能をサイトが提供するかどうかを示す。

<ACCESS>: 個人特定可能情報を本人が閲覧し、サービス提供者に対して質問や苦情を表明することができるか否か。サービス提供者はaccess属性において一つの値を公開しなければならない。アクセス手段は特定しない。利用者のアクセスが可能な値が公開されている場合（<all/>以外）、全てのデータへのアクセスが可能であることは意味せず、アクセスが可能なデータがあること、また、どのようなデータにアクセスできるのか利用者はサービス提供者にさらに確認するべきであることを意味している。
サービス提供者は、discuriで示されたWeb以外の手段で収集された情報にアクセスする許可を与えてもよい。しかし、P3Pステートメントが扱う範囲はHTTPまたは他のWeb転送プロトコルを通して収集されるデータに限られる。また、アクセスがWeb経由で提供される場合は、セキュリティの問題は本文書の範囲外ではあるが、そのようなアクセスのために強固な認証とセキュリティメカニズムを使用することを推奨する。

ACCESS 要素は、以下の要素の中から一つ構成されなければならない。:

<nonident/>: 個人特定可能データは使われていない
<all/>: 全ての個人特定可能情報: 全ての個人特定可能情報へのアクセスが提供されている。
<contact-and-other/>: 個人特定可能な連絡先情報とその他の個人特定可能情報: 個人特定可能なオンライン連絡先情報、個人特定可能な実世界における連絡先情報、および特定個人と結びついたその他の情報へのアクセスが提供されている。
<ident-contact/>: 個人特定可能な連絡先情報: 個人特定可能なオンライン連絡先情報と個人特定可能な実世界での連絡先情報へのアクセスが提供されている（例えば、利用者は住所などの情報にアクセスすることができる）。
<other-ident/>: その他の個人特定可能情報: 特定個人と結びついたその他の情報へのアクセスが提供されている（例えば、利用者は自分に課金された利用料などの情報にアクセスすることができる）。
<none/>: なし: 個人特定可能情報へのアクセスは提供していない。

[23]
access

=

"<ACCESS>" access_disclosure *extension "</ACCESS>"

[24]
access_disclosure

=

"<nonident/>" | ; 個人特定可能なデータは使われていない "<ident-contact/>" | ; 個人特定可能なコンタクト情報 "<other-ident/>" | ; その他の個人特定可能な情報 "<contact-and-other/>" | ; 個人特定可能、およびその他のコンタクト情報 "<all/>" | ; 個人特定可能な全ての情報 "<none/>" ; なし

3.2.6 `DISPUTES` 要素

ポリシーは、一つ以上の DISPUTES要素（係争解決要素）から成る、DISPUTES-GROUP要素（係争解決グループ要素）を含むべきである。 DISPUTES 要素は、サービスのプライバシープラクティスに関して係争が生じた際に行われる係争解決手続きを記述している。どのDISPUTES要素も、LONG-DESCRIPTION要素とIMG要素、REMEDIES要素をオプションとして含んでもよい。複数の係争解決の手段を持つサービスプロバイダは、それぞれに分けたDISPUTES要素を使うべきである。もし複数使うならば、異なる係争手段は係争解決手段も分かれており、それぞれのDISPUTES要素はそれぞれのLONG-DESCRIPTIONやIMGタグ、REMEDIES要素が必要になると思われる。

<DISPUTES>

サービスのプライバシープラクティス、又はプロトコル違反に関して係争が生じた際に行われる係争解決手続きを記述している。

解決タイプ(resolution-type) (必須の属性)

以下の4つの値から一つを選ぶ:

顧客窓口(Customer service) [service]: 利用者は、収集されたデータの利用に関する係争の解決のために、Webサイトの顧客窓口の代表者に申し立てることができる。この記述は、顧客サービスへのコンタクト手段を含まなければならない。
独立機関(Independent organization) [independent]: 利用者は、収集されたデータの利用に関する係争解決のために、ある独立機関に申し立てることができる。記述の中にはその第三者機関への連絡方法に関する情報が含まれなければならない。
裁判所(Court) [court]: 利用者は、ウェブサイトを告訴することができる。
適用可能な法律(Applicable law) [law]: プライバシーステートメントに関連した係争については、ステートメントにおいて参照された法律によって解決がなされる。

サービス(service) (必須の属性)

顧客窓口のウェブページや独立機関のURI、または関連する裁判所や適用可能な法律に関する情報を載せているURI。

検証(verification)

検証手続きの為に使用されるURI、または証明書。プライバシーシール等を持っているサイトの主張を検証する為の機能を、プライバシーシール提供組織が提供することが予測される。

簡易表記(short-description)

適当に合法的に公開されるか、法律に適用された、または第三者的組織などの名前、あるいはサービスURIにおいて示されていない利用者へのサービスとなるコンタクト情報などの人間が読むことができる短い記述。文字数は255以下。

DISPUTES要素には、人間が読むことができるLONG-DESCRIPTION要素を含むことができる。それは適切な法的フォーラムや、適切な法律、または、第三者的組織の名前、あるいは、サービスURIに示されていない場合は、カスタマーサービスのコンタクト情報を含むべきである。

<長い表記(LONG-DESCRIPTION)>: この要素は、人間が読むことができる（長い）記述を含む。

<IMG>: イメージロゴ（例えば、独立機関または関連する裁判所のイメージロゴ）のURI
src (必須の属性): イメージロゴのURI
幅(width): イメージロゴのピクセル幅
高さ(height): イメージロゴのピクセル高
代替テキスト(alt) (必須の属性): イメージロゴに代わる短いテキスト

[25]
disputes-group

=

"<DISPUTES-GROUP>" 1*dispute *extension "</DISPUTES-GROUP>"

[26]
dispute

=

"<DISPUTES" " resolution-type=" '"'("service"|"independent"|"court"|"law")'"' " service=" quoted-URI [" verification=" quotedstring] [" short-description=" quotedstring] ">" *extension [longdescription] [image] [remedies] *extension "</DISPUTES>"

[27]
longdescription

=

<LONG-DESCRIPTION> PCDATA </LONG-DESCRIPTION>

[28]
image

=

"<IMG src=" quoted-URI [" width=" `"` number `"`] [" height=" `"` number `"`] " alt=" quotedstring "/>"

[29]
quotedstring

=

`"` string `"`

ここで文字列は連続する文字（" や & で回避された）で定義される。PCDATAは[XML]で定義されている。

サービスは複数の保証サービスを持つことができ、それらはDISPUTES-GROUP要素に含まれる複数のDISPUTES要素の記載を通して特定できることに注意すること。ある組織のプライバシープラクティスが自組織内で保証されたものも含み、第三者機関によて監査されたり、または法的な監督機関の管轄下にあったりすることを説明することによって、このDISPUTES-GROUP要素のフィールドが様々な方法で使用されることを期待する。

3.2.7 `REMEDIES` 要素

個々のDISPUTES要素は、ポリシーに関する違反があった場合に、可能である賠償方法を指定しているREMEDIES要素を含むべきである。

<REMEDIES>: ポリシーに関する違反があった場合の賠償方法。

REMEDIES要素は、以下の1つ以上含まなければならない。:

<correct/>: プライバシーポリシーに関連して、エラーや不正なアクションが起こった場合、サービスによって賠償される。
<money/>: サービスプロバイダがプライバシーポリシーに違反した場合、個人に対し、人間が読むことができるプライバシーポリシー内に指定してある額、または損害賠償金を支払うであろう。
<law/>: ポリシーステートメントの違反に関する賠償方法は、人間が読むことができる説明で参照される法律に基づいて決定されるだろう。

[30]	remedies	=	"<REMEDIES>" 1remedy extension "</REMEDIES>"
[31]	remedy	=	"<correct/>" \| "<money/>" \| "<law/>"

3.3 ステートメント

ステートメントは、特定のデータの型に適用されるデータプラクティスを説明する。

3.3.1 `STATEMENT` 要素

STATEMENT要素（ステートメント要素）は、PURPOSE要素（目的要素）、RECIPIENT要素（受領者要素）、RETENTION（保有要素）、 DATA-GROUP要素（データグループ要素）、オプショナルなものとしてCONSEQUENCE要素（結果要素）と一つ以上の拡張を束ねたものである。 DATA-GROUP要素で参照された全てのデータは、ステートメントに含まれたその他の要素から成る情報公開に従って取り扱われる。このように、サイトは同じ方法で取り扱われる要素をグループ化し、各グループに対してステートメントを作成することができる。サイトが収集するデータの種類に合わせて個々の目的とその他の情報を公開したい場合は、各データ要素に合わせて別々のステートメントを作成することによって、そのような公開を行うことができる。

<STATEMENT>: データ要素に適用されるデータプラクティス。

[32]
statement-block

=

"<STATEMENT>" *extension [consequence] [non-identifiable] purpose recipient retention 1*data-group *extension "</STATEMENT>"

プラクティスの宣言を簡潔化するために、サービス提供者はデータ要素に関するステートメント内で情報公開（目的、受領者、保存）を集合化することができる。サービス提供者は、このような集合化は付加的な作業として行わなければならない。例えば、利用者の年齢は「当組織および当組織の業務委託先」に提供するが、利用者の郵便番号は「当組織と無関係な第三者」に提供するようなサイトは、利用者の名前と郵便番号を「当組織および当組織の業務委託先」および「当組織と無関係な第三者」に提供すると表明してもよい。そのようなステートメントでは、実際に行っている以上に多くのデータを第三者に提供しているように見える。自サイトの情報公開を詳細なものとするか簡潔なものとするかどうかを決定するのは、サービス提供者次第である。

また、サービス提供者は常に、適用される全てのオプションを公開しなければならない。例えば、「サービスまたは製品のマーケティングのためにサイト訪問者と連絡をとる」という目的のみで情報を収集するサイトを考えてみる。サイトがこの「サービスまたは製品のマーケティングのためにサイト訪問者と連絡をとる」ことを「現在の活動の遂行とサポート」の目的によるものだとみなしている場合でも、サイトは両方の目的を表明しなければならない。情報を「サービスまたは製品のマーケティングのためにサイト訪問者と連絡をとる」目的で「当サイトおよび当サイトの業務委託先」に提供し、「現在の活動の遂行とサポート」の目的で「公のフォーラム」に提供するサイトは、「当サイトおよび当サイトの業務委託先」と「公のフォーラム」の両方の受領者を表明しなければならない。

サービス提供者は時に、自分たちが収集したデータを集合化する。この集合データは元のデータとは違う目的で使用され、元のデータより広く共有され、または元のデータより長く保持されることがある。例えば多くのサイトは広告者に対して、Webへアクセスした人の数や、さまざまな人工統計学的なグループに適合するアクセス者のパーセンテージなどてら発表したり、公開したりする。こういった統計の数字を元にした個人や世帯のデータを取り出すことができないように、集合化した数字が使用されたり、共有されたりすると、P3Pポリシーで上記のような数値が非公開となることが必要である。しかしながら、サービスは元のデータが収集された事実を非公開にしなければならないし、データが集合化される前にそのデータから作成される使用のすべてを宣言しなければならない。

3.3.2 `CONSEQUENCE` 要素

STATEMENT要素（ステートメント要素）には、利用者に対し、サイトのプラクティスに関して追加的な説明を与えることができる CONSEQUENCE要素（結果要素）を任意に含むことができる。

<CONSEQUENCE>: 結果（consequense）とは、サイトが提示するプラクティスが（利用者が通常はそのプラクティスを許可しない場合であれ）、ある特別な場合になぜ価値があるのかを利用者に説明するために示されるものである。

[33]
consequence

=

"<CONSEQUENCE>" PCDATA "</CONSEQUENCE>"

3.3.3 `NON-IDENTIFIABLE` 要素

STATEMENT要素（ステートメント要素）には以下に指定する要求項目が履行された時のみ、任意にNON-IDENTIFIABLE要素が含まれる事がある。

<NON-IDENTIFIABLE/>: 収集されたデータや個人特定可能なデータがない場合のステートメントだけ表される事ができるエレメント。エンティティや第三者が人の特定に収集したデータを結び付ける為の妥当な理由がなければ、データは現在の仕様書では個人特定不可能だと考えられる。

<NON-IDENTIFIABLE/>要素が現れれば、この要素が実現される方法についての人が読むことのできる説明はdiscuriに含まれなければならない。

[34]
non-identifiable

=

"<NON-IDENTIFIABLE/>"

3.3.4 `PURPOSE` 要素

各STATEMENT要素（ステートメント要素）には、一つ以上のデータ収集目的またはデータ利用目的を含むPURPOSE要素（目的要素）が含まれなければならない。サイトは自らのデータプラクティスを、6つの特定化された目的のうちの一つ以上の目的に分類しなければならない。

<PURPOSE>: ウェブサイトに関連したデータ処理の目的

PURPOSE要素には、以下の目的の中から一つ以上が含まれなければならない:

<current/>: 現在の活動の遂行とサポート：情報は、情報提供や通信、双方向サービスなど、利用者がそのために情報を与えたところの活動を遂行するために、サービス提供者によって利用されるかもしれない。例えば、ウェブ検索の結果の返信、電子メールの送信、商品の注文など。
<admin/>: ウェブサイトとシステムの管理: 情報は、ウェブサイトとそのコンピュータシステムの技術サポートのために利用されるかもしれない。この中には、コンピュータアカウント情報の処理や、サイトの保守管理、およびサイトやエージェントによるウェブサイト活動の確認の過程で利用される情報の処理が含まれる。
<develop/>: 調査と開発: 情報は、サイトやサービス、商品、マーケットを改善したり、評価したり、検討したりするために利用されるかもしれない。この中には、特定個人に合わせてコンテンツを変更するために個人情報を利用することや、特定個人を評価したり、ターゲットとしたり、プロファイルしたり、また特定個人と連絡をとったりするために個人情報を利用することは含まれない。
<customization/>: 肯定的なカスタマイズ: 情報は、サイトへの1回または複数回の訪問を通じて特定個人によって肯定的に選択された仕様に合わせてサイトのコンテンツやデザインを変更するために利用されるかもしれない。例えば、利用者にいくつかの株式銘柄を選択させ、利用者の訪問時にそれらの現在の株価を表示する金融サイトなど。
<tailoring/>: その場限りの仕立て: 情報は、サイトへの1回の訪問のみで利用され、その後のいかなるカスタマイズにも利用されない情報として、特定個人によって肯定的に選択されていない形でサイトのコンテンツやデザインを変更するために利用されるかもしれない。例えば、訪問者が買い物かごに入れた商品にもとづいて、彼がその他に購入したいであろう商品を提案するオンラインショップなど。
<pseudo-analysis/>: ペンネーム分析: 情報は、（名前、住所、電話番号、電子メール、IPアドレスなどの）記録するための個人が特定可能な情報を使うことなく、個人かコンピュータ毎の個々の記録とペンネームの記録を繋ぐために使われるかもしれない。このプロファイルは調査や分析、報告を目的とした、習慣や興味、個人の特徴といったものの決定のために使われるかもしれないが、個人が特定可能な情報としては使われないだろう。たとえば、市場で売買する会社や人がウェブサイトの異なる部分へアクセスする人の興味を理解したいと考えるかもしれない。
<pseudo-decision/>: ペンネーム決定: 情報は、（名前、住所、電話番号、電子メール、IPアドレスなどの）記録するための個人が特定可能な情報を使うことなく、個人かコンピュータ毎の個々の記録とペンネームの記録を繋ぐために使われるかもしれない。このプロファイルは習慣や興味、個人の特徴といった個人に影響している決定をするために使われるかもしれないが、個人が特定可能な情報としては使われないだろう。例えば、市場で売買する会社や人が以前アクセスした人が見たページをもとにブラウザに表示したコンテンツを調整したり、修正したりするかもしれない。
<individual-analysis/>: 個人分析: 情報は習慣や興味、個人の特徴といったものを決定し、調査や分析、報告を目的として個人特定可能な情報と結びつけるために使われる。例えば物理的な店のオンラインWebサイトは、オンラインショッパーがどのようにオフライン購入を行うかを分析したいと考えるかもしれない。
<individual-decision/>: 個人決定: 情報は習慣や興味、個人の特徴といった個人に影響している決定をするために使われ、個人に影響している決定をするために個人特定の情報と結びつくかもしれない。例えば、オンラインストアはアクセス者が以前Webサイトに訪れた時に購入した物をもとに、商品を提案したいと思うかもしれない。
<contact/>: サービスまたは商品のマーケティングのためにサイト訪問者と連絡をとる: 情報は、商品やサービスの販売促進のために電話以外の連絡方法で個人と連絡をとる目的で利用されるかもしれない。この中には、ウェブサイトの更新を訪問者に通知することも含まれる。一度行った質問やコメント、カスタマーサービスへの直接的な回答はこの中には含まない。--そういったケースでは、<current/>が使用される。さらに、カスタマイズされたウェブコンテンツまたは、ユーザが訪れているサイトに埋め込まれた目立つ広告を通じてのマーケティングも含まれない。 -- こういう場合は <tailoring/>, <pseudo-analysis/> と <pseudo-decision/>, または <individual-analysis/> と <individual-decision/> purposes でカバーされるだろう。
<historical/>: 過去のでき事を保存: 情報は、現行の法律や政策で管理されているように、社会の過去のでき事を保存するために格納したり保存されるかもしれない。この法律や政策は<DISPUTES>要素において参照されなければならないし、この情報（どこにこの情報が格納されるか、と特にどのようにしてこの情報収集が過去のでき事の保存を向上させるのか）にアクセスできる資格のあるリサーチャーの特別な定義を含まなければならない。
<telemarketing/>: 電話を通じてのサービスと商品のマーケティングのために訪問者に連絡:情報は商品やサービスの促進のために電話で個人に連絡をする為に使用されることがある。これには一度行った質問やコメント、カスタマーサービスへの直接の回答はふくまれない。--この場合、<current/>が使用される。
<other-purpose> string </other-purpose>: その他の利用: 情報は上記の定義には当てはまらない方法で利用されるかもしれない。（この場合、人間が読むことのできる説明を与えるべきである。）

各々の目的には、以下のオプショナルな属性を付加することができる:

required

この目的がサイトに必要な業務であるかどうか。属性は以下の値をとる。:

always : 目的がいつも必要である。; ユーザはデータの使用に opt-in または opt-outをすることができない。これは、必要な属性が無い場合のデフォルトである。
opt-in : データはこの使用を積極的に要求する場合にのみ、この目的を使用することがある。 -- 例えば、ユーザがメーリングリストに追加してほしいと要求した場合。積極的な要求にはユーザが特別な処置をしなければならない。例えば、ユーザが調査に記入する場合、メーリングリストに追加するために追加のボックスにチェックを入れることは積極的な要求だとみなされる。しかしながら、事前にチェック付けているメ―リングリストが調査フォームに含まれていると積極的な要求とはみなされない。さらに、ユーザが積極的に要求する目的にたいして、ユーザが心変わりをしたり、その要求を拒否したりするにちがいない。-- そういうことはopturiに定義されなければならない。
opt-out : ユーザがこの方法で使用してほしくないと要求する時以外にデータはこの目的のために使用される。この値が選択されれば、このサービスはopturiでユーザがこの目的をopt-out する方法に関して分かり易い指示を提供しなければならない。また、サービスはデータ収集の点において、以上の指示または、その指示のポイントを提供するべきである。

[35]
purpose

=

"<PURPOSE>" 1*purposevalue *extension "</PURPOSE>"

[36]
purposevalue

=

"<current" [required] "/>" | ; 現在の活動の遂行とサポート "<admin" [required] "/>" | ; ウェブサイトとシステムの管理 "<develop" [required] "/>" | ; 調査と開発 "<customization" [required] "/>" | ; 肯定的なカスタマイズ "<tailoring" [required] "/>" | ; その場限りの調整 "<pseudo-analysis" [required] "/>" | ; ペンネーム分析 "<pseudo-decision" [required] "/>" | ; ペンネーム決定 "<individual-analysis" [required] "/>" | ; 個人分析 "<individual-decision" [required] "/>" | ; 個人決定 "<contact" [required] "/>" | ; サービスまたは商品のマーケティングのためにサイト訪問者と連絡をとる "<historical" [required] "/>" | ; 過去のでき事の保存 "<telemarketing" [required] "/>" | ; 電話でのマーケティング "<other-purpose" [required] ">" PCDATA "</other-purpose>"; その他の利用

[37]
required

=

" required=" `"` ("always"|"opt-in"|"opt-out") `"`

サービス提供者は上記の要素をデータ収集の目的を説明するために用いなければならない。サービス提供者は適用される全ての目的を公開しなければならない。サービス提供者があるデータ要素をある目的で利用することを公開しなかった場合、そのことはデータをその目的では利用しないということを意味している。「その他の利用」の目的でデータを利用すると公開したサービス提供者は、その目的に関して人間が読むことのできる説明を与えなければならない。

サービス提供者はすべての受領者に適用を非公開にしなければならない。P3Pはどのようにしてそのデータが受領者にリリースされるのかについて区別はしていない。データがリリースされた時にただ単にデータが必要なだけである。そして、そのデータの共有はP3Pポリシーで公開しなければならない。 P3Pステートメントでカバーされなければならないデータ公開の例には以下がある。

カスタマーデータを注文の履行または請求過程の一部として顧客に転送する。
メーリングリストの貸し出しと販売。
要求が第三者にリダイレクトする時、URIに個人情報を置く。
第三者にリンクしているURIに個人情報を置く。

ある場合には、上記の受領者はデータにすべての受領者を示しているわけではない。例えば、出荷や支払いをする人などといった処理進行者の問題。こういった人はその行動を完了し、サポートする必要があるが、問題のある異なる業務にしたがうことがある。現在、配達サービスは一つのポリシーで明らかに表す事ができる。オリジナルのサービス提供者に関しての業務に最も反映している部門ではどれでも、上記のような処理進行者を表すべきである。配達サービスの特別な要素は含まれているが、以下の理由から支払いに関する特別な要素は（銀行やクレジットカード会社など）含まれてはいない。配達サービスの受領者は普通、配達サービスのプライバシーポリシーを見直す機会がないが、金融機関は、金融データに関して顧客とは別個の同意書を持つだろう。

3.3.5 `RECIPIENT` 要素

各STATEMENT要素（ステートメント要素）には、収集データの一つ以上の受領者を含むRECIPIENT要素（受領者要素）が含まれなければならない。サイトはデータの受領者を、6つの特定化された受領者のうちの一つ以上の受領者に分類しなければならない。

<RECIPIENT>: データを提供するかもしれないサービス提供者および当組織の業務委託先を超えた、法人組織または事業部門

RECIPIENT要素には、以下の受領者の中から一つ以上が含まれなければならない。:

<ours>: 当組織および／または当組織の業務委託先として業務を行っている法人または当社が業務委託先として業務をしている法人: この場合、業務委託先（agent）とは、表明された目的の達成のためだけにサービス提供者に代わってデータを処理する第三者として定義される。（例えば、サービス提供者とその印刷事務所。ただし、印刷事務所は住所ラベルを印刷し、それ以上は情報に関わりを持たない。）
<delivery>: 当組織とは異なるプラクティスに従う可能性のある配送サービス: サービス提供者のプライバシーポリシーにおいて表明された目的の遂行以外の目的でデータを利用するかもしれない、 配送サービスを行う法人組織。また、これはデータプラクティスが知られていない配送サービスにも使用される。
<same>: 当組織のプラクティスに従う法人組織: サービス提供者と等価なプラクティスの下で、自らのためにデータを利用する法人組織。（例えば、収集した個人情報へのアクセスを利用者に提供し、かつ、提供された個人情報を一度利用するが保有せずに破棄してまうパートナー企業に個人情報を提供するサービス提供者を考えてみる。サービス提供者と同様なプラクティスに従う受領者は、個人情報を破棄するため個人情報へのアクセスを利用者に提供できないので、受領者はサービス提供者と同等なプラクティスに従っているとみなされる。）
<other-recipient>: 当組織とは異なるプラクティスに従う法人組織: サービス提供者の制約を受け、サービス提供者に対して責任を負うが、サービス提供者のプラクティスにおいては特定されない方法でデータを利用するかもしれない法人組織。（例えば、サービス提供者が収集したデータを、その他の目的で利用するかもしれないパートナー企業に提供する場合。しかし、利用者の利益とサービス提供者の利益への侵害と考えられるような方法でデータが利用されないことを保証することが、サービス提供者の利益となるような場合。）
<unrelated>: 当組織と無関係な第三者: サービス提供者がそのデータ利用プラクティスについて関知しないような法人組織。
<public>: 公のフォーラム: 公のフォーラム。掲示版、公のディレクトリ、または商用CD-ROMのディレクトリなど。

上記の各タグは任意に以下を含むことができる:

受領者の記述がある一つ以上のrecipient-descriptionタグ;
<ours>を例外として、required属性:この属性は共有のopt-in/opt-outが可能であるかどうかを示して、PURPOSEタグに類似の属性として定義されている。（そしてそのデフォルト値はalwaysである。）

[38]
recipient

=

"<RECIPIENT>" 1*recipientvalue *extension "</RECIPIENT>"

[39]
recipientvalue

=

"<ours>" *recdescr "</ours> | ; 当組織および／または当組織の業務委託先 "<same" [required] ">" *recdescr "</same>" | ; 当組織のプラクティスに従う法人組織 "<other-recipient" [required] ">" *recdescr "</other-recipient>" | ; 当組織とは異なるプラクティスに従う法人組織 "<delivery" [required] ">" *recdescr "</delivery>" | ; 当組織とは異なるプラクティスに従う可能性のある配送サービス "<public" [required] ">" *recdescr "</public>" | ; 公のフォーラム "<unrelated" [required] ">" *recdescr "</unrelated>" ; 当組織と無関係な第三者

[40]
recdescr

=

"<recipient-description>" PCDATA ; 受領者の記述 "</recipient-description>"

サービス提供者は適合する全ての受領者を公開しなければならない。 P3Pはそのデータが受領者にどのようにリリースされるのかについての区別はしない。ただ、データがリリースされれば、そのデータが必要であり、P3Pポリシーでそのデータ共有を明らかに示さなければならないだけである。 P3Pポリシーでカバーされなければならないデータの公表例には以下がある。

データを注文の履行または請求過程として顧客に転送する。
メーリングリストの貸し出しと販売。
要求が第三者にリダイレクトする時、URIに個人情報を置く。
第三者にリンクしているURIに個人情報を置く。

上記の受領者がデータすべてを記述してはいない場合があることに注意。たとえば、出荷や支払いをする人などのような取り引き業務をおこなう人（この行動の完了とサポートに必要であるが、他の業務にしたがうことに問題がある）の場合。現在、配達サービスのみポリシーで明らかに表している。他の取り引き業務については、オリジナルのサービスプロバイダに関して一番正確に表しているカテゴリで示している。

配達サービスの特別な要素は含まれているが、（銀行やクレジットカードなどの）支払い処理についての要素は、以下の理由のため含まれていない。配達の受領者は普通、配達サービスのプライバシーポリシーを見直す機会がないが、金融機関は一般的に顧客の金融データの使用に関して顧客との間に独立の同意書を持つだろう。

<delivery/>要素は、配送を遂行するためにサービス提供者の代行としてのみデータを使用することに同意している配送サービスに対して使われるべきではないことに注意すること。

3.3.6 `RETENTION` 要素

各STATEMENT要素（ステートメント要素）には、そのステートメントで参照されたデータに当てはまる保有ポリシーを示すRETENTION要素（保有要素）が含まれなければならない。

<RETENTION>: 有効な保有ポリシーのタイプ

RETENTION要素には、以下のうちの1つが含まれなければならない:

<no-retention/>: 情報は、オンラインでの1回のインタラクションにおいてその情報を利用するのに必要な短い時間以上は保有されない。情報はこのインタラクションの後は消去されなければならず、ログとして記録されたり、履歴として残されたり、その他の方法で保存されたりしてはならない。このタイプの保有ポリシーは、例えば、Webサーバのログを取らないサービスや、1回のセッションで使用するためだけにクッキーを設定するサービス、 Web検索を行うために情報を収集するが検索に関するログは取らないサービスなどに当てはまるだろう。
<stated-purpose/>: 言明された目的のための保有：情報は言明された目的をかなえるために保有される。これは、情報ができるだけ早期に破棄されることを要求するものである。サイトは、データ消去のタイムテーブルを設定した保有ポリシーを持たなければならない。保有ポリシーは、サイトの人間が読むことのできるプライバシーポリシーに含まれるか、またはそこからリンクが張られていなければならない。
<legal-requirement/>: 法律または適用可能な法律に基づく責務による要求: 情報は、言明された目的をかなえるために保有されるが、その保有期間は、法律上の要求または責務によってそれよりも長い場合がある。例えば、消費者が一定期間の間、取引に対して異議申立てを行うことが法律によって認められているため、企業は責務上の理由によりその取引記録を保持しようとするかもしれない。また、企業が監査上の目的あるいは健全性の目的で記録を保持することが、法律によって肯定的に要求されているかもしれない。サイトはデータ消去のタイムテーブルを設定した保有ポリシーを持たなければならない。保有ポリシーは、サイトの人間が読むことのできるプライバシーポリシーに含まれるか、またはそこからリンクが張られていなければならない。
<business-practices/>: サービス提供者の業務プラクティスによる決定: 情報は、サービス提供者の言明した業務プラクティスに従って保有される。サイトはデータ消去のタイムテーブルを設定した保有ポリシーを持たなければならない。保有ポリシーは、サイトの人間が読むことのできるプライバシーポリシーに含まれるか、またはそこからリンクが張られていなければならない。
<indefinitely/>: 無期限: 情報は、無期限に保有される。これは、保有ポリシーがない場合に起こるかもしれない。受領者が公のフォーラムである場合は、これが適切な保有ポリシーである。

[41]
retention

=

"<RETENTION>" retentionvalue *extension "</RETENTION>"

[42]
retentionvalue

=

"<no-retention/>" | ; 保有しない "<stated-purpose/>" | ; 言明された目的 "<legal-requirement/>" | ; 法律に基づいて言明された目的 "<indefinitely/>" | ; 情報は無期限に保有 "<business-practices/>" ; 業務プラクティスによる

3.3.7 `DATA集合`と`DATA`要素

各STATEMENT要素（ステートメント要素）には、1つ以上のDATA要素を含むDATA集合要素が含まれなければならない。DATA要素は、サイトが収集するデータの型を説明するために使われる。

<DATA集合>: 送信されるか、または推測されるデータを示す
base: ref属性で示されたURI参照であるbase URI ([URI])。この属性が省略されたときのデフォルト値はP3P基本データスキーマ(http://www.w3.org/TR/P3P/base)のURI([URI])である。属性が空文字列("")だった場合、ベースはローカルの文書である。

<DATA>: 送信されるか、または推測されるデータを示す
ref (必須の属性): データ要素／集合の名前を示す分割された識別部であるURI参照 ([URI])。 URIの一部はデータスキーマに一致するものを示す。 URIの一部が存在していない場合に備えて、もしDATA要素がDATA-GROUP要素の中に含まれるなら、デフォルトのベースURIはbase属性のURIであると考えられる。他の例では同じように、デフォルトベースURIは同じ文書を参照する([URI])と同じ。
データ要素と集合の名前は、大文字/小文字の区別をするので注意。（例えば、user.home は USER.HOME あるいは User.Home とは異なる）。
optional: サイトがサイト訪問者に要求するデータ要素の提供が必須のものであるか否かを意味する; "no"は、そのデータ要素の提供が必須であることを意味し、"yes"はそのデータ要素の提供が必須ではないことを意味する。 既定値は"no"である。このoptional属性は、ポリシーにおいてのみ使用される（データスキーマの定義においては使用されない）。

ユーザエージェントは自動化した意思決定でoptional属性を使用することついて注意すべきである。もし、optional属性がユーザエージェント（HTTP Refererヘッダやクッキーのような）が直接管理するデータ要素に関係があれば、ユーザエージェントは、データ要素が必要な場合にサイトのポリシーがユーザのプリファレンスと合わないと、データ要素が任意であるウェブサイトにこのデータが転送されないことを確認すべきである。また、ユーザが一般的に入力するフォームのデータに関して、任意のデータについてのサイトの業務がユーザのプリファレンスに合わなくなったら、ユーザエージェントはユーザに警告すべきである。

DATA要素は、現実のデータを含むことができる（ENTITY要素のケースでみたように）。そして、カテゴリ情報関連も含むことができる。

[43]
data-group

=

"<DATA-GROUP" [" base=" quoted-URI] ">" 1*dataref *extension "</DATA-GROUP>"

[44]
dataref

=

`<DATA" ref="` URI-reference `"` [" optional=" `"` ("yes"|"no") `"`] ">" [categories] ; データ要素のカテゴリ [PCDATA] ; データ要素の結果となる値 "</DATA>"

ここで、 URI-referenceは[URI]で定義される。

例えば、利用者の住所、データ集合user.business-infoの全ての要素、さらに（オプショナルなものとして）データ集合user.home-info.telecomの全ての要素を参照するために、サービスはP3Pポリシー内に以下の参照データを記載するだろう。:

<DATA-GROUP>
<DATA ref="#user.home-info.city"/>
<DATA ref="#user.home-info.telecom" optional="yes"/>
<DATA ref="#user.business-info"/>
</DATA-GROUP>

データの実際の値が分かっている場合、結果として生じた拡張の様に、値をDATA要素内で表現することができる。例えば、example policiesを例に挙げると：

 <ENTITY>
  <DATA-GROUP>
   <DATA ref="#business.name">CatalogExample</DATA>
   <DATA ref="#business.contact-info.postal.street">4000 Lincoln Ave.</DATA>
...

3.4 カテゴリ

カテゴリとは、利用者とユーザエージェントに、意図されたデータ利用に関してヒントを提供するデータ要素の属性である。カテゴリは、P3Pユーザエージェントの実装と使用をより容易にするために不可欠である。 カテゴリはデータ要素ではないことに注意：カテゴリによって、利用者はさらに一般化されたプリファレンスやデータ交換規則を表明することができる。

データカテゴリを示すために使われている記号は以下の通りである：

<physical/>: 実社会における連絡先情報: 実社会において個人に問い合わせを行ったり、所在を突き止めることを可能にするような情報。電話番号や住所など。
<online/>: オンライン連絡先情報: インターネット上で個人に問い合せを行ったり、所在を突き止めることを可能にするような情報。電子メールアドレスなど。この情報は、ネットワークにアクセスするときに使用される特定のコンピュータには依存しないことが多い。（"コンピュータ情報"カテゴリを参照のこと。）
<uniqueid/>: ユニークな識別子: 個人を整合的に特定するために発行された識別子。金融機関のID番号を除く。（政府発行の識別子を除く）。これらはウェブサイトやサービスから発行された識別子を含む。
<purchase/>: 購入情報: 商品やサービスを購入することによって積極的に生成される情報。支払方法の情報を含む。
<financial/>: 金融情報: 口座、残高、支払い、借越し、購入、クレジットカード、デビットカードなどの個人の金融情報。個人による非連続した購入は、"購入情報"で説明した様に、それ単体では"金融情報"には属さない。
<computer/>: コンピュータ情報: 個人がネットワークにアクセスするときに使用しているコンピュータシステムに関する情報。 IPアドレスやドメインネーム、ブラウザの種類、オペレーティングシステムなど。
<navigation/>: ナビゲーションとクリックストリームのデータ: 閲覧することによって受動的に生じるデータ。訪問したページやページごとの滞在時間など。
<interactive/>: インタラクティブデータ: Webサイトを通じた、サービス提供者との明示的なやりとりから積極的に生じるデータ。また、そのようなやりとりを反映したデータ。検索エンジンでの検索事項やアカウント活動のログなど。
<demographic/>: 人口統計学的・社会経済学的データ: 個人の特徴に関する情報。性別や年齢、収入など。
<content/>: 文章の内容 : 通信活動に含まれる言葉や表現。電子メールの文章や掲示板への掲示内容、またチャットルームでの通信内容など。
<state/>: 状態管理メカニズム: 利用者とのセッションを維持したり、また以前に特定サイトを訪問したことや特定コンテンツにアクセスしたことがある利用者を自動的に特定したりするメカニズム。HTTPクッキーなど。
<political/>: 市民情報: 宗教団体、労働組合、専門的な協会、政党などの会員、または所属。
<health/>: 健康情報: 個人の肉体的または精神的健康、性的志向、ヘルスケアーサービスや製品の使用又は調査、ヘルスケアーサービスや製品の購入等に関する情報。
<preference/>: プリファレンス（嗜好）データ: 個人の好みや嫌いなものに関するデータ。好きな色や音楽の好みなど。
<location/>: 位置データ: 個人の現在の物理的な位置情報とその位置の追跡のために使うことができる。GPS位置データなど。
<government/>: 政府発行の識別子: 個人を識別するための政府が発行した識別子。
<other-category> string </other-category>: その他: 上記の定義にあてはまらない他のデータ型。（この場合、人間が読むことのできる説明（<other-category> と </other-category>タグに挟んで）が提示されなければならない。

コンピュータ情報、ナビゲーションとクリックストリームのデータ、 インタラクティブデータ、文章の内容のカテゴリは、以下のように区別することができる。コンピューター情報には、IPアドレスやソフトウェア構成を含む利用者のコンピューターに関する情報が含まれる。ナビゲーションとクリックストリームのデータには、閲覧に関係した利用者の実際の行動が記述されている。閲覧行動に関係した情報を含んだログファイルの中にIPアドレスが記録されている場合には、コンピュータカテゴリとナビゲーションカテゴリの両者が使用されていることになる。インタラクティブデータは、閲覧にとどまらず、サイト上で何らかの有用なサービスを提供するために積極的にサイトが求めるデータである。文章の内容は、通信目的のためにサイト上で交換される情報のことである。

Otherカテゴリは、いずれのカテゴリにも当てはまらないデータが要求される場合にのみ使われるべきである。

P3Pは、利用者とユーザエージェントに、サービスから要求される情報型に関して付加的なヒントを提供するためにカテゴリを使用する。基本データスキーマ中の大部分のデータはいずれか1つのカテゴリ（またはいくつかのカテゴリの組み合わせ）に入るが、状況次第で異なる複数のカテゴリに入る可能性のあるデータ要素もある。前者は、固定カテゴリデータ要素（あるいは、短く「固定データ要素」）と呼ばれ、後者は可変カテゴリデータ要素（「可変データ要素」）と呼ばれている。以下の2つの節で、両型の要素を簡単に説明する。

3.5 拡張メカニズム

P3Pは、EXTENSIONという要素を使用して、構文とセマンティクスを拡張するための柔軟かつ強力なメカニズムを提供する。この要素は拡張に属すポリシーの部分を示す為に使用される。EXTENSION要素内のデータの意味は、拡張そのものによって定義される。

<EXTENSION>: 構文の為の拡張を説明する。
optional: この属性は、拡張が必須又は任意であるかを決定する。必須拡張はoptional属性にnoを指定することによって示される。 P3P構文への必須拡張は、この拡張を理解できないアプリケーションは、ポリシー（データスキーマ）全体の意味を理解できない事を意味する。任意拡張はoptional属性にyesを指定することによって示され、この拡張を理解できないアプリケーションは安全にEXTENSION要素の内容を無視することができ、通常どおりにポリシー（データスキーマ）全体を処理することができることを意味する。optional属性は要求事項ではなく、既定値はyes：

[47]

extension

"<EXTENSION" [" optional=" `"` ("yes"|"no") `"`] ">" PCDATA "</EXTENSION>"

例として、もし"www.catalog.example.com"が特定のデータ集合要素を、アメリカ、カナダ、メキシコに住んでいる利用者からのみ収集する事を示す機能をP3Pに追加したい場合、以下のような必須拡張を追加することができる:

<DATA-GROUP>
...     
<EXTENSION>
<COLLECTION-GEOGRAPHY type="include" xmlns="http://www.catalog.example.com/P3P/region">
<USA/><Canada/><Mexico/>
</COLLECTION-GEOGRAPHY>
</EXTENSION>
</DATA-GROUP>

一方で、もし"www.catalog.example.com"が、サーバが置かれている国を示す拡張を追加したい場合、以下の様に任意拡張の方が適している：

<POLICY>
<EXTENSION optional="yes">
<ORIGIN xmlns="http://www.catalog.example.com/P3P/origin" country="USA"/>
</EXTENSION>
...
</POLICY>

xmlns属性は重要な属性である。というのは、これは、拡張に使用される要素と属性の名称を解釈するためのネーム空間を規定するからである。 [XML-Name]に具体的に示されるように、ネーム空間URIが単に拡張に対する唯一の識別子であることが意図されているにすぎないことに注意すること。しかしながら、サービス提供者は対応するURI上で、拡張の説明を載せたページを提供してもよい。

3.6 ユーザプリファレンスのインポートとエクスポート

ユーザエージェントはプリファレンスのインポートと処理が可能な方法を文書化しなければならない。また、プリファレンスがエクスポートできる方法を文書化するべきである。

4. 簡潔なポリシー

簡潔なポリシーは、ポリシーの適用についてユーザエージェントが迅速で同時の決定をできるためのヒントを提供するＰ3Ｐポリシーを要約したものである。簡潔なポリシーはユーザエージェントやサーバの任意である性能の最適化である。簡潔なポリシーから十分な情報を得る事のできないユーザエージェントは、ユーザのプリファレンスに従って決定をする完全なポリシーを取り出すべきである。

Ｐ3Ｐｖ1において、簡潔なポリシーはクッキーのみのポリシー情報を含んでいる。ウェブサーバは完全なポリシーで参照されたクッキーを表すＰ3Ｐの簡潔なポリシーをビルドする責任がある。Ｐ3Ｐの簡潔なポリシーで指定されたポリシーはクッキーに格納されているデータおよびウェブサイトのクッキーが参照しているデータに適用する。

4.1 簡潔なポリシーを参照する

ＨＴＴＰによって転送された文書は、Ｐ3Ｐ：ヘッダを通じてＰ3Ｐの簡潔なポリシーを含んでもよい。サイトがＰ3Ｐヘッダを使用していれば、HEADとOPTION要求を含む適切なリクエスト方式のレスポンスでＰ3Ｐの簡潔なポリシーを含んでもよい。

Ｐ3Ｐヘッダ内に簡潔なポリシーを指定するには、サイトがＰ3Ｐヘッダに（2.2.2章を参照）その簡潔なポリシーを指定する。Ｐ3Ｐの簡潔なポリシーヘッダには一つ以上の範囲を決められたトークン（"簡潔なポリシー"）を含む引用された文字列がある。スペースは有効なデリミッタだけである。このヘッダの構文は以下である：

[48]
compact-policy-field

=

`CP="` compact-policy `"`

[49]
compact-policy

=

compact-access [" " compact-disputes] [*(" " compact-remedies)] [" " compact-non-identifiable] [1*(" " compact-purpose)] [1*(" "compact-recipient)] 1*(" " compact-retention) [*(" " compact-category)]
[compact-test]

ＨＴＴＰヘッダの規則を維持するにあたって、このヘッダのP3Pの部分はいずれにしても記述される。

ユーザエージェントはP3Pの簡潔なポリシーフィールドを処理してもよい。

4.2 簡潔ポリシーのボキャブラリ

P3Pの簡潔なポリシーはP3Pのボキャブラリから以下の要素をサポートする： ACCESS, CATEGORIES, DISPUTES, NON-INDENTIFIABLE, PURPOSE, RECIPIENT, REMEDIES, RETENTION, TEST

P3Pの簡潔ポリシーのボキャブラリはHTTPレスポンスヘッダ内でネットワーク上のバイト数を減らすため開発者が読む事のできる言語を使用して表現される。そのトークンの構文は以下である：

4.2.1 簡潔な`PURPOSE`

目的（purpose）は三文字コードと一つの任意の文字属性を使用してP3Pの簡潔なポリシーに表現される。このような任意の属性は、完全なP3Pポリシー内の"required"属性の値を記号化する：その値は"a", "i" と "o"であり、対応するＰ3Ｐポリシー内の"required"属性が、各々"always", "opt-in" そして "opt-out"に設定されなければならないことを意味する。

Ｐ3Ｐの簡潔なポリシーにおいて、完全なＰ3Ｐポリシー内にある一つ以上のother-purposesを設定しなければならない場合、単一のOTPフラグが完全なＰ3Ｐポリシー内に other-purposesが存在するということをユーザエージェントに知らせるために使用される。

Ｐ3Ｐの目的と簡潔なポリシーコードの対応する関連性は以下である：

4.2.2 簡潔な`RECIPIENT`

受領者（ｒｅｃｉｐｉｅｎｔ）は三文字コードと一つの任意の文字属性を使用して P3Pの簡潔なポリシーに表現される。このような任意の属性は完全なＰ3Ｐポリシー内の "required"属性の値を記号化する：その値は"a", "i" そして "o"であり、対応するＰ3Ｐポリシーの"required"属性が各々"always", "opt-in" そして"opt-out"に設定されなければならないことを意味する。

P3P受領者と簡潔なポリシーコードの対応する関連性は以下である：

4.2.3 簡潔な`RETENTION`

RETENTION要素の情報は簡潔なポリシーに以下のように表される：

[53]
compact-retention

=

"NOR" | ; for <no-retention/> "STP" | ; for <stated-purpose/> "LEG" | ; for <legal-requirement/> "BUS" | ; for <business-practices/> "IND" ; for <indefinitely/>

4.2.4 簡潔な`CATEGORIES`

カテゴリ（Ｃａｔｅｇｏｒｉｅｓ）は簡潔なポリシーに以下のように表される：

完全なP3Pポリシー内において、一つ以上のother-categoryが指定されている場合、単一のOTCトークンは、ユーザエージェントにother-category'sが完全なP3Pポリシー内に存在することを知らせるために使用される。

4.2.5 簡潔な`NON-IDENTIFIABLE`

NON-IDENTIFIABLE要素の存在はNIDトークンによって知らされる：

[55]
compact-non-identifiable

=

"NID" ; for <NON-IDENTIFIABLE/>

4.2.6 簡潔な`DISPUTES`

完全なP3Pポリシーに一つ以上のDISPUTES要素を含むDISPUTES-GROUP要素がある場合、サーバはP3Pの簡潔なポリシーフィールドに単一の"DSP"トークンを提供してユーザエージェントに知らせるべきである：

[56]
compact-disputes

=

"DSP" ; there is some DISPUTES

4.2.7 簡潔な`ACCESS`

ACCESS要素の情報は簡潔なポリシーに以下のように表される：

4.2.8 簡潔な`REMEDIES`

REMEDIES要素の情報は簡潔なポリシーに以下のように表される：

[58]
compact-remedies

=

"COR" | ; for <correct/> "MON" | ; for <money/> "LAW" ; for <law/>

4.2.9 簡潔な`TEST`

TEST要素の存在はTSTトークンによって知らされる：

[59]
compact-test

=

"TST" ; for <TEST/>

4.3 簡潔なポリシーの範囲

P3Pの簡潔なポリシーがHTTPレスポンスヘッダにある場合、現在のレスポンスで設定されたクッキーに適用する。これにはHTTP SET-COOKIEヘッダを使用して設定されたクッキーまたは、スクリプトで設定されたクッキーがある。

簡潔なポリシーがポリシーを現在のレスポンスで設定されたクッキーに適用するだけなので、簡潔なポリシーは異なるネーム空間からクッキーを適用することはできない。 COOKIE-INCLUDE 要素はこの機能を持っている。

4.4 簡潔なポリシーの有効期限

簡潔なポリシーを使用するには、完全なP3Pポリシーの効力がクッキーの有効期限に及ばなければならない。ポリシーがクッキーの有効期限を超えて有効であることを示す方法はない。なぜなら、サイトは簡潔なポリシーを送信しない限り、ユーザエージェントがいつキャッシュを最適化（キャッシングの値が限界にきている）するかを知る方法がないからである。サーバが簡潔なポリシーを送信すると、適応するクッキーの期限が有効な間は、その簡潔なポリシーと対応する完全なP3Pポリシーも有効であるという事を示している。

4.5 P3Pポリシーを簡潔なポリシーへ変換する

P3Pの簡潔なポリシーを使用している時に、ウェブサイトはP3Pポリシーの COOKIE-INCLUDE要素が参照したポリシーを要約することによって、簡潔なポリシーを構築する責任がある。 P3PポリシーをP3Pの簡潔なポリシーへ変換することは記述的なプライバシー情報のロスを引き起こす－簡潔なポリシーは完全なP3Pポリシーで指定されたポリシーの情報すべてを含むわけではない。必須の拡張子を含む完全なポリシーは簡潔なポリシーとして表されてはならない。

サイトのポリシーがCOOKIE-EXCLUDE要素を使用している場合、サイトは正しいＰ3Ｐの簡潔なポリシーをユーザエージェントへ送ることを管理する必要がある。そのユーザエージェントは特定のレスポンスで設定したクッキーを与えられている。

COOKIE-EXCLUDE要素に加え、完全なP3Pポリシーからの他の情報は簡潔なポリシーの作成時に破棄される。これには有効期限、データ集合/データスキーマ要素、法人（ENTITY）要素、そしてconsequences要素があり、disputes要素は削減される。

3.3.1章で述べたように、完全なポリシーの複数のステートメントに現れる目的（purposes）、受領者（recipients）そしてカテゴリ（categories）はすべて簡潔なポリシーに収集されなければならない。その収集を行う時、ウェブサイトは関連するトークンをすべて公開しなければならない。（例えば、複数の保有（Retention）ポリシーが設定されている以下の例を見ると）

例 4.1:

以下のP3Pポリシーを考えてみると：

<POLICY xmlns="http://www.w3.org/2000/12/P3Pv1"
  discuri="http://www.example.com/cookiepolicy.html"
  opturi="http://www.example.com/opt.html">
  <ENTITY>
    <DATA-GROUP>
      <DATA ref="#business.name">Example, Corp.</DATA>
      <DATA ref="#business.contact-info.online.email">privacy@example.com</DATA>
    </DATA-GROUP>
  </ENTITY>
  <ACCESS><none/></ACCESS>
  <DISPUTES-GROUP>
    <DISPUTES resolution-type="service"
     service="http://www.example.com/privacy.html"
     short-description="Please contact our customer service desk with
                        privacy concerns by emailing privacy@example.com"/>
  </DISPUTES-GROUP>
  <STATEMENT>
    <PURPOSE><admin/><develop/><pseudo-decision/></PURPOSE>
    <RECIPIENT><ours/></RECIPIENT>
    <RETENTION><indefinitely/></RETENTION>
    <DATA-GROUP>
      <DATA ref="#dynamic.cookies">
        <CATEGORIES><preference/><navigation/></CATEGORIES>
      </DATA>
    </DATA-GROUP>
  </STATEMENT>
  <STATEMENT>
    <PURPOSE><customization required="opt_out"/></PURPOSE>
    <RECIPIENT><ours/></RECIPIENT>
    <RETENTION><stated-purpose/></RETENTION>
    <DATA-GROUP>
      <DATA ref="#dynamic.cookies">
        <CATEGORIES><preference/><uniqueid/></CATEGORIES>
      </DATA>
    </DATA-GROUP>
  </STATEMENT>
</POLICY>

対応する簡潔なポリシーは：

"NON DSP ADM DEV PSD CUSo OUR IND STP PRE NAV UNI"

4.6 簡潔なポリシーをP3Pポリシーへ変換する

ユーザエージェントの中にはユーザプリファレンスを評価するのに簡潔なポリシーから完全なP3Pポリシーを作成しようとするものがある。ユーザエージェントは幾つかの属性と同様にENTITYおよび DISPUTES要素を提供することができない。しかし：

簡潔な保有（retention）の複数の異なる値がない場合、: ユーザエージェントは、適切なACCESS要素そして：適切なCATEGORIESを持つ dynamic.miscdata要素と同様に、適切なRECIPIENT, RETENTION, そしてPURPOSE要素を含む単一のSTATEMENT要素を使用してポリシーを作成できなければならない。
簡潔な保有（retention）の複数の異なる値がある場合、: ユーザエージェントは、適切なACCESS要素そして：適切なCATEGORIESを持つ dynamic.miscdata要素と同様に、異なった対応する RETENTION 要素の値と適切な RECIPIENTとPURPOSE要素を含む複数のSTATEMENT要素（簡潔な保有（retention）の異なる値と同じ数の）を使用してポリシーを作成できなければならない。

5. データスキーマ

P3Pでは、サービスやユーザエージェントがデータ要素を参照するための共通の方法を提供するために、 データスキーマを定義することができる。データスキーマは、階層的に分類されたデータ集合内にグループ化された特定のデータ要素の一群を表する。

データスキーマファイルのために多言語サポートを提供する目的で、サーバはAccept-Languageヘッダを基本とした正しい選択を供給すことができる。

サービスは、データスキーマを作成し、データ要素属性を参照したポリシーにおいてデータスキーマを参照することによって、 データ要素を宣言し使用することができる。 P3Pは、P3P基本データスキーマと呼ばれる標準のデータスキーマからなっており、このP3P基本データスキーマは一般的に使用される多種多様なデータ要素を定義している。

データ要素は時に、ある共通の要素を持つグループに現れる：従って、P3Pは構造を定義できる。構造は明確に記されたデータ要素の集合である。新しい構造を定義することができ、またP3Pは組み込まれた基本データ構造 を提供する。この基本データ構造は他の新しいスキーマによって都合よく拒否することができる。

<DATASCHEMA>要素は新しいデータ要素の参照からなる

[60]
dataschema

=

"<DATASCHEMA" [` xmlns="http://www.w3.org/2000/12/P3Pv1"`] ">" *(datadef|datastruct|extension) "</DATASCHEMA>"

データスキーマはポリシーの中に埋め込むことができ、 独立したXMLファイルとしても表現することができる。この2番目のケースでは、P3Pデータスキーマファイルを示すために適切なXMLネーム空間属性xmlnsが使われていなければならない:

<DATASCHEMA xmlns="http://www.w3.org/2000/12/P3Pv1">
<DATA-STRUCT ... />
...
<DATA-DEF ... />
</DATASCHEMA>

5.1 `DATA-DEF`と`DATA-STRUCT`要素

<DATA-DEF>と <DATA-STRUCT>: データ要素、データ型それぞれの定義

以下の属性はこれら2つの要素で共通である:

name （必須の属性）: データ要素または構造の名前を示す。データ要素と構造の名前が、大文字/小文字の区別をすることに注意。例えば、user.home は USER.HOME あるいは User.Home とは異なる。なお、データ要素と構造の名前は、番号文字がドットの直後に現われることができない。
structref: 構造を示す分割された識別部であるURI参照 ([URI]を参照)。 URIの一部は定義されたデータスキーマに一致するものを示す。通常、デフォルトベースURIは同じ文書を参照する([URI])と同じ。 構造属性のない（または関連した構造のない）データ要素またはデータ構造は"構造化されていない"という。
short-description: データ要素または型の簡易表記名を表す文字列。文字数は255以下。

DATA-DEFとDATA-STRUCT要素は LONG-DESCRIPTION要素を使って、データ要素/集合または型の長い表記からなることができる。

[61]
datadef

=

"<DATA-DEF name=" quotedstring [` structref="` URI-reference `"`] [" short-description=" quotedstring] ">" [categories] ; データ要素のカテゴリ [longdescription] ; データ要素の長い表記 "</DATA-DEF>"

[62]
datastruct

=

"<DATA-STRUCT name=" quotedstring [` structref="` URI-reference `"`] [" short-description=" quotedstring] ">" [categories] ; データ構造のカテゴリ [longdescription] ; データ構造の長い表記 "</DATA-STRUCT>"

ここで、URI-referenceは[URI]で定義される。

データ要素は共通のプログラム言語で構造化できる：構造はデータ要素の階層的な（ツリーのような）記述である：この階層的な記述はピリオド(".")文字を分離記号として使用し name属性でなされる。

例えば、HyperSpeedExample社が車両の特徴を車両(vehicle)のモデル（vehicle.model）、色（vehicle.color）、製造年(vehicle.built.year)、価格(vehicle.price) などの特徴を含むvehicleという構造を使って記述したい場合。

また、HyperSpeedExample社が車両の定義に製造場所を加えたい場合、国やストリート名、郵便番号などの関連したデータを使用してその構造に他のフィールドを加える事ができた。しかし、構造の各部分は、同様に他の構造を使用する事ができる： 構造は作成することができるのである。この場合、P3P基本データスキーマ （広い意味で使用されている構造とデータ要素の対応した定義を提供する）はすでに、場所の郵便情報を記述して、構造postalを提供している。したがって、車両の最終構造は以下となる。

vehicle.model (構造化されていない)
vehicle.color (構造化されていない)
vehicle.built.year (構造化されていない)
vehicle.price (構造化されていない)
vehicle.built.where (基本構造postalを持つ)

基本構造postalにはpostal.street, postal.cityなどといったフォームの記述がある。私達は基本構造postalをvehicle.built.whereに適用しているので、各vehicle.built.where.streetおよびvehicle.built.where.cityの記述を使って車両製造の番地や都市にアクセスすることができることを意味する。従って、構造を適用する事（この場合postal）は一つのモジュラー方法に非常に複雑な記述を作成することができることを意味する。

先に述べたように、構造はデータ要素を含まない。単なる抽象的な記述である。：私達は構造を使用して、すばやくデータ要素の構造化した収集を作成することができる。車とバイクのデータを交換したいので、例の様に、HyperSpeedExampleには車両の特徴に関する抽象的な記述が必要である。従って、上記の構造vehicleを使って、carとmotorcycleという二つのデータ要素を定義することができた。

このデータ要素の記述は（実際のデータ要素プラス時にはデータ要素の記述必要がある構造）データスキーマを使って、 XMLにエンコードされる。HyperSpeedExampleの場合、記述は以下の様になる。

<DATASCHEMA xmlns="http://www.w3.org/2000/12/P3Pv1">
<DATA-STRUCT name="vehicle.model" 
    short-description="Model">
    <CATEGORIES><preference/></CATEGORIES>
</DATA-STRUCT>
<DATA-STRUCT name="vehicle.color"
    short-description="Color">
    <CATEGORIES><preference/></CATEGORIES>
</DATA-STRUCT>
<DATA-STRUCT name="vehicle.built.year" 
    short-description="Construction Year">
    <CATEGORIES><preference/></CATEGORIES>
</DATA-STRUCT>
<DATA-STRUCT name="vehicle.built.where" 
    structref="http://www.w3.org/TR/P3P/base#postal"
    short-description="Construction Place">
    <CATEGORIES><preference/></CATEGORIES>
</DATA-STRUCT>
<DATA-DEF name="car" structref="#vehicle"/>
<DATA-DEF name="motorcycle" structref="#vehicle"/>
</DATASCHEMA>

例を続けて、車のモデルと製造年を参照するために、Hyperspeedや 他のどんなサービスもP3Pプライバシーポリシーの内部に以下のような参照場所を含めて送ることができるだろう：

<DATA-GROUP>
  <!-- First, the "car.model" data element, whose definition is in the data schema
       at http://www.HyperSpeed.example.com/models-schema
    -->
<DATA ref="http://www.HyperSpeed.example.com/models-schema#car.model"/>

  <!-- And second, the "car.built.year" data element, whose definition is the data schema
       at http://www.HyperSpeed.example.com/models-schema
    -->
<DATA ref="http://www.HyperSpeed.example.com/models-schema#car.built.year"/>
</DATA-GROUP>

これは属性modelとvehicleのvehicle構造に指定されているカテゴリでなので、構造はカテゴリ情報を含むことができるように、上記の参照では両方のデータ要素は<preference/>のものである。

base属性を使うことにより、上記の参照はもっと短縮することができる：

<DATA-GROUP base="http://www.HyperSpeed.example.com/models-schema">
    <DATA ref="#car.model"/>
    <DATA ref="#car.built.year"/>
</DATA-GROUP>

あるいはデータスキーマはポリシーファイルに直接埋め込む事ができる。この場合、ポリシーファイルは以下のようになる：

<POLICY xmlns="http://www.w3.org/2000/12/P3Pv1" ... >
<!-- Here the embedded data schema begins -->
<DATASCHEMA>
<DATA-STRUCT name="vehicle.model" 
    short-description="Model">
    <CATEGORIES><preference/></CATEGORIES>
</DATA-STRUCT>
<DATA-STRUCT name="vehicle.color" 
    short-description="Color">
    <CATEGORIES><preference/></CATEGORIES>
</DATA-STRUCT>
<DATA-STRUCT name="vehicle.built.year" 
    short-description="Construction Year"">
    <CATEGORIES><preference/></CATEGORIES>
</DATA-STRUCT>
<DATA-STRUCT name="vehicle.built.where" 
    structref="http://www.w3.org/TR/P3P/base#postal"
    short-description="Construction Place">
    <CATEGORIES><preference/></CATEGORIES>
</DATA-STRUCT>
<DATA-DEF name="car" structref="#vehicle"/>
<DATA-DEF name="motorcycle" structref="#vehicle"/>
</DATASCHEMA>
<!-- Now the policy begins -->
...
<DATA-GROUP base="">
<DATA ref="#car.model"/>
<DATA ref="#car.built.year"/>
</DATA-GROUP>
...
</POLICY>

どんな場合も、一つのファイルに二つ以上のデータスキーマがあってはならないことに注意。（従って、POLICIES要素に含まれているポリシーにデータスキーマを埋め込む時には注意が必要）

データ要素と構造は、いずれかの固定されているカテゴリであるか否かにかかわらず分類することができる（category要素を使うことで）。スキーマ設計者がそれぞれの要素のためにほとんど不変のカテゴリを定義するためにスキーマ定義の中でこの属性を使うことができる。一度定義されると、ユーザの嗜好（プリファレンス）とP3Pポリシーでその要素を参照する時は、その値は変更できない。しかしながら、他のスキーマ定義では変更することができる。 （上記の車輌の例で、基本データスキーマで定義されているpostal構造には physicalとdemographic カテゴリがあるが、 vehicle.built.where構造のカテゴリをpreferenceと再定義した。）

もし、CATEGORIES要素がなければ、（カテゴリを定義しないままにしておく）その要素を参照している各P3Pポリシーに明確にCATEGORIES要素をリストに入れなければならない。ユーザは同じ要素の異なるカテゴリ値に合わせた異なるプリファレンスを持つ事ができる。そして、データ構造で定義されないカテゴリの場合、他のスキーマ定義は、派生した要素にカテゴリを明白に設定することができる。（あるいは派生させたスキーマのどんな値に対するオリジナルの定義の上書き）の中のカテゴリとして、他のスキーマ定義により明白に設定することができる。

基本データスキーマや拡張データスキーマ内で指定されているデータ要素名は、 P3Pポリシーの目的以外に使用されるかもしれないことに注意されたい。例えば、ウェブサイトがHTMLのフォームフィールドをラベル付けするためにそれらの名前を使用するかもしれない。P3Pポリシーとフォームでのデータ参照方式を同じ方式で行うためには、フォームへの自動入力ツールは、 P3Pユーザエージェントと統合された方が好ましいだろう。

5.2 データスキーマの持続有効性

データスキーマにおける必須の要求条件は、データスキーマの持続有効性である。特定のURIから取得されるデータスキーマを拡張することによって、データスキーマを 後方互換性で変更することができる。（つまり、データスキーマを変更すると、そのスキーマを使用しているあらゆるポリシーの意味を変えることはできない。という事を意味している。）このようにして、ポリシーのURIはここに含まれているデータ要素と構造において唯一の拡張子の様に振る舞う。従って、後方互換性でないデータスキーマはすべて、新しくそして異なるURIを使用しなければならない。

データスキーマの持続有効性のあるアプリケーションは多言語サイトの例を示す為に提供されたことに注意：データスキーマ用に特定の言語が使用される事を適切に述べるために、 HTTP"Content-Language"を使用して、同じデータスキーマの多言語サイト（翻訳）版をサーバが提供することができる。

5.3 基本データ型

基本データ構造はP3P基本データスキーマ（この基本の性質のため、基本データ構造は再利用されるべきであり、また同様に他の異なるデータスキーマによって再使用すべきである。）によって使用される構造である。P3Pに準拠した全てのユーザエージェントの実装は、基本データ構造を認識できなければならない。以下の個々のテーブルでは、基本データ構造の要素、属するカテゴリ、構造、利用者に示す簡易表記名を指定している。二つ以上のカテゴリが一つの固定データ要素に関連づけされるかもしれない。しかしながら、どの基本データ要素も可能な限り、たった一つのカテゴリに割り当てられる。データスキーマの設計者にも同じ事を行う事を推奨する。

5.3.1 日付

date構造は、日付を特定する。日付に関する情報は、周囲の状況によって使われ方が異なるので、全てのdate情報は、"可変"カテゴリとして分類される。スキーマ定義は、このデータ構造を参照する要素内の対応するカテゴリを明白に設定しなければならない。例えば、利用者の誕生日を要求する場合は、"人口統計学的・社会経済学的データ"になるが、クレジットカードの有効期限は、"購入情報"カテゴリとなる。

date カテゴリ 構造 簡易表記名

ymd.year (可変カテゴリ) 構造化されていない 年

ymd.month (可変カテゴリ) 構造化されていない 月

ymd.day (可変カテゴリ) 構造化されていない 日

hms.hour (可変カテゴリ) 構造化されていない 時

hms.minute (可変カテゴリ) 構造化されていない 分

hms.second (可変カテゴリ) 構造化されていない 秒

fractionsecond (可変カテゴリ) 構造化されていない 秒（小数点以下）

timezone (カテゴリ) 構造化されていない タイムゾーン

"タイムゾーン"情報は、[ISO8601]の時間標準に定義されている例のためのものである。 "date.ymd"と"date.hms"は、年/月/日と時/分/秒、それぞれの組の参照時間を短縮するために使用されることに注意されたい。

5.3.2 名前

personname構造は、個人の名前に関する情報を指定する。

personname カテゴリ 構造 簡易表記名

prefix 人口統計学的・社会経済学的データ 構造化されていない 敬称

given 実社会における連絡先情報 構造化されていない 名(Given Name)

family 実社会における連絡先情報 構造化されていない 姓

middle 実社会における連絡先情報 構造化されていない ミドルネーム

suffix 人口統計学的・社会経済学的データ 構造化されていない Name Suffix

nickname 人口統計学的・社会経済学的データ 構造化されていない 愛称

5.3.3 認証

certificate構造は、本人であることの証明（例：X.509）を指定する。

certificate カテゴリ 構造 簡易表記名

key ユニークな識別子 構造化されていない 認証鍵

format ユニークな識別子 構造化されていない 認証フォーマット

"format"フィールドは、IANAに登録されている公開鍵、もしくは認証書のフォーマットの情報を表すために使用される。 "key"フィールドは、対応する認証鍵を表すために使用される。

5.3.4 電話

telephonenum構造は、電話番号に関する特徴を指定する。

telephonenum カテゴリ 構造 簡易表記名

intcode 実社会における連絡先情報 構造化されていない 国番号

loccode 実社会における連絡先情報 構造化されていない 局番

number 実社会における連絡先情報 構造化されていない 電話番号

ext 実社会における連絡先情報 構造化されていない 内線

comment 実社会における連絡先情報 構造化されていない 注釈

5.3.5 連絡先情報

contact構造は、連絡先情報を指定するために使用される。サービスは、郵便、テレコミュニケーション、またはオンラインアドレス情報のどのデータの集合が必要であるか正確に指定することができる。

contact カテゴリ 構造 簡易表記名

postal 実社会における連絡先情報, 人口統計学的・社会経済学的データ postal 郵便情報

telecom 実社会における連絡先情報 telecom テレコミュニケーション情報

online オンライン連絡先情報 online オンラインアドレス情報

5.3.5.1 郵便

postal構造は、郵便あて先を指定する。

postal カテゴリ 構造 簡易表記名

name 実社会における連絡先情報, 人口統計学的・社会経済学的データ personname 氏名

street 実社会における連絡先情報 構造化されていない 町・番地

city 実社会における連絡先情報 構造化されていない 市・区

stateprov 実社会における連絡先情報 構造化されていない 都道府県

postalcode 人口統計学的・社会経済学的データ 構造化されていない 郵便番号

country 人口統計学的・社会経済学的データ 構造化されていない 国

organization 実社会における連絡先情報, 人口統計学的・社会経済学的データ 構造化されていない 団体・組織名

"国"フィールドはその国名の情報を表す（例えば、 [ISO3166]のリストに挙げられている国の中の一つなど。）

5.3.5.2 テレコミュニケーション

telecom構造は、個人に関するテレコミュニケーション情報を指定する。

telecom カテゴリ 構造 簡易表記名

telephone 実社会における連絡先情報 telephonenum 電話番号

fax 実社会における連絡先情報 telephonenum ファックス番号

mobile 実社会における連絡先情報 telephonenum 携帯電話番号

pager 実社会における連絡先情報 telephonenum ポケットベル番号

5.3.5.3 オンライン

online構造は、個人に関するオンライン情報を指定する。

online カテゴリ 構造 簡易表記名

email Online Contact Information 構造化されていない 電子メールアドレス

uri Online Contact Information 構造化されていない ホームページアドレス

5.3.6 アクセスログとインターネットアドレス

インターネットアドレスを表すために使用される構造二つがある。 uri構造は汎用リソース識別子（URI）をカバーする。これは[URI]に詳しく定義されている。 ipaddr構造はIPアドレスとドメイン名システム（DNS）ホスト名を表している。

5.3.6.1 URI

`uri`	カテゴリ	構造	簡易表記名
authority	(可変カテゴリ)	構造化されていない	URI権限
stem	(可変カテゴリ)	構造化されていない	URIステム
querystring	(可変カテゴリ)	構造化されていない	URIの照会列部分

URIの権限は[URI] にauthorityコンポーネントとして定義されている。 URIのステムはURIの最初の'?'文字までの部分に含まれている情報として定義されている。そして、照会列は最初の'?'文字の後のURI部分に含まれている情報である。 '?'を含んでいないURIに関しては、そのステムが全URIであり、その照会列は空である。

URI情報を異なる方法で使用する事ができるので、このコンテキストにそって、 uri構造のすべてのフィールドは"可変"カテゴリであると分類けされる。スキーマの定義はこのデータ構造を参照している要素の対応するカテゴリに明白に設定しなければならない。

5.3.6.2 ipaddr

ipaddr構造はシステムのホスト名とIPアドレスを表す。

ipaddr カテゴリ 構造 簡易表記名

hostname Unique Identifiers 構造化されていない 完全なホストとドメイン名

partialhostname Demographic 構造化されていない ホスト名の一部

fullip Unique Identifiers 構造化されていない 全IPアドレス

partialip Demographic 構造化されていない IPアドレスの一部

hostname要素は単なるホスト名の集合または、ドメイン名を含んだ全ホスト名を表す為に使用される。 partialhostname要素はホスト名から少なくともホスト部分をはずした完全に分類されたホスト名情報を表す。いい換えれば、完全に分類されたホスト名の最初の'.'にまで及んでいるすべては、アドレス認識のために"ホスト名の一部"として分類されなければならない。

fullip要素は全IP4版または6版のアドレスを表す。partialip要素は少なくとも 最後の7bitの情報を削除したIP4版（IP4版のみ、6版は表さない）を表す。すべてのサイト訪問者用に合わせたパターンとbitを入れ替えてこの情報を削除しなければならない。（例えばすべての0または1）

あるWebサイトはサイト訪問者の全IPアドレスまたはホスト名を使用するために認識されているわけではないが、その情報を縮小したフォームを利用する為に認識されている。アドレス情報の一部分のみを集めて、サイト訪問者は匿名に対する確認を行われる。この"取り除かれた"IPアドレスやホスト名は個人ユーザと連携する事はできないがそれ以上に連携が困難であると主張することはこの仕様書の意図することではない。このデータを縮小するサイトはプラクティスをより正確に反映するためにこのプラクティスを宣言したいと考えているかもしれない。

5.3.6.3 アクセスログ情報

loginfo構造はWebサーバアクセスログに格納されている情報を表すために使用される。

loginfo カテゴリ 構造 簡易表記名

uri ナビゲーションとクリックストリームデータ uri 要求されたリソースのURI

timestamp ナビゲーションとクリックストリームデータ date 要求とタイムスタンプ

clientip コンピュータ情報 ipaddr クライアントのIP アドレスまたはホスト名

other.httpmethod ナビゲーションとクリックストリームデータ 構造化されていない HTTP要求方式

other.bytes ナビゲーションとクリックストリームデータ 構造化されていない レスポンスのデータバイト

other.statuscode ナビゲーションとクリックストリームデータ 構造化されていない レスポンスステータスコード

HTTP要求のリソースはuriフィールドで記録される。サーバがその要求を処理する時間は timestampで表示する。このフィールドを要求が受け取られた時、または、サーバがレスポンスを送り始めた時、または、レスポンス送信が完了した時、要求が処理された時間をサーバ実装は自由に表示すると定義できる。この要求を作成しているクライアントシステムのIPアドレスはclientipが与える。

otherデータフィールドはWebサーバアクセスログに共通して格納されている他の情報を表示する。 other.httpmethodはクライアントの要求の中にあるHTTP方法（GET, POSTなど）である。 other.bytesはサーバが送ったレスポンス本体のバイト数を示している。 other.statuscodeは200、302または404といった要求のHTTPステータスコードである。（詳細は[HTTP1.1]の6.1.1節を参照のこと）

5.3.6.4 その他HTTPプロトコル情報

httpinfo構造はloginfo構造がカバーしていないHTTPプロトコルが送る情報を表示する。

httpinfo カテゴリ 構造 簡易表記名

referer ナビゲーションとクリックストリームデータ uri ユーザが要求した最後のURI

useragent コンピュータ情報 構造化されていない ユーザエージェント情報

useragentフィールドはユーザのWebブラウザの型やバージョンについての情報を提供する HTTP User-Agentヘッダ、と（または）HTTP accept*ヘッダに表示される。

refererフィールドはユーザが以前訪問したページについての情報を提供する HTTP Refererヘッダにその情報を表示する。このフィールドは対応するHTTPヘッダと全く同じようにスペルミスされていることに注意されたい。

5.4 基本データスキーマ

P3Pに準拠して実装された全てのユーザエージェントは、P3P基本データスキーマのデータ要素を認識できなければならない。 P3P基本データスキーマは、基本データ構造の定義と user、 thirdparty、 business と dynamic の4つの要素集合を含む。 user、 thirdparty と business集合は、利用者と（または）ビジネスが値を提供するであろう要素を含み、 dynamic集合は、利用者のブラウザによる閲覧を通して動的に生成される要素を含む。ユーザエージェントは、複数の人物をサポートする機能を含み、利用者がuser集合の要素に値を提供し、データレポジトリにそれらを保存することを可能にする様々な機能をサポートするかもしれない。また利用者はそれらのデータ要素に値を提供しない選択を行う事もできるだろう。

P3P基本データスキーマの正式なXML定義は、付録3で提供されている。以下のセクションでは、基本データ要素と集合を一つずつ説明していく。これから、 他のデータセットや要素の作成要求が出てくる可能性がある。カタログ、支払い、そしてエージェント/システム属性スキーマを含むアプリケーションに関してはすでに明白である。（拡張的なシステム要素の集合例はhttp://www.w3.org/TR/NOTE-agent-attributesで提供してある）

以下のテーブルでは集合、集合内の要素、要素に関連するカテゴリ、構造、簡易表記名が指定してある。二つ以上のカテゴリが一つの固定データ要素に関連づけされるかもしれない。しかしながら、どの基本データ要素も可能な限り、たった一つのカテゴリに割り当てられる。データスキーマの設計者にも同じ事を行う事を推奨する。

5.4.1 個人データ

userデータ集合は、個人に関する一般的な情報を含む。

user カテゴリ 構造 簡易表記名

name 実社会における連絡先情報、人口統計学的・社会経済学的データ personname 利用者名

bdate 人口統計学的・社会経済学的データ date 利用者の誕生日

cert ユニークな識別子 certificate 利用者の身元証明

gender 人口統計学的・社会経済学的データ 構造化されていない 利用者の性別（男性または女性）

employer 人口統計学的・社会経済学的データ 構造化されていない 利用者の雇主

department 人口統計学的・社会経済学的データ 構造化されていない 利用者が勤務している組織の部門または課

jobtitle 人口統計学的・社会経済学的データ 構造化されていない 利用者の勤務先での肩書き

home-info 実社会における連絡先情報、オンライン連絡先情報、人口統計学的・社会経済学的データ contact 利用者の自宅へのコンタクト情報

business-info 実社会における連絡先情報、オンライン連絡先情報、人口統計学的・社会経済学的データ contact 利用者の勤務先へのコンタクト情報

このデータ集合は、それ自体がデータの集合である要素を含んでいる事に注意されたい。これらの集合は、データ構造の節で定義してある。データ集合内部にある個々の要素のための簡易表記名は、例えばカンマなど、言語/スクリプトにおける区切り文字を用いて、集合と要素のために定義されている簡易表記名の連結として定義されている。例えば、user.home.postal.postalcodeの簡易表記名は、 "利用者の自宅へのコンタクト情報, 郵便情報, 郵便番号"となる。ユーザエージェントの実装において、開発者は利用者に情報を提示する場合、連結された表記名を使用せずに、独自の簡易表記名を使用してもよいだろう。

5.4.2 第三機関データ

thirdpartyデータ集合は、利用者とビジネスが関連する第三機関にデータを提供することを許可する。これは、第三機関とデータのやり取りを行う必要がある時に便利である。例えば、ある人に送られるプレゼントをオンラインで注文する時や、配偶者や共同経営者の情報を提供する時。そのような情報は、利用者のレポジトリにuserデータ集合として保存されるだろう。ユーザエージェントは、複数のそのようなthirdpartyデータ集合を保存する機能を提供し、必要な時にリストから適切な物を利用者が選択できることを許可するだろう。

thirdpartyデータ集合は、userデータ集合と同等である。詳細は5.4.1 個人データを参照すること。

5.4.3 ビジネスデータ

businessデータ集合は、団体・組織に関するuserデータの部分集合の機能を有する。 P3P 1.0において、このデータ集合は、business-to-businessの相互作用にもまた適用可能であるけれども、主にプライバシーポリシーの団体・組織を宣言するために使用される。

business カテゴリ 構造 簡易表記名

name 人口統計学的・社会経済学的データ 構造化されていない 団体・組織名

department 人口統計学的・社会経済学的データ 構造化されていない 団体・組織における部門または課

cert ユニークな識別子 certificate 団体・組織である証明

contact-info 実社会における問い合せ窓口、オンライン問い合せ情報、人口統計学的・社会経済学的データ contact 団体・組織への問い合わせ情報

5.4.4 動的データ

利用者が入力したり、またはレポジトリに保存したりするような固定値を持たないデータ要素を指定する必要が出てくる場合がある。 P3P基本データスキーマにおいてそれらの全ての要素はdynamicデータ集合下にグループ化される。サイトは、特定の全てのデータ要素を列挙せずに、動的データ集合のみを利用して、収集するデータの型を参照してもよいだろう。

dynamic カテゴリ 構造 簡易表記名

clickstream ナビゲーションとクリックストリームのデータ, コンピュータ情報 loginfo クリックストリーム情報

http ナビゲーションとクリックストリームのデータ, コンピュータ情報 httpinfo HTTPプロトコル情報

clientevents ナビゲーションとクリックストリームのデータ 構造化されていない ユーザのリソースとの対話

cookies (可変カテゴリ) 構造化されていない HTTPクッキーの使用

miscdata (可変カテゴリ) 構造化されていない 雑多な非基本データスキーマ情報

searchtext インタラクティブデータ 構造化されていない 検索文字列

interactionrecord インタラクティブデータ 構造化されていない サーバの処理履歴の保存

これらの要素は、しばしばナビゲーションやWebでのやり取りに事実上含まれている。また、それらの方法を通して収集される情報の型を表現するために、それらの要素はカテゴリと共に使用されるべきである。以下は、各々の要素についての簡単な説明である。

clickstream: clickstream要素は、実質的にすべてのWebサイト適用する。また、Webサーバアクセスログに一般的にある情報の組み合わせを表示する：ユーザのコンピュータのIPアドレスまたはホスト名、要求されたリソースのURI、要求がなされた時間、要求の中で使用されたHTTP方式、レスポンスのサイズ、レスポンスのHTTPステータスコード。標準のサーバアクセスログを集めるWebサイトはこのデータ要素を使用して、 URIパス分析を行うこの要素サイトと同様に、どのようにしてこのデータが使用されるのかを述べることができる。 clickstream要素用にリスト化されたデータ要素のいくつかしか収集しないWebサイトは、 dynamic.clickstream要素全体よりもこれら特定の要素をリストすることを選んでもよい。このことによって、より制約されたデータ収集プラクティスをもつサイトが正確にサイト訪問者にそのプラクティスを表すことができる。
http: http要素にはHTTPプロトコルに含まれている追加情報がある。特定の要素の定義に関してはhttpinfo構造の定義を参照のこと。 httpinfo構造にある特定の要素を参照したい場合、または参照してもよい場合、サイトはhttpinfo構造のすべての要素をカバーする為に dynamic.httpを簡略伝達として使用してもよい。
clientevents: clientevents要素は、リソースとの対話中にユーザがどのようにしてWebブラウザーと対話するかについてのデータを表す。例えば、ユーザがページのある画像の上でマウスを動かしたかどうかという事や、ユーザがJavaアプレットのヘルプウインドウを出したかどうかについての情報をアプリケーションが収集する場合。この種の情報は動的.clientevents要素で表示される。この対話記録の多くは、ドキュメントオブジェクトモデル（DOM）レベル2イベント[DOM2-Events]で定義されたイベントとデータで表示される。また、clienteventsデータ要素は、ブラウザがリソースを表示している間にユーザとブラウザ間の対話に関するデータ以外をカバーする。例外として、基本データスキーマの他の要素がカバーしている要素がある。例えば、ページを見ている時にリンクをクリックしてページを要求する事はユーザとブラウザの対話であるが、単にユーザがクリックしたURLを収集することはこのデータ要素を宣言する必要がない； clickstreamがそのイベントをカバーしている。しかしながら、DOMイベントDOMFocusIn（ページのオブジェクトの上をユーザがマウスを動かしているのを表している）は既存の他の要素ではカバーされていないので、もし、サイトがこのイベントの発生を収集していれば、動的.clientevents要素を収集していると述べなければならない。このデータ要素でカバーしている項目は、普通、JavaScriptなどのクライアント側のスクりプティング言語、またはActiveX またはJava アプレトなどのクライアント側のアプレットで収集される。以前述べたのはユーザが見ているリソースに関してものだったが、このデータ要素もリソースを視覚的に表示しないWebアプリケーションに適用していることに注意。例えば、オーディオベースのWebブラウザなど。
cookies: cookies要素はHTTPクッキーがサイトによって設定されているか、または取り出されている場合には必ず使用されるべきである。 cookiesは可変データ要素であり、ポリシーでカテゴリの使用を明らかに宣言する必要があることに注意されたい。
miscdata: miscdata要素は特定のデータ要素を使用して参照しないサービスで収集される情報を参照する。カテゴリはこれらのデータをよりよく表示するために使用される：サイトは収集した雑多なデータの各カテゴリのポリシーにある独立のmiscdata要素を参照しなければならない。
searchtext: searchtext要素はサイトの検索と索引のために使用される特別な誘導の型を参照する。例えば、検索エンジンの唯一のフィールドが検索フィールドであれば、サイトはデータ要素を公開することだけを必要とする。
interactionrecord: サーバがユーザとの対話の追跡を続けている場合にinteractionrecord要素が使用されるべきである。（すなわち、クリックストリームデータ以外の情報。例えば、口座取り引きなど。）

5.5 カテゴリおよびデータ要素/構造

5.5.1 固定カテゴリデータ要素/構造

基本データスキーマにある要素はほとんど"固定した"データ要素という：その要素は一つまたは多くても二つのカテゴリクラスに属している。カテゴリを基本データスキーマの要素または構造に割り当てることによって、サービスとユーザは簡単に、対応するカテゴリを参照して要素のグループ全部を参照することができる。例えば、プライバシープリファレンス交換言語である[APPEL]を使用する場合、ユーザはあるカテゴリのあらゆるデータを集めたサイトに訪問した際に警告を発する規則を書くことができる。

固定したデータ要素のデータスキーマの作成時に、スキーマ作成者はそのデータ要素が属しているカテゴリを明白に列挙しなければならない。例えば：

<DATA-STRUCT name="postal.street" structref="#text"
short-description="Street Address">
<CATEGORIES><physical/></CATEGORIES>
</DATA-STRUCT>

要素または構造が複数のカテゴリに属する場合、適切なカテゴリを参照する複数の要素を使用できる。例えば、user.nameのデータに"物理的"と"人口統計学的"の両方があるということを宣言するために、以下のXMLの部分を使用することができる：

<DATA-STRUCT name="user.name" structref="#personname"
short-description="User's Name">
<CATEGORIES><physical/><demographic/></CATEGORIES>
</DATA-STRUCT>

例えば、周知の基本データ要素へ異なるカテゴリを割り当てる規則やポリシーを作成して、固定したデータ要素/構造のカテゴリクラスを上書きできないことに注意。ユーザエージェントはその様なカテゴリを無視しなければならない。そしてその代わりに、スキーマ定義のリストにあるオリジナルのカテゴリ（またはカテゴリの集合）を使用しなければならない。むしろ、ユーザエージェントはユーザに、固定したデータ要素は非標準カテゴリクラスと一緒に使用されることを知らせてもよい。

5.5.2 可変カテゴリデータ要素/構造

基本データスキーマのデータ要素/構造が、すべてあらかじめ決められているカテゴリクラスに属するわけではない。中には状況に合わせて、カテゴリの範囲からの情報を含んでいることもある。そういった要素/構造は可変カテゴリデータ要素/構造という。（または短縮して"可変データ要素/構造"）P3P基本データスキーマの可変データ要素ほとんどは dynamic要素集合に組み込まれているが、固定したカテゴリデータ要素と混じっていたとしても、データの集合の中に表示することができる。

そういった要素および/または構造のスキーマ定義を作成する時、スキーマ作成者は明白なカテゴリ属性をリストしてはならない。そうしなければ、その要素/構造は固定されてしまう。例えば、"年"データ構造を指定する時｛これは状況によって様々なカテゴリ、（例えば生年月日を参照するためにクレジットカードの期限を使用する時など。）を取るのだが、｝以下のスキーマ定義を使用することができる：

<DATA-STRUCT name="date.ymd.year"
short-description="Year"/> 

この事によって、こういった可変カテゴリデータ構造を参照する新しいスキーマ拡張子は、その使用にあわせて、取り出した要素に特定のカテゴリを割り当てることができる。従って、例えば、電子商取引のスキーマ拡張子は以下の様にクレジットカードの期限を定義できる：

<DATA-STRUCT name="Card.ExpDate" structref="#date.ymd"
short-description="Card Expiration Date">
<CATEGORIES><purchase/></CATEGORIES> </DATA-STRUCT>

このような状況で、クレジットカードの期限終了日を指定するために使用する場合、可変カテゴリデータ構造日付は固定したカテゴリ"購入情報"に割り当てられる。

ユーザのプリファレンスはカテゴリ情報（この要素のあらゆる使用に関するプリファレンスを効果的に表している）を追加することなしに、そういった可変データをリストすることはできるが、サービスはいつも特別なポリシーの可変データ要素の使用に適用するカテゴリを明白に指定しなくてはならない。この情報はポリシーのリストの対応したDATA要素のカテゴリ要素として表示されなければならない。以下はその例である：

<POLICY ... >
...
<DATA ref="#dynamic.cookies"><CATEGORIES><uniqueid/></CATEGORIES></DATA>
...
</POLICY>

サービスがこのサイトでユーザを識別するために使用されることを宣言する場合（すなわちカテゴリユニークな識別子など）

サービスが複数のカテゴリにあるデータ要素を宣言したいと思う場合、対応するカテゴリを宣言するだけでよい。（上記の節に述べているように）：

<POLICY ... >
...
<DATA ref="#dynamic.cookies"><CATEGORIES><uniqueid/><preference/></CATEGORIES></DATA>
...
</POLICY>

上記の宣言を使用して、サービスはこのサイトでユーザを識別し、 そしてユーザのプリファレンスデータを格納するためにクッキーを使用することを知らせる。 P3Pの目的に関して、この情報が二つの別個のクッキーに格納されているのか一つのクッキーに格納されているのかの区別はないことに注意。

最後に、カテゴリは受け継ぐ事ができることに注意： フィールドが構築されれば、カテゴリは旧版を受け継ぐことができるが、あらかじめ定義されたカテゴリを有するフィールドでのみそれが可能。 従って、スキーマ作成者が作成した新しい要素に適切なカテゴリがすべて適用していることを保証する為に、スキーマ作成者に最大の努力して頂くことを提案する。

5.6 データ要素の使用

P3Pでは、Webサイトが収集するデータ型の表現方法に関して、様々な形に対応できるようにしている。

サイトは、dynamic.miscdata要素と適切なカテゴリを使用してデータを表現することができる。
サイトは、基本データスキーマに定義されているデータ要素を使用してデータを表現することができる。
サイトは、新規データスキーマに定義されているデータ要素を使用してデータを表現することができる。

これらの三つの方法を、一つのポリシー内部で組み合わせることができる。

dynamic.miscdata要素を使用することによって、サイトは各々のデータ要素を列挙することなしに、収集するデータを指定することができる。このことは、多くのデータを収集するサイトや、組織・団体の全体を一つのP3Pポリシーでカバーしたい巨大な組織・団体のサイトにとって非常に便利である。しかし、このアプローチによる不利な点は、ユーザエージェントは、サイトが参照するカテゴリに属すすべてのデータ要素を収集するかもしれないと仮定しなければならないということである。従って、例えば、あるサイトのプライバシーポリシーに"実社会における連絡先情報"カテゴリの dynamic.miscdataを収集すると掲げてあり、実際に収集される情報は、勤務先の住所のみだとする、それでもやはりユーザエージェントは、サイトは電話番号も収集するかもしれないと仮定するだろう。もし、サイトが電話番号や勤務先の住所以外の"実社会における連絡先情報"情報を収集しないことを明白にしたい場合、サイトは、user.business-info.contact.postal要素を収集することを明らかにするべきである。なお、ユーザエージェントは、自動フォーム入力機能を伴って開発されているので、収集するデータを列挙するサイトは、自動フォーム入力機能をよりよく統合することができると思われる。

新規スキーマを定義することによって、サイトは、基本データ集合の枠を超えて、収集するデータを正確に指定することができる。しかし、ユーザエージェントが新規スキーマ内に定義されている要素に精通していない場合、ユーザエージェントは、新規の要素に関しての最小限の情報だけを利用者に提供することができるだろう。ユーザエージェントが提供する情報は個々の要素のために指定されたカテゴリと表記名に基づくだろう。

サイトが一般的なデータ開示、または特定のデータ開示のどちらかを望んでいるかにかかわらず、 dynamicデータ集合に含まれる特定の要素を開示することには利点がある。例えば、dynamic.cookiesを開示することによって、サイトはクッキーの使用を示し、その使用目的を説明することができる。この情報に基づいて、利用者にクッキー制御のインターフェイスを提供するユーザエージェントの実装を奨励する。また、デフォルトではHTTP_REFERERヘッダを送信しないユーザエージェントは、 P3Pプライバシーポリシー内でdynamic.http.referer要素を検索し、ヘッダが利用者の許容可能な目的で使用される場合には、ヘッダを送信するかもしれない。

6. 付録

付録1: 参考文献（標準準拠）

[CHARMODEL]: M. Dürst, F. Yergeau (Eds.), "Character Model for the World Wide Web ," World Wide Web Consortium Working Draft. 29 November 1999.
[DOM2-Events]: T. Pixley (Ed.), "Document Object Model (DOM) Level 2 Events Specification," World Wide Web Consortium, Proposed Recommendation. 27 September 2000.
[HTTP1.0]: T. Berners-Lee, R. Fielding, H. Frystyk, "RFC1945 -- Hypertext Transfer Protocol -- HTTP/1.0," May 1996.
[HTTP1.1]: R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, "RFC2616 -- Hypertext Transfer Protocol -- HTTP/1.1," June 1999. [Updates RFC2068]
[KEY]: S. Bradner. "RFC2119-- Key words for use in RFCs to Indicate Requirement Levels." March 1997.
[P3P-HEADER]: R. Lotenberg, M. Marchiori, M. Nottingham (Eds.), " W3C Platform for Privacy Preferences 1.0 (P3P1.0) HTTP Header" (also available in HTML and XML formats), to be submitted to the IETF as Internet Draft.
[STATE]: Kristol, D., Montulli, L., "RFC2965 -- HTTP State Management Mechanism." October, 2000 [Obsoletes RFC2109]
[URI]: T. Berners-Lee, R. Fielding, and L. Masinter. "RFC 2396 -- Uniform Resource Identifiers (URI): Generic Syntax and Semantics." August 1998. [Updates RFC1738]
[UTF-8]: F. Yergeau. "RFC2279 -- UTF-8, a transformation format of ISO 10646." January 1998.
[XML]: T. Bray, J. Paoli, C. M. Sperberg-McQueen (Eds.). "Extensible Markup Language (XML) 1.0 Specification." World Wide Web Consortium, Recommendation. 10 February 1998.
[XML-Name]: T. Bray, D. Hollander, A. Layman (Eds.). "Namespaces in XML." World Wide Web Consortium, Recommendation. 14 January 1999.
[XML-Schema1]: H. Thompson, D. Beech, M. Maloney, and N. Mendelsohn (Eds.). "XML Schema Part 1: Structures" World Wide Web Consortium Working Draft. 22 September 2000.
[XML-Schema2]: P. Biron, A. Malhotra (Eds.). "XML Schema Part 2: datatypes" World Wide Web Consortium Working Draft. 22 September 2000.

付録2: 参考文献（標準非準拠）

[ABNF]: D. Crocker, P. Overel. "RFC2234 -- Augmented BNF for Syntax Specifications: ABNF," Internet Mail Consortium, Demon Internet Ltd., November 1997.
[APPEL]: M. Langheinrich (Ed.). "A P3P Preference Exchange Language (APPEL)" World Wide Web Consortium Working Draft.
[COOKIES]: "Persistent Client State -- HTTP Cookies," Preliminary Specification, Netscape, 1999.
[HTML]: D. Raggett, A. Le Hors, and I. Jacobs (Eds.). "HTML 4.01 Specification" World Wide Web Consortium
[ISO3166]: "ISO3166: Codes for The Representation of Names of Countries." International Organization for Standardization.
[ISO8601]: "ISO8601: Data elements and interchange formats -- Information interchange -- Representation of dates and times." International Organization for Standardization.
[RDF]: O. Lassila and R. Swick (Eds.). "Resource Description Framework (RDF) Model and Syntax Specification." World Wide Web Consortium, Recommendation. 22 February 1999.
[UNICODE]: Unicode Consortium. "The Unicode Standard"

付録3: P3P基本データスキーマ定義（標準準拠）

簡単な参照に関しては、P3P基本データスキーマに相当するデータスキーマは以下のものである。また、スキーマは次のURIにある。http://www.w3.org/TR/P3P/base

<DATASCHEMA xmlns="http://www.w3.org/2000/12/P3Pv1">
<!-- ********** Base Data Structures ********** -->

<!-- "date" Data Structure -->
<DATA-STRUCT name="date.ymd.year"
    short-description="Year"/>

<DATA-STRUCT name="date.ymd.month"
    short-description="Month"/>

<DATA-STRUCT name="date.ymd.day"
    short-description="Day"/>

<DATA-STRUCT name="date.hms.hour"
    short-description="Hour"/>

<DATA-STRUCT name="date.hms.minute"
    short-description="Minutes"/>

<DATA-STRUCT name="date.hms.second"
    short-description="Second"/>

<DATA-STRUCT name="date.fractionsecond"
    short-description="Fraction of Second"/>

<DATA-STRUCT name="date.timezone"
    short-description="Time Zone"/>

<!-- "personname" Data Structure -->
<DATA-STRUCT name="personname.prefix"
    short-description="Name Prefix">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="personname.given"
    short-description="Given Name (First Name)">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="personname.middle"
    short-description="Middle Name">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="personname.family"
    short-description="Family Name (Last Name)">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="personname.suffix"
    short-description="Name Suffix">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="personname.nickname"
    short-description="Nickname">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-STRUCT>

<!-- "certificate" Data Structure -->
<DATA-STRUCT name="certificate.key"
    short-description="Certificate key">
    <CATEGORIES><uniqueid/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="certificate.format"
    short-description="Certificate format">
    <CATEGORIES><uniqueid/></CATEGORIES>
</DATA-STRUCT>

<!-- "telephonenum" Data Structure -->
<DATA-STRUCT name="telephonenum.intcode"
    short-description="International Telephone Code">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="telephonenum.loccode"
    short-description="Local Telephone Area Code">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="telephonenum.number"
    short-description="Telephone Number">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="telephonenum.ext"
    short-description="Telephone Extension">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="telephonenum.comment"
    short-description="Telephone Optional Comments">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-STRUCT>

<!-- "postal" Data Structure -->
<DATA-STRUCT name="postal.name" struct-ref="#personname">
    <CATEGORIES><physical/><demographic/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="postal.street"
    short-description="Street Address">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="postal.city"
    short-description="City">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="postal.stateprov"
    short-description="State or Province">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="postal.postalcode"
    short-description="Postal Code">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="postal.organization"
    short-description="Organization Name">
    <CATEGORIES><physical/><demographic/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="postal.country"
    short-description="Country Name">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-STRUCT>

<!-- "telecom" Data Structure -->
<DATA-STRUCT name="telecom.telephone"
    short-description="Telephone Number"
    structref="#telephonenum">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="telecom.fax"
    short-description="Fax Number"
    structref="#telephonenum">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="telecom.mobile"
    short-description="Mobile Telephone Number"
    structref="#telephonenum">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="telecom.pager"
    short-description="Pager Number"
    structref="#telephonenum">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-STRUCT>

<!-- "online" Data Structure -->
<DATA-STRUCT name="online.email"
    short-description="Email Address">
    <CATEGORIES><online/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="online.uri"
    short-description="Home Page Address">
    <CATEGORIES><online/></CATEGORIES>
</DATA-STRUCT>

<!-- "contact" Data Structure -->
<DATA-STRUCT name="contact.postal"
    short-description="Postal Address Information"
    structref="#postal">
    <CATEGORIES><physical/><demographic/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="contact.telecom"
    short-description="Telecommunications Information"
    structref="#telecom">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="contact.online"
    short-description="Online Address Information"
    structref="#online">
    <CATEGORIES><online/></CATEGORIES>
</DATA-STRUCT>

<!-- "uri" Data Structure -->
<DATA-STRUCT name="uri.authority"
    short-description="URI authority"/>

<DATA-STRUCT name="uri.stem"
    short-description="URI stem"/>

<DATA-STRUCT name="uri.querystring"
    short-description="Query-string portion of URI"/>

<!-- "ipaddr" Data Structure -->
<DATA-STRUCT name="ipaddr.hostname"
    short-description="Complete host and domain name">
    <CATEGORIES><uniqueid/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="ipaddr.partialhostname"
    short-description="Partial hostname">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="ipaddr.fullip"
    short-description="Full IP address">
    <CATEGORIES><uniqueid/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="ipaddr.partialip"
    short-description="Partial IP address">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-STRUCT>

<!-- "loginfo" Data Structure -->
<DATA-STRUCT name="loginfo.uri"
    short-description="URI of requested resource"
    structref="#uri">
    <CATEGORIES><navigation/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="loginfo.timestamp"
    short-description="Request timestamp"
    structref="#date">
    <CATEGORIES><navigation/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="loginfo.clientip"
    short-description="Client's IP address or hostname"
    structref="#ipaddr">
    <CATEGORIES><computer/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="loginfo.other.httpmethod"
    short-description="HTTP request method">
    <CATEGORIES><navigation/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="loginfo.other.bytes"
    short-description="Data bytes in response">
    <CATEGORIES><navigation/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="loginfo.other.statuscode"
    short-description="Response status code">
    <CATEGORIES><navigation/></CATEGORIES>
</DATA-STRUCT>

<!-- "httpinfo" Data Structure -->
<DATA-STRUCT name="httpinfo.referer"
    short-description="Last URI requested by the user"
    structref="#uri">
    <CATEGORIES><navigation/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="httpinfo.useragent"
    short-description="User agent information">
    <CATEGORIES><computer/></CATEGORIES>
</DATA-STRUCT>

<!-- ********** Base Data Schemas ********** -->

<!-- "dynamic" Data Schema -->
<DATA-DEF name="dynamic.clickstream"
    short-description="Click-stream information"
    structref="#loginfo">
    <CATEGORIES><navigation/><computer/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="dynamic.http"
    short-description="HTTP protocol information"
    structref="#httpinfo">
    <CATEGORIES><navigation/><computer/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="dynamic.clientevents" 
    short-description="User's interaction with a resource">
    <CATEGORIES><navigation/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="dynamic.cookies"
    short-description="Use of HTTP cookies"/>

<DATA-DEF name="dynamic.miscdata"
    short-description="Miscellaneous non-base data schema information"/>

<DATA-DEF name="dynamic.searchtext"
    short-description="Search terms">
    <CATEGORIES><interactive/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="dynamic.interactionrecord"
    short-description="Server stores the transaction history">
    <CATEGORIES><interactive/></CATEGORIES>
</DATA-DEF>

<!-- "user" Data Schema -->
<DATA-DEF name="user.name"
    short-description="User's Name"
    structref="#personname">
    <CATEGORIES><physical/><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="user.bdate"
    short-description="User's Birth Date"
    structref="#date">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="user.cert"
    short-description="User's Identity certificate"
    structref="#certificate">
    <CATEGORIES><uniqueid/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="user.gender"
    short-description="User's Gender">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="user.jobtitle"
    short-description="User's Job Title">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="user.home-info"
    short-description="User's Home Contact Information"
    structref="#contact">
    <CATEGORIES><physical/><online/><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="user.business-info"
    short-description="User's Business Contact Information"
    structref="#contact">
    <CATEGORIES><physical/><online/><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="user.employer"
    short-description="Name of User's Employer">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="user.department"
    short-description="Department or division of organization where user is employed">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-DEF>

<!-- "thirdparty" Data Schema -->
<DATA-DEF name="thirdparty.name"
    short-description="Third Party's Name"
    structref="#personname">
    <CATEGORIES><physical/><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="thirdparty.bdate"
    short-description="Third Party's Birth Date"
    structref="#date">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="thirdparty.cert"
    short-description="Third Party's Identity certificate"
    structref="#certificate">
    <CATEGORIES><uniqueid/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="thirdparty.gender"
    short-description="Third Party's Gender">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="thirdparty.jobtitle"
    short-description="Third Party's Job Title">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="thirdparty.home-info"
    short-description="Third Party's Home Contact Information"
    structref="#contact">
    <CATEGORIES><physical/><online/><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="thirdparty.business-info"
    short-description="Third Party's Business Contact Information"
    structref="#contact">
    <CATEGORIES><physical/><online/><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="thirdparty.employer"
    short-description="Name of Third Party's Employer">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="thirdparty.department"
    short-description="Department or division of organization where third party is employed">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-DEF>

<!-- "business" Data Schema -->
<DATA-DEF name="business.name"
    short-description="Organization Name">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="business.department"
    short-description="Department or division of organization">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="business.cert"
    short-description="Organization Identity certificate"
    structref="#certificate">
    <CATEGORIES><uniqueid/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="business.contact-info"
    short-description="Contact Information for the Organization"
    structref="#contact">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-DEF>

</DATASCHEMA>

付録4 : XMLスキーマ定義（標準準拠）

付録4には、P3Pポリシー参照ファイルとP3Pポリシー文書とP3Pデータスキーマの文書のためのXMLスキーマが含まれている。 XMLスキーマは、XML文書としてスキーマが作成された場合に使用される構造とデータ構造の値を有効にするために使用されるだろう。 P3Pポリシーとデータスキーマの文書はXML文書であるため、XMLスキーマと一致しなければならない。このXMLスキーマはXMLスキーマワーキングドラフト[XML-Schema1] [XML-Schema2]に基づいているが、このワーキングドラフトは予告なしに変更される可能性があることに注意されたい。このスキーマはURIhttp://www.w3.org/2000/12/P3Pv1.xsdの独立したファイルに表示されている。

<!DOCTYPE schema
  PUBLIC '-//W3C//DTD XMLSCHEMA 200010//EN'
  'http://www.w3.org/2000/10/XMLSchema.dtd' [
  <!ATTLIST schema 
    xmlns:p3p CDATA #FIXED 'http://www.w3.org/2000/12/P3Pv1'>
]>

<schema
  xmlns='http://www.w3.org/2000/10/XMLSchema'
  xmlns:p3p='http://www.w3.org/2000/12/P3Pv1'
  targetNamespace='http://www.w3.org/2000/12/P3Pv1'
  elementFormDefault='qualified'>

<!-- Basic P3P Data Type -->
 <simpleType name='yes_no'>
  <restriction base='string'>
   <enumeration value='yes'/>
   <enumeration value='no'/>
  </restriction>
 </simpleType>


<!-- *********** Policy Reference *********** -->
<!-- ************** META ************** -->
 <element name='META'>
  <complexType mixed='true'>
   <sequence minOccurs='0' maxOccurs='unbounded'>
    <element ref='p3p:POLICY-REFERENCES'/>
    <element ref='p3p:POLICIES' minOccurs='0'/>
   </sequence>
  </complexType>
 </element>

<!-- ******* POLICY-REFERENCES ******** -->
 <element name='POLICY-REFERENCES'>
  <complexType>
   <sequence>
    <element ref='p3p:EXPIRY' minOccurs='0'/>
    <element ref='p3p:POLICY-REF' minOccurs='0' maxOccurs='unbounded'/>
  </sequence>
  </complexType>
 </element>

 <element name='POLICY-REF'>
  <complexType>
   <sequence>
    <element name='INCLUDE' 
             minOccurs='0' maxOccurs='unbounded' type='uriReference'/>
    <element name='EXCLUDE' 
             minOccurs='0' maxOccurs='unbounded' type='uriReference'/>
    <element name='COOKIE-INCLUDE' 
             minOccurs='0' maxOccurs='unbounded' type='string'/>
    <element name='COOKIE-EXCLUDE'
             minOccurs='0' maxOccurs='unbounded' type='string'/>
    <element name='EMBEDDED-INCLUDE' 
             minOccurs='0' maxOccurs='unbounded' type='uriReference'/>
    <element name='EMBEDDED-EXCLUDE'
             minOccurs='0' maxOccurs='unbounded' type='uriReference'/>
    <element name='METHOD' 
             minOccurs='0' maxOccurs='unbounded' type='uriReference'/>
   </sequence>
   <attribute name='about' type='uriReference' use='required'/>
  </complexType>
 </element>

<!-- ************* EXPIRY ************* -->
 <element name='EXPIRY'>
  <complexType>
   <attribute name='max-age' type='nonNegativeInteger' use='optional'/>
   <attribute name='date' type='string' use='optional'/>
  </complexType>
 </element>

<!-- ************ POLICIES ************ -->
 <element name='POLICIES'>
  <complexType>
   <sequence>
    <element ref='p3p:POLICY' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
  </complexType>
 </element>


<!-- **************** Policy **************** -->
<!-- ************* POLICY ************* -->
 <element name='POLICY'>
  <complexType>
   <sequence>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
    <element ref='p3p:TEST'/>
    <element ref='p3p:EXPIRY' minOccurs='0'/>
    <element ref='p3p:DATASCHEMA' minOccurs='0'/>
    <element ref='p3p:ENTITY'/>
    <element ref='p3p:ACCESS'/>
    <element ref='p3p:DISPUTES-GROUP' minOccurs='0'/>
    <element ref='p3p:STATEMENT' minOccurs='0' maxOccurs='unbounded'/>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
   <attribute name='discuri' type='uriReference' use='required'/>
   <attribute name='opturi' type='uriReference' use='optional'/>
   <attribute name='name' type='ID' use='optional'/>
  </complexType>
 </element>

<!-- ************* TEST ************* -->
<element name='TEST' minOccurs='0'>

<!-- ************* ENTITY ************* -->
 <element name='ENTITY'>
  <complexType>
   <sequence>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
    <element ref='p3p:DATA-GROUP'/>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
  </complexType>
 </element>

<!-- ************* ACCESS ************* -->
 <element name='ACCESS'>
  <complexType>
   <sequence>
    <choice>
     <element name='nonident' type='p3p:access-value'/>
     <element name='ident-contact' type='p3p:access-value'/>
     <element name='other-ident' type='p3p:access-value'/>
     <element name='contact-and-other' type='p3p:access-value'/>
     <element name='all' type='p3p:access-value'/>
     <element name='none' type='p3p:access-value'/>
    </choice>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
  </complexType>
 </element>

 <complexType name='access-value'/>

<!-- ************ DISPUTES ************ -->
 <element name='DISPUTES-GROUP'>
  <complexType>
   <sequence>
    <element ref='p3p:DISPUTES' maxOccurs='unbounded'/>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
  </complexType>
 </element>

 <element name='DISPUTES'>
  <complexType>
   <sequence>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
    <choice minOccurs='0'>
     <sequence>
      <element ref='p3p:LONG-DESCRIPTION'/>
      <element ref='p3p:IMG' minOccurs='0'/>
      <element ref='p3p:REMEDIES' minOccurs='0'/>
      <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
     </sequence>
     <sequence>
      <element ref='p3p:IMG'/>
      <element ref='p3p:REMEDIES' minOccurs='0'/>
      <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
     </sequence>
     <sequence>
      <element ref='p3p:REMEDIES'/>
      <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
     </sequence>
    </choice>
   </sequence>
   <attribute name='resolution-type' use='required'>
    <simpleType>
     <restriction base='string'>
      <enumeration value='service'/>
      <enumeration value='independent'/>
      <enumeration value='court'/>
      <enumeration value='law'/>
     </restriction>
    </simpleType>
   </attribute>
   <attribute name='service' type='uriReference' use='required'/>
   <attribute name='verification' type='string' use='optional'/>
   <attribute name='short-description' type='string' use='optional'/>
  </complexType>
 </element>

<!-- ******** LONG-DESCRIPTION ******** -->
 <element name='LONG-DESCRIPTION'>
  <simpleType>
   <restriction base='string'/>
  </simpleType>
 </element>

<!-- ************** IMG *************** -->
 <element name='IMG'>
  <complexType>
   <attribute name='src' type='uriReference' use='required'/>
   <attribute name='width' type='nonNegativeInteger' use='optional'/>
   <attribute name='height' type='nonNegativeInteger' use='optional'/>
   <attribute name='alt' type='string' use='required'/>
  </complexType>
 </element>

<!-- ************ REMEDIES ************ -->
 <element name='REMEDIES'>
  <complexType>
   <sequence>
    <choice maxOccurs='unbounded'>
     <element name='correct' type='p3p:remedies-value'/>
     <element name='money' type='p3p:remedies-value'/>
     <element name='law' type='p3p:remedies-value'/>
    </choice>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
  </complexType>
 </element>

 <complexType name='remedies-value'/>

<!-- *********** STATEMENT ************ -->
 <element name='STATEMENT'>
  <complexType>
   <sequence>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
    <element name='CONSEQUENCE' minOccurs='0' type='string'/>
    <element name='NON-IDENTIFIABLE' minOccurs='0'>
     <complexType/>
    </element>
    <element ref='p3p:PURPOSE'/>
    <element ref='p3p:RECIPIENT'/>
    <element ref='p3p:RETENTION'/>
    <element ref='p3p:DATA-GROUP' maxOccurs='unbounded'/>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
  </complexType>
 </element>

 <complexType name='non-identifiable'/>

<!-- ************ PURPOSE ************* -->
 <element name='PURPOSE'>
  <complexType>
   <sequence>
    <choice maxOccurs='unbounded'>
     <element name='current' type='p3p:purpose-value'/>
     <element name='admin' type='p3p:purpose-value'/>
     <element name='develop' type='p3p:purpose-value'/>
     <element name='customization' type='p3p:purpose-value'/>
     <element name='tailoring' type='p3p:purpose-value'/>
     <element name='pseudo-analysis' type='p3p:purpose-value'/>
     <element name='pseudo-decision' type='p3p:purpose-value'/>
     <element name='individual-analysis' type='p3p:purpose-value'/>
     <element name='individual-decision' type='p3p:purpose-value'/>
     <element name='contact' type='p3p:purpose-value'/>
     <element name='historical' type='p3p:purpose-value'/>
     <element name='telemarketing' type='p3p:purpose-value'/>
     <element name='other-purpose'>
      <complexType mixed='true'>
       <attribute name='required' use='optional' type='p3p:required-value'/>
      </complexType>
     </element>
    </choice>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
  </complexType>
 </element>

 <simpleType name='required-value'>
  <restriction base='string'>
   <enumeration value='always'/>
   <enumeration value='opt-in'/>
   <enumeration value='opt-out'/>
  </restriction>
 </simpleType>

 <complexType name='purpose-value'>
  <attribute name='required' use='optional' type='p3p:required-value'/>
 </complexType>

<!-- *********** RECIPIENT ************ -->
 <element name='RECIPIENT'>
  <complexType>
   <sequence>
    <choice maxOccurs='unbounded'>
     <element name='ours'>
      <complexType>
       <sequence>
        <element ref='p3p:recipient-description' minOccurs='0' maxOccurs='unbounded'/>
       </sequence>
      </complexType>
     </element>
     <element name='same' type='p3p:recipient-value'/>
     <element name='other-recipient' type='p3p:recipient-value'/>
     <element name='delivery' type='p3p:recipient-value'/>
     <element name='public' type='p3p:recipient-value'/>
     <element name='unrelated' type='p3p:recipient-value'/>
    </choice>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
  </complexType>
 </element>

 <complexType name='recipient-value'>
  <sequence>
   <element ref='p3p:recipient-description' minOccurs='0' maxOccurs='unbounded'/>
  </sequence>
  <attribute name='required' use='optional' type='p3p:required-value'/>
 </complexType>

 <element name='recipient-description'>
  <complexType mixed='true'/>
 </element>

<!-- *********** RETENTION ************ -->
 <element name='RETENTION'>
  <complexType>
   <sequence>
    <choice>
     <element name='no-retention' type='p3p:retention-value'/>
     <element name='stated-purpose' type='p3p:retention-value'/>
     <element name='legal-requirement' type='p3p:retention-value'/>
     <element name='indefinitely' type='p3p:retention-value'/>
     <element name='business-practices' type='p3p:retention-value'/>
    </choice>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
  </complexType>
 </element>

 <complexType name='retention-value'/>

<!-- ************** DATA ************** -->
 <element name='DATA-GROUP'>
  <complexType>
   <sequence>
    <element ref='p3p:DATA' maxOccurs='unbounded'/>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
   <attribute name='base' type='uriReference' 
              use='default' value='http://www.w3.org/TR/P3P/base'/>
  </complexType>
 </element>

 <element name='DATA'>
  <complexType mixed='true'>
   <sequence minOccurs='0' maxOccurs='unbounded'>
    <element ref='p3p:CATEGORIES'/>
   </sequence>
   <attribute name='ref' type='uriReference' use='required'/>
   <attribute name='optional' use='default' value='no' type='p3p:yes_no'/>
  </complexType>
 </element>


<!-- ************** Data Schema ************* -->
<!-- *********** DATASCHEMA *********** -->
 <element name='DATASCHEMA'>
  <complexType>
   <choice minOccurs='0' maxOccurs='unbounded'>
    <element ref='p3p:DATA-DEF'/>
    <element ref='p3p:DATA-STRUCT'/>
    <element ref='p3p:EXTENSION'/>
   </choice>
  </complexType>
 </element>

 <element name='DATA-DEF' type='p3p:data-def'/>
 <element name='DATA-STRUCT' type='p3p:data-def'/>

 <complexType name='data-def'>
  <sequence>
   <element ref='p3p:CATEGORIES' minOccurs='0'/>
   <element ref='p3p:LONG-DESCRIPTION' minOccurs='0'/>
  </sequence>
  <attribute name='name' type='ID' use='required'/>
  <attribute name='structref' type='uriReference' use='optional'/>
  <attribute name='short-description' type='string' use='optional'/>
 </complexType>

<!-- *********** CATEGORIES *********** -->
 <element name='CATEGORIES'>
  <complexType>
   <choice maxOccurs='unbounded'>
    <element name='physical' type='p3p:categories-value'/>
    <element name='online' type='p3p:categories-value'/>
    <element name='uniqueid' type='p3p:categories-value'/>
    <element name='purchase' type='p3p:categories-value'/>
    <element name='financial' type='p3p:categories-value'/>
    <element name='computer' type='p3p:categories-value'/>
    <element name='navigation' type='p3p:categories-value'/>
    <element name='interactive' type='p3p:categories-value'/>
    <element name='demographic' type='p3p:categories-value'/>
    <element name='content' type='p3p:categories-value'/>
    <element name='state' type='p3p:categories-value'/>
    <element name='political' type='p3p:categories-value'/>
    <element name='health' type='p3p:categories-value'/>
    <element name='preference' type='p3p:categories-value'/>
    <element name='government' type='p3p:categories-value'/>
    <element name='other-category' type='string'/>
   </choice>
  </complexType>
 </element>

 <complexType name='categories-value'/>

<!-- *********** EXTENSION ************ -->
 <element name='EXTENSION'>
  <complexType mixed='true'>
   <choice minOccurs='0' maxOccurs='unbounded'>
    <any minOccurs='0' maxOccurs='unbounded' processContents='skip'/>
   </choice>
   <attribute name='optional' use='default' value='yes' type='p3p:yes_no'/>
  </complexType>
 </element>

</schema>

付録5 : XML DTD定義（標準準拠）

この付録では、ポリシー文書とデータスキーマのためのDTDを含む。 DTDはURIhttp://www.w3.org/2000/12/P3Pv1.dtd の独立したファイルに表示されている。

<!-- *************** Entities *************** -->
<!ENTITY % URI "CDATA">
<!ENTITY % NUMBER "CDATA">

<!-- *********** Policy Refernece *********** -->

<!-- ************** META ************** -->
<!ELEMENT META (#PCDATA | POLICY-REFERENCES | POLICIES)*>

<!-- ******* POLICY-REFERENCES ******** -->
<!ELEMENT POLICY-REFERENCES (EXPIRY?, POLICY-REF*)>
<!ELEMENT POLICY-REF (INCLUDE*,
    EXCLUDE*,
    EMBEDDED-INCLUDE*,
    EMBEDDED-EXCLUDE*,
    METHOD*)>
<!ATTLIST POLICY-REF 
    about %URI; #REQUIRED >

<!-- ************* EXPIRY ************* -->
<!ELEMENT EXPIRY EMPTY>
<!ATTLIST EXPIRY 
    max-age %NUMBER; #IMPLIED
    date    CDATA    #IMPLIED >

<!-- ************ POLICIES ************ -->
<!ELEMENT POLICIES (POLICY*)>

<!-- ***** INCLUDE/EXCLUDE/METHOD ***** -->
<!ELEMENT INCLUDE          (#PCDATA)>
<!ELEMENT EXCLUDE          (#PCDATA)>
<!ELEMENT COOKIE-INCLUDE   (#PCDATA)>
<!ELEMENT COOKIE-EXCLUDE   (#PCDATA)>
<!ELEMENT EMBEDDED-INCLUDE (#PCDATA)>
<!ELEMENT EMBEDDED-EXCLUDE (#PCDATA)>
<!ELEMENT METHOD           (#PCDATA)>

<!-- **************** Policy **************** -->

<!-- ************* POLICY ************* -->
<!ELEMENT POLICY (EXTENSION*,
    TEST,
    EXPIRY?,
    DATASCHEMA?,
    ENTITY,
    ACCESS,
    DISPUTES-GROUP?,
    STATEMENT*,
    EXTENSION*)>
<!ATTLIST POLICY
    discuri %URI; #REQUIRED
    opturi  %URI; #IMPLIED
    name    ID    #IMPLIED >

<!-- ******** TEST ******** -->
<!ELEMENT TEST (EMPTY)>

<!-- ************* ENTITY ************* -->
<!ELEMENT ENTITY (EXTENSION*, DATA-GROUP, EXTENSION*)>

<!-- ************* ACCESS ************* -->
<!ELEMENT ACCESS ((nonident
    | all
    | contact-and-other
    | ident-contact
    | other-ident
    | none),
    EXTENSION*)>
<!ELEMENT nonident          EMPTY>
<!ELEMENT all               EMPTY>
<!ELEMENT contact-and-other EMPTY>
<!ELEMENT ident-contact     EMPTY>
<!ELEMENT other-ident       EMPTY>
<!ELEMENT none              EMPTY>

<!-- ************ DISPUTES ************ -->
<!ELEMENT DISPUTES-GROUP (DISPUTES+, EXTENSION*)>
<!ELEMENT DISPUTES (EXTENSION*,
    ( (LONG-DESCRIPTION, IMG?, REMEDIES?, EXTENSION*)
      | (IMG, REMEDIES?, EXTENSION*)
      | (REMEDIES, EXTENSION*) )?)>
<!ATTLIST DISPUTES
    resolution-type   (service | independent | court | law) #REQUIRED
    service           %URI;                                 #REQUIRED
    verification      CDATA                                 #IMPLIED 
    short-description CDATA                                 #IMPLIED >

<!-- ******** LONG-DESCRIPTION ******** -->
<!ELEMENT LONG-DESCRIPTION (#PCDATA)>

<!-- ************** IMG *************** -->
<!ELEMENT IMG EMPTY>
<!ATTLIST IMG
    src    %URI;    #REQUIRED
    width  %NUMBER; #IMPLIED
    height %NUMBER; #IMPLIED
    alt    CDATA    #REQUIRED >

<!-- ************ REMEDIES ************ -->
<!ELEMENT REMEDIES ((correct | money | law)+, EXTENSION*)>
<!ELEMENT correct EMPTY>
<!ELEMENT money   EMPTY>
<!ELEMENT law     EMPTY>

<!-- *********** STATEMENT ************ -->
<!ELEMENT STATEMENT (EXTENSION*,
    NON-IDENTIFIABLE?,
    CONSEQUENCE?,
    PURPOSE,
    RECIPIENT,
    RETENTION,
    DATA-GROUP+,
    EXTENSION*)>

<!-- ********** CONSEQUENCE *********** -->
<!ELEMENT CONSEQUENCE (#PCDATA)>

<!-- ******** NON-IDENTIFIABLE ******** -->
<!ELEMENT NON-IDENTIFIABLE (EMPTY)>

<!-- ************ PURPOSE ************* -->
<!ELEMENT PURPOSE ((current
    | admin
    | develop
    | customization
    | tailoring
    | pseudo-analysis
    | pseudo-decision
    | individual-analysis
    | individual-decision
    | contact
    | historical
    | telemarketing
    | other-purpose)+,
    EXTENSION*)>

<!ENTITY % pur_att
         "required (always | opt-in | opt-out) #IMPLIED">
<!ELEMENT current             EMPTY>
<!ATTLIST current             %pur_att;>
<!ELEMENT admin               EMPTY>
<!ATTLIST admin               %pur_att;>
<!ELEMENT develop             EMPTY>
<!ATTLIST develop             %pur_att;>
<!ELEMENT customization       EMPTY>
<!ATTLIST customization       %pur_att;>
<!ELEMENT tailoring           EMPTY>
<!ATTLIST tailoring           %pur_att;>
<!ELEMENT pseudo-analysis     EMPTY>
<!ATTLIST pseudo-analysis     %pur_att;>
<!ELEMENT pseudo-decision     EMPTY>
<!ATTLIST pseudo-decition     %pur_att;>
<!ELEMENT individual-analysis EMPTY>
<!ATTLIST individual-analysis %pur_att;>
<!ELEMENT individual-decision EMPTY>
<!ATTLIST individual-decision %pur_att;>
<!ELEMENT contact             EMPTY>
<!ATTLIST contact             %pur_att;>
<!ELEMENT profiling           EMPTY>
<!ATTLIST profiling           %pur_att;>
<!ELEMENT historical          EMPTY>
<!ATTLIST historical          %pur_att;>
<!ELEMENT telemarketing       EMPTY>
<!ATTLIST telemarketing       %pur_att;>
<!ELEMENT other-purpose       (#PCDATA)>
<!ATTLIST other-purpose       %pur_att;>

<!-- *********** RECIPIENT ************ -->
<!ELEMENT RECIPIENT ((ours
    | same
    | other-recipient
    | delivery
    | public
    | unrelated)+,
    EXTENSION*)>
<!ELEMENT ours                  (recipient-description*)>
<!ELEMENT same                  (recipient-description*)>
<!ATTLIST same                  %pur_att;>
<!ELEMENT other-recipient       (recipient-description*)>
<!ATTLIST other-recipient       %pur_att;>
<!ELEMENT delivery              (recipient-description*)>
<!ATTLIST delivery              %pur_att;>
<!ELEMENT public                (recipient-description*)>
<!ATTLIST public                %pur_att;>
<!ELEMENT unrelated             (recipient-description*)>
<!ATTLIST unrelated             %pur_att;>
<!ELEMENT recipient-description (#PCDATA)>

<!-- *********** RETENTION ************ -->
<!ELEMENT RETENTION ((no-retention
    | stated-purpose
    | legal-requirement
    | indefinitely
    | business-practices),
    EXTENSION*)>
<!ELEMENT no-retention       EMPTY>
<!ELEMENT stated-purpose     EMPTY>
<!ELEMENT legal-requirement  EMPTY>
<!ELEMENT indefinitely       EMPTY>
<!ELEMENT business-practices EMPTY>

<!-- ************** DATA ************** -->
<!ELEMENT DATA-GROUP (DATA+, EXTENSION*)>
<!ATTLIST DATA-GROUP
    base     %URI;      "http://www.w3.org/TR/P3P/base" >
<!ELEMENT DATA (#PCDATA | CATEGORIES)*>
<!ATTLIST DATA
    ref      %URI;      #REQUIRED
    optional (yes | no) "no" >


<!-- *********** DATA SCHEMA *********** -->
<!ELEMENT DATASCHEMA (DATA-DEF | DATA-STRUCT | EXTENSION)*>

<!ELEMENT DATA-DEF    (CATEGORIES?, LONG-DESCRIPTION?)>
<!ATTLIST DATA-DEF
    name              ID    #REQUIRED
    structref         %URI; #IMPLIED
    short-description CDATA #IMPLIED  >

<!ELEMENT DATA-STRUCT (CATEGORIES?, LONG-DESCRIPTION?)>
<!ATTLIST DATA-STRUCT
    name              ID    #REQUIRED
    structref         %URI; #IMPLIED
    short-description CDATA #IMPLIED  >

<!-- *********** CATEGORIES *********** -->
<!ELEMENT CATEGORIES (physical
  | online
  | uniqueid
  | purchase
  | financial
  | computer
  | navigation
  | interactive
  | demographic
  | content
  | state
  | political
  | health
  | preference
  | government
  | other-category)+>
<!ELEMENT physical    EMPTY>
<!ELEMENT online      EMPTY>
<!ELEMENT uniqueid    EMPTY>
<!ELEMENT purchase    EMPTY>
<!ELEMENT financial   EMPTY>
<!ELEMENT computer    EMPTY>
<!ELEMENT navigation  EMPTY>
<!ELEMENT interactive EMPTY>
<!ELEMENT demographic EMPTY>
<!ELEMENT content     EMPTY>
<!ELEMENT state       EMPTY>
<!ELEMENT political   EMPTY>
<!ELEMENT health      EMPTY>
<!ELEMENT preference  EMPTY>
<!ELEMENT government  EMPTY>
<!ELEMENT other       EMPTY>

<!-- *********** EXTENSION ************ -->
<!ELEMENT EXTENSION (#PCDATA)>
<!ATTLIST EXTENSION
    optional (yes | no) "yes" >

付録6 : ABNF表記法（標準非準拠）

この仕様書での正式なP3P文法は、[ABNF]をわずかに修正したものを使用して作成されている。以下はABNFの簡単な説明である。

name = (elements): <name> は規則名で、<elements> は複数の規則名または、以下の数式によって得られた結果である。規則名は大文字/小文字を区別しない。
(element1 element2): 括弧によって囲まれた要素は一つの要素として扱われるが、括弧内の要素は厳密に順序付けられる。
<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 または 1要素を意味する)
"string" or 'string': ""内に与えられた文字列を意味する。

使用されているその他の表記法は:

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

付録7 : P3Pガイドライン (標準非準拠)

本付録はP3Pの開発の意図を説明し、P3P技術の責任ある使用に関するガイドラインを推奨するものである。前バージョンはW3Cノートの中で "P3P Guiding Principles（P3Pガイドライン）"として公表されている。

「Platform for Privacy Preferences Project（プライバシー情報の取り扱いに対する個人のプリファレンス（選好）を支持する技術基盤（P3P））」は柔軟性をもち、多様な利用者のプリファレンス、政策、サービス提供者のポリシー、およびアプリケーションを支援するものとして設計された。 P3Pのこの柔軟性は、設計者たちが想い描かなかったような様々な革新的方法においてP3Pを使用する機会を提供するものである。 P3Pガイドラインは、巻末に記載したP3Pワーキンググループのメンバーの意図を表明する目的で、また、Web上での利用者のプライバシーと信用・信頼を最大化するためにP3Pを最も効率的に用いる方法を提案する目的で作成された。我々の柔軟性の目標に適うように、本文書はいかなる組織に対しても要求を課すことはない。むしろ、本文書は1)P3P設計者の意図と整合性を保つために何をなすべきであるか、および2)P3P実装とWebサービスにおける利用者の信用を最大化するにはどうしたらよいかについての推奨を行う。 P3PはWeb上のプライバシーを守ることの手助けをする目的があった。我々は、この目的を達成するためにこの指針を採用する組織や個人、政策決定者、企業を奨励する。

情報プライバシー

P3Pは、サービス提供者が自らの情報プラクティスを公開することと、個人が自分の個人情報の収集と使用に関して情報提供を受けた上での決定を行うことを可能にすることによって、 Web上でのプライバシーと信用を向上させるために設計された。 P3Pユーザエージェントは、個人情報の収集と使用に関してサービス提供者と合意に達するために、個人に代わって処理を行う。すべての組織がこのような合意を尊重するという相互理解の上に信用は得られる。

サービス提供者は、関連する法律やデータ保護・プライバシー原則を自らの情報プラクティスに適用することによって信用を維持し、プライバシーを保護するべきである。以下に、P3Pの開発にあたって参考にした、またP3Pを使用する組織にとって有用であろうプライバシー原則とガイドラインのリストを挙げる:

さらに、サービス提供者とP3P実装者は、子供のプライバシーをめぐる特別な懸念について理解し、それに対処するべきである。

通知とコミュニケーション

サービス提供者は自らの情報プラクティスについて、適切なタイミングで実効のある通知を提供しなければならない。また、ユーザエージェントは利用者がそれらの通知にアクセスし、それらに基づいて意思決定を行うための効果的なツールを提供すべきである。

サービス提供者は以下をすべきである：

データの収集と使用に関して明示的にコミュニケーションし、個人情報が収集される目的と個人情報が共有される範囲とを特定すること。
Webでのデータの送受信を通して収集しようとするすべての情報に関して、P3Pプライバシーポリシーを使用してコミュニケーションすること。
明確で、人間が読むことのできるプライバシーポリシーを目立つ所に掲示すること。

ユーザエージェントは以下をすべきである：

サービス提供者の情報プラクティスを利用者に表示するためのメカニズムを提供すること。
ユーザエージェントがこれから送信しようとする個人情報に関して容易にプレビューし、それに対して同意したり拒否したりできるような選択権を利用者に提供すること。
利用者の同意なしにサービス提供者に個人情報を送信するようにデフォルト設定しないこと。
ユーザエージェントによって提供されるプライバシー関連のオプションについて、利用者に情報提供すること。

選択とコントロール

利用者は個人情報の収集、使用および開示に関して意味ある選択を行う能力を与えられるべきである。利用者は自らの個人情報に対するコントロール権を保持し、個人情報を提供する際の条件について決定すべきである。

サービス提供者は以下をすべきである：

利用者が望むレベルのサービスを遂行するのに必要な個人情報への要求を制限すること。このことは利用者のフラストレーションを低減し、信頼を増すことになるだろう。また、サービス提供者と匿名や偽名の関係、また、カスタマイズされたり、パーソナライズされたりした関係を持とうとしている利用者を含む、沢山の利用者と関係を持つことを可能にするだろう。
個人情報の収集と使用に先立って、インフォームド・コンセントを得ること。
個人情報をレビューしたり、適当な場合にはそれを修正したりできるか否かの情報を提供すること。

ユーザエージェントは以下をすべきである：

利用者が自らのプリファレンスをカスタマイズできるように、設定ツールを含むこと。
利用者が信頼できる組織からP3Pのプリファレンスをインポートし、カスタマイズできるようにすること。
中立的な方法で、またはプライバシー保護寄りの方法で、利用者に設定のオプションを提示すること。
インストールや設定過程の一部分として個人情報を登録するよう利用者に要求することなく、使用できること。

公正さと完全性

サービス提供者は利用者と利用者の個人情報を公正さと完全性をもって取り扱うべきである。これは、プライバシーを保護し、信頼を増すためには不可欠なことである。

サービス提供者は以下をすべきである：

明確かつ曖昧でない方法で、自らの情報プラクティスを正確に表示すること。決して、利用者を誤解させることを意図した表示を行ってはならない。
宣言した目的でのみ情報を使用し、必要な期間のみそれを保持すること。
情報が正確で完全で最新のものであることを保証すること。
責任の所在および苦情処理手段を公開すること。
情報が収集されたら、ユーザが新しいポリシーに対してインフォームド・コンセントが与えない限り、情報が保持されている期間はこのポリシーに基づいて情報が有効であるように取り扱いを続けること。

ユーザエージェントは以下をすべきである：

利用者が規定したプリファレンスに従って、利用者の代わりに機能すること。
サービス提供者のプラクティスを正確に表現すること。

セキュリティ

P3P自体はセキュリティメカニズムを含んでいないが、セキュリティツールと連携して使用されるように意図されている。利用者の個人情報は常に、その情報のセンシビティに合わせて適切なセキュリティ安全装置をもって保護されるべきである。

サービス提供者は以下をすべきである：

ユーザエージェントが収集した個人情報を保護するメカニズムを提供すること。
データのセキュアな伝送のために、適切で信頼されたプロトコルを用いること。

ユーザエージェントは以下をすべきである：

利用者はエージェントが保守しているデータレポジトリに登録した個人情報を保護するためのメカニズムを提供すること。
データのセキュアな伝送のために、適切で信頼されたプロトコルを用いること。
セキュアでない伝送メカニズムが使用されている場合には、利用者に警告すること。

付録8 : ワーキンググループ貢献者 (標準非準拠)

本仕様書はP3P仕様書ワーキンググループによって作成された。 P3P仕様書ワーキンググループの参加メンバーは以下の通りである： Lorrie Cranor (AT&T, 議長), Mark Ackerman (University of California, Irvine), Margareta Björksten (Nokia), Eric Brunner (Engage), Joe Coco (Microsoft), Rajeev Dujari (Microsoft), Matthias Enzmann (GMD), Patrick Feng (RPI), Dan Jaye (Engage), Marit Koehntopp (Privacy Commission of Land Schleswig-Holstein, Germany), Yuichi Koike (NEC/W3C), Yusuke Koizumi (ENC), Daniel LaLiberte (Crystaliz), Marc Langheinrich (NEC/ETH Zurich), Daniel Lim (PrivacyBank), Ran Lotenberg (IDcide), Massimo Marchiori (W3C/MIT/UNIVE), Christine McKenna (Phone.com, Inc.), Mark Nottingham (Akamai), Paul Perry (Microsoft), Jules Polonetsky (Doubleclick), Martin Presler-Marshall (IBM), Joel Reidenberg (Fordham Law School), Dave Remy (Geotrust), Ari Schwartz (CDT), Noboru Shimizu (ENC), Rob Smibert (Jotter Technologies Inc.), Mark Uhrmacher (Doubleclick), Danny Weitzner (W3C), Michael Wallent (Microsoft), Rigo Wenning (W3C), Betty Whitaker (NCR), Kevin Yen (Netscape), Sam Yen (Citigroup), Alan Zausner (American Express).

P3P仕様書ワーキンググループは、本仕様書の多くの部分を以前のP3Pワーキンググループから受け継いでいる。 P3P仕様書ワーキンググループはこれらのグループのメンバーの貢献に対し謝意を表したい（付記した所属団体は、メンバーがワーキンググループに参加していた当時の所属団体である）。

P3Pインプリメンテーション・ディプロイメントワーキンググループの参加メンバーは以下の通りである： Rolf Nelson (W3C, 議長), Marc Langheinrich (NEC/ETH Zurich, 議長), Mark Ackerman (University of California, Irvine), Rob Barrett (IBM), Joe Coco (Microsoft), Lorrie Cranor (AT&T), Massimo Marchiori (W3C/MIT), Gabe Montero (IBM), Stephen Morse (Netscape), Paul Perry (Microsoft), Ari Schwartz (CDT), Gabriel Speyer (Citibank), Betty Whitaker (NCR).

P3P構文ワーキンググループの参加メンバーは以下の通りである：Steve Lucas (Matchlogic, 議長), Lorrie Cranor (AT&T), Melissa Dunn (Microsoft), Daniel Jaye (Engage Technologies), Massimo Marchiori (W3C/MIT), Maclen Marvit (Narrowline), Max Metral (Firefly), Paul Perry (Firefly), Martin Presler-Marshall (IBM), Drummond Reed (Intermind), Joseph Reagle (W3C).

P3Pボキャブラリハーモナイゼーションワーキンググループの参加メンバーは以下の通りである： Joseph Reagle (W3C, 議長), Liz Blumenfeld (America Online), Ann Cavoukian (Information and Privacy Commission/Ontario), Scott Chalfant (Matchlogic), Lorrie Cranor (AT&T), Jim Crowe (Direct Marketing Association), Josef Dietl (W3C), David Duncan (Information and Privacy Commission/Ontario), Melissa Dunn (Microsoft), Patricica Faley (Direct Marketing Association), Marit Köhntopp (Privacy Commissioner of Schleswig-Holstein, Germany), Tony Lam (Hong Kong Privacy Commissioner's Office), Tara Lemmey (Narrowline), Jill Lesser (America Online), Steve Lucas (Matchlogic), Deirdre Mulligan (Center for Democracy and Technology), Nick Platten (Data Protection Consultant, formerly of DG XV, European Commission), Ari Schwartz (Center for Democracy and Technology), Jonathan Stark (TRUSTe).

P3Pプロトコル・データ送信ワーキンググループの参加メンバーは以下の通りである：Yves Leroux (Digital, 議長), Lorrie Cranor (AT&T), Philip DesAutels (Matchlogic), Melissa Dunn (Microsoft), Peter Heymann (Intermind), Tatsuo Itabashi (Sony), Dan Jaye (Engage), Steve Lucas (Matchlogic), Jim Miller (W3C), Michael Myers (VeriSign), Paul Perry (FireFly), Martin Presler-Marshall (IBM), Joseph Reagle (W3C), Drummond Reed (Intermind), Craig Vodnik (Pencom Web Worlds).

P3Pボキャブラリワーキンググループの参加メンバーは以下の通りである：Lorrie Cranor (AT&T, 議長), Mark Ackerman (W3C), Philip DesAutels (W3C), Melissa Dunn (Microsoft), Joseph Reagle (W3C), Upendra Shardanand (Firefly).

P3Pアーキテクチャワーキンググループの参加メンバーは以下の通りである：Martin Presler-Marshall (IBM, 議長), Mark Ackerman (W3C), Lorrie Cranor (AT&T), Philip DesAutels (W3C), Melissa Dunn (Microsoft), Joseph Reagle (W3C).

最後に、付録7はW3Cノートの中の "P3P Guiding Principles" を元に作成したものである。その署名者は以下の通りである： Azer Bestavros (Bowne Internet Solutions), Ann Cavoukian (Information and Privacy Commission Ontario Canada), Lorrie Faith Cranor (AT&T Labs-Research), Josef Dietl (W3C), Daniel Jaye (Engage Technologies), Marit Köhntopp (Land Schleswig-Holstein), Tara Lemmey (Narrowline; TrustE), Steven Lucas (MatchLogic), Massimo Marchiori (W3C/MIT), Dave Marvit (Fujitsu Labs), Maclen Marvit (Narrowline Inc.), Yossi Matias (Tel Aviv University), James S. Miller (MIT), Deirdre Mulligan (Center for Democracy and Technology), Joseph Reagle (W3C), Drummond Reed (Intermind), Lawrence C. Stewart (Open Market, Inc.).

18 October Last Call Specificationからの改訂履歴

文体を改善し、説明を追加し、誤字を訂正した。
必須のAPPELサポートを削除し、包括的なユーザプリファレンスのインポート/エクスポートに関する必要事項をそのかわりに掲載した。
otherカテゴリはother-categoryとした。
EMBEDDED-INCLUDE、EMBEDDED-EXCLUDE、COOKIE-INCLUDE、そしてCOOKIE-EXCLUDEのサポートは推奨の意味の（すべきである）から必須を意味する（しなければならない）に変更した。
contact_and_other、ident_contact、 other_ident、opt_in、opt_outを contact-and-other、ident-contact、 other-ident、opt-in、opt-outとした。
新しいシナリオを2.5章に追加した。
新しく4章を簡潔なポリシーとした。
新しくTEST要素を追加した。

[1]	p3p-header	=	`P3P: ` p3p-header-field *(`,` p3p-header-field)
[2]	p3p-header-field	=	policy-ref-field \| compact-policy-field \| extension-field
[3]	policy-ref-field	=	`policyref="` URI `"`
[4]	extension-field	=	token [`=` (token \| quoted-string) ]
ここで、`URI`はRFC 2396[URI]によって定義され、 `token`と`quoted-string`は[HTTP1.1]によって定義されている。

[5]	p3p-link-tag	=	`<link rel="P3Pv1" href="` URI `">`
ここで、`URI`はRFC 2396 [URI]に従って定義されている。

[6]	prf	=	`<META xmlns="http://www.w3.org/2000/12/P3Pv1">` policyrefs [policies] PCDATA "</META>"
[7]	policyrefs	=	"<POLICY-REFERENCES>" [expiry] *policyref "</POLICY-REFERENCES>"
ここで、`PCDATA`は[XML]で定義されている。

[8]	expiry	=	"<EXPIRY" (absdate\|reldate) "/>"
[9]	absdate	=	`date="` HTTP-date `"`
[10]	reldate	=	`max-age="` delta-seconds `"`
ここで, HTTP-dateは[HTTP1.1]の3.3.1節で定義されており、delta-seconds は[HTTP1.1]の3.3.2節で定義されている。

[12]	include	=	"<INCLUDE>" relativeURI "</INCLUDE>"
[13]	exclude	=	"<EXCLUDE>" relativeURI "</EXCLUDE>"
ここで、`相対URI`はsection 2.3.2.1.2節で定義されているように、'`*`' 文字がワイルドカードとして取り扱われている事と共にRFC 2396 [URI]に従って定義されている。

[16]	embedded-include	=	"<EMBEDDED-INCLUDE>" absoluteURI "</EMBEDDED-INCLUDE>"
[17]	embedded-exclude	=	"<EMBEDDED-EXCLUDE>" absoluteURI "</EMBEDDED-EXCLUDE>"
ここで、`相対URI`はsection 2.3.2.1.2節で定義されているように、'`*`' 文字がワイルドカードとして取り扱われている事と共にRFC 2396 [URI]に従って定義されている。

[18]	method-element	=	`<METHOD>` Method `</METHOD>`
ここで、`Method`は [HTTP1.1]の5.1.1節に定義されている

[25]	disputes-group	=	"<DISPUTES-GROUP>" 1dispute extension "</DISPUTES-GROUP>"
[26]	dispute	=	"<DISPUTES" " resolution-type=" '"'("service"\|"independent"\|"court"\|"law")'"' " service=" quoted-URI [" verification=" quotedstring] [" short-description=" quotedstring] ">" extension [longdescription] [image] [remedies] extension "</DISPUTES>"
[27]	longdescription	=	<LONG-DESCRIPTION> PCDATA </LONG-DESCRIPTION>
[28]	image	=	"<IMG src=" quoted-URI [" width=" `"` number `"`] [" height=" `"` number `"`] " alt=" quotedstring "/>"
[29]	quotedstring	=	`"` string `"`
ここで文字列は連続する文字（" や & で回避された）で定義される。`PCDATA`は[XML]で定義されている。

`date`	カテゴリ	構造	簡易表記名
ymd.year	(可変カテゴリ)	構造化されていない	年
ymd.month	(可変カテゴリ)	構造化されていない	月
ymd.day	(可変カテゴリ)	構造化されていない	日
hms.hour	(可変カテゴリ)	構造化されていない	時
hms.minute	(可変カテゴリ)	構造化されていない	分
hms.second	(可変カテゴリ)	構造化されていない	秒
fractionsecond	(可変カテゴリ)	構造化されていない	秒（小数点以下）
timezone	(カテゴリ)	構造化されていない	タイムゾーン

`personname`	カテゴリ	構造	簡易表記名
prefix	人口統計学的・社会経済学的データ	構造化されていない	敬称
given	実社会における連絡先情報	構造化されていない	名(Given Name)
family	実社会における連絡先情報	構造化されていない	姓
middle	実社会における連絡先情報	構造化されていない	ミドルネーム
suffix	人口統計学的・社会経済学的データ	構造化されていない	Name Suffix
nickname	人口統計学的・社会経済学的データ	構造化されていない	愛称

`certificate`	カテゴリ	構造	簡易表記名
key	ユニークな識別子	構造化されていない	認証鍵
format	ユニークな識別子	構造化されていない	認証フォーマット

`telephonenum`	カテゴリ	構造	簡易表記名
intcode	実社会における連絡先情報	構造化されていない	国番号
loccode	実社会における連絡先情報	構造化されていない	局番
number	実社会における連絡先情報	構造化されていない	電話番号
ext	実社会における連絡先情報	構造化されていない	内線
comment	実社会における連絡先情報	構造化されていない	注釈

`contact`	カテゴリ	構造	簡易表記名
postal	実社会における連絡先情報, 人口統計学的・社会経済学的データ	postal	郵便情報
telecom	実社会における連絡先情報	telecom	テレコミュニケーション情報
online	オンライン連絡先情報	online	オンラインアドレス情報

`postal`	カテゴリ	構造	簡易表記名
name	実社会における連絡先情報, 人口統計学的・社会経済学的データ	personname	氏名
street	実社会における連絡先情報	構造化されていない	町・番地
city	実社会における連絡先情報	構造化されていない	市・区
stateprov	実社会における連絡先情報	構造化されていない	都道府県
postalcode	人口統計学的・社会経済学的データ	構造化されていない	郵便番号
country	人口統計学的・社会経済学的データ	構造化されていない	国
organization	実社会における連絡先情報, 人口統計学的・社会経済学的データ	構造化されていない	団体・組織名

`telecom`	カテゴリ	構造	簡易表記名
telephone	実社会における連絡先情報	telephonenum	電話番号
fax	実社会における連絡先情報	telephonenum	ファックス番号
mobile	実社会における連絡先情報	telephonenum	携帯電話番号
pager	実社会における連絡先情報	telephonenum	ポケットベル番号

`online`	カテゴリ	構造	簡易表記名
email	Online Contact Information	構造化されていない	電子メールアドレス
uri	Online Contact Information	構造化されていない	ホームページアドレス

`ipaddr`	カテゴリ	構造	簡易表記名
hostname	Unique Identifiers	構造化されていない	完全なホストとドメイン名
partialhostname	Demographic	構造化されていない	ホスト名の一部
fullip	Unique Identifiers	構造化されていない	全IPアドレス
partialip	Demographic	構造化されていない	IPアドレスの一部

`loginfo`	カテゴリ	構造	簡易表記名
uri	ナビゲーションとクリックストリームデータ	uri	要求されたリソースのURI
timestamp	ナビゲーションとクリックストリームデータ	date	要求とタイムスタンプ
clientip	コンピュータ情報	ipaddr	クライアントのIP アドレスまたはホスト名
other.httpmethod	ナビゲーションとクリックストリームデータ	構造化されていない	HTTP要求方式
other.bytes	ナビゲーションとクリックストリームデータ	構造化されていない	レスポンスのデータバイト
other.statuscode	ナビゲーションとクリックストリームデータ	構造化されていない	レスポンスステータスコード

`httpinfo`	カテゴリ	構造	簡易表記名
referer	ナビゲーションとクリックストリームデータ	uri	ユーザが要求した最後のURI
useragent	コンピュータ情報	構造化されていない	ユーザエージェント情報

`user`	カテゴリ	構造	簡易表記名
name	実社会における連絡先情報、人口統計学的・社会経済学的データ	personname	利用者名
bdate	人口統計学的・社会経済学的データ	date	利用者の誕生日
cert	ユニークな識別子	certificate	利用者の身元証明
gender	人口統計学的・社会経済学的データ	構造化されていない	利用者の性別（男性または女性）
employer	人口統計学的・社会経済学的データ	構造化されていない	利用者の雇主
department	人口統計学的・社会経済学的データ	構造化されていない	利用者が勤務している組織の部門または課
jobtitle	人口統計学的・社会経済学的データ	構造化されていない	利用者の勤務先での肩書き
home-info	実社会における連絡先情報、オンライン連絡先情報、人口統計学的・社会経済学的データ	contact	利用者の自宅へのコンタクト情報
business-info	実社会における連絡先情報、オンライン連絡先情報、人口統計学的・社会経済学的データ	contact	利用者の勤務先へのコンタクト情報

Platform for Privacy Preferences 1.0 (P3P1.0) 仕様書

W3C勧告候補 2000年12月15日

要旨

本文書の位置付け

目次

1. 序論

1.1 P3P1.0仕様書

1.1.3 P3Pポリシー

1.1.4 P3Pユーザエージェント

1.1.5 サーバ上でのP3Pの実装

1.1.6 P3Pの将来バージョン

1.2 本仕様書について

1.3 専門用語

2.3.4 フォームおよび関連するメカニズム

3.1.2 ポリシーのXMLコード化

3.2.1 POLICIES 要素

3.3.1 STATEMENT 要素

3.3.2 CONSEQUENCE 要素

3.3.4 PURPOSE 要素

3.3.5 RECIPIENT 要素

3.3.6 RETENTION 要素

5.3 基本データ型

5.3.1 日付

5.3.2 名前

5.3.3 認証

5.3.4 電話

5.3.5 連絡先情報

5.3.5.1 郵便

5.3.5.2 テレコミュニケーション

5.3.5.3 オンライン

5.3.6 アクセスログとインターネットアドレス

5.3.6.1 URI

5.3.6.2 ipaddr

5.3.6.4 その他HTTPプロトコル情報

5.4 基本データスキーマ

5.4.1 個人データ

5.4.2 第三機関データ

5.4.3 ビジネスデータ

5.4.4 動的データ

5.5.1 固定カテゴリデータ要素/構造

5.5.2 可変カテゴリデータ要素/構造

5.6 データ要素の使用

6. 付録

付録1: 参考文献 （標準準拠）

付録2: 参考文献 （標準非準拠）

付録6 : ABNF表記法 （標準非準拠）

付録7 : P3Pガイドライン (標準非準拠)

情報プライバシー

通知とコミュニケーション

選択とコントロール

公正さと完全性

セキュリティ

付録8 : ワーキンググループ貢献者 (標準非準拠)

3.2.1 `POLICIES` 要素

3.3.1 `STATEMENT` 要素

3.3.2 `CONSEQUENCE` 要素

3.3.4 `PURPOSE` 要素

3.3.5 `RECIPIENT` 要素

3.3.6 `RETENTION` 要素

付録1: 参考文献（標準準拠）

付録2: 参考文献（標準非準拠）

付録6 : ABNF表記法（標準非準拠）

`business`	カテゴリ	構造	簡易表記名
name	人口統計学的・社会経済学的データ	構造化されていない	団体・組織名
department	人口統計学的・社会経済学的データ	構造化されていない	団体・組織における部門または課
cert	ユニークな識別子	certificate	団体・組織である証明
contact-info	実社会における問い合せ窓口、オンライン問い合せ情報、人口統計学的・社会経済学的データ	contact	団体・組織への問い合わせ情報

`dynamic`	カテゴリ	構造	簡易表記名
clickstream	ナビゲーションとクリックストリームのデータ, コンピュータ情報	loginfo	クリックストリーム情報
http	ナビゲーションとクリックストリームのデータ, コンピュータ情報	httpinfo	HTTPプロトコル情報
clientevents	ナビゲーションとクリックストリームのデータ	構造化されていない	ユーザのリソースとの対話
cookies	(可変カテゴリ)	構造化されていない	HTTPクッキーの使用
miscdata	(可変カテゴリ)	構造化されていない	雑多な非基本データスキーマ情報
searchtext	インタラクティブデータ	構造化されていない	検索文字列
interactionrecord	インタラクティブデータ	構造化されていない	サーバの処理履歴の保存