Re: Alt-SvcB

Lucas Pardue <> Tue, 25 October 2022 21:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0344DC14CE25 for <>; Tue, 25 Oct 2022 14:28:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.058
X-Spam-Status: No, score=-5.058 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ofMiNtywxBxT for <>; Tue, 25 Oct 2022 14:28:09 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id BA2E7C14F723 for <>; Tue, 25 Oct 2022 14:28:09 -0700 (PDT)
Received: from lists by with local (Exim 4.94.2) (envelope-from <>) id 1onRQC-004VFn-3S for; Tue, 25 Oct 2022 21:25:16 +0000
Resent-Date: Tue, 25 Oct 2022 21:25:16 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <>) id 1onRQB-004VEa-9L for; Tue, 25 Oct 2022 21:25:15 +0000
Received: from ([2607:f8b0:4864:20::329]) by with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <>) id 1onRQ9-001OxL-Hf for; Tue, 25 Oct 2022 21:25:14 +0000
Received: by with SMTP id v40-20020a056830092800b00661e37421c2so8670910ott.3 for <>; Tue, 25 Oct 2022 14:25:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=kR/lT2wxP84YFKmchovi3stTWicKQXRXQbXO1ip+81k=; b=pK+18ICxhR+m+40DrcDpueDCDKnTamrBfmFBJSTfCPYccV+J9VC4OcsQT0y1tPTMys Gi6KjSottpGwetpMTmUKGzBck+Jr89r9uIQPt+xDIiqS1QeeadbP7OCNS+/dOUwensqR B2IoxqR3t/caLWRlRxH/pScECTGpzo5UGj9ZGN0L/GcAkJVUtqH4R8SaMBViHK5QNHXC /MZ+nFPMYOl54kD6Tsf+68G13stkIEmpr9Q2hbtH3l6IF0C3n/4toYmZ4WmJ2s6jo2Tm hg2or2Z1dSVUnVbI0TG/NVQ2Hw5LNbmWmeWx8WuMxGB5L9IQD3kiy2nPXz4j113hik7+ sUiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=kR/lT2wxP84YFKmchovi3stTWicKQXRXQbXO1ip+81k=; b=wAiFCpC2qvdfNNBF07zcBxWeceJh0JZ4D6BfCROE8p80BcjxB0H1uIpdBC4axtjFhj zAl06hvO8HcleYBSIESGZk1ppz7VlxYfnR8nJvo2klJ6qhUGGEbc/LySMgfc3428zaXL JSp5QjWWyu/Hcl//0guxgGXrAvor9twveOhAz3AxhWI3bMc4UbuYxAfbbrcLJB7MnYaC KqznuyAKcbofr9xXYNrbpNZ9SoDJBYkuRxKcVtzxJCoByXETdoxwL/Ni9cDAtyzNw771 DD4p+9RB8vYmkIaqECk1Rr5uEp7mgK4ezIvniYOuvC7BdOqAoDqqNG8oB+8I6ZEZbFxn /zsA==
X-Gm-Message-State: ACrzQf0c1a+p8vT3V6BqXcyfk9KOqvQI+3QpFvsG+JnT7c4IikWxmvyi hZGzsXpeynL7rxWBHOj5cyQhEnye8yzOmu85QAk=
X-Google-Smtp-Source: AMsMyM6nShoF+1jdE6Zy0+J1+z0Sk3YdXJWxIfSZ+eBl2dpDtp66qfDjxSkZkZp+fptBD6BZ/fzubilIhD9ztzz6jXE=
X-Received: by 2002:a05:6830:2475:b0:661:b91c:f32a with SMTP id x53-20020a056830247500b00661b91cf32amr20278718otr.123.1666733102520; Tue, 25 Oct 2022 14:25:02 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Lucas Pardue <>
Date: Tue, 25 Oct 2022 22:24:45 +0100
Message-ID: <>
To: Tommy Pauly <>
Cc: Ian Swett <>, David Schinazi <>, Martin Thomson <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="00000000000082e12f05ebe28a43"
Received-SPF: pass client-ip=2607:f8b0:4864:20::329;;
X-W3C-Hub-DKIM-Status: validation passed: (, signature is good
X-W3C-Hub-Spam-Status: No, score=-4.8
X-W3C-Scan-Sig: 1onRQ9-001OxL-Hf beace5f2a0f1a678c68d4dcd36cdbb00
Subject: Re: Alt-SvcB
Archived-At: <>
X-Mailing-List: <> archive/latest/40486
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

I'd also add that by deprecating Alt-Svc, we can reasonably descope it from
other related work, to the advantage if the community.

For instance, Martin Duke and I have a draft intended to optimise
performance of selecting QUIC versions with HTTP/3 [1]. We describe how
this works with the HTTPS record. We also have to accommodate Alt-Svc
since  "that's what people use", even though we know that Alt-Svc's design
is broken for this type of versioning support in certain scenarios like

I can live with contuinuing to send Alt-Svc in order to support legacy
clients. Alt-Svc being frozen in time and not getting new goodies seems


[1] -

On Tue, 25 Oct 2022, 21:33 Tommy Pauly, <> wrote:

> The way I’d look at this is that we should be fine keeping the use of
> Alt-Svc for existing (and what will become legacy) clients to upgrade to
> h3, but we should not use it for any new protocol discovery. I.e., when we
> have an HTTP version that needs some transport other than TCP and QUIC, we
> shouldn’t plan on using Alt-Svc for that. So, our timeline should be to
> make sure clients can do HTTPS RRs by the time we replace QUIC, which
> should give us time.
> Tommy
> On Oct 25, 2022, at 1:21 PM, Ian Swett <> wrote:
> 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 <>
> 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 <> 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
>>> 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
>>> that do require some
>>> amount of input.  But we think that this is a promising approach and would
>>> appreciate more input.
>>> Cheers,
>>> Martin