Platform for Privacy Preferences (P3P) Syntax Specification

W3C Working Draft 7 April 1999

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


This is the core and lengthiest document of the P3P specification; it documents the requirements, 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/).


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

Table of Contents

  1. Introduction
    1. Problem space
    2. About this specification
    3. Operational description
    4. Operational design
    5. Assumptions
    6. Terminology
    7. 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. Client requests proposal from the server
      2. Client returns repository data referencing a specific policy
      3. Server suggests proposal (location) to the client
      4. Server accepts a proposal /data required by the client or reports an error
    4. Reason codes definition
    5. Agreement scenario
  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 VOC:DISCLOSURE element
      4. The ASSURANCE element
    3. Data Transmission
    4. Statements
      1. The STATEMENT element
      2. The DATA:REF element
      3. Creating New Data Sets
  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, its chapters, and its normative references, include all the specification necessary for the implementation of interoperable P3P applications. This specification was built upon the work of previous working groups and includes:

  1. Protocol primitives.
  2. Protocol schemas, including the privacy practice vocabularies of the proposal.
  3. Protocol syntax and encoding, including the data structures and formats.

This document includes the main body of the P3P specification. The detailed -- natural language -- semantics of the privacy disclosure vocabulary can be found in:


The detailed syntax and datatypes of the base data set is found in:


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.

1.3 Operational description

When a user encounters a Web service, the Web service may declare its privacy practices and additionally solicit information from the user.

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 a specified realm -- a Web resource or "tree" of Web resources referenced by a single URI, or list of Web resources referenced by a list of URIs.

Once an agreement is reached, the enumerated data elements that are included in the agreed-to proposal should be interpreted by the user agent as data requests from the service. It is possible to have an agreement without referencing data elements. Such an agreement states that no information is collected.

More than one proposal may exist for a realm. Services also have the capability to offer alternative or optional proposals. 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 a fingerprint of the agreement, called the .

Rather than sending a new proposal to the user agent on every contact, a site may send the propID of an existing agreement. This is 1) asserting that the service and the user agent have already agreed to a proposal, 2) signaling which proposal and privacy practices they are operating under, and 3) requesting those data elements referenced in the agreement. The user agent may turn away, respond with the requested data, or request a full proposal -- if either it has no record of such an agreement or it desires a new one.

1.4 Operational design

Proposals (or pointers to proposals) are sent in the transport mechanism (HTTP) or within the content/resource (HTML page). Multiple alternative proposals may exist for any given resource, for purposes of flexibility. Services may use the P3P-extension multiple times within HTTP, or use multiple links within HTML.

An agent should return the information according to the methods native to its transport and content model. We define how to accomplish information exchange using HTTP methods. We also specify an extensibility mechanism for returning information through other means.

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.5 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.6 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.
Fingerprint (Hash, Digest)
A fixed size value resulting from the application of a hash function to a set of data. Fingerprints are easily computed, but even small modifications to the original information result in a virtually unpredictable value. Consequently, fingerprints are often used as a key to entries in a table or databases, or as methods of assuring information integrity. We use the [MD5] digest algorithm for P3P fingerprints. This yields a 128-bit value that will be encoded and exchanged in P3P communications.
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 identity a P3P proposal. A propID is the fingerprint of a proposal. The presence of the propID in the P3P headers is the definitive declaration of which agreements are in effect for a given realm. 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 internet draft [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 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.7 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
  postURI/CGI MUST data must be able to be sent back via HTTP post to some URI

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
Abstract Elements abstract elements MUST methods of references data exchanged through mechanisms other than P3P
Harmonized Vocab harmonized vocabulary MUST see the harmonized vocubarly 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. If a reason code is not provided there is an implied semantic. Consequently the semantic is required, the presence of the code is optional.
Operational Description propID repository SHOULD full proposals can be compactly represented, new negotiation and agreement are not necessary if an agreement already exists.
  service can write to the data repository SHOULD services can write information back to the user repository if the user permits
  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 attribute MAY agents support multiple, extensible mechanisms by which information is solicited.

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 and 5 highlight 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 expanded example scenario in Appendix 1 includes an example of negotiation.

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 Data Written
1 No Yes - -
2 Yes No - -
3 Yes Yes - -
4 - - Yes No
5 - - Yes 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

Scenario 5) Client write information to service

3 Data Transport

3.1 Protocol Model

