Re: draft-ietf-httpbis-resumable-upload-09: not ready: design

Hi Glenn,

You close out your email with an expectation that the authors won't respond. That's a bit presumptive. I'll also highlight that the participants in IETF do not vote. You expressed your views, which I welcome, and I trust the WG chairs will factor these in when judging the consensus about this draft.

Your other thread contains many points, which I've reviewed and I expect the other authors too - just like all feedback that is received. Based on my personal opinion, that other thread has several useful suggestions that we can action, but also  several technical design change proposals to the document.

WGLC is the right time to be asking some questions. However, we also need to recognise that the document reflects choices of emerging consensus through the process. There are many ways to approach this problem space. The authors have threaded the needle on taking feedback to adjust the design while ensuring it continues to meet the goals and needs of implementers and users. Its not too late to make design change proposals, nor to change the design details. Doing so, however, needs sufficient evidence to motivate any change.

With regards to the claim that comments [1] [2] were "largely dismissed" let's look into that some more. Issue 2239 was created by the authors, based on feedback from the WG. Earlier designs had used a client-generated token. There has been discussions where people had proposed a design that uses something server generated. PR 2292 was created with the proposed changes. The topic was discussed during IETF 115 [3].

Your comment on issue 2239 appeared to be related to a tangential discussion about parallel uploads. On PR 2292, your comment is responding to text that sets the context of the PR but only quotes part of it. Taking the description  text as a whole, it's clear that the context of the PR is to switch to a design that uses a server-generated URL. The description highlights why the old design was how it was and what is lost by the change. The PR punts on it, and delegated the discussion to Issue 2293 [4]. That punting was done to ensure momentum on the change from client-generated to server-generated. Subsequent comments in the PR are tangential to the contents of the PR. PRs are not an appropriate place for such discussions.

As noted above, issue 2239 was discussed at IETF 115 [3] and we received a fair amount of feedback from various people. The authors reflected the emerging consensus towards a server-generated design by landing PR 2292.

In summary, you commented on an issue and PR related to the same topic. The comments were tangential to the topic. The claim the authors ignored these comments because they were seemingly intent on pre-optimization for fabricaticted scenarios is untrue. We dropped a design feature (client-initated tokens) that provided optimizations, in order to switch to a server-generated URL, at the intial request of the WG and based on emerging consensus during WG meetings. 

Cheers
Lucas

[1] - https://github.com/httpwg/http-extensions/pull/2292#issuecomment-1304748660
[2] - https://github.com/httpwg/http-extensions/issues/2239#issuecomment-1312697792
[3] - 
https://datatracker.ietf.org/meeting/115/materials/minutes-115-httpbis-00#resumable-uploads
[4] - https://github.com/httpwg/http-extensions/issues/2293

