From: Mark Nottingham <mnot@mnot.net>
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
Subject: Identifying our deliverables
Message-Id: <578BB4EC-421E-4B21-AA14-B545A41754C8@mnot.net>
Date: Sun, 28 Oct 2018 11:30:55 +1100
To: IETF QUIC WG <quic@ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/RLRs4nB1lwFCZ_7k0iuz0ZBa35s>
Precedence: list

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.=20

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*=20

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/