Subject: Lifting HTTP/3 Features into Extensions

From: Mike Bishop <[email-masked]>
Date: Wed, 12 Dec 2018 18:43:23 +0000

To preface, this is really a separate discussion, linked to this one only by what is effectively whataboutism.  We don’t have consensus to do this complicating thing that optimizes for a common case, so why did we achieve consensus to do those other complicated things that optimize for uncommon cases?  But that consensus was achieved in HTTP/2, and my personal reading of the charter leads me to believe we’re prohibited from wholesale removal of H2 features in HTTP/3; we try to keep the same general spirit unless things are fundamentally incompatible with running over QUIC.

Moving everything post-DATA to a separate stream is a fairly dramatic change, and I’m having trouble seeing exactly how that would work.  And it suffers the same liability that it’s likely to be an under-exercised code path.

Priority and push were both controversial pieces of H2 for various reasons.  Unlike in HTTP/2, they are more decoupled from the stream state model in HTTP/3, and either or both could easily could become an extension.  I find the argument more persuasive for priority than for push, because one could very reasonably choose to experiment with several independent priority schemes – the pseudo-7540-style we have now, the three-bit SPDY-style priorities, a varint fixed priority, the weighted-group<https://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/0396.html>, etc.

From: Ian Swett <[email-masked]>
Sent: Wednesday, December 12, 2018 9:27 AM
To: ianswett=[email-masked]; Roberto Peon <[email-masked]>; Ryan Hamilton <[email-masked]>; Jana Iyengar <[email-masked]>; Mike Bishop <[email-masked]>; HTTP Working Group <[email-masked]>; Lucas Pardue <[email-masked]>; IETF QUIC WG <[email-masked]>; Martin Thomson <[email-masked]>; Kazuho Oku <[email-masked]>
Subject: Re: Final DATA frames

