Re: HTTP Delays

[Ted Hardie <[e-mail]>]

I largely agree with Roy here, with one caveat, in-line below

On Wed, Jan 13, 2021 at 10:29 AM Roy T. Fielding <[e-mail]> wrote:

> > On Jan 13, 2021, at 7:29 AM, Martin Duke <[e-mail]>
> 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
>
>