Subject: [core] Observe and Block1

From: Christian Amsüss <[email-masked]>
Date: Thu, 13 Jul 2017 17:00:47 +0200

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

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 13 Jul 2017 19:14:52 +0200

On Jul 13, 2017, at 17:00, Christian Amsüss <[email-masked]> wrote:
> 
>  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

---

From: Christian Amsüss <[email-masked]>
Date: Thu, 13 Jul 2017 20:04:34 +0200

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

The former, ie. yours :-)

> 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

-- 
This may seem a bit weird, but that's okay, because it is weird.
  -- perldata(1) about perl variables