このドキュメントは

Platform for Privacy Preferences(P3P) Syntax Specification
W3C Working Draft 7 April 1999

の和訳です。

なお、このドキュメントには和訳上の誤りがありえます。
内容の保証はいたしかねますので、必ずW3C Webサイトの正式版ドキュメントを参照して下さい。

正式版のURL: http://www.w3.org/TR/1999/WD-P3P-19990407/syntax.html


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




W3C

Platform for Privacy Preferences (P3P) Syntax Specification

W3C Working Draft 7 April 1999

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

Abstract (要約)

このドキュメントは P3P specification の中でも、核心部分に関するもっとも長いドキュメントです。 ドキュメント内において、必要条件、了解事項、そしてP3Pプロトコル、伝達方法、データ構造のシンッタックスと エンコーディングにつての明確化を行っています。

Status of This Document 

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

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

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

Copyright (C)  1999 W3C (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.


Table of Contents(目次)

  1. Introduction(はじめに)
    1. Problem space
    2. About this specification(この仕様書について)
    3. Operational description(オペレーションに関する記述)
    4. Operational design(オペレーションに関する設計)
    5. Assumptions(仮定)
    6. Terminology(専門用語)
    7. 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. Client requests proposal from the server(クライアントのサーバーへのプロポーザル要求)
      2. Client returns repository data referencing a specific policy(クライアントからの特定ポリシーを参照しているデータ返却)
      3. Server suggests proposal (location) to the client(サーバーからクライアントへのプロポーザル(ロケーション)提案)
      4. Server accepts a proposal /data required by the client or reports an error(クライアントから要求されたプロポーザルやデータの受け入れ、エラー報告)
    4. Reason codes definition
    5. Agreement scenario(同意のシナリオ)
  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 VOC:DISCLOSURE element
      4. The ASSURANCE element
    3. Data Transmission(データの送信)
    4. Statements(ステートメント)
      1. The STATEMENT element
      2. The DATA:REF element
      3. Creating New Data Sets
  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アプリケーションのインプリメントに必要な全ての仕様を含む。 この仕様書は過去のワーキンググループの実績の上に築かれ、以下にあげるものを含んでいる。

  1. プロトコルの原型
  2. プロトコルのスキーマ(プロポーザルのプライバシープラクティス用語を含む)
  3. プロトコルの文法と記号化(データの構造と書式を含む)

このドキュメントは、P3P仕様のメインとなる部分を含んでいます。 プライバシーデスクロージャー用語の語議論の詳細 <natural language>は、以下の章で見る事が出来ます。

http://www.w3.org/TR/1999/WD-P3P-19990407/vocab

基本データセットの文法とデータタイプの詳細は以下の章で見る事が出来ます。

http://www.w3.org/TR/1999/WD-P3P-19990407/basedata

注意: この用語の使用がP3P1.0の応諾を必要としている間、XMLの容易さ(namespaces [XML-name] )は追加 または補足的な用語を簡単に紹介できることを許可する。

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

この仕様書で使われたABNF表記法は、RFC2234 で規定されている。また、Appendix 2に要約されている。

1.3 Operational description(操作説明)

利用者がWebサイトを訪れた時、サイトはプライバシープラクティスを宣言し、その上利用者からの個人情報を 要求する。

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

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

一度同意に至ると、合意プロポーザル(agreed-to proposal)に含まれたデータエレメント郡は、ユーザーエージェントにより、サービスからリクエストされたデータとして説明されるべきである。同意において情報を収集しない場合、データエレメントの参照なしで同意に至る事は可能である。

レルムに複数のプロポーザルが存在することが可能である。またサービスも代替手段やオプショナルなプロポーザルを提供する能力を持っている。 プロポーザルは利用者の目に見える形で、なぜ利用者が普段許可しないようなプラクティスでさえも提案したプラクティスが特定の場合に重要であるかの説明を掲げることが出来る。ユーザーエージェントは同意に至った事を同意のfingerprintごとに記録に残すべきである。

サイトは毎回ユーザーエージェントに新規のプロポーザルを送る代わりに、既存の同意のpropIDを送る事が可能である。これは、1)サービスとユーザーエージェントが既にプロポーザルに同意していることが明白である。2)どのプロポーザルとプライバシープラクティスが使用されているかの表示。3) 同意に基づくデータエレメントの要求。同意に対する記録が無い、または新規に要求したい場合、ユーザーエージェントは拒否、要求されたデータへの応答、全てのプロポーザル要求が可能である。

1.4 Operational design(操作設計)

プロポーザル(プロポーザルへのポインタ)はトランスポートメカニズム(HTTP)や内容・資源(HTMLページ)内において送られる。複数のプロポーザル代替手段は、目的の柔軟性のために存在することが可能である。サービスはHTTP内において、P3P-extension multiple times や、HTML内において multiple links を使用することが出来る。

エージェントは固有の伝達方法・コンテントモデルに関する情報を返却しなければならない。 我々はHTTP方式で情報の交換を成し遂げる方法を定義する。また、他の方法で情報を返却するための拡張メカニズムを特定する。

以下に、我々が独自に提供する拡張メカニズムに関する2つの注目すべきエリアを示す。

  1. How information is solicited from the user. (どのように情報は利用者によって要求されるか)
    (source attributeを参照して下さい)
  2. How new data sets are used by services and clients (サービスとクライアントによって、どのように新規データセットは使用されるか)
    (DATA:REFと namespacesを参照して下さい)

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

1.5 Assumptions(仮定)

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

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

1.6 Terminology(専門用語)

