Re: [EXTERNAL] Re: Alt-SvcB

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