From a technical perspective, yes.  But from a goals/process perspective, I think they related.  We've spent a lot of time on very complex work in the QUIC WG, and I realize everyone has a different perspective, but I'm confused by the amount of pushback this got relative to all the work we have done to make PUSH and something approximating(since they're actually different) H2 priorities work on top of QUIC.

If I remember correctly, your main argument against this framing change was that the existing DATA frame with a length becomes largely useless and might be under-exercised.  That makes me feel like we've over-optimized for the complex special cases and made a design error or two at least one step prior to this proposal.

To make a specific and relevant suggestion, maybe DATA should never have a length and if we want features that most requests don't use(trailers/PUSH_PROMISE/etc) we should put them on a separate unidirectional stream?

On Wed, Dec 12, 2018 at 12:02 PM Dmitri Tikhonov <[email-masked]<mailto:[email-masked]>> wrote:
But you would agree that these are completely different discussions?

One is whether to modify HTTP/3 framing mechanism.  The other is
changing HTTP/3 feature set.

My point is that it is unjustified to to say that since we have
decided not to change the framing mechanism we should consider
dropping prioritization and push promises.

On Wed, Dec 12, 2018 at 11:38:09AM -0500, Ian Swett wrote:
> I don't want to derail this too much(probably too late for that), and no
> one has a PR anywhere close to landing, but I do think we should start
> thinking of these as potential extensions.  I disagree that they're
> HTTP/2's primary features, both due to lack of use and lack of measurable
> benefits years after standardization.  Push might actually benefit from
> being an extension, because then potential improvements(ie: cache-digest)
> could be integrated into the extension more quickly.
>
> On the other hand, QPACK is relatively complex but we have clearer
> demonstrations of it's benefit.
>
> On Wed, Dec 12, 2018 at 9:00 AM Dmitri Tikhonov <[email-masked]<mailto:[email-masked]>>
> wrote:
>
> > On Tue, Dec 11, 2018 at 09:02:01PM -0500, Ian Swett wrote:
> > > TLDR: If the focus is on shipping v1 and making sure we don't introduce
> > > premature optimizations into HTTP/3, I thInk we should seriously consider
> > > moving PUSH and the existing priorities to an extension.
> >
> > The EOS DATA frame and HTTP prioritization and push promises are not
> > equivalent.  One is simply fiddling with the way data is framed and
> > is not visible to the application.  The others are HTTP/2's primary
> > features.
> >
> >   - Dmitri.
> >

---

From: David Schinazi <[email-masked]>
Date: Wed, 12 Dec 2018 13:12:39 -0800

I think there is value in moving some features to extensions. I don't see
anything in the charter preventing us from moving specific work items to
extensions, especially if we believe it'll accelerate us shipping v1, and
allow experimentations that could produce a better prioritization scheme.
>From what I heard from people involved in the HTTP/2 standardization
efforts, some things about prioritization and push could have been done
differently, and most likely would have if they had been standardized as
extensions. It would be great for us to gain this flexibility in HTTP/3.
Moving trailers to an extension would allow us to remove the length from
DATA.

David

On Wed, Dec 12, 2018 at 10:43 AM Mike Bishop <[email-masked]> wrote:

> To preface, this is really a separate discussion, linked to this one only
> by what is effectively whataboutism.  We don’t have consensus to do this
> complicating thing that optimizes for a common case, so why did we achieve
> consensus to do those other complicated things that optimize for uncommon
> cases?  But that consensus was achieved in HTTP/2, and my personal reading
> of the charter leads me to believe we’re prohibited from wholesale removal
> of H2 features in HTTP/3; we try to keep the same general spirit unless
> things are fundamentally incompatible with running over QUIC.
>
>
>
> Moving everything post-DATA to a separate stream is a fairly dramatic
> change, and I’m having trouble seeing exactly how that would work.  And it
> suffers the same liability that it’s likely to be an under-exercised code
> path.
>
>
>
> Priority and push were both controversial pieces of H2 for various
> reasons.  Unlike in HTTP/2, they are more decoupled from the stream state
> model in HTTP/3, and either or both could easily could become an
> extension.  I find the argument more persuasive for priority than for push,
> because one could very reasonably choose to experiment with several
> independent priority schemes – the pseudo-7540-style we have now, the
> three-bit SPDY-style priorities, a varint fixed priority, the
> weighted-group
> <https://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/0396.html>,
> etc.
>
>
>
> *From:* Ian Swett <[email-masked]>
> *Sent:* Wednesday, December 12, 2018 9:27 AM
> *To:* ianswett=[email-masked]; Roberto Peon <[email-masked]>;
> Ryan Hamilton <[email-masked]>; Jana Iyengar <[email-masked]>; Mike
> Bishop <[email-masked]>; HTTP Working Group <[email-masked]>;
> Lucas Pardue <[email-masked]>; IETF QUIC WG <[email-masked]>;
> Martin Thomson <[email-masked]>; Kazuho Oku <[email-masked]
> >
> *Subject:* Re: Final DATA frames
>
>
>
> From a technical perspective, yes.  But from a goals/process perspective,
> I think they related.  We've spent a lot of time on very complex work in
> the QUIC WG, and I realize everyone has a different perspective, but I'm
> confused by the amount of pushback this got relative to all the work we
> have done to make PUSH and something approximating(since they're actually
> different) H2 priorities work on top of QUIC.
>
>
>
> If I remember correctly, your main argument against this framing change
> was that the existing DATA frame with a length becomes largely useless and
> might be under-exercised.  That makes me feel like we've over-optimized for
> the complex special cases and made a design error or two at least one step
> prior to this proposal.
>
>
>
> To make a specific and relevant suggestion, maybe DATA should never have a
> length and if we want features that most requests don't
> use(trailers/PUSH_PROMISE/etc) we should put them on a separate
> unidirectional stream?
>
>
>
>
>
>
>
> On Wed, Dec 12, 2018 at 12:02 PM Dmitri Tikhonov <
> [email-masked]> wrote:
>
> > On Wed, Dec 12, 2018 at 9:00 AM Dmitri Tikhonov <
> [email-masked]>
> > wrote:
> >

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 13 Dec 2018 06:36:37 +0900

2018年12月13日(木) 6:12 David Schinazi <[email-masked]>:
>
> I think there is value in moving some features to extensions. I don't see anything in the charter preventing us from moving specific work items to extensions, especially if we believe it'll accelerate us shipping v1, and allow experimentations that could produce a better prioritization scheme. From what I heard from people involved in the HTTP/2 standardization efforts, some things about prioritization and push could have been done differently, and most likely would have if they had been standardized as extensions. It would be great for us to gain this flexibility in HTTP/3. Moving trailers to an extension would allow us to remove the length from DATA.

I am fine with making push an extension, because it's something that
we might not need from day one.

OTOH, I think that priorities need to be kept in the core
specification, considering the fact that it is a must-have for the web
browser use-case (the use-case we care the most). IIUC, the lesson
learned from HTTP/2 is that we see bad performance (worse than HTTP/1)
when priorities are not handled correctly by the servers. Therefore,
priorities need to be standardized alongside the core specification,
and we need to be clear that the servers need to implement it.
Defining priorities outside core specification would be an additional
burden for us (defining one document is easier than defining two), and
also raises the risk of people failing to recognize that the support
for priorities is a MUST for the browser use-case.

I also oppose to moving trailers to extension, because it's a feature
of the core HTTP spec.

>> Priority and push were both controversial pieces of H2 for various reasons.  Unlike in HTTP/2, they are more decoupled from the stream state model in HTTP/3, and either or both could easily could become an extension.  I find the argument more persuasive for priority than for push, because one could very reasonably choose to experiment with several independent priority schemes – the pseudo-7540-style we have now, the three-bit SPDY-style priorities, a varint fixed priority, the weighted-group, etc.
>>
>>
>>
>> On Wed, Dec 12, 2018 at 12:02 PM Dmitri Tikhonov <[email-masked]> wrote:
>>
>> > On Wed, Dec 12, 2018 at 9:00 AM Dmitri Tikhonov <[email-masked]>
>> > wrote:
>> >

-- 
Kazuho Oku

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 12 Dec 2018 22:04:16 +0000

On Wed, 12 Dec 2018, 21:36 Kazuho Oku <[email-masked] wrote:

> > I think there is value in moving some features to extensions. I don't
> see anything in the charter preventing us from moving specific work items
> to extensions, especially if we believe it'll accelerate us shipping v1,
> and allow experimentations that could produce a better prioritization
> scheme. From what I heard from people involved in the HTTP/2
> standardization efforts, some things about prioritization and push could
> have been done differently, and most likely would have if they had been
> standardized as extensions. It would be great for us to gain this
> flexibility in HTTP/3. Moving trailers to an extension would allow us to
> remove the length from DATA.
>

This is a good defense of the need to prioritise delivery in a multixed
protocol. I think in practice that it's been hard to mandate servers behave
in any way, and to observe that they do as asked.

Through the lens of interop, is there any difference in me ignoring the
contents of the PRIORITY frames in the server, or just ignoring them
completely (akin to an unsupported extension).

I agree performance is important but I don't if the UA is always right.

Could we try to draw on the transport's approach to congestion control
algorithm?

So continuing the above thinking, one approach could be to extract the text
but keep it core (I.e. mandatory to implement for H3). This is similar to
QPACK document. That could provide some of the proposed benefits.

> of the core HTTP spec.

I agree with Kazuho here.

Lucas

> >> To preface, this is really a separate discussion, linked to this one
> only by what is effectively whataboutism.  We don’t have consensus to do
> this complicating thing that optimizes for a common case, so why did we
> achieve consensus to do those other complicated things that optimize for
> uncommon cases?  But that consensus was achieved in HTTP/2, and my personal
> reading of the charter leads me to believe we’re prohibited from wholesale
> removal of H2 features in HTTP/3; we try to keep the same general spirit
> unless things are fundamentally incompatible with running over QUIC.
> >>
> >>
> >>
> weighted-group, etc.
> >> To: ianswett=[email-masked]; Roberto Peon <[email-masked]>;
> >> From a technical perspective, yes.  But from a goals/process
> perspective, I think they related.  We've spent a lot of time on very
> complex work in the QUIC WG, and I realize everyone has a different
> perspective, but I'm confused by the amount of pushback this got relative
> to all the work we have done to make PUSH and something approximating(since
> they're actually different) H2 priorities work on top of QUIC.
> >>
> >>
> >>
> >> To make a specific and relevant suggestion, maybe DATA should never
> have a length and if we want features that most requests don't

---

From: Mike Bishop <[email-masked]>
Date: Wed, 12 Dec 2018 22:07:35 +0000

Trailers aren’t an extension, no more than QPACK is.  They’re required to transfer HTTP semantics, which is the core remit of the protocol.

From: David Schinazi <[email-masked]>
Sent: Wednesday, December 12, 2018 1:13 PM
To: Mike Bishop <[email-masked]>
Cc: Ian Swett <[email-masked]>; ianswett=[email-masked]; [email-masked]; Ryan Hamilton <[email-masked]>; [email-masked]; [email-masked]; Lucas Pardue <[email-masked]>; QUIC <[email-masked]>; Martin Thomson <[email-masked]>; [email-masked]
Subject: Re: Lifting HTTP/3 Features into Extensions

David

On Wed, Dec 12, 2018 at 10:43 AM Mike Bishop <[email-masked]<mailto:[email-masked]>> wrote:
To preface, this is really a separate discussion, linked to this one only by what is effectively whataboutism.  We don’t have consensus to do this complicating thing that optimizes for a common case, so why did we achieve consensus to do those other complicated things that optimize for uncommon cases?  But that consensus was achieved in HTTP/2, and my personal reading of the charter leads me to believe we’re prohibited from wholesale removal of H2 features in HTTP/3; we try to keep the same general spirit unless things are fundamentally incompatible with running over QUIC.

From: Ian Swett <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, December 12, 2018 9:27 AM
To: ianswett=[email-masked]<mailto:[email-masked]>; Roberto Peon <[email-masked]<mailto:[email-masked]>>; Ryan Hamilton <[email-masked]<mailto:[email-masked]>>; Jana Iyengar <[email-masked]<mailto:[email-masked]>>; Mike Bishop <[email-masked]<mailto:[email-masked]>>; HTTP Working Group <[email-masked]<mailto:[email-masked]>>; Lucas Pardue <[email-masked]<mailto:[email-masked]>>; IETF QUIC WG <[email-masked]<mailto:[email-masked]>>; Martin Thomson <[email-masked]<mailto:[email-masked]>>; Kazuho Oku <[email-masked]<mailto:[email-masked]>>
Subject: Re: Final DATA frames

---

From: David Schinazi <[email-masked]>
Date: Wed, 12 Dec 2018 14:23:06 -0800

I like the idea of mandatory-to-implement extensions, because it means we
can still replace them later.

Regarding trailers, "the core remit of the protocol" - but the protocol in
that sentence is HTTP/2, not HTTP/3. When HTTP/2 was standardized, it
dropped support for a the Upgrade header, which you could consider core
remit of HTTP/1.1, so we have a precedent for removing features because we
believed we had something better. We have an opportunity to make HTTP/3
better, do we really need to bring everything in from HTTP/2 just because
it was there then? And going back to trailers, I'm not suggesting they
should not exist, I'm suggesting demoting them to an extension so it
becomes possible to iterate on that extension without changing the version
number of the mapping.

David

On Wed, Dec 12, 2018 at 2:07 PM Mike Bishop <[email-masked]> wrote:

> Trailers aren’t an extension, no more than QPACK is.  They’re required to
> transfer HTTP semantics, which is the core remit of the protocol.
>
>
>
> *From:* David Schinazi <[email-masked]>
> *Sent:* Wednesday, December 12, 2018 1:13 PM
> *To:* Mike Bishop <[email-masked]>
> *Cc:* Ian Swett <[email-masked]>; ianswett=
> [email-masked]; [email-masked]; Ryan Hamilton <[email-masked]>;
> [email-masked]; [email-masked]; Lucas Pardue <
> [email-masked]>; QUIC <[email-masked]>; Martin Thomson <
> [email-masked]>; [email-masked]
> *Subject:* Re: Lifting HTTP/3 Features into Extensions
>
>
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Dec 2018 09:29:30 +1100

Upgrade is a feature of HTTP/1.1, not HTTP.

All of this is possible.  These are largely solved problems, so
ripping them out would cost time, not save it.  I realize that the
sunk cost fallacy applies, but discussing removal of features that
aren't causing problems (except where they make new features harder to
add) doesn't seem like a good use of our time.  This protocol is close
to done and all it really needs is for this group to knuckle down and
fix the outstanding issues.

Maybe we could spend more time fixing the problems we have than
creating new ones?
On Thu, Dec 13, 2018 at 9:23 AM David Schinazi <[email-masked]> wrote:
>
> I like the idea of mandatory-to-implement extensions, because it means we can still replace them later.
>
> Regarding trailers, "the core remit of the protocol" - but the protocol in that sentence is HTTP/2, not HTTP/3. When HTTP/2 was standardized, it dropped support for a the Upgrade header, which you could consider core remit of HTTP/1.1, so we have a precedent for removing features because we believed we had something better. We have an opportunity to make HTTP/3 better, do we really need to bring everything in from HTTP/2 just because it was there then? And going back to trailers, I'm not suggesting they should not exist, I'm suggesting demoting them to an extension so it becomes possible to iterate on that extension without changing the version number of the mapping.
>
> David
>

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 13 Dec 2018 07:37:21 +0900

2018年12月13日(木) 7:04 Lucas Pardue <[email-masked]>:
>> > I think there is value in moving some features to extensions. I don't see anything in the charter preventing us from moving specific work items to extensions, especially if we believe it'll accelerate us shipping v1, and allow experimentations that could produce a better prioritization scheme. >From what I heard from people involved in the HTTP/2 standardization efforts, some things about prioritization and push could have been done differently, and most likely would have if they had been standardized as extensions. It would be great for us to gain this flexibility in HTTP/3. Moving trailers to an extension would allow us to remove the length from DATA.
>>
> This is a good defense of the need to prioritise delivery in a multixed protocol. I think in practice that it's been hard to mandate servers behave in any way, and to observe that they do as asked.
>
> Through the lens of interop, is there any difference in me ignoring the contents of the PRIORITY frames in the server, or just ignoring them completely (akin to an unsupported extension).

Interop-wise, you'd be fine with ignoring PRIORITY frames. There would
also be use-cases that do not require the use of priorities.

> I agree performance is important but I don't if the UA is always right.

It is true that servers can prioritize the responses by themselves,
for example by consulting the content-type header field. But browsers
have better information, because they know *how* the resources are
used (e.g., is it an async javascript load? is the image hidden?).

Fortunately, most of the web browsers are sending well-designed H2
priorities. We need to let the trend continue in H3.

> Could we try to draw on the transport's approach to congestion control algorithm?

Maybe, if the editors have strong preference to split the documents.

My argument is that priorities need to be defined alongside H3, and
that H3 cannot ship (or go into interop in the wild) without
priorities. The opposition to splitting the document is based on that
and the assumption that it would be easier to specify one thing than
two. I want to see H3 with priorities done soon.

> So continuing the above thinking, one approach could be to extract the text but keep it core (I.e. mandatory to implement for H3). This is similar to QPACK document. That could provide some of the proposed benefits.
>

-- 
Kazuho Oku

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 12 Dec 2018 22:46:09 +0000

Anyone proposing moving features out to optional extensions would be 
well advised to look at the history of IMAP, and the interop nightmare 
that this approach causes.

I think we need to take a good long look and make things we need 
non-optional.  If something is truly optional then you have to be 
prepared for it to cause interop problems, and you get a chicken and egg 
problem, where client vendors won't add support for an option unless a 
server vendor does, and vice versa. Making a feature optional is a 
pretty good way to consign it to oblivion.

------ Original Message ------
From: "David Schinazi" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "Ian Swett" <[email-masked]>; 
"ianswett=[email-masked]" 
<ianswett=[email-masked]>; "[email-masked]" <[email-masked]>; 
"Ryan Hamilton" <[email-masked]>; "[email-masked]" 
<[email-masked]>; "[email-masked]" <[email-masked]>; 
"Lucas Pardue" <[email-masked]>; "QUIC" <[email-masked]>; 
"Martin Thomson" <[email-masked]>; "[email-masked]" 
<[email-masked]>
Sent: 13/12/2018 10:12:39 AM
Subject: Re: Lifting HTTP/3 Features into Extensions

>see anything in the charter preventing us from moving specific work 
>items to extensions, especially if we believe it'll accelerate us 
>shipping v1, and allow experimentations that could produce a better 
>prioritization scheme. From what I heard from people involved in the 
>HTTP/2 standardization efforts, some things about prioritization and 
>push could have been done differently, and most likely would have if 
>they had been standardized as extensions. It would be great for us to 
>gain this flexibility in HTTP/3. Moving trailers to an extension would 
>allow us to remove the length from DATA.
>
>David
>
>>only by what is effectively whataboutism.  We don’t have consensus to 
>>do this complicating thing that optimizes for a common case, so why 
>>did we achieve consensus to do those other complicated things that 
>>optimize for uncommon cases?  But that consensus was achieved in 
>>HTTP/2, and my personal reading of the charter leads me to believe 
>>we’re prohibited from wholesale removal of H2 features in HTTP/3; we 
>>try to keep the same general spirit unless things are fundamentally 
>>incompatible with running over QUIC.
>>
>>
>>
>>change, and I’m having trouble seeing exactly how that would work..  
>>And it suffers the same liability that it’s likely to be an 
>>under-exercised code path.
>>
>>
>>
>>reasons.  Unlike in HTTP/2, they are more decoupled from the stream 
>>state model in HTTP/3, and either or both could easily could become an 
>>extension.  I find the argument more persuasive for priority than for 
>>push, because one could very reasonably choose to experiment with 
>>several independent priority schemes – the pseudo-7540-style we have 
>>now, the three-bit SPDY-style priorities, a varint fixed priority, the 
>>weighted-group 
>>Ryan Hamilton <[email-masked]>; Jana Iyengar <[email-masked]>; 
>>Mike Bishop <[email-masked]>; HTTP Working Group 
>><[email-masked]>; Lucas Pardue <[email-masked]>; IETF 
>>QUIC WG <[email-masked]>; Martin Thomson <[email-masked]>; 
>>Kazuho Oku <[email-masked]>
>>perspective, but I'm confused by the amount of pushback this got 
>>relative to all the work we have done to make PUSH and something 
>>approximating(since they're actually different) H2 priorities work on 
>>top of QUIC.
>>
>>
>>
>>If I remember correctly, your main argument against this framing 
>>change was that the existing DATA frame with a length becomes largely 
>>useless and might be under-exercised.  That makes me feel like we've 
>>over-optimized for the complex special cases and made a design error 
>>or two at least one step prior to this proposal.
>>
>>
>>

---

From: Andy Green <[email-masked]>
Date: Thu, 13 Dec 2018 08:13:46 +0800

On 13/12/2018 06:46, Adrien de Croy wrote:
> pretty good way to consign it to oblivion..

Yes... websockets has a similar story... extensions were used as a 
somewhat desperate measure to carve off subjects that didn't seem to 
have a good way to be resolved in the standard in the short term, 
multiplexing and compression.

Multiplexing on ws never happened, and came to fruition as h2. 
Compression happened but it is literally the only extension.  Most 
implementations of ws don't implement it.

When extensions come up as a solution it's maybe better to resist the 
urge to try to keep everyone happy and instead say either this fits with 
what we want to do and we will deal with it as a first-class citizen, or 
it is outside the scope of what we are doing.

In the case of trailers, IMHO they should be banned just like chunking 
was in h2 to simplify the protocol.  If intermediaries want to pass h1 
or h2 over h3 they can take care of fixing the trailers into headers 
just like h1 over h2 has to take care of stripping the chunking.

-Andy

> From: "David Schinazi" <[email-masked] 
> <mailto:[email-masked]>>
> To: "[email-masked]" <[email-masked] 
> <mailto:[email-masked]>>
> Cc: "Ian Swett" <[email-masked] <mailto:[email-masked]>>; 
> <ianswett=40google.com@dmarc..ietf.org 
> <mailto:ianswett=[email-masked]>>; "[email-masked]" 
> <[email-masked] <mailto:[email-masked]>>; "Ryan Hamilton" <[email-masked] 
> <mailto:[email-masked]>>; "[email-masked]" <[email-masked] 
> <mailto:[email-masked]>>; "[email-masked]" <[email-masked] 
> <mailto:[email-masked]>>; "Lucas Pardue" 
> <[email-masked] <mailto:[email-masked]>>; "QUIC" 
> <[email-masked] <mailto:[email-masked]>>; "Martin Thomson" 
> <[email-masked] <mailto:[email-masked]>>; 
> "[email-masked]" <[email-masked] <mailto:[email-masked]>>
>>     To preface, this is really a separate discussion, linked to this
>>     one only by what is effectively whataboutism.  We don’t have
>>     consensus to do this complicating thing that optimizes for a
>>     common case, so why did we achieve consensus to do those other
>>     complicated things that optimize for uncommon cases?  But that
>>     consensus was achieved in HTTP/2, and my personal reading of the
>>     charter leads me to believe we’re prohibited from wholesale
>>     removal of H2 features in HTTP/3; we try to keep the same general
>>     spirit unless things are fundamentally incompatible with running
>>     over QUIC.____
>>
>>     __ __
>>
>>     Moving everything post-DATA to a separate stream is a fairly
>>     dramatic change, and I’m having trouble seeing exactly how that
>>     would work.  And it suffers the same liability that it’s likely to
>>     be an under-exercised code path. ____
>>
>>     __ __
>>
>>     reasons.  Unlike in HTTP/2, they are more decoupled from the
>>     stream state model in HTTP/3, and either or both could easily
>>     could become an extension.  I find the argument more persuasive
>>     for priority than for push, because one could very reasonably
>>     choose to experiment with several independent priority schemes –
>>     the pseudo-7540-style we have now, the three-bit SPDY-style
>>     priorities, a varint fixed priority, the weighted-group
>>     etc.____
>>     __ __
>>     *From:* Ian Swett <[email-masked] <mailto:[email-masked]>>
>>     *To:* ianswett=[email-masked]
>>     <mailto:[email-masked]>; Roberto Peon <[email-masked]
>>     <mailto:[email-masked]>>; Ryan Hamilton <[email-masked]
>>     <mailto:[email-masked]>>; Jana Iyengar <[email-masked]
>>     <mailto:[email-masked]>>; Mike Bishop <[email-masked]
>>     <mailto:[email-masked]>>; HTTP Working Group
>>     <[email-masked] <mailto:[email-masked]>>; Lucas Pardue
>>     <[email-masked] <mailto:[email-masked]>>;
>>     IETF QUIC WG <[email-masked] <mailto:[email-masked]>>; Martin
>>     Thomson <[email-masked]
>>     <mailto:[email-masked]>>; Kazuho Oku
>>     <[email-masked] <mailto:[email-masked]>>
>>     *Subject:* Re: Final DATA frames____
>>
>>     __ __
>>
>>     perspective, I think they related.  We've spent a lot of time on
>>     very complex work in the QUIC WG, and I realize everyone has a
>>     different perspective, but I'm confused by the amount of pushback
>>     this got relative to all the work we have done to make PUSH and
>>     something approximating(since they're actually different) H2
>>     priorities work on top of QUIC.____
>>
>>     __ __
>>
>>     change was that the existing DATA frame with a length becomes
>>     largely useless and might be under-exercised.  That makes me feel
>>     like we've over-optimized for the complex special cases and made a
>>     design error or two at least one step prior to this proposal.____
>>
>>     __ __
>>
>>     To make a specific and relevant suggestion, maybe DATA should
>>     never have a length and if we want features that most requests
>>     don't use(trailers/PUSH_PROMISE/etc) we should put them on a
>>     separate unidirectional stream?____
>>
>>     __ __
>>
>>     __ __
>>
>>     __ __
>>
>>     On Wed, Dec 12, 2018 at 12:02 PM Dmitri Tikhonov
>>     <[email-masked] <mailto:[email-masked]>>
>>     wrote:____
>>
>>         > On Wed, Dec 12, 2018 at 9:00 AM Dmitri Tikhonov
>>         <[email-masked] <mailto:[email-masked]>>
>>         > wrote:
>>         >
>>         > >____

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 13 Dec 2018 15:22:44 +1300

On 13/12/18 1:13 pm, Andy Green wrote:
>> prepared for it to cause interop problems, and you get a chicken and
>> egg problem, where client vendors won't add support for an option
>> unless a server vendor does, and vice versa. Making a feature optional
>> is a pretty good way to consign it to oblivion..
> 

While I like the simplicity this approach would bring to the header
handling there are some uses of Trailers for the general performance case.

The one which is most useful is TE:Content-MD5 delivering a hash of the
content/payload in a way cross-compatible with middleware translating
the HTTP versions or assisting with interop workarounds for those DATA
size issues that have been discussed recently.

Amos

---

From: Mike Bishop <[email-masked]>
Date: Thu, 13 Dec 2018 20:49:01 +0000

Chunking is not prohibited so much as rendered differently.  Because DATA frames are effectively chunks already, it's no longer necessary to declare "chunked" as a Transfer-Encoding, because everything is chunked.

-----Original Message-----
From: Andy Green <[email-masked]> 
Sent: Wednesday, December 12, 2018 4:14 PM
To: Adrien de Croy <[email-masked]>; David Schinazi <[email-masked]>; Mike Bishop <[email-masked]>
Cc: Ian Swett <[email-masked]>; ianswett=[email-masked]; [email-masked]; Ryan Hamilton <[email-masked]>; [email-masked]; [email-masked]; Lucas Pardue <[email-masked]>; QUIC <[email-masked]>; Martin Thomson <[email-masked]>; [email-masked]
Subject: Re: Lifting HTTP/3 Features into Extensions

> is a pretty good way to consign it to oblivion..

Yes... websockets has a similar story... extensions were used as a somewhat desperate measure to carve off subjects that didn't seem to have a good way to be resolved in the standard in the short term, multiplexing and compression.

Multiplexing on ws never happened, and came to fruition as h2. 
Compression happened but it is literally the only extension.  Most implementations of ws don't implement it.

When extensions come up as a solution it's maybe better to resist the urge to try to keep everyone happy and instead say either this fits with what we want to do and we will deal with it as a first-class citizen, or it is outside the scope of what we are doing.

In the case of trailers, IMHO they should be banned just like chunking was in h2 to simplify the protocol.  If intermediaries want to pass h1 or h2 over h3 they can take care of fixing the trailers into headers just like h1 over h2 has to take care of stripping the chunking.

-Andy

> <mailto:[email-masked]>>; "[email-masked]" 
> <[email-masked] <mailto:[email-masked]>>; "Lucas Pardue"
>> gain this flexibility in HTTP/3. Moving trailers to an extension 
>> would allow us to remove the length from DATA.
>>
>> David
>>

---

From: Andy Green <[email-masked]>
Date: Fri, 14 Dec 2018 05:15:27 +0800

> Chunking is not prohibited so much as rendered differently.  Because DATA frames are effectively chunks already, it's no longer necessary to declare "chunked" as a Transfer-Encoding, because everyt…

It says:

    HTTP/2 uses DATA frames to carry message payloads.  The "chunked"
    transfer encoding defined in Section 4.1 of [RFC7230] MUST NOT be
    used in HTTP/2.

https://tools.ietf.org/html/rfc7540

The effect is you can't just simply carry h1 on h2, but have to process 
it to remove inline chunking headers in the bulk content.  h1 chunking 
per se is explicitly banned in h2.

It's not that chunking is not useful in eg, cgis, which are defined to 
be h1-only (and as Amos pointed out deferred production of content 
metadata can be convenient on server side in some cases).  It's that h2 
said "we don't do that, use the natural h2 way" and made backwards 
compatibility someone else's problem.  It's a very effective way and 
chunking users adapted.

Trailers have the downside they force the client to buffer the bulk 
content until it gets the metadata, in the name of convenience at the 
server side... if trailers stopped being a thing there are other ways to 
get the same result without them, eg, multipart bulk content, or the 
server computes the metadata at headers time.  Any problems relating to 
trailers in h3 definition are gone.

-Andy

---

From: Andy Green <[email-masked]>
Date: Fri, 14 Dec 2018 16:34:40 +0800

On 14/12/2018 05:59, Roberto Peon wrote:

> H2 did not remove chunking from HTTP and in particular, it did not make chunking optional.

Dunno what "did not remove chunking from HTTP" means to you... it's MUST 
NOT -banned on h2, not "optional".

> Backwards compatibility was no different than an H1 server <-> H1 client, at the H2->H1 transition (that only proxies would have to do).

Backwards compatibility considering, eg, serving a cgi (they are 
h1-only) on h2 is very different than "an H1 server <-> H1 client", 
since with the latter I can just send the chunked output of my cgi and 
the "chunked" TE header it produced without further processing.

 >          transfer encoding defined in Section 4.1 of [RFC7230] MUST 
NOT be

... I have to sit there and remove the chunk-related headers and chunk 
headers spread through the cgi output at my server before serving them 
on h2.

The points here are:

  - a feature that was in use with a previous version of the protocol 
became a MUST NOT on a later version

  - there are more natural ways to get the same job done in the new 
protocol and the newer protocol was simplified by refusing the old way

  - people who didn't use the feature only gain from a simplified spec. 
People who do use it have to pay some penalty to deal with conversion to 
the new way.

  - what was simply excluded doesn't have to be considered, and is not 
mentioned normatively in the rest of the h2 RFC after it was told it was 
now a MUST NOT

  - this seems it will often be a better way than "extensions"

-Andy

> -=R
> 
> On 12/13/18, 1:16 PM, "Andy Green" <[email-masked]> wrote:
> 
>      
>      
>      https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7540&d=DwIDaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=S1g6ha9CpTA_Q4qLFdkC4IqyIqO92CPYIU_FVAbgbCc&s=2O2H8mIWhv13a6k21EfsZfgBEc0CkI7hdbGR3MpTDnM&e=
>      
>      >>>      <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.w3.org_Archives_Public_ietf-2Dhttp-2Dwg_2014JanMar_0396.html&d=DwIDaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=S1g6ha9CpTA_Q4qLFdkC4IqyIqO92CPYIU_FVAbgbCc&s=s9UeHNFzjife2ro6nGsKtN8c-_Ivc2o7SgcFWWa0ZPk&e=>,
>      >>>      etc.____
>      >>>
>      >>>      __ __
>      >>>

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 14 Dec 2018 18:21:14 +0900

IIUC, transfer-encoding has never been part of the semantics of HTTP.

RFC 7230 states that "any recipient along the request/response chain
MAY decode the received transfer coding(s) or apply additional
transfer coding(s) to the message body, assuming that corresponding
changes are made to the Transfer-Encoding field-value". Therefore,
replacing it with frame lengths in H2 was fine.

OTOH, trailers are part of the semantics of HTTP. Not forwarding them
is an interoperability issue. We should encourage people to fix the
bug. Making trailers an option would have the opposite effect; it
would encourage the proxy developers to not support trailers.

-- 
Kazuho Oku