このドキュメントは

Platform for Privacy Preferences(P3P) Syntax Specification
W3C Working Draft 26 August 1999 http://www.w3.org/TR/1999/WD-P3P-19990826/syntax

の和訳です。

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

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




W3C

Platform for Privacy Preferences (P3P) Syntax Specification

W3C Working Draft 26 August 1999

This Version 
http://www.w3.org/TR/1999/WD-P3P-19990826/syntax
Latest Public Version:
http://www.w3.org/TR/WD-P3P/syntax
Previous Version:
http://www.w3.org/TR/1999/WD-P3P-19990407/syntax
Editor:
Massimo Marchiori, W3C/MIT, (massimo@w3.org)

Abstract(要約)

このドキュメントは、P3P specification の重要かつ、もっとも長いドキュメントです。このドキュメントでは、要求・了解事項を文書化し、P3Pプロトコル、転送方法、データ構造のシンタックスと表現形式を指定しています。

Status of This Document 

このドキュメントは、W3Cメンバと関連者向けのP3P specificationの補足仕様書である。この文書は、P3P活動の一部として作成されて来たものであり、最終的にはW3C勧告案に昇格する。W3Cのワーキングドラフトを参考資料として使ったり、"進行中の作業"としてではない引用を行うことは好ましくない。このドラフトの基本コンセプトはかなりしっかりとしており、我々は仕様へのフィードバックのために実験的な実装やプロトタイプの開発を行うことを奨励する。しかしこのワーキンググループでは、今後のバージョンの文書を変更する可能性のある早期の実装は認めないであろう。

このドラフトはW3C processに従い、W3Cとそのメンバーにより考えられている。この文書はP3Pの実装、承認、採用に影響を与えそうな問題に関して、W3Cの会員およびスタッフに送られるコメントを受け取る目的で公開されている。

