Re: HTTP Delays

[Ian Swett <[e-mail]>]

On Thu, Jan 14, 2021 at 12:25 PM Martin Duke <[e-mail]>
wrote:

> 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.
>

I was thinking of suggesting this, but wanted to see how the other options
played out.  I sort of expect this is what might naturally occur if you
attempted to do 2.

It seems like 4 gives deployments what they want and satisfies the
constraints of the RFC process, so I'm happy with it.

>
> 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
>>
>