Re: [core] Incoming AD review of draft-ietf-core-block-19

[Carsten Bormann <[e-mail]>]

Alexey Melnikov wrote:
> Hi,
> I am mostly happy with this document, but I have a few comments/questions:
> 
> On page 11:
> 
>    Clients that want to retrieve
>    all blocks of a resource SHOULD strive to do so without undue delay.
> 
> This is not an interoperability issue and it would be impossible to
> verify compliance with it, unless you have a number that specifies what
> is "undue delay". So I think you shouldn't use RFC 2119 SHOULD here.
> Just use lowercased "should" instead.

Indeed, you cannot measure compliance with this SHOULD.  I still think
that it is important for interoperability to point out that clients will
have more successful exchanges if they heed this.  (From an
interoperability point of view, this is a statement that relieves
servers of a potential onus to somehow cater for clients that don't.)

> Similarly, in 2.5:
> 
>    Clients SHOULD strive to send all blocks of a
>    request without undue delay.
> 
> (Similar text in 2.6)

(Ditto.)

> In 2.9.2:
> 
> Should probably also mention that this response code is also used for
>  mismatching content-format options

That is one way to see this; section 2.3 takes the view that mismatching
content-formats aren't reassembled into one body in the first place so
an incomplete body is the result of not having all parts.
(I added back reference in the editor's draft.)

> In 2.10:
> 
>    A response with a Block1 Option in control usage
>    with the M bit set invalidates cached responses for the target URI.
> 
> Can you explain the reason for this?


If the M bit had not been set the response would have been a final
response and would be used to update the cache entries for this URI.
Now, with the M bit set, we know that there will be a final response
later, but we don't know what that will be.  Continuing to serve a
previous response from the cache doesn't sound right.  But then, it
could be argued that the server just promised to perform the request
atomically later, so nothing has happened yet.  Good question.

> 
> In 3.2:
> 
>    A stateless server that simply builds/updates the resource in place
>    (statelessly) may indicate this by not setting the more bit in the
>    response (Figure 8); in this case, the response codes are valid
>    separately for each block being updated.
> 
> What is the behaviour of both the client and the server if PUT on a
> particular block fails? Is this clear enough in the document?

In the stateless case, the resource is now probably broken (unless the
resource is somehow intrinsically robust to this case).  The client
should not be using the resource (e.g., try to initiate a firmware
update from an image it just has been building).  The server is
stateless with respect to individual requests, so it is patiently
sitting there for the broken resource to be mended.

> Other questions I have after reviewing the document. If I missed where
> they are answered, please point me out to existing text in the document
> or another RFC:
> 
> Is there a special error for block size mismatch between multiple requests?

A block size mismatch is not an error (maybe I don't understand the
question).

> As block2 is a critical option, how can a server know if a particular
> client supports this option?

The assumption here is that CoAP clients generally do, unless they are
very specialized and never have to deal with non-trivial amounts of
information (such as a /.well-known/core).

Grüße, Carsten