On Aug 24, 2016, at 6:13 AM, The IESG <iesg-secretary(_at_)ietf(_dot_)org>
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(_at_)ietf(_dot_)org mailing lists by 2016-09-07. Exceptionally, comments
may be
sent to iesg(_at_)ietf(_dot_)org 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