Subject: [QUIC] Choice of area

From: Ted Hardie <[email-masked]>
Date: Tue, 17 May 2016 15:14:28 -0700

I've changed the subject on this, since I want to focus on a particular
topic.

Comments in-line:

On Tue, May 17, 2016 at 12:23 PM, Jana Iyengar <[email-masked]> wrote:

> Thanks, Mark. Responses inline:
>
>>  The third focus area will describe mappings between specific
>> applications’ semantics and the transport facilities of QUIC. The first
>> mapping will be a description of HTTP/2 semantics using QUIC, specifically
>> with the goal of minimizing web latency using QUIC. Upon completion of that
>> mapping, additional protocols may be added by updating this charter to
>> include them.
>>
>>
>> Defining application protocols in the Transport area is a pretty big
>> change around here, even if it is just mapping existing semantics to a new
>> transport.
>>
>> As everyone knows, such mappings are "leaky" -- changes under the hood
>> can and will affect how people use the application. We had numerous
>> examples of this in H2, and while QUIC appears to be a more straightforward
>> change in this respect, it's still easy enough to have unintended side
>> effects. HTTP is especially fragile in this regard, because of its
>> complexity, history and breadth of use.
>>
>> Note that I'm not saying I'm firmly against this approach, just
>> concerned; this WG is obviously going to be very deep in transport
>> discussions, and it would be easy to lose the application perspective in it.
>>
>>
I think you're right that this is a serious concern, but my thinking is
that we have this concern either way.  You could avoid that by serializing
the transport work to finish before any mapping started, but that would be
slow.  It would also risk the transport developing without the driving use
case focus that has helped the pre-standards work progress.

If we try to do the mapping work in a different/area working group while
the transport work is still ongoing, we need a very tight coordination
between the two groups throughout the work.  Basically, everyone interested
will have to be in both; given that it will not be the only topic in either
group, that's going to be distracting as well as logistically difficult.

If you're not willing to serialize,  in other words, I think you have to
pick one to have the work.  Given that QUIC will eventually have more than
one mapping, I think it makes sense to do it in a working group focused on
QUIC.  There is no question that a QUIC working group with this charter
would need the eyes of an HTTP-focused set of contributors for this
mapping.  To some extent, that means we're asking the indulgence of the
HTTP-focused community for splitting their attention for a time;
ultimately, though, I think they would have had to do that anyway.

>
> Also, if this WG *is* to do the HTTP/2 mapping, more text about what
> semantics are being mapped would avoid a lot of argument down the road; if
> you say it's "all of them", that includes running HTTP without TLS.
>

I think the intent is to cover HTTP/2 semantics for an encrypted transport,
but further assistance in conveying that would be gratefully received.

> Milestones
>
> It would be helpful to also propose the timing of the milestones, perhaps
> in the form of "date of chartering + n months."
>
> That's a great idea; I didn't want to put in dates when I didn't have a
start date in hand, but we'll try to put a strawman together with that
approach.

regards,

Ted

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 23 May 2016 16:30:14 +1000

Hi Ted,

Thanks, I can see where you (and Jana) are coming from, definitely.

If we assume that the vast bulk of the work is in defining the semantics of the transport (as many have said, building the functionality of TCP on top of UDP), it makes a lot of sense to do the work in Transport, even though to date, application protocols have lived in APPS/ART.

However, there's a latent decision in there -- that the next version of HTTP is only a change to transport, not to core semantics.

That may very well be the right decision to make, but it seems like it needs to be a very conscious one within the HTTP community (realising that the set of HTTP-focused people who choose to come to these discussions is smaller than that). There has been some discussion about making more bold changes in HTTP/3, and I think it's important to make sure there's buy-in about the scope of work, especially since doing it this way could effectively put such changes off the table for a fair amount of time (revving the protocol too often discourages deployment and investment).

I think we can do that by having a discussion in the HTTP WG, with some input from other HTTP implementers too. I'm happy to help facilitate that if you like.

