Copyright (C) 2000 W3C (MIT, INRIA, Keio), All Rights Reserved. W3C 責任、登録商標、, 文書の使用、 そして ソフトウエアライセンスに関する規則が適用される。

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification

W3C Working Draft 10 May 2000

This Version:

http://www.w3.org/TR/2000/WD-P3P-20000510

Latest Version:

http://www.w3.org/TR/P3P

Previous Version:

http://www.w3.org/TR/2000/WD-P3P-20000424

Editor:

Massimo Marchiori, W3C/MIT, (massimo@w3.org)

Authors:

Lorrie Cranor, AT&T

Marc Langheinrich, ETH Zurich

Massimo Marchiori, W3C/MIT

Martin Presler-Marshall, IBM

Joseph Reagle, W3C/MIT

Copyright (C)2000 W3C^(R) (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

要旨

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

本文書の位置付け 　　

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

本文書は、W3Cのメンバーにレビューしてもらう為のW3Cワーキングドラフトである。本文書は、P3Pアクティビティの一つであるP3P仕様書ワーキンググループに依って作成されたものであり、また、1999年11月2日に発行されたラストコールドラフト(http://www.w3.org/TR/1999/WD-P3P-19991102)の改訂３版である。改訂内容を分かりやすくする為、その 改訂履歴を本文書の最後に示す。本文書のラストコールの期限は、2000年4月30日である。本文書の改訂版は、少なくとも2つの相互互換性のあるインプリメンテーションのデモンストレーションが実施されたならW3C勧告になる予定である。

本仕様書は、他の仕様書によりいつでも改版・置換・陳腐化の可能性のあるドラフトの仕様書である。従って、W3Cのワーキングドラフトを"進行中の作業"ではないとして参考文献資料やその他として参照することは不適切である。現在のW3Cワーキングドラフトはhttp://www.w3.org/TR/で参照可能である。

コメントをwww-p3p-public-comments@w3.orgに送って欲しい。（http://lists.w3.org/Archives/Public/www-p3p-public-comments/に記録されている）。もしくは、コメントを公にしたくないならば、p3p-comments@w3.orgに送って欲しい。この場合、あなたのコメントはW3Cのメンバからのみアクセス可能となる（そのアドレスはhttp://lists.w3.org/Archives/Member/p3p-comments/である）。

目次

1. 序論
   1. P3P1.0仕様書
      1. P3P1.0の最終目的と可能性
      2. P3P利用例
      3. P3Pポリシー
      4. P3Pユーザエージェント
      5. サーバ上でのP3Pの実装
      6. P3Pの将来バージョン
   2. 本仕様書について
   3. 用語
   4. 審議中になっている変更点
2. ポリシー参照
   1. ポリシー参照の概要と目的
      1. メカニズム
   2. ポリシー参照ファイルの存在場所
      1. 周知の存在場所
      2. HTTP拡張フレームワークを使う
         1. HTTP拡張フレームワークの使用
         2. ヘッダシンタックス
      3. linkタグを使用したシンタックス
   3. ポリシー参照ファイルのシンタックスとセマンティクス
      1. ポリシー参照ファイルの例
      2. ポリシー参照ファイルの定義
         1. ポリシー参照ファイルの有効期限
         2. POLICY-REFERENCES要素
         3. RDF要素
         4. POLICY-REF要素
         5. PREFIX要素とEXCLUDE要素
         6. METHOD要素
      3. 直接参照と間接参照
         1. 間接的なポリシー参照の目的
         2. 間接参照の取り扱い
      4. 埋め込みコンテンツ
      5. フォームおよび関連するメカニズム
   4. ポリシー参照の利用
      1. 一義性
      2. 多言語
      3. ポリシーの不変性
   5. 追加要求事項
      1. セーフゾーン
      2. ポリシーの非差別化
      3. ポリシーの送信に関するセキュリティ
3. ポリシーのシンタックスとセマンティクス
   1. ポリシーの例
      1. 自然言語のポリシー
      2. ポリシーのXMLコード化
   2. ポリシー
      1. POLICY要素
      2. ENTITY要素
      3. DISCLOSURE要素
      4. REMEDIES要素
      5. DISPUTES要素
   3. ステートメント
      1. STATEMENT要素
      2. CONSEQUENCE要素
      3. PURPOSE要素
      4. RECIPIENT要素
      5. RETENTION要素
      6. DATA-GROUPとDATA要素
   4. カテゴリ
      1. 固定カテゴリデータ要素/型
      2. 可変カテゴリデータ要素/型
   5. 拡張メカニズム
4. データスキーマ
   1. DATA-DEFとDATA-TYPE要素
   2. データスキーマの不変性
   3. プリミティブデータ型
   4. 基本データ型
      1. 日付
      2. 名前
      3. 認証
      4. 電話
      5. 連絡先情報
         1. 郵便
         2. テレコミュニケーション
         3. オンライン
   5. 基本データスキーマ
      1. 個人データ
      2. 第三機関データ
      3. ビジネスデータ
      4. 動的データ
   6. データ要素を使う
5. 付録
   付録 1：参考文献（標準準拠）
   付録 2: 参考文献 (標準非準拠)
   付録 3：P3P基本データスキーマ定義（標準準拠）
   付録 4：XMLスキーマ定義（標準準拠）
   付録 5：XML DTD 定義（標準準拠）
   付録 6：ABNF表記法 (標準非準拠)
   付録 7：P3Pガイドライン (標準非準拠)
   付録 8：ワーキンググループ貢献者 (標準非準拠)

1. 序論

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

1.1.5 サーバ上でのP3Pの実装

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

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

1.1.6 P3Pの将来バージョン

P3P仕様書ワーキンググループは、当面の、P3Pの早期の実装と普及を促進するため、初期のP3P1.0 仕様書に記述してあった重要な機能を削除している。当該グループは、P3P1.0が普及した時点で、 P3Pの次期仕様書を公開することを予定している。次期仕様書には、実装経験や普及時の経験を反映させるとともに、P3P1.0から落とされた、次の４つの重要な機能を盛り込む予定である。

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

1.2 本仕様書について

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

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

更に、属性と要素は、任意の順序で使えることに注意されたい。本仕様書は、必要性の程度を表す為、RFC2119 [KEY]に定義されている次の用語を用いる。次の重要な用語が、相互互換性を実現する為に、本文書全体を通して用いられている。

「しなければならない」もしくは「してはならない」

この用語または形容詞"要求される"は、当該アイテムが本仕様書において絶対的に必要なものであることを意味する。

「するべきである」もしくは「するべきでない」

この用語または形容詞"推奨される"は、当該アイテムが正当な理由のもとに、或る状況下において無視できることを意味する。しかし、完全実装の場合、実装すべきものであり、実装しない場合、注意深く検討すべきものである。

「してもよい」

この用語または形容詞"オプショナル"は、当該アイテムが有っても無くてもよいものであることを意味する。例えば、或るベンダーは、プロダクトを魅力あるものとする為、マーケット戦略的にこのアイテムを含めるかもしれないが、他のベンダーはこのアイテムを落とすかもしれない。

1.3 用語

Character

[XML]のXML勧告で定義された連続する0か文字からなる文字列。P3Pの中のひとつの文字は、それに一致するひとつの抽象化されたUnicode値と同じになる（[UNICODE]参照）。

データ要素

名字や電話番号と言った個々のデータの実体を意味する。相互互換性のため、P3P 1.0はデータ要素の基本集合を定めている。

データカテゴリ

「実社会における連絡先情報」などのような、データ要素や データ集合の或る重要な属性を指し、トラストエンジンにより、どのデータ型が処理中なのか判断する為に用いられる。P3P 1.0は、基本データカテゴリを定めている。

データ集合

"user.home.postal"と言った、 データ要素の一般的なグループのことである。P3P 1.0は、幾つかの基本データスキーマを定めている。

等価なプラクティス

オリジナルのプラクティスと比較して、目的、受領者、個人を特定別可能な利用などが同じか、もしくは、より制約されているプラクティスであり、更に、その他の情報開示事項が本質的に異ならないものを言う。例えば、異なる業界ガイドラインに準拠しているが、似ているプラクティスを有する二つのサイトを言う。

個人特定可能情報

個人に関するか、個人を特定可能な任意の情報

ポリシー

一つ、もしくは、複数のプライバシーステートメントの集まりであり、所有者、URI、保証や当該のポリシーによってカバーされるサービスの係争解決手続きなどと、一緒になっている。

プラクティス

データの利用の仕方、目的、受領者やその他の情報公開事項などを述べている情報公開の集合。

プリファレンス

ユーザエージェントが行うべきアクションを決める一つの規則、もしくは、規則の集合。或るプリファレンスは、形式定義の算定可能なステートメント(例；プリファレンス交換言語 [APPEL])により記述されるかもしれない。

目的

データ収集とデータ利用の理由

レポジトリ

ユーザエージェントの管理下で、利用者情報を格納しておくメカニズムを言う。

サービス

ポリシーを発行し、必要ならデータ要求を行うプログラムを言う。この定義に従えば、サービスは、サーバ(サイト)、ローカルアプリケーション、ローカルに動くアクティブコード(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やプライバシー代行業者の契約条項の一部として、信頼されるかもしれない。

1.4 審議中になっている変更点

ワーキンググループはP3P1.0で必要な追加の特徴が明確になる実装チームからのインプットによることを決定した。ワーキンググループは必要となる追加の特徴を決めたが、このドラフトの執筆の時点でその特性を指定することについての仕事が完了しなかった。その特徴を実装可能なガイダンスとして以下に列挙する。

• "ミニポリシー"がポリシー参照ファイルで重要になる。 この特徴は、データ要素のポリシー参照ファイルの中の非常に限定されたセットを隠して、P3Pポリシーの概略を提供する方法を供給する。
• ポリシー参照ファイルにP3Pポリシーのインラインを含める能力。 現在、ポリシー参照ファイルがP3Pポリシーを見つけられることができるURLを指定する。 将来的には、ポリシー参照ファイル自体にポリシーのテキストを置くことが可能となるように付け加えられるだろう。

2. ポリシー参照

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

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

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

2.1.1 メカニズム

ポリシー参照ファイル（policy reference file）は、ポリシーとURIを関連付ける為に使用される。ポリシー参照ファイルの存在場所は、二つの方法のうち一つを使用して指定することができる。ポリシー参照ファイルは、"周知の"存在場所としてあらかじめ定義された中で位置付けられるかも知れない。あるいは、ドキュメントはHTMLのLINKタグ、または、HTTP拡張フレームワーク（HTTP Extension Framework）を使用することによって、ポリシー参照ファイルを指し示すかも知れない。ポリシー参照ファイルは、ドキュメントや他のURIなどに適用されるP3Pポリシーを指定する。ポリシー参照ファイルは、[RDF]/[XML]ファイルであり、単一のWebドキュメントや、Webサイトの幾つかの部分、又はWebサイト全体の為のポリシーを指定することが出来る。ポリシー参照ファイルは、複数のP3Pポリシーを参照するであろう。この事は、異なるP3Pポリシーが、サイトの異なる部分に適用されているにもかかわらず、単一の参照ファイルのみでサイト全体をカバーする事を許可する。

ポリシーは、HTTPの実体と同等に利用されることに注意すること。URIをフェッチする事によって取得された実体は、実体に関連したP3Pポリシーを持っている。利用者から見た"ページ"は、複数のHTTPの実体によって作成されているだろう。個々の実体は、それ自体に関連した独自のP3Pポリシーを持つだろう。しかしながら、現実的な注意点として、単一のページ上にある異なる実体に、多くの異なるP3Pポリシーを置くことはページを表現するが、ユーザエージェントが利用者に関連するポリシーを知らせる事を困難にする。加えてサービスは、作成したいかなる"ページ"をもカバーする単一のポリシー参照ファイルを念入りに作成する事を試みるべきである。

ユーザエージェントが所定の組織に適用されるポリシーを処理するためには、その組織のポリシー参照ファイルの位置を定めなければならず、そのポリシー参照ファイルを取って来て、ポリシー参照ファイルを解析し、必要とされる全てのP3Pポリシーを取って来て、そしてP3Pポリシーまたはポリシーを解析する。

HTTP以外の方法で取得されたドキュメントとP3Pポリシーとをどの様にして関連付けるかに関し、このドキュメントにおいては指定していない。しかしながら、他のプロトコルの上で運ばれてきたドキュメントとP3Pポリシーを結び付けることに対してはメカニズムの将来の開発を妨げない。

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

この節では、二つのサポートされているメカニズムを使用して、ポリシー参照を作成する為に使用されるシンタックスを説明する。

2.2.1 周知の存在場所

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

サイトがこのメカニズムを使う必要がないことに注意。さらに、もしサイトがこのメカニズムを使うことに決めるなら、周知の存在場所に位置しているポリシー参照ファイルが全部のサイトをカバーする必要はない。例えば、内容のすべてがひとつの組織の管理下にあるわけではないサイトは、このメカニズムを使わないことを決めるかもしれない。あるいはそのサイトで限られた部分のみをカバーするポリシー参照ファイルを置くことを決めるかもしれない。

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

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

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

2.2.2 HTTP拡張フレームワークを使う

P3PはHTTP拡張フレームワーク[HTTP-EXT]を使用する。HTTP拡張フレームワークでは、新規のHTTPヘッダを定義し、使用することができる。リクエストやレスポンスにおいて、作成された拡張と関連付けられた全てのHTTPヘッダには、任意の２桁のネーム空間識別子が前置される。この2桁の識別子は、メッセージ毎に実装者によって選択されるであろう。この事は、拡張ヘッダにおけるユニークなネーム空間を保証する。加えて、拡張は、ネーム空間を宣言する時に、自分自身を（URIと）同じものとして扱わなければならない。

2.2.2.1 HTTP拡張フレームワークの使用

HTTP拡張フレームワークは、拡張（拡張宣言（extension declaration））を示す世界的にユニークなURIを必要とする。P3Pでの拡張宣言は、以下のURIである：

http://www.w3.org/2000/P3Pv1

HTTPによって取得されるドキュメントは、新規のレスポンスヘッダであるPolicyRefヘッダを使用することによって、ポリシー参照ファイルを指し示すであろう。PolicyRefヘッダは、ポリシー参照ファイルのURIを含み、それは同様に参照ファイルと、もしかすると他のものを指し示したドキュメントをカバーしているP3Pポリシーを述べるだろう。このURIは、P3Pポリシーを確認、参照する目的以外で使用してはならない。

P3Pを利用できるサーバが、HEADとOPTION要求に応答する場合を含む、適切な要求に対して応答する場合は、必ずP3P拡張宣言とポリシーヘッダ参照を挿入すべきである。

P3Pを利用できないユーザエージェントが、適切に解釈を行い、P3Pポリシー参照を含んだレスポンスを処理することが可能である為、P3Pは、HTTP拡張フレームワークの点からして"任意"のものである。ポリシー参照は、応答の連鎖に従って、いかなる存在場所においてもユーザエージェントによって処理されるので、P3Pは端と端をつなぐHTTP拡張である。従って、P3P拡張を宣言する為に使用されるヘッダは、Optであるだろう。

2.2.2.2 ヘッダシンタックス

ポリシー参照ヘッダのシンタックスは:

policy-reference-header

=

nsprefix `-PolicyRef: ` URI

ヘッダのPolicyRef部分は、他のHTTPヘッダ規則に従っていかなる字体で書かれてもよい。（例えば大文字/小文字の区別はしない）

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

HTTP/1.1 200 OK
Opt: "http://www.w3.org/2000/P3Pv1"; ns=11
11-PolicyRef: http://catalog.example.com/P3P/PolicyReferences.xml
Content-Type: text/html
Content-Length: 7413
Server: CC-Galaxy/1.3.18

2.2.3 linkタグを使用したシンタックス

サーバは、適切なP3Pポリシー参照ファイルの存在場所を示したlinkタグが埋め込まれたHTMLコンテンツを提供するだろう。このP3Pの使用方法は、P3Pに準拠したサーバを必要としない：コンテンツは、サーバの運用方法の変更なしに、埋め込みlinkタグを含むように変更されるだろう。

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

p3p-link-tag

=

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

例えば、例2.1のように、HTTPヘッダを使用して表現されているポリシー参照は、http://catalog.example.com/index.htmlのWebページ内に、以下のHTML部分を含むことによって同等に表現できる：

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

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

ユーザエージェントがHTMLを処理する場合、ユーザエージェントは両方のメカニズム（HTTPヘッダ内のポリシー参照又はlinkタグ）を互換的に処理しなければならないことに注意すること。両方のメカニズムは、互いにオーバーライドしない。一義性の要求事項も参照すること。

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

ポリシー参照ファイルは、P3PポリシーとURI空間の決まった領域とを関連付ける為に使用される。ドキュメントがポリシー参照ファイルにリンクするために使うメカニズムにかかわらず、その参照ファイルのシンタックスは同じのままである。ポリシー参照ファイルは、以下のステートメントの幾つか、又は全てを作成するために使用される：

• P3PプライバシーポリシーがあるURI
• ポリシーによってカバーされているURI、またはURI空間の領域
• ポリシーによってカバーされていないURI、またはURI空間の領域
• ポリシーが適用可能であるアクセス方法
• クレームが有効であると考えられる一定の期間

最初の四つのステートメントは、ポリシー参照ファイルのボディー部に作成され、最後のステートメントはポリシー参照ファイルにHTTP expirationヘッダを使用して作成される。

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

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

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

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

<POLICY-REFERENCES
    xmlns="http://www.w3.org/2000/P3Pv1"
    xmlns:web="http://www.w3.org/1999/02/22-rdf-syntax-ns#" >
  <web:RDF>

    <POLICY-REF web:about="/P3P/Policy1.p3p">
      <PREFIX>/</PREFIX>
      <EXCLUDE>/catalog/</EXCLUDE>
      <EXCLUDE>/cgi-bin/</EXCLUDE>
      <EXCLUDE>/servlet/</EXCLUDE>
    </POLICY-REF>

    <POLICY-REF web:about="/P3P/Policy2.p3p">
      <PREFIX>/catalog/</PREFIX>
    </POLICY-REF>

    <POLICY-REF web:about="/P3P/Policy3.p3p">
      <PREFIX>/cgi-bin/</PREFIX>
      <PREFIX>/servlet/</PREFIX>
      <EXCLUDE>/servlet/unknown</EXCLUDE>
    </POLICY-REF>

  </web:RDF>
</POLICY-REFERENCES>

このポリシー参照ファイルへのクレームの有効期間が8時間であることを示す為に、このページを提供するサーバは、このファイルと共にCache-Control: max-age=28800ヘッダを返信するだろう。代替案として、このサーバはレスポンスにおいて、Dateヘッダから8時間後を示したExpiresヘッダを生成するだろう。

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

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

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

2.3.2.1 ポリシー参照ファイルの有効期限

ポリシー参照ファイルの有効期限は、ユーザエージェントに対し、参照ファイル内のクレームがどれくらいの期間有効であるかを告げる。例えば、ポリシー参照ファイルが16時間の有効期限を持っている場合、ユーザエージェントは16時間ファイルをリロードする必要がなく、参照ファイルからの参照は16時間有効であると仮定することが出来る。単一のポリシー参照ファイルから参照される全てのポリシーは、同じ有効期限を持つであろう。P3Pプライバシーポリシーの為に異なる有効期限を指定したい場合の唯一の方法は、個々のP3Pポリシー毎に、異なるポリシー参照ファイルを使用する事である。

ポリシー参照ファイルの有効期限は、参照ファイルと共に提供されたHTTP cache controlヘッダによって決定される。しかし、ユーザエージェントは参照ファイルの有効期限を算出する為に、ファイルの更新日を基にした有効期限の算出を使用してはならない。ユーザエージェントは、参照ファイルと共に提供される "Expires"、"Cache-Control"、"Pragma" ヘッダが利用可能であるならば、それらのヘッダを基にポリシー参照ファイルの有効期限を算出しなければならない。それらのヘッダのセマンティクスは、[HTTP]によって定義されている。もしそれらのヘッダが利用できない場合、有効期限はサーバがドキュメントを送信した時点から24時間にセットされなければならない。サーバは、ポリシー参照ファイルの有効期限を明白に提供する為に、上記のヘッダの一つを使用すべきである。

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

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

2.3.2.2 POLICY-REFERENCES要素

POLICY-REFERENCES要素は、完全なポリシー参照ファイルを含む。ポリシー参照ファイル内には、必ず一つのPOLICY-REFERENCES要素がなければならない。この要素は、RDF要素を一つ含まなければならない。

POLICY-REFERENCES

RDF要素を一つ含む。この要素は属性を持たない。（あるいはネーム空間宣言でも良い）

policies

=

`<POLICY-REFERENCES xmlns="http://www.w3.org/2000/P3Pv1" `
rdf-ns-def
`>`
rdf
`</POLICY-REFERENCES>`

rdf-ns-def

=

xmlns `:` rdf-ns-prefix
`="http://www.w3.org/1999/02/22-rdf-syntax-ns#"`

rdf-ns-prefix

=

NCName

2.3.2.3 RDF要素

RDF要素は、ポリシー参照ファイル内のRDF表記をカプセル化する。この要素は複数のPOLICY-REF要素（ポリシー参照）を含まなければならない。

POLICY-REFERENCES

複数の区別されたポリシー参照を含む。この要素は属性を持たない。

rdf

=

`<` rdf-ns-prefix `:` `RDF>`
policy-ref
`</` rdf-ns-prefix `:` `RDF/>`

2.3.2.4 POLICY-REF要素

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

POLICY-REF

単一のP3Pプライバシーポリシーに関する情報を含む。

(rdf-nf-prefix:)about （必須の属性）

P3PプライバシーポリシーのURI。もしこれが関連するURLであれば、ポリシー参照ファイルのURIに関するものとして解釈される。この事は、直接的又は間接的なポリシー参照であるだろう；これらの用語の定義に関しては、直接ポリシー参照と間接ポリシー参照を参照すること。

policy-ref

=

`<POLICY-REF ` rdf-ns-prefix `:` `about="` URI `">`
*prefix
*exclude
*method-element
`</POLICY-REF>`

2.3.2.5 PREFIX要素とEXCLUDE要素

個々のPREFIX要素又はEXCLUDE要素は、単一のローカルURI-prefixを指定する。それらの要素は、含まれているPOLICY-REF要素によって示されるポリシーによってカバーされるWebサイトの一部を特定する為に使用される。

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

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

PREFIX要素がPOLICY-REF要素内に含まれていない場合、hrefによって与えられたポリシーは、ポリシー参照ファイルにリンクされているリソースに対して適用されると無条件に仮定されなければならない。ポリシー参照ファイルがPREFIX要素なしに、二つ以上のPOLICY-REF要素を持つことは誤りである。PREFIX要素なしにEXCLUDE要素を提供する事は、間違いではないが、意味のないことである；この場合EXCLUDE要素は、ユーザエージェントによって無視されなければならない。

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

ポリシー参照ファイルは、いかなる正規表現の種類もサポートしていないことに注意すること。POLICY-REF要素内において唯一提供されている機能は、最新のドキュメント（PREFIX要素を含まないことによって必ず）を参照することや、相対URI-Prefixを使用することである。例えば、".asp"という拡張子で終わっている全てのURIに適用される確実なP3Pプライバシーポリシーや、't'という文字を3個以上含んでいるURIに適用される確実なP3Pプライバシーポリシーを述べることは不可能である。

さらに、PREFIXとEXCLUDEのマッチングは単純な文字列上のマッチングで行う。結果として、ディレクトリの末尾の“/”が欠けたりした場合、予期しない結果がもたらされるかもしれない。例えば、<EXCLUDE>/images/logos</EXCLUDE>要素（hrefの末尾に'/'が欠けている事に注意）は、/images/logos/サブディレクトリ内の全てのリソースを排除するだけでなく、例えば、相対的なURIの/images/logoschool.jpgファイルも排除するであろう。

prefix

=

`<PREFIX>` URI`</PREFIX>`

exclude

=

`<EXCLUDE>` URI `</EXCLUDE>`

2.3.2.6 METHOD要素

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

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

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

<POLICY-REFERENCES
    xmlns="http://www.w3.org/2000/P3Pv1"
    xmlns:web="http://www.w3.org/1999/02/22-rdf-syntax-ns#" >
  <web:RDF>

    <POLICY-REF web:about="/P3P/Policy1.p3p">
      <PREFIX>/docs/</PREFIX>
      <METHOD>GET</METHOD>
      <METHOD>HEAD</METHOD>
    </POLICY-REF>

    <POLICY-REF web:about="/P3P/Policy2.p3p">
      <PREFIX>/docs/</PREFIX>
      <METHOD>PUT</METHOD>
      <METHOD>DELETE</METHOD>
    </POLICY-REF>

  </web:RDF>
</POLICY-REFERENCES>

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

method-element

=

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

2.3.3 直接参照と間接参照

サービスは直接ポリシーを参照してもよいし、間接的に参照してもよい。ポリシーの直接参照とは、取得されたポリシーURIがそのポリシーの本体となるXML文書を返す場合の、ポリシーURIのことである。ポリシーの間接参照とは、取得されたポリシーURIが新たなポリシーURIを返す場合の、ポリシーURIのことである。間接参照によって返されるこの新たなポリシーURIは、それ自体が間接参照であってもよいが、このことはパフォーマンス上の理由から薦められない。

直接参照と間接参照は、それらが取得される際にサーバによって与えられるHTTPのリターンコードによって識別がされる。直接参照のポリシーURIが取得された場合、サーバは200番台のHTTPリターンコードか、301 (Moved Permanently)のリターンコードか、あるいは（適当であれば）エラーコードを返すべきである。サーバは302(Found)や303 (See Other) 、 307 (Temporary Redirect)のリターンコードを返してはならない。間接参照のポリシーURIが取得された場合、エラーコード(400番台または500番台のコード)が適当な場合でないかぎり、サーバは302や303、307のリターンコードを返さなければならない。302や303、307のリターンコードが返される場合は、そのリターンコードは実際のポリシーURIを与えるLocation応答ヘッダを含まなければならない。

サービスは、適切な方法として、直接ポリシー参照と間接ポリシー参照のどちらを使用するか選択することができる（ポリシーの不変性の要求事項を尊重するかぎりにおいて）。直接参照は、これらのポリシーを処理するユーザエージェントにとって最良のパフォーマンスをもたらす。ポリシーの不変性の規則により、ユーザエージェントがすでに取得済みのポリシーURIへの直接参照を受信した場合、それ以上の通信活動を行うことなく、ポリシーの処理を行うことができる。このことはユーザエージェントの応答時間を短縮する効果をもたらす。

2.3.3.1 間接的なポリシー参照の目的

間接参照は、実際のポリシーの所在を突きとめるために、さらに少なくとも一往復の通信活動を行うことが必要となる。このことはユーザエージェントのパフォーマンスを下げる結果となる。しかし、間接参照を用いることで、ある種の組織はより柔軟性のあるポリシーの配置を行うことができる。以下にその一例を挙げる：

CatalogExample社という架空の企業は、世界的規模でWebサイトを開設している。この企業の大本のWebサイトwww.catalog.example.comはいくつもの国別サイトへのリンクを提供している。ここでは、CatalogExample社が皮切りに、usa.catalog.example.com (米国)、www.CatalogExample.co.uk(英国)、www.catalog.example.com.ru(ロシア)、 www.catalog.example.co.jp(日本)という4つのローカルなサイトを立ち上げたと仮定する。また、これらのサイトは各々、サイトのコンテンツをローカルに開発していると仮定する。このことにより、各サイトはローカルな閲覧者により適合したサイトを構築することができる。

しかし、CatalogExample社は、世界中の自社のサイト全てに適用する単一のプライバシーポリシーを所持することを決定した。CatalogExample社は大本のWebサイト（www.catalog.example.com）にこのプライバシーポリシーを掲載し、ローカルなサーバ上の各ページにはこのプライバシーポリシーを参照させることで、この決定を実行することができるだろう。ここで、CatalogExample社がポリシーを更新しようとする場合、ポリシーの不変性の規則により、CatalogExample社は自社のプライバシーポリシーを新しいURIに掲載しなければならない。したがって、CatalogExample社は自社の全てのWebサイト上のポリシー参照を変更しなければならない。このためには、世界各地のWeb管理者の作業が必要となるだろう。この問題は、CatalogExample社がより事業を拡大し、20とか50とかのローカルなWebサイトを所持した時にはいっそう困った問題となる。

間接参照はこのような運用上の問題に対するソリューションとして意図されたものである。CatalogExample社の各ローカルサイトは大本のCatalogExample社のサーバを指し示したポリシーURIを表明することができる。このポリシーURIを取得すると、現在適用されているプライバシーポリシーへのポリシー参照が与えられる。例えばCatalogExample社が顧客にその週の特別供給品のリストを送付するために顧客の電子メールアドレスを収集しようとしていると仮定する。各ローカルサーバは間接的なポリシーURIであるhttp://www.catalog.example.com/privacy/P3P/policy-weeklyspecialを使用することができる。このURIを取得すると、実際のプライバシーポリシー（それはhttp://www.catalog.example.com/privacy/P3P/policy-weeklyspecial-3.xmlであるかもしれない）へのリンクが与えられる。CatalogExample社がプライバシーポリシーを更新しようとする場合、そのプライバシーポリシーを参照しているローカルサーバの台数に関わりなく、大本のサーバ上でのみ更新を行えばよい。

一般に、サービスは直接ポリシー参照の使用が可能な場合には、そちらを使用するべきである。間接ポリシー参照については、沢山の多様なWebサイトを持つ組織のみが使用することが望ましい。

サービスは、ポリシーステートメントの正確性を保証するために、同一の組織運営下にあるURI間でのみ間接ポリシー参照を行うべきであることに注意すること。しかし、この要求事項を守らせるための技術的手段はない。間接ポリシー参照は、組織のWebサイトの構造によっては、他のホスト上のURIや他のドメイン内のURIに対してさえ参照を行うことができる。

2.3.3.2 間接参照の取り扱い

ユーザエージェントがポリシー参照を受信したときに、それが直接参照なのか間接参照なのかを区別する方法はない。ポリシーを適切に処理するためには、ユーザエージェントはそのポリシー参照で規定されたURIを取得しなければならない。この参照が302(Found)、303(See Other)、または 307 (Temporary Redirect)というリターンコードを返した場合は、ユーザエージェントは、実際のポリシーの存在場所を指し示すLocationヘッダにおいて与えられるURIを取得しなければならない。ポリシーが一たび直接参照により取得されると、（ユーザエージェントがこの情報を記録しつづけるかぎり）2度目以降は取得される必要がなくなることに注意すること。しかし、間接参照では、（ExpiresまたはCache-ControlHTTPヘッダによってポリシーが変更されていないことが示されないかぎり）、ポリシーが変更されていないことを確認するために再チェックを行う必要がある。

2.3.4 埋め込みコンテンツ

HTML ページは時に、画像イメージ、音、レイヤあるいはフレームのような、ページに直接埋め込まれた他のリソースへのリンクを含んでいる。 従って、そのようなページを表現するために、ユーザエージェントは、現在使われているページにおけるポリシーによってカバーされるか、しないかといった追加のリクエストを行う必要がある。

2.3 ポリシー参照ファイルのシンタックスとセマンティクスで記述されるように、このような事態のための望ましい方法はひとつのポリシー参照ファイルの<PREFIX>と<EXCLUDE>要素を使い、影響するすべてのポリシーを仮宣言することである。2.3.1 ポリシー参照ファイルの例における例2.2、それと同様に良い例として2.3.2 ポリシー参照ファイルの定義を参照のこと。

もし、ユーザエージェントが埋め込みコンテンツにリンクするような与えられたURIのプレフィックスに一致するものが見つけれなかったら (例えばIMGタグのsrc属性)、それは与えられたリソースに関係するようなP3Pポリシーは存在しないものとすべきである。しかしながら、影響するようなポリシーを見つけるために、リソースを実際に求める前に、ユーザエージェントが現在のページのヘッダでカバーされた埋め込みURIにHEADのリクエストを発行することを望んでもよい。

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

フォームは、HEADリクエストを使わないと思われる、CGIスクリプトへのリンクや、その他のサーバ側アプリケーションへのURIなど、埋め込みコンテンツにおける特別な型である。

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

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

ある場合には、異なったデータがフォームの中で選択されたものに応じて同じアクションURIで集められる。例えば、探索サービスが（名前あるいは電子メールなどで）人と（独断的な）イメージにおいて検索を試みようとするかもしれない。フォームでラジオボタンを使うとき、ひとつのサーバ側のアプリケーションはひとつに決められ、そして同じアクションURIは両方のケースを処理して、そして探索に必要な必要情報を集める。

もしサービスがサーバ側のアプリケーションのデータ収集の処理を仮宣言することを望むなら、それは現在ただひとつのポリシーファイル（アクションURIにマッチする宣言の<PREFIX>を使った）に対してのデータ収集の処理のすべてを宣言することについてのオプションを持っているだけである。実際上、ユーザエージェントは状況に応じたすべてのデータ要素が集められると想定しなくてはならない。このソリューションはひとつのポリシーでは便利さを提供する。しかしただリストされたデータ要素の一部だけが一度に集められるという事実を適切に反映しないかもしれない。（選択されたラジオボタンの値が特に存在しないという理由なしで）サービスがアクションURIへの単純なヘッドのリクエストがすべてのケースをカバーするようなポリシーを返すであろうことを明確にすべきである。

フォーム送信はGETメソッドを使うことに注意。<PREFIX>属性において送信データ（そのデータはGETメソッドのアクションURIに添付される）の一部を含むことができる。これは可能であるけれども、このメソッドは次の理由のために反対される：

• ユーザエージェントへの依存:　[HTML4.01]であっても、 HTMLソースで指定されたフォームデータをユーザエージェントがいつも送ることを要求される。素直でないユーザエージェントが保証された方法で問合せ文字列を組み立てないかもしれない。
• ページソースへの依存:　もし、ページデザイナーが後になってページのデザインを変更することを望むなら、入力要素を再注文しているどんなものでも前回の規律を壊すかもしれない。それで仮宣言された P3P ポリシーリンクを無用にする。
• ページ要素の種類の制限:　<PREFIX>メカニズムページでの使用を作るために、デザイナーはこのページの最初に現れる区別した要素を明確にしなければならない。

2.4 ポリシー参照の利用

2.4.1 一義性

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

ひとつのポリシー参照ファイルが明らさまに曖昧であることをチェックする必要性があれば、ユーザエージェントWebサイト全体にわたってポリシー宣言を探してもよい。

時間的な一義性（不変性）に関する議論として、ポリシーの不変性の節も参照すること。

2.4.2 多言語

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

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

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

ポリシーとデータスキーマ両方が不変である必要があるときから（下の2.4.3 ポリシーの不変性と比較）、変換は大変に注意して行わなければならない。もし、変換エラーがあったために変更が必要であるなら、新しいポリシーURIが使われなければならない。これはさらにもっと多くの注意がデータスキーマ変換に必要であることを意味する。

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

2.4.3 ポリシーの不変性

ポリシーの重要な要求事項として、いわゆるポリシーの不変性がある。これは、一つの例外を除いて、あるURIで直接参照されるポリシーは変更してはならないというものである。このようにして、ポリシーのURIはポリシーの一意的な識別子のようにふるまうため、いかなる新たなポリシーも新たな異なるURIを使用しなければならない。この一般原則に対する一つの例外とは、同一のポリシーの多言語版（翻訳版）が、HTTPの"Content-Language"タグを用いることにより、サーバによって提供される場合である。

P3Pクライアントは、キャッシュ上のポリシー（および、Content-Languageが表明されている場合にはそのContent-Language）と新たに取得したポリシー（および、Content-Languageが表明されている場合にはそのContent-Language）とを比較することにより、ポリシーの不変性をチェックしてもよい。ユーザエージェントが2つの異なるポリシーが同一のURIを持つことを発見した場合、それらが2つの異なるContent-Language 値を持つのでないかぎり、ユーザエージェントはその変更されたポリシーがカバーするページについてはP3Pポリシーを持たないものとして取り扱わなければならない。

ポリシーの不変性は、直接参照されるポリシーにのみ当てはまることに注意すること。間接参照に関しては、間接ポリシー参照が取得されたときに返される実際のポリシーURIは、時間の経過とともに変えることができる（これが間接ポリシー参照の背後にある目的である）。間接ポリシー参照は、直接ポリシー参照に変更されてはならない。このようなことを望む場合には、新たなポリシーURIが使用されなければならない。

2.5 追加要求事項

2.5.1 セーフゾーン

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

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

加えてP3Pユーザエージェントは、他の要求を行う前に適切なポリシーの存在場所を知るために、サイトに対しHEAD要求を送信してもよいだろう。この方法はデータの送信を必要とする要求を行う事なしに、サイトのポリシーを取得するのに有効である。しかしながら、サイトが Accept-Languageヘッダ（［HTTP1.1］仕様の15.1.4 Privacy Issues Connected to Accept Headersと比較されたし） によりユーザの識別を検出することが可能であるかもしれないときから、ポリシーのマシンリーダブルな一部を受けとるためのAccept-LanguageヘッダなしでHEADリクエストが発行されるかもしれない、そしてそれが合理的に満足がいく場合に限り、もし必要なら、適切な言語でのポリシーは取り出される。

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

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

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

2.5.2 ポリシーの非差別化

サーバ側に対して2つの重要な追加要求がある：

全ての要求に対してポリシーを参照すること:

P3Pに準拠したサーバは、適切なポリシーが利用可能である場合に、Webリソースに対するポリシーへの参照を含むべきである。

HTTP HEAD 要求のサポート

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

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

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

3.ポリシーのシンタックスとセマンティクス

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

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

以下の節では、XML要素を紹介していく。各要素は <>ブランケット（例えば、<POLICY>）で表記され、その後に有効な属性がリストアップされる。「必須の属性」と付記された属性以外は、全てオプショナルな属性である。開始タグと終了タグが隔てられているBNFで示されている多くのXML要素は、要素内に任意の要素を含むことが出来る事に注意が必要である。何も要素が含まれていない場合XML規則に従い、代わりに、自己終結要素（self-closing element）が使用される。

3.1 ポリシーの例

3.1.1 自然言語のポリシー

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

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

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

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

このステートメントに関する質問はこちら：
CatalogExample社
4000 Lincoln Ave.
Birmingham, MI 48009 USA
電子メール: 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.1 Policy]
• 組織(Entity): CatalogExample社
  4000 Lincoln Ave.
  Birmingham, MI 48009
  USA
  catalog@example.com
  +1 (248) 392-6753
  [3.2.2 Entity]
• 個人特定情報へのアクセス: なし(None)
  [3.2.3 Access]
• 係争解決(Disputes):
  係争解決タイプ: 独立機関(independent)
  サービス: http://www.privacyseal.example.org
  表記: PrivacySealExample
  [3.2.4 Disputes]
• 救済(Remedies): 私達はあらゆる間違った行動による害を正します。
  [3.2.5 Remedies]
• 当組織が集める情報:
  dynamic.clickstream.server
  dynamic.http.useragent
  [4.5 Base Data Schema]
• 目的: Webサイトとシステム管理、調査と開発
  [3.3.3 Purpose]
• 受領者(Recipients): 当組織および当組織の業務委託先
  [3.3.4 Recipients]
• 保有期間(Retention): 明記された目的にそう適切な期間
  [3.3.5 Retention]

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

CatalogExample社はあなたのプライバシーを大切にします。 私達はあなたのクレジットカード番号やその他の金融情報を第三者と共有することはありません。 あなたの許可があった場合に限り、あなたが過去に特別な提供をしたか、過去の購入の習慣などの嗜好を、慎重に選んだマーケティングパートナーとのみ情報を共有します。 あなたの好みと嫌いなものを知ることによって、ニーズに応じたより良い申し出（情報）を提供することができます。
　
CatalogExample社はPrivacySealExampleプログラムの認可を持っています。 PrivacySealExampleは、Webサイト使用権利者に高いプライバシー基準を取得させ、 そして会計監査人と一緒にこれらの情報の業務がフォローされていることを確認することにより、 あなたのプライバシーを保証しています。

このステートメントに関する質問はこちら：
CatalogExample社
4000 Lincoln Ave.
Birmingham, MI 48009 USA
電子メール: catalog@example.com
Telephone 248-EXAMPLE (248-392-6753)

もし私達があなたの問合せに返答しなかったか、あるいはあなたの問合せが満足に扱われなかったときには、http://www.privacyseal.example.orgによってPrivacySealExampleと連絡を取ることができます。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/P3Pv1"
  discuri="http://www.catalog.example.com/PrivacyPracticeBrowsing.html">
 <ENTITY>
  <DATA-GROUP>
   <DATA ref="#business.name">CatalogExample</DATA>
   <DATA ref="#business.contact-info.postal.street.line1">4000 Lincoln Ave.</DATA>
   <DATA ref="#business.contact-info.postal.city">Birmingham</DATA>
   <DATA ref="#business.contact-info.postal.stateprov">MI</DATA>
   <DATA ref="#business.contact-info.postal.postalcode">48009</DATA>
   <DATA ref="#business.contact-info.postal.countrycode">USA</DATA>
   <DATA ref="#business.contact-info.online.email">catalog@example.com</DATA>
   <DATA ref="#business.contact-info.telecom.telephonenum.intcode">1</DATA>
   <DATA ref="#business.contact-info.telecom.telephonenum.loccode">248</DATA>
   <DATA ref="#business.contact-info.telecom.telephonenum.number">3926753</DATA>
  </DATA-GROUP>
 </ENTITY>
 <DISPUTES-GROUP>
  <DISPUTES resolution-type="independent"
    service="http://www.PrivacySeal.example.org"
    short-description="PrivacySeal.example.org">
   <REMEDIES><correct/></REMEDIES>
   <IMG src="http://www.PrivacySeal.example.org/Logo.gif"/>
  </DISPUTES>
 </DISPUTES-GROUP>
 <ACCESS><nonident/></ACCESS>
 <STATEMENT>
  <PURPOSE><admin/><develop/></PURPOSE>
  <RECIPIENT><ours/></RECIPIENT>
  <RETENTION><stated-purpose/></RETENTION>
  <DATA-GROUP>
   <DATA ref="#dynamic.clickstream.server"/>
   <DATA ref="#dynamic.http.useragent"/>
  </DATA-GROUP>
 </STATEMENT>
</POLICY>

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

<POLICY xmlns="http://www.w3.org/2000/P3Pv1"
  discuri="http://www.catalog.example.com/PrivacyPracticeBrowsing.html">
 <ENTITY>
  <DATA-GROUP>
   <DATA ref="#business-info.name">CatalogExample</DATA>
   <DATA ref="#business-info.contact-info.postal.street.line1">4000 Lincoln Ave.</DATA>
   <DATA ref="#business-info.contact-info.postal.city">Birmingham</DATA>
   <DATA ref="#business-info.contact-info.postal.stateprov">MI</DATA>
   <DATA ref="#business-info.contact-info.postal.postalcode">48009</DATA>
   <DATA ref="#business-info.contact-info.postal.countrycode">USA</DATA>
   <DATA ref="#business-info.contact-info.online.email">catalog@example.com</DATA>
   <DATA ref="#business.contact-info.telecom.telephonenum.intcode">1</DATA>
   <DATA ref="#business-info.contact-info.telecom.telephonenum.loccode">248</DATA>
   <DATA ref="#business-info.contact-info.telecom.telephonenum.number">3926753</DATA>
  </DATA-GROUP>
 </ENTITY>
 <DISPUTES-GROUP>
  <DISPUTES resolution-type="independent"
    service="http://www.PrivacySeal.example.org"
    short-description="PrivacySeal.example.org">
   <REMEDIES><correct/></REMEDIES>
   <IMG src="http://www.PrivacySeal.example.org/Logo.gif"/>
  </DISPUTES>
 </DISPUTES-GROUP>
 <ACCESS><contact_and_other/></ACCESS>
 <STATEMENT>
  <PURPOSE><admin/><develop/></PURPOSE>
  <RECIPIENT><ours/></RECIPIENT>
  <RETENTION><stated-purpose/></RETENTION>
  <DATA-GROUP>
   <DATA ref="#dynamic.clickstream.server"/>
   <DATA ref="#dynamic.http.useragent"/>
  </DATA-GROUP>
 </STATEMENT>
 <STATEMENT>
  <PURPOSE><current/></PURPOSE>
  <RECIPIENT><ours/></RECIPIENT>
  <RETENTION><stated-purpose/></RETENTION>
  <DATA-GROUP>
   <DATA ref="#user.name"/>
   <DATA ref="#user.home-info.postal"/>
   <DATA ref="#user.home-info.telecom.phone"/>
   <DATA ref="#user.business-info.postal"/>
   <DATA ref="#user.business-info.telecom.phone"/>
   <DATA ref="#user.home-info.online.email"/>
   <DATA ref="#miscdata>
   <CATEGORIES><financial/><CATEGORIES/>
   </DATA>
  </DATA-GROUP>
 </STATEMENT>
 <STATEMENT>
  <PURPOSE>
   <contact change_preferences="yes"/>
   <customization change_preferences="yes"/>
   <targeting change_preferences="yes"/>
  </PURPOSE>
  <RECIPIENT><ours/><same/></RECIPIENT>
  <RETENTION><stated-purpose/></RETENTION>
  <DATA-GROUP>
   <DATA ref="#user.name" optional="yes"/>
   <DATA ref="#user.home-info.address" optional="yes"/>
   <DATA ref="#user.home-info.postal" optional="yes"/>
   <DATA ref="#user.home-info.telecom.phone" optional="yes"/>
   <DATA ref="#user.business-info.postal" optional="yes"/>
   <DATA ref="#user.business-info.telecom.phone" optional="yes"/>
   <DATA ref="#user.home-info.online.email" optional="yes"/>
  </DATA-GROUP>
 </STATEMENT>
 <STATEMENT>
  <CONSEQUENCE>Lets you access your own information</CONSEQUENCE>
  <PURPOSE><customization change_preferences="yes"/></PURPOSE>
  <RECIPIENT><ours/><same/></RECIPIENT>
  <RETENTION><stated-purpose/></RETENTION>
  <DATA-GROUP>
   <DATA ref="#dynamic.miscdata">
    <CATEGORIES><uniqueid/></CATEGORIES>
   </DATA>
  </DATA-GROUP>
 </STATEMENT>
 <STATEMENT>
  <CONSEQUENCE>A site with products you would appreciate</CONSEQUENCE>
  <PURPOSE>
    <customization change_preferences="yes"/>
    <targeting change_preferences="yes"/>
  </PURPOSE>
  <RECIPIENT><ours/><same/></RECIPIENT>
  <RETENTION><stated-purpose/></RETENTION>
  <DATA-GROUP>
   <DATA ref="#user.bdate.ymd.year" optional="yes"/>
   <DATA ref="#user.gender" optional="yes"/>
  </DATA-GROUP>
 </STATEMENT>
 <STATEMENT>
  <CONSEQUENCE>A site with clothes you would appreciate</CONSEQUENCE>
  <PURPOSE><customization/><develop/></PURPOSE>
  <RECIPIENT><ours/></RECIPIENT>
  <RETENTION><indefinitely/></RETENTION>
  <DATA-GROUP>
   <DATA ref="#dynamic.cookies"><CATEGORIES><state/></CATEGORIES></DATA>
   <DATA ref="#dynamic.miscdata"><CATEGORIES><preference/></CATEGORIES></DATA>
  </DATA-GROUP>
 </STATEMENT>
</POLICY>

3.2 ポリシー

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

3.2.1 POLICY要素

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

<POLICY>

一つ以上のステートメントを含む。各ステートメントは一組のデータ要素に適用される一組の情報開示(DISCLOSURE)要素を含む。

discuri (必須の属性)

自然言語のプライバシーステートメントのURI。

policy

=

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

quoted-URI

=

`"` URI `"`

3.2.2 ENTITY要素

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

<ENTITY>

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

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

entity

=

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

entitydescription

=

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

3.2.3 ACCESS要素

<ACCESS>

個人特定可能情報を本人が閲覧し、サービス提供者に対して質問や苦情を表明することができるか否か。サービス提供者はaccess属性において一つの値を公開しなければならない。アクセス手段は特定しない。利用者のアクセスが可能な値が公開されている場合、全てのデータへのアクセスが可能であることは意味せず、アクセスが可能なデータがあること、また、どのようなデータにアクセスできるのか利用者はサービス提供者にさらに確認するべきであることを意味している。

サービス提供者は、discuriで示されたWeb以外の手段で収集された情報にアクセスする許可を与えてもよい。しかし、P3Pステートメントが扱う範囲はHTTPまたは他のWeb転送プロトコルを通して収集されるデータに限られる。また、アクセスがWeb経由で提供される場合は、セキュリティの問題は本文書の範囲外ではあるが、そのようなアクセスのために強固な認証とセキュリティメカニズムを使用することを推奨する。

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

<nonident/>

個人特定可能データは使われていない

<all/>

全ての個人特定可能情報: 全ての個人特定可能情報へのアクセスが提供されている。

<contact_and_other/>

個人特定可能な連絡先情報とその他の個人特定可能情報: 個人特定可能なオンライン連絡先情報、個人特定可能な実世界における連絡先情報、および特定個人と結びついたその他の情報へのアクセスが提供されている。

<ident_contact/>

個人特定可能な連絡先情報: 個人特定可能なオンライン連絡先情報と個人特定可能な実世界での連絡先情報へのアクセスが提供されている（例えば、利用者は住所などの情報にアクセスすることができる）。

<other_ident/>

その他の個人特定可能情報: 特定個人と結びついたその他の情報へのアクセスが提供されている（例えば、利用者は自分に課金された利用料などの情報にアクセスすることができる）。

<none/>

なし: 個人特定可能情報へのアクセスは提供していない。

access

=

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

access-disclosure

=

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

3.2.4 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]

利用者は、Webサイトを告訴することができる。

適用可能な法律(Applicable law)[law]

プライバシーステートメントに関連した係争については、ステートメントにおいて参照された法律によって解決がなされる。

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

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

検証(verification)

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

簡易表記(short-description)

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

DISPUTES要素には、人間が読むことができるLONG-DESCRIPTION要素を含むことができる。 それは適当に合法的に公開されるか、法律に適用された、または第三者的組織の名前、あるいはサービスURIにおいて示されていない利用者へのサービスとなるコンタクト情報などを含まなければならない。

<長い表記（LONG-DESCRIPTION）>

この要素は、人間が読むことができる（恐らく長い）記述を含む。

<IMG>

イメージロゴ（例えば、独立機関または関連する裁判所のイメージロゴ）のURI

src (必須の属性)

イメージロゴのURI

幅(width)

イメージロゴのピクセル幅

高さ(height)

イメージロゴのピクセル高

代替テキスト(alt)

イメージロゴに代わる短いテキスト

disputes-group

=

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

dispute

=

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

longdescription

=

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

image

=

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

quoted-string

=

`"` string `"`

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

3.2.5 REMEDIES要素

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

<REMEDIES>

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

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

<correct/>

プライバシーポリシーに関連して、エラーや不正なアクションが起こった場合、サービスによって賠償される。

<money/>

サービスプロバイダがプライバシーポリシーに違反した場合、個人に対し、人間が読むことができるプライバシーポリシー内に指定してある額、または損害賠償金を支払うであろう。

<law/>

ポリシーステートメントの違反に関する賠償方法は、人間が読むことが出来る説明で参照される法律に基づいて決定されるだろう。

remedies

=

"<REMEDIES>" 
1*remedy
*extension
"</REMEDIES>"

remedy

=

"<correct/>" | 
"<money/>"   |
"<law/>"
        

3.3 ステートメント

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

3.3.1 STATEMENT要素

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

<STATEMENT>

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

statement-block

=

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

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

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

3.3.2 CONSEQUENCE要素

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

<CONSEQUENCE>

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

consequence

=

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

3.3.3 PURPOSE要素

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

<PURPOSE>

>Webサイトに関連したデータ処理の目的

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

<current/>

現在の活動の遂行とサポート：情報は、情報提供や通信、双方向サービスなど、利用者が そのために情報を与えたところの活動を遂行するために、サービス提供者によって利用されるかも しれない。例えば、Web検索の結果の返信、電子メールの送信、商品の注文など。

<admin/>

Webサイトとシステムの管理：情報は、Webサイトとそのコンピュータシステムの 技術サポートのために利用されるかもしれない。この中には、コンピュータアカウント情報の処理 や、サイトの保守管理の過程で利用される情報の処理が含まれる。

<develop/>

調査と開発：情報は、サイトやサービス、商品、マーケットを改善したり、評価したり、 検討したりするために利用されるかもしれない。この中には、特定個人に合わせてコンテンツを 変更するために個人情報を利用することや、特定個人を評価したり、ターゲットとしたり、 プロファイルしたり、また特定個人と連絡をとったりするために個人情報を利用することは 含まれない。

<customization/>

肯定的なカスタマイズ：情報は、サイトへの1回または複数回の訪問を通じて特定個人に よって肯定的に選択された仕様に合わせてサイトのコンテンツやデザインを変更するために 利用されるかもしれない。例えば、利用者にいくつかの株式銘柄を選択させ、利用者の訪問時に それらの現在の株価を表示する金融サイトなど。

<tailoring/>

その場限りの仕立て：情報は、サイトへの1回の訪問のみで利用され、 その後のいかなるカスタマイズにも利用されない情報として、 特定個人によって肯定的に選択されていない形でサイトのコンテンツやデザインを変更するために 利用されるかもしれない。例えば、訪問者が買い物かごに入れた商品にもとづいて、 彼がその他に購入したいであろう商品を提案するオンラインショップなど。

<pseudonym/>

ペンネームプロファイル: 情報は、（名前、住所、電話番号、電子メール、IPアドレスなどの） 記録するための個人が特定可能な情報を使うことなく、個人かコンピュータ毎の個々の記録と ペンネームの記録を繋ぐために使われるかもしれない。このプロファイルは習慣や興味、 個人の特徴といった決定のために使われるかもしれないが、個人が特定可能な情報としては 使われないだろう。

<profiling/>

個人のプロファイリング：情報は、特定個人または特定コンピュータの習性や 個人特定可能情報を編集する目的で、その個人またはコンピュータに関する記録を作成するために 利用されるかもしれない。例えば、訪問者がこれまでにサイトで購入した商品にもとづいて、 彼が購入したいであろう商品を提案するオンラインショップなど。

<contact/>

サービスまたは商品のマーケティングのためにサイト訪問者と連絡をとる：情報は、 商品やサービスの販売促進のために個人と連絡をとる目的で利用されるかもしれない。 この中には、Webサイトの更新を訪問者に通知することも含まれる。

<other-purpose> string </other-purpose>

その他の利用：情報は上記の定義には当てはまらない方法で利用されるかもしれない。 （この場合、人間が読むことのできる説明を与えるべきである。）

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

change_preferences

サイトが個人に対して特定の目的に関する彼らのプリファレンスの変更を許可するか否か。既定値は「いいえ」である。「はい」の値が用いられた場合、サイトは個人に対して自分のデータをその目的では利用しないように要求するメカニズムを提供していることになる。このメカニズムの利用方法に関する情報はdiscuriの中に含まれなければならない。

yesno

=

"yes" | "no"

purpose

=

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

purposevalue

=

"<current" [change] "/>"  | ; 現在の活動の遂行とサポート
"<admin" [change]   "/>"  | ; Webサイトとシステムの管理
"<develop" [change] "/>"  | ; 調査と開発
"<contact" [change] "/>"  | ; サービスまたは商品のマーケティングのためにサイト訪問者と連絡をとる
"<customization" [change] "/>" | ; 肯定的なカスタマイズ
"<targeting" [change] "/>"     | ; その場限りのターゲット化
"<profiling" [change] "/>"     | ; 個人のプロファイリング
"<other-purpose" [change] " >" PCDATA "</other-purpose>"; その他の利用

change

=

" change_preferences=" `"` yesno `"`

ワーキンググループは、サイトが実行するかもしれない目的と実行することになっている目的との区別をサイトに許可することの可能性を、長時間議論してきた。ワーキンググループの総評は、そのような区別は必ずしも必要ないというものであった。しかし、この結論に同意しない何人かのメンバーは以下のように述べている：

ボキャブラリにおける応答の選択肢としては、「はい」、「いいえ」、および 「かもしれない（may）」の全てが必要である。もし選択肢が「いいえ」と「かもしれない」 しかなかったならば、「かもしれない」の意味は「はい」に等しいということになり、意味の乱れが 生じてしまう。「かもしれない」はその真の意味（「はい」または「いいえ」）を反映した一つの 選択肢でなければならない。もし「かもしれない」がデフォルトとして「はい」を意味している としたら、「はい」は応答の選択肢に含まれていないため、消費者は欺かれることになるだろう。 「かもしれない」は、プライバシーポリシーを理解するために消費者が参照できるこの用語 （「かもしれない」）の背後に一連の規則があることを含意するために使用されるべきである。 もし「かもしれない」が「はい」を意味するとしたら、消費者がクリックを通じてWebサイトの プライバシーポリシーを調査する可能性はもっと低くなるだろう。この「いいえ」と「かもしれない」 という一見簡素な解決策は、消費者が「いいえ」と「かもしれない」だけに絞られた選択肢の意味に おいて混乱をきたすので、電子商取引にとって重大な障壁となる可能性がある。3つの選択肢全てを 提供することはWebサイトの消費者を欺く企てにつながると主張するメンバーたちは、論点を外して いる。プライバシー保護の領域では、プライバシーポリシーを表明する際の正確性こそが、 情報の利用方法に関して消費者の信用と信頼を勝ち得るための決定的な要因なのだ。ソフトウェアの 簡潔性のために、消費者のプリファレンスの選択肢を「いいえ」と「かもしれない」に 限定することは、消費者への害悪となると同時に、プライバシーポリシーに関して消費者と正確な 意思疎通を心がけているWebサイトへの害悪ともなるだろう。

3.3.4 RECIPIENT要素

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

<RECIPIENT>

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

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

<ours/>

当組織および／または当組織の業務委託先：当組織およびその業務委託先。この場合、 業務委託先（agent）とは、表明された目的の達成のためだけにサービス提供者に代わってデータ を処理する第三者として定義される。（例えば、サービス提供者とその印刷事務所。ただし、 印刷事務所は住所ラベルを印刷し、それ以上は情報に関わりを持たない。）

<delivery/>

当組織とは異なるプラクティスに従う可能性のある配送サービス： サービス提供者のプライバシーポリシーにおいて表明された目的の遂行以外の目的でデータを 利用するかもしれない、配送サービスを行う法人組織。

<same/>

当組織のプラクティスに従う法人組織：サービス提供者と等価なプラクティスの下で、 自らのためにデータを利用する法人組織。（例えば、収集した個人情報へのアクセスを利用者に 提供し、かつ、提供された個人情報を一度利用するが保有せずに破棄してまうパートナー企業に 個人情報を提供するサービス提供者を考えてみる。サービス提供者と同様なプラクティスに従う 受領者は、個人情報を破棄するため個人情報へのアクセスを利用者に提供できないので、受領者は サービス提供者と同等なプラクティスに従っているとみなされる。）

<other-recipient/>

当組織とは異なるプラクティスに従う法人組織：サービス提供者の制約を受け、サービス 提供者に対して責任を負うが、サービス提供者のプラクティスにおいては特定されない方法で データを利用するかもしれない法人組織。（例えば、サービス提供者が収集したデータを、 その他の目的で利用するかもしれないパートナー企業に提供する場合。しかし、利用者の利益と サービス提供者の利益への侵害と考えられるような方法でデータが利用されないことを保証する ことが、サービス提供者の利益となるような場合。）

<unrelated/>

当組織と無関係な第三者：サービス提供者がそのデータ利用プラクティスについて 関知しないような法人組織。

<public/>

公のフォーラム：公のフォーラム。掲示版、公のディレクトリ、または商用CD-ROMの ディレクトリなど。

recipient

=

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

recipientvalue

=

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

サービス提供者は適合する全ての受領者を公開しなければならない。ただし、上記の6つの受領者のセットでは、データの全ての受領者が完全には表示されない場合があることに注意すること。例えば、運送業者や決済業者は、取引活動を遂行し支援するために必要であるが、異なるプラクティスに従う場合もあり、このような業務処理促進業者に関する点が問題になっていた。現在のところ、明示的にポリシー内で示すことができるのは配送サービスだけである。その他の業務処理促進業者については、元のサービス提供者との関係において彼らのプラクティスを最も正確に反映しているカテゴリにおいて表明されなければならない。ワーキンググループは配送サービスに対して特別の区分を設けることにしたが、（銀行やクレジットカード会社のような）決済業者に対しては以下のような理由でそのような措置をとらなかった：金融機関は、典型的に、金融データの使用に関して顧客と個々に合意している一方で、配送サービスの受領者はたいてい、配送サービスのプライバシーポリシーを検討する機会をもたないためである。

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

3.3.5 RETENTION要素

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

<RETENTION>

有効な保有ポリシーのタイプ

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

<no-retention/>

情報は 、オンラインでの1回のインタラクションにおいてその情報を利用するのに必要な 短い時間以上は保有されない。情報はこのインタラクションの後は消去されなければならず 、ログとして記録されたり、履歴として残されたり、その他の方法で保存されたり してはならない。このタイプの保有ポリシーは、例えば、Webサーバのログを取らない サービスや、1回のセッションで使用するためだけにクッキーを設定するサービス、 Web検索を行うために情報を収集するが検索に関するログは取らないサービスなどに 当てはまるだろう。

<stated-purpose/>

言明された目的のための保有：情報は言明された目的をかなえるために保有される。これは、 情報ができるだけ早期に破棄されることを要求するものである。サイトは、データ消去のタイム テーブルを設定した保有ポリシーを持たなければならない。保有ポリシーは、 サイトの人間が読むことのできるプライバシーポリシーに含まれるか、またはそこからリンクが 張られていなければならない。

<legal-requirement/>

法律または適用可能な法律に基づく責務による要求：情報は、言明された目的をかなえるために 保有されるが、その保有期間は、法律上の要求または責務によってそれよりも長い場合がある。 例えば、消費者が一定期間の間、取引に対して異議申立てを行うことが法律によって 認められているため、企業は責務上の理由によりその取引記録を保持しようとするかもしれない。 また、企業が監査上の目的あるいは健全性の目的で記録を保持することが、法律によって肯定的に 要求されているかもしれない。サイトはデータ消去のタイムテーブルを設定した保有ポリシーを 持たなければならない。保有ポリシーは、サイトの人間が読むことのできるプライバシー ポリシーに含まれるか、またはそこからリンクが張られていなければならない。

<business-practices/>

サービス提供者の業務プラクティスによる決定：情報は、サービス提供者の言明した 業務プラクティスに従って保有される。サイトはデータ消去のタイムテーブルを設定した 保有ポリシーを持たなければならない。保有ポリシーは、 サイトの人間が読むことのできるプライバシーポリシーに含まれるか、 またはそこからリンクが張られていなければならない。

<indefinitely/>

無期限：情報は、無期限に保有される。これは、保有ポリシーがない場合に起こるかもしれない。 受領者が公のフォーラムである場合は、これが適切な保有ポリシーである。

retention

=

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

retentionvalue

= 

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

3.3.6 DATA-GROUPとDATA要素

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

<DATA-GROUP>

送信されるか、または推測されるデータを示す

base

ref属性で示されたURI参照であるbase URI ([URI]を参照)。 この属性が省略されたときのデフォルト値はP3P基本データスキーマ(http://www.w3.org/TR/P3P/base)のURIである。属性が空文字列("")だった場合、基本はローカルのドキュメントである。

<DATA>

送信されるか、または推測されるデータを示す

ref (必須の属性)

データ要素／集合の名前を示す分割された識別部であるURI参照 ([URIを参照])。URIの一部はデータスキーマに一致するものを示す。 URIの一部が存在していない場合に備えて、もしデータ要素がデータグループ要素の中に含まれるなら、デフォルトのベースURIはベース属性のURIであると考えられる。 他の例では同じように、デフォルトベースURIは同じドキュメントを参照する([URI])と同じ。
データ要素と集合の名前が、大文字/小文字の区別をするので注意。（例えば、user.home は USER.HOME. あるいは User.Home とは異なる）。

optional

サイトがサイト訪問者に要求するデータ要素の提供が必須のものであるか否かを意味する；"no"は、そのデータ要素の提供が必須であることを意味し、"yes"はそのデータ要素の提供が必須ではないことを意味する。既定値は"no"である。このoptional属性は、ポリシーにおいてのみ使用される（データスキーマの定義においては使用されない）。P3Pは、あるデータプラクティスがオプショナルなものであることを規定するメカニズムを含んでいないことに注意すること。

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

data-group

=

"<DATA-GROUP"

[" base=" quoted-URI]

>"
1*dataref
*extension
"</DATA-GROUP>"
        

dataref

=

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

例えば、利用者の住所、データ集合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 policyを例に挙げると：

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

3.4 カテゴリ

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

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

categories

=

"<CATEGORIES>" 1*category "</CATEGORIES>"

category

=

"<physical/>"    | ; 実社会における連絡先情報
"<online/>"      | ; オンライン連絡先情報
"<uniqueid/>"    | ; ユニークな識別子
"<purchase/>"    | ; 購入情報
"<financial/>"   | ; 金融情報
"<computer/>"    | ; コンピュータ情報
"<navigation/>"  | ; ナビゲーションとクリックストリームのデータ
"<interactive/>" | ; インタラクティブデータ
"<demographic/>" | ; 人口統計学的・社会経済学的データ
"<content/>"     | ; 文章の内容
"<state/>"       | ; 状態管理メカニズム
"<political/>"   | ; 市民情報
"<health/>"      | ; 健康情報
"<preference/>"  | ; 嗜好データ
"<other/>"         ; その他

<physical/>

実社会における連絡先情報： 実社会において個人に問い合わせを行ったり、所在を突き止めることを可能にするような情報。電話番号や住所など。

<online/>

オンライン連絡先情報： インターネット上で個人に問い合せを行ったり、所在を突き止めることを可能にするような情報。電子メールアドレスなど。この情報は、ネットワークにアクセスするときに使用される特定のコンピュータには依存しないことが多い。（"Computer Information"カテゴリを参照のこと。）

<uniqueid/>

ユニークな識別子： 個人を整合的に特定するために発行された識別子。金融機関のID番号を除く。 これらは社会保障番号といった政府発行の識別子、Webサイトやサービスから発行された識別子を含む。

<purchase/>

購入情報： 商品やサービスを購入することによって積極的に生成される情報。支払方法の情報を含む。

<financial/>

金融情報： 口座、残高、支払い、借越し、購入、クレジットカード、デビットカードなどの個人の金融情報。個人による非連続した購入は、“購入情報”で説明した様に、それ単体では“金融情報”には属さない。

<computer/>

コンピュータ情報： 個人がネットワークにアクセスするときに使用しているコンピュータシステムに関する情報。IPアドレスやドメインネーム、ブラウザの種類、オペレーティングシステムなど。

<navigation/>

ナビゲーションとクリックストリームのデータ： 閲覧することによって受動的に生じるデータ。訪問したページやページごとの滞在時間など。

<interactive/>

インタラクティブデータ： Webサイトを通じた、サービス提供者との明示的なやりとりから積極的に生じるデータ。また、そのようなやりとりを反映したデータ。検索エンジンでの検索事項やアカウント活動のログなど。

<demographic/>

人口統計学的・社会経済学的データ： 個人の特徴に関する情報。性別や年齢、収入など。

<content/>

文章の内容： 通信活動に含まれる言葉や表現。電子メールの文章や掲示板への掲示内容、またチャットルームでの通信内容など。

<state/>

状態管理メカニズム： 利用者とのセッションを維持したり、また以前に特定サイトを訪問したことや特定コンテンツにアクセスしたことがある利用者を自動的に特定したりするメカニズム。HTTPクッキーなど。

<political/>

市民情報： 宗教団体、労働組合、専門的な協会、政党などの会員、または所属。

<health/>

健康情報： 健康情報：個人の肉体的または精神的健康、性的志向、ヘルスケアーサービスや製品の使用又は調査、ヘルスケアーサービスや製品の購入等に関する情報。

<preference/>

嗜好データ： 個人の好みや嫌いなものに関するデータ。好きな色や音楽の好みなど。

<location/>

位置データ: 個人の現在の物理的な位置情報とその位置の追跡のために使うことができる。

<other/>

その他： 上記の定義にあてはまらない他のデータ型。（この場合、人間が読むことのできる説明が提示されなければならない。）

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

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

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

3.4.1 固定カテゴリデータ要素/型

基本データスキーマとほとんどの要素は「固定」データ要素と呼ばれる：それらは、1つかせいぜい２つのカテゴリに属している。あるカテゴリを不変的に基本データスキーマの型、または要素に割り当てることによって、サービスと利用者は、単に対応するカテゴリを参照するだけで要素の全グループに言及することができる。例えば、利用者はプライバシープリファレンス交換言語である[APPEL]を使用して、ユーザエージェントがあるカテゴリ内のどのデータ要素も提供しないようにする規則を書くことができる。

固定データ要素に対するデータスキーマを考案する際、スキーマ考案者は、それらの要素が属するカテゴリを明確に列挙しなければならない。例えば：

<DATA-TYPE name="postal.street.line1" typeref="#text"
short-description="Street Address, Line 1">
<CATEGORIES><physical/></CATEGORIES>
</DATA-TYPE>

1つの要素や型が複数のカテゴリに属する場合、同データについて言及している複数の要素を使用することができる。例えば以下のXML表記は、user.nameのデータ要素が「実社会における連絡先情報」と「人口統計学的・社会経済学的データ」の両カテゴリを含んでいることを言明する為に使用できる：

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

固定データ要素/型のカテゴリは、変更できないことに注意すること。例えば、既存の固定基本データ要素に別のカテゴリを当てはめる規則やポリシーを書くことはできない。ユーザエージェントは、そのようなカテゴリを無視して、代わりにスキーマ定義にリストされている元のカテゴリ（あるいはカテゴリの集合）を使用しなければならない。ユーザエージェントはむしろ利用者に、固定データ要素が非標準的なカテゴリにおいて使用されることを警告してもよい。

3.4.2 可変カテゴリデータ要素/型

基本データスキーマにおける全てのデータ要素/型が、予め決まったカテゴリに属するわけではない。それらは個々の状況によって、カテゴリ領域からの情報を含むことができる。そのような要素/型は可変カテゴリデータ要素/型（あるいは短く「可変データ要素/型」）と呼ばれる。P3P基本データスキーマにおけるほとんどの可変データ要素は、dynamic.要素集合と結びついているにもかかわらず、可変データはどのデータ集合にも現れる可能性があり、固定カテゴリデータ要素と混合しさえするかもしれない。

そのような要素あるいは型に対し、スキーマ定義を考案する際、スキーマ考案者は、明確なカテゴリ属性をリストしてはならない。さもなければ、その要素/型は固定になる。例えば、状況次第でさまざまなカテゴリをとり得る"Year"データ型（例として、クレジットカード期限や生年月日で使用される場合など）を規定するとき、以下のスキーマ定義を使用できる：

<DATA-TYPE name="date.ymd.year" typeref="#number" size="6"
short-description="Year"/> <!-- Variable Data Type-->

これによって、そのような可変カテゴリデータ型を参照する新たなスキーマ拡張は、そのスキーマ拡張における使用に従って、引き出された要素に特定のカテゴリを割り当てる。例えば、こうしてE-commerceスキーマ拡張は、クレジットカード期限を以下のように定義できる：

<DATA-TYPE name="Card.ExpDate" typeref="#date.ymd"
short-description="Card Expiration Date">
<CATEGORIES><financial/></CATEGORIES>
</DATA-TYPE>

このような条件の下では、可変データ型dateは、クレジットカード期限を規定するために使用されている場合、固定カテゴリの金融機関のID番号を割り当てられる。

利用者のプリファレンスは、（可変データ要素のあらゆる使用に関するプリファレンスを効果的に表現している）付加的なカテゴリ情報なしでも、そのような可変データ要素をリストすることができるが、サービスは、自らのポリシーにおいて、可変データ要素の使用に適用するカテゴリを必ず明確に示さなければならない。この情報はポリシーでリストアップされたデータ要素のカテゴリ要素として現れなければならない。

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

ここでサービスは、このサイトではクッキーを利用者の識別のために（すなわち、ユニークな識別子として）使用することを表明している。

サービスが複数のカテゴリに属すデータ要素を宣言したい場合、単に複数回、同じカテゴリを宣言する（3.4.1で示した様に）：

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

上記の宣言により、サービスはこのサイトにおいて利用者を特定する為と利用者の嗜好データを保存する為にクッキーを使用する事を告げる。P3Pの目的においては、そのような情報が2つのクッキー又は単一のクッキーに保存されるかに関して相違が無い事に注意されたい。

3.5 拡張メカニズム

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

<EXTENSION>

シンタックスの為の拡張を説明する。

optional

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

extension

=

"<EXTENSION" [" optional=" '"' yesno '"'] ">" 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上で、拡張の説明を載せたページを提供してもよい。

4. データスキーマ

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

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

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

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

dataschema

=

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

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

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

4.1 DATA-DEFとDATA-TYPE要素

<DATA-DEF>と<DATA-TYPE>

データ要素、データ型それぞれの定義

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

name

データ要素またはデータ型の名前を示す。 データ要素とデータ型の名前が、大文字/小文字の区別をすることに注意。 例えば、user.home は USER.HOME あるいは User.Home とは異なる。 なお、データ要素と型の名前は、番号文字がドットの直後に現われることができない。

typeref

データ要素または型を示す分割された識別部であるURI参照 ([URI]を参照)。 URIの一部は定義されたデータスキーマに一致するものを示す。 通常、デフォルトベースURIは同じドキュメントを参照する([URI])と同じ。

short-description

データ要素または型の簡易表記名を表す文字列。文字数は255以下。

size

データ要素や対応する型の要素を保存するのに必要とされる文字の最大数を示す。この情報はユーザエージェントがデータの容器(レポジトリ)を能率的に構築するために有効であろう。0の既定値は、データ要素が任意に大きくなってもよいことを意味している。

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

datadef

=

"<DATA-DEF name=" quoted-string 
 [" typeref=`" URI-reference "`"]
 [" short-description=" quoted-string] 
 [" size=" `"` number `"`] ) ; デフォルトは 0 （サイズ制限なし）
 ">"
 [categories] ; データ要素のカテゴリ 
 [longdescription] ; データ要素の長い表記
"</DATA-DEF>"
        

datatype

=

"<DATA-TYPE name=" quoted-string 
 [" typeref=`" URI-reference "`"]
 [" short-description=" quoted-string] 
 [" size=" `"` number `"`] ) ; デフォルトは 0 （サイズ制限なし）
 ">"
 [categories] ; データ型のカテゴリ 
 [longdescription] ; データ型の長い表記
