Draft: draft-ietf-core-echo-request-tag

Commentary: 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 " . 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 do n'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 do n't have the precise definition at hand ) . 
 Looks good .
Paragraph (version A):
Two matchable block-wise operations are said to be "concurrent" if a
block of the second request is exchanged even though the client still
intends to exchange further blocks in the first operation.
(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.).
Paragraph (version B):
Two matchable block-wise operations are said to be "concurrent" if a
block of the second request is exchanged even though the client still
intends to exchange further blocks in the first operation.
(Concurrent block-wise request operations from a single endpoint are
impossible with the options of RFC7959 (see the last paragraphs of
Sections 2.4 and 2.5) because the second operation's block overwrites
any state of the first exchange.).
Paragraph (version A):
Two messages carrying the same Request-Tag is a necessary but not
sufficient condition for being part of the same operation.  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.
Paragraph (version B):
Two messages carrying the same Request-Tag is a necessary but not
sufficient condition for being part of the same operation.  For one,
a server may still treat them as independent messages when it sends
interest in an old operation but wants to start over can overwrite
the server's old state with a new initial (num=0) Block1 request and
the same Request-Tag under some circumstances.  Likewise, that
results in the new message not being part of he old operation.
Paragraph (version A):
For each separate block-wise request operation, the client can choose
a Request-Tag value, or choose not to set a Request-Tag.  Starting a
request operation matchable to a previous operation and even using
the same Request-Tag value is called request tag recycling.  The
absence of a Request-Tag option is viewed as a value distinct from
all values with a single Request-Tag option set; starting a request
operation matchable to a previous operation where neither has a
Request-Tag option therefore constitutes request tag recycling just
as well (also called "recycling the absent option").
Paragraph (version A):
Clients MUST NOT recycle a request tag unless the first operation has
concluded.  What constitutes a concluded operation depends on the
application, and is outlined individually in req-tag-applications.
Paragraph (version B):
For each separate block-wise request operation, the client can choose
a Request-Tag value, or choose not to set a Request-Tag.  It needs to
be set to the same value (or unset) in all messages belonging to the
same operation, as otherwise they are treated as separate operations
by the server.
Paragraph (version B):
Starting a request operation matchable to a previous operation and
even using the same Request-Tag value is called request tag
recycling.  The absence of a Request-Tag option is viewed as a value
distinct from all values with a single Request-Tag option set;
starting a request operation matchable to a previous operation where
neither has a Request-Tag option therefore constitutes request tag
recycling just as well (also called "recycling the absent option").
Paragraph (version B):
Clients that use Request-Tag for a particular purpose (like in req-
tag-applications) MUST NOT recycle a request tag unless the first
operation has concluded.  What constitutes a concluded operation
depends on that purpose, and is defined there.
Paragraph (version A):
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.
Paragraph (version B):
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 (including the absent option) that is not in
use by the other matchable operations for the new operation.