NOTE-P3P10-Protocols-19980324 118 KB

Raw Blame History Permalink

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
"http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1252">
  <META NAME="GENERATOR" CONTENT="Microsoft FrontPage 3.0">
  <TITLE>NOTE-P3P10-Protocols-980324</TITLE>
</HEAD>
<BODY BGCOLOR="#ffffff" TEXT="#000000" LINK="#0000ff" VLINK="#800080">
<H3 ALIGN="RIGHT">
  <A HREF="http://www.w3.org/"><IMG SRC="http://www.w3.org/Icons/w3c_home.gif"
      ALT="W3C" BORDER="0" ALIGN="LEFT"></A>NOTE-P3P10-Protocols-19980324
</H3>
<P ALIGN="RIGHT">
&nbsp;
<H1 ALIGN="CENTER">
  P3P Protocol and Data Transport Working Group<BR>
  Draft White Paper
</H1>
<TABLE CELLSPACING="0" BORDER="0" CELLPADDING="0" WIDTH="637">
  <TR>
    <TD VALIGN="MIDDLE" COLSPAN="2" width="637"><DL>
	<DT>
	  This Version
	<DD>
	  <A HREF="http://www.w3.org/TR/1998/NOTE-P3P10-Protocols-19980324.html">http://www.w3.org/TR/1998/NOTE-P3P10-Protocols-19980324.html</A>
	<DT>
	  Latest Version
	<DD>
	  <A HREF="http://www.w3.org/TR/1998/NOTE-P3P10-Protocols">http://www.w3.org/TR/1998/NOTE-P3P10-Protocols</A>
	<DT>
	  Previous Version:
	<DD>
	  Please see drafts at the
	  &nbsp;<A HREF="http://www.w3.org/P3P/Group/Protocols/Overview.html">Protocols
	  WG Page</A>.
	  [<A HREF="http://www.w3.org/Consortium/Overview.html#Membership">Member
	  only</A>]
      </DL>
    </TD>
  </TR>
  <TR>
    <TD WIDTH="364" VALIGN="MIDDLE"><DL>
	<DT>
	  <STRONG></STRONG>
	<DD>
	  <STRONG></STRONG>
	<DT>
	  <STRONG>Editors</STRONG>
	<DD>
	  Philip DesAutels, W3C
	<DD>
	  Steve Lucas, MatchLogic
	<DD>
	  Joseph Reagle, W3C<FONT COLOR="#c0c0c0"></FONT>
	  <P>
	  <STRONG> </STRONG>
	<DT>
	  <B>Contributors</B>:
	<DD>
	  Lorrie Cranor, AT&amp;T
	<DD>
	  Philip DesAutels, MatchLogic
	<DD>
	  Melissa Dunn, Microsoft
	<DD>
	  Tatsuo Itabashi, Sony
	<DD>
	  Dan Jaye, Engage
	<DD>
	  Yves Leroux, Digital
	<DD>
	  Steve Lucas, Matchlogic
	<DD>
	  Jim Miller, W3C
	<DD>
	  Michael Myers, VeriSign
	<DD>
	  Paul Perry, FireFly
	<DD>
	  Martin Presler-Marshall, IBM
	<DD>
	  Joseph Reagle, W3C
	<DD>
	  Drummond Reed, Intermind
	<DD>
	  Craig Vodnik, Pencom Web Works
      </DL>
    </TD>
    <TD WIDTH="273" VALIGN="MIDDLE"><DL>
	<DD>
	  &nbsp;
      </DL>
    </TD>
  </TR>
  <TR>
    <TD VALIGN="MIDDLE" COLSPAN="2" width="637"><H2>
	Status of This Document
      </H2>
      <P>
      This W3C NOTE is <EM>provided for historical purposes</EM> <EM>only</EM>.
      It is not part of the P3P specification and need not be read to understand
      P3P. It is an intermediary product, from the
      <A href="http://www.w3.org/P3P/Group/Protocols/Overview.html">Format and
      Protocol WG</A>, of the <A href="http://www.w3.org/P3P">P3P Activity</A>.
      This document was completed in March, but is being released concurrently
      with the <A href="http://www.w3.org/TR/1998/WD-P3P10-syntax">public Working
      Draft of the Specification.</A> It is published because much of the work
      and contributors on this document was instrumental to the development of
      the <A href="http://www.w3.org/TR/1998/WD-P3P10-syntax">specification.</A>
      <P>
      Parts of this document may be incomplete, it will not be updated and it will
      not be advanced toward W3C recommendation status.
      <P>
      This document is a NOTE made available by the W3 Consortium for archival
      purposes. This indicates no endorsement of its content.</TD>
  </TR>
</TABLE>
<H2>
  Table of Contents
</H2>
<OL>
  <LI>
    <A HREF="#Introduction">Introduction</A>
    <OL>
      <LI>
	<A HREF="#Problem_Space">Problem Space</A>
      <LI>
	<A HREF="#Scope">Scope</A>
      <LI>
	<A HREF="#Terminology">Protocol Terminology</A>
      <LI>
	<A HREF="#Assumptions">Assumptions</A>
    </OL>
  <LI>
    <A href="#Scenarios__Overview">Scenarios, Overview</A>
    <OL>
      <LI>
	<A HREF="#BM1__No_Negotiation">No Negotiation</A>
	<OL TYPE="A">
	  <LI>
	    <A HREF="#BM1A__Practices_and_preferences_are_comp">Practices and preferences
	    are compatible</A>
	  <LI>
	    <A HREF="#BM1B__Practices_and_preferences_are_inco">Practices and preferences
	    are incompatible</A>
	</OL>
      <LI>
	<A HREF="#BM2__Negotiation">Negotiation</A>
	<OL TYPE="A">
	  <LI>
	    <A HREF="#BM2A__User_does_not_provide_a_counter_pr">User does not provide
	    a counter proposal</A>
	  <LI>
	    <A HREF="#BM2B__User_provides_a_counter_proposal">User provides a counter
	    proposal</A>
	</OL>
      <LI>
	<A HREF="#BM3__Exceptional_Scenarios">Exceptional Scenarios</A>
	<OL TYPE="A">
	  <LI>
	    <A HREF="#BM3A__Request_for_data_without_a_proposa">Request for data without
	    a proposal</A>
	  <LI>
	    <A HREF="#BM3B__Error_scenarios">Error scenarios</A>
	</OL>
    </OL>
  <LI>
    <A HREF="#Negotiation_Primitives">Negotiation_Primitives</A>
    <OL>
      <LI>
	<A HREF="#OK_PROP">OK-PROP - I Agree</A>
      <LI>
	<A HREF="#OK_TXD">OK-TXD - Data Transfer Successful</A>
      <LI>
	<A HREF="#PROP">PROP - Here is a Proposal</A>
      <LI>
	<A HREF="#RFD">RFD - Request for Data</A>
      <LI>
	<A HREF="#RFD">RFT - Request for Text of Proposal</A>
      <LI>
	<A HREF="#RFP">RFP - Request for Proposal</A>
      <LI>
	<A HREF="#SRY_PROP">SRY-PROP - Sorry I Refuse Because ...</A>
      <LI>
	<A HREF="#SRY_RFD">SRY-RFD - Sorry No Agreement </A>
      <LI>
	<A href="#SRY_RFP">SRY-RFP - Sorry I won't give a proposal</A>
      <LI>
	<A HREF="#SRY_RFT">SRY-RFT - Sorry No Text </A>
      <LI>
	<A HREF="#SRY_TXD">SRY-TXD - Sorry Data Transfer Not Successful</A>
      <LI>
	<A HREF="#STOP">STOP - Stop Negotiation</A>
      <LI>
	<A HREF="#TXD">TXD - Transmit Data</A>
    </OL>
  <LI>
    <A HREF="#Scenarios__Detailed">Scenarios, Detailed (HTTP headers)</A><BR>
    <A HREF="#BM1__No_Negotiation">No Negotiation and Negotiated Line-Flows</A>
    <OL>
      <LI>
	No Negotiation
	<OL TYPE="A">
	  <LI>
	    <A HREF="#BM_1A_Lineflows">Practices and preferences are compatible</A>
	  <LI>
	    <A HREF="#BM_1B_Lineflows">Practices and preferences are incompatible</A>
	</OL>
      <LI>
	Negotiation
	<OL TYPE="A">
	  <LI>
	    <A HREF="#BM_2A_Lineflows">User does not provide a counter proposal</A>
	  <LI>
	    <A HREF="#BM_2B_Lineflows">User provides a counter proposal</A>
	</OL>
      <LI>
	<A HREF="#Exceptional_Lines_Flows">Exceptional Line-Flows</A>
	<OL TYPE="A">
	  <LI>
	    <A HREF="#No_Pre_Existing_Agreement_Without_Digita">No Pre-Existing Agreement
	    Without Digital Signatures</A>
	  <LI>
	    <A HREF="#No_Pre_Existing_Agreement_With_Digital_S">No Pre-Existing Agreement
	    With Digital Signatures</A>
	  <LI>
	    <A HREF="#Service_Requests_Data_Without_Proposal">Service Requests Data Without
	    Proposal</A>
	</OL>
    </OL>
  <LI>
    <A HREF="#Syntax_of_P3P_Negotiation_Primitives_and">Syntax of P3P Negotiation
    Primitives</A>
  <LI>
    <A HREF="#Syntax_of_P3P_Schemas">Syntax of P3P Schemas</A>
    <OL>
      <LI>
	<A HREF="#Syntax_of_P3P_Proposal">Syntax of P3P Proposal</A>
      <LI>
	<A HREF="#Syntax_of_Disclosures">Syntax of Disclosures</A>
      <LI>
	<A HREF="#Syntax_of_Categories">Syntax of Categories</A>
      <LI>
	<A href="#Syntax_of_Data_Set">Syntax of Data Set</A>
    </OL>
</OL>
<OL TYPE="A">
  <LI>
    <A HREF="#notation">Notation</A> (EBNF description)
  <LI>
    <A HREF="#P3P_Data_Elements__Categories_and_Sets">P3P Data Elements, Categories
    and Sets</A>
  <LI>
    <A href="#References">References</A>
  <LI>
    <A HREF="http://www.w3.org/TR/WD-P3P-arch-971022.html">P3P Glossary</A> [refers
    to Definitions in Architecture Draft]
</OL>
<H2>
  <A NAME="Introduction">Introduction</A>
</H2>
<P>
This paper extends the work started in the earlier P3P Working Groups by
working through details of the user/service interactions that take place
as a user traverses the Web. It is our intention to provide sufficient grounding
that the next step, a detailed technical specification of the "bits and bytes,"
will be a straightforward technical task. Toward that end, we provide an
English language description of the scenarios that form the core of the design
as well as the messages (and their content) required to make the scenarios
real.
<H3>
  <A NAME="Problem_Space">Problem Space</A>
</H3>
<P>
P3P is attempting to provide mechanisms:
<UL>
  <LI>
    <FONT COLOR="#ff0000"> </FONT>
  <LI>
    for a user agent and service to negotiate over the privacy practices of a
    site and over what data, if any, is to be exchanged under those practices
  <LI>
    to exchange data when such exchange is consistent with a user's preferences
    and authorized by the user.
</UL>
<P>
The negotiation is based on comparing a set of privacy preferences, owned
by the user agent, with the privacy practices specified by the service. When
the privacy preferences do not match the service's practices, the two sides
must come to an agreement by exchanging proposals on alternative practices
that both entities can agree to. Every proposal has a defined set of consequences
that can be shown to a human user to explain why the suggested practice may
be acceptable in this instance even if the user would not normally allow
the practice (for example, the service may offer a discount, offer a bonus,
etc.).
<H3>
  <A NAME="Scope">Scope</A>
</H3>
<P>
<FONT COLOR="#ff0000"></FONT>
<P>
This Working Group is tasked with describing the set of negotiation primitives
(and their proper ordering) necessary for arriving at an agreement and answering
related questions related to those primitives such as how they can be digitally
signed when that technology is deployed. There are a number of tasks related
to this problem space which are not part of this Working Group's scope:
<OL>
  <LI>
    The language used to specify these practices is being created by another
    Harmonized Vocabulary Working Group. It is our working premise that the precise
    terms and conditions will not materially affect either the format of the
    messages needed to convey them or the kinds of negotiation steps required
    to arrive at agreement.
  <LI>
    This Working Group (and, indeed, W3C itself) is not tasked with defining
    "value add" work that applies only to the user or service sides of the
    negotiation. In particular, this Working Group will not advise developers
    on intelligent strategies or tactics for performing negotiation.
  <LI>
    This Working Group is not tasked with creating a transportable format for
    moving privacy-related configuration information, either on the user (privacy
    preferences) or service (privacy practices) side. This will be determined
    by the syntax group.
  <LI>
    This Working Group is not tasked with expressing how data will be shared
    or aggregated. This is the responsibility of the Harmonized Vocabulary Working
    Group.
</OL>
<H3>
  <A NAME="Terminology">Terminology</A>
</H3>
<P>
In addition to the terms defined in
<A HREF="http://www.w3.org/TR/WD-P3P-arch-971022.html">earlier P3P
documents</A>, the following terms are used consistently throughout this
document:
<TABLE CELLSPACING="0" BORDER="0" CELLPADDING="7" WIDTH="100%">
  <TBODY>
    <TR>
      <TD VALIGN="middle" align="left"></TD>
    </TR>
  </TBODY>
  <TBODY>
    <TR>
      <TD><STRONG>Term</STRONG></TD>
      <TD VALIGN="middle" align="left"><H4>
	  Definition
	</H4>
      </TD>
    </TR>
    <TR>
      <TD VALIGN="middle" align="left">Data Element</TD>
      <TD VALIGN="middle" align="left">An individual data entity, such as last
	name or phone number.</TD>
    </TR>
    <TR>
      <TD VALIGN="middle" align="left">Data Category</TD>
      <TD VALIGN="middle" align="left">A significant attribute of a data element
	or set that may be used by a trust engine to determine what type of element
	is under discussion, such as physical contact information.</TD>
    </TR>
    <TR>
      <TD VALIGN="middle" align="left">Data Set</TD>
      <TD VALIGN="middle" align="left">A known grouping of data elements, such
	as mailing address.</TD>
    </TR>
  </TBODY>
</TABLE>
<P>
<B></B>
<P>
<A NAME="Agreement">Agreement</A><BR>
An <STRONG><I>agreement</I></STRONG> is a small unit of information that
is sufficient to indicate that both parties have agreed on a common proposal.
This&nbsp; includes any one of:
<OL>
  <LI>
    the <A href="#Fingerprint__aka_Hash_or_Digest_">fingerprint</A> of an accepted
    proposal (if both parties agree that it need not be non-repudiable)
  <LI>
    the <A href="#Fingerprint__aka_Hash_or_Digest_">fingerprint</A> plus the
    digital signature and identity information of the
    <A href="#Assuring_Party">assuring party</A> and/or the user.
