www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From field...@apache.org
Subject Re: protocol/2793: When will Apache support P3P? Any Plans?
Date Tue, 15 Sep 1998 20:11:07 GMT
[In order for any reply to be added to the PR database, ]
[you need to include <apbugs@Apache.Org> in the Cc line ]
[and leave the subject line UNCHANGED.  This is not done]
[automatically because of the potential for mail loops. ]
[If you do not include this Cc, your reply may be ig-   ]
[nored unless you are responding to an explicit request ]
[from a developer.                                      ]
[Reply only with text; DO NOT SEND ATTACHMENTS!         ]

Synopsis: When will Apache support P3P? Any Plans?

State-Changed-From-To: open-suspended
State-Changed-By: fielding
State-Changed-When: Tue Sep 15 13:11:05 PDT 1998
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 new set of interaction semantics for indicating that
     an agreement is needed and additional data be provided before a
     request can be processed. The 409 status code is misused for that
     purpose 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 use of pseudo-HTTP response codes
     within the agreement field syntax will certainly cause confusion
     with real HTTP status 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 a 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.  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.

     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 Fielding (on behalf of the Apache Group)

Category-Changed-From-To: general-protocol
Category-Changed-By: fielding
Category-Changed-When: Tue Sep 15 13:11:05 PDT 1998

View raw message