A P3P Preference Exchange Language 1.0 (APPEL1.0)

This document complements the P3P1.0 specification [P3P10] by specifying a language for describing collections of preferences regarding P3P policies between P3P agents. Using this language, a user can express her preferences in a set of preference-rules (called a ruleset), which can then be used by her user agent to make automated or semi-automated decisions regarding the acceptability of machine-readable privacy policies from P3P enabled Web sites.

Status of this Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.

This is a W3C Working Draft of the P3P Specification Working Group, for review by W3C members and other interested parties. This document has been produced as part of the P3P Activity, and may eventually be advanced toward W3C Recommendation status. Being a Working Draft document, this specification may be updated, replaced, or obsoleted by other documents at any time. It is therefore inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress." A list of current W3C working drafts can be found at http://www.w3.org/TR/.

This Working Group has considered a number of different approaches to developing a P3P preference interchange language and has decided to document one approach and solicit feedback on it. The group may consider other approaches, including more general-purpose languages (for example, XML or RDF query languages). We encourage the development of experimental implementations and prototypes so as to provide feedback on the specification. However, this Working Group will not allow early implementations to affect their ability to make changes to future versions of this document.

This version of the APPEL language relies on ordered rules. The Working Group is particulary interested in feedback on how to improve this mechanism in terms of better supporting merging and editing of rulesets. Please note that the examples in this draft document are based on the 16 April 2002 Recommendation of the P3P Specification and that such examples might need to be updated should a revised version of the P3P Specification appear.

This draft document will be considered by W3C and its members according to W3C process. This document is made public for the purpose of receiving comments that inform the W3C membership and staff on issues likely to affect the implementation, acceptance, and adoption of P3P.

1. Introduction

This document specifies a language for describing collections of preferences regarding P3P policies between P3P agents. Using this language, a user can express her preferences in a set of preference-rules (called a ruleset), which can then be used by her user agent to make automated or semi-automated decisions regarding the acceptability of machine-readable privacy policies from P3P enabled Web sites.

Note: This language is intended as a transmission format; individual implementations must be able to read and write their specifications in this language, but need not use this format internally.

This language complements the P3P1.0 specification [P3P10]. Much of the underlying logic is based on [PICSRules]. We hope in time that this will merely be an application of [XML] rules or query languages.

1.1 P3P Basics

P3P is designed to inform users about the privacy policies of services (Web sites and applications that declare privacy practices). When a P3P compliant client requests a resource, a service sends a link to a machine-readable privacy policy in which the organization responsible for the service declares its identity and privacy practices. The privacy policy enumerates the data elements that the service proposes to collect and explains how each will be used, with whom data may be shared, and how long the data will be retained.

Policies can be parsed automatically by user agents -- such as Web browsers, browser plug-ins, or proxy servers -- and compared with privacy preferences set by the user. Depending on those preferences, a user agent may then simply display information for the user, generate prompts or take other actions.

In some implementations, a match between the user's preferences and a site's policy might authorize electronic wallets and other data repositories to (semi-) automatically release information to the service.

1.2 Goals of A P3P Preference Exchange Language

The P3P1.0 specification provides a syntax for specifying policies and a mechansim for associating policies with Web resources. It does not specify requirements upon the graphical user interface (GUI) or trust engines. However, there are benefits associated with being able to express user preferences as captured by the GUI and processed by the trust engine:

Primarily, we envision this language will be used to allow users to import preference rulesets created by other parties and to transport their own rulesets files between multiple user agents. User agent implementors might also choose to use this language (or some easily-derived variation) to encode user preferences for use by the rule evaluators that serve as the decision-making components of their user agents.

1.3 Requirements

In defining the scope of the APPEL language, the working group generated a large list of possible requirements. The group then narrowed the scope to eliminate those requirements that were deemed less important or easier to implement if handled elsewhere. Thus, this draft is based on the following requirements:

In order to facilitate the rapid development of prototype implementations of the language the working group decided to first release a Version 1.0 specification designed to express only basic privacy preferences, and later prepare a more detailed specification that would implement the rest of the requirements outlined above. Specifically, APPEL 1.0 limits the requirements to

The remainder of this document will discuss the thus restricted version of APPEL, refered to as the APPEL1.0 specification. See Appendix A: Future Work for a list of possible extensions regarding the full list of requirements given above.

1.4 APPEL and P3P policies

Since APPEL rulesets are intended to express preferences over P3P policies, most of APPEL's synatx and semantics are very much influenced by the P3P 1.0 Specification. In order to follow many of the examples in this draft, the working group strongly recommends that you first familiarize yourself with the P3P 1.0 Specification itself. This will also allow you to better understand the choices in syntax and semantics that were made in the APPEL specification.

As a quick reference, the following figure shows an example policy that features most of the elements and attributes of an XML P3P 1.0 policy. Please refer to section 3. Policy Syntax and Semantics of the P3P 1.0 Specification for details on the individual elements and their usage.

1.5 Definitions

The following definitions (in alphabetical order) reflect the way terms are commonly used in this document.

In addition, this specification uses the same words as RFC 2119 [ RFC2119 ] for defining the significance of each particular requirement. These words are:

2. General Operation and Semantics

The following sections give an overview of the basic operations of an APPEL rule evaluator.

2.1 Inputs and Outputs of the Rule Evaluator

An APPEL rule evaluator is activated by a P3P application. The activating application provides the evaluator with various pieces of "evidence," the P3P base data schema, any custom data schemas referenced in the evidence, and a rule set for processing them. Evidence includes the URI of the service and a single P3P policy (together with the URI of the policy ) from the service if present.

The scope of the rule is determined by the opening and closing elements of an <appel:RULE> element. The evaluator returns the behavior (as specified in its behavior and prompt attributes) of the rule that fired on the basis of the evidence discussed above. In addition, the rule evaluator may optionally return an explanation string (suitable for user display), a prompt message (used for prompting the user for a decision if necessary), the name of a persona, and/or the rule that fired.

HTTP user agents often include a variety of non-essential headers with their requests. These are optional headers such as the REFERER header, and headers that may help the server provide a response in an appropriate language or format. P3P user agents that implement APPEL SHOULD, whenever feasible, limit the use of these non-essential headers, sending them only to sites that have declared them in P3P policies that trigger the request behavior when evaluated against the user's preferences. This may not always be feasible, however, if user agents need to send requests before a P3P policy is evaluated to prevent performance problems.

User agents MAY wish to monitor Web forms and set_cookie requests from Web sites, to make sure they are consistent with the site's declared policy. Techniques for doing this are beyond the scope of this specification.

2.2 Rule Processing and Evaluation

The information described in the following sections is only intended to give a first overview. Details can be found in section 5 Semantics, and should be referenced from the corresponding sections below.

2.2.1 Rule Processing

Rules are evaluated with respect to the evidence provided. A rule evaluates to true if all of its enclosed expressions are satisfied. Basically, an expression is satisfied if any of the available evidence satisfies it.

Each rule in the ruleset is evaluated in the order in which it appears. Once a rule evaluates to true, the corresponding behavior is returned and rule evaluation ends. However, in order to provide a comprehensive list of reasons why a particular behavior got triggered, user agents SHOULD continue evaluation and find additional rules with identical behavior and prompt attribute values. By having access to the combined list of description-message attribute values in all triggered rules, the user can get a comprehensive explanation for the behavior of the user agent.

