- From: Éric Vyncke via Datatracker <noreply@ietf.org>
- Date: Mon, 15 Sep 2025 04:19:37 -0700
- To: "The IESG" <iesg@ietf.org>
- Cc: draft-ietf-httpbis-optimistic-upgrade@ietf.org, httpbis-chairs@ietf.org, ietf-http-wg@w3.org, tpauly@apple.com, tpauly@apple.com, int-dir@ietf.org, jinmei@wide.ad.jp
Éric Vyncke has entered the following ballot position for draft-ietf-httpbis-optimistic-upgrade-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-httpbis-optimistic-upgrade/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-httpbis-optimistic-upgrade-05 CC @evyncke Thank you for the work put into this document. Usually, I like short and dense documents, but I am afraid that this I-D is too terse to the point of being not easy to understand. Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education). Special thanks to Tommy Pauly for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status. Other thanks to Tatuya Jinmei, the Internet directorate reviewer (at my request): https://datatracker.ietf.org/doc/review-ietf-httpbis-optimistic-upgrade-05-intdir-telechat-jinmei-2025-09-12/ (and I have read the initial discussion) I hope that this review helps to improve the document, Regards, -éric ## COMMENTS (non-blocking) ### Lack of introduction Like other ADs, I think that an introduction will be useful. ### Section 2 Should Upgrade be quoted to make it visible that it is a protocol item ? I.e., s/A request using Upgrade might be rejected/A request using "Upgrade" might be rejected/ ### Section 3 Who is the "we" in `we call` ? The author ? The WG ? The IETF Community ? Please avoid using vague and ambiguous "we" (e.g., by using passive mode). Probably due to my own lack of expertise in the area, but I find the explanations and examples (in this section and its sub-sections) not easy to understand. ### Section 7 Perhaps because English is not my primary language, but the title of the section includes "Guidance", i.e., it does not smell normative while it actually is. The use of a "MUST" with an unless as in `unless the client is known to wait for a 2xx` is rather weird, but perhaps clearer than a "SHOULD" with the same unless... How can a server check that `the client is known to wait for a 2xx` ? At the bare minimum the text should contain "how it is done is out of scope".
Received on Monday, 15 September 2025 11:19:41 UTC