httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <>
Subject Re: proposed reply to PR 2793, request for P3P support
Date Mon, 14 Sep 1998 02:15:09 GMT
On Sun, 13 Sep 1998, Roy T. Fielding wrote:

> PR 2793 (Peter Corless <>) requests that we implement
> the P3P protocol <>.  I was tempted
> to respond directly to the report, but I believe this one requires some
> form of group consensus.
> My suggested response is as follows.  Your comments/votes would be
> appreciated.

Personally, when I saw the PR and went to look at P3P for the first time
my initial reaction was "huh?".  It was difficult to find either a real
summary of what the point of it, in a couple of paragraphs, is and it was
also extremely difficult find any technical specifics on exactly how it is
implemented that weren't all mixed in with non-technical rantings.

On a more practical point, since there is apparently no one overly
interested in it, it won't be done unless someone outside does it.  It is,
however, not apparent that there is any widespread support for it and it
is just one of a zillion "hey, wouldn't this be cool" proposed things
and, from your comments below and other things, it obviously isn't ready
for implementation.

So yea, your respones sounds fine.  

> The Apache Group does not intend to implement the P3P protocol as
> described in <> at this time
> or in the foreseeable future.  There are several reasons for this,
> each of which deserve attention:
>   1) P3P is an HTTP extension without proper peer review.
>      HTTP is a very flexible protocol, which makes it both easy to
>      implement extensions and easy to design them incorrectly.  P3P
>      defines a number of new status codes and reuses the 200 and 409
>      status codes.  The 409 status code is misused for the purpose of
>      signaling an additional agreement is necessary, rather than for
>      its intended purpose of signaling an action has failed because
>      the resource state conflicts with the requested action.  This
>      will result in protocol failure when P3P responses are combined
>      with remote authoring actions that use 409 to indicate merge
>      conflicts.  Additionally, the 530 response code (in the server
>      error class) is in fact a client request error, and thus belongs
>      in the 4xx class of codes.  Finally, P3P relies on the Mandatory
>      extension syntax, which has not yet been approved by the IETF.
>      HTTP extensions should be developed in an open forum where the
>      quality of the design is not restricted to the membership of the W3C.
>      P3P obviously needs that level of peer review if it is to
>      appropriate seven new status codes.
>   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.
>   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.
> The first two issues need to be addressed by the authors before the
> Apache Group will consider implementation of P3P.  The last issue is simply
> a realistic constraint which, we hope, will be remedied long before the
> other two issues are completed, mostly because WebDAV also requires an
> XML parser.  Nevertheless, it is the type of constraint that a protocol
> designer should be aware of before making significant changes to the
> amount of work needed to implement the protocol.
> ....Roy

View raw message