The protocol model is based on a single interaction. 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.

Request proposal from the server
If a client does not have a proposal, or wants a new one, for a particular resource it may request one from the service. Note that the proposals obtained from the service can cover a set of resources, for example, all the resources exported by a particular server.
Return repository data referencing a specific policy
if the client already has an agreement for a specific resource then it can require the server to use this proposal for the data included in the request. If the server does not want to comply with this policy it must disregard the data and return an error.

3.1.2 Server Actions

The server can perform the following actions:

Suggest proposal (location) to the client
The server can include proposals in any response that it issues. The server may include proposals in a response because a client has requested it, or it wants to indicate to the client an alternative policy for one or more resources.
Accept a proposal referenced by the client or report an error
If the client references a proposal, the server can either accept it or fail. If the server does not accept the proposal then it must issue an error in which it may suggest a policy that it can accept/reference. The client can then decide whether it wants to try again or not.

3.2 HTTP Extension Framework and P3P

In order to use the HTTP Extension Framework [HTTP-EXT], it is required to provide 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's of the referenced proposal. The format is "md5:X", where X is the resource-hash (the base-64 encoding of the md5 fingerprint) of the proposal as defined in Appendix 2.
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

3.3.1 Client requests proposal from the server

A client requests a proposal from a server by issuing a request stating that it is P3P savvy. This request is performed via the HTTP Extension Framework, using the P3P extension declaration (http://www.w3.org/TR/WD-P3P/). It is up to the implementation whether to use the Optional or Mandatory extension.

For example, a client can verify, using the OPTIONS method, whether the server is P3P compliant or not:

OPTIONS some.resource HTTP/1.1
Host: some.host
Opt: "http://www.w3.org/TR/WD-P3P/"

Or, for example, within a normal GET request:

GET some.resource HTTP/1.1
Host: some.host
Opt: "http://www.w3.org/TR/WD-P3P/"

Of course, if the Mandatory extension is used in place of the Optional one, the methods M-OPTIONS and M-GET must be used ([HTTP-EXT]).

3.3.2 Client returns repository data referencing a specific policy

If the client already has an agreement for a specific resource or wants to agree to an offered proposal then it can require the server to use this proposal for the data included in the request. This is done using the Mandatory P3P extension declaration with the M-POST method, and setting the following P3P extensions for each proposal:

If the server does not want to comply with this policy it must disregard the data and return an error.

For example, if the client wants to agree to an offered proposal with propID 94df1293a3e5, it could send:

Host: www.CoolCatalog.com
Man: "http://www.w3.org/TR/WD-P3P/"; ns='15-'
15-status: OK
15-propID: "md5:94df1293a3e5"
15-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">
15-data: <DATA:REF name="User.Name.First" value="Sheila">
15-data: <DATA:REF name="User.Name.Second" value="Doherty">
15-data: </TXD>


As another example, if the client wants to agree to an offered proposal with propID 94df1293a3e5 and to a proposal with propID AAbbAAbbAAbb, it could send:

Host: www.CoolCatalog.com
Man: "http://www.w3.org/TR/WD-P3P/"; ns='15-'
Man: "http://www.w3.org/TR/WD-P3P/"; ns='22-'
15-status: OK
15-propID: "md5:94df1293a3e5"
15-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">
15-data: <DATA:REF name="User.Name.First" value="Sheila">
15-data: <DATA:REF name="User.Name.Second" value="Doherty">
15-data: </TXD>
22-status: OK
22-propID: "md5:AAbbAAbbAAbb"
22-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">
22-data: <DATA:REF name="User.Business.Postal.City" value="Cambridge">
22-data: </TXD>

3.3.3 Server suggests proposal (location) to the client

The server can at any point in time indicate which policy will be used for one or more resources. In case more than one proposal is offered, they are considered as multiple alternative proposals. Alternative means that the client is supposed to choose (at most) one proposal among the possibly many offered. Suggesting proposals can be done in two ways: at HTTP level, using the HTTP Extension framework, or at HTML level, using the HTML LINK tag. These two ways are not exclusive: in case both are used at the same time, the interpretation is a set of multiple alternative proposals.

HTTP Level

This is done using the Optional P3P extension declaration, and setting the following P3P extensions for each suggested proposal:

The default realm is the current Request-URI only.

For example:

HTTP/1.1 200 OK
Opt: "http://www.w3.org/TR/WD-P3P/"; ns='14-'
14-propID: "md5:94df1293a3e5"
14-proposal: "http://www.privacy.org/P3PProposal"

Or, in case of multiple (three) alternative proposals:

HTTP/1.1 200 OK
Opt: "http://www.w3.org/TR/WD-P3P/"; ns='15-'
Opt: "http://www.w3.org/TR/WD-P3P/"; ns='18-'
Opt: "http://www.w3.org/TR/WD-P3P/"; ns='20-'
15-propID: "md5:94df1293a3e5"
15-proposal: "http://www.privacy.org/P3PProposal"
18-propID: "md5:23as53aw12w2"
18-proposal: "http://www.privacy.org/P3PProposal2"
20-propID: "md5:56ew89qwht14"
20-proposal: "http://www.privacy.org/P3PProposal3"

HTML level

This is accomplished by using the HTML LINK tag in the following way for each suggested alternative proposal:

<LINK rel="p3p:md5:hash" href="URI">

Here, URI points to the P3P proposal, and "p3p:md5:hash" is a relation name used to distinguish this special P3P link, and to encode the (md5) hash of the proposal. For example, if a proposal at http://www.privacy.org/P3PProposal has hash 94df1293a3e5, we would use <LINK rel="p3p:md5:94df1293a3e5" href="http://www.privacy.org/P3PProposal">.

Note: This may increase the latency of fetching a proposal since it must now be sought in the HTML content. However, such proposals can be cached. Regardless, this method should only be used for sites which 1) do not use P3P data methods and 2)  have a few, simple, non-overlapping proposals for their site.

