On Thu, Jan 14, 2021 at 12:25 PM Martin Duke <[email protected]> wrote:
> 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. > I was thinking of suggesting this, but wanted to see how the other options played out. I sort of expect this is what might naturally occur if you attempted to do 2. It seems like 4 gives deployments what they want and satisfies the constraints of the RFC process, so I'm happy with it. > > 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 >> >
