Subject: [hybi] example of extension with Framing Proposal VII

From: John Tamplin <[email-masked]>
Date: Fri, 27 Aug 2010 14:33:21 -0400

This is not a proposal for something we should adopt, but rather an
example of how proposal VII could be extended to accomplish something
very similar to Greg's most recent proposal.

Imagine the framing is defined as follows (other than making CMLP from
VII a reserved bit and using 7/16/63 length encoding instead of 7/63),
this is something that could be defined as a future extension of VII):

 * 1 bit - MORE - indicates this message is fragmented and another frame follows
 * 3 bits - Reserved, must be 0
 * 4 bits - opcode, defining the interpretation of the payload
     * 0=continuation
     * 1=control
     * 2=text
     * 3=binary
     * 4-11=Reserved for future assignment
     * 12-15=Reserved for private use
  * 1 bit - METADATA - if set, indicates presence of metadata before
payload, must be 0 if not negotiated
  * 7 bits - short length - length of payload (or should it include
metadata?) in bytes
  * 2 bytes - medium length - present only if short length=126
  * 8 bytes - long length - present only if short length=127, high bit must be 0
  * Metadata present only if METADATA=1, 1 or more instances of:
     * 1 bit - MORE_METADATA - indicates this isn't the last metadata if set
     * 7 bits - metadata short length
     * 2 bytes - metadata medium length - present only if metadata
short length=126
     * 8 bytes - metadata long length - present only if metadata short
length=127
     * 1 byte - metadata code, initially all reserved for future
definition / private use
      * n bytes - metadata content, defined by metadata short/medium/long length
   * n bytes - payload data, as defined by short/medium/long length,
interpreted according to opcode
     * opcode=continuation - append to previous frame
     * opcode=control:
        * 8 bits - control type
          * 0=close
          * 1=ping
          * 2=pong
          * 3-0xBF=reserved for future assignment
          * 0xC0-0xFF=reserved for private use
        * remaining payload bytes interpreted according to control type
     * opcode=text - UTF8 text
     * opcode=binary - unspecified binary blob

Note that the reserved bits could later be allocated to the opcode if
we ran out, or they could be allocated to other needs.

So I believe this accomplishes the same thing that Greg's suggestion
does, in the context of the current proposal which seemed to have good
support in general.  Some examples:

Simple text:
   0x02 0x15 "Hello wonderful world"

Fragmented:
   0x82 0x06 "Hello "
   0x80 0x0A "wonderful "
   0x00 0x05 "world"

Total message length as a metadata extension, code=0xCD with the
length in 8 bytes
   0x82 0x86 0x08 0xCD 0000000000000015 "Hello"
   0x80 0x0A "wonderful "
   0x00 0x05 "world"

MIME-type metadata extension, code=0xCE
   0x82 0x86 0x0A 0xCE "text/plain"
   0x80 0x0A "wonderful "
   0x00 0x05 "world"

Multiplexing extension, defined as opcode 0x04, with the payload being
a 16-bit stream ID and the actual message being muxed (probably would
be more sophisticated than that)
   0x04 0x13 0001 0x82 0x06 "Hello " 0002 0x00 0x05 "world"    (note
two separate streams)

Per-frame compression, if done by opcode of 0x05 rather than a
reserved bit (storing the original opcode as the first byte in the
payload)
   0x05 0x04 0x02 792FC3

Per-frame compression, if done by allocating the first reserved bit:
   0x42 0x03 792FC3

So, I don't agree that the extension mechanism has to be defined in
the base protocol in order to accomplish what you wanted.

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

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 28 Aug 2010 08:45:44 +1000

John,

This is great.  Semantically your frame and my frame are both

   flags op-code frame-length *( meta-data-length meta-data-code meta-data) data

except I didn't have flags. Other differences are just style and I'm
happy with either style.

So the only thing I disagree with you about is your last phrase: "So,
I don't agree that the extension mechanism has to be defined in the
base protocol in order to accomplish what you wanted" ?  Surely you
have just defined a meta-data mechanism, which is obviously a core
part of the extension mechanism - add some governance conventions and
we're done!

cheers

---

From: John Tamplin <[email-masked]>
Date: Fri, 27 Aug 2010 19:00:23 -0400

> part of the extension mechanism - add some governance conventions and

The point was that what you want is possible with the base framing
proposal, so we don't have to define it before agreeing on the base
framing.  Perhaps we can get people to agree to the metadata model,
but previously it seemed a contentious subject.  That is why I would
like to get agreement on the base protocol, knowing that it can be
extended to meet the various ways people have in mind of extending it,
and then move on to actually designing exactly how it would be
extended.