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

W3C勧告案 2002年1月28日

この版:

http://www.w3.org/TR/2002/PR-P3P-20020128/

最新公開版:

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

旧版:

http://www.w3.org/TR/2001/WD-P3P-20010928/

編集者:

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

著者:

Lorrie Cranor, AT&T

Marc Langheinrich, ETH Zurich

Massimo Marchiori, W3C/MIT/UNIVE

Martin Presler-Marshall, IBM

Joseph Reagle, W3C/MIT

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

---

要旨

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

本文書の位置付け

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

本書はPlatform for Privacy Preferences 1.0 (P3P1.0) 仕様書の2002年1月28日勧告案 である。本勧告のレビュー期間は2002年2月25日に終了する。本文書はP3P仕様ワーキンググループ （メンバーのみ）がP3Pの活動の一環として作成したものである。

W3C諮問委員会の代表者は本仕様書をレビューし、そのコメントをp3p-review@w3.orgへ返信することを推奨する。これはW3Cのチームのみが見ることができる。

レビュー後、W3Cのディレクターが文書の最終的な処理を告知する。つまり、その文書が（恐らく細かい部分を修正した）W3Cの勧告になり、ワーキングドラフトの位置付けに戻るか、W3Cの作業項目として落とされるか、ということである。この告知はレビュー終了後、14日より早く行われることはない。

参考のため、本文書の末尾に9月28日ラストコールワーキングドラフトから修正された部分の概略を記した変更ログを掲載している。

