Fwd: Identifying our deliverables (naming QUIC's HTTP binding) (fwd)

[Poul-Henning Kamp]

As expected:  QUIC == HTTP/3

Start reading up...

Poul-Henning

------- Forwarded Message

From: Mark Nottingham <mnot at mnot.net>
Date: Tue, 30 Oct 2018 11:18:36 +1100
To: HTTP Working Group <ietf-http-wg at w3.org>
Message-Id: <67D04361-CE05-4DCC-AA99-3DA259BBF326 at mnot.net>

Everyone,

FYI, this might come to the WG in Bangkok.

Cheers,


> Begin forwarded message:
> 
> From: Mark Nottingham <mnot at mnot.net>
> Subject: Identifying our deliverables
> Date: 28 October 2018 at 11:30:55 am AEDT
> To: IETF QUIC WG <quic at ietf.org>
> Archived-At: 
<https://mailarchive.ietf.org/arch/msg/quic/RLRs4nB1lwFCZ_7k0iuz0ZBa35s>
> 
> 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/
------- End of Forwarded Message