Mohamed Boucadair's No Objection on draft-ietf-httpbis-optimistic-upgrade-05: (with COMMENT)

Mohamed Boucadair 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:
----------------------------------------------------------------------

Hi Ben,

Thanks for the effort put into this well-written spec.

Please find below some minor comments:

# Please help readers to find where to look for various statements in the spec.
For example:

(1)

OLD:
   In HTTP/1.1 and later, a single connection can be used for many
   requests.  In HTTP/2 and HTTP/3, these requests

NEW:
   In HTTP/1.1 [RFC9112]  and later, a single connection can be used for many
   requests.  In HTTP/2 [RFC9113] and HTTP/3 [RFC9114], these requests

(2) Point to where this is specified

CURRENT:
   However, in HTTP/1.1, requests are strictly sequential, and each new
   request is distinguished implicitly by the closure of the preceding
   request.

(3) Cite 9.3.6 of 9110

CURRENT:
   The other mechanism is the HTTP CONNECT method.

# Only when accepted

OLD:
   The server replies with a 2xx (Successful)
   response to indicate that the request was accepted and a TCP
   connection was established.

New:
   If accepted, the server replies with a 2xx (Successful)
   response to indicate that the request was accepted and a TCP
   connection was established.

# Definitive list or samples?

CURRENT:
   Rejections are common, and can happen for a variety of reasons.  A
   request using Upgrade might be rejected if:

Is this the definite list of conditions under which this can be rejected or
these are only examples? Consider making this clear in the text.

The same applies for other similar text in the draft

# An example

CURRENT:
   In some cases, the client might expect that the protocol transition
   ^^^^^^^^^^^^
   will succeed.

Can an example be provided here for illustration purposes?

# Registered Upgrade Tokens

CURRENT:
   This section describes the impact of this document's considerations
   on some registered upgrade tokens that are believed to be in use at
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   the time of writing.

Can we cite
https://www.iana.org/assignments/http-upgrade-tokens/http-upgrade-tokens.xhtml?

# Future specifications

CURRENT:
   Future specifications for upgrade tokens should account for the
   security issues discussed here and provide clear guidance on how
   implementations can avoid them.

How this reco will be tracked?

# Consider using {:quote} to tag all the citations in the document.

Cheers,
Med

Received on Wednesday, 10 September 2025 08:53:48 UTC