RE: HTTP Delays

[Mike Bishop <[e-mail]>]

I agree that those are the options, and my preference is 2 >= 1 > 3.  While 
we've been very deliberate about keeping transport and HTTP in lockstep up to 
this point, we knew we were taking a risk in moving to the update HTTP drafts. 
We thought the risk was worthwhile for the better separation of Semantics from 
HTTP/1.1, and based on the assurances that the HTTP WG docs would be done in 
time for us.  It's not clear they're quite done, but trying to back out the 
change at this point would be riskier than delaying and I really don't want to 
ship HTTP/3 and immediately have its references superseded.

-----Original Message-----
From: QUIC <[e-mail]> On Behalf Of Magnus Westerlund
Sent: Wednesday, January 13, 2021 11:26 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: HTTP Delays

Hi,

I think you summarizes the alternatives correctly.

On Wed, 2021-01-13 at 07:29 -0800, Martin Duke wrote:
> To summarize, I think there are three options:
> 1) Don't publish any RFCs until httpbis-semantics and httpbis-cache are in 
> the
> RFC Ed queue

This will in fact drag documents not dependent on HTTP into this missref 
tangle.
I note that the document that normatively depend on draft-ietf-quic-transport
are these:
https://datatracker.ietf.org/doc/draft-ietf-quic-transport/referencedby/


Only one appear to be in immediate risk of ending up in missref:

https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-importer/
(In IESG evaluation)

Then I think we have a couple of WG documet that is still in their respective
WGs.
https://datatracker.ietf.org/doc/draft-ietf-quic-datagram/

https://datatracker.ietf.org/doc/draft-ietf-quic-applicability/

https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/

https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc7983bis/

So it isn't a massive tangle.

But, unless we think the HTTP semantics changes would spread back through 
HTTP/3
and QPAC docs why we need to hold the core QUIC protocol from publication.


> 2) Publish QUIC ASAP without HTTP/3, and suggest that deployed endpoints run
> QUICv1 with ALPN h3-29/32/34 or whatever

I personally think this is the best compromise with what I have heard so far.

> 3) Publish QUIC and HTTP/3 ASAP with a downref, allow ALPN h3 to deploy, and
> hope nothing important changes in the httpbis docs.

I very hesitant to do this. As just this week there was a PR into the QUIC 
HTTP
doc to align with changes in the HTTP specs. These are editorial but to fix
these when the RFC has been published it requires a new RFC. While editorial
alignment to language is something we can live with in AUTH48.


>
> The second sounds cleanest to me, but I can certainly be persuaded of the
> others.
> >

We appear to share views here. But I do like to hear additional input. And 
also
maybe some planning for what we do version indication of the interim version 
if
that should be h-34 or what?

Cheers

Magnus Westerlund