Should we disallow Request-Tag without value?

[gselander]

Reading "Every message in which the Block1 option is set is considered to carry a Request-Tag . . . " I wonder about the potential confusion between a message with the Block1 option without Request-Tag and a message with the Block1 option with empty Request-Tag option, i.e. no value. As I read it we allow Request-Tag without value (length 0). Then we have two "special classes" of Block1 options, for which equality needs to be tested. Or should we require at least 1 byte of value?

[chrysn]

That would add 1-2 bytes to each blockwise request operation, where a more comprehensible wording would allow zero overhead most of the time. I'll put in much more time expressing the idea in an easy to understand way before taking that length penalty.

[gselander]

I'm fine with this. Here is a proposal for new overall text:

"In order to reliably attribute any CoAP request with the Block1 option set to a specific request message body, the following notion of Request-Tag equality is applied:

• CoAP requests with the Request-Tag option set have equal Request-Tag values if and only if their option lengths and option values are equal.

  • In particular, CoAP requests with empty Request-Tag have equal Request-Tag values.

• Absence of the Request-Tag option implies a value that is distinct from any value of a message with the Request-Tag option set, and equal to that of any other message without the Request-Tag option.

In this way every CoAP request in which the Block1 option is set is considered to carry a Request-Tag value that can be compared for equality with the value of any other such CoAP requests. "

[chrysn]

I only really looked at this issue again after overhauling the value definition into a matchability definition (with latest clarification at 6e4017a3), do you think this is better understandable now?

[gselander]

Only looking at this now, I think this is easy to understand now.