Subject: [core] block transfer option interpretation and consistency

From: "Peter A. Bigot" <[email-masked]>
Date: Sat, 19 Oct 2013 22:13:38 -0500

When a request or response is fragmented using the block options, how
are other options to be interpreted?

The only discussion I find is with respect to ETag.  The client MUST
detect that the ETag for one block is different from another, and work
to get a complete body constructed from fragments with the same Etag.

What requirements are placed on the presence and value-consistency of
other options?  Does the complete set of options need to be repeated for
each fragment?  2.4 implies this is the case for client-initiated
response collection, but client-initiated requests are not addressed.

What if the value of an option changes over different blocks, as would
happen if a representation with strict tolerances for Max-Age is
transferred in blocks?  From which fragment is the value used to
determine the freshness of the representation taken?

Related to this: block-12 section 2.4 has:

    ...  To minimize the resulting
    inefficiency, the server MAY cache the current value of a
    representation for an ongoing sequence of requests.  (The server may
    identify the sequence by the combination of the requesting end-point
    and the URI being the same in each block-wise request.)

This is the only text that describes how individual fragments are to be
recognized and associated with a specific request or response.  Should
it not also require that the token be the same?

Peter