A P3P Preference Exchange Language (APPEL)

W3C Working Draft 20 April 2000

This version:

https://www.w3.org/TR/2000/WD-P3P-preferences-20000420

Latest Version:

https://www.w3.org/TR/P3P-preferences

Previous Version:

https://www.w3.org/TR/1998/WD-P3P-preferences-19980814

Editor

Marc Langheinrich, ETH Zurich <langhein@inf.ethz.ch>

Authors

Lorrie Cranor, AT&T Labs-Research
Marc Langheinrich, ETH Zurich
Massimo Marchiori, W3C/MIT

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

---

Abstract

This document complements the P3P1.0 specification 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 Preference Interchange Language 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 https://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 4 April 2000 version 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.

Comments should be sent to www-p3p-public-comments@w3.org. This is the preferred method of providing feedback. Public comments and their responses can be accessed at https://lists.w3.org/Archives/Public/www-p3p-public-comments/. Alternatively, if you do not wish your comment to be made public, you can send your comment to p3p-comments@w3.org. In this case, your comments will only be accessible to W3C members (at https://lists.w3.org/Archives/Member/p3p-comments/).

Contents

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. Much of the underlying logic is based on PICSRules. We hope in time that this will merely be an application of XML (XML-data) rules or query languages.

1.1 P3P Basics

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.

A basic P3P interaction might proceed as follows:

1. The agent requests a Web page from a service.
2. The service responds by sending a reference to a P3P policy in the header of its HTTP response. A policy consists of one or more statements about a service's privacy practices.
3. The agent fetches the policy, evaluates it according to the user's ruleset (which represents her preferences) and determines what action to take (e.g., simply informing the user about the privacy policy in place, or prompting her for a decision).

1.2 Goals of A P3P Preference Exchange Language

• Sharing and installation of rulesets. Sophisticated preferences may be difficult for end-users to specify, even through well-crafted user interfaces. An organization can create a set of recommended preferences for users. Users who trust that organization can install a pre-defined ruleset rather than specifying a new set from scratch. It will be easy to change the active ruleset on a single computer, or to carry a ruleset to a new computer.
• Communication to agents, search engines, proxies, or other servers. Servers of various kinds may wish to tailor their output to better meet users' preferences, as expressed in a ruleset. For example, a search service might return only links that match a user's ruleset, which may specify criteria based on a variety of factors including quality, privacy, age suitability, or the safety of downloadable code.
• Portability between products. The same ruleset will work with any P3P-APPEL enabled product.

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

• APPEL rules should allow the expression of preferences over anything that can be expressed in the P3P base schema as well as all other XML metadata relevant to P3P decision making (e.g., is the communication channel secured). (APPEL rules may express preferences over PICS labels if they are translated into an appropriate XML schema.)
• APPEL should address situations in which a service does not offer a P3P policy.
• APPEL rules should be able to prescribe the following set of behaviors: accept, reject, inform and warn. In addition, APPEL should include extensibility mechanisms that allow rules to describe additional behaviors.
• APPEL encoding should be consistent with other P3P work and leverage members' existing work and code base. As much as possible, the encoding should be simple and support the efficient computation of rule matches.

The working group limited the scope of APPEL as follows:

• APPEL rules need not allow the expression of "sophisticated" rules based on the presence of multiple data elements within a P3P policy (for example, a rule that would allow a zipcode to be collected unless a full name is also collected).
• APPEL need not be capable of expressing rules for ranking multiple policies. Rather it expresses the rules necessary for determining whether a single policy triggers a behavior. If more than one P3P policy is available, they should be submitted to the rule evaluator individually. It is up to the calling program to determine what to do if multiple policies are acceptable, or if a "prompt" behavior (i.e. inform or warn) is returned while evaluating multiple policies.
• A compact or easy-to-read representation is not essential.
• APPEL need not be capable of expressing negotiation strategies.
• APPEL rules need not be able to express preferences based on state information (unless such information is encoded in XML and submitted to an APPEL engine as any other metadata would be submitted).

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

• only support four standard behaviors, accept, reject, inform and warn (i.e. no custom behaviors).
• only support preferences over P3P policies and a limited set of metadata.
• only support restricted matching capabilities using a limited set of comparison operators and wildcards.

The remainder of this document will discuss the thus simplified version of APPEL, refered to as the Level 1 specification. See Appendix A for a list of further planned extensions regarding the full APPEL syntax, from here on refered to as the Level 2 specification.

1.4 APPEL and P3P policies

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.

