Re: closed P3P bug 698

On 12/07/2005, at 7:45 AM, Lorrie Cranor wrote:

> Let's go with "Web resources transmitted over [HTTP1.1]"

Nit: this should be "Representations of Web resources transmitted  
over [HTTP1.1]."  You can't transfer a resource, only a  
representation of it.


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

Pointing it out in LC review seems like a good plan.


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

That adds more confusion, I think; what does it mean to 'carry  
forward privacy meta-data,' if the generic attribute is only meant to  
be used in interface descriptions, not on-the-wire artefacts?  I also  
don't see where the submission tells you how to use the generic  
attribute in a SOAP envelope.


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

So, how does this proposal improve that situation? A fragment  
identifier's semantics are determined by the media type in question;  
it can say what the scope of a fragid is.


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

So, it's OK that the structure might refer to other things? It seems  
the applicability would be ambiguous in that case. What I think  
you're really trying to say is that each format has to describe what  
it means to use the attribute, in terms of scope of application, for  
itself; e.g., for WSDL, if applied at the service level, it applies  
to the operations referenced from the service as well (this is what  
you say in the note, correct?).

This leads me to wonder what the purpose of defining a generic  
attribute is, if its applicability is always application-dependant.  
In other words, xi:Include and similar mechanisms are truly  
idependent of the formats they're used in; you can write a generic  
XInclude processor and feed it documents whose specific format it  
knows nothing about. I don't see any way that you can write reusable  
software that takes advantage of the generic P3P attribute; in each  
case of its use, application-specific scoping (and perhaps semantics)  
need to be specified as well.

Please understand that I don't think this will break things, just  
that it seems unnecessary, and might be an avenue for future abuse.

Cheers,

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

Received on Tuesday, 12 July 2005 20:57:53 UTC