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.
>>
>>