<POLICY xmlns="https://www.w3.org/2000/P3Pv1">
  <ENTITY>
    <DATA name="business.name">TheCoolCatalog</DATA>
    <DATA name="business.contact-info.postal.street.line1">123 Main Street</DATA>
    <DATA name="business.contact-info.postal.city">Bethesda</DATA>
    <DATA name="business.contact-info.postal.stateprov">MD</DATA>
    <DATA name="business.contact-info.postal.postalcode">20814</DATA>
    <DATA name="business.contact-info.postal.countrycode">US</DATA>
  </ENTITY>
  <DISPUTES-GROUP>
     <DISPUTES resolution-type="independent" 
      service="https://www.PrivacySeal.org" 
      description="PrivacySeal.org"
      image="https://www.PrivacySeal.org/Logo.gif"/>
  </DISPUTES-GROUP>
  <DISCLOSURE 
   discuri="https://www.TheCoolCatalog.com/PrivacyPractice.html" 
   access="none"/>
  <STATEMENT>
     <CONSEQUENCE-GROUP>
       <CONSEQUENCE>a site with clothes you would appreciate</CONSEQUENCE>
     </CONSEQUENCE-GROUP>
     <RECIPIENT><ours/>/RECIPIENT>
     <PURPOSE><custom/><develop/></PURPOSE>
     <RETENTION><indefinitely/></RETENTION>
     <DATA-GROUP>
       <DATA name="dynamic.cookies" category="state"/>
       <DATA name="dynamic.miscdata" category="preference"/>
       <DATA name="user.gender"/>
       <DATA name="user.home." optional="yes"/>
     </DATA-GROUP>
  </STATEMENT>
  <STATEMENT>
    <RECIPIENT><ours/></RECIPIENT>
    <PURPOSE><admin/><develop/></PURPOSE>
    <RETENTION><indefinitely/></RETENTION>
    <DATA-GROUP>
      <DATA name="dynamic.clickstream.server"/>
      <DATA name="dynamic.http.useragent"/>
    </DATA-GROUP>
  </STATEMENT>
</POLICY>

1.5 Definitions

behavior

The activity taken upon the successful matching of a rule. While APPEL Level 1 only supports four standard behaviors (accept, reject, inform and warn), Level 2 also allows user agents to define custom behaviors.

behavior, standard

The four behaviors that have to be supported by every APPEL user agent: accept, reject, inform and warn. APPEL Level 2 additionally allows user agents to define a set of custom behaviors. Please note that APPEL Level 1 does not allow for custom behaviors.

connective

An attribute of an expression that determines how any contained expressions will be matched. APPEL Level 1 supports four connectives: or, and, or-exact and and-exact. See section 5.4.3 Connectives for more details.

data repository

A mechanism for storing user information under the control of the user agent.

evidence

A P3P application provides an APPEL rule evaluator with an APPEL ruleset and various pieces of evidence. This evidence could for example include the URI of the service and a P3P policy from the service if present. Evidence should be presented in the form of XML elements, although implementations are free to use other formats internally.

expression

A component of a rule that is expressed as an XML element and that can be evaluated to TRUE or FALSE with respect to some (piece of) evidence. An expression consists of

1. an element identifier (element name)
2. zero or more attribute expressions
3. zero or more contained expressions
4. an optional connective

See sections 2.2 Expressions for a list of expressions and 5.3 Expressions for details on how they match available evidence. Please note that APPEL Level 1 only allows for the <POLICY> and <APPEL:REQUEST> elements to be used as the (top-level) expression in a rule.

expression, attribute

An attribute-value pair contained in an expression. They can be used to compare the values of two strings surrounded by quotes (i.e. the value of an attribute) or test for the presence or absence of a particular attribute without checking for a particular value (when used with wildcards). Please see section 5.4.1 Matching Attribute Expressions for more information.

expression, contained

An expression that is enclosed in another expression, i.e. an XML element that is enclosed in another (non-APPEL) XML element. In order for an expression to match, some or all of its contained expressions (depending on the connective used) have to match as well. See section 5.3 Expressions for details.

expression, degenerate

An expression that always evaluates to true. See section 4.2.3 The <OTHERWISE> element.

expression, top-level

The expressions contained immediately below an <APPEL:RULE> element. In APPEL Level 1, the top-level expression can only be a <POLICY> or <APPEL:REQUEST> element, or the degenerate expression.

persona

A unique identifier for a set of data element values in the user's data repository that the user wants to use during the current browsing session. Implementations could offer to store multiple values for the same data element and allow users to conveniently choose between certain sets of values when giving out information from the repository (e.g. a set of values to be used in the office and a a different set to be used on weekends).

preference (privacy, not qualified in use)

The user's desires regarding the collection and treatment of information exchanged under P3P and HTTP. Privacy preferences are formally expressed by a set of APPEL rules and should preferably be captured through a GUI.

policy (privacy, not qualified in use)

A site's privacy practices, as expressed in its P3P policies.

policy, P3P

A P3P policy is a collection of one or more privacy statements together with information asserting the identity, URI, assurances, and disclosures of the service covered by the policy. The format of such a P3P policy is defined in the P3P 1.0 Specification

rule

The formal expression of a user's preference. Rules express the users preferences that are then compared to a services P3P policy. The action resulting from a successful match is defined by the behavior specified by the rule. The rule is delimited by an opening and closing element of the form
<APPEL:RULE behavior="...">rule</APPEL:RULE>

rule evaluator

Process responsible for comparing a user's privacy preferences (for example in form of an APPEL ruleset) with a P3P policy sent from a service. See also comments in Appendic C: Trust Engines and Database Engines.

ruleset

A set of rules that define all of the user's P3P preferences.

schema, P3P base

schema defined in the P3P 1.0 Specification.

service

A program that issues policies and (possibly) data requests. By this definition, a service may be a server (site), a local application, a piece of locally active code, such as an ActiveX control or Java applet, or even another user agent. In most cases this will be a P3P-enabled Web server.

statement, P3P

A P3P statement is a set of privacy practice disclosures relevant to a collection of data elements, sets, and categories. The enumerated elements act as an embedded data request. A statement which references no data, requests no data.

