Re: [QUIC] h2 mapping - extensions

[Jana Iyengar <[e-mail]>]

On Mon, Nov 7, 2016 at 11:34 AM, Patrick McManus <[e-mail]>
wrote:

>
>
> 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 :)
>

Gotcha. I think it makes sense to limit to QUIC and TCP at the moment since
there is a proposal to run HTTP over these, until such a time as there is a
need to define over another transport (let's call it Essy Transport
Protocol, you know, EssyTP). I suspect at that point the httpbis wg (hey,
that's you! :-)) can figure out how to define extensions over the other
transport.

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 :)
>

Ah, sorry -- my grasp of which things are extensions and which ones not in
HTTP-land is weak. I think compression is likely to be one of those things
that is different in QUIC than in HTTP/2.

>
>
>> (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?
>

Do you mean an IANA registry? It's probably safest to put these extensions
will be in different namespaces entirely, so yes, if I understand your
question correctly.

- jana


>
> -P
>
>
>