The CC/PP working group wishes to congratulate the P3P working group on its completion of the current specification. We have reviewed it, and note that it while the specification stresses the use of HTTP, P3P is concerned with the expression of a policy, which is independent of HTTP. The mechanisms that allow a server to communicate the association between policy and entity to a client is bound to HTTP, but there is a protocol-independent component which we feel deserve highlighting, especially in view of the new protocols for e-commerce being considered (e.g. in the W3C XML and Protocols activity, and the IETF Blocks work).

We also note that P3P conceptually consists of three main parts: (a) a policy reference file format, and mechanisms for using this with HTTP. The policy reference file uses RDF. It associates a policy with entities that may be retrieved from a site using HTTP. (b) a policy statement file format. This is fairly independent of HTTP, and does not use RDF, though an RDF model for the information is provided as a non-normative appendix. (c) a data schema format, which can be used to define the data types and other properties used with data elements referenced by a policy statement.

We feel the current specification may overemphasize the structure for naming data items, and its not clear why a privacy policy needs to know about data types, etc., and hence reference an associated data schema. It may be preferrable to simply use a URI-as-data-item-identifier, in much the same way as RDF. Indeed, if RDF were used here, then RDF schema (and its progeny) could provide schema facilities form P3P as and when these are needed.

We note that the CC/PP mechanisms and the P3P mechanisms should be able to coexist, the P3P policy being used by the client to decide which CC/PP components and attributes which are transmitted. However, this presents a problem with the current specification. If the CC/PP collection of profile information is regarded as sensitive, we cannot send the profile first and then recieve a policy as response. We must have the ability to establish wether we can accept the policy before sending the profile information. This must take place with as little network transactions as possible, as we want to minimize these to minimize the latency introduced.

We do note that the P3P specification lists some future work items, which overlap the work of the CC/PP working group. This is particularly true for the intent to develop a mechanism to allow the user agent to transfer user data to servers. While the intent is that such transfer should be automatic in CC/PP, but must be controlled by the user in P3P, we foresee the possibility of using the same mechanisms. We welcome the P3P working group to review our recently published working drafts with regards to their suitability in this matter.

For the CC/PP working group

Johan Hjelm