Re: Getting to Consensus: CONTINUATION-related issues

My ultimate preference is to keep the status quo.

Failing that, I could live with (B).

I can not live with (A).

For one, it drastically increases the complexity of implementation for
no discernible gain. This complexity comes from two sources - (1)
special-casing the implementation of one particular frame type, by
allowing for it to have a different max size from any other frame, and
(2) requiring a rollback capability in the HPACK encoder. Down both of
those roads lies the madness of subtle interop issues. Given that we've
already shown good interop with CONTINUATION, I see no need to introduce
two brand new sources of problems.

The required rollback capability that is implicit in (A) also gives us
yet another issue - the memory and/or CPU requirements to implement it.
The requirements aren't exactly pretty on desktop or server, and they're
downright nasty on mobile or other low-powered devices.

Finally, (A) explicitly breaks backwards compatibility with HTTP/1.1,
which is a horrible position to put ourselves in.
-- 
Peace,
  -Nick

Received on Friday, 18 July 2014 16:35:07 UTC