Assuring Party(保証機関)
P3P内部において、保証機関は合法的な実体(個人 または 団体)であり、プロポーザルに関して保証を行うものである。(例:プラクティス監査やデータ収集ガイドラインに従っているかなど)保証はサービス、または第三機関からくるものです。保証機関は、プロポーザル内において、保証文の一部として、何を 証明するか、特定されたURI、またはメタデータスキーマの意味を明らかにしなければならない。
Agreement(同意)
サービスとユーザーエージェント双方が同意したプロポーザル。この同意はレルム内におて使用され、しばしばpropIDとして用いられる。このような同意性は、将来のP3Pにおける証明書や電子署名の将来性のサポートにより強固になります。version1.0でその事は特定されていなかったが、今後特定のフィールドを設けたいと思っている。(例:assuring paty(保証機関)による電子署名の発行など)
Data Element(データエレメント)
個々のデータ要素。例えば、名字、電話番号など。国際的利用のため、P3P1.0では、基本的なデータエレメントを指定しています。
Data Category(データカテゴリ)
データエレメントデータセットの属性はTrust Engineがどんなエレメントタイプが審議中であるか決定するために使われる。例えば、"Contact Information."  P3P1.0では、10個の基本データカテゴリーを指定しています。
Data Set(データセット)
グループ化されたデータエレメント。例えば、"User.Home.Postal."。データセットはピリオドの区切りにっよって表現されている。P3P1.0ではいくつかの基本データセットを指定しています。
Fingerprint (Hash, Digest)(フィンガープリント)
あるいくつかのデータをハッシュ関数にかけた結果として出来た固定サイズの値。フィンガープリントは簡単に計算できますが、 ちょっとした変化を元の情報に加えても事実上予期できない値が結果として出来てきます。したがって、フィンガープリントは、 しばしばテーブルやデータベースへ入るキーまたは情報の安全保障の手段として用いられます。我々は、[MD5]というアルゴリズム をP3Pフィンガープリント用に使用しています。これは、128-bitの値を生み出し、P3Pのコミュニケーションのなかでその値は、 暗号化され交換されています。
Preference
ユーザーエージェントがどんな行動をするか、何時会話に入ることを許可するか、またはサービスとの交渉等に関する規則(規則集)。 プリファレンスは形式の整った計算できる文で表現される。(例:[APPEL] プリファレンスは言語を交換する) この文書のなかで、プリファレンスはユーザーエージェントとサービス間に達するいろんな同意を管理します。
PropID
P3Pプロポーザルを識別するために使われる情報。propIDはプロポーザルにおけるfingerprintです。P3Pヘッダ内でのpropIDの存在は、どの同意がrealm(レルム)に対して実施されるかの最終的宣言である。確認とP3Pプロポーザルの参照以外の目的でpropIDを使用してはならない。(例:利用者のブラウジング状態を維持させるために使用してはならない。)
Proposal(プロポーザル)
プロポーザルは、いくつかのプライバシーステートメント(主張された身元、URI、保証等の情報、プロポーザルによりカバーされているサービスの情報開示)の集まりです。プロポーザルは常にサービスの観点から作り出されるもので、サービスにとっての情報の確認を含んでいます。しかし、プロポーザルは、ユーザーによって作り出され、サーバーに許可のために送られる事もあります。
Realm(レルム)
レルムは、与えられた同意が発行された元に要求したエクスペリエンス スペースです。レルムはプロポーザルを適用した領域として、 広い意味で定義されています。レルムは、いくつかのURIから参照されます。どの同意がURIで実施されているかの最終判断は、同意IDの存在によって決定されます。それぞれのURIは、URIによって限定された特殊なリソースを名前付けます。例えば、HTTP スキーマの中で、オブジェクト(home.html)で終了しているURIは、特殊なオブジェトを適用します。また、URIがpath http://www.w3.org/P3P/ の場合、URIは、path 配下の system tree を参照します。もしプロポーザルに電子署名が無い場合、それぞれのURIはオリジナルのサーバーとドメインが同一でなければなりません。ドメイン マッチングは、HTTP state management mechanism internet draft [STATE] に含まれています。
Repository(レポジトリ)
P3Pの制御下で利用者情報を保存するメカニズム
Service
プロポーザルを発行しデータを要求するプログラム。この定義では、サービスはサーバー(サイト)、ローカルアプリケーション、 ローカルなアクティブコード(ActiveX や 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.7 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
この言葉は、「推奨される、した方がよい」という意味で、無視することができるある特定の状況が存在する場合もあるが、レベル1インプリケーションのために別の方法をとるまえに完全な意味を理解し、注意深く状況を判断すべきである。
MAY
この言葉は、「任意に選んで良い、してもよい」という意味で、選択する余地がある場合に用いられる。あるベンダーは、ある特定の市場はそれを必要としているから、或いは製品を向上させるからという理由で、そのアイテムを選んでもよい。例えば、別のベンダーは同じアイテムをレベル1インプリメンテーションで省略するかもしれない。

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

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

Terminology

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

Data transport

the HTML LINK tag MUST エージェント及びサービスはこの場所にプロポーザルを設置することが出来る必要がある。
  HTTP拡張メカニズム MUST エージェント及びサービスはこの場所にプロポーザルを設置することが出来る必要がある。
  postURI/CGI MUST データはHTTP post経由でいくつかのURIに送り返すことが可能でなければならない。

XML/RDF encoding

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

XML/RDF encoding

完全なXMLとXML-namespaceのサポート MUST 実装時、使用されるだけでなく、完全に XML と namespacesをサポートしなければならない。
Data References base data reference syntax MUST エージェントは請求されている情報のシンタックスを理解できなければならない。
Abstract Elements abstract elements MUST P3P以外の方法で交換されたreference dataの方法
Harmonized Vocab harmonized vocabulary MUST 必要条件に関しては、harmonized vocubarlyを参照。この必要条件を満たさなければならない。満たさない場合、インプリメンテーションがprivcy公開を適切なレベルで出来なくなってしまう。
Reason Codes (OK, SRY-, ERR-, SRY, ERR) MUST 同意に達する必要がある。もし理由コードが提供されない場合は、暗示のセマンティクスがある。結果として、このセマンティクスは必要となり、codeの存在は、任意となる。
Operational Description propID repository SHOULD 完全なプロポーザルはコンパクトに表示されることが出来る。同意がすでにある場合、新規の交渉、同意は不必要である。
  service can write to the data repository SHOULD 利用者の承諾があれば、サービスは利用者レポジトリに情報を書き込むことが出来る。
  data repository MAY 頻繁に要求される利用者プロフィール情報は利用者によって保存/管理される。
Data Definitions new schema instantiation MAY base setとは異なったスキーマは、エージェントにより例示/サポートされることが可能である。
Source Attribute source attribute MAY エージェントは複数の拡張可能な機能をサポートし、それにより情報は送信を請求される。

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

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

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

2. Scenarios(シナリオ)

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

これらのシナリオは交渉が発生しない場合の相互作用を図解している。 しかしどのシナリオもサイトが初めから複数のプロポーザルを行うシナリオに拡張されたり、サイトとユーザ間で一連のプロポーザルやカウンタープロポーザルが交わされるシナリオに拡張される可能性がある。 Appendix 1 のシナリオ拡張例は、交渉の一例を含んでいる。

以下の表は、各シナリオの特徴をまとめたもの。表中の"-"は、そのシナリオでは仮定されない(中立な)という意味を表す。
 
Scenario Existing Agreement New Proposal Data Requested Data Written
1 No Yes - -
2 Yes No - -
3 Yes Yes - -
4 - - Yes No
5 - - Yes 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) サービスがクライアントのレポジトリからデータを要求する。

