Re: HTTP Delays

[Martin Duke <[e-mail]>]

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 <[e-mail]> 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 <[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
>>
>>