Rulesets should be written so that there is always a rule that will fire. A rule evaluator should return an error if it is called without a ruleset, with an empty ruleset, or if no rule fires. It is up to the calling program to determine what to do if an error is returned; however, calling programs SHOULD NOT treat an error as they would a "request" behavior without a prompt.

2.2.2 Expressions

An expression in APPEL is represented by an XML element that can be evaluated to TRUE or FALSE by matching it against the available evidence. An expression always consists of (see figure 2.1 for examples):

Element name only: `<CONSEQUENCE></CONSEQUENCE>`	Element name, attributes, contained elements & connective: `<POLICY>` `<ENTITY>` `<DATA ref="#business.name">` `W3C` `</DATA>` `</ENTITY>` `<STATEMENT>` `<PURPOSE` `appel:connective="or-exact">` `<current/>` `</PURPOSE>` `</STATEMENT>` `</POLICY>`
Element and attribute: `<DISPUTES resolution-type="independent"/>`
Element name, contained elements and connective: `<RECIPIENT appel:connective="or" >` `<ours/>` `<same/>` `<delivery/>` `</RECIPIENT>`

Attribute-expressions may take string or numeric values, although APPEL will treat all values as simple strings. APPEL1.0 supports only the equality operator in attribute-expressions.

APPEL offers a single wildcard metacharacter "*" that closely resembles the wildcard character in many operating system shells. Attribute expressions can use this metacharacter to match ranges of values such as

<DATA
    name="#User.*">

(any element from the "User" data set). Contained expressions can use the wildcard character anywhere where #PCDATA ("parsed character data", SGML term for character data that may contain both &entity; and markup) can be used, i.e., between the opening and closing of a tag. Further details are given in sections 5.4.2 Attribute Expressions, 5.4.3 Expression Metacharacters and 5.4.4 Matching #PCDATA .

A special form of expression is the so called degenerate expression <appel:OTHERWISE>. Instead of matching it against the evidence, the rule evaluator MUST always evaluate this expression to true. This expression usally appears in the last rule of a ruleset in order to catch all possible cases that haven't been matched yet.

2.2.3 Rule Evaluation

A rule includes a behavior, an optional persona, optional explanation and prompt messages, and a number of expressions. A rule without any expression always evaluates to false. A rule containing the degenerate expression always evaluates to true. Individual expressions are each composed of attribute expressions and contained expressions, and optionally feature a connective.

When multiple attribute expressions and/or contained expressions are placed within the scope of a single expression, all are matched within the scope of a single piece of evidence. For example, if a rule contains a <STATEMENT> expression that contains both a <PURPOSE><develop/></PURPOSE> expression and a <RECIPIENT><ours/></RECIPIENT> expression, then it will only evaluate to true if the P3P policy contains a statement that both declares local recipients and a research & development purpose. If both expressions are satisfied, but only in separate statements, then the expression evaluates to false.

While attribute expressions within an expression are implicitly ANDed together, a special connective attribute is used to govern the matching semantics of contained expressions. APPEL supports six such connectives: or, and, non-or, non-and ¸ or-exact, and and-exact. If no connective is given, APPEL defaults to requiring and matches: only if all of the elements in the evidence can be found in the rule (additional elements are ignored), a match is triggered.

The matching of attribute and contained expressions is described in more detail in section 5.4 Matching.

3 Simple Example Scenario

In the following section we will describe a simple APPEL preference file in order to introduce the different elements of the APPEL language and illustrate their usage. Although the example is a well formed APPEL ruleset (i.e. it is enclosed in an <appel:RULESET> element), it is only used to demonstrate a small set of example rules.

We will start with a plain text description of the user's (admittedly simple) preferences, followed by a tabular overview of the involved elements and their allowed values. Finally, we will give an example of the corresponding APPEL encoding. Note that each listing in this document features line numbers for ease of reference; they are not part of the actual encoding!

3.1 User Preferences

3.2 Tabular Overview

The following table describes the fields the user is referencing in her privacy preferences, together with the matching conditions and actions that should be taken (Please refer to the Base data elements and sets as well as the XML encoding of a policy, defined in the P3P 1.0 Specification for the list of fields referenced). Do not try to use it as a lookup table for finding a behavior, given a list of attributes/elements and their values. Instead one has to step through the table row by row until the values referenced in the table match. This is because each row represents an ordered rule in our ruleset.

Please note that some of the cells feature a wildcard symbol "*", while others are empty. APPEL distinguishes between non-referenced attributes and those that are referenced but contain only wildcards. In the former case, the user truly does not care about the attribute, even whether it is included in the policy or not. In the latter case, the user might not care about the attributes value, but at least expects it to have some value. For further details see section 5.4.3 Expression Metacharacters. In row two of our example below, the user does not care about the purpose of the collected clickstream data (hence the empty fields in the table), but requires that some form of dispute -information is present (represented by a wildcard "*" character).

3.3 APPEL ruleset

The following listing illustrates one way to encode the above preferences into an APPEL ruleset. Five rules are used to handle all incoming policies from a service. A block -rule (i.e., a rule with the string "block" in its behavior attribute) first rejects any policies asking for identifiable data that is distributed to 3rd parties.

Using an explicit match for the request URL, a second rule then accepts a policy if, when connecting to www.my-bank.com, the requested data is only distributed to the bank and its agents.

Next, a "request" rule checks to see if only non-identifiable clickstream data and/or user agent information (such as browser version, operating system, etc) is collected, and seamlessly continues to request the resource if dispute information is available.

A "request" rule featuring a prompt="yes" attribute then matches any requests for the user's name for non-marketing purposes and eventually initiates a prompt informing the user that a site wants to collect her name under acceptable circumstances.

If none of the other rules matches, a "limited"-rule (again using a prompt="yes" attribute) encapsulating the degenerate expression " appel:OTHERWISE " will fire, prompting the user to (cautiously) decide on any policy that has not been covered by any of the rules above, while using only the absolutely required headers to make the request, if at all.

001: <appel:RULESET
xmlns:appel="http://www.w3.org/2002/04/APPELv1" 
002:                xmlns:p3p="http://www.w3.org/2000/12/P3Pv1" 
003:                crtdby="W3C" crtdon="1999-11-03T09:21:32-05:00">

004:   <appel:RULE behavior="block" description="Service collects personal
005:                   data for 3rd parties">
006:     <p3p:POLICY>
007:       <p3p:STATEMENT>
008:         <p3p:DATA-GROUP>
009:           <p3p:DATA>
010:             <p3p:CATEGORIES appel:connective="or">
011:               <p3p:physical/>
012:               <p3p:demographic/>
013:               <p3p:uniqueid/>
014:             </p3p:CATEGORIES>
015:           </p3p:DATA>
016:         </p3p:DATA-GROUP>
017:         <p3p:RECIPIENT appel:connective="or">
018:           <p3p:same/>
019:           <p3p:other-recipient/>
020:           <p3p:public/>
021:           <p3p:delivery/>
022:           <p3p:unrelated/>
023:         </p3p:RECIPIENT>
024:       </p3p:STATEMENT>
025:     </p3p:POLICY>
026:   </appel:RULE>

