Subject: ALT_SVC HTTP/3 Frame?

From: Ryan Hamilton <[email-masked]>
Date: Wed, 18 Sep 2019 13:02:21 -0700

Howdy Folks,

I'm trying to understand the state of the ALT_SVC frame in HTTP/3. It is
not explicitly defined in the HTTP/3 draft, as far as I can tell. However,
A.2.3 says

... frame type HTTP/2 extensions are typically portable to QUIC simply by
replacing Stream 0 in HTTP/2 with a control stream in HTTP/3.

Does this mean that I can send an HTTP/3 frame with type 0xa
<https://tools.ietf.org/html/rfc7838#section-4> on the HTTP/3 control
stream with the payload:

    +-------------------------------+-------------------------------+
    |         Origin-Len (16)       | Origin? (*)                 ...
    +-------------------------------+-------------------------------+
    |                   Alt-Svc-Field-Value (*)                   ...
    +---------------------------------------------------------------+

Do I have that right?

Cheers,

Ryan

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 18 Sep 2019 21:21:10 +0100

Hi Ryan,

Mike actually has an expired draft for this [1] dating back to 2017. The
code point (0xA) is the same, we've been careful to avoid the H3 frames
colliding.

Maybe time to dust the ID off..

Lucas

[1] - https://tools.ietf.org/html/draft-bishop-httpbis-altsvc-quic-00

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 18 Sep 2019 14:51:10 -0700

Howdy,

Ah, great! That helps. That being said, I think I'm not clear on what the
language in A.2.3 means. Is it saying:
1) "Hey, when you get around to specifying an HTTP/3-specific version of an
HTTP/2 frame type extension is should be pretty easy"
2) Or, "HTTP/2 extensions are translated to HTTP/3 like this."

Given Mike's draft, I'm guessing it's 2? If so it might make sense to
clarify A.2.3?

Cheers,

Ryan

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 18 Sep 2019 23:22:25 +0100

I think in the last 2 years we've gained a better understanding of what
HTTP/3 is, how it varies from HTTP/2 and can tighten up the language. I'll
let Mike answer for his own doc though.

Lucas

On Wed, 18 Sep 2019, 22:51 Ryan Hamilton, <[email-masked]> wrote:

> 1) "Hey, when you get around to specifying an HTTP/3-specific version of
> an HTTP/2 frame type extension is should be pretty easy"
>>> ... frame type HTTP/2 extensions are typically portable to QUIC simply
>>> by replacing Stream 0 in HTTP/2 with a control stream in HTTP/3.
>>>
>>>

---

From: Mike Bishop <[email-masked]>
Date: Thu, 26 Sep 2019 18:15:11 +0000

The language in A.2.3 is talking about what is involved in porting an HTTP/2 extension to HTTP/3.  In A.2.4 it says, “Frame types defined by extensions to HTTP/2 need to be separately registered for HTTP/3 if still applicable.”  Perhaps that sentence should be in A.2.3 instead.

From: QUIC <[email-masked]> On Behalf Of Lucas Pardue
Sent: Wednesday, September 18, 2019 6:22 PM
To: Ryan Hamilton <[email-masked]>
Cc: QUIC WG <[email-masked]>
Subject: Re: ALT_SVC HTTP/3 Frame?

I think in the last 2 years we've gained a better understanding of what HTTP/3 is, how it varies from HTTP/2 and can tighten up the language. I'll let Mike answer for his own doc though.

Lucas

On Wed, 18 Sep 2019, 22:51 Ryan Hamilton, <[email-masked]<mailto:[email-masked]>> wrote:
Howdy,

Ah, great! That helps. That being said, I think I'm not clear on what the language in A.2.3 means. Is it saying:
1) "Hey, when you get around to specifying an HTTP/3-specific version of an HTTP/2 frame type extension is should be pretty easy"
2) Or, "HTTP/2 extensions are translated to HTTP/3 like this."

Given Mike's draft, I'm guessing it's 2? If so it might make sense to clarify A.2.3?

Cheers,

Ryan

On Wed, Sep 18, 2019 at 1:21 PM Lucas Pardue <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ryan,

Mike actually has an expired draft for this [1] dating back to 2017. The code point (0xA) is the same, we've been careful to avoid the H3 frames colliding.
Maybe time to dust the ID off..

Lucas

On Wed, Sep 18, 2019 at 9:03 PM Ryan Hamilton <rch=[email-masked]<mailto:[email-masked]>> wrote:
Howdy Folks,

I'm trying to understand the state of the ALT_SVC frame in HTTP/3. It is not explicitly defined in the HTTP/3 draft, as far as I can tell. However, A.2.3 says

... frame type HTTP/2 extensions are typically portable to QUIC simply by replacing Stream 0 in HTTP/2 with a control stream in HTTP/3.

Does this mean that I can send an HTTP/3 frame with type 0xa<https://tools.ietf.org/html/rfc7838#section-4> on the HTTP/3 control stream with the payload:

    +-------------------------------+-------------------------------+
    |         Origin-Len (16)       | Origin? (*)                 ...
    +-------------------------------+-------------------------------+
    |                   Alt-Svc-Field-Value (*)                   ....
    +---------------------------------------------------------------+

Do I have that right?

Cheers,

Ryan

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 27 Sep 2019 10:05:30 +1000

On Fri, Sep 27, 2019, at 04:15, Mike Bishop wrote:
> The language in A.2.3 is talking about what is involved in porting an 
> HTTP/2 extension to HTTP/3. In A.2.4 it says, “Frame types defined by 
> extensions to HTTP/2 need to be separately registered for HTTP/3 if 
> still applicable.” Perhaps that sentence should be in A.2.3 instead.

Maybe this is something that should be on the body of the document, and with a MUST.