trust engine

See rule evaluator.

user

An individual (or group of individuals acting as a single entity) on whose behalf a service is accessed and for which personal data exists.

user agent

A program that acts on a user's behalf. The agent may act on preferences (rules) for a broad range of purposes, such as content filtering, trust decisions, or privacy. For P3P purposes, a user agent acts on a user's privacy preferences. Users may use different user agents at different times.

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

MUST

This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.

MUST NOT

This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.

SHOULD

This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

SHOULD NOT

This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

MAY

This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)

2. General Operation and Semantics

2.1 Inputs and Outputs of the Rule Evaluator

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 attribute) of the rule that fired on the basis of the evidence discussed above as well as a copy of the policy that triggered the rule. The latter might not necessarily be identical with the original policy found in the evidence, particulary if it contained optional elements that were not matched by the rule. In addition, the rule evaluator may optionally return an explanation string (suitable for user display), the name of a persona, and/or the rule that fired.

Applications should interpret the standard outputs as follows:

• "accept": the provided evidence is acceptable. If a P3P policy is provided, it SHOULD be accepted seamlessly (i.e. without consulting the user). If a URI is provided, the resource at that URI SHOULD be accessed. Note that P3P 1.0 does not support the concept of binding agreements: Acceptance of a policy only indicates a corresponding user agent behavior (i.e. displaying certain "acceptance"-symbols), not a legal agreement. This functionality might be extended if later versions of P3P support this.
• "reject": the provided evidence is not acceptable. If a P3P policy is provided, it SHOULD be rejected seamlessly. If a URI is provided, the resource at that URI SHOULD NOT be accessed. Note that in some instances of the P3P 1.0 protocol, the resource URI might have already been accessed in order to receive a the P3P policy URI. In these cases it is up to the calling program to determine what information to present to the user.
• "inform": information SHOULD be provided to the user. It is up to the calling program to determine how the information should be provided. It may be provided, for example, in the form of a visual or audio signal, or a prompt that requires a user response. However, the context of the information should be informational and SHOULD NOT suggest to users that their privacy preferences are being violated. For example, an inform prompt might state "x.y.com has requested that your home address be provided so that your order can be processed. Would you like to proceed or cancel your request?"
• "warn": a warning SHOULD be provided to the user. It is up to the calling program to determine how the user should be warned. It may be provided, for example, in the form of a visual or audio signal, or a prompt that requires a user response. However, the context of the information SHOULD be a warning that the policy may violate the user's privacy preferences. For example, a warn prompt might state "Warning: x.y.com has requested that your home address be provided so that your order can be processed. Your preferences state that you do not wish to provide your home address under such circumstances. Would you like to override your preferences or cancel your request?"

2.2 Rule Processing and Evaluation

2.2.1 Rule Processing

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. User Agents that wish to provide additional information in case a policy is not accepted (such as listing all reasons why it was rejected, not only the first one that led to "reject") might require further evaluation in order to provide such information to the user.

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 "accept".

Further information on rule processing can be found in sections 5.1 The Rule Evaluator in a nutshell and 5.2 Rules ordering.

2.2.2 Expressions

1. expression: uses attribute- and contained-expressions to match a full XML element in the evidence.
2. attribute expression: matches a single attribute and its value in an XML element.
3. contained expression: recursively matches contained subelements of an XML element.

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):

1. an element identifier (element name)
2. zero or more attribute expressions
3. zero or more contained expressions
4. an optional connective

Attribute-expressions may take string or numeric values, although APPEL will treat all values as simple strings. APPEL Level 1 supports only the equality operator in attribute-expressions (APPEL Level 2 might additionally offer comparison operators such as "<" less-than and ">" greater-than for matching numeric values).

APPEL offers a single wildcard metacharacter "*" which 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). Further details are given in sections 5.4.1 Attribute Expressions and 5.4.2 Regular Expression Metacharacters.

2.2.3 Rule Evaluation

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 four such connectives: or, and, or-exact, and and-exact. If no connective is given, APPEL defaults to requiring and-exact matches: only if the elements in the evidence are identical to those given in the rule, 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

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

1. Requests for personal information which will be given out to 3rd parties should be rejected.
2. The user does not mind revealing click-stream and user agent information to sites that collect no other information. However, she insists that the service provides some form of assurance.
3. The user is comfortable with giving out her first and last name, as long as it is for non-marketing purposes. She requires assurances (i.e., dispute information) from both "PrivacyProtect and "TrustUs" before trusting such a statement. However, she always wants to be explicitly informed about such cases before actually transfering this information.
4. When interacting with her bank's Web site at https://www.my-bank.com, she accepts any data request as long as her data is not redistributed to other recipients.
5. All other requests for data transfer should be prompted for (indicating a conflict with her privacy preferences) and will be decided by the user on a site-by-site basis.

3.2 Tabular Overview

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.2 Regular Expression Metacharacters. In row three 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

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, an "accept" 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 accepts if dispute information is available.

An "inform" rule 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 "warn"-rule encapsulating the degenerate expression "APPEL:OTHERWISE" will fire, warning the user to (cautiously) decide on any policy that has not been covered by any of the rules above.

000: <APPEL:RULESET xmlns:APPEL="https://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="https://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="https://www.privacyprotect.com"/>
065:         <DISPUTES service="https://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 Example Explanation

