FWIW, I agree with you; I'd rather not mint a new ALPN. It depends how
brutal we're willing to be with installed and not-upgraded systems. An ALPN
change is high friction, but won't break them; simply deploying GREASE will
break some things that maybe deserve to get broken.
-----Original Message-----
From: Willy Tarreau <w@1wt.eu>
Sent: Thursday, December 10, 2020 11:41 PM
To: Mike Bishop <mbishop@evequefou.be>
Cc: Ian Swett <ianswett@google.com>; David Benjamin <davidben@chromium.org>;
Cory Benfield <cory@lukasa.co.uk>; Mark Nottingham <mnot@mnot.net>; Bence
Béky <bnc@google.com>; HTTP Working Group <ietf-http-wg@w3.org>; Tommy Pauly
<tpauly@apple.com>
Subject: Re: Call for Adoption: HTTP/2 Bis
Hi Mike,
On Thu, Dec 10, 2020 at 10:05:22PM +0000, Mike Bishop wrote:
> And to me, that's the real question over a new ALPN. If we can keep
> the token "h2" and add GREASE successfully, let's do that. If we
> can't add GREASE without changing the ALPN token, we should consider
> changing the ALPN token.
But why would GREASE require a new ALPN ? Bence is already doing some
greasing and managed to find bugs in several of our implementations. I'd
rather push stronger in this direction after some code points can be
reserved for various purposes.
> Of course, that means we're effectively minting "h2.1" or
> "h2-nobugs", at which point we need not necessarily be limited to
> non-breaking changes.
What I hate with changing ALPN is that it's a user-visible change. Asking
users to change their ALPN string from "h2,http/1.1" to "h2.1,h2,http/1.1"
just because a working group decided to slightly change the protocol for the
sake of better interoperability is hard to justify, especially after it was
claimed that the protocol is called "HTTP/2" because it will not have a
sub-version.
If we'd change the ALPN we should then think about all the on-wire changes
that were discussed in the past, like the poor hpack encoding, changing
initial settings etc. It doesn't seem worth doing with H3 knocking at the
door in my opinion.
Cheers,
Willy