027:   <appel:RULE behavior="request" 
028:               description="My Bank collects data only for itself 
029:                            and its agents">
030:     <appel:REQUEST-GROUP>
031:       <appel:REQUEST uri="http://www.my-bank.com/*"/>
032:     </appel:REQUEST-GROUP>
033:     <p3p:POLICY>
034:       <p3p:STATEMENT>
035:         <p3p:RECIPIENT appel:connective="or-exact">
036:           <p3p:ours/>
037:         </p3p:RECIPIENT>
038:       </p3p:STATEMENT>
039:     </p3p:POLICY>
040:   </appel:RULE>

041:   <appel:RULE behavior="request" 
042:               description="Service only collects clickstream data">
043:     <p3p:POLICY>
044:       <p3p:STATEMENT>
045:         <p3p:DATA-GROUP appel:connective="or-exact">
046:           <p3p:DATA ref="#dynamic.http.useragent"/>
047:           <p3p:DATA ref="#dynamic.clickstream.server"/>
048:         </p3p:DATA-GROUP>
049:       </p3p:STATEMENT>
050:       <p3p:DISPUTES-GROUP>
051:         <p3p:DISPUTES service="*"/>
052:       </p3p:DISPUTES-GROUP>
053:     </p3p:POLICY>
054:   </appel:RULE>

055:   <appel:RULE behavior="request" prompt="yes" 
056:               promptmsg="Service only collects your name
057:                            for non-marketing purposes (assured)

058:                            Do you want to continue?">
059:     <p3p:POLICY>
060:       <p3p:STATEMENT>
061:         <p3p:PURPOSE appel:connective="or-exact">
062:           <p3p:current/>
063:           <p3p:admin/>
064:           <p3p:customization/>
065:           <p3p:develop/>
066:         </p3p:PURPOSE>
067:         <p3p:DATA-GROUP appel:connective="or-exact">
068:           <p3p:DATA ref="#user.name.*"/>
069:         </p3p:DATA-GROUP>
070:       </p3p:STATEMENT>
071:       <p3p:DISPUTES-GROUP>
072:         <p3p:DISPUTES service="http://www.privacyprotect.com"/>
073:         <p3p:DISPUTES service="http://www.trustus.org"/>
074:       </p3p:DISPUTES-GROUP>
075:     </p3p:POLICY>
076:   </appel:RULE>

077:   <appel:RULE behavior="limited" prompt="yes" 
078:     promptmsg="Suspicious Policy.  Do you want to continue (limited access)?">
079:     <appel:OTHERWISE/>
080:   </appel:RULE>

081: </appel:RULESET>

3.4 Example Explanation

Using the line numbers in the example above, we will briefly explain the basic structure of an APPEL ruleset.