Scenario 5) クライアントが情報をサービスに書き込む。

3 Data Transport

3.1 Protocol Model

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

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

3.1.1 Client Actions

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

サーバへのプロポーザル要求
クライアントがプロポーザルを持っていないか新規にほしい場合、クライアントはサービスの特定のリソース対しプロポーザルを1つ要求することが出来る。 注意:サービスから取得したプロポーザルはリソースをカバーすることが出来る。例えば、特定のサーバーからエクスポートされた全てのリソース。
特定のポリシーを参照しているレポジトリデータの返却
クライアントが既に特定のリソースに対して同意に至っている場合、クライアントはサーバーに対して要求に含まれるデータのために このプロポーザルを使用することを要求することが出来る。

3.1.2 Server Actions

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

クライアントに対してプロポーザル(ロケーション)を提案する。
サーバーはサーバーが発行するいかなるレスポンスにプロポーザルを含むことが出来る。 クライアントがプロポーザル要求を出したために、サーバーはレスポンス内部にプロポーザルを有するであろう。 または、サーバーはクライアントに対し複数のリソースのための代替的なポリシーを示したい。
クライアントまたはエラーレポートによるプロポーザルの受諾
クライアントがプロポーザルを照会した時、サーバーはそのプロポーザルを受諾または拒否することが出来る。 サーバーがプロポーザルを受諾しない場合、サーバーは受諾/参照のポリシーをうたっているエラーを発行しなければならない。 そのため、クライアントはリトライするかどうか決めることが出来る。

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

HTTP Extension Framework[HTTP-EXT]を使用するためには、 拡張(拡張宣言)を識別するためのグローバルなユニークURIを規定することが要求される。 P3Pの拡張宣言は以下のURIを参照して下さい。

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

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

status
P3Pメッセージのステータスを記述します。ステータスはreason code(Section 3.4を参照)を使用して表現されます。
propID
参照されたプロポーザルのpropID。フォーマットは"md5:X"である。 XAppendix 2で定義しているプロポーザルのリソースハッシュ (64bitベースであるmd5 fingerprint暗号)
proposal
プロポーザルがフェッチされることが出来るURI。
data
特定の同意の元にクライアントがサーバーに送るデータを一行ごとに記号化したXMLメッセージ

3.3 Protocol Actions

3.3.1 Client requests proposal from the server(クライアントのサーバーへのプロポーザル要求)

