W3C home > Mailing lists > Public > www-p3p-public-comments@w3.org > August 2000

Re: Comments from the CC/PP working group

From: Lorrie Cranor <lorrie@research.att.com>
Date: Wed, 16 Aug 2000 12:11:55 -0400
Message-ID: <013e01c0079c$b304c220$3a06cf87@research.att.com>
To: <www-p3p-public-comments@w3.org>, <johan.hjelm@era-t.ericsson.se>
Cc: <w3c-ccpp-wg@w3.org>, <w3c-p3p-specification@w3.org>
Dear CC/PP Working Group Members,

Thank you for your thoughtful review of P3P. We agree
with you that P3P can be used with protocols other
than HTTP, and we have added a statement to that
effect that will be in the next public draft.

In your note you wrote:
>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 preferable 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 agree that the data types are not necessary, and in fact, we 
decided to remove them some time ago. This will be reflected in our
next public draft. 

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

Any data that a user regards as sensitive must not be transmitted
to a web site until the web site's policy can be obtained and evaluated.
The P3P spec tries to minimize the latency this will introduce by
allowing sites to declare an expiration date for their policies so that
user agents need not fetch policies they have already seen. Furthermore,
the spec allows sites to declare that a policy applies to a range of
URIs so that user agents need not fetch the same policy for each of
these URIs. We can also imagine that proxies and wireless gateways
might perform further optimizations by storing user preferences on
the gateway rather than on the wireless device, so that the policy need
not be transmitted routinely to the wireless device. We believe our
design for P3Pv1 does an adequate job of laying the ground work for
using P3P in conjunction with CC/PP and wireless protocols. Given
the many dependencies potentially involved, we cannot afford to delay
the P3P process until there is sufficient time to fully consider how
P3P would work in a wireless environment and implement it so that
it can be tested. We need to move forward with the P3Pv1 specification.
We hope that as more concrete issues are raised, these can be 
addressed in future P3P work.

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

There is certainly some potential to work together on a common
mechanism. The P3P working group will not address this until after
we finish version 1 and the group is rechartered. But hopefully some of
the members will have some time to review your working drafts and
provide their input.


Lorrie Cranor
P3P Specification Working Group Chair
Received on Wednesday, 16 August 2000 12:15:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:42:59 UTC