You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
4577 lines
186 KiB
4577 lines
186 KiB
<?xml version="1.0" encoding="iso-8859-1"?>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
|
|
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
|
|
<head>
|
|
<meta name="generator" content="HTML Tidy, see www.w3.org" />
|
|
|
|
<title>A P3P Preference Exchange Language 1.0 (APPEL1.0)</title>
|
|
<meta http-equiv="Content-Type"
|
|
content="text/html; charset=iso-8859-1" />
|
|
<style type="text/css">
|
|
<!--
|
|
code.c3 {font-weight: bold}
|
|
img.c2 {border:0;width:88px;height:31px}
|
|
ol.c1 {list-style-type: lower-alpha}
|
|
|
|
.new {color: red}
|
|
.comment {color: gray}
|
|
.highlit {color: #009900; font-weight: bold}
|
|
.dim {color: #808080}
|
|
tt,pre,code {font-family: fixed;}
|
|
|
|
pre.xsd,pre.dtd {
|
|
font-family: monospace;
|
|
font-size: 85%;
|
|
white-space: pre;
|
|
background-color: rgb(204,204,255);
|
|
padding: 0.5em;
|
|
margin-left: 0;
|
|
border: none;
|
|
width: 97%;
|
|
}
|
|
|
|
th { text-align: left; vertical-align: top; }
|
|
th.top { background: rgb(0,90,156); color: white; }
|
|
th.side { background: #999999; }
|
|
td { vertical-align: top; }
|
|
td.top { background: #cccccc; }
|
|
td.desc { background: white; }
|
|
|
|
div.negmargn {margin-left: -65px;}
|
|
div.bnf, div.framed-bnf {
|
|
background-color: rgb(204,204,255);
|
|
padding: 0.5em;
|
|
border: none;
|
|
}
|
|
|
|
div.framed-bnf {
|
|
border: solid black;
|
|
border-width: 1px;
|
|
margin-right: 5%;
|
|
margin-top: -0.5em;
|
|
}
|
|
div.contents {
|
|
background-color: rgb(204,204,255);
|
|
padding: 0.5em;
|
|
border: none;
|
|
margin-right: 5%;
|
|
}
|
|
div.navbar { text-align: center; }
|
|
|
|
div.framed {
|
|
border: solid black;
|
|
border-width: 1px;
|
|
}
|
|
|
|
div.table, div.figure {
|
|
background-color: rgb(255,255,204);
|
|
border: solid black;
|
|
border-width: 1px;
|
|
margin-right: 5%;
|
|
margin-top: -0.2em;
|
|
}
|
|
div.figure {
|
|
padding: 0.5em;
|
|
}
|
|
div.table {
|
|
padding: 0em;
|
|
}
|
|
div.caption {
|
|
/* background-color: rgb(204,204,204); */
|
|
padding-left: 0.5em;
|
|
padding-top: 0.2em;
|
|
padding-bottom: 0.2em;
|
|
border: none;
|
|
margin-right: 5%;
|
|
}
|
|
img {
|
|
color: white;
|
|
border: none;
|
|
}
|
|
BODY {
|
|
margin: 2em 1em 0em 70px;
|
|
}
|
|
-->
|
|
|
|
</style>
|
|
<link rel="stylesheet" type="text/css"
|
|
href="http://www.w3.org/StyleSheets/TR/W3C-WD" />
|
|
</head>
|
|
|
|
<body>
|
|
<!-- <div class="navbar">
|
|
<a href="#toc">table of contents</a>
|
|
<hr />
|
|
</div>
|
|
-->
|
|
|
|
<div class="head">
|
|
<a href="http://www.w3.org/"><img height="48" width="72"
|
|
alt="W3C" src="http://www.w3.org/Icons/w3c_home" /></a>
|
|
|
|
<h1>A P3P Preference Exchange Language 1.0 (APPEL1.0)</h1>
|
|
|
|
<h2>W3C Working Draft 15 April 2002</h2>
|
|
|
|
<dl>
|
|
<dt>This version:</dt>
|
|
|
|
<dd><a
|
|
href="http://www.w3.org/TR/2002/WD-P3P-preferences-20020415">http://www.w3.org/TR/2002/WD-P3P-preferences-20020415</a></dd>
|
|
|
|
<dt>Latest Version:</dt>
|
|
|
|
<dd><a
|
|
href="http://www.w3.org/TR/P3P-preferences">http://www.w3.org/TR/P3P-preferences</a></dd>
|
|
|
|
<dt>Previous Version:</dt>
|
|
|
|
<dd><a
|
|
href="http://www.w3.org/TR/2001/WD-P3P-preferences-20010226">http://www.w3.org/TR/2001/WD-P3P-preferences-20010226</a></dd>
|
|
|
|
<dt>Editor</dt>
|
|
|
|
<dd><a href="http://www.inf.ethz.ch/~langhein/">Marc
|
|
Langheinrich</a>, ETH Zurich < <a
|
|
href="mailto:langhein@inf.ethz.ch">langhein@inf.ethz.ch</a>
|
|
></dd>
|
|
|
|
<dt>Authors</dt>
|
|
|
|
<dd><a href="http://www.research.att.com/~lorrie/">Lorrie
|
|
Cranor</a>, AT&T Labs-Research<br />
|
|
<a href="http://www.inf.ethz.ch/~langhein/">Marc
|
|
Langheinrich</a>, ETH Zurich<br />
|
|
<a href="http://www.w3.org/People/Massimo/">Massimo
|
|
Marchiori</a>, W3C/MIT</dd>
|
|
</dl>
|
|
|
|
<p class="copyright"><a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Copyright">
|
|
Copyright</a> ©2002 <a href="http://www.w3.org/"><abbr
|
|
title="World Wide Web Consortium">W3C</abbr></a> <sup>®</sup> (
|
|
<a href="http://www.lcs.mit.edu/"><abbr
|
|
title="Massachusetts Institute of Technology">MIT</abbr></a> , <a
|
|
href="http://www.inria.fr/"><abbr lang="fr"
|
|
title="Institut National de Recherche en Informatique et Automatique">
|
|
INRIA</abbr></a> , <a href="http://www.keio.ac.jp/">Keio</a>),
|
|
All Rights Reserved. W3C <a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Legal_Disclaimer">
|
|
liability</a>, <a
|
|
href="http://www.w3.org/Consortium/Legal/ipr-notice-20000612#W3C_Trademarks">
|
|
trademark</a>, <a
|
|
href="http://www.w3.org/Consortium/Legal/copyright-documents-19990405">
|
|
document use</a> and <a
|
|
href="http://www.w3.org/Consortium/Legal/copyright-software-19980720">
|
|
software licensing</a> rules apply.</p>
|
|
<br />
|
|
|
|
<hr title="Separator for header" />
|
|
</div>
|
|
|
|
<h2>Abstract</h2>
|
|
|
|
<p>This document complements the <a
|
|
href="http://www.w3.org/TR/P3P/">P3P1.0 specification</a> [<a
|
|
href="#P3P10">P3P10</a>] 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 <b>ruleset</b>), 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.</p>
|
|
|
|
<h2>Status of this Document</h2>
|
|
|
|
<p><em>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.</em></p>
|
|
|
|
<p>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 <a
|
|
href="http://www.w3.org/Privacy/Activity.html">P3P Activity</a>,
|
|
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 <a href="http://www.w3.org/TR/">http://www.w3.org/TR/</a>.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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 <a href="http://www.w3.org/TR/P3P/">16
|
|
April 2002</a> Recommendation of the P3P Specification and that
|
|
such examples might need to be updated should a revised version of
|
|
the P3P Specification appear.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>Comments should be sent to <a
|
|
href="mailto:www-p3p-public-comments@w3.org">www-p3p-public-comments@w3.org</a>.
|
|
This is the preferred method of providing feedback. Public comments
|
|
and their responses can be accessed at <a
|
|
href="http://lists.w3.org/Archives/Public/www-p3p-public-comments/">
|
|
http://lists.w3.org/Archives/Public/www-p3p-public-comments/</a>.
|
|
Alternatively, if you do not wish your comment to be made public,
|
|
you can send your comment to <a
|
|
href="mailto:p3p-comments@w3.org">p3p-comments@w3.org</a>. In
|
|
this case, your comments will only be accessible to W3C members (at
|
|
<a
|
|
href="http://lists.w3.org/Archives/Member/p3p-comments/">http://lists.w3.org/Archives/Member/p3p-comments/</a>).</p>
|
|
<hr />
|
|
|
|
<h2 class="notoc"><a id="toc" name="toc">Contents</a></h2>
|
|
|
|
<div class="contents">
|
|
<ul class="toc">
|
|
<li class="tocline">
|
|
1. <a href="#introduction">Introduction</a>
|
|
|
|
<ul class="toc">
|
|
<li class="tocline">1.1 <a href="#basics">P3P
|
|
Basics</a></li>
|
|
|
|
<li class="tocline">1.2 <a href="#appel">Goals of a P3P
|
|
Preference Exchange Language</a></li>
|
|
|
|
<li class="tocline">1.3 <a
|
|
href="#requirements">Requirements</a></li>
|
|
|
|
<li class="tocline">1.4 <a href="#P3Ppolicies">APPEL and
|
|
P3P policies</a></li>
|
|
|
|
<li class="tocline">1.5 <a
|
|
href="#definitions">Definitions</a></li>
|
|
</ul>
|
|
</li>
|
|
|
|
<li class="tocline">
|
|
2. <a href="#operation">General Operation and Semantics</a>
|
|
|
|
<ul class="toc">
|
|
<li class="tocline">2.1 <a href="#inout">Inputs and Outputs
|
|
to the Rule Evaluator</a></li>
|
|
|
|
<li class="tocline">
|
|
2.2 <a href="#proc_eval">Rule Processing &
|
|
Evaluation</a>
|
|
|
|
<ul class="toc">
|
|
<li class="tocline">2.2.1 <a href="#proc">Rule
|
|
Processing</a></li>
|
|
|
|
<li class="tocline">2.2.2 <a
|
|
href="#expr">Expressions</a></li>
|
|
|
|
<li class="tocline">2.2.3 <a href="#eval">Rule
|
|
Evaluation</a></li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
|
|
<li class="tocline">
|
|
3. <a href="#example">Simple Example Scenarios</a>
|
|
|
|
<ul class="toc">
|
|
<li class="tocline">3.1 <a href="#ex_prefs">User
|
|
Preferences</a></li>
|
|
|
|
<li class="tocline">3.2 <a href="#ex_tabs">Tabular
|
|
Overview</a></li>
|
|
|
|
<li class="tocline">3.3 <a href="#ex_rs">APPEL
|
|
ruleset</a></li>
|
|
|
|
<li class="tocline">3.4 <a href="#ex_expl">Example
|
|
explanation</a></li>
|
|
</ul>
|
|
</li>
|
|
|
|
<li class="tocline">
|
|
4. <a href="#techdef">Technical Definition</a>
|
|
|
|
<ul class="toc">
|
|
<li class="tocline">
|
|
4.1 <a href="#syntax">Syntax & Encoding</a>
|
|
|
|
<ul class="toc">
|
|
<li class="tocline">4.1.1 <a href="#bnf">BNF
|
|
Syntax</a></li>
|
|
|
|
<li class="tocline">4.1.2 <a
|
|
href="#transport">Transport & Storage</a></li>
|
|
</ul>
|
|
</li>
|
|
|
|
<li class="tocline">
|
|
4.2 <a href="#elements">Elements</a>
|
|
|
|
<ul class="toc">
|
|
<li class="tocline">4.2.1 <a
|
|
href="#RULESET">RULESET</a></li>
|
|
|
|
<li class="tocline">4.2.2 <a href="#RULE">RULE</a></li>
|
|
|
|
<li class="tocline">4.2.3 <a
|
|
href="#OTHERWISE">OTHERWISE</a></li>
|
|
|
|
<li class="tocline">4.2.4 <a
|
|
href="#REQUEST">REQUEST</a></li>
|
|
|
|
<li class="tocline">4.2.5 <a
|
|
href="#connective">connective</a></li>
|
|
|
|
<li class="tocline">4.2.6 <a href="#p3p10policy">P3P1.0
|
|
policy snippet</a></li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
|
|
<li class="tocline">
|
|
5. <a href="#semantics">Semantics</a>
|
|
|
|
<ul class="toc">
|
|
<li class="tocline">
|
|
5.1 <a href="#nut">The Rule Evaluator in a nutshell</a>
|
|
|
|
<ul class="toc">
|
|
<li class="tocline">5.1.1 <a
|
|
href="#nut_be">Behaviors</a></li>
|
|
|
|
<li class="tocline">5.1.2 <a
|
|
href="#nut_rs">Rulesets</a></li>
|
|
|
|
<li class="tocline">5.1.3 <a
|
|
href="#nut_ex">Expressions</a></li>
|
|
</ul>
|
|
</li>
|
|
|
|
<li class="tocline">5.2 <a href="#order">Rule
|
|
Ordering</a></li>
|
|
|
|
<li class="tocline">5.3 <a
|
|
href="#expressions">Expressions</a></li>
|
|
|
|
<li class="tocline">
|
|
5.4 <a href="#match">Matching</a>
|
|
|
|
<ul class="toc">
|
|
<li class="tocline">5.4.1 <a
|
|
href="#match_connectives">Connectives</a></li>
|
|
|
|
<li class="tocline">5.4.2 <a
|
|
href="#match_attr_expr">Attribute Expressions</a></li>
|
|
|
|
<li class="tocline">5.4.3 <a
|
|
href="#match_wild">Expression Metacharacters</a></li>
|
|
|
|
<li class="tocline">5.4.4 <a
|
|
href="#match_pcdata">Matching
|
|
<code>#PCDATA</code></a></li>
|
|
|
|
<li class="tocline">5.4.5 <a
|
|
href="#match_dataref">Matching <code>p3p:DATA</code>
|
|
elements</a></li>
|
|
|
|
<li class="tocline">5.4.6 <a href="#match_cat">Category
|
|
expansion</a></li>
|
|
|
|
<li class="tocline">5.4.7 <a
|
|
href="#match_optional">Matching optional data
|
|
elements</a></li>
|
|
|
|
<li class="tocline">5.4.8 <a
|
|
href="#match_extension">Matching optional and mandatory
|
|
extensions</a></li>
|
|
</ul>
|
|
</li>
|
|
|
|
<li class="tocline">
|
|
5.5 <a href="#match_sum_and_example">Matching Summary
|
|
& Examples</a>
|
|
|
|
<ul class="toc">
|
|
<li class="tocline">5.5.1 <a
|
|
href="#match_pseudocode">Matching Semantics in
|
|
pseudocode</a></li>
|
|
|
|
<li class="tocline">5.5.2 <a
|
|
href="#match_algorithm">Sample Matching
|
|
Algorithm</a></li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
|
|
<li class="tocline">
|
|
<a href="#appendices">Appendices</a>
|
|
|
|
<ul class="toc">
|
|
<li class="tocline">A. <a href="#future">Future
|
|
Work</a></li>
|
|
|
|
<li class="tocline">B. <a href="#examples">Ruleset
|
|
Examples</a></li>
|
|
|
|
<li class="tocline">C. <a href="#xmlschema">XML Schema
|
|
(normative)</a></li>
|
|
|
|
<li class="tocline">D. <a href="#dtd">Document Type
|
|
Definition (informative)</a></li>
|
|
|
|
<li class="tocline">E. <a href="#abnf">ABNF Notation
|
|
(informative)</a></li>
|
|
|
|
<li class="tocline">F. <a href="#related">Trust Engines and
|
|
Database Engines</a></li>
|
|
|
|
<li class="tocline">G. <a
|
|
href="#contrib">Contributors</a></li>
|
|
</ul>
|
|
</li>
|
|
|
|
<li class="tocline"><a href="#references">References</a></li>
|
|
</ul>
|
|
</div>
|
|
<hr />
|
|
|
|
<h1><a name="introduction" id="introduction">1.
|
|
Introduction</a></h1>
|
|
|
|
<p>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 <b>ruleset</b>), 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.</p>
|
|
|
|
<p><b>Note:</b> 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.</p>
|
|
|
|
<p>This language complements the <a
|
|
href="http://www.w3.org/TR/P3P/">P3P1.0 specification</a> [<a
|
|
href="#P3P10">P3P10</a>]. Much of the underlying logic is based on
|
|
[<a href="#PICSRules">PICSRules</a>]. We hope in time that this
|
|
will merely be an application of [<a href="#XML">XML</a>] rules or
|
|
query languages.</p>
|
|
|
|
<h2><a name="basics" id="basics">1.1 P3P Basics</a></h2>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>A basic P3P interaction might proceed as follows:</p>
|
|
|
|
<ol>
|
|
<li>The agent requests a Web page from a service.</li>
|
|
|
|
<li>The service responds by sending a reference to a P3P
|
|
<b>policy-reference</b> in the header of its HTTP response. A
|
|
policy-reference file lists parts of a Web site and the URIs of
|
|
their corresponding privacy policies. A policy consists of one or
|
|
more statements about a service's privacy practices.</li>
|
|
|
|
<li>The agent fetches the policy-reference file and determines
|
|
the URI of the policy that applies to the requested page.</li>
|
|
|
|
<li>The agent fetches the policy, evaluates it according to the
|
|
user's <b>ruleset</b> (which represents her
|
|
<b>preferences</b>) and determines what action to take (e.g.,
|
|
simply informing the user about the privacy policy in place, or
|
|
prompting her for a decision).</li>
|
|
</ol>
|
|
|
|
<p>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.</p>
|
|
|
|
<h2><a name="appel" id="appel">1.2 Goals of A P3P Preference
|
|
Exchange Language</a></h2>
|
|
|
|
<p>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 <a href="#def_trustengine">trust engines</a>.
|
|
However, there are benefits associated with being able to express
|
|
user preferences as captured by the GUI and processed by the trust
|
|
engine:</p>
|
|
|
|
<ul>
|
|
<li><b>Sharing and installation of rulesets.</b> 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.</li>
|
|
|
|
<li><b>Communication to agents, search engines, proxies, or other
|
|
servers.</b> 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.</li>
|
|
|
|
<li><b>Portability between products.</b> The same ruleset will
|
|
work with any P3P-APPEL enabled product.</li>
|
|
</ul>
|
|
|
|
<p><b>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.</b> 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.</p>
|
|
|
|
<h2><a name="requirements" id="requirements">1.3
|
|
Requirements</a></h2>
|
|
|
|
<p>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:</p>
|
|
|
|
<ul>
|
|
<li>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.)</li>
|
|
|
|
<li>APPEL should address situations in which a service does not
|
|
offer a P3P policy.</li>
|
|
|
|
<li>APPEL rules should be able to prescribe the following set of
|
|
behaviors: request, don't request, limit request. In
|
|
addition, APPEL should include extensibility mechanisms that
|
|
allow rules to describe additional behaviors.</li>
|
|
|
|
<li>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.</li>
|
|
</ul>
|
|
|
|
<p>The working group limited the scope of APPEL as follows:</p>
|
|
|
|
<ul>
|
|
<li>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).</li>
|
|
|
|
<li>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 is returned while evaluating multiple
|
|
policies.</li>
|
|
|
|
<li>A compact or easy-to-read representation is not
|
|
essential.</li>
|
|
|
|
<li>APPEL need not be capable of expressing negotiation
|
|
strategies.</li>
|
|
|
|
<li>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).</li>
|
|
</ul>
|
|
|
|
<p>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 <b>1.0</b> limits the
|
|
requirements to</p>
|
|
|
|
<ul>
|
|
<li>only support three <a href="#def_beh_standard">standard
|
|
behaviors</a>, <em>request</em>, <em>limited</em> (request), and
|
|
<em>block</em> ed (request); together with an optional
|
|
<em>prompt</em> (i.e. no custom behaviors).</li>
|
|
|
|
<li>only support preferences over P3P policies and a limited set
|
|
of metadata.</li>
|
|
|
|
<li>only support restricted matching capabilities using a limited
|
|
set of comparison operators and wildcards.</li>
|
|
</ul>
|
|
|
|
<p>The remainder of this document will discuss the thus restricted
|
|
version of APPEL, refered to as the APPEL1.0 specification. See <a
|
|
href="#future">Appendix A: Future Work</a> for a list of possible
|
|
extensions regarding the full list of requirements given above.</p>
|
|
|
|
<h2><a name="P3Ppolicies" id="P3Ppolicies">1.4 APPEL and P3P
|
|
policies</a></h2>
|
|
|
|
<p>Since APPEL rulesets are intended to express preferences over
|
|
P3P policies, most of APPEL's synatx and semantics are very
|
|
much influenced by the <a href="http://www.w3.org/TR/P3P/">P3P 1.0
|
|
Specification</a>. 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.</p>
|
|
|
|
<p>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 <a
|
|
href="http://www.w3.org/TR/P3P/#P3P_markup">3. Policy Syntax and
|
|
Semantics</a> of the P3P 1.0 Specification for details on the
|
|
individual elements and their usage.<br />
|
|
</p>
|
|
|
|
<div class="caption">
|
|
<b>Figure 1.1:</b> P3P Example Policy
|
|
</div>
|
|
|
|
<div class="figure">
|
|
<pre>
|
|
<POLICY xmlns="http://www.w3.org/2000/12/P3Pv1"
|
|
discuri="http://www.example.com/ourprivacypolicy.html">
|
|
<ENTITY>
|
|
<DATA-GROUP>
|
|
<DATA ref="#business.name">CatalogExample</DATA>
|
|
<DATA ref="#business.contact-info.postal.street">123 Main Street</DATA>
|
|
<DATA ref="#business.contact-info.postal.city">Bethesda</DATA>
|
|
<DATA ref="#business.contact-info.postal.stateprov">MD</DATA>
|
|
<DATA ref="#business.contact-info.postal.postalcode">20814</DATA>
|
|
<DATA ref="#business.contact-info.postal.country">US</DATA>
|
|
</DATA-GROUP>
|
|
</ENTITY>
|
|
<ACCESS>
|
|
<nonident/>
|
|
</ACCESS>
|
|
<DISPUTES-GROUP>
|
|
<DISPUTES resolution-type="independent"
|
|
service="http://www.PrivacySeal.example.org"
|
|
short-description="PrivacySeal.example.org">
|
|
<IMG src="http://www.PrivacySeal.example.org/Logo.gif"
|
|
alt="Privacy Seal Logo"/>
|
|
<REMEDIES>
|
|
<correct/>
|
|
</REMEDIES>
|
|
</DISPUTES>
|
|
</DISPUTES-GROUP>
|
|
<STATEMENT>
|
|
<CONSEQUENCE>We tailor our site based on your past visits,
|
|
preferences, and personal information</CONSEQUENCE>
|
|
<PURPOSE>
|
|
<customization/>
|
|
<develop/>
|
|
</PURPOSE>
|
|
<RECIPIENT>
|
|
<ours/>
|
|
</RECIPIENT>
|
|
<RETENTION>
|
|
<stated-purpose/>
|
|
</RETENTION>
|
|
<DATA-GROUP>
|
|
<DATA ref="#dynamic.cookies">
|
|
<CATEGORIES>
|
|
<state/>
|
|
</CATEGORIES>
|
|
</DATA>
|
|
<DATA ref="#dynamic.miscdata">
|
|
<CATEGORIES>
|
|
<preference/>
|
|
</CATEGORIES>
|
|
</DATA>
|
|
<DATA ref="#user.gender"/>
|
|
<DATA ref="#user.home-info" optional="yes"/>
|
|
</DATA-GROUP>
|
|
</STATEMENT>
|
|
<STATEMENT>
|
|
<CONSEQUENCE>We record some information in order to serve your request
|
|
and to secure and improve our Web site.</CONSEQUENCE>
|
|
<PURPOSE>
|
|
<admin/>
|
|
<develop/>
|
|
</PURPOSE>
|
|
<RECIPIENT>
|
|
<ours/>
|
|
</RECIPIENT>
|
|
<RETENTION>
|
|
<indefinitely/>
|
|
</RETENTION>
|
|
<DATA-GROUP>
|
|
<DATA ref="#dynamic.clickstream"/>
|
|
<DATA ref="#dynamic.http.useragent"/>
|
|
</DATA-GROUP>
|
|
</STATEMENT>
|
|
</POLICY>
|
|
</pre>
|
|
</div>
|
|
|
|
<h2><a name="definitions" id="definitions">1.5 Definitions</a></h2>
|
|
|
|
<p>The following definitions (in alphabetical order) reflect the
|
|
way terms are commonly used in this document.</p>
|
|
|
|
<dl>
|
|
<dt><a name="def_behavior" id="def_behavior">behavior</a></dt>
|
|
|
|
<dd>The activity taken upon the successful matching of a <a
|
|
href="#def_rule">rule</a>. APPEL1.0 supports three <a
|
|
href="#def_beh_standard">standard behaviors</a> (request, limited
|
|
and block), as well as an optional <em>prompt</em>
|
|
parameter.</dd>
|
|
|
|
<dt><a name="def_beh_standard" id="def_beh_standard">behavior,
|
|
standard</a></dt>
|
|
|
|
<dd>The three behaviors that have to be supported by every APPEL
|
|
user agent: <em>request</em>, <em>limited</em> and
|
|
<em>block</em>. Please note that APPEL1.0 does not allow for
|
|
custom behaviors.</dd>
|
|
|
|
<dt><a name="def_connective"
|
|
id="def_connective">connective</a></dt>
|
|
|
|
<dd>An attribute of an expression that determines how any <a
|
|
href="#def_cont_expr">contained expressions</a> will be matched.
|
|
APPEL1.0 supports six connectives: <code>or</code>,
|
|
<code>and</code>, <code>non-or</code>, <code>non-and</code>,
|
|
<code>or-exact</code> and <code>and-exact</code>. See section <a
|
|
href="#match_connectives">5.4.1 Connectives</a> for more
|
|
details.</dd>
|
|
|
|
<dt><a name="def_repository" id="def_repository">data
|
|
repository</a></dt>
|
|
|
|
<dd>A mechanism for storing user information under the control of
|
|
the user agent.</dd>
|
|
|
|
<dt><a name="def_evidence" id="def_evidence">evidence</a></dt>
|
|
|
|
<dd>A P3P application provides an APPEL <a
|
|
href="#def_ruleeval">rule evaluator</a> with an APPEL <a
|
|
href="#def_ruleset">ruleset</a> and various pieces of
|
|
<em>evidence</em>. This evidence for example includes 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.</dd>
|
|
|
|
<dt><a name="def_expr" id="def_expr">expression</a></dt>
|
|
|
|
<dd>
|
|
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) <a href="#def_evidence">evidence</a>. An expression
|
|
consists of
|
|
|
|
<ol>
|
|
<li>an element identifier (element name)</li>
|
|
|
|
<li>zero or more <a href="#def_attr_expr">attribute
|
|
expressions</a></li>
|
|
|
|
<li>zero or more <a href="#def_cont_expr">contained
|
|
expressions</a></li>
|
|
|
|
<li>an optional <a href="#def_connective">connective</a></li>
|
|
</ol>
|
|
See sections <a href="#expressions">2.2 Expressions</a> for a
|
|
list of expressions and <a href="#expressions">5.3
|
|
Expressions</a> for details on how they match available <a
|
|
href="#def_evidence">evidence</a>. Please note that APPEL1.0
|
|
only allows for the <code><POLICY></code> and
|
|
<code><appel:REQUEST></code> elements to be used as <a
|
|
href="#def_top_expr">top-level expressions</a> in a rule.
|
|
</dd>
|
|
|
|
<dt><a name="def_attr_expr" id="def_attr_expr">expression,
|
|
attribute</a></dt>
|
|
|
|
<dd>An attribute-value pair contained in an <a
|
|
href="#def_expr">expression</a>. 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 <a href="#match_attr_expr">5.4.2
|
|
Matching Attribute Expressions</a> for more information.</dd>
|
|
|
|
<dt><a name="def_cont_expr" id="def_cont_expr">expression,
|
|
contained</a></dt>
|
|
|
|
<dd>An expression that is enclosed in another expression, i.e. an
|
|
XML element or <code>#PCDATA</code> 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 <a
|
|
href="#def_connective">connective</a> used) have to match as
|
|
well. See section <a href="#expressions">5.3 Expressions</a> for
|
|
details.</dd>
|
|
|
|
<dt><a name="def_dege_expr" id="def_dege_expr">expression,
|
|
degenerate</a></dt>
|
|
|
|
<dd>An <a href="#def_expr">expression</a> that always evaluates
|
|
to true. See section <a href="#OTHERWISE">4.2.3 The
|
|
<code><OTHERWISE></code> element</a>.</dd>
|
|
|
|
<dt><a id="def_top_expr" name="def_top_expr">expression,
|
|
top-level</a></dt>
|
|
|
|
<dd>The expressions contained immediately below an
|
|
<code><appel:RULE></code> element. In APPEL1.0 , the
|
|
top-level expression can only be a <code><POLICY></code> or
|
|
<code><appel:REQUEST></code> element, or the <a
|
|
href="#def_dege_expr">degenerate expression</a>.</dd>
|
|
|
|
<dt><a name="def_persona" id="def_persona">persona</a></dt>
|
|
|
|
<dd>A unique identifier for a set of data element values in the
|
|
user's <a href="#def_repository">data repository</a> 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).</dd>
|
|
|
|
<dt><a name="def_preference" id="def_preference">preference</a>
|
|
(privacy, not qualified in use)</dt>
|
|
|
|
<dd>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 <a
|
|
href="#def_rule">rules</a> and should preferably be captured
|
|
through a GUI.</dd>
|
|
|
|
<dt><a name="def_policy" id="def_policy">policy</a> (privacy, not
|
|
qualified in use)</dt>
|
|
|
|
<dd>A site's privacy practices, as expressed in its <a
|
|
href="#def_P3Ppolicy">P3P policies</a>.</dd>
|
|
|
|
<dt><a name="def_P3Ppolicy" id="def_P3Ppolicy">policy</a>,
|
|
P3P</dt>
|
|
|
|
<dd>A P3P policy is a collection of one or more privacy <a
|
|
href="#def_statement">statements</a> 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 <a href="http://www.w3.org/TR/P3P/">P3P 1.0
|
|
Specification</a></dd>
|
|
|
|
<dt><a name="def_rule" id="def_rule">rule</a></dt>
|
|
|
|
<dd>The formal expression of a user's preference. Rules
|
|
express the users preferences that are then compared to a
|
|
services <a href="#def_P3Ppolicy">P3P policy</a>. The action
|
|
resulting from a successful match is defined by the <a
|
|
href="#def_behavior">behavior</a> specified by the rule. The rule
|
|
is delimited by an opening and closing element of the form<br />
|
|
<code><appel:RULE behavior="..."
|
|
...>rule</appel:RULE></code></dd>
|
|
|
|
<dt><a name="def_ruleeval" id="def_ruleeval">rule
|
|
evaluator</a></dt>
|
|
|
|
<dd>Process responsible for comparing a user's privacy <a
|
|
href="#def_preference">preferences</a> (for example in form of an
|
|
APPEL <a href="#def_ruleset">ruleset</a>) with a P3P <a
|
|
href="#def_policy">policy</a> sent from a service. See also
|
|
comments in <a href="#related">Appendic C: Trust Engines and
|
|
Database Engines</a>.</dd>
|
|
|
|
<dt><a name="def_ruleset" id="def_ruleset">ruleset</a></dt>
|
|
|
|
<dd>A set of <a href="#def_rule">rules</a> that define all of the
|
|
user's P3P <a href="#def_preference">preferences</a>.</dd>
|
|
|
|
<dt><a name="def_schema_P3P_base"
|
|
id="def_schema_P3P_base">schema, P3P base</a></dt>
|
|
|
|
<dd>schema defined in the <a href="http://www.w3.org/TR/P3P/">P3P
|
|
1.0 Specification</a>.</dd>
|
|
|
|
<dt><a name="def_service" id="def_service">service</a></dt>
|
|
|
|
<dd>A program that issues <a href="#def_policy">policies</a> 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.</dd>
|
|
|
|
<dt><a name="def_statement" id="def_statement">statement</a>,
|
|
P3P</dt>
|
|
|
|
<dd>A <a href="http://www.w3.org/TR/P3P/#Statements">P3P
|
|
statement</a> 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
|
|
that references no data, requests no data.</dd>
|
|
|
|
<dt><a name="def_trustengine" id="def_trustengine">trust
|
|
engine</a></dt>
|
|
|
|
<dd>See <a href="#def_ruleeval">rule evaluator</a>.</dd>
|
|
|
|
<dt><a name="def_user" id="def_user">user</a></dt>
|
|
|
|
<dd>An individual (or group of individuals acting as a single
|
|
entity) on whose behalf a <a href="#def_service">service</a> is
|
|
accessed and for which personal data exists.</dd>
|
|
|
|
<dt><a name="def_user_agent" id="def_user_agent">user
|
|
agent</a></dt>
|
|
|
|
<dd>A program that acts on a user's behalf. The agent may act
|
|
on preferences ( <a href="#def_rule">rules</a>) for a broad range
|
|
of purposes, such as content filtering, trust decisions, or
|
|
privacy. For P3P purposes, a user agent acts on a <a
|
|
href="#def_user">user</a> 's privacy preferences. Users may
|
|
use different user agents at different times.</dd>
|
|
</dl>
|
|
|
|
<p>In addition, this specification uses the same words as RFC 2119
|
|
[ <a href="#RFC2119">RFC2119</a> ] for defining the significance of
|
|
each particular requirement. These words are:</p>
|
|
|
|
<dl>
|
|
<dt>MUST</dt>
|
|
|
|
<dd>This word, or the terms "REQUIRED" or
|
|
"SHALL", mean that the definition is an absolute
|
|
requirement of the specification.</dd>
|
|
|
|
<dt>MUST NOT</dt>
|
|
|
|
<dd>This phrase, or the phrase "SHALL NOT", mean that
|
|
the definition is an absolute prohibition of the
|
|
specification.</dd>
|
|
|
|
<dt>SHOULD</dt>
|
|
|
|
<dd>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.</dd>
|
|
|
|
<dt>SHOULD NOT</dt>
|
|
|
|
<dd>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.</dd>
|
|
|
|
<dt>MAY</dt>
|
|
|
|
<dd>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 that does not include a
|
|
particular option MUST be prepared to interoperate with another
|
|
implementation that does include the option, though perhaps with
|
|
reduced functionality. In the same vein an implementation that
|
|
does include a particular option MUST be prepared to interoperate
|
|
with another implementation that does not include the option
|
|
(except, of course, for the feature the option provides.)</dd>
|
|
</dl>
|
|
|
|
<h1><a name="operation" id="operation">2. General Operation and
|
|
Semantics</a></h1>
|
|
|
|
<p>The following sections give an overview of the basic operations
|
|
of an APPEL rule evaluator.</p>
|
|
|
|
<h2><a name="inout" id="inout">2.1 Inputs and Outputs of the Rule
|
|
Evaluator</a></h2>
|
|
|
|
<p>An APPEL rule evaluator is activated by a P3P application. The
|
|
activating application provides the evaluator with various pieces
|
|
of "evidence," the <a
|
|
href="http://www.w3.org/TR/P3P/base">P3P base data schema</a>, 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.</p>
|
|
|
|
<p>The scope of the rule is determined by the opening and closing
|
|
elements of an <code><appel:RULE></code> element. The
|
|
evaluator returns the behavior (as specified in its
|
|
<code>behavior</code> and <code>prompt</code> 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.</p>
|
|
|
|
<p>Applications should interpret the <em>behavior</em> outputs as
|
|
follows:</p>
|
|
|
|
<ul>
|
|
<li><a name="beh_request" id="beh_request">" <b>request</b>
|
|
"</a> : the provided evidence is acceptable. If a URI is
|
|
provided, the resource at that URI SHOULD be accessed. Note that
|
|
P3P 1.0 does not support the concept of <em>binding
|
|
agreements</em> : 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.</li>
|
|
|
|
<li><a name="beh_limited" id="beh_limited">" <b>limited</b>
|
|
"</a> : the provided evidence is somewhat acceptable. If a
|
|
URI is provided, the resource at that URI SHOULD be accessed.
|
|
However, the request made to access the resource SHOULD be
|
|
limited, that is, all but absolutely necessary request headers
|
|
should be suppressed.</li>
|
|
|
|
<li><a name="beh_block" id="beh_block">" <b>block</b>
|
|
"</a> : the provided evidence is not acceptable. 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.</li>
|
|
</ul>
|
|
|
|
<p>HTTP user agents often include a variety of non-essential
|
|
headers with their requests. These are optional headers such as the
|
|
<code>REFERER</code> 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.</p>
|
|
|
|
<p>User agents MAY wish to monitor Web forms and
|
|
<code>set_cookie</code> 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.</p>
|
|
|
|
<p>In addition, applications should interpret the <em>prompt</em>
|
|
attribute as follows:</p>
|
|
|
|
<ul>
|
|
<li>prompt = " <b>no</b> ": The behavior specified in
|
|
the <em>behavior</em> attribute SHOULD be performed seamlessly,
|
|
i.e. without soliciting input from the user. However, calling
|
|
programs MAY still display information about rule evaluation that
|
|
does not require user interaction (i.e. a message in the status
|
|
bar, audio feedback, etc).</li>
|
|
|
|
<li>prompt = " <b>yes</b> ": The user SHOULD be
|
|
prompted for a decision whether the behavior triggered by the
|
|
rule should be performed. User agents SHOULD whenever possible
|
|
use the message contained in the corresponding <em>promptmsg</em>
|
|
attribute of the rule when prompting the user.</li>
|
|
</ul>
|
|
|
|
<h2><a name="proc_eval" id="proc_eval">2.2 Rule Processing and
|
|
Evaluation</a></h2>
|
|
|
|
<p>The information described in the following sections is only
|
|
intended to give a first overview. Details can be found in section
|
|
<a href="#semantics">5 Semantics</a>, and should be referenced from
|
|
the corresponding sections below.</p>
|
|
|
|
<h3><a name="proc" id="proc">2.2.1 Rule Processing</a></h3>
|
|
|
|
<p>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 <i>any</i> of
|
|
the available evidence satisfies it.</p>
|
|
|
|
<p>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 <em>behavior</em> and
|
|
<em>prompt</em> attribute values. By having access to the combined
|
|
list of <em>description-message</em> attribute values in all
|
|
triggered rules, the user can get a comprehensive explanation for
|
|
the behavior of the user agent.</p>
|
|
|
|
<p>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
|
|
<em>prompt</em>.</p>
|
|
|
|
<p>Further information on rule processing can be found in sections
|
|
<a href="#nut">5.1 The Rule Evaluator in a nutshell</a> and <a
|
|
href="#order">5.2 Rules ordering</a>.</p>
|
|
|
|
<h3><a name="expr" id="expr">2.2.2 Expressions</a></h3>
|
|
|
|
<p>APPEL uses 3 basic types of expressions:</p>
|
|
|
|
<ol>
|
|
<li><span class="highlit">expression</span> : uses attribute- and
|
|
contained-expressions to match a full XML element in the
|
|
evidence.</li>
|
|
|
|
<li><span class="highlit">attribute expression</span> : matches a
|
|
single attribute and its value in an XML element.</li>
|
|
|
|
<li><span class="highlit">contained expression</span> :
|
|
recursively matches contained subelements and #PCDATA of an XML
|
|
element.</li>
|
|
</ol>
|
|
|
|
<p>An expression in APPEL is represented by an XML element that can
|
|
be evaluated to TRUE or FALSE by matching it against the available
|
|
<a href="#def_evidence">evidence</a>. An expression always consists
|
|
of (see figure 2.1 for examples):</p>
|
|
|
|
<ol>
|
|
<li>an element identifier (element name)</li>
|
|
|
|
<li>zero or more <a href="#def_attr_expr">attribute
|
|
expressions</a></li>
|
|
|
|
<li>zero or more <a href="#def_cont_expr">contained
|
|
expressions</a></li>
|
|
|
|
<li>an optional <a href="#def_connective">connective</a></li>
|
|
</ol>
|
|
|
|
<div class="caption">
|
|
<b>Figure 2.1:</b> Example Expressions
|
|
</div>
|
|
|
|
<div class="table">
|
|
<table summary="Example expressions" border="1" cellpadding="5"
|
|
width="100%">
|
|
<tbody>
|
|
<tr>
|
|
<td>
|
|
<small>Element name only:</small>
|
|
|
|
<p>
|
|
<code><CONSEQUENCE></CONSEQUENCE></code></p>
|
|
</td>
|
|
|
|
<td rowspan="3" valign="top">
|
|
<small>Element name, attributes, contained elements &
|
|
connective:</small>
|
|
|
|
<p><code><POLICY></code><br />
|
|
<code>    <ENTITY></code><br />
|
|
<code>      <DATA
|
|
ref="#business.name"></code><br />
|
|
<code>        W3C</code><br />
|
|
<code>      </DATA></code><br />
|
|
<code>    </ENTITY></code><br />
|
|
<code>    <STATEMENT></code><br />
|
|
<code>      <PURPOSE</code><br />
|
|
<code>       
|
|
appel:connective="or-exact"></code><br />
|
|
<code>       
|
|
<current/></code><br />
|
|
<code>      </PURPOSE></code><br />
|
|
<code>    </STATEMENT></code><br />
|
|
<code></POLICY></code><br />
|
|
</p>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<small>Element and attribute:</small>
|
|
|
|
<p><code><DISPUTES
|
|
resolution-type="independent"/></code></p>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>
|
|
<small>Element name, contained elements and
|
|
connective:</small>
|
|
|
|
<p><code><RECIPIENT appel:connective="or"
|
|
></code><br />
|
|
<code>  <ours/></code><br />
|
|
<code>  <same/></code><br />
|
|
<code>  <delivery/></code><br />
|
|
<code></RECIPIENT></code><br />
|
|
</p>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<p>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.<br />
|
|
</p>
|
|
|
|
<p>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 <code><DATA
|
|
name="#User.*"></code> (any element from the
|
|
"User" data set). Contained expressions can use the
|
|
wildcard character anywhere where <code><a
|
|
href="http://www.w3.org/TR/2000/WD-xml-2e-20000814#dt-chardata">#PCDATA</a></code>
|
|
("parsed character data", SGML term for character data
|
|
that may contain both <code>&entity;</code> and markup) can be
|
|
used, i.e., between the opening and closing of a tag. Further
|
|
details are given in sections <a href="#match_attr_expr">5.4.2
|
|
Attribute Expressions</a>, <a href="#match_wild">5.4.3 Expression
|
|
Metacharacters</a> and <a href="#match_pcdata">5.4.4 Matching
|
|
<code>#PCDATA</code></a> .</p>
|
|
|
|
<p>A special form of expression is the so called <a
|
|
href="#def_dege_expr">degenerate expression</a>
|
|
<code><appel:OTHERWISE></code>. 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.<br />
|
|
</p>
|
|
|
|
<h3><a name="eval" id="eval">2.2.3 Rule Evaluation</a></h3>
|
|
|
|
<p>A rule includes a behavior, an optional persona, optional
|
|
explanation and prompt messages, and a number of <a
|
|
href="#def_expr">expressions</a>. A rule without any expression
|
|
always evaluates to false. A rule containing the <a
|
|
href="#def_dege_expr">degenerate expression</a> always evaluates to
|
|
true. Individual expressions are each composed of <a
|
|
href="#def_attr_expr">attribute expressions</a> and <a
|
|
href="#def_cont_expr">contained expressions</a>, and optionally
|
|
feature a <a href="#def_connective">connective</a>.</p>
|
|
|
|
<p>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 <code><STATEMENT></code> expression that
|
|
contains both a
|
|
<code><PURPOSE><develop/></PURPOSE></code>
|
|
expression and a
|
|
<code><RECIPIENT><ours/></RECIPIENT></code>
|
|
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.</p>
|
|
|
|
<p>While attribute expressions within an expression are implicitly
|
|
ANDed together, a special <a
|
|
href="#def_connective"><code>connective</code></a> attribute is
|
|
used to govern the matching semantics of <a
|
|
href="#def_cont_expr">contained expressions</a>. APPEL supports six
|
|
such connectives: <em>or</em>, <em>and</em>, <em>non-or</em>,
|
|
<em>non-and</em> ¸ <em>or-exact</em>, and <em>and-exact</em>. If no
|
|
connective is given, APPEL defaults to requiring <em>and</em>
|
|
matches: only if all of the elements in the evidence can be found
|
|
in the rule (additional elements are ignored), a match is
|
|
triggered.</p>
|
|
|
|
<p>The matching of attribute and contained expressions is described
|
|
in more detail in section <a href="#match">5.4 Matching</a>.</p>
|
|
|
|
<h1><a name="example" id="example">3 Simple Example
|
|
Scenario</a></h1>
|
|
|
|
<p>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 <code><a
|
|
href="#RULESET"><appel:RULESET></a></code> element), it is
|
|
only used to demonstrate a small set of example rules.</p>
|
|
|
|
<p>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!<br />
|
|
</p>
|
|
|
|
<h2><a name="ex_prefs" id="ex_prefs">3.1 User Preferences</a></h2>
|
|
|
|
<ol>
|
|
<li>Requests for personal information that will be given out to
|
|
3rd parties should be blocked.</li>
|
|
|
|
<li>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.</li>
|
|
|
|
<li>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 accessing such a page.</li>
|
|
|
|
<li>When interacting with her bank's Web site at
|
|
<code>http://www.my-bank.com</code>, she accepts any data request
|
|
as long as her data is not redistributed to other
|
|
recipients.</li>
|
|
|
|
<li>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.</li>
|
|
</ol>
|
|
|
|
<h2><a name="ex_tabs" id="ex_tabs">3.2 Tabular Overview</a></h2>
|
|
|
|
<p>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 <a
|
|
href="http://www.w3.org/TR/P3P/#Base_Data_Schema">Base data
|
|
elements and sets</a> as well as the <a
|
|
href="http://www.w3.org/TR/P3P/#encoding">XML encoding of a
|
|
policy</a>, defined in the <a href="http://www.w3.org/TR/P3P/">P3P
|
|
1.0 Specification</a> 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.</p>
|
|
|
|
<p>Please note that some of the cells feature a wildcard symbol
|
|
"*", while others are empty. APPEL <a
|
|
href="#match_attr_expr">distinguishes</a> 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 <em>some</em> value. For
|
|
further details see section <a href="#match_wild">5.4.3 Expression
|
|
Metacharacters</a>. In row two of our example below, the user does
|
|
not care about the <em>purpose</em> of the collected clickstream
|
|
data (hence the empty fields in the table), but requires that
|
|
<em>some</em> form of <em>dispute</em> -information is present
|
|
(represented by a wildcard "*" character).<br />
|
|
</p>
|
|
|
|
<div class="negmargn">
|
|
<table summary="Tabular overview of example preferences"
|
|
border="1" cellpadding="2" width="100%">
|
|
<tbody>
|
|
<tr>
|
|
<td><b>Behavior /<br />
|
|
Prompt</b> </td>
|
|
|
|
<td><b><a
|
|
href="http://www.w3.org/TR/P3P/#Base_Data_Schema">Element/Set</a></b>
|
|
</td>
|
|
|
|
<td><b><small><a href="#REQUEST">URI</a></small></b> </td>
|
|
|
|
<td><b><small><a
|
|
href="http://www.w3.org/TR/P3P/#DISPUTES">Disputes</a></small></b>
|
|
</td>
|
|
|
|
<td><b><small><a
|
|
href="http://www.w3.org/TR/P3P/#PURPOSE">Purpose</a></small></b>
|
|
</td>
|
|
|
|
<td><b><small><a
|
|
href="http://www.w3.org/TR/P3P/#RECPNT">Recipient</a></small></b>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>block /<br />
|
|
no</td>
|
|
|
|
<td>category="physical", or<br />
|
|
category="demographic", or<br />
|
|
category="uniqueid"</td>
|
|
|
|
<td> </td>
|
|
|
|
<td> </td>
|
|
|
|
<td> </td>
|
|
|
|
<td>same, other,<br />
|
|
delivery, public<br />
|
|
or unrelated</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>request /<br />
|
|
no</td>
|
|
|
|
<td>dynamic.http.useragent, dynamic.clickstream.server</td>
|
|
|
|
<td> </td>
|
|
|
|
<td>*</td>
|
|
|
|
<td> </td>
|
|
|
|
<td> </td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>request /<br />
|
|
yes</td>
|
|
|
|
<td>user.name.*</td>
|
|
|
|
<td> </td>
|
|
|
|
<td>"PrivacyProtect" and "TrustUs"</td>
|
|
|
|
<td>current, admin, customization or develop</td>
|
|
|
|
<td> </td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>request /<br />
|
|
no</td>
|
|
|
|
<td> </td>
|
|
|
|
<td><small>www.my-bank.com</small> </td>
|
|
|
|
<td> </td>
|
|
|
|
<td> </td>
|
|
|
|
<td>ours</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>limited /<br />
|
|
yes</td>
|
|
|
|
<td>[otherwise]</td>
|
|
|
|
<td> </td>
|
|
|
|
<td> </td>
|
|
|
|
<td> </td>
|
|
|
|
<td> </td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<h2><a name="ex_rs" id="ex_rs">3.3 APPEL ruleset</a></h2>
|
|
|
|
<p>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 <em>block</em> -rule (i.e.,
|
|
a rule with the string "block" in its
|
|
<code>behavior</code> attribute) first rejects any policies asking
|
|
for identifiable data that is distributed to 3rd parties.</p>
|
|
|
|
<p>Using an explicit match for the request URL, a second rule then
|
|
accepts a policy if, when connecting to
|
|
<code>www.my-bank.com</code>, the requested data is only
|
|
distributed to the bank and its agents.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>A "request" rule featuring a
|
|
<em>prompt="yes"</em> 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.</p>
|
|
|
|
<p>If none of the other rules matches, a "limited"-rule
|
|
(again using a <em>prompt="yes"</em> attribute)
|
|
encapsulating the <a href="#def_dege_expr">degenerate
|
|
expression</a> " <a href="#OTHERWISE">appel:OTHERWISE</a>
|
|
" 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.<br />
|
|
</p>
|
|
|
|
<div class="caption">
|
|
<b>Figure 3.1:</b> Simple Ruleset in APPEL1.0
|
|
</div>
|
|
|
|
<div class="figure">
|
|
<pre>
|
|
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>
|
|
</pre>
|
|
</div>
|
|
|
|
<h2><a name="ex_expl" id="ex_expl">3.4 Example Explanation</a></h2>
|
|
|
|
<p>Using the line numbers in the example above, we will briefly
|
|
explain the basic structure of an APPEL ruleset.<br />
|
|
</p>
|
|
|
|
<div class="framed">
|
|
<table summary="Example explanation" border="0" cellpadding="5">
|
|
<tbody>
|
|
<tr>
|
|
<th align="left">Lines</th>
|
|
|
|
<th align="left">Explanation</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign="top">000 - 081</td>
|
|
|
|
<td valign="top">
|
|
<em>APPEL ruleset</em>. Usually a single APPEL ruleset
|
|
(i.e., a set of ordered <a href="#RULE">rules</a>
|
|
enclosed in an <code><a
|
|
href="#RULESET"><appel:RULESET></a></code> 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 <code><a
|
|
href="#RULESET"><appel:RULESET></a></code> element
|
|
can be tagged with additional information such as author
|
|
or date of creation:
|
|
|
|
<div class="bnf">
|
|
<pre>
|
|
[1] ruleset = '<appel:RULESET
|
|
xmlns:appel="http://www.w3.org/2002/04/APPELv1" '
|
|
common-attributes '>'
|
|
rseq
|
|
'</appel:RULESET>'
|
|
|
|
[2] rseq = 1*rule
|
|
</pre>
|
|
</div>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign="top">004 - 026</td>
|
|
|
|
<td valign="top">
|
|
<em>"block" rule</em>. APPEL offers three
|
|
distinct kinds of <a href="#def_behavior">behaviors</a>
|
|
for rules: <a
|
|
href="#beh_request">"request"</a>, <a
|
|
href="#beh_block">"block"</a>, and <a
|
|
href="#beh_limited">"limited"</a>, each of
|
|
which can optionally prompt the user (
|
|
<code>prompt="yes"</code>). Each rule consists
|
|
of an <code><a href="#RULE"><appel:RULE></a></code>
|
|
element surrounding a set of expressions or the <a
|
|
href="#def_dege_expr">degenerate expression</a> <code><a
|
|
href="#OTHERWISE"><appel:OTHERWISE></a></code> .
|
|
|
|
<div class="bnf">
|
|
<pre>
|
|
[3] rule = '<appel:RULE behavior="' behavior '"'
|
|
common-attributes
|
|
rule-attributes
|
|
[connective] '>'
|
|
body
|
|
'</appel:RULE>'
|
|
|
|
[7] behavior = 'request' | 'block' | 'limited'
|
|
</pre>
|
|
</div>
|
|
|
|
<p>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
|
|
(<code>promptmsg</code>) allows the specification of an
|
|
apropriate question.</p>
|
|
|
|
<div class="bnf">
|
|
<pre>
|
|
[4] common-attributes = [' crtdby=' quoted-string]
|
|
[' crtdon="' datetime '"']
|
|
[' description=' quoted-string]
|
|
|
|
[5] rule-attributes = [' prompt ="' ('yes'|'no') '"']
|
|
[' persona=' quoted-string]
|
|
[' promptmsg=' quoted-string]
|
|
</pre>
|
|
</div>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign="top">006 - 025</td>
|
|
|
|
<td valign="top">
|
|
<em>P3P Policy to match</em>. Most APPEL rules have a P3P
|
|
policy as the matching expression inside a
|
|
<code><RULE></code> 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).
|
|
|
|
<div class="bnf">
|
|
<pre>
|
|
[8] top-expression = policy | request-group [policy]
|
|
|
|
[9] policy = <[<a
|
|
href="#P3P10">P3P10</a>] policy snippet (including embed. connectives)>
|
|
|
|
[10] request-group = '<appel:REQUEST-GROUP ' [connective] '>'
|
|
1*request
|
|
'</appel:REQUEST-GROUP>'
|
|
|
|
[11] request = '<appel:REQUEST uri="' [<a
|
|
href="#URI">URI</a>] as per <a
|
|
href="http://www.ietf.org/rfc/rfc2396.txt">RFC 2396</a>'"/>'
|
|
</pre>
|
|
</div>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign="top">007 - 024</td>
|
|
|
|
<td valign="top"><em>STATEMENT element match</em>. The
|
|
"block" rule should fire (i.e. reject the policy)
|
|
if the service asks for personal data (
|
|
<code><DATA></code> elements in the categories
|
|
<code>physical</code>, <code>demographic</code> or
|
|
<code>uniqueid</code>) that is distributes to 3rd parties (
|
|
<code><RECIPIENT></code> matching
|
|
<code><same/></code>,
|
|
<code><other-recipient/></code> " or
|
|
<code><published/></code>). Note that rules do not
|
|
always feature <em>all</em> required elements of a P3P
|
|
policy. Given that both the <code><DATA></code> and
|
|
<code><RECIPIENT></code> element match, this block
|
|
rule will match regardless of the <a
|
|
href="http://www.w3.org/TR/P3P/#PURPOSE">purpose</a> (
|
|
<code><PURPOSE></code>) specified in the policy.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign="top">010, 017, ...</td>
|
|
|
|
<td valign="top">
|
|
<em>Connectives.</em> Using the
|
|
<code>appel:connective</code> attribute, the rule author
|
|
can explictly specify different matching semantics for
|
|
the contained expressions of an element. APPEL supports
|
|
six different connectives ( <code>or</code>,
|
|
<code>and</code>, <code>non-or</code>,
|
|
<code>non-and</code>, <code>or-exact</code> and
|
|
<code>and-exact</code>) that implement different matching
|
|
semantics. If no connective is given, the default
|
|
matching semantics require an <em>and</em> match between
|
|
the rule and the available evidence.
|
|
|
|
<div class="bnf">
|
|
<pre>
|
|
[12] connective = 'appel:connective="' conn '"'
|
|
|
|
[13] conn = or | and | non-or | non-and | or-exact | and-exact
|
|
</pre>
|
|
</div>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign="top">027 - 040</td>
|
|
|
|
<td valign="top"><em>Restricted request-rule</em>. This
|
|
"request" rule only continues to match the policy
|
|
if it has been fetched while requesting a Web resource from
|
|
<code>www.my-bank.com</code>. This is because of the
|
|
additional <a
|
|
href="#REQUEST"><code><appel:REQUEST></code></a>
|
|
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.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign="top">041 - 054</td>
|
|
|
|
<td valign="top"><em>request</em>. 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 <a
|
|
href="http://www.w3.org/TR/P3P/#PURPOSE">purpose</a> (
|
|
<code><PURPOSE></code>) and <a
|
|
href="http://www.w3.org/TR/P3P/#RECPNT">recipient
|
|
element</a> ( <code><RECIPIENT></code>) <em>do
|
|
not</em> have to appear in the rule, even though they are
|
|
required in a P3P policy statement.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign="top">046 - 047</td>
|
|
|
|
<td valign="top"><em>Data Elements to match</em>. Because
|
|
of the use of the " <code>or-exact</code> "- <a
|
|
href="#def_connective">connective</a>, the
|
|
"request" rule will only match if the statement
|
|
in the policy does not contain any <em>additional</em> data
|
|
references <em>not</em> 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
|
|
<em>false</em> (i.e. <em>not</em> accepting the
|
|
policy).</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign="top">050 - 052</td>
|
|
|
|
<td valign="top"><em>DISPUTE-resolution information to
|
|
match</em>. 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.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign="top">055 - 076</td>
|
|
|
|
<td valign="top"><em>"prompt and request"
|
|
rule</em>. Although the user agrees to releasing her name
|
|
for non-marketing purposes to Web Sites that have
|
|
assurances from both TrustUs <i>and</i> 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.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign="top">010, 017, 028, ...</td>
|
|
|
|
<td valign="top"><em>Matching a list of alternatives</em>.
|
|
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 <em>not</em> be matched, the
|
|
"non-or" connective can be used.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign="top">071 - 074</td>
|
|
|
|
<td valign="top"><em>Matching conjunctive values</em>. In
|
|
order to require both assurances from TrustUs <i>and</i>
|
|
PrivacyProtect in the policy, the rule lists the same
|
|
element ( <code><DISPUTES></code>) multiple times
|
|
(but with different values in their attributes). Because of
|
|
the implied "and" connective (this is the default
|
|
connective if no <code>appel:connective</code> attribute is
|
|
given) in the enclosing <code>DISPUTES-GROUP</code>
|
|
element, this represents a logical AND between the
|
|
values.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign="top">077 - 080</td>
|
|
|
|
<td valign="top"><em>"limited" rule</em>. 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 <code><OTHERWISE></code> rule at the
|
|
top), our user agent would always issue a prompt for all
|
|
incoming policies (see comment below).</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign="top">079</td>
|
|
|
|
<td valign="top">
|
|
<em>Degenerate Expression</em>. Using the degenerate
|
|
expression <code><OTHERWISE></code>, we can create
|
|
"catch-all" rules that are always known to
|
|
evaluate to true. Rules containing
|
|
<code><OTHERWISE></code> 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.
|
|
|
|
<p>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.</p>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<h1><a name="techdef" id="techdef">4. Technical Definition</a></h1>
|
|
|
|
<p>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 <a href="#match">5.4
|
|
Matching Semantics</a>.</p>
|
|
|
|
<h2><a name="syntax" id="syntax">4.1 Syntax & Encoding</a></h2>
|
|
|
|
<p>This section lists the exact syntax used for the APPEL1.0
|
|
language, as well as encoding issues.</p>
|
|
|
|
<h3><a name="bnf" id="bnf">4.1.1 BNF Syntax, APPEL1.0
|
|
(non-normative)</a></h3>
|
|
|
|
<p>The BNF syntax below is just an informal representation of the
|
|
actual syntax. Please refer to <a href="#xmlschema">Appendix C: XML
|
|
Schema</a> for the normative description of the APPEL syntax.
|
|
Detailed explanations can be found in section <a
|
|
href="#elements">4.2 Elements</a>.<br />
|
|
</p>
|
|
|
|
<div class="caption">
|
|
<b>Figure 4.1:</b> APPEL1.0 BNF Syntax (informative)
|
|
</div>
|
|
|
|
<div class="framed-bnf">
|
|
<pre>
|
|
[1] ruleset = '<appel:RULESET
|
|
xmlns:appel="http://www.w3.org/2002/04/APPELv1" '
|
|
common-attributes '>'
|
|
rseq
|
|
'</appel:RULESET>'
|
|
|
|
[2] rseq = 1*rule
|
|
|
|
[3] rule = '<appel:RULE behavior="' behavior '"'
|
|
common-attributes
|
|
rule-attributes
|
|
[connective] '>'
|
|
body
|
|
'</appel:RULE>'
|
|
|
|
[4] common-attributes= [' crtdby=' quoted-string]
|
|
[' crtdon="' datetime '"']
|
|
[' description=' quoted-string]
|
|
|
|
[5] rule-attributes = [' prompt ="' ('yes'|'no') '"']
|
|
[' persona=' quoted-string]
|
|
[' promptmsg=' quoted-string]
|
|
|
|
[6] body = top-expression | '<appel:OTHERWISE/>'
|
|
|
|
[7] behavior = 'request' | 'block' | 'limited'
|
|
|
|
[8] top-expression = policy | request-group [policy]
|
|
|
|
[9] policy = <[<a
|
|
href="#P3P10">P3P10</a>] policy snippet (including embed. connectives)>
|
|
|
|
[10] request-group = '<appel:REQUEST-GROUP ' [connective]'>'
|
|
1*request
|
|
'</appel:REQUEST-GROUP>'
|
|
|
|
[11] request = '<appel:REQUEST uri="' [<a
|
|
href="#URI">URI</a>] as per <a
|
|
href="http://www.ietf.org/rfc/rfc2396.txt">RFC 2396</a>'">'
|
|
|
|
[12] connective = 'appel:connective="' conn '"'
|
|
|
|
[13] conn = or | and | non-or | non-and | or-exact | and-exact
|
|
|
|
[14] quoted-string = '"' string '"'
|
|
|
|
[15] string = <[<a
|
|
href="#utf8">UTF-8</a>] string (with " and & escaped)>
|
|
|
|
[16] datetime = <date/time as per [<a
|
|
href="#bib_iso8601">ISO8601</a>] or section 3.3.1 in [<a
|
|
href="#RFC2616">RFC2616</a>]>
|
|
</pre>
|
|
</div>
|
|
|
|
<p>Details are described in section <a href="#elements">4.2
|
|
Elements</a> below. Please see also <a href="#future">Appendix A:
|
|
Future Work</a>.</p>
|
|
|
|
<h3><a name="transport" id="transport">4.1.2 Transport &
|
|
Storage</a></h3>
|
|
|
|
<p>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 <a
|
|
href="http://www.w3.org/TR/1998/REC-xml-19980210#charencoding">character
|
|
encoding</a> section in the <a
|
|
href="http://www.w3.org/TR/1998/REC-xml-19980210">XML
|
|
Recommendation</a>. Note that in XML documents both element and
|
|
attribute names are <em>case-sensitive</em>. 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 <a
|
|
href="http://www.w3.org/TR/P3P/">the latest P3P Specification</a>
|
|
for a normative definition of case in P3P elements.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<h2><a name="elements" id="elements">4.2 Elements</a></h2>
|
|
|
|
<p>This section describes the elements that are used to create an
|
|
APPEL ruleset. Each element is given in <code><></code>
|
|
brackets, followed by the list of attributes that can appear in the
|
|
element. All listed attributes are optional, except when tagged as
|
|
<em>mandatory</em>. For more information on the actual usage of
|
|
these elements, please refer to section <a href="#semantics">5.
|
|
Semantics</a> as well as section <a href="#example">3. Simple
|
|
Example Scenario</a>.</p>
|
|
|
|
<h3><a name="RULESET" id="RULESET">4.2.1 The
|
|
<code><appel:RULESET></code> element</a></h3>
|
|
|
|
<dl>
|
|
<dt><code><appel:RULESET></code></dt>
|
|
|
|
<dd>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 <b>true</b>.</dd>
|
|
|
|
<dt><code>crtdby</code></dt>
|
|
|
|
<dd>Name or ID of the ruleset author (could be the user
|
|
agent).</dd>
|
|
|
|
<dt><code>crtdon</code></dt>
|
|
|
|
<dd>Time & Date of ruleset creation.</dd>
|
|
|
|
<dt><code>description</code></dt>
|
|
|
|
<dd>A short natural language explanation that can be displayed by
|
|
the user agent when the ruleset gets selected, or to help
|
|
debugging a rulefile.</dd>
|
|
</dl>
|
|
|
|
<div class="bnf">
|
|
<pre>
|
|
[1] ruleset = '<appel:RULESET
|
|
xmlns:appel="http://www.w3.org/2002/04/APPELv1" '
|
|
common-attributes '>'
|
|
rseq
|
|
'</appel:RULESET>'
|
|
|
|
[2] rseq = 1*rule
|
|
|
|
[4] common-attributes= [' crtdby=' quoted-string]
|
|
[' crtdon="' datetime '"']
|
|
[' description=' quoted-string]
|
|
</pre>
|
|
</div>
|
|
|
|
<h3><a name="RULE" id="RULE">4.2.2 The
|
|
<code><appel:RULE></code> element</a></h3>
|
|
|
|
<dl>
|
|
<dt><code><appel:RULE></code></dt>
|
|
|
|
<dd>Contains conditions under which a certain behavior should be
|
|
carried out by the calling program.</dd>
|
|
|
|
<dt><code>behavior</code>     <em>(mandatory
|
|
attribute)</em></dt>
|
|
|
|
<dd>Behavior that should be carried out by the calling program if
|
|
the expressions match the evidence.</dd>
|
|
|
|
<dt><code>connective</code></dt>
|
|
|
|
<dd>Allows for different matching semantics of enclosed
|
|
subelements. See section <a href="#connective">4.2.5 The
|
|
<code>appel:connective</code> attribute</a> below.</dd>
|
|
|
|
<dt><code>crtdby</code></dt>
|
|
|
|
<dd>Name or ID of the rule author (could be the user agent).</dd>
|
|
|
|
<dt><code>crtdon</code></dt>
|
|
|
|
<dd>Time & Date of rule creation.</dd>
|
|
|
|
<dt><code>description</code></dt>
|
|
|
|
<dd>A short natural language explanation that can be displayed by
|
|
the user agent when the rule gets executed, or to help debugging
|
|
a rulefile. Note that a separate <code>promptmsg</code> should be
|
|
used in case the user should be prompted for a decision.</dd>
|
|
|
|
<dt><code>prompt</code></dt>
|
|
|
|
<dd>Indicates whether a prompt message should be displayed to the
|
|
user. If this attribute is not present, no prompt message is
|
|
displayed.</dd>
|
|
|
|
<dt><code>persona</code></dt>
|
|
|
|
<dd>If the user agent supports multiple user repositories, this
|
|
string identifies the data repository that should be used in case
|
|
the resource is accessed (i.e. if the rule that fires features a
|
|
"request" or "limited" behavior, or if a
|
|
"block" rule is overridden at the prompt). If no
|
|
persona is given, the user agent's default value is
|
|
used.</dd>
|
|
|
|
<dt><code>promptmsg</code></dt>
|
|
|
|
<dd>A short natural language explanation or question that can be
|
|
displayed by the user agent when the user should be prompted for
|
|
a decision. Note that the <code>description</code> field can be
|
|
used to hold a brief summary of the rule for debugging or
|
|
informational purposes.</dd>
|
|
</dl>
|
|
|
|
<p>A rule that only contains a <code><POLICY></code> element,
|
|
but no <code><appel:REQUEST></code> element, will try to
|
|
match policies on <em>any</em> site. A rule that contains both a
|
|
<code><POLICY></code> element <em>and</em> an
|
|
<code><appel:REQUEST></code> element will only match policies
|
|
at sites that match the URI given in the
|
|
<code><appel:REQUEST></code> element. A rule that only
|
|
contains an <code><appel:REQUEST></code> element, but no
|
|
<code><POLICY></code> element, will match whenever a resource
|
|
from that particular site is requested, no matter what P3P policy
|
|
applies (even if <em>no</em> policy applies). If you want to match
|
|
sites that <em>don't</em> have a P3P policy, use the
|
|
<code>non-or</code> or <code>non-and</code> connectives in the
|
|
<code><appel:RULE></code> element, together with a
|
|
<code><POLICY></code> element. A rule with an empty list of
|
|
expressions will never get activated. In order to create a
|
|
<em>default rule</em> that will trigger if no other (preceding)
|
|
rule fired, the degenerate expression
|
|
<code><OTHERWISE/></code> should be used.<br />
|
|
</p>
|
|
|
|
<div class="bnf">
|
|
<pre>
|
|
[3] rule = '<appel:RULE behavior="' behavior '"'
|
|
common-attributes
|
|
rule-attributes
|
|
[connective] '>'
|
|
body
|
|
'</appel:RULE>'
|
|
|
|
[5] rule-attributes = [' prompt ="' ('yes'|'no') '"']
|
|
[' persona=' quoted-string]
|
|
[' promptmsg=' quoted-string]
|
|
|
|
[6] body = top-expression | '<appel:OTHERWISE/>'
|
|
|
|
[7] behavior = 'request' | 'block' | 'limited'
|
|
|
|
[8] top-expression = policy | request-group [policy]
|
|
</pre>
|
|
</div>
|
|
|
|
<h3><a name="OTHERWISE" id="OTHERWISE">4.2.3 The
|
|
<code><appel:OTHERWISE></code> element</a></h3>
|
|
|
|
<dl>
|
|
<dt><code><appel:OTHERWISE></code></dt>
|
|
|
|
<dd>so called degenerate-expression, which always evaluates to
|
|
<b>true</b>. This can be used to craft "catch-all"
|
|
rules that match all cases not covered by previous rules.</dd>
|
|
</dl>
|
|
|
|
<p><code><appel:OTHERWISE></code> 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 <code><OTHERWISE></code> element together with a
|
|
<em>request</em> behavior, which would result in indiscriminated
|
|
access to all sites not covered by the preceding rules.<br />
|
|
</p>
|
|
|
|
<div class="bnf">
|
|
<pre>
|
|
[6] body = top-expression | '<appel:OTHERWISE/>'
|
|
</pre>
|
|
</div>
|
|
|
|
<h3><a name="REQUEST" id="REQUEST">4.2.4 The
|
|
<code><appel:REQUEST></code> element</a></h3>
|
|
|
|
<dl>
|
|
<dt><code><appel:REQUEST></code></dt>
|
|
|
|
<dd>allows the creation of rules that only apply to a certain
|
|
resource or domain.</dd>
|
|
|
|
<dt><code>connective</code></dt>
|
|
|
|
<dd>Allows for different matching semantics of enclosed
|
|
subelements. See section <a href="#connective">4.2.5 The
|
|
<code>appel:connective</code> attribute</a> below.</dd>
|
|
|
|
<dt><code>uri</code>     <em>(mandatory
|
|
attribute)</em></dt>
|
|
|
|
<dd>the URI of the currently requested resource (not the policy
|
|
URI).</dd>
|
|
</dl>
|
|
|
|
<p>Together with a <code><POLICY></code> -expression, the
|
|
<code><appel:REQUEST></code> element (embedded in an
|
|
<code><appel:REQUEST-GROUP></code> 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 <code><appel:REQUEST></code> element will
|
|
limit the application of the <code><POLICY></code> expression
|
|
to the given URI.</p>
|
|
|
|
<p>In order to list multiple, alternative resources and/or domains
|
|
in a single rule, you can embed multiple
|
|
<code><appel:REQUEST></code> elements in an
|
|
<code><appel:REQUEST-GROUP></code> element and connect them
|
|
using an <code>or</code> or <code>or-exact</code> connective.<br />
|
|
</p>
|
|
|
|
<div class="bnf">
|
|
<pre>
|
|
[8] top-expression = policy | request-group [policy]
|
|
|
|
[10] request-group = '<appel:REQUEST-GROUP ' [connective]'>'
|
|
1*request
|
|
'</appel:REQUEST-GROUP>'
|
|
|
|
[11] request = '<appel:REQUEST uri="' [<a
|
|
href="#URI">URI</a>] as per <a
|
|
href="http://www.ietf.org/rfc/rfc2396.txt">RFC 2396</a>
|
|
|
|
'">'
|
|
</pre>
|
|
</div>
|
|
|
|
<h3><a name="connective" id="connective">4.2.5 The
|
|
<code>appel:connective</code> attribute</a></h3>
|
|
|
|
<dl>
|
|
<dt><code>appel:connective</code></dt>
|
|
|
|
<dd>determines how contained expressions are matched when a rule
|
|
is compared to the available evidence.</dd>
|
|
</dl>
|
|
|
|
<p>APPEL supports six different kinds of connectives:
|
|
<code>or</code>, <code>and</code>, <code>non-or</code>,
|
|
<code>non-and</code>, <code>or-exact</code> and
|
|
<code>and-exact</code>. Please refer to section <a
|
|
href="#match_connectives">5.4.1 Connectives</a> for a description
|
|
of their semantics. If no <code>appel:connective</code> is given,
|
|
APPEL's matching semantics default to an <code>and</code>
|
|
match: <em>All</em> of the containedexpressions <em>must</em>
|
|
appear in the evidence, <em>additional</em> elements will be
|
|
ignored.<br />
|
|
</p>
|
|
|
|
<div class="bnf">
|
|
<pre>
|
|
[12] connective = 'appel:connective="' conn '"'
|
|
|
|
[13] conn = or | and | non-or | non-and | or-exact | and-exact
|
|
</pre>
|
|
</div>
|
|
|
|
<h3><a name="p3p10policy" id="p3p10policy">4.2.6 The P3P1.0 policy
|
|
snippet</a></h3>
|
|
|
|
<p>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.</p>
|
|
|
|
<div class="bnf">
|
|
<pre>
|
|
[8] top-expression = policy | request-group [policy]
|
|
|
|
[9] policy = <[<a
|
|
href="#P3P10">P3P10</a>] policy snippet (including embed. connectives)>
|
|
</pre>
|
|
</div>
|
|
|
|
<p>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 <code>DATA</code> element, even though such
|
|
an element would need to be embedded within a
|
|
<code>STATEMENT</code> 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 <code>DATA</code> elements and their
|
|
<code>CATEGORIES</code>, APPEL rule evaluators must properly check
|
|
the corresponding P3P1.0 semantics (see sections <a
|
|
href="#match_dataref">5.4.5 Matching <code>p3p:DATA</code>
|
|
elements</a> and <a href="#match_cat">5.4.6 Category expansion</a>
|
|
below).</p>
|
|
|
|
<h1><a name="semantics" id="semantics">5 Semantics</a></h1>
|
|
|
|
<p>While section <a href="#operation">2. General Operation and
|
|
Semantics</a> 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 <a
|
|
href="#operation">section 2</a>, and then focus on individual
|
|
issues concerning rule evaluation: rule ordering, expressions,
|
|
matching, and rule expiration.</p>
|
|
|
|
<h2><a name="nut" id="nut">5.1 The Rule Evaluator in a
|
|
Nutshell</a></h2>
|
|
|
|
<p>A P3P user agent or other program will invoke an APPEL rule
|
|
evaluator, providing an APPEL <b>ruleset</b> and various pieces of
|
|
"<b>evidence</b>," 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).</p>
|
|
|
|
<p>The rule evaluator MUST return a <b>behavior</b> (i.e., one of
|
|
the three <a href="#def_beh_standard">standard behaviors</a>
|
|
"request", "block" or "limited") that
|
|
the calling program should carry out (including any optional
|
|
<code>prompt</code> 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.</p>
|
|
|
|
<h3><a name="nut_be" id="nut_be">5.1.1 Behaviors</a></h3>
|
|
|
|
<p>A user agent MUST at least support the three <a
|
|
href="#def_beh_standard">standard behaviors</a>
|
|
"request", "block" or "limited". Each
|
|
behavior may optionally require a user prompt, as indicated by the
|
|
<code>prompt</code> attribute. User agents SHOULD if possible
|
|
support such prompts.</p>
|
|
|
|
<h3><a name="nut_rs" id="nut_rs">5.1.2 Rulesets</a></h3>
|
|
|
|
<p>A ruleset consists of an ordered list of <b>rules</b>. Rules
|
|
describe conditions under which a certain behavior should be
|
|
carried out by the calling program.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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".</p>
|
|
|
|
<h3><a name="nut_ex" id="nut_ex">5.1.3 Expressions</a></h3>
|
|
|
|
<p>Each rule contains a number of top-level <b>expressions</b> in
|
|
form of a well-formed XML element and features one single
|
|
<b>behavior</b> (with an optional <code>prompt</code> attribute).
|
|
An APPEL compliant user agent MUST at least support the P3P
|
|
<code><POLICY></code> element, the APPEL
|
|
<code><appel:OTHERWISE></code> element, as well as the
|
|
<code><appel:REQUEST></code> element (representing the URI of
|
|
the <em>currently requested resource</em>, not the policy URI).</p>
|
|
|
|
<p>Each expression in a rule is implicitly ANDed together with all
|
|
of its enclosed <a href="#def_attr_expr">attribute expressions</a>.
|
|
<a href="#def_cont_expr">Contained expressions</a> (including <a
|
|
href="#def_top_expr">top-level expressions</a>) are by default also
|
|
ANDed together, unless the rule author explicitly specified an
|
|
alternative matching using the <code>connective</code>
|
|
attribute.</p>
|
|
|
|
<p>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 <code>STATEMENT</code> element
|
|
nested inside a <code>POLICY</code> element in the rule will only
|
|
match a <code>STATEMENT</code> element in the evidence that is
|
|
nested inside a matching <code>POLICY</code> element.</p>
|
|
|
|
<p>A rule containing no expressions always evaluates to false, a
|
|
rule containing only the <a href="#def_dege_expr">degenerate
|
|
expression</a> always evaluates to true.</p>
|
|
|
|
<h2><a name="order" id="order">5.2 Rules ordering</a></h2>
|
|
|
|
<blockquote>
|
|
<p><em>How APPEL evaluates multiple rules in a ruleset</em></p>
|
|
</blockquote>
|
|
|
|
<p>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!</p>
|
|
|
|
<p>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:</p>
|
|
|
|
<ol>
|
|
<li>Exceptions (any behavior)</li>
|
|
|
|
<li>Request rules</li>
|
|
|
|
<li>Limited rules</li>
|
|
|
|
<li>Block rules</li>
|
|
</ol>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>Care should be taken that only a single rule containing the
|
|
degenerate expression <code><OTHERWISE></code> exists and is
|
|
placed at the end of the ruleset.</p>
|
|
|
|
<h2><a name="expressions" id="expressions">5.3 Expressions</a></h2>
|
|
|
|
<blockquote>
|
|
<p><em>How to specify what to match in a rule</em></p>
|
|
</blockquote>
|
|
|
|
<p>Every rule in an APPEL ruleset contains a number of top-level <a
|
|
href="#def_expr">expressions</a> 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
|
|
<code><appel:REQUEST></code> element).</p>
|
|
|
|
<p>All sub-expressions of a single expression are per default
|
|
always ANDed together, that is, <i>all</i> <a
|
|
href="#def_attr_expr">attribute</a> and <a
|
|
href="#def_cont_expr">contained</a> expressions have to evaluate to
|
|
<b>true</b> in order for the expression to match. However, using
|
|
the <code>appel:connective</code> attribute, the rule author can
|
|
explictly specify different matching semantics for the top-level
|
|
and contained expressions.</p>
|
|
|
|
<p>Note that connectives only govern the matching of contained
|
|
expressions appearing <em>at this level</em>. Should these
|
|
contained expressions in turn contain other expressions, they will
|
|
be matched using the default matching semantics (i.e.,
|
|
<code>and</code>) unless another <code>connective</code> attribute
|
|
is used within the contained expression. See section <a
|
|
href="#match_connectives">5.4.1 Connectives</a> for details.</p>
|
|
|
|
<p>Figure 5.1 below gives the informal definition of the 3 main
|
|
types of expressions in APPEL.<br />
|
|
</p>
|
|
|
|
<div class="caption">
|
|
<b>Figure 5.1:</b> APPEL Expressions (informative)
|
|
</div>
|
|
|
|
<div class="framed-bnf">
|
|
<pre>
|
|
[1] <span
|
|
class="highlit">expression</span> = empty-expression | containing-expression | <code><a
|
|
href="http://www.w3.org/TR/2000/WD-xml-2e-20000814#dt-chardata">#PCDATA</a></code>
|
|
|
|
[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] <span
|
|
class="highlit">attribute-expression</span> = attribute_name "=" quoted-string
|
|
|
|
[6] <span class="highlit">contained-expression</span> = expression
|
|
|
|
[7] attribute_name = identifier
|
|
|
|
[8] identifier = <a valid XML identifier>
|
|
|
|
[9] quoted-string = `"` string `"`
|
|
|
|
[10] string = <[<a
|
|
href="#utf8">UTF-8</a>] string (with " and & escaped)>
|
|
|
|
[11] connective = 'appel:connective="' conn '"'
|
|
|
|
[12] conn = or | and | non-or | non-and | or-exact | and-exact
|
|
</pre>
|
|
</div>
|
|
|
|
<p>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 <code>STATEMENT</code> -expressions in the
|
|
rule independantly match the same <code><STATEMENT></code>
|
|
element in the evidence.<br />
|
|
</p>
|
|
|
|
<div class="caption">
|
|
<b>Figure 5.2:</b> Matching Example
|
|
</div>
|
|
|
|
<div class="table">
|
|
<table summary="Matching example" border="0" width="100%">
|
|
<tbody>
|
|
<tr>
|
|
<td>
|
|
<pre>
|
|
<-- ruleset -->
|
|
|
|
<appel:RULE behavior="request">
|
|
<POLICY>
|
|
<STATEMENT>
|
|
<RECIPIENT appel:connective="or-exact">
|
|
<ours/>
|
|
</RECIPIENT>
|
|
<DATA-GROUP appel:connective="or-exact">
|
|
<DATA ref="#user.*"/>
|
|
</DATA-GROUP>
|
|
</STATEMENT>
|
|
<STATEMENT>
|
|
<PURPOSE appel:connective="or-exact">
|
|
<customization/>
|
|
</PURPOSE>
|
|
<DATA-GROUP>
|
|
<DATA>
|
|
<CATEGORIES appel:connective="or-exact">
|
|
<online/>
|
|
</CATEGORIES>
|
|
</DATA>
|
|
</DATA-GROUP>
|
|
</STATEMENT>
|
|
</POLICY>
|
|
</appel:RULE>
|
|
</pre>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign="top">
|
|
<pre>
|
|
<-- evidence (abbreviated) -->
|
|
|
|
<POLICY>
|
|
...
|
|
<STATEMENT>
|
|
<RECIPIENT><ours/></RECIPIENT>
|
|
<PURPOSE><customization/></PURPOSE>
|
|
<DATA-GROUP>
|
|
<DATA ref="#user.home.online.email"/>
|
|
</DATA-GROUP>
|
|
</STATEMENT>
|
|
</POLICY>
|
|
</pre>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<p>Expressions over elements that are <em>not</em> in the set of
|
|
evidence provided by the calling program always evaluate to
|
|
<b>false</b>, unless the rule author explicitly used the
|
|
<code>appel:connective</code> attribute with either the
|
|
<code>or</code>, <code>or-exact</code>, <code>non-or</code> or
|
|
<code>non-and</code> flag. For example, a rule using a (contained)
|
|
expression to match a <a
|
|
href="http://www.w3.org/TR/P3P/#DISPUTES">disputes element</a>
|
|
without any connectives would always fail unless the evidence would
|
|
contain such an element.</p>
|
|
|
|
<p>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 <code>appel:connective</code>
|
|
attribute with either the <code>or-exact</code>,
|
|
<code>and-exact</code>, <code>non-or</code> or <code>non-and</code>
|
|
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 <em>both</em> a disputes <em>and</em> a disclosure
|
|
element.</p>
|
|
|
|
<p>When using APPEL1.0 all elements other that P3P policies and
|
|
<code>appel:REQUEST</code> 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 <a href="#nut">5.1 The Rule Evaluator in a
|
|
Nutshell</a>).</p>
|
|
|
|
<h2><a name="match" id="match">5.4 Matching</a></h2>
|
|
|
|
<blockquote>
|
|
<p><em>How APPEL matches expressions against available
|
|
evidence</em></p>
|
|
</blockquote>
|
|
|
|
<p>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 <a
|
|
href="#match_connectives">5.4.1 Connectives</a> below) and can be
|
|
summarized as follows:<br />
|
|
</p>
|
|
|
|
<ol>
|
|
<li><b>All attribute expressions in a rule are ANDed, additional
|
|
attributes are ignored.</b><br />
|
|
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.</li>
|
|
|
|
<li>
|
|
<b>Contained expressions are...</b><br />
|
|
|
|
|
|
<ol>
|
|
<li><b>...ORed</b> ( <code>or</code>, <code>or-exact</code>
|
|
and <code>non-or</code> connectives)<br />
|
|
At least <em>one</em> contained expression in the current
|
|
expression has to match an element in a corresponding element
|
|
of the evidence.<br />
|
|
If the <code>non-or</code> connective is used, the rule will
|
|
<em>fail</em> in the above case, i.e. it only evaluates to
|
|
true if <em>none</em> of the contained expressions in the
|
|
current expression can be found in a corresponding element of
|
|
the evidence.</li>
|
|
|
|
<li><b>...ANDed</b> ( <code>and</code>,
|
|
<code>and-exact</code> and <code>non-and</code>
|
|
connectives)<br />
|
|
Any contained element listed in the expression <em>has</em>
|
|
to appear in a corresponding position in the evidence, with
|
|
matching attributes and values.<br />
|
|
If the <code>non-and</code> connective is used, the rule
|
|
will <em>fail</em> in the above case, i.e. it only evaluates
|
|
to true if <em>all</em> of the contained expressions in the
|
|
current expression can <em>not</em> be found in a
|
|
corresponding element of the evidence.</li>
|
|
</ol>
|
|
</li>
|
|
|
|
<li>
|
|
<b>Additional evidence (non-attribute)...</b>
|
|
|
|
<ol>
|
|
<li><b>...is ignored</b> ( <code>or</code>, <code>and</code>,
|
|
<code>non-or</code> and <code>non-and</code>
|
|
connectives)<br />
|
|
Any element listed in the evidence that can not be found in
|
|
the rule (or which can be found but without matching
|
|
attributes and values) will be ignored.</li>
|
|
|
|
<li><b>...is <em>not</em> ignored</b> ( <code>or-exact</code>
|
|
and <code>and-exact</code> connectives)<br />
|
|
Any element listed in the evidence that can not be found in
|
|
the rule (or which can be found but without matching
|
|
attributes and values) will prompt the rule to fail.</li>
|
|
</ol>
|
|
</li>
|
|
</ol>
|
|
|
|
<p>The different matching semantics that result from the six
|
|
available connectives are summarized in Table 5.3 below:<br />
|
|
</p>
|
|
|
|
<div class="table">
|
|
<table summary="Connectives" width="100%" cellspacing="0"
|
|
cellpadding="5" border="1">
|
|
<caption>
|
|
<b>Table 5.3:</b> Connectives Summary (informative)
|
|
</caption>
|
|
|
|
<tbody>
|
|
<tr>
|
|
<th rowspan="2" colspan="2">
|
|
</th>
|
|
|
|
<th colspan="2">Contained expressions are</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<th>ORed</th>
|
|
|
|
<th>ANDed</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<th rowspan="2">Additional evidence</th>
|
|
|
|
<th>is ignored</th>
|
|
|
|
<td><code>or</code>, <code>non-or</code> </td>
|
|
|
|
<td><code>and</code> (default), <code>non-and</code> </td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<th>is not ignored</th>
|
|
|
|
<td><code>or-exact</code> </td>
|
|
|
|
<td><code>and-exact</code> </td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
|
|
<h3><a name="match_connectives" id="match_connectives">5.4.1
|
|
Connectives</a></h3>
|
|
|
|
<p>While <em>attribute-expressions</em> are always ANDed, the
|
|
matching of <em>contained-expressions</em> 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 <code>#PCDATA</code>, 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, <em><strong>R</strong></em>
|
|
denotes the set of immediate subelements below the currently
|
|
compared rule element (i.e., the contained expressions, including
|
|
<code>#PCDATA</code>), while <em><strong>E</strong></em> identifies
|
|
the immediate subelements (including <code>#PCDATA</code>) below
|
|
the corresponding element in the evidence. Note that subelements of
|
|
subelements are <em>not</em> part of these sets but need to be
|
|
compared recursively in turn for each of the subelements.</p>
|
|
|
|
<table summary="Matching Semantics of Connectives" border="1">
|
|
<caption>
|
|
<b>Table 5.4:</b> Matching Semantics of Connectives
|
|
</caption>
|
|
|
|
<tbody>
|
|
<tr>
|
|
<th class="top" rowspan="2">Connective</th>
|
|
|
|
<th class="top">Short Description (informative)</th>
|
|
|
|
<th class="top">Formula (informative)</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<th class="top" colspan="3">Long Description (normative)</th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<th rowspan="2" class="side">or</th>
|
|
|
|
<td class="top">at least one common element between rule
|
|
elements <strong>R</strong> and evidence <strong>E</strong>
|
|
</td>
|
|
|
|
<td class="top"><img width="75" height="31"
|
|
src="or-20020415.png" alt="\( R\cap E\neq \emptyset \)" />
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td class="desc" colspan="3">Matches if <em>one or more</em>
|
|
of the contained expressions can be found (at the correct
|
|
position) in the evidence. If the evidence contains elements
|
|
<em>not</em> listed in the rule, such evidence is
|
|
<em>ignored</em>. 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 <em>always fails</em> !</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<th rowspan="2" class="side">and</th>
|
|
|
|
<td class="top">rule elements <strong>R</strong> subset of
|
|
evidence <strong>E</strong> </td>
|
|
|
|
<td class="top"><img width="49" height="29"
|
|
src="and-20020415.png" alt="\( R\subseteq E \)" /> </td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td class="desc" colspan="3">Matches if <em>all</em> of the
|
|
contained expressions can be found (at the correct position)
|
|
in the evidence. If the evidence contains elements
|
|
<em>not</em> listed in the rule, such evidence is
|
|
<em>ignored</em>. 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 <em>always matches</em> (provided that all of its
|
|
attribute-expressions match). <b>This is the default matching
|
|
semantics if no connective is given.</b> </td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<th rowspan="2" class="side">non-or</th>
|
|
|
|
<td class="top">no common elements between rule elements
|
|
<strong>R</strong> and evidence <strong>E</strong> </td>
|
|
|
|
<td class="top"><!-- MATH: $R\cap E=\emptyset$ -->
|
|
<img width="75" height="31" src="non-or-20020415.png"
|
|
alt="\( R\cap E=\emptyset \)" /> </td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td class="desc" colspan="3">Matches if <em>none</em> of the
|
|
contained expressions can be found (at the correct position)
|
|
in the evidence. If the evidence contains elements
|
|
<em>not</em> listed in the rule, such evidence is
|
|
<em>ignored</em>. In case no contained expressions are
|
|
listed, the enclosing expression <em>always matches</em>
|
|
(provided that all of its attribute-expressions match). This
|
|
connective is the equivalent of negating a standard
|
|
<code>or</code> match described above: <code>NOT (... or ...
|
|
or ...)</code>.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<th rowspan="2" class="side">non-and</th>
|
|
|
|
<td class="top">at least one rule element <strong>R</strong>
|
|
not in evidence <strong>E</strong> </td>
|
|
|
|
<td class="top"><!-- MATH: $R\setminus E\neq \emptyset$ -->
|
|
<img width="72" height="31" src="non-and-20020415.png"
|
|
alt="\( R\setminus E\neq \emptyset \)" /> </td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td class="desc" colspan="3">Matches if <em>not all</em> of
|
|
the contained expressions can be found (at the correct
|
|
position) in the evidence. If the evidence contains elements
|
|
<em>not</em> listed in the rule, such evidence is
|
|
<em>ignored</em>. In case no contained expressions are
|
|
listed, matching <em>always fails</em> ! This connective is
|
|
the equivalent of negating a standard <code>and</code> match
|
|
described above: <code>NOT (... and ... and ...)</code>.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<th rowspan="2" class="side">or-exact</th>
|
|
|
|
<td class="top">non-empty evidence <strong>E</strong> subset
|
|
of rule elements <strong>R</strong> </td>
|
|
|
|
<td class="top"><!-- MATH: $\emptyset\neq E\subseteq R$ -->
|
|
<img width="79" height="23" src="or-exact-20020415.png"
|
|
alt="\( E\subseteq R \)" /> </td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td class="desc" colspan="3">Matches if <em>one or more</em>
|
|
of the contained expressions can be found (at the correct
|
|
position) in the evidence. If the evidence contains elements
|
|
<em>not</em> listed in the rule, matching <em>fails</em>. In
|
|
case no contained expressions are listed, matching <em>always
|
|
fails!</em> Using this connective ensures that only those
|
|
elements listed in the rule appear in the evidence.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<th rowspan="2" class="side">and-exact</th>
|
|
|
|
<td class="top">evidence <strong>E</strong> equals rule
|
|
elements <strong>R</strong> </td>
|
|
|
|
<td class="top">E=R</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td class="desc" colspan="3">Matches if <em>all</em> of the
|
|
contained expressions can be found (at the correct position)
|
|
in the evidence. If the evidence contains elements
|
|
<em>not</em> listed in the rule, matching <em>fails</em>.
|
|
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).</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<h3><a name="match_attr_expr" id="match_attr_expr">5.4.2 Attribute
|
|
Expressions</a></h3>
|
|
|
|
<p>An <b>attribute expression</b> matches an attribute-value pair
|
|
of an XML element in the evidence if and only if:</p>
|
|
|
|
<ol>
|
|
<li>the attribute names are identical</li>
|
|
|
|
<li>AND the values are identical (using string comparison)</li>
|
|
</ol>
|
|
|
|
<p>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, <i>all</i> 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 <em>ignored</em>. 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.</p>
|
|
|
|
<p>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 "
|
|
<b>*</b> " may be used (e.g. as in
|
|
<code>attribute="*"</code>). 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
|
|
<em>not</em> appear in an element of the evidence set (e.g.
|
|
matching <code><DISPUTES></code> elements without
|
|
<code>resolution-type</code> attribute).</p>
|
|
|
|
<p>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 <em>always</em> ignored.</p>
|
|
|
|
<h3><a name="match_wild" id="match_wild">5.4.3 Expression
|
|
Metacharacters</a></h3>
|
|
|
|
<p>APPEL offers a single metacharacter for providing simple regular
|
|
expression support in its expressions: the asterix (" <b>*</b>
|
|
") 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 <em>egrep</em>.</p>
|
|
|
|
<p>Using metacharacters with strings allows us to specify ranges of
|
|
string-values, for example " <code>*.foo.com</code> " for
|
|
any host in the foo.com domain, or " <code>*://*"</code>
|
|
" for a URI (or at least something that looks like one).
|
|
Please note that string values are always matched <em>from the
|
|
beginning</em> of the string, unless the user specified an initial
|
|
<b>*</b> star symbol. Forcing a string match from the end is not
|
|
possible in APPEL1.0.</p>
|
|
|
|
<p>Note that since the asterix is also a legal character in URIs ([
|
|
<a href="#URI">URI</a> ]), some special conventions have to be
|
|
followed when encoding such "extended URIs" in an APPEL
|
|
ruleset:</p>
|
|
|
|
<ul>
|
|
<li>URIs represented in an APPEL ruleset MUST be properly
|
|
escaped, as in [ <a href="#URI">URI</a> ].</li>
|
|
|
|
<li>APPEL rule evaluators MUST escape any characters that should
|
|
be escaped, as according to [ <a href="#URI">URI</a> ], before
|
|
attempting to match a URI in an APPEL ruleset.</li>
|
|
|
|
<li>APPEL rule evaluators MUST un-escape any escaped sequences
|
|
that resolve to URI-legal characters, according to [ <a
|
|
href="#URI">URI</a> ], before attempting to match a URI in an
|
|
APPEL ruleset, EXCEPT</li>
|
|
|
|
<li>Literal '*'s in URIs MUST be escaped by APPEL rule
|
|
evaluators before attempting to match a URI in an APPEL
|
|
ruleset.</li>
|
|
<!-- <li> P3P user agents MUST ignore any URI pattern that do not conform to
|
|
[<a href="#URI">URI</a>]</li> -->
|
|
</ul>
|
|
|
|
<p>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 <code>#PCDATA</code>). However, you
|
|
can not use the wildcard character to match attribute or element
|
|
names, as for example in <code><DISPUTES
|
|
res*="service"></code> or <code><DISP*
|
|
resolution-type="service"></code> ! Nor can you use it
|
|
in the <code>ref</code> attribute of <code><DATA></code>
|
|
elements or the <code>base</code> attribute of
|
|
<code><DATA-GROUP</code> elements. For details on matching P3P
|
|
data elements, see section <a href="#match_dataref">5.4.5 Matching
|
|
<code>p3p:DATA</code> elements</a> below.</p>
|
|
|
|
<h3><a name="match_pcdata" id="match_pcdata">5.4.4 Matching
|
|
<code>#PCDATA</code></a></h3>
|
|
|
|
<p>It is possible to write APPEL rules that match
|
|
<code>#PCDATA</code> in the evidence, simply by including the text
|
|
to match as <code>#PCDATA</code> within the corresponding element
|
|
in the APPEl rule.</p>
|
|
|
|
<p>However, in order to facilitate rule formulation, the APPEL
|
|
ruleset evaluator MUST normalize both pieces of
|
|
<code>#PCDATA</code> before <code>#PCDATA</code> taken from the
|
|
ruleset is matched against <code>#PCDATA</code> taken from the
|
|
policy. The normalization algorithm to use is given below:</p>
|
|
|
|
<ol>
|
|
<li>Replace all occurrences of <code>#x9</code> (tab),
|
|
<code>#xA</code> (line feed) and <code>#xD</code> (carriage
|
|
return) with <code>#x20</code> (space).</li>
|
|
|
|
<li>Replace contiguous sequences of spaces with a single
|
|
space.</li>
|
|
|
|
<li>Delete any leading and trailing space.</li>
|
|
</ol>
|
|
|
|
<p>Once both values have been normalized, matching
|
|
<code>#PCDATA</code> is similar to <a
|
|
href="#match_attr_expr">attribute expression matching</a> described
|
|
above: Two pieces of <code>#PCDATA</code> match if and only if</p>
|
|
|
|
<ul>
|
|
<li>the values are identical (using string comparison over the
|
|
normalized values)</li>
|
|
</ul>
|
|
|
|
<p>Similarly to contained expressions, the matching of
|
|
<code>#PCDATA</code> is subject to the <a
|
|
href="#connective">appel:connective</a> given in its enclosing
|
|
element. For practical purposes, each block of <code>#PCDATA</code>
|
|
can be seen as a separate subelement for which the matching
|
|
semantics described in section <a href="#match_connectives">5.4.1
|
|
Connectives</a> above must be applied.</p>
|
|
|
|
<p>Please note that some XML parsers might treat a block of
|
|
<code>#PCDATA</code> that contains one or more <a
|
|
href="http://www.w3.org/TR/REC-xml#sec-comments">XML comments</a>
|
|
as two or more separate <code>#PCDATA</code> blocks. XML comments
|
|
both within the rule and the evidence MUST be ignored , so
|
|
implementors must make sure that such separated
|
|
<code>#PCDATA</code> blocks are treated as if they were a single,
|
|
contiguous section (i.e., as if no comments were present).</p>
|
|
|
|
<h3><a name="match_dataref" id="match_dataref">5.4.5 Matching
|
|
<code>p3p:DATA</code> elements</a></h3>
|
|
|
|
<p><code><p3p:DATA></code> and
|
|
<code><p3p:DATA-GROUP></code> elements carry a special
|
|
semantic in P3P policies. They reference sets and elements of the
|
|
<a href="http://www.w3.org/TR/P3P/#Base_Data_Schema">P3P base data
|
|
schema</a> 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 <em>name</em> of the data element or
|
|
set, while the URI part denotes the corresponding <em>data
|
|
schema</em> (compare with section <a
|
|
href="http://www.w3.org/TR/P3P/#DATA">3.3.7 The
|
|
<code>DATA-GROUP</code> and <code>DATA</code> elements</a> in the
|
|
<a href="http://www.w3.org/TR/P3P/">P3P1.0 Specification</a>).</p>
|
|
|
|
<p>In order to correctly handle the semantics of data schemas, the
|
|
following exceptions to standard matching apply to
|
|
<code>p3p:DATA-GROUP</code> and <code>p3p:DATA</code> elements:</p>
|
|
|
|
<ol>
|
|
<li>The <code>base</code> attribute of a <code>DATA-GROUP</code>
|
|
element is <em>omitted</em> from standard attribute matching.
|
|
Instead, it is used to set the <em>base URI</em> for all URI
|
|
references in the <code>DATA</code> elements contained by this
|
|
<code>DATA-GROUP</code> element (see step 2 below). When this
|
|
attribute is not present, the default value is the URI of the P3P
|
|
base data schema ( <a
|
|
href="http://www.w3.org/TR/P3P/base">http://www.w3.org/TR/P3P/base</a>).
|
|
When the attribute appears as an empty string (""), the
|
|
base is the local document. Note that this process must be
|
|
applied to <code>DATA-GROUP</code> elements in <em>both</em> the
|
|
rule <em>and</em> the evidence.</li>
|
|
|
|
<li>Each <code>ref</code> attribute of a <code>DATA</code>
|
|
element that contains only a fragment identifier (e.g.,
|
|
"#user.name") is expanded using the corresponding
|
|
<code>base</code> of its enclosing <code>DATA-GROUP</code>
|
|
element (see step 1 above). This process must be applied to
|
|
<code>DATA</code> elements in <em>both</em> the rule <em>and</em>
|
|
the evidence.</li>
|
|
|
|
<li>Two <code>ref</code> attributes match if both their URI parts
|
|
(i.e., without the fragment identifier) match, <em>and</em> one
|
|
fragment identifier is a <em>prefix</em> of the other. It does
|
|
not matter whether it is the <code>ref</code> attribute in the
|
|
rule that is a prefix of the <code>ref</code> attribute in the
|
|
evidence, or the other way around.</li>
|
|
|
|
<li>Wildcards in <code>base</code> and <code>ref</code> elements
|
|
of <code>DATA-GROUP</code> and <code>DATA</code> elements are not
|
|
permitted.</li>
|
|
</ol>
|
|
|
|
<p>The above matching semantics will have the effect that a rule
|
|
specifying, for example, the <em>data set</em>
|
|
<code>#user.name</code>, matches the <em>data element</em>
|
|
<code>#user.name.first</code> in the evidence. Equally, a single
|
|
<em>data element</em> in the rule, like
|
|
<code>#user.homeinfo.postal.street</code> will match a whole
|
|
<em>data set</em> specified in the evidence, such as
|
|
<code>#user.home-info</code>. In order to write a rule matching all
|
|
data elements from a specific data schema, rule authors can use the
|
|
empty fragment identifier ' <code>#</code> ' in conjunction
|
|
with an enclosing <code>DATA-GROUP</code> element that features a
|
|
corresponding <code>base</code> attribute.</p>
|
|
|
|
<p>However, note that in order for a <code>p3p:DATA</code> element
|
|
to match, any implicitly or explicitly given <em>categories</em>
|
|
must match as well, as described in section <a
|
|
href="#match_cat">5.4.6 Category expansion</a> below.</p>
|
|
|
|
<h3><a name="match_cat" id="match_cat">5.4.6 Category
|
|
expansion</a></h3>
|
|
|
|
<p><a href="http://www.w3.org/TR/P3P/#Categories">P3P
|
|
categories</a> 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.</p>
|
|
|
|
<p>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 <a
|
|
href="#inout">2.1 Inputs and Outputs of the Rule
|
|
Evaluator</a>).</p>
|
|
|
|
<p>APPEL rule evaluators must expand <code>DATA</code> and
|
|
<code>CATEGORIES</code> elements in the evidence according to the
|
|
steps described below before attempting to match
|
|
<code>CATEGORIES</code> elements in a rule:</p>
|
|
|
|
<ol>
|
|
<li>If the data element enclosing a <code>CATEGORIES</code>
|
|
element is a <a href="http://www.w3.org/TR/P3P/#fixed">fixed
|
|
categories data element</a>, any explicit category referenced in
|
|
the evidence MUST be part of the element's fixed set of
|
|
categories as defined in its base data schema. Non-matching
|
|
categories MUST be removed prior to matching. User agents MAY
|
|
optionally alert the user to any mismatch.</li>
|
|
|
|
<li>For each <a
|
|
href="http://www.w3.org/TR/P3P/#variable">variable-categories
|
|
data element</a>, the evidence MUST contain one or more explicit
|
|
categories. Otherwise the evidence is not a valid P3P policy and
|
|
user agents MUST treat them as they treat other malformed P3P
|
|
policies (compare with section <a
|
|
href="http://www.w3.org/TR/P3P/#variable">5.5.2 Variable-Category
|
|
Data Elements/Structures</a> in the <a
|
|
href="http://www.w3.org/TR/P3P/">P3P1.0 Specification</a>).</li>
|
|
|
|
<li>Each <a
|
|
href="http://www.w3.org/TR/P3P/#fixed">fixed-categories data
|
|
element</a> in the evidence MUST be expanded to contain a
|
|
<code>CATEGORIES</code> sublement listing <em>all</em> its
|
|
categories (as defined in the element's data schema).</li>
|
|
</ol>
|
|
|
|
<p>Implementors might want to note that unless a ruleset does
|
|
contain at least one <code>CATEGORIES</code> element, the above
|
|
expansion can be skipped.</p>
|
|
|
|
<h3><a name="match_optional" id="match_optional">5.4.7 Matching
|
|
optional data elements</a></h3>
|
|
|
|
<p>Data elements in P3P can be tagged as
|
|
<code>optional="yes"</code>, 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.</p>
|
|
|
|
<p>Since fully transparent support for such optional elements would
|
|
require rule evaluators to be able to <em>selectively remove</em>
|
|
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 <a
|
|
href="#match_attr_expr">attribute matching</a> (as described in
|
|
section <a href="#match_attr_expr">5.4.2 Attribute Expressions</a>)
|
|
on the corresponding <code>optional</code> attribute identifying
|
|
such elements.</p>
|
|
|
|
<p>Due to its standard <a href="#match_attr_expr">attribute
|
|
matching semantics</a>, APPEL rules must <em>ignore</em> attributes
|
|
present in the evidence that are not referenced in the rule.
|
|
Consequently, a rule featuring a data element without explicitly
|
|
specifying an <code>optional="yes"</code> or
|
|
<code>optional="no"</code> attribute will match
|
|
<em>any</em> corresponding data element in the evidence
|
|
<em>regardless</em> of its mandatory or optional status. This
|
|
default should be suitable for most rules (especially those
|
|
resulting in a <em>request</em> behavior).</p>
|
|
|
|
<p>However, in some cases (notably <em>block</em> rules) rule
|
|
authors might want to differentiate between data elements declared
|
|
as <em>mandatory</em> and those being <em>optional</em>. This can
|
|
be done by adding an explicit <code>optional="no"</code>
|
|
to data elements in the corresponding rule, forcing the rule
|
|
evaluator to check for an <code>optional</code> attribute in the
|
|
corresponding evidence and rejecting the match unless the evidence
|
|
features an explicit <code>optional="yes"</code> for this
|
|
element.</p>
|
|
|
|
<p>Rule authors must thus decide for every element that they want
|
|
to match in their rules whether they want to match only
|
|
<em>optional</em> elements in the evidence (by using
|
|
<code>optional="yes"</code> in the rule), only mandatory
|
|
elements (by using <code>optional="no"</code> in the
|
|
rule), or if the optional status of an element does not matter (by
|
|
leaving out the <code>optional</code> attribute altogether). Note
|
|
that different <code>connective</code>s in each of the enclosing
|
|
elements in the rule might affect this requirement.</p>
|
|
|
|
<h3><a name="match_extension" id="match_extension">5.4.8 Matching
|
|
optional and mandatory extensions</a></h3>
|
|
|
|
<p>P3P 1.0 also supports the concept of <a
|
|
href="http://www.w3.org/TR/P3P/#extension">optional and mandatory
|
|
extensions</a>. Such extensions are enclosed in a set of
|
|
<code><EXTENSION>...</EXTENSION></code> tags and
|
|
feature an <code>optional</code> attribute that is used to indicate
|
|
wheter an unknown extension can either be safely ignored (
|
|
<code>optional="yes"</code>) or not.</p>
|
|
|
|
<p>As with the concept of optional data elements discribed in
|
|
section <a href="#match_optional">5.4.7 Matching optional data
|
|
elements</a> above, the optional extension mechanism does
|
|
<em>not</em> require any special handling on behalf of the APPEL
|
|
rule evaluator. Again, standard <a
|
|
href="#match_attr_expr">attribute matching semantics</a> apply, as
|
|
described in section <a href="#match_attr_expr">5.4.2 Attribute
|
|
Expressions</a>.</p>
|
|
|
|
<p>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
|
|
<code>optional="yes"</code> attribute present and pass
|
|
the evidence on to the APPEL rule evaluator. If it does
|
|
<em>not</em> 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 <a
|
|
href="http://www.w3.org/TR/P3P/#extension">3.5 Extension
|
|
Mechanism</a> of the <a href="http://www.w3.org/TR/P3P/">P3P1.0
|
|
Specification</a>.</p>
|
|
|
|
<p>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 <code>optional</code> 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.</p>
|
|
|
|
<h2><a name="match_sum_and_example" id="match_sum_and_example">5.5
|
|
Matching Summary & Examples</a></h2>
|
|
|
|
<p>The following section summarizes the different matching
|
|
semantics described above and tries to give examples for matching
|
|
algrorithms.</p>
|
|
|
|
<h3><a name="match_pseudocode" id="match_pseudocode">5.5.1 Matching
|
|
Semantics in Pseudocode</a></h3>
|
|
|
|
<p>The standard matching semantics for rules in APPEL are as
|
|
follows (compare with section <a href="#match_connectives">5.4.1
|
|
Connectives</a>):</p>
|
|
|
|
<blockquote>
|
|
<p>An expression " <b>E</b> " matches a piece of
|
|
evidence " <b>X</b> " (i.e. a certain XML element in
|
|
the evidence) if and only if all of the following holds:</p>
|
|
|
|
<ol>
|
|
<li>the element names of <b>E</b> and <b>X</b> are
|
|
identical</li>
|
|
|
|
<li>all of <b>E</b> 's attribute expressions match
|
|
attributes of <b>X</b> (additional attributes in evidence
|
|
<b>X</b> that are not referenced in expression <b>E</b> are
|
|
ignored)</li>
|
|
|
|
<li>[if an <code>or</code> connective is given in <b>E</b> ]
|
|
<em>at least one</em> of <b>E</b> 's contained expressions
|
|
match <b>X</b> 's enclosed elements or <code>#PCDATA</code>
|
|
(additional enclosed elements or <code>#PCDATA</code> in
|
|
evidence <b>X</b> that are not referenced in expression
|
|
<b>E</b> are ignored). In case an element does not feature any
|
|
contained expressions, matching always fails!</li>
|
|
|
|
<li>[if an <code>and</code> connective, or if no connective is
|
|
given in <b>E</b> ] <em>all</em> of <b>E</b> 's contained
|
|
expressions match <b>X</b> 's enclosed elements and
|
|
<code>#PCDATA</code> (additional enclosed elements and
|
|
<code>#PCDATA</code> in evidence <b>X</b> that are not
|
|
referenced in expression <b>E</b> are ignored).</li>
|
|
|
|
<li>[if an <code>non-or</code> connective is given in <b>E</b>
|
|
] <em>none</em> of <b>E</b> 's contained expressions match
|
|
<b>X</b> 's enclosed elements and <code>#PCDATA</code>
|
|
(additional enclosed elements and <code>#PCDATA</code> in
|
|
evidence <b>X</b> that are not referenced in expression
|
|
<b>E</b> are ignored).</li>
|
|
|
|
<li>[if an <code>non-and</code> connective is given in <b>E</b>
|
|
] <em>not all</em> of <b>E</b> 's contained expressions
|
|
match <b>X</b> 's enclosed elements and
|
|
<code>#PCDATA</code> (additional enclosed elements and
|
|
<code>#PCDATA</code> in evidence <b>X</b> that are not
|
|
referenced in expression <b>E</b> are ignored). In case an
|
|
element does not feature any contained expressions, matching
|
|
always fails!</li>
|
|
|
|
<li>[if an <code>or-exact</code> connective is given in
|
|
<b>E</b> ] <em>at least one</em> of <b>E</b> 's contained
|
|
expressions match <b>X</b> 's enclosed elements or
|
|
<code>#PCDATA</code> (additional enclosed elements or
|
|
<code>#PCDATA</code> in evidence <b>X</b> that are not
|
|
referenced in expression <b>E</b> are <em>not</em> ignored). In
|
|
case element <b>E</b> does not feature any contained
|
|
expressions, matching <em>always fails</em>!</li>
|
|
|
|
<li>[if an <code>and-exact</code> connective is given in
|
|
<b>E</b> ] <em>all</em> of <b>E</b> 's contained
|
|
expressions match <b>X</b> 's enclosed elements and
|
|
<code>#PCDATA</code> (additional enclosed elements and
|
|
<code>#PCDATA</code> in evidence <b>X</b> that are not
|
|
referenced in expression <b>E</b> are <em>not</em> ignored). In
|
|
case element <b>E</b> does not feature any contained
|
|
expressions, the corresponding element <b>X</b> in the evidence
|
|
must also not contain any subelements or #PCDATA.</li>
|
|
</ol>
|
|
</blockquote>
|
|
|
|
<h3><a name="match_algorithm" id="match_algorithm">5.5.2 Sample
|
|
Matching Algorithm</a></h3>
|
|
|
|
<p>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.</p>
|
|
|
|
<blockquote>
|
|
<p>For [ at least one | each ] <sup>*</sup> expression in the
|
|
rule, find a match in the evidence such that the following
|
|
conditions (C1-C3) [ do | do not ] <sup>*</sup> hold:</p>
|
|
|
|
<table summary="Sample Matching Algorithm" cellpadding="4">
|
|
<tbody>
|
|
<tr>
|
|
<th valign="top">C1</th>
|
|
|
|
<td>the matching evidence is the same type of XML element
|
|
as the rule expression (i.e. <STATEMENT>,
|
|
<POLICY>, etc.)</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<th valign="top">C2</th>
|
|
|
|
<td>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</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<th>
|
|
</th>
|
|
|
|
<td valign="top"><b>If the expressions features an
|
|
<code>or</code> connective:</b> </td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<th valign="top">C3a</th>
|
|
|
|
<td>for <em>at least one</em> nested XML element or
|
|
<code>#PCDATA</code> contained within the expression, C1
|
|
through C3 are satisfied.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<th>
|
|
</th>
|
|
|
|
<td valign="top"><b>If the expressions features no
|
|
connective, or an <code>and</code> connective:</b> </td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<th valign="top">C3b</th>
|
|
|
|
<td>for <em>each</em> nested XML element and
|
|
<code>#PCDATA</code> contained within the expression, C1
|
|
through C3 are satisfied.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<th>
|
|
</th>
|
|
|
|
<td valign="top"><b>If the expressions features an
|
|
<code>non-or</code> connective:</b> </td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<th valign="top">C3c</th>
|
|
|
|
<td>for <em>none</em> of the nested XML element and
|
|
<code>#PCDATA</code> contained within the expression, C1
|
|
through C3 are satisfied.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<th>
|
|
</th>
|
|
|
|
<td valign="top"><b>If the expressions features an
|
|
<code>non-and</code> connective:</b> </td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<th valign="top">C3d</th>
|
|
|
|
<td>for <em>at least one</em> nested XML element and
|
|
<code>#PCDATA</code> contained within the expression, C1
|
|
through C3 are <b>not</b> satisfied.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<th>
|
|
</th>
|
|
|
|
<td valign="top"><b>If the expressions features an
|
|
<code>or-exact</code> connective:</b> </td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<th valign="top">C3c</th>
|
|
|
|
<td>for <em>each</em> nested XML element and
|
|
<code>#PCDATA</code> <b>in the evidence</b>, C1 through C3
|
|
are satisfied.</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<th>
|
|
</th>
|
|
|
|
<td valign="top"><b>If the expressions features an
|
|
<code>and-exact</code> connective:</b> </td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<th valign="top">C3d</th>
|
|
|
|
<td>for <em>each</em> nested XML element and
|
|
<code>#PCDATA</code> contained within the expression, and
|
|
for <em>each</em> nested XML element and
|
|
<code>#PCDATA</code> <b>in the evidence</b>, C1 through C3
|
|
are satisfied.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>If a match [ can | can not ] <sup>*</sup> be found for [ at
|
|
least one | each ] <sup>*</sup> expression, then the rule
|
|
fires.</p>
|
|
</blockquote>
|
|
|
|
<p>* depending on the <code>appel:connective</code> used in the
|
|
<code><appel:RULE></code> element (compare with C3a-C3d).</p>
|
|
<hr />
|
|
|
|
<h1><a name="appendices" id="appendices">Appendices</a></h1>
|
|
<hr />
|
|
|
|
<h1><a name="future" id="future">Appendix A: Future Work</a></h1>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>As mentioned in section <a href="#requirements">1.3
|
|
Requirements</a> 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
|
|
<b>1.0</b>) 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.</p>
|
|
|
|
<p>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 <b>1.0</b>) in order
|
|
to allow for simple initial implementations:</p>
|
|
|
|
<ul>
|
|
<li><b>Extensible behaviors:</b> 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 <em>known</em> behavior is
|
|
always executed.</li>
|
|
|
|
<li><b>Matching external schemas:</b> Expressions can contain
|
|
<code><POLICY></code> elements as well as external elements
|
|
such as PICS labels or Protocol features (e.g. "SSL in
|
|
use").</li>
|
|
|
|
<li><b>Optional rules:</b> Rules that are truly cosmetic can be
|
|
ignored should a non-standard behavior be unknown to the
|
|
particular user agent in use.</li>
|
|
|
|
<li><b>Optional schemas:</b> Expressions can be tagged
|
|
<em>optional</em> 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).</li>
|
|
|
|
<li><b>Groups & Triggers:</b> Sets of rules can be collated
|
|
into <em>groups</em> allowing selective activation of certain
|
|
privacy preferences depending on <em>triggers</em> such as URLs,
|
|
PICS labels, etc.</li>
|
|
|
|
<li><b>Comparison operators for simple numeric expressions:</b>
|
|
Ranges of allowed values can be expressed by using common
|
|
mathematical comparison operators such as <, >, <=,
|
|
>=, etc.</li>
|
|
|
|
<li><b>Expiration dates:</b> Rules and Groups can be set to
|
|
expire at a certain point, allowing user agents (and users) to
|
|
create temporary rules.</li>
|
|
|
|
<li>
|
|
<b>String-passing:</b> In order to create more informative
|
|
<code>prompt</code> and <code>description</code> messages,
|
|
<code>sprintf</code> -like placeholders can be used within
|
|
those attributes-strings and will be replaced by the trust
|
|
engine with corresponding values from the matched evidence.
|
|
Examples for such placeholders would be:
|
|
|
|
<ul>
|
|
<li><code>%cq</code> (consequence)</li>
|
|
|
|
<li><code>%op</code> (other purpose)</li>
|
|
|
|
<li><code>%oc</code> (other category)</li>
|
|
|
|
<li><code>%rd</code> (recipient description)</li>
|
|
|
|
<li><code>%si</code> (site name)</li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>Comments to <a
|
|
href="mailto:www-p3p-public-comments@w3.org">www-p3p-public-comments@w3.org</a>
|
|
regarding the usability of current and planned features are highly
|
|
encouraged.</p>
|
|
|
|
<h1><a name="examples" id="examples">Appendix B: Ruleset
|
|
Examples</a></h1>
|
|
|
|
<h2><a name="b.1" id="b.1">B.1 ALMOST ANONYMOUS</a></h2>
|
|
|
|
<p>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.<br />
|
|
</p>
|
|
|
|
<div class="caption">
|
|
<b>Figure B.1:</b> "Almost Anonymous" Ruleset
|
|
</div>
|
|
|
|
<div class="figure">
|
|
<pre>
|
|
<appel:RULESET xmlns:appel="http://www.w3.org/2002/04/APPELv1"
|
|
xmlns:p3p="http://www.w3.org/2000/12/P3Pv1"
|
|
crtdby="W3C" crtdon="2000-03-15T10:55:32+01:00">
|
|
<appel:RULE behavior="limited" prompt="yes"
|
|
description="Service collects some kind of identifiable
|
|
information"
|
|
promptmsg="Warning! Service collects some kind of identifiable
|
|
information. Do you want to continue (using limited access)?">
|
|
<p3p:POLICY>
|
|
<p3p:ACCESS appel:connective="non-and">
|
|
<p3p:nonident/>
|
|
</p3p:ACCESS>
|
|
</p3p:POLICY>
|
|
</appel:RULE>
|
|
<appel:RULE behavior="limited" prompt="yes"
|
|
description="Service collects physical and/or online
|
|
contact information and/or financial account
|
|
identifiers and/or other data that may be
|
|
personally-identifiable"
|
|
promptmsg="Warning! Service collects physical and/or online
|
|
contact information and/or financial account
|
|
identifiers and/or other data that may be
|
|
personally-identifiable. Do you want to
|
|
continue (using limited access)?">
|
|
<p3p:POLICY>
|
|
<p3p:STATEMENT>
|
|
<p3p:DATA-GROUP>
|
|
<p3p:DATA>
|
|
<p3p:CATEGORIES appel:connective="or">
|
|
<p3p:physical/>
|
|
<p3p:online/>
|
|
<p3p:uniqueid/>
|
|
<p3p:financial/>
|
|
<p3p:other-category/>
|
|
</p3p:CATEGORIES>
|
|
</p3p:DATA>
|
|
</p3p:DATA-GROUP>
|
|
</p3p:STATEMENT>
|
|
</p3p:POLICY>
|
|
</appel:RULE>
|
|
<appel:RULE behavior="request"
|
|
description="Service does not collect identifiable data or share
|
|
data with other parties">
|
|
<p3p:POLICY>
|
|
<p3p:STATEMENT>
|
|
<p3p:RECIPIENT appel:connective="and-exact">
|
|
<p3p:ours/>
|
|
</p3p:RECIPIENT>
|
|
<p3p:PURPOSE appel:connective="non-and">
|
|
<p3p:contact/>
|
|
<p3p:telemarketing/>
|
|
<p3p:individual-analysis/>
|
|
<p3p:individual-decision/>
|
|
<p3p:other-purpose/>
|
|
</p3p:PURPOSE>
|
|
<p3p:DATA-GROUP appel:connective="or-exact">
|
|
<p3p:DATA ref="#user.*"/>
|
|
<p3p:DATA ref="#dynamic.*">
|
|
<p3p:CATEGORIES><state></p3p:CATEGORIES>
|
|
</p3p:DATA>
|
|
</p3p:DATA-GROUP>
|
|
</p3p:STATEMENT>
|
|
</p3p:POLICY>
|
|
</appel:RULE>
|
|
<appel:RULE behavior="limited"
|
|
description="Warning! Service requests data from your data
|
|
repository or has a practice that doesn't match
|
|
your preferences">
|
|
<appel:OTHERWISE/>
|
|
</appel:RULE>
|
|
</appel:RULESET>
|
|
</pre>
|
|
</div>
|
|
|
|
<h2><a name="b.2" id="b.2">B.2 PRIVACY AND COMMERCE</a></h2>
|
|
|
|
<p>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.<br />
|
|
</p>
|
|
|
|
<div class="caption">
|
|
<b>Figure B.2:</b> "Privacy And Commerce" Ruleset
|
|
</div>
|
|
|
|
<div class="figure">
|
|
<pre>
|
|
<appel:RULESET xmlns:appel="http://www.w3.org/2002/04/APPELv1"
|
|
xmlns:p3p="http://www.w3.org/2000/12/P3Pv1"
|
|
crtdby="W3C" crtdon="2000-03-15T16:41:21+01:00">
|
|
<appel:RULE behavior="limited" prompt="yes"
|
|
description="Data may be shared with legal entities
|
|
following different practices, public fora, or
|
|
unrelated third parties."
|
|
promptmsg="Warning! Data may be shared 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: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="Data may be used for marketing, tailoring
|
|
or other purposes."
|
|
promptmsg="Warning! Data may be used for marketing, tailoring
|
|
or other purposes. Do you want to continue (using
|
|
limited access)?">
|
|
<p3p:POLICY>
|
|
<p3p:STATEMENT>
|
|
<p3p:PURPOSE appel:connective="or">
|
|
<p3p:contact/>
|
|
<p3p:tailoring/>
|
|
<p3p:other-purpose/>
|
|
</p3p:PURPOSE>
|
|
</p3p:STATEMENT>
|
|
</p3p:POLICY>
|
|
</appel:RULE>
|
|
<appel:RULE behavior="limited" prompt="yes"
|
|
description="Site collects healthcare information.">
|
|
promptmsg="Warning! Site collects healthcare information.
|
|
Do you want to continue (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" prompt="yes"
|
|
description="Service does not provide access to identifiable data
|
|
it collects">
|
|
promptmsg="Service does not provide access to identifiable data
|
|
it collects. Do you want to continue anyway?">
|
|
<p3p:POLICY>
|
|
<p3p:ACCESS>
|
|
<p3p:none/>
|
|
</p3p:ACCESS>
|
|
</p3p:POLICY>
|
|
</appel:RULE>
|
|
<appel:RULE behavior="request"
|
|
description="Privacy policy matches Privacy And Commerce
|
|
preferences">
|
|
<appel:OTHERWISE/>
|
|
</appel:RULE>
|
|
</appel:RULESET>
|
|
</pre>
|
|
</div>
|
|
|
|
<h2><a name="b.3" id="b.3">B.3 LOOK FOR THE SEAL</a></h2>
|
|
|
|
<p>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.<br />
|
|
</p>
|
|
|
|
<div class="caption">
|
|
<b>Figure B.3:</b> "Look For The Seal" Ruleset
|
|
</div>
|
|
|
|
<div class="figure">
|
|
<pre>
|
|
<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>
|
|
</pre>
|
|
</div>
|
|
|
|
<h2><a name="b.4" id="b.4">B.4 INFORMATION ONLY</a></h2>
|
|
|
|
<p>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.<br />
|
|
</p>
|
|
|
|
<div class="caption">
|
|
<b>Figure B.4:</b> "Information Only" Ruleset
|
|
</div>
|
|
|
|
<div class="figure">
|
|
<pre>
|
|
<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:04:02+01:00">
|
|
<appel:RULE behavior="request" prompt="yes"
|
|
description="Service collects data for marketing, tailoring, or
|
|
'other' purposes.">
|
|
promptmsg="FYI: This service collects data for marketing,
|
|
tailoring, or 'other' purposes. Continue?">
|
|
<p3p:POLICY>
|
|
<p3p:STATEMENT>
|
|
<p3p:PURPOSE appel:connective="or">
|
|
<p3p:contact/>
|
|
<p3p:telemarketing/>
|
|
<p3p:pseudo-analysis/>
|
|
<p3p:pseudo-decision/>
|
|
<p3p:individual-analysis/>
|
|
<p3p:individual-decision/>
|
|
<p3p:other-purpose/>
|
|
</p3p:PURPOSE>
|
|
</p3p:STATEMENT>
|
|
</p3p:POLICY>
|
|
</appel:RULE>
|
|
<appel:RULE behavior="request" prompt="yes"
|
|
description="Service shares information with legal entities
|
|
following different practices, public fora, or
|
|
unrelated third parties.">
|
|
promptmsg="FYI: This service shares information with legal entities
|
|
following different practices, public fora, or
|
|
unrelated third parties. Continue anyway?">
|
|
<p3p:POLICY>
|
|
<p3p:STATEMENT>
|
|
<p3p:RECIPIENT appel:connective="or">
|
|
<p3p:other-recipient/>
|
|
<p3p:public/>
|
|
<p3p:unrelated/>
|
|
</p3p:RECIPIENT>
|
|
</p3p:STATEMENT>
|
|
</p3p:POLICY>
|
|
</appel:RULE>
|
|
<appel:RULE behavior="request" prompt="yes"
|
|
description="Site collects healthcare information.">
|
|
promptmsg="FYI: Site collects healthcare information. Continue?">
|
|
<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="Privacy policy matches Information Only
|
|
preferences">
|
|
<appel:OTHERWISE/>
|
|
</appel:RULE>
|
|
</appel:RULESET>
|
|
</pre>
|
|
</div>
|
|
|
|
<h2><a name="xmlschema" id="xmlschema">Appendix C: XML Schema
|
|
Definition</a> (normative)</h2>
|
|
|
|
<p>This appendix contains the XML schema [ <a href="#xsd1">XML
|
|
Schema 1</a>, <a href="#xsd2">XML Schema 2</a> ] 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 <!--
|
|
<a href="http://www.w3.org/2002/04/APPELv1.xsd"> -->
|
|
<a href="APPELv1-20020415.xsd">APPELv1-20020415.xsd</a></p>
|
|
<pre class="xsd">
|
|
<?xml version='1.0' encoding='UTF-8'?>
|
|
<schema targetNamespace="http://www.w3.org/2002/04/APPELv1"
|
|
xmlns="http://www.w3.org/2000/10/XMLSchema"
|
|
xmlns:appel="http://www.w3.org/2002/04/APPELv1"
|
|
elementFormDefault="qualified">
|
|
<!-- ********* APPEL Data Types ******** -->
|
|
<simpleType name="yes_no">
|
|
<restriction base="string">
|
|
<enumeration value="yes"/>
|
|
<enumeration value="no"/>
|
|
</restriction>
|
|
</simpleType>
|
|
<simpleType name="connective-value">
|
|
<restriction base="string">
|
|
<enumeration value="or"/>
|
|
<enumeration value="and"/>
|
|
<enumeration value="non-or"/>
|
|
<enumeration value="non-and"/>
|
|
<enumeration value="or-exact"/>
|
|
<enumeration value="and-exact"/>
|
|
</restriction>
|
|
</simpleType>
|
|
<simpleType name="behavior-value">
|
|
<restriction base="string">
|
|
<enumeration value="request"/>
|
|
<enumeration value="block"/>
|
|
<enumeration value="limited"/>
|
|
</restriction>
|
|
</simpleType>
|
|
<attributeGroup name="common-attributes">
|
|
<attribute name="crtdby" type="string" use="optional"/>
|
|
<attribute name="crtdon" type="timeInstant" use="optional"/>
|
|
<attribute name="description" type="string" use="optional"/>
|
|
</attributeGroup>
|
|
<!-- ************ RULESET ************* -->
|
|
<element name="RULESET">
|
|
<complexType>
|
|
<sequence>
|
|
<element ref="appel:RULE" maxOccurs="unbounded"/>
|
|
</sequence>
|
|
<attributeGroup ref="appel:common-attributes"/>
|
|
</complexType>
|
|
</element>
|
|
<!-- ************** RULE ************** -->
|
|
<element name="RULE">
|
|
<complexType>
|
|
<choice>
|
|
<element ref="appel:OTHERWISE"/>
|
|
<sequence>
|
|
<element ref="appel:REQUEST-GROUP" minOccurs="0"/>
|
|
<any namespace="http://www.w3.org/2000/12/P3Pv1"
|
|
processContents="skip" minOccurs="0"/>
|
|
</sequence>
|
|
</choice>
|
|
<attribute name="behavior" type="appel:behavior-value" use="required"/>
|
|
<attribute name="connective" type="appel:connective-value" use="optional"/>
|
|
<attribute name="prompt" type="appel:yes_no" use="default" value="no"/>
|
|
<attribute name="persona" type="string" use="optional"/>
|
|
<attribute name="promptmsg" type="string" use="optional"/>
|
|
<attributeGroup ref="appel:common-attributes"/>
|
|
</complexType>
|
|
</element>
|
|
<!-- ********* REQUEST-GROUP ********** -->
|
|
<element name="REQUEST-GROUP">
|
|
<complexType>
|
|
<sequence>
|
|
<element ref="appel:REQUEST" maxOccurs="unbounded"/>
|
|
</sequence>
|
|
<attribute name="connective" type="appel:connective-value" use="optional"/>
|
|
</complexType>
|
|
</element>
|
|
<!-- ************* REQUEST ************ -->
|
|
<element name="REQUEST">
|
|
<complexType>
|
|
<attribute name="uri" type="string" use="required"/>
|
|
</complexType>
|
|
</element>
|
|
<!-- ************* OTHERWISE ************* -->
|
|
<element name="OTHERWISE">
|
|
<complexType/>
|
|
</element>
|
|
</schema>
|
|
</pre>
|
|
|
|
<h2><a name="dtd" id="dtd">Appendix D: Document Type Definition
|
|
(DTD)</a> (informative)</h2>
|
|
|
|
<p>This appendix contains the DTD for policy documents and for data
|
|
schemas. The DTD is also present as a separate file at the URI
|
|
<!-- <a
|
|
href="http://www.w3.org/2002/04/APPELv1.dtd"> -->
|
|
<a href="APPELv1-20020415.dtd">APPELv1-20020415.dtd</a></p>
|
|
<pre class="dtd">
|
|
<!-- ************ Entities ************ -->
|
|
<!ENTITY % URI "CDATA">
|
|
<!ENTITY % TIME "CDATA">
|
|
|
|
<!-- ************ RULESET ************* -->
|
|
<!ELEMENT RULESET (RULE+)>
|
|
<!ATTLIST RULESET
|
|
xmlns CDATA #FIXED 'http://www.w3.org/2002/04/APPELv1'
|
|
crtdby CDATA #IMPLIED
|
|
crtdon %TIME; #IMPLIED
|
|
description CDATA #IMPLIED >
|
|
|
|
<!-- ************** RULE ************** -->
|
|
<!ELEMENT RULE ANY>
|
|
<!ATTLIST RULE
|
|
connective (or | and | non-or | non-and | or-exact | and-exact) #IMPLIED
|
|
behavior (request | block | limited) #REQUIRED
|
|
prompt (yes | no) #IMPLIED
|
|
persona CDATA #IMPLIED
|
|
promptmsg CDATA #IMPLIED
|
|
crtdby CDATA #IMPLIED
|
|
crtdon %TIME; #IMPLIED
|
|
description CDATA #IMPLIED >
|
|
|
|
<!-- ********* REQUEST-GROUP ********** -->
|
|
<!ELEMENT REQUEST-GROUP (REQUEST+)>
|
|
<!ATTLIST REQUEST-GROUP
|
|
connective (or | and | non-or | non-and | or-exact | and-exact) #IMPLIED >
|
|
|
|
<!-- ************* REQUEST ************ -->
|
|
<!ELEMENT REQUEST EMPTY>
|
|
<!ATTLIST REQUEST
|
|
uri %URI; #REQUIRED >
|
|
</pre>
|
|
|
|
<h2><a name="abnf" id="abnf">Appendix E: ABNF Notation</a>
|
|
(informative)</h2>
|
|
|
|
<p>The formal grammar of APPEL is given in this specification using
|
|
a slight modification of [ <a href="#ABNF">ABNF</a> ]. 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 ("), <a
|
|
href="http://www.w3.org/TR/REC-xml#dt-chardata">character
|
|
escaping</a>, comments, and case sensitivity. In addition, note
|
|
that attributes and elements may appear in any order.</p>
|
|
|
|
<p>The following is a simple description of the ABNF.</p>
|
|
|
|
<dl>
|
|
<dt><code class="c3">name = (elements) </code></dt>
|
|
|
|
<dd>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. </dd>
|
|
|
|
<dt><code>(</code> <code class="c3">element1
|
|
element2)</code></dt>
|
|
|
|
<dd>elements enclosed in parentheses are treated as a single
|
|
element, whose contents are strictly ordered.</dd>
|
|
|
|
<dt><code class="c3"><a>*<b>element</code></dt>
|
|
|
|
<dd>at least <a> and at most <b> occurrences of the
|
|
element.</dd>
|
|
|
|
<dd><em>(1*4<element> means one to four
|
|
elements.)</em></dd>
|
|
|
|
<dt><code class="c3"><a>element</code></dt>
|
|
|
|
<dd>exactly <a> occurrences of the element.</dd>
|
|
|
|
<dd><em>(4<element> means exactly 4 elements.)</em></dd>
|
|
|
|
<dt><code class="c3"><a>*element</code></dt>
|
|
|
|
<dd><a> or more elements</dd>
|
|
|
|
<dd><em>(4*<element> means 4 or more elements.)</em></dd>
|
|
|
|
<dt><code class="c3">*<b>element</code></dt>
|
|
|
|
<dd>0 to <b> elements.</dd>
|
|
|
|
<dd><em>(*5<element> means 0 to 5 elements.)</em></dd>
|
|
|
|
<dt><code class="c3">*element</code></dt>
|
|
|
|
<dd>0 or more elements.</dd>
|
|
|
|
<dd><em>(*<element> means 0 to infinite
|
|
elements.)</em></dd>
|
|
|
|
<dt><code class="c3">[element]</code></dt>
|
|
|
|
<dd>optional element, equivalent to *1(element).</dd>
|
|
|
|
<dd><em>([element] means 0 or 1 element.)</em></dd>
|
|
|
|
<dt><code class="c3">"string"</code> or <code
|
|
class="c3">'string'</code></dt>
|
|
|
|
<dd>matches the literal string given inside double quotes.</dd>
|
|
</dl>
|
|
|
|
<p>Other notations used in the productions are:</p>
|
|
|
|
<dl>
|
|
<dt>; or <b><code>/* ... */</code></b></dt>
|
|
|
|
<dd>comment.</dd>
|
|
</dl>
|
|
|
|
<h1><a name="related" id="related">Appendix F: Trust Engines and
|
|
Database Engines</a></h1>
|
|
|
|
<p>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 [ <a href="#keynote">Keynote</a> ] 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.</p>
|
|
|
|
<h1><a name="contrib" id="contrib">Appendix G: Working Group
|
|
Contributors</a></h1>
|
|
|
|
<table summary="Working group contributors">
|
|
<tbody>
|
|
<tr>
|
|
<td>Nikolaj Budzyn</td>
|
|
|
|
<td>Christian-Albrechts-University of Kiel</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>Lorrie Cranor</td>
|
|
|
|
<td>AT&T Labs-Research</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>Matthias Enzmann</td>
|
|
|
|
<td>GMD</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>Marit Köhntopp</td>
|
|
|
|
<td>Independent Center for Privacy Protection
|
|
Schleswig-Holstein</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>Yuichi Koike</td>
|
|
|
|
<td>NEC</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>Marc Langheinrich</td>
|
|
|
|
<td>ETH Zürich (Editor & Chair)</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>Massimo Marchiori</td>
|
|
|
|
<td>W3C</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>Joerg Meyer</td>
|
|
|
|
<td>IBM</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>Joseph Reagle</td>
|
|
|
|
<td>W3C</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>Drummond Reed</td>
|
|
|
|
<td>OneName</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>Rigo Wenning</td>
|
|
|
|
<td>W3C</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td>Mary Ellen Zurko</td>
|
|
|
|
<td>Iris (former Chair)</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<h1><a name="references" id="references">References</a></h1>
|
|
|
|
<dl>
|
|
<dt><a name="URI" id="URI">[URI]</a></dt>
|
|
|
|
<dd>T. Berners-Lee, R. Fielding, and L. Masinter. <a
|
|
href="http://www.ietf.org/rfc/rfc2369.txt">"RFC2396 --
|
|
Uniform Resource Identifiers (URI): Generic Syntax and
|
|
Semantics."</a> August 1998. See <a
|
|
href="http://www.ietf.org/rfc/rfc2369.txt">/rfc/rfc2369.txt</a>
|
|
at <a href="http://www.ietf.org/">http://www.ietf.org/</a>.
|
|
(updates <a
|
|
href="http://www.ietf.org/rfc/rfc1738.txt">RFC1738</a>)</dd>
|
|
|
|
<dt><a name="xsd2" id="xsd2">[XML-Schema 2]</a></dt>
|
|
|
|
<dd>Paul V. Biron, Ashok Malhotra (editors), <a
|
|
href="http://www.w3.org/TR/xmlschema-2/">"XML Schema Part 2:
|
|
Datatypes"</a> 24 October 2000. W3C Candidate
|
|
Recommendation. See <a
|
|
href="http://www.w3.org/TR/xmlschema-2/">/TR/xmlschema-2/</a> at
|
|
<a href="http://www.w3.org/">http://www.w3.org/</a></dd>
|
|
|
|
<dt><a name="keynote" id="keynote">[Keynote]</a></dt>
|
|
|
|
<dd>Blaze, Feigenbaum, Keromytis, <a
|
|
href="http://www.cis.upenn.edu/~angelos/keynote.html">"Keynote
|
|
Trust Management System"</a>.</dd>
|
|
|
|
<dt><a name="RFC2119" id="RFC2119">[RFC 2119]</a></dt>
|
|
|
|
<dd>S. Bradner, <a
|
|
href="http://www.ietf.org/rfc/rfc2119.txt">"Key words for
|
|
use in RFCs to Indicate Requirement Levels"</a> See <a
|
|
href="http://www.ietf.org/rfc/rfc2119.txt">/rfc/rfc2119.txt</a>
|
|
at <a href="http://www.ietf.org/">http://www.ietf.org/</a>.</dd>
|
|
|
|
<dt><a name="XML" id="XML">[XML]</a></dt>
|
|
|
|
<dd>Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, Eve Maler, <a
|
|
href="http://www.w3.org/TR/REC-xml">"Extensible Markup
|
|
Language (XML) 1.0 (Second Edition)"</a> 14 January 1999 <a
|
|
href="http://www.w3.org/">World Wide Web Consortium</a>
|
|
Recommendation. See <a
|
|
href="http://www.w3.org/TR/REC-xml">/TR/REC-xml</a> at <a
|
|
href="http://www.w3.org/">http://www.w3.org/</a></dd>
|
|
|
|
<dt><a name="RFC822" id="RFC822">[RFC 822]</a></dt>
|
|
|
|
<dd>David H. Crocker (editor), <a
|
|
href="http://www.faqs.org/rfcs/rfc822.html">Standard for the
|
|
format of ARPA Internet text messages</a> See <a
|
|
href="http://www.faqs.org/rfcs/rfc822.html">/rfc/rfc822.txt</a>
|
|
at <a href="http://www.faqs.org/">http://www.faqs.org/</a>.</dd>
|
|
|
|
<dt><a name="ABNF" id="ABNF">[ABNF]</a></dt>
|
|
|
|
<dd>D. Crocker, P. Overel. " <a
|
|
href="http://www.ietf.org/rfc/rfc2234.txt">RFC2234 -- Augmented
|
|
BNF for Syntax Specifications: ABNF</a>," Internet Mail
|
|
Consortium, Demon Internet Ltd., November 1997. See <a
|
|
href="http://www.ietf.org/rfc/rfc2119.txt">/rfc/rfc2119.txt</a>
|
|
at <a href="http://www.ietf.org/">http://www.ietf.org/</a>.</dd>
|
|
|
|
<dt><a name="PICSRules" id="PICSRules">[PICSRules]</a></dt>
|
|
|
|
<dd>Christopher Evans, Clive D.W. Feather, Alex Hopmann, Martin
|
|
Presler-Marshall, Paul Resnick, <a
|
|
href="http://www.w3.org/TR/REC-PICSRules">"PICSRules
|
|
Specification"</a> 29 December 1997. See <a
|
|
href="http://www.w3.org/TR/REC-PICSRules">/TR/REC-PICSRules</a>
|
|
at <a href="http://www.w3.org/">http://www.w3.org/</a></dd>
|
|
|
|
<dt><a name="RFC2616" id="RFC2616">[RFC 2616]</a></dt>
|
|
|
|
<dd>R. Fielding et al, <a
|
|
href="http://www.ietf.org/rfc/rfc2616.txt">"RFC2616 --
|
|
Hypertext Transfer Protocol -- HTTP/1.1"</a> June 1999. See
|
|
<a
|
|
href="http://www.ietf.org/rfc/rfc2616.txt">/rfc/rfc2616.txt</a>
|
|
at <a href="http://www.ietf.org/">http://www.ietf.org/</a>.
|
|
(updates <a
|
|
href="http://www.ietf.org/rfc/rfc2616.txt">RFC2068</a>)</dd>
|
|
|
|
<dt><a name="bib_iso8601" id="bib_iso8601">[ISO8601]</a></dt>
|
|
|
|
<dd>"ISO8601: Data elements and interchange formats --
|
|
Information interchange -- Representation of dates and
|
|
times." International Organization for Standardization.</dd>
|
|
|
|
<dt><a name="bib_rdf" id="bib_rdf">[RDF]</a></dt>
|
|
|
|
<dd>Ora Lassila, Ralph R. Swick (editors), <a
|
|
href="http://www.w3.org/TR/REC-rdf-syntax/">"Resource
|
|
Description Framework (RDF) Model and Syntax
|
|
Specification"</a> 22 February 1999. See <a
|
|
href="http://www.w3.org/TR/REC-rdf-syntax/">/TR/REC-rdf-syntax</a>
|
|
at <a href="http://www.w3.org/">http://www.w3.org/</a></dd>
|
|
|
|
<dt><a name="P3P10" id="P3P10">[P3P10]</a></dt>
|
|
|
|
<dd>Massimo Marchiori (editor), <a
|
|
href="http://www.w3.org/TR/P3P/">"Platform for Privacy
|
|
Preferences 1.0 (P3P1.0) Specification"</a> 16 April 2002.
|
|
<a href="http://www.w3.org/">World Wide Web Consortium</a>
|
|
Recommendation. See <a
|
|
href="http://www.w3.org/TR/P3P/">/TR/P3P/</a> at <a
|
|
href="http://www.w3.org/">http://www.w3.org/</a></dd>
|
|
|
|
<dt><a name="xsd1" id="xsd1">[XML-Schema 1]</a></dt>
|
|
|
|
<dd>Henry S. Thompson, David Beech, Murray Maloney, Noah
|
|
Mendelsohn (editors), <a
|
|
href="http://www.w3.org/TR/xmlschema-1/">"XML Schema Part 1:
|
|
Structures"</a> 24 October 2000. W3C Candidate
|
|
Recommendation. See <a
|
|
href="http://www.w3.org/TR/xmlschema-1/">/TR/xmlschema-1/</a> at
|
|
<a href="http://www.w3.org/">http://www.w3.org/</a></dd>
|
|
|
|
<dt><a name="utf8" id="utf8">[UTF-8]</a></dt>
|
|
|
|
<dd>F. Yergeau. <a
|
|
href="http://www.ietf.org/rfc/rfc2279.txt">"RFC 2279 --
|
|
UTF-8, a transformation format of ISO 10646."</a> January
|
|
1998. See See <a
|
|
href="http://www.ietf.org/rfc/rfc2279.txt">/rfc/rfc2279.txt</a>
|
|
at <a href="http://www.ietf.org/">http://www.ietf.org/</a></dd>
|
|
</dl>
|
|
<hr />
|
|
|
|
<p><a href="http://validator.w3.org/check/referer"><img
|
|
src="http://validator.w3.org/images/vxhtml10"
|
|
alt="Valid XHTML 1.0!" height="31" width="88" /></a> <a
|
|
href="http://jigsaw.w3.org/css-validator/"><img class="c2"
|
|
src="http://jigsaw.w3.org/css-validator/images/vcss.gif"
|
|
alt="Valid CSS!" /></a></p>
|
|
</body>
|
|
</html>
|
|
|