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

W3Cワーキングドラフト 2000年10月18日

この版:

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

最新公開版:

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

旧版:

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

編集者:

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

著者:

Lorrie Cranor, AT&T

Marc Langheinrich, ETH Zurich

Massimo Marchiori, W3C/MIT/UNIVE

Martin Presler-Marshall, IBM

Joseph Reagle, W3C/MIT

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

---

要旨

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

本文書の位置付け 　　

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

本文書は、P3Pアクティビティの一つであるP3P仕様書ワーキンググループに依って作成されたものである。このワーキンググループは本書をラストコールのドラフトとして発行することに同意[メンバーのみ] する。このラストコールの期限に続いて、ワーキンググループは発行するこの仕様書を勧告になるものとして提出する意図がある。

本仕様書は、他の仕様書によりいつでも改版・置換・陳腐化の可能性のあるドラフトの仕様書である。従って、W3Cのワーキングドラフトを"進行中の作業"ではないとして参考文献資料やその他として参照することは不適切である 本文書の改訂版は、少なくとも2つの相互互換性のあるインプリメンテーションのデモンストレーションが実施された後に、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 タグ
   3. ポリシー参照ファイルの構文とセマンティクス
      1. ポリシー参照ファイルの例
      2. ポリシー参照ファイルの定義
         1. ポリシー参照ファイルの処理
            1. 順序の意義
            2. ポリシー参照ファイルのワイルドカード
         2. METAとPOLICY-REFERENCES要素
         3. ポリシー参照ファイルの有効期限とEXPIRY element要素
            1. モチベーションとメカニズム
            2. EXPIRY要素
            3. HTTPヘッダの使用
            4. ポリシー参照ファイル有効期限のためのエラー処理
         4. POLICY-REF要素
         5. INCLUDEおよびEXCLUDE要素
         6. EMBEDDED-INCLUDEおよびEMBEDDED-EXCLUDE要素
         7. COOKIE-INCLUDEおよびCOOKIE-EXCLUDE要素
         8. METHOD要素
      3. ポリシーをURIへ適用
      4. フォームおよび関連するメカニズム
   4. 追加要求項目
      1. 一義性
      2. 多言語
      3. セーフゾーン
      4. ポリシーの非差別化
      5. ポリシーの送信に関するセキュリティ
      6. ポリシー改版
   5. シナリオの例
3. ポリシーの構文とセマンティクス
   1. ポリシーの例
      1. 自然言語のポリシー
      2. ポリシーのXMLコード化
   2. ポリシー
      1. POLICIES要素
      2. POLICY要素
      3. ENTITY要素
      4. ACCESS要素
      5. DISPUTES要素
      6. REMEDIES要素
   3. ステートメント
      1. STATEMENT要素
      2. CONSEQUENCE要素
      3. NON-IDENTIFIABLE要素
      4. PURPOSE要素
      5. RECIPIENT要素
      6. RETENTION要素
      7. DATA-GROUPとDATA要素
   4. カテゴリ
   5. 拡張メカニズム
   6. APPEL処理
4. データスキーマ
   1. DATA-DEFとDATA-STRUCT要素
   2. データスキーマの持続有効性
   3. 基本データ型
      1. 日付
      2. 名前
      3. 認証
      4. 電話
      5. 連絡先情報
         1. 郵便
         2. テレコミュニケーション
         3. オンライン
      6. アクセスログとインターネットアドレス
         1. URI
         2. ipaddr
         3. アクセスログ情報
         4. その他HTTPプロトコル情報
   4. 基本データスキーマ
      1. 個人データ
      2. 第三機関データ
      3. ビジネスデータ
      4. 動的データ
   5. カテゴリおよびデータ要素/構造
      1. 固定カテゴリデータ要素/構造
      2. 可変カテゴリデータ要素/構造
   6. データ要素の使用
