If the HTTP experts all agree that there will be no changes to the httpbis documents that affect HTTP/3 implementations at all, then I would be fine with option 3 (publish all drafts ASAP with downrefs as necessary).
Although I wonder if SECDIR review might alter a security recommendation in some tangible way.... My only concern is that the 'h3' ALPN not be ambiguous due to a late change. On Wed, Jan 13, 2021 at 10:55 AM Ted Hardie <[email protected]> wrote: > I largely agree with Roy here, with one caveat, in-line below > > On Wed, Jan 13, 2021 at 10:29 AM Roy T. Fielding <[email protected]> > wrote: > >> > On Jan 13, 2021, at 7:29 AM, Martin Duke <[email protected]> >> 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 >> > 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. >> > >> > The second sounds cleanest to me, but I can certainly be persuaded of >> the others. >> >> This doesn't make any sense to me. HTTP is a mature protocol and >> it simply doesn't matter to the protocol implementations whether >> the xrefs line up to the correct section in an RFC. The wire definitions >> don't change. There is no risk that the protocol will change because >> of HTTP specification changes. >> >> HTTP/3 doesn't have any normative dependencies on the attributes >> of Semantics other than to QPACK, which itself is not based on any >> normative rules of HTTP other than field values being strings. All >> of the late edits have been for editorial cleanliness. >> >> Likewise, even if HTTP Semantics were fixed in stone RFC tablets, >> the protocol is extensible on the wire and HTTP/3 has to carry that >> extensibility whether or not it is defined by an RFC. >> >> 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. The IETF can preassign the new RFC numbers >> for HTTP Semantics, Cache, and HTTP/1.1 at any time and use those >> numbers for publication of QUIC and HTTP/3, > > > 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.] > > or the entire set can >> sit in the queue for a few weeks (finished and implementable) while >> the RFC editor works on HTTP Semantics and Cache. >> > > I think they are implementable with the current drafts and that care in > changes during any final edits will ensure that they will remain so. This > is why I support the downref theory. > > But this is my personal opinion, and it should definitely be considered in > light of my personal scarring with the current procedures. > > Ted > > >> >> Either that, or build a time machine and fix 2020. >> >> ....Roy >> >>
