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

From: The IESG <[email-masked]>
Date: Wed, 24 Aug 2016 06:13:26 -0700

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
[email-masked] mailing lists by 2016-09-07. Exceptionally, comments may be
sent to [email-masked] 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.

---

From: "Marc Blanchet" <[email-masked]>
Date: Wed, 24 Aug 2016 09:20:20 -0400

Hello,
  found strange the abstract below.

>    detailing the request.  This leads to some applications to using POST

s/POST/GET/  or do I need more coffee?

Marc.

---

From: peter van der Stok <[email-masked]>
Date: Wed, 24 Aug 2016 17:44:55 +0200

> s/POST/GET/  or do I need more coffee?

May be something stronger?

My apologies, I hope this is a copy/paste confusion coming from a lack 
of coffee.

Peter

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 24 Aug 2016 09:32:17 -0700

> On Aug 24, 2016, at 6:13 AM, The IESG <[email-masked]> wrote:
> 
> 

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 25 Aug 2016 07:37:14 +0200

>> s/POST/GET/  or do I need more coffee?

Applications are actually using POST for these operations because they
can use a request body with POST (allowing to transcend any limitations
on the request URI size) and POST is the catch-all operation of
HTTP.

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 25 Aug 2016 07:54:46 +0200

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

RFC 7252 is referencing RFC 2616 for its security considerations,
because the RFC 723x series wasn't out yet at the time CoAP was
completed.  draft-ietf-core-etch references RFC 7252 for its security
considerations.  This implies a reference to RFC 2616 as well, which we
decided to make explicit (it's hard to be explicit enough about security
considerations).  We could change that to leave it implicit, rendering
the downref less visible.

> not section 15 of RFC2616.  Just fix the reference or remove it entirely

While we could add RFC 7231 to the above reference (which, as I said is
already implicitly there), a single security considerations section out
of one of the RFC 723x documents does not cover the entire security
considerations of RFC 2616 (e.g., section 15.7 does very much apply,
some of which seems to have been moved to RFC 7234).  Do you see
anything specific in RFC 7231 that we should cover that isn't mentioned
in RFC 2616?

We could use draft-ietf-core-etch more or less randomly as the point
where we finally clean up the editorial issues caused by the sharding of
RFC 2616.  The authors so far did not see a reason to do that exactly in
this document, which describes functionality not really touched by that
sharding.  Should we, anyway?

Gruesse, Carsten

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 26 Aug 2016 13:40:03 -0700

> On Aug 24, 2016, at 10:54 PM, Carsten Bormann <[email-masked]> wrote:
> 

If you think security considerations are important, they should be included
in the draft and specific to the additions made by that draft.  Specifying
them by reference to HTTP would have made sense if you had specified CORE
semantics by reference to HTTP (instead, the method definitions were copied,
which creates a fork of the protocol).

Regardless, this draft does not change the security considerations of RFC7252
(nor 2616, nor 7230).  There is no reason to reference considerations that
are not applicable to the *changes* introduced by this draft. 7252 is already
a normative requirement and its normative dependency on 2616 is not changed
by 2616 becoming obsolete -- the text is effectively imported by reference.

If there are NEW security considerations introduced by ONLY the addition
of these two methods to the semantics of CORE, then that is what should
be in the security considerations of this draft.  Just that and a generic
link to RFC7252's security section.  Nothing else.

> anything specific in RFC 7231 that we should cover that isn't mentioned

It doesn't matter -- they are not relevant to these two methods.
If there is something relevant from HTTP caching, then just copy
the text and make it specific to these two methods.

HTTP semantics could have been used verbatim by CORE, without any
changes, so a normative reference to RFC 7231 (HTTP Semantics) would
have been appropriate IF the CORE methods and status codes were specified
by reference and not forked into your spec.

My long-term advice would be to delete 50% of CORE spec and replace
that with normative references to HTTP, but I wouldn't bother until after
HTTP/1.1 advances to Standard status.

> sharding.  Should we, anyway?

No, we can't make updates to a proposed standard more or less randomly.
They have to be within scope and reviewed by the right folks.
Method specs (which define optional features to be deployed at leisure)
are not the place to make updates to the underlying protocol.
People who are not implementing a given method should feel free to
ignore its specification.

I would actually go further and say that these two methods should have
been specified in two separate documents, but it's far too late for that
comment.

Cheers,

Roy T. Fielding                     <http://roy.gbiv.com/>
Senior Principal Scientist, Adobe   <https://www.adobe.com/>