W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2020

Re: Call for Adoption: HTTP/2 Bis

From: Ian Swett <ianswett@google.com>
Date: Wed, 2 Dec 2020 20:46:00 -0500
Message-ID: <CAKcm_gOAFMamcdj68LjW3gJ7spNwhuSx1tjW3pZjNJc+EBLymg@mail.gmail.com>
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>
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

This archive was generated by hypermail 2.4.0 : Thursday, 3 December 2020 01:46:25 UTC