Re: closed P3P bug 698

Rigo and I discussed these comments further and have some additional 
thoughts... everyone please let us know if you have any further 
concerns. If we don't hear any comments in the next few days Rigo will 
make the changes described below.

Lorrie


On Jul 9, 2005, at 10:41 PM, Lorrie Cranor wrote:

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

Still a little ambiguous, the sentence I propose is:

P3P 1.0 was designed to associate XML-encoded privacy policies with Web 
resources using URIs, Web resources using sets of URIs, or cookies.

>
>>>> 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]"

Let's go with "Web resources 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.

Rigo published a team note with Hugo Haas 
http://www.w3.org/TeamSubmission/2004/SUBM-p3p-wsdl-20040213/ titled 
Handling Privacy in WSDL 2.0.

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

Rigo notes that the above Team note explains how the generic attribute 
can be used in SOAP. Nonetheless the above sentence doesn't capture 
what we were getting it. Instead, how about,
"Because P3P 1.0 cannot be used in situations where a request is not 
directed to a URI,
the generic attribute is designed to help integrate privacy meta-data 
into XML languages, for example carrying forward privacy meta-data in 
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 
> necessary?

Rigo and I think we can drop this sentence.

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

The point here is that the generic attribute can't be applied to a 
structure that refers to itself. It should work on any XML 
serialization. So let's change this to:

"The P3P Generic Attribute MUST only be used on XML serialization and 
is only applicable to elements and sub-elements of the XML 
serialization to which it is attached. 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."

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

Rigo will fix.

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

Rigo will take care of it in the next draft.


> Lorrie
>
>
>
>>>
>>> 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 Tuesday, 12 July 2005 14:47:35 UTC