> 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, 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. Either that, or build a time machine and fix 2020. ....Roy
