[core] Message correlation with observe

[Jim Schaad <[e-mail]>]

Klaus, Carsten,

I am trying to figure out if there is a problem in my head, and thus in my
code, or if it is in the design of the specs.

Start by setting up an observe operation:

C1:  GET /temperature  MID:10  Token: 0x4a Observe: 0
S1:  ACK 2.05 Content  MID:10 Token:0x4a Observe:12 Payload:22.9
S2: NON 2.05 Content MID:11 Token:0x4a Observe:44  Payload: 22.8

I now do a proactive cancel

C2: GET /temperature MID:15 Token:0x4a Observe:1

I now get two responses back

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

As a human being, I automatically associate response S3 with request C1 and
response S4 with request C2.  However, my code base is associating response
S3 with request C2 and then drops response S4 on the floor because it is an
ACK to a message that has already received a response.  My code however is
doing something strange with the response S3 internally to deal with the
possibility of needing to refresh the observe relationship automatically
under the covers.

Other than playing with the use of the observe option in the response to
change the correlation algorithm, I believe that my code is correctly
following the spec and I just need to fix things about the refreshing in my
code.  The one odd side effect is that the client is not going to get a
response from the server that does not have an observe option in it, even if
the proactive cancel operation is a CON.  This seems to have cognitive
dissidence.   The observe relation is canceled, but there is no positive
notification of the fact.

I don't' believe that the use of OSCORE changes any thing in the above.  The
same thing is true for using a reliable transport since the MID is not
really used for correlation here, the token value is used here.

Is what my code does what the authors expected to occur?

Jim