Also includes changes to a paragraph that will be Section 3 after the pending intro-shoving.
Rationale as in the review response mail:
" (Concurrent block-wise request operations are impossible with the
options of [RFC7959] because the second operation's block overwrites
any state of the first exchange.).
"
I believe this is true, but could you point to the section that states
that? I didn't manage to find it while checking.
Reference made more precise, "from a single endpopoint" added.
" They can
still be treated as independent messages by the server (e.g. when it
sends 2.01/2.04 responses for every block), or initiate a new
operation (overwriting kept context) when the later message carries
Block1 number 0.
"
I have a hard time parsing/understanding this paragraph, particularly from "or initiate..."
Split up into separate sentences for better clarity.
Section 3.3
"
Clients MUST NOT recycle a request tag unless the first operation has
concluded.
"
in the case where a client supports but does not use Request-Tag, this implies "concurrent block operations without Request-Tag are not allowed". If that is the case, I would like that to be stated explicitely.
(also minor, I'd like to add "that support Request-Tag" after "Clients")
That requirement was already kind of conditional on the client using
Request-Tag for a particular purpose -- for otherwise the "unless
concluded" clause makes no sense, for that's defined by the purpose.
Rephrased to pull in the purpose before the MUST and make that explicit.
The "that support Request-Tag" comment should be obsolete by hat, for
only who supports it can use it for something.
(We did, in the chat earlier, consider asking the WG whether that'd all
mean that we're updating RFC7959, but as we're now back to "If you want
to achieve X, do Y" wording, I don't see necessity for such an update).
Section 3.3
The last sentence gives some requirements about where the Request-Tag option can/musty be used per message. I felt the document was missing on usage requirements (e.g. if it is set, it MUST be set for all requests for a specific operation)
Added to the initial (now split up) paragraph of that section.
Section 3.4.2
"
When initializing a new block-wise operation, a client has to look at
other active operations:
o If any of them is matchable to the new one, and the client neither
wants to cancel the old one nor postpone the new one, it can pick
a Request-Tag value that is not in use by the other matchable
operations for the new operation.
o Otherwise, it can start the new operation without setting the
Request-Tag option on it.
"
Does not cover the fact that Request-Tag can be omitted if that is a
different from the other matchable operations. ("pick a new value"
excludes it)
Explicitly included as an option now.
(Would have been even easier if there were a once-and-for-all definition
of a "request-tag value" that can be absent or have the option's data,
but that had long-winded wording in the last version that was in, and
still might be mistaken by readers that don't have the precise
definition at hand).
Also includes changes to a paragraph that will be Section 3 after the pending intro-shoving.
Rationale as in the review response mail:
Reference made more precise, "from a single endpopoint" added.
Split up into separate sentences for better clarity.
That requirement was already kind of conditional on the client using Request-Tag for a particular purpose -- for otherwise the "unless concluded" clause makes no sense, for that's defined by the purpose.
Rephrased to pull in the purpose before the MUST and make that explicit.
The "that support Request-Tag" comment should be obsolete by hat, for only who supports it can use it for something.
(We did, in the chat earlier, consider asking the WG whether that'd all mean that we're updating RFC7959, but as we're now back to "If you want to achieve X, do Y" wording, I don't see necessity for such an update).
Added to the initial (now split up) paragraph of that section.
Explicitly included as an option now.
(Would have been even easier if there were a once-and-for-all definition of a "request-tag value" that can be absent or have the option's data, but that had long-winded wording in the last version that was in, and still might be mistaken by readers that don't have the precise definition at hand).