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

W3C勧告候補 2000年12月15日

この版:

http://www.w3.org/TR/2000/CR-P3P-20001215

最新公開版:

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

旧版:

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

編集者:

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

著者:

Lorrie Cranor, AT&T

Marc Langheinrich, ETH Zurich

Massimo Marchiori, W3C/MIT/UNIVE

Martin Presler-Marshall, IBM

Joseph Reagle, W3C/MIT

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

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

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

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

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

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

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

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

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

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

必須機能の要約：

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

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

推奨される機能の要約：

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

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

目次

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要素
            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. 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集合とDATA要素
   4. カテゴリ
   5. 拡張メカニズム
   6. ユーザプリファレンスのインポートとエクスポート
4. 簡潔なポリシー
   1. 簡潔なポリシーの参照
   2. 簡潔なポリシーのボキャブラリ
      1. 簡潔なPURPOSE
      2. 簡潔なRECIPIENT
      3. 簡潔なRETENTION
      4. 簡潔なCATEGORIES
      5. 簡潔なNON-IDENTIFIABLE
      6. 簡潔なDISPUTES
      7. 簡潔なACCESS
      8. 簡潔なREMEDIES
      9. 簡潔なTEST
   3. 簡潔なポリシーの範囲
   4. 簡潔なポリシーの有効期限
   5. P3Pポリシーを簡潔なポリシーへ変換する
   6. 簡潔なポリシーをP3Pポリシーへ変換する
5. データスキーマ
   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. データ要素の使用
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ポリシーは、ポリシーの中にプライバシー情報を如何に処理するか表記している組織を識別するためP3PボキャブラリのXMLエンコーディングを用い、収集されるデータ型とデータ要素を列挙し、そして、どの様にデータが使われるか説明する。更に、ポリシーは、データの受領者を明確にし、係争解決のための情報のような情報開示にまつわる諸々のものを作成可能にし、当該サイトの人間が読むことのできるプライバシーポリシーの存在場所(URL)の通知を行う。P3Pポリシーは、関係する総てのデータ要素とそれをどう使うかカバーしなければならない。(しかし、法の執行の際に必要とされる情報に関する法律的問題はこの仕様書では関知しない。：例えば、公権力によって要求された場合、第三者に提供しないはずのデータがポリシーの規定に反して、他の組織に提供されることがあるかもしれない。)P3Pの記述は、ポジティブな記述であるべきである。すなわち、あるサイトが何々をしないと記述するよりは、何々を行うと記述することが望ましい。P3Pボキャブラリは、ある特殊な法律や行動規範に準拠するためのインディケータというより、サイトがプライバシー情報を如何に取り扱うかを記述することを目的に設計されている。しかしながら、幾つかのユーザエージェントは、サイトのプライバシー情報の取り扱い方が法律や行動規範に合っているか否かテストするために、開発されるかもしれない。

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

1.1.4 P3Pユーザエージェント

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

1.1.5 サーバ上でのP3Pの実装

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

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

1.1.6 P3Pの将来バージョン

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

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

1.2 本仕様書について

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

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

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

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

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

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

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

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

「〜してもよい」

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

1.3 専門用語

文字

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

データ要素

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

データカテゴリ

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

データ集合

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

等価なプラクティス

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

個人特定可能情報

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

ポリシー

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

プラクティス

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

プリファレンス

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

目的

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

レポジトリ

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

セーフゾーン

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

サービス

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

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

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

ステートメント

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

URI

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

利用者

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

ユーザエージェント

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

2. ポリシー参照

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.1 周知の存在場所

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

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

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

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

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

2.2.2 HTTPヘッダ

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

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

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

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

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

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

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

例 2.1:

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

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

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

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

2.2.3 HTML linkタグ

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

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

[5]	p3p-link-tag	=	`<link rel="P3Pv1" href="` URI `">`
ここで、URIはRFC 2396 [URI]に従って定義されている。

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

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

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

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

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

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

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

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

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

例 2.2:

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

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

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

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

 </POLICY-REFERENCES>
</META>

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

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

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

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

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

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

2.3.2.1.1 順序の意義

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

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

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

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

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

2.3.2.2 META および POLICY-REFERENCES 要素

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

<POLICY-REFERENCES>

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

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

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

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

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

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

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

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

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

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

2.3.2.3.2 EXPIRY 要素

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

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

2.3.2.3.3 HTTPヘッダの使用

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

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

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

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

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

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に関するものとして解釈される。 これは、ポリシー参照ファイルに含まれているポリシーへの参照としてもよい。 そのために、ポリシーURIは#policy-nameによって与えられ、 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>"
ここで、相対URIはsection 2.3.2.1.2節で定義されているように、'*' 文字がワイルドカードとして取り扱われている事と共にRFC 2396 [URI]に従って定義されている。

2.3.2.6 EMBEDDED-INCLUDE と EMBEDDED-EXCLUDE 要素

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

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

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

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

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

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

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

Example 2.5:

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

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

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

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

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

2.3.2.7 COOKIE-INCLUDE と COOKIE-EXCLUDE 要素

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

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

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

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

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

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

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

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

例2.3:

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

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

例 2.4:

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

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

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

2.3.2.8 METHOD 要素

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

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

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

例 2.6:

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

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

[18]	method-element	=	`<METHOD>` Method `</METHOD>`
ここで、Methodは [HTTP1.1]の5.1.1節に定義されている

2.3.3 ポリシーをURIへ適用

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

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

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

明確な例:

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など、特別な考察に値する。 時にこれらのアクションURIはフォーム自身よりも異なるポリシーによってカバーされることがある。

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

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

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

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

2.4 追加要求事項

2.4.1 一義性

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

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

2.4.2 多言語

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

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

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

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

2.4.3 セーフゾーン

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

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

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

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

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

2.4.4 ポリシーの非差別化

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

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

P3Pに準拠したサーバは、可能である場合には必ず、ウェブリソースに対する ポリシー参照ファイルへのリンクを含むべきである。

HTTP HEAD 要求のサポート

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

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

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

2.4.6 ポリシーの改版

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

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

2.5 シナリオの例

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1 ポリシーの例

3.1.1 自然言語のポリシー

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1.2 ポリシーのXMLコード化

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

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

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

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

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

3.2 ポリシー

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

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

3.2.1 POLICIES 要素

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

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

例 3.3:

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

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

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

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

[19]

policies

=

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

3.2.2  POLICY 要素

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

<POLICY>

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

discuri (必須の属性)

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

opturi

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

name

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

policy

=

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

quoted-URI

=

`"` URI `"`

3.2.3 TEST 要素

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

[22]

test

=

"<TEST/>"

3.2.4 ENTITY 要素

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

<ENTITY>

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

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

[21]	entity	=	"<ENTITY>" *extension entitydescription *extension "</ENTITY>"
[22]	entitydescription	=	"<DATA-GROUP>" `<DATA ref="#business.name"/>` PCDATA "</DATA>" *(`<DATA ref="#business.` string `"/>` PCDATA "</DATA>") "</DATA-GROUP>"
ここで文字列は、ビジネスデータ集合によって許される数字の間、連続する文字（" や & で回避された）で定義される。