Re: h2 frame layout

Roy,

there have been several contributors (including myself) who have come into
the process late and looked at the framing layer and had a similar reaction
to what you have expressed.          For my own part,  I strongly argued
against the framing flags being a function of frame type and I expressed my
belief that it is a mistake to conflate the semantics of HTTP with the
framing layer.

As each of these new views has come in, it has woken up some other voices
with lingering levels of discontent towards the design and a new round of
debating some  design decisions results.   Unfortunately none of the
iterations of this pattern have been able to convince enough of the voices
here to achieve consensus to change some fundamental design decisions that
drive what has been described as the "uglyness" of the framing layer.
I think the problem is that none of the new voices have been able to
inspire an appetite for wholesale change and have instead resorted to try
to "fix" the protocol by arguing for change bit by bit or byte by byte.

So while there have been many minor improvements in the last few iterations
of the draft, I do not think that some of the fundamental problems with the
framing layer have been fixed and when new eyes look at tit they still have
a WTF moment with some elements of it.

Your own proposals represent both ends of the spectrum:

Your proposal A is just a trim of the current framing layer to send the
same semantics over 64 bytes rather than 72.  I've got no objections to
that, but note that making it look data aligned will not actually make it
data aligned unless padding is not a function of frame type and we require
all payloads to be padded to a word boundary, so I think more substantial
change is necessary to achieve any more substantial than a saving of 1 byte
per frame.   So it is a bit by bit improvement, but doesn't "fix" the
framing.

Your proposal B is a significant change of semantic.  I totally agree that
defining concepts like END_STREAM independently to frame type is a really
good idea, as this would facilitate carrying alternate semantics like
websocket and maybe even waka?    However, all previous attempts to achieve
consensus that this is something that should be fixed has failed, I think
mostly because the WG was wrongly chartered to primarily consider HTTP
semantics.   If it had been chartered to support multiple web semantics:
HTTP, Websocket and potential future web semantics, then we might have
ended up with a better framing layer that is not dependent on frame type or
HTTP semantics.

As much as I would like to see significant changes to the framing layer, I
don't think it is worthwhile reopening that can of worms unless we firstly
revisit the charter.     If essentially all we have to transport is HTTP in
it's current usage patterns, then the argument always devolves to that it
doesn't matter if the framing layer is ugly, fragile, inextensible, special
purpose etc.   We have made the mistake of trying to generalise from a
single example, so the non-HTTP parts of the protocol such as unused flags
and frame types are highly unlikely to be usable for anything that does not
pretend to be HTTP.

cheers

-- 
Greg Wilkins <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.