Re: [hybi] An _idea_ on framing

[John Tamplin <[e-mail]>]

On Mon, Aug 16, 2010 at 8:22 AM, Greg Wilkins <[e-mail]> wrote:

> your idea is the basis of the recent proposal from Ian Fette (as well
> as some others).
> If we wish to have meta data per frame, then I think having a
> meta-data length within a total frame length is a good way of
> achieving that.   However, I think we need to first agree that we need
> meta data per frame.
>

My feeling is that if we are going to try and get a base protocol out and
implemented quickly, which means leaving out use cases we know we want to
eventually support because we don't want to try and get consensus on them
now, then we need to make sure we have sufficient extensibility in the base
protocol so that we can add to it later without having to change existing
implementations.  The most recent proposal from Ian Fette has the following
extensibility provisions:

   - if no extensions are negotiated in the handshake, they will not be
   present in the framing
   - extensions may exchange arbitrary information in the handshake
   - two bits in the frame header are available for later definition for
   things that need to be very low overhead
      - if we decide the best way to support compression is on a per-frame
      basis, it seems very likely we would want to use one of these bits to
      indicate the frame has been compressed
   - 9 opcodes are available for definition in a future version of the
   standard
   - 4 opcodes are available for private use, either for experiments for
   future standardization or for permanent use if the same entity controls the
   complete path and both endpoints
   - an arbitrary amount of data may be included in each frame, in a format
   to be determined when the first extension is defined
   - additional control frame types may be defined by an extension

Regarding per-frame extension data, the case seemed to have been made
earlier that if extension data was required to exist outside of the frame,
that would require additional state to be kept for each connection.  For
example, imagine the base frame was not extended for multiplexing, then you
would have to have a concept of the current channel on a muxed connection.
 Alternating frames between two channels would require sending a "change
channel" message between each payload frame.  If instead we have per-frame
extension data, then the channel number of a message can be included in that
frame itself.

-- 
John A. Tamplin
Software Engineer (GWT), Google