Skip to main content

Bootstrapping WebSockets with HTTP/3
RFC 9220

Yes

Francesca Palombini

No Objection

Erik Kline
(Alvaro Retana)
(Martin Vigoureux)

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

Francesca Palombini
Yes
Martin Duke
Yes
Comment (2022-01-25 for -02) Sent
You should probably either complete the TODO acknowledge or remove the section. :-)
Zaheduzzaman Sarker
Yes
Comment (2022-02-01 for -02) Sent
Thanks for the short but required upgrade.

Please add a reference to HTTP/2 RFC 7540.
Erik Kline
No Objection
Lars Eggert
No Objection
Comment (2022-02-03 for -02) Sent
Thanks to Vijay Gurbani for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/MA9WZc8SHIyjFmEN_0yCkUuFodo).

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 3. , paragraph 2, nit:
>  RST exceptions are represented with an stream error (Section 8 of [HTTP3]) o
>                                      ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".
Murray Kucherawy
No Objection
Comment (2022-02-01 for -02) Not sent
I concur with the others:

* Please finish or remove your Acknowledgments section.

* This needs a reference to HTTP/2.

* This was pretty dense for such a short document.
Robert Wilton
No Objection
Comment (2022-01-30 for -02) Sent
Hi,

Thanks for this document.  Given how short this document is, I found it somewhat harder to read than I expected, and hence I have a few minor and editorial suggestions (that you are welcome to take or leave) that may improve readability.

   [RFC8441] defines an extension to HTTP/2 which is also useful in
   HTTP/3.

1. I would suggest adding the referenced doc title here rather than leading the introduction with just the RFC reference number.
2. I think that you need at least an informative reference to HTTP/2.
3. The references to both HTTP/2 and HTTP/3 should be included when they are cited in the first sentence.

  3.  Websockets Upgrade over HTTP/3

4. I would suggest moving the 2nd paragraph that considers stream closure to the end of section 3, since the 1st, 3rd and 4th paragraphs all seem to be more closely related in their subject matter.

Thanks,
Rob
Roman Danyliw
No Objection
Comment (2022-01-31 for -02) Not sent
Thank you to Tirumaleswar Reddy for the SECDIR review.
Warren Kumari
No Objection
Comment (2022-02-02 for -02) Sent
I was dreading reviewing this document - I understand what websockets are, and how to use them, but much of how they are actually implemented is black magic to me.
Same for HTTP/3 - it's better and faster and securer(!) and all-around-wonderful... but "Bootstrapping WebSockets with HTTP/3" sounded suspiciously like "prefabulated amulite, surmounted by a malleable logarithmic casing in such a way that the two main spurving bearings were in a direct line with the panametric fan."

It turns out that this document simply reduces to a previous document which I also didn't understand, and so I manage to remain in blissful ignorance.
Kerphew!
Éric Vyncke
No Objection
Comment (2022-01-31 for -02) Not sent
Like Rob, I find this short document pretty hard to understand for non HTTP expert. Hence, a very superficial review of mine.

I was about to raise the same comment as Martin about the TODO acknowledgement section.
Benjamin Kaduk Former IESG member
Yes
Yes (2022-01-28 for -02) Sent
A couple editorial nits in https://github.com/httpwg/http-extensions/pull/1904
and just one "real" comment.

Section 1

   HTTP/3.  This extension makes use of an HTTP/2 setting.  Appendix A.3
   of [HTTP3] describes the required updates for HTTP/2 settings to be
   used with HTTP/3.

The referenced appendix mostly (by line count) talks about how individual
HTTP/2 settings (or the semantics thereof) are mapped to HTTP/3; however,
it does not list or discuss SETTINGS_ENABLE_CONNECT_PROTOCOL.  That leads
me to surmise that the intent here is instead to refer to the statements
like "Settings ported from HTTP/2 might choose to redefine their value to
limit it to 30 bits for more efficient encoding, or to make use of the
62-bit space if more than 30 bits are required" and "Settings need to be
defined separately for HTTP/2 and HTTP/3."  If so, perhaps something
like "gives some guidance on what changes (if any) are appropriate when
porting settings from HTTP/2 to HTTP/3" would help direct the reader to
the intended part of A.3?
Alvaro Retana Former IESG member
No Objection
No Objection (for -02) Not sent

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