P3P Specification Comments.

Hi all,

These are comments based on the 29 April Draft. 

1.1.2 Example of P3P in Use
Basically the example leaves out important protocol details and belongs more in an introduction document rather than in a specification.  This example is very different that the actual workings of the P3P protocol.  For example, when the server returns the home page it does not return the P3P policy it returns a reference to a document that contains references to privacy policies.

1.1.5 Implementing P3P 1.0 on Servers

Last sentence in 1.1.5 should be removed since it implies a conflict with last sentence in 2.1.1.  However it brings up an interesting point.  

How can the user tell if the policy applies to HTTP traffic only?  For example an applet that makes a socket connection and sends some data to the server.  How is the user told that this data conforms to some policy?

2.1 Overview ad Purpose of Policy References

(policy references are) "typically less than 50 bytes"  This should be removed since there is no way to know.  The example policy reference in the specification is 51 bytes.  http://catalog.example.com/P3P/PolicyReferences.xml

2.2.1.1 Use of the HTTP Extension Framework

"The P3P extension declaration and s/policy header/policy reference header/

2.2.2 Syntax using the link tag. [last paragraph]

Use of an HTML tag is defined but, you only associate policies with resources fetched using HTTP.  You assume that HTML can only be retrieved via HTTP.  Other transport protocols exist ex. WAP Protocols.  

Change text to something like "... if user agents support retrieving HTML content over HTTP then they MUST handle both mechanisms interchangeably".

2.3.2.6 The METHOD element.

This is an attempt to control HTTP functionality.  You could specify policyA for HEAD requests and policyB for GET requests thereby breaking the meaning of HEAD, e.g. difference in responses based on the two requests.

2.3.3.1 Purpose of Indirect Policy References

Just an observation, one thing I have noticed about all the privacy work is that there are very different laws governing privacy in the world.  In your example isn't it more likely that CatalogExample couldn't actually have one policy for the entire world?

2.3.5 Forms and Related Mechanisms
 
Inventing an HTTP control mechanism.

Why not use the OPTIONS method on a resource and the Allow response header to determine if a METHOD is supported or not.  Rather than relying on a P3P policy reference document.

If a Policy Reference on a response differs from the Policy reference file used when determining which policy applies what actions should be taken?  Too late since you already accepted the policy.

Appendix

Reference to RFC 2068 should be changed to RFC 2616

http://lists.w3.org/Archives/Public/www-p3p-public-comments/2000Apr/0007.html

Questions and suggestions:

No real answer was given to 
http://lists.w3.org/Archives/Public/www-p3p-public-comments/2000Apr/0030.html

Does the spec assume that a policy applies to all parts in a multipart message?
User won't know which policy is in effect.  Is the one policy one resource rule broken when a multipart response is returned?

(see attached)
Using forms, the prompts you suggest can only be displayed after the submit button on the login page has been hit since you don't know which submit button was hit and therefore what your target is (consider multiple submit buttons on a single page).  Counterintuitive for users. Only after you hit submit do you know what the data is used for.  User would probably want to know before hand.

No explicit acceptance makes P3P no better than what is available now.  Increases network load for no real benefit.  Why not take advantage of cookies.

GET home.html if there isn't a cookie indicating this user has read the policy then redirect to policy pages.  If cookie exists but indicates not accepted then do something appropriate.

tom.