Re: proposed reply to PR 2793, request for P3P support

["Roy T. Fielding" <fi...@kiwi.ics.uci.edu>]

Daniel writes:
> Concerning item 3) I have developped a C library [1] [2] for XML/RDF/NS
>parsing/encoding and if W3C licence [3] is Ok w.r.t. the Apache
>group I guess it could be used for P3P (or WebDav since I actually
>started coding this XML piece with WebDav support for Apache in mind !).
>...
>[1] ftp://rufus.w3.org/pub/XML/cvs-snapshot.tar.gz
>[2] http://dev.w3.org/cgi-bin/cvsweb/XML/
>[3] http://www.w3.org/Consortium/Legal/copyright-software.html

Sounds great.  The W3C license is compatible with that of Apache, so
that shouldn't be a problem.

Massimo writes:
>P3P doesn't extend HTTP, this was one of the hottest point since the
>very beginning and we decided it was not the right way, as Roy was
>saying, to just extend http for p3p's needs. P3P is an application 
>based on http and does not modify/extend it (and, can work with http

You have been misinformed.  HTTP is an application-level protocol in
which the application semantics are visible in the message by design.
Anytime you change the semantics of a message you are making an extension
to the protocol, not just riding on top of the protocol.

>1.0 even): the "response codes" are simply codes internal to P3P. 
>Since their behaviour is pretty much like http status codes, we
>decided to be smart enough (<smile>) to assign them numeric codes 
>that are compatible and do not clash with http codes, so that if 
>in the (long?) future P3P becomes an established standard and 
>someone starts claiming the use of http codes for privacy, the 
>same numbers could be possibly reused.

What makes you think the 430-435 HTTP status codes won't be assigned
to some other purpose in the meantime?  I have tried to explain why this
type of code inheritance is wrong many times in HTTP-WG and it just
doesn't seem to get through: If you are expressing HTTP semantics and
only HTTP semantics, a three-digit classified status code makes sense
because it allows uncomprehending participants in the communication to
know what default processing is expected for the message.  For any other
use than that, a numeric code of any kind is just a poor design.
HTTP itself would not be designed that way if it was possible to undo
the mistakes of the past.

>Anyway, sorry for the confusion that arose, we'd have been clearer in the 
>spec: I'll include a note on this in the next draft.

You are not going to remove the confusion until you get rid of those codes.
Just use a token with identifiable semantics relative to the namespace.
Making it look like an HTTP status code will not ease the transition.

None of this changes the fact that you are misusing the 409 status code
for something other than the semantics of 409.  Most of the uses are to
tell the client that it must try again with a different set of semantics
included with the next message, in much the same way as 401 Unauthorized,
but with a sufficient change in semantics that a new code is required.

>And, by the way, transport in http is only one of the possible
>tranports, there are also other transport mechanisms, like for
>instance using the html LINK tag. 

An external link is the proper mechanism if what you want is a reference
to the privacy policy of the site. P3P goes far beyond that to the point
where it is placing additional semantics within each message, replacing
cookies with a different syntax and defining a sequence of interactions
for negotiating an acceptable policy.

>>   2) P3P has significant implications on the cachability of responses.
>> 
>>      The P3P specification fails to address the issues of caching
>>      normal responses or allowing intermediaries to negotiate proposals
>>      on behalf of the user agent or origin server.  Even the simple
>>      identification of sharable versus non-sharable response is ignored.
>>      As specified, P3P would fail to interoperate across any shared cache.
>
>The cache issue has also been one of the "hot spots" in the p3p discussion.
>P3P should work fine with cache if the LINK method is used. In the other 
>case, I'd need further inputs, so far P3P can cope with cache because
>of the postURI field, although it might not be the most elegant
>solution. Anyway, I understand P3P can have (still) a number of
>problems: any suggestion on the cache issue is appreciated, P3P is not 
>a standard yet, and we plan to spend this last phase in collecting
>feedback from implementors, so you're all MORE than welcome to let me 
>know in detail what its problems are (and what your solution could be ;-)

All of your examples indicate messages that are intended for one and only
one user agent.  The obvious fix for them is to add

    Cache-Control: private

to every response message.  However, that still doesn't deal with the
overall issue of when a P3P affected response should or should not be
cached, when the server should mark the response as private or no-cache,
and how that decision impacts network performance and server scalability.

You need to solve this issue -- it is one of those things that cookies
failed to deal with and ended up being screwed.  Right now the P3P proposal
is no better than adding a few extension-params to the Set-Cookie syntax.

>>   3) P3P requires the introduction of an XML/RDF parser
>> 
>>      XML is not something that a normal server needs to parse, and thus
>>      there are no known XML parsers with a C source code license that is
>>      compatible with the one Apache uses to distribute our code.  We would
>>      either have to wait for one to become available, or create our own,
>>      which is a non-trivial task given the overly abundant use of
>>      semantics-by-reference and unbounded macro inclusion found in XML,
>>      including the examples used by the P3P specification.
>> 
>>      Speaking of which, the XML specification is not complete without
>>      a finished resolution of the XML namespace issue and its incorporation
>>      into the requirements for XML.
>
>This is, luckily, not a problem: it is true that P3P uses XML/RDF
>syntax, but it is constrained to a specific structure (see the BNF
>;-). In other words, we use for the protocol chunks like (say)
>
><BLA>
> <FOO ATTR="minnie">
></BLA>
>
>but this is a static structure, it cannot be changed (must conform to 
>the BNF), and it is not allowed to use other equivalent forms of XML.
>So, no need for XML/RDF parsers (although of course one could re-use them 
>as well).

Think again

    data-xfer = <XML formatted data element name-value pairs>

XML sucks as a static syntax -- it's only advantage is the extensibility.
I can guarantee you that a fixed parser won't be able to parse an
in-practice P3P XML template even a year down the line.  New tags will be
added as soon as some overly-caffeinated programmer at Microsoft thinks
that it will save them time to add a new tag rather than misuse the
existing ones, and of course they will be exactly right in doing so
because a static syntax is always the wrong design for the Web.
That is why most existing HTTP header field-value syntax is not static.

.....Roy