Éric Vyncke's No Objection on draft-ietf-quic-http-33: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-quic-http-33: 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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-quic-http/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be
appreciated), and two nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

For many comments, please bear with my lack of expertise in HTTP in general.

-- Section 1.1 --
This section mixes "HTTP/1.1" and "HTTP/1.x" and it is unclear to me what the
link is between the first 2 sentences.

-- Section 3.1 --
In "clients SHOULD attempt to use TCP-based versions of HTTP in this case."
Should the version(s) of HTTP be specified or is it done on purpose to allow a
HTTP/4 over TCP (if ever) ?

-- Section 4.2 --
Should this section mention the work in MASQUE? While I am not really familiar
with MASQUE, isn't it using the CONNECT H/2 method (e.g.,
draft-ietf-masque-connect-udp albeit for UDP) ?

-- Section 4.4 --
Should the client behavior be specified when server does not respect "A server
SHOULD use Push IDs sequentially, beginning from zero. " ?

-- Section 5.3 --
Should the CONNECT method behavior be specified when the client does an
immediate closure?

-- Section 5.4 --
Should the server behavior be specified when the QUIC transport aborts ? It is
mostly obvious that all states will be cleared but what about the CONNECT
method ?

-- Section 11.2.1 and others --
I must admit that the purpose of the special "0x1f * N + 0x21" values are
unknown to me (or is it only for application padding as described in the
security section?) but shouldn't they be reserved in the IANA registry?

== NITS ==

-- Section 1 --
" These semantics have most commonly been used with
   HTTP/1.1, over a variety of transport and session layers, and with
   HTTP/2 over TLS. "

The asymmetric use of comas is puzzling, should there be a coma after "HTTP/2" ?

-- Section 11.2 --
Should "and a contact of the HTTP working group ([e-mail])." rather
be "and a contact of the W3C HTTP working group ([e-mail])." ?