[core-parameters] Method and response code allocations for draft-ietf-core-etch

[Carsten Bormann <[e-mail]>]

draft-ietf-core-etch proposes to allocate the following method codes:

                       +------+--------+-----------+
                       | Code | Name   | Reference |
                       +------+--------+-----------+
                       | 0.05 | FETCH  | [RFCthis] |
                       | 0.06 | PATCH  | [RFCthis] |
                       | 0.07 | iPATCH | [RFCthis] |
                       +------+--------+-----------+

The specific codes proposed lead to the following nice symmetry:

           +------+--------+------+--------+------+------------+
           | Code | Name   | Code | Name   | safe | idempotent |
           +------+--------+------+--------+------+------------+
           | 0.01 | GET    | 0.05 | FETCH  | yes  | yes        |
           | 0.02 | POST   | 0.06 | PATCH  | no   | no         |
           | 0.03 | PUT    | 0.07 | iPATCH | no   | yes        |
           | 0.04 | DELETE |      |        | no   | yes        |
           +------+--------+------+--------+------+------------+

draft-ietf-core-etch also allocates the following response code:

                      +------+----------+-----------+
                      | Code | Name     | Reference |
                      +------+----------+-----------+
                      | 4.09 | Conflict | [RFCthis] |
                      +------+----------+-----------+

This is analogous to HTTP 409 Conflict.

There is an ongoing discussion whether the response code for an iPATCH
payload that happens to cause a non-idempotent change should be 4.12 (as
shown in an example in section 3.1) or maybe a different one.
(Note that the server is in no way required to check that the payload
for an iPATCH is indeed idempotent.)
This author believes that 4.09 Conflict would be appropriate, as there
is no precondition on the resource state that is not being met (as would
be the normal situation for a 4.12), instead there is something in the
patch payload that cannot be done.  4.00 of course would also be
appropriate.  It is not envisioned that a new response code is needed
for this kind of error response.

Grüße, Carsten