</OL>
<P>
Technically, this corresponds to a small piece of metadata in
<A HREF="http://www.w3.org/Metadata/RDF/">RDF</A> (Resource Description
Framework) format that may optionally include a
<A HREF="http://www.w3.org/Security/DSig/">DSig</A> 2.0-compliant signature.
<P>
<B></B>
<P>
<A NAME="Fingerprint__aka_Hash_or_Digest_">Fingerprint (aka Hash or
Digest)</A><BR>
Given any digital information, it is possible to construct a fixed size (about
20 byte) number that is easily computed from the original information but
even small modifications to the original result in a different number which
is virtually unpredictable. We call these fixed size numbers the
<STRONG><I>fingerprint</I></STRONG> of the original object. Given a fingerprint
and an object it is easy to tell whether the fingerprint refers to that
particular object, but it is not easy to predict what object created a given
fingerprint. Both generating a fingerprint and verifying its correctness
are quickly performed and do <I>not</I> rely on public or private keys, identity
information, etc.
<P>
In P3P, we use fingerprints both as part of signatures and to identify Proposals
so that the entire text of the proposal need not be sent repeatedly. This
should significantly reduce the overhead of the protocol. The hash protocol
is an MD5 digest in US-ASCII characters using MIME base-64 encoding.
<P>
<STRONG></STRONG>
<P>
<A NAME="Assuring_Party">Assuring Party</A><BR>
Within P3P, an <STRONG>assuring party</STRONG> attests that the service will
abide by its proposal, follows guidelines in the processing of data or other
relevant assetions; this assurance may come from the service or an independent
<STRONG><I>assuring party</I></STRONG>.The assuring party musts identify
what they are attesting to as part of the assurance statement. (This may
happen within the statement, or as part of the semantic definition of a meta-data
schema.) <FONT COLOR="#ff0000"></FONT>
<P>
<B></B>
<P>
<A NAME="Identity_information">Identity information</A><BR>
<STRONG><I>Identity information</I></STRONG> is any information sufficient
to satisfy one party of the identity of another. This may consist of a public
key and/or set of certificates that can be used to verify signatures, or
it may consist of a shared secret, or some real word identification information
(name, social security number, birthdate, etc.)
<P>
<B></B>
<P>
Proposal<BR>
A <STRONG><I>proposal</I></STRONG> is an offer by a service to collect a
specified set of information (or an offer to provide a service without collecting
any information) from a user for a particular purpose and under a specific
set conditions. Note that the proposal is always a statement made from the
point of view of the service and contains identifying information for the
service, but it may be created by the user and sent to the server for approval.
The proposal includes identity information specifying the entity with whom
the user is entering into agreement (this need not be the same as the entity
that signs the proposal).&nbsp; A proposal will be encoded using
<A HREF="http://www.w3.org/Metadata/RDF/">RDF</A> for transfer between the
user and the service.
<P>
<B></B>
<P>
<A NAME="BM_Digital__Signature">(Digital) Signature</A><BR>
We assume that users and services may have a pair of keys, one public (i.e.
known to everyone) and one private. A <STRONG><I>(digital)
signature</I></STRONG> for an object is generated by calculating the
<A href="#Fingerprint__aka_Hash_or_Digest_">fingerprint</A> of the object
and then encrypting it with the private key. Given the public key, the signature,
and the digital object it is easy to ensure that the the signature was generated
by someone in possession of the corresponding private key and the digital
object, and was almost certainly not generated in any other way (this is
called <STRONG><I>signature verification</I></STRONG>).&nbsp; While signature
verification is an efficient process, generating the signature requires a
significant amount of computation.
<P>
In P3P, we will use digital signatures as specified in the
<A HREF="http://www.w3.org/Security/DSig/">DSig</A>-2.0 specification (for
creating signed RDF).&nbsp; These signatures are always attached to a specific
statement; the signature asserts that the entity creating the signature believes
the statement to be true. This functionality is not available for P3P1.0.
<P>
<B></B>
<P>
Signed Proposal<BR>
A <STRONG><I>signed proposal</I></STRONG> is a proposal that has an attached
digital signature. A
<STRONG><I><A NAME="signed_proposal_from_the_service">signed proposal from
the service</A></I></STRONG> is signed by an entity, the assuring party,&nbsp;
willing to assure that the service will abide by the proposal.&nbsp; A
<STRONG><I>signed sroposal from the user</I></STRONG> is signed by the user.
In the short term, we assume the likely hood of assuring parties (which may
be the service itself) to sign proposals is greater than that of user agent
signatures because of the lack of a well established client side certificate
infrastructure.<FONT COLOR="#ff0000"></FONT>
<P>
<B></B>
<P>
<A NAME="Signed_Proposal">Signed Agreement</A><BR>
A <STRONG><I>signed aggrement</I></STRONG> is an agreement between the service
and user that has one or more attached digital signatures. A
<STRONG><I>signed agreement</I></STRONG> is signed by the assuring party
and the user. The same caveat regarding the existence of client side certificates
as expressed above applies.<FONT COLOR="#ff0000"></FONT>
<P>
  <HR WIDTH="80%">
<H3>
  <A NAME="Assumptions">Assumptions</A>
</H3>
<P>
P3P makes several assumptions about the environment in which it works and
the problem it is trying to solve.
<OL>
  <LI>
    <FONT COLOR="#ff0000"> </FONT>
  <LI>
    P3P enables the creation of an agreement between the user and the service.
    This agreement can contain information that creates non-repudiable evidence
    of the identities of the parties and the terms of the agreement. The
    non-repudiability of these statements will fall to future versions of the
    protocol. At this time, no clear/dominant PKI model exists for use in P3P.
    In future versions of the protocol, we assume that both users and services
    will be able to require signatures/certificates. Even so, such evidence can
    be expensive in terms of computational or complexity costs (logs, multiple
    certificates and signatures) and it is recommended that it be optional, not
    required.
  <LI>
    P3P agreements are end-to-end, between the user and the service. Intermediaries
    such as telecommunication providers, internet service providers, proxies
    and others may be privy to the exchange of data between a service and a user
    but those practices are not included in the agreement between the end parties.
  <LI>
    We assume that communication security is achieved through means other than
    P3P itself (such as SSL). Hence P3P does not provide mechanisms for
    cryptographically protecting information.
  <LI>
    P3P1.0 does not provide for signatures or require identification certificates.
    It is our expectation that these will be required in future versions of the
    protocol. Services, assurers and users can use certificates as forms of
    identification and operate over secure protocols (e.g. SSL) to obtain a higher
    level of trust, but these are not required.
  <LI>
    P3P allows a service to include identifying information about itself in its
    proposals. If no identifying information is provided, the service identity
    is assumed to be the registered owner of the service's domain.
  <LI>
    P3P is intended to be carried over
    <A HREF="http://www.w3.org/Protocols/History.html#Rev01">HTTP/1.1</A> and
    we assume user-agents implement HTTP/1.1 persistent connections. This is
    a performance-related assumption, not a correctness-related assumption; our
    protocol design must be fully backward compatible with HTTP/1.0, and will
    draw heavily on the existing design work on
    <A HREF="http://www.w3.org/Protocols/PEP/">PEP</A>.
  <LI>
    <A NAME="Most_Common_Case">Most sites will have one or a small number of
    clearly stated privacy policies that are acceptable for their typical users
    and will make "take it or leave it" offers. Some sites may be willing to
    negotiate with users and user agents.</A>
</OL>
<H2>
  Overview of <A NAME="Scenarios__Overview">Scenarios</A>
</H2>
<P>
We provide a set of scenarios covering typical uses for the P3P protocol.
We do not expect these scenarios to be all-inclusive, but we believe that
they cover the most common uses.
<P>
These scenarios discuss the interaction between the user agent and the service.
In all cases, the user agent may prompt the human user (if any) for guidance
before proceeding, or it may operate without user intervention ("seamlessly")
based on preferences stored in the user agent.
<P>
  <HR WIDTH="80%">
<H3>
  <A NAME="BM1__No_Negotiation">#1: No Negotiation</A>
</H3>
<P>
This case is simplest from the protocol point of view. This case is where
the privacy practices of the service are compatible with the privacy preferences
of the user-agent. This case can occur without the need for human intervention.
The service and user-agent must still exchange a proposal, as the interaction
must be covered by some agreement.
<H4>
  <A NAME="BM1A__Practices_and_preferences_are_comp">#1A: Practices and preferences
  are compatible</A>
</H4>
<DL>
  <DT>
    User view
  <DD>
    User enters a URL into their Web browser, and the page is displayed.
</DL>
<P>
Service operation
<DL>
  <DD>
    The service requests some information with a given practice. For example,
    the service is configured to request only the user's clickstream data, for
    the purposes of system administration.
</DL>
<P>
Agent operation
<DL>
  <DD>
    Considering the service's practice and the user agent's preferences, the
    user agent decides that they are compatible. Consequently, it agrees to allow
    the service the access it has requested. For example, the user-agent is
    configured that the data element "clickstream" is in the "anonymous information"
    grouping, and is configured to allow services to collect information of that
    category if it is used only for system administration.
</DL>
<P>
Note that these discussions are between the user agent and the service. The
user agent may need to prompt the user to determine if its preferences are
compatible with the request that the service makes, or it may happen
automatically ("seamlessly"). For our purposes, these two scenarios are
equivalent.
<H4>
  <A NAME="BM1B__Practices_and_preferences_are_inco">#1B: Practices and preferences
  are incompatible</A>
</H4>
<P>
User view
<DL>
  <DD>
    User enters a URL into their Web browser, and gets back an error in response.
</DL>
<P>
Service operation
<DL>
  <DD>
    The service requests some information with a given practice. For example,
    the service is configured to request the user's governmental ID (for example,
    National Social Security Number), and disclose that they will share it with
    anyone they wish.
</DL>
<P>
Agent operation
<DL>
  <DD>
    Considering the service's practice and the user agent's preferences, the
    user agent decides that they are not compatible. Further, the user agent
    is configured such that it does not negotiate over such sensitive information.
    Consequently, it refuses to allow the service the access it has requested,
    and shows the user an error message. For example, the user-agent is configured
    such that the data element "National Social Security Number" is sensitive
    and it is configured to never allow services to collect information of that
    type.
</DL>
<P>
As mentioned above, this scenario does not specify the interaction between
the user agent and the user.
<P>
  <HR WIDTH="80%">
<H3>
  <A NAME="BM2__Negotiation">#2: Negotiation</A>
