Subject: HTTP Delays

From: Martin Duke <[email-masked]>
Date: Mon, 11 Jan 2021 12:56:41 -0800

I was disappointed to realize that quic-http has two normative references
(httpbis-cache and https-semantics) that are not even in WGLC.

This suggests that there will be significant delay (best case, months)
between QUIC and HTTP/3 finalizing as RFCs.

How are we to handle deployment of this? Will there be endpoints operating
QUICv1 with h3-29 or h3-32? Or have the chairs cooked up a maneuver to
avoid this problem?

Martin

---

From: Ted Hardie <[email-masked]>
Date: Mon, 11 Jan 2021 13:03:50 -0800

Hi Martin,

The easiest way to handle this would be to have those included in the
downref registry.  That would allow the documents to proceed with a
reference to the drafts, rather than the final RFCs.  If the ADs are
confident that the -chache and -semantics will not change the elements that
are referenced by QUIC, then a second last call that highlights that point
(and basically nothing else) will unstick this.

As someone has been waiting for cluster 238 for quite a while now, I am a
big fan of not trying to wait until everything can go lockstep.  The
benefits have definitely not outweighed the costs for C238, and I don't
think they would here.  Downref it and go on with publication.

Just my opinion, of course.

regards,

Ted

---

From: Julian Reschke <[email-masked]>
Date: Mon, 11 Jan 2021 22:13:07 +0100

Am 11.01.2021 um 21:56 schrieb Martin Duke:
> I was disappointed to realize that quic-http has two normative
> references (httpbis-cache and https-semantics) that are not even in WGLC.

We are trying to get to WGLC in the next few days.

> between QUIC and HTTP/3 finalizing as RFCs.

In theory, once all of the specs are in the RFC Editor Queue, the IESG
could ask the RPC nicely to fast-track the HTTP specs so that they do
not delay the QUIC specs.

 > ...

Best regards, Julian

---

From: Martin Duke <[email-masked]>
Date: Tue, 12 Jan 2021 07:43:20 -0800

Ted,

This would be great. However, though I'm not an expert at all,
http-semantics is deeply integrated into quic-http, and at 200+ pages is
reasonably likely to have a small edit here and there. I'm skeptical we can
ship HTTP/3 without this anchor firmly lodged.

But I'm happy to be corrected by people with more knowledge of both
documents!

On Mon, Jan 11, 2021 at 1:04 PM Ted Hardie <[email-masked]> wrote:

>> How are we to handle deployment of this? Will there be endpoints
>> operating QUICv1 with h3-29 or h3-32? Or have the chairs cooked up a
>> maneuver to avoid this problem?
>>
>> Martin
>>
>

---

From: Martin Duke <[email-masked]>
Date: Tue, 12 Jan 2021 07:44:12 -0800

Hi Julian,

I believe the intent was to request expedited processing on the QUIC docs.
Maybe that doesn't make any sense if we're waiting for HTTP/3 -- or maybe
we'll ship one without the other. That's what I'm waiting to clarify.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 12 Jan 2021 18:17:52 +0100

Am 12.01.2021 um 16:44 schrieb Martin Duke:
> Hi Julian,
>
> I believe the intent was to request expedited processing on the QUIC
> docs. Maybe that doesn't make any sense if we're waiting for HTTP/3 --
> or maybe we'll ship one without the other. That's what I'm waiting to
> clarify.

Hmmm. quic-tls has an informative reference to quic-http.

Best regards, Julian

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 13 Jan 2021 10:58:07 +1100

> Hmmm. quic-tls has an informative reference to quic-http.

That can be excised.

---

From: Martin Duke <[email-masked]>
Date: Tue, 12 Jan 2021 16:14:58 -0800

I don't believe an informative reference matters.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 13 Jan 2021 10:41:10 +0000

Hi,

My current judgment is also that this will result in that the HTTP/3 and QPACK
specs will end up in missref due to these references. I don't think there is an
good option. The new HTTP specs are substantial rewrites so going back to RFC
723x doesn't make sense here, and likely include substantial amount of work.

I do think the WG do need to be clear if the message is to stay with the the
prelimenary versions, if that is h-29 or declare a h-34 based on the forthcoming
-34 versions and what to do with salts and keys. 

Cheers

Magnus

---

From: Martin Duke <[email-masked]>
Date: Wed, 13 Jan 2021 07:29:47 -0800

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.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 13 Jan 2021 16:25:58 +0000

Hi,

I think you summarizes the alternatives correctly. 

On Wed, 2021-01-13 at 07:29 -0800, Martin Duke wrote:
> 1) Don't publish any RFCs until httpbis-semantics and httpbis-cache are in the
> RFC Ed queue

This will in fact drag documents not dependent on HTTP into this missref tangle.
I note that the document that normatively depend on draft-ietf-quic-transport
are these:
https://datatracker.ietf.org/doc/draft-ietf-quic-transport/referencedby/

Only one appear to be in immediate risk of ending up in missref:

https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-importer/
(In IESG evaluation)

Then I think we have a couple of WG documet that is still in their respective
WGs. 
https://datatracker.ietf.org/doc/draft-ietf-quic-datagram/

https://datatracker.ietf.org/doc/draft-ietf-quic-applicability/

https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsoquic/

https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc7983bis/

So it isn't a massive tangle. 

But, unless we think the HTTP semantics changes would spread back through HTTP/3
and QPAC docs why we need to hold the core QUIC protocol from publication. 

