Maybe there is an option 4 to add to the other 3 <https://mailarchive.ietf.org/arch/msg/quic/N8h5QwRX11N1gAzU3CXAel3zil0/>?
1) Don't publish any RFCs until httpbis-semantics and httpbis-cache are in the RFC Ed queue 2) Publish QUIC ASAP without HTTP/3, and suggest that deployed endpoints run QUICv1 with ALPN h3-29/32/34 or whatever 3) Publish QUIC and HTTP/3 ASAP with a downref, allow ALPN h3 to deploy, and hope nothing important changes in the httpbis docs. 4) Publish QUIC RFCs ASAP, advertise ALPN h3 in deployments, let HTTP/3 sit in the Ed queue till httpbis catches up. If HTTP/3 is functionally stable, this would allow real-world deployment to continue while letting the HTTP/3 RFC use the final terminology, etc. On Thu, Jan 14, 2021 at 5:54 AM Magnus Westerlund <magnus.westerlund= [email protected]> wrote: > Hi, > > On Wed, 2021-01-13 at 20:06 +0100, Julian Reschke wrote: > > Am 13.01.2021 um 19:55 schrieb Ted Hardie: > > > ... > > > While they could theoretically pre-assign it, the RFC Editor won't > > > publish the document without the documents actually being available for > > > retrieval. That's a big reason you get clusters. This is why we do > > > downrefs to the drafts; since there is an onward pointer from the > > > referenced draft to the final RFC in the tools, that's considered okay > > > as anyone who seriously wants the reference can readily find it. > [Note: > > > my opinion on that is separate from my recitation of what I think the > > > facts are.] > > > ... > > > > Maybe we need a separate discussion about easily (or even > > semi-automatically) updating published RFCs when their downrefs become > RFCs. > > Which isn't done at all. The main body of the RFC when published is > inmutable. > Thus, if you want to align any language changes or anything with the new > HTTP > specs when going for do a "downref" means a new RFC. > > That is why I didn't understand Roy's comment: > > > In short, there's no need to be pedantic. As soon as the QUIC RFCs > > enter the RFC ed queue, we can fix their content as such including > > the final protocol versions and ALPNs. If the HTTP Semantics spec > > needs additional changes, we can choose those changes deliberately > > without impacting any content or references within HTTP/3. We don't > > xref by page number. > > What you can do is do a last alignment in AUTH48 with the status of HTTP > semantics and cache at this point. If we want the rfc numbers of the HTTP > specs, > then you have to wait until they are ready and also in AUTH48. So, if the > HTTP > semantics and cache aren't ready when we come to AUTH48 you still have the > risk > of missalignment if going down the downref path. > > I would like to point out that just this week a PR was merged to the > HTTP/3 spec > to align with the latest changes done in the HTTP semantics. So the risk > for > missalignment is not zero here. Sure the HTTP specs are mature, but you can > still end up in a situation where it becomes hard to interpret HTTP/3 > correctly > when section numbering and terms don't align. > > This might be primarily directed to Ted. However, I don't understand how we > could do a downref in this case when we have a normative reference to a > IETF > draft. This case is not the type of downref that RFC 3967 discusses, where > the > normatively referenced document is an lower maturity (Informational or > Experimental) RFC or an external document. So I want to understand what > process > diviation Ted really had in mind when he suggested this? > > Sorry to be a damper, but I don't see we can do Option 3) within our > process > without violating our process. > > Cheers > > Magnus Westerlund > Responsible AD >
