Re: HTTP Delays

"Roy T. Fielding" <fielding@gbiv.com> Wed, 13 January 2021 18:29 UTC

Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Subject: Re: HTTP Delays
From: "Roy T. Fielding" <fielding@gbiv.com>
In-Reply-To: <CAM4esxQeFaYytwyeB+m_yDrn8SSR8Yy4BHTsvxngTjG3=y0Zag@mail.gmail.com>
Date: Wed, 13 Jan 2021 10:29:03 -0800
Cc: Magnus Westerlund <magnus.westerlund@ericsson.com>, "ted.ietf@gmail.com" <ted.ietf@gmail.com>, "quic@ietf.org" <quic@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4459A34C-ED70-4354-9653-BA5165EC887A@gbiv.com>
References: <CAM4esxSObWwLfzRWazAg+Q+9=BHGzXaSSduONozHF_zGCqC-kg@mail.gmail.com> <CA+9kkMA++3QYnXiVwuKSPZDYycERRrC11b-jHTG6JcyjngDhqA@mail.gmail.com> <CAM4esxQ9w0h2-rZ1ynhEMKAxwq0gfSVJtfGXV8ydGdUTEefMuA@mail.gmail.com> <029bd6e66fb81e2ecf16e35adf30b90c816c9962.camel@ericsson.com> <CAM4esxQeFaYytwyeB+m_yDrn8SSR8Yy4BHTsvxngTjG3=y0Zag@mail.gmail.com>
To: Martin Duke <martin.h.duke@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/CWJ7JA9ZYT2erojdsG7lntVKCNQ>
Precedence: list

> On Jan 13, 2021, at 7:29 AM, Martin Duke <martin.h.duke@gmail.com> 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

HTTP Delays Martin Duke
Re: HTTP Delays Ted Hardie
Re: HTTP Delays Julian Reschke
Re: HTTP Delays Martin Duke
Re: HTTP Delays Martin Duke
Re: HTTP Delays Julian Reschke
Re: HTTP Delays Martin Thomson
Re: HTTP Delays Martin Duke
Re: HTTP Delays Magnus Westerlund
Re: HTTP Delays Martin Duke
Re: HTTP Delays Magnus Westerlund
RE: HTTP Delays Mike Bishop
Re: HTTP Delays Roy T. Fielding
Re: HTTP Delays Ted Hardie
Re: HTTP Delays Martin Duke
Re: HTTP Delays Julian Reschke
Re: HTTP Delays Magnus Westerlund
Re: HTTP Delays Julian Reschke
Re: HTTP Delays Martin Duke
Re: HTTP Delays Ian Swett
Re: HTTP Delays Roy T. Fielding
Re: HTTP Delays Julian Reschke