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

[Christian Amsüss <[e-mail]>]

Hello Carsten and various original authors,

On Mon, Nov 13, 2017 at 11:33:11AM +0800, Carsten Bormann wrote:
> 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.

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