I'll try to suggest some charter text separately regarding HTTP semantics.

One other thing - the rationale you gives makes a lot of sense for HTTP, as the "original" use case for QUIC. I'm not sure it does for further application mappings. If QUIC is going to be a successful transport(-ish) protocol, shouldn't other protocols be able to use it without coordination, and without being defined inside a "super-group"?

Cheers,

> On 18 May 2016, at 8:14 AM, Ted Hardie <[email-masked]> wrote:
> 
> I've changed the subject on this, since I want to focus on a particular topic.
> 
> Comments in-line:
> 
>  The third focus area will describe mappings between specific applications’ semantics and the transport facilities of QUIC. The first mapping will be a description of HTTP/2 semantics using QUIC, specifically with the goal of minimizing web latency using QUIC. Upon completion of that mapping, additional protocols may be added by updating this charter to include them.
> 
> 
> Defining application protocols in the Transport area is a pretty big change around here, even if it is just mapping existing semantics to a new transport.
> 
> As everyone knows, such mappings are "leaky" -- changes under the hood can and will affect how people use the application. We had numerous examples of this in H2, and while QUIC appears to be a more straightforward change in this respect, it's still easy enough to have unintended side effects. HTTP is especially fragile in this regard, because of its complexity, history and breadth of use.
> 
> Note that I'm not saying I'm firmly against this approach, just concerned; this WG is obviously going to be very deep in transport discussions, and it would be easy to lose the application perspective in it.
> 
> 
> I think you're right that this is a serious concern, but my thinking is that we have this concern either way.  You could avoid that by serializing the transport work to finish before any mapping started, but that would be slow.  It would also risk the transport developing without the driving use case focus that has helped the pre-standards work progress.  
> 
> If we try to do the mapping work in a different/area working group while the transport work is still ongoing, we need a very tight coordination between the two groups throughout the work.  Basically, everyone interested will have to be in both; given that it will not be the only topic in either group, that's going to be distracting as well as logistically difficult.  
> 
> If you're not willing to serialize,  in other words, I think you have to pick one to have the work.  Given that QUIC will eventually have more than one mapping, I think it makes sense to do it in a working group focused on QUIC.  There is no question that a QUIC working group with this charter would need the eyes of an HTTP-focused set of contributors for this mapping.  To some extent, that means we're asking the indulgence of the HTTP-focused community for splitting their attention for a time; ultimately, though, I think they would have had to do that anyway.
>  
> Also, if this WG *is* to do the HTTP/2 mapping, more text about what semantics are being mapped would avoid a lot of argument down the road; if you say it's "all of them", that includes running HTTP without TLS.
> 
>  
> I think the intent is to cover HTTP/2 semantics for an encrypted transport, but further assistance in conveying that would be gratefully received.
> 
> > Milestones
> 
> It would be helpful to also propose the timing of the milestones, perhaps in the form of "date of chartering + n months."
> 
> That's a great idea; I didn't want to put in dates when I didn't have a start date in hand, but we'll try to put a strawman together with that approach.
>  
> regards,
> 
> Ted

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

---

From: Ted Hardie <[email-masked]>
Date: Mon, 23 May 2016 03:31:12 -0400

Hi Mark,

Thanks for your thoughts on this.  Some additional musing below.

On Mon, May 23, 2016 at 2:30 AM, Mark Nottingham <[email-masked]> wrote:

> If we assume that the vast bulk of the work is in defining the semantics
> of the transport (as many have said, building the functionality of TCP on
> top of UDP), it makes a lot of sense to do the work in Transport, even
> though to date, application protocols have lived in APPS/ART.
>
> However, there's a latent decision in there -- that the next version of
> HTTP is only a change to transport, not to core semantics.
>
> So, that's an interesting question, but not the way I'd understood the
intent here.  My reading of the intent was to map the current HTTP/2
semantics onto QUIC rather than create a new HTTP version.   My mental
model of the relationship was closer to defining HTTP over TLS vs. HTTP
over TCP, rather than shifting from HTTP 1.1. to HTTP/2.

