Re: [QUIC] Choice of area (and scope of work)

I think a simple sentence in the paragraph discussing the third focus area would suffice. Something such as:

“This mapping will accommodate the extension mechanisms defined in the HTTP/2 specification.”

Lucas

From: Ian Swett [mailto:ianswett@google.com]
Sent: 24 May 2016 16:54
To: Lucas Pardue <Lucas.Pardue@bbc.co.uk>
Cc: Mark Nottingham <mnot@mnot.net>; Martin Thomson <martin.thomson@gmail.com>; Ted Hardie <ted.ietf@gmail.com>; Julian F. Reschke <julian.reschke@gmx.de>; Cory Benfield <cory@lukasa.co.uk>; Christian Huitema <huitema@microsoft.com>; Jana Iyengar <jri@google.com>; quic@ietf.org
Subject: Re: [QUIC] Choice of area (and scope of work)

All streams guarantee in order delivery, so HTTP/2 extension frames could be sent on a different stream if desired.

QUIC definitely needs to be able to accommodate extensions to H2, otherwise it's not really supporting H2.  That could be stated explicitly if it's important to clarify?

On Tue, May 24, 2016 at 11:37 AM, Lucas Pardue <Lucas.Pardue@bbc.co.uk<mailto:Lucas.Pardue@bbc.co.uk>> wrote:
Bringing this back to the original topic - the charter - is it worth adding text to indicate that the scope of third focus area work includes the ability to accommodate extensions to HTTP/2. If it is possible to achieve this by specifying simple reusable recipes for the blocking and non-blocking cases, then so much the better. Otherwise, each new extension will need to explicitly specify the required mappings to h2c/h2 and h2q.

Ryan has made a suggestion to send HTTP/2 extension frames on the QUIC Headers stream (stream 3). It seems sub-optimal to mix such frames, which will be dropped if unknown/unsupported, with the HEADERS frames. Could such frames be sent on other streams, and can other streams provide in-order guarantees as Martin seems to suggest?

Lucas

> -----Original Message-----
> From: QUIC [mailto:quic-bounces@ietf.org<mailto:quic-bounces@ietf.org>] On Behalf Of Mark Nottingham
> Sent: 24 May 2016 02:28
> To: Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>>
> Cc: Ted Hardie <ted.ietf@gmail.com<mailto:ted.ietf@gmail.com>>; Julian F. Reschke
> <julian.reschke@gmx.de<mailto:julian.reschke@gmx.de>>; Ian Swett <ianswett@google.com<mailto:ianswett@google.com>>; Cory Benfield
> <cory@lukasa.co.uk<mailto:cory@lukasa.co.uk>>; Christian Huitema <huitema@microsoft.com<mailto:huitema@microsoft.com>>; Jana
> Iyengar <jri@google.com<mailto:jri@google.com>>; quic@ietf.org<mailto:quic@ietf.org>
> Subject: Re: [QUIC] Choice of area (and scope of work)
>
>
> > On 24 May 2016, at 6:27 AM, Martin Thomson
> <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>> wrote:
> >
> > On 23 May 2016 at 16:03, Jana Iyengar <jri@google.com<mailto:jri@google.com>> wrote:
> >> By extension, HTTP/2 extensions will by default extend h2 and not
> >> h2q, and may rely on TCP underneath. As a rule, I think we have to
> >> assume that they'll need to explicitly map to QUIC.
> >
> > I think that this is the safest assumption.  Extensions for "h2" don't
> > immediately port to "h2q".
> >
> > That said, we do have in order guarantees on both stream 3 and stream
> > N, so maybe, just maybe, there is a simple set of guidelines we can
> > produce that will be generally applicable to most, if not all,
> > extensions.
>
> +1. We should be looking at how we can minimise the differences wherever
> possible.
>
> --
> Mark Nottingham   https://www.mnot.net/
>
> _______________________________________________
> QUIC mailing list
> QUIC@ietf.org<mailto:QUIC@ietf.org>
> https://www.ietf.org/mailman/listinfo/quic