Change:
The previous statement was overreaching, see discussion at URL
Context at URL probable conclusion "stateless proxies can only process Block1 cases trivially, everything else needs further exploration"
Not Our Problem thanks to URL, and put out of scope in URL On 2020-03-06, at 16:55, Christian Amsüss wrote: Actually, I believe this is material for neither. You don’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. Grüße, Carsten
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 can't be changed when going from the Block1 to the Block2 phase), and b) the proxy can'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]: URL To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
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 Block1 phase [without] the Block1 Options and [including] a Block2 request option with non-zero NUM". The Block1 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 can't tell them apart from the above case. KR c To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom

Discussion:
proxy that would forward blocks as plain messages would risk mixing up clients' requests. <del> 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. </del> <ins> 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. </ins> This is particularly useful to proxies that strive for stateless <del> operation as described in I-D.ietf-core-stateless Section 3.1. </del> <ins> operation as described in I-D.ietf-core-stateless Section 4. 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. </ins> 3.6.