"</DATA-TYPE>"

例えば、HyperSpeedExample社が以下のようなデータスキーマを構築したいと考えた場合:

• 以下のような構造をしたvehicleと名付けた型:
  vehicle.model (of primitive type text)
  vehicle.color (of primitive type text)
  vehicle.built.year (of primitive type number)
  vehicle.built.where (of basic type postal)
  vehicle.price (of primitive type number)
• vehicleという型の上のcarとmotorcycleという2つのデータ要素

以下のようなコードをhttp://www.HyperSpeed.example.com/models-schemaに置くことができる。

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

この例では、car modelとconstruction yearを参照するために、サービスはP3Pプライバシーポリシー内部に以下の参照場所を掲載することができるだろう：

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

あるいは、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/P3Pv1" ... >

...
<DATA-GROUP base="">
<DATA ref="#car.model"/>
<DATA ref="#car.built.year"/>
</DATA-GROUP>
...
<DATASCHEMA>
<DATA-TYPE name="vehicle.model" 
    typeref="http://www.w3.org/TR/P3P/base#text" 
    short-description="Model" 
    size="63">
    <CATEGORIES><preference/></CATEGORIES>
</DATA-TYPE>
<DATA-TYPE name="vehicle.color" 
    typeref="http://www.w3.org/TR/P3P/base#text" 
    short-description="Color"
    size="63">
    <CATEGORIES><preference/></CATEGORIES>
