Subject: Identifying our deliverables

From: Mark Nottingham <[email-masked]>
Date: Sun, 28 Oct 2018 11:30:55 +1100

You might recall that we've previously talked about renaming our deliverables to clarify their relationship to the input documents (sometimes referred to as "gQUIC vs iQUIC").

After a fair amount of discussion with various folks, it seems like there's confidence that calling our core deliverable just "QUIC" will work, since Google's variant will fade out of use if we succeed, and there aren't any good alternatives; our best candidate was "QUIC/2", but it was pointed out that this additional level of versioning (since we already have a wire version) will cause yet more confusion.

However, in those discussions, a related concern was identified; confusion between QUIC-the-transport-protocol, and QUIC-the-HTTP-binding. I and others have seen a number of folks not closely involved in this work conflating the two, even though they're now separate things.

To address this, I'd like to suggest that -- after coordination with the HTTP WG -- we rename our the HTTP document to "HTTP/3", and using the final ALPN token "h3". Doing so clearly identifies it as another binding of HTTP semantics to the wire protocol -- just as HTTP/2 did -- so people understand its separation from QUIC.

As part of that discussion, I'd suggest that we formalise that its maintenance (as well as that of QPACK) pass off to the HTTP WG once we've published it.

I've talked about this with a number of folks. The only concerns I've heard so far are:

a) That QUIC isn't yet proven. That's true, but the name won't be formalised or used on the wire until the RFC is published, so we have a good amount of time to back away. Even then, if it fails in the market, we can always skip to HTTP/4 one day, if we need to. 

b) That discussing naming is a distraction from our technical work. I agree with the concern overall, but we have a responsibility to communicate clearly with external developers and users, so I'd like to have a *limited* discussion about this. Please, don't bike shed.

*Chair hat* 

We plan on reserving a very small period of time to discuss this in Bangkok; barring serious objections (of which "what about this name that I like instead?" is not one), we'll bring it up with the HTTP WG in Bangkok as well.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 30 Oct 2018 06:21:33 +0100

On Sun, Oct 28, 2018 at 11:30:55AM +1100, Mark Nottingham wrote:
> To address this, I'd like to suggest that -- after coordination with the HTTP
> WG -- we rename our the HTTP document to "HTTP/3", and using the final ALPN
> token "h3". Doing so clearly identifies it as another binding of HTTP
> semantics to the wire protocol -- just as HTTP/2 did -- so people understand
> its separation from QUIC.

FWIW I always thought that HTTP/3 should be its final naming -- just like SPDY
became HTTP/2 -- for various reasons, one of them being encouraging adoption
by the protocol being presented as the natural upgrade to the previous ones
and not a competitor that's been there for some time and suddenly comes as
an RFC.

H1 with 723x, then H2 with 754x have shown that it's not a problem to cover
multiple areas with a common name and that the protocol itself is in fact a
family of protocols and mechanisms. So QPACK will naturally fall under H3
just like HPACK naturally belongs to H2.

Just my two cents,
Willy

---

From: Ian Swett <[email-masked]>
Date: Tue, 30 Oct 2018 09:56:00 -0400

>From a completely practical perspective, I support this because I can't
tell you how many times I've had to explain the difference between the HTTP
over QUIC mapping and QUIC the transport.

And moving the HTTP over QUIC and QPACK documents to the HTTP working group
seems like the right thing to do.

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 30 Oct 2018 14:25:32 +0000

I echo Ian's thoughts, "HTTP over QUIC" doesn't work well as a term in
practice.

I support this change, using an incremental number is logical, and is
compatible with the ecosystem that expects an HTTP version number.

On Tue, 30 Oct 2018, 13:56 Ian Swett, <ianswett=[email-masked]>
wrote:

> And moving the HTTP over QUIC and QPACK documents to the HTTP working
> group seems like the right thing to do.
>

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Tue, 30 Oct 2018 07:28:43 -0700

Recent edits in transport also use terms such as “This frame is only used
in the QUIC layer” which is slightly confusing when QUIC/HTTP is also a
(higher) level QUIC layer while “QUIC layer” refers to the transport layer
only, implicitly.

Mikkel

On 30 October 2018 at 15.26.19, Lucas Pardue ([email-masked])
wrote:

---

From: Roberto Peon <[email-masked]>
Date: Tue, 30 Oct 2018 16:34:04 +0000

Since there isn’t any particular need to identify QUIC the transport (without mechanisms to explicitly multiplex multiple protocols), I think calling HTTP-on-QUIC H3 is the right move.
QUIC without anything else is as meaningless as TCP without anything else from a what-the-server-will-speak perspective.
-=R

From: QUIC <[email-masked]> on behalf of Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Tuesday, October 30, 2018 at 7:29 AM
To: Ian Swett <ianswett=[email-masked]>, Lucas Pardue <[email-masked]>
Cc: Mark Nottingham <[email-masked]>, IETF QUIC WG <[email-masked]>, Willy Tarreau <[email-masked]>
Subject: Re: Identifying our deliverables

