httpwg
RESUMABLE: proposal - upload resource should be a temporary file and nothing more
@gstrauss provided the following feedback on https://lists.w3.org/Archives/Public/ietf-http-wg/2025JulSep/0094.html wrt Section 4.4.2
The upload resource should be a temporary file, and for draft-ietf-httpbis-resumable-upload, maintains state. A better design might be only a temporary file and nothing more.
See also the following text from @gstrauss
If the upload resource is simply a file and the client manages overall state and the client finishes the upload before sending Upload-Complete: ?1 with an empty body, then a client can send a HEAD request for size details. Upload-Offset would be redundant. There would be little need to keep upload resources around after Upload-Complete: ?1. There would be little need to make queries to try to approximate "transaction status" or "history" of the upload resource state.
In the event that the client did not receive a response to request with Upload-Complete: ?1 and empty body, the client could repeat that request.
This appears to be a last-minute suggestion for an alternative design without strong motivation (although it could be in other issues that need to be developed). Absent strong support for exploring this design in the WG, I think we can close.
This appears to be a last-minute suggestion for an alternative design
I believe this was discussed, perhaps in different wording, in an email thread 3 years ago from April - June 2022. https://lists.w3.org/Archives/Public/ietf-http-wg/2022AprJun/0000.html
I do not believe that @LPardue was an editor on this draft at the time and so I suggest that thread be reviewed.
I believe that design-based feedback given in that thread is not new, and is being repeated in https://lists.w3.org/Archives/Public/ietf-http-wg/2025JulSep/0093.html and is the contextual underpinnings for my feedback in https://lists.w3.org/Archives/Public/ietf-http-wg/2025JulSep/0094.html
I do not believe that @LPardue was an editor on this draft at the time and so I suggest that thread be reviewed.
I was. You can check this yourself at https://datatracker.ietf.org/doc/draft-tus-httpbis-resumable-uploads-protocol/00/
The thread you are talking about was in relation to an I-D pre-adoption. The adoption call went out of 2022-08-02 and the document adoption was confirmed on 2022-08-25; see https://lists.w3.org/Archives/Public/ietf-http-wg/2022JulSep/0113.html
I am not aware of any proposal to change the design, as captured on this issue, during or after the adoption call. Therefore as a WG item, this is a late design change proposals.
I am not aware of any proposal to change the design, as captured on this issue, during or after the adoption call.
Maybe so. That is because I strongly objected to the adoption when I gave my technical objections to the design.
Please consider my post to the mailing list, late or not, as my continuing objection to the design flaws I have identified in draft-ietf-httpbis-resumable-upload-09. I do not believe it is ready for publication. I do believe it is a flawed and inefficient application, not a well-designed generically-useful and efficient HTTP extension.
Maybe so. That is because I strongly objected to the adoption when I gave my technical objections to the design.
@gstrauss you did not raise these comments during the formal adoption call.
Discussion about non-adopted work is just feedback on non-adopted work, and authors have no duty to consider it or not.
During the formal drafting process you have not engaged while the working group has iterated on its adopted draft.
I do hope that the working group considers feedback on the mailing list whenever posted, and not just in certain limited windows of time on the mailing list. In any case, I think this is off-topic for the issue and that further nit-picking will not be fruitful.
Discussing the process is not nitpicking. Its a requirement for the chairs and document shepherd to understand how the document developed, gathered rough consensus, and the state of running code.
The Working Group works on adopted documents. The design has evolved a lot since comments made in 2022.
When you told me in 2023 that you planned to wait until last call to raise your issues, I advised against that as it runs counter to how the process operates.
Thank you for noting that I privately expressed concerns to you in 2023. Yes, you did recommended that I repeat my concerns which I had already posted in the WG mailing list in 2022, but even as an editor on this document, you were aware of those concerns and ignored them until I posted here at last call to repeat myself from 2022.
As I noted several times, you had every opportunity to raise discussion on the list, open issues and PRs, or reach out to the chairs during the period between the draft being adopted and WGLC being issued.
The WG is responsible for driving discussion topics. The adoption call is the signal to the authors that the design at the time has passed the WG bar to use as a starting point in draft 00. The WG has also driven evolution of the document to its 09.
As a WG participant, it cannot be expected that other people will do the work for you. Nor can it be expected that everyone will respond to everyone else, and give them the answer they expect or want.
I observe that to be true.
Many of us are volunteers and there are limits to everyone's time and how they choose to spend it.