3.3.4 Server accepts a proposal /data required by the client or reports an error

If the client requires a proposal using the M-POST method, the server must either accept it or fail: this is a property of the Mandatory request functionality [HTTP-EXT]. If the server accepts the proposal, no further reply is required. If the server does not accept the proposal then it must disregard all the data possibly received by the client with the M-POST message, and it must issue an error in which it may suggest a policy that it can accept (the client can then decide whether it wants to try again or not). This is done using the Optional P3P extension declaration, and setting the following P3P extensions:

Of course, the propID extension must be set if a new proposal is offered. Again, the default realm is the current Request-URI only.

For example, if the previous agreement has expired:

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

3.4 Reason codes definitions

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. Every P3P extension must include a status header with a specified value or extension URI. Applications that do not understand the status extension must ignore the p3p-message.
Reason Token Explaination
OK ok, receipt of the contents of the proposal or data extension completed successfully.
SRY-AU because the agreement is unkown. (sent in response to the content of the data extension)
SRY-AE because the agreement expired. (sent in response to the content of the data extension)
SRY-PR because the proposal was rejected. (sent in response to the content of the proposal extension)
SRY-DU because the data is unavailable. (sent in response to the content of the proposal extension)
SRY-DR because the data could not be accepted or written to repository (sent in response to the content of the proposal extension)
SRY sorry, receipt of the contents of the proposal or data extension failed. This code can be sent, in response to the content of the proposal extension, when all the other SRY- codes are not applicable
ERR-IF invalid format, the P3P message that was received was syntactically invalid or semantic garbage.
ERR-TF data transfer failed, 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, a request was not understood or received properly. This code can be sent when all the other ERR- codes are not applicable

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.

3.5 Agreement scenario

1. The user goes to an order page and asks for a proposal:

GET store1.com/catalog/page1.html HTTP/1.1
Host: store1.com
Opt: "http://www.w3.org/TR/WD-P3P/"

2. Or perhaps the service returns location of alternative proposals, structured via RDF, in effect  for the requested URI:

HTTP/1.1 200 OK
Opt: "http://www.w3.org/TR/P3P/"; ns='12-'
12-propID: "md5:aaaaaa"
12-proposal: "http://www.store1.com/P3PProposal1.RDF"
Opt: "http://www.w3.org/TR/P3P/"; ns='4253-'
4253-propID: "md5:ababab"
4253-proposal: "http://www.store1.com/P3PProposal2.RDF"
Content-Type: text/html
Content-Length: 110
<h1>Welcome to Cool Catalogue</h1>
<p>We'd love to have the following information to
   customize our online catalogue to you.</p>
