Re: AD Review: draft-ietf-httpbis-optimistic-upgrade

Hi Mike,

I've opened a PR that attempts to address these comments: https://github.com/httpwg/http-extensions/pull/3133/files.  Please review.

In draft-04, the update to RFC 9112 is indeed implicit in Section 7.  Assuming an explicit textual update is required, this PR defines that update as adding a new section to RFC 9112.  Only the requirements on proxy servers are included in the update, on the theory that the client-side requirements already existed implicitly.

I wasn't able to make kramdown-rfc render RFC 9112 as "HTTP/1.1", as recommended in the HTTP editorial style guide, due to lack of support for the "/" and "." characters.  If anyone knows how to do that please comment on the PR.

--Ben


________________________________
From: Mike Bishop <mbishop@evequefou.be>
Sent: Thursday, July 17, 2025 11:05 AM
To: draft-ietf-httpbis-optimistic-upgrade@ietf.org <draft-ietf-httpbis-optimistic-upgrade@ietf.org>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Subject: AD Review: draft-ietf-httpbis-optimistic-upgrade

Hi, Ben - Thanks for this document. I've followed it with interest and reviewed it in the past, so my comments at this point are minimal. Please review the HTTP Editorial Style Guide, particularly ensuring that you're using a consistent format

Hi, Ben -

Thanks for this document. I've followed it with interest and reviewed it in the past, so my comments at this point are minimal.

Please review the HTTP Editorial Style Guide<https://urldefense.com/v3/__https://httpwg.org/admin/editors/style-guide__;!!Bt8RZUm9aw!9SUJ-f9qE6UUIOBbGeWmUN5DdSRbVC3xYtI_cbJh5hVOyUskwzXf1G_C5Gi_IOBPoYM8wmIlMqGOuQYf$>, particularly ensuring that you're using a consistent format to reference status codes, field names, and method names.
HTTP Editorial Style Guide - httpwg.org<https://urldefense.com/v3/__https://httpwg.org/admin/editors/style-guide__;!!Bt8RZUm9aw!9SUJ-f9qE6UUIOBbGeWmUN5DdSRbVC3xYtI_cbJh5hVOyUskwzXf1G_C5Gi_IOBPoYM8wmIlMqGOuQYf$>
Example Messages If your specification has examples of HTTP messages (and it probably should), they should give enough context for readers to understand. Generally, this means showing a substantial portion of the message; e.g., not just a header field in isolation, but an entire request or response message (with a truncated body). Where appropriate, an entire exchange (request and response ...
httpwg.org
The metadata indicates that it updates RFC9112, but 9112 is not mentioned in the abstract and the specific change being made is not explicit in the text of the document. I assume that Section 7 is intended to update RFC9112 to impose these requirements?

In Section 3.1, consider "doesn't" => "cannot".

In Section 6, should TLS also be listed as an example of a fixed preamble? It's only one byte, but it gets the job done.

In Section 6.1, I assume you're capitalizing "Upgrade Token," "Method," etc. because they're capitalized in the registries, but registry names are always title-cased. Where these terms are used elsewhere in RFC9110, they're not capitalized terms.

While I can understand that a Security Considerations section seems superfluous in a document whose title is "Security Considerations for...", RFC2223 does require it of all RFCs. A single sentence that the entire document discusses security considerations should be sufficient.

Beyond these minor comments, I think this is ready to move forward into Last Call and IESG review. Thanks for driving this work forward over the last two years.

-Mike Bishop (as AD)