> On Aug 24, 2016, at 6:13 AM, The IESG <iesg-secretary@xxxxxxxx> 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 > ietf@xxxxxxxx mailing lists by 2016-09-07. Exceptionally, comments may be > sent to iesg@xxxxxxxx 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 > https://datatracker.ietf.org/doc/draft-ietf-core-etch/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-core-etch/ballot/ > > > 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). ....Roy