Platform for Privacy Preferences (P3P) Syntax Specification

W3C Working Draft 26 August 1999

This Version 
Latest Public Version:
Previous Version:
Massimo Marchiori, W3C/MIT, (massimo@w3.org)


This is the core and lengthiest document of the P3P specification; it documents the requirements and assumptions, and specifies the P3P protocols, transport methods, and the data structures' syntax and encoding.

Status of This Document 

This is a subspecification of the P3P specification for review by W3C members and other interested parties. This document has been produced as part of the P3P Activity, and will eventually be advanced toward W3C Recommendation status. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress." The underlying concepts of the draft are fairly stable and we encourage the development of experimental implementations and prototypes so as to provide feedback on the specification. However, this Working Group will not allow early implementations to affect their ability to make changes to future versions of this document.

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

Send comments to www-p3p-public-comments@w3.org (archived at http://lists.w3.org/Archives/Public/www-p3p-public-comments/).

Table of Contents

  1. Introduction
    1. Problem space
    2. About this specification
    3. Operational description
    4. Assumptions
    5. Terminology
    6. Conformance requirements
  2. Scenarios
  3. Data Transport
    1. Protocol Model
      1. Client Actions
      2. Server Actions
    2. HTTP Extension Framework and P3P
    3. Protocol Actions
      1. P3P Client Actions
      2. P3P Server Actions
      3. Protocol Example
    4. Error messages
    5. Limited Protocol
  4. P3P markup and processing
    1. Example proposal
      1. English language proposal
      2. XML/RDF encoding of proposal
    2. Proposals
      1. The PROP element
      2. The REALM element
      3. The DISCLOSURE element
      4. The ASSURANCE element
    3. Data Transmission
    4. Statements
      1. The STATEMENT element
      2. The CONSQ element
      3. The PURPOSE element
      4. The RECPNT element
      5. The REF element
      6. Null Values
      7. The source attribute
    5. Categories
      1. Fixed-Category Data Elements
      2. Variable-Category Data Elements
    6. Creating new data sets
      1. Repository Data
      2. Non-Repository Data
  5. Appendices
    Appendix 1: References (Normative)
    Appendix 2: ABNF Notation (Non-normative)
    Appendix 3: Working Group Contributors (Non-normative)

1. Introduction

The Platform for Privacy Preferences Project (P3P) enables Web sites to express their privacy practices and enables users to exercise preferences over those practices. P3P compliant products will allow users to be informed of site practices (in both machine and human readable formats), to delegate decisions to their computer when appropriate, and to tailor their relationship to specific sites. Site practices that are compatible with a user's preferences can, at the user's option, be accessed "seamlessly". Otherwise users will be notified of a site's practices and have the opportunity to agree to those terms or other terms and continue browsing if they wish.

P3P gives users the ability to make informed decisions regarding their Web experience and the ability to control the use of their information. Sites can use P3P to increase the level of confidence users place in their services, as well as improve the quality of the services offered, customize content, and simplify site access.

P3P uses  [XML] (using the [RDF] data model) for the exchange of structured data and assertions. P3P will support future digital certificate and digital signature capabilities. P3P can be incorporated into browsers, browser plug-ins, servers, or proxy servers that sit between a client and server.

1.1 Problem space

The P3P specification provides mechanisms:

1.2 About this specification

This document, along with its normative references and the other chapters of the P3P specification, includes all the specification necessary for the implementation of interoperable P3P applications.

This document includes the main body of the P3P specification. The detailed -- natural language -- semantics of the privacy disclosure vocabulary can be found in [HARMV]. The detailed syntax and datatypes of the base data set is found in [BASEDATA].

Note that while use of the above vocabulary is required for P3P1.0 compliance, the facility of XML-namespaces [XML-name] allows additional or complementary vocabularies to be easily introduced.

We use the following typographical conventions for representing the status of text:

The ABNF notation used in this specification is specified in RFC2234 and summarized in Appendix 2. However, note that such syntax is only a grammar representative of the XML syntax: all the syntactic flexibilities of XML are also implicitly included; e.g. whitespace rules, quoting using either single quote (') or double quote ("), character escaping, and case sensitivity.

1.3 Operational description and design

When a user encounters a Web service, the Web service may declare its privacy practices and solicit information from the user by sending the user the URI of a P3P proposal and an identifier for that proposal called a propID. The proposal and propID are transmitted using an extension to the HTTP transport mechanism.

A P3P proposal consists of one or more statements, each of which expresses privacy practices for a set of data elements. The P3P proposal should cover all relevant data elements and practices: if a service wants to collect a data element, it must be mentioned in the proposal. Note that most declarations in P3P are positive, meaning you state what you do, rather than what you do not do.

A core concept to the P3P specification is that of a P3P agreement. A P3P agreement is a proposal agreed to by both the service and user agent. User agents compare the privacy practices specified in a proposal with the user's preferences to determine whether to enter into an agreement. An agreement applies to all data exchanged between the user agent and service within one or more specified realms -- a Web resource or "tree" of Web resources referenced by a single URI.

If a user agent finds a proposal acceptable, it can signal agreement to the web site by returning the proposal identifier. If the proposal includes a request for data to be sent using P3P data transfer methods, the corresponding data is returned with the proposal identifier.

Servers may offer multiple alternative proposals for each realm. Every proposal can have a set of consequences that can be shown to a human user to explain why the suggested practice may be valuable in a particular instance even if the user would not normally allow the practice. User agents should record the agreements reached, indexed by an identifier of the agreement, called the propID. Rather than sending a new proposal URI and propID to the user agent on every contact, a site may send the propID of an existing agreement.

Services may also embed <LINK> tags into HTML content that reference a P3P proposal. This allows services to assert that they follow the practices specified in a P3P proposal without requiring that they use a P3P-compliant server.

There are two notable areas where we substantively provide extensibility mechanisms.

  1. How information is solicited from the user. (see source attribute)
  2. How new data sets are used by services and clients (see DATA:REF and namespaces)

Our design is such that applications can be efficiently implemented independent of our assumptions or expectations regarding the latency of multi-round communications, the cacheability of proposals, the use of user agent or server side data repositories, and the size of the agreement repositories.

1.4 Assumptions

P3P makes several assumptions about the environment in which it works and the problem it is trying to solve.

  1. P3P allows a service to include identifying information about itself in its proposals. Since the registered owner of a domain name may not correspond to the entity responsible for a service, this information MUST be provided.
  2. Strong non-repudiable evidence of identities and agreements will be provided by future versions of the protocol. At this time, no clear/dominant Public Key Infrastructure (PKI) model exists for use in P3P. In the future both users and services may require signatures and certificates.
  3. We assume that communication security is achieved through means other than P3P itself [SSL]. Hence, P3P does not provide mechanisms for cryptographically protecting information in storage or transit.
  4. 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 their practices are not governed by the agreement between the end parties.
  5. While P3P can make profitable use of the HTTP Extension Framework [HTTP-EXT], which is based on [HTTP1.1], P3P should be able to work with [HTTP1.0] servers/proxies.
  6. P3P covers all data generated or exchanged via HTTP.

1.5 Terminology

Assuring Party
Within P3P, an assuring party is a legal entity (person or organization) that makes a statement of assurance about a proposal (e.g. that practices are audited, or are in compliance with certain data collection guidelines). Assurance may come from the service itself or from an independent third party. The assuring party must identify what it is attesting to as part of the assurance statement within the proposal, at a specified URI, or as part of the semantic definition of a meta-data schema.
A proposal to which both the service and user agent agree. This agreement is applied within the realm and is often represented by a propID. The non-repudiability of such agreements will be strengthened by the support of certificate and digital signature capabilities in future versions of P3P; however this is not specified in version 1.0. We do provide the appropriate fields for the inclusion of such tokens within P3P1.0 (e.g. a digital signature from the assuring party.)
Data Element
An individual data entity, such as last name or telephone number. For interoperability, P3P 1.0 specifies a base set of data elements.
Data Category
A significant attribute of a data element or data set that may be used by a trust engine to determine what type of element is under discussion, such as "Contact Information." P3P 1.0 specifies 10 base data categories.
Data Set
A known grouping of data element, such as "user.Home.Postal.". A set is represented with a trailing period. P3P 1.0 specifies a number of base data sets.
A rule, or set of rules, that determines what action(s) a user agent will take or allow when involved in a conversation or negotiation with a service. A preference might be expressed as a formally defined computable statement (e.g., the [APPEL] preference exchange language). In this document, preferences govern the types of agreements that can be reached between a user agent and a service.
A small unit of information used to uniquely identity a P3P proposal (together with the URI the proposal resides). The presence of the propID in the P3P headers is the definitive declaration of which agreements are in effect for a given realm. Whenever a service changes a proposal at the same URI, it MUST change the corresponding propID (for example, a fingerprint of the proposal could be computed, like [MD5]). The propID MUST not be used for any other purpose beyond identifying and referencing P3P proposals (so, for example, they cannot be used to maintain user browsing state).
A proposal is a collection of one or more privacy statements together with information asserting the identity, URI, assurances, and disclosures of the service covered by the proposal. A proposal is always created 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 realm is the experience space from which requests under a given agreement may be issued -- it broadly defines the area to which a proposal applies.   It is referenced by one or more URIs. Each URI may name a specific resource or a set of resources qualified by the URI. For instance, in the HTTP URI scheme, a URI ending with an object (home.html) applies to that specific object, a URI that is a path http://www.w3.org/P3P/   references the file system tree below that path.   If the proposal is not digitally signed, then each of the URIs must be from a domain that domain-matches the origin server. Domain matching is covered in the HTTP state management mechanism [STATE].
A mechanism for storing user information under the control of P3P.
A program that issues proposals and (possibly) data requests. By this definition, a service may be a server (site), a local application, a piece of locally active code, such as an ActiveX control or Java applet, or even another user agent.
A P3P statement is a set of privacy practice disclosures relevant to a collection of data elements, sets, and categories. The enumerated elements may act as an embedded data request. A statement which references no data, does not request any data.
A Uniform Resource Identifier used to identify Web resources. For definitive information on URI syntax and semantics, see [URI].
User Agent
A program whose purpose is to mediate interactions with services on behalf of the user under the user's preferences. A user may have more than one user agent, and agents need not reside on the user's desktop, but any agent must be controlled by and act on behalf of only the user. The trust relationship between a user and her agent may be governed by constraints outside of P3P. For instance, an agent may be trusted as a part of the user's operating system or Web client, or as a part of the terms and conditions of an ISP or privacy proxy.

1.6 Conformance requirements

This document specifies requirements over interoperability, feature sets, and policy related semantics. Interoperability requirements constrain implementations such that the protocols operate in accordance with a "shared" protocol state machine and that information is not arbitrarily lost or confounded. This document further specifies requirements over feature sets. This means that while not implementing a feature does not break the protocol, it is an abuse of the reciprocating party's -- or user's -- expectation of which features are supported. Furthermore, because of the important policy implications of this application, P3P includes natural language semantics for an XML/RDF schema. To provide an example, an interoperability requirement requires that all parties support the protocol primitives and their responses. Given this requirement, a compliant agent could always return a SORRY. However, it abuses the expectations of a service from being able to reach an agreement if all agents are implemented to merely return a sorry. To extend this example, services may not be willing to implement multiple policies or negotiated settlements if no agents exist to do so -- in either case, this lack of a support of a feature does not abuse protocol interoperability.

The breadth of these requirements is atypical but necessary given that P3P is more than a protocol, but an application of existing standards such as HTTP and XML. Furthermore, this document discusses expected features which are not yet implemented and need not be part of the specification itself, but are an important part of the P3P user experience.

The following key words are used throughout the document and should be read as interoperability requirements. This specification uses words as defined in RFC2119 [KEY] for defining the significance of each particular requirement. These words are:

This word or the adjective "required" means that the item is an absolute requirement of the specification.
This word or the adjective "recommended" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course.
This word or the adjective "optional" means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item.

The following table presents a summary of features and operations with respect to their requirements. The context of whether the requirements are placed on the client and/or service is left to the context found in the specification.

Section Feature/Operation Key Word Explanation (or Implication if not supported)


propID MUST propID uniquely identifies any privacy proposal

Data transport

the HTML LINK tag MUST agents and services must be able to locate a proposal in this location
  the HTTP extension mechanism MUST agents and services must be able to locate a proposal in this location

XML/RDF encoding

XML parsing MUST proposals and data syntax are readily processed or presented to the user. The RDF data model was used to structure the required grammar/syntax but applications need not support RDF if they do not want to take advantage of the RDF data model.

XML/RDF encoding

Full XML and XML-namespace support MUST implementations must support full XML and namespaces, not just that used here.
Data References base data reference syntax MUST agents must be able to understand that syntax of solicited information
Harmonized Vocab harmonized vocabulary MUST see the harmonized vocabulary [HARMV] for requirements; they must be followed otherwise the implementation abuses consensus on adequate levels of privacy disclosure
Reason Codes (OK, SRY-, ERR-, SRY, ERR) MUST necessary for reaching agreement.
propID repository SHOULD full proposals can be compactly represented, new negotiation and agreement are not necessary if an agreement already exists.
  data repository MAY frequently requested user profile information is stored and managed by the user.
Data Definitions new schema instantiation MAY schemas other than the base set can be instantiated and supported by the agent.
Source Attribute source attributes "matched-form" and "extension" MAY agents support multiple, extensible mechanisms by which information is solicited.

Note that services need not use P3P-compliant servers in order to make P3P proposals available to user agents.

A very simple P3P user agent might do little more than receive P3P proposals and present them to users. Whenever information is requested, such a user agent would prompt the user to make a decision. Thus such a user agent would not make any decisions on behalf of a user or transfer any user data automatically (with the exception of passively generated data such as click-stream data).

User agents that make decisions on behalf of a user or transfer user data automatically must include a user-configurable "trust engine." The trust engine must be able to take a P3P proposal and a set of user preferences -- recorded as a set of rules -- as input and determine what action (seamless accept, seamless reject, informational prompt, warning prompt, or other action) should be taken. User preferences can be encoded in [APPEL] or another language. The preference language should be well-documented or a user interface should be provided for creating rule sets in that language. The user agent must provide a way for users to import rule sets that they create themselves or obtain from others. It should also provide mechanisms for users to create or change rules.

User agents may be initially unconfigured (thus requiring users to configure them before they can be used) or configured with a default rule set. However user agents must not be configured by default to transfer personal information to a service provider without the user's active agreement (seamless accept).

2. Scenarios

The following scenarios are designed to illustrate several possible ways that P3P might be used. Each scenario highlights a different P3P feature. Scenario 1 shows how a basic P3P agreement is established. Scenarios 2 and 3 show what happens when a user returns to a site where an agreement has already been reached. Scenarios 4 highlights the use of the user data repository given existing agreements.

These scenarios illustrate interactions in which no negotiation occurs. However, any scenario could be expanded to one in which a site initially offers multiple alternative proposals.

The table below summarizes the features of each scenario. A "-" in the table indicates a feature about which no assumptions (neutral) are made.
Scenario Existing Agreement New Proposal Data Requested
1 No Yes -
2 Yes No -
3 Yes Yes -
4 - - Yes

Scenario 1) No existing agreement, site sends proposal

  1. User goes to the home page of CoolCatalog (CoolCatalog/*), she has never been there before but is P3P-compliant.
  2. CoolCatalog makes a proposal, including privacy practices, disclosures, and the data elements to which they apply.
  3. User agrees to proposal.

Scenario 2) Existing realm agreement

  1. User has previously done scenario 1.
  2. User returns to CoolCatalog and -- following the existing agreement -- is automatically under the current proposal.

Scenario 3) Existing realm agreement, new proposal

  1. User has previously completed scenario 1.
  2. User returns to CoolCatalog and furnishes propID of Agreement(1) on all page requests.
  3. User goes to order page on CoolCatalog (CoolCatalog/Order/*) and sends propID of Agreement(1) and the service makes a new proposal because its policies at the order page differ from the rest of the site. In this instance, it wants actual order information.
  4. User considers the new proposal, and agrees to it.

Scenario 4) Service wants data from client repository

3 Data Transport

3.1 Protocol Model

The protocol model is based on a single round interaction, where the client performs an action (like requesting a proposal), and the server completes the interaction with another action (for example, suggesting a proposal back). Since we follow the rule of thumb that compact data (usually, just a single line) should be placed in an HTTP header, often the response to a request will be a location at which the client must fetch the actual proposal -- just as an HTML client makes several requests to retrieve images in a page. This single interaction (which may involve multiple HTTP requests) can be extended to multiple interactions (or "negotiation") if needed. That is, multiple interactions can be built on top of a single interaction without affecting the simplicity of a single round interaction. It is important to note that the proposed protocol interactions strictly follow the HTTP request/response paradigm in order to properly interact with intermediate caches which may or may not know about P3P.

The basic protocol actions can be summarized as follows.

3.1.1 Client Actions

The client can perform any of the following actions at any point in time when issuing requests:

  1. Request a proposal
  2. Make a request referencing a known proposal
  3. Submit data under a known proposal
  4. Report unacceptable proposals and other errors

3.1.2 Server Actions

The server can perform the following actions:

  1. Suggest a proposal in response to any request from a P3P-enabled client
  2. Fulfill a request and accept data under a corresponding proposal
  3. Reject a proposal (and possibly data) and report errors
  4. Accept SRY and ERR messages

3.2 HTTP Extension Framework and P3P

The P3P protocol uses the HTTP Extension Framework [HTTP-EXT]. P3P includes four header extensions, which may be added to any standard HTTP request. The HTTP Extension Framework requires a globally unique URI identifying the extension (the extension declaration). The P3P extension declaration is the following URI:


The P3P extensions are the following:

This describes the status of the P3P message. The status is expressed using a reason code (see Section 3.4).
This contains the propID of the referenced proposal. A propID is meant to be a label that uniquely identifies a proposal at a specified URI (referenced in the proposal extension, see below). Whenever a service changes a proposal at the same URI, it MUST change the corresponding propID (for example, a fingerprint of the proposal could be computed, like [MD5]). The propID MUST not be used for any other purpose beyond identifying and referencing P3P proposals (so, they MUST not be used to maintain user browsing state).
When returning to a web site, user agents SHOULD verify that the propID has not changed. If the propID changes, the user agent SHOULD request the proposal again and re-evaluate it. As an added safeguard, user agents MAY periodically request the proposal again to make sure the proposal was not changed without changing the propID.
This contains the URI where the proposal can be fetched.
This contains, line by line, the XML message encoding the data that the client sends to the server under a specific agreement.

3.3 Protocol Actions

This section describes the actions P3P-compliant clients and servers take to carry out the P3P protocol as an extension to the HTTP protocol. This section includes references to the various error codes that must be reported in carrying out the protocol. These codes are defined and discussed in more detail in section 3.4.

3.3.1 P3P Client Actions

P3P clients MUST be able to:

Request a proposal
To request a proposal from a P3P-compliant server, a P3P-enabled client MUST issue a request that includes either an optional or mandatory P3P HTTP header extension, for example:
Opt: "http://www.w3.org/TR/WD-P3P/"
or Man: "http://www.w3.org/TR/WD-P3P/"

Generally the Opt header should be used. However, if the client wishes to express that it requires P3P support, the mandatory extension may be used along with the methods M-GET, M-POST, etc. A P3P-compliant server should not treat Man headers any differently than it treats Opt headers.

Any request that contains a P3P HTTP header extension is an implied request for a proposal. A P3P-compliant server will always send the propID and proposal P3P extension headers when a relevant proposal is available.

If a client wishes to just request a proposal, without content, the client may issue an OPTIONS or HEAD request.

If a client wishes to simultaneously request a proposal and content, the client SHOULD issue a GET request (or other relevant request). If the server is willing to provide content regardless of whether a P3P agreement is reached, the server will provide the appropriate content along with the propID and proposal P3P extension headers. If the server is not willing to provide content until an agreement is reached, the server will respond with the SRY-AR code in a P3P status header and possibly an HTTP 510 error code. If the proposal is acceptable the client SHOULD repeat the original request, this time including an extension header with the relevant propID.

Note, when a user directs a P3P-compliant user agent to reach agreements with web sites before exchanging data, that client should not transfer data to a URI for which there is no corresponding P3P agreement. Thus, while a POST request is also an implicit request for a proposal, it should not be used that way by clients configured not to transfer data without agreement. Instead an OPTIONS or HEAD request should be made. Once the propID has been obtained, then the POST request can be made. Likewise, clients configured not to transfer data without an agreement should issue an OPTIONS or HEAD request before sending a GET request that includes form data (generally such a request would include a question mark) to a realm with which no agreement exists. In addition, there may be other cases where client implementations may need to be careful not to transfer data prior to reaching an agreement.

Make a request referencing a known proposal
If the client already knows the propID of an appropriate proposal that it finds acceptable, it can make a request that includes a propID header. The client may include a propID header in any standard HTTP request. If the propID is valid, a P3P-compliant server should try to fulfill the request. If the propID is invalid, a P3P-compliant server is expected to respond with an appropriate error in a P3P status header and possibly an HTTP 510 error code.

Submit data under a known proposal
If the client is making a request for which the corresponding proposal requests that data be submitted using P3P methods, the client MUST be able to submit data in a P3P data header attached to that request. All P3P-compliant clients MUST be able to submit data in conjunction with GET and POST requests. They MAY also be able to submit data in conjunction with other HTTP requests.

The client SHOULD submit any required data the first time it includes a given propID in a request. If a client submits a request including a propID and does not submit the required data, the server may request the data by sending a P3P SRY-DR in a status header and possibly also an HTTP 510 error. If the client receives a SRY-DR it SHOULD repeat the request with the required data if it still wishes to access the requested resource.

Report unacceptable proposals and other errors
If none of the proposals offered by a service in proposal headers are acceptable (because the policy is unacceptable, the client doesn't have the requested data, or because of a technical problem such as an invalid propID or syntax error), the client SHOULD respond by repeating the request with the appropriate SRY or ERR code in an extension header. However, clients SHOULD NOT repeat successful POST requests or other requests with side effects. In addition, if the client no longer wishes to access the requested resource, it MAY choose not to respond to an unacceptable proposal. If the service offers multiple proposals and the client finds at least one acceptable, it need not report a SRY or ERR for the others. If it finds all proposals unacceptable and wishes to respond, it SHOULD report a SRY or ERR code for each. Clients MUST take precautions to avoid getting into infinite loops in which they report errors, receive a response from the service, and report errors again.

3.3.2 P3P Server Actions

P3P servers MUST be able to:

Suggest a proposal in response to any request from a P3P-enabled client
P3P-compliant servers MUST include propID and proposal headers in all responses to requests from P3P-enabled clients when a relevant proposal is available. Servers MAY indicate the availability of multiple proposals for a particular resource by including multiple propID and proposal headers in their responses.

When a client requests proposals or human readable privacy policies by issuing a GET request to a URI indicated by a proposal header, P3P LINK tag, or a discuri tag within a proposal, the server MUST fulfill the request without requiring an agreement.

Fulfill a request and accept data under a corresponding proposal
When a request is made that includes a propID header, servers MUST verify that the propID is valid. If the propID is valid, they SHOULD try to fulfill the request. P3P-compliant servers MUST have the ability to accept data submitted in data headers as part of GET and POST requests. They MAY also accept data as part of any HTTP requests.

Reject a proposal (and possibly data) and report errors
When a request is made with an invalid propID, the server MUST respond with the appropriate error code in a status header. If data is submitted with an invalid propID, the data MUST be thrown away. If the request is not fulfilled, the server SHOULD respond with an HTTP 510 error code in addition to the P3P status header.

When reporting errors involving multiple proposals, the server may either report a single error and list all of the propIDs to which that error applies, or it may report an error for each propID. If different errors apply to each propID, they MUST be reported seperately.

Accept SRY and ERR messages
P3P-compliant servers MUST be able to accept SRY and ERR messages from the client and log or report these messages to the server operator.

3.3.3 Protocol Example

The following is an example of how interactions between P3P-compliant clients and servers will typically proceed. Examples of client and server actions are shown in the shaded boxes.

1. Client requests resource using GET or POST or whatever method it pleases. Client also sends P3P extension header to indicate that it is P3P-enabled.

GET coolcatalog.com/index.html HTTP/1.1
Host: coolcatalog.com
Opt: "http://www.w3.org/TR/WD-P3P/"

2a. If server does not a require P3P agreement, the server returns content and propID and proposal headers. Multiple sets of propID and proposal headers may be used to indicate that the server offers a choice of multiple alternative proposals. (Client may optionally fetch and evaluate each proposal before displaying the content.) [If all proposals are unacceptable skip to step 3b, otherwise skip to step 5]

HTTP/1.1 200 OK
Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1
1-propID: Ed3Oorq/ZJbTpVaFRD4qfA==
1-proposal: http://coolcatalog.com/P3PProposal1.xml
Opt: "http://www.w3.org/TR/WD0P3P/"; ns=2
2-propID: 9Pfx3KzqthhRfWxxW1gLnQ==
2-proposal: http://coolcatalog.com/P3PProposal2.xml
. . .
Content-Type: text/html
. . .

2b. If the server requires a P3P agreement, the server returns one or more propID/proposal headers, a status: SRY-AR header, and optionally an HTTP 510 error code.

HTTP/1.1 510 Not Extended
Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1
1-propID: Ed3Oorq/ZJbTpVaFRD4qfA==
1-proposal: http://coolcatalog.com/P3PProposal1.xml
1-status: SRY-AR
Opt: "http://www.w3.org/TR/WD-P3P/"; ns=2
2-propID: 9Pfx3KzqthhRfWxxW1gLnQ==
2-proposal: http://coolcatalog.com/P3PProposal2.xml
2-status: SRY-AR
. . .

(If the client needs to evaluate the proposal, it fetches it by issuing a GET request to the URI indicated by the proposal header. After fetching the proposal, the client may optionally interact with the user to determine whether the proposal is acceptable and/or display information to the user.)

GET coolcatalog.com/P3PProposal1.xml HTTP/1.1
Host: coolcatalog.com
Opt: "http://www.w3.org/TR/WD-P3P/"

3a. If the proposal is acceptable, the client resubmits the request, this time including propID and any requested data. (If more than one proposal is available, the client should select only one and include the corresponding propID in its response.)

GET coolcatalog.com/index.html HTTP/1.1
Host: coolcatalog.com
Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1
1-propID: Ed3Oorq/ZJbTpVaFRD4qfA==
1-data: <TXD xmlns="http://www.w3.org/TR/WD-P3P/syntax"
1-data: <DATA:REF name="user.name.first" value="Sheila">
1-data: <DATA:REF name="user.name.second" value="Doherty">
1-data: </TXD>
. . .

3b. If the proposal is not acceptable or if there is some other error, the client repeats the request with the appropriate SRY or ERR header (unless the request was a successful POST request or some other request that would have an undesirable side effect if repeated). [return to step 2 but client should give up after a small number of failed attempts to avoid infinite loop]

GET coolcatalog.com/index.html HTTP/1.1
Host: coolcatalog.com
Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1
1-propID: Ed3Oorq/ZJbTpVaFRD4qfA==
1-status: SRY-PR
Opt: "http://www.w3.org/TR/WD-P3P/"; ns=2
2-propID: 9Pfx3KzqthhRfWxxW1gLnQ==
2-status: SRY-PR

Alternatively, this may be written:

GET coolcatalog.com/index.html HTTP/1.1
Host: coolcatalog.com
Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1
1-propID: Ed3Oorq/ZJbTpVaFRD4qfA==
1-propID: 9Pfx3KzqthhRfWxxW1gLnQ==
1-status: SRY-PR

4a. If the propID is valid and there are no problems, the server returns content plus proposal/propID headers.

HTTP/1.1 200 OK
Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1
1-propID: Ed3Oorq/ZJbTpVaFRD4qfA==
1-proposal: http://coolcatalog.com/P3PProposal1.xml
. . .
Content-Type: text/html
. . .

4b. If there is some other problem (for example, the client did not actually send the required data), the server returns a status header with the appropriate SRY or ERR code, and proposal/propID headers. The server may optionally return an HTTP 510 error code if the request is not fulfilled. [return to step 3 to try again, but client should give up after a small number of failed attempts to avoid infinite loop]

HTTP/1.1 510 Not Extended
Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1
1-propID: Ed3Xorq/ZJbTpVaFRD4qfA==
1-status: SRY-DR
2-propID: Ed3Oorq/ZJbTpVaFRD4qfA==
2-proposal: http://coolcatalog.com/P3PProposal1.xml
Opt: "http://www.w3.org/TR/WD-P3P/"; ns=2
3-propID: 9Pfx3KzqthhRfWxxW1gLnQ==
3-proposal: http://coolcatalog.com/P3PProposal2.xml
. . .

[time passes]

5. The client requests the same resource as before. It includes a propID header in order to indicate that it agrees to the proposal.

GET coolcatalog.com/index.html HTTP/1.1
Host: coolcatalog.com
Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1
1-propID: "Ed3Oorq/ZJbTpVaFRD4qfA=="
. . .

6a. If the agreement is still valid and the server doesn't need the data again (or if the server does not require a P3P agreement), it simply returns the content, together with proposal/propID headers (as in step 4a).

HTTP/1.1 200 OK
Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1
1-propID: Ed3Oorq/ZJbTpVaFRD4qfA==
1-proposal: http://coolcatalog.com/P3PProposal1.xml
. . .
Content-Type: text/html
. . .

6b. If the agreement is still valid, but the server needs the data again, it asks the client to resubmit data by sending a status: SRY-DR header and optionally an HTTP 510 error code. [continue to step 3]

HTTP/1.1 510
Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1
1-propID: Ed3Oorq/ZJbTpVaFRD4qfA==
1-proposal: http://coolcatalog.com/P3PProposal1.xml
1-status: SRY-DR
. . .

6c. If there is some other problem, the server returns a status header with the appropriate SRY or ERR codes, proposal/propID headers, and optionally an HTTP 510 error code. [return to step 5 to try again, but client should give up after a small number of failed attempts to avoid infinite loop]

HTTP/1.1 510
Opt: "http://www.w3.org/TR/WD-P3P/"; ns=1
1-propID: Ed3Oorq/ZJbTpVaFRD4qfA==
1-status: ERR-IF
1-proposal: http://coolcatalog.com/P3PProposal1.xml
. . .

3.4 Error messages

Each protocol action can trigger an error, due to various reasons. For example, the proposal could be malformed, or the referenced agreement could be unknown, and so forth. An error message is issued using the following P3P extensions:

Reason codes are sent in the status extention headers and indicate the state of a proposal or data -- potentially -- in the context of a previous interaction. P3P extensions must only include status headers when they are reporting errors. In all the other cases (that is to say, when  receipt of the contents of the proposal or data extension have been completed successfully), no status header must be included. Applications that do not understand the status extension must ignore the p3p-message.
Reason Token Description Sent by Explaination
SRY-AR the agreement is required server Sent (together with a propID) if a prior agreement (corresponding to the propID) is required. Clients should evaluate the proposal (this might require them to download it first) and according to the user's preferences resubmit (with or without data), send a SRY(-PR) or end the communication.
SRY-AU the agreement is unkown server Sent if a client sent an unkown propID along with its request. If a new proposal is available that requires agreement, the site would also have to send a SRY-AR (see above). If no "SRY-AR" is present, client can re-submit the request without referencing any propID.
SRY-DR the data is required server Sent if the client agreed to an agreement (referenced by the corresponding propID), but did not send the proper data. Clients would need to resubmit the same request but also include the required (according to the proposal) data, if they want to access the resource.
SRY-DU the data is unavailable client Sent if a client cannot provide the requested data, because they are not available.
SRY-PR the proposal is rejected client Sent if the proposal is unacceptable. Servers can log this and optionally redirect the client or offer a different page/proposal.
SRY sorry server or client Sent if receipt of the contents of the proposal or data extension failed, despite syntactically correct, and all the other SRY- codes are not applicable, or for privacy reasons (see afterwards).
ERR-IF invalid format server or client The P3P message that was received was syntactically invalid or semantic garbage.
ERR-TF data transfer failed server or client the transfer request was received, and it was syntactically valid, and covered by a valid agreement, but the data could not be stored for some reason
ERR error server or client a request was not understood or received properly. This code can be sent when all the other ERR- codes are not applicable, or for privacy reasons (see afterwards).

Note that if, for privacy reasons, the client does not want to divulge its reasons for refusing a proposal, the client can reply with the generic SRY code, rather than with a more specific SRY-  code. The same holds for the error messages (ERR can be used rather than a specific ERR-), although it is advisable that ERR-IF and ERR-TF are used whenever possible.

Server MUST at least support sending out SRY-AR and ERR. Clients MUST understand at least the three specific SRY- error codes that can be sent by the server, that is to say they MUST be able to (if the user wants) accept a proposal (by sending the propID) and send data if necessary (again at the user's discretion). In case of SRY-AU, clients MUST be able to resubmit the request without referencing a (probably outdated or unknown) propID.

Finally, note than more than one reason codes can be used to specify an error status; for example, a client as a response to proposal suggestion by the server could return SRY-DU to indicate some requested data is not available, and ERR-IF to indicate that some part of the proposal was syntactically incorrect too:

HTTP/1.1 200 OK
Opt: "http://www.w3.org/TR/WD-P3P/"; ns=14
14-status: SRY-DU
14-status: ERR-IF
14-propID: 94df1293c1p8
14-proposal: http://www.privacy.org/newP3PProposal

3.5 Limited Protocol

A limited version of the P3P protocol may be executed without using the HTTP header extension mechanism. Instead, servers may serve HTML content with embedded LINK tags that indicate the location of relevant P3P proposals. This limited protocol requires a P3P-aware client, but does not require a P3P-aware server (content may be modified to include the embedded link tags without requiring any changes to the way the server operates).

A service that uses the limited protocol may declare that it will abide by a given P3P proposal by embedding a LINK tag of the following form in the <HEAD> area of an HTML document:

<LINK rel="p3p:propID" href="URI">

URI indicates the location of the P3P proposal and "p3p:propID" is a relation name used to distinguish this special P3P link and to encode the propID of the proposal. For example, if a proposal at http://www.privacy.org/P3PProposal has propID x3tYwafhfKSqGV0Q+eSOZw==, we would use <LINK rel="p3p:x3tYwafhfKSqGV0Q+eSOZw==" href="http://www.privacy.org/P3PProposal">.

P3P-compliant clients MUST search for such LINK tags whenever they make a request that results in the return of HTML content without the inclusion of propID and proposal headers. In addition, P3P-compliant clients MAY search for LINK tags embedded in HTML content at any time. If a client finds a P3P LINK tag in addition to propID and proposal headers in the same document, it should consider them to reference multiple alternative proposals.

The limited protocol is not suitable for services that wish to use P3P methods for data collection, offer a choice of proposals, or require explicit agreement to proposals.

The following is an example of how interactions between P3P-compliant clients and non-P3P-compliant servers will typically proceed. Examples of client and server actions are shown in the shaded boxes.

1. Client requests resource using GET or POST or whatever method it pleases. Client also sends P3P extension header to indicate that it is P3P-enabled.

GET coolstore.com/index.html HTTP/1.1
Host: coolstore.com
Opt: "http://www.w3.org/TR/WD-P3P/"

2. Server is not P3P enabled so it ignores the P3P extension header (unless it is a mandatory extension and/or the server is not extension enabled, in which case the server reports back that it is not P3P enabled) and sends the requested content.

3. Client checks the returned content for an embedded link tag with attribute rel="p3p:propID". If no such link tag exists and the requested resource is not in a realm with which the client already has an agreement, the client can assume there is no P3P proposal available and behaves accordingly. If the link tag does exist, the client may fetch the proposal by issuing a GET request to the URI indicated by the href attribute of the link tag, evaluate the proposal, and act according.

Note, in all cases the appropriate behavior after evaluating a proposal and/or determining that no proposal exists depends on the user's preferences and how the client is configured. Clients may proceed with a request, display information, prompt the user, or take some other action.

4. P3P markup and processing

This section describes the syntax and semantics of P3P proposals as well as for blocks of user data transmitted between a user agent and a service. A more complete English language description of the terms used in a proposal may be found in [HARMV].

We begin with an example of an English language privacy policy and a corresponding P3P proposal in Section 4.1. P3P proposals include general assertions that apply to the entire proposal as well as specific assertions -- called statements -- that apply only to the handling of particular types of data referred to by data references. Section 4.2 describes the proposal element and proposal-level assertions. Section 4.3 describes the TXD element that is used to transfer data blocks. Section 4.4 describes statements and data references.

In the sections that follow we introduce a number of XML elements. Each element is given in <> brackets, followed by a list of valid attributes and an XML name space (xmlns). All listed attributes are optional, except when tagged as mandatory.

4.1 Example proposal

4.1.1 English language proposal

The following is an example of an English-language privacy policy that we would like to encode as a P3P proposal.

CoolCatalog makes the following statement for the Web pages at http://www.CoolCatalog.com/catalog/.

We use cookies and collect, via a web form, your gender and (optionally) your home address to customize our entry catalog pages and for our own research and product development. We do not use this information in identifiable form.

We also maintain server logs that include information about the what pages on our site are visited and the types of browsers our visitors use. We use this information in order to maintain and improve our web site. We do not use this information in an identifiable way.

We do not provide access capabilities to information we may have from you, but we do have retention and opt-out policies, which you can read more about at our privacy page  http://www.CoolCatalog.com/PrivacyPractice.html. The third-party PrivacySeal.org provides assurance that we abide by this agreement.

The following is a more formal description, using the P3P element and attribute names, with their numeric values in parentheses:

Entity: http://www.CoolCatalog.com/
Realm: http://www.CoolCatalog.com/catalog/
Disclosure URI: http://www.CoolCatalog.com/PrivacyPractice.html
Access to Identifiable Information: none
Assurance: PrivacySeal.org
Other disclosures: Change agreement, retention

We collect:
    user.home.  (optional)
For purpose: Customization of the site to individuals, research and development
Identifiable use: No
Recipients: Only ourselves and our agents
Consequence: A site with clothes you would appreciate

We collect:
For purpose: Web site and system administration, research and development
Identifiable use: No
Recipients: Only ourselves and our agents

4.1.2 XML/RDF encoding of proposal

The following piece of [RDF] captures the information as expressed above. P3P proposals are statements that are properly expressed according to the syntax model of [RDF] as well as well-formed XML. However, there are two assumptions, used to make the proposal shorter, that slightly differentiate a P3P proposal from standard RDF. If the XML/RDF data is homogeneously P3P then the enclosing RDF tags may be optionally omitted. The proposal syntax will be explained in more detail in the sections that follow.

<RDF:RDF xmlns:RDF="http://www.w3.org/TR/WD-rdf-syntax">
<PROP xmlns="http://www.w3.org/TR/WD-P3P/syntax" 
  <ASSURANCE org="http://www.PrivacySeal.org" 
   text="third party" image="http://www.PrivacySeal.org/Logo.gif"/>
  <REALM uri="http://www.CoolCatalog.com/catalog/">
  <VOC:DISCLOSURE discuri="http://www.CoolCatalog.com/PrivacyPractice.html" 
   access="none" retention="yes" change_agreement="yes"/>
  <STATEMENT VOC:id="nonid">
     <CONSQ v="a site with clothes you would appreciate"/>
<VOC:RECPNT v="ours"/>
<VOC:PURPOSE v="uniqueid"/>
<VOC:PURPOSE v="financial"/>      <DATA:REF name="dynamic.cookies" source="service"/>      <DATA:REF name="user.gender" source="matched-form"/>      <DATA:REF name="user.home." optional="yes" source="matched-form"/>   </STATEMENT>   </USES>   <USES>   <STATEMENT VOC:id="nonid">
<VOC:RECPNT v="ours"/>
<VOC:PURPOSE v="admin"/>
<VOC:PURPOSE v="develop"/>     <DATA:REF name="dynamic.clickstream.server" source="service"/>     <DATA:REF name="dynamic.http.useragent" source="service"/>   </STATEMENT>   </USES> </PROP> </RDF:RDF>

4.2 Proposals

This section defines the key elements, attributes and processing heuristics for operating on a proposal. All proposals are encoded using [UTF-8].

4.2.1 The PROP element

<PROP> (xmlns="http://www.w3.org/TR/WD-P3P/syntax")
includes one or more statements. Each statement includes a set of disclosures as applied to a set of data elements.
entity (mandatory attribute)
URI referencing a domain name and path that can be associated with the legal entity making the representation of the privacy practices contained in the proposal.

(`<RDF:RDF xmlns:RDF="http://www.w3.org/TR/REC-rdf-syntax/">`

`<PROP xmlns="http://www.w3.org/TR/WD-P3P/syntax" 
" entity=" quoted-URI  

4.2.2 The REALM element

<REALM> (xmlns="http://www.w3.org/TR/WD-P3P/syntax")
describes the realm of the proposal (the URIs to which the proposal applies)
uri (mandatory attribute)
the URI to which the proposal applies

 " uri=" quoted-URI

The URIs specified by REALM define the scope of the agreement (the "realm"). This information is used by the user agent, for example, to determine whether there is an existing agreement with the service. Each of the Realm URIs should "domain-match" [STATE] the domain of the server.

Each URI may name a specific resource or a set of resources qualified by the URI. In the HTTP URI scheme, a URI ending in "/" references the file system tree below that path (for example, http://www.w3.org/P3P/" would apply to "http://www.w3.org/P3P/foo/schema.html" as well); on the other hand, a URI  that does not end in "/" would apply only to that specific resource (for example, "http://www.w3.org/P3P/data.html" wot apply to "http://www.w3.org/P3P/foo/schema.html").

User agents should record the realms with which an agreement has been reached and the corresponding propIDs and store them for as long as the agreements remain valid (or as long as feasible). When returning to any part of a realm previously visited, the user agent should include the relevant propID in its requests to the service.


P3P is designed around HTTP and related schemes (such as HTTPS). Specifically in the case of HTTP and HTTPS, agreements reached using HTTP implicitly cover URI requests that use the HTTPS scheme (but not vice versa). For example, if a user reaches an agreement with realm "http://www.romulus.com/", then "https://www.romulus.com/" is considered part of the realm. However, if the user reached an agreement with realm "https://www.romulus.com/", then "http://www.romulus.com/" is not subject to the agreement. Agreements may be reached regarding realms that include other schemes such as FTP; however, the agreement must be reached by conducting the protocol over HTTP (or HTTPS) or through links embedded in HTML content. The protocol may be extended in the future to cover data exchange and negotiation using other schemes, such as FTP or NNTP.

4.2.3 The DISCLOSURE element

<DISCLOSURE> (xmlns="http://www.w3.org/TR/WD-P3P/syntax")
simple disclosures regarding service access capabilities, and binary values as to whether the entity makes disclosures regarding changing the agreement (opt-out) for data already collected and how long data is retained.
discuri (mandatory attribute)
URI of the natural language privacy statement of the proposal, which should include information on how to contact the service with questions or concerns.
the ability of the individual to view identifiable information and address questions or concerns to the service provider.
does the site make its policy regarding retention known at its discuri?
does the site make its policy regarding change agreement known at its discuri?

The values of [5] are provided for reference only. The normative specification is in the harmonized vocabulary [HARMV] document.
" discuri=" quoted-URI
" access=" `"` access-disclosure `"`
[" retention=" `"` yesno `"`]
[" change_agreement=" `"` yesno `"`] "/>"
"nonident" | ; Identifiable Data is Not Used
"contact"  | ; Identifiable Contact Information
"other"    | ; Other Identifiable Information
"contact_and_other" | ; Identifiable and other contact information "none" ; None
"yes" | "no"

4.2.4 The ASSURANCE element

<ASSURANCE> (xmlns="http://www.w3.org/TR/WD-P3P/syntax")
describes a services that attests that the entity will abide by its proposal, follows guidelines in the processing of data, or other relevant assertions.
URI of the assurance service
short textual description of the type of assurance service (e.g., third party, legal, etc.)
URI of an image logo of the assurance service
width in pixels of the image logo
height in pixels of the image logo
very short textual description of the image logo

 " service=" quoted-URI
 [" text=" quoted-string]
 [" image=" quoted-URI
 [" width=" `"` number `"`]
 [" height=" `"` number `"`]
 [" alt=" quoted-string]

Note that there can be multiple assurance services, specified via multiple occurrences of ASSURANCE.

4.2.5 Semantics of a Proposal

If a website links to a P3P proposal, the website is stating that it is willing to honor that proposal for any user agent that sends a reference to that proposal to the website in the header of its http requests.

If a website links to multiple P3P proposals, this means that the website is only bound by the P3P proposal that the user agent chooses out of the multiple proposals. The user agent signals that it has chosen a specific P3P proposal by sending a reference to that proposal in the headers.

A website is not bound by any P3P proposal if the user agent does not reference a P3P proposal in the headers of its requests, even if that website has only one P3P proposal. Therefore user agents that do not support p3p do not bind the website to any particular P3P proposal. Furthermore, the first request a user agent makes of a website is unlikely to be covered by any P3P proposals, since the user agent probably does not yet know what P3P proposal to reference in the headers of the request.

Websites with web servers that do not support p3p should avoid linking to multiple proposals, as the website probably has no way of determining which proposal the user agent has chosen. If, despite this advice, a website links to multiple proposals, the website is bound to somehow honor whichever proposal the user agent has selected, no matter what difficulty this places on the website.

4.3 Data Transmission

The client sends data referencing a specific agreement to the service (see Section 3.3.2) by transmitting an XML/RDF message in the header.

<TXD> (xmlns="http://www.w3.org/TR/WD-P3P/syntax")
indicates that a block of data is returned under an agreement referenced by the propID

(`<RDF:RDF>` txd-block `</RDF:RDF>`) |

`<TXD xmlns="http://www.w3.org/TR/WD-P3P/syntax"

When TXD messages are sent as HTTP header extensions, line breaks should be inserted after each closing angle bracket >. In addition, the appropriate prefix must be inserted on each line. For example:

42-data: <TXD xmlns="http://www.w3.org/TR/WD-P3P/syntax" xmlns:VOC="http://www.w3.org/TR/WD-P3P/vocab" xmlns:DATA="http://www.w3.org/TR/WD-P3P/basedata">
42-data: <DATA:REF name="user.name.first" value="Sheila"/>
42-data: <DATA:REF name="user.name.Last" value="Doherty"/>
42-data: <DATA:REF name="user.name.Title" value="Miss"/>
42-data: </TXD>

4.4 Statements

Statements describe data practices that are applied to particular types of data.

4.4.1 The STATEMENT element

<STATEMENT> (xmlns="http://www.w3.org/TR/WD-P3P/syntax")
data practices as applied to data elements.
id (mandatory attribute) (xmlns:VOC="http://www.w3.org/TR/WD-P3P/vocab")
specifies if data used in a  way that is personally identifiable (including linking it with identifiable information about you from other sources)
consequences that can be shown to a human user to explain why the suggested practice may be valuable in a particular instance even if the user would not normally allow the practice.

" VOC:id=" `"` idvalue `"` ">" *(consequence) *(purpose) *(recipient) *(data-reference) "</STATEMENT>" "</USES>"
The values of [11-13] are provided for reference only. The normative specification is in the harmonized vocabulary [HARMV] document.
"current" | ; Completion and Support of Current Activity
"admin"   | ; Web Site and System Administration
"custom"  | ; Customization of the Site to Individuals
"develop" | ; Research and Development
"contact" | ; Contacting Visitors for Marketing of Services or Products
"other" [" (" string ")"] ; Other Uses

"ours" | ; only ourselves and our agents
"same" | ; organizations following our practices
"other" | ; organizations following different practices
"published"   ; unrelated third parties or public forum

"nonid" | ; non identifiable
"id" ; identifiable

4.4.2 The CONSQ element

<CONSQ> (xmlns="http://www.w3.org/TR/WD-P3P/vocab")
consequences that can be shown to a human user to explain why the suggested practice may be valuable in a particular instance even if the user would not normally allow the practice.
v (mandatory attribute)
the corresponding value
the language in which the consequence is expressed

Multiple consequences can be indicated using multiple CONSQ elements, each with one of the consequences. This way, multi-lingual versions of the consequences can be encoded, using the xml:lang attribute.

"<CONSQ v=" quoted-string [xml:lang= LanguageID ] "/>"

xml:lang and its value type LanguageID are defined in the [XML] specification.

4.4.3 The PURPOSE element

<PURPOSE> (xmlns="http://www.w3.org/TR/WD-P3P/vocab")
purposes for data processing relevant to the Web.
v (mandatory attribute)
the corresponding value

Multiple values can be indicated using multiple PURPOSE elements, each with one of the values.

"<VOC:PURPOSE v=" `"` purposevalue `"` "/>"

The values of [16] are provided for reference only. The normative specification is in the harmonized vocabulary [HARMV] document.
"current" | ; Completion and Support of Current Activity
"admin"   | ; Web Site and System Administration
"custom"  | ; Customization of the Site to Individuals
"develop" | ; Research and Development
"contact" | ; Contacting Visitors for Marketing of Services or Products
"other" [" (" string ")"] ; Other Uses

4.4.4 The RECPNT element

<VOC:RECPNT> (xmlns="http://www.w3.org/TR/WD-P3P/vocab")
the organizational area, or domain, beyond the service provider and its agents where data may be distributed.
v (mandatory attribute)
the corresponding value

Multiple values can be indicated using multiple RECPNT elements, each with one of the values.

"<VOC:RECPNT v=" `"` recipientvalue `"` "/>"

The values of [17] are provided for reference only. The normative specification is in the harmonized vocabulary [HARMV] document.
"ours"  | ; only ourselves and our agents
"same"  | ; organizations following our practices
"other" | ; organizations following different practices
"published" ; unrelated third parties or public forum

4.4.5 The REF element

<REF> (xmlns="http://www.w3.org/TR/WD-P3P/basedata" as default)
describes the data to be transferred or inferred
name (mandatory attribute)
a string denoting the name of a data element/set. Sets and elements are syntactically distinguished by the presence of a trailing dot after the set name. For example, the trailing dot indicates that user.Home. is a data set. Remember that names are case-sensitive (so, for example, user.Home. is different from USER.HOME. or user.home.). Furthermore, in names no underscore symbol ("_") can be present, and no number character can appear immediately following a dot.
string denoting the actual value of the data element specified in the name attribute. In the case of a data element request, the value attribute is missing.
"no" or "yes". "no" indicates that the data element is required, while "yes" indicates that the data element is not required. The default is "no". The optional attribute is used only in proposals. Services may use the optional attribute to indicate that a data request is optional. User agents may send or ignore optional attributes according to the user's preferences. Note that P3P does not include a mechanism for specifying that certain data practices are optional. If services wish to give users a choice of data practices, for example, whether or not data is used for marketing, they may do so by providing multiple alternative proposals that users may choose from.
source (mandatory attribute)
specifies the mechanism for data transfer
category (xmlns="http://www.w3.org/TR/WD-P3P/vocab")
a string denoting the categories of a data element.

The following six attributes are only used when a new (not defined in the P3P [BASEDATA]) data element or set is referenced.

a string denoting the type of a data element/set.
a URI denoting the data schema where the type specified in the type attribute is defined.
specifies whether or not the corresponding data element is part of a type definition only. If set to 1, this means that that the data element is a type definition, and is not actually representing a data element with an associated value. The default value is 0.
a string denoting the short display name of the data element/set, no more than 127 [UTF-8] characters.
a string denoting a longer description of a data element/set, no more than 1023 [UTF-8] characters.
denotes the maximum number of [UTF-8] characters that are needed to store the data element. The default value of 0 indicates that the data element can be arbitrarily large.

In addition, the namespace of REF can be overridden, using for example an in-line xmlns attribute, with an  URI denoting the name of the data schema the data element/set specified in name belongs to. The default namespace of REF is declared in the PROP element, but it can be overridden using a local namespace declaration in a DATA:REF element.

"<DATA:REF" " name=" quoted-string 
" source=" `"` sourcevalue `"` 
[" optional=" yesno] [" value=" quoted-string] 
[" type=" quoted-string] [" typeschema=" quoted-string] 
[" template=" yesno] [" VOC:category=" category] 
[" short=" quoted-string] [" long=" quoted-string]
[" size=" `"` number `"`] ; default is 0 (unlimited size)

"service"      |
"agent"        |
"matched-form" |

Example: To request the user's home address city, all the elements of the data set user.business. and (optionally) all the elements of the data set user.home.phone and collect them through a matched form,  the service would send the following references inside a P3P proposal:

<DATA:REF name="user.home.city" source="matched-form"/>
<DATA:REF name="user.home.phone." optional="yes" source="matched-form"/>
<DATA:REF name="user.business." source="matched-form"/>

If the user agrees to returning the city and business information and only the international phone code and local area code of her home phone number, she returns the following inside the txd tag:

<DATA:REF name="user.home.city" value="Cambridge"/>
<DATA:REF name="user.home.phone.intcode" value="1"/>
<DATA:REF name="user.home.phone.loccode" value="617"/>
<DATA:REF name="user.business.street" value="254 Windsor St."/>
<DATA:REF name="user.business.city" value="Cambridge"/>
... (the other values of user.business.) ...

4.4.6 Null Values

In some cases, only some of the values in a data set could have a value (for example, the user could not have a home page, or a fax, or a middle name, etc.). That is to say, for some elements there can be no defined value at all in the user's repository: in such case, elements are said to have a null value. The way a client signals that an element has a null value is simply by omitting the corresponding DATA:REF reference. For example, if a client agrees to provide all the user's name information (user.name.), and then sends

<DATA:REF name="user.name.first." value="Sheila"/>
<DATA:REF name="user.name.last" value="Doherty"/>
<DATA:REF name="user.name.formatted" value="Sheila Doherty"/>

that means that in the user's repository all the other fields (prefix, suffix, middle name, nickname) are not defined.

4.4.7 The source attribute

The source attribute specifies a mechanism for transferring data from the user agent to the service. We define three standard mechanisms, and an extensibility mechanism that allows new data transfer mechanisms to be defined in the future. The standard mechanisms are as follows:

The service solicits and collects the data using a method that requires no active involvement of the P3P user agent (for example, standard HTML forms, data collected from standard HTTP header stream, inferred data, etc.). Thus the service maintains full control over the presentation of any prompts to the user. However, the service may not take advantage of the user data repository.
The P3P agent must prompt the user for data and/or retrieve data from the user's data repository. The agent must transfer the data to the service using the HTTP header extension mechanism. The service has no control over how the user will be prompted for the data if it is not available in the repository. User agents should incorporate the short and/or long display names into their prompts rather than using the element name.
The service solicits data through a form in the associated HTML content in which the names of the form fields match the data references in the proposal. The form field names should use an underscore ("_") notation instead of the normal P3P dot (".") notation to separate different components of the attribute name (allowing interoperability with client-side javascript). For example, user.name.first in a P3P proposal would be referenced as user_name_first in an HTML form. Thus agents may optionally fill out the form with data from the user's repository. When using this method the service maintains full control over the presentation of user prompts, but may take advantage of the user data repository if the user agent has auto-fill support. If the user agent does not have this support (or if none of the requested data is stored in the repository), a standard HTML form is displayed.
A service may also wish to transfer data using another mechanism not defined here, such as an electronic commerce wallet. In that case, the service should specify source="extension" to indicate that data will be collected using that mechanism.

<REF> elements should always include a source attribute with exactly one value., except when they occur in a data schema definition. In that case the attribute may be left out entirely, it may take one value, or it may take multiple values (the latter case is obtained by multiple <REF> elements referencing the same data but with different source's).

4.5 Categories

Categories are attributes of data elements that provide hints to users and user agents as to the intended uses of the data. Categories are vital to making P3P user agents easier to implement and use; they allow users to express more generalized preferences and rules over the exchange of their data. Categories are often included when defining a new element or when referring to data that the user is prompted to type in (as opposed to data stored in the user data repository).

In the current version of P3P, the following tokens are used to denote data categories:

"physical"    | ; Physical Contact Information
"online"      | ; Online Contact Information
"uniqueid"    | ; Unique Identifiers
"financial"   | ; Financial Account Identifiers
"computer"    | ; Computer Information
"navigation"  | ; Navigation and Click-stream Data
"interactive" | ; Interactive Data
"pref"        | ; Preference Data
"demograph"   | ; Demographic and SocioEconomic Data
"content"       ; Content

While we specify the category attribute for reference purposes, the normative definitions and values, as well as a more detailed explanation of each category, can be found in the P3P Harmonized Vocabulary Specification [HARMV].

P3P uses categories to give users and user agents additional hints as to what type of information is requested from a services. While most data in the Base Data Set is in a known category (or a set of known categories), some data elements can be in a number of different categories, depending on the situation. The former are called fixed-category data elements (or "fixed data elements" for short), the latter variable-category data elements ("variable data elements"). We will briefly describe both types of elements in the two sections below.

4.5.1 Fixed-Category Data Elements

Most of the elements in the base data set are so called "fixed" data elements: they belong into one or at most two category classes. By assigning a category invariably to elements in the base data set, services and users are able to refer to entire groups of elements simply by referencing the corresponding category. For example, using APPEL, the privacy preferences exchange language, users can write rules that prevent their user agent from giving out any data element in a certain category.

When creating new data schemas (see the next section "Creating New Data Sets") for fixed data elements, schema creators have to explicitly enumerate the categories that these element belong to. For example:

<DATA:REF name="postal.street.line1"     type="text"
          short="Street Address, Line 1" VOC:category="physical" template="yes"/>

In case of multiple categories, multiple elements referencing the same data can be used, each with a different category). For example, in case we want to declare that the data elements in user.name. have both category "physical" and "demograph" we can use:

<DATA:REF name="user.name."     type="personname."
          short="User's Name" VOC:category="physical" template="yes" />

<DATA:REF name="user.name."     type="personname."
          short="User's Name" VOC:category="demograph" template="yes" />

Please note that the category classes of fixed data elements can not be overridden, for example by writing rules or proposals that assign a different category to a known fixed base data element. User Agents MUST ignore such categories and instead use the original category (or set of categories) listed in the schema definition. User Agents CAN preferably alert the user that a fixed data element is used together with a non-standard category class.

4.5.2 Variable-Category Data Elements

Not all data elements in the base data set belong to a pre-determined category class. Some elements can contain information from a range of categories, depending on a particular situation. Such elements are called variable-category data elements (or "variable data element" for short). Although most variable data elements in the P3P Base Data Set are combined in the dynamic. element set, they can appear in any data set, even mixed with fixed-category data elements.

When creating a schema definition for such elements, schema authors MUST NOT list an explicit category attribute, otherwise the element becomes a fixed data element. For example when specifying the "Year" data type, which can take various categories depending on the situation (e.g. when used for a credit card expiration date vs. for a birth date), the following schema definition is used:

<DATA:REF name="date.year" type="number" size="6"
          short="Year"     template="yes"/>  <!-- Variable Data Element -->

This allows new schema extensions that reference such variable-category data types to assign a specific category to derived elements, depending on their usage in that extension. For example, an E-commerce schema extension could thus define a credit card expiration date as follows:

<DATA:REF name="Card.ExpDate."         type="date."
          short="Card Expiration Date" VOC:category="financial" template="yes"/>

Under these conditions, the variable data type date. is assigned a fixed category Financial Account Identifiers when being used for specifiying a credit card expiration date. Please see the next section "Creating New Data Sets" for more information.

Note that while user preferences can list such variable data elements without any additional category information (effectively expressing preferences over any usage of this element), services MUST always explicitly specify the categories that apply to the usage of a variable data element in their particular proposal. This information has to appear as an attribute to the corresponding DATA:REF element listed in the proposal, for example as in:

   <DATA:REF name="dynamic.cookies" VOC:category="uniqueid">

where a service declares that cookies are used for identifying the user at this site (i.e. category Unique Identifiers).

4.6 Creating New Data Sets

Services may declare and use new data elements by creating a data schema and referencing it in a proposal using the DATA namespace (xmlns:DATA). When data elements beyond those defined in the base data set [BASEDATA] are referenced in a proposal, the DATA:REF element must include values for the following attributes: name, category, type, typeschema, and short (typeschema may be omitted if it has the same value as the DATA namespace). If the data schema URI does not domain match the origin server URI, user agents MUST check the data schema to verify the consistency of the information. Otherwise the information in the main data schema MAY be checked in order to verify consistency of the information. In case of a mismatch, either an ERR-IF reason code (Invalid Format) or the generic ERR code must be returned. If for any other reason the user is unable to reconstruct the needed information, either a SRY-DU reason code (Data Unavailable) or a generic SRY code must be returned.

The format of a new data schema is a special proposal of the form

<PROP xmlns="http://www.w3.org/TR/WD-P3P/syntax" 

A data block is enclosed within the <STATEMENT> tag and contains references to the new data elements. References can be made using the <DATA:REF> tag and the following attributes: name, type, typeschema, template, VOC:category, short, long, size, source.

For every data element, all of the information except long  and source are mandatory. If source is present, it indicates that the element must only be collected using the specified data transport mechanism. If source is missing, there are no restrictions placed on how the element may be collected. If any attribute is missing, it is presumed to be present with an empty string. In the case of the typeschema, the empty string value has the special meaning that the type schema coincides with the namespace of the corresponding REF element.

For example, suppose the company HyperSpeed wants to build the following data schema:

car.built.where. (of basic type postal.)
bike.built.where. (of basic type postal.)

Then, it could place the following code at http://www.HyperSpeed.com/models-schema

<PROP xmlns="http://www.w3.org/TR/WD-P3P/syntax" 
<USES><STATEMENT VOC:id="nonid">
<VOC:RECPNT v="ours"/>
<VOC:PURPOSE v="contact"/>  <DATA:REF name="car.model" type="text" short="Model"     VOC:category="pref" size="63"/>  <DATA:REF name="car.color" type="text" short="Color"     VOC:category="pref" size="63"/>  <DATA:REF name="car.built.year" type="number" short="ConstructionYear"     VOC:category="pref" size="63"/>  <DATA:REF name="car.built.where." type="postal."  short="Construction Place"     VOC:category="pref" size="63"/>  <DATA:REF name="bike." type="car."     typeschema="http://www.HyperSpeed.com/models-schema"/> </USES></STATEMENT></PROP>

Note that every time a data set is created, it can be implicitly used as a type, just like the car. case above. However, in some situations one may wish to define a type without creating a specific element within the user's repository. This can be accomplished by using the template attribute in the <DATA:REF> . Setting the value to yes, template="yes" (default is "no"), means that the corresponding data element is part of a type definition only, and is not actually representing a data element with an associated value. For example, HyperSpeed might want to define a GenericModel. type of general utility, and then instantiating it with car. and bike. This could be done with the following schema:

<PROP xmlns="http://www.w3.org/TR/WD-P3P/syntax" 
<USES><STATEMENT VOC:id="nonid">
<VOC:RECPNT v="ours"/>
<VOC:PURPOSE v="contact"/>  <DATA:REF name="GenericModel.model" type="text" short="Model" template="yes"     VOC:category="7" size="63"/>  <DATA:REF name="GenericModel.color" type="text" short="Color" template="yes"     VOC:category="7" size="63"/>  <DATA:REF name="GenericModel.built.year" type="number" short="Construction Year"     template="yes" VOC:category="7" size="63"/>  <DATA:REF name="GenericModel.built.where." type="postal."     short="Construction Place" template="yes" VOC:category="7" size="63"/>  <DATA:REF name="car." type="GenericModel."     typeschema="http://www.HyperSpeed.com/models-schema" short="Car"/>  <DATA:REF name="bike." type="GenericModel."     typeschema="http://www.HyperSpeed.com/models-schema" short="Bike"/> </USES></STATEMENT></PROP>

Creators of new schema should be aware that unless they place restrictions on the source attribute (i.e. source="service" or use an extension that does not store data in the user data repository), user agents may automatically store elements from the new schema in the user data repository after the user types them in. Some implementations may include user data repositories that do not use security measures appropriate for storing sensitive data.

In order to provide multilingual support for data schema files, a server can supply the right alternative based on the HTTP Accept-Language header.

P3P allows users to store frequently requested information, such as user name and postal address, in a client-side repository. While most data in the P3P Base Data Set [BASEDATA] (as well the majority of schema extensions) will most likely be stored in the repository, P3P also supports the use of non-repository data. Such data is either information that is never stored in a repository and has to be manually entered by the user every time the element is requested, or data that constitutes information which is dynamically created by the user agent or operating system, such as clickstream information or the browser identification string.

When creating new schema definitions, schema designers can either specify that user agents should try to create corresponding fields in the user's repository (thus facilitating repeated transmission of the information), or that the element is dynamic and should not be included in the repository. The following subsections explain those two concepts in more detail.

4.6.1 Repository Data

Any element in a schema definition is assumed to be part of the user's repository. Thus, a standard schema definition of a (fixed) repository element would look like this:

<DATA:REF name="personname.first" type="text"
          short="First Name"      VOC:category="physical" template="yes"/>

However, even though an element is part of the user repository, a P3P proposal could explicitly specify that it wants the user to manually enter it (for example through an HTML form), ignoring any available data in the repository:

   <DATA:REF name="user.name.first" source="service">

Applications can of course still offer a repository-based auto-fill functionality, even though the site did not request any repository data. Also note that it is up to user agent implementations to decide what action to take when encountering a new repository-stored data schema. Some implementation could for example automatically add the element to the user's repository (with an empty value), others might want to prompt the user for a decision.

4.6.2 Non-Repository Data

As explained before, attribute values set in data schema definitions can not be overridden. Thus, in order to force a certain data element to always be outside of the user repository, schema designers simply have to set the source attribute to service:

<DATA:REF name="dynamic.clickstream.client"
          short="Click-stream collected on the client"
                         type="boolean" source="service"
                          VOC:category="navigation" template="yes"/>

The above example ensures that dynamic.clickstream.server will never become part of the user's repository, but is instead either manually collected (for example through HTML forms) or implicitly transmitted as part of the connection (which is the case for clickstream data). In either case, a P3P user agent could (depending on the user's preferences) inform the user about the collection of this data element and its terms, but would take no further action for transmitting the data.

5. Appendices

Appendix 1: References (Normative)

M. Langheinrich (Ed.). "A P3P Preference Exchange Language (APPEL)" World Wide Web Consortium.
M. Marchiori (Ed.). "P3P Base Data Set." World Wide Web Consortium, Working Draft.
Y. Chu, P. DesAutels, B. LaMacchia, P. Lipp. "PICS Signed Labels (DSig) 1.0 Specification," World Wide Web Consortium Recommendation 27 May 1998.
J. Reagle (Ed.). "P3P Harmonized Vocabulary Specification,"  World Wide Web Consortium, Working Draft.
T. Berners-Lee, R. Fielding, H. Frystyk Nielsen, "RFC1945 -- Hypertext Transfer Protocol -- HTTP/1.0," W3C/MIT, UC Irvine, W3C/MIT, May 1996.
R. Fielding, J. Gettys, J.C. Mogul, H. Frystyk, T. Berners-Lee, "RFC2068 -- Hypertext Transfer Protocol -- HTTP/1.1," UC Irvine, Digital Equipment Corporation, MIT.
H. Frystyk, P. Leach, S. Lawrence. "HTTP Extensions" (draft-frystyk-http-extensions-03.txt). Jan 1999. IETF Internet Draft.
"ISO3166: Codes for The Representation of Names of Countries." International Organization for Standardization.
S. Bradner. "RFC2119 -- Key words for use in RFCs to Indicate Requirement Levels." March 1997.
R. Rivest. "RFC 1321 -- The MD5 Message-Digest Algorithm," MIT. April 1992.
N. Freed, N. Borenstein. "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies." November 1996.
O. Lassila, R. Swick (Eds.). "Resource Description Framework (RDF) Model and Syntax Specification."  World Wide Web Consortium Recommendation. 22 February 1999.
A. Freier, P. Karlton,  P. Kocher. "SSL 3.0 Specification." (http://home.netscape.com/eng/ssl3/index.html)
Network Working Group, D. Kristol, Bell Laboratories, Lucent Technologies; Category: Standards Track  HTTP State Management Mechanism. (ftp://ftp.isi.edu/in-notes/rfc2109.txt)
T. Berners-Lee, R. Fielding, and L. Masinter. "Uniform Resource Identifiers (URI): Generic Syntax and Semantics." August 1998. RFC 2396. [Updates RFC1738]
F. Yergeau. "RFC2279 -- UTF-8, a transformation format of ISO 10646." January 1998.
"vCard - The Electronic Business Card Version 2.1." Internet Mail Consortium, September 18, 1996.
T. Bray, J. Paoli, C. M. Sperberg-McQueen. "Extensible Markup Language (XML) 1.0 Specification." World Wide Web Consortium, Recommendation. 10 February 1998.
A. Layman et al. "XML-Data." World Wide Web Consortium, Note. 05-January-1998.
T. Bray, D. Hollander, A. Layman. "Namespaces in XML." World Wide Web Consortium, Recommendation, 14-January-1999.

Appendix 2: ABNF Notation (Non-normative)

The formal grammar of P3P is given in this specification using a slight modification of the ABNF defined in http://info.internet.isi.edu/in-notes/rfc/files/rfc2234.txt . The following is a simple description of the ABNF.

name = (element) 
where <name> is the name of the rule, <elements> is one or more rule names or terminals combined through the operands provided below. Rule names are case-insensitive. 
(element1 element2)
elements enclosed in parentheses are treated as a single element, whose contents are strictly ordered.
at least <a> and at most <b> occurrences of the element.
(1*4<element> means one to four elements.)
exactly <a> occurrences of the element.
(4<element> means exactly 4 elements.)
<a> or more elements
(4*<element> means 4 or more elements.)
0 to <b> elements.
(*5<element> means 0 to 5 elements.)
0 or more elements.
(*<element> means 0 to infinite elements.)
optional element, equivalent to *1(element).
([element] means 0 or 1 element.)
"string" or 'string'
matches a literal string matching that given inside the double quotes.

Other notations used in the productions are:

; or /* ... */

Appendix 3: Working Group Contributors

The following individuals participated in the P3P Specification Working Group:

[fill in later]

The P3P Specification Working Group inherited most of the specification from previous P3P working groups. The Working Group would like to acknowledge the contributions of the members of these previous groups:

[fill in later]