httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Veillard <>
Subject Re: proposed reply to PR 2793, request for P3P support
Date Mon, 14 Sep 1998 19:36:23 GMT
  Hi Roy,

 having seen your mail on the list, and since it seems that you were
raising quite a few points about P3P I took the liberty to forward it
to people working on it at W3C, with the hope that it could be useful
to both groups.
 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 !).



----- Forwarded message from Massimo Marchiori <> -----

Date: Mon, 14 Sep 1998 11:01:35 -0400
From: Massimo Marchiori <>
To: Daniel Veillard <>
Subject: Re: (forw) proposed reply to PR 2793, request for P3P support
X-Mailing-List: <> archive/latest/1509

Hi Daniel,
thanks a lot for your email: here is my answer to Roy, feel free to 
forward/include it to Roy and the Apache group.

> 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.

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
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.
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.

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. 

>   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 ;-)

>   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)

 <FOO ATTR="minnie">

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).

> The first two issues need to be addressed by the authors before the
> Apache Group will consider implementation of P3P.  
As said, point 1) is not a problem. For point 2), there is the partial
answer of the LINK mode (apache could implement that mode only), but
in any case I'll be more than happy to get all the feedback on this
point that the apache group is able to give, and to ask the wg to 
modify the spec accordingly.

> 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.

As said, this too should not be a problem :-)


| Massimo Marchiori                    Room NE43-350            |
| The World Wide Web Consortium (W3C)  545 Technology Square    |
| MIT Laboratory for Computer Science  Cambridge, MA 02139, USA |
| WWW:    Phone: +1 (617) 253 2442 |
| Email:                Fax:   +1 (617) 258 5999 | 

----- End forwarded message -----

-- | W3C  MIT/LCS  NE43-344  | Today's Bookmarks :
Tel : +1 617 253 5884  | 545 Technology Square   | Linux, WWW, rpm2html,
Fax : +1 617 258 5999  | Cambridge, MA 02139 USA | badminton, Kaffe, | HTTP-NG and Amaya.

View raw message