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