このドキュメントは

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification
W3C Recommendation 16 April 2002
http://www.w3.org/TR/2002/REC-P3P-20020416/

の和訳です。

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



W3C

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

W3C勧告 2002年4月16日

この版:
http://www.w3.org/TR/2002/REC-P3P-20020416/
最新公開版:
http://www.w3.org/TR/P3P/
旧版:
http://www.w3.org/TR/2002/PR-P3P-20020128/
編集者:
Massimo Marchiori, W3C / MIT / University of Venice, (massimo@w3.org)
著者:
Lorrie Cranor, AT&T
Marc Langheinrich, ETH Zurich
Massimo Marchiori, W3C / MIT / University of Venice
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が決めている。

T本書はPlatform for Privacy Preferences 1.0 (P3P1.0) 仕様書の勧告 である。

本文書はW3Cメンバー、その他の関係する団体、およびW3C勧告として是認する理事によってレビューされた。本文書は確定した文書であり、他文書からも標準文書として引用、あるいは参照資料として使われる。勧告とする際のW3Cの役割は、仕様書に注意を引き付けることとその広範囲の展開です。 これは、Webの機能性および相互運用を強化する。

このドキュメントはW3C Technology & Society ドメインのプライバシー活動の一部としてP3P仕様ワーキンググループによって作成された。

本文書に適切な特許の開示は、W3Cポリシーと一致したP3P1.0の特許の開示ページにあるかもしれない。

本文書のコメントについては、www-p3p-public-comments@w3.org(公的なコメントの保管先)を参照ください。

本文書における既知のエラーのリストはhttp://www.w3.org/2002/04/P3Pv1-errataで閲覧することができる。

本仕様書の英語版のみが、唯一の標準版である。本文書(他)の翻訳に関する情報はhttp://www.w3.org/2002/04/P3Pv1-translationsにある。

現在の公開W3C技術レポートは、http://www.w3.org/TRにある。

目次

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

1. 序論

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

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

1.1 P3P1.0仕様書

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

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

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

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

1.1.2 P3P利用例

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

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

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

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

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

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

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

1.1.3 P3Pポリシー

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

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

P3Pの語彙が十分に正確でないので、Webサイトのプラクティスについて記述する際、サイトは、最も緊密にそれらのプラクティスと一致し、一層の説明を提供する語彙用語を使用するべきです。(3.2章に述べられている). しかしながら、ポリシーは誤りかあるいは誤解を招きやすいステートメントを行なってはならない。

1.1.4 P3Pユーザエージェント

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

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

1.1.5 サーバ上でのP3Pの実装

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

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

1.1.6 P3Pの将来バージョン

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

1.2 本仕様書について

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

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

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

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

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

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

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

1.3 専門用語

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

2. ポリシー参照

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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.1 周知の存在場所

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

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

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

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

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

2.2.2 HTTPヘッダ

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

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