On Sun, Aug 10, 2025, at 01:12, Glenn Strauss wrote:
> draft-ietf-httpbis-resumable-upload-09: not ready: design
> 
> Major Issues:
> - It is an application; overly complex for a generic extension to HTTP
> - It fails to discuss existing solutions
> - It unnecessarily over-specifies application implementation details
> 
> draft-ietf-httpbis-resumable-upload has been in development for over 3 years.
> None of these are new criticisms, yet remain unaddressed.
> 
> 
> 
> In April of 2022, I and others gave *detailed* feedback in thread [1]
> on how tus-v2 (the precursor to resumable uploads) is an application,
> and an application which does not leverage existing HTTP mechanisms.
> 
> [1] https://lists.w3.org/Archives/Public/ietf-http-wg/2022AprJun/0000.html
> 
> My posts in that thread from April - June 2022:
> [2] https://lists.w3.org/Archives/Public/ietf-http-wg/2022AprJun/0052.html
> [3] https://lists.w3.org/Archives/Public/ietf-http-wg/2022AprJun/0224.html
> [4] https://lists.w3.org/Archives/Public/ietf-http-wg/2022AprJun/0235.html
> [5] https://lists.w3.org/Archives/Public/ietf-http-wg/2022AprJun/0239.html
> [6] https://lists.w3.org/Archives/Public/ietf-http-wg/2022AprJun/0240.html
> [7] https://lists.w3.org/Archives/Public/ietf-http-wg/2022AprJun/0242.html
> [8] https://lists.w3.org/Archives/Public/ietf-http-wg/2022AprJun/0245.html
> 
> 
> 
> Application-specific drafts are now out-of-scope for HTTPWG according to
> the recent draft proposal to update to HTTPWG charter [9] which states:
> "This Working Group is charged with maintaining and developing the core specifications for HTTP and generic extensions to it (i.e., those that are not specific to one application)."
> 
> [9] https://lists.w3.org/Archives/Public/ietf-http-wg/2025JulSep/0005.html
> 
> As currently written, draft-ietf-httpbis-resumable-upload reads to me as
> a specific application.
> 
> 
> 
> Regarding already-existing HTTP mechanisms, back in 2022 I wrote:
> 
> In [6] above, I wrote:
> > I have provided some examples how resumable uploads might be implemented
> > using current standards, and so I request that any new protocol justify
> > why current mechanisms are insufficient and why the new protocol is
> > substantially better (and hopefully without adding new security
> > headaches).
> 
> draft-ietf-httpbis-resumable-upload does not sufficiently address this.
> 
> In [8] above, I wrote:
> > More generally, I think it useful to separate uploading a large resource
> > (which might be interrupted) from processing that resource.
> > 
> > If a resource is uploaded via partial-PUT to a temporary file,
> > e.g. to a path assigned by initial upload request, then the resource
> > can be extended via partial-PUT until complete.
> > 
> > Once resource is completely uploaded, an HTTP request can be made to
> > an endpoint requesting that the target be processed.
> > 
> > This sequence of requests can be achieved today with existing standards.
> > 
> > This loosely couples multiple HTTP requests to achieve a stateful upload
> > before processing, where both client and server know that the upload is
> > complete or not, and know that processing did not occur until the upload
> > was complete.
> > 
> > Pre-requisites to allowing uploads, quotas, managing total disk usage,
> > temp file lifetimes, etc. can be site-specific or application-specific,
> > or both.
> 
> In contrast, draft-ietf-httpbis-resumable-upload describes a fragile,
> overly-convoluted sequence of steps where the application requires
> application-level state to be maintained on the server.  Additionally,
> appending to an upload resource requires that a server or intermediaries
> not block (by policy) the PATCH method.  Cancelling a resumable upload
> requires that a server or intermediaries not block (by policy) the
> DELETE method.  This is not a generic extension to HTTP.
> 
> draft-ietf-httpbis-resumable-upload describes the implementation of a
> specific application (or two, depending on the approach) imposing that
> the server maintain additional application-level state about the upload
> resource and requiring many different parts of the server to participate
> in conveying the availability of this application and state of the
> upload resource.  It suggests changes needed in numerous different code
> paths for servers to support resumable uploads.
> 
> 
> 
> In 2022, I tried giving more directed feedback on various github issues
> [10] [11], but my feedback was largely dismissed by the
> resumable-upload authors.  They seemed intent on pre-optimizing
> for fabricated scenarios without data on realistic use.
> 
> [10] https://github.com/httpwg/http-extensions/pull/2292
> https://github.com/httpwg/http-extensions/pull/2292#issuecomment-1304748660
> https://github.com/httpwg/http-extensions/pull/2292#issuecomment-1304869022
> [11] https://github.com/httpwg/http-extensions/issues/2239
> https://github.com/httpwg/http-extensions/issues/2239#issuecomment-1312697792
> 
> 
> 
> Practically speaking, the vast majority of HTTP requests do not contain
> large request bodies.  For those which do, another large swath of
> requests uploads are static files.  If a client has access to upload
> files, such as documents or pictures, one existing mechanism is to
> upload to a temporary file and to rename once the upload is complete.
> draft-ietf-httpbis-resumable-upload does not provide a compelling
> alternative to existing solutions for this scenario.  iCloud, GDrive,
> OneDrive, DropBox, and many others have solutions for syncing files.
> 
> 
> 
> draft-ietf-httpbis-resumable-upload may have some underlying intentions
> which may be better extracted to one or more simpler RFCs.
> 
> I can envision a much simpler RFC to define a Content-Accum header with
> a token that can be used by multiple requests to modify state of a
> temporary resource, e.g. via partial-PUT.  Once complete, the token may
> be used to indicate to a server to process a request using the temporary
> resource in lieu of a request body.
> 
> This might be useful for CDNs or regional endpoints to collect a
> request body from a flaky client over multiple partial uploads,
> and then to send the completed request for processing.
> 
> This might be useful to scanners which check content for intellectual
> property, GDPR, or other policy validation.
> 
> The client should manage the state of the temporary resource, uploading
> the resource in chunks.  If a chunk fails, resend the chunk, perhaps
> trying with a smaller chunk size.  The server may apply policies to
> avoid abuse, but the server is not required to manage or maintain state
> besides creating and mapping a token to a temporary resource, and the
> temporary resource.  A client managing the state of the temporary
> resource may send parallel uploads over multiple paths, which is an
> artificial and hard limitation explicitly not supported in
> draft-ietf-httpbis-resumable-upload.
> 
> 
> 
> I will follow this email with another which give more direct feedback
> on the contents of draft-ietf-httpbis-resumable-upload.
> 
> I do not expect the original authors of TUSv2 or Resumable Uploads
> to respond to these criticisms.  This post instead is directed towards
> those evaluating draft-ietf-httpbis-resumable-upload for Last Call.
> 
> To those reviewers, my non-binding vote is that the resumable-upload
> application should not be published as an RFC from the HTTPWG.
> 
> 
> Cheers, Glenn
> lighttpd developer
> (among other things, author of the current lighttpd mod_webdav)
> 
>