Re: closed P3P bug 698

On Jul 12, 2005, at 4:57 PM, Mark Nottingham wrote:

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

And if they want to use fragid for something else, they might not 
define it in the way we would need it defined for P3P use.

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

No, we don't say that applications have to define anything. We say that 
the attribute applies to the entire structure to which it is attached.

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

I'm not sure it is always application-dependent. The idea was to define 
a generic element that people could start using without waiting for 
every application working group to have to independently figure out how 
to do this.

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

Received on Wednesday, 13 July 2005 15:26:04 UTC