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 <[email protected]> On Behalf Of Magnus Westerlund Sent: Wednesday, January 13, 2021 11:26 AM To: [email protected] Cc: [email protected]; [email protected] 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
smime.p7s
Description: S/MIME cryptographic signature