</DATA-TYPE>
<DATA-TYPE name="vehicle.built.year" 
    typeref="http://www.w3.org/TR/P3P/base#number" 
    short-description="Construction Year"
    size="63">
    <CATEGORIES><preference/></CATEGORIES>
</DATA-TYPE>
<DATA-TYPE name="vehicle.built.where" 
    typeref="http://www.w3.org/TR/P3P/base#postal"
    short-description="Construction Place"
    size="63">
    <CATEGORIES><preference/></CATEGORIES>
</DATA-TYPE>
<DATA-DEF name="car" typeref="#vehicle"/>
<DATA-DEF name="motorcycle" typeref="#vehicle"/>
</DATASCHEMA>
</POLICY>

データ要素とタイプは、いずれかの固定されているカテゴリであるか否かにかかわらず分類することができる（category属性を使うことで）。スキーマ設計者がそれぞれの要素のために不変のカテゴリを定義するためにスキーマ定義の中でこの属性を使うことができる。一度定義されると、ユーザの嗜好（プリファレンス）、P3Pポリシー、あるいはその他のスキーマ定義の中でその要素を参照する時は、その値は変更されない。しかしながら、定義がされないままであればこの属性は、その要素についてそれぞれのP3Pポリシー参照の中で明白にリストされなければならない。ユーザは、同じ要素に対して、異なる属性-値に則り、異なる嗜好（プリファレンス）を持つことができる。そして、このようにデータtypesの中で属性が定義されないような場合、派生させた属性（あるいは派生させたスキーマのどんな値に対するオリジナルの定義の上書き）の中のカテゴリとして、他のスキーマ定義により明白に設定することができる。

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

