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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to