Re: Lifting HTTP/3 Features into Extensions

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" <>
To: "" <>
Cc: "Ian Swett" <>; 
<>; "" <>; 
"Ryan Hamilton" <>; "" 
<>; "" <>; 
"Lucas Pardue" <>; "QUIC" <>; 
"Martin Thomson" <>; "" 
Sent: 13/12/2018 10:12:39 AM
Subject: Re: Lifting HTTP/3 Features into Extensions

>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.
>On Wed, Dec 12, 2018 at 10:43 AM Mike Bishop <> 
>>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 
>>From: Ian Swett <>
>>Sent: Wednesday, December 12, 2018 9:27 AM
>>To:; Roberto Peon <>; 
>>Ryan Hamilton <>; Jana Iyengar <>; 
>>Mike Bishop <>; HTTP Working Group 
>><>; Lucas Pardue <>; IETF 
>>QUIC WG <>; Martin Thomson <>; 
>>Kazuho Oku <>
>>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 
>><> 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 
>>> > 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 
>>> > benefits years after standardization.  Push might actually benefit 
>>> > being an extension, because then potential improvements(ie: 
>>> > 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 
>>> > 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 
>>> > > > 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 
>>> > > equivalent.  One is simply fiddling with the way data is framed 
>>> > > is not visible to the application.  The others are HTTP/2's 
>>> > > features.
>>> > >
>>> > >   - Dmitri.
>>> > >

Received on Wednesday, 12 December 2018 23:50:49 UTC