[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-reference `"`
[4] 
extension-field
 
=
 
token
[`=` (token | quoted-string) ]
ここで、URI-referenceはRFC 2396[URI]によって定義され、 tokenとquoted-stringは[HTTP1.1]によって定義されている。

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

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

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

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

例 2.1:

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

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

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

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

2.2.3 HTML linkタグ

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

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

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

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

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

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

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

2.2.4 XHTMLlinkタグ

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

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

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

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

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

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

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

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

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

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

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

例 2.2:

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

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

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

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

 </POLICY-REFERENCES>
</META>

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

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

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

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

2.3.2.1.1 順序の意義

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

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

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

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

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

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

2.3.2.2 META および POLICY-REFERENCES 要素

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

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

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

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

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

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

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

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

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

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

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

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

2.3.2.3.2 EXPIRY 要素

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

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

[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 ポリシーとポリシー参照ファイルの要求

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

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

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

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

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

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

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

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

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

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

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

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

2.3.2.4 POLICY-REF要素

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

POLICY-REF
単一のP3Pプライバシーポリシーに関する情報を含む。
about (必須の属性)
フラグメント識別子の部分が（name属性に与えられている）ポリシーの名前を示し、そのURI部分がポリシーが存在するURIを示している場合のURI参照([URI])。(ポリシーファイル、ポリシー参照ファイルについては3.2章を参照のこと)。これが相対的URI参照であれば、ポリシー参照ファイルのURIに関連があると解釈される。
[11] 
policy-ref
 
=
 
`<POLICY-REF about="` URI-reference `">`
*include
*exclude
*cookie-include
*cookie-exclude
*method-element
*extension
`</POLICY-REF>`
ここで、URIはRFC 2396 [URI]に従って定義されている。

2.3.2.5 INCLUDE要素およびEXCLUDE要素

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

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

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

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

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

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

[12] 
include

=

"<INCLUDE>" relativeURI "</INCLUDE>"
[13] 
exclude

=

"<EXCLUDE>" relativeURI "</EXCLUDE>"
ここで、relativeURIは2.3.2.1.2章で定義されているように、'*' 文字がワイルドカードとして取り扱われている事と共にRFC 2396 [URI]に従って定義されている。

2.3.2.6 HINT要素

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

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

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

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

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

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

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

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

例2.3:

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

[14] 
hint
 
=
 
`<HINT scope="` scheme ( `://` | `:/` ) authority `" path="` relativeURI `/>`
ここで、scheme、 authorityそして relativeURIはRFC 2965 [STATE]から取り出される。

2.3.2.7 COOKIE-INCLUDE と COOKIE-EXCLUDE 要素

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

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

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

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

COOKIE-INCLUDE (resp. COOKIE-EXCLUDE)
name, value, domainおよびpath属性を照合するクッキーを含んでいる。 (または、含んでいない。）
name
クッキーのNAME部分を照合する。
value
クッキーのVALUE部分を照合する。
domain
クッキーのDomain部分を照合する。
path
クッキーのPath部分を照合する。

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

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

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

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

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

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

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

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

例2.4 : 

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

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

例 2.5 : 

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

[15] 
cookie-include
 
=
 
"<COOKIE-INCLUDE"
   [` name="` token `"`]   ; matches the cookie's NAME
   [` value="` token `"`]  ; matches the cookie's VALUE
   [` domain="` token `"`] ; matches the cookie's Domain
   [` path="` token `"`]   ; matches the cookie's Path
"/>"
[16] 
cookie-exclude
 
=
 
"<COOKIE-EXCLUDE"
   [` name="` token `"`]   ; matches the cookie's NAME
   [` value="` token `"`]  ; matches the cookie's VALUE
   [` domain="` token `"`] ; matches the cookie's Domain
   [` path="` token `"`]   ; matches the cookie's Path
"/>"
ここで、token, NAME, VALUE, DomainそしてPath は2.3.2.1.2章で示している様に、'*' 文字をワイルド文字として処理するRFC 2965 [STATE]に従って定義されている。

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

2.3.2.8 METHOD 要素

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

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

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

例 2.6: 

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

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

[17] 
method-element

=

`<METHOD>` Method `</METHOD>`
ここで、Methodは [HTTP1.1]の5.1.1章に定義されている

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

2.3.3 ポリシーをURIへ適用

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

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

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

明確な例:

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

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

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

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

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

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

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

2.4 追加要求事項

2.4.1 一義性

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

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

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

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

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

2.4.2 多言語

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

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

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

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

[18] 
xml-lang
 
=
 
` xml:lang="` language `"`
ここで、languageとは[LANG]で定義されているように、言語識別子である。

2.4.3 セーフゾーン

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

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

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

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

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

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

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

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

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

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

2.4.6 ポリシーの改版

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

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

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

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

2.4.8 非同期の評価

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

2.5 シナリオの例

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1 ポリシーの例

3.1.1 自然言語のポリシー

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

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

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

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

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

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


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

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

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

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

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

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

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


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


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

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

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

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

3.1.2 ポリシーのXML符号化

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

例3.1のXML符号化の方法: 

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

例3.2のXML符号化の方法: 

<POLICIES xmlns="http://www.w3.org/2002/01/P3Pv1">
 <POLICY name="forShoppers" 
     discuri="http://www.catalog.example.com/Privacy/PrivacyPracticeShopping.html"
     opturi="http://catalog.example.com/preferences.html"
     xml:lang="en">
  <ENTITY>
   <DATA-GROUP>
    <DATA ref="#business.name">CatalogExample</DATA>
    <DATA ref="#business.contact-info.postal.street">4000 Lincoln Ave.</DATA>
    <DATA ref="#business.contact-info.postal.city">Birmingham</DATA>
    <DATA ref="#business.contact-info.postal.stateprov">MI</DATA>
    <DATA ref="#business.contact-info.postal.postalcode">48009</DATA>
    <DATA ref="#business.contact-info.postal.country">USA</DATA>
    <DATA ref="#business.contact-info.online.email">catalog@example.com</DATA>
    <DATA ref="#business.contact-info.telecom.telephone.intcode">1</DATAg