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

Re: [EXTERNAL] Re: Alt-SvcB

From: Martin Thomson <mt@lowentropy.net>
Date: Wed, 02 Nov 2022 11:07:47 +0000
Message-Id: <020c3e89-a464-4ae9-8b07-5549d8418ad0@app.fastmail.com>
To: "David Benjamin" <davidben@chromium.org>, "Tommy Jensen" <Jensen.Thomas@microsoft.com>
Cc: "David Schinazi" <dschinazi.ietf@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
I'd be happy to roll that into the Alt-SvcB document; we're obsoleting RFC 7838, so we can include some discussion of how it might be better interpreted.

On Tue, Nov 1, 2022, at 15:29, David Benjamin wrote:
> 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> wrote:
>> 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 HTTPS RR?
>> 
>> 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 Wednesday, 2 November 2022 11:08:24 UTC

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