Re: Last Call: <draft-ietf-core-etch-02.txt> (Patch and Fetch Methods for Constrained Application Protocol (CoAP)) to Proposed Standard

"Roy T. Fielding" <> Wed, 24 August 2016 16:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 71F3A12D104; Wed, 24 Aug 2016 09:32:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mAgu4LuGxBPE; Wed, 24 Aug 2016 09:32:19 -0700 (PDT)
Received: from ( []) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EF2E0127735; Wed, 24 Aug 2016 09:32:18 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 813426002610; Wed, 24 Aug 2016 09:32:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to;; bh=EXIav+E/fGtWIHB+1yNL6HSybCQ=; b=Ga4HEu0NJrqblqrwbDI9H9r8nQyj Ms47g91FuqQfBjrq96P1s5hIcmFCMGoDkd3gp3/6CZ/1lt+RZWHr2mstWJPCEcH6 KX9IsHV5xRfPUEE6JBUuuDrwGZinQ6p4ZXlxjNyNng3Mm24zHVmCDnFO9lJF8aey nkz/6CqLbMKqTFY=
Received: from [] ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id EE99E600260F; Wed, 24 Aug 2016 09:32:17 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
Subject: Re: Last Call: <draft-ietf-core-etch-02.txt> (Patch and Fetch Methods for Constrained Application Protocol (CoAP)) to Proposed Standard
From: "Roy T. Fielding" <>
In-Reply-To: <>
Date: Wed, 24 Aug 2016 09:32:17 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <>
References: <>
X-Mailer: Apple Mail (2.2104)
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Aug 2016 16:32:20 -0000

> On Aug 24, 2016, at 6:13 AM, The IESG <> wrote:
> The IESG has received a request from the Constrained RESTful Environments
> WG (core) to consider the following document:
> - 'Patch and Fetch Methods for Constrained Application Protocol (CoAP)'
>  <draft-ietf-core-etch-02.txt> as Proposed Standard
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> mailing lists by 2016-09-07. Exceptionally, comments may be
> sent to instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> Abstract
>   The existing Constrained Application Protocol (CoAP) methods only
>   allow access to a complete resource, not to parts of a resource.  In
>   case of resources with larger or complex data, or in situations where
>   a resource continuity is required, replacing or requesting the whole
>   resource is undesirable.  Several applications using CoAP will need
>   to perform partial resource accesses.
>   Similar to HTTP, the existing Constrained Application Protocol (CoAP)
>   GET method only allows the specification of a URI and request
>   parameters in CoAP options, not the transfer of a request payload
>   detailing the request.  This leads to some applications to using POST
>   where actually a cacheable, idempotent, safe request is desired.
>   Again similar to HTTP, the existing Constrained Application Protocol
>   (CoAP) PUT method only allows to replace a complete resource.  This
>   also leads applications to use POST where actually a cacheable,
>   possibly idempotent request is desired.
>   This specification adds new CoAP methods, FETCH, to perform the
>   equivalent of a GET with a request body; and the twin methods PATCH
>   and iPATCH, to modify parts of a CoAP resource.
> The file can be obtained via
> IESG discussion can be tracked via
> No IPR declarations have been submitted directly on this I-D.
> The document has a reference to obsolete RFC 2616, this is intentional.

What is that supposed to mean?  The reference is intentionally wrong?

I looked at the text and it should be referencing section 9 of RFC7231,
not section 15 of RFC2616.  Just fix the reference or remove it entirely
(since RFC7252 already forked HTTP semantics for no reason whatsoever).