Re: [core] ETag vs. Block Identifier

[Jon Shallow <[e-mail]>]

Hi Christian,

This approach (Etag: replacing BID) makes good sense to me and cannot think
of any corner case issues where it would fail. For Block4 Etag: is mandatory
(RFC7959 is a SHOULD) in the response.

I think that we need to suggest how the Etag: is generated - while a
checksum or hash should not be the same for two different versions of the
data for a resource it is possible that there may be a clash.  My
recommendation would be that for Block4, it has an initial random value and
then is incremented for each new body.  In order to prevent Etag: wraparound
happening too quickly on busy servers sending back many bodies for many
resources, the Etag: updating should be on a per resource change basis.

We will update the draft appropriately.

Regards

Jon

> -----Original Message-----
> From: Christian Amsüss [mailto: [e-mail]]
> Sent: 11 June 2020 08:35
> To: [e-mail]
> Cc: Carsten Bormann ([e-mail]); [e-mail]; draft-bosh-core-new-
> [e-mail]
> Subject: Re: ETag vs. Block Identifier
> 
> Hello Med,
> 
> On Thu, Jun 11, 2020 at 06:53:40AM +0000,
> [e-mail] wrote:
> > It was suggested during yesterday's meeting that ETag can be used to
> > achieve what BID is intended for in draft-bosh-core-new-block (block4
> > case). We still don't see how that would work given that only a 2.03
> > will be sent as per Section 5.10.6.2 of RFC7252.
> >
> > Can you please clarify how a missing block can be sent back as a
> > response to a GET+ETag?
> 
> By simply not including the ETag in the request (as that would, as you
point
> out, indicate to the server that the client just needs confirmation that
this
> block is still (2.03) Valid).
> 
> I think this is best illustrated by reusing the new-block-02 example
figure 5
> and 6 (where the B4 option is written without an MID, and the values are
> used in the ETag instead):
> 
>            CoAP        CoAP
>           Client      Server
>             |          |
>             +--------->| NON GET /path M:0x01 T:0xf0 O:0 B4:0/0/1024
>             |<---------+ NON 2.05 M:0xf1 T:0xf0 O:1234 ETag:21 B4:0/1/1024
>             |<---------+ NON 2.05 M:0xf2 T:0xf0 O:1234 ETag:21 B4:1/1/1024
>             |<---------+ NON 2.05 M:0xf3 T:0xf0 O:1234 ETag:21 B4:2/1/1024
>             |<---------+ NON 2.05 M:0xf4 T:0xf0 O:1234 ETag:21 B4:3/0/1024
>                  ...
>               [[Observe triggered]]
>             |<---------+ NON 2.05 M:0xf5 T:0xf0 O:1235 ETag:22 B4:0/1/1024
>             |<---------+ NON 2.05 M:0xf6 T:0xf0 O:1235 ETag:22 B4:1/1/1024
>             |<---------+ NON 2.05 M:0xf7 T:0xf0 O:1235 ETag:22 B4:2/1/1024
>             |<---------+ NON 2.05 M:0xf8 T:0xf0 O:1235 ETag:22 B4:3/0/1024
>                 ...
> 
> 
>            CoAP        CoAP
>           Client      Server
>             |          |
>                 ...
>                [[Observe triggered]]
>             |<---------+ NON 2.05 M:0xf9 T:0xf0 O:1236 ETag:23 B4:0/1/1024
>             |     X<---+ NON 2.05 M:0xfa T:0xf0 O:1236 ETag:23 B4:1/1/1024
>             |     X<---+ NON 2.05 M:0xfb T:0xf0 O:1236 ETag:23 B4:2/1/1024
>             |<---------+ NON 2.05 M:0xfc T:0xf0 O:1236 ETag:23 B4:3/0/1024
>             |          |
>          [[Client realises blocks are missing and asks for the missing
>               ones in one go. The client does not give any indication of
>               which "version" it is missing a block -- it will always be
>               assumed it's the latest one.]]
>             +--------->| NON GET /path M:0x02 T:0xf1 B4:1/0/1024\
>             |          |                             B4:2/0/1024
>             |     X<---+ NON 2.05 M:0xfd T:0xf1 ETag:23 B4:1/1/1024
>             |<---------+ NON 2.05 M:0xfe T:0xf1 ETag:23 B4:2/1/1024
>             |          |
>          [[Get final missing block]]
>             +--------->| NON GET /path M:0x03 T:0xf2 B4:1/0/1024
>             |<---------+ NON 2.05 M:0xff T:0xf2 ETag:23 B4:1/1/1024
>                 ...
> 
> When, during the transfer of missing blocks, the server does change the
> representation and mints a new ETag, then the blocks of the older
> representation are not accessible any more. This is consistent with the
rest
> of Observe behavior (once a new state is there, clients can only get the
new
> state and the old is lost to everyone who didn't fully get it), and allows
> constrained server implementations (as the server is under no obligation
to
> keep old representations around).
> 
> Kind regards
> Christian
> 
> --
> The detailed semantics of CoAP methods are "almost, but not entirely
> unlike" [HHGTTG] those of HTTP methods.
> [HHGTTG]: Adams, D., "The Hitchhiker's Guide to the Galaxy", October 1979.
>   -- Shelby, et al., Internet-Draft Constrained Application Protocol
(CoAP)