That may be the wrong mental model, and you're quite right that this was a
latent in the description rather than made as a choice between two options.

> That may very well be the right decision to make, but it seems like it
> needs to be a very conscious one within the HTTP community (realising that
> the set of HTTP-focused people who choose to come to these discussions is
> smaller than that). There has been some discussion about making more bold
> changes in HTTP/3, and I think it's important to make sure there's buy-in
> about the scope of work, especially since doing it this way could
> effectively put such changes off the table for a fair amount of time
> (revving the protocol too often discourages deployment and investment).
>
> I think we can do that by having a discussion in the HTTP WG, with some
> input from other HTTP implementers too. I'm happy to help facilitate that
> if you like.
>
> I very much appreciate your offer to facilitate, and I think the
discussion should definitely occur.

> One other thing - the rationale you gives makes a lot of sense for HTTP,
> as the "original" use case for QUIC. I'm not sure it does for further
> application mappings. If QUIC is going to be a successful transport(-ish)
> protocol, shouldn't other protocols be able to use it without coordination,
> and without being defined inside a "super-group"?
>
> I think after we have a few worked examples, it will be possible to do
without that aspect of this group, much as X over TLS work occurs in
coordination with (rather than inside) TLS.

regards,

Ted

> > I think the intent is to cover HTTP/2 semantics for an encrypted
> transport, but further assistance in conveying that would be gratefully
> received.
> >
> > > Milestones
> >
> > It would be helpful to also propose the timing of the milestones,
> perhaps in the form of "date of chartering + n months."
> >

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 23 May 2016 17:37:18 +1000

> On 23 May 2016, at 5:31 PM, Ted Hardie <[email-masked]> wrote:
> 
>> So, that's an interesting question, but not the way I'd understood the intent here.  My reading of the intent was to map the current HTTP/2 semantics onto QUIC rather than create a new HTTP version.   My mental model of the relationship was closer to defining HTTP over TLS vs. HTTP over TCP, rather than shifting from HTTP 1.1. to HTTP/2.  
> 
> That may be the wrong mental model, and you're quite right that this was a latent in the description rather than made as a choice between two options.

AIUI (and please correct me if I'm wrong), the plan is to advertise availability of the new mapping using a new ALPN token over Alt-Svc; if that's the case, it can't be "h2" because that denotes HTTP/2 over TLS over TCP.

Of course, we could define the new thing as "h2-udp".

Cheers,

---

From: Julian Reschke <[email-masked]>
Date: Mon, 23 May 2016 09:41:36 +0200

On 2016-05-23 08:30, Mark Nottingham wrote:
> ...

I think it would be unfortunate to couple wire protocol changes with 
application level changes if we don't need to.

Q: do you expect that HTTP over Quic will be negotiated with something 
similar to ALPN, and that we'll need a new token for that?

Best regards, Julian

---

From: Cory Benfield <[email-masked]>
Date: Mon, 23 May 2016 15:15:20 +0100

> On 23 May 2016, at 08:41, Julian Reschke <[email-masked]> wrote:
> 
> I think it would be unfortunate to couple wire protocol changes with application level changes if we don't need to.

What does “application level changes” mean here? My understanding is that no-one is planning to make *semantic* changes to HTTP as part of this work, but necessarily there is going to be some divergence from RFC 7540 if only because the nature of the transport will be meaningfully different from TCP.

I would expect that an application that was protected from working with HTTP directly, or that works with it at a semantic level (e.g. a Python WSGI application) wouldn’t change in response to QUIC, but any application that actually speaks HTTP is going to have to change at least a little bit.

Cory

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 23 May 2016 14:17:09 +0000

> I would expect that an application that was protected from working with
> HTTP directly, or that works with it at a semantic level (e.g. a Python WSGI
> application) wouldn’t change in response to QUIC, but any application that
> actually speaks HTTP is going to have to change at least a little bit.

I think you have, in essence, described the difference between syntactic and semantic differences. :)

