Re: Draft v1 Update for Resumable Uploads

Hi Glenn,

I'd like to respond to one aspectdirectly:

On Sun, Jun 19, 2022 at 7:04 AM <gs-lists-ietf-http-wg@gluelogic.com> wrote:

> On Thu, Jun 16, 2022 at 02:30:59PM -0700, Guoye Zhang wrote:
> > Our previous resumable upload draft generated a lot of discussions.
>
> At least in my case, I attempted to be polite after you submitted a
> draft without first doing a survey of existing RFCs.  You admitted no
> knowledge of WebDAV RFCs, which I deemed a large oversight considering
> the nature of the tus-v2 protocol.
>
> > I’m glad to announce that we have a new draft ready to address many
> feedbacks that suggested adopting the PATCH method.
>
> The draft abstract begins with unsubstantiated claims to justify itself,
> and I believe that almost all of those claims are also misleading.
>
> "HTTP clients often encounter interrupted data transfers as a result of
> canceled requests or dropped connections. [...] it is often desirable to
> issue subsequent requests that transfer only the remainder of the
> representation."
>
> The multiple uses of "often" are misrepresentations, IMHO.
>
> A large percentage of HTTP requests are GET/HEAD and have no body.
> A sizable percentage (if not more) of HTTP POST requests are small,
> e.g. using POST as an alternative to GET along with XSRF tokens.
>
> What data do you have to support the claims in the draft Abstract?
> What percentage of requests have request bodies, and further have
> request bodies that are sufficiently large that it is excessively
> wasteful to resend the entire representation? (and when safe to do so!)
>

The text you quote from the tus v2 draft is based on an almost verbatim
section of text from RFC 9110 Section 14 [1], which describes Range
Requests. Quote:

> Clients often encounter interrupted data transfers as a result of
canceled requests or dropped connections. When a client has stored a
partial representation, it is desirable to request the remainder of that
representation in a subsequent request rather than transfer the entire
representation.

I wrote the tus v2 text to explicity juxtapose resumable HTTP downloads
against uploads. To quote the abstract in full:

> HTTP clients often encounter interrupted data transfers as a result
   of canceled requests or dropped connections.  Prior to interruption,
   part of a representation may have been exchanged.  To complete the
   data transfer of the entire representation, it is often desirable to
   issue subsequent requests that transfer only the remainder of the
   representation.  HTTP range requests support this concept of
   resumable downloads from server to client.  This document describes a
   mechanism that supports resumable uploads from client to server using
   HTTP.

If you have concerns about the first instance of "often", I'd suggest
starting a separate thread against RFC 9110. I don't agree this document
has a requirement to justify that as you suggest.

If you have concerns about the second instance of "often", that is perhaps
where we have different readings causing some friction. RFC 9110 doesn't
have any qualification of the term "it is desirable", I used "often" to
dilute this i.e, "often but not always". A different reading is that,
having seen multiple HTTP-based custom resumable upload approaches from
different vendors, there is an unaddressed use case. Hence it is not seldom
that for applicaitons that feature uploads, resumption is desirable.
Either way, I am happy to remove that second "often" or do other
wordsmithing of this sentence that makes it clear why we think this is a
problem worth standardising in the HTTP WG.


Cheers,
Lucas