Subject: I-D Action: draft-ietf-httpbis-method-registrations-08.txt

From: [email-masked]
Date: Mon, 02 Jul 2012 05:29:02 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Hypertext Transfer Protocol Bis Working Group of the IETF.

	Title           : Initial Hypertext Transfer Protocol (HTTP) Method Registrations
	Author(s)       : Julian F. Reschke
	Filename        : draft-ietf-httpbis-method-registrations-08.txt
	Pages           : 6
	Date            : 2012-07-02

Abstract:
   This document registers those Hypertext Transfer Protocol (HTTP)
   methods which have been defined in standards-track RFCs before the
   IANA HTTP Method Registry was established.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-method-registrations

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-httpbis-method-registrations-08

A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-httpbis-method-registrations-08

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Julian Reschke <[email-masked]>
Date: Mon, 02 Jul 2012 14:50:56 +0200

On 2012-07-02 14:29, [email-masked] wrote:
> ...

(This is just a freshup in order to avoid expiration)

Best regards, Julian

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 03 Jul 2012 14:19:01 +1200

> ftp://ftp.ietf.org/internet-drafts/

Thank you for that.

I just wish the registry recorded the other properties we request as 
considerations for new headers. eg. idempotent=yes/no. Not just 
safe=yes/no.

AYJ

---

From: mike amundsen <[email-masked]>
Date: Mon, 2 Jul 2012 22:24:16 -0400

+1 on listing idempotent. this is _critical_ in assessing the use/impact of
a method. I'm not clear why it's left off the listing.

mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me

On Mon, Jul 2, 2012 at 10:19 PM, Amos Jeffries <[email-masked]> wrote:

>>         Title           : Initial Hypertext Transfer Protocol (HTTP)
>> Method
>> Registrations
>>         Filename        : draft-ietf-httpbis-method-**
>> registrations-08.txt
>>         Pages           : 6
>>         Date            : 2012-07-02
>>
>> Abstract:
>> https://datatracker.ietf.org/**doc/draft-ietf-httpbis-method-**
>> registrations<https://datatracker.ietf.org/doc/draft-ietf-httpbis-method-registrations>
>>
>> http://tools.ietf.org/html/**draft-ietf-httpbis-method-**registrations-08<http://tools.ietf.org/html/draft-ietf-httpbis-method-registrations-08>
>>
>> http://tools.ietf.org/rfcdiff?**url2=draft-ietf-httpbis-**
>> method-registrations-08<http://tools.ietf.org/rfcdiff?url2=draft-ietf-httpbis-method-registrations-08>
>>
>>
>> ftp://ftp.ietf.org/internet-**drafts/<ftp://ftp.ietf.org/internet-drafts/>
>>
>
> Thank you for that.
>
> considerations for new headers. eg. idempotent=yes/no. Not just safe=yes/no.
>
> AYJ
>
>
>

---

From: Erlend Hamnaberg <[email-masked]>
Date: Tue, 3 Jul 2012 09:21:01 +0200

> a method. I'm not clear why it's left off the listing.

+1

-E

---

From: Julian Reschke <[email-masked]>
Date: Tue, 03 Jul 2012 09:28:38 +0200

On 2012-07-03 04:24, mike amundsen wrote:
> +1 on listing idempotent. this is _critical_ in assessing the use/impact
> of a method. I'm not clear why it's left off the listing.
> ...

Anything in the registry beyond the pointer to the defining 
specification is just a shortcut; just because it's not in the registry 
doesn't mean it's not there.

Adding new fields is possible, but we need find a balance; also, it 
requires deciding on the value for all methods in the list, which also 
doesn't come at zero cost :-)

Best regards, Julian

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 04 Jul 2012 11:10:36 +1200

On 03.07.2012 19:28, Julian Reschke wrote:
> specification is just a shortcut; just because it's not in the
> registry doesn't mean it's not there.
>

FYI: I made that comment at the point of writing a parser to handle 
methods.

Having just read may way through 2 WebDAV and 2 HTTP RFC and re-read 
the HTTPbis drafts, your post came as a bit of a non-surprise to find 
there were more RFCs which I now have to read just to find out if the 
methods listed are idempotent and/or cacheable.

