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

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 <Lucas.Pardue@bbc.co.uk>
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
>
>
>
> [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
>
>
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org
> https://www.ietf.org/mailman/listinfo/quic
>
>