RE: Identifying our deliverables

[Mike Bishop <[e-mail]>]

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 <[e-mail]> On Behalf Of Roy T. Fielding
Sent: Tuesday, October 30, 2018 2:19 PM
To: Mark Nottingham <[e-mail]>
Cc: IETF QUIC WG <[e-mail]>
Subject: Re: Identifying our deliverables

> On Oct 27, 2018, at 5:30 PM, Mark Nottingham <[e-mail]> wrote:
> 
> 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.

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