You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Roy T. Fielding" <fi...@kiwi.ics.uci.edu> on 1998/09/14 03:58:31 UTC
proposed reply to PR 2793, request for P3P support
PR 2793 (Peter Corless <pc...@cisco.com>) requests that we implement
the P3P protocol <http://www.w3.org/TR/WD-P3P10-syntax/>. 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.
====================================================================
The Apache Group does not intend to implement the P3P protocol as
described in <http://www.w3.org/TR/WD-P3P10-syntax/> 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
Re: proposed reply to PR 2793, request for P3P support
Posted by Ben Laurie <be...@algroup.co.uk>.
Roy T. Fielding wrote:
>
> PR 2793 (Peter Corless <pc...@cisco.com>) requests that we implement
> the P3P protocol <http://www.w3.org/TR/WD-P3P10-syntax/>. 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.
+1. It may also be worth noting that the status of the P3P proposal is
such that it should only be used experimentally (it says here).
I suppose that pointing out that those who choose to ignore the process
should pay for their mistakes is going too far? :-)
Or perhaps we should simply ask when Cisco intend to start development
and how long it will take them?
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686| Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org/
and Technical Director|Email: ben@algroup.co.uk |
A.L. Digital Ltd, |Apache-SSL author http://www.apache-ssl.org/
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache/
WE'RE RECRUITING! http://www.aldigital.co.uk/
Re: proposed reply to PR 2793, request for P3P support
Posted by Bill Stoddard <st...@raleigh.ibm.com>.
+1.
Is anyone on the list working on an XML parser for Apache?
--
Bill Stoddard
stoddard@raleigh.ibm.com
Re: proposed reply to PR 2793, request for P3P support
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Roy T. Fielding wrote:
>
> PR 2793 (Peter Corless <pc...@cisco.com>) requests that we
> implement the P3P protocol <http://www.w3.org/TR/WD-P3P10-syntax/>.
> 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.
+1 as is. Very cogently written, as usual. (I particularly like the
bit about W3C doing their stuff in a region of reduced atmospheric
pressure. :-)
#ken P-)}
Ken Coar <http://Web.Golux.Com/coar/>
Apache Group member <http://www.apache.org/>
"Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>
Re: proposed reply to PR 2793, request for P3P support
Posted by Marc Slemko <ma...@znep.com>.
On Sun, 13 Sep 1998, Roy T. Fielding wrote:
> PR 2793 (Peter Corless <pc...@cisco.com>) requests that we implement
> the P3P protocol <http://www.w3.org/TR/WD-P3P10-syntax/>. 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 <http://www.w3.org/TR/WD-P3P10-syntax/> 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
>