Re: Comments on P3P WD of 24 April 2000

Thank you for your comments on the 24 April P3P working draft.

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

We have clarified the spec to make it more clear that mechanisms
may be developed for other protocols to use P3P. We don't specify
them, but we don't preclude them from being specified in the future.

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

While your proposal would work, we believe our current syntax also
works. P3Pv1 does describe the kind or relation. We have not
defined a MIME type for P3P (although this is something we
are looking into).

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

We are looking into the possibility of defining a P3P MIME type.
In the mean time, we believe using .xml makes implementers'
lives easier because they don't have to do any special server
configurations to have the correct content type sent.

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

The current syntax can be parsed by an RDF parser.

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

True, when you include content from multiple sites you will need
multiple round trips to fetch the P3P policy. But the alternative
would allow sites to specify policies for servers they do not 
control, perhaps maliciously.

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

We're not sure what you mean here. We think the XML namespace
is essential.

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

The implementers in our group say they are happy with the
current syntax and have found it easy to parse with or without an
XML or RDF parser.

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

Other mechanisms could be defined for other protocols
(not necessarily using a policy reference file).

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

The main reason to do this is so as not to submit a form until you
have checked the policy and are ready. In the May 10 spec we have
added a new mechanism - a p3p.xml file -  which should make this 
mostly unnecessary.

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

Our p3p.xml file addresses this. See also section 2.3.5 of
the May 10 spec http://www.w3.org/TR/P3P/#forms

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

This has been changed to referencing policies.

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

See above.

Regards,

Lorrie Cranor
P3P Specification Working Group Chair

Received on Wednesday, 10 May 2000 22:52:03 UTC