A P3P Preference Exchange Language (APPEL), W3C Working Draft, April 20, 2000

本文書は、P3Pエージェントにおいて、 P3Pプライバシーポリシーに関するプリファレンスの集合を説明するための言語として、 P3P1.0 仕様書を補完するものである。この言語を使うことにより、ユーザはP3P対応のWebサイトからの、マシンが読むことができるプライバシーポリシーの受領に関して、ユーザのユーザエージェントが自動、または半自動で判断できるようになるプリファレンス-規則 (規則セットと呼ばれる) といったセットでユーザのプリファレンスを表現することができる。

本文書の位置付け

この章では、発行時における本文書の位置付けを説明する。他の文書がこの文書にとって代わる可能性もある。本文書のシリーズの最新の位置付けは、W3Cで決められる。

本書は、P3Pプリファレンスの置換言語のワーキンググループが W3Cメンバと他の関連団体とともにレビューを行うためのW3Cワーキングドラフトである。本文書は、P3P活動の一環として作成され、最終的にはW3Cの勧告となることを目指す。ワーキングドラフト文書であるため、この仕様書はいつでも改版、置換、または他の文書により陳腐化するかもしれない。従って、W3Cのワーキングドラフトを "進行中の作業"ではないとして参考文献資料、その他として参照することは不適切である。現在のW3Cワーキングドラフトは、 http://www.w3.org/TR/を参照のこと。

このワーキンググループは、 P3Pプリファレンスの置換言語を開発するための幾つかの異なったアプローチについて考え、ひとつのアプローチを文書で取り決め、フィードバックを行う。このグループは、全般的な-目的言語 (例としては、 XML、またはRDF問い合わせ言語)を含む他のアプローチについても考える。仕様書にフィードバックするならば、実験的な実装とプロトタイプの開発を奨励する。しかしながら、このワーキンググループは、本文書の将来的な版を変更させうる影響のあるような、早期の実装を許すものではない。

APPEL言語の本バージョンは、正しい規則を当てにしている。ワーキンググループは特に、規則セットのマージと編集のより良いサポートに関して、どのようにしてこの機構を改良するか、フィードバックを勧める。どうか、このドラフト文書の例はP3P仕様書の 2000年4月4日版が基本であることに注意されたし。そして、このような例は、 P3P仕様書の出版によって、改定すべきである。

このドラフト文書はW3CとそのメンバーによりW3Cの手順に従って考案される。これは、P3Pの実装、受領、採用に影響する問題を担当するW3Cメンバシップとスタッフに対するコメントを一般から受ける目的で公開されている。

1. 序論

本文書は、P3Pエージェントにおいて、 P3Pプライバシーポリシーに関するプリファレンスの集合を描写する言語を規定する。この言語を使うことにより、ユーザはP3P対応のWebサイトからの、マシンが読むことができるプライバシーポリシーの受領に関して、ユーザのユーザエージェントが自動、または半自動で判断できるようになるプリファレンス-規則 (規則セットと呼ばれる) といったセットでユーザのプリファレンスを表現することができる。

注意:この言語は、伝送形式を意図している; 個々の実装では、この言語でかかれた仕様書を読み書きできるようにしなければならないが、この形式を内部的に使う必要はない。