<form method="POST" action="http://www.CoolCatalog.com/cgi-bin">
<p><input type="submit" value="Submit" name="B1">
<input type="reset" value="Reset" name="B2">
First Name <input type="text" name="User.Name.First" size="20" value="Your First Name Here">
Second Name <input type="text" name="User.Name.Second" size="20" value="Your Second Name Here">


3. The user agrees by returning the relevant propIDs with the data that is returned. Agreement over abstract data elements (see [BASEDATA]) is assumed to follow from subsequent interactions with the service.

M-POST store1.com/catalog/page1.html HTTP/1.1
Host: store1.com
Man: "http://www.w3.org/TR/WD-P3P/" ns='23-'
23-propID: "md5:aaaaaa"
23-status: "OK"
23-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">
23-data: </TXD>
Man: "http://www.w3.org/TR/WD-P3P/" ns='78-'
78-propID: "md5:ababab"
78-status: "OK"
78-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">
78-data: <DATA:REF name="User.Name.First" value="Sheila">
78-data: <DATA:REF name="User.Name.Second" value="Doherty">

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 your gender and (optionally) information about your preferences to customize our entry catalog pages for the type of clothing you are likely to be interested in 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 (3)
Assurance: PrivacySeal.org
Other disclosures: Change agreement, retention (0,1)

We collect:
    Form.Data_  (category=8, optional)
For purpose: Customization of the site to individuals, research and development (2.3)
Identifiable use: No (0)
Recipients: Only ourselves and our agents (0)
Consequence: A site with clothes you would appreciate

We collect:
For purpose: Web site and system administration, research and development (1,3)
Recipients: Only ourselves and our agents(0)

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="3" other="0,1"/>
  <STATEMENT VOC:purp="2,3" VOC:recpnt="0" VOC:id="0"
   consq="a site with clothes you would appreciate">
     <DATA:REF name="Cookies_" source="0"/>
     <DATA:REF name="Form.Data_" VOC:category="8" optional="1" source="0"/>
     <DATA:REF name="User.Gender" source="1"/>
  <STATEMENT VOC:purp="1,3" VOC:recpnt="0" VOC:id="0">
    <DATA:REF name="ClickStream.Server_" source="0"/>
    <DATA:REF name="HTTP.UserAgent_" source="0"/>

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

includes one or more statements. Each statement includes a set of disclosures as applied to a set of data elements.
URI to which information may be transmitted
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.
the date on which an agreement, if reached, will expire. Default is 6 months. The agreement expiration is the last date when a user agent can transfer data to the service under the agreement. The service continues to be bound by the restrictions of the agreement for data collected under the agreement, even after the expiration. Proposals expire after the time indicated by the "EXPIRES" HTTP header. The default expiration is 1 hour.
(`<RDF:RDF xmlns:RDF="http://www.w3.org/TR/REC-rdf-syntax/">`

`<PROP xmlns="http://www.w3.org/TR/WD-P3P/syntax" 
[" agrexp=" `"` datetime `"`] ;default is six months
" entity=" quoted-URI  
[" postURI=" quoted-URI]

The entity attribute

The entity attribute references a domain name and path that can be associated with the legal entity making the representation of the privacy practices contained in the proposal. In the absence of digital signatures, this is the only mechanism for tracking down the legal entity via the weak identification mechanisms provided by the domain name registry's and the records of the organization responsible for that domain name. In addition, the entity attribute is used as the "root" domain to which the URIs in the realm must domain-match [KRISTOL] when a certificate is not used as the realm attribute. In addition, the URI of the customer request must domain-match the entity attribute.

4.2.2 The REALM element

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

Note that there can be multiple realms, specified via multiple occurrences of the REALM element.

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" [KRISTOL] the domain of the server.

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 VOC:DISCLOSURE element

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 change agreement and retention known at its discURI?
The values of [4-6] are provided for reference only. The normative specification is in the harmonized vocabulary document.
" discURI=" quoted-URI
" access=" `"` access-disclosure `"`
[" other=" `"` 
   other-disclosure *("," other-disclosure) `"`]
"0" | ; Identifiable Data is Not Used
"1" | ; Identifiable Contact Information
"2" | ; Other Identifiable Information
"3" | ; None
"0" | ; change agreement
"1"   ; retention

4.2.4 The ASSURANCE element

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 assurances services, specified via multiple occurrences of ASSURANCE.

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. The service can also send similar messages to a user agent to request that values be stored in the user data repository.

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

