Re: Alt-SvcB

[David Schinazi <[e-mail]>]

Thanks Martin, this makes sense to me. I'd suggest tweaking the phrasing in
the document then. Your email says <<We're not proposing that we
*deprecate* Alt-Svc.>> but the draft abstract says <<This document
deprecates RFC 7838>>. But if it's just a matter of wording then I'm ok
with your plan.

David

On Tue, Oct 25, 2022 at 5:45 PM Martin Thomson <[e-mail]> wrote:

> On Wed, Oct 26, 2022, at 10:21, David Schinazi wrote:
> > h3 hints are a great example of something that needs to be added to
> > Alt-Svc.
>
> So I think that we're fixated a little much on a specific interpretation
> of "obsoletes" here.
>
> TLS 1.3 obsoleted TLS 1.2.  That has not stopped the TLS community from
> publishing a number of RFCs that specifically extend TLS 1.2.
>
> In TLS 1.2, just like Alt-Svc, we have clear problems, but an ongoing
> deployment need.  For TLS, it is primarily deployment costs (1.3 is a
> relatively big lift), with a sprinkling of other attachments. For Alt-Svc,
> it is the signal of HTTP/3 support where HTTPS doesn't work.  That's more
> than just an OS problem.  It's also tied up with deployment of networking
> gear in some cases, so we'll probably be stuck with it as long as the
> desire to use HTTP/3 in those affected cases is significant.
>
> We're not proposing that we *deprecate* Alt-Svc.  This isn't RFC 8996 for
> TLS 1.1/1.0 where the use of the protocol is actively discouraged.  RFC
> 8996 came some time after TLS 1.2/RFC 5246.  Though perhaps folks like
> Lucas might want that deprecation to happen sooner rather than later, we
> recognize that Alt-Svc is needed.  That is, until the problems Alt-Svc
> causes starts to look bad relative to the diminishing number of clients
> that need it to get HTTP/3.
>
> As others have noted, we'll probably need the HTTP/3 signal for some
> time.  But we might be able to narrow that over time.
>
> We're not taking Alt-Svc away.  We're merely saying that it is not our
> preferred solution any more.
>
>