[hybi] Multiplexing, Binary/Text; Endpoint Identification

[Bob Gezelter <[e-mail]>]

The recent discussion concerning some of the issues raised in my blog
(http://rlgsc.com/r/20110323) has been interesting. However, my point
is and was not to restart discussion from the beginning, but to ensure
as flexible a future as possible. The WebSocket protocol seems poised
for mass adoption; significant changes following official
standardization will be disruptive and painful. Past history shows that
such changes are often all but unimplementable, a reality with no
shortage of examples (SMTP was temporary until issues were resolved,
hence the "Simple"; also see "Mythical Man Month" by Fred Brooks
concerning OS/360 architectural mis-steps).

The multiplexing discussion is of great interest, and I am certainly
not trying to steal John's thunder, but perhaps the implications of my
main points have been obscured by the history of the discussion.

Many of the points raised in the ensuing discussion of multiplexing
are significant, yet the concerns have little effect on the
specification of multiplexing at the level of the wire protocol.

My concerns do not require a complete definition of multiplexing
behavior, nor do I intend to imply that all WebSocket protocol implementations 
support large-scale multiplexing. Rather, I see it
as critical to define the structural framework within which
multiplexing is implemented. The issues of implementation can then
be appropriately resolved at a future time. These concerns only
require a modest change in the wire protocol and related parts of the
the specification (these are not suggested text, merely checklist
items):

   - Addition of two frame types:
     o Open WebSocket subChannel (endpoint ID, quota, UTF-8/binary)
     o Close WebSocket subChannel

   - Small modification to Close frame ("close all subChannels")

   - Addition to the opening WebSocket protocol handshake
     ("SubChannels: n"; baseline, non-multiplexed implementations use
     "SubChannels: 1"). From both sides, count is minimum of exchanged
     values.

   - Coalesce frame types for UTF-8/binary data into a single frame type;
     "Data" (mode is associated with the subChannel and specified in the
     Open WebSocket subChannel control frame).

   - Addition of subChannel identification to a new "Switch SubChannel"
     control frame.

I know that many prefer to implement communication schemes based upon
printable representations (e.g., UTF-8). While this is not my preferred
approach for inter-machine communications (I personally prefer binary
specifications), I have no desire to have a "Coke vs. Pepsi" dispute.
I would prefer to enable all constituencies to have their favorite flavor.

That said, I do not see many applications routinely switching back and forth
on a frame-by-frame basis between UTF-8 and binary. If that capability is
desired, it can parsimoniously be provided by implementing a "Switch Mode"
control frame (it could also be included as part of the "Switch subChannel"
control frame).

This approach also removes the need for the restriction (at the end of 4.4
in the -06 draft) that all fragments within a message must be either text or
binary. The current specification does not permit intra-message mode
switching and this proposal does not change that rule. Under my proposal
the mode of a subchannel is established at open, and can be changed.
Intra-message mode switching is not permitted by definition.

The Open SubChannel command frame type now has three minimal requirements:

   - definition of endpoint (suggestion: TAG URI of desired partner; this
     allows a wide degree of flexibility in design and implementation
     without imposing anything more than an IETF-sanctioned way to
     hierarchically distinguish names for endpoints; including explicit
     ways to define "well-known" services, should they evolve; for
     example: WebSocket.ietf.org:ftp for an ftp portal over an
     existing WebSocket protocol connection).

   - Transfer quota specification (default value permissible).

   - specifying UTF-8 or binary mode for the subChannel.

Note that the above does not discuss the "Hows" of multiplexing, it
merely establishes a framework. Different multiplexing schemes can be
used as extensions, and it is certainly possible to enhance the Open
subchannel control frame with supplemental commands specifying options.

Needless to say, the existence of multiplexing at the WebSocket protocol
level is all but invisible to the JavaScript user/developer. The modest
changes are limited to the WebSockets library-class layer.

My reasoning is straightforward. Supersetting has a very poor track
record. Unintended mutually incompatible supersetting has been the bane of
interoperability since the long before the Internet protocol suite. Defining
an architectural space with multiple viable subset implementations enable
interoperability in the long term with few side effects at the outset.

Needless to say, I will be happy to clarify any of my thoughts on the above.

- Bob
+--------------------------------------------------------------------------+
| Robert "Bob" Gezelter                       E-Mail:  [e-mail]  |
| Robert Gezelter Software Consultant                                      |
| 35-20 167th Street, Suite 215               Fax:       (on Request)      |
| Flushing, New York  11358-1731                                           |
| United States of America                    http://www.rlgsc.com         |
+--------------------------------------------------------------------------+