クライアントはP3Pについての知識があると言うことを明言した要求を発行することにより、 サーバーへのプロポーザル要求を行う。この要求はP3P extension declaration(http://www.w3.org/TR/WD-P3P/)を 使用し、HTTP Extension Framework(HTTPの拡張構成)経由で実行される。Optional extensionもしくはMandatory extensionの使用は実装次第である。

例:クライアントはOPTIONSを使用し、サーバーがP3P準拠であるかどうか確認できる。

OPTIONS some.resource HTTP/1.1
Host: some.host
Opt: "http://www.w3.org/TR/WD-P3P/"

または標準の GET 要求

GET some.resource HTTP/1.1
Host: some.host
Opt: "http://www.w3.org/TR/WD-P3P/"

もちろんMandatory extensionがOptionalの代わりに使用された場合、M-OPTIONSM-GET メソッドを使用しなければならない。([HTTP-EXT])

3.3.2 Client returns repository data referencing a specific policy(クライアントからの特定ポリシーを参照しているデータ返却)

クライアントが既に特定のリソースに対しての同意を得ている、またはクライアントが提供されたプロポーザル に同意したい時、リクエスト内に含まれたデータのためにこのプロポーザルを使用することを、サーバーに要請することが出来る。 これは、Mandatory P3P extension declarationのM-POSTメソッドを使用することにより成し遂げられ、おのおの のプロポーザルのために以下のP3P extension を設ける。

サーバーがこのポリシーに従いたくない場合、サーバーはデータを無視し、エラーを返さなければならない。

例1:クライアントがpropID(94df1293a3e5)を用いて、提供されているプロポーザルに対して同意したい場合、クライアントは 以下のものを送る。

M-POST / HTTP/1.1
Host: www.CoolCatalog.com
Man: "http://www.w3.org/TR/WD-P3P/"; ns='15-'
15-status: OK
15-propID: "md5:94df1293a3e5"
15-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">
15-data: <DATA:REF name="User.Name.First" value="Sheila">
15-data: <DATA:REF name="User.Name.Second" value="Doherty">
15-data: </TXD>

...
[Content]

例2:クライアントがpropID(94df1293a3e5)で、提供されているプロポーザルに対して同意し、 propID(AAbbAAbbAAbb)でプロポーザルに同意したい場合、クライアントは以下のものを送る。

M-POST / HTTP/1.1
Host: www.CoolCatalog.com
Man: "http://www.w3.org/TR/WD-P3P/"; ns='15-'
Man: "http://www.w3.org/TR/WD-P3P/"; ns='22-'
15-status: OK
15-propID: "md5:94df1293a3e5"
15-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">
15-data: <DATA:REF name="User.Name.First" value="Sheila">
15-data: <DATA:REF name="User.Name.Second" value="Doherty">
15-data: </TXD>
22-status: OK
22-propID: "md5:AAbbAAbbAAbb"
22-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">
22-data: <DATA:REF name="User.Business.Postal.City" value="Cambridge">
22-data: </TXD>
...
[Content]

3.3.3 Server suggests proposal (location) to the client(サーバーからクライアントへのプロポーザル(ロケーション)提案)

サーバーは何時でも複数のリソースに対し、どのポリシーが使われるか示すことが出来る。 複数のプロポーザルが提供された場合、そのプロポーザルは複合代替プロポーザルとして 考慮される。“代替”とはどういう意味かというと、提供されるかも知れない多くのプロポーザルの中から クライアントはひとつのプロポーザルを選択すべきであるという事です。プロポーザルの提供には 二つの方法がある。一つ目はHTTPレベルで、HTTP Extension frameworkを使用する方法で、二つ目はHTMLレベルで、 HTMLLINKタグを使用する方法です。 これらの二つの方法は排他的ではない:二つの方法が同時に使用された場合、解釈は複合代替プロポーザル群が行う。

HTTP Level

Optional P3P extension declarationを使用することによって行われ、各々の提案されたプロポーザルのために以下の P3P extensionsを設ける。

規定のrealm(レルム)は現行のRequest-URIのみです。

例:

HTTP/1.1 200 OK
Opt: "http://www.w3.org/TR/WD-P3P/"; ns='14-'
14-propID: "md5:94df1293a3e5"
14-proposal: "http://www.privacy.org/P3PProposal"
...
[Content]

複合(この場合三つ)の代替プロポーザルがある場合:

HTTP/1.1 200 OK
Opt: "http://www.w3.org/TR/WD-P3P/"; ns='15-'
Opt: "http://www.w3.org/TR/WD-P3P/"; ns='18-'
Opt: "http://www.w3.org/TR/WD-P3P/"; ns='20-'
15-propID: "md5:94df1293a3e5"
15-proposal: "http://www.privacy.org/P3PProposal"
18-propID: "md5:23as53aw12w2"
18-proposal: "http://www.privacy.org/P3PProposal2"
20-propID: "md5:56ew89qwht14"
20-proposal: "http://www.privacy.org/P3PProposal3"
...
[Content]

HTML level

これは、各々の提供された代替プロポーザルに対し、以下の方法でHTML LINKタグ を使用したことによって遂行される:

<LINK rel="p3p:md5:hash" href="URI">

ここでURIはP3Pプロポーザルを指し示す。"p3p:md5:hash" は この特殊なP3Pリンクを区別するための関連名で、md5を使用してプロポーザルのhash(ハッシュ)値を とるためのものです。例えば、http://www.privacy.org/P3PProposalでプロポーザルはハッシュ値94df1293a3e5 を持っている場合、<LINK rel="p3p:md5:94df1293a3e5"href="http://www.privacy.org/P3PProposal"> という風に記述します。

注意:HTMLのコンテント内部をすぐに検索しなければならないので、プロポーザルのフェッチに 時間がかかる可能性がある。しかし、そのようなプロポーザルはキャッシュされることができる。この方法は次のような サイトでのみ使用されるべきである。1)P3Pのデータメソッドを使用していないサイト 2)少量、簡潔、重複なしのプロポーザル を持っているサイト

3.3.4 Server accepts a proposal /data required by the client or reports an error (クライアントから要求されたプロポーザルやデータの受け入れ、エラー報告)

クライアントがM-POSTメソッドを使用してプロポーザル要求を行った場合、サーバーは それを受け入れるか失敗しなければならない:これはMandatoryが機能的要求の特性です。[HTTP-EXT] サーバーがプロポーザルを受け入れた場合、それ以上の応答は必要ありません。サーバーがプロポーザルを受け入れなかった場合、 サーバーはクライアントから受け取ったであろう全てのM-POSTメッセージを無視しなければならない。また、プロポーザルを 受け入れることが出来るというポリシーを提唱しているエラーを発行しなければならない(これによってクライアントは リトライするかどうか決めることが出来る)。これは、Optional P3P extension declarationを使用することによって行われ、 以下のP3P extensionsを設ける:

もちろん、新規プロポーザルが提供された場合、propID extensionを設けなければならない。 規定のrealm(レルム)は現行のRequest-URIのみです。

例えば、以前の同意が期限切れの場合:

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

3.4 Reason codes definitions

理由コードはstatus extention headers(ステータスエクステンションヘッダ)内で送られ、プロポーザルやデータの状態を 表す(可能性として、以前の相互作用の状況内で)。全てのP3Pエクステンションは特定された値やextension URIと一緒に ステータスヘッダを含まなければならない。ステータスエクステンションを理解できないアプリケーションはP3Pメッセージを 無視しなければならない。
Reason Token(理由の標章) Explaination(説明)
OK ok, プロポーザルの内容やデータエクステンションの受け取りが完全に成功した。
SRY-AU 同意(agreement)が不明(unkown)であるから。(データエクステンションの内容に応じて送られた)
SRY-AE 同意(agreement)が期限切れ(expired)であるかあら。(データエクステンションの内容に応じて送られた)
SRY-PR プロポーザル(proposal)が拒否(rejected)されたため。(データエクステンションの内容に応じて送られた)
SRY-DU データ(data)が利用できない(unavailable)。(データエクステンションの内容に応じて送られた)
SRY-DR データ(data)を受け入れることができなかった。もしくはレポジトリ(repository)に 書き込めなかった。(データエクステンションの内容に応じて送られた)
SRY sorry), プロポーザルの内容やデータエクステンションの受け入れに失敗。このコード は他のSRY-コードが適用できない時にプロポーザルエクステンションに応じて送られる。
ERR-IF invalid format), 受け取ったP3Pメッセージが文法的に不適切、または意味が通じない。
ERR-TF データ転送失敗(data transfer failed), 文法的に正しく、正しい同意 がある転送要求が受け取られたが、何かの理由でデータを保存できなかった。
ERR error)要求は理解されなかった、または正しく受け取られた。このコードはその他全てのERR-コード が当てはまらない時に送られる。

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

