Hi Spencer, Thanks for sharing.
On Thu, May 6, 2021 at 3:17 PM Spencer Dawkins at IETF < [email protected]> wrote: > Hi, Lucas, > > I am aware that QUIC and HTTP/3 have been deployed at scale with all the > instrumentation one could hope for when deploying Internet-Drafts, but I > have to ask - if people identify a (presumably rare) problem using HTTP/3 > ALPN identifier "h3" with QUIC "0x00000001", what do we do then? > Speaking as an individual. There are possibilities for things to go wrong. HTTP has a mild safety by means of Alt-Svc, its upgrade and fallback mechanism should insulate end users from problems. QUIC can, however, be used for many applications so the story isn't complete. One failure root cause class is due to implementation - those things can typically be detected and fixed. Another failure root cause class could be in the QUIC protocol itself. There may be a need to fix such a problem in a new version and that's partly why the WG is placing energy into the version negotiation document (draft-ietf-quic-version-negotiation) [1] As I mentioned up thread, the "h3" ALPN identifier is explicitly linked to only QUIC 0x00000001. Some of the recent version negotiation discussion has touched on what HTTP/3 ALPN identifier we might use with a new version of QUIC. So I don't have all the answers but I'm encouraged by the attitude to the version negotiation work, in anticipation of the need to support QUIC protocol revisions. Anyone with ideas or suggestions on that topic please review or contribute to discussion on appropriate list thread or the GitHub repository https://github.com/quicwg/version-negotiation/issues Cheers, Lucas [1] - https://datatracker.ietf.org/doc/html/draft-ietf-quic-version-negotiation