> 2) Publish QUIC ASAP without HTTP/3, and suggest that deployed endpoints run
> QUICv1 with ALPN h3-29/32/34 or whatever

I personally think this is the best compromise with what I have heard so far. 

> 3) Publish QUIC and HTTP/3 ASAP with a downref, allow ALPN h3 to deploy, and
> hope nothing important changes in the httpbis docs.

I very hesitant to do this. As just this week there was a PR into the QUIC HTTP
doc to align with changes in the HTTP specs. These are editorial but to fix
these when the RFC has been published it requires a new RFC. While editorial
alignment to language is something we can live with in AUTH48. 

> The second sounds cleanest to me, but I can certainly be persuaded of the

We appear to share views here. But I do like to hear additional input. And also
maybe some planning for what we do version indication of the interim version if
that should be h-34 or what? 

Cheers

Magnus Westerlund

---

From: Mike Bishop <[email-masked]>
Date: Wed, 13 Jan 2021 16:38:15 +0000

I agree that those are the options, and my preference is 2 >= 1 > 3.  While 
we've been very deliberate about keeping transport and HTTP in lockstep up to 
this point, we knew we were taking a risk in moving to the update HTTP drafts. 
We thought the risk was worthwhile for the better separation of Semantics from 
HTTP/1.1, and based on the assurances that the HTTP WG docs would be done in 
time for us.  It's not clear they're quite done, but trying to back out the 
change at this point would be riskier than delaying and I really don't want to 
ship HTTP/3 and immediately have its references superseded.

-----Original Message-----
From: QUIC <[email-masked]> On Behalf Of Magnus Westerlund
Sent: Wednesday, January 13, 2021 11:26 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: HTTP Delays

Hi,

On Wed, 2021-01-13 at 07:29 -0800, Martin Duke wrote:
> the

This will in fact drag documents not dependent on HTTP into this missref 
tangle.
I note that the document that normatively depend on draft-ietf-quic-transport
are these:
https://datatracker.ietf.org/doc/draft-ietf-quic-transport/referencedby/

But, unless we think the HTTP semantics changes would spread back through 
HTTP/3
and QPAC docs why we need to hold the core QUIC protocol from publication.

> hope nothing important changes in the httpbis docs.

I very hesitant to do this. As just this week there was a PR into the QUIC 
HTTP
doc to align with changes in the HTTP specs. These are editorial but to fix
these when the RFC has been published it requires a new RFC. While editorial
alignment to language is something we can live with in AUTH48.

> The second sounds cleanest to me, but I can certainly be persuaded of the

We appear to share views here. But I do like to hear additional input. And 
also
maybe some planning for what we do version indication of the interim version 
if
that should be h-34 or what?

Cheers

Magnus Westerlund

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 13 Jan 2021 10:29:03 -0800

> On Jan 13, 2021, at 7:29 AM, Martin Duke <[email-masked]> wrote:
> 
> 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

---

From: Ted Hardie <[email-masked]>
Date: Wed, 13 Jan 2021 10:55:22 -0800

I largely agree with Roy here, with one caveat, in-line below

On Wed, Jan 13, 2021 at 10:29 AM Roy T. Fielding <[email-masked]> wrote:

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

---

From: Martin Duke <[email-masked]>
Date: Wed, 13 Jan 2021 11:00:07 -0800

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 <[email-masked]> wrote:

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

---

From: Julian Reschke <[email-masked]>
Date: Wed, 13 Jan 2021 20:06:46 +0100

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.

Best regards, Julian

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 14 Jan 2021 13:53:53 +0000

Hi,

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

> 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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 14 Jan 2021 15:45:58 +0100

> specs when going for do a "downref" means a new RFC.

I understand that this is the current state of things - but it might
makes sense to discuss in the context of other conversations we'll
hopefully have about RFC "immutability".

(and yes, that doesn't help with the current problem)

Best regards, Julian

---

From: Martin Duke <[email-masked]>
Date: Thu, 14 Jan 2021 09:24:43 -0800

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

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.

---

From: Ian Swett <[email-masked]>
Date: Thu, 14 Jan 2021 12:31:57 -0500

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

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

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 14 Jan 2021 15:31:17 -0800

> On Jan 14, 2021, at 5:53 AM, Magnus Westerlund <magnus.westerlund=[email-masked]> wrote:
> 

I meant that the HTTP/3 draft would remain in the queue (done but not
published except on the WG site) until its normative references can also
be published as RFCs. That does not prevent implementations from
deploying the protocols as specified. I guess that matches choice (4).

> when section numbering and terms don't align. 

Right, but we did that editorial change deliberately because all five
HTTP specs can align on terminology, knowing full well that this is
a change we can do right now (and probably not after). We might
want to make additional changes around how [HTTP11] is referenced
by HTTP/3, but this would also be to align the specs while we still can.

I am pretty sure that none of us will want to make such editorial
changes once alignment is no longer possible.  Julian even has
a script to check that we haven't broken xrefs from HTTP3.

Cheers,

....Roy

---

From: Julian Reschke <[email-masked]>
Date: Fri, 15 Jan 2021 08:00:53 +0100

> maneuver to avoid this problem?

For those not on the httpbis WG's mailing list: the HTTP core specs are
now in WGLC (see
<https://lists.w3.org/Archives/Public/ietf-http-wg/2021JanMar/0015.html>).

Best regards, Julian