W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2022

Re: [EXTERNAL] Re: Alt-SvcB

From: David Benjamin <davidben@chromium.org>
Date: Tue, 1 Nov 2022 11:29:24 -0400
Message-ID: <CAF8qwaCnCDyryKrM-4swECpoyAg89bFKK95HeNC9LSqrYPE_UA@mail.gmail.com>
To: Tommy Jensen <Jensen.Thomas@microsoft.com>
Cc: Martin Thomson <mt@lowentropy.net>, David Schinazi <dschinazi.ietf@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
If we're looking to make a separate system here, with Alt-Svc still
existing for a while, should we make a separate draft to patch up some of
the more glaring mistakes in Alt-Svc? Or perhaps a paragraph in this one.
I'm specifically thinking about how Alt-Svc tries to circumvent the
TLS-level ALPN negotiation. For HTTPS/SVCB, we picked a more nuanced
interpretation. Otherwise implementers may not know that Alt-Svc
misunderstood ALPN and that they need to ignore the spec on this point.

On Wed, Oct 26, 2022 at 1:04 PM Tommy Jensen <Jensen.Thomas@microsoft.com>

> I agree with the point of "deprecation" meaning "please use Alt-SvcB for
> future alt-svc uses" and not "immediately stop using its predecessors"
> however that needs to be appropriately phrased.
> > Can somebody quantify the relative proportion of clients that can't do
> Windows supports SVCB but not HTTPS at the moment, but that will change in
> a future release. Browsers of course tend to support far older OS versions
> than we prefer to backport changes to, which will not be a unique situation
> among OS platforms. This just lends to the statement about what
> "deprecation" means.
> Thanks,
> Tommy
Received on Tuesday, 1 November 2022 15:29:54 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 28 January 2023 21:29:46 UTC