
From nobody Fri Jul 22 02:37:06 2016
Return-Path: <cabo@tzi.org>
X-Original-To: core-parameters@ietfa.amsl.com
Delivered-To: core-parameters@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D539112DF39; Fri, 22 Jul 2016 02:37:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHoh1CYXRw1j; Fri, 22 Jul 2016 02:37:02 -0700 (PDT)
Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:c:538::194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFC7312DF38; Fri, 22 Jul 2016 02:36:59 -0700 (PDT)
Received: from mfilter24-d.gandi.net (mfilter24-d.gandi.net [217.70.178.152]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 35B1AC5A72; Fri, 22 Jul 2016 11:36:58 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter24-d.gandi.net
Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter24-d.gandi.net (mfilter24-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id TqOrFmbm4hqb; Fri, 22 Jul 2016 11:36:56 +0200 (CEST)
X-Originating-IP: 31.133.154.74
Received: from dhcp-9a4a.meeting.ietf.org (dhcp-9a4a.meeting.ietf.org [31.133.154.74]) (Authenticated sender: cabo@cabo.im) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 1BEE5C5A83; Fri, 22 Jul 2016 11:36:55 +0200 (CEST)
Message-ID: <5791E934.4010507@tzi.org>
Date: Fri, 22 Jul 2016 11:36:52 +0200
From: Carsten Bormann <cabo@tzi.org>
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: core-parameters@ietf.org
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/core-parameters/qq6gH6oYko3Ae-uCxQVpFMOy3OA>
Cc: draft-ietf-core-etch.all@ietf.org
Subject: [core-parameters] Content-Format value allocations for draft-ietf-core-etch
X-BeenThere: core-parameters@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Expert review of CoAP parameters." <core-parameters.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core-parameters>, <mailto:core-parameters-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core-parameters/>
List-Post: <mailto:core-parameters@ietf.org>
List-Help: <mailto:core-parameters-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core-parameters>, <mailto:core-parameters-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Jul 2016 09:37:05 -0000

draft-ietf-core-etch proposes to make the following content-format value
allocations for two existing media types:

       +------------------------------+----------+----+-----------+
       | Media Type                   | Encoding | ID | Reference |
       +------------------------------+----------+----+-----------+
       | application/json-patch+json  |          | 51 | [RFC6902] |
       | application/merge-patch+json |          | 52 | [RFC7396] |
       +------------------------------+----------+----+-----------+

The numbers proposed are adjacent to the number 50 allocated to JSON in
RFC 7252.  Since the above media types are also generic in nature (they
apply to many different kinds of JSON structures), this seems appropriate.

Grüße, Carsten


From nobody Fri Jul 22 02:44:20 2016
Return-Path: <cabo@tzi.org>
X-Original-To: core-parameters@ietfa.amsl.com
Delivered-To: core-parameters@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA71012DF36; Fri, 22 Jul 2016 02:44:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OlJUw_Ftbe5P; Fri, 22 Jul 2016 02:44:17 -0700 (PDT)
Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:c:538::194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4635712DC51; Fri, 22 Jul 2016 02:44:17 -0700 (PDT)
Received: from mfilter31-d.gandi.net (mfilter31-d.gandi.net [217.70.178.162]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 133ECC5A4E; Fri, 22 Jul 2016 11:44:16 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter31-d.gandi.net
Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter31-d.gandi.net (mfilter31-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id XKOM9gBxxJ28; Fri, 22 Jul 2016 11:44:14 +0200 (CEST)
X-Originating-IP: 31.133.154.74
Received: from dhcp-9a4a.meeting.ietf.org (dhcp-9a4a.meeting.ietf.org [31.133.154.74]) (Authenticated sender: cabo@cabo.im) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id D4A45C5A6D; Fri, 22 Jul 2016 11:44:13 +0200 (CEST)
Message-ID: <5791EAEC.5020206@tzi.org>
Date: Fri, 22 Jul 2016 11:44:12 +0200
From: Carsten Bormann <cabo@tzi.org>
User-Agent: Postbox 4.0.8 (Macintosh/20151105)
MIME-Version: 1.0
To: core-parameters@ietf.org
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/core-parameters/xoE4Tnkpb8q7bF_M1V0L-bidgmY>
Cc: draft-ietf-core-etch.all@ietf.org
Subject: [core-parameters] Method and response code allocations for draft-ietf-core-etch
X-BeenThere: core-parameters@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Expert review of CoAP parameters." <core-parameters.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core-parameters>, <mailto:core-parameters-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core-parameters/>
List-Post: <mailto:core-parameters@ietf.org>
List-Help: <mailto:core-parameters-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core-parameters>, <mailto:core-parameters-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Jul 2016 09:44:19 -0000

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

