Fwd: closed P3P bug 698

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.
>> 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.
>> 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.
>
> 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.
>> 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?
>> 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.
>> 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.
>
> 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.
>
> * The status section says that changes from P3P 1.0 are highlighted; 
> nothing shows up in my browser (Safari or Mozilla).
>
> 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 Wednesday, 6 July 2005 18:43:43 UTC