Re: My comments on the current last call draft

Louis,

Thank you for your comments on the February 11, 2000 P3P 
working draft. We issued a new working draft April 4 that
addresses some of your concerns. Many of the others
should be addressed shortly.

> Protocol extensions in particular are very difficult to deploy and really
> need to be the result of extensive profiling.  There is a large amount of
> text devoted to the use of the non-standard HTTP-EXT mechanism and policy
> reference caching without any concrete statements of the potential effects.
> I'm concerned that this kind of a priori postulation of performance impact
> is both out of scope for P3P and ill advised from an engineering standpoint.

We are in the process of reworking this so that there is only one
extension header, which simply provides the URI of a "policy
reference file." We expect to issue a public working draft with this
update on April 24. 

> There are also a number of serious editorial issues, including normative
> references to transient artifacts and incorrect or unnecessary use of ABNF.
> Also, a number of sections are defined in an overly informal and vague
> style.  This presents a major obstacle to outsiders (including myself) who
> want to evaluate P3P.

We are in the process of trying to clean up the specificaiton to make it
more readable. We will split the normative and non-normative references
into seperate sections in the next draft and fix the ABNF. While some
have argued that the ABNF is completely unnecessary, we have chosen
to keep it in because many implementers have told us they find it 
helpful (they would rather read that than the DTD).

> Example of P3P in use:
>  
> The example session between `Shelia' and thecoolcatalog.com should be
> rewritten as a functional description of servers and clients conducting a
> transaction involving a policy.  A state diagram would also be useful, and
> thecoolcatalog.invalid would be a more correct domain for the example
> server.

The example was really designed to be understandable by a more
general audience than would understand state diagrams. And using
non-standard top-level domain names would likely further confuse
this audience.


> Use of ABNF:
>  
> The liberal use of ABNF in the P3P specification isn't really necessary and
> only adds complexity.  XML in particular has a well defined syntax that
> allows for higher level descriptions (i.e., DTDs or schemas) to be used.
> This is much less error prone and easier to read.  The description of the
> use of ABNF in section 1.2 is particularly confusing: are the HTTP header
> rules intended to be processed as XML; is the intent that ABNF's ordering
> rules be ignored all the time, or only in rules that look like XML
> attributes?  Since there are already better notations for describing XML
> structures, why not just use one?  

We have a DTD, which is the normative defintion. The ABNF is for those
who find it useful. Those who don't find the ABNF useful can feel
free to ignore it.

> Even where ABNF is required, there are a number of minor errors.  For
> example, the first use of ABNF uses an undefined nonterminal `prefix' ---
> RFC 2774 calls this `header-prefix', which is defined as `2*DIGIT'; this
> means that the English description of HTTP-EXT prefixes as two digit numbers
> is misleading.
>  
> Finally, it is noteworthy that HTTP-EXT uses the RFC 822 syntax, not the RFC
> 2234 syntax.  P3P doesn't really use the 2234 syntax either, seeing as '|'
> is used as the alternation operator instead of '/'.

We will check this over and make sure all of the errors are corrected.

> Use of HTTP-EXT:
>  
> Use of an internet draft as a normative reference is in direct violation of
> RFC 2026 (section 2.2).  While the W3C isn't necessarily bound by the IETF
> process documents, I would call attention to the following excerpt from RFC
> 2026:
> 
>    An Internet-Draft that is published as an RFC, or that has remained
> 
>    unchanged in the Internet-Drafts directory for more than six months
> 
>    without being recommended by the IESG for publication as an RFC, is
> 
>    simply removed from the Internet-Drafts directory.
> 
> Are W3C Recommendations really allowed to use transient artifacts as
> normative references?  As of this writing, HTTP-EXT is available as an
> experimental RFC ( http://www.isi.edu/in-notes/rfc2774.txt
> <http://www.isi.edu/in-notes/rfc2774.txt> ), so at the very least the
> reference should be updated.  Note that RFCs with the Experimental
> designation are not considered to be standards.

We understand that HTT-EXT is not a standard. However, P3P
does not require general support for this mechanism. We think
it is useful rather than inventing our own similar mechanism
for the purpose. We will use the updated reference. 

> This specific use of HTTP-EXT:
>  
> Since ',' is a legitimate URI character, it can't be used as a list
> separator unless there is a requirement that all other occurrences be
> escaped.  I'm also concerned about the use of the (as far as I can tell)
> undefined nonterminal `local-URI'.

We have fixed this.

> The <meta> tag syntax:
>  
> As described, the <meta> tag syntax is in violation of HTML's content model.
> Why not just use the kludge that is already in HTML---<meta
> type="http-equiv" ...>?  Also, the names of the tags should be changed to
> lower case, so that they conform to XHTML 1.0.

Our switch to policy reference files gets rid of this problem as well.

> Indirect references:
>  
> This section is far too long.  Service replication and localization is a
> system administration issue and should be left to site administrators.  A
> simple paragraph requiring that a P3P user agent resolve all 3xx status
> codes is adequate.

Others felt this section was needed. Those who aren't interested 
need not read it.

> Reference caching:
>  
> The justifications of reference caching aren't explained very well.  If I
> understand section 2.4.1.2 correctly, there is assumed to be an external
> service that handles policy negotiation of behalf of multiple users.  Given
> the current web infrastructure, such a service would either be implemented
> as an intermediate proxy or as an extension to the user agent.  In the
> former case, the service would have to fetch the content anyway; the latter
> doesn't make a lot of sense to me, since an extended user agent would most
> likely just implement P3P.
>  
> Unless there is a specific, common configuration that benefits from
> reference caching it should simply be removed.  If reference caching is to
> remain, there should at least be some mention of the fact that a policy
> reference may live longer than the associated document.

We think this is an important feature, and we will revise our 
explanation (as well as making the revisions that come about
as a result of our switch to the policy reference file).

> The safe zone:
>  
> Taken literally, the safe zone would be an ideal location for a malicious
> client to launch an anonymous denial of service attack against a system.  A
> simpler solution to the problem the safe zone attempts to address would be
> to require that user agents use a strictly limited subset if HTTP headers
> (Host is the only really essential header for most requests) when requesting
> a policy document.

That is what we are suggesting.

> Also, it is unclear why HEAD is recommended.  The purpose of making a
> request to a site is to retrieve data; since the location of the policy
> document will be returned with the initial response, using HEAD only adds a
> round trip and the programs that generate dynamic content often don't
> implement HEAD.

That is explained as well. However, in some cases HEAD can be 
useful.

> Syntactic issues:
>  
> The XML syntax is not very consistent.  <PURPOSE>, <RECIPIENT> and
> <RETENTION> use empty tags extensively while <DATA> uses attributes.  I
> consider the former option to be superior, as illustrated by the example in
> section 3.4.1.  Also, the reuse of <DATA> in the data schema specification
> is extremely confusing.

We will work on making the syntax more consistent.

> Also, the skeleton data schema matches neither the ABNF description nor the
> complete example.

We have fixed this.

> Extensibility issues:
>  
> P3P data schemas have less expressive power and are harder to extend than
> either RDF or XML Schemas.  Is there any justification for not using one of
> those?

We find the P3P data schemas better suited to our specific purposes
and we believe they are easier to implement. 

> Data types:
>  
> The descriptions of the primitive and base data types should proceed in
> either a top-down or bottom-up direction.  The current ordering (primitive,
> base data schema, basic types) is confusing.

This has been fixed.

Regards,

Lorrie Cranor
P3P Specification Working Group Chair

Received on Thursday, 13 April 2000 21:57:37 UTC