Re: Call for Adoption: HTTP/2 Bis

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.


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

Received on Tuesday, 8 December 2020 08:54:46 UTC