Having a quick reference safe=yes/no, idempotent=yes/no would greatly 
assist writing parser that treated these methods as safe or idempotent 
without having to read/support every RFC on the block.

An indication of cacheability would also be great, yes/no/conditional 
kind of thing. Something to indicate if we proxy authors actually have 
to read the RFCs in question for correct interoperable behaviour when 
handling the method. Otherwise the method is going to get left on the 
"other" pile and not be supported fro a longer time. Which is a shame 
for new cacheable method responses.

Just the core considerations requested for new methods. Since those are 
the details we have already as a WG identified as important/critical for 
HTTP software implementing the method to be aware of.

AYJ

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 4 Jul 2012 09:40:21 +1000

Amos, I'd say that the caching semantics of any non-GET method are going to be subtle enough where you'll really need to read the spec. Furthermore, I'd be surprised if any more cacheable methods are defined (the WebDAV people seem to have settled down).

While it's true that the registry might give you a cheap discovery mechanism for finding new cacheable methods, I'd think a better indication would be user demand...

Cheers,

On 04/07/2012, at 9:10 AM, Amos Jeffries wrote:

> FYI: I made that comment at the point of writing a parser to handle methods.
> 
> Having just read may way through 2 WebDAV and 2 HTTP RFC and re-read the HTTPbis drafts, your post came as a bit of a non-surprise to find there were more RFCs which I now have to read just to find out if the methods listed are idempotent and/or cacheable.
> 
> Having a quick reference safe=yes/no, idempotent=yes/no would greatly assist writing parser that treated these methods as safe or idempotent without having to read/support every RFC on the block.
> 
> An indication of cacheability would also be great, yes/no/conditional kind of thing. Something to indicate if we proxy authors actually have to read the RFCs in question for correct interoperable behaviour when handling the method. Otherwise the method is going to get left on the "other" pile and not be supported fro a longer time. Which is a shame for new cacheable method responses.
> 
> 
> Just the core considerations requested for new methods. Since those are the details we have already as a WG identified as important/critical for HTTP software implementing the method to be aware of.
> 
> AYJ
> 
> 

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

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 5 Jul 2012 10:48:07 +1000

So, I'm hearing a lot of agreement on adding idempotency to the registry.

Anyone object to that as closing this issue?

Cheers,

On 03/07/2012, at 5:28 PM, Julian Reschke wrote:

> Anything in the registry beyond the pointer to the defining specification is just a shortcut; just because it's not in the registry doesn't mean it's not there.
> 
> Adding new fields is possible, but we need find a balance; also, it requires deciding on the value for all methods in the list, which also doesn't come at zero cost :-)
> 
> Best regards, Julian
>

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 5 Jul 2012 12:36:31 +1000

Marked for incorporation in -20.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 05 Jul 2012 08:41:39 +0200

> Anyone object to that as closing this issue?

Works for me. Hopefully it won't be too much work to figure out all 
values for existing methods :-)

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 05 Jul 2012 15:40:51 +0200

> values for existing methods :-)

Also, would it make sense to mention somewhere that for resource that 
support strong ETags, any request can be made idempotent by adding an 
"If-Match" header with that ETag?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 05 Jul 2012 19:22:08 +0200

> Marked for incorporation in -20.

-> <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1728>

The list I have for P2 is:

 >    +---------+------+------------+---------------+
 >    | Method  | Safe | Idempotent | Reference     |
 >    +---------+------+------------+---------------+
 >    | CONNECT | no   | no         | Section 2.3.8 |
 >    | DELETE  | no   | yes        | Section 2.3.6 |
 >    | GET     | yes  | yes        | Section 2.3.2 |
 >    | HEAD    | yes  | yes        | Section 2.3.3 |
 >    | OPTIONS | yes  | yes        | Section 2.3.1 |
 >    | POST    | no   | no         | Section 2.3.4 |
 >    | PUT     | no   | yes        | Section 2.3.5 |
 >    | TRACE   | yes  | yes        | Section 2.3.7 |
 >    +---------+------+------------+---------------+

Suggest to discuss the values for "CONNECT", while I start looking at 
all these WebDAV methods...

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 05 Jul 2012 20:02:14 +0200

> all these WebDAV methods...

...and here are the values for the other methods, with some inline comments:

+-------------------+------+------------+---------------------------+
| Method Name       | Safe | Idempotent | Reference                 |
+-------------------+------+------------+---------------------------+
| ACL               | no   | yes        | [RFC3744], Section 8.1    |
| BASELINE-CONTROL  | no   | yes        | [RFC3253], Section 12.6   |
| BIND              | no   | yes        | [RFC5842], Section 4      |
| CHECKIN           | no   | yes        | [RFC3253], Section 4.4    |
|                   |      |            | and [RFC3253], Section    |
|                   |      |            | 9.4                       |
| CHECKOUT          | no   | yes        | [RFC3253], Section 4.3    |
|                   |      |            | and [RFC3253], Section    |
|                   |      |            | 8.8                       |
| COPY              | no   | yes        | [RFC4918], Section 9.8    |
| LABEL             | no   | yes        | [RFC3253], Section 8.2    |
| LINK              | no   |            | [RFC2068], Section        |
|                   |      |            | 19.6.1.2                  |

I honestly can't tell from the prose in RFC 2068, which isn't sufficient 
as definition. The same applies to UNLINK.

| LOCK              | no   | no         | [RFC4918], Section 9.10   |
| MERGE             | no   | yes        | [RFC3253], Section 11.2   |
| MKACTIVITY        | no   | yes        | [RFC3253], Section 13.5   |
| MKCALENDAR        | no   | yes        | [RFC4791], Section 5.3.1  |
| MKCOL             | no   | yes        | [RFC4918], Section 9.3    |
| MKREDIRECTREF     | no   | yes        | [RFC4437], Section 6      |

RFC 4437 claims that it's not idempotent, but I think the author was 
confused. Will complain to him.

| MKWORKSPACE       | no   | yes        | [RFC3253], Section 6.3    |
| MOVE              | no   | yes        | [RFC4918], Section 9.9    |
| ORDERPATCH        | no   | yes        | [RFC3648], Section 7      |
| PATCH             | no   | no         | [RFC5789], Section 2      |
| PROPFIND          | yes  | yes        | [RFC4918], Section 9.1    |
| PROPPATCH         | no   | yes        | [RFC4918], Section 9.2    |
| REBIND            | no   | yes        | [RFC5842], Section 6      |
| REPORT            | yes  | yes        | [RFC3253], Section 3.6    |
| SEARCH            | yes  | yes        | [RFC5323], Section 2      |
| UNBIND            | no   | yes        | [RFC5842], Section 5      |
| UNCHECKOUT        | no   | yes        | [RFC3253], Section 4.5    |
| UNLINK            | no   |            | [RFC2068], Section        |
|                   |      |            | 19.6.1.3                  |

(see above)

| UNLOCK            | no   | yes        | [RFC4918], Section 9.11   |
| UPDATE            | no   | yes        | [RFC3253], Section 7.1    |
| UPDATEREDIRECTREF | no   | yes        | [RFC4437], Section 7      |
| VERSION-CONTROL   | no   | yes        | [RFC3253], Section 3.5    |
+-------------------+------+------------+---------------------------+

I'll also ask Mr. DeltaV for advice on whether I got these right.

Best regards, Julian

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 06 Jul 2012 14:35:06 +1200

> ...and here are the values for the other methods, with some inline 

Your interpretation of RFC 4918 methods matches my list. Still going 
through the others.

AYJ

---

From: Julian Reschke <[email-masked]>
Date: Fri, 06 Jul 2012 05:24:45 +0200

> Your interpretation of RFC 4918 methods matches my list. Still going

RFC 4918 actually states safeness/idempotency.

The harder ones are earlier specs :-)

---

From: Julian Reschke <[email-masked]>
Date: Thu, 12 Jul 2012 09:13:11 +0200

>> -> <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1728>

I have marked the issue as "incorporated"; if we find out later on that 
one of the classifications was wrong then we can deal with that separately.

And again, please review the classifications in 
draft-ietf-httpbis-method-registrations!

Best regards, Julian