W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

Re: #230: Considerations for registering new methods

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 19 Oct 2010 12:11:10 +0200
Message-ID: <4CBD6EBE.9010808@gmx.de>
To: Mark Nottingham <mnot@mnot.net>
CC: HTTP Working Group <ietf-http-wg@w3.org>
On 19.10.2010 08:04, Mark Nottingham wrote:
> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/230>
>
> I've incorporated the proposal below as a starting point:

Thanks a lot.

I have some comments, both editorial and content-wise; almost the same 
apply to #229 (status codes).

> --->8---
>
> When it is necessary to express new semantics for a HTTP request that aren't specific to a single application or media type, and currently defined methods are inadequate, it may be appropriate to register a new method [ref].
>
> New methods SHOULD be potentially applicable to any resource. I.e., they should not be specific to any particular media type, "type" of resource, or application.

General question: is the use of RFC2119 keywords appropriate here? What 
about the "should" in the 2nd sentence?

> New methods MUST NOT prohibit a message-body on either the request or the response message; however they MAY specify that only a zero-length body is allowed.

I think it would be good if we rephrased that as a general statement 
about HTTP methods, and then pointed out that new methods need to follow 
that.

Such as:

"Due to the parsing rules defined in ..., HTTP methods cannot prohibit 
the presence of a message-body on either the request or the response 
message (with the single exception of HEAD responses). Definitions of 
new methods cannot change this rule, but they can specify that only 
zero-length bodies (as opposed to absent bodies) are allowed."

> New methods MUST define whether they are safe [ref] and whether they are idempotent [ref]. They MUST also state whether they can be cached [ref to p6]; in particular what conditions a cache may store the response, and under what conditions such a stored response may be used to satisfy a subsequent request.

Agreed. We'd better make sure that our method definitions give a good 
example how to do this ;-)

> New methods SHOULD explain how conditional request headers [ref] affect the response (if there is any effect).

Wow. I always thought they apply to any method; thus extensions methods 
can't be special. Maybe this deserves a separate issue?

> HTTP methods SHOULD be registered in a document that isn't specific to an application or other use of HTTP, so that it's clear that they are not specific to that application or extension.

That's very vague (what does "other use" mean).

Maybe we should start with examples, and then come up with guidelines?

- PATCH (RFC 5789) is certainly a good example for a generic definition.

- MKCALENDAR (RFC 4791) is certainly a good example for something that 
shouldn't have been a separate method.

I think most of us agree on the above. But what about things between 
these extremes, such as WebDAV?

> ...

Best regards, Julian
Received on Tuesday, 19 October 2010 10:11:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:30 GMT