Subject: [core] Block1 vs. other options

From: Mateusz Kwiatkowski <[email-masked]>
Date: Fri, 27 Nov 2015 15:49:03 +0100

Hello,

First of all, this is my first post to any of the IETF mailing lists, so 
please correct me if I'm doing anything against the common etiquette.

While studying and working on an implementation of the Block-wise 
transfer in CoAP, I came across an apparent ambiguity of the current 
draft spec.

Specifically - how should other CoAP options (not related to the BLOCK 
document) be treated when performing a block-wise request (utilizing 
Block1)? Should they be repeated on every message? Or may they be 
omitted on all requests save from some specific one - first or last 
perhaps? Should the server e.g. validate whether Uri-Path values match 
between subsequent blocks? None of these questions seems to be addressed 
by the document.

This issue is especially significant for implementations that attempt to 
abstract the block-wise nature of the message exchange away from the 
actual business logic. This is what e.g. Eclipse Californium does, and 
it actually seems to ignore any non-BLOCK-related options from all but 
the last message in block sequence. Such implementation apparently 
cannot fulfill the requirement from RFC 7252 section 5.4.1, which 
explicitly states that unrecognized options of class "critical" MUST 
cause the message to be rejected.

Of course this is not itself a defect of the protocol, but a more 
specific requirement in the BLOCK spec would help to avoid such 
arbitrary decisions. By my personal judgment, not repeating the options 
in every message would be the way to go - saving bandwidth, and making 
it much easier to fulfill the above-mentioned requirement while using 
abstractions like the one in Californium. It would then, however, remain 
an open problem, which block to use as "option source" - first or last? 
Requiring the client to repeat the options, and the server to verify 
their consistency (like with Content-Format), would offer more 
robustness, but waste bandwidth and complicate server implementations.

In any case, I believe that this is an ambiguity that should be 
addressed. Unless I'm misunderstanding something and answers to my 
questions can be inferred from some other parts of the spec.

Best regards,
Mateusz

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 27 Nov 2015 17:35:10 +0100

Hi Mateusz,

questions like yours are indeed most welcome here.

Let me try to give a quick answer now; we can maybe refine that later.

> Block1)? Should they be repeated on every message? 

Yes.

> Or may they be
> perhaps? 

No.

> Should the server e.g. validate whether Uri-Path values match
> between subsequent blocks? 

Actually, if a server receives two requests with different Uri-Path
values, they are unrelated, so there is no need (actually: it would be
wrong) to validate a match.
(What will happen if, say, the client simply leaves out the Uri-Path
options on what it things is the second request in sequence?  A 4.08,
because the server does not have the previous blocks needed to perform a
PUT or POST to / -- the URI implied by Uri-Path options absent.)

> None of these questions seems to be addressed
> by the document.

We do discuss the situation where the Content-Format options do not
match (last paragraph of section 2.3).

2.4 is quite clear in saying:

2.4.  Using the Block2 Option

   When a request is answered with a response carrying a Block2 Option
   with the M bit set, the requester may retrieve additional blocks of
   the resource representation by sending further requests with the same
   options as the initial request and a Block2 Option giving the block
   number and block size desired.

... "with the same options as the initial request".

You are right that the text is never spelling out the same as explicitly
for Block1, however, e.g. the text

   The Block1 option provides no way for a single endpoint to perform
   multiple concurrently proceeding block-wise request payload transfer
   (e.g., PUT or POST) operations to the same resource.  Starting a new
   block-wise sequence of requests to the same resource (before an old
   sequence from the same endpoint was finished) simply overwrites the
   context the server may still be keeping.  (This is probably exactly
   what one wants in this case - the client may simply have restarted
   and lost its knowledge of the previous sequence.)

does not really make any sense if Block1 were meant to have completely
different semantics.

> cause the message to be rejected.

Time to file a bug, I'd say.

> robustness, but waste bandwidth and complicate server implementations.

Well, first of all a server needs the Cache Key (Uri-Path etc.) in order
to find which of the many Block1 requests you may be getting at a
particular point in time from the same endpoint actually refers to the
same resource -- there is of course nothing wrong with concurrent Block1
sequences being performed to different resources at the same time.

In many cases, the server is free to implement Block1 atomically or in a
stateless fashion -- if the client is not supplying the options with
every request, that is not possible.  (Content-Format is somewhat
special because it is part of the resource state.)

> questions can be inferred from some other parts of the spec.

Do you have any specific places in mind where an editorial change should
be made?  Now is still a very good time to make these.

Grüße, Carsten