Re: Comments on PEP draft

At 05:17 PM 4/29/97 -0700, Jim Whitehead wrote:

Hi Jim,

>Here are some brief comments on the latest PEP draft.

Sorry for the delay - I have been out for the last two days looking for a
new place to live...

>My understanding of this draft is that is only really usable to describe
>extensions to HTTP that involve the use of new headers to modify the
>semantics of existing methods.  If you create an extension which defines
>new methods, then PEP doesn't allow you to specify what those new methods
>are, nor any new response codes those methods may generate.

PEP is indeed designed to allow to extend both methods, headers, and status
codes in HTTP. It may not be clear enough in the draft, but I will
incorporate it into the next one. Let me try and give an outline here:

HTTP methods have always been difficult to extend for several reasons:
There can only be a single method in each request and everybody must agree
on the semantics for how to handle the new method. Headers can modify the
semantics but can not override the overall semantics of the method. For
example, a header can not turn a GET request into a PUT request.

Status codes have almost the same properties as methods. However, it is
somewhat easier to extend them as unknown status codes must be treated as
the x00 code of that class.

Headers are relatively easy to extend - we all know that - and either love
or hate it. However, the advantage with headers is that the header space is
a relatively open compared to methods and status codes - there can be more
than one!

This is the whole reason why PEP uses headers and not directly changes the
method or the status codes: it allows for multiple extensions to be
deployed simultaneously without risking fighting over the method and the
status code.

This has an important impact on many of the things, DAV wants to do.
Imagine an example where a DAV client wants to upload a document but only
if the server does the following:

	1) Create the document on the server as X
	2) Link the document into collection Y

If the server can't do both, the transaction must fail. In PEP, this would
look like this:

	PEP-PUT /my.new.document.html HTTP/1.1
	PEP: {{map "http://www.w3.org/ext/link" Collection-1} {strength must)}
	Collection-1: "/my.collection.html"

In other words, one of the forces of PEP is that it can express complex
transactions on the wire. It is, of course, another question how the server
handles transactions internally but this is server implementation land
outside the scope of PEP.

>If my understanding is correct, then there should be some text in the draft
>explaining the scope of PEP.  If my understanding is incorrect, then
>perhaps there should be an example showing how PEP can be used to describe
>an HTTP extension which uses a new method.

I agree that using the "PEP-" prefix gives the impression that the method
has been sub-classed. This is not strictly necessary but I think we can
make it better. What if we introduce the "PEP" method as a placeholder for
new methods which are now sub-classed from existing methods. The PEP
methods will have the following semantics:

***

The PEP method indicates that the semantics of this request are defined by
one or more PEP extensions with strength "must" included in the request.
The origin server MUST identify, consult and adhere to the relevant
extension specification(s) or respond with 420 (Bad Extensions). 

A successful response SHOULD be 200 (OK) if the response includes an
entity, 202 (Accepted) if the action has not yet been enacted, or 204 (No
Content) if the response is OK but does not include an entity. If no
extensions have strength "must", the response SHOULD be 400 (Bad Request).

If the request passes through a cache and the Request-URI identifies one or
more currently cached entities, those entries should be treated as stale.
Responses to this method are not cachable.

***

On the status code side, PEP already defines a placeholder status code
which is 420 (Bad Extensions). The 420 code means that "somewhere in this
response, a PEP-Info (or C-PEP-Info) header will explain what went wrong."
That is, 420 is in itself only a placeholder to make sure that we get the
right behavior from proxies. The exact error will be explained by the
extension itself.

This is very similar to the 401 (Unauthorized) status code, where the
client has to look for the WWW-Authenticate header in order to know how to
try again.

>Some nits:

Thanks!

Henrik
--
Henrik Frystyk Nielsen, <frystyk@w3.org>
World Wide Web Consortium, MIT/LCS NE43-346
545 Technology Square, Cambridge MA 02139, USA

Received on Thursday, 1 May 1997 08:45:19 UTC