W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: Striving for Compromise (Consensus?)

From: Johnny Graettinger <jgraettinger@chromium.org>
Date: Mon, 14 Jul 2014 12:29:20 -0400
Message-ID: <CAEn92TquseLrgnE5WQof2M5=4xYBE9YMQWSkfQNb8fsGatobyA@mail.gmail.com>
To: Greg Wilkins <gregw@intalio.com>
Cc: Roberto Peon <grmocg@gmail.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
On Sat, Jul 12, 2014 at 1:56 AM, Greg Wilkins <gregw@intalio.com> wrote:

> Roberto,
> So it sounds like you don't like continuations any more than the proposers
> of "Greg et al".
> So here is a path to something that will keep everybody happy,
> Support the proposal - at some frame size >=18 <=31 bits. Then
> continuations are gone and the two down sides for you are:
>    1. Can't stream headers
>    2. We advertise a max header size (it is a frame size but the same
>    thing in proposal).
> Now once we have that in place, we look at some new proposals to address
> those concerns.
> If we want to be able to stream headers, then we can put forward a
> proposal to allow header frames to be fragmented in the same way data
> frames currently are. ie we use the end-segment flag that they already
> carry to indicate end of a header block.    Then the same framing layer
> code can be used for fragmenting data and headers.      The discussion
> around that proposal would also settle if they can be interleaved or not.
> Hpack would then be updated to work with whatever results (eg by removing
> reference set or whatever else is necessary).

This sounds an awful lot like removing continuation & header fragmenting,
just to re-add it back in later.
It presents exactly the same debate we're having now: Do we preserve the
ability to fragment headers? Do we allow the interleaving of those
Received on Monday, 14 July 2014 16:29:48 UTC

This archive was generated by hypermail 2.3.1 : Monday, 9 September 2019 17:48:20 UTC