Re: [hybi] Dave's Framing Proposal

[Douglas Otis <[e-mail]>]

On 8/5/10 1:52 PM, Dave Cridland wrote:
> As for the framing itself, rather than describe actual bitfields, I 
> thought I'd describe some properties.
>
> 1) Have a single leading octet, which has a frame type.
This tag should keep data framing state separate from bits describing 
content.  As such, at least 3 bits could be dedicated for framing state. 
Such as "start", "end", "concatenated".
> a) This frame type says if it's a leading chunk, a completing text, a 
> completing blob, or a control.
Frame type can signal initial frame, intermediary frame, and/or ending 
frame for the stream, as well as low level content descriptors.
> b) If it's a control, then some of the remaining bits are used to 
> indicate what it is, including Final Frame, Ping, Pong, etc.
The explicitly defined initial frame could always represent 
meta-information, where frames can also be concatenated within the 
enclosed message. This would keep the frame header information limited 
to using 4 bytes.
> c) There should be some bits left over (and therefore reserved, MUST 
> zero, MUST ignore).
>
> 2) A stream identifier, set to 0x01 in the version of the standard. 
> Other values MUST cause the frame to be discarded by receivers. 
> Intermediaries MUST ignore this value.
Okay.
> 3) A 16-bit, network order, extension length field. This describes how 
> much of the packet is extension data (ie, designed for the stack to 
> process) rather than payload data. This field MUST NOT exceed the 
> length of the frame's payload.
See above.  Consider the possibility of having frame concatenation, 
where the first frame always exchanges meta-information, even when given 
a zero length.
> 4) A 16-bit, network order, payload length field. This describes the 
> entire payload, including any extension data. A naïve intermediary MAY 
> therefore ignore the extension length in order to forward frames; 
> however if it chooses to refragment frames it MUST take into account 
> the extension length.
>
> 5) Extension data. Note that we need to handle multiple extension 
> data, therefore this field needs to be internally TLVed consistently.
The meta-data should also use TLV structures, but this should not impact 
the actual data payload.
>
> 6) Payload data.
-Doug