Comments on P3P WD of 24 April 2000

Ad 2.1.1

Privacy policies can only be associated with resources retireved over
HTTP. Indeed they seem to be very much tied to the HTTP architecture.
Isn't that a bit limiting? There are also forms that are send by
e-mail and servers that work with FTP or RealAudio's protocols. And in
the future much of HTTP traffic may go over napster, gnutella or
freenet-like protocols. It is not clear how P3P would be extended in
that case.

Ad 2.2.2

The link element has a REL attribute of "P3Pv1", but normally the REL
attribute is for the kind of relation and the TYPE attribute holds the
name of the format. Shouldn't it be REL="privacy-policy" (or something
like that) with an optional TYPE="application/p3pv1" (or possibly
"text/p3pv1")?

Ad 2.2.2

The extension of the referenced file in the example is ".xml". Is
there no preferred extension for P3P files? The extension ".p3p"
suggests itself.

Ad 2.3.1

There is a reference to RDF near example 2.2, but the example doesn't
seem to conform to RDF syntax.

Also, the "about" attribute is given the XML Namespace of RDF, but it
is not clear why. It doesn't look like an RDF parser would be able to
understand the policy references and a P3P parser doesn't seem to need
such a long name for the attribute. In other words, what feature is
enabled by having this long name for the "about" attribute?

Ad 2.3.1

The URL "prefix" doesn't allow to specify a policy for a different
site or a different protocol than the one the references file is
linked from. How can you specify the policy for a form that is on a
different server? It seems you will need an extra round-trip if the
other server is HTTP, and there is no possibility if the other server
is not HTTP (e.g., mailto: or ftp:).

Ad 2.3.1

Why does the references file have an XML Namespace? Since it requires
HTTP anyway, it seems that the HTTP Content-Type is enough to
identify the file?

Omitting the Namespace would be shorter, but in particular it would be
more flexible: you can use the same file for P3P version 2 (assuming
it is backwards compatible), by just sending a different HTTP header
without changing the file.

Also, putting the namespace in the file is redundant, and redundancy
is an invition for errors (Content-Type for a different version than
the Namespace, e.g.). I believe I read in the spec somewhere that
ambiguity always result in the policy being ignored, but it is better
to reduce the possibility for ambiguities in the first place.

Ad 2.3.1

Why is the references file in XML syntax? It seems that to understand
P3P you need three parsers: HTTP, XML and P3P on top of the XML
parser. It will probably be easier to write a dedicated P3P parser.
That way one could use tools like flex and bison. I couldn't find text
explaining the reason for chosing an XML syntax.

Ad 2.3.2.5

HTTP uses a hierarchical URL scheme, where prefixes make sense, but
how would P3P be extended for other protocols? There is no way even to
put a URL in the POLICY-REF element that is *not* a prefix.

Ad 2.3.4

UAs may do a HEAD to get the URI of a policy. But if they do a GET
they are not disclosing anything more, but they get exactly the same
HTTP headers back and the resource as well, so why would they do a
HEAD? Seems just a waste of time.

Ad 2.3.4

In general, how can you know the policy of a site that you haven't
been to before? Say you find a form in a Web page that asks you to
fill in your name. Once you have submitted the form, you may get an
HTTP header back with a policy reference, but by then it is too late.
You could try to guess some other URL on that site and hope that doing
a GET on that returns a policy that covers this particular form as
well, but in general there appears to be no way to discover the policy
governing a resource without actually sending a request for that
resource.

Ad 2.4.3

This section is rather confusing: the title of 2.4 is "policy
references," but 2.4.3 actually talks about policies, not policy
references. The former may be immutable, the latter clearly are not.

Ad 2.5.1

See also 2.3.4. A HEAD and a GET always return the same headers, so
why would you do a HEAD?

What if the resource is returned by a PUT or POST request? A HEAD
request doesn't help in that case.

Even with a GET-type resource, you may not be able to do a HEAD
without disclosing sensitive information (if the GET results from a
form, for example).

A P3P compliant server is required to not use the information it gets
through a HEAD request, but the client cannot know whether the server
is compliant without actually sending the HEAD. So the client has no
reason to send the HEAD. Maybe what is needed is a new WHATIF request,
or maybe a way to include a link in a form to point to the place where
the policy can be downloaded before filling in the form.



Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos/                              W3C/INRIA
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Received on Tuesday, 2 May 2000 16:57:26 UTC