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

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

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