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.

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