この言語は、P3P1.0仕様書を補足する。基礎となる論理の大部分はPICSRules に基づいている。ゆくゆくはこれが単にXML (XML-data、規則、照会言語のアプリケーションとなることを期待している。

1.1 P3Pの基礎

ポリシーは、（webブラウザ、ブラウザプラグイン、プロキシサーバのような）ユーザエージェントにより自動的に解析される。そして、ユーザが定義したプライバシープリファレンスセットと比較される。これらのプリファレンスに依存して、ユーザエージェントは、ユーザにシンプルな情報を表示したり、プロンプトを出したり、その他の動作をするかもしれない。

基本的なP3Pの対話について、以下のような処理が考えられる:

1.2 P3Pプリファレンス交換言語(Preference Exchange Language)の最終目的

まずはじめに、この言語は、他の団体が作ったプリファレンス規則セットをインポートすることをユーザに許し、それ自体の規則セットのファイルを複数のユーザエージェント間で転送するために使われる。ユーザエージェントを実装する人はまた、ユーザプリファレンスをエンコードして、そのユーザエージェントの意志決定をする部品としてのサーバのような規則評価器で使うためにこの言語（またはいくつかの簡単な派生版として）を選ぶかもしれない。

1.3 必要条件

言語の原形実装の普及を早めるために、ワーキンググループは基本のプライバシープリファレンスのみを表現するために設計されたレベル1仕様書を最初にリリースし、その後、上記の残りの必要条件を実装するレベル2仕様書を準備することを決めた。特に、,APPELレベル1は必要条件を以下に限定する。

本文書は以降で、このようにして簡略化したバージョンのAPPEL（レベル1仕様書として参照された）について述べる。より詳細な全APPEL構文に関する拡張子のリストについては、付録Aを参照のこと。APPEL構文は以降、レベル2仕様書そして参照される。

1.4 APPELとP3Pプライバシーポリシー

簡単な参照として、以下の図はXMLP3P1.0ポリシーの要素と属性のほとんどを表しているポリシーの例を示している。個々の要素とその使用についての詳細は、P3P1.0仕様書の3 ポリシー構文と意味論を参照されたし。

1.5 定義

さらに、この仕様書は各特定の必要条件の意味を特定する為にRFC 2119 [RFC2119]で使用されているのと同じことばを使用する。そのことばとは：

2. 全般的な作用と意味論

2.1 規則評価器（エバリュエーター）への入出力

規則の範囲は<APPEL:ルール>要素のオープン、クローズにより決定される。評価器はこの規則を起こしたポリシーのコピーと同様に、上記の証拠を基本としてできた規則の挙動 (挙動属性で規定されているように)を返す。特に、この規則で照合されていないオプション的要素が含まれていない場合は、この規則を起こしたポリシーは証拠で見つけたオリジナルのポリシーと必ずしも一致するわけではない。さらに、規則評価器は任意に、説明文字列 (ユーザ表示にあわせた)、ペルソナの名前、および/またはfiredした規則を返すことがある。

アプリケーションは標準出力を以下のように解釈すべきである:

2.2 規則の処理と評価

2.2.1 規則の処理

規則セットの各規則は表示される順番に評価される。規則がtrueと評価されたら、対応する挙動が返され、規則の評価は終了する。ポリシーが受領されない場合にさらに情報を提供したがっているユーザエージェントは、（なぜそれが"拒否"されたかの理由を全てリストアップするようなこと）そのような情報をユーザに与えるためにさらなる評価を必要とするかもしれない。

規則セットは常にfireする規則があるように記述されるべきである。規則評価器は、規則セットなしで、空の規則セットで、どのルールもfireしない場合にはエラーを返すべきである。エラーが返却された場合どうするかを決定するのは callingプログラム次第であるが、calling プログラムはエラーを"受領"するように処理すべきでない。

2.2.2 表現

APPELの表現は有効な証拠に対して照合することによって、正、誤の評価ができるXML要素によって表される。表現はいつも以下で構成されている。(例えば、図2.1 を参照のこと):

APPELはすべての値を単純な文字列として扱うが、属性-表現は文字列または数値をとるかもしれない。APPELレベル1は属性-表現の一様な操作のみをサポートしている (APPELレベル2は数値照合のための"<"less-thanや">"greater-thanなどの比較操作を追加的に提供する。

APPELは、多くの人気のあるOS shellに見られるワイルドカードメタ文字"*"のシンプルセットをサポートする。属性の表現は <DATA name="ユーザ.*"> ("ユーザ" データセットからのあらゆる要素) などの値の範囲を照合するためにこのメタ文字を使用することができる。詳細は5.4.1 属性の表現および5.4.2 規則的な表現メタ文字を参照のこと

2.2.3 規則の評価

複数の属性表現および/または組み込まれた表現が一つの表現の範囲内に置かれるとき、全ての表現は一つの証拠の範囲内で照合される。規則が<PURPOSE><develop/></PURPOSE>と<RECIPIENT><ours/></RECIPIENT>表現の両方を含む<STATEMENT>表現を組み込む場合、P3Pポリシーが、ローカルな受領者と研究開発を宣言するステートメントを含む時、その表現は true を評価するのみである。

表現内の属性の表現は暗黙に互いにANDされているが、特別なconnective(連結詞)属性は組み込まれた表現の意味論照合を管理するために使用される。APPEL はそういった連結詞4つをサポートする:or, and, or-exact, と and-exact。もし連結詞が与えられていなければ、必要なand-exactへのAPPEL デフォルトは照合する: 証拠の要素が規則に与えられた連結詞と一致した時のみ、照合が起こる。

属性の照合と組み込まれた表現については5.4 照合で詳細を述べている。

3. 単純なシナリオの例

ここでは、ユーザのプレファレンスの簡単なテキスト記載(文句無しに単純な)、含まれる要素とそれらの許可された値の概要表を示す。最後に、該当するAPPEL暗号化の例を挙げる。本文書に参照しやすいようにという配慮から書かれている表中のライン番号は、実際の暗号の一部ではないので注意されたし。

3.1 ユーザプリファレンス

3.2 表による概要

属性/要素とその値のリストがあるが、挙動を探すためのルックアップ表としてその表を使用しないでください。その代わり、表照合で値が参照するまで、列ごとにその表をみていかなければならない。なぜなら、各列はこの規則セットで順序づけられた規則を表しているからである。セルにはワイルドカードシンボルの"*"が付いているものと何もついてないものがあることに注意されたし。APPEL は参照されない属性と参照されるがワイルドカードのみを含む属性を見分ける。前者の場合、ポリシーに属性が含まれる含まれないに関わらず、ユーザは本当に属性に注意を払わない。後者の場合、ユーザは属性値に注意を払うかもしれないが、少なくともアトリビュートが何かの値を持つことを期待する。詳細については、5.4.2 規則的な表現メタ文字を参照のこと。以下に示す我々の例の3列では、ユーザは収集したclickstream データの目的について注意を払わない(そのためこの表では空欄), しかし、ある種の係争解決-情報を要求する (ワイルドカードの"*"を使って表示)

3.3 APPEL規則セット

リクエストURLの明確な照合を使用して、2番目の規則はポリシーを受領する場合、www.my-bank.comに接続していると、リクエストされたデータは銀行とエージェントへ配布されるだけである。

次に、"受領"規則は同一だとみなし得ないclickstream データおよび/またはユーザエージェント情報 (ブラウザバージョンやOSなど)が収集されているかどうかを見る為に、確認をし、もし、係争解決情報受領が有効であれば、受領する。

"通知"規則は売買目的ではないユーザ名に対するあらゆるリクエストを照合し、最終的にはユーザにサイトが受領可能な状況でユーザ名を収集したがっているという事を即座に通知し始める。

もし、他の規則が照合しなければ、上記の規則がカバーしているポリシーについてユーザに（慎重に）警告し、劣化した表現"APPEL:OTHERWISE"を要約している"警告"-規則はfireするだろう。

000: <APPEL:RULESET xmlns:APPEL="http://www.w3.org/2000/APPEL"
001:                crtdby="W3C" crtdon="13-Nov-1999 09:12:32 GMT">
002:
003:   <APPEL:RULE behavior="reject" 
004:      description="Service collects personal
005:                   data for 3rd parties">  
006:     <POLICY APPEL:connective="and">
007:       <STATEMENT APPEL:connective="and">
008:         <DATA-GROUP APPEL:connective="or">
009:             <DATA category="physical"/>
010:             <DATA category="demographic"/>
011:             <DATA category="uniqueid"/>
012:         </DATA-GROUP>
013:         <RECIPIENT APPEL:connective="or">
014:           <same/><other/><public/><delivery/><unrelated/>
015:         <RECIPIENT/>
016:       </STATEMENT>
017:     </POLICY>
018:   </APPEL:RULE>
019:
020:   <APPEL:RULE behavior="accept" 
021:      description="My Bank collects data only for itself 
022:                   and its agents">  
023:     <APPEL:REQUEST-GROUP>
024:       <APPEL:REQUEST uri="http://www.my-bank.com/*"/>
025:     </APPEL:REQUEST-GROUP>
026:     <POLICY APPEL:connective="and">
027:       <STATEMENT APPEL:connective="and">
028:         <RECIPIENT APPEL:connective="or-exact">
029:           <ours/>
030:         <RECIPIENT/>
031:       </STATEMENT>
032:     </POLICY>
033:   </APPEL:RULE>
034:
035:   <APPEL:RULE behavior="accept"
036:      description="Service only collects clickstream data">  
037:     <POLICY APPEL:connective="and">
038:       <STATEMENT APPEL:connective="and"> 
039:         <DATA-GROUP APPEL:connective="or-exact">
040:           <DATA name="Dynamic.HTTP.UserAgent"/>
041:           <DATA name="Dynamic.ClickStream.Server"/>
042:         </DATA-GROUP>
043:       </STATEMENT>
044:       <DISPUTES-GROUP>
045:         < DISPUTES service="*"/>      
046:       </DISPUTES-GROUP>
047:     </POLICY>
048:   </APPEL:RULE>
049:
050:   <APPEL:RULE behavior="inform" 
051:      description="Service only collects your name
052:                   for non-marketing purposes (assurance   
053:                   from PrivacyProtect and TrustUs)">   
054:     <POLICY APPEL:connective="and">
055:       <STATEMENT APPEL:connective="and">
056:         <PURPOSE APPEL:connective="or-exact">
057:              <current/><admin/><custom/><develop/>
058:         </PURPOSE>
059:         <DATA-GROUP APPEL:connective="or-exact">
060:             <DATA name="User.Name.*"/>
061:         </DATA-GROUP>
062:       </STATEMENT>
063:       <DISPUTES-GROUP APPEL:connective="and">
064:         <DISPUTES service="http://www.privacyprotect.com"/>
065:         <DISPUTES service="http://www.trustus.org"/>  
066:       </DISPUTES-GROUP>
067:     </POLICY>
068:   </APPEL:RULE>
069:
070:   <APPEL:RULE behavior="warn"
071:      description="Suspicious Policy. Beware!"> 
072:     <APPEL:OTHERWISE/>
073:   </APPEL:RULE>
074:      
075: </APPEL:RULESET>

3.4 例の説明

Lines	説明
000 - 075	APPEL規則セット。APPEL規則セット。単一のAPPEL規則セット(すなわち、`<APPEL:RULESET>`タグに囲まれている順序づけられた規則のセット) は普通、ユーザエージェントにインストールされている。実装はシステムの現在ユーザ、または、現在のブラウジングセッション中にユーザが使用したいと思うペルソナに合わせて異なる規則セットを維持するために提供するかもしれない。`<APPEL:RULESET>`要素は著者や作成の日付などの追加情報でタグ付けすることができる: [1] ruleset = '<APPEL:RULESET xmlns="http://www.w3.org/2000/APPEL" ' attributes '>' rseq '</APPEL:RULESET>' [2] rseq = 1*rule
003 - 018	"拒否"規則。APPELは4種類の規則の挙動を提供する。:"受領(accept)", "拒否(reject)", "通知(inform)"そして "警告(warn)"。各規則は表現のセットや劣化した表現`<APPEL:OTHERWISE>`に囲まれた`<APPEL:RULE>`要素で構成されている。 [3] rule = '<APPEL:RULE behavior="' behavior '"' attributes '>' body '</APPEL:RULE>' [5] body = top-expression \| '<APPEL:OTHERWISE/>' [6] behavior = 'accept' \| 'reject' \| 'inform' \| 'warn' 各規則は属性のセットよって増加することができる。我々の例では、規則がfireすべきである場合の人間が読むことのできる("サービスはclickstream データ"のみを集める)説明を提供する記載フィールドを使用する。(これは、データ転送やプロンプト中にユーザエージェントによって表示されるか、目的をデバッグするために使用される) [4] attributes = [' persona=' quoted-string] [' crtby=' quoted-string] [' crton="' datetime '"'] [' description=' quoted-string]
006 - 017	照合するためのP3Pプライバシーポリシー。ほとんどのAPPEL規則には、`<RULE>`要素内に照合する表現があるように、P3Pプライバシーポリシーがある。ワイルドカード ("") は値の範囲を照合するのに使用されるが、規則が照合すべき要素および属性値はポリシーで簡単に述べられている。属性もしくは要素を完全に省略することでサービスが提供しているポリシーから属性/要素を省略することができる。(もしくはあらゆる値を使って組み込むこともできる。). [7] top-expression = policy \| request [policy] [8] policy = <[P3P10] policy (optionally with embedded connectives)> [9] request-group = '<APPEL:REQUEST-GROUP ' [connective] '>' 1request '</APPEL:REQUEST-GROUP>' [10] request = '<APPEL:REQUEST uri="' [URI] as per RFC 2396 '"/>'
007 - 016	STATEMENT(ステートメント) 要素照合。もし、サービスが第三機関(`<same/>`, `<other/>`"または`<published/>`を照合する`<RECIPIENT>`)へ配布される個人データ(カテゴリ`physical`, `demographic`または`uniqueid`の`<DATA>`要素)について問い合わせたら、"拒否"規則は解除すべきである (すなわちポリシーの拒否)。規則はいつもP3Pプライバシーポリシーの必要な要素すべてを特徴付けてはいないことに注意。`<DATA>`および`<RECIPIENT>`要素が照合することを考えると、この拒否規則はポリシーで規定された目的(`<PURPOSE>`)に関わらず規定を行うだろう。
006 - 008, ...	連結詞。APPELを使用して: `APPEL:connective`属性, 規則の著者は要素の組み込まれた表現に対して異なった照合の意味論明確に規定する。APPELは異なった照合の意味論を実装する異なる連結詞 (`or`, `and`, `or-exact`および`and-exact`) 4つをサポートする。もし、連結詞が与えられなければ、anand-exactを必要とする意味論を照合するdefaultは規則と有効な証拠の間を照合する。 [11] connective = 'APPEL:connective="' conn '"' [12] conn = or \| and \| or-exact \| and-exact
020 - 033	制限された受領-規則。`www.my-bank.com`からWebリソースをリクエストしている間に"accept"規則が取り出されている場合、この規則はポリシーの照合を続けるのみである。それは規則本体に追加の`<APPEL:REQUEST>`要素があるからである。ユーザエージェントが要素にリストされたuriからリクエストをしない限り、この追加の`<APPEL:REQUEST>`要素はfalseと評価する。これによってユーザは簡単に制限されたドメインのセットからポリシーを適用しているだけの規則を書く事ができる。
035 - 048	受領。多くても、サービスが送ったポリシーがユーザエージェントおよび/またはclickstreamデータの集まりを宣言する場合、"受領"規則はデータのリリースのみを許可すべきである。目的(`<PURPOSE>`)および受領者(recipient) 要素 (`<RECIPIENT>`)がP3Pプライバシーポリシーステートメントで必要であったとしても、規則に現れてはいけない事に注意。
040 - 041	照合するためのデータ要素。"`or-exact`"-連結詞の使用があるので、ポリシーのステートメントが規則にnotふくまれていない追加データ参照をもたない場合は"受領"規則は照合するのみである。それゆえ、規則セットの33行から36行に明確に列挙している要素以外をリクエストしているポリシーは直ちにその表現をfalseと評価するだろう。(すなわち、ポリシーを受領しない。)
044 - 046	照合するための係争-解決情報。ユーザは係争が起こった場合に備えて、プライバシーポリシーに関する保証を提供できる組織への参照を持つサービスを確認したいと考える。
050 - 068	"通知"規則。ユーザはTrustUsおよびPrivacyProtectの両方の保証があるWebサイトへ売買目的ではなく、自身の名前を提供することに同意したが、個々のデータ転送を管理したいと思う。実装は、ユーザを新しいサイトへアクセスするよう効果的に促し、特定のサイトへの二次的なデータ転送をすべて明確に受領できるユーザインターフェースを提供するかもしれない。
013, 056	択一のリストの照合。幾つかの異なった目的や受領者を照合するため、"or"または"or-exact"連結詞を使用し、有効な択一の受領者と目的要素のリストを含める。
063 - 066	連結詞の値の照合。ポリシーのTrustUsおよびPrivacyProtect両方の保証を要求するため、規則は`DISPUTES-GROUP`要素の"すべての"連結詞と一緒に同じ要素 (`<DISPUTES>(係争解決)`)を何度(しかし、属性の異なった値で)もリストする。このようにして値の間の論理ANDを表す。
070 - 073	"警告"規則。APPEL規則セットの規則が順序づけられるので、"警告"規則は発行者が送ったポリシーを照合できない先行する規則すべてを評価するだけである。我々の規則の順序を逆にすれば、(すなわち、`<OTHERWISE>`規則を最初に置くこと)ユーザエージェントは得られるポリシーすべてに対していつも警告を発するだろう(以下のコメントを参照のこと)。
072	劣化した表現。劣化した表現`<OTHERWISE>`を使用して、いつもtrueと評価することで知られている"catch-all"規則を作成できる。後に続く規則すべてが評価されないので、`<OTHERWISE>`を含む規則はいつも規則セットの最後に置かれなければならない。空の規則は何も照合しないことに注意。あらゆる可能な証拠セットのために、いつもfire する規則があるように規則セットを書くべきである。このようにして, もし規則がfireしていなければ、規則評価器はエラーをすべきである。

4. 技術的な定義

4.1 構文およびエンコード

4.1.1 BNF構文, APPELレベル1 (標準非準拠)

4.1.2 転送および保管

P3Pプライバシーポリシーと違って、APPEL規則セットはHTTPプロトコルエクステンションのような特別な手段を用いてリアルタイムで交換するようには作られていない。そのかわり、使用中のハードウェアセットアップか、ソフトウェアセットアップかによって利用できる手段を使って単純なファイルのように処理、ダウンロードされる。

内部的には、ユーザエージェントは、ユーザの簡単なテキスト規則セットファイルをその内部表示に合わせるための方法を提供する限り、ユーザの規則セット（バイナリフォーム）の便利な暗号はどれでも使って良い。

4.2 要素

4.2.1 <APPEL:RULESET>(規則セット)要素

4.2.2 <APPEL:RULE>(規則)要素

<APPEL:RULE>要素で直接囲まれているトップ-レベル表現はいつもexact照合(5.4.4 連結詞を参照)と照合されなければならない。-- 一番上の要素の異なる照合の意味論を指定する APPELレベル1に方法がない。

<POLICY>要素を含んでいるが、<APPEL:REQUEST>要素を含まない規則はどのサイトにおいてもポリシーを照合しようとするだろう。<POLICY>要素と<APPEL:REQUEST>要素の両方を含んでいる規則は<APPEL:REQUEST>要素で与えられているURIを照合するサイトでポリシー照合をするのみである。サイトがP3Pプライバシーポリシーを提供しない場合、<APPEL:REQUEST>要素を含んでいるが<POLICY>要素を含まない規則は照合をするだろう。表現の空のリストを持つ規則は起動しない。（前の）規則がfireされていない場合、発生するであろうデフォルト規則を作成するために、劣化した表現<OTHERWISE/>が使用されるべきである。

4.2.3 <APPEL:OTHERWISE>要素

<APPEL:OTHERWISE>規則の唯一の表現である。一つの規則セットは通常、劣化した表現を特徴づける一つの規則を含み、そのような規則は規則セットの最後にくる。ユーザは、ユーザの先行する規則がカバーしない場所のデータレポジトリへのアクセスに制限のない受領挙動で<OTHERWISE>要素を使用しないように注意する必要がある。ユーザエージェントは、そのような"catch-all"受領を持つ規則セットの受領を拒否しなければならない。

4.2.4 <APPEL:REQUEST>要素

<POLICY>-表現と一緒に、<APPEL:REQUEST>要素(<APPEL:REQUEST-GROUP>要素に埋め込まれている) はあるリソースやドメインのみを適用する規則を作成するのに使用される。規則がfireするために表現は正であると評価する必要があるので、既存のどの<APPEL:REQUEST>要素も<POLICY>表現のアプリケーションを与えられたURIへ制限するだろう。

単一の規則にある複数で、択一のリソースや/またはドメインをリストするために、<APPEL:REQUEST-GROUP>要素に複数の<APPEL:REQUEST>要素を埋め込む事ができるし、orやor-exact連結詞を使用して接続することもできる。

4.2.5 APPEL:connective(連結詞)属性

APPELは異なった4種類の連結詞をサポートする: or, and, or-exactそしてand-exact意味論の記載については、5.4.3 連結詞を参照して下さい。APPEL:connectiveが与えられていない場合、and-exactへのAPPEL照合の意味論デフォルトは照合する。：含まれた表現はすべて証拠に現れなければならず、追加の要素は現れてはならない。

5. 意味論

5.1 規則評価器の要約

規則評価器は callingプログラムが、規則が発生させるポリシーのコピーと同様に実行する挙動(4つの標準挙動"受領", "拒否", "通知" または"警告"のどれか一つ)を返さなければならない。規則によって照合されていないオプション的要素があった場合は特に、後者は証拠にあるオリジナルのポリシーと一致しなくてもよいということに注意されたい。さらに、規則評価器は任意に(ユーザ表示に合った)説明文字列、ペルソナの名、や/またはfireされた規則を返してもよい。

5.1.1 挙動

5.1.2 規則セット

規則セットの各規則は現れる順番で評価される。規則がtrueと評価すると、対応する挙動は返され、規則の評価は終了する。照合が行われず、規則すべてが進行する場合、callingプログラムへエラーが返される。

規則セットは、あらゆる可能な証拠セットのために、fire する規則がいつもあるように書かれなければならない。エラーが返された時どうするかを決めるのはcalling プログラム (通常はユーザエージェント)次第である。しかしながら、callingプログラムはエラーを"受領"の様に扱うべきではない。

5.1.3 表現

規則のトップ-レベル表現はすべて一緒に暗黙的にANDされる。同様に各表現は囲まれた属性表現と共に、暗黙的にANDされる。規則の著者がconnective(連結詞)属性を使用して明示的に択一照合を規定しなければ、組み込まれた表現はデフォルトによって ANDされる。

すべての表現とそのサブ-表現 (属性およびと含まれた表現)は規則評価器によって、規則に現れるネスティングに従った証拠の要素と照合される。例えば、規則のPOLICY要素内にネストされているステートメント要素は照合するPOLICY要素の中にネストされている証拠のステートメント要素のみを照合する。

表現を含んでいない規則はいつもfalseと評価し、劣化した表現のみを含んでいる規則はいつもtrueと評価する。

5.2 規則の順序

劣化する表現<OTHERWISE>を含む単一の規則のみが存在し、規則セットの最後にあるということに注意すべきである。

5.3 表現

単一表現のすべてのサブ-表現はいつも一緒にANDされている各デフォルトである、それはつまり、表現が照合をするために、すべての属性および組み込まれた表現はtrueと評価されなければならないということである。しかしながら、APPEL:connective(連結詞)属性を使用して、規則の著者は要素の含まれた表現の異なる照合の意味論を明示的に規定できる。

連結詞がこのレベルにおいて現れている含まれている表現のみを管理している事に注意。これらの含まれている表現は交互に他の表現を含むべきであり、別のconnective(連結詞)属性が含まれている表現の中で使用されていない場合は、デフォルト照合の意味論（exact）を使用して照合されるだろう。詳細は5.4.3 連結詞を参照のこと。

図5.1 以下ではAPPELの表現の正式でない定義の主な種類を3つ説明する。

APPELでは、規則における複数の表現が証拠の一つと同じ要素を照合できるということに注意。規則評価器は証拠でどの部分の規則がどの部分に照合したかという事を覚えておく必要ない。その代わり、以下の例に示しているように、各表現は有効な証拠に対して別々に確認することができる。: 規則のステートメント-表現は、証拠の同じ<STATEMENT>(ステートメント)要素を別々に照合する。

規則の著者がorもしくはor-exactフラグと共にAPPEL:connective(連結詞)属性を明示的に使用しなかった場合、callingプログラムによって提供される証拠のセットの中にない要素に関する表現は、常にfalseと評価する。例えば、証拠が要素を含まない場合に限り、連結詞を使わずに係争解決要素を照合する(含まれている)表現を使用することはいつもうまくいかない。

反対に、規則の著者が明示的にor-exactまたはand-exactフラグと共にAPPEL:connective(連結詞)属性を使用しなかった場合に限り、規則にある対応する要素表現がない証拠はいつも無視される。例えば、係争解決要素を含むが、開示要素を含まない(そして、連結詞を使用しない) P3Pプライバシーポリシーを参照する規則はおそらく、係争解決および開示要素の両方を特徴づけるP3Pプライバシーポリシーを照合することができる。

P3Pプライバシーポリシーやリクエスト情報以外の証拠を照合するにはAPPELレベル2を使用することが必要であることに注意されたし。APPELレベル1を使用すると、P3PプライバシーポリシーやAPPEL:REQUEST要素以外は無視されるだろう(規則の評価の変更はしない)。2つ以上のP3Pプライバシーポリシーが有効である場合、個々に規則評価器へ提示されるべきである。(5.1 規則評価器の要約を参照のこと)

5.4 照合

APPELの表現は規則と有効な証拠を照合するのに使用される。規則で与えられた要素に対して、表現は同じ属性、値、そして照合している-要素を特徴づけている全く同じ要素を証拠が含んでいるかどうかをテストすることができる。APPELにある表現すべての標準の照合の意味論は使用される連結詞の選択で左右され、（以下の5.4.3 連結詞を参照のこと)以下に要約することができる。:

5.4.1 属性の表現

= operatorだけは属性の表現に適応されてもよい。すべての属性値が数字(P3P要素が数属性値を表していないのでこれは実際には重要でない)を表したとしても、APPELで文字列として扱われる。表現が照合するために、表現の属性の表現にリストされている属性および値はすべて、証拠において同じ名前で一つの要素に現れなければならない。証拠で発見されているが、規則で参照されていない追加の属性はいずれも無視される。

規則に属性の値に制限がない要素に特別な属性の出現が必要である場合、(空白の値を含む!), ワイルドカード文字"*"が使用されるかもしれない。(例えば、attribute="*"の中のように) しかしながら、規則が特別な属性の出現を全く必要としない場合、属性は規則に現れるべきではない。

APPELでは、証拠セットの要素(たとえば、access属性のない照合<DISCLOSURE>要素)に或る属性が出現しない規則を書く事ができない事や、ある要素は証拠に存在していない事に注意されたし。(例えば、係争解決フィールドを含まない照合ポリシー)

5.4.2 属性の表現メタ文字

文字列と共にメタ文字を使用すると文字列-値の範囲を規定することができる。例えば、foo.comドメインのホストの"*.foo.com"、または、URI の"*://*""(または、少なくともこういったもの)。ユーザが最初の*星のシンボルを規定しない限り、文字列値はいつも文字列の始まりから照合される事に注意されたし。APPELレベル1では、終わりから文字列の照合はできない。

また、例えば、<DISPUTES res*="service">もしくは<DISP*resolution-type="service">などにおいての属性名または要素名を照合する為ではなく、引用されている文字列の中にのみワイルドカード文字が許可されている事にも注意! データ要素（サブツリー）の範囲を照合するの上記の方法でワイルドカード文字は適用されるが、データ-参照表現 (<DATA name="user.*"/>when used in)で使用される時は、データセット leafs: <DATA name="*.zipcode"/>のセットの照合をするためには使用できない: !

5.4.3 連結詞

トップレベル表現右下の<APPEL:RULE>要素はいつもexact照合を使用して照合される。連結詞は<APPEL:RULE>要素下の要素で使用される。連結詞が与えられていない場合、exact照合が行われる。連結詞は含まれている-表現の直接の照合を管理するのみであり、ダウンロードを伝達しない（受け継いだもの）。これらの含まれている-表現が他の表現を含んでいる場合、新しい連結詞はそのレベルか、または、exact連結詞が再び適用しているデフォルトで規定される必要がある。

4つの有効な連結詞から生じている異なった照合の意味論は以下の図5.3で要約される:

	含まれている表現は
ORされている	ANDされている
追加の証拠	は無視される	`or`	`and`
を変更する	`or-exact`	`and-exact` (デフォルト)

5.4.4 オプションデータ要素の照合要素

規則に対抗するオプション的データ要素を使ってポリシーを照合する単純な機構を以下に記す。ユーザエージェントの実装者は恐らくもっと効率的な戦略を使用したいと思うだろう:

5.4.5 オプションと必須の拡張子の照合

このような必須およびオプション的な拡張子は, オプション的<DATA>要素が照合されるのと全く同じ方法で、APPELで照合される。(5.4.4 オプションデータ要素の照合と比較して下さい): 規則評価器は、オプション的であるとタグ付けされている拡張タグを選択的に取り除くことができなければならなず、ユーザの規則セットとこのようにして変更された証拠を何度も比較できなければならない。オプション的拡張が削除された後の照合の場合、規則評価器は発生した挙動と一緒に発生した変更後のポリシーのコピーをかえさなければならない。

P3Pプライバシーポリシーファイルで参照された拡張子がサポートされているかどうかを決めるのはcalling アプリケーションであるという事に注意。この事は恐らく、規則評価器が呼び出される前になされるべきである。例えば、同時に有効なP3Pプライバシーポリシーは構文的に正しい。

5.4.6 カテゴリの翻訳サポート

P3Pカテゴリはユーザとユーザエージェントにデータの故意の使用に関するヒントを提供するデータ参照要素の属性である。カテゴリはP3P ユーザエージェントが実装と使用をし易くするのに重要である; カテゴリによって、ユーザはデータ交換に関してより普及したプリファレンスと規則を表す事ができる。新しい要素もしくは、形式データやクッキーなどの可変性の抽象的な要素への照合が定義されると、カテゴリは含まれなければならない。

以下の章はAPPELトラストエンジンがサポートしなければならないふたつの異なったケースを示す: 明確なカテゴリを使用して、名付けられたデータ参照要素を参照する規則, その例は以下である。

名前を付けられ、カテゴリ化されたデータ参照要素

しかしながら、ある数の要素に関して、基本データセットは固定したカテゴリを規定しないが、P3Pプライバシーポリシーの著者は明確にカテゴリをリストする代わりに、この要素はこの特別な状況のために使用される。これらの要素は"可変性-カテゴリデータ要素と呼ばれており、これらの要素を参照するデータ参照表現だけのために、APPEL則評価器はカテゴリ属性の追加的使用をサポートしなければならない。

以下の擬似コードは任意に明らかなカテゴリ属性を特徴付けている、名前を付けられたデータ参照要素を照合するために必要な操作を要約している:

カテゴリ-onlyデータ参照要素(カテゴリ拡張子)

カテゴリ-onlyデータ参照要素はカテゴリ(category)属性のみを含むが、name属性を含まない<DATA>要素である。このような規則のカテゴリ-onlyデータ参照要素に遭遇すると、APPEL規則エンジンは黙示的に各参照されたカテゴリを、効果的に規則を表しながら、あたかもこのカテゴリに属しているP3P基本データセットからのすべての要素が明示的にリストされているかのように、そのカテゴリに属している基本要素のリストへ翻訳しなければならない。

以下の図5.4 は一例を示している。あらゆる固定した-カテゴリデータ要素 ("user.home.online.*"および"user.business.online.*") に加えて、拡張子はいずれの可変性-カテゴリデータ要素 ("dynamic.cookies"および"dynamic.miscdata") を適切なカテゴリで増加させて、考慮する必要がある。

参照されているカテゴリに属しているこのサービスとして紹介しているカスタムデータスキーマはいずれもこの機構によって照合される。ユーザエージェントはサービスに固定したカテゴリ基本要素、例えば、"user.name.first"または"user.home.postal.city"などのカテゴリを上書きできるようにしてはならない。

APPELトラストエンジン実装が明示的にカテゴリ-onlyデータ参照要素を含む規則を拡張するかどうか、または、かわりに対応するカテゴリで(または、複数のカテゴリがこの要素の為に定義されたら、異なったカテゴリを特徴付けている複数の要素で)証拠の各データ参照要素を増すかどうか、または、単にカテゴリ属性のディレクトリを直接照合するかどうかはAPPELトラストエンジン実装しだいである。

5.5 要約の照合と例

5.5.1 擬似コードの意味論の照合

5.5.2 照合アルゴリズムの例

C1	証拠の照合は規則表現(<STATEMENT>, <POLICY>など)と同じ種類のXML要素である etc.)
C2	規則表現すべての属性-表現に関して, 属性-表現が同じ属性名と規則を照合する適切な属性-表現に従って照合する値を持つ証拠に存在する。
	表現が`or`連結詞を特徴付ける場合:
C3a	表現内に含まれているネストされた各XML要素の少なくとも一つに関して、C1からC3を満している。
	表現が`and`連結詞を特徴付けている場合:
C3b	表現内に含まれているネストされた各XML要素に関して、C1からC3 を満たしている
	表現が`or-exact`連結詞を特徴付けている場合:
C3c	証拠においてネストされた各XML要素に関して, C1からC3を満たしている
	表現が連結詞を特徴付けていないか, an `exact`連結詞を特徴付けている場合:
C3d	表現に含まれているネストされた各XML要素および, 証拠においてネストされた各XML要素に関して, C1 からC3を満たしている。

付録

付録 A: APPELレベル2仕様書

1.3 必要条件の章で述べた様に, APPELで表現されている規則セットをサポートする初期段階のP3Pユーザエージェントの実装を用意にする為に、この仕様書を簡単にする努力がなされた。核となる言語 (レベル1)から表現のセット(レベル2)を分離する事によって、APPELの完全な機能セットを仕上げる前に私達がプライバシープリファレンス言語を使用しての業務に着手できるように、ワーキンググループはAPPELの早い採用を望む。

レベル2改訂において、ワーキンググループは単純な最初の実装を可能にするために、以下の構成を構文および前回(レベル1で)見落としていた言語の意味論を追加する予定である:

付録 B: 規則セット例 (レベル1)

B.1 ほぼ匿名(ALMOST ANONYMOUS)

B.2 プライバシーと商取引

B.3 シールを探す（LOOK FOR THE SEAL）

<APPEL:RULESET xmlns:APPEL="http://www.w3.org/2000/APPEL"
               crtdby="W3C" crtdon="15-March-2000 16:41:21 GMT">

  <APPEL:RULE behavior="accept" 
     description="Service has privacy seal and does not share data
                  with unrelated third parties.">  
    <POLICY APPEL:connective="and">
      <DISPUTES-GROUP APPEL:connective="or">
        <DISPUTES resolution-service="independent"
                 service="http://www.privacyprotect.org*" />
        <DISPUTES resolution-service="independent"
                 service="http://www.trustus.org*" />
      </DISPUTES-GROUP>
      <STATEMENT APPEL:connective="and">
        <RECIPIENT APPEL:connective="or">
          <ours/><same/><other/><delivery/><public/>
        <RECIPIENT/>
      </STATEMENT>
    </POLICY>
  </APPEL:RULE>

  <APPEL:RULE behavior="warn" 
     description="Service collects data needed for e-commerce activities
                  but may share this data with legal entities following
                  different practices, public fora, or unrelated third parties."> 
    <POLICY APPEL:connective="and">
      <STATEMENT APPEL:connective="and">
        <PURPOSE APPEL:connective="and-exact">
             <current/>
        </PURPOSE>
        <RECIPIENT APPEL:connective="or">
          <other/><public/><unrelated/>
        <RECIPIENT/>
      </STATEMENT>
    </POLICY>
  </APPEL:RULE>

  <APPEL:RULE behavior="warn" 
     description="Service collects data needed for e-commerce activities
                  but may use it also for marketing, profiling, or "other"
          purposes."> 
    <POLICY APPEL:connective="and">
      <STATEMENT APPEL:connective="and">
        <PURPOSE APPEL:connective="and">
             <current/>
        </PURPOSE>
        <PURPOSE APPEL:connective="or">
             <contact/><profiling/><other/>
        </PURPOSE>
      </STATEMENT>
    </POLICY>
  </APPEL:RULE>

  <APPEL:RULE behavior="inform" 
     description="Site collects healthcare information but participates in
                  a seal program.">
    <POLICY APPEL:connective="and">
      <DISPUTES-GROUP APPEL:connective="and">
        <DISPUTES resolution-service="independent"
                 service="*" />
      </DISPUTES-GROUP>
      <STATEMENT APPEL:connective="and">
       <DATA-GROUP APPEL:connective="or">
            <DATA category="health"/>
        </DATA-GROUP>
      </STATEMENT>
    </POLICY>
  </APPEL:RULE>

  <APPEL:RULE behavior="warn" 
     description="Site collects healthcare information but does not
                  participates in a seal program.">
    <POLICY APPEL:connective="and">
      <STATEMENT APPEL:connective="and">
       <DATA-GROUP APPEL:connective="or">
            <DATA category="health"/>
        </DATA-GROUP>
      </STATEMENT>
    </POLICY>
  </APPEL:RULE>

  <APPEL:RULE behavior="accept" 
     description="Service collects data needed for e-commerce activities
                  only, without sharing with legal entities following different
          practices, public fora or unrelated third parties. A seal 
          program vouches for this."> 
    <POLICY APPEL:connective="and">
      <DISPUTES-GROUP APPEL:connective="and">
        <DISPUTES resolution-service="independent"
                 service="*" />
      </DISPUTES-GROUP>
      <STATEMENT APPEL:connective="and">
        <PURPOSE APPEL:connective="and-exact">
             <current/>
        </PURPOSE>
        <RECIPIENT APPEL:connective="or-exact">
          <ours/><same/><delivery/>
        <RECIPIENT/>
      </STATEMENT>
    </POLICY>
  </APPEL:RULE>

  <APPEL:RULE behavior="inform" 
     description="service does not provide access to identifiable data
                  it collects">  
    <POLICY APPEL:connective="and">
      <DISCLOSURE access="contact" />
     </STATEMENT>
    </POLICY>
  </APPEL:RULE>

  <APPEL:RULE behavior = "accept"
    description = "privacy policy matches Look For The Seal preferences">
      <APPEL:OTHERWISE/>
  </APPEL:RULE>

</APPEL:RULESET>

B.4 情報のみ(INFORMATION ONLY)

付録 C: トラストエンジンとデータベースエンジン

付録 D: ABNF表記法(有益)

APPELの正式な文法は、少し変更した[ABNF]を使用してこの仕様書で与えられている。そういった構文がXMLの唯一の文法表現であることに注意されたい: XMLの構文的柔軟性も黙示的に含まれている; 例えば、空白規則, シングルクォーテーション(') やダブルクォーテーション(")を使用した引用、文字エスケープ、コメント、および大文字小文字を区別するなど。さらに、属性と要素はあらゆる順番で現れることに注意。

要素名のみ: `<CONSEQUENCE></CONSEQUENCE>`	要素および属性: `<DISCLOSURE discuri="*"/>`
要素名, 組み込まれた要素および連結詞 `<RECIPIENT APPEL:connective="or-exact" >` `<ours/>` `<same/>` `<delivery/>` `</RECIPIENT>`	要素名, 属性, 組み込まれた要素と連結詞: `<POLICY entity="W3C">` `<STATEMENT APPEL:connective="and">` `<PURPOSE APPEL:connective="or-exact"> <current/></PURPOSE>` `</STATEMENT>` `</POLICY>`

挙動	要素(element)/セット(Set)	URI	係争解決(Disputes)	目的(Purpose)	受領者(Recipient)
reject (拒否)	category="physical", or category="demographic", or category="uniqueid"				same, other, delivery, public or unrelated
accept (受領)	dynamic.http.useragent, dynamic.clickstream.server		*
inform (通知)	user.name.*		"PrivacyProtect" and "TrustUs"	current, admin, custom or develop
accept (受領)		www.my-bank.com			ours
warn (警告)	[otherwise]

Lorrie Cranor	AT&T Labs-Research
Marc Langheinrich (Editor & Chair)	ETH Zurich
Massimo Marchiori	W3C
Joerg Meyer	IBM
Joseph Reagle	W3C
Drummond Reed	Intermind
Mary Ellen Zurko (former Chair)	Iris

P3Pプリファレンス交換言語(APPEL)

W3Cワーキングドラフト 2000年4月20日