Original text:
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 <del> 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. </del>  The server MUST send the "Upload-Offset" header field in the response if it considers the upload active, either when the response is a

Reviewer comments:
As discussed in URL, this requires the upload offset to not decrease. The server is not allowed to "forget" data appended to an upload. The benefit is that it allows a client to reduce the amount of data buffered while the upload is ongoing as it receives acknowledgements from the server that data has been stored permanently and will not have to be retransmitted. Closes URL
URL added the requirement that the offset reported in 104 informational responses must not decrease over time. For example, it is not allowed that one 104 response includes and the next includes . For now, this requirement is not mentioned for responses to offset retrieval responses. As NAME mentioned in URL, we should add this rule there as well. Maybe it also makes sense to move this into a more central section of the document, so that we don't have to repeat this rule trice (upload creation, upload appending, and offset retrieval).
Thinking about this a bit more, progress reporting and offset retrieving are different enough that adding this requirement to offset retrieving might not actually make sense. In a single append, it's impossible for progress to go back and it's fine to be extremely strict. However, offset retrieving can happen much later. A server could have already forgotten about the previous uploaded body, but still want the upload restarted from 0. In the case that the client cannot supply the bytes, it can always decide to not resume, or perform an explicit cancel.
I am not sure if such a case would actually occur where the server has forgotten parts of the uploaded data but has not forgotten the existence of the upload resource itself, allowing the client to still resume the upload. Do you have an example application? I would have imagined that the upload should be considered as unresumable and failed then. The client could create a new upload if its still has the file data and the application logic allows that. That was my motivation behind enforcing a strict requirement that the upload offset never decreases. The Upload-Offset values should be a guarantee by the server that this amount of data has been saved and won't be lost again. If we don't include such a requirement, it could encourage servers to handle the received data without too much care because they are allowed to decrease the offset again.

Revised text:
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  <ins> the value to inform the client about the upload progress. </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