3.5 Agreement scenario(同意のシナリオ)

1. 利用者がオーダーのページに行き、プロポーザルを要求:

GET store1.com/catalog/page1.html HTTP/1.1
Host: store1.com
Opt: "http://www.w3.org/TR/WD-P3P/"

2. もしくはサービスは要求されたURIに対してRDFによって構築された代替のプロポーザルのロケーションを返却する。

HTTP/1.1 200 OK
Opt: "http://www.w3.org/TR/P3P/"; ns='12-'
12-propID: "md5:aaaaaa"
12-proposal: "http://www.store1.com/P3PProposal1.RDF"
Opt: "http://www.w3.org/TR/P3P/"; ns='4253-'
4253-propID: "md5:ababab"
4253-proposal: "http://www.store1.com/P3PProposal2.RDF"
...
Content-Type: text/html
Content-Length: 110
<html><body>
<h1>Welcome to Cool Catalogue</h1>
<p>We'd love to have the following information to
   customize our online catalogue to you.</p>
<form method="POST" action="http://www.CoolCatalog.com/cgi-bin">
<p><input type="submit" value="Submit" name="B1">
<input type="reset" value="Reset" name="B2">
First Name <input type="text" name="User.Name.First" size="20" value="Your First Name Here">
Second Name <input type="text" name="User.Name.Second" size="20" value="Your Second Name Here">
</form>

</body>
</html>

3. 利用者は返却されたデータと適切なpropIDを返却することにより同意する。 abstract data elements(抽出されたデータ項目)([BASEDATA]を参照)による同意は サービスとの交流が続いて起こっているかのように見せかけられる。

M-POST store1.com/catalog/page1.html HTTP/1.1
Host: store1.com
Man: "http://www.w3.org/TR/WD-P3P/" ns='23-'
23-propID: "md5:aaaaaa"
23-status: "OK"
23-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">
23-data: </TXD>
Man: "http://www.w3.org/TR/WD-P3P/" ns='78-'
78-propID: "md5:ababab"
78-status: "OK"
78-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">
78-data: <DATA:REF name="User.Name.First" value="Sheila">
78-data: <DATA:REF name="User.Name.Second" value="Doherty">
78-data:
...
[Content]

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ページの為に以下のステートメントを作成。

cookieを使用し、利用者の性別と、(任意に)利用者が興味のある洋服のタイプや研究と製品の向上の為に カタログの入り口ページをカスタマイズするかどうかの、利用者の好みについての情報を収集する。 我々は、この情報をidentifiable form(確認可能なフォーム)内において使用しない。

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

我々は、利用者から得た情報に対してのアクセス権を与えない、しかし我々は情報を確実に保持し、そして プライバシーポリシーに関するページ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 (3)
Assurance: PrivacySeal.org
Other disclosures: Change agreement, retention (0,1)

We collect:
    Cookies_
    User.Gender
    Form.Data_  (category=8, optional)
For purpose: Customization of the site to individuals, research and development (2.3)
Identifiable use: No (0)
Recipients: Only ourselves and our agents (0)
Consequence: A site with clothes you would appreciate

We collect:
     ClickStream.Server_
     HTTP.UserAgent_
For purpose: Web site and system administration, research and development (1,3)
Recipients: Only ourselves and our agents(0)

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="3" other="0,1"/>
  <USES>
  <STATEMENT VOC:purp="2,3" VOC:recpnt="0" VOC:id="0"
   consq="a site with clothes you would appreciate">
     <DATA:REF name="Cookies_" source="0"/>
     <DATA:REF name="Form.Data_" VOC:category="8" optional="1" source="0"/>
     <DATA:REF name="User.Gender" source="1"/>
  </STATEMENT>
  </USES>
  <USES>
  <STATEMENT VOC:purp="1,3" VOC:recpnt="0" VOC:id="0">
    <DATA:REF name="ClickStream.Server_" source="0"/>
    <DATA:REF name="HTTP.UserAgent_" source="0"/>
  </STATEMENT>
  </USES>
</PROP>
</RDF:RDF>

4.2 Proposals(プロポーザル)

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

4.2.1 The PROP element

