Framing and control-frame continuations

The proposal for framing is that there are always 8 bytes to read for every
frame, both control and data frames. (Thanks to Jeff Pinner for modifying
this for me already!)

Generically, this is the format of a frame.

  0        1        2        3        4         5        6        7
  +--------+--------+--------+--------+--------+--------+--------+--------+
  | Length(16)      |Type(8) |Flags(8)| Num-of-Entries-or-Stream-ID-or-ID | ->
  +--------+--------+--------+--------+--------+--------+--------+--------+

  8..N
  +========+
  |  Data  |
  +========+


   Length: An unsigned 16-bit value representing the number of bytes of
   the data field.

   Type: The frame type.

   Flags: Flags related to this frame.  Flag definitions are dependent
   upon the frame type.

   Data: data associated with this control frame.  The format of this
   data is controlled by the frame type.

For a data frame, TYPE is set to zero, and the
Num-of-Entries-or-Stream-ID-or-ID field (gotta get a better name :) )
contains a '0' followed by 31 bits of stream ID. Valid flags are:


      0x01 = FLAG_FIN - signifies that this frame represents the last
      frame to be transmitted on this stream.  See Stream Close
      (Section 2.3.7) below.

      0x02 = MSG_DONE - signifies that this frame represents the last
      frame of a message.  This is relevant for layering of message-
      based protocols on top of SPDY.



For control frames, a non-zero value will exist in the TYPE field.
The following flags are valid for all control frames:



      0x01 = FLAG_FIN - signifies that this frame represents the last
      frame to be transmitted on this stream.

      0x02 = MSG_DONE - signifies that this frame represents the last
      frame of a sequence of a run of same-type control frames.


If MSG_DONE is not set for a control-frame, then the particular
control message was unable to fit within a single control-frame.
Implementations may process the control message up to the amount
received, but MUST not treat the message as done. Implementations
SHOULD finish sending the control-message as soon as possible and when
finished with the particular control message, they MUST set MSG_DONE.


What do people think about the FLAGS/TYPE arrangement? If swapped, we
gain more contiguous reserved bits.
-=R