Subject: [core] ETag vs. Block Identifier

From: <[email-masked]>
Date: Thu, 11 Jun 2020 06:53:40 +0000

Hi Christian/Carsten, all,

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?

Thank you.

Cheers,
Med

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Christian Amsüss <[email-masked]>
Date: Thu, 11 Jun 2020 09:34:39 +0200

Hello Med,

On Thu, Jun 11, 2020 at 06:53:40AM +0000, [email-masked] 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.
> 

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)

---

From: "Jon Shallow" <[email-masked]>
Date: Thu, 11 Jun 2020 12:02:52 +0100

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: [email-masked]]
> Sent: 11 June 2020 08:35
> To: [email-masked]
> Cc: Carsten Bormann ([email-masked]); [email-masked]; draft-bosh-core-new-
> [email-masked]
> Subject: Re: ETag vs. Block Identifier
> 
> Hello Med,
> 
point
> out, indicate to the server that the client just needs confirmation that
this
> block is still (2.03) Valid).
> 
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
>             |          |
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
> 
> --