<PROP>
1つかそれ以上のstatementを含む。各ステートメントはデータエレメントに適用されるような情報開示を含む。
postURI
情報が送られるURI。
entity (mandatory attribute)
プロポーザル内にあるプライバシープラクティスの表現を作成する合法的な実体と結びつけることが出来る URIが参照するドメイン名やパス。
agrexp
同意が期限切れになる日付。デフォルトは6ヶ月 同意の期間終了は、同意に基づいてユーザエージェントが サービスにデータを転送することができる最後の日である。 サービスは、同意に基づいて 集められたデータに対し、 期限切れの後でさえ同意の制限を受ける。プロポーザルは、HTTPヘッダの"EXPIRES"に示された時間後に期限切れとなる。 デフォルトは1時間
xmlns="http://www.w3.org/TR/WD-P3P/syntax"
[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"` 
[" agrexp=" `"` datetime `"`] ;default is six months
" entity=" quoted-URI  
[" postURI=" quoted-URI]
">"
1*statement-block 
disclosure
[assurance]
1*realm
`</PROP>`

The entity attribute

entity(実体)の属性は、プロポーザル内にあるプライバシープラクティスの表現を作成する合法的な 実体と結びつけることが出来るドメイン名やパスを参照する。デジタル署名がない場合に、このentityはドメイン名 の登録所によって提供されている権威のない証明メカニズムとドメイン名に対して責任ががある団体のレコードによって 合法的な実体(legal entity)を追跡する唯一のメカニズムです。その上、entity(実体)属性は "root"ドメインとして使用され、"root"ドメインはレルム(realm)属性として認証が使用されない時 にレルム(realm)内のURIsと一致しなければならない(domain-match [KRISTOL])。

4.2.2 The REALM element(レルム)

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

注意:REALM(レルム)要素の複合発生によって特定された複合レルムができることがある。

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

ユーザーエージェントはどの同意が同意に至ったか、またそれに対応する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 VOC:DISCLOSURE element

<VOC:DISCLOSURE>
サービスのアクセス能力に関する簡単な情報開示で、entityがすでに集められたデータの同意の変更や データの保持方法についての情報開示を行うかどうかに関するバイナリ値。
discURI (mandatory attribute)
プロポーザルの分かりやすいプライバシーステートメントのURL。これは質問等がある場合にどのようにしてサービスに連絡を とれば良いかという情報を含まなければならない。
access
識別情報、住所に関する質問やサービスプロバイダへの考慮事項を個人が参照できる能力
other
サイトはそのdiscURIで知られる同意の変更や保持に関してそのポリシーを作るのか?
xmlns:VOC="http://www.w3.org/TR/WD-P3P/vocab"
The values of [4-6] are provided for reference only. The normative specification is in the harmonized vocabulary document.
[4]
disclosure
=
"<VOC:DISCLOSURE"
" discURI=" quoted-URI
" access=" `"` access-disclosure `"`
[" other=" `"` 
   other-disclosure *("," other-disclosure) `"`]
"/>"
[5]
access-disclosure
=
"0" | ; Identifiable Data is Not Used(認識可能なデータは使用されていない)
"1" | ; Identifiable Contact Information(認識可能なコンタクト情報)
"2" | ; Other Identifiable Information(その他の認識可能な情報)
"3" | ; None(なし)
[6]
other-disclosure
=
"0" | ; change agreement(同意の変更)
"1"   ; retention(保持)

4.2.4 The ASSURANCE element

<ASSURANCE>
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の短い原文通りの説明
xmlns="http://www.w3.org/TR/WD-P3P/syntax"
[7]
assurance
=
"<ASSURANCE"
 " service=" quoted-URI
 [" text=" quoted-string]
 [" image=" quoted-URI
 [" width=" `"` number `"`]
 [" height=" `"` number `"`]
 [" alt=" quoted-string] ]
"/>"

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

4.3 Data Transmission(データの送信)

クライントはヘッダ内にXML/RDFメッセージを伝えることにより、特定の同意を参照したデータをサービス(Section 3.3.2を参照)に送る。 またサービスは、同じようなメッセージを利用者のデータレポジトリに保存してあるデータ要求の為にユーザーエージェントへ送ることが出来る。

<TXD>
propIDにより参照された同意をもとに返却されたデータブロックを示す。
xmlns="http://www.w3.org/TR/WD-P3P/syntax.html"
[8]
TXD-msg
=
(`<RDF:RDF xmlns:RDF="http://www.w3.org/TR/WD-rdf-syntax">`
  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>
データエレメントに適用されるデータプラクティス
VOC:purp (mandatory attribute)
Webに適切なデータ生成の目的
VOC:recpnt (mandatory attribute)
データが配布されるかもしれないサービスプロバイダーやエージェントを越えたorganizational areaとドメイン。
VOC:id (mandatory attribute)
個人的な身元確認可能な方法で使用されるデータ。他のソースからのあなたに関する 身元確認可能な情報とのリンクを含む。
action
データ読み込み又は読み込みと書き込み (規定値はデータ読み込み)
xmlns="http://www.w3.org/TR/WD-P3P/syntax"
xmlns:VOC="http://www.w3.org/TR/WD-P3P/vocab"
[10]
statement-block
"<USES>"
"<STATEMENT" 
[" action=" `"` action `"`]
" VOC:purp=" `"` purpose *("," purpose) `"`
" VOC:recpnt=" `"` recipients *("," recipients) `"`
" VOC:id=" yesno
[" consq=" quoted-string]
">"
*(data-reference)
"</STATEMENT>"
"</USES>"

[11]
action
=
("r" | "rw") ; r=read, rw=read&write, default is read

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

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

[14]
id
=
yesno

[15]
yesno
=
"1" | "0" ; 1 stands for "Yes", 0 for "No"

注意: もともとサービスにこれらのデフォルトに対抗して、これらのプラクティスに正直であるように強制するために かなり保守的なデフォルト値は("0")となっていた。しかし、これは意味相互運用性(semantic interoperability) に結びつく可能性があった。サービスはある属性が任意であると思い、ユーザがそれらに(?)暗黙の/デフォルトの 意味に基づいた情報をあたえる。もっと良いアプローチは、デフォルト値をかなり高く設定することである。 (すなわち、recipient属性が含まれていない場合は、データが公共に分配されていることを意味する) しかし、我々は、任意属性と規定の意味論を持った要求されている属性の混同を避けるために規定値を提供しない立場 をとりつつある。

The action attribute

サービスは利用者のレポジトリに情報が書きこまれたかどうか問う権限がある。 P3Pエージェントが以下の要求をプロポーザルの一部として受け取ったと考えてください:

<STATEMENT action="r" VOC:purp="2" VOC:recpnt="0" VOC:id="0"/>
    <DATA:REF name="User.Name.First" source="1"/>
</STATEMENT>
<STATEMENT ="rw" VOC:purp="2" VOC:recpnt="0" VOC:id="0">
    <DATA:REF name="FineShoes.shoesize"
     xmlns:DATA="http://www.FineShoes.com/Schema1.0" source="1"/>
</STATEMENT>

利用者はこのプロポーザルに対して同意したかどうか尋ねられ、User.Name.Firstが自動的に 記入(利用者は以前に入力していたと仮定する)されていて、FineShoes.shoesizeの部分は 無記入のフォームのような物を見せられる。利用者は無記入の欄を記入しTXDを使用して データを転送するだろう。

利用者は以下のものを転送する:
43-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">
43-data: <DATA:REF name="User.Name.First" value="Sheila"/>
43-data: <DATA:REF name="User.Name.Second" value="Doherty"/>
43-data: <DATA:REF name="FineShoes.Shoesize" xmlns:DATA="http://www.FineShoes.com/Schema1.0" value="7"/>
</TXD>

データエレメントが"rw"属性になっていて、利用者によって新規の値が提供された場合、 ユーザーエージェントはデータレポジトリへの書きこみを試みなければならない。 書きこみが失敗した場合、ユーザーエージェントは適切なレスポンスコードを返却しなければならない。 この自動書き込み機能は、サービスがユーザーエージェントに対し情報を再転送する必要性を省く。 しかし、サービスは何時でもTXDメッセージを送ることが出来る。例えば、利用者は靴のサイズを "7"として提供したけれども、サービスはヨーロッパでの靴のサイズに変換して書き込みたい。

4.4.2 The DATA:REF element

<DATA:REF>
転送または導入されるデータに関する説明
name (mandatory attribute)
data element/setの名前を意味する文字列である。 Setとelementは、セットされたnameの後のドット(.)の存在により文法的に識別される。 例えば、セットUser.Homeを示す場合、文字列はUser.Home.になる。 便利なことに、data sets/elementsの名前は、ASCIIコードの範囲内において大文字/小文字の区別をしない。 (そのため、User.Home.USER.HOMEuser.home.と同等である) 付け加えて、nameのなかにはドット(.)の直後に数字を入れてはならない。 最後に、下線("_")が最後につくnameには特別な意味がある。(それらはabstract elementsと呼ばれる。Section 3の[BASEDATA]を参照してください。)
value
name属性に指定されるデータエレメントの実際の値を意味する文字列である。 データエレメント要求の場合は、value属性はない。
optional
"0" または"1"である。"0"はデータエレメントが必要だということを示す。 "1"は、データエレメントが必要でないことを示す。規定値は"0"。 optional属性はプロポーザルの中でのみ使用される。
source (mandatory attribute)
データ転送のメカニズムを特定する。
VOC:category
データエレメントのcategories (カテゴリ)を意味する文字列。
以下の7つの属性は、新規のデータエレメントやセット(P3P1.0 ベース [BASEDATA]には定義されていない) が参照された時のみに使用される。
type
データエレメント/セットのタイプを意味する文字列。
typeschema
type属性で特定されたタイプが規定されるデータスキーマを意味するURI
template
一致するデータエレメントがタイプの定義の一部のみであるか特定する。 "1"にセットすると、そのデータエレメントはタイプの定義であることを意味する。 そして、実際には関連する値のデータエレメントを意味しない。規定値は"0"。
short
データエレメント/セットの短縮名を意味する文字列。127文字以内の[UTF-8]文字。
long
データエレメント/セットを説明する長い文字列を意味する。1023文字以内の[UTF-8]文字。
size
データエレメントを保存するのに必要な[UTF-8]文字の最大数を意味する。 規定値の"0"はデータエレメントを任意の大きさにする事が出来ることを示す。
xmlns:DATA
データスキーマ名やnameの属する所で特定されたデータエレメント/セットを意味するURI。 規定のDATA namespaceはPROPエレメントの中で宣言される。しかし、それはDATA:REFエレメント 内でのローカルなnamespace宣言を使用し、オーバーライドされることが可能です。

xmlns="http://www.w3.org/TR/WD-P3P/syntax"
xmlns:VOC="http://www.w3.org/TR/WD-P3P/basedata"

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

[17]
source
=
"0" | ; service
"1" | ; agent
"2" | ; matched-form
"3"   ; extension

[18]
categories
=
`"` *(number ",") number `"`

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

<DATA:REF name="User.Home.Postal.City" source="2"/>
<DATA:REF name="User.Home.Telecom.Phone." optional="1" source="2"/>
<DATA:REF name="User.Business." source="2"/>

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

<DATA:REF name="User.Home.Postal.City" value="Cambridge"/>
<DATA:REF name="User.Home.Telecom.Phone.IntCode" value="1"/>
<DATA:REF name="User.Home.Telecom.Phone.LocCode" value="617"/>
<DATA:REF name="User.Business.Postal.Street" value="254 Windsor St."/>
<DATA:REF name="User.Business.Postal.City" value="Cambridge"/>
... (the other values of User.Business.) ...

The VOC:category attribute(カテゴリ属性)

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

Categoryの中のデータエレメントのメンバーシップは、一般的にばらばら(disjoint)である。ほとんどのデータエレメントは、1つのcategoryに属さなければならないが、必要であればそれらは複数のcategoryに属する場合もある。さらに、データセットは、エレメントが属する全てのcategoryに属する。 基本データエレメントは全てP3P仕様書のデフォルトcategoryに割り当てられている。サービスが新しいデータエレメントをproposeする時、そのプロポーザルは、デフォルトcategoryかエレメント用のcategoryを含んでいなければならないが、ユーザやユーザエージェントは、category割り当てに対する最終的な制御権を持っている。

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

"0" ; Physical Contact Information
"1" ; Online Contact Information
"2" ; Unique Identifiers
"3" ; Financial Account Identifiers
"4" ; Computer Information
"5" ; Navigation and Click-stream Data
"6" ; Transaction Data
"7" ; Preference Data
"8" ; Demographic and SocioEconomic Data
"9" ; Content

categoryに関する詳しい説明はP3P Harmonized Vocabulary Specificationを参照して下さい。

The source attribute(ソース属性)

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

0: service(サービス)
サービスはP3Pユーザーエージェントがアクティブであることを要求しない方法を使用して データを要求/収集する。(例えば、スタンダードなHTMLフォーム。データはスタンダードなHTTPヘッダ から収集される。暗示されたデータ等)そのためサービスは利用者に対するいかなるプロンプトの提示について のフルコントロールを保持する。しかし、サービスは利用者のデータレポジトリを利用できない。
1: agent(エージェント)
P3Pユーザーエージェントは利用者に、データと(または)データレポジトリからデータについて促さなければならない。 エージェントはHTTPヘッダの拡張機構またはpost機構(postURIが指定されている時)を使用してサービスにデータを転送しなければならない。 サービスは、レポジトリのデータが利用できない場合、どのようにして利用者にプロンプトするかの権限を持っていない。 ユーザーエージェントは、エレメント名を使用するのではなく、short and/or long display 名をプロンプト内に含むべきである。
2: matched-form
サービスは、フォームのフィールド名がプロポーザル内のデータ参照と一致するHTMLのコンテントのフォームを通して データを要求する。そのため、エージェントは任意に利用者レポジトリからのデータでフォームを埋めるだろう。 この方法を使用するとき、サービスは利用者へのプロンプトの提示に関しフルコントロールを保持するが、ユーザーエージェント が自動記入(auto-fill)をサポートしていたら、利用者レポジトリを利用する。ユーザーエージェントがauto-fillをサポートしていない 場合(または、要求されたデータがレポジトリに保存されていない場合)、一般的なHTMLフォームが表示される。

またサービスは、ここで定義されていない他の機構(electronic commerce wallet(電子財布)など)を使用してデータを転送したいかもしれない。 その場合、サービスはその機構を使用してデータが収集される事を示すためにsource="3"を明記しなければならない。

DATA:REF エレメントは常にデータスキーマの定義内にある時を除いて、source attribute(ソース属性) を一つだけ含まなければならない。属性が完全に省かれた場合、属性は一つまたは複数の値を取るだろう。

The optional attribute

サービスはデータ要求が任意である事を示すために任意の属性を使用するだろう。 ユーザーエージェントは利用者のプリファレンスに従って、任意の属性を送信または無視するだろう。

注意:P3Pは確かなデータプラクティスが任意であるか特定するための機構を含んでいない。 もしサービスが利用者にデータプラクティスの選択権を与えたいならば(例えば、データがマーケティングに使用されるかどうか)、 利用者が選択できる複合代替プロポーザルを提供することによって選択権を与えることが出来る。

4.4.3 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の場合、空の文字列はタイプスキーマがxmlns:DATAの属性値と一致する事を意味する。

例えば、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:purp="4" VOC:recpnt="0" VOC:id="0">
 <DATA:REF name="car.model" type="Text" short="Model" 
   VOC:category="7" size="63"/>
 <DATA:REF name="car.color" type="Text" short="Color" 
   VOC:category="7" size="63"/>
 <DATA:REF name="car.built.year" type="Number" short="Construction Year" 
   VOC:category="7" size="63"/>
 <DATA:REF name="car.built.where." type="Postal."  short="Construction Place" 
   VOC:category="7" size="63"/>
 <DATA:REF name="bike." type="car." 
   typeschema="http://www.HyperSpeed.com/models-schema"/>
</USES></STATEMENT></PROP>

注意:データセットが作られる度に、必然的にデータセットはタイプ(上記のcar.のように)として使用される。 しかし、何らかの状況で、利用者のレポジトリ内で特定のエレメントを作成すること無しに、タイプを定義したいと望むだろう。 これは、<DATA:REF>内でtemplate属性を使用することにより成し遂げられることが出来る。 値を"yes"、template="1" (規定値は "0")に設定すると、一致するデータエレメントはタイプの定義の一部のみである事を意味する。 そして、それは実際には提携された値のデータエレメントを示していない。 例えば、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:purp="4" VOC:recpnt="0" VOC:id="0">
 <DATA:REF name="GenericModel.model" type="Text" short="Model" template="1" 
   VOC:category="7" size="63"/>
 <DATA:REF name="GenericModel.color" type="Text" short="Color" template="1" 
   VOC:category="7" size="63"/>
 <DATA:REF name="GenericModel.built.year" type="Number" short="Construction Year" 
   template="1" VOC:category="7" size="63"/>
 <DATA:REF name="GenericModel.built.where." type="Postal." 
   short="Construction Place" template="1" 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=0 や、 利用者のレポジトリにデータを保存しない拡張 機構の使用)に制限を設けない限り、ユーザーエージェントは利用者が新規スキーマのエレメントを書きこんだ後に、自動的にレポジトリに それらのエレメントを保存する事を理解していなければならない。 いくつかの実装はセンシティブなデータの保存に対しての適切なセキュリティーを設けていない利用者レポジトリを持っているものも ある。


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. 8 Februay 1999.
[DSIG]
Y. Chu, P. DesAutels, B. LaMacchia, P. Lipp (Eds.). "DSig 1.0 Signature Labels Specification: Using PICS 1.1 Labels for Making Signed Assertions," World Wide Web Consortium, Recommendation. 03-April-1998.
[RDF]
O. Lassila, R. Swick (Eds.). "Resource Description Framework (RDF) Model and Syntax Specification."  World Wide Web Consortium, Proposed Recommendation. 5 January 1999.
[HARMV]
J. Reagle (Ed.). "P3P Harmonized Vocabulary Specification,"  World Wide Web Consortium, Working Draft. 8 February 1999.
[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.
[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.
[HTTP-EXT]
H. Frystyk, P. Leach, S. Lawrence. "HTTP Extensions" (draft-frystyk-http-extensions-03.txt). Jan 1999. IETF Internet Draft.
[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.
[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." 1997. (Work in progress; see updates to 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, Working Draft. 16 September 1998.

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 から <b> 個のエレメント
(*5<element> は0〜5個のエレメントを意味する)
*element
0個以上のエレメント
(*<element> 無限のエレメントを意味する)
[element]
任意のエレメント、*1(element)と同等
([element] は 0 または 1 エレメントを意味する)
"string" or 'string'
””内に与えられた文字列matchingと同等

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

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

Appendix 3: Working Group Contributors (標準非準拠)

Lorrie Cranor AT&T
Philip DesAutels Matchlogic
Melissa Dunn Microsoft
Daniel Jaye Engage Technologies
Steve Lucas (Chair) Matchlogic
Massimo Marchiori (Editor)  W3C
Maclen Marvit Narrowline
Max Metral Firefly Network Inc.
Paul Perry Firefly Network Inc
Martin Presler-Marshall IBM
Joseph Reagle (Project Manager) W3C
Drummond Reed Intermind