[core] draft-ietf-core-echo-request-tag -14 and Block2

[[e-mail]]

Hi there,

 

I have run into an issue where multiple CoAP requests (not needing Block1)
to the same resource trigger potentially different responses that require
the use of Block2. If the responses overlap, then there is confusion as to
how to pull back the correct response to match the request.  For example
(grossly simplifying things)

POST /api/<service>/read   payload = { 'offset': 0, 'count': 1200 }

POST /api/<service>/read   payload = { 'offset': 2000, 'count': 1300 }
Or

FETCH /api/<service>/read   payload = { 'offset': 0, 'count': 1200 }

FETCH /api/<service>/read   payload = { 'offset': 2000, 'count': 1300 }
 

RFC7959 2.4 rightly states

   The Block2 Option provides no way for a single endpoint to perform

   multiple concurrently proceeding block-wise response payload transfer

   (e.g., GET) operations to the same resource.  This is rarely a

   requirement, but as a workaround, a client may vary the cache key

   (e.g., by using one of several URIs accessing resources with the same

   semantics, or by varying a proxy-safe elective option).

 

Which then brings in the possible use of Request-Tag option in the request
as a proxy-safe elective option. However.

draft-ietf-core-echo-request-tag -14 3.2 states

   The Request-Tag option is only used in requests that

   carry the Block1 option, and in Block2 requests following these.

 

Which implies that the examples above need to contain the Block1 option in
the first instance if there is any suspicion that Block2 is needed in the
response.

 

Then draft-ietf-core-echo-request-tag -14 3.4 states

   Note that Request-Tag options can be present in request messages that

   carry no Block option (for example, because a Request-Tag unaware

   proxy reassembled them), and MUST be ignored in those.

 

Apart from being hard to parse (what does "those" refer to?), this tells me
that Servers MUST ignore requests that have no Block option - so, I cannot
just add the Request-tag option to a request on the off-chance there may be
a Block2 needed response.

 

Is there a good reason for this MUST?

 

If it is too late for the draft to be updated, the only easy way forward
that I can see is to add in an unneeded Block1 to the request, or to add in
a Block2 option to the request so the Request-Tag can be used even if the
response fits into a single payload.

 

I have raised this as Issue #77
https://github.com/core-wg/echo-request-tag/issues/77 .

 

Regards

 

Jon