Hypertext Transfer Protocol Version 3 (HTTP/3)
Note: This ballot was opened for revision 33 and is now closed.
Benjamin Kaduk (was Discuss) Yes
Thanks for addressing my comments on the -33, and for another clear and well-written document. I especially appreciated Appendix A.
Martin Duke Yes
Roman Danyliw Yes
Comment (2021-01-19 for -33)
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.
Alvaro Retana No Objection
Erik Kline No Objection
Martin Vigoureux No Objection
Murray Kucherawy No Objection
Robert Wilton No Objection
Comment (2021-01-21 for -33)
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? 220.127.116.11. Field Compression Given that section 18.104.22.168. 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. Thanks, Rob
Warren Kumari No Objection
Comment (2021-01-20 for -33)
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)
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 (firstname.lastname@example.org)." rather be "and a contact of the W3C HTTP working group (email@example.com)." ?
(Barry Leiba; former steering group member) (was Discuss) Yes
Thanks for addressing my comments in -34, and for a very well-written document.
(Magnus Westerlund; former steering group member) Yes
( for -33)
(Alissa Cooper; former steering group member) No Objection
( for -33)
(Deborah Brungard; former steering group member) No Objection
( for -33)