5. 付録
   付録 1：参考文献（標準準拠）
   付録 2: 参考文献 (標準非準拠)
   付録 3：P3P基本データスキーマ定義（標準準拠）
   付録 4：XMLスキーマ定義（標準準拠）
   付録 5：XML DTD 定義（標準準拠）
   付録 6：ABNF表記法 (標準非準拠)
   付録 7：P3Pガイドライン (標準非準拠)
   付録 8：ワーキンググループ貢献者 (標準非準拠)

1. 序論

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

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

1.1 P3P1.0仕様書

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

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

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

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

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

1.1.2 P3P利用例

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

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

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

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

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

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

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

1.1.3 P3Pポリシー

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

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

1.1.4 P3Pユーザエージェント

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

1.1.5 サーバ上でのP3Pの実装

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

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

1.1.6 P3Pの将来バージョン

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

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

1.2 本仕様書について

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

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

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

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

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

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

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

「〜してもよい」

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

1.3 専門用語

Character

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

データ要素

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

データカテゴリ

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

データ集合

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

等価なプラクティス

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

個人特定可能情報

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

ポリシー

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

プラクティス

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

プリファレンス

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

目的

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

レポジトリ

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

Safe Zone

サービスプロバイダーが最低限のデータ収集をおこなうWebサイトの一部であり、収集されたあらゆるデータが識別不可能な方法の場合にのみ使用される。 ways.

サービス

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

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

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

ステートメント

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

URI

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

利用者

サービスを利用し、個人情報を有する個人(または、単体の様に行動する人々のグループ)をいう。

ユーザエージェント

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

2. ポリシー参照

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

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

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

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

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

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

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

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

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

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

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

与えられた実体に適用するポリシーを作成するユーザエージェントのために、そのポリシーはその実体用のポリシー参照ファイルを発見し、そのポリシー参照ファイルを取り出し、一つまたはそれ以上のP3Pポリシーを解析しなければならない。

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

2.2.1 周知の存在場所

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

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

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

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

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

2.2.2 HTTPヘッダ

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

P3Pヘッダは一つ以上のコンマで区切られたディレクトリを提供する。以下がその構文である。

[1]	p3p-header	=	`P3P: ` p3p-header-field *(`,` p3p-header-field)
[2]	p3p-header-field	=	policy-ref-field | extension-field
[3]	policy-ref-field	=	`policyref="` URI `"`
[4]	extension-field	=	token [`=` (token | quoted-string) ]
ここで、URIはRFC 2396[URI]によって定義され、tokenとquoted-stringは[HTTP1.1]によって定義されている。

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

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

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

例 2.1:

1. 1． ClientがGET要求をおこなう。

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

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

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

2.2.3 HTML link タグ

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

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

p3p-link-tag

=

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 </POLICY-REFERENCES>
</META>

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

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

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

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

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

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

2.3.2.1.1 順序の意義

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

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

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

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

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

2.3.2.2 METAおよびPOLICY-REFERENCES要素

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

<POLICY-REFERENCES>

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

[6]	prf	=	`<META xmlns="http://www.w3.org/2000/10/18/P3Pv1">` policyrefs [policies] PCDATA "</META>"
[7]	policyrefs	=	"<POLICY-REFERENCES>" [expiry] *policyref "</POLICY-REFERENCES>"
ここで、PCDATAは[XML]で定義されている。

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

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

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

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

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

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

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

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

2.3.2.3.2 EXPIRY要素

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

[8]	expiry	=	"<EXPIRY" (absdate|reldate) "/>"
[9]	absdate	=	`date="` HTTP-date `"`
[10]	reldate	=	`max-age="` delta-seconds `"`
ここで, HTTP-日付は[HTTP1.1]の3.3.1節 で定義されており、delta-seconds は[HTTP1.1]の3.3.2節で定義されている。

2.3.2.3.3 HTTPヘッダの使用

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

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

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

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

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

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

2.3.2.4 POLICY-REF要素

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

POLICY-REF

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

about (必須の属性)

P3PプライバシーポリシーのURI。もしこれが関連するURLであれば、ポリシー参照ファイルのURIに関するものとして解釈される。これは、ポリシー参照ファイルに含まれているポリシーへの参照となるかもしれない。そのために、#policy-nameはポリシーURIを与える。そしてこの場合、policy-nameがこのポリシー参照ファイルのポリシーのname属性で値を与えられる。

