- From: Ian Swett <ianswett@google.com>
- Date: Wed, 2 Dec 2020 20:46:00 -0500
- To: Mark Nottingham <mnot@mnot.net>, Bence Béky <bnc@google.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, Tommy Pauly <tpauly@apple.com>
- Message-ID: <CAKcm_gOAFMamcdj68LjW3gJ7spNwhuSx1tjW3pZjNJc+EBLymg@mail.gmail.com>
That seems sensible to me, but I'd like a better understanding of whether we ever expect to be able to ship extensions to HTTP/2 or not before I support the lack of a new ALPN. Google servers have attempted to enable WebSockets over H2 twice to my knowledge and had to roll it back both times(once only a few months ago). +Bence Béky <bnc@google.com> has done some work to improve the server-side ecosystem via Chrome experiments, but I'm not sure if we expect enough improvements in clients and servers to ship extensions in the near future. If we don't mint a new ALPN, I believe we should call out that extensions face deployment risk without a new ALPN. A few IETF contributors I trust have put forth the idea that in 5 years, H2 will no longer be worth supporting given the widespread deployment of H3, so possibly this is a self-solving problem? Thanks, Ian On Wed, Dec 2, 2020 at 7:40 PM Mark Nottingham <mnot@mnot.net> wrote: > Based upon discussion at the interim and subsequent activity on the HTTP/2 > issues list, the Chairs believe that the following is in-scope for a HTTP/2 > bis effort: > > * Incorporating errata > * Makeing strictly editorial improvements > * Aligning with the publication of http-core > * Incorporating RFC8740 to align with the publication of TLS 1.3 > * Updating references to other specifications as necessary > * Documenting additional security considerations > * Providing implementer guidance where appropriate > * Addressing problems or ambiguities where the affect interoperability, so > long as the solution does decrease interoperability > * Making the protocol more resistant to ossification, so long as doing so > does not affect interoperability > > This effort will not create a new version of HTTP; its output will not > have a distinct ALPN identifier. As such, new features and > backwards-incompatible changes like updates to the HPACK static table are > out of scope. For the same reason, deprecating or removing Server Push and > the Priority scheme is out of scope, although implementation advice might > contextualise their use. > > Please indicate whether you support this approach to the work; the CfA > will end in two weeks on 17 December. > > Cheers, > > -- > Mark and Tommy > > >
Received on Thursday, 3 December 2020 01:46:24 UTC