RE: Call for Adoption: HTTP/2 Bis

These feed on each other.  Several of the proposed features require or might require a new ALPN.  That's an argument against them so long as we don't have to do a new ALPN otherwise.  If, however, we agree to do something that requires a new ALPN token then that argument against the others goes away and might change the balance of consensus.

That said, I agree with you that GREASE is the only maybe-requires feature that seems to have enough drive to push it over the edge regardless.  If we come to the point where a new ALPN is required, we could re-evaluate those other things.

-----Original Message-----
From: Mark Nottingham <mnot@mnot.net> 
Sent: Thursday, December 10, 2020 7:18 PM
To: Mike Bishop <mbishop@evequefou.be>
Cc: Ian Swett <ianswett@google.com>; David Benjamin <davidben@chromium.org>; Cory Benfield <cory@lukasa.co.uk>; 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

Hey Mike,

I agree that the discussion on grease needs to play out, and I can see a future where we come to consensus that a new ALPN identifier is useful in serving that goal. However, I don't think it's useful to talk about other breaking changes before that consensus (if it happens), based on the lack of interest in them in the discussion so far. Also, if we do gain that consensus, it would be good to have an agreement about whether other breaking changes are suddenly back on the table.

Does that make sense, and if so, can we modify the scope to capture it (with a direction on the latter question)?

Cheers,


> On 11 Dec 2020, at 9:05 am, Mike Bishop <mbishop@evequefou.be> 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.  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.
>  
> To Roy’s comments, I’m comfortable with the distinction that the document being adopted now has a particular scope, and future documents that do other things may be considered for adoption in the future.  While water under the bridge is and was a poor argument for pre-standard working group drafts, it’s a very solid argument for a non-breaking revision of a deployed protocol.
>  
> I support adoption of the document, but I feel like aspects of the scope aren’t as settled as this announcement suggests.
>  
> From: Ian Swett <ianswett@google.com>
> Sent: Tuesday, December 8, 2020 1:05 PM
> To: David Benjamin <davidben@chromium.org>
> Cc: 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
>  
>  
>  
> On Tue, Dec 8, 2020 at 11:15 AM David Benjamin <davidben@chromium.org> wrote:
> 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.
>  
> +1 to David on GREASE.
>  
>  
> > 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.
> 

--
Mark Nottingham   https://www.mnot.net/