W3C home > Mailing lists > Public > public-p3p-spec@w3.org > July 2005

Re: closed P3P bug 698

From: Lorrie Cranor <lorrie+@cs.cmu.edu>
Date: Sat, 9 Jul 2005 22:41:11 -0400
Message-Id: <357c0b320f92339aa300f62fb376b241@cs.cmu.edu>
Cc: Mark Nottingham <mark.nottingham@bea.com>
To: 'public-p3p-spec' <public-p3p-spec@w3.org>

On Jul 6, 2005, at 2:42 PM, Lorrie Cranor wrote:

> Begin forwarded message:
>> From: Mark Nottingham <mark.nottingham@bea.com>
>> Date: July 6, 2005 11:47:56 AM EDT
>> To: Lorrie Cranor <lorrie@cs.cmu.edu>
>> Cc: Rigo Wenning <rigo@w3.org>
>> Subject: Re: closed P3P bug 698
>> Hi Lorrie,
>> I'm afraid that it doesn't really address my comments; I see only 
>> trivial changes in the latest draft. I'll try and expand upon my 
>> concerns below (feel free to forward to the list);
>>> P3P 1.0 was designed to associate XML-encoded privacy policies with 
>>> URIs, sets of URIs, or cookies.
>> For the record, I still believe it is more accurate and well-aligned 
>> with the Architecture of the WWW to say "P3P 1.0 was designed to 
>> associate privacy policies with Web resources using URIs, sets of 
>> URIs, or cookies." URIs are identifiers, not the targets of the 
>> policies in and of themselves.

changing "with URIs" to "with Web resources using URIs"  in the first 
paragraph of 2.5 sounds reasonable to me

>>> P3P 1.0 is well suited for use with HTML and XHTML pages transmitted 
>>> over [HTTP1.1] or [HTTP1.0].
>> What is this supposed to imply? It can also be used with GIF and JPEG 
>> images, etc.

good point... we should change "HTML and XHTML pages transmitted over 
[HTTP1.1]" to "content transmitted over [HTTP1.1]"

>>> However, P3P 1.0 cannot be used in situations where a request is not 
>>> directed to a URI, for example, some applications of Web Services 
>>> and SOAP.
>> Have you brought this text to the attention of the Web Services 
>> Coordination Group or the Architecture Domain lead? There are a 
>> number of existing mechanisms for associating metadata and policy 
>> with WSDL; I'm not sure that adding a purpose-specific one is 
>> desirable, from the WS standpoint.

There has been discussion of this among the web services folks and 
various members of the W3C team. Rigo can probably say who exactly this 
has been discussed with. I propose that at this point we leave this as 
is and when we go to last call we alert these folks to make sure they 
take a look at this point.

>> Also, using "SOAP" in this context may confuse some people; the 
>> attribute wouldn't actually appear in a SOAP infoset, but some may 
>> read this as saying it will.

So would you like us to strike "and SOAP" from "However, P3P 1.0 cannot 
be used in situations where a request is not directed to a URI, for 
example, some applications of Web Services and SOAP."

>>> In addition, P3P 1.0 cannot be used in situations where policies 
>>> apply to only a subset of the content associated with a given URI. 
>>> For example, while P3P 1.0 can be used to apply a P3P policy to an 
>>> entire form specified by XForms, it cannot be used to apply the 
>>> policy to only a single form field.
>> Why can't fragment identifiers be used to give the form field its own 
>> URI?

Because a fragment identifier does not mean precisely a single form 
field. If you place a fragment identifier in front of a form field, how 
do you know if it means just that field, all the fields for the rest of 
the page, or something else?

>>> The P3P 1.1 Specification provides a new binding mechanism to allow 
>>> for increased granularity beyond the URI level and to allow policies 
>>> to apply to content not associated with a URI. The new mechanism 
>>> takes the form of a generic attribute (similar to xml:lang) that 
>>> binds a P3P policy to an XML element.
>>> A P3P policy referenced by the P3P generic attribute MUST apply to 
>>> all data collection performed as a result of processing the 
>>> elementcarrying the P3P Generic Attribute. The policy also MUST 
>>> describe all data collection performed as a result of the processing 
>>> of all subelements.
>>> For all XML applications in which the P3P Generic Attribute is to be 
>>> used, the attribute MUST be imported into the relevant XML schema.
>> This can be read to say that use of XML Schema is required to use 
>> this attribute; that's inappropriate.
>>  Also, do you really want to constrain the way the attribute is 
>> represented in the schema (by importing it)? That seems needlessly 
>> draconian. I'd suggest dropping this sentence altogether.

I don't remember why this was added... Rigo, is this sentence really 

>>> If the element is re-used by mechanisms such as XInclude or the SVG 
>>> <use> Element, the Policy applies also in the new context where the 
>>> element is re-used. The policy is sticky to the element from which 
>>> it is referenced.
>>> The P3P Generic Attribute is designed for use in XML elements that 
>>> describe interfaces, not XML elements that encode user data. Thus, 
>>> it is meaningful to use the P3P Generic Attribute to associate a P3P 
>>> policy with a blank form or form field. The semantics of such an 
>>> association are that any data entered into the form will be 
>>> processed in a manner consistent with the P3P policy. It is not 
>>> meaningful to use the P3P Generic Attribute to associate a P3P 
>>> policy with data a user has entered into a form.
>>> The P3P Generic Attribute MUST NOT be used in applications, such as 
>>> RDF, that do not have a tree structure because its semantics relies 
>>> on the concept of subelements. In the case of RDF, one of the other 
>>> three binding mechanisms described in 2. Referencing Policies may be 
>>> used, as RDF makes use of URIs.
>> This highlights the biggest problem I have with this proposal; it 
>> tries to apply a generic attachment mechanism for policy to arbitrary 
>> XML formats. What makes a format become "tree structured?" WSDL, for 
>> example, does have a graph structure at the component level. 
>> Considering that most of the details of defining policy have to do 
>> with the scope and semantics of its attachment to a particular 
>> domain, I question the value of the definition of this attribute, and 
>> am especially concerned about the potential abuses of it. My 
>> preference would be to drop the section altogether.

Rigo, any comments?

>> A few other things I noticed;
>> * The spec refers to RFC2396 for URI; that has been superceded by 
>> RFC3986. You should probably also run through the document and make 
>> sure your use of "URI" (as opposed to "URI Reference") is still 
>> appropriate.

Rigo, please check.

>> * The status section says that changes from P3P 1.0 are highlighted; 
>> nothing shows up in my browser (Safari or Mozilla).

That was supposed to have been removed... Rigo, please update.


>> Regards,
>> On 30/06/2005, at 3:51 PM, Lorrie Cranor wrote:
>>> I have closed P3P bug 698 
>>> http://www.w3.org/Bugs/Public/show_bug.cgi?id=698
>>> This was based on your comments on the P3P generic attribute. Please 
>>> let us know whether you have any concerns about the resolution.
>>> Lorrie
>> --
>> Mark Nottingham   Principal Technologist
>> Office of the CTO   BEA Systems
Received on Sunday, 10 July 2005 02:41:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:02:19 UTC