policy-ref

=

`<POLICY-REF about="` URI `">`
*include
*exclude
*cookie-include
*cookie-exclude
*embedded-include
*embedded-exclude
*method-element
`</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は含まない。

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

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

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

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

[12]	include	=	"<INCLUDE>" relativeURI "</INCLUDE>"
[13]	exclude	=	"<EXCLUDE>" relativeURI "</EXCLUDE>"
ここで、relativeURIは2.3.2.1.2節で定義されているように、'*' 文字がワイルドカードとして取り扱われている付加でRFC 2396 [URI]に従って定義されている。

2.3.2.6 EMBEDDED-INCLUDE要素およびEMBEDDED-EXCLUDE要素

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

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

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

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

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

ユーザエージェントはこのポリシーが第三のコンテンツに適用している事を決める為に、ポリシー参照ファイルのEMBEDDED-INCLUDE要素とEMBEDDED-EXCLUDE要素を解釈するべきである。リダイレクトを作成するコンテンツ用にこのようなポリシーの関係を使用するべきではない。

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

例 2.5:

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

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

[16]	embedded-include	=	"<EMBEDDED-INCLUDE>" absoluteURI "</EMBEDDED-INCLUDE>"
[17]	embedded-exclude	=	"<EMBEDDED-EXCLUDE>" absoluteURI "</EMBEDDED-EXCLUDE>"
ここで、absoluteURIは2.3.2.1.2節で定義されているように、'*' 文字がワイルドカードとして取り扱われている付加でRFC 2396[URI]に従って定義されている。

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

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

2.3.2.7 COOKIE-INCLUDE とCOOKIE-EXCLUDE要素

HTMLページにはステート管理メカニズム（クッキーで知られている）のインスタンスがよくある。クッキーにはHTMLページの適用範囲とは異なる適用範囲があるので、ユーザエージェントは現在レイアウトされているページを有効にするために、このポリシーでカバーされているかまたはカバーされていない追加的な要求を作成する必要があることがある。COOKIE-INCLUDEおよびCOOKIE-EXCLUDE要素はクッキーとポリシーを対応付けるために使用される。

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

各COOKIE-INCLUDEおよびCOOKIE-EXCLUDE要素は、いずれかまたはすべてがワイルドカード化したName、Domain、Path属性で構成されているクッキーネーム空間を指定する。これらのプレフィックスは（INCLUDEとEXCLUDEに似ているが）ポリシー参照ファイルが存在するWebサイト上の文書からクッキーが設定された時にabout属性が指定したポリシーによってカバーされているクッキーネーム空間を指定するために使用される。

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

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

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

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

例 2.3:

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

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

例 2.4:

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

[14]	cookie-include	=	"<COOKIE-INCLUDE>" NAME "." Domain Path "</COOKIE-INCLUDE>"
[15]	cookie-exclude	=	"<COOKIE-EXCLUDE>" NAME "." Domain Path "</COOKIE-EXCLUDE>"
ここでは、2.3.2.1.2節で定義されているように、'*' 文字がワイルドカードとして取り扱われている付加でNAME、Domain とPathはRFC 2965 [STATE]に従って定義されている。

[STATE]と同じ様に、はっきりと定義されたDomain値がドットで始まっていなければ、ユーザエージェントはリーディングドットを提供しなければならないことに注意。そのため、COOKIE-INCLUDE （またはCOOKIE-EXCLUDE）要素内のNAMEとDomainの分類はダブルドット".."があるのを見つけることによって簡単に識別することができる。また、Pathすべてが"/" シンボルで始まるので、（Domain内には発生できない）、DomainとPathの分類は"/"のの後のダブルドットで始まるのを見つける事によって同じように識別できる。

2.3.2.8 METHOD要素

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

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

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

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

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

method-element

=

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

2.3.3 ポリシーをURIへ適用

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

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

"クライアントソフトウェアが行うと考えられている行動"という概念には、クライアント側のクッキーやレスポンスによって呼び出されるステート管理メカニズムの設定が含まれている。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ポリシーは、この電子メールプログラムを使用して収集する事のできるデータについてのステートメントを作成する必要がない。この電子メールプログラムをインストールし、起動することはWebブラウジングをすることとは明らかに違うものであるので、この仕様書ではカバーしていない。異なるプロトコルのダウンロードヲ可能にしたアプリケーションをP3Pに表すことができるようにデザインする事ができたが、この仕様書には述べない。
4. フォームを含んでいるHTMLページはカスタムクライアントコントロールを提供する実行可能なものへの参照を含む。このコントロールにあるデータはフォームが提示された時にサイトへ提示される。この場合、HTMLページのURIとカスタムコントロールのURIは、カスタムコントロールが表示しているデータについてのステートメントを作成する必要がない。しかしながら、フォームコンテンツがあるURIは、フォームを処理する事で他のデータをカバーするように、カスタムコントロールからのデータをカバーしなければならない。このふるまいは、HTMLっフォームが標準ののHTMLコントロールを使用する時のHTMLの処理方法と類似している。このコントロール自身はデータを収集することはなく、このフォームが知らされた時にデータが収集される。この例はユーザが積極的に"Submit"やそれに類似したボタンを押すとこのフォームが通知されるだけであるということを仮定していることに注意されたい。フォームが自動的に通知されれば、（例えばこのページのJavaScriptコードで）この例は例#2と類似するだろう。そして、フォームから収集されたデータはHTMLフォームをカバーしているP3Pポリシーに記述されなければならない。
5. URIへの要求は第三者ヘリダイレクトされる。第一者が以前収集した個人データを照会列やリダイレクトURIの他の部分に埋め込めば、第一者のURIのプライバシーポリシーは転送されたデータ種類を記述しなくてはならないし、第三者を受領者としてとりこまなければならない。

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

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

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

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

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

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

2.4 追加要求事項

2.4.1 一義性

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

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

2.4.2 多言語

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

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

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

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

2.4.3 "セーフゾーン"

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

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

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

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

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

2.4.4 ポリシーの非差別化

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

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

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

HTTP HEAD HEAD 要求のサポート

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

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

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

2.4.6 ポリシーの改版

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

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

2.5 シナリオの例

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

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

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

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

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

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

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

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

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

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

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

3.1 ポリシーの例

3.1.1 自然言語のポリシー

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1.2 ポリシーのXMLコード化

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

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

<POLICY xmlns="http://www.w3.org/2000/10/18/P3Pv1"
	discuri="http://www.catalog.example.com/PrivacyPracticeBrowsing.html">
 <ENTITY>
  <DATA-GROUP>
   <DATA ref="#business.name">CatalogExample</DATA>
   <DATA ref="#business.contact-info.postal.street">4000 Lincoln Ave.</DATA>
   <DATA ref="#business.contact-info.postal.city">Birmingham</DATA>
   <DATA ref="#business.contact-info.postal.stateprov">MI</DATA>
   <DATA ref="#business.contact-info.postal.postalcode">48009</DATA>
   <DATA ref="#business.contact-info.postal.country">USA</DATA>
   <DATA ref="#business.contact-info.online.email">catalog@example.com</DATA>
   <DATA ref="#business.contact-info.telecom.telephone.intcode">1</DATA>
   <DATA ref="#business.contact-info.telecom.telephone.loccode">248</DATA>
   <DATA ref="#business.contact-info.telecom.telephone.number">3926753</DATA>
  </DATA-GROUP>
 </ENTITY>
 <ACCESS><nonident/></ACCESS>
 <DISPUTES-GROUP>
  <DISPUTES resolution-type="independent"
	service="http://www.PrivacySeal.example.org"
	short-description="PrivacySeal.example.org">
   <IMG src="http://www.PrivacySeal.example.org/Logo.gif" alt="PrivacySeal's logo"/>
   <REMEDIES><correct/></REMEDIES>
  </DISPUTES>
 </DISPUTES-GROUP>
 <STATEMENT>
  <PURPOSE><admin/><develop/></PURPOSE>
  <RECIPIENT><ours/></RECIPIENT>


  <RETENTION><stated-purpose/></RETENTION> 

  <DATA-GROUP>
   <DATA ref="#dynamic.clickstream"/>
   <DATA ref="#dynamic.http"/>
  </DATA-GROUP>
 </STATEMENT>
</POLICY>

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

<POLICY xmlns="http://www.w3.org/2000/10/18/P3Pv1"
	discuri="http://www.catalog.example.com/Privacy/PrivacyPracticeShopping.html"
	opturi="http://catalog.example.com/preferences.html">
 <ENTITY>
  <DATA-GROUP>
   <DATA ref="#business.name">CatalogExample</DATA>
   <DATA ref="#business.contact-info.postal.street">4000 Lincoln Ave.</DATA>
   <DATA ref="#business.contact-info.postal.city">Birmingham</DATA>
   <DATA ref="#business.contact-info.postal.stateprov">MI</DATA>
   <DATA ref="#business.contact-info.postal.postalcode">48009</DATA>
   <DATA ref="#business.contact-info.postal.country">USA</DATA>
   <DATA ref="#business.contact-info.online.email">catalog@example.com</DATA>
   <DATA ref="#business.contact-info.telecom.telephone.intcode">1</DATA>
   <DATA ref="#business.contact-info.telecom.telephone.loccode">248</DATA>
   <DATA ref="#business.contact-info.telecom.telephone.number">3926753</DATA>
  </DATA-GROUP>
 </ENTITY>
 <ACCESS><contact_and_other/></ACCESS>
 <DISPUTES-GROUP>
  <DISPUTES resolution-type="independent"
	service="http://www.PrivacySeal.example.org"
	short-description="PrivacySeal.example.org">
   <IMG src="http://www.PrivacySeal.example.org/Logo.gif" alt="PrivacySeal's logo"/>
   <REMEDIES><correct/></REMEDIES>
  </DISPUTES>
 </DISPUTES-GROUP>
 <STATEMENT>
  <CONSEQUENCE>
	We record some information in order to serve your request 
	and to secure and improve our web site.
  </CONSEQUENCE>
  <PURPOSE><admin/><develop/></PURPOSE>
  <RECIPIENT><ours/></RECIPIENT>
  <RETENTION><stated-purpose/></RETENTION>
  <DATA-GROUP>
   <DATA ref="#dynamic.clickstream.server"/>
   <DATA ref="#dynamic.http.useragent"/>
  </DATA-GROUP>
 </STATEMENT>
 <STATEMENT>
  <CONSEQUENCE>
	We use this information when you make a purchase.
  </CONSEQUENCE>
  <PURPOSE><current/></PURPOSE>
  <RECIPIENT><ours/></RECIPIENT>
  <RETENTION><stated-purpose/></RETENTION>
  <DATA-GROUP>
   <DATA ref="#user.name"/>
   <DATA ref="#user.home-info.postal"/>
   <DATA ref="#user.home-info.telecom.telephone"/>
   <DATA ref="#user.business-info.postal"/>
   <DATA ref="#user.business-info.telecom.telephone"/>
   <DATA ref="#user.home-info.online.email"/>
   <DATA ref="#dynamic.miscdata">
	<CATEGORIES><purchase/></CATEGORIES>
   </DATA>
  </DATA-GROUP>
 </STATEMENT>
 <STATEMENT>
  <CONSEQUENCE>
	At your request, we will send you carefully selected marketing 
	solicitations that we think you will be interested in.
  </CONSEQUENCE>
  <PURPOSE>
   <contact required="opt_in"/>
   <customization required="opt_in"/>
   <tailoring required="opt_in"/>
  </PURPOSE>
  <RECIPIENT required="opt_in"><ours/><same/></RECIPIENT>
  <RETENTION><stated-purpose/></RETENTION>
  <DATA-GROUP>
   <DATA ref="#user.name" optional="yes"/>
   <DATA ref="#user.home-info.postal" optional="yes"/>
   <DATA ref="#user.home-info.telecom.telephone" optional="yes"/>
   <DATA ref="#user.business-info.postal" optional="yes"/>
   <DATA ref="#user.business-info.telecom.telephone" optional="yes"/>
   <DATA ref="#user.home-info.online.email" optional="yes"/>
  </DATA-GROUP>
 </STATEMENT>
 <STATEMENT>
  <CONSEQUENCE>
	We allow you to set a password so that you
	can access your own information.
  </CONSEQUENCE>
  <PURPOSE><customization required="opt_in"/></PURPOSE>
  <RECIPIENT><ours/></RECIPIENT>
  <RETENTION><stated-purpose/></RETENTION>
  <DATA-GROUP>
   <DATA ref="#dynamic.miscdata">
	<CATEGORIES><uniqueid/></CATEGORIES>
   </DATA>
  </DATA-GROUP>
 </STATEMENT>
 <STATEMENT>
  <CONSEQUENCE>
	At your request, we will tailor our site and 
	highlight products related to your interests.
  </CONSEQUENCE>
  <PURPOSE>
	<customization required="opt_in"/>
	<tailoring required="opt_in"/>
  </PURPOSE>
  <RECIPIENT><ours/></RECIPIENT>
  <RETENTION><stated-purpose/></RETENTION>
  <DATA-GROUP>
   <DATA ref="#user.bdate.ymd.year" optional="yes"/>
   <DATA ref="#user.gender" optional="yes"/>
  </DATA-GROUP>
 </STATEMENT>
 <STATEMENT>
  <CONSEQUENCE>
	We tailor our site based on your past visits.
  </CONSEQUENCE>
  <PURPOSE><tailoring/><develop/></PURPOSE>
  <RECIPIENT><ours/></RECIPIENT>
  <RETENTION><stated-purpose/></RETENTION>
  <DATA-GROUP>
   <DATA ref="#dynamic.cookies">
	<CATEGORIES><state/></CATEGORIES>
   </DATA>
   <DATA ref="#dynamic.miscdata">
	<CATEGORIES><preference/></CATEGORIES>
   </DATA>
  </DATA-GROUP>
 </STATEMENT>
</POLICY>

3.2 ポリシー

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

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

3.2.1 POLICIES要素

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

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

例 3.3:

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

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

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

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

[19]

policies

=

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

3.2.2  POLICY要素

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

<POLICY>

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

discuri (必須の属性)

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

opturi

ユーザが特別な目的（opt_inまたはopt_out）のために使用されるデータを要求したり、拒否したりする際に従うことのできるURIの指示のこと。この属性はopt-in または opt-outに設定されている必要な属性と一緒に purposeを含むポリシーに必須である。

name

このポリシーの名前。ポリシーを参照することのできるフラグメント識別子。ポリシーがPOLICIES要素にあれば、この属性は必須である。

policy

=

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

quoted-URI

=

`"` URI `"`

3.2.3 ENTITY要素

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

<ENTITY>

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

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

entity

=

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

entitydescription

=

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

3.2.4 ACCESS要素

<ACCESS>

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

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

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

<nonident/>

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

<all/>

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

<contact_and_other/>

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

<ident_contact/>

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

<other_ident/>

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

<none/>

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

access

=

access-disclosure

=

3.2.5 DISPUTES要素

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

<DISPUTES>

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

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

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

顧客窓口(Customer service) [service]

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

独立機関(Independent organization)[independent]

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

裁判所(Court) [court]

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

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

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

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

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

検証(verification)

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

簡易表記(short-description)

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

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

<長い表記（LONG-DESCRIPTION）>

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

<IMG>

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

src (必須の属性)

イメージロゴのURI

幅(width)

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

高さ(height)

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

代替テキスト(alt)(必須の属性)

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

disputes-group

=

"<DISPUTES-GROUP>"
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

=