Subject: [core] CoAP: non-traditional response forms

From: Carsten Bormann <[email-masked]>
Date: Mon, 13 Nov 2017 11:33:11 +0800

I have submitted a new draft, draft-bormann-core-responses-00.txt.

This is trying to outline additional ways CoAP responses may be formed, beyond those defined in RFC 7252.

This draft is a reaction to developments within LWM2M and OCF that are not yet all public.

I expect these ideas to be controversial.
(I myself am not convinced that any of these approaches should be pursued.) 
But they would solve real problems.

I cannot possible ask Jaime to allocate agenda tine for this this week before there was a mailing list discussion.  So please fire away…

Grüße, Carsten

Name:		draft-bormann-core-responses
Title:		CoAP: Non-traditional response forms
Htmlized:       https://tools.ietf.org/html/draft-bormann-core-responses-00
Abstract:
  In CoAP as defined by RFC 7252, responses are always unicast back to
  a client that posed a request.  The present memo describes two forms
  of responses that go beyond that model.  These descriptions are not
  intended as advocacy for adopting these approaches immediately, they
  are provided to point out potential avenues for development that
  would have to be carefully evaluated.

---

From: Christian Amsüss <[email-masked]>
Date: Mon, 13 Nov 2017 11:17:52 +0100

Hello Carsten and various original authors,

> But they would solve real problems.

as Response-For and Response-To are phrased, I'd first ask how this is
supposed to work over forward and reverse proxies and hops through
different protocols, and I frankly don't expect very concrete answers.

It occurrs to me that "draft-cao-core-delegated-observe" should probably
be reflected in this draft as well. (Not only because I'm feeling guilty
of not being constructive enough in my reviews of that document).

Kneejerk reaction: My approach to this would be something maybe best
described as CoAP over CoAP:

Define another transport for CoAP that does not use tokens and addresses
but one URI per exchange. (It is similar in that respect to OSCORE that
already provides such a layer, even with a similar backend but not the
options to mix and merge parties).

When a node (or multicast address) is configured to receive a response,
it grows a resource that can even be discoverable as

| </conf-resp/42>;rt="core.coap",
| <coap://config-server/configured-request>;rel="coap-request";anchor="/conf-res/42"

Anyone can then send a response to that as

| POST </conf-resp/42>
| Content-Format: application/coap-response
| Payload:
| +--------+-------------+------+-------------------------+
| |  Code  | Options ... | 0xff | Payload                 |
| +--------+-------------+------+-------------------------+

This has minimally more overhead than Response-To (1 Byte the outer POST
code, plus nibble shards for not having the identifier not in 8-bit-safe
opaque options but in UTF-8 path parts, and you don't really need to
send the Content-Format on rt="core.coap") and should cover all the
Section 3 cases without hacking up the mid/token/REST sublayers. (I'm
aware that CoAP was specified with the sublayers in one specification to
allow interlinking them more deeply and playing with them, but changes
at the level of core-response-00 options have too strict requirements of
using up to date infrastructure).

I wouldn't treat the responses as that get POSTed thusly as responses to
separate requests, but as multiple responses arriving for the same
request. This is a pattern that is already well established in multicast
and observation (which are very much alike on the Request-Response
sublayer).

I surmise one could do something similar for Response-For, but I think
that this option needs to be considered for two distinct applications:

* Used like Response-To, but just with ephemeral requests. Those can be
  sent to anything that can be addressed, and IMO should go to a
  discoverable resource there.

* Used to tack additional cache content onto a request a la HTTP/2. I
  wouldn't expect anything not actively fetched by the requester to go
  through here without all proxies and protocols collaborating.

  What I can well imagine for such a use case is something like
  "Constrained MIME" that doesn't returns the response together with an
  attached request/response pair in the body.

Best regards
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom