Re: Identifying our deliverables

Willy Tarreau <> Thu, 01 November 2018 05:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1693D130DFA for <>; Wed, 31 Oct 2018 22:59:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ymqZM2VtcQSG for <>; Wed, 31 Oct 2018 22:59:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9998C124C04 for <>; Wed, 31 Oct 2018 22:59:10 -0700 (PDT)
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id wA15wxru031911; Thu, 1 Nov 2018 06:58:59 +0100
Date: Thu, 01 Nov 2018 06:58:59 +0100
From: Willy Tarreau <>
To: Mike Bishop <>
Cc: "Roy T. Fielding" <>, Mark Nottingham <>, IETF QUIC WG <>
Subject: Re: Identifying our deliverables
Message-ID: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.6.1 (2016-04-27)
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 01 Nov 2018 05:59:14 -0000

On Thu, Nov 01, 2018 at 03:32:21AM +0000, Mike Bishop wrote:
> In theory, all Standards-track RFCs reflect IETF consensus, not just the
> consensus of a single working group, so I don't see HTTP as having "naming
> rights" per se.  But in general, I think the QUIC WG should have the
> consensus of the HTTP WG to call its output "HTTP/3."  And Mark's proposal
> reflects exactly that, with a heads-up to the HTTP list that we'll be
> discussing in Bangkok.  Along similar lines, I think we'd want to send the
> HTTP doc to both working groups for WGLC, either in parallel or in sequence.
> If both WGs have consensus on the documents, I don't see this as a barrier.

Also we must not dismiss the fact that there's a significant overlap between
the participants of the two WGs, which definitely is an indication of the
strong link between HTTP and QUIC in the way these protocols are designed.
For me it's exactly similar to how SPDY became HTTP/2, those of us who were
following spdy-dev saw a significant drop in activity on this WG once it was
adopted as the basis for H2. Here with QUIC the main justification to have
had a separate WG is that it covers additional areas such as the transport
whose design was out of the scope of the HTTP WG.