Code change:
upload append (upload-appending), and upload cancellation (upload- cancellation). <del> Once the upload resource is available, the target resource MAY send an informational response with a "104 (Upload Resumption Supported)" status code to the client while the request content is being uploaded.  In this informational response, the "Location" header field MUST be set to the upload resource. </del> <ins> Once the upload resource is available and while the request content is being uploaded, the target resource MAY send one or more informational responses with a "104 (Upload Resumption Supported)" status code to the client.  In the first informational response, the "Location" header field MUST be set to the URL pointing to the upload resource.  In subsequent informational responses, the "Location" header field MUST NOT be set.  An informational response MAY contain the "Upload-Offset" header field with the current upload offset as the value to inform the client about the upload progress.  In subsequent informational responses, the upload offset MUST NOT be smaller than in previous informational responses.  In addition, later offset retrievals (offset-retrieving) MUST NOT receive an upload offset that is less than the offset reported in the latest informational response, allowing the client to free associated resources. </ins> The server MUST send the "Upload-Offset" header field in the response if it considers the upload active, either when the response is a

Related discussion:
text: Or maybe URL
I'm not fussed on the specific response code value but the 102 seems deprecated, for whatever that means, and the linked wording seems at odds with the system design we want
It's not deprecated, but wasn't carried over to WebDAV-bis due to lack of implementations. It's in the registry, so it's a real HTTP status code. That said, I now agree it doesn't fit well, as 102 is for situations where the client is actually waiting for a response (as opposed to still sending).
I guess that's accurate to the historical record, after a very cursory delve into RFC 2518 and 4918. But I wonder how clear that interpretation is to the broader HTTP world. MDN has a perspective you might want to follow up on. Yeah this is where I'm hitting a hard edge. A registered status code, where the behaviour, the important stuff, is described in an obsoleted RFC doesn't really seem great.
FWIW, I would push back hard on that line of argument. The code is registered, so it's a valid status code. And yes, a spec that wants to use might want to either include an updated definition, or make sure the definition is moved to a separate new document.
I also think that 102 is OK to use here (but maybe a new status code is still warranted, see below). The 102 isn't depreciated as a bad idea or because of another better solution, it was merely omitted from recent updates to the WebDAV specification for lack of implementations. I imagine another specification could take over ownership of the definition/registration. I think the only reason I didn't specifically write 102 in my email is, I've to indicate "upload complete, the server is now performing additional processing" and it may be useful to distinguish this signal from "upload has been partially received and committed to storage". The former is probably closer to the intended usage, so it may still be good to mint a new status code for the latter usage. Alternatively, both cases might be distinguished by the HTTP fields that are returned, and maybe servers want to indicate both at the same time ("50% committed to disk, 20% processed").
I share the view that 102 does not fit very well here.