[1] ruleset = '<APPEL:RULESET xmlns="https://www.w3.org/2000/APPEL" '
                 attributes '>'
                 rseq
              '</APPEL:RULESET>'
 
[2] rseq    = 1*rule

[3] rule     = '<APPEL:RULE behavior="' behavior '"'
                  attributes '>' 
                      body
               '</APPEL:RULE>'

[5] body     = top-expression | '<APPEL:OTHERWISE/>'

[6] behavior = 'accept' | 'reject' | 'inform' | 'warn'

[4] attributes = [' persona=' quoted-string]
                 [' crtby=' quoted-string]
                 [' crton="' datetime '"']
                 [' description=' quoted-string]

[7] top-expression = policy | request [policy]    

[8] policy         = <[P3P10] policy (optionally with embedded connectives)> 

[9] request-group  = '<APPEL:REQUEST-GROUP ' [connective] '>'
                          1*request
                     '</APPEL:REQUEST-GROUP>'

[10] request       = '<APPEL:REQUEST uri="' [URI] as per RFC 2396 '"/>'

[11] connective      = 'APPEL:connective="' conn '"'

[12] conn            = or | and | or-exact | and-exact

4. Technical Definition

4.1 Syntax & Encoding

4.1.1 BNF Syntax, APPEL Level 1 (non-normative)

[1] ruleset          = '<APPEL:RULESET xmlns="https://www.w3.org/2000/APPEL" '
                          attributes '>'
                          rseq
                       '</APPEL:RULESET>'
      
[2] rseq             =  1*rule 

[3] rule             = '<APPEL:RULE behavior="' behavior '"'
                         attributes '>' 
                            body
                       '</APPEL:RULE>'
      
[4] attributes       = [' persona=' quoted-string]
                       [' crtby=' quoted-string]
                       [' crton="' datetime '"']
                       [' description=' quoted-string]
      
[5] body             = top-expression | '<APPEL:OTHERWISE/>'

[6] behavior         = 'accept' | 'reject' | 'inform' | 'warn'

[7] top-expression   = policy | request-group [policy]

[8] policy           = <[P3P10] policy (optionally with embedded connectives)> 

[9] request-group    = '<APPEL:REQUEST-GROUP ' [connective] '>'
                          1*request
                       '</APPEL:REQUEST-GROUP>'

[10] request         = '<APPEL:REQUEST uri="' [URI] as per RFC 2396 '">'

[11] connective      = 'APPEL:connective="' conn '"'

[12] conn            = or | and | or-exact | and-exact

[13] quoted-string   = '"' string '"'

[14] string          = <[UTF-8] string (with " and & escaped)>

[15] datetime        = <date/time as per section 3.3 of [RFC 2068]>      

Details are described in section 4.2 Elements below. Please see also Appendix 7.3 APPEL Level 2 Specification.

4.1.2 Transport & Storage

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

4.2.1 The <APPEL:RULESET> element

<APPEL:RULESET>

This tag is the delimiter that denotes an APPEL file. It includes a sequence of one or more rules. Each rule features a certain behavior that is returned to the calling program if the expressions listed in the rule all evaluate to true.

persona

If the user agent supports multiple user repositories, this string identifies the data repository that should be used. If no persona is given, the default persona should be used. Note that this value can be overridden on the <RULE> level.

crtby

Name or ID of the ruleset author (could be the user agent).

crton

Time & Date of ruleset creation.

description

A short natural language explanation that can be displayed by the user agent when the ruleset gets selected, or to help debugging a rulefile.

[1] ruleset          = '<APPEL:RULESET xmlns="https://www.w3.org/2000/APPEL" '
                          attributes '>'
                          rseq
                       '</APPEL:RULESET>'
 
[2] rseq             =  1*rule 

[4] attributes       = [' persona=' quoted-string]
                       [' crtby=' quoted-string]
                       [' crton="' datetime '"']
                       [' description=' quoted-string]

4.2.2 The <APPEL:RULE> element

<APPEL:RULE>

Contains conditions under which a certain behavior should be carried out by the calling program.

behavior     (mandatory attribute)

Behavior that should be carried out by the calling program if the expressions match the evidence.

persona

If the user agent supports multiple user repositories, this string identifies the data repository that should be used. If no persona is given, the corresponding value of the enclosing <RULESET> is used.

crtby

Name or ID of the rule author (could be the user agent).

crton

Time & Date of rule creation.

description

A short natural language explanation that can be displayed by the user agent when the rule gets executed, or to help debugging a rulefile.

The top-level expressions directly enclosed by an <APPEL:RULE> element MUST always be matched with an exact match (see section 5.4.4 Connectives) -- there is no way in APPEL Level 1 to specify a different matching semantics for the topmost elements.

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 if a site does not offer any P3P policy. A rule with an empty list of expressions will never get activated. In order to create a default rule which will trigger if no other (preceding) rule fired, the degenerate expression <OTHERWISE/> should be used.

[3] rule             = '<APPEL:RULE behavior="' behavior '"'
                         attributes '>' 
                            body
                       '</APPEL:RULE>'
      
[4] attributes       = [' persona=' quoted-string]
                       [' crtby=' quoted-string]
                       [' crton="' datetime '"']
                       [' description=' quoted-string]
      
[5] body             = top-expression | '<APPEL:OTHERWISE/>'

[6] behavior         = 'accept' | 'reject' | 'inform' | 'warn'

[7] top-expression   = policy | request [policy] 

4.2.3 The <APPEL:OTHERWISE> element

<APPEL:OTHERWISE>

so called degenerate-expression, which always evaluates to true. This can be used to craft "catch-all" rules which match all cases not covered by previous rules.

<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 accept behavior, which would result in unlimited access to a user's data repository for sites not covered by the preceding rules! User agents MUST refuse to accept rulesets with such "catch-all" accept rules.

[5] body             = top-expression | '<APPEL:OTHERWISE/>'

4.2.4 The <APPEL:REQUEST> element

<APPEL:REQUEST>

allows the creation of rules that only apply to a certain resource or domain.

uri     (mandatory attribute)

the URI of the currently requested resource (not the policy URI).

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.

[7] expression       = policy | request | 1*<A chunk of XML code (optionally with embedded connectives)>

[8] policy           = <[P3P10] policy (optionally with embedded connectives)>

[9] request-group    = '<APPEL:REQUEST-GROUP ' [connective] '>'
                          1*request
                       '</APPEL:REQUEST-GROUP>'

[10] request         = '<APPEL:REQUEST uri="' [URI] as per RFC 2396 '">'

4.2.5 The APPEL:connective attribute

APPEL:connective

determins how contained expressions are matched when a rule is compared to the available evidence.

APPEL supports four different kinds of connectives: or, and, or-exact and and-exact. Please refer to section 5.4.3 Connectives for a description of their semantics. If no APPEL:connective is given, APPEL's matching semantics default to an and-exact match: All of the contained?expressions must appear in the evidence, and no additional elements must be present.

[11] connective      = 'APPEL:connective="' conn '"'

[12] conn            = or | and | or-exact | and-exact

5 Semantics

5.1 The Rule Evaluator in a Nutshell

The rule evaluator MUST return a behavior (i.e., one of the four standard behaviors "accept", "reject", "inform" or "warn") that the calling program should carry out, as well as a copy of the policy that triggered the rule. Please note that the latter might not necessarily be identical with the original policy found in the evidence, particulary if it contained optional elements that were not matched by the rule! In addition, the rule evaluator 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

5.1.2 Rulesets

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 "accept".

5.1.3 Expressions

All top-level expressions in a rule are implicitly ANDed together. Each expression in turn is implicitly ANDed together with all of its enclosed attribute expressions. Contained 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 which 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

How APPEL evaluates multiple rules in a ruleset

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

How to specify what to match in a rule

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 contained expressions of an element.

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., exact) unless another connective attribute is used within the contained expression. See section 5.4.3 Connectives for details.

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

