Re: Alt-SvcB

[Ian Swett <[e-mail]>]

I would second David's statement.  In the world we live in today, we still
need to use the Alt-Svc header for a substantial number of users.

On Tue, Oct 25, 2022 at 2:31 PM David Schinazi <[e-mail]>
wrote:

> Hi Martin,
>
> Thanks for writing this up. Overall I think the long-term strategy makes
> sense, but I think it's too early to obsolete/deprecate 7838. It's fairly
> common for browsers to use getaddrinfo() on some platforms and that does
> not provide access to HTTPS RRs. In those cases, 7838 is the only path to
> using HTTP/3, so I expect browsers to keep using it for quite some time.
> Marking 7838 as obsolete doesn't reflect that reality.
>
> David
>
> On Mon, Oct 24, 2022 at 5:10 PM Martin Thomson <[e-mail]> wrote:
>
>> Hey everyone,
>>
>> The Alt-Svc design team has been very busy recently and making some
>> progress on working out an alternative alternative services design.
>>
>> I just posted
>> https://martinthomson.github.io/alt-svcb/draft-thomson-httpbis-alt-svcb.html
>> as a -00 draft.  This outlines the alternative design that we've been
>> exploring in the design team.
>>
>> The basic idea is split into two procedures:
>>
>> 1. Use: When an Alt-SvcB field or ALTSVCB frame is encountered, the
>> client looks for HTTPS records for the provided name in the DNS and creates
>> a connection using what it learns.
>> 2. Reuse: When a client that has previously used an alternative service
>> connects again, it remembers the HTTPS record that worked.  It performs a
>> regular HTTPS record lookup for the server - not using the alternative that
>> it learned, but the name from the URI - but it prefers the alternative it
>> previously used if that alternative appears in the results.
>>
>> The draft explains in more detail and goes into some of the implications
>> of the design.
>>
>> This is not done by any imagining.  We have a bunch of open issues at
>> https://github.com/martinthomson/alt-svcb/issues that do require some
>> amount of input.  But we think that this is a promising approach and would
>> appreciate more input.
>>
>> Cheers,
>> Martin
>>
>>