Recent edits in transport also use terms such as “This frame is only used in the QUIC layer” which is slightly confusing when QUIC/HTTP is also a (higher) level QUIC layer while “QUIC layer” refers to the transport layer only, implicitly.

Mikkel

On 30 October 2018 at 15.26.19, Lucas Pardue ([email-masked]<mailto:[email-masked]>) wrote:
I echo Ian's thoughts, "HTTP over QUIC" doesn't work well as a term in practice.

I support this change, using an incremental number is logical, and is compatible with the ecosystem that expects an HTTP version number.

On Tue, 30 Oct 2018, 13:56 Ian Swett, <ianswett=[email-masked]..org<mailto:[email-masked]>> wrote:
From a completely practical perspective, I support this because I can't tell you how many times I've had to explain the difference between the HTTP over QUIC mapping and QUIC the transport.

And moving the HTTP over QUIC and QPACK documents to the HTTP working group seems like the right thing to do.

On Tue, Oct 30, 2018 at 1:21 AM Willy Tarreau <[email-masked]<mailto:[email-masked]>> wrote:

Just my two cents,
Willy

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 30 Oct 2018 10:58:49 -0700

I'll add to the chorus: I'm in favor of this change.

On Tue, Oct 30, 2018 at 9:36 AM Roberto Peon <[email-masked]> wrote:

> Since there isn’t any particular need to identify QUIC the transport
> (without mechanisms to explicitly multiplex multiple protocols), I think
> calling HTTP-on-QUIC H3 is the right move.
>
> QUIC without anything else is as meaningless as TCP without anything else
> from a what-the-server-will-speak perspective.
> -=R
>
>
>
> *From: *QUIC <[email-masked]> on behalf of Mikkel Fahnøe Jørgensen
> <[email-masked]>
> *Date: *Tuesday, October 30, 2018 at 7:29 AM
> *To: *Ian Swett <ianswett=[email-masked]>, Lucas Pardue <
> [email-masked]>
> *Cc: *Mark Nottingham <[email-masked]>, IETF QUIC WG <[email-masked]>,
> Willy Tarreau <[email-masked]>
> *Subject: *Re: Identifying our deliverables
>
>
>
> On Tue, 30 Oct 2018, 13:56 Ian Swett, <ianswett=
> [email-masked]..org <[email-masked]>> wrote:
>

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 30 Oct 2018 12:18:57 -0700

> On Oct 27, 2018, at 5:30 PM, Mark Nottingham <[email-masked]> wrote:
> 

FWIW, I don't have a problem with calling a product of the HTTP WG some form of h3,
with the implication that we are working on the next version of HTTP and that it will
work on top of QUIC.  I have a bit of a problem with assuming that h3 product will be
the current HTTP-over-QUIC binding, QPACK, etc.  It's a reasonable option to work upon.

....Roy

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Tue, 30 Oct 2018 12:22:43 -0700

On 30 October 2018 at 20.19.26, Roy T. Fielding ([email-masked]) wrote:

 I have a bit of a problem with assuming that h3 product will be
the current HTTP-over-QUIC binding, QPACK, etc. It's a reasonable option to
work upon.

It could be h3.alpha

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 30 Oct 2018 13:36:55 -0700

> with the implication that we are working on the next version of HTTP and

work on top of QUIC.

That sounds like HTTP/4 to me :-)

---

From: Daniel Stenberg <[email-masked]>
Date: Wed, 31 Oct 2018 00:02:43 +0100 (CET)

On Sun, 28 Oct 2018, Mark Nottingham wrote:

> To address this, I'd like to suggest that -- after coordination with the 
> HTTP WG -- we rename our the HTTP document to "HTTP/3", and using the final 
> ALPN token "h3". Doing so clearly identifies it as another binding of HTTP 

I like it!

-- 

  / daniel.haxx.se

---

From: Mike Bishop <[email-masked]>
Date: Thu, 1 Nov 2018 03:32:21 +0000

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.

Those process and ownership requirements satisfied, I think this naming is entirely appropriate.  In Montreal, the HTTP WG made an explicit decision not to backport things from HTTP/QUIC to HTTP/2 because HTTP/QUIC is "the future," and I think the HTTP/3 name reflects that intent.  Not to say the intent couldn't change as future circumstances do, but it accurately reflects what we plan at this point.

-----Original Message-----
From: QUIC <[email-masked]> On Behalf Of Roy T. Fielding
Sent: Tuesday, October 30, 2018 2:19 PM
To: Mark Nottingham <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
Subject: Re: Identifying our deliverables

> We plan on reserving a very small period of time to discuss this in Bangkok; barring serious objections (of which "what about this name that I like instead?" is not one), we'll bring it up with the…

FWIW, I don't have a problem with calling a product of the HTTP WG some form of h3, with the implication that we are working on the next version of HTTP and that it will work on top of QUIC.  I have a bit of a problem with assuming that h3 product will be the current HTTP-over-QUIC binding, QPACK, etc.  It's a reasonable option to work upon.

.....Roy

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 1 Nov 2018 06:58:59 +0100

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.

Willy