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

Everyone,

FYI, this might come to the WG in Bangkok.

Cheers,


> Begin forwarded message:
> 
> From: Mark Nottingham <mnot@mnot.net>
> Subject: Identifying our deliverables
> Date: 28 October 2018 at 11:30:55 am AEDT
> To: IETF QUIC WG <quic@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/