[1] expression            = empty-expression | containing-expression

[2] empty-expression      = "<" element-name *attribute-expression "/>"
      
[3] containing-expression = "<" element-name *attribute-expression [connective]">"
                                1*contained-expression
                            "</" element-name ">" 

[4] element-name          = identifier
      
[5] attribute-expression  = attribute_name "=" quoted-string
      
[6] contained-expression  = expression
      
[7] attribute_name        = identifier

[8] identifier            = <a valid XML identifier>

[8] quoted-string         = `"` string `"`

[9] string                = <[UTF-8] string (with " and & escaped)>

[10] connective           = 'APPEL:connective="' conn '"'

[11] conn                 = or | and | or-exact | and-exact

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.

<-- ruleset -->

<APPEL:RULE behavior="inform">
  <POLICY APPEL:connective="and">
    <STATEMENT APPEL:connective="and">
      <RECIPIENT APPEL:connective="or-exact">
        <ours/>
      </RECIPIENT>
      <DATA-GROUP APPEL:connective="or-exact">
        <DATA name="user.*"/>
      </DATA-GROUP>
    </STATEMENT>
    <STATEMENT APPEL:connective="and">
      <PURPOSE APPEL:connective="or-exact">
        <custom/>
      </PURPOSE>
      <DATA-GROUP APPEL:connective="or-exact">
        <DATA category="online"/>
      </DATA-GROUP>
    </STATEMENT>
  </POLICY>
</APPEL:RULE>

<-- evidence (abbreviated) -->

<POLICY>
  ...
  <STATEMENT>
      <RECIPIENT><ours/></RECIPIENT>
      <PURPOSE><custom/></PURPOSE>
      <DATA-GROUP>
        <DATA name="user.home.online.email"/>
      </DATA-GROUP>
  </STATEMENT>
</POLICY>

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 or-exact 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 or and-exact 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.

Please note that matching any evidence other than a P3P policy or request information requires the use of APPEL Level 2. When using APPEL Level 1 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

How APPEL matches expressions against available evidence

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.3 Connectives below) and can be summarized as follows:

1. All attribute expressions in a rule are ANDed, additional attributes are ignored.
   Attributes are ANDed within a single element, that is all attributes in an expression have to appear in a single element in the evidence. Any attribute in the evidence that can not be found in the element in the rule is ignored.
2. Contained expressions are...
   
   1. ...ORed (or and or-exact connectives)
      At least one contained expression in the current expression has to match an element in a corresponding element of the evidence.
   2. ...ANDed (and and and-exact connectives)
      Any contained element listed in the expression has to appear in a corresponding position in the evidence, with matching attributes and values.
