Re: [hybi] Framing Take VI (a compromise proposal)

[John Tamplin <[e-mail]>]

On Mon, Aug 16, 2010 at 11:27 AM, John Tamplin <[e-mail]> wrote:

> The problem I have with this approach is when you have multiple extensions
> you make a long chain to process.  For example, you want to send total
> message length on muxed messages:
>
> op=extension, ext=MUX (channel id=1, type=META_DATA(..., type=text,
> data="Hello world"))
>
> As more extensions are defined, finding the data you want gets more
> problematic.  Instead, if there is one extension data field, presumably an
> implementation could compute pointers to specific the field for a specific
> extension during the handshake when the extension is negotiated (there might
> need to be another level of indirection if variable-length per-extension
> data is supported).
>
> Anyway, if others like your proposal I don't feel strongly enough against
> it to object.
>

How about deferring the decision of exactly how to represent extensions
until later?  That would be

   - INI - 1 bit, indicates initial frame of message
   - FIN - 1 bit, indicates final frame of message
   - Reserved1 - 1 bit - must be 0, except for private use by external
   agreement
   - Opcode - 4 bits, 0=Control, 1=Text, 2=Binary, 3-11=Reserved for future
   definition, 12-15=Reserved for private use
   - Reserved2 - 1 bit - must be 0
   - Length - 7 bits, 127=uses extended length
   - Extended length - 8 bytes [if Length=127]
   - Total message length - 8 bytes [if INI=1 & FIN=0] -- all 0s means
   unknown
   - Payload - (Extended) Length bytes - interpretation defined by opcode

Later, we can decide to allocate one of the reserved bits adjacent to the
opcode as an Extension Data Present flag, as proposed originally in this
thread, or as an extra bit in the Opcode field if we decide that we want all
extensions to be defined with new opcodes (and nesting the final payload
opcode in the extension's payload).  That way we can defer deciding exactly
how extensions should be represented until we actually have an extension to
implement.

I can see rationale for your suggestion, but I still think some extensions
are ignorable (for example, an intermediary that doesn't understand the
MIME-type extension data could safely ignore it) -- maybe at the point we
define extension data formats we can define "critical" extension types which
must be understood or the message is altered vs "optional" extension types
("critical" terminology taken from the PNG spec about chunks).

Note that if we defer defining extension data, we can't move the total
message length to extension data, so I am leaving it where it is.

Would this remove remaining objections to this proposal?

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