Subject: CoAP and new methods?

From: Martin Thomson <[email-masked]>
Date: Mon, 9 May 2016 17:00:02 +1000

I see that the core working group has adopted this work:

https://tools.ietf.org/html/draft-ietf-core-etch-00

This defines new methods for CoAP, which is (was?) very much *like* HTTP.

The new methods are:

FETCH, which looks like the proposed SEARCH in that it acts as a safe,
idempotent retrieval.  It is different in that responses that are
cacheable by default AND the request body forms part of the cache key.
(I think that I got that right.)

iPATCH, which is like PATCH, but idempotent.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 9 May 2016 17:08:07 +1000

Well, they've got a separate registry for methods, so I'm not too concerned.

I'd be a little happier if they didn't seem to justify everything they did in terms of HTTP.

Cheers,

> On 9 May 2016, at 5:00 PM, Martin Thomson <[email-masked]> wrote:
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 09 May 2016 15:53:48 +0200

> Well, they've got a separate registry for methods, so I'm not too concerned.

Right.  In the end, of course, we would be most happy with a solution
that maps cleanly into HTTP in a cross-protocol proxy.  (Consider this a
mild expression of interest in getting SEARCH to RFC.)

> I'd be a little happier if they didn't seem to justify everything they did in terms of HTTP.

We do have the use cases (e.g., resource directory for iPATCH, COMI/COOL
YANG-based management for all three new methods).  The text that points
to HTTP is mainly there to justify what we selected among some of the
particular bike-shed details one could come up with.  Now if your
experience indicates HTTP got those details wrong, and we should do it
in a different way, we would like to know that!

(Any other tidbits about the experience with integrating PATCH into HTTP
would also be most welcome -- RFC 5789 has been out for six years now;
time to advance it to STD?)

Grüße, Carsten