You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Observe has been redefined to have an implicit value twice now (TCPish, OSCORE); a clarification could generalize that notifications carry a Observe: 0 on transports that provide implicit ordering.
Signalling messages were defined for TCPish transports. OSCORE said they can be encrypted too without losing many more words on them. Defining that 7xx is signalling (sharing the number space and the per-code option space across all transports)
Even though some of those are no-ops in the protocol (there are no other ordered transports right now, and describing that some signalling messages might be usable on TCP is a different topic), stating that those fundamentally apply everywhere would help readers understand them better, and help implementers find the right abstractions. (Like, "do I need to know the transport just to be able to interpret the code?" … so far, with signaling only on TCPish, an update to CoAP-over-UDP could define different codes there).
The text was updated successfully, but these errors were encountered:
It may also make sense to generalize that "Observation has an implicit value" property into one of possibly multiple properties that transports have and that applications that set the option need to know. Other properties on that list are the implied scheme, and the way to get the default values for some options (Uri-Host/-Port).
There are a few places where I think we were too narrow in where we defined new behavior:
Even though some of those are no-ops in the protocol (there are no other ordered transports right now, and describing that some signalling messages might be usable on TCP is a different topic), stating that those fundamentally apply everywhere would help readers understand them better, and help implementers find the right abstractions. (Like, "do I need to know the transport just to be able to interpret the code?" … so far, with signaling only on TCPish, an update to CoAP-over-UDP could define different codes there).
The text was updated successfully, but these errors were encountered: