server_playground/doc/www.w3.org/TR/1998/NOTE-P3P10-Protocols-19980324


								<!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>