Generalizing and defining non-traditional responses #1
Conversation
This adds (without any editing and smoothing around the edges that'll still needed) content from [1] to define the framework for the later options (and other documents doing similar things). [1]: https://mailarchive.ietf.org/arch/msg/core/KPDCO9mQNzYjAuGwjV6FWWEkAH8
chrysn
force-pushed
the
generalization
branch
from
12e5dce to
babeff7
Compare
... now that proper commit hooks are in place
|
Ping @cabo, I'd like to make progress on this until IETF113, but there's little point in proceeding until this is merged or at least got an initial comment. |
|
Pong. Question: Is this the place where we (1) discuss the design space, or where we (2) define new protocol elements, or where we (3) do (1) in terms of (2), or (4) what else? |
|
I think this should mainly discuss the design space (without expanding what CoAP options can do, because they already did do it in Observe and Q-Block). To stay in the design "space" terminology, it'd set a convenient base in terminology that is more convenient for authors of current and future documents. The document doesn't indicate an intended status yet, but I've read it as standards-track from the Response-For option. (Options have been specified in like in RFC7967 No-Response, but turned out people are careful to use that fearing downrefs). A standards-track document would also allow later users (like groupcomm-proxy) to use the base normatively rather than reiterate. ("The Multicast-Signaling option indicates that non-traditional responses as described in ... are expected for the request; responses are expected for the number of seconds indicated in the option." would save them a lot of text, especially about tokens). Leisure-For-Responses is just using the base for illustrative purposes, and it may well make sense not to define this particular option here (but describing an option that does not get registered but is really just an example feels a bit weird). Maybe we'd also find a better example to illustrate. (Could be a Send-More-Blocks that does almost as Leisure-For-Responses does but makes a clear request for which additional responses should be sent). That being said, to be fair and transparent, I do plan for these things to have immediate consequences too: I've seen implementations (mainly mine) struggle to get observation and multicast integrated smoothly, and think that having a stream of responses (which may be one traditional, or any number as indicated by the application) is a suitable abstraction at some levels of CoAP. By making the abstraction available to future document authors, I hope that the next thing that sends nontraditional responses makes the implementors' lives easier as they just see a familiar (and planned-for) mechanism exercised. And of course they're free to ret-con observation, multicast and Q-Block all into the same mechanism internally. |
| can be added on top of that to give better guidance), and the server may | ||
| choose not to send any at all. | ||
|
|
||
| Intermediaries may add or remove the option, and use incoming responses to |
There was a problem hiding this comment.
Are you trying to say that this option is hbh?
There was a problem hiding this comment.
Yes, as are all options that allow non-traditional responses (Observe and Block2 explicitly, requests to multicast addresses in their original versions ~"need some extra stuff out of scope of these documents", and the upcoming Multicast-Signaling explicitly again). Any such option requires the client to use a token that outlives the original response/'s exchange lifetime, and any client end of a proxy needs to be aware of that.
That is a reason why we may prefer to have a Leisure-For and an extra option that allows sending, say, multiple blocks or follow-up data: In such a split, only Leisure-For would need to be hop-by-hop, and the other could be safe-to-forward (but a proxy that understands it may thin out responses like it may with Observe). But there are sure also good reasons against silently introducing CONNECT-lite ;-)
There was a problem hiding this comment.
For a concrete example on why it has to be, assume a client sends it to allow the server to send multiple response blocks.
The proxy would receive several blocks; in the likely case it receives the initial (the requested) block first, stores it in its cache and forwards it; later responses don't match a pending request and are discarded. But if a later block arrives first, what'll the proxy do? If it looks at the descriptive-use Block2 block number, it considers the response wrong, won't populate the cache and send the client a generic "proxy error". Worse, if it doesn't look at it (7959 says it MUST take not of the block size and MUST check ETags, but makes no requirement to verify the block number, at least on a quick check), it puts the data into the wrong cache part and forwards that.
So yeah, no improvements over the existing cases, still hop-by-hop.
Co-authored-by: cabo <cabo@tzi.org>
Co-authored-by: cabo <cabo@tzi.org>
Co-authored-by: cabo <cabo@tzi.org>
This works in my mail at 1 (after way too long time), adding definitions of non-traditional responses and setting requirements for their use.
It's not completely ship-shape yet as the text on the options introduced does not refer back to the new sections (instead, the "explaining existing stuff with the new terminology" appendix refers back to it), but IMO good enough for review. The whole PR is probably best viewed as a total delta (split into steps helping me keep track of parts), can squash if you prefer.