4.2 データスキーマの不変性

P3Pポリシーと類似して、データスキーマにおける必須の要求条件は、データスキーマの不変性である。一つの例外を除いて、特定のURIから取得されるデータスキーマが変更されることはない。このようにして、ポリシー上のURIは、データスキーマのためのユニークな識別子として振舞いる。従って、通常新規のデータスキーマは、新規の異なるURIを使用しなければならない。この一般的な基本方針での唯一の例外は、データスキーマのために特定の言語への記号化がなされていることを適切に示すためにHTTPの"Content-Language"リクエストヘッダ領域をエンコードするサーバによって同一のデータスキーマの多言語（翻訳）版が提供される時のみである。P3Pクライアントは、キャッシュしてあったデータスキーマ（Content-Languageがある場合は、Content-Languageを含む）と、対応する新しく取得したデータスキーマ（Content-Languageがある場合は、Content-Languageを含む）を比較することによって、データスキーマの不変性をチェックしてもよい。もしユーザエージェントが、二つのデータスキーマは異なるが、同一のURIを所有していることを発見した場合、ユーザエージェントは、そのデータスキーマがContent-Languageに二つの異なる値を持っている場合以外は、そのリソースはP3Pポリシーを持たないとして扱わなければならない。

4.3 プリミティブデータ型

P3Pスキーマは、以下のデータ要素型を引用することができる。

4.4 基本データ型

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

4.4.1 日付

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

date型の全てのフィールドは、[ISO8601]の時間標準のものと同じフォーマットでなければならない。"date.ymd"と"date.hms"は、年/月/日と時/分/秒、それぞれの組の参照時間を短縮するために使用されることに注意されたい。

4.4.2 名前

personname型は、個人の名前に関する情報を指定する構造化された型である。

4.4.3 認証

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

"format"フィールドは、IANAに登録されている公開鍵、もしくは認証書のフォーマットのことである。"key"フィールドには、対応する認証鍵が含まれる。

4.4.4 電話

phonenum型は、電話番号に関する特徴を指定する構造化された型である。

4.4.5 連絡先情報

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

4.4.5.1 郵便

postal型は、郵便あて先を指定する構造化された型である。

町・番地に関する情報のために三つの異なるフィールドを使用することによって、サービス提供者とユーザエージェントは、要求中に長い住所を幾つかのラインに分割することができる。しかし、この三つのフィールドは共通のstreetを共有しているため、このstreetだけで三つのフィールドを一度に参照することができる。

"formatted"フィールドは、例えば、ラベル上に印刷されるあて先のように、配達先の住所に対応した形式化されたテキストを指定するために使用される。

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

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

