Skip to main content

RFC 9114


Martin Duke
(Magnus Westerlund)

No Objection

Erik Kline
Murray Kucherawy
(Alissa Cooper)
(Alvaro Retana)
(Deborah Brungard)
(Martin Vigoureux)

Note: This ballot was opened for revision 33 and is now closed.

Martin Duke
Roman Danyliw
Comment (2021-01-19 for -33) Sent
The work on this document and its companions is greatly appreciated! 

Thank you to Hilarie Orman for the SECDIR review.

** Section 3.1.  “The host must be listed either as the CN field …”, why not a normative MUST just as there is in the next sentence around the required use of iPAddress?

** Section 3.3  Per “Once a connection exists to a server endpoint, this connection MAY be reused for requests with multiple different URI authority components”, it might be worth repeating here that in cases of https, changes in the authority components still need to occur within the bounds of the certificate validation practices noted in Section 3.1 and in Section 4.3.4 of draft-ietf-httpbis-semantics.
Erik Kline
No Objection
Murray Kucherawy
No Objection
Robert Wilton
No Objection
Comment (2021-01-21 for -33) Sent
Another well written document coming out of the QUIC WG, thank you for that.

Some minor comments:

4.1.1.  Field Formatting and Compression

   As in previous versions of HTTP, field names are strings containing a
   subset of ASCII characters that are compared in a case-insensitive
   fashion.  Properties of HTTP field names and values are discussed in
   more detail in Section 5.1 of [SEMANTICS].  As in HTTP/2, characters
   in field names MUST be converted to lowercase prior to their
   encoding.  A request or response containing uppercase characters in
   field names MUST be treated as malformed (Section 4.1.3).
Why make the comparison case-insensitive given that the request MUST only use lowercase characters?  Presumably implementations will just do a regular case sensitive comparison?  Field Compression

Given that section  states that "Pseudo-header fields are not HTTP fields.", it might be helpful to be explicit that pseudo-header fields are also compressed using QPACK.

6.1.  Bidirectional Streams

So as to not unnecessarily limit
   parallelism, at least 100 requests SHOULD be permitted at a time.
Given that this section is about streams, perhaps better if the limit is stated in terms of streams, e.g., perhaps change "requests" to "request streams".

10.6.  Use of Compression

   Implementations communicating on a secure channel MUST NOT compress
   content that includes both confidential and attacker-controlled data
   unless separate compression contexts are used for each source of
   data.  Compression MUST NOT be used if the source of data cannot be
   reliably determined.
This wasn't entirely clear to me.  I presume (perhaps wrongly) that the issue is about the use of compression before the confidential data has been encrypted.  I.e., I would presume that compressing a stream of data that includes both encrypted and non encrypted data is okay?  Perhaps this could be clarified.

Warren Kumari
No Objection
Comment (2021-01-20 for -33) Not sent
I support Barry and Ben's DISCUSS (to the extent that I understand it :-))

Other than that, I found this document easily readable, sane, and useful. I with I could say that about more documents...
Éric Vyncke
No Objection
Comment (2021-01-19 for -33) Sent
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,




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 (" rather be "and a contact of the W3C HTTP working group (" ?
Barry Leiba Former IESG member
(was Discuss) Yes
Yes (2021-02-02) Sent
Thanks for addressing my comments in -34, and for a very well-written document.
Benjamin Kaduk Former IESG member
(was Discuss) Yes
Yes (2021-02-02) Sent
Thanks for addressing my comments on the -33, and for another clear
and well-written document.  I especially appreciated Appendix A.
Magnus Westerlund Former IESG member
Yes (for -33) Unknown

Alissa Cooper Former IESG member
No Objection
No Objection (for -33) Not sent

Alvaro Retana Former IESG member
No Objection
No Objection (for -33) Not sent

Deborah Brungard Former IESG member
No Objection
No Objection (for -33) Not sent

Martin Vigoureux Former IESG member
No Objection
No Objection (for -33) Not sent