[core] Observe and Block1

[Christian Amsüss]

Hello working group,

with FETCH, it is now more realistic to get into a situation where an
observation is established from a request whose body spans multiple
Block1 exchanges.

RFC7959 Section 2.6 explains how observe and blockwise interact, but
only considers interaction between Block2 and observation.

I'd implement it in a way that the Observe option is set on the initial
Block1 (and thus the observation results ride on that request's token),
but found no text on that, and someone else might send the Observe
option on (and request the token of) the last Block1. My earlier
implementation would even have sent the Observe option with every
block.

What do other implementers do there, what are the authors' opinions on
this, and where can we write down how to do that?

(This came up when refactoring the blockwise implementation of the
aiocoap library).

Best regards
Christian

[Carsten Bormann]

Post by Christian Amsüss
what are the authors' opinions on
this,

The authors of RFC 7959, or those of RFC 8132? :-)

I think you have shown that RFC 8132 exposes a weakness in RFC 7959 (namely that it didn’t define the interaction of Block1 and Observe, note the curious absence of a section 3.5 “Combining Observe and Block1").

Generally, the assumption with Block1 is that all options are sent with each copy of the request, so I would start out by expecting the Observe request option to be present on all Block1 requests. Now which token should be used for the notifications? This question may not really occur in practice with Block1 as each response is likely to retire the token, so the next response can use the same token. It is a bit weird to send an Observe response option on a response that retires the token, so that would argue for the Observe response option to be present only on the last exchange in the Block1 sequence. This would fit with the way Block1 and Block2 are used: The Block2 sequence starts with the last exchange of the Block1 sequence.

Where do we publish the result of the deliberations we need to answer this question? This is likely to be a bit long for an errata report, so we could write a short document that updates RFC 7959, or respin RFC 7959 (which would be most useful if there are also other changes we want to make).

Grüße, Carsten

[Christian Amsüss]

Post by Carsten Bormann
The authors of RFC 7959, or those of RFC 8132? :-)

The former, ie. yours :-)

Post by Carsten Bormann
Generally, the assumption with Block1 is that all options are sent
with each copy of the request, so I would start out by expecting the
Observe request option to be present on all Block1 requests. Now
which token should be used for the notifications? This question may
not really occur in practice with Block1 as each response is likely to
retire the token, so the next response can use the same token. It is
a bit weird to send an Observe response option on a response that
retires the token, so that would argue for the Observe response option
to be present only on the last exchange in the Block1 sequence. This
would fit with the way Block1 and Block2 are used: The Block2 sequence
starts with the last exchange of the Block1 sequence.

Sounds good to me. The lack of an Observe option in each 2.31 response
(what of non-2.31 responses? are they mutually exclusive with observe?)
would conveniently inform the client that no notifications will ever
arrive on that token, so it is free for reuse before the next block is
sent.


Thanks for your quick response
Christian