Subject: Re: Issue 72, was: Status of IANA Considerations (registrations and registries) -- issues 40, 59, 72, 79

From: Julian Reschke <[email-masked]>
Date: Sat, 12 Jul 2008 18:48:48 +0200

Julian Reschke wrote:
> ...
>> - an additional document, referencing Part 2, and making the 
>> registrations for all other methods
> 
> I can work on that, but we probably should discuss whether this is 
> supposed to become a WG work item.
> ...

Proposal: 
<http://greenbytes.de/tech/webdav/draft-reschke-http-method-registrations-latest.html>.

BR, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 14 Jul 2008 21:54:09 +1000

Looks good from here, and yes, this should be a WG item.

Q: any more thoughts about whether to add things like safety,  
idempotence to the registry?

Cheers,

On 13/07/2008, at 2:48 AM, Julian Reschke wrote:

> Proposal: <http://greenbytes.de/tech/webdav/draft-reschke-http-method-registrations-latest.html 
> >.
>
> BR, Julian
>

--
Mark Nottingham     http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Tue, 15 Jul 2008 13:56:22 +0200

> Looks good from here, and yes, this should be a WG item.

OK, will prepare that as draft-ietf-httpbis-method-registrations. 
Publication will have to wait until draft-ietf-httpbis-p2-semantics-04 
is ready.

> idempotence to the registry?

I'm in favor of adding stuff that would be important to know in an 
implementation, such as: "is this method safe" (so can I retry, and can 
I automatically follow redirects?).

For "safety" this is pretty clear, for idempotency I'm not totally sure 
(yet).

Furthermore: what about cacheability? In WebDAV space, I see many specs 
making statements about the cacheability of a method result. Is this a 
good idea? After all, 
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.13.4> states:

"Unless specifically constrained by a cache-control (Section 14.9) 
directive, a caching system MAY always store a successful response (see 
Section 13.8) as a cache entry, MAY return it without validation if it 
is fresh, and MAY return it after successful validation."

So if a (success) method result is known not to be cacheable, the server 
must send it with "Cache-Control: no-cache" anyway, right?

Proposed next steps:

- add "safeness" to the method registration template (Part 2)
- move proposed initial registration into a WG draft

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 18 Jul 2008 13:51:59 +0200

> Looks good from here, and yes, this should be a WG item.

<http://wiki.tools.ietf.org/wg/httpbis/trac/browser/draft-ietf-httpbis-method-registrations/latest>

> idempotence to the registry?

I have added "safeness" to the registration "template" (in quotes 
because it currently isn't really a template) -- 
<http://wiki.tools.ietf.org/wg/httpbis/trac/changeset/286>.

The relevant sections now read:

3.1.  Method Registry

    The HTTP Method Registry defines the name space for the Method token
    in the Request line of an HTTP request.

    Registrations MUST include the following fields:

    o  Method Name (see Section 3)

    o  Safe ("yes" or "no", see Section 8.1.1)

    o  Pointer to specification text

    Values to be added to this name space are subject to IETF review
    ([RFC5226], Section 4.1).  Any document registering new method names
    should be traceable through statuses of either 'Obsoletes' or
    'Updates' to this document.

    The registry itself is maintained at
    <http://www.iana.org/assignments/http-methods>.

and

11.1.  Method Registry

    The registration procedure for HTTP Methods is defined by Section 3.1
    of this document.

    The HTTP Method Registry located at
    <http://www.iana.org/assignments/http-methods> should be populated
    with the registrations below:

    +---------+------+-------------+
    | Method  | Safe | Reference   |
    +---------+------+-------------+
    | CONNECT | no   | Section 8.9 |
    | DELETE  | no   | Section 8.7 |
    | GET     | yes  | Section 8.3 |
    | HEAD    | yes  | Section 8.4 |
    | OPTIONS | yes  | Section 8.2 |
    | POST    | no   | Section 8.5 |
    | PUT     | no   | Section 8.6 |
    | TRACE   | yes  | Section 8.8 |
    +---------+------+-------------+

As usually, this raises more questions:

- Is the explanation of "safeness" sufficient?

- Did I get the values for the HTTP/1.1 methods right? (what about 
CONNECT and TRACE?)

BR, Julian