[In order for any reply to be added to the PR database, ] [you need to include <[EMAIL PROTECTED]> 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 State-Changed-Why: 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
