Re: #230: Considerations for registering new methods

On 20.10.2010 02:32, Mark Nottingham wrote:
>
> On 19/10/2010, at 9:11 PM, Julian Reschke wrote:
>>> 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?
>
> In as much as they describe requirements for the registration of new methods, and what is considered a conformant application, I think it's appropriate. Using the keywords has the advantage of unambiguously communicating the requirements.
>
> However, I'm not lie-down-in-the-road about using them.

My preference is to reserve those keywords for instructions on 
implementations, not processes.

>>> 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."
>
> Seems reasonable.

See <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1040>:

"Due to the parsing rules defined in &message-body;, definitions of HTTP
methods cannot prohibit the presence of a message-body on either the 
request or the response message (with responses to HEAD requests being 
the single exception). 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 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?
>
> Well, we could say that 304 is specific to GET/HEAD, and all other methods use 412 for failed conditions, but that bit of glue seems to be missing ATM.
>
> We should probably also warn that clients can't take it for granted that a resource will support conditional requests (if we don't already); this can be surprising if you're expecting it on POST/PUT, etc.
>
> It sounds like we should remove this sentence and open two new issues.

Hm.

Are we aware of any implementations that do PUT but do not handle 
If-Match? That would be surprising.

>>> 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).
>
> That can be dropped.

Maybe we should think of applications whether extensions? 
Authoring/Querying calendar data (CalDAV) would qualify as application, 
while things like namespace operations (WebDAV COPY/MOVE) or partial 
updates (PATCH) would be considered extensions.

>> 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?
>
>
> What this is saying is that the WebDAV methods should have been registered in a non-WebDAV specific document, to clarify that they can be used in other contexts.

If you take out the message definitions from WebDAV, little will be 
left. Really.

COPY/MOVE does require some understanding of collections. 
PROPFIND/PROPPATCH does require some understanding of metadata. 
LOCK/UNLOCK does require some understanding of locking semantics.

That's why I'm very nervous about making this a hard requirement; what 
it should be is a recommendation to make methods re-usable, and a 
reminder for the Expert Reviewers to check this.

Best regards, Julian

Received on Wednesday, 20 October 2010 16:12:42 UTC