Re: [QUIC] h2 mapping - extensions

[Patrick McManus <[e-mail]>]

On Mon, Nov 7, 2016 at 2:26 PM, Jana Iyengar <[e-mail]> wrote:

> On Thu, Nov 3, 2016 at 2:39 PM, Patrick McManus <[e-mail]>
> wrote:
>
>> Hi Robbie, Mike, et al. Thanks for getting the ball rolling with
>> https://tools.ietf.org/html/draft-shade-quic-http2-mapping-00..
>>
>> What is the thinking about rfc 7540 h2 extensions and the h2/quic
>> mapping.. particularly the way it allows unspecified frame types which may
>> or may not require negotiation.
>>
>> it seems some of these extensions may have stateful issues across
>> streams, ala hpack and some may not.
>>
>> If the extension were only defined for h2-over-quic that would be for the
>> extension to sort out.. but it doesn't seem like we are limiting things to
>> quic vs tcp, or are we?
>>
>
> Not sure what you mean by not limiting things to QUIC vs. TCP -- do you
> have a different mapping in mind?
>


I meant explicitly scoping h2 extensions so that they only apply to quic
and/or tcp.. and it does seem like that's what you mean :)


>
> My sense is that we'll need to
> (i) define how current extensions will work with QUIC (eg, HPACK), and
>

fwiw HPACK/QPACK is not an extension and you can't define it as one in quic
because it would need to be negotiated and that's going to break the 0RTT
goal of the protocol. I don't think that's a problem though as there is no
need to make it an extension :)


> (ii) require that future extensions be defined explicitly  for both TCP
> and QUIC.
>

So the mapping document will need to establish a new h2 extension registry?

-P