4.4.5.3 オンライン

online型は、個人に関するオンライン情報を指定する構造化された型である。

4.5 基本データスキーマ

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

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

以下のテーブルでは、集合、集合内の要素、要素に関連するカテゴリ、型、簡易表記名が指定してある。我々は、可能である限り、一つの基本データ要素に対して一つのカテゴリを割り当てるように努力しましたが、一つ以上のカテゴリが固定データ要素と関連付けられているものもある。我々は、スキーマの設計者にも同じ努力を行うことを推奨する。

4.5.1 個人データ

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

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

4.5.2 第三機関データ

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

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

4.5.3 ビジネスデータ

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

4.5.4 動的データ

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

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

"clickstream.client"は、サーバが、利用者のクライアントによって収集されているオフラインでのブラウザによる閲覧情報にアクセスする場合に使用されるべきである。Microsoft社のInternet Explorerの幾つかのバージョン（5.0など）は、このような振るまいをサポートしていることで知られている。

"clickstream.server"は、今日のほとんどのWebサイトに適用されるだろう。サーバ側で、ページへのアクセスデータが保存される場合には必ずclickstream.serverが使用されなければならない。現在のほとんどのWebサーバの実装において、サーバはリクエストの発生場所（IPアドレスやDNS名）、時間、要求されたリソース、HTTPリターンコード、転送バイトなどを含むアクセスログを標準で作成する。リソース名とリクエストの発生したアドレスの組み合わせは、クリックストリームのデータ（すなわち、このデータはサイトを通した訪問者の動向を再現することを可能にする）とみなされ、宣言されるべきである。

参照（referer）ログやユーザエージェント情報（多くのブラウザによるHTTPリクエストのヘッダに含まれる）に関するログを採取する場合には、"http.useragent"と"http.referrer"データ要素を使用して、明白にその旨を宣言するべきである。

"cookies" は、後にその情報を要求する（すなわち、自動的に送信する）ために、HTTPのクッキーメカニズムを使用して、利用者のマシンに情報が置かれる場合に必ず使用しなければならない。cookiesは、可変データ要素で、ポリシー内において使用カテゴリを明白に宣言する必要があることに注意されたい。

"http.useragent"は、オペレーティングシステムやブラウザ（バージョン情報を含む）などのユーザエージェントに関する追加情報を、サーバがログに保存することを示す。

"http.referrer" は、"HTTP_REFERER"ヘッダによって示されているように、利用者が直前に閲覧したページに関する追加情報をサーバが保存することを示す。

"miscdata"要素は、特定のデータ要素を使用しないで参照を行うサービスによって収集された情報を参照する。サイトは収集するmiscdataの各カテゴリに対し、ポリシーにおいて別々にmiscdata要素を参照しなければならない。

"searchtext"は、サイトの検索と索引のために使用される特有の要求のことである。例えば、検索エンジンのページでの唯一のフィールドが検索フィールドである場合、サイトは、そのデータ要素のみを開示する必要がある。

"interactionrecord"要素は、サーバが、利用者との間での交流履歴（クリックストリームのデータ以外の情報。例えば、口座取引など）を保存する場合にのみ使用されるべきである。この要素は、利用者との間での交流履歴情報が保持されることを利用者に知らせることのみを意味し、情報がどのくらいの期間保持されるということを知らせるものではない。

上記の可変データ要素を一つでも含んでいるポリシーは、要求する情報のカテゴリを明白に宣言する。例えば、ユーザのIRC名をたずねるには、以下のXMLで使われるようなカテゴリオンライン連絡先情報に属する:

<POLICY ... >
 ...
<DATA ref="#dynamic.miscdata">
    <CATEGORIES><online/></CATEGORIES>
</DATA>
        ... 
</POLICY>

4.6 データ要素の使用について

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

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

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

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

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

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

5. 付録

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

[CHARMODEL]

Martin J. Durst, Francois Yergeau, "Character Model for the World Wide Web ," World Wide Web Consortium Working Draft. 29 November 1999.

[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]

[HTTP-EXT]

H. Frystyk, P. Leach, S. Lawrence. "Experimental RFC 2774 -- An HTTP Extension Framework," Microsoft, Agranat Systems, February 2000.

