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

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

Received on Thursday, 1 May 2025 12:24:40 UTC