This appendix provides a brief introduction to P3P. The following sections will give an overview of the goals and features of P3P and illustrate P3P by explaining a sample P3P scenario. For more detailed information, the reader should refer to [Reagle99] and W3C's P3P web site  .
P3P enables Web sites to express their privacy practices and enables users to exercise preferences over the release of personal information. P3P-compliant products will be able to inform users of site practices (in both machine- and human-readable formats), allow users delegate decisions to their computers when appropriate, and tailor users' relationships to specific sites. Sites whose practices are compatible with a user's preferences can, at the user's option, be accessed seamlessly. If the site practices and the user preferences are incompatible, users will be notified of a site's practices and have the opportunity to agree to those terms or other terms.
While the P3P1.0 specification provides a syntax for specifying proposals and a protocol and associated syntax for exchanging information between a Web site and user agent, it does not define how to verify the information of a P3P proposal nor does it provide a mechanism for enforcement in case of privacy violations. However, P3P will support future digital certificate and digital signature capabilities.
A P3P user agent communicates to Web servers using standard HTTP methods such as GET and POST  . P3P was designed to transport data between the agent and the service in the headers of a P3P HTTP extension 1 . When placing an initial request to a Web server, the user-agent may include the p3p-opt-header to notify the server that the user agent is P3P-compliant. If the user-agent sends this OPT header, and the server implements the P3P protocol, then the server must:
The following section describes and explains the grammar of P3P. This grammar was taken from the current P3P working draft  . Because P3P is still in progress, changes to the P3P specification may be introduced as it advances toward recommendation 2 status.
The following parts of the grammar 3 define the content of the P3P message header in a P3P request.
Inside a P3P proposal a Web site (or a P3P agent) can define which information elements are covered by the proposal as well as the respective terms and conditions for each element. Such information elements are called data references (see grammar element 37, data-reference).
A proposal can contain more information than just the terms and conditions. The following grammar elements define assurance and disclosure statements. The assurance statement (36) describes a service that attests that the entity will abide by its proposal and follow certain guidelines or assertions in the processing of data. A disclosure statement (33) offers information regarding service access capabilities, how long data is retained, and whether the entity makes disclosures regarding changing the agreement for data already collected.
The last three grammar definitions describe the structure of referencing information elements. A Web site that requests information with a P3P proposal lists the respective data references 5 in the proposal.
This scenario was taken from the latest public P3P working draft, which is available at W3C's P3P Web site  . This line flow scenario describes a user who directs his Web browser for the first time to the home page of CoolCatalog. When he requests CoolCatalog's home page, his browser indicates that it understands P3P.
The CoolCatalog Web site receives this request and recognizes that the visitor is using a P3P-compliant browser. CoolCatalog responds by sending a proposal that includes information about the site's privacy practices and disclosures. It also requests an identifier (PUID) and the user's gender in order to be able to personalize the content of the Web site to the user 6 :
The user's browser receives the proposal as the first response from CoolCatalog. The browser's P3P agent rejects this proposal 7 and sends a sorry message back to CoolCatalog.
CoolCatalog's Web site receives the user's sorry message and decides to send another proposal. This time the site requests an automatic return identifier and the user's name and age (optional), both for the purpose of customizing the site.
On subsequent visits to CoolCatalog, the user agent can automatically provide the required data on the user's initial request. Again, the user's name and the identifier are sent in a TXD message which refers to the proposal that the user and CoolCatalog had previously agreed on:
1. There might be instances in which the content of P3P data could exceed the expected length of a header in some HTTP implementations. Hence, P3P implementations should be able to conform to other methods of exchange. Those methods are likely to be within the HTTP extension header, at a specified URI that a client or server then obtains with a HTTP GET request, or as part of the content of a XML or HTML page.
2. W3C working groups, such as the P3P working group, produce specifications in the form of working drafts. Eventually, a working draft may be put forward to the W3C membership as a proposed recommendation. After an advisory vote by the membership, the W3C Director may issue the proposal as a recommendation  .
3. The grammar as presented in this document uses the Augmented Backus-Naur Form (ABNF) notation, which is specified in RFC 2234. Because of limited space and for clarity reasons , the text string "..." was used as a replacement for the string TR/1998/WD-P3P-19981109.
5. More information about data references can be found in the P3P Base Data Set, available at the W3C Web site  .
6. The proposal was split across multiple lines for readability; over the network, a carriage-return line-feed (CRLF) pair would be added only after the </P3P> element. Multiple lines are also used in the following P3P code samples.