Lines	Explanation
000 - 081	APPEL ruleset. Usually a single APPEL ruleset (i.e., a set of ordered rules enclosed in an `<appel:RULESET>` tag) is installed in a user agent. Implementations might offer to hold different rulesets depending on the current user of the system, or on the persona the user wants to use during the current browsing session. The `<appel:RULESET>` element can be tagged with additional information such as author or date of creation: [1] ruleset = '<appel:RULESET xmlns:appel="http://www.w3.org/2002/04/APPELv1" ' common-attributes '>' rseq '</appel:RULESET>' [2] rseq = 1*rule
004 - 026	"block" rule. APPEL offers three distinct kinds of behaviors for rules: "request", "block", and "limited", each of which can optionally prompt the user ( `prompt="yes"`). Each rule consists of an `<appel:RULE>` element surrounding a set of expressions or the degenerate expression `<appel:OTHERWISE>` . [3] rule = '<appel:RULE behavior="' behavior '"' common-attributes rule-attributes [connective] '>' body '</appel:RULE>' [7] behavior = 'request' \| 'block' \| 'limited' Each rule can be augmented by a set of attributes. In our example we use the description field to supply a human readable explanation ("Service only collects clickstream data") in case the rule should fire (this could be displayed by the user agent during data transfer, or could be used for debugging purposes). In case we want the rule to prompt the user for a decision, a separate prompt message attribute (`promptmsg`) allows the specification of an apropriate question. [4] common-attributes = [' crtdby=' quoted-string] [' crtdon="' datetime '"'] [' description=' quoted-string] [5] rule-attributes = [' prompt ="' ('yes'\|'no') '"'] [' persona=' quoted-string] [' promptmsg=' quoted-string]
006 - 025	P3P Policy to match. Most APPEL rules have a P3P policy as the matching expression inside a `<RULE>` element. Elements and attribute values that the rule should match on are simply spelled out in the policy, while wildcards ("") are used to match a range of values. Omitting an attribute or element completely allows the attribute/element to be missing from the policy supplied by the service (or to be included with any value). [8] top-expression = policy \| request-group [policy] [9] policy = <[P3P10] policy snippet (including embed. connectives)> [10] request-group = '<appel:REQUEST-GROUP ' [connective] '>' 1request '</appel:REQUEST-GROUP>' [11] request = '<appel:REQUEST uri="' [URI] as per RFC 2396'"/>'
007 - 024	STATEMENT element match. The "block" rule should fire (i.e. reject the policy) if the service asks for personal data ( `<DATA>` elements in the categories `physical`, `demographic` or `uniqueid`) that is distributes to 3rd parties ( `<RECIPIENT>` matching `<same/>`, `<other-recipient/>` " or `<published/>`). Note that rules do not always feature all required elements of a P3P policy. Given that both the `<DATA>` and `<RECIPIENT>` element match, this block rule will match regardless of the purpose ( `<PURPOSE>`) specified in the policy.
010, 017, ...	Connectives. Using the `appel:connective` attribute, the rule author can explictly specify different matching semantics for the contained expressions of an element. APPEL supports six different connectives ( `or`, `and`, `non-or`, `non-and`, `or-exact` and `and-exact`) that implement different matching semantics. If no connective is given, the default matching semantics require an and match between the rule and the available evidence. [12] connective = 'appel:connective="' conn '"' [13] conn = or \| and \| non-or \| non-and \| or-exact \| and-exact
027 - 040	Restricted request-rule. This "request" rule only continues to match the policy if it has been fetched while requesting a Web resource from `www.my-bank.com`. This is because of the additional `<appel:REQUEST>` element in the rule body, which evaluates to false unless the user agent is currently requesting a resource from the uri listed in the element. This allows users to easily write rules that only apply to policies from a restricted set of domains.
041 - 054	request. The "request" rule should only continue to request the resource if the policy sent by the service at most declares the collection of user agent and/or clickstream data. Note that the purpose ( `<PURPOSE>`) and recipient element ( `<RECIPIENT>`) do not have to appear in the rule, even though they are required in a P3P policy statement.
046 - 047	Data Elements to match. Because of the use of the " `or-exact` "- connective, the "request" rule will only match if the statement in the policy does not contain any additional data references not contained in the rule. Consequently, a policy requesting any other element than the ones explicitly enumerated in between lines 45 and 48 of the ruleset would immediately evaluate the expression to false (i.e. not accepting the policy).
050 - 052	DISPUTE-resolution information to match. The user wants to make sure that the service included a reference to an organization that can provide assurance about its privacy policy in case disputes should arise.
055 - 076	"prompt and request" rule. Although the user agrees to releasing her name for non-marketing purposes to Web Sites that have assurances from both TrustUs and PrivacyProtect, she wants to supervise each individual data transfer. Implementations might offer User Interfaces that allow users to explicitly accept all subsequent data transfers to a particular site, effectively prompting the user only for her first visit to a new site.
010, 017, 028, ...	Matching a list of alternatives. In order to match a number of different purposes or recipients, we use either the "or" or the "or-exact" connective and enclose a list of valid alternatives recipients and purposes elements. If a number of alternatives should not be matched, the "non-or" connective can be used.
071 - 074	Matching conjunctive values. In order to require both assurances from TrustUs and PrivacyProtect in the policy, the rule lists the same element ( `<DISPUTES>`) multiple times (but with different values in their attributes). Because of the implied "and" connective (this is the default connective if no `appel:connective` attribute is given) in the enclosing `DISPUTES-GROUP` element, this represents a logical AND between the values.
077 - 080	"limited" rule. Since rules in an APPEL ruleset are ordered, the "limited" rule only gets evaluated should all preceding rules fail to match the policy sent by the publisher. If we would reverse the order of our rules (i.e. putting the `<OTHERWISE>` rule at the top), our user agent would always issue a prompt for all incoming policies (see comment below).
079	Degenerate Expression. Using the degenerate expression `<OTHERWISE>`, we can create "catch-all" rules that are always known to evaluate to true. Rules containing `<OTHERWISE>` should usually be placed at the end of a ruleset, since all following rules will never be evaluated. Note that empty rules never match anything. Rulesets should be written so that for any possible evidence set, there is always a rule that will fire. Thus, if no rule fires, the rule evaluator should return an error.

4. Technical Definition

The following syntax must be used for implementations to be compliant. In addition, compliant applications must process rules according to the semantics defined in section 5.4 Matching Semantics.

4.1 Syntax & Encoding

This section lists the exact syntax used for the APPEL1.0 language, as well as encoding issues.

4.1.1 BNF Syntax, APPEL1.0 (non-normative)

The BNF syntax below is just an informal representation of the actual syntax. Please refer to Appendix C: XML Schema for the normative description of the APPEL syntax. Detailed explanations can be found in section 4.2 Elements.

4.1.2 Transport & Storage

APPEL rulesets are represented as XML documents, following the same character set conventions as generic XML. Legal characters are tab, carriage return, line feed, and the legal graphic characters of Unicode and ISO/IEC 10646. For further details see the character encoding section in the XML Recommendation. Note that in XML documents both element and attribute names are case-sensitive. All element names in APPEL are in uppercase, while attributes are using all lowercase. The P3P uses a similar convention, so it should be a uniform format even for P3P policies. However, please refer to the latest P3P Specification for a normative definition of case in P3P elements.

In contrast to P3P policies, APPEL rulesets are not intended to be exchanged in real time by special means such as an HTTP protocol extension. Instead, they should be treated and downloaded like simple files, using any means available depending on the hard- and software setup in use.

Internally, user agents may use any convenient encoding of a user's ruleset (e.g. in binary form), as long as they provide methods to synchronize a user's plain text ruleset file with its internal representation.

4.2 Elements

This section describes the elements that are used to create an APPEL ruleset. Each element is given in <> brackets, followed by the list of attributes that can appear in the element. All listed attributes are optional, except when tagged as mandatory. For more information on the actual usage of these elements, please refer to section 5. Semantics as well as section 3. Simple Example Scenario.

4.2.1 The <appel:RULESET> element

4.2.2 The <appel:RULE> element

A rule that only contains a <POLICY> element, but no <appel:REQUEST> element, will try to match policies on any site. A rule that contains both a <POLICY> element and an <appel:REQUEST> element will only match policies at sites that match the URI given in the <appel:REQUEST> element. A rule that only contains an <appel:REQUEST> element, but no <POLICY> element, will match whenever a resource from that particular site is requested, no matter what P3P policy applies (even if no policy applies). If you want to match sites that don't have a P3P policy, use the non-or or non-and connectives in the <appel:RULE> element, together with a <POLICY> element. A rule with an empty list of expressions will never get activated. In order to create a default rule that will trigger if no other (preceding) rule fired, the degenerate expression <OTHERWISE/> should be used.

4.2.3 The <appel:OTHERWISE> element

<appel:OTHERWISE> should be the only expression in a rule. A ruleset should usually contain one and only one rule featuring the degenerate expression, and such a rule should be the last one in a ruleset. Users should take care not to use the <OTHERWISE> element together with a request behavior, which would result in indiscriminated access to all sites not covered by the preceding rules.

4.2.4 The <appel:REQUEST> element

Together with a <POLICY> -expression, the <appel:REQUEST> element (embedded in an <appel:REQUEST-GROUP> element) can be used to create rules that only apply to a certain resource or domain. Since both expressions need to evaluate to true in order for the rule to fire, any existing <appel:REQUEST> element will limit the application of the <POLICY> expression to the given URI.

In order to list multiple, alternative resources and/or domains in a single rule, you can embed multiple <appel:REQUEST> elements in an <appel:REQUEST-GROUP> element and connect them using an or or or-exact connective.

4.2.5 The appel:connective attribute

APPEL supports six different kinds of connectives: or, and, non-or, non-and, or-exact and and-exact. Please refer to section 5.4.1 Connectives for a description of their semantics. If no appel:connective is given, APPEL's matching semantics default to an and match: All of the containedexpressions must appear in the evidence, additional elements will be ignored.

4.2.6 The P3P1.0 policy snippet

The primary focus of APPEL is the matching of P3P1.0 policies, although in principle any kind of XML evidence could potentially be matched against. While P3P1.0 policies must adhere to the strict syntax and semantics of the P3P1.0 specification, the P3P1.0 policy snippets given in an APPEL rule can consist of any set of P3P1.0 elements, in any order.

Not only can required parts of a P3P1.0 policiy be omitted (in case they are not relevant for the matching), even enclosing tags need not be present: it is perfectly legal for a rule to contain, for example, a single DATA element, even though such an element would need to be embedded within a STATEMENT element when part of a P3P1.0 policy. APPEL rule evaluators need not verify a given policy for P3P1.0 compliance, this must be done by the calling application. Only when matching DATA elements and their CATEGORIES, APPEL rule evaluators must properly check the corresponding P3P1.0 semantics (see sections 5.4.5 Matching p3p:DATA elements and 5.4.6 Category expansion below).

5 Semantics

While section 2. General Operation and Semantics already gave an overview of the basic operations of an APPEL rule evaluator, the following sections describe the semantics of the APPEL language in more detail. We first revisit the basic operation of an APPEL rule evaluator described in section 2, and then focus on individual issues concerning rule evaluation: rule ordering, expressions, matching, and rule expiration.

5.1 The Rule Evaluator in a Nutshell

A P3P user agent or other program will invoke an APPEL rule evaluator, providing an APPEL ruleset and various pieces of "evidence," which may include the URI of the currently requested resource, and a single P3P policy. If multiple P3P policies are available, the user agent SHOULD call the rule evaluator repeatedly and feed it each policy separately (in any order).

The rule evaluator MUST return a behavior (i.e., one of the three standard behaviors "request", "block" or "limited") that the calling program should carry out (including any optional prompt attribute). In addition, the rule evaluator SHOULD optionally return a prompt message (if applicable) and MAY optionally return an explanation string (suitable for user display), the name of a persona, and/or the rule that fired.

5.1.1 Behaviors

A user agent MUST at least support the three standard behaviors "request", "block" or "limited". Each behavior may optionally require a user prompt, as indicated by the prompt attribute. User agents SHOULD if possible support such prompts.

5.1.2 Rulesets

A ruleset consists of an ordered list of rules. Rules describe conditions under which a certain behavior should be carried out by the calling program.

Each rule in a ruleset is evaluated in the order in which it appears. Once a rule evaluates to true, the corresponding behavior is returned and rule evaluation ends. If no match occurs and all rules have been processed, an error is returned to the calling program.

Rulesets should be written so that for any possible evidence set, there is always a rule that will fire. It is up to the calling program (usually the user agent) to determine what to do if an error is returned; however, calling programs should not treat an error as they would an "request".

5.1.3 Expressions

Each rule contains a number of top-level expressions in form of a well-formed XML element and features one single behavior (with an optional prompt attribute). An APPEL compliant user agent MUST at least support the P3P <POLICY> element, the APPEL <appel:OTHERWISE> element, as well as the <appel:REQUEST> element (representing the URI of the currently requested resource, not the policy URI).

Each expression in a rule is implicitly ANDed together with all of its enclosed attribute expressions. Contained expressions (including top-level expressions) are by default also ANDed together, unless the rule author explicitly specified an alternative matching using the connective attribute.

All expressions and their sub-expressions (i.e. attribute and contained expressions) are matched by the rule evaluator against the elements in the evidence according to the nesting in which they appear in the rule. For example, a STATEMENT element nested inside a POLICY element in the rule will only match a STATEMENT element in the evidence that is nested inside a matching POLICY element.

A rule containing no expressions always evaluates to false, a rule containing only the degenerate expression always evaluates to true.

5.2 Rules ordering

There is no need for logic operators between multiple rules in an APPEL ruleset, since all rules in APPEL are evaluated strictly in order. However, inserting a new rule or changing the order of an existing list of rules can greatly influence the behavior of the user agent!

Even though rules are evauluated strictly in order, independently of their behavior, the working group has found the following ordering to be helpful when (manually) creating APPEL rulesets:

After starting out with all cases that are deemed acceptable (request rules), append all situations under which only limited request should be made (limited rules). The final set of rules cover all cases that should result in a blocked request (block rules). Finally, prepend a list of exceptions (any behavior) to the list of rules, such as special provisions for trusted sites, etc. This ordering has proven to be helpful for members of the working group, both for creating as well as for maintaining rulesets.

Care should be taken that only a single rule containing the degenerate expression <OTHERWISE> exists and is placed at the end of the ruleset.

5.3 Expressions

Every rule in an APPEL ruleset contains a number of top-level expressions that must be in valid XML format. Each expression tries to match a certain piece of evidence, which in APPEL1.0 can only be in the form of a P3P policy or represent request information such as the resource URI (using the <appel:REQUEST> element).

All sub-expressions of a single expression are per default always ANDed together, that is, all attribute and contained expressions have to evaluate to true in order for the expression to match. However, using the appel:connective attribute, the rule author can explictly specify different matching semantics for the top-level and contained expressions.

Note that connectives only govern the matching of contained expressions appearing at this level. Should these contained expressions in turn contain other expressions, they will be matched using the default matching semantics (i.e., and) unless another connective attribute is used within the contained expression. See section 5.4.1 Connectives for details.

Figure 5.1 below gives the informal definition of the 3 main types of expressions in APPEL.

Note that it is possible in APPEL that multiple expressions in the rule match one and the same element in the evidence. Rule evaluators do not need to keep track of which part of the rule matched which part in the evidence. Instead, each expression can separately be checked against the available evidence, as shown in the example below: Both STATEMENT -expressions in the rule independantly match the same <STATEMENT> element in the evidence.

Expressions over elements that are not in the set of evidence provided by the calling program always evaluate to false, unless the rule author explicitly used the appel:connective attribute with either the or, or-exact, non-or or non-and flag. For example, a rule using a (contained) expression to match a disputes element without any connectives would always fail unless the evidence would contain such an element.

On the other hand, elements in the evidence that do not have a corresponding expression in the rule are always ignored, unless the rule author explicitly used the appel:connective attribute with either the or-exact, and-exact, non-or or non-and flag. For example, a rule referencing a P3P policy containing a disputes element but no disclosure element (and using no connectives) could possibly match evidence of a P3P policy featuring both a disputes and a disclosure element.

When using APPEL1.0 all elements other that P3P policies and appel:REQUEST elements will be ignored (i.e. do not alter rule evaluation). Also remember that if more than one P3P policy is available, they should be submitted to the rule evaluator individually (see 5.1 The Rule Evaluator in a Nutshell).

5.4 Matching

Expressions in APPEL are used to match a rule against the available evidence. For a given element in the rule, an expression can test whether the evidence contains an identical element featuring the same attributes, values, and matching sub-elements. The standard matching semantics for all expressions in APPEL depend on the choice of connective that is used (see section 5.4.1 Connectives below) and can be summarized as follows:

The different matching semantics that result from the six available connectives are summarized in Table 5.3 below:

**Table 5.3:** Connectives Summary (informative)
	Contained expressions are
ORed	ANDed
Additional evidence	is ignored	`or`, `non-or`	`and` (default), `non-and`
is not ignored	`or-exact`	`and-exact`

5.4.1 Connectives

While attribute-expressions are always ANDed, the matching of contained-expressions is subject to matching connectives that can be specified as attributes to the enclosing element. Note that even if an element does not feature any contained expressions or #PCDATA, specifying a connective will affect its matching semantics! APPEL1.0 supports six connectives, which are described in Table 5.4 below. In the informative mathematical formulas, R denotes the set of immediate subelements below the currently compared rule element (i.e., the contained expressions, including #PCDATA), while E identifies the immediate subelements (including #PCDATA) below the corresponding element in the evidence. Note that subelements of subelements are not part of these sets but need to be compared recursively in turn for each of the subelements.

**Table 5.4:** Matching Semantics of Connectives
Connective	Short Description (informative)	Formula (informative)
Long Description (normative)
or	at least one common element between rule elements R and evidence E	$R\cap E\neq \emptyset$
Matches if one or more of the contained expressions can be found (at the correct position) in the evidence. If the evidence contains elements not listed in the rule, such evidence is ignored. Using this connective requires that at least one of the listed contained expressions appear in the evidence. In case an element does not feature any contained expressions, matching always fails !
and	rule elements R subset of evidence E	$R\subseteq E$
Matches if all of the contained expressions can be found (at the correct position) in the evidence. If the evidence contains elements not listed in the rule, such evidence is ignored. Using this connective requires that all of the listed contained expressions appear in the evidence. In case no contained expressions are given, the enclosing expression always matches (provided that all of its attribute-expressions match). This is the default matching semantics if no connective is given.
non-or	no common elements between rule elements R and evidence E	$R\cap E=\emptyset$
Matches if none of the contained expressions can be found (at the correct position) in the evidence. If the evidence contains elements not listed in the rule, such evidence is ignored. In case no contained expressions are listed, the enclosing expression always matches (provided that all of its attribute-expressions match). This connective is the equivalent of negating a standard `or` match described above: `NOT (... or ... or ...)`.
non-and	at least one rule element R not in evidence E	$R\setminus E\neq \emptyset$
Matches if not all of the contained expressions can be found (at the correct position) in the evidence. If the evidence contains elements not listed in the rule, such evidence is ignored. In case no contained expressions are listed, matching always fails ! This connective is the equivalent of negating a standard `and` match described above: `NOT (... and ... and ...)`.
or-exact	non-empty evidence E subset of rule elements R	$E\subseteq R$
Matches if one or more of the contained expressions can be found (at the correct position) in the evidence. If the evidence contains elements not listed in the rule, matching fails. In case no contained expressions are listed, matching always fails! Using this connective ensures that only those elements listed in the rule appear in the evidence.
and-exact	evidence E equals rule elements R	E=R
Matches if all of the contained expressions can be found (at the correct position) in the evidence. If the evidence contains elements not listed in the rule, matching fails. Using this connective ensures that the elements listed in the rule are identical with the evidence -- no elements are missing, no additional elements appear. In case no contained expressions are listed, the enclosing expression only matches if the evidence does not contain any subelements (at the corresponding position).

5.4.2 Attribute Expressions

An attribute expression matches an attribute-value pair of an XML element in the evidence if and only if:

Only the = operator may be applied to attribute expressions. All attribute values are treated as strings in APPEL, even if they represent numbers (No P3P element features numeric attribute values, so this shouldn't really matter). In order for an expression to match, all of the attributes and values listed in the expression's attribute expressions have to appear in a single element with the same name in the evidence. Any additional attributes that are found in the evidence but which are not referenced in the rule are ignored. Since some attributes in P3P have a default value that applies when the attribute is not explicitly given in an element, the matching algorithm MUST represent such default attributes with their implicit values, in case a rule explicitly tries to match an attribute with its default value.

If a rule requires that a particular attribute appears in an element without restrictions on the value for that attribute (including the empty value!), the wildcard character " * " may be used (e.g. as in attribute="*"). However, if a rule does not require that a particular attribute appear at all, the attribute should not appear in the rule at all. It is not possible in APPEL to write rules that require that a certain attribute does not appear in an element of the evidence set (e.g. matching <DISPUTES> elements without resolution-type attribute).

Please note that attribute expressions match independently from any given connective, that is, no matter which connective is in effect, additional attributes found in the evidence but not in the rule are always ignored.

5.4.3 Expression Metacharacters

APPEL offers a single metacharacter for providing simple regular expression support in its expressions: the asterix (" * ") character, which is used to represent a sequence of 0 or more characters. This usage of the asterix character is similar to popular operating system shells under DOS/Windows and UNIX, but differs from its semantics in standard regular expression systems such as egrep.

Using metacharacters with strings allows us to specify ranges of string-values, for example " *.foo.com " for any host in the foo.com domain, or " *://*" " for a URI (or at least something that looks like one). Please note that string values are always matched from the beginning of the string, unless the user specified an initial * star symbol. Forcing a string match from the end is not possible in APPEL1.0.

Note that since the asterix is also a legal character in URIs ([ URI ]), some special conventions have to be followed when encoding such "extended URIs" in an APPEL ruleset:

Please note also that the wildcard character is both allowed within quoted strings (i.e., in attribute expressions) and between XML elements (i.e., matching #PCDATA). However, you can not use the wildcard character to match attribute or element names, as for example in

<DISPUTES
    res*="service">

<DISP*
    resolution-type="service">

! Nor can you use it in the ref attribute of <DATA> elements or the base attribute of <DATA-GROUP elements. For details on matching P3P data elements, see section 5.4.5 Matching p3p:DATA elements below.

5.4.4 Matching #PCDATA

It is possible to write APPEL rules that match #PCDATA in the evidence, simply by including the text to match as #PCDATA within the corresponding element in the APPEl rule.

However, in order to facilitate rule formulation, the APPEL ruleset evaluator MUST normalize both pieces of #PCDATA before #PCDATA taken from the ruleset is matched against #PCDATA taken from the policy. The normalization algorithm to use is given below:

Once both values have been normalized, matching #PCDATA is similar to attribute expression matching described above: Two pieces of #PCDATA match if and only if

Similarly to contained expressions, the matching of #PCDATA is subject to the appel:connective given in its enclosing element. For practical purposes, each block of #PCDATA can be seen as a separate subelement for which the matching semantics described in section 5.4.1 Connectives above must be applied.

Please note that some XML parsers might treat a block of #PCDATA that contains one or more XML comments as two or more separate #PCDATA blocks. XML comments both within the rule and the evidence MUST be ignored , so implementors must make sure that such separated #PCDATA blocks are treated as if they were a single, contiguous section (i.e., as if no comments were present).

5.4.5 Matching p3p:DATA elements

<p3p:DATA> and <p3p:DATA-GROUP> elements carry a special semantic in P3P policies. They reference sets and elements of the P3P base data schema and potentially custom schemas. Each reference to a data element or data set consists of a URI reference, where the fragment identifier part denotes the name of the data element or set, while the URI part denotes the corresponding data schema (compare with section 3.3.7 The DATA-GROUP and DATA elements in the P3P1.0 Specification).

In order to correctly handle the semantics of data schemas, the following exceptions to standard matching apply to p3p:DATA-GROUP and p3p:DATA elements:

The above matching semantics will have the effect that a rule specifying, for example, the data set #user.name, matches the data element #user.name.first in the evidence. Equally, a single data element in the rule, like #user.homeinfo.postal.street will match a whole data set specified in the evidence, such as #user.home-info. In order to write a rule matching all data elements from a specific data schema, rule authors can use the empty fragment identifier ' # ' in conjunction with an enclosing DATA-GROUP element that features a corresponding base attribute.

However, note that in order for a p3p:DATA element to match, any implicitly or explicitly given categories must match as well, as described in section 5.4.6 Category expansion below.

5.4.6 Category expansion

P3P categories are subelements of data reference elements that provide hints to users and user agents as to the intended uses of the data. Categories are vital to making P3P user agents easier to use; they allow users to express more generalized preferences and rules over the exchange of their data. Categories have to be included when defining a new element or referring to variable abstract elements such as form data or cookies.

In order for rule evaluators to be able to identify and expand data element categories, the corresponding data schema for each encountered data element must be known to the rule evaluator. Consequently, both the P3P base data schema, as well as any custom data schemas referenced in the evidence MUST be passed to the rule evaluator when processing a ruleset (compare section 2.1 Inputs and Outputs of the Rule Evaluator).

APPEL rule evaluators must expand DATA and CATEGORIES elements in the evidence according to the steps described below before attempting to match CATEGORIES elements in a rule:

Implementors might want to note that unless a ruleset does contain at least one CATEGORIES element, the above expansion can be skipped.

5.4.7 Matching optional data elements

Data elements in P3P can be tagged as optional="yes", indicating that the declared element is not required. Intuitively, an optional element in the evidence which would cause a rule to fail should be treated differently from a mandatory element when being evaluated by an APPEL rule evaluator.

Since fully transparent support for such optional elements would require rule evaluators to be able to selectively remove certain non-mandatory elements from the evidence in order to find a possible match for a rule (an NP-hard problem), the working group decided to simplify optional-element handling by the rule evaluator at slightly additional costs for the rule authors. In practice, this means that optional element handling is done using standard attribute matching (as described in section 5.4.2 Attribute Expressions) on the corresponding optional attribute identifying such elements.

Due to its standard attribute matching semantics, APPEL rules must ignore attributes present in the evidence that are not referenced in the rule. Consequently, a rule featuring a data element without explicitly specifying an optional="yes" or optional="no" attribute will match any corresponding data element in the evidence regardless of its mandatory or optional status. This default should be suitable for most rules (especially those resulting in a request behavior).

However, in some cases (notably block rules) rule authors might want to differentiate between data elements declared as mandatory and those being optional. This can be done by adding an explicit optional="no" to data elements in the corresponding rule, forcing the rule evaluator to check for an optional attribute in the corresponding evidence and rejecting the match unless the evidence features an explicit optional="yes" for this element.

Rule authors must thus decide for every element that they want to match in their rules whether they want to match only optional elements in the evidence (by using optional="yes" in the rule), only mandatory elements (by using optional="no" in the rule), or if the optional status of an element does not matter (by leaving out the optional attribute altogether). Note that different connectives in each of the enclosing elements in the rule might affect this requirement.

5.4.8 Matching optional and mandatory extensions

P3P 1.0 also supports the concept of optional and mandatory extensions. Such extensions are enclosed in a set of <EXTENSION>...</EXTENSION> tags and feature an optional attribute that is used to indicate wheter an unknown extension can either be safely ignored ( optional="yes") or not.

This is because the availability of an extension (i.e., whether or not it will be ignored) is neither a feature of the user's preferences, nor of the P3P1.0 policy: it is up to the implementation calling the APPEL rule evaluator to decide whether it can understand any extensions embedded in P3P1.0 policies. If it does understand the extension, it can remove any optional="yes" attribute present and pass the evidence on to the APPEL rule evaluator. If it does not understand the extension, it must decide whether it can safely remove the unknown extension (in case it is tagged as being optional) or abort evaluation of this policy if it is mandatory, as it cannot understand the meaning of the whole policy (compare with section 3.5 Extension Mechanism of the P3P1.0 Specification.

APPEL rule evaluators NEED NOT care about whether a certain extension matched in the evidence is known to the calling application or not. In most cases, rules covering extensions will not use the optional attribute at all: either the calling application supports this extension, then it will pass such evidence on to the rule evaluator. In case it does not support such an extensions, it will probably never pass any evidence containing such an extension to the rule evaluator in the first place.

5.5 Matching Summary & Examples

The following section summarizes the different matching semantics described above and tries to give examples for matching algrorithms.

5.5.1 Matching Semantics in Pseudocode

The standard matching semantics for rules in APPEL are as follows (compare with section 5.4.1 Connectives):

5.5.2 Sample Matching Algorithm

In order to better understand the implications of the above distinctions in the matching process this sections lists a sample algorithm for implementing the matching semantics of APPEL1.0.

C1	the matching evidence is the same type of XML element as the rule expression (i.e. <STATEMENT>, <POLICY>, etc.)
C2	for every attribute-expression in the rule expression, an attriubte-expression exists in the evidence with the same attribute name and a value that matches according to the appropriate attribute-expression matching rules
	If the expressions features an `or` connective:
C3a	for at least one nested XML element or `#PCDATA` contained within the expression, C1 through C3 are satisfied.
	If the expressions features no connective, or an `and` connective:
C3b	for each nested XML element and `#PCDATA` contained within the expression, C1 through C3 are satisfied.
	If the expressions features an `non-or` connective:
C3c	for none of the nested XML element and `#PCDATA` contained within the expression, C1 through C3 are satisfied.
	If the expressions features an `non-and` connective:
C3d	for at least one nested XML element and `#PCDATA` contained within the expression, C1 through C3 are not satisfied.
	If the expressions features an `or-exact` connective:
C3c	for each nested XML element and `#PCDATA` in the evidence, C1 through C3 are satisfied.
	If the expressions features an `and-exact` connective:
C3d	for each nested XML element and `#PCDATA` contained within the expression, and for each nested XML element and `#PCDATA` in the evidence, C1 through C3 are satisfied.

* depending on the appel:connective used in the <appel:RULE> element (compare with C3a-C3d).

Appendices

Appendix A: Future Work

When the first draft of this document was released, the working group felt that, although it had met the requirements it had set, the resulting language was complex and difficult to grasp fully. It was argued that as long no one actually tried to use this language in a real world application it would be hard to assess the suitability of the language design for expressing privacy preferences.

As mentioned in section 1.3 Requirements above, an effort was made to simplify the specification in order to facilitate the implementation of early P3P user agents that would support rulesets expressed in APPEL. By separating a set of extensions from the core language (APPEL 1.0) the working group hopes to encourage early adoptions of APPEL, allowing us to gain some first hand experiences with a privacy preference language before finalizing the full feature set of APPEL.

In future revisions, the working group considers adding the following constructs to the syntax and semantics of the language that have so far been left out (i.e. in APPEL 1.0) in order to allow for simple initial implementations:

Comments to www-p3p-public-comments@w3.org regarding the usability of current and planned features are highly encouraged.

Appendix B: Ruleset Examples

B.1 ALMOST ANONYMOUS

This ruleset provides a nearly anonymous browsing experience. It prompts the user for a decision about Web sites that make an access disclosure other than "identifiable data is not used." It also prompts for Web sites that collect physical contact information, online contact information, financial account identifiers, and data described as "other" data. All prompts imply that all but the absolutely necessary request headers should be suppressed if the user decides to access the resource. It allows for the collection of other kinds of data and the use of state management mechanisms as long as this data will not be shared, will not be used for contacting visitors for marking, will not be used for individual tailoring, and will not be used for purposes described as "other" uses. Users wishing to engage in electronic commerce activities that require the exchange of personal information such as payment and billing information will have to override these settings on a site by site basis.

B.2 PRIVACY AND COMMERCE

This ruleset allows users to exchange personal information needed for electronic commerce activities while providing warning prompts when that information may be shared with legal entities following different practices, public fora, or unrelated third parties; or used for marketing, tailoring, or "other" purposes. A warning prompt will also be provided if the site collects healthcare information. All warnings imply that all but the absolutely necessary request headers should be suppressed if the user decides to access the resource. An informational prompt will be provided at sites that provide no access to identifiable information.

B.3 LOOK FOR THE SEAL

This ruleset allows users to exchange any type of personal information for any purpose with Web sites that have either a "PrivacyProtect" or "TrustUs" seal as long as those sites do not share the information with unrelated third parties. It also allows users to exchange personal information needed for electronic commerce activities with any site, while providing warning prompts (and suppressing unnecessary request headers) when that information may be shared with legal entities following different practices, public fora, or unrelated third parties; or used for marketing, tailoring, or "other" purposes by sites that do not have a seal. An informational prompt will be provided at sites that have seals and collect healthcare information; a warning prompt (again, suppressing all unnecessary headers) will be provided at sites that do not have seals and collect healthcare information. An informational prompt will be provided at sites that provide no access.

<appel:RULESET xmlns:appel="http://www.w3.org/2002/04/APPELv1"
               xmlns:p3p="http://www.w3.org/2000/12/P3Pv1" 
               crtdby="W3C" crtdon="2001-02-19T16:21:21+01:00">
  <appel:RULE behavior="request" 
              description="Service has privacy seal and does not share data
                           with unrelated third parties.">
    <p3p:POLICY>
      <p3p:DISPUTES-GROUP appel:connective="or">
        <p3p:DISPUTES resolution-type="independent" 
                      service="http://www.privacyprotect.org/*"/>
        <p3p:DISPUTES resolution-type="independent" 
                      service="http://www.trustus.org/*"/>
      </p3p:DISPUTES-GROUP>
      <p3p:STATEMENT>
        <p3p:RECIPIENT appel:connective="non-and">
          <p3p:unrelated/>
        </p3p:RECIPIENT>
      </p3p:STATEMENT>
    </p3p:POLICY>
  </appel:RULE>
  <appel:RULE behavior="limited" prompt="yes" 
              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.">
              promptmsg="Warning! 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. Do you want to continue
                         (using limited access)?">
    <p3p:POLICY>
      <p3p:STATEMENT>
        <p3p:PURPOSE appel:connective="and-exact">
          <p3p:current/>
        </p3p:PURPOSE>
        <p3p:RECIPIENT appel:connective="or">
          <p3p:other-recipient/>
          <p3p:public/>
          <p3p:unrelated/>
        </p3p:RECIPIENT>
      </p3p:STATEMENT>
    </p3p:POLICY>
  </appel:RULE>
  <appel:RULE behavior="limited" prompt="yes" 
              description="Service collects data needed for e-commerce 
                           activities but may use it also for marketing,
                           tailoring, or 'other' purposes.">
              promptmsg="Warning! Service collects data needed for e-commerce 
                         activities but may use it also for marketing,
                         tailoring, or 'other' purposes. Do you still
                         want to continue (using limited access)?">
    <p3p:POLICY>
      <p3p:STATEMENT>
        <p3p:PURPOSE>
          <p3p:current/>
        </p3p:PURPOSE>
        <p3p:PURPOSE appel:connective="or">
          <p3p:contact/>
          <p3p:tailoring/>
          <p3p:other-purpose/>
        </p3p:PURPOSE>
      </p3p:STATEMENT>
    </p3p:POLICY>
  </appel:RULE>
  <appel:RULE behavior="request" prompt="yes" 
              description="Site collects healthcare information but
                           participates in a seal program.">
              promptmsg="FYI: This site collects healthcare information but
                         participates in a seal program. Continue?">
    <p3p:POLICY>
      <p3p:DISPUTES-GROUP>
        <p3p:DISPUTES p3p:resolution-type="independent" p3p:service="*"/>
      </p3p:DISPUTES-GROUP>
      <p3p:STATEMENT>
        <p3p:DATA-GROUP>
          <p3p:DATA>
            <p3p:CATEGORIES>
              <p3p:health/>
            </p3p:CATEGORIES>
          </p3p:DATA>
        </p3p:DATA-GROUP>
      </p3p:STATEMENT>
    </p3p:POLICY>
  </appel:RULE>
  <appel:RULE behavior="limited" prompt="yes" 
              description="Site collects healthcare information but
                           does not participate in a seal program.">
              promptmsg="Warning! Site collects healthcare information but does not
                         participate in a seal program. Do you want to continue anyway">
                         (using limited access)?">
    <p3p:POLICY>
      <p3p:STATEMENT>
        <p3p:DATA-GROUP>
          <p3p:DATA>
            <p3p:CATEGORIES>
              <p3p:health/>
            </p3p:CATEGORIES>
          </p3p:DATA>
        </p3p:DATA-GROUP>
      </p3p:STATEMENT>
    </p3p:POLICY>
  </appel:RULE>
  <appel:RULE behavior="request" 
              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.">
    <p3p:POLICY>
      <p3p:DISPUTES-GROUP>
        <p3p:DISPUTES p3p:resolution-type="independent" p3p:service="*"/>
      </p3p:DISPUTES-GROUP>
      <p3p:STATEMENT>
        <p3p:PURPOSE appel:connective="and-exact">
          <p3p:current/>
        </p3p:PURPOSE>
        <p3p:RECIPIENT appel:connective="or-exact">
          <p3p:ours/>
          <p3p:same/>
          <p3p:delivery/>
        </p3p:RECIPIENT>
      </p3p:STATEMENT>
    </p3p:POLICY>
  </appel:RULE>
  <appel:RULE behavior="limited" prompt="yes" 
              description="Service does not provide access to
                           identifiable data it collects">
              promptmsg="Warning! Service does not provide access to identifiable 
                         data it collects. Do you want to continue anyway (using 
                         limited access)?">
    <p3p:POLICY>
      <p3p:ACCESS>
        <p3p:none/>
      </p3p:ACCESS>
    </p3p:POLICY>
  </appel:RULE>
  <appel:RULE behavior="request" 
              description="Privacy policy matches Look For The Seal
                           preferences"> 
    <appel:OTHERWISE/>
  </appel:RULE>
</appel:RULESET>

B.4 INFORMATION ONLY

This ruleset allows users to exchange any type of personal information for any purpose. However, it provides informational prompts when sites collect data for marketing, pseudonymous or individual tailoring, or "other" purposes; share data with legal entities following different practices, public fora, or unrelated third parties; or collect healthcare information.

Appendix C: XML Schema Definition (normative)

This appendix contains the XML schema [ XML Schema 1, XML Schema 2 ] for APPEL ruleset documents. An XML schema may be used to validate the structure and datastruct values used in an instance of the schema given as an XML document. APPEL ruleset documents are XML documents that MUST conform to this schema. The schema is also present as a separate file at the URI APPELv1-20020415.xsd

Appendix D: Document Type Definition (DTD) (informative)

This appendix contains the DTD for policy documents and for data schemas. The DTD is also present as a separate file at the URI APPELv1-20020415.dtd

Appendix E: ABNF Notation (informative)

The formal grammar of APPEL is given in this specification using a slight modification of [ ABNF ]. Please note that such syntax is only a grammar representative of the XML syntax: all the syntactic flexibilities of XML are also implicitly included; e.g. whitespace rules, quoting using either single quote (') or double quote ("), character escaping, comments, and case sensitivity. In addition, note that attributes and elements may appear in any order.

While a special-purpose APPEL engine might be built for use in a P3P user agent, P3P implementors might also consider using an existing database engine or trust engine for this purpose. For example, an SQL engine or an engine for the Keynote Trust Management System [ Keynote ] might prove useful. Use of one of these engines would likely require that the APPEL syntax be translated into the syntax expected by the engine. This could likely be done trivially by a translation script. The Working Group encourages experimentation in this area.

Behavior / Prompt	Element/Set	URI	Disputes	Purpose	Recipient
block / no	category="physical", or category="demographic", or category="uniqueid"				same, other, delivery, public or unrelated
request / no	dynamic.http.useragent, dynamic.clickstream.server		*
request / yes	user.name.*		"PrivacyProtect" and "TrustUs"	current, admin, customization or develop
request / no		www.my-bank.com			ours
limited / yes	[otherwise]

Nikolaj Budzyn	Christian-Albrechts-University of Kiel
Lorrie Cranor	AT&T Labs-Research
Matthias Enzmann	GMD
Marit Köhntopp	Independent Center for Privacy Protection Schleswig-Holstein
Yuichi Koike	NEC
Marc Langheinrich	ETH Zürich (Editor & Chair)
Massimo Marchiori	W3C
Joerg Meyer	IBM
Joseph Reagle	W3C
Drummond Reed	OneName
Rigo Wenning	W3C
Mary Ellen Zurko	Iris (former Chair)

A P3P Preference Exchange Language 1.0 (APPEL1.0)

W3C Working Draft 15 April 2002

Abstract

Status of this Document

Appendix C: XML Schema Definition (normative)

Appendix D: Document Type Definition (DTD) (informative)

Appendix E: ABNF Notation (informative)