コメントはwww-p3p-public-comments@w3.org へ送られたし。 (公的なコメントの保管先）

勧告案として発行しても、W3Cの全会員によって承認されたわけではない。つまり、本文書は他の文書によりいつでも改版、置換、 または陳腐化する可能性があるということである。現在公開のW3Cワーキングドラフトのリストはhttp://www.w3.org/TRに掲載している。

目次

1. 序論
   1. P3P1.0仕様書
      1. P3P1.0の最終目的と可能性
      2. P3P利用例
      3. P3Pポリシー
      4. P3Pユーザエージェント
      5. サーバ上でのP3Pの実装
      6. P3Pの将来バージョン
   2. 本仕様書について
   3. 専門用語
2. ポリシー参照
   1. ポリシー参照の概要と目的
   2. ポリシー参照ファイルの存在場所
      1. 周知の存在場所
      2. HTTPヘッダ
      3. HTML linkタグ
      4. XHTML linkタグ
      5. HTTPポートおよびその他のプロトコル
   3. ポリシー参照ファイルの構文とセマンティクス
      1. ポリシー参照ファイルの例
      2. ポリシー参照ファイルの定義
         1. ポリシー参照ファイルの処理
            1. 順序の意義
            2. ポリシー参照ファイルのワイルドカード
         2. METAとPOLICY-REFERENCES要素
         3. ポリシー参照ファイルの有効期限とEXPIRY要素
            1. モチベーションとメカニズム
            2. EXPIRY要素
            3. ポリシーとポリシー参照ファイルの要求
            4. ポリシー参照ファイルおよびポリシーの有効期限のエラー処理
         4. POLICY-REF要素
         5. INCLUDEとEXCLUDE要素
         6. HINT要素
         7. COOKIE-INCLUDEとCOOKIE-EXCLUDE要素
         8. METHOD要素
      3. ポリシーをURIへ適用
      4. フォームおよび関連するメカニズム
   4. 追加要求項目
      1. 一義性
      2. 多言語
      3. セーフゾーン
      4. ユーザエージェントによるポリシーとポリシー参照ファイルの処理
      5. ポリシーの送信に関するセキュリティ
      6. ポリシーの改版
      7. ポリシー参照ファイルがない場合
      8. 非同期の評価
   5. シナリオの例
3. ポリシーの構文とセマンティクス
   1. ポリシーの例
      1. 自然言語のポリシー
      2. ポリシーのXML符号化
   2. ポリシー
      1. POLICIES要素
      2. POLICY要素
      3. TEST要素
      4. ENTITY要素
      5. ACCESS要素
      6. DISPUTES要素
      7. REMEDIES要素
   3. ステートメント
      1. STATEMENT要素
      2. CONSEQUENCE要素
      3. NON-IDENTIFIABLE要素
      4. PURPOSE要素
      5. RECIPIENT要素
      6. RETENTION要素
      7. DATA-GROUPとDATA要素
   4. カテゴリとCATEGORIES要素
   5. 拡張メカニズム:EXTENSION要素
   6. ユーザプリファレンス
4. コンパクトポリシー
   1. コンパクトポリシーの参照
   2. コンパクトポリシーのボキャブラリ
      1. コンパクトなACCESS
      2. コンパクトなDISPUTES
      3. コンパクトなREMEDIES
      4. コンパクトなNON-IDENTIFIABLE
      5. コンパクトなPURPOSE
      6. コンパクトなRECIPIENT
      7. コンパクトなRETENTION
      8. コンパクトなCATEGORIES
      9. コンパクトなTEST
   3. コンパクトポリシーの範囲
   4. コンパクトポリシーの有効期限
   5. P3Pポリシーをコンパクトポリシーへ変換する
   6. コンパクトポリシーをP3Pポリシーへ変換する
5. データスキーマ
   1. データスキーマのための自然言語のサポート
   2. データ構造
   3. DATA-DEFとDATA-STRUCT要素
      1. P3Pデータスキーマのカテゴリ
      2. P3Pデータスキーマの例
      3. データ要素の名前の使用
   4. データスキーマの持続有効性
   5. 基本データ型
      1. 日付
      2. 名前
      3. ログイン
      4. 認証
      5. 電話
      6. 連絡先情報
         1. 郵便
         2. テレコミュニケーション
         3. オンライン
      7. アクセスログとインターネットアドレス
         1. URI
         2. ipaddr
         3. アクセスログ情報
         4. その他HTTPプロトコル情報
   6. 基本データスキーマ
      1. 個人データ
      2. 第三者機関データ
      3. ビジネスデータ
      4. 動的データ
   7. カテゴリおよびデータ要素/構造
      1. 固定カテゴリデータ要素/構造
      2. 可変カテゴリデータ要素/構造
   8. データ要素の使用
6. 付録
   付録 1：参考文献（標準準拠）
   付録 2：参考文献 （標準非準拠）
   付録 3：P3P基本データスキーマ定義（標準準拠）
   付録 4：XMLスキーマ定義（標準準拠）
   付録 5：XML DTD 定義（標準非準拠）
   付録 6：ABNF表記法（標準非準拠）
   付録 7：P3Pガイドライン（標準非準拠）
   付録 8：ワーキンググループ貢献者（標準非準拠）

1. 序論

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

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

1.1 P3P1.0仕様書

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

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

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

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

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

1.1.2 P3P利用例

P3Pを理解する為、P3Pを利用する一つの事例を考えてみよう。花子さんは、CatalogExample社(そのURLがhttp://www.catalog.example.com/)と呼ばれるあるサイトを見ようと思ったと仮定し、そのCatalogExample社は総てのページにP3Pポリシーを附加しているものと仮定する、更に、花子さんは、P3P対応のブラウザを利用しているものとする。

花子さんが、ブラウザ上でCatalogExample社のURLを指定したとすると、CatalogExample社からホームページ情報を返すとき、花子さんのWebブラウザは自動的にそのページに対応したP3Pポリシーを持ってくる。そのポリシーには、当該ページでは標準のHTTPアクセスログに含まれるデータのみを収集すると記述しているものとする。花子さんのブラウザは、そのポリシーを予め花子さんがブラウザに与えておいたプリファレンスと照合し、そのポリシーが受け入れ可能か、又は、花子さんに通知すべきかチェックする。そのポリシーが受け入れ可能だったと仮定すると、この場合、ホームページは、如何なるポップアップメッセージも表示されること無しに表示される。多分、ウィンドウの片隅に小さなアイコンが表示され、サイトからプライバシーポリシーが提示され、そのポリシーは、彼女のプリファレンスに合致していることを示すであろう。

次に、花子さんが、当該サイトのオンラインカタログのリンクを選択したとすると、当該サイトのカタログ部分で少し複雑なソフトウェアが実行されるようになっていて、このソフトウェアがショツピングカート機能を実現する為に、クッキーを用いていたとすると、当該Webサイトのこの部分は、より多くの情報を収集するので、Webサーバは、花子さんのブラウザに新しいP3Pポリシーを送信する。この場合においても、当該ポリシーが花子さんのプリファレンスに合致したと仮定すると、何のポップアップメッセージが表示されることなく、花子さんは、操作を継続でき、何かを購入したりして、最後にチェックアウトページに進むことができる。

CatalogExample社のチェックアウトページは、何らかの追加情報を必要とする。例えば、花子さんの名前、住所、クレジットカード番号及び電話番号等である。この場合、当該Webサイトは、どんなデータをここで収集し、ここで収集した彼女のデータは、彼女の注文を処理する為にのみ使用すること等を記述した新しいP3Pポリシーを送信する。

花子さんのブラウザは、このP3Pポリシーを調べ、例えば、花子さんが、ブラウザにもしも、電話番号の要求があったならば、警告を通知するよう設定しているならば、ポップアップメッセージで、電話番号が要求されていることを通知し、かつ、P3Pステートメントの内容についても説明する。そこで、花子さんは、要求されたものが受け入れ可能か否か判断することができ、もし、受け入れ可能であるならば、彼女は、注文操作を継続することができ、受け入れることができないならば、トランザクションをキャンセルすることができる。

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

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

1.1.3 P3Pポリシー

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

P3Pポリシーは、サイトがプライバシー情報を如何に取り扱うかを表現する。しかし、電気通信プロバイダやインターネットサービスのプロバイダやプロキシ、その他の中間業者が、サイトと利用者との間のプライバシーデータ交換に関与するが、それらの中間業者が何を行っているかについて、サイトのポリシーは関与しない。また、各P3Pポリシーはポリシー参照ファイルにリストされている特定のWebリソース（Webページや画像、クッキーなど）に適用されることに注意。複数のP3PポリシーをWebサイトに配置するため、会社や組織は、彼らのポリシー参照ファイルに記述されていないその他のWebリソースやP3PポリシーがカバーしいるWebサイトに収集されたデータを含まないその他のオンライン作業、または、オフライン作業に関係しているプライバシーに関する処理については述べない。

1.1.4 P3Pユーザエージェント

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

P3P1.0仕様はP3Pユーザエージェントのユーザインターフェースに関する要件をほとんど提起しない。そのため、ユーザエージェント実装者はWebサイトのプライバシーポリシーについての情報をユーザに提供するために表す言葉やシンボルを独自に選択できる。実装者はユーザインターフェースで本仕様の言葉通りに定義を使用する必要はない。しかし、ユーザに提供する情報を付録 7：”P3Pガイドライン（標準非準拠）”に従ってすべて正確に表現することを確実に行うべきである。

1.1.5 サーバ上でのP3Pの実装

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

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

1.1.6 P3Pの将来バージョン

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

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

1.2 本仕様書について

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

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

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

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

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

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

「〜してもよい」

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

2.2.2章, 2.2.3章および 4章を除いて、P3P仕様は ネーム空間構文(cf. [XML] および [XML-Name])でXMLを定義する。コンパクトにするため、以下では、"ネーム空間を使用してのXML"という意味で"XML"ということにする。

BFNのような記述も本仕様の中で使用されている。本仕様書で用いられている[ABNF]記述は、RFC2234 に従ったものであり、その概略を付録 6に示す。しかし、XML構文の場合、そういったABNF構文は可読性（例えば、空白規則や引用符（’）や（”）などを使用して引用したり、文字拡張や、コメント、大文字小文字の区別、属性の順序、ネーム空間の処理など、XMLに絶対的に含まれている構文的な融通性がない）を向上させるために使用される文法表現であるため、標準準拠の値がない。本仕様書で定義されているXML構文はすべて、自然言語を使用して本仕様で表現しているその他の制約と一緒に、標準準拠の定義を構成するP3PのXMLスキーマに従わなければならない（付録4)を参照）。

P3Pファイルが有効であることを確認するために、付録 5の（標準非準拠）のDTDを使用してもよいが、ネーム空間の使用が原因で、DTDに照合すると、有効なファイルが拒否される場合がある。

本仕様で定義している非XML構文に関する限り、（P3PのHTTPヘッダを定義している2.2.2章、HTMLでのP3Pの使用について定義している2.2.3章、そして、コンパクトポリシーを定義している4章）代わりに、（自然言語を使用して本仕様で表現しているその他の制約と一緒に）ABNF記述が標準準拠の定義を構成する。

1.3 専門用語

文字

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

データ要素

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

データカテゴリ

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

データ集合

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

データスキーマ

P3P1.0 DATASCHEMA 要素を使用して定義した要素と集合の集まり。 P3P1.0はP3P基本データスキーマという標準のデータスキーマを定義する。

データ構造

データ要素の集合の階層的な記述。データ集合はそのデータ構造に従って記述される。P3P1.0はP3P基本データスキーマにデータ集合を記述するために使用される。

等価なプラクティス

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

特定されたデータ

個人を特定する為にデータ収集者が妥当に使用することのできるデータ

ポリシー

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

プラクティス

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

プリファレンス

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

目的

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

レポジトリ

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

リソース

URIが識別できるネットワークのデータオブジェクトやサービスのこと。リソースは複数の表現（例えば、多言語や、データフォーマット、サイズ、解像度など）で利用可能であるか、方法によって異なることがある。

セーフゾーン

サービス提供者が最低限のデータ収集をおこなうWebサイトの一部であり、個人を妥当に特定しない方法の場合にのみ収集されたデータ使用される。

サービス

ポリシーを発行し、必要ならデータ要求を行うプログラムをいう。 この定義に従えば、サービスは、サーバ(サイト)、ローカルアプリケーション、ローカルに動くアクティブコード(ActiveXコントロールやJavaアプレット等)や 他のユーザエージェントであってもよい。しかし、一般的にはサービスはWebサイトである。本仕様では、”サービス”という用語と”Webサイト”という用語を互換性があるように使用している。

サービス提供者(データ管理者、組織)

Webサイトを使って情報やプロダクトを提供し、情報を収集し、プラクティスステートメントを作成し掲示する人、もしくは、組織をいう。

ステートメント

P3Pステートメントは、データ要素の収集を行うときに開示されるプライバシープラクティスの集合である。

URI

Webリソースを特定する為に用いられるUniform Resource Identifierをいう。 URIの構文及びセマンティクスに関する詳細は付録の[URI]を参照されたい。XMLやHTMLに書かれたURIは、[CHARMODEL]のCharacter Encoding in URI References章で定義されたように取り扱われるとみなす。 このことは、HTTPヘッダに含まれるURI参照を適用するものではなく、URIはHTTPヘッダでいつも逃れるべきである。

利用者

サービスを利用し、個人情報を有する個人(または、単体の様に行動する人々のグループ)をいう。P3Pポリシーはこの個人やグループについての個人データの集合と使用を記述している。

ユーザエージェント

利用者の代りに、ユーザプリファレンスに基づいて、サービスとのやりとりを仲介することを目的に作られたプログラムをいう。 一人の利用者が複数のユーザエージェントを持つことができ、また、ユーザエージェントは、必ずしもデスクトップ上に存在しなければならないことはないが、総てのユーザエージェントは利用者だけの利益のために動作し、利用者の管理下になければならない。 このような利用者とユーザエージェントの信頼関係は、P3P外部の制約によって左右されるかもしれない。 例えば、あるユーザエージェントは、オペレーティングシステムやWebクライアントの一部として、また、ISPやプライバシー代行業者の契約条項の一部として、 信頼されるかもしれない。

2. ポリシー参照

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

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

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

ポリシー参照ファイルはURLスペースのある領域とP3Pポリシーの対応づけのために使用される。また、ポリシー参照ファイルは一つのWeb文書や、サイトの一部または全サイトのためにポリシーを指定することができるネーム空間を持つXMLファイル([XML]と[XML-Name]を参照のこと)である。ポリシー参照ファイルは複数のP3Pポリシーを参照することがある。そして、たとえ異なるP3Pポリシーがサイトの異なる部分を適用するとしてもポリシー参照ファイルが複数のP3Pポリシーを参照することによって一つの参照ファイルが全サイトをカバーできる。 ポリシー参照ファイルは以下のどれか、もしくはすべてのステートメントを作成するために使用される。

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

これらのステートメントのすべてはポリシー参照ファイルの主要部分に作成されている。

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

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

ポリシー参照ファイルの存在場所は4つのメカニズムの内の一つを使って示す事ができる。ポリシー参照ファイルは

1. 周知の存在場所にあるか、
2. 文書はHTML LINKタグでポリシー参照ファイルを示しているか、
3. 文書はXHTML LINKタグでポリシー参照ファイルを示しているか、
4. 文書はHTTPヘッダを通してポリシー参照ファイルを示している。

ユーザエージェントがHTTPを使用してHTML（XHTML）コンテンツの検索をサポートする場合、ユーザエージェントは上記、1、2、3（それぞれ、4つ）のメカニズムすべてを互換的に処理しなければならないことに注意すること。一義性の要求事項も参照すること。

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

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

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

2.2.1 周知の存在場所

P3Pを使っているWebサイトはポリシー参照ファイルを"周知の"存在場所に置いてもよい（これを強く推奨する）。このために、ポリシー参照ファイルは、パス/w3c/p3p.xmlのサイト上で利用可能になる。

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

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

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

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

2.2.2 HTTPヘッダ

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

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

p3p-header

=

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

p3p-header-field

=

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

policy-ref-field

=

`policyref="` URI-reference `"`

extension-field

=

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

その他のHTTPヘッダに従うために、いかなるケーシングでもこのヘッダのP3P部分を書き込まれることがある。コンテンツはケーシングを正確に使用して指定されるべきである。

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

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

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

例 2.1:

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

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

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

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

2.2.3 HTML linkタグ

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

linkタグは、P3Pヘッダを使用して表現されるポリシー参照情報を符号化する。linkタグは以下の形式をとる(ここで、linkタグのためにありうる一つのABNF形式を作成し、そういったタグがHTMLファイルに使用される際に[HTML] 構文規則が使用できると仮定する。）

p3p-link-tag

=

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

href属性は相対URIであり、その相対URIは要求URIと関連していると解釈される。

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

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

最後に、p3p-link-tagはHTML文書に埋め込まれているので、その文字の符号化はHTML文書の文字の符号化と同じになる。 P3Pポリシーとポリシー参照文書（下の2.3章と3章)とを対照すると、p3p-link-tagは[UTF-8]を使って符号化する必要はない。また、linkタグは大文字小文字を区別しないことに注意。

2.2.4 XHTMLlinkタグ

HTMLリンクタグがどのように見られるかということに応じて、P3PはXHTML（(cf. [XHTML-MOD])もサポートする。サーバはXHTML リンクモジュール(cf. [XHTML-MOD]の5.19章 ）を使用して、埋め込まれたXHTML linkで関連するP3Pポリシー参照ファイルの場所を示すXHTMLコンテンツを取り扱ってもよい。HTMLの場合と同じ様に、以下を設定することによって、XHTMLlinkは、P3Pヘッダを使用してポリシー参照ファイルを符号化するために使用することができる。

• rel属性を"P3Pv1"に設定する。
• href属性を関連するP3Pポリシー参照ファイルのURI に設定する。

2.2.5 HTTPポートおよびその他のプロトコル

ここで記述するメカニズムを根本的なプロトコルでのHTTPトランザクション用に使用してもよい。これにはSSL接続での暗号化されたHTTP、ネットワーク設計者が実装したいと考えているその他の通信プロトコルでのHTTPと同様にTCP/IPでのテキストHTTPも含まれている。

RFC 2396 [URI]で述べているように、URLにはネットワークポート番号を含んでもよい。P3Pの目的に対して単一のホストの異なるポートは別々の”サイト”と考えなければならない。そのため、例えば、SSLでアクセスすると、（SSL通信はデフォルト443という異なるポート上で行われるので）ポート80(http://www.example.com/w3c/p3p.xml) 上のwww.example.comの周知の存在場所にあるポリシー参照ファイルはwww.example.comに適用するポリシーについての情報を全く提供しない。

本文書はHTTP以外の方法を使用して検索された文書にP3Pポリシーがどのように関連付けられるのかを述べてはいないが、その他のプロトコルで取り出された文書とP3Pポリシーを関連付けるメカニズムの将来の開発をはばむものではない。さらに、HTTPを使用して検索された文書とP3Pポリシーを関連付ける方法が将来開発されるかもしれない。

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

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

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

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

1. P3Pポリシー /P3P/Policies.xml#firstを、/catalog、/cgi-bin、または、/servletで始まるパスを持つリソースを除くサイト全体に適用する。
2. P3Pポリシー /P3P/Policies.xml#secondを、/catalogで始まるパスを持つリソースすべてに適用する。
3. P3Pポリシー /P3P/Policies.xml#thirdを、/servlet/unknownを除く、/cgi-binと/servletで始まるパスを持つリソースすべてに適用する。
4. どのP3Pポリシーが/servlet/unknownに適用されるかのステートメントはない。
5. ステートメントは2日間有効である。

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

例 2.2:

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

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

    <POLICY-REF about="/P3P/Policies.xml#second">
      <INCLUDE>/catalog/*</INCLUDE>
    </POLICY-REF>

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

 </POLICY-REFERENCES>
</META>

また、この例に文書の中にEXPIRY相対有効期限がある。(cf. 2.3.2.3.2章)

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

この章では、P3Pポリシー参照ファイルの構文とセマンティクスを定義する。全てのポリシー参照ファイルは、[UTF-8]を使用して符号化されなければならない。 P3Pサーバは、この構文を使用してポリシー参照を符号化しなければならない。

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

2.3.2.1.1 順序の意義

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

各POLICY-REFにはINCLUDE要素やEXCLUDE要素、METHOD要素、COOKIE-INCLUDE要素、そしてCOOKIE-EXCLUDE 要素など複数の要素が含まれていることがあり、与えられたURIへPOLICY-REFが適用するかどうかを決めるために、与えられたPOLICY-REF内にあるこれらの要素はすべてまとめて考えなければならない。そのため、EXCLUDE要素やMETHOD要素はPOLICY-REFが一致しなかった変更子としての働きをすることがあるので、与えられたURIと一致するINCLUDE要素を検索するだけでは充分ではない。

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

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

• policy-refファイルに表されているURIを、[URI]で書かれているように適切にエスケープしなければならない。 しかし、以下は除く。
  • URIのリテラルな '*' はポリシー参照ファイル内でエスケープしなければならない。(つまり、それは"%2A"として表示されなければならない) ポリシー参照ファイル内のURIに存在する'*'はアスタリスクワイルドカードの表示として利用される。
  • 従って、P3Pユーザエージェントは 、内部的に表示されているURIと比べる前で、アスタリスクワイルドカーととして存在するリテラルな'*'を認識するしたすぐ後に、[URI]に従って、ポリシー参照ファイルの与えられたURIを適切にアンエスケープしなければならない。

URIのエスケープとアンエスケープは使用されている実際のスキームに非常に依存し、単一のスキーム内の個々のコンポーネントによっても違ってくる。そのため、エスケープする必要のある文字のための規則は易しいものではない。エスケープ処理の詳細については直接[URI] を参照下さい。P3Pユーザエージェントは[URI]と一致しないURIパターンはいづれも無視してよい。

ワイルドカード文字をINCLUDE および EXCLUDE 要素、 COOKIE-INCLUDE および COOKIE-EXCLUDE 要素、HINT要素で使用してもよい。

2.3.2.2 META および POLICY-REFERENCES 要素

<META>

META要素は、完全なポリシー参照ファイルを含む。任意に一つのPOLICIES要素はあとに続くことができる。また、METAはコンテンツが表現される言語を述べるために、xml:lang属性(2.4.2章を参照のこと) と同様に複数のEXTENSION 要素 (cf. 3.5章を参照のこと)を含むことができる。

<POLICY-REFERENCES>

この要素は一つ以上のPOLICY-REF（ポリシー参照）を含んでいてもよい。 また一つのEXPIRY要素（その有効期限を示している）や複数のHINT要素、そして、複数のEXTENSION 要素 (cf. 3.5章)を含んでもよい。

prf

=

`<META xmlns="http://www.w3.org/2002/01/P3Pv1"` [xml-lang] `>`
*extension
policyrefs
[policies]
*extension
"</META>"

policyrefs

=

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

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

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

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

このような長所を生かすために、ポリシー参照ファイルはその有効期限を示すEXPIRY要素を含むべきである。ポリシー参照ファイルがEXPIRY要素を含んでいないとその有効期限は24時間になる。

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

ポリシー参照ファイルの有効期限を示すために使用されるものと同じメカニズムがP3Pポリシーの有効期限を示すのにも使用される。そのため、同様にP3PのPOLICIES要素は関連するEXPIRY要素を持つべきであった。この有効期限はPOLICIES要素内に含まれるP3Pポリシー全部に適用する。P3Pポリシーと関連するEXPIRY要素がない場合は24時間の有効期限となる。

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

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

ユーザエージェントが有効期限の切れていないポリシー参照ファイルまたはポリシーファイルを再び取り出す必要はないが、 "セーフゾーン"プラクティスを使用する必要性を避ける為に、ポリシー参照ファイルの有効期限が切れる前にファイルを更新してもよいことに注意。有効なP3Pユーザエーンジェントの実装にはポリシーやポリシー参照ファイルのキャッシュを含める必要はないが、そうすればより性能はよくなる。

2.3.2.3.2 EXPIRY 要素

ポリシー参照ファイル（またはポリシーが）がいつまで有効かという事を示すためにEXPIRY要素はポリシー参照ファイルおよび/またはPOLICIES要素で使用できる。有効期限の有効期は絶対的有効期限または相対的有効期限として与えられる。絶対的有効期限は、GMTによって与えられる期間であり、ポリシー参照ファイル（またはポリシーが）が有効であるまでの期間である。相対的有効期限はポリシー参照ファイル（またはポリシーが）が有効であるための時間（秒）を与える。この相対的有効期限はクライアントがポリシー参照ファイル（またはポリシーが）を要求したか、最後に再確認した時間に相当する。この計算法はオリジナルの要求または再確認の時間と現時間を使用して行わなければならない。そしてこの両方の時間はクライアントの時計で計った時間を使用しなければならない。再確認は[HTTP1.1]のの13.3章で述べている。

相対的有効期限の最低限の時間は24時間、または、86400秒である。86400秒より少ない相対的有効期限はクライアントの実装で86400秒と同じ扱いをしなければならない。クライアントが過去に絶対的有効期限に遭遇している場合、あたかも使用可能なポリシー参照ファイル（またはポリシー）がないかのように動作しなければならない。その場合の必要な手順に関しては2.4.7章の”ポリシー参照ファイルがない場合”を参照のこと。

expiry

=

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

absdate

=

`date="` HTTP-date `"`

reldate

=

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

2.3.2.3.3 ポリシーとポリシー参照ファイルの要求

実際のネットワークではポリシーとポリシー参照ファイルを隠すキャッシュがあることがある。これは全体的なネットワークのパフォーマンスを上げるのに良いことではあるが、適切に使用しないとP3Pの操作に悪影響を及ぼすことがある。それには二つの懸念がある。

1. ユーザエージェントがポリシー参照ファイル（またはポリシー）を受信する際、キャッシングプロキシ( [CACHING]を参照)から行われる場合、ユーザエージェントはポリシー参照ファイルやポリシーがどのくらいの期間そのキャッシングプロキシに存在するのかを知る必要がある。この期間は相対的有効期限を使用するポリシーまたはポリシー参照ファイルの有効期限から引かなければならない。
2. ユーザエージェントがポリシー参照ファイル（またはポリシー）を再確認する必要がある際、再確認することがポリシー参照ファイル（またはポリシー）の現バージョンを取り出すことになることを確認する必要がある。例えば、ユーザエージェントが1日の相対的有効期限をもつポリシー参照ファイルを保持している場合を考える。そのファイルをユーザエージェントがキャッシングプロキシから再度取り出した場合、そのファイルは3日間ネットワークキャッシュに存在し、その結果そのファイルは無駄になる。

HTTP1.1[HTTP1.1] には強力なキャッシュ制御メカニズムがあり、クライアントはネットワークキャッシュの操作に必要事項を導入することができる。このメカニズムは上記で述べた問題を解決できる。その方法は以下に述べる。

しかし、HTTP1.0にはそういった高度なキャッシュ制御メカニズムがない。HTTP1.0のネットワークキャッシュは恐らく最後にファイルを変更した日にちを元にしてポリシー参照ファイル（またはポリシー）の有効期限を計算することになるだろう。そして結果としてできたキャッシュの有効期限はEXPIRY要素で指定したものよりも非常に長くなるだろう。そのため、キャッシングプロキシはポリシー参照ファイル（またはポリシー）をクライアントへEXPIRYの有効期限を超えて提供するかもしれない。その結果、ユーザエージェントは無駄なポリシー参照ファイル（またはポリシー）を受けとることになるだろう。

HTTP1.0キャッシングプロキシに関する2番目の問題はキャッシングプロキシがどのくらいの期間ポリシー参照ファイルを保存できたかということをユーザエージェントが知る方法がないということである。ポリシー参照ファイル（またはポリシー）が相対的有効期限に依存する場合、ユーザエージェントはそのポリシー参照ファイルの有効期限がすでに切れたかどうか、またはいつ切れそうであるかということを決めることができない。

そのため、ユーザエージェントがポリシー参照ファイルやポリシーを要求し、起点サーバへのパスにHTTP1.0が存在しないことを明確に知らない場合、その要求はエンドツーエンドの再確認を推し進めなければならない。このことはPragma: no-cache HTTP 要求ヘッダで行うことができる。HTTPもP3Pも与えられたネットワークパスにHTTP1.0対応のキャッシュが存在するかどうかを決める方法を定義しない事に注意。そのため外部のソースから得たこの情報をユーザエージェントが持っている場合以外、エンドツーエンドの再確認を行ってはいけない。

ユーザエージェントが起点サーバへのネットワークパスに在るキャッシュすべてがHTTP1.1に対応していることを知る方法を持つ場合（または起点サーバへのネットワークパスにキャッシュが全くない場合）、クライアントは、エンドツーエンドの再確認をする代わりに、以下を行なわなければならない。

1. 受信した返答が有効期限より古くないことを確認する為にキャッシュ制御要求ヘッダを使用する。これは最大期限キャッシュ制御設定、ポリシー参照ファイル（またはポリシー）の有効期限よりも非常に少ない最大期限を使用して行う。例えば、ユーザエージェントが 最大期限が43200であるCache-Controlを送るとすると、応答は12時間以上にはならないと確認できる。
2. 相対的有効期限を使用している場合、ポリシー参照ファイル（またはポリシー）から応答の期限を引く。応答の期限は Age: HTTP応答-ヘッダより与えられている。

クライアントがHTTP要求に影響する待ち時間を正確に予測する事ができないことに注意。そのため、要求をカバーしているポリシー参照ファイルはすぐに期限切れとなる場合、クライアントはその要求を続ける前に、ユーザに警告するかポリシー参照ファイルの再確認をすることを考慮したいと思ってもよい。

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

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

1. 有効期限が無効であるか、作成に間違いがあるため、過去の絶対的有効期限は相対的、絶対的に関わらず、ポリシー参照ファイル（またはポリシー）をポリシー無駄なものにする。この場合、ユーザエージェントはあたかも使用可能なポリシー参照ファイル（またはポリシー) がないかのように振る舞わなければならない。その場合の必要な手順に関しては2.4.7章”ポリシー参照ファイルがない場合”を参照のこと。
2. 86400秒（一日）より短い相対的有効期限は86400秒と同じだと見なされる。
3. 二つ以上のEXPIRY要素がある場合、参照ファイルの有効期限を決めるのには、最初にある日付を優先する。

2.3.2.4 POLICY-REF要素

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

POLICY-REF

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

about (必須の属性)

フラグメント識別子の部分が（name属性に与えられている）ポリシーの名前を示し、そのURI部分がポリシーが存在するURIを示している場合のURI参照([URI])。これが相対的URI参照であれば、ポリシー参照ファイルのURIに関連があると解釈される。

policy-ref

=

`<POLICY-REF about="` URI-reference `">`
*include
*exclude
*cookie-include
*cookie-exclude
*method-element
*extension
`</POLICY-REF>`

2.3.2.5 INCLUDE要素およびEXCLUDE要素

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

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

ポリシー参照ファイルで参照されたポリシーはそれを参照しているDNS（Domain Name System）ホストのURIにのみ適用することができる。従って、例えば、ホストwww.example.comの周知の場所にあるポリシー参照ファイルはwww.example.comにあるリソースだけにポリシーを適用することができる。しかし、foo.example.comが、bar.example.comにあるポリシー参照ファイルを参照するレスポンスにP3PHTTPヘッダを含む場合、そのポリシー参照ファイルは（bar.example.comやwww.example.comではなく）foo.example.comにあるリソースに適用される。同じポリシー参照ファイルは複数のホストが送信しているP3PHTTPヘッダにおいて参照される。その場合、それを参照している各ホストにそのポリシー参照ファイルは適用される。INCLUDE 要素およびEXCLUDE要素は、これらの要素が適用されているDNSホストのルートに関連しているURIパターンを指定しなければならない。

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

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

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

include

=

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

exclude

=

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

2.3.2.6 HINT要素

ポリシー参照のヒントはある条件下で使用できるパフォーマンスの最適化である。サイトは周知の存在場所、P3P応答ヘッダ、または、HTML/XHTMLlinkタグを使用して自身のポリシー参照を宣言するかもしれない。また。サイトは他のサイトが宣言したものなど、さらなるポリシー参照のヒントを適用してもよい。

例えば、HTMLページはハイパーリンクや埋め込みコンテンツのポリシー参照にヒントを与え、アクションURIを作成するかもしれない。周知の存在場所からポリシー参照が使用出来ない場合、影響を受けたURIを要求する前にユーザエージェントはそのヒントメカニズムを使用してポリシー参照を発見してもよい。

ポリシー検索のためにヒントを使用するユーザエージェントは、ヒントの与えられたポリシー参照ファイルを含むサイト以外には、ポリシーを適用してはならない。

ポリシー参照ファイルはいずれも０以上のポリシー参照のヒントを含んでいることがある。各ヒントは、二つの属性、scopeおよびpathを持つHINT要素に含まれている。

scope属性はURIスキームとヒントの与えられたポリシー参照ファイルが適用できる権限を指定するために使用される。権限のコンポーネント(cf. [URI])がサーバコンポーネント（例えばホスト名やIPアドレス）である場合、その権限のホスト部分は、2.3.2.1.2章で定義されているように、ワイルドカードで始めてもよい。scope属性はワイルドカーとをどこにも含んではいけないが、2.3.2.1.2章の規定に従って符号化されなければならないし、パスや照会、フラグメントURIコンポーネントを含んではならない。また、権限がサーバである場合は、ユーザ情報部分を含むべきではない。

例えば、scopeにとって合法的な値は以下を含む。

• http://www.example.com
• http://www.example.com:81
• http://*.example.com
• ftp://ftp.example.org

scope属性にとって合法的ではない値は以下である。

• http://www.*.com ; ワイルドカードは最初に置くことができる。
• http://www.example.com/ ; 後続のスラッシュは使用できない。
• www.example.com ; スキームは始めなければならない。
• *://www.example.com ; スキームはワイルドカードとを含むことができない。
• http://www.example.com:*; ポートはワイルドカードを含むことができない。

path属性は、ヒントを与えられたサイトにあるポリシー参照ファイルを探すのに使用される。また、path属性はURIスキームを基本とする相対的URIであり、scope属性で照合された権限である。ポリシー参照ファイルはいつもそれが適用されている同じサイトから検索されるので、path属性は絶対的URIであってはならない。

例2.3:

<HINT scope="http://www.example.org" path="/mypolicy/p3.xml" />
<HINT scope="http://www.example.net:81" path="/w3c/prf.xml" />
<HINT scope="http://*.shop.example.com" path="/w3c/prf.xml" />

hint

=

`<HINT scope="` scheme ( `://` | `:/` ) authority `" path="` relativeURI `/>`

2.3.2.7 COOKIE-INCLUDE と COOKIE-EXCLUDE 要素

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

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

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

各COOKIE-INCLUDEおよびCOOKIE-EXCLUDE要素は、（INCLUDEおよびEXCLUDEと同じ様に）ポリシー参照ファイルが存在するWebサイト上のリソースからクッキーが設定される際、about属性が指定したポリシーによってカバーされているクッキーを示しながら、そのクッキーのNAME、VALUE、Domain、およびPathコンポーネントを照合するために使用することができる。

COOKIE-INCLUDE (resp. COOKIE-EXCLUDE)

name, value, domainおよびpath属性を照合するクッキーを含んでいる。 (または、含んでいない。）

name

クッキーのNAME部分を照合する。

value

クッキーのVALUE部分を照合する。

domain

クッキーのDomain部分を照合する。

path

クッキーのPath部分を照合する。

domain属性の値がドット文字（"."）に設定されている場合、そのドメインはdomain属性を省略するクッキーのみを照合する。（そして、RFC 2965 [STATE]に従って、要求ホストと同等のドメインを持つ）

path属性を省略するクッキーには、RFC 2965 [STATE]に従って、セット‐クッキーレスポンスを作成した要求URIのデフォルトパスがある。クッキーがpath属性を省略する場合、COOKIE-INCLUDEのpath属性は このデフォルト値と比較されるべきである。

この4つの属性は任意である｡属性がない場合、COOKIE-INCLUDE (resp. COOKIE-EXCLUDE)がいずれかの値に設定されている属性を持つクッキーを照合する。

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

ユーザエージェントはポリシー参照ファイルのCOOKIE-INCLUDE 要素と COOKIE-EXCLUDE要素を使用してポリシー参照ファイルが適用しているホストに設定、または、再現されているクッキーへ適用するポリシーを決めなければならない。COOKIE-INCLUDEのdomain属性はより幅広く照合する（例えば、domain属性が省略される場合、いずれかのドメイン値の照合をデフォルト値としてとる）が、ユーザエージェントは、ポリシー参照ファイルが適用しているホストで設定されているクッキーで適切に使用できるドメインへのポリシーの適用を制限しなければならない。例えば、abc.xyz.example.comが <COOKIE-INCLUDE domain="*.xyz.*ple.com"/>でpolicyrefを宣言する場合、.example.com や .xyz.sample.com.ではなく、.abc.xyz.example.com そして、.xyz.example.comなどといったドメインで宣言される。

P3Pポリシーは、再生されるホストのいずれか、またはすべて、または、クッキーを設定するホストによってクッキーと関連付けることができる。ユーザエージェントは、（恐らく）ドメインの他のホストへ再現される際にクッキーが設定され、その後適用される時、クッキーポリシーを取り出してもよい。ユーザエージェントはクッキーをホストに再現する前に、ホストからのポリシー参照ファイルを要求してもよいし、ホストがクッキーを設定していなくても、ポリシー参照ファイルに適切なCOOKIE-INCLUDEがある場合は、ポリシーはそのクッキーに適用される。ホストがそのクッキーに対してポリシーを宣言しているかいないかに関わらず、クッキーが再現されるホストはいずれもそのクッキーに関連するすべてのポリシーを有効にできなければならない。従って、ドメイン内で複数のホストに再現されるクッキーを設定するサイトは、すべてのホストが宣言されたポリシーに従うことができるかを確認するために調整を行う必要がある。更に、サイトは、ポリシーが適用されるべきではないクッキーへポリシーを不注意に適用しないようにするために、ワイルドカードの使用には注意すべきである。（まだ使用中のクッキーをあらかじめ設定したり、ドメインのほかのホストで設定されたクッキーなどを含む）

関連するポリシー参照ファイルがポリシーの有効期限より早く無効になったとしても（しかし、クッキーが設定された後）、ポリシーの有効期限が終了するまではクッキーを適用しているポリシーは有効である。クッキーと対応しているポリシーの期限が終了している場合、ユーザエージェントはクッキーを送信する前にクッキーポリシーを再度評価するべきである。さらに、ユーザエージェントは新規のセットクッキーイベントを評価する際は有効期限の切れていないポリシーやポリシー参照ファイルを使用しなければならない。

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

例2.4 :

<META xmlns="http://www.w3.org/2002/01/P3Pv1">
 <POLICY-REFERENCES>
  <POLICY-REF about="/P3P/Policies.xml#first">
       <COOKIE-INCLUDE name="*" value="*" domain="*" path="*"/>
  </POLICY-REF>
 </POLICY-REFERENCES>
</META>

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

例 2.5 :

<META xmlns="http://www.w3.org/2002/01/P3Pv1">
 <POLICY-REFERENCES>
  <POLICY-REF about="/P3P/Policies.xml#first">
       <COOKIE-INCLUDE name="*" value="*" domain="*" path="*"/>
       <COOKIE-EXCLUDE name="obnoxious-cookie" value="*" domain=".example.com" path="/"/>
    </POLICY-REF>
    <POLICY-REF about="/P3P/Policies.xml#second">
       <COOKIE-INCLUDE name="obnoxious-cookie" value="*" domain=".example.com" path="/"/>
  </POLICY-REF>
 </POLICY-REFERENCES>
</META>

cookie-include

=

"<COOKIE-INCLUDE"
   [` name="` token `"`]   ; matches the cookie's NAME
   [` value="` token `"`]  ; matches the cookie's VALUE
   [` domain="` token `"`] ; matches the cookie's Domain
   [` path="` token `"`]   ; matches the cookie's Path
"/>"

cookie-exclude

=

"<COOKIE-EXCLUDE"
   [` name="` token `"`]   ; matches the cookie's NAME
   [` value="` token `"`]  ; matches the cookie's VALUE
   [` domain="` token `"`] ; matches the cookie's Domain
   [` path="` token `"`]   ; matches the cookie's Path
"/>"

[STATE]はクッキーのドメインとパス属性のデフォルト値を示しているということに注意。これらの値は属性が特定のクッキーにない場合に比較のために使用されるべきである。また、[STATE]と同じ様に、はっきりと定義されたDomain値がピリオド(".")で始まっててはならないこと、ユーザエージェントはピリオドを付けなければならないことに注意。また、すべてのPathは"/" 文字で始まることにも注意されたい。

2.3.2.8 METHOD 要素

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

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

従って、/P3P/Policies.xml#firstが、GETとHEADメソッドのために/docs/で始まるパスを持つリソースすべてに適用し、一方で、/P3P/Policies.xml#secondは、PUTとDELETEメソッドの時に適用される事を示す場合、以下のポリシー参照ファイルを記述することができる：

例 2.6:

<META xmlns="http://www.w3.org/2002/01/P3Pv1">
 <POLICY-REFERENCES>
    <POLICY-REF about="/P3P/Policies.xml#first">
      <INCLUDE>/docs/*</INCLUDE>
      <METHOD>GET</METHOD>
      <METHOD>HEAD</METHOD>
    </POLICY-REF>
    <POLICY-REF about="/P3P/Policies.xml#second">
      <INCLUDE>/docs/*</INCLUDE>
      <METHOD>PUT</METHOD>
      <METHOD>DELETE</METHOD>
    </POLICY-REF>
 </POLICY-REFERENCES>
</META>

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

method-element

=

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

最後に、METHOD要素はINCLUDE要素やCOOKIE-INCLUDE要素と共に使用される様にデザインされていることに注意。METHOD要素はそれ自身、POLICY-REFをURIへ適用することはない。

2.3.3 ポリシーをURIへ適用

ポリシー参照ファイルは与えられたURIに適用するポリシーを指定する。つまり、示されているポリシーは、その与えられたURIを参照しないことの影響をすべて述べているのである。（時々、適切に指定されたMETHODで）

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

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

明確な例:

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

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

CGIスクリプトへのリンクや、その他のサーバ側アプリケーションへのURI（[HTML]の17.3で定義されているように、アクションURIはHTML<FORM>要素のアクション属性に与えられたURIである）フォームは特別な考察に値する。時にこれらのアクションURIはフォーム自身よりも異なるポリシーによってカバーされることがある。

もし、ユーザエージェントが、そのページから参照されるポリシー参照ファイルの与えられたアクションURIのための照合組み込み規則を見つけられない場合、それは有効なポリシーが全くないとするべきである。このような事情から、ユーザエージェントは、アクションURIをカバーするポリシー参照ファイルを見つける試みのためのアクションURIにあるホスト上の周知の存在場所をチェックするべきである。もし、アクションURIをカバーするP3Pポリシーを提供するものでなければ、ポリシーを効果的に検索するために実際にデータを提出する前に、ユーザエージェントはアクションURIのHINTメカニズムを使用するか、HEADリクエストをアクションURIへ発行してポリシー参照ファイルを検索しようとしてもよい。サービスは、サーバ側のアプリケーションがHEADの該当するポリシー参照リンクを返すよう、明確にするべきである。このようにアプリケーションの下にあるケースの場合、HEAD要求がわからず、問題となっているアクションURIを示す仮宣言されたポリシーが全くないことになり、ユーザエージェントは有効なポリシーが全くないとしなければならず、そしてユーザにこれについて確認し、ユーザのプリファレンスに従って通信手段を取るようにするべきである。

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

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

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

2.4 追加要求事項

2.4.1 一義性

ユーザエージェントは与えられたURIにどのポリシーが適用するのかを明確に決めることができなければならない。そのため、サイトは与えられたURIに対して有効な複数のポリシーを複数宣言することを避けるべきである。まれにサイトが与えられたURIに対して有効な複数のポリシーを宣言してもよい時がある。例えば、サイトがそのポリシーを変更する転換期などである。そういう場合、サイトは恐らく与えられたどのポリシーをユーザが見るのかということを明確に決めることができないかもしれない。従って、すべてのポリシーを有効にしなければならない。（これはコンパクトポリシーの場合にもいえる。4.1章および4.6章を参照)サイトは与えられたURIに対して複数のポリシーを宣言するときはそのプラクティスに慎重になり、そのポリシー全部を同時に有効にできるかを確認しなければならない。

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

HTTP応答に複数のポリシー参照ファイルへの参照がある場合、P3Pのユーザエージェントは2番目以降の参照をすべて無視しなければならない。

HTML(XHTML) ファイルに複数のポリシー参照ファイルへのHTML(XHTML) linkリンクタグ参照がある場合、P3Pのユーザエージェントは2番目以降の参照をすべて無視しなければならない。

ユーザエージェントが与えられたURIで有効なP3Pポリシー参照ファイルを複数見つけた場合、（例えば、ページに異なるポリシー参照ファイルを参照するP3Pヘッダとlink タグがあったり、サイトの2ページに対するP3Pヘッダが同じURIの異なるポリシーを宣言する異なるポリシー参照ファイルを参照しているといった理由などで）サイトがこれらのポリシー全部を有効にしなければならないので、ユーザエージェントはこれらのポリシーのいずれか（または全部）が適用していると仮定してもよい。

2.4.2 多言語

同一のポリシーの多言語版（翻訳版）は、そのポリシーが特定の言語によって符号化されていることを正確に示すために、 HTTPの"Content-Language"ヘッダを用いることによって、サーバによって提供することができる。このことは、「組織（entity）」や「結果(consequence)」のような人間が読むことのできる箇所を様々な言語で表現することができるので有用である。データスキーマの多言語版を提供するために、同じメカニズムも使用することができる。与えられた言語プレファレンスを照合するポリシーが利用可能になると、サーバは、HTTP"Accept-Language"で、レスポンスのローカル化されたポリシーをHTTP要求へ返すべきである。

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

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

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

最後に、言語宣言はP3P XMLファイル内に直接含むことができる。それらを含んでいる人間が読むことのできるフィールドの言語を示すため、POLICY要素、 POLICIES要素、META要素、そして、DATASCHEMA要素はxml:langを取り上げてもよい。(xml:langは普通、 [XMLの2.12章]で定義されている。)

xml-lang

=

` xml:lang="` language `"`

2.4.3 セーフゾーン

P3Pは”セーフゾーン”プラクティスの特別なセットを定義する。このセーフゾーンプラクティスのセットはP3Pポリシーやポリシー参照ファイルを取り出す一環として行う通信のためのP3P対応のユーザエージェントやサービスすべてで使用されるべきである。特に、ポリシー参照ファイルのための周知の存在場所のりクエストはこれらの"セーフゾーン"によってカバーされるべきである。セーフゾーンプラクティスでカバーしている通信は最低限のデータ集合のみを持つべきであり、収集されたデータはいずれも個人特定出来ない方法でのみ使用される。

このセーフゾーンをサポートするために、P3Pユーザエージェントはサイトのポリシーが取得されるまで、サイトのポリシーを発見する目的に不必要なデータの送信を控えるべきである。そのため、ユーザエージェントのセーフゾーンプラクティスには以下の事項が必要である。

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

サーバのセーフゾーンプラクティスには以下の事項が必要である。

• サーバはセーフゾーンでHTTP Refererヘッダや、クッキー、ユーザエージェント情報、要求に対する応答に不必要なその他の情報の受領を要求するべきではない。
• ユーザエージェントがセーフゾーン操作の一環としてAccept-Language HTTPを抑制する場合、サーバは利用可能な翻訳を自由に選択する。
• （SSLなどの）安全な接続で通信が行われる場合、サーバはセーフゾーンの要求のためのユーザエージェントからの証明を特定するべきではない。
• さらに、サーバはセーフゾーンプラクティスを提供している間は個人特定可能な方法で使用するべきではない。

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

2.4.4 ユーザエージェントによるポリシーとポリシー参照ファイルの処理

P3Pユーザエージェントはうまく作成されたXMLであるP3Pポリシーやポリシー参照ファイルの役割をしなければならない。

P3Pユーザエージェントは、付録 4にあるXMLスキーマに従ったP3Pポリシーやポリシー参照ファイルの役割をすべきである。そして、このXMLスキーマに従わないポリシーやポリシー参照ファイルの一部に依存すべきではない。

ユーザエージェントは、XMLスキーマに合わせるためにローカルにP3Pポリシーやポリシー参照ファイルを変更してはならない。

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

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

2.4.6 ポリシーの改版

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

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

2.4.7ポリシー参照ファイルがない場合

与えられたサイトに対してポリシー参照ファイルが使用出来ない場合、ユーザエージェントは（空の）ポリシー参照ファイルが周知の存在場所に24時間の有効期限で存在していると思わなければならない。そのため、ユーザが24時間を過ぎてサイトを返した場合はユーザエージェントはもう一度周知の存在場所からポリシー参照ファイルを取り出そうと試みなければならない。ユーザエージェントは周知の存在場所やユーザが更新ボタンをクリックするなどの特定のイベントをより頻繁にチェックしてもよい。サイトは利用可能なポリシーがないことを示す周知の存在場所のポリシー参照ファイルを置いてもよいが、ユーザエージェントが24時間毎にチェックしなくてもいいように有効期限を設定してもよい。

2.4.8 非同期の評価

ユーザエージェントは非同期的にP3Pポリシーを取り出したり評価したりしてもよい。つまり、P3Pポリシーは他のHTTPトランザクションより先に取り出したり、評価したりする必要がない。この挙動はユーザの嗜好と行われた要求の種類に依ることがある。ポリシーが評価されるまで、ユーザエージェントはプライバシーポリシーがないかの様にサイトを取り扱うべきである。ポリシーが評価されると、ユーザエージェントはユーザの嗜好を適用するべきである。ユーザエージェントは決定論者的な挙動を促進するために、矛盾のない時点までポリシーのアプリケーションを引き延ばすべきである。例えば，ユーザエージェントがナビゲーションを完了するか、フォームの提出を確認したすぐ後に、webブラウザはユーザの嗜好を適用するかもしれない。

2.5 シナリオの例

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

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

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

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

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

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

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

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

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

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

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

P3Pポリシーは、XML内でネーム空間で符号化される（[XML] および [XML-Nameを参照のこと]。 RDFデータモデル([RDF]) を使用して起こり得る符号化は[P3P-RDF]に掲載している。

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

3.1 ポリシーの例

3.1.1 自然言語のポリシー

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

あなたが私達のサイトを閲覧する際に私達がが集める情報は以下です。

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

あなたが商品購入を選んだ場合、以下のような詳細情報の提出を依頼いたします

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

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

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

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

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

3.1.2 ポリシーのXML符号化

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

例3.1のXML符号化の方法:

<POLICIES xmlns="http://www.w3.org/2002/01/P3Pv1">
 <POLICY name="forBrowsers" 
     discuri="http://www.catalog.example.com/PrivacyPracticeBrowsing.html"
     xml:lang="en">
  <ENTITY>
   <DATA-GROUP>
    <DATA ref="#business.name">CatalogExample</DATA>
    <DATA ref="#business.contact-info.postal.street">4000 Lincoln Ave.</DATA>
    <DATA ref="#business.contact-info.postal.city">Birmingham</DATA>
    <DATA ref="#business.contact-info.postal.stateprov">MI</DATA>
    <DATA ref="#business.contact-info.postal.postalcode">48009</DATA>
    <DATA ref="#business.contact-info.postal.country">USA</DATA>
    <DATA ref="#business.contact-info.online.email">catalog@example.com</DATA>
    <DATA ref="#business.contact-info.telecom.telephone.intcode">1</DATA>
    <DATA ref="#business.contact-info.telecom.telephone.loccode">248</DATA>
    <DATA ref="#business.contact-info.telecom.telephone.number">3926753</DATA>
   </DATA-GROUP>
  </ENTITY>
  <ACCESS><nonident/></ACCESS>
  <DISPUTES-GROUP>
   <DISPUTES resolution-type="independent"
     service="http://www.PrivacySeal.example.org"
     short-description="PrivacySeal.example.org">
    <IMG src="http://www.PrivacySeal.example.org/Logo.gif" alt="PrivacySeal's logo"/>
    <REMEDIES><correct/></REMEDIES>
   </DISPUTES>
  </DISPUTES-GROUP>
  <STATEMENT>
   <PURPOSE><admin/><develop/></PURPOSE>
   <RECIPIENT><ours/></RECIPIENT>
   <RETENTION><stated-purpose/></RETENTION> <!-- サイトの人間が読むことの
                                                 できるプライバイシーはデータが二週間毎にパージ
                                                 されること、あるいはこの情報へのリンクを提供する
                                                 ことを述べなければならない  -->
   <DATA-GROUP>
    <DATA ref="#dynamic.clickstream"/>
    <DATA ref="#dynamic.http"/>
   </DATA-GROUP>
  </STATEMENT>
 </POLICY>
</POLICIES>

例3.2のXML符号化の方法:

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

3.2 ポリシー

本章では、P3Pポリシーの構文とセマンティクスを定義する。全てのポリシーは[UTF-8]を用いて表現しなければならない。

P3PのボキャブラリがWebサイトのプラクティスを記述できるほど正確ではない場合、サイトはそのプラクティスに一番近いボキャブラリ用語を使用し、CONSEQUENCE フィールドにより詳細な説明と人間が読むことのできるポリシーを提供すべきである。しかし、ポリシーは間違ったり、誤解を受けるようなステートメントを行ってはならない。

ポリシーはPOLICIES要素内に置かなければならない。

3.2.1 POLICIES 要素

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

POLICIES要素は含まれるポリシーの有効期限を示して、xml:lang 属性と(2.4.2章を参照のこと)EXPIRY要素、そして、DATASCHEMA要素を使用して埋め込まれたデータスキーマを任意に含むことができる。(5章を参照のこと)

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

例 3.3:

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

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

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

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

policies

=

`<POLICIES xmlns="http://www.w3.org/2002/01/P3Pv1"` [xml-lang] `>`
[expiry]
[dataschema]
*policy
"</POLICIES>"

3.2.2  POLICY 要素

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

<POLICY>

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

name(必須の属性)

ポリシーを参照することのできるフラグメント識別子として使用されているこのポリシーの名前。

discuri (必須の属性)

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

opturi

ユーザが特別な目的（opt_inまたはopt_out）のために使用されるデータを要求したり、拒否したりする際に従うことのできるURIの指示のこと。 この属性はopt-in または opt-outに設定されている必要な属性と一緒に purposeを含むポリシーに必須である。 opt_inまたはopt_out手順は各サイトで決定され、全サイトや自動化されたメカニズムのために中心のメカニズムを組み込まないということに注意。

xml:lang

ポリシーが表現される言語（2.4.2章を参照。）

policy

=

`<POLICY name=` quotedstring
         ` discuri=` quoted-URI
         [` opturi=` quoted-URI]
         [xml-lang] `>`
*extension
[test]
entity
access
[disputes-group]
1*statement-block
*extension
`</POLICY>`

quoted-URI

=

`"` URI `"`

3.2.3 TEST 要素

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

test

=

"<TEST/>"

3.2.4 ENTITY 要素

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

<ENTITY>

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

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

 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.5 ACCESS 要素

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

<ACCESS>

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

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

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

<nonident/>

webサイトは個人特定可能なデータは使っていない

<all/>

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

<contact-and-other/>

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

<ident-contact/>

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

<other-ident/>

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

<none/>

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

access

=

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

access_disclosure

=

"<nonident/>"          | ; 個人特定可能なデータは使われていない



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

3.2.6 DISPUTES 要素

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

<DISPUTES>

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

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

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

顧客窓口(Customer service) [service]

利用者は、収集されたデータの利用に関する係争の解決のために、Webサイトの顧客窓口の代表者に申し立てることができる。 この記述は、顧客サービスへの連絡方法関する情報が含まれなければならない。

独立機関(Independent organization) [independent]

利用者は、収集されたデータの利用に関する係争解決のために、ある独立機関に申し立てることができる。 記述の中にはその第三者機関への連絡方法に関する情報が含まれなければならない。

裁判所(Court) [court]

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

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

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

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

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

検証(verification)

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

簡易表記(short-description)

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

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

<長い表記(LONG-DESCRIPTION)>

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

<IMG>

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

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=" quotedstring]
 [" short-description=" quotedstring]
">"
*extension
[longdescription]
[image]
[remedies]
*extension
"</DISPUTES>"

longdescription

=

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

image

=

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

quotedstring

=

`"` string `"`

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

3.2.7 REMEDIES 要素

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

<REMEDIES>

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

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

<correct/>

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

<money/>

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

<law/>

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

remedies

=

"<REMEDIES>"
*extension
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) |
 (non-identifiable [purpose] [recipient] [retention] *data-group))
*extension
"</STATEMENT>"

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

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

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

3.3.2 CONSEQUENCE 要素

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

<CONSEQUENCE>

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

consequence

=

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

3.3.3 NON-IDENTIFIABLE 要素

このSTATEMENT配下には収集されたデータがないということや、STATEMENTで 参照されているデータはすべて収集に関して匿名扱いされるということを示して、STATEMENT 要素（ステートメント要素）には任意にNON-IDENTIFIABLE要素が含まれる事がある。

<NON-IDENTIFIABLE/>

この要素は収集されたデータがない（Webログを含む）ということや、STATEMENTを囲む 際に参照されるデータを匿名扱いにすることを示す。”匿名扱い”されるデータを考慮するためは、 組織や第三者機関が自然人の識別のために収集されたデータを添付する妥当な方法はない。ランダム に作成されたセッションIDの様に、データの種類によっては、元から匿名であったものもある。 ある 状況において、自然人を識別するデータ（IPアドレスや名前、住所など）は”匿名”だとみなされる ようにするために、非可逆的な変換をなされなければならない。 非可逆的な変換の例として、IPアドレスの最後の7ビット削除し、ゼロに置き換えることがある。 この変換はバックアップ媒体に保存されるものを含む、データのコピーすべてに適用されなければならない。 識別されたデータをテーブルから一意に対応する値と置き換えるアルゴリズムは非可逆的だとはみなされない。 更に、起こり得るデータ値の集合が、起こり得るハッシュ値が作成され、ある人が逆にしようと試みている値と 比較できるほど少ない場合、一方的な暗号ハッシュは、非可逆的だとはみなされない。

NON-IDENTIFIABLE要素が、ポリシーのSTATEMENT要素に存在する場合、この要素が匿名化される方法についての人が読むことのできる説明はdiscuriに含まれるかリンクされなければならない。

また、NON-IDENTIFIABLE要素がSTATEMENTに存在する場合、そのSTATEMENTのその他の要素は任意になる。

non-identifiable

=

"<NON-IDENTIFIABLE/>"

3.3.4 PURPOSE 要素

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

<PURPOSE>

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

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

<current/>

データが提供されている活動の遂行とサポート：情報は、情報提供や通信、双方向サービスなど、利用者が そのために情報を与えたところの活動を遂行するために、 サービス提供者によって利用されるかも しれない。例えば、ウェブ検索の結果の返信、電子メールの送信、商品の注文、または、申込サービスの提供など、繰り返し行う活動や、オンラインのアドレスブックや電子財布にアクセスを許可することなど。

<admin/>

ウェブサイトとシステムの管理: 情報は、ウェブサイトとそのコンピュータシステムの 技術サポートのために利用されるかもしれない。 この中には、コンピュータアカウント情報の処理や、サイトの保守管理、およびサイトやエージェントによるウェブサイト活動の確認の過程で利用される情報の処理が含まれる。

<develop/>

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

<tailoring/>

その場限りの仕立て: サイトへの1回の訪問のみで利用されたり、 その後のいかなるカスタマイズにも利用されない情報を含むサイトのコンテンツに合わせたり、そのコンテンツを変更したりする為に情報が使用されることがある。 例えば、訪問者が買い物かごに入れた商品にもとづいて、彼がその他に購入したいであろう商品を提案するオンラインショップなど。

<pseudo-analysis/>

ペンネーム分析: 情報は、（名前、住所、電話番号、電子メールなどの）記録するための個人が特定可能なデータを使うことなく、 個人かコンピュータ毎の個々の記録とペンネームの記録を繋ぐために使われるかもしれない。 このプロファイルは調査や分析、報告を目的とした、習慣や興味、個人の特徴といったものの決定のために使われるかもしれないが、 個人が特定可能な情報としては使われないだろう。 たとえば、市場で売買する会社や人がウェブサイトの異なる部分へアクセスする人の興味を理解したいと考えるかもしれない。

<pseudo-decision/>

ペンネーム決定: 情報は、（名前、住所、電話番号、電子メールなどの）記録するための個人が特定可能なデータを使うことなく、 個人かコンピュータ毎の個々の記録と ペンネームの記録を繋ぐために使われるかもしれない。 このプロファイルは習慣や興味、個人の特徴といった個人に影響している決定をするために使われるかもしれないが、個人が特定可能な情報としては 使われないだろう。 例えば、市場で売買する会社や人が以前アクセスした人が見たページをもとにブラウザに表示したコンテンツを調整したり、修正したりするかもしれない。

<individual-analysis/>

個人分析: 情報は習慣や興味、個人の特徴といったものを決定し、調査や分析、報告を目的として個人特定可能なデータと結びつけるために使われる。 例えば物理的な店のオンラインWebサイトは、オンラインショッパーがどのようにオフライン購入を行うかを分析したいと考えるかもしれない。

<individual-decision/>

個人決定:  情報は習慣や興味、個人の特徴といった個人に影響している決定をするために使われ、個人に影響している決定をするために個人特定の情報と結びつくかもしれない。 例えば、オンラインストアはアクセス者が以前Webサイトに訪れた時に購入した物をもとに、商品を提案したいと思うかもしれない。

<contact/>

サービスまたは商品のマーケティングのためにサイト訪問者と連絡をとる: 情報は、 商品やサービスの販売促進のために電話以外の連絡方法で個人と連絡をとる目的で利用されるかもしれない。 この中には、ウェブサイトの更新を訪問者に通知することも含まれる。 一度行った質問やコメント、カスタマーサービスへの直接的な回答はこの中には含まない。--そういったケースでは、<current/> が使用される。 さらに、カスタマイズされたウェブコンテンツまたは、ユーザが訪れているサイトに埋め込まれたバナー広告を通じてのマーケティングも含まれない。 -- こういう場合は <tailoring/>, <pseudo-analysis/> と <pseudo-decision/>, または <individual-analysis/> と <individual-decision/> purposes でカバーされるだろう。

<historical/>

過去のでき事を保存: 情報は、現行の法律や政策で管理されているように、社会の過去のでき事を保存するために格納したり保存されるかもしれない。 この法律や政策は<DISPUTES>要素において参照されなければならないし、この情報（どこにこの情報が格納されるか、と特にどのようにしてこの情報収集が過去のでき事の保存を向上させるのか）にアクセスできる資格のあるリサーチャーの特別な定義を含まなければならない。

<telemarketing/>

電話を通じてのサービスと商品のマーケティングのために訪問者に連絡:情報は商品やサービスの促進のために電話で個人に連絡をする為に使用されることがある。 これには一度行った質問やコメント、カスタマーサービスへの直接の回答はふくまれない。--この場合、<current/>が使用される。

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

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

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

required

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

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

 purpose

=

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

 purposevalue

=

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

 required

=

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

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

3.3.5 RECIPIENT 要素

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

<RECIPIENT>

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

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

<ours>

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

<delivery>

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

<same>

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

<other-recipient>

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

<unrelated>

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

<public>

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

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

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

recipient

=

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

recipientvalue

=

"<ours>" *recdescr
"</ours>                         |  ; 当組織および／または当組織の業務委託先
"<same" [required] ">" *recdescr
"</same>"                        |  ; 当組織のプラクティスに従う合法組織

"<other-recipient" [required] ">" *recdescr
"</other-recipient>"             |  ; 当組織とは異なるプラクティスに従う合法組織

"<delivery" [required] ">" *recdescr
"</delivery>"                    |  ; 当組織とは異なるプラクティスに
"<public" [required] ">" *recdescr                   従う可能性のある配送サービス
"</public>"                      |  ; 公のフォーラム

"<unrelated" [required] ">" *recdescr
"</unrelated>"                      ; 当組織と無関係な第三者

recdescr

=

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

"</recipient-description>"

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

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

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

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

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

3.3.6 RETENTION 要素

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

<RETENTION>

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

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

<no-retention/>

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

<stated-purpose/>

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

<legal-requirement/>

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

<business-practices/>

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

<indefinitely/>

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

retention

=

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

retentionvalue

= 

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

3.3.7 DATA集合とDATA要素

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

<DATA集合>

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

base

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

<DATA>

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

ref (必須の属性)

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

optional

サイトが、リソースにアクセスしたり、トランザクションを完了するために、サイト訪問者に対して要求するデータ要素の提供が必須のものであるか否かを意味する; "no"は、そのデータ要素の提供がオプションではない（必須）ことを意味し、"yes"はそのデータ要素の提供がオプションであることを意味する。 既定値は"no"である。このoptional属性は、ポリシーにおいてのみ使用される（データスキーマの定義においては使用されない）。

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

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

data-group

=

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

dataref

=

`<DATA" ref="` URI-reference `"`
 [" optional=" `"` ("yes"|"no") `"`] ">"
 [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要素内で表現することができる。例えば、ポリシーの例の様に。

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

3.4 カテゴリとCATEGORIES要素

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

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

categories

=

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

category

=

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

<physical/>

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

<online/>

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

<uniqueid/>

ユニークな識別子: 個人を整合的に特定したり、認識するために発行された識別子。金融機関のID番号を除く。（政府発行の識別子を除く）。 これらはウェブサイトやサービスから発行された識別子を含む。

<purchase/>

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

<financial/>

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

<computer/>

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

<navigation/>

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

<interactive/>

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

<demographic/>

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

<content/>

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

<state/>

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

<political/>

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

<health/>

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

<preference/>

プリファレンス（嗜好）データ: 個人の好みや嫌いなものに関するデータ。好きな色や音楽の好みなど。

<location/>

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

<government/>

政府発行の識別子: 個人を識別するための政府が発行した識別子。

<other-category> string </other-category>

その他: 上記の定義にあてはまらない他のデータ型。（この場合、人間が読むことのできる説明<other-category> と </other-category>タグに挟んで）が提示されなければならない。

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

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

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

3.5 拡張メカニズム:EXTENSION要素

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

<EXTENSION>

構文の為の拡張を説明する。

optional

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

extension

=

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

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

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

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

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

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

EXTENSION要素はP3P構文内のさまざまな場所に存在することができる。その場所は付録 4のXMLスキーマで規範的に指定されている（そして、付録 5のAMNF構文とDTDで非公式に指定されている）。

3.6 ユーザプリファレンス

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

P3Pユーザエージェントはユーザが選択したプレファレンス設定に従って動作しなければならない。そのためには、ユーザエージェントがポリシーとポリシー参照ファイルを処理して、ユーザのプリファレンスや設定で指定したその他の基準に関して各ポリシーを適切に評価できなければならない。設定によっては、ユーザエージェントがP3Pの必要な部分が存在するかどうかを確認したり、全ポリシーの構文が正しいかどうかを確認する必要がある。

4. コンパクトポリシー

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

Ｐ3Ｐｖ1において、コンパクトポリシーはクッキー（cf. [COOKIES] および [STATE])のみのポリシー情報を含んでいる。ウェブサーバは完全なポリシーで参照されたクッキーを表すＰ3Ｐのコンパクトポリシーをビルドする責任がある。Ｐ3Ｐのコンパクトポリシーで指定されたポリシーはコンパクトポリシーと同じHTTP応答で設定されていたり、HTTP応答に関連するスクリプトで設定されているクッキーに格納されているデータやそのクッキーにリンクしているデータに適用する。

4.1 コンパクトポリシーの参照

HTTPリソースはいずれもP3Pレスポンスヘッダ(cf. 2.2.2章)を通じてP3Pのコンパクトポリシーを含んでもよい。サイトがP3Pヘッダを使用している場合、HEADとOPTION要求を含む適切なリクエスト方式のレスポンスでＰ3Ｐのコンパクトポリシーを含むべきである。

Ｐ3Ｐのコンパクトポリシーヘッダには一つ以上の範囲を決められたトークン（"コンパクトポリシー"）を含む引用された文字列がある。トークンはどの順番ででも表示できるし、スペース文字(" ") は有効なデリミッタだけである。このヘッダの構文は以下である：

compact-policy-field

=

`CP="` compact-policy `"`

compact-policy

=

compact-token *(" " compact-token)

compact-token

=

compact-access           |
compact-disputes         |
compact-remedies         |
compact-non-identifiable |
compact-purpose          |
compact-recipient        |
compact-retention        |
compact-categories       |
compact-test

すべてのHTTPヘッダに関して、P3Pヘッダのフィールドの名前は大文字小文字を区別しない。その代わり、フィールド値（つまり、ヘッダのコンテンツ）は大文字小文字を区別する。

HTTP応答にコンパクトポリシーが複数含まれている場合、P3Pユーザエージェントは2番目以降をすべて無視しなければならない。

4.2 コンパクトポリシーのボキャブラリ

P3PのコンパクトポリシーはP3Pのボキャブラリから以下の要素を表わすトークンを使用する。 ACCESS, CATEGORIES, DISPUTES, NON-INDENTIFIABLE, PURPOSE, RECIPIENT, REMEDIES, RETENTION, TEST

一つのコンパクトポリシーにトークンが2回以上現れると、そのコンパクトポリシーは一度しか現れなかったポリシーと同じセマンティクを持つ。コンパクトポリシーに承認されないトークンが現れる場合、コンパクトポリシーはトークンが存在しないポリシーと同じセマンティクを持つ。

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

4.2.1 コンパクトなACCESS

ACCESS要素の情報はコンパクトポリシーに 三文字コードで構成されたトークンを使用して以下のように表される：

compact-access

=

"NOI" | ; for <nonident/>
"ALL" | ; for <all/>
"CAO" | ; for <contact-and-other/>
"IDC" | ; for <ident-contact/>
"OTI" | ; for <other-ident/>
"NON"   ; for <none/>

4.2.2 コンパクトなDISPUTES

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

compact-disputes

=

"DSP" ; there is some DISPUTES

4.2.3 コンパクトなREMEDIES

REMEDIES要素の情報はコンパクトポリシーに以下のように表される：

compact-remedies

=

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

4.2.4 コンパクトなNON-IDENTIFIABLE

ポリシーの各ステートメントにあるNON-IDENTIFIABLE要素の存在はNIDトークンによって知らされる（NIDトークンはポリシー内の各ステートメントにNON-IDENTIFIABLE要素がない限り、使用してはならない。）：

compact-non-identifiable

=

"NID" ; for <NON-IDENTIFIABLE/>

4.2.5 コンパクトなPURPOSE

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

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

Ｐ3Ｐの目的とコンパクトポリシーコードの関連性は以下である：

compact-purpose

=

"CUR"        | ; for <current/>
"ADM" [creq] | ; for <admin/>
"DEV" [creq] | ; for <develop/>
"TAI" [creq] | ; for <tailoring/>
"PSA" [creq] | ; for <presudo-analysis/>
"PSD" [creq] | ; for <preudo-decision/>
"IVA" [creq] | ; for <individual-analysis/>
"IVD" [creq] | ; for <indovidual-decision/>
"CON" [creq] | ; for <contact/>
"HIS" [creq] | ; for <historical/>
"TEL" [creq] | ; for <telemarketing/>
"OPT" [creq]   ; for <other-purpose/>

creq

=

"a"| ;"always"
"i"| ;"opt-in"
"o"  ;"opt-out"

4.2.6 コンパクトなRECIPIENT

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

P3P受領者とコンパクトポリシーコードの関連性は以下である：

compact-recipient

=

"OUR"        | ; for <ours/>
"DEL" [creq] | ; for <delivery/>
"SAM" [creq] | ; for <same/>
"UNR" [creq] | ; for <unrelated/>
"PUB" [creq] | ; for <public/>
"OTR" [creq]   ; for <other-recipient/>

4.2.7 コンパクトなRETENTION

RETENTION要素の情報はコンパクトポリシーに以下のように表される：

compact-retention

=

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

4.2.8 コンパクトなCATEGORIES

カテゴリ（Ｃａｔｅｇｏｒｉｅｓ）はコンパクトポリシーに以下のように表される：

compact-categories

=

"PHY" | ; for <physical/>
"ONL" | ; for <online/>
"UNI" | ; for <uniqueid/>
"PUR" | ; for <purchase/>
"FIN" | ; for <financial/>
"COM" | ; for <computer/>
"NAV" | ; for <navigation/>
"INT" | ; for <interactive/>
"DEM" | ; for <demographic/>
"CNT" | ; for <content/>
"STA" | ; for <state/>
"POL" | ; for <political/>
"HEA" | ; for <health/>
"PRE" | ; for <preference/>
"LOC" | ; for <location/>
"GOV" | ; for <government/>
"OTC"   ; for <other-category/>

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

4.2.9 コンパクトなTEST

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

compact-test

=

"TST" ; for <TEST/>

4.3 コンパクトポリシーの範囲

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

4.4 コンパクトポリシーの有効期限

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

4.5 P3Pポリシーをコンパクトポリシーへ変換する

P3Pのコンパクトポリシーを使用している時に、ウェブサイトはP3Pポリシー参照ファイルの COOKIE-INCLUDE要素が参照したポリシーを要約することによって、コンパクトポリシーを構築する責任がある。サイトのポリシー参照ファイルがCOOKIE-EXCLUDE要素を使用している場合、そのサイトは、特定の応答で設定されたクッキーを与えられたユーザエージェントへの正しいP3Pのコンパクトポリシーの送信を管理する必要があるだろう。

P3PポリシーをP3Pのコンパクトポリシーへ変換すると、記述的なポリシー情報にロスを生み出すことがある。--コンパクトポリシーには完全なポリシーで指定されたポリシー情報をすべて含んでいなくてもよい。expiry要素、data group/data-schema要素、entity要素、consequences要素、そしてdisputes要素を含むコンパクトポリシーを実装する際に破棄された完全なポリシーからの情報は減少する。

必須の拡張子を含む完全なポリシーをコンパクトポリシーとして表してはならない。

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

また、ステートメントに現れる各固定カテゴリデータ要素に対して、関連するカテゴリは、関連するスキーマに定義されているように、コンパクトポリシーに組込まれなければならない。

例  4.1:

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

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

対応するコンパクトポリシーは：

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

4.6 コンパクトポリシーをP3Pポリシーへ変換する

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

コンパクトな保有（retention）の複数の異なる値がない場合、

ユーザエージェントは、適切なACCESS要素そして：適切なCATEGORIESを持つ dynamic.miscdata要素と同様に、適切なRECIPIENT, RETENTION, そしてPURPOSE要素を含む単一のSTATEMENT要素を 使用してポリシーを作成できなければならない。

コンパクトな保有（retention）の複数の異なる値がある場合、

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

2.4.1章で述べている一義性の必要事項に従って、(4.5章に従って、URIのポリシー参照ファイルで参照されている完全なポリシーがコンパクトポリシーに対して応答しない場合でも）、サイトはいずれの場合でも与えられたURIのコンパクトポリシーを有効にしなければならないことに注意。

5. データスキーマ

データスキーマとはデータの集合の記述である。P3Pにはデータスキーマを記述する方法があるので、サービスは収集したデータについてユーザエージェントと通信できる。データスキーマは多くのデータ要素から作成されている。このデータ要素はサービスが収集するかもしれない特定の項目である。

データのデータ要素は以下の特性をもつ。

• データ要素の名前。データ要素の名前はP3Pポリシーが<DATA>要素にこのデータ要素を持つ際に使用される。これはすべてのデータ要素で必要である。
• 記述的な名前または、短い名前。データ要素の短い名前はデータ要素の短く人間が読むことのできる名前を持つ。この短い名前は必須ではないが、使用を強く推奨する。
• 長い記述。データ要素の長い記述はより詳細で、人間が読むことのできるデータ要素の定義を持つ。短い名前と同じように、この長い記述は必須ではないが、使用を強く推奨する。
• カテゴリ。データスキーマにデータ要素が定義される際、そのデータ要素のほとんどはカテゴリーが割り当てられている。カテゴリに関しての詳細はカテゴリを参照のこと。

デーータ要素は階層式に構成されている。データ要素は自動的に階層式にその配下にすべてのデータ要素を含める。例えば、”ユーザ名”を表しているデータ要素には”ユーザの名前”、”ユーザの名字”などを表わすデータ要素が含まれている。この階層はデータ要素の名前に基づいている。そのため、データ要素、user.name.given, user.name.family, そしてuser.name.nicknameはデータ要素user.nameの子であり、データ要素user.nameはデータ要素userの子である。

P3Pはサービスが共通に使用するデータ要素を大量に含むP3P 基本データスキーマというデータスキーマを定義する。

サービスは、データスキーマを作成し、そのデータスキーマを公開することによって新しいデータ要素を宣言する事がある。これは<DATASCHEMA>を使用して行われる。スキーマはXMLファイルに独立して発行することができる。そしてそれらを使用するポリシーによって参照されるか、それを参照しているポリシーファイルに埋め込むことができる。<DATASCHEMA>要素は以下のように定義されている。

dataschema

=

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

独立したデータスキーマにはファイルの最初のXML要素のとして<DATASCHEMA> 要素があり、以下のようにP3Pデータスキーマとして識別するためにはxmlns属性に適切なネーム空間を持たなければならない。

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

任意にDATASCHEMAはxml:lang属性を含むことができる。(2.4.2章を参照)

（3.2.1章,"<POLICIES>要素に定義されているように）データスキーマがポリシーファイルに宣言されると、<DATASCHEMA>要素はすでに使用されているが、ネーム空間属性は与えられていない。

5.1データスキーマのための自然言語のサポート

データスキーマには自然言語で書かれた多くのフィールドがある。データスキーマを公開しているサービスはこれらのフィールドを多言語に翻訳したいと考えても よい。データ要素の短い名前と長い名前を翻訳してもよいが、データ要素名は翻訳てきない。-このフィールドはデータスキーマの翻訳に関係なく一貫性を保たなければならない。

サービスが多言語でデータスキーマを提供しようとしする場合、最良の選択ができるようにそのデータスキーマの要求にあるAccept-Language HTTP要求-ヘッダを調べるべきである。

5.2 データ構造

データスキーマはよく、データ要素の共通のグループを再利用する必要がある。P3Pデータスキーマはデータ構造を使用してそれをサポートしている。データ構造は名前を付けられ、抽象的なデータ要素のグループの定義である。データ要素が定義されると、そのデータ要素を構造化されていないタイプであると定義することができる。その場合、子エレメントがない。また、データ要素を特別に構造化されているタイプであると定義することもできる。その場合、データ要素はデータ構造で定義されている要素すべてをサブ-要素として組込むために自動的に展開される。例えば、以下の構造が日付と時間を表示するのに使用される。

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

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

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

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

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

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

では、会議の時間と場所を含む”会議”データ要素を定義してみる。

<DATA-DEF name="meeting.time"
    short-description="Meeting time"
    structref="#date"/>
<DATA-DEF name="meeting.place"
    short-description="Meeting place/>

meeting.placeは構造を参照していないので、構造化されていないタイプであり、子要素を持たない。meeting.time要素はdate構造を使用している。このことを宣言することで以下のサブ-要素を作成する。

meeting.time.ymd.year
meeting.time.ymd.month
meeting.time.ymd.day
meeting.time.hms.hour
meeting.time.hms.minute
meeting.time.hms.second

P3Pポリシーはmeetingデータ要素を収集すると宣言することができる。meetingデータ要素はすべてのmeetingのサブ-要素を収集することまたは、階層- meeting.timeの配下のデータ要素、例えばmeeting.time.ymd.dayなど、を使用できることを暗示している。

5.3 DATA-DEFとDATA-STRUCT要素

<DATA-DEF>と <DATA-STRUCT>

それぞれ、データ要素、データ構造を定義する。データ構造はデータ要素を実装するのに使用できる再利用可能で、構造化された定義である。データ要素はステートメントでカバーしているデータを記述する為にP3Pポリシーの<STATEMENT>内で宣言されている。

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

name （必須の属性）

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

structref

構造を示す分割された識別部であるURI参照 ([URI]を参照)。 URIの一部は定義されたデータスキーマに一致するものを示す。 通常、デフォルトベースURIは同じ文書を参照する([URI])と同じ。 strucref属性のない（または関連した構造のない） データ要素またはデータ構造は"構造化されていない"という。

short-description

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

DATA-DEFとDATA-STRUCT要素は LONG-DESCRIPTION要素を使って、データ要素/集合または型のLONG-DESCRIPTIONを含むことができる。

datadef

=

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

datastruct

=

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

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

P3Pは幅広く使用されている数多くの構造やデータ要素の組み込みの定義を持つP3P基本データスキーマを持っている。P3P実装にはP3P基本データスキーマを理解することが必要なので、P3P基本データスキーマが定義している構造や要素はいつもP3Pの実装者が利用できるようになっている。

データスキーマは構造を記述するDATA-STRUCT を含むことがある。例えば、P3P基本データスキーマのuriデータ構造(cf. 5.5.7.1章)のために、単一のDATA-STRUCTは存在しない。代わりに、この構造を定義するためにuri.authority、 uri.stem、そしてuri.querystringが一緒に解釈される。

5.3.1 P3Pデータスキーマのカテゴリ

カテゴリはデータ構造やデータ要素に割り当てることができる。以下の規則はこれらのカテゴリがどのような意味を持つのかを定義している。

1. <DATA-STRUCT> 要素はその中にカテゴリ定義を含んでもよい。構造の定義にカテゴリが含まれている場合、データ定義にあるこれらの構造とデータ構成を使用するとそのカテゴリが選択される。構造の定義にカテゴリがない場合、他の構造やデータ要素で構造の定義を使用する際、その構造のカテゴリを定義してもよい。そうでない場合は、この構造を使用するデータ要素は可変カテゴリ要素となる。ポリシーの可変カテゴリデータ要素を他で使用するとそのポリシー内にカテゴリをリストしなければならない。
2. <DATA-DEF>にカテゴリが定義されていない場合、構造化されていないタイプの<DATA-DEF>は可変カテゴリデータ要素となり、カテゴリが含まれている場合は<DATA-DEF>にリストされているカテゴリを持つことになる。
3. <DATA-DEF>または<DATA-STRUCT>にカテゴリが定義されていない場合、その構造に定義されているカテゴリがない構造化されたタイプの<DATA-DEF>または<DATA-STRUCT>は可変カテゴリデータ要素・構造を作成する。<DATA-DEF>または<DATA-STRUCT>にリストされたカテゴリがある場合、カテゴリはそのデータ要素またはサブ要素に適用される。つまり、構造化されたタイプとなるデータ要素を定義し、その構造化されたタイプがカテゴリを定義しない場合、カテゴリはサブ-要素に押し下げられる。
4. 構造に定義したカテゴリがある構造化されたタイプを使用する<DATA-DEF>はその構造にリストされたカテゴリすべてを選択する。さらに、 カテゴリは<DATA-DEF>にリストされることがあり、構造で定義したカテゴリに付加される。これらのカテゴリはデータ要素のレベルでのみ定義され、サブｰ要素に”押し下げられる”ことはない。
5. カテゴリが割り当てされておらず、サブタイプで定義されているカテゴリがある構造化されたサブタイプを使用している<DATA-STRUCT>はそのサブタイプにリストしているカテゴリすべてを選択する。
6. カテゴリが割り当てられていて、構造化されたサブタイプを使用している<DATA-STRUCT>はそのサブタイプにリストしているカテゴリすべてを置き換える。
7. データ要素を参照している際、カテゴリの”バブルアップ”規則がある。それは、データ要素は少なくとも子が定義したカテゴリをすべてふくまなければならないということである。この規則は繰り返し適用するので、例えば、データ要素foo.a.w, foo.a.y, そしてfoo.b.z が定義したカテゴリはすべて、データ要素fooに適用すると考えなければならない。
8. <DATA-STRUCT>は可変カテゴリ要素や固定カテゴリ要素で定義することはできない。構造のサブ-要素はすべて可変カテゴリに無くてはならない、か、または、そのすべてに複数のカテゴリが割り当てられなければならない。
9. 可変カテゴリ要素と固定カテゴリ要素をいくつか持っている<DATA-DEF>を参照してはならない。つまり、データベーススキーマに存在するdynamic構造(cf. 5.6.4章 "Dynamic Data")はポリシー内では参照できない、ということである。（そのサブ要素、dynamic.clickstream、やdynamic.httpなどは個々に参照できる。）

5.3.2 P3Pデータスキーマの例

HyperSpeedExample社が車両の特徴をvehicleという構造を使用して述べたいと考えているというケースを考える。この構造には以下が含まれる。

• 車輌のモデルの種類(vehicle.model),
• 車輌の色(vehicle.color),
• 車輌の製造年(vehicle.built.year), and
• 車輌の価格(vehicle.price ).

また、HyperspeedExampleは車両製造業者の場所の定義を組込みたい場合、国や住所､郵便番号などの関連するデータでその他のフィールドに構造を付加することができる。しかし、構造の各部分は同様にその他の構造も使用することができる。つまり、構造は構成できるということである。この場合、P3P基本データスキーマ は場所の郵便情報をすべて表記して、postal構造を持っている。そのため構造車輌の最終的な定義は以下となる。

• vehicle.model (構造化されていない)
• vehicle.color (構造化されていない)
• vehicle.price (構造化されていない)
• vehicle.built.year (構造化されていない)
• vehicle.built.where (基本データスキーからのpostal 構造がある)

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

HyperSpeedExampleは車輌情報すべてが<preference/>カテゴリにあることを宣言したいと考えている。vehicle.model、vehicle.color, vehicle.price,そしてvehicle.built.yearフィールドはすべて構造化されていないタイプなので、それらを<preference/>カテゴリに割り当てるとHyperSpeedExample の目的は達成できる。車輌は構造化された定義なので、<preference/>カテゴリをvehicle.built.whereに割り当てると、postal構造が始めに他のカテゴリに定義されていたとしても、すべての要素を<preference/>カテゴリに配置し、vehicle.built.whereカテゴリのサブ-要素すべてに定義されたカテゴリを上書き（置き換える）する。

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

このデータ要素とデータ構造の記述はデータスキーマを使って、XMLに符号化される。HyperSpeedExampleの場合、記述は以下の様になる。

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

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

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

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

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

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

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

<POLICIES xmlns="http://www.w3.org/2002/01/P3Pv1">
<!-- Embedded data schema -->
<DATASCHEMA>
<DATA-STRUCT name="vehicle.model" 
    short-description="Model">
    <CATEGORIES><preference/></CATEGORIES>
</DATA-STRUCT>
<DATA-STRUCT name="vehicle.color" 
    short-description="Color">
    <CATEGORIES><preference/></CATEGORIES>
</DATA-STRUCT>
<DATA-STRUCT name="vehicle.built.year" 
    short-description="Construction Year"">
    <CATEGORIES><preference/></CATEGORIES>
</DATA-STRUCT>
<DATA-STRUCT name="vehicle.built.where" 
    structref="http://www.w3.org/TR/P3P/base#postal"
    short-description="Construction Place">
    <CATEGORIES><preference/></CATEGORIES>
</DATA-STRUCT>
<DATA-DEF name="car" structref="#vehicle"/>
<DATA-DEF name="motorcycle" structref="#vehicle"/>
</DATASCHEMA>
<!-- end of embedded data schema -->
<POLICY name="policy1" discuri="http://www.example.com/disc1">
...
<DATA-GROUP base="">
<DATA ref="#car.model"/>
<DATA ref="#car.built.year"/>
</DATA-GROUP>
...
</POLICY>
<POLICY name="policy2" discuri="http://www.example.com/disc2"> .... </POLICY>
<POLICY name="policy3" discuri="http://www.example.com/disc3"> .... </POLICY>
</POLICIES>

どんな場合も、一つのファイルに二つ以上のデータスキーマがあってはならないことに注意。

5.3.3 データ要素の名前の使用

基本データスキーマや拡張データスキーマで指定されたデータ要素名はP3Pポリシー以外の目的に使用されることがあるということに注意。例えば、WebサイトはHTNLフォームフィールドにラベルを付けるためにこれらのデータ要素名を使用することがある。P3Pポリシーやフォームで同じようにデータを参照することによって、自動化された入力ツールはP3Pユーザエージェントによりよく連携することができる。

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

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

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

5.5 基本データ型

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

5.5.1 日付

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

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

5.3.2 名前

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

5.5.3 ログイン

login構造は認証を必要とするコンピュータシステムやWebサイトの情報（IDやパスワード）を指定する。このデータ要素は認証にデジタル認証を使用しているコンピュータシステムやWebサイトに使用すべきではないことに注意。その場合はcertificate構造が使用される。

"id"フィールドはコンピュータシステムのログイン情報のID部分を表している。パスワードは秘密にされているが、ユーザのIDは公開される。これには生物測定学的な認証メカニズムのタイプは含まれない。

"password" フィールドはコンピュータシステムのログイン情報のパスワード部分を表している。これは文字列で、ユーザを認証する際に使用される機密のデータ値である。一般的にパスワードは秘密にされていて、注意が必要な情報だと考えられている。

5.5.4 認証

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

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

5.5.5 電話

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

5.5.6 連絡先情報

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

5.5.6.1 郵便

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

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

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

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

5.5.6.3 オンライン

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

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

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

5.5.7.1 URI

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

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

5.5.7.2 ipaddr

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

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

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

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

5.5.7.3 アクセスログ情報

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

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

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

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

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

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

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

5.6 基本データスキーマ

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

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

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

5.6.1 個人データ

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

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

5.6.2 第三者機関データ

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

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

5.6.3 ビジネスデータ

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

5.6.4 動的データ

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

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

clickstream

clickstream要素は、実質的にすべてのWebサイト適用する。 また、Webサーバアクセスログに一般的にある情報の組み合わせを表示する： ユーザのコンピュータのIPアドレスまたはホスト名、要求されたリソースのURI、 要求がなされた時間、要求の中で使用されたHTTP方式、レスポンスのサイズ、 レスポンスのHTTPステータスコード。 URIパス分析を行うサイトと同様に標準のサーバアクセスログを集めるWebサイトはこのデータ要素を使用して、 どのようにしてこのデータが使用されるのかを述べることができる。 clickstream要素用にリスト化されたデータ要素を数個しか収集しないWebサイトは、 dynamic.clickstream要素全体よりもこれら特定の要素をリストすることを選んでもよい。 このことによって、より制約されたデータ収集プラクティスをもつサイトが正確にサイト訪問者に そのプラクティスを表すことができる。

http

http要素にはHTTPプロトコルに含まれている追加情報がある。 特定の要素の定義に関してはhttpinfo構造の定義を参照のこと。 必要であれば、サイトはhttpinfo構造のすべての要素をカバーする為に dynamic.httpを簡略伝達として使用してもよいし、 httpinfo構造にある特定の要素を参照してもよい。

clientevents

clientevents要素は、リソースとのやりとりを行っている時にユーザがどのようにしてWebブラウザーと やりとりするかについてのデータを表す。例えば、ユーザがページのある画像の上でマウスを動かしたかどうか という事や、ユーザがJavaアプレットのヘルプウインドウを出したかどうかについての情報を アプリケーションが収集する場合。この種の情報は動的.clientevents要素で表示される。 このやりとりの記録の多くは、ドキュメントオブジェクトモデル（DOM）レベル2イベント[DOM2-Events]で定義された イベントとデータで表示される。また、clienteventsデータ要素は、 ブラウザがリソースを表示している間にユーザとブラウザ間のやりとりに関するデータ以外をカバーする。 例外として、基本データスキーマの他の要素がカバーしている要素がある。 例えば、ページを見ている時にリンクをクリックしてページを要求する事はユーザとブラウザのやりとりであるが、 単にユーザがクリックしたURLを収集することはこのデータ要素を宣言する必要がない； clickstreamがそのイベントをカバーしている。 しかしながら、DOMイベントDOMFocusIn（ページのオブジェクトの上をユーザがマウスを動かしているのを表している）は 既存の他の要素ではカバーされていないので、もし、サイトがこのイベントの発生を収集していれば、 動的.clientevents要素を収集していると述べなければならない。 このデータ要素でカバーしている項目は、普通、JavaScriptなどのクライアント側のスクりプティング言語、 またはActiveX またはJava アプレトなどのクライアント側のアプレットで収集される。 以前述べたのはユーザが見ているリソースに関してものだったが、 このデータ要素もリソースを視覚的に表示しないWebアプリケーションに適用していることに注意。 例えば、オーディオベースのWebブラウザなど。

cookies

cookies要素はHTTPクッキーがサイトによって設定されているか、 または検索されている場合には必ず使用されるべきである。 cookiesは可変データ要素であり、 ポリシーでカテゴリの使用を明らかに宣言する必要があることに注意されたい。

miscdata

miscdata要素は特定のデータ要素を使用して参照しないサービスで収集される情報を参照する。 カテゴリはこれらのデータをよりよく表示するために使用される： サイトは収集した雑多なデータの各カテゴリのポリシーにある独立のmiscdata要素を参照しなければならない。

searchtext

searchtext要素はサイトの検索と索引のために使用される特別な誘導の型を参照する。 例えば、検索エンジンの唯一のフィールドが検索フィールドであれば、 サイトはデータ要素を公開することだけを必要とする。

interactionrecord

サーバがユーザとのやりとりの追跡を続けている場合にinteractionrecord要素が使用されるべきである。 （すなわち、クリックストリームデータ以外の情報。例えば、口座取り引きなど。）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.8 データ要素の使用

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

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

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

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

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

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

6. 付録

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

[ABNF]

D. Crocker, P. Overel. "RFC2234 -- Augmented BNF for Syntax Specifications: ABNF," Internet Mail Consortium, Demon Internet Ltd., November 1997.

[CHARMODEL]

M. Durst, F. Yergeau (Eds.), "Character Model for the World Wide Web ," World Wide Web Consortium Working Draft. 29 November 1999.

[DOM2-Events]

T. Pixley (Ed.), "Document Object Model (DOM) Level 2 Events Specification," World Wide Web Consortium, Proposed Recommendation. 27 September 2000.

[HTTP1.0]

T. Berners-Lee, R. Fielding, H. Frystyk, "RFC1945 -- Hypertext Transfer Protocol -- HTTP/1.0," May 1996.

[HTTP1.1]

R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, "RFC2616 -- Hypertext Transfer Protocol -- HTTP/1.1," June 1999. [Updates RFC2068]

[HTML]

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

[KEY]

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

[LANG]

H. Alvestrand, "RFC 1766: Tags for the Identification of Languages", 1995.

[P3P-HEADER]

M. Marchiori, R. Lotenberg (Eds.), "The HTTP header for the Platform for Privacy Preferences 1.0 (P3P1.0)" (also available in HTML and XML formats), IETF Internet Draft, August 2001.

[STATE]

Kristol, D., Montulli, L., "RFC2965 -- HTTP State Management Mechanism." October, 2000 [Obsoletes RFC2109]

[URI]

T. Berners-Lee, R. Fielding, and L. Masinter. "RFC 2396 -- Uniform Resource Identifiers (URI): Generic Syntax and Semantics." August 1998. [Updates RFC1738]

[UTF-8]

F. Yergeau. "RFC2279 -- UTF-8, a transformation format of ISO 10646." January 1998.

[XHTML-MOD]

M. Altheim, et al. (Eds.). "Modularization of XHTML". World Wide Web Consortium, Recommendation. 10 April 2000.

[XML]

T. Bray, J. Paoli, C. M. Sperberg-McQueen, E.MalerEds.). "Extensible Markup Language (XML) 1.0 Specification (Second Edition)." World Wide Web Consortium, Recommendation. 6 October 2000.

[XML-Name]

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

[XML-Schema1]

H. Thompson, D. Beech, M. Maloney, and N. Mendelsohn (Eds.). "XML Schema Part 1: Structures" World Wide Web Consortium Recommendation. 2 May 2001.

[XML-Schema2]

P. Biron, A. Malhotra (Eds.). "XML Schema Part 2: Datatypes" World Wide Web Consortium Recommendation. 2 May 2001.

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

[APPEL]

M. Langheinrich (Ed.). "A P3P Preference Exchange Language (APPEL)" World Wide Web Consortium Working Draft.

[CACHING]

I. Cooper, I. Melve, G. Tomlinson. "RFC3040 -- Internet Web Replication and Caching Taxonomy." January 2001.

[COOKIES]

"Persistent Client State -- HTTP Cookies," Preliminary Specification, Netscape, 1999.

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

[P3P-RDF]

B. McBride, R.Wenning, L.Cranor. "An RDF Schema for P3P." World Wide Web Consortium, Note. 25 January 2001.

[RDF]

O. Lassila and R. Swick (Eds.). "Resource Description Framework (RDF) Model and Syntax Specification." World Wide Web Consortium, Recommendation. 22 February 1999.

[UNICODE]

Unicode Consortium. "The Unicode Standard"

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

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

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

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

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

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

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

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

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

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

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

<!-- "login" Data Structure -->
<DATA-STRUCT name="login.id"
    short-description="Login ID">
    <CATEGORIES><uniqueid/></CATEGORIES>
</DATA-STRUCT>

<DATA-STRUCT name="login.password"
    short-description="Login Password">
    <CATEGORIES><uniqueid/></CATEGORIES>
</DATA-STRUCT>

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

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

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

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

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

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

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

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

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

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

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

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

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

<!-- "postal" Data Structure -->
<DATA-STRUCT name="postal.name" structref="#personname">
</DATA-STRUCT>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<!-- "ipaddr" Data Structure -->
<DATA-STRUCT name="ipaddr.hostname"
    short-description="Complete Host and Domain Name">
    <CATEGORIES><computer/></CATEGORIES>
</DATA-STRUCT>

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

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

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

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

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

<DATA-STRUCT name="loginfo.clientip"
    short-description="Client's IP Address or Hostname"
    structref="#ipaddr">
</DATA-STRUCT>

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

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

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

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

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

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

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

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

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

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

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

<DATA-DEF name="dynamic.interactionrecord"
    short-description="Server Stores the Transaction History">
    <CATEGORIES><interactive/></CATEGORIES>
</DATA-DEF>

<DATA-DEF name="dynamic.miscdata"
    short-description="Miscellaneous Non-base Data Schema =
information"/>

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

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

<DATA-DEF name="user.login"
    short-description="User's Login Information"
    structref="#login">
    <CATEGORIES><uniqueid/></CATEGORIES>
</DATA-DEF>

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

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

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

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

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

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

<DATA-DEF name="user.department"
    short-description="Department or Division of Organization where User is Employed">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-DEF>

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

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

<DATA-DEF name="thirdparty.login"
    short-description="Third Party's Login Information"
    structref="#login">
    <CATEGORIES><uniqueid/></CATEGORIES>
</DATA-DEF>

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

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

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

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

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

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

<DATA-DEF name="thirdparty.department"
    short-description="Department or Division of Organization where Third Party is Employed">
    <CATEGORIES><demographic/></CATEGORIES>
</DATA-DEF>

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

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

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

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

</DATASCHEMA>

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

付録4には、P3Pポリシー参照ファイルとP3Pポリシー文書とP3Pデータスキーマの文書のためのXMLスキーマがある。P3Pポリシー参照ファイル、P3Pポリシー文書そしてP3Pデータスキーマの文書はこのスキーマと一致しなければならないXML文書である。 このXMLスキーマはXMLスキーマ仕様書XML-Schema1][XML-Schema2]に基づいていることに注意されたい。このスキーマはURIhttp://www.w3.org/2002/01/P3Pv1.xsd の独立したファイルに表示されている。

<?xml version='1.0' encoding='UTF-8'?>
<schema
  xmlns='http://www.w3.org/2001/XMLSchema'
  xmlns:p3p='http://www.w3.org/2002/01/P3Pv1'
  targetNamespace='http://www.w3.org/2002/01/P3Pv1'
  elementFormDefault='qualified'>

<!-- enabling xml:lang attribute -->
 <import namespace='http://www.w3.org/XML/1998/namespace' 
    schemaLocation='http://www.w3.org/2001/xml.xsd' />

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


<!-- *********** Policy Reference *********** -->
<!-- ************** META ************** -->
 <element name='META'>
  <complexType>
   <sequence>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
    <element ref='p3p:POLICY-REFERENCES'/>
    <element ref='p3p:POLICIES' minOccurs='0'/>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
   <attribute ref='xml:lang' use='optional'/>
  </complexType>
 </element>

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

 <element name='POLICY-REF'>
  <complexType>
   <sequence>
    <element name='INCLUDE' 
             minOccurs='0' maxOccurs='unbounded' type='anyURI'/>
    <element name='EXCLUDE' 
             minOccurs='0' maxOccurs='unbounded' type='anyURI'/>
    <element name='COOKIE-INCLUDE' 
             minOccurs='0' maxOccurs='unbounded' type='p3p:cookie-element'/>
    <element name='COOKIE-EXCLUDE'
             minOccurs='0' maxOccurs='unbounded' type='p3p:cookie-element'/>
    <element name='METHOD' 
             minOccurs='0' maxOccurs='unbounded' type='anyURI'/>
    <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
   <attribute name='about' type='anyURI' use='required'/>
  </complexType>
 </element>

 <complexType name='cookie-element'>
  <attribute name='name' type='string' use='optional'/>
  <attribute name='value' type='string' use='optional'/>
  <attribute name='domain' type='string' use='optional'/>
  <attribute name='path' type='string' use='optional'/>
 </complexType>

<!-- ************* HINT ************* -->
 <element name='HINT'>
  <complexType>
   <attribute name='scope' type='string' use='required'/>
   <attribute name='path' type='string' use='required'/>
  </complexType>
 </element>

<!-- ************ POLICIES ************ -->
 <element name='POLICIES'>
  <complexType>
   <sequence>
    <element ref='p3p:EXPIRY' minOccurs='0'/>
    <element ref='p3p:DATASCHEMA' minOccurs='0'/>
    <element ref='p3p:POLICY' minOccurs='0' maxOccurs='unbounded'/>
   </sequence>
   <attribute ref='xml:lang' use='optional'/>
  </complexType>
 </element>


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

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

<!-- ************* TEST ************* -->
 <element name='TEST'>
  <complexType/>
 </element>

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

 <complexType name='data-in-entity' mixed='true'>
  <attribute name='ref' type='anyURI' use='required'/>
 </complexType>

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

 <complexType name='access-value'/>

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

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

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

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

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

 <complexType name='remedies-value'/>

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

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

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

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

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

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

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

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

 <complexType name='retention-value'/>

<!-- ************** DATA ************** -->
 <complexType name='data-group-type'>
  <sequence>
   <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
   <element name='DATA' type='p3p:data-in-statement' maxOccurs='unbounded'/>
   <element ref='p3p:EXTENSION' minOccurs='0' maxOccurs='unbounded'/>
  </sequence>
  <attribute name='base' type='anyURI' 
             use='optional' default='http://www.w3.org/TR/P3P/base'/>
 </complexType>

 <complexType name='data-in-statement' mixed='true'>
  <sequence minOccurs='0' maxOccurs='unbounded'>
   <element ref='p3p:CATEGORIES'/>
  </sequence>
  <attribute name='ref' type='anyURI' use='required'/>
  <attribute name='optional' use='optional' default='no' type='p3p:yes_no'/>
 </complexType>

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

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

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

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

 <complexType name='categories-value'/>

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

</schema>

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

この付録では、P3Pポリシー参照ファイル、P3Pポリシー文書そしてP3Pデータスキーマ文書のためのDTDを含む。 P3Pが有効であることを確認するためにこのDTDを使用してもよい。（しかし、DTDと比較した場合、拒否される有効なファイルが存在することがあることに注意。） DTDはURIhttp://www.w3.org/2002/01/P3Pv1.dtdの独立したファイルに表示されている。

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

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

<!-- ************** META ************** -->
<!ELEMENT META (EXTENSION*, POLICY-REFERENCES, POLICIES?, EXTENSION*)>
<!ATTLIST META xml:lang NMTOKEN #IMPLIED>
<!ATTLIST META xmlns #FIXED "http://www.w3.org/2002/01/P3Pv1">

<!-- ******* POLICY-REFERENCES ******** -->
<!ELEMENT POLICY-REFERENCES (EXPIRY?, POLICY-REF*, HINT*, EXTENSION*)>

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

<!-- ************** HINT ************** -->
<!ELEMENT HINT EMPTY>
<!ATTLIST HINT
    scope  CDATA  #IMPLIED
    path   CDATA  #IMPLIED >

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

<!-- ************ POLICIES ************ -->
<!ELEMENT POLICIES (EXPIRY?, DATASCHEMA?,
    POLICY*)>
<!ATTLIST POLICIES xml:lang NMTOKEN #IMPLIED>
<!ATTLIST POLICIES xmlns #FIXED "http://www.w3.org/2002/01/P3Pv1">

<!-- ***** INCLUDE/EXCLUDE/METHOD ***** -->
<!ELEMENT INCLUDE          (#PCDATA)>
<!ELEMENT EXCLUDE          (#PCDATA)>
<!ELEMENT COOKIE-INCLUDE   EMPTY>
<!ATTLIST COOKIE-INCLUDE
    name   CDATA  #IMPLIED
    value  CDATA  #IMPLIED
    domain CDATA  #IMPLIED
    path   CDATA  #IMPLIED>
<!ELEMENT COOKIE-EXCLUDE   EMPTY>
<!ATTLIST COOKIE-EXCLUDE
    name   CDATA  #IMPLIED
    value  CDATA  #IMPLIED
    domain CDATA  #IMPLIED
    path   CDATA  #IMPLIED>
<!ELEMENT METHOD           (#PCDATA)>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


<!-- *********** DATA SCHEMA *********** -->
<!ELEMENT DATASCHEMA (DATA-DEF | DATA-STRUCT | EXTENSION)*>
<!ATTLIST DATASCHEMA xml:lang NMTOKEN #IMPLIED>
<!ATTLIST DATASCHEMA xmlns #FIXED "http://www.w3.org/2002/01/P3Pv1">

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

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

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

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

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

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

name = (elements) 

<name> は規則名で、<elements> は複数の規則名または、 以下の数式によって得られた結果である。規則名は大文字/小文字を区別しない。 

(element1 element2)

括弧によって囲まれた要素は一つの要素として扱われるが、括弧内の要素は厳密に順序付けられる。

<a>*<b>element

<a> 個から <b> 個の要素。

(1*4<element> は1〜4要素を意味する)

<a>element

<a> 個の要素。

(4<element> は4個の要素を意味する)

<a>*element

<a> 個、またはそれ以上の要素。

(4*<element> は4個、またはそれ以上の要素を意味する)

*<b>element

0から <b> 個の要素

(*5<element> は0〜5個の要素を意味する)

*element

0個以上の要素。

(*<element> 0〜無限の要素を意味する)

[element]

オプション要素、*1(element)と同等。

([element] は 0 または 1要素を意味する)

"string" or 'string'

""内に与えられた文字列を意味する。

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

; または /* ... */

コメント。

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

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

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

情報プライバシー

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

P3Pアーキテクチャワーキンググループの参加メンバーは以下の通りである：Martin Presler-Marshall (IBM, 議長), Mark Ackerman (W3C), Lorrie Cranor (AT&T), Philip DesAutels (W3C), Melissa Dunn (Microsoft), Joseph Reagle (W3C).

最後に、付録7はW3Cノートの中の "P3P Guiding Principles" を元に作成したものである。その署名者は以下の通りである： Azer Bestavros (Bowne Internet Solutions), Ann Cavoukian (Information and Privacy Commission Ontario Canada), Lorrie Faith Cranor (AT&T Labs-Research), Josef Dietl (W3C), Daniel Jaye (Engage Technologies), Marit Köhntopp (Land Schleswig-Holstein), Tara Lemmey (Narrowline; TrustE), Steven Lucas (MatchLogic), Massimo Marchiori (W3C/MIT), Dave Marvit (Fujitsu Labs), Maclen Marvit (Narrowline Inc.), Yossi Matias (Tel Aviv University), James S. Miller (MIT), Deirdre Mulligan (Center for Democracy and Technology), Joseph Reagle (W3C), Drummond Reed (Intermind), Lawrence C. Stewart (Open Market, Inc.).

2001年9月28日ラストコールワーキングドラフトからの改訂履歴

• 例の中の間違いと全体的な誤字を訂正した。
• 参考文献と標準準拠の項目を更新した。
• (2001年12月12日に従って)P3P 更新ページから
  • E20: 完了
  • E21: 完了
  • E22: 完了
  • E23: 完了
  • E24: 完了
  • E25: 完了
  • E26: 完了
  • E27: 完了 [プラス、必要なフィールドのスキーマとクリスパー定義を改良した。]
  • S31: 完了
  • S32: 完了
  • S33: 完了
  • S34: 変更して完了[2.3.2.9 章の複写は完了していない(ほとんど意味がない)。3.5章に対応するために拡大しただけ。]
  • S35: 変更して完了 [S36と一緒にまとめ、1.2に付加]
  • S36: 変更して完了 [S35と一緒にまとめ、1.2に付加]
  • S37: 完了
  • S38: 完了
  • S39: 完了
  • S40: 未完
  • S41: 完了
  • S42: 完了
  • S43: 完了
  • S44: 完了
• P3P更新ページではないその他の編集 :
  • ACCESS、DISPUTES-GROUP、 REMEDIES、PURPOSE、RECIPIENT、RETENTION、DATA-GROUPの始めにオプションの拡張子を追加した。
  • POLICY-REFの終わりにオプションの拡張子を追加した。
  • (P3Pコンポーネントの前後に）METAは拡張メカニズムを使用し、P3Pコンポーネントの後には一般的なマークアップはない。(DTDとスキーマをはめ込む。)
  • DTDにオプションのP3P xmlns 宣言をMETA、POLICIESそして、DATASCHEMAに追加した。
  • XHTMLのサポートを追加した。
  • クッキーについての説明(2.3.2.5章と2.3.2.7章を改良した。)