`<TXD xmlns="http://www.w3.org/TR/WD-P3P/syntax" 
 *(data-reference) `</TXD>`

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

data practices as applied to data elements.
VOC:purp (mandatory attribute)
purposes for data processing relevant to the Web.
VOC:recpnt (mandatory attribute)
an organizational area, or domain, beyond the service provider and its agents where data may be distributed.
VOC:id (mandatory attribute)
is data used in a  way that is personally identifiable -- including linking it with identifiable information about you from other sources?
read the data, or read and write (read is default value)
[" action=" `"` action `"`]
" VOC:purp=" `"` purpose *("," purpose) `"`
" VOC:recpnt=" `"` recipients *("," recipients) `"`
" VOC:id=" yesno
[" consq=" quoted-string]

("r" | "rw") ; r=read, rw=read&write, default is read

The values of [12-15] are provided for reference only. The normative specification is in the harmonized vocabulary document.
"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" [" (" string ")"] ; Other Uses

"0" | ; only ourselves and our agents
"1" | ; organizations following our practices
"2" | ; organizations following different practices
"3"   ; unrelated third parties or public forum


"1" | "0" ; 1 stands for "Yes", 0 for "No"

Note: Originally, very conservative default values were chosen ("0") to force services to counter those defaults to be honest about those practices. However, this could lead to semantic interpretability: a service believes an attribute is optional and a user gives them information based on the  implied/default semantic. A better approach could be to set the default values very high (i.e., if the recipient attribute isn't included, it means the data is distributed to the public.) However, we are now erring on the side of not providing default values to ensure there is no confusion between optional attributes and required attributes with default semantics.

The action attribute

Services have the capacity to ask that information be written to the user repository. Consider a P3P agent receiving the following request as part of a proposal:

<STATEMENT action="r" VOC:purp="2" VOC:recpnt="0" VOC:id="0"/>
    <DATA:REF name="User.Name.First" source="1"/>
<STATEMENT ="rw" VOC:purp="2" VOC:recpnt="0" VOC:id="0">
    <DATA:REF name="FineShoes.shoesize"
     xmlns:DATA="http://www.FineShoes.com/Schema1.0" source="1"/>

The user could be prompted, asked if she agrees to this proposal, and then shown a form-like interface with the User.Name.First auto-filled (assuming she's entered that before) and a blank field for FineShoes.shoesize. The user would enter this information and transmit it using a TXD.

The user sends:
43-data: <TXD xmlns="http://www.w3.org/TR/WD-P3P/syntax" xmlns:VOC="http://www.w3.org/TR/WD-P3P/vocab"

43-data: <DATA:REF name="User.Name.First" value="Sheila"/>
43-data: <DATA:REF name="User.Name.Second" value="Doherty"/>
43-data: <DATA:REF name="FineShoes.Shoesize" xmlns:DATA="http://www.FineShoes.com/Schema1.0" value="7"/>

Whenever the attribute "rw" is applied to a data element, and a new value is provided by the user, the user agent should attempt a write to the data repository. If that attempt fails, the agent should return the appropriate response code. This auto-write eliminates the need for the service to retransmit information back to the user agent. However, the service may send a TXD message at any time. For instance, even though the user provided their shoesize as 7, the service may wish to convert it into European shoe sizes and write that value instead.

4.4.2 The DATA:REF element

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. For convenience, names of data sets/elements are case insensitive within the ASCII character range (so, for example, User.Home. is equivalent to USER.HOME or user.home.). Furthermore, in names no number character can appear immediately following a dot. Finally, names ending with an underscore symbol ("_") have a special meaning (they are so called abstract elements, see Section 3 of [BASEDATA]).
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.
"0" or "1". "0" indicates that the data element is required, while "1" indicates that the data element is not required. The default is 0. The optional attribute is used only in proposals.
source (mandatory attribute)
specifies the mechanism for data transfer
a string denoting the categories of a data element.
The following seven attributes are only used when a new (not defined in the P3P1.0 base [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.
a URI denoting the name of the data schema the data element/set specified in name belongs to. The default DATA namespace 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=" `"` source `"` 
[" xmlns:DATA=" quoted-URI] 
[" optional=" yesno] [" value=" quoted-string] 
[" type="quoted-string] [" typeschema=" quoted-string] 
[" template=" yesno] [" VOC:category=" categories] 
[" short=" quoted-string] [" long=" quoted-string]
[" size=" `"` number `"`] ; default is 0 (unlimited size)

"0" | ; service
"1" | ; agent
"2" | ; matched-form
"3"   ; extension

`"` *(number ",") number `"`

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.Telecom.Phone and collect them through a matched form,  the service would send the following references inside a P3P proposal:

<DATA:REF name="User.Home.Postal.City" source="2"/>
<DATA:REF name="User.Home.Telecom.Phone." optional="1" source="2"/>
<DATA:REF name="User.Business." source="2"/>

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.Postal.City" value="Cambridge"/>
<DATA:REF name="User.Home.Telecom.Phone.IntCode" value="1"/>
<DATA:REF name="User.Home.Telecom.Phone.LocCode" value="617"/>
<DATA:REF name="User.Business.Postal.Street" value="254 Windsor St."/>
<DATA:REF name="User.Business.Postal.City" value="Cambridge"/>
... (the other values of User.Business.) ...

The VOC:category attribute

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

Membership of data elements in categories is generally disjoint; most data elements should belong to just one category. However data elements may belong to more than one category when necessary. In addition, a data set belongs to all of the categories to which its elements belong. Base data elements have all been assigned a default category in the P3P specification. When a service proposes a new data element, the proposal should include the default category or categories for the element, however the user and/or user agent retains final control over the category assignment.

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

"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
"9" ; 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.

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:

0: service
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.
1: agent
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 or the post mechanism (if a postURI is specified). 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.
2: matched-form
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. 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="3" to indicate that data will be collected using that mechanism.

DATA: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 optional attribute

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.

4.4.3 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 value of the xmlns:DATA attribute.

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:purp="4" VOC:recpnt="0" VOC:id="0">
 <DATA:REF name="car.model" type="Text" short="Model" 
   VOC:category="7" size="63"/>
 <DATA:REF name="car.color" type="Text" short="Color" 
   VOC:category="7" size="63"/>
 <DATA:REF name="car.built.year" type="Number" short="Construction Year" 
   VOC:category="7" size="63"/>
 <DATA:REF name="car.built.where." type="Postal."  short="Construction Place" 
   VOC:category="7" size="63"/>
 <DATA:REF name="bike." type="car." 

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="1" (default is 0), 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:purp="4" VOC:recpnt="0" VOC:id="0">
 <DATA:REF name="GenericModel.model" type="Text" short="Model" template="1" 
   VOC:category="7" size="63"/>
 <DATA:REF name="GenericModel.color" type="Text" short="Color" template="1" 
   VOC:category="7" size="63"/>
 <DATA:REF name="GenericModel.built.year" type="Number" short="Construction Year" 
   template="1" VOC:category="7" size="63"/>
 <DATA:REF name="GenericModel.built.where." type="Postal." 
   short="Construction Place" template="1" 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"/>

Creators of new schema should be aware that unless they place restrictions on the source attribute (i.e. source=0 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.

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. 8 Februay 1999.
Y. Chu, P. DesAutels, B. LaMacchia, P. Lipp (Eds.). "DSig 1.0 Signature Labels Specification: Using PICS 1.1 Labels for Making Signed Assertions," World Wide Web Consortium, Recommendation. 03-April-1998.
O. Lassila, R. Swick (Eds.). "Resource Description Framework (RDF) Model and Syntax Specification."  World Wide Web Consortium, Proposed Recommendation. 5 January 1999.
J. Reagle (Ed.). "P3P Harmonized Vocabulary Specification,"  World Wide Web Consortium, Working Draft. 8 February 1999.
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.
"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.
H. Frystyk, P. Leach, S. Lawrence. "HTTP Extensions" (draft-frystyk-http-extensions-03.txt). Jan 1999. IETF Internet Draft.
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.
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." 1997. (Work in progress; see updates to 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, Working Draft. 16 September 1998.

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 (Non-normative)

Lorrie Cranor AT&T
Philip DesAutels Matchlogic
Melissa Dunn Microsoft
Daniel Jaye Engage Technologies
Steve Lucas (Chair) Matchlogic
Massimo Marchiori (Editor)  W3C
Maclen Marvit Narrowline
Max Metral Firefly Network Inc.
Paul Perry Firefly Network Inc
Martin Presler-Marshall IBM
Joseph Reagle (Project Manager) W3C
Drummond Reed Intermind