---

From: Cory Benfield <[email-masked]>
Date: Mon, 23 May 2016 15:21:53 +0100

> On 23 May 2016, at 15:17, Salz, Rich <[email-masked]> wrote:
> 
> 

Heh, I have. But Julian said “wire protocol changes” and “application level changes”, and it’s not *trivially* clear to me that he was using those words in a way that corresponds one-to-one with syntactic and semantic. =) That’s why I followed up: I wanted to make sure I understood what Julian was saying before responding further.

Cory

---

From: Julian Reschke <[email-masked]>
Date: Mon, 23 May 2016 16:27:07 +0200

> What does “application level changes” mean here? My understanding is that no-one is planning to make *semantic* changes to HTTP as part of this work, but necessarily there is going to be some diver…

I was referring to what Mark said -- people have been talking about what 
HTTP/3 could be, and these discussions (AFAIR) also touched features 
above the transport layer.

So the question is: is the result of mapping HTTP/2 to Quik what will be 
referred to as "HTTP/3"? And so, will it *just* affect the mapping, and 
leave everything else unmodified?

Best regards, Julian

---

From: Cory Benfield <[email-masked]>
Date: Mon, 23 May 2016 15:28:23 +0100

> On 23 May 2016, at 15:27, Julian Reschke <[email-masked]> wrote:
> 
> I was referring to what Mark said -- people have been talking about what HTTP/3 could be, and these discussions (AFAIR) also touched features above the transport layer.
> 
> So the question is: is the result of mapping HTTP/2 to Quik what will be referred to as "HTTP/3"? And so, will it *just* affect the mapping, and leave everything else unmodified?
> 

Thanks for that clarification Julian. I definitely have similar concerns to you here.

Cory

---

From: Ian Swett <[email-masked]>
Date: Mon, 23 May 2016 11:48:25 -0400

A very interesting question Mark.  A few thoughts.

In regards to alt-svc, my thinking is that this would be h2-udp or
something similar.  That assumes QUIC has no semantic changes to H2.

If QUIC enables semantic changes to h2 that are valuable and are difficult
or impossible with TCP, then this becomes a very challenging question
indeed.  So far, the largest divergence we've considered from h2 in QUIC's
mapping is the best way to map headers and still minimize HoL blocking.
But that doesn't change semantics.  Developers build applications with the
tools presented to them, so lack of use is no indication that there aren't
semantic changes of interest, but I'm not aware of any QUIC specific ones
at the moment.

If the concern is that there's interest in an h3, but little appetite to
deploy h3 over TCP and h2-QUIC and h3-QUIC all in close time proximity,
that's a fair concern.

However, from a deployment perspective, I expect H2 over TCP is going to
have a relatively long life.   So there will be almost as much complexity
to support H2-TCP and H3-QUIC as H2-TCP, H3-TCP, H2-QUIC and H3-QUIC,
unless there are features of QUIC which make H3 profoundly easier to
implement.

On Mon, May 23, 2016 at 10:28 AM, Cory Benfield <[email-masked]> wrote:

> HTTP/3 could be, and these discussions (AFAIR) also touched features above
> the transport layer.
> >
> _______________________________________________
> QUIC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/quic
>
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 23 May 2016 13:04:25 -0400

On 23 May 2016 at 11:48, Ian Swett <[email-masked]> wrote:
> In regards to alt-svc, my thinking is that this would be h2-udp or something
> similar.  That assumes QUIC has no semantic changes to H2.

I don't want to distract from this, because this is a good intention.
However, I'm not yet convinced that this is even possible.  QUIC does
... things to the mapping of frames to streams that might alter the
way some h2 extensions work.  I don't quite know what we would do with
(for example) this: https://mikebishop.github.io/http2-certs/

