W3C home > Mailing lists > Public > public-p3p-spec@w3.org > November 2006

Re: RESPONSE NEEDED: P3P 1.1 note publication and working group close

From: Massimo Marchiori <massimo@math.unipd.it>
Date: Fri, 10 Nov 2006 18:32:40 +0100
Message-ID: <eaff15140611100932q42fe2149t92c566f39676023d@mail.gmail.com>
To: "Lorrie Cranor" <lorrie+@cs.cmu.edu>
Cc: public-p3p-spec <public-p3p-spec@w3.org>, "Rigo Wenning" <rigo@w3.org>

I am a bit late with the review, but since I did browse the spec, I include my
quick comments up to now, gathered by a read of the spec. Exec summary: as a
W3C note, I don't think there are stopovers (so you can well count
mine as an extra yes).
Fixing some of the things below could anyway help, now or for a future
iteration.

Thanks and keep up the good work! :)
 Massimo



----------------

Comments on P3P draft version: http://www.w3.org/TR/2006/WD-P3P11-20061006/


Section 2.5, the P3P Generic Attribute.
This is deja vu, and it still seems to be the most problematic part of the spec.
The real problem with the generic attribute is that it tries to be a "catch-all"
in all those situation where the classic p3p1.0 association methods fail.
But the problem is that whereas the p3p1.0 association methods fall within
the HTTP processing model, the generic attribute doesn't have a
processing model,
so it's quite unclear what kind of actions its scope lies in: this is severe
as there's a MUST requirement to be fulfilled, i.e. the generic attribute
is not just a hint.
A couple of examples: suppose one queries an XML database of documents (eg thru
XQuery), and get a data slice that has the p3p generic attribute in it:
what does this mean for the query service and/or the client?
Or, suppose one encounters a piece of RDF/XML with the generic attribute in it:
what does it mean, given that "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" ? RDF/XML viewed as XML does have a tree
structure... Conversely, muddling the borders, for example, any XML
view generated
from a relational database come from a relational model, and so not
from a tree structure.
So all in all, having a MUST implies the specifics of applications
(where to do something,
and what to do) ought to be sharply defined, which doesn't look the
case presently.


In the XML encoding of Example 3.2:
catalog@example.co.uk --> catalog@example.com

In the URI reference: "August 1998" -> ""January 2005" (..!)

There are several "eaten spaces" when markup is present
eg Agents and P3P</a></q>P3P
   <code>authority</code>is defined
etc.

section 3.36 -> section 3.3.6

(playing the Susan here ;-): all refs to Sections of the
spec should have "Section" and not "section"
(cf. for example first paras in 1.2.1).

There are several occurrences of "an" where "a" should be
used (eg "an special token").

A spelling check should be done (eg "acheived").

Rather severe: extensions should all be in the p3p11 namespace.
But they don't seem to (eg ppurpose etc): both the EBNF and
the XML Schema definition should be corrected.

Section 4.1:
"The P3P compact policy header has a quoted string that may contain
one or more delimited tokens (the "compact policy")."
This is not true any more now that there are compact
statements. You could rewrite as
"The P3P compact policy header has a quoted string (the "compact policy")
that may either contain one or more delimited tokens or compact statements."

Then, compact statements ought to be also present in the EBNF (rule [58]), as
currently they are not (?):
now it is
compact-policy = compact-token *(" " compact-token)
whereas it could e.g. be
compact-policy =  (compact-token | compact-statement) *(" "
(compact-token | compact-statement))

Section 4.2:
"If a token appears more than once in a single compact policy, the
compact policy has the same semantics as if that token appeared only
once. "
This was true in P3P1.0, but not in P3P1.1 due both to the OHO token, and
to the presence of compact statements.

After the second example of Sec.5.7. there is a double pseudo-repetition of
the three paras: one of the two repetitions must be stricken.


Finally, things I planned to check but run out of time:

Possible problem of *forward-compatibility* that not all user-defined
P3P1.0 dataschemas are directly translatable into the new XML-Schema based
P3P1.1 dataschemas (cf. P3P1.1 Data Element forward transform); in any
case, now in Section 5.7:
"Web sites using custom data schemas MUST publish these schemas in
P3P1.1 format only."
would seem to prevent forward-compatibility in some cases... which
seems to contradict
the later example (classicalmusicpreference.baroquemusicpreference)

On backward compatibility, check whether all the p3p1.1 EXTENSIONS
position are compatible
with p3p1.0 schema (http://www.w3.org/TR/P3P/#Appendix_schema ), i.e.
more in general,
if every p3p1.1 xml document does validate wrt the p3p1.0 schema.
Received on Monday, 13 November 2006 01:26:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 13 November 2006 01:26:23 GMT