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

Commentary: The previous statement was overreaching , see discussion at 
  at probable conclusion " stateless proxies can only process Block1 cases trivially , everything else needs further exploration " 
 Not Our Problem thanks to , and put out of scope in
Mailing list commentary: Hello CoRE , handling blockwise in a stateless fashion is hard , and previous discussion[1 ] stalled a bit . My current impression is that both echo - request - tag and stateless - proxy expect the other document to say how it 's actualy done ( and both documents should be released soon ) , and nobody is quite sure what can be said at all . There is one pretty clear - cut case where " the simple thing " works : Client sends request with Block1 partial data , and the proxy attaches Request - Tag identifying the original client . Even the pure Block2 case is a bit doubtful -- I think that a stateless proxy could just forward safe requests with Block2 in request and/or response as long as there is no Block1 around , but I ' m not sure . When Block1+Block2 comes in , it gets tricky , because a ) some argument is needed that a Request - Tag makes sense at all with Block2 ( it does , as it can be a legitimate leftover from a reassembly , and ca n't be changed when going from the Block1 to the Block2 phase ) , and b ) the proxy ca n't statelessly determine whether a late POST with Block2 : n message should have a Request - Tag ( as it might belong to a POST Block1 : m messagee that had one ) , or not ( because it might belong to a POST with no mention of a Block option and thus no Request - Tag ) -- at least not without Request - Tagging every message which is clearly excessive . I think that a bit more than the clear - cut case can be salvaged , but honestly am not much driven to make a scenario work for which our best example is a SOAP exchange . So , questions to the group : Which document should the procedure and limitations be described in ( I 'd suggest stateless , as the Block2 case needs reasoning that 's unrelated to Request - Tag ) , and are there any better ideas than " Sorry , no stateless forwarding " for Block1+Block2 or non - safe Block2 ? KR Christian [ 1 ] :
Actually , I believe this is material for neither . You do n’t need ERT to solve this problem , and it is a similar problem even if stateless is not in use , so we should write this up in general . ,
It is intended for Block1 , but spills into the Block2 phase due to RFC7959 Section 2.7 's description of the block-2 - phase requests as " similar to the requests in the phase [ without ] the Block1 Options and [ including ] a Block2 request option with non - zero NUM " . The operation may have created state on the server , and the later requests may be only accessible if the block - matching - relevant options of the Block2 - phase requests are the same as the earlier ones . From that , I 'd assume the use of Request - Tag to be suitable there . How that relates to single - message unsafe requests with blockwise response bodies ( eg . empty POSTs ) I ' m unsure , but a stateless proxy would send a Request - Tag on some of the messages as it ca n't tell them apart from the above case . KR c
Paragraph (version A):
The Request-Tag option provides a very simple way for a proxy to keep
them separate: if it appends a Request-Tag that is particular to the
requesting endpoint to all request carrying any Block option, it does
not need to keep track of any further block state.
Paragraph (version A):
This is particularly useful to proxies that strive for stateless
operation as described in I-D.ietf-core-stateless Section 3.1.
Paragraph (version B):
In some cases, for example when forwarding block-wise request
operations, appending a Request-Tag value unique to the client can
satisfy the requirements on the proxy that come from the presence of
a block option.
Paragraph (version B):
This is particularly useful to proxies that strive for stateless
operation as described in I-D.ietf-core-stateless Section 4.
Paragraph (version B):
The precise classification of cases in which such a Request-Tag
option is sufficient is not trivial, especially when both request and
response body are fragmented, and out of scope for this document.