---

From: Ian Swett <[email-masked]>
Date: Mon, 23 May 2016 13:22:04 -0400

Can you describe the particular QUIC specific challenge with the
http2-certs draft?  I'm familiar with the draft, and no issues come to mind.

On Mon, May 23, 2016 at 1:04 PM, Martin Thomson <[email-masked]>
wrote:

> something

---

From: Martin Thomson <[email-masked]>
Date: Mon, 23 May 2016 13:28:34 -0400

On 23 May 2016 at 13:22, Ian Swett <[email-masked]> wrote:
> Can you describe the particular QUIC specific challenge with the http2-certs
> draft?  I'm familiar with the draft, and no issues come to mind.

The draft requires exchanges on the affected stream and stream 0.  I'm
concerned that the change to move header fields to stream 3 will
negatively affect the sequencing of things.  I haven't thought it
through completely, maybe it's even an improvement.

Even if this is OK, I'm concerned that changes like the placement of
header blocks will have an impact on h2 extensions generally.

---

From: Ian Swett <[email-masked]>
Date: Mon, 23 May 2016 13:32:07 -0400

Agreed, the ability of QUIC to fix head of line blocking creates a variety
of challenges for specifications which relied on head of line
blocking(including, but not limited to headers).

The simple fix is to put all H2 frames requiring HoL blocking onto the
headers stream.  I 'think' that's sufficient as a viable approach, and in
some cases we may be able to do better.

On Mon, May 23, 2016 at 1:28 PM, Martin Thomson <[email-masked]>
wrote:

> http2-certs

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 23 May 2016 13:03:20 -0700

The intent was definitely to use alt-svc with "h2q", and not define a new
HTTP/3.

In general as a transport, lack of HoL blocking in QUIC (or equivalently,
the availability of HoL blocking in TCP) is a key difference when
considering HTTP/2 mechanisms or extensions. Having QUIC as an alternative
transport for HTTP/2 makes it important that any new HTTP/2 extension
explicitly consider and state its HoL blocking assumptions.

HTTP/2 was clearly defined to run on top of TLS or TCP... RFC 7540
<http://httpwg.org/specs/rfc7540.html> clearly states: "An HTTP/2
connection is an application-layer protocol running on top of a TCP
connection". This is exactly why "h2q" needs a mapping document, which maps
the semantics of HTTP/2 on top of a different wire-format. 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.

We've done something similar in the past in TSVAREA that may be helpful --
when a modification to a congestion control or a loss recovery mechanism is
made, it can be made for both TCP and SCTP in the same doc (see RFC 5827
<https://tools.ietf.org/html/rfc5827>, for instance.) To be clear, this is
not required for draft authors at the moment, and it is a model to consider
for future HTTP/2 extensions -- an extension could have a "TCP" and a
"QUIC" section.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 23 May 2016 16:27:35 -0400

On 23 May 2016 at 16:03, Jana Iyengar <[email-masked]> 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.

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 23 May 2016 13:51:37 -0700

> immediately port to "h2q".

Agreed.

> produce that will be generally applicable to most, if not all,

Agreed.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 24 May 2016 11:26:44 +1000

Hi Ian,

> On 24 May 2016, at 1:48 AM, Ian Swett <[email-masked]> wrote:
> 
> In regards to alt-svc, my thinking is that this would be h2-udp or something similar.  That assumes QUIC has no semantic changes to H2.
> 
> If QUIC enables semantic changes to h2 that are valuable and are difficult or impossible with TCP, then this becomes a very challenging question indeed.  So far, the largest divergence we've considered from h2 in QUIC's mapping is the best way to map headers and still minimize HoL blocking.  But that doesn't change semantics.  Developers build applications with the tools presented to them, so lack of use is no indication that there aren't semantic changes of interest, but I'm not aware of any QUIC specific ones at the moment.
> 
> If the concern is that there's interest in an h3, but little appetite to deploy h3 over TCP and h2-QUIC and h3-QUIC all in close time proximity, that's a fair concern.

That's a part of it, but mainly my concern is mostly that the decision is happening as a side effect of the start of QUIC work, rather than something explicitly made. I think it's easy enough to fix.

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 24 May 2016 11:27:53 +1000

> On 24 May 2016, at 6:27 AM, Martin Thomson <[email-masked]> wrote:
> 

+1. We should be looking at how we can minimise the differences wherever possible.

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 24 May 2016 15:37:39 +0000

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:[email-masked]] On Behalf Of Mark Nottingham
> Sent: 24 May 2016 02:28
> To: Martin Thomson <[email-masked]>
> Cc: Ted Hardie <[email-masked]>; Julian F. Reschke
> <[email-masked]>; Ian Swett <[email-masked]>; Cory Benfield
> <[email-masked]>; Christian Huitema <[email-masked]>; Jana
> Iyengar <[email-masked]>; [email-masked]
> Subject: Re: [QUIC] Choice of area (and scope of work)
> 
> 
> >> 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.
> >