3. Additional evidence (non-attribute)...
   1. ...is ignored (or and and connectives)
      Any element listed in the evidence which can not be found in the rule (or which can be found but without matching attributes and values) will be ignored
   2. ...is not ignored (or-exact and and-exact connectives)
      Any element listed in the evidence which can not be found in the rule (or which can be found but without matching attributes and values) will prompt the rule to fail.

5.4.1 Attribute Expressions

1. the attribute names are identical
2. AND the values are identical (using string comparison)

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.

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.

Please note that 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 <DISCLOSURE> elements without access attribute), nor that a certain element is absent from the evidence (e.g. matching policies that do not include a disputes field).

5.4.2 Attribute Expression Metacharacters

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 APPEL Level 1.

Please note also that the wildcard character is only allowed within quoted strings, not for matching attribute names or element names, for example such as in <DISPUTES res*="service"> or <DISP* resolution-type="service">! While it can be applied in the above manner to match ranges of data elements (i.e. subtrees) when used in data-reference expressions (<DATA name="user.*"/>), it can not be used to match a set of data set leafs: <DATA name="*.zipcode"/>!

5.4.3 Connectives

or

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.

and

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.

or-exact

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. Using this connective ensures that only those elements listed in the rule appear in the evidence.

and-exact

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. Using this connective ensures that the elements listed in the rule are identical with the evidence -- no elements are missing, no additional elements appear. This is the default matching semantics if no connective is given.

The top level expressions right below the <APPEL:RULE> element are always matched using exact matching. Connectives can only be used in elements below the <APPEL:RULE> element. If no connective is given, an exact match is performed. Connectives only govern matching of the immediate contained-expressions, they do not propagate downward (inheritance). If these contained-expressions in turn contain other expressions, new connectives need to be specified at that level, or the default exact connective applies again.

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

5.4.4 Matching optional data elements

A simple mechanism for matching a policy with optional data elements against a rule is given below. User agent implementors will probably want to use a more efficient startegy:

1. For each rule in the ruleset
   1. Make a copy of the original policy and place it into the pool of evidence.
   2. While the policy in the evidence fails to match the rule and optional data elements exist:
      1. remove one optional data element at random.
   3. If the rule matches the (possibly altered) policy, return both the behavior of the rule and the copy of the policy.

5.4.5 Matching optional and mandatory extensions

Such extensions, both mandatory and optional, can be matched in APPEL in very much the same way as optional <DATA> elements are matched (compare section 5.4.4 Matching optional data elements): Rule evaluators MUST be able to selectively remove extension tags that are tagged as being optional and repeatedly compare the user's ruleset with the thus altered evidence. In case of a match after any optional extension has been removed, the rule evaluator MUST return a copy of the altered policy that triggered the rule, together with the triggered behavior.

Note that is up to the calling application to determine whether an extension referenced in a P3P policy file is supported or not. This should presumably be done before the rule evaluator is invoked, for example at the same time the available P3P policy is syntactically validated.

5.4.6 Category translation support

P3P categories are attributes of data reference elements which 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 implement and 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.

The following sections describe the two different cases that must be supported by an APPEL trust engine: rules that refer to named data reference elements using explicit categories, for example as in

<DATA name="dynamic.cookies" category="navigation"/>,

<DATA category="preference"/>

Named, categorized data reference elements

However, for a certain number of elements the base data set does not specify a fixed category but instead requires the author of a P3P policy to explicitly list the categories this element is used for in this particular situation. These elements are called "variable-category data elements, and only for data reference expressions referencing those elements the APPEL rule evaluator must support the additional use of the category attribute.

The following pseudo-code summarizes the steps necessary to match named data reference elements that optionally feature an explicit category attribute:

1. Check the P3P base data set for the defined category of the named data reference element.
   1. If one or more fixed categories are defined, ignore any additional category attributes (in both the rule and the evidence). Alternatively, a user agent could indicate an error in the rule file, preferably during a preliminary parsing step right after the rulefile is loaded into the application.
   2. If no fixed category is defined in the base set, or if the element is not part of the base set, require the use of an explicit category attribute in both the evidence. Only elements in the rule that correctly match the category attribute of their corresponding evidence element are allowed -- all cases where no category is given or where the category values do not match cause the rule to fail.
2. Use the matching process described in 5.4 Matching above to match all data elements in the rule.

Category-only data reference elements (Category expansion)

Category-only data reference elements are <DATA> elements that contain only a category attribute, but no name attribute. Upon encountering such a category-only data reference element in a rule, an APPEL rule engine must implicitly translate each referenced category into the list of base elements that belong into that category, effectively representing the rule as if every element from the P3P base data set belonging to this category had been explicitly listed instead.

Figure 5.4 below shows an example. In addition to any fixed-category data element ("user.home.online.*" and "user.business.online.*") the expansion also needs to take into account any variable-category data elements ("dynamic.cookies" and "dynamic.miscdata") by augmenting them with the proper category.

Any custom data schemes that have been introduced by the service as to belonging to the referenced category will also be matched by this mechanism. Please note again that user agents MUST NOT allow services to override the category of fixed category base elements, such as for example "user.name.first" or "user.home.postal.city".

It is up to APPEL trust engine implementations whether they explicitly expand rules containing category-only data reference elements, or if they instead augment each data reference element in the evidence with the corresponding category (or with multiple elements each featuring a different category, if multiple categories are defined for the element) and simply match the category attributes directly.

