698 2004-05-03 13:48:03 +0000 Mark Nottingham's proposed wording changes for P3P generic attribute 2010-08-04 23:23:12 +0000 1 1 1 Unclassified P3P P3P beyond HTTP unspecified Other other REOPENED http://lists.w3.org/Archives/Public/public-p3p-spec/2004Apr/0016.html P2 normal --- 1 lorrie rigo oldest_to_newest 1778 0 lorrie 2004-05-03 13:48:03 +0000 See Mark's email at http://lists.w3.org/Archives/Public/public-p3p-spec/2004Apr/0016.html and followup discussion 4395 1 lorrie 2005-06-30 19:48:49 +0000 I believe Mark's comments have been incorporated into the redraft http://www.w3.org/P3P/2005/WD- P3P11-20050701.html#generic_attribute. Mark should tell us if he is not completely satisfied. 4435 2 rigo 2005-07-07 17:32:15 +0000 http://lists.w3.org/Archives/Public/public-p3p-spec/2005Jul/0014.html 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