Re: HTTP Delays

[Magnus Westerlund <[e-mail]>]

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