Re: [core] ETag vs. Block Identifier

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

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)