Subject: [QUIC] Supporting HTTP/2 extension: frames and semantics

From: Lucas Pardue <[email-masked]>
Date: Fri, 20 May 2016 15:22:41 +0000

Hello,

I would like to gain further clarification on the mapping of HTTP/2 frames in QUIC, especially with regards to extension via new frame types. Is it anticipated that HTTP/2 extension frame types will be supported in QUIC and is there a feeling about how that would be defined?

Previous QUIC documents have covered how to map HTTP/2 frame types such as HEADERS or DATA, however there was little explanation of how something like the ALTSVC frame [1] would be supported in QUIC (if at all). In the specific case of HTTP Alternative Services we can fallback on the header field crutch and use Alt-Svc to express the same service detail within a HEADERS frame. However, this does not hold true for other extensions such as the ORIGIN frame [2].

I am also interested in understanding how QUIC might handle HTTP semantic extension such as proposed in the Peer-to-Peer Extension to HTTP/2 [3].

Lucas

[1] https://tools.ietf.org/html/rfc7838
[2] https://datatracker.ietf.org/doc/draft-ietf-httpbis-origin-frame/
[3] https://tools.ietf.org/html/draft-benfield-http2-p2p

---

From: Ryan Hamilton <[email-masked]>
Date: Fri, 20 May 2016 14:07:40 -0700

I don't know that we yet have an answer to this question. I suspect that
the third focus area will resolve this issue. That being said, the simplest
solution would be to deliver these HTTP/2 frames on the QUIC Headers Stream
since that is already processing HTTP/2 frames.

On Fri, May 20, 2016 at 8:22 AM, Lucas Pardue <[email-masked]>
wrote:

> Hello,
>
>
>
> I would like to gain further clarification on the mapping of HTTP/2 frames
> in QUIC, especially with regards to extension via new frame types. Is it
> anticipated that HTTP/2 extension frame types will be supported in QUIC and
> is there a feeling about how that would be defined?
>
>
>
> Previous QUIC documents have covered how to map HTTP/2 frame types such as
> HEADERS or DATA, however there was little explanation of how something like
> the ALTSVC frame [1] would be supported in QUIC (if at all). In the
> specific case of HTTP Alternative Services we can fallback on the header
> field crutch and use Alt-Svc to express the same service detail within a
> HEADERS frame. However, this does not hold true for other extensions such
> as the ORIGIN frame [2].
>
>
>
> I am also interested in understanding how QUIC might handle HTTP semantic
> extension such as proposed in the Peer-to-Peer Extension to HTTP/2 [3].
>
>
>
> Lucas
>
>
>
> _______________________________________________
> QUIC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/quic
>
>

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 23 May 2016 14:32:00 +1000

+1; I share this concern. There are a growing number of H2 extensions that are either in progress [1] or coming [2][3]; it would be good to avoid too much of a mess here.

The same question arises for SETTINGSes.

Cheers,

1. https://httpwg.github.io/http-extensions/origin-frame.html
2. https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs
3. https://datatracker.ietf.org/doc/draft-kazuho-h2-cache-digest

> On 21 May 2016, at 1:22 AM, Lucas Pardue <[email-masked]> wrote:
> 
> Hello,
>  

--
Mark Nottingham   https://www.mnot.net/

---

From: Ryan Hamilton <[email-masked]>
Date: Sun, 22 May 2016 21:38:31 -0700

Agreed. Do you have any suggestions for language we could include in the
charter to ensure that this gets addressed satisfactorily?

On Sun, May 22, 2016 at 9:32 PM, Mark Nottingham <[email-masked]> wrote:

> +1; I share this concern. There are a growing number of H2 extensions that
> are either in progress [1] or coming [2][3]; it would be good to avoid too
> much of a mess here.
>
> > I would like to gain further clarification on the mapping of HTTP/2
> frames in QUIC, especially with regards to extension via new frame types.
> Is it anticipated that HTTP/2 extension frame types will be supported in
> QUIC and is there a feeling about how that would be defined?
> >
> > Previous QUIC documents have covered how to map HTTP/2 frame types such
> as HEADERS or DATA, however there was little explanation of how something
> like the ALTSVC frame [1] would be supported in QUIC (if at all). In the
> > I am also interested in understanding how QUIC might handle HTTP
> semantic extension such as proposed in the Peer-to-Peer Extension to HTTP/2
> [3].
> >
> > Lucas
> >