[hybi] Dave's Framing Proposal

[Dave Cridland <[e-mail]>]

I thought I'd name mine, saves confusion. I gave it a nice neutral  
name, too. I wanted to call it "Dave's Really Great Framing  
Proposal", but I decided not to.

First off, feature negotiation is external. Presumably we'd do it in  
the framing layer. I'd include both compression (at stream level) and  
TLS (likewise) here. I believe that external negotiation is not  
contentious. I think the latter two may be, but I'd like to have  
optional TLS as well as mandatory TLS (ie, "StartTLS" as well as  
port-based old-school).

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.

a) This frame type says if it's a leading chunk, a completing text, a  
completing blob, or a control.

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.

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.

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.

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.

6) Payload data.


I think this outlines something which:

A - Is likely to serve for the foreseeable future - it contains  
sufficient extension/expansion space to adapt as we find new  
requirements. Note I've specifically ignored multiplexing and Greg's  
MIME proposal, yet both have potential space.

B - Can be treated simply by intermediaries, particularly naïve ones.

Downside is that it's 6 octets, but I can't see an obvious way of  
avoiding this without either having a variable-length header, or  
dropping some features.

I know this will not please everyone completely, and that's okay. I'm  
more curious, though, as to whether this is likely to be workable for  
everyone if pushed.

Dave.
-- 
Dave Cridland - mailto:[e-mail] - xmpp:[e-mail]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade