W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: #364 Capturing more information in the method registry

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 05 Jul 2012 20:02:14 +0200
Message-ID: <4FF5D6A6.8080606@gmx.de>
To: Mark Nottingham <mnot@mnot.net>
CC: mike amundsen <mamund@yahoo.com>, Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
On 2012-07-05 19:22, Julian Reschke wrote:
> On 2012-07-05 04:36, Mark Nottingham wrote:
>> 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

...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
Received on Thursday, 5 July 2012 18:02:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 5 July 2012 18:02:54 GMT