[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.

[KEY]

S. Bradner. "RFC2119-- Key words for use in RFCs to Indicate Requirement Levels." March 1997.

[MIME]

N. Freed, N. Borenstein. "RFC2045 -- MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies." November 1996.

[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. "Extensible Markup Language (XML) 1.0 Specification." World Wide Web Consortium, Recommendation. 10 February 1998.

[XML-Name]

T. Bray, D. Hollander, A. Layman. "Namespaces in XML." World Wide Web Consortium, Recommendation. 14 January 1999.

[XML-Schema1]

H. Thompson, D. Beech, M. Maloney, and N. Mendelsohn (Ed.). "XML Schema Part 1: Structures" World Wide Web Consortium Working Draft. 7 April 2000.

[XML-Schema2]

P. Biron, A. Malhotra (Ed.) "XML Schema Part 1: Datatypes" World Wide Web Consortium Working Draft. 7 April 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.

[HTML]

D. Raggett, A. Le Hors, and I. Jacobs (Eds.). "HTML 4.01 Specification" World Wide Web Consortium

[RDF]

O. Lassila and R. Swick (Ed.). "Resource Description Framework (RDF) Model and Syntax Specification." W3C Recommendation. 22 February 1999.

[UNICODE]

Unicode Consortium. "The Unicode Standard"

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

P3P基本データスキーマに相当するデータスキーマは以下のものである。我々はコードを読みやすくするために、属性名に伴ってコードを字下げし、整列させましたが、実際のスキーマ定義での空白は、文書の内容は変更されてはならないという観点（データスキーマの不変性）からみて、非常に重要な意味を持っている。規範的な実際のスキーマは次のURIにある。

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

<!-- "date" Data Type -->
<DATA-TYPE name="date.ymd.year"
    short-description="Year"
    typeref="#number"
    size="6"/>

<DATA-TYPE name="date.ymd.month"
    short-description="Month"
    typeref="#number"
    size="2"/>

<DATA-TYPE name="date.ymd.day"
    short-description="Day"
    typeref="#number"
    size="2"/>

<DATA-TYPE name="date.hms.hour"
    short-description="Hour"
    typeref="#number"
    size="2"/>

<DATA-TYPE name="date.hms.minute"
    short-description="Minutes"
    typeref="#number"
    size="2"/>

<DATA-TYPE name="date.hms.second"
    short-description="Second"
    typeref="#number"
    size="2"/>

<DATA-TYPE name="date.fractionsecond"
    short-description="Fraction of Second"
    typeref="#number"
    size="6"/>

<DATA-TYPE name="date.timezone"
    short-description="Time Zone"
    typeref="#text"
    size="10"/>

<!-- "personname" Data Type -->
<DATA-TYPE name="personname.prefix"
    short-description="Name Prefix"
    typeref="#text">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-TYPE>

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

<DATA-TYPE name="personname.middle"
    short-description="Middle Name"
    typeref="#text">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-TYPE>

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

<DATA-TYPE name="personname.suffix"
    short-description="Name Suffix"
    typeref="#text">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-TYPE>

<DATA-TYPE name="personname.formatted"
    short-description="Formatted Name"
    typeref="#text">
    <CATEGORIES><physical/><demographic/></CATEGORIES>
</DATA-TYPE>

<DATA-TYPE name="personname.nickname"
    short-description="Nickname"
    typeref="#text">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-TYPE>

<!-- "certificate" Data Type -->
<DATA-TYPE name="certificate.key"
    short-description="Certificate key"
    typeref="#binary"
    size="0">
    <CATEGORIES><uniqueid/></CATEGORIES>
</DATA-TYPE>

<DATA-TYPE name="certificate.format"
    short-description="Certificate format"
    typeref="#number"
    size="128">
    <CATEGORIES><uniqueid/></CATEGORIES>
</DATA-TYPE>

<!-- "telephonenum" Data Type -->
<DATA-TYPE name="telephonenum.intcode"
    short-description="International Telephone Code"
    typeref="#number"
    size="11">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-TYPE>

<DATA-TYPE name="telephonenum.loccode"
    short-description="Local Telephone Area Code"
    typeref="#number"
    size="11">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-TYPE>

<DATA-TYPE name="telephonenum.number"
    short-description="Telephone Number"
    typeref="#number"
    size="30">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-TYPE>

<DATA-TYPE name="telephonenum.ext"
    short-description="Telephone Extension"
    typeref="#number"
    size="11">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-TYPE>

<DATA-TYPE name="telephonenum.comment"
    short-description="Telephone Optional Comments"
    typeref="#text">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-TYPE>

<!-- "postal" Data Type -->
<DATA-TYPE name="postal.name"
    short-description="Name"
    typeref="#personname">
    <CATEGORIES><physical/><demographic/></CATEGORIES>
</DATA-TYPE>

<DATA-TYPE name="postal.street.line1"
    short-description="Street Address, Line 1"
    typeref="#text">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-TYPE>

<DATA-TYPE name="postal.street.line2"
    short-description="Street Address, Line 2"
    typeref="#text">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-TYPE>

<DATA-TYPE name="postal.street.line3"
    short-description="Street Address, Line 3"
    typeref="#text">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-TYPE>

<DATA-TYPE name="postal.city"
    short-description="City"
    typeref="#text">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-TYPE>

<DATA-TYPE name="postal.stateprov"
    short-description="State or Province"
    typeref="#text">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-TYPE>

<DATA-TYPE name="postal.postalcode"
    short-description="Postal Code"
    typeref="#text">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-TYPE>

<DATA-TYPE name="postal.organization"
    short-description="Organization Name"
    typeref="#text">
    <CATEGORIES><physical/><demographic/></CATEGORIES>
</DATA-TYPE>

<DATA-TYPE name="postal.formatted"
    short-description="Formatted Postal Address"
    typeref="#text">
    <CATEGORIES><physical/><demographic/></CATEGORIES>
</DATA-TYPE>

<DATA-TYPE name="postal.country"
    short-description="Country Name"
    typeref="#text">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-TYPE>

<DATA-TYPE name="postal.countrycode"
    short-description="Country Code"
    typeref="#countrycode"
    size="2">
   <CATEGORIES><demographic/></CATEGORIES>
</DATA-TYPE>

<!-- "telecom" Data Type -->
<DATA-TYPE name="telecom.telephone"
    short-description="Telephone Number"
    typeref="#telephonenum">
    <CATEGORIES><physical/></CATEGORIES>
</DATA-TYPE>

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

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

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

<!-- "online" Data Type -->
<DATA-TYPE name="online.email"
    short-description="Email Address"
    typeref="#text">
    <CATEGORIES><online/></CATEGORIES>
</DATA-TYPE>

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

<!-- "contact" Data Type" -->
<DATA-TYPE name="contact.postal"
    short-description="Postal Address Information"
    typeref="#postal">
    <CATEGORIES><physical/><demographic/></CATEGORIES>
</DATA-TYPE>

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

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

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

<!-- "dynamic" Data Schema -->
<DATA-DEF name="dynamic.clickstream.client"
    short-description="Client-side clickstream"
    typeref="#text">
    <CATEGORIES><navigation/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="dynamic.clickstream.server"
    short-description="Server-side clickstream"
    typeref="#text">
    <CATEGORIES><navigation/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="dynamic.cookies"
    short-description="HTTP Cookies"
    typeref="#text">
</DATA-DEF>

<DATA-DEF name="dynamic.http.useragent"
    short-description="User agent information"
    typeref="#text">
    <CATEGORIES><navigation/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="dynamic.http.referrer"
    short-description="Last URI requested by the user"
    typeref="#uri">
    <CATEGORIES><navigation/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="dynamic.miscdata"
    short-description="Other information"
    typeref="#text"/>

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

<DATA-DEF name="dynamic.interactionrecord"
    short-description="Transaction history"
    typeref="#text">
    <CATEGORIES><interactive/></CATEGORIES>
</DATA-DEF>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

</DATASCHEMA>

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

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

<?xml version='1.0'?>

<!-- XML Schema for policy reference files -->
<schema
  xmlns='http://www.w3.org/1999/XMLSchema'
  targetNamespace='http://www.w3.org/2000/P3Pv1'
  xmlns:p3pr='http://www.w3.org/2000/P3Pv1'
  xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#' >

 <element name='POLICY-REFERENCES'>
  <complexType content='elementOnly'>
   <element ref='rdf:RDF'/>
   <attribute name='xmlns:rdf' type='uriReference' use='fixed' value='http://www.w3.org/1999/02/22-rdf-syntax-ns'/>
  </complexType>
 </element>

 <element name='rdf:RDF'>
  <complexType content='elementOnly'>
   <element ref='p3pr:POLICY-REF' maxOccurs='unbounded'/>
  </complexType>
 </element>

 <element name='POLICY-REF'>
  <complexType content='elementOnly'>
   <choice maxOccurs='unbounded'>
    <element ref='p3pr:PREFIX'/>
    <element ref='p3pr:EXCLUDE'/>
    <element ref='p3pr:MEHTOD'/>
   </choice>
   <attribute name='rdf:about' type='uriReference' use='required'/>
  </complexType>
 </element>

 <element name='PREFIX'>
  <complexType content='mixed'/>
 </element>

 <element name='EXCLUDE'>
  <complexType content='mixed'/>
 </element>

 <element name='METHOD'>
  <complexType content='mixed'/>
 </element>
</schema>



<?xml version='1.0'?>
<!-- XML Schema for Policy documents -->
<schema
  xmlns='http://www.w3.org/1999/XMLSchema'
  targetNamespace='http://www.w3.org/2000/P3Pv1'
  xmlns:p3p='http://www.w3.org/2000/P3Pv1'>

 <element name='POLICY'>
  <complexType content='elementOnly'>
   <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   <element ref='p3p:ENTITY'/>
   <element ref='p3p:DISPUTES-GROUP' minOccurs='0' maxOccurs='1'/>
   <element ref='p3p:ACCESS'/>
   <element ref='p3p:STATEMENT' maxOccurs='unbounded'/>
   <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   <element ref='p3p:DATASCHEMA' minOccurs='0' maxOccurs='1'/>
   <attribute name='discuri' type='uriReference' use='required'/>
  </complexType>
 </element>

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

 <element name='DISPUTES-GROUP'>
  <complexType content='elementOnly'>
   <element ref='p3p:DISPUTES' maxOccurs='unbounded'/>
   <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
  </complexType>
 </element>

 <element name='DISPUTES'>
  <complexType content='elementOnly'>
   <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   <element ref='p3p:REMEDIES' minOccurs='0' maxOccurs='1'/>
   <element ref='p3p:IMG' minOccurs='0' maxOccurs='1'/>
   <element ref='p3p:SHORT-DESCRIPTION' minOccurs='0' maxOccurs='1'/>
   <element ref='p3p:LONG-DESCRIPTION' minOccurs='0' maxOccurs='1'/>
   <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   <attribute name='resolution-type' use='required'>
    <simpleType base='string'>
     <enumeration value='service'/>
     <enumeration value='independent'/>
     <enumeration value='court'/>
     <enumeration value='law'/>
    </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>

 <element name='REMEDIES'>
  <complexType content='elementOnly'>
   <choice maxOccurs='unbounded'>
    <element ref='p3p:correct'/>
    <element ref='p3p:money'/>
    <element ref='p3p:law'/>
   </choice>
   <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
  </complexType>
 </element>

 <element name='correct'>
  <complexType content='empty'/>
 </element>

 <element name='money'>
  <complexType content='empty'/>
 </element>

 <element name='law'>
  <complexType content='empty'/>
 </element>

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

 <element name='LONG-DESCRIPTION'>
  <complexType content='mixed'>
  </complexType>
 </element>

 <element name='ACCESS'>
  <complexType content='elementOnly'>
   <choice>
    <element ref='p3p:nonident'/>
    <element ref='p3p:ident_contact'/>
    <element ref='p3p:other_ident'/>
    <element ref='p3p:contact_and_other'/>
    <element ref='p3p:all'/>
    <element ref='p3p:none'/>
   </choice>
  </complexType>
 </element>

 <element name='nonident'>
  <complexType content='empty'/>
 </element>

<element name='ident_contact'>
  <complexType content='empty'/>
 </element>

 <element name='other_ident'>
  <complexType content='empty'/>
 </element>

 <element name='contact_and_other'>
  <complexType content='empty'/>
 </element>

 <element name='all'>
  <complexType content='empty'/>
 </element>

 <element name='none'>
  <complexType content='empty'/>
 </element>

 <element name='STATEMENT'>
  <complexType content='elementOnly'>
   <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   <element ref='p3p:CONSEQUENCE' minOccurs='0' maxOccurs='1'/>
   <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'/>
  </complexType>
 </element>

 <element name='CONSEQUENCE'>
  <complexType content='mixed'>
  </complexType>
 </element>

 <element name='PURPOSE'>
  <complexType content='elementOnly'>
   <choice maxOccurs='unbounded'>
    <element ref='p3p:current'/>
    <element ref='p3p:admin'/>
    <element ref='p3p:develop'/>
    <element ref='p3p:contact'/>
    <element ref='p3p:customization'/>
    <element ref='p3p:targeting'/>
    <element ref='p3p:profiling'/>
    <element ref='p3p:other-purpose'/>
   </choice>
   <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
  </complexType>
 </element>

 <element name='current'>
  <complexType content='empty'>
   <attribute name='change_preferences' use='default' value='no'>
    <simpleType base='string'>
     <enumeration value='yes'/>
     <enumeration value='no'/>
    </simpleType>
   </attribute>
  </complexType>
 </element>

 <element name='admin'>
  <complexType content='empty'>
   <attribute name='change_preferences' use='default' value='no'>
    <simpleType base='string'>
     <enumeration value='yes'/>
     <enumeration value='no'/>
    </simpleType>
   </attribute>
  </complexType>
 </element>

 <element name='develop'>
  <complexType content='empty'>
   <attribute name='change_preferences' use='default' value='no'>
    <simpleType base='string'>
     <enumeration value='yes'/>
     <enumeration value='no'/>
    </simpleType>
   </attribute>
  </complexType>
 </element>

 <element name='contact'>
  <complexType content='empty'>
   <attribute name='change_preferences' use='default' value='no'>
    <simpleType base='string'>
     <enumeration value='yes'/>
     <enumeration value='no'/>
    </simpleType>
   </attribute>
  </complexType>
 </element>

 <element name='customization'>
  <complexType content='empty'>
   <attribute name='change_preferences' use='default' value='no'>
    <simpleType base='string'>
     <enumeration value='yes'/>
     <enumeration value='no'/>
    </simpleType>
   </attribute>
  </complexType>
 </element>

 <element name='targeting'>
  <complexType content='empty'>
   <attribute name='change_preferences' use='default' value='no'>
    <simpleType base='string'>
     <enumeration value='yes'/>
     <enumeration value='no'/>
    </simpleType>
   </attribute>
  </complexType>
 </element>

 <element name='profiling'>
  <complexType content='empty'>
   <attribute name='change_preferences' use='default' value='no'>
    <simpleType base='string'>
     <enumeration value='yes'/>
     <enumeration value='no'/>
    </simpleType>
   </attribute>
  </complexType>
 </element>

 <element name='other-purpose'>
  <complexType content='mixed'>
   <attribute name='change_preferences' use='default' value='no'>
    <simpleType base='string'>
     <enumeration value='yes'/>
     <enumeration value='no'/>
    </simpleType>
   </attribute>
  </complexType>
 </element>

 <element name='RECIPIENT'>
  <complexType content='elementOnly'>
   <choice maxOccurs='unbounded'>
    <element ref='p3p:ours'/>
    <element ref='p3p:same'/>
    <element ref='p3p:other-recipient'/>
    <element ref='p3p:delivery'/>
    <element ref='p3p:public'/>
    <element ref='p3p:unrelated'/>
   </choice>
   <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
  </complexType>
 </element>

 <element name='ours'>
  <complexType content='empty'/>
 </element>

 <element name='same'>
  <complexType content='empty'/>
 </element>

 <element name='other-recipient'>
  <complexType content='empty'/>
 </element>

 <element name='delivery'>
  <complexType content='empty'/>
 </element>

 <element name='public'>
  <complexType content='empty'/>
 </element>

 <element name='unrelated'>
  <complexType content='empty'/>
 </element>

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

 <element name='no-retention'>
  <complexType content='empty'/>
 </element>

 <element name='stated-purpose'>
  <complexType content='empty'/>
 </element>

 <element name='legal-requirement'>
  <complexType content='empty'/>
 </element>

 <element name='indefinitely'>
  <complexType content='empty'/>
 </element>

 <element name='business-practices'>
  <complexType content='empty'/>
 </element>

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

 <element name='DATA'>
  <complexType content='mixed'>
   <choice minOccurs='0' maxOccurs='unbounded'>
    <element ref='p3p:CATEGORIES'/>
    <element ref='p3p:EXTENSION'/>
   </choice>
   <attribute name='name' type='uriReference' use='required'/>
   <attribute name='optional' use='default' value='no'>
    <simpleType base='string'>
     <enumeration value='yes'/>
     <enumeration value='no'/>
    </simpleType>
   </attribute>
  </complexType>
 </element>

 <element name='CATEGORIES'>
  <complexType content='elementOnly'>
   <choice maxOccurs='unbounded'>
    <element ref='p3p:physical'/>
    <element ref='p3p:online'/>
    <element ref='p3p:uniqueid'/>
    <element ref='p3p:purchase'/>
    <element ref='p3p:financial'/>
    <element ref='p3p:computer'/>
    <element ref='p3p:navigation'/>
    <element ref='p3p:interactive'/>
    <element ref='p3p:demographic'/>
    <element ref='p3p:content'/>
    <element ref='p3p:state'/>
    <element ref='p3p:political'/>
    <element ref='p3p:health'/>
    <element ref='p3p:preference'/>
    <element ref='p3p:location'/>
    <element ref='p3p:other'/>
   </choice>
  </complexType>
 </element>

 <element name='physical'>
  <complexType content='empty'/>
 </element>

 <element name='online'>
  <complexType content='empty'/>
 </element>

 <element name='uniqueid'>
  <complexType content='empty'/>
 </element>

 <element name='purchase'>
  <complexType content='empty'/>
 </element>

 <element name='financial'>
  <complexType content='empty'/>
 </element>

 <element name='computer'>
  <complexType content='empty'/>
 </element>

 <element name='navigation'>
  <complexType content='empty'/>
 </element>

 <element name='interactive'>
  <complexType content='empty'/>
 </element>

 <element name='demographic'>
  <complexType content='empty'/>
 </element>

 <element name='content'>
  <complexType content='empty'/>
 </element>

 <element name='state'>
  <complexType content='empty'/>
 </element>

 <element name='political'>
  <complexType content='empty'/>
 </element>

 <element name='health'>
  <complexType content='empty'/>
 </element>

 <element name='preference'>
  <complexType content='empty'/>
 </element>

 <element name='other'>
  <complexType content='empty'/>
 </element>

 <element name='EXTENSION'>
  <complexType content='mixed'>
   <attribute name='optional' use='default' value='yes'>
    <simpleType base='string'>
     <enumeration value='yes'/>
     <enumeration value='no'/>
    </simpleType>
   </attribute>
  </complexType>
 </element>
</schema>

<element name='DATASCHEMA'>
  <complexType content='elementOnly'>
   <choice minOccurs='0' maxOccurs='unbounded'>
    <element ref='p3ps:DATA-DEF'/>
    <element ref='p3ps:DATA-TYPE'/>
    <element ref='p3ps:EXTENSION'/>
   </choice>
  </complexType>
 </element>

 <element name='DATA-DEF'>
  <complexType content='elementOnly'>
    <element ref='p3ps:EXTENSION'/>
   <attribute name='name' type='uriReference' use='required'/>
   <attribute name='typeref' type='uriReference' use='required'/>
   <attribute name='short-description' type='string' use='optional'/>
   <attribute name='size' type='nonNegativeInteger' use='default' value='0'/>
  </complexType>
 </element>

<element name='DATA-TYPE'>
  <complexType content='elementOnly'>
    <element ref='p3ps:EXTENSION'/>
   <attribute name='name' type='uriReference' use='required'/>
   <attribute name='typeref' type='uriReference' use='required'/>
   <attribute name='short-description' type='string' use='optional'/>
   <attribute name='size' type='nonNegativeInteger' use='default' value='0'/>
  </complexType>
 </element>



<?xml version='1.0'?>
<!-- XML Schema for Dataschemas -->
<schema
  xmlns='http://www.w3.org/1999/XMLSchema'
  targetNamespace='http://www.w3.org/2000/P3Pv1'
  xmlns:p3ps='http://www.w3.org/2000/P3Pv1'>

 <element name='DATASCHEMA'>
  <complexType content='elementOnly'>
   <choice minOccurs='0' maxOccurs='unbounded'>
    <element ref='p3ps:DATA-DEF'/>
    <element ref='p3ps:DATA-TYPE'/>
    <element ref='p3ps:EXTENSION'/>
   </choice>
  </complexType>
 </element>

 <element name='DATA-DEF'>
  <complexType content='elementOnly'>
    <element ref='p3ps:EXTENSION'/>
   <attribute name='name' type='uriReference' use='required'/>
   <attribute name='typeref' type='uriReference' use='required'/>
   <attribute name='short-description' type='string' use='optional'/>
   <attribute name='size' type='nonNegativeInteger' use='default' value='0'/>
  </complexType>
 </element>

<element name='DATA-TYPE'>
  <complexType content='elementOnly'>
    <element ref='p3ps:EXTENSION'/>
   <attribute name='name' type='uriReference' use='required'/>
   <attribute name='typeref' type='uriReference' use='required'/>
   <attribute name='short-description' type='string' use='optional'/>
   <attribute name='size' type='nonNegativeInteger' use='default' value='0'/>
  </complexType>
 </element>

 <element name='CATEGORIES'>
  <complexType content='elementOnly'>
   <choice maxOccurs='unbounded'>
    <element ref='p3ps:physical'/>
    <element ref='p3ps:online'/>
    <element ref='p3ps:uniqueid'/>
    <element ref='p3ps:purchase'/>
    <element ref='p3ps:financial'/>
    <element ref='p3ps:computer'/>
    <element ref='p3ps:navigation'/>
    <element ref='p3ps:interactive'/>
    <element ref='p3ps:demographic'/>
    <element ref='p3ps:content'/>
    <element ref='p3ps:state'/>
    <element ref='p3ps:political'/>
    <element ref='p3ps:health'/>
    <element ref='p3ps:preference'/>
    <element ref='p3ps:other'/>
   </choice>
  </complexType>
 </element>

 <element name='physical'>
  <complexType content='empty'/>
 </element>

 <element name='online'>
  <complexType content='empty'/>
 </element>

 <element name='uniqueid'>
  <complexType content='empty'/>
 </element>

 <element name='purchase'>
  <complexType content='empty'/>
 </element>

 <element name='financial'>
  <complexType content='empty'/>
 </element>

 <element name='computer'>
  <complexType content='empty'/>
 </element>

 <element name='navigation'>
  <complexType content='empty'/>
 </element>

 <element name='interactive'>
  <complexType content='empty'/>
 </element>

 <element name='demographic'>
  <complexType content='empty'/>
 </element>

 <element name='content'>
  <complexType content='empty'/>
 </element>

 <element name='state'>
  <complexType content='empty'/>
 </element>

 <element name='political'>
  <complexType content='empty'/>
 </element>

 <element name='health'>
  <complexType content='empty'/>
 </element>

 <element name='preference'>
  <complexType content='empty'/>
 </element>

<element name='location'>
  <complexType content='empty'/>
 </element>

 <element name='other'>
  <complexType content='empty'/>
 </element>

 <element name='EXTENSION'>
  <complexType content='mixed'>
   <attribute name='optional' use='default' value='yes'>
    <simpleType base='string'>
     <enumeration value='yes'/>
     <enumeration value='no'/>
    </simpleType>
   </attribute>
  </complexType>
 </element>
</schema>

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

この付録では、ポリシー文書とデータスキーマのためのDTDを含む。 以下は、P3Pプライバシーポリシー文書のためのXML DTDである。

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

<!--  *********** POLICY ***********  -->
<!ELEMENT POLICY (EXTENSION*,
    ENTITY,
    DISPUTES-GROUP?,
    ACCESS,
    STATEMENT+,
    EXTENSION*)>
<!ATTLIST POLICY
      discuri %URI; #REQUIRED >

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

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

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

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

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

<!--  *********** ACCESS ***********  -->
<!ELEMENT ACCESS (nonident
    | ident_contact
    | other_ident
    | contact_and_other
    | all
    | none)>
<!ELEMENT nonident EMPTY>
<!ELEMENT ident_contact EMPTY>
<!ELEMENT other_ident EMPTY>
<!ELEMENT contact_and_other EMPTY>
<!ELEMENT all EMPTY>
<!ELEMENT none EMPTY>

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

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

<!--  *********** PURPOSE ***********  -->
<!ELEMENT PURPOSE ((current
    | admin
    | develop
    | contact
    | customization
    | targeting
    | profiling
    | other-purpose)+,
    EXTENSION*)>
<!ELEMENT current EMPTY>
<!ATTLIST current
      change_preferences (yes | no) "no" >
<!ELEMENT admin EMPTY>
<!ATTLIST admin
      change_preferences (yes | no) "no" >
<!ELEMENT develop EMPTY>
<!ATTLIST develop
      change_preferences (yes | no) "no" >
<!ELEMENT contact EMPTY>
<!ATTLIST contact
      change_preferences (yes | no) "no" >
<!ELEMENT customization EMPTY>
<!ATTLIST customization
      change_preferences (yes | no) "no" >
<!ELEMENT targeting EMPTY>
<!ATTLIST targeting
      change_preferences (yes | no) "no" >
<!ELEMENT profiling EMPTY>
<!ATTLIST profiling
      change_preferences (yes | no) "no" >
<!ELEMENT other-purpose (#PCDATA)>
<!ATTLIST other-purpose
      change_preferences (yes | no) "no" >

<!--  *********** RECIPIENT ***********  -->
<!ELEMENT RECIPIENT ((ours
    | same
    | other-recipient
    | delivery
    | public
    | unrelated)+,
    EXTENSION*)>
<!ELEMENT ours EMPTY>
<!ELEMENT same EMPTY>
<!ELEMENT other-recipient EMPTY>
<!ELEMENT delivery EMPTY>
<!ELEMENT public EMPTY>
<!ELEMENT unrelated EMPTY>

<!--  *********** 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 | EXTENSION)*>
<!ATTLIST DATA
     ref %URI; #REQUIRED
     optional (yes | no) "no"
     typeref %URI; #IMPLIED
     template (yes | no) "no"
     short CDATA #IMPLIED
     long CDATA #IMPLIED
     size %NUMBER; #IMPLIED >

<!--  *********** CATEGORIES ***********  -->
<!ELEMENT CATEGORIES (physical
  | online
  | uniqueid
  | purchase
  | financial
  | computer
  | navigation
  | interactive
  | demographic
  | content
  | state
  | political
  | health
  | preference
  | location
  | other)+>
<!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 location EMPTY>
<!ELEMENT other EMPTY>

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

以下はポリシー参照ファイルのDTDである。:

<!-- ************** Entities ************** -->
<!ENTITY % URI "CDATA">
<!ENTITY % RDFNS "web">
<!ENTITY % RDF "%RDFNS;:RDF">

<!-- ****** POLICY-REFERENCES ****** -->
<!ELEMENT POLICY-REFERENCES (%RDFNS;:RDF)>
<!ATTLIST POLICY-REFERENCES
      xmlns:%RDFNS; %URI; #FIXED "http://www.w3.org/1999/02/22-rdf-syntax-ns" >


<!-- ****** RDF ****** -->
<!ELEMENT %RDF; (POLICY-REF+)>

<!-- ****** POLICY-REF ****** -->
<!ELEMENT POLICY-REF (PREFIX | EXCLUDE | MEHTOD)+>
<!ATTLIST POLICY-REF
    %RDFNS;:about %URI; #REQUIRED >

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

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

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

以下はデータスキーマDTDである。:

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

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

<!--  *********** DATA ***********  -->
<!ELEMENT DATA (#PCDATA | CATEGORIES | EXTENSION)*>
<!ATTLIST DATA
     name %URI; #REQUIRED
     optional (yes | no) "no"
     typeref %URI; #REQUIRED
     template (yes | no) "no"
     short CDATA #IMPLIED
     long CDATA #IMPLIED
     size %NUMBER; "0" >

<!--  *********** CATEGORIES ***********  -->
<!ELEMENT CATEGORIES (physical
  | online
  | uniqueid
  | purchase
  | financial
  | computer
  | navigation
  | interactive
  | demographic
  | content
  | state
  | political
  | health
  | preference
  | other)+>
<!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 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>は１〜４要素を意味する）

<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ガイドライン）として公表されている。

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

情報プライバシー

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

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

• CDMA Code of Ethics & Standards of Practice: Protection of Personal Privacy
• 1981 Council of Europe Convention For the Protection of Individuals with Regard to Automatic Processing of Personal Data
• CSA--Q830-96 Model Code for the Protection of Personal Information
• Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data
• The DMA's Marketing Online Privacy Principles and Guidance and The DMA Guidelines for Ethical Business Practice
• OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data
• Online Privacy Alliance Guidelines for Online Privacy Policies

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

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

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

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

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

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

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

選択とコントロール

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

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

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

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

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

公正さと完全性

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

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

• 明確かつ曖昧でない方法で、自らの情報プラクティスを正確に表示すること。決して、利用者に誤解させることを意図した表示を行ってはならない。
• 宣言した目的でのみ情報を使用し、必要な期間のみそれを保持すること。
• 情報が正確で完全で更新されていることを保証すること。
• 責任の所在および苦情処理手段を公開すること。

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

• 利用者によって規定されたプリファレンスに従って、利用者の利益のためにのみ機能すること。
• サービス提供者のプラクティスを正確に表現すること。

セキュリティ

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

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

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

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

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

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

本仕様書はP3P仕様書ワーキンググループによって作成された。P3P仕様書ワーキンググループの参加メンバーは以下の通りである：Lorrie Cranor (AT&T、議長), Mark Ackerman (University of California, Irvine), Margareta Björksten (Nokia), Joe Coco (Microsoft), Patrick Feng (RPI), Yuichi Koike (NEC/W3C), Daniel LaLiberte (Crystaliz), Marc Langheinrich (NEC/ETH Zurich), Daniel Lim (PrivacyBank), Massimo Marchiori (W3C/MIT), Christine McKenna (Phone.com, Inc.), Paul Perry (Microsoft), Martin Presler-Marshall (IBM), Joel Reidenberg (Fordham Law School), Dave Remy (Geotrust), Ari Schwartz (CDT), Rigo Wenning (W3C), Betty Whitaker (NCR), 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)

最後に、付録8はW3Cノートの中のP3P Guiding Principlesを元に作成したものである。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.)

2 November 1999 Specification (last call)からの改訂履歴

• 誤字の訂正と、説明の追加。
• Boolean型を "true"と "false"に変更した。多数の形式的な問題を修正した。
• 多言語サポート（不変性の定義を変更した）を改善し、Content-Languageの詳しい説明を追加した。
• これまでに承認されたすべての"ボキャブラリ変更"(メンバー限定)を組み込んだ。
• P3Pノートの"P3Pガイドライン"を付録として追加した。
• RETENTION要素を追加し、change_preferencesタグを移動した。
• 「 直接参照」、「ポリシーと参照に関するキャッシュの可能性」の節を追加し、「信頼できるキャッシュ」を追加した。
• LINKタグをmetaタグに変更した。ASSURANCEをDISPUTESに変更した。受領者の中に「配送サービス」を追加した。
• 現在、拡張メカニズムでは、多くのポリシーとデータスキーマ要素内部に挿入されることが出来る拡張を許可する。OPT-EXTENSIONとMAN-EXTENSIONタグはEXTENSIONタグに統一された。
• XMLスキーマ付録、DTD付録、RDFデータモデル付録を追加した。
• 全てのxml-langを削除した。CONSEQUENCE-GROUP要素を削除した。
• verification属性を追加した。
• 新規にpurchase、politicalとhealthカテゴリを追加した。interactiveとfinancialカテゴリの意味を変更した。
• REMEDIES要素を追加した。
• entity属性を構造化されたENTITY要素に変更した。
• 基本データスキーマ：新規にthirdpartyとbusinessデータ集合を追加。Countryをcountrycodeに変更。personname.first と personname.lastはpersonname.given と personname.familyにそれぞれ変更。
• DISPUTES要素内。description属性をshort-description属性とLONG-DESCRIPTION要素に置換。新しいIMG で画像イメージの記述を分けた。
• DATA要素のshort と long属性をshort-description属性とLONG-DESCRIPTION 要素に変更。
• データと型の参照をURI参照を使った形式に変更。base属性をDATA-GROUPに変更;
• ポリシーとWebオブジェクトを関連づけるために、独立したXMLポリシー参照ファイルを使った。それにより、時間制御の期限切れを変更。HTTPアクセス方法を考慮した精巧な制御。
• DISCLOSURE要素の削除。それはdiscuri属性がPOLICY要素に移動したから。その属性accessは要素のACCESSに変更し、比較する値は個別の要素に変更した。
• カテゴリは、個別の要素で表現するようにした。
• <pseudonym>目的を追加した。
• P3Pポリシー参照ファイルのための"周知の存在場所"といったコンセプトを追加