</H3>
<P>
<FONT COLOR="#ff0000"></FONT>
<P>
In the next scenario, a service initiates a request to exchange data. The
user responds by refusing to provide the data. The user may provide a&nbsp;
code or comment as to why the request was denied. The user might also opt
to provide a counter proposal -- for example, the user may agree to partially
satisfy the initial request. (Such as "I will provide my age and zip code
but not my name and address.") If a counter proposal is provided by the user,
the service responds by accepting or rejecting it. If no counter proposal
is provided, or if it is rejected, the service may send another proposal
to the user. This "negotiation" may continue until an offer is accepted or
one of the parties decides to end the
negotiation.<FONT COLOR="#ff0000"></FONT>
<H4>
  <A NAME="BM2A__User_does_not_provide_a_counter_pr">#2A: User does not provide
  a counter proposal</A>
</H4>
<DL>
  <DT>
    User view
  <DD>
    User enters a URL into their Web browser. Depending on the preferences the
    user has set in their browser, they may see a pop-up message requesting that
    they agree to the service's practices. The page is then displayed.
</DL>
<P>
Service operation
<DL>
  <DD>
    The service requests some information with a given practice. For example,
    the service requests a service ID so that the user can be anonymously be
    recognized during this session and in future sessions. The user agent refuses
    the request and does not make a counter proposal, though it may explain what
    it objects to. The service then makes an alternative proposal.
</DL>
<P>
Agent operation
<DL>
  <DD>
    Considering the service's practice and the user agent's preferences, the
    user agent decides that they are not compatible. The user agent refuses the
    service's request. The service can then make a counter proposal. Assuming
    that the user agent finds that its preferences are compatible with this new
    proposal, the user agent agrees to allow the service the access it has requested.
    For example, the alternative proposal could request a service ID that would
    only be good for the current session. If the user agent finds that alternative
    proposal acceptable, it agrees to that request.
</DL>
<H4>
  <A NAME="BM2B__User_provides_a_counter_proposal">#2B: User provides a counter
  proposal</A>
</H4>
<P>
User view
<DL>
  <DD>
    User enters a URL into their Web browser. The page is then displayed.
</DL>
<P>
Service operation
<DL>
  <DD>
    The service requests some information with a given practice. This request
    is rejected by the user agent, which makes a counter offer indicating what
    it finds acceptable. If the service finds this counter offer acceptable,
    it agrees to this counter offer, and allows access to the requested URL.
    For example, the service requests a service ID so that the user can be
    anonymously be recognized during this session and in future sessions. The
    user agent refuses this request and makes a counter offer, to give the service
    an ID which is usable for the current session only.
</DL>
<P>
Agent operation
<DL>
  <DD>
    Considering the service's practice and the user agent's preferences, the
    user agent decides that they are not compatible. The user agent looks at
    what parts of the request are acceptable, and makes a counter proposal that
    it finds acceptable. Assuming that the counter offer is acceptable to the
    service, the user agent gives access to the requested data. The example is
    given above.
</DL>
<P>
In both of the scenarios above, the P3P protocol does not make any distinction
about whether the user is prompted for approval or not. We believe that the
interactions, or lack thereof, between the user and the user agent are up
to the implementers of the user agents.
<P>
  <HR WIDTH="80%">
<H3>
  <A NAME="BM3__Exceptional_Scenarios">#3: Exceptional Scenarios</A>
</H3>
<H4>
  <A NAME="BM3A__Request_for_data_without_a_proposa">#3A: Request for data
  without a proposal</A>
</H4>
<P>
<FONT COLOR="#ff0000"></FONT>
<P>
A request could be issed in the absense of an agreement. This may because
the service believed that it had an agreement whereas the user did not. (Perhaps
it never did, or it only has a short memory). A user agent that does not
have such a policy will request a proposal. In very rare cases, in some people's
implementations other circumstances beyond privacy practices could allow
such a request to be issued. (For instance, perhaps the users trusted email
application running on the users machine is querying the users' repository
for an email address, in this case, the user doesn't require privacy practices
from the email application. This is not within the scope of this document
however.)<FONT COLOR="#ff0000"></FONT>
<H4>
  <A NAME="BM3B__Error_scenarios">#3B: Error scenarios</A>
</H4>
<P>
Services have several responsibilities in order to have reasonable error
situations:
<OL>
  <LI>
    Services must recognize clients that do not support P3P. For those clients,
    they must never use the P3P mechanisms to ask for data. They must also never
    use any error-reporting mechanisms defined by P3P.
  <LI>
    If a service and a user agent are unable to form an agreement after some
    number of rounds of negotiation, the service can provide a fallback page.
    This encompasses two tasks. First, we must provide a way to prevent infinite
    loops of negotiation. Second, certain countries (for example, Germany) will
    legally require that the services provide some non-personalized version of
    the requested resource.
</OL>
<P>
User agents are responsible for several error scenarios are well:
<OL>
  <LI>
    User agents must be able to call an end to negotiation. Assuming that this
    protocol is implemented over HTTP, proposals from the service will be carried
    in HTTP responses. The user agent must be able to send a request that includes
    a statement saying that the proposal included in the request - if any - is
    non-negotiable by using the FINAL qualifier. In addition, a user agent can
    terminate the negotiation at any time through use of the STOP message.
</OL>
<P>
  <HR WIDTH="80%">
<P>
&nbsp;
<H2>
  3 <A NAME="Negotiation_Primitives">Negotiation Primitives</A>
</H2>
<P>
In order to support the scenarios described above, P3P provides a set of
<I>primitive operations</I> to use in conversations:
<TABLE BORDER="1" CELLSPACING="1" WIDTH="100%">
  <TR>
    <TD WIDTH="12%" VALIGN="MIDDLE"><P ALIGN="CENTER">
      <B>Message</B></TD>
    <TD WIDTH="6%" VALIGN="MIDDLE"><B></B>
      <P ALIGN="CENTER">
      Meaning</TD>
    <TD WIDTH="2%" VALIGN="MIDDLE"><B></B>
      <P ALIGN="CENTER">
      U to S?</TD>
    <TD WIDTH="2%" VALIGN="MIDDLE"><B></B>
      <P ALIGN="CENTER">
      S to U?</TD>
    <TD WIDTH="11%" VALIGN="MIDDLE"><B></B>
      <P ALIGN="CENTER">
      After Receiving</TD>
    <TD WIDTH="18%" VALIGN="MIDDLE"><B></B>
      <P ALIGN="CENTER">
      Expected Response</TD>
    <TD WIDTH="20%" VALIGN="MIDDLE"><B></B>
      <P ALIGN="CENTER">
      Data in Message</TD>
    <TD WIDTH="30%" VALIGN="MIDDLE"><B></B>
      <P ALIGN="CENTER">
      Optional in Message</TD>
  </TR>
  <TR>
    <TD WIDTH="12%" VALIGN="MIDDLE"><A HREF="#OK_PROP">OK-PROP</A></TD>
    <TD WIDTH="6%" VALIGN="MIDDLE">Proposal acceptable</TD>
    <TD WIDTH="2%" VALIGN="MIDDLE">Yes</TD>
    <TD WIDTH="2%" VALIGN="MIDDLE">Yes</TD>
    <TD WIDTH="11%" VALIGN="MIDDLE">PROP</TD>
    <TD WIDTH="18%" VALIGN="MIDDLE">none</TD>
    <TD WIDTH="20%" VALIGN="MIDDLE">Agreement</TD>
    <TD WIDTH="30%" VALIGN="MIDDLE">&nbsp;Signature of recipient of proposal</TD>
  </TR>
  <TR>
    <TD WIDTH="12%" VALIGN="MIDDLE"><A HREF="#OK_TXD">OK-TXD</A></TD>
    <TD WIDTH="6%" VALIGN="MIDDLE">Data transfer successful</TD>
    <TD WIDTH="2%" VALIGN="MIDDLE">Yes</TD>
    <TD WIDTH="2%" VALIGN="MIDDLE">Yes</TD>
    <TD WIDTH="11%" VALIGN="MIDDLE">TXD</TD>
    <TD WIDTH="18%" VALIGN="MIDDLE">none</TD>
    <TD WIDTH="20%" VALIGN="MIDDLE">[hash of] data transferred</TD>
    <TD WIDTH="30%" VALIGN="MIDDLE">&nbsp;</TD>
  </TR>
  <TR>
    <TD WIDTH="12%" VALIGN="MIDDLE"><A HREF="#PROP">PROP</A></TD>
    <TD WIDTH="6%" VALIGN="MIDDLE">Here's a Proposal</TD>
    <TD WIDTH="2%" VALIGN="MIDDLE">Yes</TD>
    <TD WIDTH="2%" VALIGN="MIDDLE">Yes</TD>
    <TD WIDTH="11%" VALIGN="MIDDLE">any time</TD>
    <TD WIDTH="18%" VALIGN="MIDDLE">OK or SRY-PROP or PROP</TD>
    <TD WIDTH="20%" VALIGN="MIDDLE">Text of a proposal</TD>
    <TD WIDTH="30%" VALIGN="MIDDLE">Signature of initiator, fingerprint of previous
      Proposal</TD>
  </TR>
  <TR>
    <TD WIDTH="12%" VALIGN="MIDDLE"><A HREF="#RFD">RFD</A></TD>
    <TD WIDTH="6%" VALIGN="MIDDLE">Request for Data</TD>
    <TD WIDTH="2%" VALIGN="MIDDLE">No</TD>
    <TD WIDTH="2%" VALIGN="MIDDLE">Yes</TD>
    <TD WIDTH="11%" VALIGN="MIDDLE">any time</TD>
    <TD WIDTH="18%" VALIGN="MIDDLE">SRY-RFD, PROP, RFP, RFT or TXD</TD>
    <TD WIDTH="20%" VALIGN="MIDDLE">Names of data elements, sets of data elements,
      or categories</TD>
    <TD WIDTH="30%" VALIGN="MIDDLE">Previous agreement if not sent with a new
      proposal</TD>
  </TR>
  <TR>
    <TD WIDTH="12%" VALIGN="MIDDLE"><A HREF="#RFP">RFP</A></TD>
    <TD WIDTH="6%" VALIGN="MIDDLE">Request for Proposal</TD>
    <TD WIDTH="2%" VALIGN="MIDDLE">Yes</TD>
    <TD WIDTH="2%" VALIGN="MIDDLE">Yes</TD>
    <TD WIDTH="11%" VALIGN="MIDDLE">any time</TD>
    <TD WIDTH="18%" VALIGN="MIDDLE">PROPor SRY-RFP</TD>
    <TD WIDTH="20%" VALIGN="MIDDLE">Must agreement be signed?</TD>
    <TD WIDTH="30%" VALIGN="MIDDLE">Set of URLs to be covered</TD>
  </TR>
  <TR>
    <TD WIDTH="12%" VALIGN="MIDDLE"><A HREF="#RFT">RFT</A></TD>
    <TD WIDTH="6%" VALIGN="MIDDLE">Request for Text of Proposal</TD>
    <TD WIDTH="2%" VALIGN="MIDDLE">Yes</TD>
    <TD WIDTH="2%" VALIGN="MIDDLE">No</TD>
    <TD WIDTH="11%" VALIGN="MIDDLE">Agreement</TD>
    <TD WIDTH="18%" VALIGN="MIDDLE">PROP or SRY-RFT</TD>
    <TD WIDTH="20%" VALIGN="MIDDLE">Agreement</TD>
    <TD WIDTH="30%" VALIGN="MIDDLE">&nbsp;</TD>
  </TR>
  <TR>
    <TD WIDTH="12%" VALIGN="MIDDLE"><A HREF="#SRY_PROP">SRY-PROP</A></TD>
    <TD WIDTH="6%" VALIGN="MIDDLE">Refuse Proposal</TD>
    <TD WIDTH="2%" VALIGN="MIDDLE">Yes</TD>
    <TD WIDTH="2%" VALIGN="MIDDLE">Yes</TD>
    <TD WIDTH="11%" VALIGN="MIDDLE">PROP</TD>
    <TD WIDTH="18%" VALIGN="MIDDLE">PROP</TD>
    <TD WIDTH="20%" VALIGN="MIDDLE">Fingerprint of proposal refused, Reason</TD>
    <TD WIDTH="30%" VALIGN="MIDDLE">Which practices are unacceptable (To Be Designed)</TD>
  </TR>
  <TR>
    <TD WIDTH="12%" VALIGN="MIDDLE"><A HREF="#SRY_RFD">SRY-RFD</A></TD>
    <TD WIDTH="6%" VALIGN="MIDDLE">Refuse RFD</TD>
    <TD WIDTH="2%" VALIGN="MIDDLE">Yes</TD>
    <TD WIDTH="2%" VALIGN="MIDDLE">Yes</TD>
    <TD WIDTH="11%" VALIGN="MIDDLE">RFD</TD>
    <TD WIDTH="18%" VALIGN="MIDDLE">none</TD>
    <TD WIDTH="20%" VALIGN="MIDDLE">Agreement refused, Reason</TD>
    <TD WIDTH="30%" VALIGN="MIDDLE">&nbsp;</TD>
  </TR>
  <TR>
    <TD WIDTH="12%" VALIGN="MIDDLE"><A HREF="#SRY_RFP">SRY-RFP</A></TD>
    <TD WIDTH="6%" VALIGN="MIDDLE">I won't give you a Proposal</TD>
    <TD WIDTH="2%" VALIGN="MIDDLE">Yes</TD>
    <TD WIDTH="2%" VALIGN="MIDDLE">Yes</TD>
    <TD WIDTH="11%" VALIGN="MIDDLE">RFP</TD>
    <TD WIDTH="18%" VALIGN="MIDDLE">none</TD>
    <TD WIDTH="20%" VALIGN="MIDDLE">&nbsp;Reason</TD>
    <TD WIDTH="30%" VALIGN="MIDDLE">&nbsp;</TD>
  </TR>
  <TR>
    <TD WIDTH="12%" VALIGN="MIDDLE"><A HREF="#SRY_RFT">SRY-RFT</A></TD>
    <TD WIDTH="6%" VALIGN="MIDDLE">Proposal Text not available</TD>
    <TD WIDTH="2%" VALIGN="MIDDLE">No</TD>
    <TD WIDTH="2%" VALIGN="MIDDLE">Yes</TD>
    <TD WIDTH="11%" VALIGN="MIDDLE">RFT</TD>
    <TD WIDTH="18%" VALIGN="MIDDLE">none</TD>
    <TD WIDTH="20%" VALIGN="MIDDLE">Agreement, Reason</TD>
    <TD WIDTH="30%" VALIGN="MIDDLE">&nbsp;</TD>
  </TR>
  <TR>
    <TD WIDTH="12%" VALIGN="MIDDLE"><A HREF="#SRY_TXD">SRY-TXD</A></TD>
    <TD WIDTH="6%" VALIGN="MIDDLE">Data transfer not successfull</TD>
    <TD WIDTH="2%" VALIGN="MIDDLE">Yes</TD>
    <TD WIDTH="2%" VALIGN="MIDDLE">No</TD>
    <TD WIDTH="11%" VALIGN="MIDDLE">TXD or none</TD>
    <TD WIDTH="18%" VALIGN="MIDDLE">none</TD>
    <TD WIDTH="20%" VALIGN="MIDDLE">&nbsp;Agreement, Reason</TD>
    <TD WIDTH="30%" VALIGN="MIDDLE">&nbsp;</TD>
  </TR>
  <TR>
    <TD WIDTH="12%" VALIGN="MIDDLE"><A HREF="#STOP">STOP</A></TD>
    <TD WIDTH="6%" VALIGN="MIDDLE">Stop negotiation</TD>
    <TD WIDTH="2%" VALIGN="MIDDLE">Yes</TD>
    <TD WIDTH="2%" VALIGN="MIDDLE">No</TD>
    <TD WIDTH="11%" VALIGN="MIDDLE">any time before reaching an agreement</TD>
    <TD WIDTH="18%" VALIGN="MIDDLE">Good question!</TD>
    <TD WIDTH="20%" VALIGN="MIDDLE">none</TD>
    <TD WIDTH="30%" VALIGN="MIDDLE">&nbsp;</TD>
  </TR>
  <TR>
    <TD WIDTH="12%" VALIGN="MIDDLE"><A HREF="#TXD">TXD</A></TD>
    <TD WIDTH="6%" VALIGN="MIDDLE">Transfer Data</TD>
    <TD WIDTH="2%" VALIGN="MIDDLE">Yes</TD>
    <TD WIDTH="2%" VALIGN="MIDDLE">Yes</TD>
    <TD WIDTH="11%" VALIGN="MIDDLE">any time</TD>
    <TD WIDTH="18%" VALIGN="MIDDLE">none, OK-TXD or SRY-TXD</TD>
    <TD WIDTH="20%" VALIGN="MIDDLE">Data element names and values to be written,
      as requested</TD>
    <TD WIDTH="30%" VALIGN="MIDDLE">Agreement</TD>
  </TR>
</TABLE>
<P>
This section describes each of the operations and specifies who (user or
service) can initiate the action and under what circumstances. Under
<A HREF="#Scenarios, Detailed">Scenarios, Detailed</A> we revisit the earlier
scenarios, but this time showing how they are implemented using these primitive
operations. This section also provides some insight into requirements on
detailed data formats, which are then gathered together (along with information
from the earlier P3P documents) in the section on
<A HREF="#Formats: Requirements And Specifications">Formats: Requirements
and Specifications</A>.
<H3>
  <A NAME="OK_PROP"></A>3.1 I Agree (<TT>OK-PROP</TT>)
</H3>
<P>
After receiving a proposal from the other party, either party can respond
by accepting the proposal. The response includes an agreement.&nbsp;
<A HREF="#Agreement">Recall</A> that the fingerprint of the agreed upon proposal
can be extracted from the agreement, and that the agreement may or may not
include digital signatures of both parties.
<H3>
  <A NAME="OK_TXD"></A>3.2 Data transfer successful (<TT>OK-TXD</TT>)
</H3>
<P>
This message is sent after an entity has successfully received the contents
of a <A HREF="#TXD"><I>Transmit Data (TXD)</I></A> message.
<H3>
  3.3 <A NAME="PROP">Here's A Proposal (<TT>PROP</TT>)</A>
</H3>
<P>
At any time, either participant can send one or more proposals to the other,
these are sent in the prop-msg. The proposal's terms aren't binding until
the other side has agreed to them (see the
<A HREF="#OK_PROP"><TT><FONT COLOR="#0000ff"><U>OK-PROP</U></FONT></TT></A>
primitive). The proposal may be signed by the party that creates it if so
desired (recall, though, that the user can refuse to accept an agreement
unless the proposal is signed). In addition the PROP may also include the
fingerprint of a proposal previously received from the other party (this
may help the other party keep track of the negotiation). If a site wished
to express that a data element is optional, it may do so within the proposal;
the user agent will return the optional elements it feels appropriate. An
agreement over a proposal with optional purposes or qualifiers is ambigous;
there is not a strong mechanism for the agent to express that one purpose
was agreed to, but another was not. Consequently, optional purposes or qualifiers
must be expressed through multiple unambigous
proposals.<FONT COLOR="#ff0000"></FONT>
<P>
<A NAME="UserInitiatedProposalImplication">There is a privacy implication
if the user initiates a proposal</A>.&nbsp; The service may well use the
proposals it receives (from individual users or via statistical sampling
techniques) to tailor future proposals that it makes.&nbsp; In a sense, this
is precisely the reason that the user might wish to make a proposal -- in
the hope that the service will alter its longterm behavior towards that requested
by the user.&nbsp; On the other hand, revealing preferences by making a proposal
does divulge a good deal of valuable information about the current user (in
a non-personally-identifying form).
<P>
If a proposal isn't automatically acceptable to the user, there are three
options. The user agent must be programmed in some manner to decide which
response is appropriate:
<OL>
  <LI>
    <B> </B>
  <LI>
    Refuse (<TT>SRY-PROP</TT>) the proposal. This implies a desire to receive
    a new proposal from the service. Notice that there is a potential for an
    infinite loop if the user agent continues to send a <TT>SRY</TT> message
    should the same proposal be sent repeatedly. It is the responsibility of
    the user agent to maintain sufficient state to detect this case and respond
    using one of the other techniques after it determines that a sufficient number
    of negotiation rounds have occurred (the service might, after all, choose
    to change its proposal if the agent appears sufficiently obstinate...)
    <P>
    <B> </B>
  <LI>
    Return a <A HREF="#PROP">PROPosal</A><B> of its own.</B> This is a common
    negotiation strategy (the counterproposal), and perfectly appropriate. It
    implies a refusal, but provides an alternate that the user considers acceptable
    if accepted by the service. Notice that the service has the right to assume
    that by making the offer the user is willing to accept it if the service
    does (no further confirmation is required). Also notice that there is a privacy
    <A HREF="#UserInitiatedProposalImplication">consideration</A>, discussed
    <A HREF="#There is a privacy implication if the user initiates a proposal">earlier</A>,
    when a user issues a proposal.
    <P>
    <B> </B>
  <LI>
    Walk away from the negotiation. There is no requirement that the user agent
    respond at all. The user agent may also choose to respond but use a new
    connection and a new <I>unique ID</I> so that the service is unaware that
    it is the same agent.
</OL>
<P>
In time, the capability to send a subset of the user's preferences to better
help the service make an informed proposal may exist.
<H3>
  <A NAME="RFD"></A>3.4 Request for Data (<TT>RFD</TT>)
</H3>
<P>
The service can, at any time, request that data be transmitted from the user
(this includes the special case of requesting a unique identifier for collecting
clickstream data). The request can be transmitted alone (with no commitment
by the service as to the use of the data should it be transmitted) or accompanied
by either:
<UL>
  <LI>
    a previously negotiated <A HREF="#Agreement">agreement</A> (represented by
    a hash). This should "remind" the user that this request falls within the
    bounds previously agreed. The agreement does not include the text of the
    proposal, but that can be requested by the user from the service using a
    <A HREF="#Request for Text of Proposal (RFT)">RFT</A> message.
  <LI>
    a newly initiated proposal. This indicates the practices that the service
    intends to apply to the data if it is divulged. The proposal may be
    <A HREF="#signed proposal from the service">signed by the service</A> if
    it desires or was requested to do so by an earlier
    <A HREF="#Request for Proposal (RFP)">RFP</A>.
</UL>
<P>
There are four proper responses to a <TT>RFD</TT>: the user may walk away
(this cannot be eliminated, since a network failure will cause this to occur
even if the protocol were to "require" a response); the user may refuse with
a reason
(<A HREF="#SRY_RFD"><TT><FONT COLOR="#0000ff"><U>SRY-RFD</U></FONT></TT></A>);
the user may send its own <A HREF="#PROP">PROPosal</A> back; or the user
may transmit the requested data
(<A HREF="#Transmit Data (TXD)"><TT><FONT COLOR="#0000ff"><U>TXD</U></FONT></TT></A>).
<H3>
  <A NAME="RFT"></A>3.5 Request for Text of Proposal (<TT>RFT</TT>)
</H3>
<P>
After the user and service have reached an agreement, the user may request
the text of the proposal that is part of that agreement from the service,
so that it does not have to store state during the negotiation process. The
service should respond either with a
<A HREF="#Here's A Proposal (PROP)"><TT><FONT COLOR="#0000ff"><U>PROP</U></FONT></TT>osal
message</A>, including the correct proposal text (which can be verified by
the user, since the user has the fingerprint of the proposal text as part
of the agreement itself), or with a
<A HREF="#SRY_RFT"><TT><FONT COLOR="#0000ff"><U>SRY_RFT</U></FONT></TT></A>,
if the server no longer has a record of the agreement and is unable to regenerate
it algorithmically.
<H3>
  <A NAME="RFP"></A>3.6 Request for Proposal (<TT>RFP</TT>)
</H3>
<P>
At any time, the user can send a <I>request for proposal</I> to the service.
The RFP specifies whether or not the user expects to reach a non-repudiable
agreement and the set of URLs the user would like the agreement to cover.
<P>
This should not be used if the user has a particular proposal that she would
like to see adopted by the service; that is best handled (although with some
privacy consequences) by using the
<A HREF="#Here's A Proposal (PROP)"><I>Here's A Proposal
(<TT><FONT COLOR="#0000ff"><U>PROP</U></FONT></TT>)</I></A> primitive.
<H3>
  <A NAME="SRY_PROP"></A>3.7 Sorry, I Refuse Because (<TT>SRY-PROP</TT>)
</H3>
<P>
The user, after receiving a proposal from the service, can refuse it and
request another proposal. The <TT>SRY</TT> message includes the fingerprint
of the proposal being rejected, as well as the reason why it is being refused.
The technical cause for refusing a proposal are given by the
<A HREF="#reason codes">reason codes</A>. Reasons, such as the user's preferences
not matching the site's practices, are not returned at this point. Sites
may provide capabilities on their privacy practice page whereby users can
inform a site of practices that they did not&nbsp; find appealing. Future
versions&nbsp; of P3P may be able to enable the expression of reasons that
are sufficiently specified that the service, upon receipt, can make a reasonable
decision about a potentially acceptable replacement proposal.
<H3>
  <A NAME="SRY_RFD"></A>3.8 Sorry, No Agreement (<TT>SRY-RFD</TT>)
</H3>
<P>
The recipient, after receiving a <A HREF="#RFD"><I>Request for Data
(RFD)</I></A> can respond with a <A HREF="#SRY_RFD">SRY_RFD</A> message.
The reason code describes whether the <A HREF="#RFD">RFD</A> was denied because
the recipient does not recognize an agreement contained in the
<A HREF="#RFD">RFD</A> request or if the recipient wants to terminate the
agreement.
<H3>
  <A NAME="SRY_RFP">3.9 Sorry, I won't give you a proposal (SRY-RFP)</A>
</H3>
<P>
The service after receiving a <A HREF="#RFP">Request for Proposal (RFP)</A>
can respond with a SRY-RFP message to indicate that it will not make a
proposal.<FONT COLOR="#ff0000"></FONT>
<H3>
  <A NAME="SRY_RFT"></A>3.10 Sorry, No Text (<TT>SRY-RFT</TT>)
</H3>
<P>
The service after receiving a <A HREF="#RFT"><I>Request for Text
(RFT)</I></A> can respond with a SRY-RFT message to indicate that it no longer
has access the text of the proposal requested by the user.
<H3>
  <A NAME="SRY_TXD"></A>3. 11 Sorry, Data Transfer Not Successful
  (<TT>SRY-TXD</TT>)
</H3>
<P>
The recipient after receiving a <A HREF="#RFT"><I>Transmit Data (TXD)</I></A>
can respond with a SRY-TXD message to indicate that it did not successfully
receive the data. The sender may re-try the TXD message but should prevent
an infinite loop of re-tries.
<H3>
  <A NAME="STOP"></A>3. 12 Stop Negotiation (<TT>STOP</TT>)
</H3>
<P>
At any time before an agreement is reached, the recipient can respond with
a STOP message to indicate that it does not want to continue negotiations.
If there is still an http request outstanding, the server should still respond
to the request, even if the response is merely an HTML document indicating
that the requested object cannot be returned without an agreement.
<H3>
  <A NAME="TXD"></A>3.13 Transmit Data (<TT>TXD</TT>)
</H3>
<P>
After the receipt of a <A HREF="#RFD"><I>Request For Data (RFD)</I></A>,
the user may send out the requested data. The message can optionally include
the agreement that the user understands is to be applied. The service is
bound to honor the agreement if it is valid (signed by both sides if so required,
within the proper time limits, and covering the data being transferred).
If no agreement is transmitted the service is obliged to follow all of the
agreements it has entered into that cover this transfer. (Notice that it
is only in the case of signed agreements that the user will have convincing
evidence that an agreement was made. In other cases, the user will have to
rely on the honesty of the service. Since there is a cost associated with
the signatures, this requires users to balance their trust of the service
against the cost of the signature.)
<P>
The user is not obliged to respond to an RFD with a transfer of all the data
requested, since the agreement may include optional elements. It is up to
the user agent to decide how many of these to transfer (the agreement will
have informed the user the consequences (presumably rewards) of sending the
optional items).
<P>
  <HR WIDTH="80%">
<H2>
  4 <A NAME="Scenarios__Detailed">Scenarios, Detailed</A>
</H2>
<P>
This section amplifies on the scenarios presented
<A HREF="#Scenarios, Overview">earlier</A>, by providing a detailed description
of how a combination of an appropriately configured browser and server can
create these scenarios using the negotiation primitives
<A HREF="#Negotiation Primitives">proposed here</A>.The interaction will
be shown as a set of HTTP requests and responses, with the important part
being the general flow of proposal and response. The precise details of the
requests are not filled in at this time.
<H3>
  <A NAME="No_Negotiation_and_Negotiated_Lineflows">No Negotiation and Negotiated
  Line-Flows</A>
</H3>
<H4>
  <A NAME="BM_1A_Lineflows">4.1.A Lineflows</A> (no negotiation, compatible
  practices &amp; preferences):
</H4>
<P>
The transaction begins:
<PRE>GET /Index.html HTTP/1.1
Accept: */*
User-Agent: BugblatterBeast/3.02 (RT-11; english)
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html"} {strength must}}
</PRE>
<P>
The user agent has requested a Web page, and indicates that it supports the
P3P protocol.
<PRE>HTTP/1.1 400 Agreement required
Server: Marvin/2.0.1
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html" 42-} {strength must}}
42-P3P: {{PROP [proposal with hash XYZ]} {RFD [data request}}
Content-Type: text/html
Content-Length: 70

&lt;html&gt;&lt;body&gt;
&lt;h1&gt;HTTP/1.1 400 Agreement Required&lt;/h1&gt;
&lt;/body&gt;&lt;/html&gt;
</PRE>
<P>
The service indicates that it supports the P3P protocol, and that it will
not serve the requested resource without first reaching an agreement with
the user agent. The user agent receives this response, accepts the proposal,
and signifies its agreement with it.
<PRE>GET /Index.html HTTP/1.1
Accept: */*
User-Agent: BugblatterBeast/3.02 (RT-11; english)
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html" 20996-} {strength must}}
20996-P3P: {{OK-PROP XYZ} {TXD [data transfer with hash LMN]}
</PRE>
<P>
The user agent has now made a new request that indicates that it agrees to
the previous proposal. The service finds this acceptable, and sends the object.
<PRE>HTTP/1.1 200 OK
Server: Marvin/2.0.1
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html" 62090-} {strength must}}
62090-P3P: {{OK-TXD LMN}}
Content-type: text/html
Content-length: ...

...body...
</PRE>
<H4>
  <A NAME="BM_1B_Lineflows">4.1.B Lineflows</A> (no negotiation, incompatible
  practices &amp; preferences):
</H4>
<P>
We start with:
<PRE>GET /Index.html HTTP/1.1
Accept: */*
User-Agent: BugblatterBeast/3.02 (RT-11; english)
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html"} {strength must}}
</PRE>
<P>
The user agent has requested a Web page, and indicates that it supports the
P3P protocol.
<PRE>HTTP/1.1 400 Agreement required
Server: Marvin/2.0.1
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html" 42-} {strength must}}
42-P3P: {{PROP [proposal with hash XYZ]} {RFD [data request}}
Content-Type: text/html
Content-Length: 70

&lt;html&gt;&lt;body&gt;
&lt;h1&gt;HTTP/1.1 400 Agreement Required&lt;/h1&gt;
&lt;/body&gt;&lt;/html&gt;
</PRE>
<P>
The service indicates that it supports the P3P protocol, and that it will
not serve the requested resource without first reaching an agreement with
the user agent. The user agent receives this response, decides that it is
unwilling to negotiate with the service, and the transfer halts.
<H4>
  <A NAME="BM_2A_Lineflows">4.2.A Lineflows</A> (negotiation, user agent does
  not provide a counter proposal):
</H4>
<PRE>GET /Index.html HTTP/1.1
Accept: */*
User-Agent: BugblatterBeast/3.02 (RT-11; english)
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html"} {strength must}}
</PRE>
<P>
The user agent has requested a Web page, and indicates that it supports the
P3P protocol.
<PRE>HTTP/1.1 400 Agreement required
Server: Marvin/2.0.1
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html" 42-} {strength must}}
42-P3P: {{PROP [proposal with hash XYZ]} {RFD [data request}}
Content-Type: text/html
Content-Length: 70

&lt;html&gt;&lt;body&gt;
&lt;h1&gt;HTTP/1.1 400 Agreement Required&lt;/h1&gt;
&lt;/body&gt;&lt;/html&gt;
</PRE>
<P>
The user agent looks at the proposal, decides it is not acceptable, and refuses
it.
<PRE>GET /Index.html HTTP/1.1
Accept: */*
User-Agent: BugblatterBeast/3.02 (RT-11; english)
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html" 4402-} {strength may}}
4402-P3P: {{SRY-PROP XYZ 303 Proposal Rejected}}
</PRE>
<P>
The service looks at the refusal, and offers an alternative proposal.
<PRE>HTTP/1.1 400 Agreement required
Server: Marvin/2.0.1
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html" 42-} {strength must}}
42-P3P: {{PROP [proposal with hash PDQ]} {RFD [data request}}
Content-Type: text/html
Content-Length: 70

&lt;html&gt;&lt;body&gt;
&lt;h1&gt;HTTP/1.1 400 Agreement Required&lt;/h1&gt;
&lt;/body&gt;&lt;/html&gt;
</PRE>
<P>
  <HR WIDTH="40%">
<P>
If the user agent finds this alternative proposal acceptable, it accepts
it:
<PRE>GET /Index.html HTTP/1.1
Accept: */*
User-Agent: BugblatterBeast/3.02 (RT-11; english)
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html" 52294-} {strength may}}
52294-P3P: {{OK-PROP PDQ} {TXD [data transfer with hash ABC]}
</PRE>
<P>
The user agent has now made a new request that indicates that it agrees to
the previous proposal. The service finds this acceptable, and sends the object.
<PRE>HTTP/1.1 200 OK
Server: Marvin/2.0.1
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html" 62090-} {strength must}}
62090-P3P: {{OK-TXD ABC}}
Content-type: text/html
Content-length: ...

...body...
</PRE>
<P>
  <HR WIDTH="40%">
<P>
On the other hand, if the user agent finds this alternative proposal
unacceptable, it can refuse the proposal and demand an end to negotiation:
<PRE>GET /Index.html HTTP/1.1
Accept: */*
User-Agent: BugblatterBeast/3.02 (RT-11; english)
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html" 31567-} {strength must}}
31567-P3P: {{SRY-PROP PDQ 303 Proposal Rejected} {STOP}}
</PRE>
<P>
The user agent has now made a new request, refusing the alternative proposal,
and indicating that it is unwilling to continue negotiating. The service
can now send a non-personalized version of the requested object - or whatever
it chooses to send if it cannot get information from the user agent.
<PRE>HTTP/1.1 200 OK
Server: Marvin/2.0.1
Content-type: text/html
Content-length: ...

...non-personalized body (or an error message!)...
</PRE>
<H4>
  <A NAME="BM_2B_Lineflows">4.2.B Lineflows</A> (negotiation, user agent provides
  a counter proposal):
</H4>
<PRE>GET /Index.html HTTP/1.1
Accept: */*
User-Agent: FerengiNegotiatingAgent/11.6.1 (Starfleet-OS/2.07; vulcan)
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html"} {strength must}}
</PRE>
<P>
The user agent has requested a Web page, and indicates that it supports the
P3P protocol.
<PRE>HTTP/1.1 400 Agreement required
Server: Romulan-Systemwide/1.2.1Beta6
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html" 43-} {strength must}}
43-P3P: {{PROP [proposal with hash XYZ]} {RFD [data request}}
Content-Type: text/html
Content-Length: 107

&lt;html&gt;&lt;body&gt;
&lt;h1&gt;HTTP/1.1 400 Agreement Required&lt;/h1&gt;
&lt;p&gt;Agree to this! We demand it!&lt;/p&gt;
&lt;/body&gt;&lt;/html&gt;
</PRE>
<P>
The user agent looks at the proposal, decides it is not acceptable, and refuses
it. It also includes a counter proposal.
<PRE>GET /Index.html HTTP/1.1
Accept: */*
User-Agent: FerengiNegotiatingAgent/11.6.1 (Starfleet-OS/2.07; vulcan)
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html" 1701-} {strength must}}
1701-P3P: {{SRY-PROP XYZ 303 Proposal Rejected} {PROP [proposal with hash DEF]}}
</PRE>
<P>
The service looks at the refusal and the counter proposal, and, if it is
acceptable, it accepts that counter proposal.
<PRE>HTTP/1.1 400 Data Required
Server: Romulan-Systemwide/1.2.1Beta6
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html" 1412-} {strength must}}
1412-P3P: {{OK-PROP DEF} {RFD [data request]}}
</PRE>
<P>
The user now requests the document again, and sends the requested information:
<PRE>GET /Index.html HTTP/1.1
Accept: */*
User-Agent: FerengiNegotiatingAgent/11.6.1 (Starfleet-OS/2.07; vulcan)
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html" 4601-} {strength must}}
4601-P3P: {{TXD [data transfer with hash ABC]}
</PRE>
<P>
The user agent has now made a new request that sends the information the
service needs. The service can now send the requested object:
<PRE>HTTP/1.1 200 OK
Server: Romulan-Systemwide/1.2.1Beta6
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html" 1414-} {strength must}}
1414-P3P: {{OK-TXD ABC}}
Content-type: text/html
Content-length: ...

...body...
</PRE>
<P>
On the other hand, if the service does not find this counter proposal acceptable,
and does not wish to continue negotiating, it can refuse the counter proposal
and not offer any alternatives. It may send an error message, or it may send
a non-personalized version of the requested object. Here we show sending
an error message:
<PRE>HTTP/1.1 400 Agreement Required
Server: Romulan-Systemwide/1.2.1Beta6
PEP: {{map "http://www.w3.org/P3P/PEP/V1_0.html" 47819-} {strength DEF}}
47819-P3P: {{SRY-PROP DEF 303 Proposal Rejected} {STOP})
</PRE>
<P>
At this point the conversation is ended.
<H3>
  4.3 <A NAME="Exceptional_Lines_Flows">Exceptional Lines-Flows</A>
</H3>
<P>
All of our scenarios begin with the same action from the user, the request
to follow a link that leads to the URL http://www.sales.com/Index.html. This
causes the user agent to issue the HTTP request:
<PRE>GET /Index.html HTTP/1.1
Accept: */*
User-Agent: BugblatterBeast/3.02 (RT-11; english)
</PRE>
<H4>
  4.3. A<A NAME="No_Pre_Existing_Agreement_Without_Digita">No Pre-Existing
  Agreement Without Digital Signatures</A>
</H4>
<P>
This case is the one we <A HREF="#Most Common Case">assume</A> to be the
most common: that the <EM>site has practices that are acceptable to the
user</EM>, and includes a proposal to apply those practices whenever it requests
the transmission of data from the user.&nbsp; This is why an
<A HREF="#Request for Data (RFD)">RFD</A> message can include a proposal
(or an agreement).&nbsp; In our case, we assume the service <EM>does not
have access to an agreement</EM> previously made with this user.&nbsp; This
happens when a service wants data from the user:
<UL>
  <LI>
    on their first visit
  <LI>
    when a user has not yet identified themself
  <LI>
    when a service's policy changes
  <LI>
    if the service does not store previously negotiated agreements, or
  <LI>
    the service is configured to always offer a standard proposal
</UL>
<P>
We first show the sequence of messages that occur when no digital signatures
are used (hence the agreement might be repudiated by either side) .
<PRE>HTTP/1.1 417 Request For Data
Server: Marvin/2.0.1
Protocol-Request: {W3C-P3P {P3P-Proposal P3P-RFD}}
P3P-Proposal: ...content of proposal... [note: fingerprint is XYZ]
P3P-RFD: ...list of data elements requested...

GET /Index.html HTTP/1.1
Accept: */*
User-Agent: BugblatterBeast/3.02 (RT-11; english)
Protocol-Request: {W3C-P3P {PDP-OK P3P-TXD}}
P3P-OK: XYZ [note: in this case, the fingerprint is the agreement]
P3P-TXD: ...data elements as requested...
</PRE>
<P>
At this point, the server responds as a current server would have responded
to the original request, by supplying the contents of the request page:
<PRE>HTTP/1.1 200 OK
Server: Marvin/2.0.1
Protocol-Request: {W3C-P3P {P3P-OK}}
P3P-OK: XYZ

Text of the page requested
</PRE>
<H4>
  4.3.B <A NAME="No_Pre_Existing_Agreement_With_Digital_S">No Pre-Existing
  Agreement With Digital Signatures</A>
</H4>
<P>
We now consider the same sequence of messages generated when both the client
and the service choose to sign the agreement, providing non-repudiable evidence
for both sides that an agreement has been concluded.&nbsp; Either side can
retain&nbsp; the agreement ("CDQ plus RDF signature (by client) of CDQ")
plus the Signed Proposal ("content of proposal plus RDF signature on it (by
assuring party) [note: fingerprint is CDQ]") as non-repudiable evidence of
the agreement.&nbsp; The service can, additionally, store the Signed Proposal
for some period of time so that it can be retrieved by a client that wishes
to review the text of the proposal before actually transmitting the data.
<PRE>HTTP/1.1 417 Request For Data
Server: Marvin/2.0.1
Protocol-Request: {W3C-P3P {P3P-Proposal P3P-RFD}}
P3P-Proposal: content of proposal plus RDF signature on it (by assuring party)
              [note: fingerprint is CDQ]
P3P-RFD: ...list of data elements requested...
GET /Index.html HTTP/1.1
Accept: */*
User-Agent: BugblatterBeast/3.02 (RT-11; english)
Protocol-Request: {W3C-P3P {PDP-OK P3P-TXD}}
P3P-OK: CDQ plus RDF signature (by client) of CDQ
P3P-TXD: ...data elements as requested...
HTTP/1.1 200 OK
Server: Marvin/2.0.1
Protocol-Request: {W3C-P3P {P3P-OK}}
P3P-OK: CDQ plus RDF signature (by client) of CDQ
Text of the page requested
</PRE>
<P>
The above sequence of messages can be altered slightly to handle another
common case: when the service knows the identity of the user and has access
to a previously concluded agreement, the same messages will suffice if the
agreement replaces the proposal in the RFD message above.
<H4>
  4.3.C <A NAME="Service_Requests_Data_Without_Proposal">Service Requests Data
  Without Proposal</A>
</H4>
<P>
If a service requests data without a proposal the user-agent has several
options: 1) walk away from the transaction, 2) accept the proposal as-is
(perhaps after prompting for user intervention), or 3) make a counter-proposal.
These options are described as follows:
<OL>
  <LI>
    If the user-agent wishes to walk away, we are done. No further communication
    is required.
  <LI>
    If the user-agent wishes to accept the proposal, it could send a request
    like the following:<BR>
    <TT>GET /Index.htm</TT>l HTTP/1.1<BR>
    Accept: */*<BR>
    User-Agent: BugblatterBeast/3.02 (RT-11; english)<BR>
    Protocol-Request: {W3C-P3P {P3P-Agreement}}<BR>
    P3P-Agreement: ...I agree to proposal #XYZ...<BR>
    <BR>
    Assuming that the service is still interested in accepting that proposal,
    it would respond with:<BR>
    HTTP/1.1 200 OK<BR>
    Server: Marvin/2.0.1<BR>
    Protocol-Request: {W3C-P3P {P3P-Agreement}}<BR>
    P3P-Agreement: ...the agreement that the user-agent sent...<BR>
    <BR>
    In this scheme, the user-agent has sent the proposal that it finds acceptable,
    and the service has returned it verbatim, indicating that it also agrees.
  <LI>
    If the user-agent wishes to make a counteroffer, the counteroffer follows
    the same form as accepting the proposal, but with a twist: the agreement
    is not to proposal XYZ that the service originally proposed, but rather to
    some variant of XYZ - call it XYZ1. In other words, the user-agent's request
    looks like:<BR>
    GET /Index.html HTTP/1.0<BR>
    Accept: */*<BR>
    User-Agent: BugblatterBeast/3.02 (RT-11; english)<BR>
    Protocol-Request: {W3C-P3P {P3P-Agreement P3P-Proposal}}<BR>
    P3P-Proposal: ...content of proposal #XYZ1...<BR>
    P3P-Agreement: ...I agree to proposal #XYZ1...<BR>
    <BR>
    The service then has three options: A) refuse the user-agent's counter-proposal,
    B) accept the counter-proposal as-is, or C) offer yet another counter-proposal.
    <OL TYPE="A">
      <LI>
	For a service to "walk away", it can simply repeat its original proposal.
      <LI>
	For a service to accept the counter-proposal, behaves as in scenario 2) above:
	send the response, including the agreement that the user-agent sent. The
	service and user-agent have now exchanged an agreement, and they can now
	operate under the terms of that agreement.
      <LI>
	For a service to offer yet another counter-proposal, we jump back to the
	second step of this negotiation: the service returns a 416 Agreement Required
	response, and offers a new proposal.
    </OL>
</OL>
<H2>
  5 <A NAME="Syntax_of_P3P_Negotiation_Primitives_and">Syntax of P3P Negotiation
  Primitives</A>
</H2>
<P>
The syntax of P3P negotiation primitives is provided below. See
<A HREF="#notation">notation</A> for a brief description of
<A HREF="http://info.internet.isi.edu/in-notes/rfc/files/rfc2234.txt">RFC2234</A>
ABNF.
<TABLE CELLSPACING="0" BORDER="0" CELLPADDING="0" WIDTH="100%">
  <TR>
    <TD WIDTH="3%" VALIGN="TOP" BGCOLOR="#F5DCB3"><P ALIGN="RIGHT">
      [1]</TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><CODE></CODE>
      <P ALIGN="RIGHT">
      p3p-request</TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><CODE></CODE>
      <P ALIGN="RIGHT">
      :=</TD>
    <TD VALIGN="MIDDLE" BGCOLOR="#F5DCB3"><CODE>start-line<BR>
      *m</CODE>essage-header<BR>
      "OPT" ":" p3p-opt-header<BR>
      [p3p-header-prefix "P3P" ":" p3p-header CRLF]<BR>
      [ messag<CODE>e-body ]</CODE>
      <P>
      /* start-line, message-header, CRLF, and <BR>
      message-body are as defined in the <BR>
      HTTP 1.1 specification [HTTP1.1]. */</TD>
  </TR>
</TABLE>
<P>
The user agent communicates to the server using standard methods such as
"GET" or "POST". When placing an initial request to the server, the P3P PEP
header is included to notify the server that the user agent is
P3P-compliant.<BR>
<BR>
The server sets status code 400 for responses other than OK-*, which provides
status 200.
<TABLE CELLSPACING="0" BORDER="0" CELLPADDING="0" WIDTH="100%">
  <TR>
    <TD WIDTH="3%" VALIGN="TOP" BGCOLOR="#F5DCB3">[2]</TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>p3p-opt-header
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>p3p-extension ";" "ns-" p3p-header-prefix
</PRE>
    </TD>
  </TR>
  <TR>
    <TD WIDTH="3%" VALIGN="TOP" BGCOLOR="#F5DCB3">[3]</TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>p3p-extension
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>&lt;"&gt; http://www.w3.org/TR/1998/REC-P3P10-1998xxxx/ &lt;"&gt;
</PRE>
    </TD>
  </TR>
  <TR>
    <TD WIDTH="3%" VALIGN="TOP" BGCOLOR="#F5DCB3">[4]</TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>p3p-header-prefix
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>1*digit "-"
</PRE>
    </TD>
  </TR>
  <TR>
    <TD WIDTH="3%" VALIGN="TOP" BGCOLOR="#F5DCB3">[5]</TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>p3p-header
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>"{" p3p-message+ "}" qualifier*
</PRE>
    </TD>
  </TR>
  <TR>
    <TD WIDTH="3%" VALIGN="TOP" BGCOLOR="#F5DCB3">[6]</TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>qualifier
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>"FINAL" | token
</PRE>
    </TD>
  </TR>
  <TR>
    <TD WIDTH="3%" VALIGN="TOP" BGCOLOR="#F5DCB3">[7]</TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>p3p-message
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>"{" p3p-content "}"
</PRE>
    </TD>
  </TR>
  <TR>
    <TD WIDTH="3%" VALIGN="TOP" BGCOLOR="#F5DCB3">[8]</TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>p3p-content
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>OK-PROP-msg |
OK-TXD-msg |
PROP-msg |
RFD-msg |
RFP-msg |
RFT-msg |
SRY-PROP-msg |
SRY-RFD-msg |
SRY-RFP-msg |
SRY-RFT-msg |
SRY-TXD-msg |
STOP-msg |
TXD-msg
</PRE>
    </TD>
  </TR>
  <TR>
    <TD WIDTH="3%" VALIGN="TOP" BGCOLOR="#F5DCB3">[9]</TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>OK-PROP-msg
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>"OK-PROP" fingerprint [sigblock]
</PRE>
    </TD>
  </TR>
  <TR>
    <TD WIDTH="3%" VALIGN="TOP" BGCOLOR="#F5DCB3">[10]</TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>OK-TXD-msg
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>"OK-TXD" fingerprint
</PRE>
    </TD>
  </TR>
  <TR>
    <TD WIDTH="3%" VALIGN="TOP" BGCOLOR="#F5DCB3">[11]</TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>PROP-msg
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>"PROP" 1*(proposal [sigblock] [fingerprint)
</PRE>
    </TD>
  </TR>
  <TR>
    <TD WIDTH="3%" VALIGN="TOP" BGCOLOR="#F5DCB3">[12]</TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>RFD-msg
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>"RFD" fingerprint data-request
</PRE>
    </TD>
  </TR>
  <TR>
    <TD WIDTH="3%" VALIGN="TOP" BGCOLOR="#F5DCB3">[13]</TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>RFP-msg
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>"RFP" realm
</PRE>
    </TD>
  </TR>
  <TR>
    <TD WIDTH="3%" VALIGN="TOP" BGCOLOR="#F5DCB3">[14]</TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>RFT-msg
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>"RFT" fingerprint
</PRE>
    </TD>
  </TR>
  <TR>
    <TD WIDTH="3%" VALIGN="TOP" BGCOLOR="#F5DCB3">[15]</TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>SRY-PROP-msg
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>"SRY-PROP" fingerprint reason-code
</PRE>
    </TD>
  </TR>
  <TR>
    <TD WIDTH="3%" VALIGN="TOP" BGCOLOR="#F5DCB3">[16]</TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>SRY-RFD-msg
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>"SRY-RFD" agreement reason-code
</PRE>
    </TD>
  </TR>
  <TR>
    <TD WIDTH="3%" VALIGN="TOP" BGCOLOR="#F5DCB3">[17]</TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>SRY-RFP-msg
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>"SRY-RFP" reason-code
</PRE>
    </TD>
  </TR>
  <TR>
    <TD WIDTH="3%" VALIGN="TOP" BGCOLOR="#F5DCB3">[18]</TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>SRY-RFT-msg
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>"SRY-RFT" fingerprint reason-code
</PRE>
    </TD>
  </TR>
  <TR>
    <TD WIDTH="3%" VALIGN="TOP" BGCOLOR="#F5DCB3">[19]</TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>SRY-TXD-msg
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>"SRY-TXD" fingerprint reason-code
</PRE>
    </TD>
  </TR>
  <TR>
    <TD WIDTH="3%" VALIGN="TOP" BGCOLOR="#F5DCB3">[20]</TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>STOP-msg
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>"STOP"
</PRE>
    </TD>
  </TR>
  <TR>
    <TD WIDTH="3%" VALIGN="TOP" BGCOLOR="#F5DCB3">[21]</TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>TXD-msg
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>"TXD" fingerprint data-xfer
</PRE>
    </TD>
  </TR>
  <TR>
    <TD WIDTH="3%" VALIGN="TOP" BGCOLOR="#F5DCB3">[22]</TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>proposal
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>/* see <A HREF="#proposal">proposal</A> BNF */
</PRE>
    </TD>
  </TR>
  <TR>
    <TD WIDTH="3%" VALIGN="TOP" BGCOLOR="#F5DCB3">[23]</TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>data-xfer
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>/* RDF format data element name-value pairs */
</PRE>
    </TD>
  </TR>
  <TR>
    <TD WIDTH="3%" VALIGN="TOP" BGCOLOR="#F5DCB3">[24]</TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>data-request
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>/* (fingerprint)* and RDF format
   list of data-elements or sets */
</PRE>
    </TD>
  </TR>
  <TR>
    <TD WIDTH="3%" VALIGN="TOP" BGCOLOR="#F5DCB3">[25]</TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>fingerprint
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>/* hash of proposal or data-xfer */
   The hash protocol is an MD5 digest
   in US-ASCII characters using MIME
   base-64 encoding.
</PRE>
    </TD>
  </TR>
  <TR>
    <TD WIDTH="3%" VALIGN="TOP" BGCOLOR="#F5DCB3">[26]</TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>sigblock
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>/* as per [DSIG] */
</PRE>
    </TD>
  </TR>
  <TR>
    <TD WIDTH="3%" VALIGN="TOP" BGCOLOR="#F5DCB3">[27]</TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>FINAL
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="top" BGCOLOR="#F5DCB3"><PRE>/* The "FINAL" qualifier indicates that the
   set  of proposals represent final offers
   and no alternative offers will be made if
   they are all rejected. */
</PRE>
    </TD>
  </TR>
</TABLE>
<P>
The reason codes are as follows
<TABLE CELLSPACING="0" BORDER="0" CELLPADDING="0" WIDTH="100%">
  <TR>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><P ALIGN="RIGHT">
      [28]</TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE><A NAME="reason_codes">reason code</A>
</PRE>
    </TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="MIDDLE" BGCOLOR="#F5DCB3"><PRE>/* 3xx Rejection Codes*/

"301 Unrecognized Agreement" |	/*(SRY-RFD, SRY-RFT, SRY-TXD)*/
"302 Agreement Expired" |	/*(SRY-RFD, SRY-RFT, SRY-TXD)*/
"303 Proposal Rejected" |	/*(SRY-PROP)*/
"305 Data unavailable" |	/*(SRY-RFD)*/
"306 Text unavailable" |	/*(SRY-RFT)*/
"307 Agreement Recinded" |	/*(SRY-RFD, SRY-RFT)*/
"308 RFP Rejected" |		/*(SRY-RFP)*/
"309 Data not accepted" |	/*(SRY-RFD, SRY-RFT, SRY-TXD)*/

/* 4xx Error Codes */

"401 Invalid Format" |		/*(ALL)*/
"402 Data transfer unsuccessful" | /*(SRY-TXD)*/
"403 Invalid Signature" |	/*(SRY-PROP)*/
</PRE>
      <P>
      &nbsp;</TD>
  </TR>
</TABLE>
<H2>
  6 <A NAME="Syntax_of_P3P_Schemas">Syntax of P3P Schemas</A>
</H2>
<P>
The following schema syntaxes should be used to create well formed (signed)
RDF declarations. An example encoding has been created as part of the
<A HREF="http://www.w3.org/P3P/Group/Harmonization/Drafts/P3P-harmonization-encoding-980204.html">Harmonization
Encoding</A> work. The <A HREF="http://www.w3.org/RDF/Group/SchemaCharter">RDF
Schema Working Group</A> will further define the method for specifying RDF
schema. The following is in simple BNF, it will have to be modified appropriately
so that:
<OL>
  <LI>
    The proper representation are made in accordance with the RDF Schema Model.
    The BNF will have to be extended such that the proper RDF
    <A HREF="http://www.w3.org/TR/REC-xml#dt-element">elements</A>
    ("&lt;RDF&gt;...&lt;/RDF&gt;") can be constructed.
  <LI>
    Currently, the HTTP BNF generates valid PEP headers as of ~ October-98. The
    Syntax editors will have to coordinate with a HTTP activity lead to ensure
    that the HTTP extension mechanisms are appropriate.
</OL>
<TABLE CELLSPACING="0" BORDER="0" CELLPADDING="0" WIDTH="100%">
  <TR>
    <TD VALIGN="top" BGCOLOR="#C0C0C0"><STRONG>Consensus Note</STRONG>: Much
      of the work done on the schema beyond the the proposal (which was defined
      first in the <A href="http://www.w3.org/TR/WD-P3P-grammar.html">P3P&nbsp;
      Grammar Working Draft</A>) was conducted under signficant time pressure.
      Accordingly, a number of these schema may need to be revisited in the future
      by the W3C or other entities as appropriate. Issues encountered in the creation
      of the following schema are documented accordingly:
      <UL>
	<LI>
	  <STRONG>proposal:
	  </STRONG><A href="http://www.w3.org/TR/WD-P3P-grammar.html">Grammar Working
	  Draft</A>, this document, and the
	  <A href="http://www.w3.org/P3P/Group/Harmonization/">Harmonized Vocabulary
	  WG's</A> final draft
	<LI>
	  <STRONG>disclosure and categories:
	  </STRONG><A href="http://www.w3.org/P3P/Group/Harmonization/">Harmonized
	  Vocabulary WG's</A> final draft
	<LI>
	  <STRONG>base data elements</STRONG>: this document
      </UL>
    </TD>
  </TR>
</TABLE>
<H3>
  6.1 <A NAME="Syntax_of_P3P_Proposal">Syntax of P3P Proposal</A>
</H3>
<TABLE CELLSPACING="0" BORDER="0" CELLPADDING="0" WIDTH="100%">
  <TR>
    <TD VALIGN="TOP" COLSPAN="4" BGCOLOR="#F5DCB3"><STRONG>Schema &lt;?namespace
      href="http://www.w3.org/TR/1998/REC-P3P10-1998xxxx/P3Pproposal1.0#"
      as="proposal"?&gt; <BR>
      Status: Required</STRONG></TD>
  </TR>
  <TR>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><P ALIGN="RIGHT">
      [1]</TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE><A NAME="proposal">proposal</A>
</PRE>
    </TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="MIDDLE" BGCOLOR="#F5DCB3"><PRE>"in" proposal_schema
"for" experience-space
entity "will"
1*p3p-statement
"assured_by" assurance
</PRE>
      <PRE>/* Where "'in' proposal_schema" defines the semantics
   over all the schema used in P3P1.0 including the
   ones in the core schemea "proposal":
   purpose, purpose_qualifier, identifiable,
   domain_of_use data_set, data_qualifier,
   data_required, and access
*/
</PRE>
    </TD>
  </TR>
  <TR>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><P ALIGN="RIGHT">
      [2]</TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE>experience-space
</PRE>
    </TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="MIDDLE" BGCOLOR="#F5DCB3"><PRE>/* RDF/XML-experience-space or a
   URL */
</PRE>
    </TD>
  </TR>
  <TR>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><P ALIGN="RIGHT">
      [3]</TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE>assurance
</PRE>
    </TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="MIDDLE" BGCOLOR="#F5DCB3"><PRE>quoted-string :: '"' UTF-7 '"' /*URI:HTML:XML:BASE64 */
</PRE>
    </TD>
  </TR>
  <TR>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><P ALIGN="RIGHT">
      [4]</TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE>entity
</PRE>
    </TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="MIDDLE" BGCOLOR="#F5DCB3"><PRE>quoted-string :: '"' UTF-7 '"'
</PRE>
    </TD>
  </TR>
  <TR>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><P ALIGN="RIGHT">
      [5]</TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE>p3p-statement
</PRE>
    </TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="MIDDLE" BGCOLOR="#F5DCB3"><PRE>"for" experience-space
( (1*purpose)(1*purpose-qualifier)
"will apply to" (*<A HREF="#data-set">data-set</A> *<A HREF="#data-category">data-category</A> data-required)
"with" consequence
"see general disclosures at" [<A HREF="#disclosure">disclosure</A>] URL
</PRE>
    </TD>
  </TR>
  <TR>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><P ALIGN="RIGHT">
      [6]</TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE>purpose
</PRE>
    </TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="MIDDLE" BGCOLOR="#F5DCB3"><PRE>("0" | "Completion and Support of Current Activity") |
("1" | "Web Site and System Administration") |
("2" | "Customization of the Site to Individuals") |
("3" | "Research and Development") |
("4" | "Contacting Visitors for Marketing of
        Services or Products") |
("5" | ("Other Uses" quoted-string))
</PRE>
    </TD>
  </TR>
  <TR>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><P ALIGN="RIGHT">
      [7]</TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE>consequence
</PRE>
    </TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="MIDDLE" BGCOLOR="#F5DCB3"><PRE>quoted-string
</PRE>
    </TD>
  </TR>
  <TR>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><P ALIGN="RIGHT">
      [8]</TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE>purpose-qualifier
</PRE>
    </TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="MIDDLE" BGCOLOR="#F5DCB3"><PRE>identifiable domain-of-use [access]
</PRE>
    </TD>
  </TR>
  <TR>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><P ALIGN="RIGHT">
      [9]</TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE>identifiable
</PRE>
    </TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="MIDDLE" BGCOLOR="#F5DCB3"><PRE>"("0" | "no") | ("1" | "yes")
</PRE>
    </TD>
  </TR>
  <TR>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><P ALIGN="RIGHT">
      [10]</TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE>domain-of-use
</PRE>
    </TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="MIDDLE" BGCOLOR="#F5DCB3"><PRE>("0" | "only ourselves and our agents") |
("1" | "organizations following our practices") |
("2" | "organizations following different practices") |
("3" | "unrelated third parties or public fora")
</PRE>
    </TD>
  </TR>
  <TR>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><P ALIGN="RIGHT">
      [11]</TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE>data-set
</PRE>
    </TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="MIDDLE" BGCOLOR="#F5DCB3"><PRE>/* Paul and Philip have a list, also, it may make
   sense to just make this the data-request */
</PRE>
    </TD>
  </TR>
  <TR>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><P ALIGN="RIGHT">
      [12]</TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE>data-qualifier
</PRE>
    </TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="MIDDLE" BGCOLOR="#F5DCB3"><PRE>data-required
</PRE>
    </TD>
  </TR>
  <TR>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><P ALIGN="RIGHT">
      [13]</TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE>data-required
</PRE>
    </TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="MIDDLE" BGCOLOR="#F5DCB3"><PRE>("0" | "no") | ("1" | "yes") /* default yes */
</PRE>
    </TD>
  </TR>
  <TR>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><P ALIGN="RIGHT">
      [14]</TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE>quoted-string
</PRE>
    </TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="MIDDLE" BGCOLOR="#F5DCB3"><PRE>'"' UTF-7 '"'
</PRE>
    </TD>
  </TR>
  <TR>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><P ALIGN="RIGHT">
      [15]</TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE>URL
</PRE>
    </TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="MIDDLE" BGCOLOR="#F5DCB3"><PRE>/* as defined in RFC-1738 */
</PRE>
    </TD>
  </TR>
  <TR>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"></TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3">/* the following may be optional */</TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"></TD>
    <TD VALIGN="MIDDLE" BGCOLOR="#F5DCB3"></TD>
  </TR>
  <TR>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><P ALIGN="RIGHT">
      [16]</TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE>access
</PRE>
    </TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE>=
</PRE>
    </TD>
    <TD VALIGN="MIDDLE" BGCOLOR="#F5DCB3"><PRE>("0" | "no") | ("1" | "yes")
</PRE>
    </TD>
  </TR>
  <TR>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"></TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"></TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"></TD>
    <TD VALIGN="MIDDLE" BGCOLOR="#F5DCB3"></TD>
  </TR>
</TABLE>
<H3>
  6.2 <A NAME="Syntax_of_Disclosures">Syntax of Disclosures</A>
</H3>
<TABLE CELLSPACING="0" BORDER="0" CELLPADDING="0" WIDTH="100%">
  <TR>
    <TD VALIGN="TOP" COLSPAN="4" BGCOLOR="#F5DCB3"><STRONG>Schema &lt;?namespace
      href="hhttp://www.w3.org/TR/1998/REC-P3P10-1998xxxx/P3Pdisclosure1.0#"
      as="disclosure"?&gt; <BR>
      Status: Optional</STRONG></TD>
  </TR>
  <TR>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3" align="right">[1]</TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE><A NAME="disclosure">disclosure</A>
</PRE>
    </TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3">=</TD>
    <TD VALIGN="MIDDLE" BGCOLOR="#F5DCB3"><PRE>access-disclosure assurance-disclosure [other-disclosure]
</PRE>
    </TD>
  </TR>
  <TR>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3" align="right">[2]</TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE>access-disclosure
</PRE>
    </TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3">=</TD>
    <TD VALIGN="MIDDLE" BGCOLOR="#F5DCB3"><PRE>("0" | "Identifiable Data is Not Used") |
("1" | "Identifiable Contact Information") |
("2" | "Other Identifiable Information") |
("3" | "None")
</PRE>
    </TD>
  </TR>
  <TR>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3" align="right">[3]</TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE>assurance-disclosure
</PRE>
    </TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"></TD>
    <TD VALIGN="MIDDLE" BGCOLOR="#F5DCB3"><PRE>"("0" | "no") | ("1" | "yes")
</PRE>
    </TD>
  </TR>
  <TR>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3" align="right"><P ALIGN="RIGHT">
      [4]</TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE>other-disclosure
</PRE>
    </TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><DIV align="center">
	<CENTER>
	  <PRE>=
</PRE>
	</CENTER>
      </DIV>
    </TD>
    <TD VALIGN="MIDDLE" BGCOLOR="#F5DCB3"><PRE>[("0" | "change_agreement")] | [("1" | "retention")]
</PRE>
    </TD>
  </TR>
</TABLE>
<H3>
  6.3 <A NAME="Syntax_of_Categories">Syntax of Categories</A>
</H3>
<TABLE CELLSPACING="0" BORDER="0" CELLPADDING="0" WIDTH="100%">
  <TR>
    <TD VALIGN="TOP" COLSPAN="4" BGCOLOR="#F5DCB3"><STRONG>Schema &lt;?namespace
      href="http://www.w3.org/TR/1998/REC-P3P10-1998xxxx/P3Pcategories1.0#"
      as="categories"?&gt; <BR>
      Status: Optional</STRONG></TD>
  </TR>
  <TR>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><P ALIGN="RIGHT">
      [1]</TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE>data-category
</PRE>
    </TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><DIV align="center">
	<CENTER>
	  <PRE>=
</PRE>
	</CENTER>
      </DIV>
    </TD>
    <TD VALIGN="MIDDLE" BGCOLOR="#F5DCB3"><UL>
	<LI>
	  <PRE>("0" | "Physical Contact Information") |
("1" | "Online Contact Information") |
("2" | "Unique Identifiers") |
("3" | "Financial Account Identifiers") |
("4" | "Computer Information") |
("5" | "Navigation and Click-stream Data") |
("6" | "Transaction Data") |
("7" | "Preference Data") |
("8" | "Demographic and SocioEconomic Data") |
("8" | "Content")
</PRE>
      </UL>
    </TD>
  </TR>
</TABLE>
<H3>
  6.4 <A NAME="Syntax_of_Data_Set">Syntax of Data Set</A>
</H3>
<TABLE CELLSPACING="0" BORDER="0" CELLPADDING="0" WIDTH="100%">
  <TR>
    <TD VALIGN="TOP" COLSPAN="4" BGCOLOR="#F5DCB3"><STRONG>Schema &lt;?namespace
      href="http://www.w3.org/TR/1998/REC-P3P10-1998xxxx/P3Pelements1.0#"
      as="dataset"?&gt; <BR>
      Status: Required</STRONG></TD>
  </TR>
  <TR>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><P ALIGN="RIGHT">
      [1]</TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><PRE><A NAME="data_set">data-set</A>
</PRE>
    </TD>
    <TD VALIGN="TOP" BGCOLOR="#F5DCB3"><DIV align="center">
	<CENTER>
	  <PRE>=
</PRE>
	</CENTER>
      </DIV>
    </TD>
    <TD VALIGN="MIDDLE" BGCOLOR="#F5DCB3"><PRE>1*(/*one of the following*/)
</PRE>
    </TD>
  </TR>
</TABLE>
<H4>
  Required (standard) Data Elements and Categories
</H4>
<P>
The following are the standard data elements and sets. These data elements
and sets may not be modified or deleted by either the service or the user
agent
<TABLE CELLSPACING="0" BORDER="0" CELLPADDING="0" WIDTH="100%">
  <TR>
    <TD VALIGN="top" BGCOLOR="#C0C0C0"><STRONG>Consensus Note</STRONG>: When
      the group was confronted with the issue of which base data elements to include
      in the specification, two issues made the development of the data element
      set difficult:
      <OL>
	<LI>
	  Would the inclusion of a data element be seen as a representation from the
	  WG that requests for that element are "endorsed"? For instance, including
	  a SSN as a named data elements raises significant privacy concerns (sites
	  will be able to ask for it) but does provide two two goods things with respect
	  to privacy:
	  <OL>
	    <LI>
	      By not making a statement about an element, it is explicit that a site is
	      in fact not doing anything over that element. For things like click_stream,
	      this is a useful representation for a site to make
	    <LI>
	      By creating an element, the user will be able to express their preferences
	      over that element right away. So for instance, a user can say, "never give
	      user.SSN out, ever."
	  </OL>
	<LI>
	  The group agreed that data elements could have a number of useful functions.
	  For instance, the user.P3Ppreferences element could be the mechanism by which
	  a site informs a search site of preferences regarding the type of sites it
	  will want returned. System data elements could also be used to communicate
	  system capabilities such as resolution, CPU, the number of display colors,
	  or the security characteristics of the protocol P3P runs atop of. However,
	  there is a question as to whether P3P data elements are the right place for
	  the transport of such data.
	  <OL>
	    <LI>
	      Such parameters might be opaque to P3P implementations -- such as the security
	      of underlying protocols.
	    <LI>
	      Presentation issues should be part of content negotiation in HTTP headers
	      and visible to proxies, or all of this should be left to style sheets.
	  </OL>
	  <P>
	  The general issue is how much knowledge should P3P have about the parameters
	  of other protocols or applications? Should users be able to express preferences
	  over those parameters, and how is this accomplished? An extensive set of
	  such system elements is provided in a
	  <A href="http://www.w3.org/P3P/Group/Protocols/WD-P3P-Protocols-980303.html#Syntax_of_Data_Set">previous
	  draft</A> and are based on
	  <A href="http://www.w3.org/TR/NOTE-agent-attributes">http://www.w3.org/TR/NOTE-agent-attributes</A>
	  .
      </OL>
      <P>
      The group was not able to definitevely resolve either of these questions.
      With respect to the first question, we can state that <EM>the inclusion of
      an element does not mean sites should not exercise caution when asking for
      data.</EM> Some things, like session_ID and site_ID, are common and important
      enough that we did name them and place them under user control. However,
      we shyed away from including race, religious or health elements in the core
      set. With respect to the second question, we define a system schema, but
      include few elements.
      <P>
      The issue of which elements are in the P3P base set may require future W3C
      work, the P3P set is indepedently extensible regardless.</TD>
  </TR>
</TABLE>
<P>
&nbsp;
<TABLE border="1" cellPadding="2" cellSpacing="1" width="100%">
  <TR>
    <TD vAlign="top"><B>#User</B></TD>
    <TD vAlign="top"><B>Category</B></TD>
    <TD vAlign="top"><B>Type</B></TD>
    <TD vAlign="top"><B>Short display name</B></TD>
  </TR>
  <TR>
    <TD vAlign="top">User.Name.Prefix</TD>
    <TD vAlign="top">Demographic</TD>
    <TD vAlign="top">Text</TD>
    <TD vAlign="top">Name Prefix</TD>
  </TR>
  <TR>
    <TD vAlign="top">User.Name.First</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD vAlign="top">Text&nbsp;</TD>
    <TD vAlign="top">First Name</TD>
  </TR>
  <TR>
    <TD vAlign="top">User.Name.Last</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD vAlign="top">Text&nbsp;</TD>
    <TD vAlign="top">Last Name</TD>
  </TR>
  <TR>
    <TD vAlign="top">User.Name.Middle</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD vAlign="top">Text&nbsp;</TD>
    <TD vAlign="top">Middle Name</TD>
  </TR>
  <TR>
    <TD vAlign="top">User.Name.Suffix</TD>
    <TD vAlign="top">Demographic</TD>
    <TD vAlign="top">Text</TD>
    <TD vAlign="top">Name Suffix</TD>
  </TR>
  <TR>
    <TD >User.Photo</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD >graphic</TD>
    <TD >User Photograph</TD>
  </TR>
  <TR>
    <TD >User.Bdate</TD>
    <TD vAlign="top">Demographic</TD>
    <TD >date</TD>
    <TD >Birthdate</TD>
  </TR>
  <TR>
    <TD vAlign="top">User.IDCert</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD vAlign="top">Text</TD>
    <TD vAlign="top">Identity Certificate</TD>
  </TR>
  <TR>
    <TD ><B>#User.Demo</B></TD>
    <TD vAlign="top"><B>Category</B></TD>
    <TD ><B>Type</B></TD>
    <TD ><B>User Demographics</B></TD>
  </TR>
  <TR>
    <TD >User.Demo.Country</TD>
    <TD vAlign="top">Demographic</TD>
    <TD >Country</TD>
    <TD >Country x.520</TD>
  </TR>
  <TR>
    <TD >User.Demo.Postal</TD>
    <TD vAlign="top">Demographic</TD>
    <TD >Text</TD>
    <TD >Postal Code x.520</TD>
  </TR>
  <TR>
    <TD >User.Demo.Age</TD>
    <TD vAlign="top">Demographic</TD>
    <TD >Number</TD>
    <TD >Age</TD>
  </TR>
  <TR>
    <TD >User.Demo.Gender&nbsp;</TD>
    <TD vAlign="top">Demographic</TD>
    <TD >Gender</TD>
    <TD >Gender</TD>
  </TR>
  <TR>
    <TD vAlign="top"><B>#User.Home</B></TD>
    <TD vAlign="top"><B>Category</B></TD>
    <TD ><B>Type</B></TD>
    <TD vAlign="top"><B>Home</B></TD>
  </TR>
  <TR>
    <TD >User.Home.Formatted_Name</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD >Text</TD>
    <TD >Formatted Name</TD>
  </TR>
  <TR>
    <TD vAlign="top">User.Home.Address.Street1</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD vAlign="top">Text</TD>
    <TD vAlign="top">Street Address Line 1</TD>
  </TR>
  <TR>
    <TD vAlign="top">User.Home.Address.Street2</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD vAlign="top">Text</TD>
    <TD vAlign="top">Street Address Line 2</TD>
  </TR>
  <TR>
    <TD vAlign="top">User.Home.Address.City</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD vAlign="top">Text</TD>
    <TD vAlign="top">City</TD>
  </TR>
  <TR>
    <TD vAlign="top">User.Home.Address.PostCode</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD vAlign="top">Text</TD>
    <TD vAlign="top">PostCode</TD>
  </TR>
  <TR>
    <TD vAlign="top">User.Home.Address.State_Prov</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD vAlign="top">Text</TD>
    <TD vAlign="top">State or Province</TD>
  </TR>
  <TR>
    <TD vAlign="top">User.Home.Address.Country</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD vAlign="top">Country</TD>
    <TD vAlign="top">Country</TD>
  </TR>
  <TR>
    <TD vAlign="top">User.Home.Phone</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD vAlign="top">Number</TD>
    <TD vAlign="top">Phone</TD>
  </TR>
  <TR>
    <TD vAlign="top">User.Home.Fax</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD vAlign="top">Number</TD>
    <TD vAlign="top">Fax</TD>
  </TR>
  <TR>
    <TD >User.Home.Cellular</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD >Number</TD>
    <TD >Cellular</TD>
  </TR>
  <TR>
    <TD >User.Home.Email</TD>
    <TD vAlign="top">Online Contact</TD>
    <TD >Text</TD>
    <TD >Email</TD>
  </TR>
  <TR>
    <TD >User.Home.URL</TD>
    <TD vAlign="top">Online Contact</TD>
    <TD >URL</TD>
    <TD >HomePage</TD>
  </TR>
  <TR>
    <TD >User.Home.TZ</TD>
    <TD vAlign="top">&nbsp;</TD>
    <TD >Text</TD>
    <TD >Time Zone</TD>
  </TR>
  <TR>
    <TD vAlign="top"><B>#User.Shipping</B></TD>
    <TD vAlign="top"><B>Category</B></TD>
    <TD vAlign="top"><B>Type</B></TD>
    <TD vAlign="top"><B>Shippin Information</B></TD>
  </TR>
  <TR>
    <TD >User.Shipping.Formatted_Name</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD >Text</TD>
    <TD >Formatted Name</TD>
  </TR>
  <TR>
    <TD vAlign="top">User.Shipping.Address.Street1</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD vAlign="top">Text</TD>
    <TD vAlign="top">Street Address Line 1</TD>
  </TR>
  <TR>
    <TD vAlign="top">User.Shipping.Address.Street2</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD vAlign="top">Text</TD>
    <TD vAlign="top">Street Address Line 2</TD>
  </TR>
  <TR>
    <TD vAlign="top">User.Shipping.Address.City</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD vAlign="top">Text</TD>
    <TD vAlign="top">City</TD>
  </TR>
  <TR>
    <TD vAlign="top">User.Shipping.Address.PostCode</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD vAlign="top">Text</TD>
    <TD vAlign="top">PostCode x.520</TD>
  </TR>
  <TR>
    <TD vAlign="top">User.Shipping.Address.State_Prov</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD vAlign="top">Text</TD>
    <TD vAlign="top">State or Province</TD>
  </TR>
  <TR>
    <TD vAlign="top">User.Shipping.Address.Country</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD vAlign="top">Country</TD>
    <TD vAlign="top">Country x.520</TD>
  </TR>
  <TR>
    <TD vAlign="top">User.Shipping.Method1</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD vAlign="top">Text</TD>
    <TD vAlign="top">1st Preffered shipping method</TD>
  </TR>
  <TR>
    <TD vAlign="top">User.Shipping.Method2</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD vAlign="top">Text</TD>
    <TD vAlign="top">2nd preffered shipping method</TD>
  </TR>
  <TR>
    <TD vAlign="top"><B>#User.Business&nbsp;</B></TD>
    <TD vAlign="top"><B>Category</B></TD>
    <TD vAlign="top"><B>Type</B></TD>
    <TD vAlign="top"><B>Business</B></TD>
  </TR>
  <TR>
    <TD >User.Business.Company</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD >Text</TD>
    <TD >Company</TD>
  </TR>
  <TR>
    <TD >User.Business.FormattedName</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD >Text</TD>
    <TD >Formatted Name</TD>
  </TR>
  <TR>
    <TD >User.Business.SIC_Code</TD>
    <TD vAlign="top">&nbsp;</TD>
    <TD >Text</TD>
    <TD >Industry SIC Code</TD>
  </TR>
  <TR>
    <TD >User.Business.DUNS_Number</TD>
    <TD vAlign="top">&nbsp;</TD>
    <TD >Text</TD>
    <TD >D&amp;B Number</TD>
  </TR>
  <TR>
    <TD >User.Ticker.Symbol</TD>
    <TD vAlign="top">&nbsp;</TD>
    <TD >Text</TD>
    <TD >Stock Symbol</TD>
  </TR>
  <TR>
    <TD >User.Business.Logo</TD>
    <TD vAlign="top">&nbsp;</TD>
    <TD >Graphic</TD>
    <TD >Business Logo</TD>
  </TR>
  <TR>
    <TD >User.Business.JobTitle</TD>
    <TD vAlign="top">Demographic</TD>
    <TD >Text</TD>
    <TD >Job Title</TD>
  </TR>
  <TR>
    <TD >User.Business.Department</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD >Text</TD>
    <TD >Department</TD>
  </TR>
  <TR>
    <TD >User.Business.Office</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD >Text</TD>
    <TD >Office</TD>
  </TR>
  <TR>
    <TD vAlign="top">User.Business.Address.Street1</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD vAlign="top">Text</TD>
    <TD vAlign="top">Street Address Line 1</TD>
  </TR>
  <TR>
    <TD vAlign="top">User.Business.Address.Street2</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD vAlign="top">Text</TD>
    <TD vAlign="top">Street Address Line 2</TD>
  </TR>
  <TR>
    <TD vAlign="top">User.Business.Address.Street3</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD vAlign="top">Text</TD>
    <TD vAlign="top">Street Address Line 3</TD>
  </TR>
  <TR>
    <TD vAlign="top">User.Business.Address.City</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD vAlign="top">Text</TD>
    <TD vAlign="top">City</TD>
  </TR>
  <TR>
    <TD vAlign="top">User.Business.Address.Postal</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD vAlign="top">Text</TD>
    <TD vAlign="top">Postal Code</TD>
  </TR>
  <TR>
    <TD vAlign="top">User.Business.Address.State_Prov</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD vAlign="top">Text</TD>
    <TD vAlign="top">State or Province</TD>
  </TR>
  <TR>
    <TD vAlign="top">User.Business.Address.Country</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD vAlign="top">Country</TD>
    <TD vAlign="top">Country</TD>
  </TR>
  <TR>
    <TD vAlign="top">User.Business.Phone</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD vAlign="top">Phone</TD>
    <TD vAlign="top">Phone</TD>
  </TR>
  <TR>
    <TD vAlign="top">User.Business.Fax</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD vAlign="top">Phone</TD>
    <TD vAlign="top">Fax</TD>
  </TR>
  <TR>
    <TD >User.Business.Pager</TD>
    <TD vAlign="top">Physical Contact</TD>
    <TD >Phone</TD>
    <TD >Pager</TD>
  </TR>
  <TR>
    <TD >User.Business.Email</TD>
    <TD vAlign="top">Online Contact</TD>
    <TD >Email</TD>
    <TD >Email</TD>
  </TR>
  <TR>
    <TD vAlign="top">User.Business.URL</TD>
    <TD vAlign="top">Online Contact</TD>
    <TD vAlign="top">URL</TD>
    <TD vAlign="top">Home Page</TD>
  </TR>
</TABLE>
<P>
&nbsp;
<TABLE BORDER="1" CELLSPACING="1" CELLPADDING="2" WIDTH="100%">
  <TR>
    <TD WIDTH="38%" VALIGN="TOP"><STRONG>#System.Computer</STRONG></TD>
    <TD WIDTH="26%" VALIGN="TOP"><STRONG>Category</STRONG></TD>
    <TD WIDTH="12%" VALIGN="TOP"><STRONG>Type</STRONG></TD>
    <TD WIDTH="25%" VALIGN="TOP"><STRONG>Short display name</STRONG></TD>
  </TR>
  <TR>
    <TD WIDTH="38%" VALIGN="TOP">System.Computer.Info</TD>
    <TD WIDTH="26%" VALIGN="TOP">Computer Information</TD>
    <TD WIDTH="12%" VALIGN="TOP">Text</TD>
    <TD WIDTH="25%" VALIGN="TOP">Information about your computer, OS, CPU, etc.</TD>
  </TR>
  <TR>
    <TD WIDTH="101%" VALIGN="TOP" colspan="4">&lt;otherwise, see
      <A href="http://www.w3.org/TR/NOTE-agent-attributes">http://www.w3.org/TR/NOTE-agent-attributes</A>
      &gt;</TD>
  </TR>
  <TR>
    <TD WIDTH="38%" VALIGN="MIDDLE"><STRONG>#System.Web</STRONG></TD>
    <TD WIDTH="26%" VALIGN="TOP"><STRONG>Category</STRONG></TD>
    <TD WIDTH="12%" VALIGN="TOP"><STRONG>Type</STRONG></TD>
    <TD WIDTH="25%" VALIGN="TOP"><STRONG>Short display name</STRONG></TD>
  </TR>
  <TR>
    <TD WIDTH="38%" VALIGN="MIDDLE">System.Web.Client_Click_Stream</TD>
    <TD WIDTH="26%" VALIGN="TOP">Navigation and Click-stream Data&nbsp;</TD>
    <TD WIDTH="12%" VALIGN="MIDDLE">Binary</TD>
    <TD WIDTH="25%" VALIGN="MIDDLE">Click Stream collected on the server.</TD>
  </TR>
  <TR>
    <TD WIDTH="38%" VALIGN="MIDDLE">System.Web.Server_Click_Stream</TD>
    <TD WIDTH="26%" VALIGN="TOP"><DL>
	<DT>
	  Navigation and Click-stream Data&nbsp;
      </DL>
    </TD>
    <TD WIDTH="12%" VALIGN="MIDDLE">Binary</TD>
    <TD WIDTH="25%" VALIGN="MIDDLE">Click Stream collected on the client.</TD>
  </TR>
  <TR>
    <TD >System.Web.Search_Text</TD>
    <TD vAlign="top">Transaction Data</TD>
    <TD >Text</TD>
    <TD >Search keywords</TD>
  </TR>
  <TR>
    <TD WIDTH="38%" VALIGN="MIDDLE">System.Web.HTML_Form</TD>
    <TD WIDTH="26%" VALIGN="TOP">Transaction Data</TD>
    <TD WIDTH="12%" VALIGN="MIDDLE">Text</TD>
    <TD WIDTH="25%" VALIGN="MIDDLE">Form data not including search terms</TD>
  </TR>
  <TR>
    <TD WIDTH="38%" VALIGN="MIDDLE">System.Web.PUID</TD>
    <TD WIDTH="26%" VALIGN="TOP">Unique Identifiers</TD>
    <TD WIDTH="12%" VALIGN="MIDDLE">Number</TD>
    <TD WIDTH="25%" VALIGN="MIDDLE">Pairwise or Site ID</TD>
  </TR>
  <TR>
    <TD WIDTH="38%" VALIGN="MIDDLE">System.Web.TUID</TD>
    <TD WIDTH="26%" VALIGN="TOP">Unique Identifiers</TD>
    <TD WIDTH="12%" VALIGN="MIDDLE">Number</TD>
    <TD WIDTH="25%" VALIGN="MIDDLE">Temporary or Session ID</TD>
  </TR>
</TABLE>
<H2>
  <A NAME="notation">A. Notation</A>
</H2>
<P>
The formal grammar of P3P is given in this specification using the ABNF defined
in
<A HREF="http://info.internet.isi.edu/in-notes/rfc/files/rfc2234.txt">http://info.internet.isi.edu/in-notes/rfc/files/rfc2234.txt</A>
. The following is a simple description of the ABNF.
<P>
<DL>
  <DT>
    name&nbsp;=&nbsp;(element)
  <DD>
    where &lt;name&gt; is the name of the rule, &lt;elements&gt; is one or more
    rule names or terminals combined through the operands provided below. Rule
    names are case-insensitive
  <DT>
    (element1 element2)
  <DD>
    elements enclosed in parentheses are treated as a single element, whose contents
    are strictly ordered,
    <P>
    <CODE><B> </B></CODE>
  <DT>
    &lt;a&gt;*&lt;b&gt;element
  <DD>
    at least &lt;a&gt; and at most &lt;b&gt; occurrences of the element.<BR>
    <EM>(1*4&lt;element&gt; means one to four elements.)</EM>
    <P>
    <CODE><B> </B></CODE>
  <DT>
    &lt;a&gt;element
  <DD>
    exactly &lt;a&gt; occurences of the element.<BR>
    <EM>(4&lt;element&gt; means exactly 4 elements.)</EM>
    <P>
    <STRONG><FONT FACE="Courier New" SIZE="2"> </FONT></STRONG>
  <DT>
    &lt;a&gt;*element
  <DD>
    &lt;a&gt; or more elements<BR>
    <EM>(4*&lt;element&gt; means 4 or more elements.)</EM>
    <P>
    <STRONG><FONT FACE="Courier New" SIZE="2"> </FONT></STRONG>
  <DT>
    *&lt;b&gt;element
  <DD>
    0 to &lt;b&gt; elements.<BR>
    <EM>(*5&lt;element&gt; means 0 to 5 elements.)</EM>
    <P>
    <CODE><B> </B></CODE>
  <DT>
    *element
  <DD>
    0 or more elements.<BR>
    <EM>(*&lt;element&gt; means 0 to infinite elements.)</EM>
    <P>
    <CODE><B> </B></CODE>
  <DT>
    [element]
  <DD>
    optional element, equivalent to *1(foo bar).<BR>
    <EM>([element] means 0 or 1 elements.)</EM>
    <P>
    <CODE><B> </B></CODE>
  <DT>
    "string"
  <DD>
    matches a literal string <A HREF="#dt-match">matching</A> that given inside
    the double quotes.
</DL>
<P>
Other notations used in the productions are: <CODE><B></B></CODE>
<DL>
  <DT>
    ; or <CODE><B>/* ... */</B></CODE>
  <DD>
    comment.
</DL>
<P>
  <HR WIDTH="80%">
<H2>
  B. <A NAME="P3P_Data_Elements__Categories_and_Sets">P3P Data Elements, Categories
  and Sets</A>
</H2>
<P>
<EM>[This section is very relevant to the Implementation Guide.]</EM>
<P>
Authors:
<UL>
  <LI>
    Melissa Dunn, Microsoft
  <LI>
    Paul Perry, FireFly
    <P>
    <FONT COLOR="#ff0000"> </FONT>
  <LI>
    [ed. Joseph Reagle]
</UL>
<H3>
  Purpose
</H3>
<P>
The purpose of this section is to describe the nature of the client side
data store. This includes the basic building blocks, the general expectations
for the client and the standard data categories and elements. This document
is not a design specification. It is meant to outline requirements without
defining implementation. Therefore, examples should be taken as merely that
and should not be used to limit the possible implementations.
<H3>
  Definitions
</H3>
<TABLE CELLSPACING="0" BORDER="0" CELLPADDING="7" WIDTH="100%">
  <TBODY>
    <TR>
      <TD VALIGN="middle" align="left"></TD>
    </TR>
  </TBODY>
  <TBODY>
    <TR>
      <TD><STRONG>Term</STRONG></TD>
      <TD VALIGN="middle" align="left"><H4>
	  Definition
	</H4>
      </TD>
    </TR>
    <TR>
      <TD VALIGN="middle" align="left">Data Element</TD>
      <TD VALIGN="middle" align="left">An individual data entity, such as last
	name or phone number.</TD>
    </TR>
    <TR>
      <TD VALIGN="middle" align="left">Data Category</TD>
      <TD VALIGN="middle" align="left">A significant attribute of a data element
	or set that may be used by a trust engine to determine what type of element
	is under discussion, such as physical contact information.</TD>
    </TR>
    <TR>
      <TD VALIGN="middle" align="left">Data Set</TD>
      <TD VALIGN="middle" align="left">A known grouping of data elements, such
	as mailing address.</TD>
    </TR>
    <TR>
      <TD VALIGN="middle" align="left">Persona</TD>
      <TD VALIGN="middle" align="left">One or more data elements used to create
	a set representing an image or personality presented to a service.</TD>
    </TR>
    <TR>
      <TD VALIGN="middle" align="left">Profile</TD>
      <TD VALIGN="middle" align="left">Data entered by the user or the service
	that describes service specific information, such as user preference categories.</TD>
    </TR>
    <TR>
      <TD VALIGN="middle" align="left">Identity</TD>
      <TD VALIGN="middle" align="left">The single persistent attribute by which
	the individual may always be known.</TD>
    </TR>
  </TBODY>
</TABLE>
<H4>
  Data Components
</H4>
<P>
The following assumptions are made in this document:
<OL>
  <LI>
    The user will store "reusable" information in the user agent data store.
  <LI>
    The service will request information that is to be stored on the server .
  <LI>
    The service will request data that is to be stored in the user agent data
    store.
</OL>
<H4>
  Data Element
</H4>
<P>
A data element represents a single piece of information. This information
may be a singleton, such as last name, or a stream of information, such as
the user&#146;s click stream. There is a base set of standard data elements
(see the Standard Data Requirements).
<P>
Services, or user applications, may create additional data elements as allowed
by the user.
<P>
In order to prevent accidental duplication of element names, as well as to
allow for a certain degree of standardization, the following naming conventions
should be applied:
<UL>
  <LI>
    <UL>
      <LI>
	Multiple word names use an underscore to separate the words (e.g., Last_Name)
      <LI>
	Name space identifiers can be used in front of data elements in order to
	distinguish differences in values according to a domain (e.g.,
	Anonymous::First_Name, Known::First_Name)
      <LI>
	Names are case insensitive
    </UL>
</UL>
<H4>
  Data Types
</H4>
<P>
Associated with the data element is an expected data type. The data types
of each attribute are expressed in terms of the X.520 specification and
[IETF-VCARD]. For example, the birth date (BDAY) is formatted in the same
manner as the corresponding BDAY attribute in [IETF-VCARD].
<P>
Note: VCARD is used throughout this document by way of example and not as
an endorsement of that standard.
<P>
The defined formats are:
<UL>
  <LI>
    Plain text: arbitrary text
  <LI>
    Number: number
  <LI>
    Date: [from vcard specification]
  <LI>
    URL: [from vcard specification]
  <LI>
    Email: [from vcard specification]
  <LI>
    Phone: X.520
  <LI>
    Gender: Enum type: M - for male, F - for female
  <LI>
    Country: ISO 3166 Country Code
</UL>
<DL>
  <DT>
    The P3P data repository and service providers can extend the data types through
    the use of RDF.
</DL>
<H4>
  <A NAME="Data_Category">Data Category</A>
</H4>
<P>
Data categories are used to classify data elements based upon the conceptual
schema underlying the privacy policy. They provide context to proposals but
can not be the sole referent of a request for data using P3P methods. A site
may not say, "I would like all of your demographic data under this agreement."
No data category is implicitly more identifiable than another. Often, identity
can be derived from seemingly non-identifiable characteristics like zip-code,
gender, and birthdate. Consequently, it is the service's use of data that
is identifiable or not. Obviously many of the elements in the category Contact
Information will be used in an identifiable way.
<P>
Data categories do provide several advantages.
<P>
First, data categories can be used to identify the type of information the
service will be requesting. The user agent can match the preference to the
category without further parsing. If preferences are expressed over categories,
and there is not a match, the user agent can reject the service, investigate
the specific data set or elements, or move to the start of the next policy
statement.&nbsp; However, such an implementations could be abused by services
that request sensitive data elements under a relatively non-sensitive data
category, this is a major privacy concern. We recommend that implementations
parse and make decisions on the basis of requests and preferences over data
sets and elements. See note on <A HREF="#GUI">GUIs</A>.
<P>
Second, data categories can identify the type of data element when the element
is unknown to the user agent. This may happen when a new data set or element
is proposed to the user agent, or when data is collected from a form (HTML_put).
This provides a further to the user of the data the service is asking him
to provide.
<P>
Finally, the user agent can use the category to determine whether the service
can write the element into the P3P data repository.
<P>
The following are the ten specified P3P data categories (see
<A HREF="http://www.w3.org/P3P/Group/Harmonization/Drafts/P3P-harmonization-980120.html">http://www.w3.org/P3P/Group/Harmonization/Drafts/P3P-harmonization-980120.html</A>
for further information)
<H4>
  Data Set
</H4>
<P>
In the simplest terms, a data set is a named set of data elements. The
organization of data elements into logical sets provides a short hand means
of requesting a groups of data elements, such as mailing address, without
the need to request each data element. This should reduce the amount of time
required to request and negotiate for data. Further, the use of a set notation
can be used by the implementation to quickly locate the actual set of data
elements regardless of the data repository implementation.
<P>
The assumption here is that the base set of P3P sets should address 90% of
the requests for user data.
<P>
It should be remembered that the P3P data repository is not meant to retain
all of the information requested by a service. There will be some data elements
that will not be requested by many or any other service. It is anticipated
that this information will be stored with the service.
<P>
Further, the number of services requesting the storage of service specific
data elements will be less than the number relying upon common elements.
Allowing the service to create it&#146;s own grouping, or set, of data containing
those data elements should reduce latency by providing the short hand notation
of the data set.
<P>
The base set of P3P sets, as defined in the section on Standard Data Elements
and Sets, can not be changed by the either the user agent or a service. Data
sets share in the naming convention of data elements, adding the following:
<UL>
  <LI>
    Data sets should begin with a pound sign to distinguish between a data element
    and the set (e.g., #shipping_address)
</UL>
<P>
Treating data sets as objects gives the advantage of the concept of inheritance.
"Inheritance", as meant here, allows a service or user agent to create a
new data element grouping without necessarily replicating all of the data
elements. For example, if a service wants all of the information in the base
shipping_address set, plus a single identification code representing the
invoice, all that needs to be stored by the user agent is the service&#146;s
set name, a reference to the shipping_address set and the new data element:
<BLOCKQUOTE>
  #shipping_address<BR>
  invoice
</BLOCKQUOTE>
<P>
Data set notation has the advantage of allowing the user agent to track the
information requested by any service. However, this is really an implementation
detail as to whether the data repository should/would track all information
requests and store transactional information, such as the invoice. Due to
the fact that this shorthand notation is violated when the user opts to change
the shipping address information for the specific occurrence or service,
it would be more common to find the service storing the shipping information
on their server, rather than be dependent upon the user data repository.
<P>
Another advantage of data sets, in the simple case, is the reduction of data
replication. If the user wants to reuse the #shipping_address information
without change, then associating the set notation with a service&#146;s name
space becomes an accurate representation of the data shared without actually
needing to maintain and store duplicates (e.g., Nike::#shipping_address)
<P>
Since data sets may contain data elements from more than one category, a
set may be placed into multiple categories. The way in which this information
is stored is implementation specific. However, the transport mechanism may
be used to indicate the data categories, as well as the data elements as
designed.
<P>
Note: it is difficult to expand upon the notion of categories and semantic
transport without an understanding of the transport mechanism itself. If
RDF is used, then the transport is more graphical in nature, than if XML&#146;s
hierarchical notion is chosen. It is assumed that the transport is through
HTTP.
<P>
<FONT FACE="Arial"></FONT>
<H2>
  C. <A name="References">References</A>
</H2>
<P>
[DSIG] <B><I>Recommendation:
<A href="http://www.w3.org/TR/1998/PR-DSig-label-19980403/">DSig 1.0 Signature
Labels Specification: Using PICS 1.1 Labels for Making Signed
Assertions</A></I></B>. Yang-Hua Chu, Philip DesAutels, Brian LaMacchia,
Peter Lipp. <A href="http://www.w3.org/">World Wide Web Consortium.</A>
03-April-1998.
<P>
[HTTP1.1] <EM><STRONG>RFC 2068:
</STRONG></EM><A href="http://www.w3.org/Protocols/rfc2068/rfc2068">Hypertext
Transfer Protocol -- HTTP/1.1</A>. Fielding, Gettys, Mogul, Frystyk, Berners-Lee.
<A href="http://www.ietf.org/home.html">IETF</A>. January 1997.
<P>
[ISO 3166] <EM><STRONG>Codes for The Representation of Names of
Countries</STRONG></EM>. International Organization for Standardization,
December, 1993.
<P>
[RDF]<STRONG><EM> Working Draft:
</EM></STRONG><B><I><A href="http://www.w3.org/TR/WD-rdf-syntax">Resource
Description Framework (RDF) Model and Syntax Specification</A></I></B>. Ora
Lassila, Ralph R. Swick. <A href="http://www.w3.org/">World Wide Web
Consortium.</A> 16-February-1998.
<P>
[MD5] <EM><STRONG><A href="http://ds.internic.net/rfc/rfc1321.txt">RFC
1321:</A></STRONG></EM> <EM><STRONG>The
</STRONG><A href="http://ds.internic.net/rfc/rfc1321.txt"><B>MD5 Message
Digest Algorithm</B></A></EM>, Rivest.
<A href="http://www.ietf.org/home.html">IETF</A>. April 1992.
<P>
[PEP] <STRONG><EM>Working Draft:
</EM></STRONG><B><I><A href="http://www.w3.org/TR/WD-http-pep">PEP Specification:
an Extension Mechanism for HTTP</A></I></B>. Henrik Frystyk Nielsen, Dan
Connolly, Rohit Khare, Eric Prud'hommeaux. <A href="http://www.w3.org/">World
Wide Web Consortium.</A> 21-November-1997.
<P>
[XML] <B><I>Recommendation: <A href="http://www.w3.org/TR/REC-xml">Extensible
Markup Language (XML) 1.0 Specification</A></I></B>. Tim Bray, Jean Paoli,
C. M. Sperberg-McQueen. <A href="http://www.w3.org/">World Wide Web
Consortium.</A> 10-February-1998.
<P>
[VCARD]&nbsp; <A href="http://www.imc.org/pdi/vcard-21.txt">vCard - The
Electronic Business Card Version 2.1.</A> Internet Mail Consortium, September
18, 1996.
<P>
  <HR>
<EM><B></B></EM>
<P>
posted by: <A HREF="mailto:reagle@w3.org"><I>reagle@w3.org</I></A>
</BODY></HTML>