Re: Call for Adoption: HTTP/2 Bis

On Tue, Dec 8, 2020 at 3:55 AM Cory Benfield <cory@lukasa.co.uk> wrote:

> On Thu, 3 Dec 2020 at 01:49, Ian Swett <ianswett@google.com> wrote:
> >
> > 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 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.
>
> It would be very good to characterise why we believe a new ALPN
> doesn't just punt the ossification risk to the new ALPN. The only way
> I see that happening is if we mandate GREASE as part of the new ALPN.
> I'm open to extending the work to add that, but otherwise it seems
> like we just end up defining a new zero-point and have to do this
> again in five years.
>

Even without GREASE, a new ALPN resets the slate. That means the old
versions of the various broken servers aren't included. The old culprits
have since fixed the broken implementations and will presumably not make
the same mistake. Especially if we actually manage to deploy HTTP/2
extensions this time, that'll also provide a hint to anyone that missed the
memo.

But, yes, whenever we reset the slate, we certainly should take the
opportunity to implement GREASE to help keep it there.


> > 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?
>
> I am with Willy: QUIC has yet to prove its worth in the DC setting.
> This may be self-solving, but if it isn't it would be good for the WG
> to have an idea of how we'd tackle it.
>
> >
> > 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.
>
> I support this approach.
>
>