---

From: Ian Swett <[email-masked]>
Date: Tue, 24 May 2016 11:54:15 -0400

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 <[email-masked]>
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
>

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 24 May 2016 16:36:57 +0000

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:[email-masked]]
Sent: 24 May 2016 16:54
To: Lucas Pardue <[email-masked]>
Cc: Mark Nottingham <[email-masked]>; Martin Thomson <[email-masked]>; Ted Hardie <[email-masked]>; Julian F. Reschke <[email-masked]>; Cory Benfield <[email-masked]>; Christian Huitema <[email-masked]>; Jana Iyengar <[email-masked]>; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> 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.

Lucas

> From: QUIC [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Mark Nottingham
> Sent: 24 May 2016 02:28
> To: Martin Thomson <[email-masked]<mailto:[email-masked]>>
> Cc: Ted Hardie <[email-masked]<mailto:[email-masked]>>; Julian F. Reschke
> <[email-masked]<mailto:[email-masked]>>; Ian Swett <[email-masked]<mailto:[email-masked]>>; Cory Benfield
> <[email-masked]<mailto:[email-masked]>>; Christian Huitema <[email-masked]<mailto:[email-masked]>>; Jana
> Iyengar <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
> > On 24 May 2016, at 6:27 AM, Martin Thomson
> <[email-masked]<mailto:[email-masked]>> wrote:
> >
> > On 23 May 2016 at 16:03, Jana Iyengar <[email-masked]<mailto:[email-masked]>> wrote:
> [email-masked]<mailto:[email-masked]>

---

From: Ian Swett <[email-masked]>
Date: Tue, 24 May 2016 18:41:02 -0400

I'm happy with that addition.

On Tue, May 24, 2016 at 12:36 PM, Lucas Pardue <[email-masked]>
wrote:

> *From:* Ian Swett [mailto:[email-masked]]
> *Sent:* 24 May 2016 16:54
> *To:* Lucas Pardue <[email-masked]>
> *Cc:* Mark Nottingham <[email-masked]>; Martin Thomson <
> [email-masked]>; Ted Hardie <[email-masked]>; Julian F.
> Reschke <[email-masked]>; Cory Benfield <[email-masked]>;
> Christian Huitema <[email-masked]>; Jana Iyengar <[email-masked]>;
> [email-masked]
>
> *Subject:* Re: [QUIC] Choice of area (and scope of work)
>
>
>
> 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?
>
>
>
> > <[email-masked]> wrote:
> > >

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 25 May 2016 11:03:31 +1000

+1. 

> On 25 May 2016, at 8:41 AM, Ian Swett <[email-masked]> wrote:
> 
> On Tue, May 24, 2016 at 12:36 PM, Lucas Pardue <[email-masked]> wrote:
> On Tue, May 24, 2016 at 11:37 AM, Lucas Pardue <[email-masked]> wrote:
>