Lucas Pardue

The issue with your proposed design is, it can consume additional bandwidth due to needing to send duplicated data that was already delivered to server but not confirmed as such...

It would be remiss to not mention that fetching the upload offset, as described in 09, is also a request that would count against total requests. However, the nature of...

It sounds like parralelization is an optimization that can be fragile. There's a lot of open questions and tradeoffs here for both the current design and the proposal. I suggest...

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...

> 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...

> 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...

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....

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...

@MikeBishop I'm wondering if it might make sense to address the issuing of stopping a request more generally (rather than just his section) alongside text I've proposed in https://github.com/httpwg/http-extensions/pull/3232 (which...

This got me thinging about some security implications there might be wrt content negotiaton, see https://github.com/httpwg/http-extensions/issues/3213#issuecomment-3217520588