Re: [quicwg/base-drafts] Unclear what to do when QUIC Version Hints are missing (#3061)

Mike Bishop <> Fri, 04 October 2019 17:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8401B120024 for <>; Fri, 4 Oct 2019 10:47:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.898
X-Spam-Status: No, score=-7.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iapBmFkQJLPS for <>; Fri, 4 Oct 2019 10:47:03 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6C85012008D for <>; Fri, 4 Oct 2019 10:47:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 97CAEC60B24 for <>; Fri, 4 Oct 2019 10:47:02 -0700 (PDT)
Date: Fri, 04 Oct 2019 10:47:02 -0700
From: Mike Bishop <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/3061/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Unclear what to do when QUIC Version Hints are missing (#3061)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d9785968978c_88d3f81d04cd95c1788c5"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 Oct 2019 17:47:07 -0000

It's fine to omit this parameter.  As @Lekensteyn notes, if the client supports multiple versions of QUIC, this helps avoid the need to do Version Negotiation.  However, it's only an optimization -- in the absence of this information, the client does any version of QUIC it believes to be compatible with the ALPN token(s) it is offering.  If the server needs to do VN, it will.  (Details TBD, unfortunately.)

Is this critical to HTTP/3?  No, and it could reasonably be extricated to a separate document until such time that there are multiple QUIC versions.  Most stacks currently support only one version at a time, so this doesn't serve much purpose.  If HTTP/3 doesn't require breaking changes to keep up with QUICvN, this probably serves a purpose on the day there are several.

Personal opinion:  If anyone thinks this is half-baked, let's set it aside until we need it, with the rest of VN.  If we're fairly confident this is what we want, however, it saves us the trouble of defining another separate RFC later.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: