Re: [core] Message correlation with observe

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

Hello Jim, CoRE,

On Mon, Aug 17, 2020 at 08:39:36AM -0700, Jim Schaad wrote:
> S3: NON 2.05 Content MID:99 Token:0x4a Observe:46 Payload: 22.2
> S4: ACK 2.05 Content MID:15 Token:0x4a Payload: 22.1

In follow-up requests on the same token as Observe introduces them (and
I hope to generalize), an important theme is that responses that relate
to a particular follow-up message must be distinguishable as such where
it matters.

If just a plain refresh is sent, it doesn't matter whether a response
relates to the old or new request (especially, it's not necessarily
newer than the second request).

If the ETag set is changed (which is the only permissible alteration in
7641), it doesn't matter either (even though a new ETag clearly
indicates its generation after the second request).

If an OSCORE inner refresh happens, there is clear indication that it's
a later one because it only decrypts with the newest request's Partial
IV.

And if the observation is cancelled, a response only fits that by not
carrying the Observe option, as Jon pointed out.

Programmatically (at least in my implementation), all those responses
wind up in the same channel (which I call PlumbingRequest, but maybe
token channel or token subsocket would be more suitable), and it's up to
the requesting mechanism (observation) to sort them. If S4 happened to
overtake S3 on the wire, S4 would already be recognized as a response to
C2, "slamming the door" for everything that's not a response to C2 (just
like a higher observe value would make it disregard lower value
responses). By that time, any CON/ACK has already been handled as that's
purely on the Message-ID layer.

Kind regards
Christian

-- 
I shouldn't have written all those tank programs.
  -- Kevin Flynn