Re: I-D Action: draft-ietf-httpbis-resumable-upload-08.txt

Hello Julian,

thank you very much for the extensive feedback and constructive
suggestions. We'll be sure to address these quickly to make the draft more
precise and understandable. Overall, I agreed with everything you said, but
want to comment on two points in particular.

> One big issue that I see is the overuse of BCP14 keywords.

You're right. The draft's usage of BCP14 keywords has been rightfully
brought up and adjusted before, but seems to need more attention. We'll
have another look at it.

> 4.4.1 "The request content MAY be empty" - of course, why not? Why does
this need permission?

This paragraph stems from experience that we gathered during previous
implementations of resumable upload protocols, where empty representations
or content triggered edge cases and were not properly handled. In addition,
we received questions about the possibility and implications of empty
content in the past, and thus figured it would make sense to explain these
in the document.

Best regards,
Marius


On Thu, May 1, 2025 at 2:26 PM Julian Reschke <julian.reschke@gmx.de> wrote:

> Am 11.04.2025 um 14:19 schrieb Julian Reschke:
> > Am 08.04.2025 um 14:14 schrieb Marius Kleidl:
> >> ...
> >> With the closure of https://github.com/httpwg/http-extensions/
> >> issues/2962 <https://github.com/httpwg/http-extensions/issues/2962>
> >> following the discussion at the IETF meeting, there are currently no
> >> more open issues for this document. Hence, we believe this draft is
> >> ready for a WGLC.
> >> ...
> >
> > +1 (and I'll try to review soonish)
> > ...
>
> Ok, not that soonish. But here's my feedback:
>
> Hi there,
>
> below a ton of nits, and a few more important things; sorry for the lack
> of structure.
>
> One big issue that I see is the overuse of BCP14 keywords.
>
> - for each MAY, please check whether this is actually an interop
> requierement or just a statement of fact. In which case "may" or "can"
> would be better.
>
> - for each SHOULD NOT, it's important to understand why this is MUST
> NOT. So what are the exceptional cases where not following the
> requirement is acceptable?
>
> I flagged some of these cases, but not all.
>
>
> 2. re STRUCTURE-FIELDS; maybe state here upfront that all fields defined
> here actually use that syntax; the definitions, for instance in 4.1.1
> are really not sufficient for readers not aware of SF to understand
> what's going on. Or, in each definition, link to the matching section in
> the SF spec
>
> 3.1 maybe say something about the PATCH media type early on?
>
> 4 But URIs of upload resources could be recycled, right?
>
> 4.1.1 "resource-loses" - typo?
>
> 4.1.3 "MAY use" -> "can use"
>
> 4.1.4 "MAY not create" -> "might not create" (twice)
>
> 4.1.4 "MAY stop" -> "can stop" - it does not need permission here, and
> it might choose to stop it for other reasons anyway.
>
> 4.1.4 "SHOULD NOT send such requests" - in which cases would it be
> allowed? Maybe this is a MUST?
>
> 4.1.4 "MAY make the upload resource" -> "might"
>
> 4.1.4 "client SHOULD NOT attempt" -> rephrase this as statement that
> such attempts will fail
>
> 4.1.4 "MAY be extended but SHOULD NOT be reduced" - unless?
>
> "under a target URI" -> "for a target URI"?
>
> "OPTIONS *" support is known for servers to be hard to implement, so a
> MUST feels out of place here.
>
> "The limits announced in an OPTIONS response SHOULD NOT be less
> restrictive than the limits applied to an upload once the upload
> resource has been created." - what about if the limit changes between
> the requests?
>
> 4.2.3 I would have moved that to an appendix (if only to avoid that
> section numbers will change later on).
>
> 4.2.4 Remove the version indicators before WG LC please.
>
> 4.3.1 "The client MUST NOT perform offset retrieval while creation
> (Section 4.2) or appending (Section 4.4) is in progress." - otherwise?
>
> 4.4.1 "The request content MAY be empty" - of course, why not? Why does
> this need permission?
>
> 4.4.2 "... and without discontinuities as possible." - what does this mean?
>
> 4.5.1 "The client MUST NOT initiate cancellation without the knowledge
> of server support." - how does it know that, and what would happen if it
> would do it anyway?
>
> 4.5.2 why does it need to be a 204?
>
> 4.6 "the resource SHOULD prevent race conditions, data loss, and
> corruption by terminating the previous request before processing the new
> request" - that actually sounds like a MUST.
>
> 5. "The start and end of the block might align with the start and end of
> the representation data, but they are not required to be aligned." -
> explain "aligned"
>
> 8. "Please note that the Content-Length header field cannot be used in
> conjunction with the Transfer-Encoding header field." - really?
>
> 9.1 " If the digests don't match, the server SHOULD consider the upload
> failed and not process the representation further." - and signal an
> error, right?
>
> 10. Can the "subsequent resource" have the same URI as the upload resource?
>
> 10. Content-Location appears to be incorrect here, see
> https://www.rfc-editor.org/rfc/rfc9110.html#section-6.4.2-5.5
>
> 11.1.1 What does "user" refer to here?
>
> 13. Split into subsections
>
> 13. The definition of Status Code 104 really needs a dedicated section
> that the registry can link to.
>
> 14.1 8792 does not seem to be normative, as it is only used in examples.
>
>
> Best regards, Julian
>
>