5.5 Matching Summary & Examples

5.5.1 Matching Semantics in Pseudocode

An expression "E" matches a piece of evidence "X" (i.e. a certain XML element in the evidence) if and only if all of the following holds:

1. the element names of E and X are identical
2. all of E's attribute expressions match attributes of X (additional attributes in evidence X which are not referenced in expression E are ignored)
3. [if an or connective is given in E] at least one of E's contained expressions (if any) match X's enclosed elements (additional enclosed elements in evidence X which are not referenced in expression E are ignored).
4. [if an and connective is given in E] all of E's contained expressions (if any) match X's enclosed elements (additional enclosed elements in evidence X which are not referenced in expression E are ignored).
5. [if an or-exact connective is given in E] at least one of E's contained expressions (if any) match X's enclosed elements (additional enclosed elements in evidence X which are not referenced in expression E are not ignored).
6. [if an and-exact connective, or if no connective is given in E] all of E's contained expressions (if any) match X's enclosed elements (additional enclosed elements in evidence X which are not referenced in expression E are not

5.5.2 Sample Matching Algorithm

For each expression in the rule, find a match in the evidence such that the following conditions (C1-C3) hold:

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 contained within the expression, C1 through C3 are satisfied.
	If the expressions features an and connective:
C3b	for each nested XML element contained within the expression, C1 through C3 are satisfied.
	If the expressions features an or-exact connective:
C3c	for each nested XML element in the evidence, C1 through C3 are satisfied.
	If the expressions features no connective, or an exact connective:
C3d	for each nested XML element contained within the expression, and for each nested XML element in the evidence, C1 through C3 are satisfied.

If a match can be found for every expression, then the rule fires.

Appendices

Appendix A: APPEL Level 2 Specification

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 (Level 2) from the core language (Level 1) 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 its Level 2 revision, the working group plans to add the following constructs to the syntax and semantics of the language that have previously been left out (i.e. in Level 1) in order to allow for simple initial implementations:

• Extensible behaviors: User Agents (e.g. browsers) can define their own set of behaviors and let rules use them. In order to preserve portability accross different user agents, a fallback mechanism guarantees that a known behavior is always executed.
• Matching external schemas: Expressions can contain <POLICY> elements as well as external elements such as PICS labels or Protocol features (e.g. "SSL in use").
• Optional rules: Rules that are truly cosmetic can be ignored should a non-standard behavior be unknown to the particular user agent in use.
• Optional schemas: Expressions can be tagged optional and thus allow rule execution even if a referenced schema is not available (e.g. no information about the status of the Protocol Security, no existing P3P policy, etc).
• Groups & Triggers: Sets of rules can be collated into groups allowing selective activation of certain privacy preferences depending on triggers such as URLs, PICS labels, etc.
• Comparison operators for simple numeric expressions: Ranges of allowed values can be expressed by using common mathematical comparison operators such as <, >, <=, >=, etc.
• Expiration dates: Rules and Groups can be set to expire at a certain point, allowing user agents (and users) to create temporary rules.

Appendix B: Ruleset Examples (Level 1)

B.1 ALMOST ANONYMOUS

<APPEL:RULESET xmlns:APPEL="https://www.w3.org/2000/APPEL"
               crtdby="W3C" crtdon="15-March-2000 10:55:32 GMT">

  <APPEL:RULE behavior="warn" 
     description="Service collects some kind of identifiable information">  
    <POLICY APPEL:connective="or">
      <DISCLOSURE access="contact" />
      <DISCLOSURE access="other" />
      <DISCLOSURE access="contact_and_other" />
      <DISCLOSURE access="all" />
      <DISCLOSURE access="none" />
    </POLICY>
  </APPEL:RULE>

  <APPEL:RULE behavior="warn" 
     description="Service collects physical and/or online contact 
                  information and/or financial account identifiers and/or
          other data that may be personally-identifiable">  
    <POLICY APPEL:connective="and">
      <STATEMENT APPEL:connective="and">
        <DATA-GROUP APPEL:connective="or">
            <DATA category="physical"/>
            <DATA category="online"/>
            <DATA category="uniqueid"/>
            <DATA category="financial"/>
            <DATA category="other"/>
        </DATA-GROUP>
      </STATEMENT>
    </POLICY>
  </APPEL:RULE>

  <APPEL:RULE behavior="accept" 
     description="service does not collect identifiable data or share
                  data with other parties">  
    <POLICY APPEL:connective="and">
      <STATEMENT APPEL:connective="and">
        <RECIPIENT APPEL:connective="and-exact">
          <ours/>
        <RECIPIENT/>
        <PURPOSE APPEL:connective="or-exact">
             <current/><admin/><develop/><custom/><targeting/>
        </PURPOSE>
        <DATA-GROUP APPEL:connective="or-exact">
            <DATA name="user.*"/>
            <DATA name="dynamic.*" category="state"/>
        </DATA-GROUP>
     </STATEMENT>
    </POLICY>
  </APPEL:RULE>

  <APPEL:RULE behavior = "warn"
    description = "service requests data from your data repository or
                   has a practice that doesn't match your preferences">
      <APPEL:OTHERWISE/>
  </APPEL:RULE>
</APPEL:RULESET>

B.2 PRIVACY AND COMMERCE

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

  <APPEL:RULE behavior="warn" 
     description="Data may be shared with legal entities following 
                  different practices, public fora, or unrelated third
          parties.">  
    <POLICY APPEL:connective="and">
      <STATEMENT APPEL:connective="and">
        <RECIPIENT APPEL:connective="or">
          <other/><public/><unrelated/>
        <RECIPIENT/>
      </STATEMENT>
    </POLICY>
  </APPEL:RULE>

  <APPEL:RULE behavior="warn" 
     description="Data may be used for marketing, profiling or "other"
          purposes.">  
    <POLICY APPEL:connective="and">
      <STATEMENT APPEL:connective="and">
        <PURPOSE APPEL:connective="or">
             <contact/><profiling/><other/>
        </PURPOSE>
      </STATEMENT>
    </POLICY>
  </APPEL:RULE>

  <APPEL:RULE behavior="warn" 
     description="Site collects healthcare information.">
    <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="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 Privacy And Commerce preferences">
      <APPEL:OTHERWISE/>
  </APPEL:RULE>
</APPEL:RULESET>

B.3 LOOK FOR THE SEAL

<APPEL:RULESET xmlns:APPEL="https://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="https://www.privacyprotect.org*" />
        <DISPUTES resolution-service="independent"
                 service="https://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

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

  <APPEL:RULE behavior="inform" 
     description="Service collects data for marketing, profiling, 
                  or "other" purposes.">  
    <POLICY APPEL:connective="and">
      <STATEMENT APPEL:connective="and">
        <PURPOSE APPEL:connective="or">
             <contact/><profiling/><other/>
        </PURPOSE>
      </STATEMENT>
    </POLICY>
  </APPEL:RULE>

  <APPEL:RULE behavior="inform" 
     description="Service shares information with legal entities 
                  following different practices, public fora, or unrelated third
                  parties.">  
    <POLICY APPEL:connective="and">
      <STATEMENT APPEL:connective="and">
        <RECIPIENT APPEL:connective="or">
          <other/><public/><unrelated/>
        <RECIPIENT/>
      </STATEMENT>
    </POLICY>
  </APPEL:RULE>

  <APPEL:RULE behavior="warn" 
     description="Site collects healthcare information.">
    <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 = "privacy policy matches Information Only preferences">
      <APPEL:OTHERWISE/>
  </APPEL:RULE>

</APPEL:RULESET>

Appendix C: Trust Engines and Database Engines

Appendix D: 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.

The following is a simple description of the ABNF.

name = (elements) 

where <name> is the name of the rule, <elements> is one or more rule names or terminals combined through the operands provided below. Rule names are case-insensitive. 

(element1 element2)

elements enclosed in parentheses are treated as a single element, whose contents are strictly ordered.

<a>*<b>element

at least <a> and at most <b> occurrences of the element.

(1*4<element> means one to four elements.)

<a>element

exactly <a> occurrences of the element.

(4<element> means exactly 4 elements.)

<a>*element

<a> or more elements

(4*<element> means 4 or more elements.)

*<b>element

0 to <b> elements.

(*5<element> means 0 to 5 elements.)

*element

0 or more elements.

(*<element> means 0 to infinite elements.)

[element]

optional element, equivalent to *1(element).

([element] means 0 or 1 element.)

"string" or 'string'

matches the literal string given inside double quotes.

Other notations used in the productions are:

; or /* ... */

comment.

Appendix E: Working Group Contributors

References

[ABNF]

D. Crocker, P. Overel. "RFC2234 -- Augmented BNF for Syntax Specifications: ABNF," Internet Mail Consortium, Demon Internet Ltd., November 1997. See /rfc/rfc2119.txt at https://www.ietf.org/.

[Keynote]

Blaze, Feigenbaum, Keromytis, "Keynote Trust Management System".

[PicsRules]

Christopher Evans, Clive D.W. Feather, Alex Hopmann, Martin Presler-Marshall, Paul Resnick, "PICSRules Specification" 29 December 1997. See /TR/REC-PICSRules at https://www.w3.org/

[P3P10]

Massimo Marchiori (editor), "Platform for Privacy Preferences 1.0 (P3P1.0) Specification" 11 February 2000 [Work in progress]. See /TR/P3P/ at https://www.w3.org/

[RDF]

Ora Lassila, Ralph R. Swick (editors), "Resource Description Framework (RDF) Model and Syntax Specification" 22 February 1999. See /TR/REC-rdf-syntax at https://www.w3.org/

[RFC 2068]

R. Fielding et al, "Hypertext Transfer Protocol -- HTTP/1.1" January 1997. See /rfc/rfc2068.txt at https://www.ietf.org/.

[RFC 2119]

S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels" See /rfc/rfc2119.txt at https://www.ietf.org/.

[RFC 822]

David H. Crocker (editor), Standard for the format of ARPA Internet text messages See /rfc/rfc822.txt at https://www.faqs.org/.

[URI]

T. Berners-Lee, R. Fielding, and L. Masinter. "Uniform Resource Identifiers (URI): Generic Syntax and Semantics." 1997. (Work in progress; see updates to RFC1738.)

[UTF-8]

F. Yergeau. "RFC 2279 -- UTF-8, a transformation format of ISO 10646." January 1998. See See /rfc/rfc2279.txt at https://www.ietf.org/