Re: HTTP Delays

[Martin Duke <[e-mail]>]

Maybe there is an option 4 to add to the other 3
<https://mailarchive.ietf.org/arch/msg/quic/N8h5QwRX11N1gAzU3CXAel3zil0/>?

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.

4) Publish QUIC RFCs ASAP, advertise ALPN h3 in deployments, let HTTP/3 sit
in the Ed queue till httpbis catches up.

If HTTP/3 is functionally stable, this would allow real-world deployment to
continue while letting the HTTP/3 RFC use the final terminology, etc.

On Thu, Jan 14, 2021 at 5:54 AM Magnus Westerlund <magnus.westerlund=
[e-mail]> wrote:

> Hi,
>
> On Wed, 2021-01-13 at 20:06 +0100, Julian Reschke wrote:
> > Am 13.01.2021 um 19:55 schrieb Ted Hardie:
> > > ...
> > > 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.]
> > > ...
> >
> > Maybe we need a separate discussion about easily (or even
> > semi-automatically) updating published RFCs when their downrefs become
> RFCs.
>
> Which isn't done at all. The main body of the RFC when published is
> inmutable.
> Thus, if you want to align any language changes or anything with the new
> HTTP
> specs when going for do a "downref" means a new RFC.
>
> That is why I didn't understand Roy's comment:
>
> > 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.
>
> What you can do is do a last alignment in AUTH48 with the status of HTTP
> semantics and cache at this point. If we want the rfc numbers of the HTTP
> specs,
> then you have to wait until they are ready and also in AUTH48. So, if the
> HTTP
> semantics and cache aren't ready when we come to AUTH48 you still have the
> risk
> of missalignment if going down the downref path.
>
> I would like to point out that just this week a PR was merged to the
> HTTP/3 spec
> to align with the latest changes done in the HTTP semantics. So the risk
> for
> missalignment is not zero here. Sure the HTTP specs are mature, but you can
> still end up in a situation where it becomes hard to interpret HTTP/3
> correctly
> when section numbering and terms don't align.
>
> This might be primarily directed to Ted. However, I don't understand how we
> could do a downref in this case when we have a normative reference to a
> IETF
> draft. This case is not the type of downref that RFC 3967 discusses, where
> the
> normatively referenced document is an lower maturity (Informational or
> Experimental) RFC or an external document. So I want to understand what
> process
> diviation Ted really had in mind when he suggested this?
>
> Sorry to be a damper, but I don't see we can do Option 3) within our
> process
> without violating our process.
>
> Cheers
>
> Magnus Westerlund
> Responsible AD
>