Re: [core] Last Call: <draft-ietf-core-block-18.txt> (Block-wise transfers in CoAP) to Proposed Standard

[Carsten Bormann <[e-mail]>]

Jim Schaad wrote:
> This is where the current BLOCK draft falls apart on its own merits.  It does not discuss what should happen if the set of options is not the same between all of the blocks. This is a problem if one is using security or not.  The correct set of headers is the set that needs to be protected, but there is no way to determine what the set of headers is supposed to be.

This is not entirely true.  For Content-Format, 2.3 has this discussion:

   The Content-Format Option sent with the requests or responses MUST
   reflect the content-format of the entire body.  If blocks of a
   response body arrive with different content-format options, it is up
   to the client how to handle this error (it will typically abort any
   ongoing block-wise transfer).  If blocks of a request arrive at a
   server with mismatching content-format options, the server MUST NOT
   assemble them into a single request; this usually leads to a 4.08
   (Request Entity Incomplete, Section 2.9.2) error response on the
   mismatching block.

For ETag, 2.4 has:

   Block-wise transfers can be used to GET resources the representations
   of which are entirely static (not changing over time at all, such as
   in a schema describing a device), or for dynamically changing
   resources.  In the latter case, the Block2 Option SHOULD be used in
   conjunction with the ETag Option, to ensure that the blocks being
   reassembled are from the same version of the representation: The
   server SHOULD include an ETag option in each response.  If an ETag
   option is available, the client's reassembler, when reassembling the
   representation from the blocks being exchanged, MUST compare ETag
   Options.  If the ETag Options do not match in a GET transfer, the
   requester has the option of attempting to retrieve fresh values for
   the blocks it retrieved first.  To minimize the resulting


It is hard to discuss all potential options because new options may have
interesting interactions with the Block options, which I hope will be
specified with those options.

More interesting is Max-Age, as this can change during the transfer, or
Size2.  Location-Path/-Query is something that is often only available
at the end of the block transfer, so I would expect that to come with
the block(s) carrying the 2.01.

Also, 2.4 specifies:

   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...

While I agree this could be spelled out in more detail, the information
basically is there.

Grüße, Carsten