[core] Request-Token (in draft-ietf-core-new-block-06 and draft-ietf-core-echo-request-tag-11)

[Lauri Piikivi <[e-mail]>]

Hi alls,

I read the new block with interest and started wondering about the request tag. Why do we need new tag, when we have the basic COAP token. Token is used to match request and response, and in doing that it does identify the request blocks and response blocks to be part of the same request and response.

In blocwise transfer 7959 , the message IDs change but token combines them together. Same seems usable in the new-block approach. It is the same request, so they should have the same token. RFC 7959 does not say a whole lot about tokens "As a general comment on tokens, there is no other mention of tokens in this document, as block-wise transfers handle tokens like any other CoAP exchange. As usual, the client is free to choose tokens for each exchange as it likes.” This could be clarified. My understanding is that the token is the same for all blocks of a request and response.  This is shown for example in the Figure 13 of 7959.

My wondering started from reading the  draft-ietf-core-new-block-06. It states then need for request tag, and in example 9.1.1  shows the basic tokens as different for the fragmented request. Is that an error? Should the basic tokens be the same? And if the tokens are the same, the request-tag seems unnecessary.

I did read the draft-ietf-core-echo-request-tag-11 to understand the request-token better, but I found the description a bit hard to follow. It says in in chp 3.2 that  "The Request-Tag is intended for use as a short-lived identifier for keeping apart distinct block-wise request operations on one resource from one client”

But on the wire there is already the token specified in 7252 chp 5.3.1 "A token is intended for use as a client-local identifier for  differentiating between concurrent requests (see Section 5.3<https://tools.ietf.org/html/rfc7252#section-5.3>)”.


I do not understand exactly what is meant by  "The block-wise functionality does not support the detection of interchanged blocks between different message bodies to the same resource having the same block number” in  tag-11 chp 3.1. Is the message body the payload?  If the requests come from same client, they must have different tokens, per rfc 7252.


Is there some problem in token that I fail to understand now — necessitating the request-token?


In similar vein, and as a use case where request token seems good, is the understanding correct that for block1 requests all the request options are duplicated in all the blocks? I could not find a clear statement, but once again the figures in 7959 show the URI for each block. The URI path and query options can be long, and take considerable space in each block.

Could request token be the identifier for request options, so that only 1st block would have full options and later ones only the the request tag?

Sincerely,
- Lauri

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.