コメントがある方は以下にお願いしたい。 www-p3p-public-comments@w3.org
(アーカイブは http://lists.w3.org/Archives/Public/www-p3p-public-comments/


Table of Contents(目次)

  1. Introduction(はじめに)
    1. Problem space
    2. About this specification(この仕様書について)
    3. Operational description(オペレーションに関する記述)
    4. Assumptions(仮定)
    5. Terminology(専門用語)
    6. Conformance requirements(準拠要求事項)
  2. Scenarios(シナリオ)
  3. Data Transport(データ転送)
    1. Protocol Model
      1. Client Actions
      2. Server Actions
    2. HTTP Extension Framework and P3P(HTTPの拡張構成とP3P)
    3. Protocol Actions
      1. P3P Client Actions
      2. P3P Server Actions
      3. Protocol Example(プロトコル例)
    4. Error messages
    5. Limited Protocol(プロトコル制限)
  4. P3P markup and processing
    1. Example proposal(プロポーザル例)
      1. English language proposal(英語版プロポーザル)
      2. XML/RDF encoding of proposal(XML/RDFによるプロポーザル)
    2. Proposals(プロポーザル)
      1. The PROP element
      2. The REALM element
      3. The DISCLOSURE element
      4. The ASSURANCE element
    3. Data Transmission(データの送信)
    4. Statements(ステートメント)
      1. The STATEMENT element
      2. The CONSQ element
      3. The PURPOSE element
      4. The RECPNT element
      5. The REF element
      6. Null Values
      7. The source attribute
    5. Categories(カテゴリ)
      1. Fixed-Category Data Elements(固定カテゴリのデータ要素)
      2. Variable-Category Data Elements(可変カテゴリのデータ要素)
    6. Creating new data sets(新規データセットの作成)
      1. Repository Data(レポジトリ・データ)
      2. Non-Repository Data(非レポジトリ・データ)
  5. Appendices(付録)
    Appendix 1: References (標準準拠)
    Appendix 2: ABNF Notation (標準非準拠)
    Appendix 3: Working Group Contributors (標準非準拠)


1. Introduction(はじめに)

P3P(The Platform for Privacy Preferences)プロジェクトは、Webサイトが自分たちのプライバシープラクティスを表現し、ユーザがそれらのプラクティスに対するプリファレンスを実行することを可能にする。P3P準拠の製品は、ユーザが(マシンと人間の両方が解読できる書式で)サイトのプラクティスを知ること、適切ならばコンピュータに決定を委ねること、そして特定サイトに結びつけることを許す。ユーザのプリファレンスに適合したサイトのプラクティスは、ユーザの選択によりシームレスにアクセスすることができる。そうでない場合は、ユーザはサイトのプラクティスを通知され、それらに同意する機会を与えられてブラウジングを続けることができる。

P3Pは、ユーザがWeb上で十分に説明された決定を行う能力と、彼らの情報の使用を制御する能力を与える。サイトはP3Pを、サービス品質の向上、コンテンツのカスタマイズ、サイトアクセスの簡略化だけでなく、サービス内での信頼ユーザの地位レベルを上げるために使うことができる。

P3Pは、 [XML]( [RDF]データモデルを使用)を、構造化されたデータと主張の交換の為に使用する。P3Pは将来のデジタル認証とデジタル署名の能力もサポートする予定である。P3Pはブラウザ、プラグイン、サーバ、もしくはクライアントとサーバ間のプロキシサーバに組み込むことができる。

1.1 Problem space

The P3P specification は以下の機構を提供します:

1.2 About this specification(この仕様書について)

このドキュメント(各章、各規準参照)は、統一されたP3Pアプリケーションのインプリメントに必要な全ての仕様を含んでいます。

このドキュメントは、P3P仕様のメインとなる部分を含んでいます。プライバシーデスクロージャー用語の語議論の詳細 <natural language>は、[HARMV]で見ることができます。文法と基本データセットのデータ・タイプの詳細は、[BASEDATA]で見ることができます。

注意:P3P1.0に準拠する為には、上記の用語を使用することが要求される。同時に、XML-namespaces [XML-name]の利便さは、付加または補足的な用語を容易に取り入れることを可能にする。

文章のステータスを表現するために以下の規約を用いる:

この仕様書で使われたABNF表記法は、RFC2234で規定されている。また、Appendix 2に要約されている。しかし、そのようなシンタックスは、XMLシンタックス文法の典型だけであることに注意してください。また、XMLの全ての統語的な適応性は無条件で含まれる。例えば、「空白に関する規則」、「クォートする場合に、シングルクォート(')または、ダブルクォート(")の何れかを使用する」、「character escaping」、「大文字・小文字の区別」などです。

1.3 Operational description and design(オペレーションに関する記述と設計)

利用者がWebサービスに遭遇した場合、Webサービスは、個人情報の取り扱い方に関しての宣言を行い、利用者にP3P プロポーザルのURIと、propIDと呼ばれるプロポーザルの識別子を送る事によって、利用者からの情報を求めるだろう。プロポーザルとpropIDは、HTTPの転送メカニズムを拡張した物を使用して転送される。

P3Pプロポーザルは複数のステートメントを含み、データエレメントセットに関するプライバシープラクティスを表記している。また、P3Pプロポーザルは全ての適切なデータエレメントとプラクティスをカバーしなければならない。(サイトがデータエレメントを収集したい場合、プロポーザルにおいて、その旨を宣言しておかなければならない)
注意:P3Pでのプロポーザル宣言は、肯定的でなければならない。(”何をしない”ではなく”何をする”と言うような表現)

P3P specification での中心的概念は P3P agreement(同意)です。P3P agreement とは、サービスとユーザーエージェント双方で同意したプロポーザルのことである。ユーザーエージェントは同意を始めるかどうかを決定するために、プロポーザルに宣言してあるプライバシープラクティスと利用者のプリファレンスを比較する。同意は一つ以上の指定されたレルム内において、ユーザーエージェントとサービス間での全てのデータ交換に適用する。
(レルム:唯一のURIから参照されるWebリソース、またはTree構造のWebリソース)

ユーザエージェントが受諾可能なプロポーザルを見つけた場合、エージェントは、プロポーザル識別子を送り返す事で、Webサイトに同意を示すことができる。もしプロポーザルがP3Pデータ転送方法を使用したデータ転送要求を含んでいる場合、一致するデータはプロポーザル識別子と共に返却される。

サーバーは個々のレルムに対して、多種多様な代替のプロポーザルを提供するだろう。すべてのプロポーザルは、なぜ提案されたプラクティスが、普段利用者が受け入れないようなプラクティスであるにもかかわらず、ある特定の場合に重要であるかを、利用者の目に見える形で説明することができる帰結のセットを持つことができる。ユーザエージェントは、同意に至ったこと(propIDと呼ばれる、同意の識別子によってインデックス化)を記録すべきである。毎回の交渉で、ユーザエージェントに新規のプロポーザルURIとpropIDを送るよりは、サイトは、既存の同意のpropIDを送るだろう。

またサービスは、P3Pプロポーザルを参照する<LINK>タグをHTMLのコンテンツ内部に埋め込むだろう。これは、サービスがP3P準拠のサーバーの使用にかかわらず、P3Pプロポーザル内に明記してある個人情報の取り扱い方に従っていることを主張することを許可する。

我々が現実的に提供する拡張的メカニズムについて、二つの注目すべきエリアがある。

  1. どのようにして利用者に情報をせがむか(参照:source 属性)
  2. どのようにして新規データセットは、サービスとクライアントによって使用されるか(参照:DATA:REFとnamespaces)

我々の設計は次のようなものである。独自の想定において効果的に実装できるアプリケーションやマルチラウンド通信の待ち時間、キャシュ可能なプロポーザル、ユーザーエージェントやサーバー側のデータレポジトリの使用、同意レポジトリのサイズに等に関する期待である。

1.4 Assumptions(仮定)

P3Pは、動作する環境と解決すべき問題についていくつかの仮定を行っている。

  1. P3Pは、サービスがそれ自身の身元情報をプロポーザルに含むことを許す。登録したドメインのオーナーがサービス本体と一致しない場合もあるので、この情報は必ず提供されなければならない。
  2. 身元や同意に関する強い承認が、プロトコルの将来のバージョンで提供される。この際P3Pには、使用されるはっきりした有力なPKIモデルは存在しない。将来的にはユーザとサービス両方が署名と認証を必要とするかも知れない。
  3. 我々は、通信のセキュリティがP3P自身以外の手段[SSL]で達成されると仮定している。そのためP3Pでは、保管や通信の暗号化による情報の保護については、そのメカニズムを提供していない。
  4. P3P同意は、端末間のもの。つまりユーザーとサービス間のもの。回線プロバイダやインターネット サービス プロバイダ、プロキシ等は、サービスと利用者間でデータ交換に関与しているような仲介者であって、それらの個人情報の取り扱い方は、端末間での同意によって制御されない。
  5. P3Pは[HTTP1.1]を元にしたHTTP拡張構成[HTTP-EXT]を有効に利用出来ると同時に、[HTTP1.0]サーバ/プロキシでも動作可能でなければならない。
  6. P3Pは、HTTP経由で生成、または交換された全てのデータをカバーする。

1.5 Terminology(専門用語)

Assuring Party(保証機関)
P3P内部において、保証機関は合法的な実体(個人、または団体)であり、プロポーザルに関して保証を行うものである(例:プラクティス監査やデータ収集ガイドラインに従っているかなど)。保証はサービス自身、または第三機関からくるものです。保証機関は、プロポーザル内において、保証文の一部として、何を証明するか、特定されたURI、またはメタデータスキーマの意味を明らかにしなければならない。
Agreement(同意)
サービスとユーザーエージェント双方が同意したプロポーザル。この同意はレルム内におて使用され、しばしばpropIDとして用いられる。このような否認不可能な同意は、将来のP3Pにおける証明書や電子署名の将来性のサポートにより強固になります。Version 1.0 でその事は特定されていなかったが、今後特定のフィールドを設けたいと思っている(例:assuring party(保証機関)による電子署名の発行など)。
Data Element(データエレメント)
個々のデータ要素。例えば、名字、電話番号など。国際的利用のため、P3P1.0では、基本的なデータエレメントを指定しています。
Data Category(データカテゴリ)
データエレメントデータセットの属性はTrust Engineがどんなエレメントタイプが審議中であるか決定するために使われる。例えば、"Contact Information."  P3P 1.0では、10個の基本データカテゴリーを指定しています。
Data Set(データセット)
グループ化されたデータエレメント。例えば、"user.Home.Postal."。データセットはピリオドの区切りにっよって表現されている。P3P1.0ではいくつかの基本データセットを指定しています。
Preference(プリファレンス)
ユーザーエージェントがどんな行動をするか、何時会話に入ることを許可するか、またはサービスとの交渉等に関する規則(規則集)。プリファレンスは形式の整った計算できる文で表現される(例:[APPEL] プリファレンスは言語を交換する)。この文書のなかで、プリファレンスはユーザーエージェントとサービス間で同意に至る、いろいろな同意を管理します。
PropID
P3Pプロポーザルを識別するために使われる情報。P3Pヘッダ内でのpropIDの存在は、どの同意がrealm(レルム)に対して実施されるかの最終的宣言である。サービスが、同一のURIでのプロポーザルを変更した時は、一致するpropID(例:プロポーザルのフィンガープリントは、[MD5]のように計算されることができるだろう)を必ず変更しなければならない。確認とP3Pプロポーザルの参照以外の目的でpropIDを使用してはならない(例:利用者のブラウジング状態を維持させるために使用してはならない)。
Proposal(プロポーザル)
プロポーザルは、いくつかのプライバシーステートメント(主張された身元、URI、保証等の情報、プロポーザルによりカバーされているサービスの情報開示)の集まりです。プロポーザルは常にサービスの観点から作り出されるもので、サービスにとっての情報の確認を含んでいます。しかし、プロポーザルは、ユーザーによって作り出され、サーバーに許可のために送られる事もあります。
Realm(レルム)
レルムは、与えられた同意が発行された元に要求したエクスペリエンス スペースです。レルムはプロポーザルを適用した領域として、広い意味で定義されています。レルムは、いくつかのURIから参照されます。それぞれのURIは、URIによって限定された特定のリソースを名前付けます。例えば、HTTP URIスキーマの中で、オブジェクト(home.html)で終了しているURIは、特殊なオブジェクトを適用します。また、URIがpath http://www.w3.org/P3P/ の場合、URIは、path 配下の ファイル システム ツリーを参照します。もしプロポーザルに電子署名が無い場合、それぞれのURIはオリジナルのサーバーとドメインが同一でなければなりません。ドメイン マッチングは、HTTP state management mechanism [STATE] に含まれています。
Repository(レポジトリ)
P3Pの制御下で利用者情報を保存するメカニズム
Service
プロポーザルを発行しデータを要求するプログラム。この定義では、サービスはサーバー(サイト)、ローカルアプリケーション、ローカルなアクティブコード(ActiveX controlやJava applet)または他のユーザーエージェントである。
Statement(ステートメント)
P3Pステートメントは、データエレメント、データセット、カテゴリの集まりに関連がある privacy practice disclosures の集まりです。列挙された要素は、埋め込まれたデータ要求のように動きます。データを参照しないステートメントは、データを要求しません。
URI
URI(A Uniform Resource Identifier)は、Webリソースを確認するために使われる。URIシンタックスとセマンティクスの定義については、[URI]を参照して下さい。
User Agent
利用者が定義したプリファレンスをもとに、サービスと利用者間の仲介を行うことを目的としたプログラムである。利用者は1つ以上のユーザエージェントを持つかもしれない。また、利用者のデスクトップにある必要はない。しかし、どのエージェントも利用者だけが制御し、使えなければならない。利用者とそのユーザエージェント間との信頼関係は、P3Pの範囲外で管理されるものである。例えば、エージェントは利用者のOSまたはWebクライアントの一部、またはISPかプライバシーProxyの状況により信頼される。

1.6 Conformance requirements(準拠要求事項)

このドキュメントはインターオペラビリティ(interoperability)、feature sets、意味に関するポリシー(policy related semantics)についての要求事項について説明します。インターオペラビリティの必要事項は、プロトコルは"shared"プロトコル・ステート・マシンに従って動作すること、情報は任意に喪失されない、もしくは混同されないこと等です。このドキュメントで feature setsに関する必要事項をさらに説明する。 というのは、プロトコルを壊さないfeatureをインプリメントしない一方で、それは、どの機能がサポートされているかという相手又はユーザの期待を裏切ることになります。その上、このアプリケーションの重要なpolicy implicationの為、P3PはXML/RDFのための natural language semantics を含んでいます。例をあげると、インターオペラビリティの要求事項はすべてのパーティーにプロトコル原型とレスポンスをサポートすることです。
この要求事項を与えられ、エージェントはいつも“SORRY”を返す事が出来ます。 しかし、このことは、全てのエージェントが単にsorryを返すように実行されている場合、合意に至ることができるというサービスの期待を裏切ることになる。この例を広げてみると、もしそのような事をするエージェントが存在しない場合、サービスは、マルチプルポリシーや交渉した決定事項を好んで実行しないだろう。 いずれにしても、機能のサポート不足によりプロトコル インターオペラビリティーを裏切らない。

この広域なそれらの必要事項は不規則なものではあるが、P3Pがプロトコル以上の物であり、HTTPやXMLのような既存の標準アプリケーションであるので必要である。さらに、この文書では、まだ実装されていない、または仕様書の一部として作る必要のない機能、しかしP3Pユーザの経験の一部として重要と思われる機能についても予想して書かれている。

以下のキーワードは文書全体を通じて使用され、interoperability要求事項として読まれなければならない。このキーワードはRFC2119[KEY] で定義されている。以下にそのキーワードを示す。

MUST
これは、「必要とされる、しなければならない」という意味で、仕様書中、絶対的に守るべき事項に付加される。
SHOULD
この言葉は、「推奨される、した方がよい」という意味で、無視することができるある特定の状況が存在する場合もあるが、完全なインプリケーションのために別の方法をとるまえに完全な意味を理解し、注意深く状況を判断すべきである。
MAY
この言葉は、「任意に選んで良い、してもよい」という意味で、選択する余地がある場合に用いられる。あるベンダーは、ある特定の市場はそれを必要としているから、或いは製品を向上させるからという理由で、そのアイテムを選んでもよい。例えば、別のベンダーは同じアイテムを省略するかもしれない。

以下の表は、要求に関しての機能/動作をまとめたものです。クライアントとサービス、クライアントまたはサービスに対する要求かどうかは、このspecificationの左側に記載されています。

セクション 機能/動作 Key Word 説明

Terminology

propID MUST propID は、どのようなプライバシープロポーザルも認識する。

Data transport

the HTML LINK tag MUST エージェント及びサービスはこの場所にプロポーザルを設置することが出来る必要がある。
  HTTP拡張メカニズム MUST エージェント及びサービスはこの場所にプロポーザルを設置することが出来る必要がある。

XML/RDF encoding

XML 解析 MUST プロポーザルとデータシンタックスは、速やかに処理されるか、ユーザに提出される。RDFデータモデルは、必要なgrammar/シンタックスを構成するために使用されるが、アプリケーションは、その必要を感じない場合は必ずしもRDFをサポートする必要はない。

XML/RDF encoding

完全なXMLとXML-namespaceのサポート MUST 使用されるだけでなく、完全に XML と namespacesをサポートしなければならない。
Data References base data reference syntax MUST エージェントは請求されている情報のシンタックスを理解できなければならない。
Harmonized Vocab harmonized vocabulary MUST 要求事項に関しては、harmonized vocubarly[HARMV] を参照。この必要条件を満たさなければならない。満たさない場合、インプリメンテーションがプライバシー公開を適切なレベルで出来なくなってしまう。
Reason Codes (OK, SRY-, ERR-, SRY, ERR) MUST 同意に達するために必要。
propID レポジトリ SHOULD 完全なプロポーザルはコンパクトに表現されることができる。同意が既に存在する場合、新規のネゴシエーションと同意は必要ない。
  データ レポジトリ MAY 頻繁に要求される利用者プロフィール情報は利用者によって保存/管理される。
Data Definitions new schema instantiation MAY base setとは異なったスキーマは、エージェントにより例示/サポートされることが可能である。
Source Attribute source attributes "matched-form" and "extension" MAY base setとは異なったスキーマは、エージェントにより例示/サポートされることが可能である。

注意:サービスは、ユーザエージェントに利用可能なP3Pプロポーザルを作成するために、P3P準拠のサーバーを使用する必要はない。

簡易P3PユーザーエージェントはP3Pプロポーザルを受け取って、利用者にそれらを提示するぐらいの機能を有し、情報要求があった場合、ユーザーエージェントは利用者に決定権を委ねる。そのため、ユーザーエージェントは利用者の自動的な利用者情報の転送(クリックストリームのような受動的に生成されたものは除く)のための決定権を持っていない。

利用者の自動的な利用者情報の転送のための決定権を持っているユーザーエージェントは、"trust engine"を含まなければならない。trust engineはP3Pプロポーザルと利用者のプリファレンスセット(規則として記録されている)の入力や、どのようなアクション(シームレスな受託、拒否、情報プロンプト、警告プロンプト、その他のアクション)をとるかと示すことで取得することが可能でなければならない。利用者のプリファレンスは[APPEL]や他の言語で記号化されることが可能である。プリファレンス言語はドキュメント化されるべきであり、その言語によって規則を作成するユーザーインターフェイスを提供すべきである。ユーザーエージェントは利用者自身が作成した、もしくは他人から手に入れた規則をインポートする方法を提供すべきである。また、利用者が規則の作成/変更可能な機能も提供すべきである。

ユーザーエージェントは初期の段階では、何も設定されていない状態(利用者が利用する前に設定ができるように)、もしくはデフォルトの規則の設定がなされている状態である。しかし、利用者の有効な同意なしに個人情報をサービスプロバイダに転送するようなデフォルトの設定をしてはならない。(シームレスな受託)

2. Scenarios(シナリオ)

以下のシナリオは、P3Pが使われる可能性のあるいくつかの場面について説明してあります。各シナリオは、それぞれ異なるP3Pの特徴を強調しています。シナリオ1はどのようにして基本的なP3P同意が確立されるかを示しています。シナリオ2、3は既に同意に達しているサイトにユーザが戻った際に何が起きるかを示しています。シナリオ4は同意を与えられたデータレポジトリの使用について強調しています。

これらのシナリオは交渉が発生しない場合の相互作用を図解している。しかしどのシナリオもサイトが初めから複数のプロポーザルを行うシナリオに拡張される可能性がある。

以下の表は、各シナリオの特徴をまとめたもの。表中の"-"は、そのシナリオでは仮定されない(中立な)という意味を表す。
 
Scenario Existing Agreement New Proposal Data Requested
1 No Yes -
2 Yes No -
3 Yes Yes -
4 - - Yes

シナリオ 1) 同意は存在しない。サイトはプロポーザルを送る。

  1. ユーザは、CoolCatalogのホームページ(CoolCatalog/*)に行く。 彼女はそこに1度も行ったことがないが、そこはP3P準拠である。
  2. CoolCatalogがプロポーザルを作成。そこにはプライバシープラクティス、情報開示、そしてそれらが適用されるデータエレメントの情報が含まれている。
  3. ユーザはプロポーザルに合意。

シナリオ 2) レルム同意が存在する。

  1. ユーザは以前にシナリオ1を終了している。
  2. ユーザは既存の同意に従いながらCoolCatalogのページに戻り、自動的に現行のプロポーザルを使用している。

シナリオ 3) レルム同意が存在し、新しいプロポーザルが発生する。

  1. ユーザは前にシナリオ1を完了している。
  2. ユーザはCoolCatalogに戻り、すべてのページ要求に同意(1)のpropIDを与える。
  3. ユーザはCoolCatalogの注文ページ(CoolCatalog/Order/*)に行き、同意(1)のpropIDを送る。サービスは注文ページのポリシーがサイトの他のページと異なるため、新しいプロポーザルを作成。この場合、実際の注文情報を要求する。
  4. ユーザは新しいプロポーザルを考慮し、同意する。

シナリオ 4) サービスがクライアントのレポジトリからデータを要求する。

3 Data Transport

3.1 Protocol Model

プロトコルモデルは、クライアントがアクション(プロポーザルを要求するような)を起こし、そしてサーバーは、他のアクション(例えば、プロポーザルの返却を提案する)で相互作用を完結する、単一の相互作用を基本としている。我々は、コンパクトなデータ(普通は単一行)はHTTPヘッダ内に置くべきであるという経験から得た法則に従って以来、しばしば要求に対するレスポンスはクライアントが実際のプロポーザルを取ってくるべき場所からになる。(HTMLクライアントがページ内の画像を取ってくるのに数回リクエストをするようなもの)この単一相互作用(複数回のHTTPリクエストを含む)は、必要であれば複数回の相互作用(または"交渉")に拡張する事が出来る。すなわち、複数回の相互作用は単一の相互作用の上に作る事が可能で、単一の相互作用には何の影響も与えないからです。注意:proposed protocolの相互作用は、P3Pを認識している、または認識していない中間キャシュに正しく作用するために、厳密にHTTPの request/responce の表記法に従う。

基本的なプロトコルの動作は以下のようにまとめることが出来る。

3.1.1 Client Actions

クライアントは要求を発行する時に、以下の動作をいつでもすぐに行うことが出来る。

  1. プロポーザル要求
  2. 既知のプロポーザルを参照し、要求を作成
  3. 既知のプロポーザルの元にデータをサブミット
  4. 受諾不可能なプロポーザルとその他のエラー報告

3.1.2 Server Actions

サーバーは以下のアクションを行うことが出来る。

  1. P3Pが適用されているクライアントからの要求に応じてプロポーザルを提案
  2. 対応するプロポーザルを元に、データの要求と受諾を遂行
  3. プロポーザル(データ)拒否とエラー報告
  4. SRYとERRメッセージ受諾

3.2 HTTP Extension Framework and P3P(HTTPの拡張構成とP3P)

P3Pプロトコルは、HTTP Extension Framework[HTTP-EXT]を使用する。P3Pは、いかなるスタンダードなHTTP要求に追加することができるであろう四つの拡張ヘッダを含んでいる。HTTP Extension Frameworkを使用するためには、拡張(拡張宣言)を識別するための、グローバルなユニークURIを規定することが要求される。P3Pの拡張宣言は以下のURIを参照して下さい。

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

P3P extensions は以下のようなものである。

status
P3Pメッセージのステータスを記述します。ステータスはreason code(Section 3.4を参照)を使用して表現されます。
propID
このpropIDは、参照されたプロポーザルのpropIDを含む。propIDは、指定されたURI(拡張プロポーザル内に参照される。詳しくは以下)でのプロポーザルを独自に識別するラベルとしての意味を持つ。サービスが同一のURIでの プロポーザルを変更したときは、サービスは対応するpropID(例えば、プロポーザルのフィンガープリントは、[MD5]のように計算されることができる)を必ず変更しなければならない。propIDを、P3Pプロポーザルを識別、参照する目的以外に使用してはならない(従って、propIDは、利用者のブラウジング状態を維持するために使用されてはならない)。
Webサイトに戻ってきた時、ユーザエージェントは、propIDが変更されていなかったかどうかを確かめなければならない。もしpropIDが変更されている場合、ユーザエージェントは、再びプロポーザルを要求し、再評価しなければならない。追加的な保護手段として、ユーザエージェントは定期的にプロポーザルを再要求し、propIDの変更なしにプロポーザルが変更されていないか確かめるかもしれない。
proposal
プロポーザルが取ってくることが出来るURI。
data
特定の同意の元に、クライアントがサーバーに送るデータを一行ごとに記号化したXMLメッセージ

3.3 Protocol Actions

このセクションでは、P3Pに準拠したクライアントとサーバーが、HTTPプロトコルの拡張としてP3Pプロトコルを実施するために、どのようなアクションをするかについて説明します。またこのセクションでは、このプロトコルを実施する場合に報告しなければならない様々なエラーコードへの参照も含んでいる。それらのエラーコードについての詳細は、はセクション3.4.で、定義、議論されています。

3.3.1 P3P Client Actions

P3P クライアントは、以下の事柄を行うことができなければならない:

プロポーザル要求
P3P準拠のサーバーにプロポーザルを要求する時、P3P利用可能なクライアントは、任意または、強制的なP3P拡張HTTPヘッダを含んだ要求を発行しなければならない。例えば:
Opt: "http://www.w3.org/TR/WD-P3P/"
or Man: "http://www.w3.org/TR/WD-P3P/"

一般的には、Optヘッダが使用されるべきである。しかしながら、クライアントが、P3Pのサポートを要求するという事を述べたい場合、必須の拡張が、M-GETM-POSTメソッドと共に使用されるだろう。P3P準拠のサーバーは、ManOptヘッダを同等に取り扱わなければならない。

P3P-HTTPヘッダ拡張を含む全ての要求は、暗黙のプロポーザル要求である。P3P準拠のサーバーは、適切なプロポーザルが有効である時に、常にpropIDとP3P拡張ヘッダproposalを送信するだろう。

クライアントが、単にプロポーザルだけを要求したい場合(内容は含まない)、クライアントは、OPTIONSまたは、HEAD要求を発行するだろう。

クライアントが、プロポーザルと内容を同時に要求したい場合、クライアントは、GET要求(または、その他の適切な要求)を発行しなければならない。サーバーが、P3Pの同意に至った事に関係なく、内容を提供することを望んでいる場合、サーバーは、propIDとP3P拡張ヘッダプロポーザルにそって、適切な内容を提供するだろう。サーバーが、同意に至るまでは、内容を提供しない場合、サーバーは、P3Pstatusヘッダ内のSRY-ARコード、あるいはHTTP 510エラーコードで返答するだろう。プロポーザルが受諾可能な場合、クライアントは、適切なpropIDと共に拡張ヘッダを含んだオリジナルの要求を再び行わなければならない。

注意:利用者が、P3P準拠のユーザ・エージェントを、データの交換を行う以前に、Webサイトと同意に至るように仕向けた場合、クライアントは、対応するP3Pの同意が無いURIに対してデータを送ってはならない。従って、POST要求もまた暗黙のプロポーザル要求であるけれども、同意無しではデータを送らないように設定されているクライアントから、そのような方法は使用すべきではない。代わりに、OPTIONSHEAD要求が行われるべきである。以前に、propIDを獲得しているならば、POST要求を行うことができる。同様に、同意無しではデータを送らないように設定されているクライアントは、同意が存在しないレルムへのフォームデータ(一般的にそのような要求はクエスチョンマークを含んでいるだろう)を含むGET要求を送る前に、OPTIONSHEAD要求を発行しなければならない。加えて、同意に至るより重要な、データを送らないことに関する注意が必要である、クライアント実装ケースがあるだろう。

既知のプロポーザルを参照し、要求を作成
クライアントが既に、受諾可能な適切なプロポーザルのpropIDを知っている場合、クライアントは、propIDヘッダを含む要求を行うことができる。クライアントは、いかなる標準のHTTP要求にもpropIDヘッダを含むだろう。propIDが有効な場合、P3P準拠のサーバーは、要求を満たすことを試みるべきである。propIDが有効でない場合、P3P準拠のサーバーは、P3Pstatusヘッダ内の適切なエラー、あるいはHTTP 510エラーコードで、応じることが期待される。

既知のプロポーザルの元にデータをサブミット
該当するプロポーザルが、P3Pの方法を使用して、データをサブミットする要求を、クライアントが要求した場合、クライアントは、その要求にアタッチされたP3P dataヘッダ内で、データをサブミットすることができなければならない。全てのP3P準拠のクライアントは、GETPOST要求と共に、データをサブミットすることができなければならない。また、クライアントは、他のHTTP要求と共にデータをサブミットすることができるだろう。

クライアントは、リクエスト内に与えられたpropIDを含む初回に、要求された何れかのデータをサブミットしなければならない。クライアントが、propIDを含むリクエストをサブミットし、要求されたデータをサブミットしなかった場合、サーバーは、statusヘッダ内にP3P SRY-DR、もしくはHTTP 510エラーを送ることによって、データを要求するだろう。クライアントが、SRY-DRを受け取った場合で、クライアントがまだ要求したリソースにアクセスすることを望む場合、クライアントは、要求されているデータと共に、リクエストを再び行わなければならない。

受諾不可能なプロポーザルとその他のエラー報告
サービスによって申し出られたproposalヘッダ内のプロポーザルが受諾不可能な場合(ポリシーが受諾不可な場合、クライアントが要求データを持っていない場合、有効でないpropIDやシンタックスのエラーのような技術的問題の場合)、クライアントは、拡張ヘッダ内に適切なSRY または ERRコードを含むリクエストを、送りかえして、対応しなければならない. しかし、クライアントは、成功したPOSTリクエストや副作用を伴う他のリクエストを送り返してはならない。加えて、クライアントが、要求するリソースに対して、これ以上アクセスするつもりが無い場合、受諾不可なプロポーザルに対して、対応しないことを選択するだろう。サービスが複数のプロポーザルを申し出て、クライアントが一つでも受諾可能なプロポーザルを発見した場合、受諾できない他のプロポーザルの為にSRYERRを報告する必要は無い。全てのプロポーザルが受諾不可能で、それに対して応じたい場合、クライアントは、個々にSRYERRを報告しなければならない。クライアントは、エラー報告、サービスからのレスポンスの受け取り、再びエラー報告といった無限ループに入らないように注意しなければならない。

3.3.2 P3P Server Actions

P3P サーバーは、以下の事柄を行うことができなければならない:

P3Pが適用されているクライアントからの要求に応じてプロポーザルを提案
P3P準拠のサーバーは、適切なプロポーザルが利用可能な時、P3Pが適用されているクライアントからの要求の全てのレスポンスに、propIDproposalヘッダを含まなければならない。サーバーは、レスポンス内に、複数のpropIDproposalヘッダを含むことによって、特定のリソースのための複数のプロポーザルの有効性を示すだろう。

クライアントが、proposalヘッダ、P3PLINKタグ、またはプロポーザル内のdiscURIタグによって示されているURIに対してGET要求を発行する事によって、プロポーザルまたは、人間が読める形のプライバシーポリシーを要求した時、サーバーは、同意要求無しで、要求を満たさなければならない。

対応するプロポーザルを元に、データの要求と受諾を遂行
propIDヘッダを含む要求が行われた場合、サーバーは、propIDが有効かどうか確かめなければならない。propIDが有効である場合、サーバーは、要求に応じるよう試みなければならない。P3P準拠のサーバーは、GETPOST要求の一部としてdataヘッダ内でサブミットされたデータを受け入れる能力を持たなければならない。またサーバーは、何れかのHTTP要求の一部としてデータを受け入れるだろう。

プロポーザル(データ)拒否とエラー報告
無効なpropIDで要求が行われた場合、サーバーは、statusヘッダ内において、適切なエラー・コードで応じなければならない。無効なpropIDでデータがサブミットされた場合、データは破棄されなければならない。要求が遂行されない場合、サーバーは、P3Pstatusヘッダに加えて、HTTP 510エラー・コードで応じるべきである。

複数のプロポーザルに伴うエラーを報告する場合、サーバーは、一つのエラーと、そのエラーが適用された全てのpropIDのリストを報告するか、もしくは個々のpropIDのエラーを報告するだろう。異なったエラーが個々のpropIDに適用された場合、エラーは個別に報告されなければならない。

SRYERRメッセージ受諾
P3P準拠のサーバーは、クライアントからのSRYERRメッセージを受け入れ、サーバーのオペレータにそれらのメッセージをログに残したり、レポートすることが出来なければならない。

3.3.3 Protocol Example

以下は、どのようにP3P準拠のクライアントとサーバー間での相互作用が、通常発生するかの例です。クライアントとサーバーの動作の例は、影つきの箱内に示しています。

1. クライアントがGETまたはPOSTまたは、なにかしら有効な方法を使用してリソースを要求する。また、クライアントは、P3P利用可能であることを示すために、P3P拡張ヘッダを送る。

GET coolcatalog.com/index.html HTTP/1.1
Host: coolcatalog.com
Opt: "http://www.w3.org/TR/WD-P3P/"

2a. サーバーが、P3P同意を要求しない場合、サーバーは、内容、propIDproposalヘッダを返信する。複数のpropIDproposalヘッダの組は、サーバーが複数の代替えプロポーザルからの選択権を申し出ていることを示すことに使用されるだろう。(内容を表示する前に、クライアントは任意にフェッチし、個々のプロポーザルを評価するだろう)[全てのプロポーザルが受け入れられない場合、ステップ3bへスキップしてください。そうでなければ、ステップ5へスキップしてください。]

HTTP/1.1 200 OK
Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1
1-propID: Ed3Oorq/ZJbTpVaFRD4qfA==
1-proposal: http://coolcatalog.com/P3PProposal1.xml
Opt: "http://www.w3.org/TR/WD0P3P/"; ns=2
2-propID: 9Pfx3KzqthhRfWxxW1gLnQ==
2-proposal: http://coolcatalog.com/P3PProposal2.xml
. . .
Content-Type: text/html
. . .

2b. サーバーがP3P同意を要求する場合、一つまたは複数のpropID/proposalヘッダ、status: SRY-ARヘッダ、そして任意にHTTP 510エラー・コードを返却する。

HTTP/1.1 510 Not Extended
Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1
1-propID: Ed3Oorq/ZJbTpVaFRD4qfA==
1-proposal: http://coolcatalog.com/P3PProposal1.xml
1-status: SRY-AR
Opt: "http://www.w3.org/TR/WD-P3P/"; ns=2
2-propID: 9Pfx3KzqthhRfWxxW1gLnQ==
2-proposal: http://coolcatalog.com/P3PProposal2.xml
2-status: SRY-AR
. . .

(クライアントが、プロポーザルを評価する必要がある場合、クライアントは、proposalヘッダによって示されているURIに対してGET要求を発行する事によってプロポーザルを取得してくる。プロポーザルを取得した後、クライアントは、任意に利用者と、プロポーザルが受諾可能か、そして/または利用者に情報を表示するかを決定するために、互いに伝達し合うだろう。)

GET coolcatalog.com/P3PProposal1.xml HTTP/1.1
Host: coolcatalog.com
Opt: "http://www.w3.org/TR/WD-P3P/"

3a. プロポーザルが受け入れ可能ならば、クライアントは、要求をサブミットしなおす。この時は、propIDと要求されたデータを含む。(複数のプロポーザルが有効な場合、クライアントは、一つを選択し、それに対応するpropIDをレスポンスの中に含まなければならない)

GET coolcatalog.com/index.html HTTP/1.1
Host: coolcatalog.com
Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1
1-propID: Ed3Oorq/ZJbTpVaFRD4qfA==
1-data: <TXD xmlns="http://www.w3.org/TR/WD-P3P/syntax" 
  xmlns:VOC="http://www.w3.org/TR/WD-P3P/vocab" 
  xmlns:DATA="http://www.w3.org/TR/WD-P3P/basedata">
1-data: <DATA:REF name="user.name.first" value="Sheila">
1-data: <DATA:REF name="user.name.second" value="Doherty">
1-data: </TXD>
. . .

3b. プロポーザルが受け入れられない、もしくは他のエラーがある場合、クライアントは適切なSRYまたはERRヘッダと一緒にリクエストを再送信する。(リクエストが成功しない限り、POST要求や、他の要求を繰り返すと望ましくない副作用をもたらすだろう)[ステップ2に戻ってください。しかし、クライアントは、クライアントの要求が数回失敗した後には、無限ループを避けるために、要求をあきらめなければならない。]

GET coolcatalog.com/index.html HTTP/1.1
Host: coolcatalog.com
Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1
1-propID: Ed3Oorq/ZJbTpVaFRD4qfA==
1-status: SRY-PR
Opt: "http://www.w3.org/TR/WD-P3P/"; ns=2
2-propID: 9Pfx3KzqthhRfWxxW1gLnQ==
2-status: SRY-PR

他の手段として、以下のものは書かれています:

GET coolcatalog.com/index.html HTTP/1.1
Host: coolcatalog.com
Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1
1-propID: Ed3Oorq/ZJbTpVaFRD4qfA==
1-propID: 9Pfx3KzqthhRfWxxW1gLnQ==
1-status: SRY-PR

4a. propIDが有効で問題がなければ、サーバーは内容とproposal/propIDヘッダ を返却する。

HTTP/1.1 200 OK
Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1
1-propID: Ed3Oorq/ZJbTpVaFRD4qfA==
1-proposal: http://coolcatalog.com/P3PProposal1.xml
. . .
Content-Type: text/html
. . .

4b. 何か他の問題(例えば、クライアントが要求されたデータを確かに送らなかった)がある場合、サーバーは、適切なSRYまたはERRコードを含むstatusヘッダとproposal/propIDヘッダを返却する。そのサーバーは、要求が遂行されなかった場合には、任意にHTTP 510エラーコードを返却するだろう。[ステップ3に戻って、もう一度やり直してください。しかし、クライアントは、クライアントの要求が数回失敗した後には、無限ループを避けるために、要求をあきらめなければならない。]

HTTP/1.1 510 Not Extended
Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1
1-propID: Ed3Xorq/ZJbTpVaFRD4qfA==
1-status: SRY-DR
2-propID: Ed3Oorq/ZJbTpVaFRD4qfA==
2-proposal: http://coolcatalog.com/P3PProposal1.xml
Opt: "http://www.w3.org/TR/WD-P3P/"; ns=2
3-propID: 9Pfx3KzqthhRfWxxW1gLnQ==
3-proposal: http://coolcatalog.com/P3PProposal2.xml
. . .

[time passes]

5. クライアントが、以前と同じリソースを要求する。その要求には、プロポーザルに同意する事を示すために、propIDヘッダが含まれる。

GET coolcatalog.com/index.html HTTP/1.1
Host: coolcatalog.com
Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1
1-propID: "Ed3Oorq/ZJbTpVaFRD4qfA=="
. . .

6a. 同意がまだ有効で、サーバーが再度データを必要としない(もしくは、サーバーがP3P同意を要求しない)場合、サーバーは、単にproposal/propIDヘッダと一緒に内容(ステップ4にあるように)を返す。

HTTP/1.1 200 OK
Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1
1-propID: Ed3Oorq/ZJbTpVaFRD4qfA==
1-proposal: http://coolcatalog.com/P3PProposal1.xml
. . .
Content-Type: text/html
. . .

6b. 同意はまだ有効だけれども、サーバーがデータを再び必要とする場合、サーバーは、status: SRY-DRヘッダと任意のHTTP 510エラー・コードを送ることによって、データを再送信させることを、クライアントに求める。[ステップ3へ続く]

HTTP/1.1 510
Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1
1-propID: Ed3Oorq/ZJbTpVaFRD4qfA==
1-proposal: http://coolcatalog.com/P3PProposal1.xml
1-status: SRY-DR
. . .

6c. 何か問題がある場合、サーバーは、適切なSRYまたはERRコードを伴うstatusヘッダ、proposal/propIDヘッダ、そして任意のHTTP 510エラーコードを返却する。[ステップ5に戻って、もう一度やり直してください。しかし、クライアントは、クライアントの要求が数回失敗した後には、無限ループを避けるために、要求をあきらめなければならない。]

HTTP/1.1 510
Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1
1-propID: Ed3Oorq/ZJbTpVaFRD4qfA==
1-status: ERR-IF
1-proposal: http://coolcatalog.com/P3PProposal1.xml
. . .

3.4 Error messages

それぞれのプロトコル動作は、様々な理由でエラーを引き起こす。例えば、プロポーザルが奇形であったり、参照された同意が不明なものだったりです。error messageは、以下の拡張P3Pを使用して発行されます:

理由コードはstatus extention headers(ステータスエクステンションヘッダ)内で送られ、プロポーザルやデータの状態を表す(可能性として、以前の相互作用の状況内で)。P3Pエクステンションは、エラーを報告する場合、ステータスヘッダのみを含まなければならない。その他全ての場合(プロポーザルの内容やデータエクステンションの受け取りが成功している時)、ステータスヘッダを含んではならない。ステータスエクステンションを理解できないアプリケーションはP3Pメッセージを無視しなければならない。
Reason Token(理由の標章) Description(記述) Sent by(送り主) Explaination(説明)
SRY-AR 同意(agreement)が要求(required)されている server もし以前の同意(propIDに一致する)が要求された場合に(propIDと共に)送信。クライアントは、プロポーザルを評価(クライアントは前もってプロポーザルをダウンロードする必要がある)し、利用者のプリファレンスに従って、(データと共に、またはデータなしに)サブミットしなおし、SRY(-PR)を送信、またはコミュニケーションを終了する。
SRY-AU 同意(agreement)が不明(unkown) server クライアントが、要求と共に不明なpropIDを送信した場合に送信。同意を必要とする新規のプロポーザルが可能な場合、サイトはSRY-AR(上記にあるように)を送信しなければならない。"SRY-AR"が存在しない場合、クライアントは、propIDの参照なしで要求をサブミットしなおすことが出来る。
SRY-DR データ(data)が要求(required)されている server クライアントがagreement(一致するpropIDによって参照された)に同意したが、適切なデータを送信しなかった時に送信。クライアントがリソースにアクセスしたい場合、クライアントは要求されたデータ(プロポーザルに応じた)を含む同じリクエストをサブミットしなおす必要があるだろう。
SRY-DU データ(data)が利用できない(unavailable) client データが利用できないので、クライアントが要求されたデータを提供出来なかった時に送信。
SRY-PR プロポーザル(proposal)が拒否(rejected)された client プロポーザルが受け入れられない時に送信。サーバーはこれについてログを取り、任意にクライアントに送り返したり、異なったページ/プロポーザルを申し出ることができる。
SRY sorry server または client 文法的に正しいにもかかわらず、プロポーザルまたはデータエクステンションの内容の受け取りに失敗、そして他の全てのSRY-コードが利用できない、またはプライバシに関する理由(後に説明)の場合に送信。
ERR-IF 不適切(invalid)なフォーマット(format) server または client 受け取ったP3Pメッセージが文法的に不適切、または意味が通じない。
ERR-TF データの転送(transfer)が失敗(failed)した server または client 文法的に正しく、有効な同意にカバーされている転送要求を受け取ったが、何かの理由でデータを保存することができなかった。
ERR error server または client 要求が理解されない、または正しく受け取られなかった。このコードはその他全てのERR-コードが当てはまらない時、またはプライバシに関する理由(後に説明)により送られる。

注意:もしプライバシーの理由でクライアントがプロポーザルを拒否する理由を漏らしたくない時、クライアントは特定の“SRY- ”コードではなく一般的な“SRY"コードをリプライすることが出来る。可能であれば何時でもERR-IF と ERR-TFコードが使用されることを推奨するが、エラーコードも同様に特定の“ERR- ”コードではなく一般的な“ERR"コードを使うことが出来る。

サーバーは最低でもSRY-ARとERRを送らなければならない。クライアントは最低でもサーバーから送られてくる三つの特定のSRY-エラーコードを理解しなければならない。言い換えると、クライアントは、(利用者が望む場合)プロポーザルを受け入れ(propIDを送ることによって)、必要であれば(利用者の判断で)データを送信することが可能でなければならない。SRY-AUの場合、クライアントは、リクエストを(期限切れまたは不明である)propIDの参照なしにサブミットしなおすことが可能でなければならない。

最後に、エラー・ステータスを特定するために、複数の理由コードを使用することが可能であることを覚えといてください:例えば、クライアントが、サーバーが提案したプロポーザルへのレスポンスとして、SRY-DUを要求したデータが利用できないことを示すために、そしてERR-IFをプロポーザルの一部が文法的に間違っていることを示すために返却することができるだろう:

HTTP/1.1 200 OK
Opt: "http://www.w3.org/TR/WD-P3P/"; ns=14
14-status: SRY-DU
14-status: ERR-IF
14-propID: 94df1293c1p8
14-proposal: http://www.privacy.org/newP3PProposal
...
[Content]

3.5 Limited Protocol(プロトコル制限)

制限されたP3Pプロトコルは、HTTPヘッダ拡張メカニズムを使用しないで実行されるだろう。代わりに、サーバーは適切なP3Pプロポーザルの場所を示すLINKタグを埋め込んだHTMLコンテンツを提供するだろう。このプロトコル制限は、P3Pを理解するクライアントを必要とするが、P3Pを理解するサーバーは必要としない(コンテンツは、サーバーの動作方法を変えることなく、埋め込まれたlinkタグを含むために修正されるだろう)。

limited protocolを使用しているサービスは、HTMLドキュメントの<HEAD>エリア内に、以下のフォームのLINKタグを埋め込むことによって、与えられたP3Pプロポーザルに従うことを宣言するだろう:

<LINK rel="p3p:propID" href="URI">

URI はP3Pプロポーザルの場所を示し、"p3p:propID"は、この特別なP3P linkとプロポーザルのpropIDの記号化を区別するために使用される関連名です。例えば、 http://www.privacy.org/P3PProposalにあるプロポーザルが、propIDx3tYwafhfKSqGV0Q+eSOZw==を持っているとすると、次のようになる:
<LINK rel="p3p:md5:x3tYwafhfKSqGV0Q+eSOZw==" href="http://www.privacy.org/P3PProposal">

P3P準拠のクライアントは、propIDproposalヘッダを含まないHTMLコンテンツを返却する要求をした場合は必ず、LINKタグを捜さなければならない。加えて、P3P準拠のクライアントは、いつでもHTMLコンテンツ内に埋め込まれているLINKタグを捜すだろう。クライアントが、同じドキュメント内にP3P LINKタグに加えて、propIDproposalヘッダを見つけた場合、クライアントは、それらを複数の代替プロポーザル参照とみなすべきである。

limited protocolは、データ収集の為にP3Pの方法を使用することを望んでいたり、プロポーザルの選択を申し出ること、プロポーザルへの明白な同意を求めることを望んでいるサービスには適していない。

以下は、どのような相互作用がP3P準拠のクライアントと非P3P準拠のサーバー間で、典型的に進められるかの例です。クライアントとサーバーのアクション例は、影つきの部分に示されています。

1. クライアントが、GETPOST、または他の要求を満たす方法を使用して、リソースを要求。また、クライアントは、P3Pが利用可能であることを示すために、P3P拡張ヘッダを送信。

GET coolstore.com/index.html HTTP/1.1
Host: coolstore.com
Opt: "http://www.w3.org/TR/WD-P3P/"

2. サーバーは、P3P利用不可能なので、P3P拡張ヘッダ(それが必須の拡張と、(または)サーバーは拡張利用が不可能な場合以外、サーバーは、P3P利用不可能であることを、クライアントに報告する)を無視し、要求されたコンテンツを送る。

3. クライアントは、属性rel="p3p:propID"と共に埋め込まれたlinkタグを、返却されたコンテンツから調べる。もしそのようなlinkタグが無く、クライアントが既に同意したレルム内に、要求されたリソースが無い場合、クライアントは、P3Pプロポーザルが利用できないと判断し、それに応じた行動をとることが出来る。linkタグが有る場合、クライアントは、linkタグのhref属性によって示されているURIへのGET要求を発行する事によってプロポーザルを取得し、評価し、それに応じた行動をするだろう。

注意:プロポーザルを評価した後の適切な行動と、(または)プロポーザルが存在しないと決定する全てのケースは、利用者のプリファレンスと、どのようにクライアントが設定されているかによる。クライアントは、要求、情報表示、利用者への問いかけ、またはその他の行動をとることを続けるだろう。

4. P3P markup and processing

このセクションではユーザーエージェントとサービス間で転送された利用者データのブロックと同様に、P3Pプロポーザルの文法や意味論について説明します。プロポーザルで使用される英語の用語説明は、[HARMV]に、より詳しく記載されている。

英語版プライバシーポリシーと、Section 4.1でのP3Pプロポーザルについての例から始めます。P3Pプロポーザルは、プロポーザル全体に適用される一般的な主張を含みます。同様に、statements(ステートメント)と呼ばれる特殊な主張は、data referencesにより参照された特定のデータタイプを操作する時のみ適用されます。Section 4.2では、プロポーザル要素とプロポーザルにおける主張のレベルについて説明します。Section 4.3では、データブロック(data blocks)を転送する時に使用されるTXD要素について、Section 4.4では、ステートメントとデータの参照について説明します。

以下のセクションでは、いくつかのXML要素を紹介しています。各々のXML要素は適切な属性とXML name space(xmlns)を伴って<>内に書かれてあります。全ての掲げてある属性はmandatoryとしてタグで囲まれている時を除いては、任意のものである。

4.1 Example proposal(プロポーザル例)

4.1.1 English language proposal(英語版プロポーザル)

以下の例は、我々がP3Pプロポーザルとして記号化したい英語版のプライバシーポリシーの例です。

CoolCatalogはhttp://www.CoolCatalog.com/catalog/でのWebページのために以下のステートメントを作成。

Webフォーム経由で、cookieを使用し、入り口のページのカスタマイズと製品の研究と向上のために、性別と(任意に)実家の住所を収集する。この情報は、確認可能なフォームのためには使用しない。

我々はまた、どのページが訪れられたかや、利用者のWebブラウザのタイプについての情報を含んだログをサーバーに保持する。この情報は、我々のWebサイトの保持、向上のために使用される。我々は、この情報を利用者情報が確認可能な手段に使用しない。

我々は、利用者から得た情報に対してのアクセス権を与えない、しかし我々は情報を確実に保持し、そしてプライバシーポリシーに関するページhttp://www.CoolCatalog.com/PrivacyPractice.htmlにおいて利用者がポリシーについて読むことが出来るopt-out policiesを持っている。第三機関であるPrivacySeal.orgによって、我々がこの同意に従っている事の証明が提供される。

以下の例は、P3P要素と属性名を使用した括弧内に数値を持っているより正式な説明です。

Entity: http://www.CoolCatalog.com/
Realm: http://www.CoolCatalog.com/catalog/
Disclosure URI: http://www.CoolCatalog.com/PrivacyPractice.html
Access to Identifiable Information: none
Assurance: PrivacySeal.org
Other disclosures: Change agreement, retention

We collect:
    dynamic.cookies
    user.gender
    user.home.  (optional)
For purpose: Customization of the site to individuals, research and development
Identifiable use: No
Recipients: Only ourselves and our agents
Consequence: A site with clothes you would appreciate

We collect:
     dynamic.clickstream.server
     dynamic.http.useragent
For purpose: Web site and system administration, research and development
Identifiable use: No
Recipients: Only ourselves and our agents

4.1.2 XML/RDF encoding of proposal(XML/RDFによるプロポーザル)

以下の[RDF]は、上記にあるような情報を捕捉する。P3Pプロポーザルとは、[RDF]および、有効でよく形成されたXML構文モデルに基づいて正しく表現された文章でなければならない。しかしプロポーザルを短くするために使われる、P3Pプロポーザルと標準RDFをわずかに区別する2つの仮定がある。もし、XML/RDFデータがP3Pと同種のものからなっているとき、囲んでいるRDFタグは、任意に省略してもよい。より多くのプロポーザル文法については以下に続くセクションで説明されている。

<RDF:RDF xmlns:RDF="http://www.w3.org/TR/WD-rdf-syntax">
<PROP xmlns="http://www.w3.org/TR/WD-P3P/syntax" 
 xmlns:VOC="http://www.w3.org/TR/WD-P3P/vocab"
 xmlns:DATA="http://www.w3.org/TR/WD-P3P/basedata"
 entity="http://www.CoolCatalog.com">
  <ASSURANCE org="http://www.PrivacySeal.org" 
   text="third party" image="http://www.PrivacySeal.org/Logo.gif"/>
  <REALM uri="http://www.CoolCatalog.com/catalog/">
  <VOC:DISCLOSURE discuri="http://www.CoolCatalog.com/PrivacyPractice.html" 
   access="none" retention="yes" change_agreement="yes"/>
  <USES>
  <STATEMENT VOC:id="nonid">
     <CONSQ v="a site with clothes you would appreciate"/>
<VOC:RECPNT v="ours"/>
<VOC:PURPOSE v="uniqueid"/>
<VOC:PURPOSE v="financial"/>      <DATA:REF name="dynamic.cookies" source="service"/>      <DATA:REF name="user.gender" source="matched-form"/>      <DATA:REF name="user.home." optional="yes" source="matched-form"/>   </STATEMENT>   </USES>   <USES>   <STATEMENT VOC:id="nonid">
<VOC:RECPNT v="ours"/>
<VOC:PURPOSE v="admin"/>
<VOC:PURPOSE v="develop"/>     <DATA:REF name="dynamic.clickstream.server" source="service"/>     <DATA:REF name="dynamic.http.useragent" source="service"/>   </STATEMENT>   </USES> </PROP> </RDF:RDF>

4.2 Proposals(プロポーザル)

このセクションでは、あるプロポーザルで動作するためのキーエレメント、属性、processing heuristicsについて定義する。全てのプロポーザルは[UTF-8]を使用して記号化される。

4.2.1 The PROP element

<PROP> (xmlns="http://www.w3.org/TR/WD-P3P/syntax")
1つかそれ以上のstatementを含む。各ステートメントはデータエレメントに適用されるような情報開示を含む。
entity (mandatory attribute)
プロポーザル内にあるプライバシープラクティスの表現を作成する合法的な実体と結びつけることが出来るドメイン名やパスを参照しているURI。

[1]
PROP-msg
=
(`<RDF:RDF xmlns:RDF="http://www.w3.org/TR/REC-rdf-syntax/">`
 proposal
 "</RDF:RDF>")|
proposal

[2]
proposal
=
`<PROP xmlns="http://www.w3.org/TR/WD-P3P/syntax" 
 xmlns:VOC="http://www.w3.org/TR/WD-P3P/vocab"
 xmlns:DATA="http://www.w3.org/TR/WD-P3P/basedata"` 
" entity=" quoted-URI  
">"
1*statement-block 
disclosure
[assurance]
1*realm
`</PROP>`

4.2.2 The REALM element

<REALM> (xmlns="http://www.w3.org/TR/WD-P3P/syntax")
プロポーザルのレルムにつての説明(プロポーザルを適用するURI)
uri (mandatory attribute(必須属性))
プロポーザルを適用するURI

[3]
realm
=
"<REALM"
 " uri=" quoted-URI
"/>"

同意の範囲を設定したREALMにより特定されたURI("realm")。この情報はユーザーエージェントにより使用される。例えば、サービスに既存の同意があるかどうか等。各々のレルムURIsはサーバーのドメインと一致しなければならない("domain-match" [STATE])。

個々のURIは特定のリソースや、URIによって限定されたリソースの組を指定するだろう。HTTP URIスキーマにおいて、"/"で終わるURIは、path配下のファイル・システム・ツリーを参照する。(例えば、"http://www.w3.org/P3P/"は"http://www.w3.org/P3P/foo/schema.html"を同様に用いるだろう)一方で、"/"で終わっていないURIは、特定のリソースだけに適応される。(例えば、"http://www.w3.org/P3P/data.html"は、"http://www.w3.org/P3P/foo/schema.html"に適応されないだろう)

ユーザーエージェントは、どの同意が同意に至ったか、またそれに対応するpropIDと供にレルムを記録しなければならない。そして、同意のレルムが有効である限り(実行可能な限り)それらの情報を保存しなければならない。以前訪れた時のレルムのいかなる部分を返却する時、ユーザーエージェントは適切なpropIDをサービスへのリクエストに含まなければならない。

Schemes(スキーマ)

P3Pは、HTTPと関連するschemes (HTTPSのような)用に設計されている。特にHTTP、HTTPSの場合、HTTPを使用して同意に至った同意は、必然的にHTTPS schemesを使用するURI要求をサポートする。例えば、利用者がレルム"http://www.romulus.com/"で同意に至った場合、https://www.romulus.com"がレルムの一部として考慮される。しかし、利用者がレルム"https://www.romulus.com/"で同意に至った場合、"http://www.romulus.com" は同意を受け取る必要がない。FTPなどのその他のスキーマを含むレルムに関して、同意に至ることがあるが、HTTP/HTTPSプロトコルを使用する、またはHTMLコンテンツに埋め込まれたリンクからによって同意に至らなければならない。プロトコルはFTPやNNTP等のスキーマを使用したデータ交換や交渉(negotiation)をカバーするために将来拡張されるだろう。

4.2.3 The DISCLOSURE element

<DISCLOSURE> (xmlns="http://www.w3.org/TR/WD-P3P/syntax")
サービスのアクセス能力に関する簡単な情報開示で、entityがすでに集められたデータの同意の変更(opt-out)と、データの保持期間についての情報開示を行うかどうかに関するバイナリ値。
xmlns="http://www.w3.org/TR/WD-P3P/vocab"
discuri (mandatory attribute)
プロポーザルの分かりやすいプライバシーステートメントのURL。これは質問等がある場合にどのようにしてサービスに連絡をとれば良いかという情報を含まなければならない。
access
識別情報、住所に関する質問やサービスプロバイダへの考慮事項を個人が参照できる能力
retention
サイトは、サイトのdiscuriにおいて知られている"保持"に関するポリシーを作成しますか?
change_agreement
サイトは、サイトのdiscuriにおいて知られている"同意の変更"に関するポリシーを作成しますか?

The values of [5] are provided for reference only. The normative specification is in the harmonized vocabulary [HARMV] document.
[4]
disclosure
=
"<VOC:DISCLOSURE"
" discuri=" quoted-URI
" access=" `"` access-disclosure `"`
[" retention=" `"` yesno `"`]
[" change_agreement=" `"` yesno `"`] "/>"
[5]
access-disclosure
=
"nonident" | ; Identifiable Data is Not Used
"contact"  | ; Identifiable Contact Information
"other"    | ; Other Identifiable Information
"contact_and_other" | ; Identifiable and other contact information "none" ; None
[6]
yesno
=
"yes" | "no"

4.2.4 The ASSURANCE element

<ASSURANCE> (xmlns="http://www.w3.org/TR/WD-P3P/syntax")
entityがプロポーザルに従っていて、データ生成のガイドラインまたはその他の適切な主張に従っていることを証明するサービスにつての説明。
service
Assurance serviceのURI
text
Assurance serviceのタイプの短い原文通りの説明(例:third party, legal, 等)
image
Assurance serviceのimage logoのURI
width
Image logoのピクセル幅
height
Image logo のピクセル高さ
alt
Image logoの短い原文通りの説明

[7]
assurance
=
"<ASSURANCE"
 " service=" quoted-URI
 [" text=" quoted-string]
 [" image=" quoted-URI
 [" width=" `"` number `"`]
 [" height=" `"` number `"`]
 [" alt=" quoted-string]
"/>"

注意:ASSURANCEの複数の発生により指定される複数のassurance serviceが存在することが出来る。

4.2.5 Semantics of a Proposal(プロポーザルの意味)

Webサイトが、P3Pプロポーザルへのリンクをはっている場合、WebサイトはHTTPリクエストのヘッダ内に、プロポーザルをWebサイトに参照する要求を送るユーザエージェントのためのプロポーザルを喜んで守るということを掲げている。

Webサイトが、複数のP3Pプロポーザルへのリンクをはっている場合、Webサイトは、ユーザエージェントが複数のプロポーザルから選択したP3Pプロポーザルによってのみ拘束されていることを意味する。ユーザエージェントは、ヘッダ内にプロポーザルへの参照を送信する事によって、特定のP3Pプロポーザルを選択したことを知らせる。

たとえWebサイトが、P3Pプロポーザルを一つしか持っていなくても、ユーザエージェントが要求ヘッダ内にP3Pプロポーザルを参照しないならば、Webサイトは、何れのP3Pプロポーザルにも拘束されない。そのため、P3Pをサポートしていないユーザエージェントは、Webサイトと、いかなる特定のP3Pプロポーザルを結び付けない。さらに、最初のユーザエージェントからWebサイトへのリクエストは、ユーザエージェントは多分、リクエストのヘッダ内の参照するP3Pプロポーザルが何であるか分かっていないので、いかなるP3Pプロポーザルによってもカバーされない。

Webサーバ上のP3PをサポートしていないWebサイトは、複数のプロポーザルへのリンクは避けるべきである、なぜなら多分Webサイトは、どのプロポーザルをユーザエージェントが選択したか判別する方法を知らないからです。このアドバイスにもかかわらず、Webサイトが複数のプロポーザルにリンクをはっている場合、Webサイトは、Webサイト上にどんな困難さが設置してあるにもかかわらず、ユーザエージェントが選択したプロポーザルを、どうにかして守るために拘束される。

4.3 Data Transmission(データの送信)

クライアントはヘッダ内のXML/RDFメッセージを伝えることにより、特定の同意を参照したデータをサービス(Section 3.3.2を参照)に送る。

<TXD> (xmlns="http://www.w3.org/TR/WD-P3P/syntax")
propIDにより参照された同意をもとに返却されたデータブロックを示す。

[8]
TXD-msg
=
(`<RDF:RDF>` txd-block `</RDF:RDF>`) |
 txd-block

[9]
txd-block
=
`<TXD xmlns="http://www.w3.org/TR/WD-P3P/syntax"
      xmlns:VOC="http://www.w3.org/TR/WD-P3P/vocab"
      xmlns:DATA="http://www.w3.org/TR/WD-P3P/basedata">` 
*(data-reference)
`</TXD>`

TXDメッセージが拡張HTTPヘッダとして送信された場合、改行を全ての >の後に入れなければならない。その上、特有の接頭句をすべての行に入れなければならない。例えば:

42-data: <TXD xmlns="http://www.w3.org/TR/WD-P3P/syntax" xmlns:VOC="http://www.w3.org/TR/WD-P3P/vocab" xmlns:DATA="http://www.w3.org/TR/WD-P3P/basedata">
42-data: <DATA:REF name="user.name.first" value="Sheila"/>
42-data: <DATA:REF name="user.name.Last" value="Doherty"/>
42-data: <DATA:REF name="user.name.Title" value="Miss"/>
42-data: </TXD>

4.4 Statements

ステートメントは特定タイプのデータに適用されるデータプラクティスについて説明する。

4.4.1 The STATEMENT element

<STATEMENT> (xmlns="http://www.w3.org/TR/WD-P3P/syntax")
データエレメントに適用されるデータプラクティス
id (mandatory attribute) (xmlns:VOC="http://www.w3.org/TR/WD-P3P/vocab")
個人的な身元確認可能な方法で使用されるデータ。他のソースからのあなたに関する身元確認可能な情報とのリンクを含む。
consq
利用者が普段、許可しないような個人情報の取り扱いであっても、提唱された個人情報の取り扱い方が、ある特定の場合に価値あるものであるという理由を、利用者に示すことが出来る重要性。

[10]
statement-block
"<USES>"
"<STATEMENT" 
" VOC:id=" `"` idvalue `"` ">" *(consequence) *(purpose) *(recipient) *(data-reference) "</STATEMENT>" "</USES>"
The values of [11-13] are provided for reference only. The normative specification is in the harmonized vocabulary [HARMV] document.
[11]
purposevalue
=
"current" | ; Completion and Support of Current Activity(現在の活動の終了と支持)
"admin"   | ; Web Site and System Administration(サイトとシステム管理者)
"custom"  | ; Customization of the Site to Individuals(個人のためのサイトのカスタマイゼーション)
"develop" | ; Research and Development(研究開発)
"contact" | ; Contacting Visitors for Marketing of Services or Products(サービスや製品のマーケティングのために利用者とコンタクトを取る)
"other" [" (" string ")"] ; Other Uses(その他の使用)

[12]
recipientvalue
"ours" | ; only ourselves and our agents(我々とエージェントのみ)
"same" | ; organizations following our practices(我々のプラクティスに従う団体/組織)
"other" | ; organizations following different practices(その他のプラクティスに従う団体/組織)
"published"   ; unrelated third parties or public forum(関係の無い第三機関や公共のフォーラム)

[13]
idvalue
=
"nonid" | ; non identifiable
"id" ; identifiable

4.4.2 The CONSQ element

<CONSQ> (xmlns="http://www.w3.org/TR/WD-P3P/vocab")
利用者が普段、許可しないような個人情報の取り扱いであっても、提唱された個人情報の取り扱い方が、ある特定の場合に価値あるものであるという理由を、利用者に示すことが出来る重要性。
v (mandatory attribute)
対応する値
xml:lang
帰結が表現される言語

複数の結果は、複数のCONSQエレメント(一つの結果を伴っている)を使用して示すことができる。このようにして、多国後バージョンの結果は、xml:lang属性を使用して記号化することができる。

[14]
consequence
"<CONSQ v=" quoted-string [xml:lang= LanguageID ] "/>"

xml:lang と、そのLanguageID の値のタイプは、[XML] specification内に定義してある。

4.4.3 The PURPOSE element

<PURPOSE> (xmlns="http://www.w3.org/TR/WD-P3P/vocab")
Webに関するデータ処理のための目的
v (mandatory attribute)
対応する値

複数の値(value)は、multiple PURPOSE elementsを使用する事によって表すことが出来る。個々のエレメントは一つの値を伴う。

[15]
purpose
"<VOC:PURPOSE v=" `"` purposevalue `"` "/>"

The values of [16] are provided for reference only. The normative specification is in the harmonized vocabulary [HARMV] document.
[16]
purposevalue
=
"current" | ; Completion and Support of Current Activity(現在の活動の終了と支持)
"admin"   | ; Web Site and System Administration(サイトとシステム管理者)
"custom"  | ; Customization of the Site to Individuals(個人のためのサイトのカスタマイゼーション)
"develop" | ; Research and Development(研究開発)
"contact" | ; Contacting Visitors for Marketing of Services or Products(サービスや製品のマーケティングのために利用者とコンタクトを取る)
"other" [" (" string ")"] ; Other Uses(その他の使用)

4.4.4 The RECPNT element

<VOC:RECPNT> (xmlns="http://www.w3.org/TR/WD-P3P/vocab")
データが配布されるサービスプロバイダとそのエージェントの範囲を越えた、組織的エリア、またはドメイン。
v (mandatory attribute)
対応する値

複数の値(value)は、multiple RECPNT elementsを使用する事によって表すことが出来る。個々のエレメントは一つの値を伴う。

[16]
recipient
"<VOC:RECPNT v=" `"` recipientvalue `"` "/>"

The values of [17] are provided for reference only. The normative specification is in the harmonized vocabulary [HARMV] document.
[17]
recipientvalue
"ours"  | ; only ourselves and our agents(我々とエージェントのみ)
"same"  | ; organizations following our practices(我々のプラクティスに従う団体/組織)
"other" | ; organizations following different practices(その他のプラクティスに従う団体/組織)
"published" ; unrelated third parties or public forum(関係の無い第三機関や公共のフォーラム)

4.4.5 The REF element

<REF> (xmlns="http://www.w3.org/TR/WD-P3P/basedata" as default)
転送または暗示されるデータの説明
name (mandatory attribute)
データエレメント/セットの名前を意味する文字列。セットとエレメントは、セット名に続いているドット(.)によって統語的に区別される。例えば、User.Home.を示す続いているドットは、データセットです。nameは、大文字・小文字を区別することを覚えといてください。(例:User.Home.は、USER.HOME.user.home.と別物である)さらに、アンダスコア("_")は使用できず、ドットの直後に数字を使用することはできない
value
name属性に指定してあるデータエレメントの実際の値を示す文字列。データエレメント要求の場合、value属性は欠けている。
optional
"no"または"yes"。"yes"がデータエレメントを必要としないことを意味しているので、"no"はデータエレメントが必要であることを意味する。規定値は"no"。optional属性は、プロポーザル内でのみ使用される。サービスは、データ要求が任意であることを示すためにoptional属性を使用するだろう。ユーザエージェントは、利用者のプリファレンスに元ずいて、optional属性を送信、または無視するだろう。P3Pでは、どのデータプラクティスがoptionalであるかを特定するメカニズムを含んでいないことに注意してください。もしサーバーが、データはマーケティングのために使用されるなどの例のように、利用者にデータプラクティスの選択権を与えることを望む場合、利用者が選択できる、複数の代替プロポーザルを使用者に提供する事によって成し得るだろう。
source (mandatory attribute)
データ転送のメカニズムを指定する。
category (xmlns="http://www.w3.org/TR/WD-P3P/vocab")
データエレメントのcategories (カテゴリ)を意味する文字列。

以下の6つの属性は、新規のデータエレメントやセット(P3P1.0 ベース [BASEDATA]には定義されていない) が参照された時のみに使用される。

type
データエレメント/セットのタイプを意味する文字列。
typeschema
type属性で特定されたタイプが規定されるデータスキーマを意味するURI。
template
一致するデータエレメントがタイプの定義の一部のみであるか指定する。"1"にセットすると、そのデータエレメントはタイプ定義であることを意味する。そして、実際には関連する値のデータエレメントを意味しない。規定値は"0"。
short
データエレメント/セットの短縮名を意味する文字列。127文字以内の[UTF-8]文字。
long
データエレメント/セットを説明する長い文字列を意味する。1023文字以内の[UTF-8]文字。
size
データエレメントを保存するのに必要な[UTF-8]文字の最大数を意味する。規定値の"0"はデータエレメントを任意の大きさにする事が出来ることを示す。

加えて、REFのnamespaceは、例えば、nameが属する場所で指定されたデータスキーマ、データエレメント/セットの名前を意味するURIを持った一列のxmlns属性を使用することで、オーバーライドが可能です。規定のDATA namespaceはPROPエレメントの中で宣言される。しかし、それはDATA:REFエレメント内でのローカルなnamespace宣言を使用し、オーバーライドされることが可能です。

[18] 
data-reference
=
"<DATA:REF" " name=" quoted-string 
" source=" `"` sourcevalue `"` 
[" optional=" yesno] [" value=" quoted-string] 
[" type=" quoted-string] [" typeschema=" quoted-string] 
[" template=" yesno] [" VOC:category=" category] 
[" short=" quoted-string] [" long=" quoted-string]
[" size=" `"` number `"`] ; default is 0 (unlimited size)
"/>"

[19]
sourcevalue
=
"service"      | 
"agent"        | 
"matched-form" | 
"extension"

例:利用者の実家の町、User.Business.のデータセットの全てのエレメントと(任意に)User.Home.Telecom.Phoneのデータセットの全てのエレメントを要求し一致したフォームを参照することにより情報を収集。;サービスはP3Pプロポーザル内で以下の内容を送信する。

<DATA:REF name="user.home.city" source="matched-form"/>
<DATA:REF name="user.home.phone." optional="yes" source="matched-form"/>
<DATA:REF name="user.business." source="matched-form"/>

利用者が町、ビジネス情報、国際電話番号と市外局番のみを返信することに同意した場合、txdタグ内において、以下の物を返信する。

<DATA:REF name="user.home.city" value="Cambridge"/>
<DATA:REF name="user.home.phone.intcode" value="1"/>
<DATA:REF name="user.home.phone.loccode" value="617"/>
<DATA:REF name="user.business.street" value="254 Windsor St."/>
<DATA:REF name="user.business.city" value="Cambridge"/>
... (the other values of user.business.) ...

4.4.6 Null Values

あるケースにおいて、データセット内の幾つかの値のみが値を持っている。(例えば、利用者がホームページ、Fax、ミドルネーム等を持っていない)言い換えると、幾つかのエレメントは、利用者のレポジトリ内に定義された値を持っていない。そのような場合、エレメントはヌル値を持っていると言える。クライアントが、エレメントがヌル値を持っていることを示す方法は、単に一致するDATA:REF参照を省略すれば良い。例えば、クライアントが全ての利用者名に関する情報(user.name.)を提供することに同意した場合、以下のものを送信する:

<DATA:REF name="user.name.first." value="Sheila"/>
<DATA:REF name="user.name.last" value="Doherty"/>
<DATA:REF name="user.name.formatted" value="Sheila Doherty"/>

この場合、多の全てのフィールド(prefix, suffix, middle name, nickname)は利用者のレポジトリ内に定義されていないことを意味する。

4.4.7 The source attribute(ソース属性)

source属性は、ユーザーエージェントからサービスへのデータ転送のためのメカニズムを明記します。我々は3つのスタンダードメカニズムと、将来的に、規定される拡張可能な新規データ転送メカニズムを定義する。スタンダードメカニズムは以下のようなものである:

service(サービス)
サービスはP3Pユーザーエージェントがアクティブであることを要求しない方法を使用してデータを要求/収集する。(例えば、スタンダードなHTMLフォーム、データのスタンダードなHTTPヘッダストリームからの収集、暗示されたデータ等)そのためサービスは利用者に対するいかなるプロンプトの提示についてのフルコントロールを保持する。しかし、サービスは利用者のデータレポジトリを利用できない。
agent(エージェント)
P3Pユーザーエージェントは利用者に、データと(または)データレポジトリからのデータについて促さなければならない。エージェントはHTTPヘッダの拡張機構を使用してサービスにデータを転送しなければならない。サービスは、レポジトリのデータが利用できない場合、どのようにして利用者にプロンプトするかの権限を持っていない。ユーザーエージェントは、エレメント名を使用するのではなく、short and/or long display 名をプロンプト内に含むべきである。
matched-form
サービスは、フォームのフィールド名がプロポーザル内のデータ参照と一致するHTMLのコンテントのフォームを通してデータを要求する。属性名の異なるコンポーネンツを区別するために(クライアント側のjavascriptとの相互作用を許可するために)、フォーム・フィールド名に、普段のP3Pドット(".")表記の代わりに、下線("_")表記を使用しなければならない。 例えば、P3Pプロポーザル内のuser.name.firstは、HTMLフォーム内では、user_name_firstとして参照されるだろう。従ってエージェントは、利用者レポジトリからのデータで任意にフォームを記入するだろう。この方法を使用する時、サービスは利用者へのプロンプト問いかけに関する権限を保持するが、ユーザエージェントが自動記入をサポートしているとき、利用者のデータ・レポジトリを利用するだろう。もしユーザ・エージェントが自動入力機能をサポートしていない(または要求したデータがレポジトリ内に保存されていない)場合、一般的なHTMLフォームが表示される。
extension
またサービスは、ここで定義されていない他の機構(electronic commerce wallet(電子財布)など)を使用してデータを転送したいかもしれない。その場合、サービスはその機構を使用してデータが収集される事を示すためにsource="extension"を明記しなければならない。

<REF> エレメントは、データ・スキーマ定義内に存在する時以外は、常に一つの値を持ったソース属性を含まなければならない。この場合、属性は完全に省かれるか、値を一つ、または複数取るだろう。(値を取る場合、同じデータを参照しているが、異なるソースを持つ複数の<REF>エレメントから取得される)

4.5 Categories(カテゴリ)

Category は、データエレメントの属性であり、ユーザとユーザエージェントにデータの意図した使い方のヒントを与える。Categoryは、P3Pユーザエージェントの実施や使用を簡単にするために必要である。これにより、ユーザがデータの交換においてより一般的なプリファレンスやルールを表現することができる。Categoryは、新しいエレメントを定義したり、利用者に記入するように問いかけたデータを参照したりする時にしばしば含まれる。(利用者のデータ・レポジトリに保存してあるデータとは対照的に)

P3Pの現在のバージョンでは、以下のトークンがデータカテゴリを示すために使用されている:

[20] 
category
=
"physical"    | ; Physical Contact Information(物理的なコンタクト情報)
"online"      | ; Online Contact Information(オンラインのコンタクト情報)
"uniqueid"    | ; Unique Identifiers(ユニークな識別子)
"financial"   | ; Financial Account Identifiers(金融機関のID番号)
"computer"    | ; Computer Information(コンピュータ情報)
"navigation"  | ; Navigation and Click-stream Data(ナビゲーションとクリックストリームのデータ)
"interactive" | ; Interactive Data(インタラクティブデータ)
"pref"        | ; Preference Data(嗜好データ)
"demograph"   | ; Demographic and SocioEconomic Data(人口統計学的・社会経済学的データ)
"content"       ; Content(文章の内容)

我々は、参照目的のカテゴリ属性を指定している。規範的な定義と値、個々のcategoryに関する詳しい説明は P3P Harmonized Vocabulary Specification[HARMV]を参照して下さい。

P3Pは、利用者とユーザエージェントに、サービスから、どんなタイプの情報が要求されたかを知る追加的なヒントを与えるために、categoriesを使用する。大部分の基本データセットのデータは、既に知られているカテゴリ(または知られているカテゴリの組)内にあると同時に、幾つかのデータエレメントは、状況によって幾つかの異なるカテゴリ内にあることが出来る。最初の分は、fixed-category data elements(不変カテゴリ・データ・エレメント)(また短く"fixed data elements"(不変データエレメント))と呼ばれ、2番目は、variable-category dataelements(可変カテゴリデータエレメント)("variable data elements"(可変データエレメント))と呼ばれる。以下の二つの章で、これらのエレメント・タイプについて簡単に説明する。

4.5.1 Fixed-Category Data Elements(固定カテゴリのデータ要素)

基本データセットの大部分のエレメントは"固定"(fixed)データエレメントと呼ばれる:それらのエレメントは、一つ、または二つまでのカテゴリ・クラスに属する。基本データセットのエレメントを不変にカテゴリに割り当てることによって、サービスと利用者は、簡単に一致するカテゴリを参照する事によって、全体のグループを参照することが可能である。例えば、APPEL(privacy preferences exchange language)を使うことによって、利用者は、特定のカテゴリのデータエレメントを、ユーザエージェントが配布することを防ぐ規則を書くことが出来る。

固定データエレメントのために、新規のデータスキーマを作成(参照: "Creating New Data Sets(新規データセットの作成)")する時、スキーマの作成者は、エレメントが属するカテゴリを明白に列挙しなければならない。例えば:

<DATA:REF name="postal.street.line1"     type="text"
          short="Street Address, Line 1" VOC:category="physical" template="yes"/>

複数のカテゴリの場合、同じデータを参照している複数のエレメントを使用することが出来る。(個々のエレメントは、異なるカテゴリに属す)例えば、User.Name.のデータ・エレメントに"physical"と"demograph"と言うカテゴリを持たせたい場合、以下のように使用することが出来る:

<DATA:REF name="user.name."     type="personname."
          short="User's Name" VOC:category="physical" template="yes" />

<DATA:REF name="user.name."     type="personname."
          short="User's Name" VOC:category="demograph" template="yes" />

固定のデータエレメントのカテゴリクラスをオーバーライドすることは出来ない。例えば、固定の基本データエレメントに対して、異なるカテゴリを割り当てるような規則、またはプロポーザルを書くことによって。ユーザエージェントは、そのようなカテゴリを無視しなければならず、代わりにスキーマ定義内にリストされているオリジナルのカテゴリ(またはカテゴリの組)を使用する。ユーザエージェントは利用者に対して、固定のデータエレメントが、非標準的なカテゴリクラスと一緒に使用されていることを、警告することが出来る。

4.5.2 Variable-Category Data Elements(可変カテゴリのデータ要素)

基本データセットの全てのデータエレメントが、すでに決定されているカテゴリクラスに属するわけではない。幾つかのエレメントは、特定の状況において、幾つかのカテゴリからの情報を含むことが出来る。そのようなエレメントは、variable-category data elements(または短く"variable data element")と呼ばれる。P3P基本データセットの大部分の可変データエレメントは、dynamic.エレメントセットと結び付けられているが、それらの可変データエレメントは、どのデータセット内(fixed-category data elementsと混ざってもいても)にあっても良い。

そのようなエレメントのスキーマ定義を作成する時、スキーマの作成者は明白に述べられたカテゴリ属性をリストしてはならない。もしそうでなければ、エレメントは、固定(fixed)データエレメントになる。例えば、状況(例えば、クレジットカードの有効期限の日付に使用 VS. 誕生日の日付に使用)に応じて幾つかのカテゴリを取ることが出来る、"Year"データタイプを指定する時、以下のスキーマ定義が使用される:

<DATA:REF name="date.year" type="number" size="6"
          short="Year"     template="yes"/>  <!-- Variable Data Element -->

これは、そのような可変カテゴリデータタイプを参照する新規拡張スキーマが、新規スキーマの使用法に応じて、エレメントを引き出すための特定のカテゴリを割り当てることを許可する。例えば、拡張E-commerceスキーマは、以下のようにクレジットカードの有効期限を以下のように定義することが出来る:

<DATA:REF name="Card.ExpDate."         type="date."
          short="Card Expiration Date" VOC:category="financial" template="yes"/>

それらの状況下において、可変データタイプのdate.は、クレジットカードの有効期限を指定するために使われているので、固定カテゴリのFinancial Account Identifiersとして割り当てられた。より詳しい情報は、次章"Creating New Data Sets(新規データセットの作成)"を見てください。

利用者のプリファレンスは、そのような可変データエレメントを、追加のカテゴリ情報(このエレメントのいかなる使用法を通して、有効に表現されたプリファレンス)なしでリストすることが出来るので、サービスは常に特定のプロポーザル内に、可変データエレメントの使用法を適用するカテゴリを明白に指定しなければならない。この情報は、属性として、プロポーザルにリストされている一致するDATA:REFエレメントになければならない。例えば:

<P3P:PROP>
   ...
   <DATA:REF name="dynamic.cookies" VOC:category="uniqueid">
   ...
</P3P:PROP>

サービスは、このサイトでcookieが利用者を特定するために使用されることを宣言する。(例:カテゴリUnique Identifiers)

4.6 Creating New Data Sets(新規データセットの作成)

サービスはデータスキーマを作成することにより新規データエレメントを宣言/使用でき、DATA namespace(xmlns:DATA)を使用することによってプロポーザル内のデータエレメントを参照できる。基本データセット[BASEDATA]に定義されていないデータエレメントがプロポーザル内で参照された時、DATA:REF エレメントは以下の属性のための値を含まなければならない:name, category, type, typeschema, short(typeschema は DATAnamespaceと同じ値を持つ場合、省略できる)データスキーマのURIがオリジナルのサーバーのURIとの間で、ドメインの一致をしない場合、ユーザーエージェントは情報の一貫性を確かめるためにデータスキーマを確認しなければならない。または、メインデータスキーマの情報は情報の一貫性を確かめるために確認されるだろう。ドメインが一致しない場合、ERR-IF(Invalid Format)コードまたは一般的なERRコードが返却されなければならない。何かの理由で利用者が必要とされた情報を再構築できない場合、SRY-DU(Data Unavailable)コードまたは一般的なSRYコードが返却されなければならない。

新規データスキーマのフォーマットはフォームの特殊なプロポーザルです。

<PROP xmlns="http://www.w3.org/TR/WD-P3P/syntax" 
 xmlns:VOC="http://www.w3.org/TR/WD-P3P/vocab"
 xmlns:DATA="http://www.w3.org/TR/WD-P3P/basedata">
<USES><STATEMENT>
  ....
</STATEMENT></USES></PROP>

データブロックは<STATEMENT>タグで囲まれており、新規データエレメントの参照を含んでいる。参照は、<DATA:REF>タグと以下の属性を使用して作成されることが出来る: name, type,typeschema, template, VOC:category, short, long, size, source.

全てのデータエレメントについて、全ての情報(longsourceは除く)は必須である。もしsourceが存在する場合、エレメントは特定のデータ転送機構を用いてのみ収集されなければならない。もしsourceが無い場合、どのようにエレメントが収集されるかについての制限はない。もし属性が無い場合、空の文字列が存在すると考えられる。typeschemaの場合、空の文字列はタイプスキーマが、対応するREFエレメントのnamespaceに一致しているという特別な意味を持つ。

例えば、HyperSpeed社は以下のようなデータスキーマを構築したいと想定する:

car.model
car.color
car.built.year
car.built.where. (of basic type postal.)
car.price
bike.model
bike.color
bike.built.year
bike.built.where. (of basic type postal.)
bike.price

それからHyperSpeed社は、以下のコードをhttp://www.HyperSpeed.com/models-schemaに置く。

<PROP xmlns="http://www.w3.org/TR/WD-P3P/syntax" 
 xmlns:VOC="http://www.w3.org/TR/WD-P3P/vocab"
 xmlns:DATA="http://www.w3.org/TR/WD-P3P/basedata">
<USES><STATEMENT VOC:id="nonid">
<VOC:RECPNT v="ours"/>
<VOC:PURPOSE v="contact"/>  <DATA:REF name="car.model" type="text" short="Model"     VOC:category="pref" size="63"/>  <DATA:REF name="car.color" type="text" short="Color"     VOC:category="pref" size="63"/>  <DATA:REF name="car.built.year" type="number" short="Construction Year"     VOC:category="pref" size="63"/>  <DATA:REF name="car.built.where." type="postal."  short="Construction Place"     VOC:category="pref" size="63"/>  <DATA:REF name="bike." type="car."     typeschema="http://www.HyperSpeed.com/models-schema"/> </USES></STATEMENT></PROP>

注意:データセットが作られる度に、必然的にデータセットはタイプ(上記のcar.のように)として使用される。しかし、何らかの状況で、利用者のレポジトリ内で特定のエレメントを作成すること無しに、タイプを定義したいと望むだろう。これは、<DATA:REF>内でtemplate属性を使用することにより成し遂げられることが出来る。値を"yes"、template="yes" (規定値は "no")に設定すると、一致するデータエレメントはタイプの定義の一部のみである事を意味する。そして、それは実際には提携された値のデータエレメントを示していない。例えば、HyperSpeed社はGenericModel.を一般的な実用品として定義したい。それから、car.bike.を具体的な物としたい。これは以下のスキーマに従うことで可能である:

<PROP xmlns="http://www.w3.org/TR/WD-P3P/syntax" 
 xmlns:VOC="http://www.w3.org/TR/WD-P3P/vocab"
 xmlns:DATA="http://www.w3.org/TR/WD-P3P/basedata">
<USES><STATEMENT VOC:id="nonid">
<VOC:RECPNT v="ours"/>
<VOC:PURPOSE v="contact"/>  <DATA:REF name="GenericModel.model" type="text" short="Model" template="yes"     VOC:category="7" size="63"/>  <DATA:REF name="GenericModel.color" type="text" short="Color" template="yes"     VOC:category="7" size="63"/>  <DATA:REF name="GenericModel.built.year" type="number" short="Construction Year"     template="yes" VOC:category="7" size="63"/>  <DATA:REF name="GenericModel.built.where." type="postal."     short="Construction Place" template="yes" VOC:category="7" size="63"/>  <DATA:REF name="car." type="GenericModel."     typeschema="http://www.HyperSpeed.com/models-schema" short="Car"/>  <DATA:REF name="bike." type="GenericModel."     typeschema="http://www.HyperSpeed.com/models-schema" short="Bike"/> </USES></STATEMENT></PROP>

新規にスキーマを作成する者はソース属性(例えば source="service" や、利用者のレポジトリにデータを保存しない拡張機構の使用)に制限を設けない限り、ユーザーエージェントは利用者が新規スキーマのエレメントを書きこんだ後に、自動的にレポジトリにそれらのエレメントを保存する事を理解していなければならない。いくつかの実装はセンシティブなデータの保存に対しての適切なセキュリティーを設けていない利用者レポジトリを持っているものもある。

データスキーマファイルの多国語サポートを提供する為に、サーバーは、HTTPヘッダのAccept-Languageを元に、正しい選択肢を供給することができる。

P3Pは、利用者名と住所などの頻繁に要求される情報をクライアント側のレポジトリ内に保存することを許す。P3P基本データセット[BASEDATA](拡張スキーマの多くも同様に)の多くのデータは、多分レポジトリに保存されるが、P3Pはまた、レポジトリに保存されないデータ(non-repository data)もサポートする。そのようなデータは、けしてレポジトリには保存されず、毎回エレメントが要求されたときに利用者が手で打ち込まなければならない情報か、クリックストリーム情報やブラウザを特定する文字列のようなユーザエージェントまたはオペレーティングシステムによってダイナミックに生成された情報を構成するデータです。

新規のスキーマ定義を作成する時、スキーマの設計者は、利用者のレポジトリ内に一致するフィールドを設けることを、ユーザエージェントが試みなければならないということを(従って、情報の繰り返された転送を促進する)指定することが出来る。もしくは、スキーマの設計者は、エレメントが動的で、レポジトリ内に含まれるべきではない、ということを指定することが出来る。以下のサブセクションでは、それら二つのより詳しいコンセプトを説明している。

4.6.1 Repository Data(レポジトリデータ)

スキーマ定義内のいかなるエレメントは、利用者レポジトリの一部として仮定される。従って、(固定)レポジトリエレメントのスタンダードなスキーマ定義は、以下のようになる:

<DATA:REF name="personname.first" type="text"
          short="First Name"      VOC:category="physical" template="yes"/>

しかし、エレメントは利用者レポジトリの一部だけれども、レポジトリ内の利用可能なデータを無視して、P3Pプロポーザルが利用者に手動でエレメントを入力させることを明白に指定することが出来るだろう。(例えば、HTMLフォームを通して)

<P3P:PROP>
   ...
   <DATA:REF name="user.name.first" source="service">

   ...
</P3P:PROP>

もちろん、アプリケーションは、Webサイトがレポジトリデータを要求していなかったにもかかわらず、レポジトリを元にした自動入力機能を提供することが出来る。また、新規のレポジトリに保存されているデータスキーマに遭遇した時、どんな行動をとるかを決定するのは、ユーザエージェントの実装方法によることを注意してください。例えば、利用者のレポジトリ(空の値を伴って)にエレメントを自動的に追加することが出来る実装だったり、利用者に、どうするかを決めてもらうために問いかけを行う実装です。

4.6.2 Non-Repository Data(非レポジトリデータ)

以前に説明したように、データスキーマ定義内の属性値のセットは、オーバーライドされることは出来ない。従って、常に確かなデータエレメントを利用者レポジトリの外に置くためには、スキーマの設計者は単に、source属性をserviceに設定しなければならない:

<DATA:REF name="dynamic.clickstream.client"
          short="Click-stream collected on the client"
                          type="boolean" source="service"
                          VOC:category="navigation" template="yes"/>

上記の例は、Dynamic.Clickstream.Serverは、利用者レポジトリの一部にはなり得ないことを保証しますが、代わりに、手動で情報を収集(HTMLフォームを通して)または、コネクションの一部として、暗黙の内に送信される(クリックストリームデータの場合)。どちらの場合にせよ、P3Pユーザエージェントは利用者に、(利用者のプリファレンスによる)データエレメントと、その用語について知らせるだろうが、エージェントはデータの転送に関して、それ以上何もしない。


5. Appendices(付録)

Appendix 1: References (標準準拠)

[APPEL]
M. Langheinrich (Ed.). "A P3P Preference Exchange Language (APPEL)" World Wide Web Consortium.
[BASEDATA]
M. Marchiori (Ed.). "P3P Base Data Set." World Wide Web Consortium, Working Draft.
[DSIG]
Y. Chu, P. DesAutels, B. LaMacchia, P. Lipp. "PICS Signed Labels (DSig) 1.0 Specification," World Wide Web Consortium Recommendation 27 May 1998.
[HARMV]
J. Reagle (Ed.). "P3P Harmonized Vocabulary Specification,"  World Wide Web Consortium, Working Draft.
[HTTP1.0]
T. Berners-Lee, R. Fielding, H. Frystyk Nielsen, "RFC1945 -- Hypertext Transfer Protocol -- HTTP/1.0," W3C/MIT, UC Irvine, W3C/MIT, May 1996.
[HTTP1.1]
R. Fielding, J. Gettys, J.C. Mogul, H. Frystyk, T. Berners-Lee, "RFC2068 -- Hypertext Transfer Protocol -- HTTP/1.1," UC Irvine, Digital Equipment Corporation, MIT.
[HTTP-EXT]
H. Frystyk, P. Leach, S. Lawrence. "HTTP Extensions" (draft-frystyk-http-extensions-03.txt). Jan 1999. IETF Internet Draft.
[ISO3166]
"ISO3166: Codes for The Representation of Names of Countries." International Organization for Standardization.
[KEY]
S. Bradner. "RFC2119 -- Key words for use in RFCs to Indicate Requirement Levels." March 1997.
[MD5]
R. Rivest. "RFC 1321 -- The MD5 Message-Digest Algorithm," MIT. April 1992.
[MIME]
N. Freed, N. Borenstein. "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies." November 1996.
[RDF]
O. Lassila, R. Swick (Eds.). "Resource Description Framework (RDF) Model and Syntax Specification."  World Wide Web Consortium Recommendation. 22 February 1999.
[SSL]
A. Freier, P. Karlton,  P. Kocher. "SSL 3.0 Specification." (http://home.netscape.com/eng/ssl3/index.html)
[STATE]
Network Working Group, D. Kristol, Bell Laboratories, Lucent Technologies; Category: Standards Track  HTTP State Management Mechanism. (ftp://ftp.isi.edu/in-notes/rfc2109.txt)
[URI]
T. Berners-Lee, R. Fielding, and L. Masinter. "Uniform Resource Identifiers (URI): Generic Syntax and Semantics." August 1998. RFC 2396. [Updates RFC1738]
[UTF-8]
F. Yergeau. "RFC2279 -- UTF-8, a transformation format of ISO 10646." January 1998.
[VCARD]
"vCard - The Electronic Business Card Version 2.1." Internet Mail Consortium, September 18, 1996.
[XML]
T. Bray, J. Paoli, C. M. Sperberg-McQueen. "Extensible Markup Language (XML) 1.0 Specification." World Wide Web Consortium, Recommendation. 10 February 1998.
[XML-Data]
A. Layman et al. "XML-Data." World Wide Web Consortium, Note. 05-January-1998.
[XML-Name]
T. Bray, D. Hollander, A. Layman. "Namespaces in XML." World Wide Web Consortium, Recommendation, 14-January-1999.

Appendix 2: ABNF Notation (標準非準拠)

正式なP3Pの文法については、このスペック内にありhttp://info.internet.isi.edu/in-notes/rfc/files/rfc2234.txtで定義されているABNFを少し修正した物を使用している。以下はABNFの簡単な説明です。

name = (element) 
<name> は規則名, <elements> は複数の規則名または、以下によって提供された数値を通して 結合されたターミナル。 規則名は大文字/小文字を区別しない 
(element1 element2)
括弧によって囲まれたエレメントは一つのエレメントとして扱われ、コンテントは厳しく順番づけられる。
<a>*<b>element
最低 <a> 個と最高<b>個のエレメントの発生
(1*4<element> は1〜4エレメントを意味する)
<a>element
<a>個のエレメントの発生
(4<element> は4個のエレメントの発生を意味する)
<a>*element
<a> 個、またはそれ以上のエレメント
(4*<element> は4個以上のエレメントを意味する)
*<b>element
0 to <b> 個のエレメント
(*5<element> は0〜5個のエレメントを意味する)
*element
0個以上のエレメント
(*<element> 無限のエレメントを意味する)
[element]
任意のエレメント、*1(element)と同等
([element] は 0 または 1 エレメントを意味する)
"string" or 'string'
””内に与えられた文字列matchingと同等

使用されているその他の記号法は:

; or /* ... */
コメント

Appendix 3: Working Group Contributors

以下の個人は、P3P Specification Working Groupに参加した人たちです。

[後で記入]

P3P Specification Working Group は、以前のP3P working groupsから大部分のスペックを受け継いでいる。 Working Groupは、以前のグループのメンバの貢献に感謝したい:

[後で記入]