Subject: [core] I-D Action: draft-ietf-core-etch-04.txt

From: [email-masked]
Date: Sun, 13 Nov 2016 16:56:53 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Constrained RESTful Environments of the IETF.

        Title           : Patch and Fetch Methods for Constrained Application Protocol (CoAP)
        Authors         : Peter van der Stok
                          Carsten Bormann
                          Anuj Sehgal
	Filename        : draft-ietf-core-etch-04.txt
	Pages           : 20
	Date            : 2016-11-13

Abstract:
   The methods defined in RFC 7252 for the Constrained Application
   Protocol (CoAP) 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.

   This specification defines the new CoAP methods, FETCH, PATCH and
   iPATCH, which are used to access and update parts of a resource.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-core-etch/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-core-etch-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-core-etch-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 14 Nov 2016 10:10:35 +0900

This update tries to address all remaining IESG comments.
There is no technical change intended, but I’ll ask the WG to watch out for the new sentences that contain the word “RECOMMENDED”:

   […FETCH…].  It is
   RECOMMENDED that any discovery method that allows a client to find
   out that the server supports FETCH also provides information what
   FETCH payload media types are applicable.

and

   It is RECOMMENDED that any discovery method that allows a client to
   find out that the server supports one of PATCH and iPATCH also
   provides information what patch payload media types are applicable
   and which of the two methods are implemented by the server for each
   of these media types.

   Servers that do not rely on the idempotency of iPATCH can easily
   support both PATCH and iPATCH, and it is RECOMMENDED they do so.
   This is inexpensive to do, as, for iPATCH, there is no requirement on
   the server to check that the client's intention that the request be
   idempotent is fulfilled (although there is diagnostic value in that
   check, so a less-constrained implementation may want to perform it).

Please check that you are comfortable with the direction taken there.
(And, once you have done that, please check out all other changes below.)

Grüße, Carsten