Subject: [hybi] (partial) RE: Retitled: Poor Use of subprotocol; Probably should be supraprotocol (or client protocol)

From: "Bob Gezelter" <[email-masked]>
Date: Tue, 23 Aug 2011 06:54:21 -0700

Brian,

"We can do this later" is in effect a "straw man". The Internet
community has had no shortage of such episodes. A few years ago, I was
asked to do a book chapter on the evolution of electronic mail. When I
dug into the historical record, I found that there was a reason that our
standard mail transport is "SMTP" (the "S" stands for "Simple").

Many problems were to be solved when the true mail transport was
finished, but SMTP usage hit critical mass, and the issue of backwards
compatibility raised its head. We are still dealing with the mayhem
caused by using a "demonstration" technology in production.

We are having a similar problem with IPv6. It has been many years, but
the huge mass of installed production infrastructure is VERY slowly
(emphasis on the SLOWLY) being replaced. The main stimulus being address
availability. 

Whatever finally comes out of the process is what we will be stuck with
for a good, long time, for better or worse.

There is no need for another committee, this committee can easily
bifurcate the present draft specification into two different documents. 

The last time I checked, most of the implementations of the WebSocket
protocol were not up to the latest version of the specification. 

In terms of applications protocols, there are two distinct classes:
closed and documented. Closed connections are within a pair of
applications written as a unitary entity, often between one or two
programmers working as a team. Often, the descriptions of such
interfaces are ad hoc, frequently defined, if at all, by comments in one
or both code bases. Such protocols can be widely deployed, but do not
actively involve other parties. For these, bare text or bare JSON, is
often viable.

Documented protocols involve many-to-one or many-to-many interactions
between client-based applications and server-based information providers
of various forms. These applications protocols must be strictly
documented in their own right, to ensure that software developed by
different teams can interoperate. 

I do not deny anyone the freedom to use "just plain UTF-8/binary" as
they wish. What I propose is simply a removal of the UTF-8/binary bit
(currently implicit in the OpCode) to part of the payload. and the
corresponding small change to the current libraries. 

My background in 35 years of systems internals and network-stack
programming informs this belief, I have spent far too much of my time
and client's money correcting this type of semantic mixing. The
transport component has no need for the type differentiation (even less
than previously, JavaScript now supports typed arrays).

User programs have to define the contents to the extent that they find
appropriate. A distinction between binary and UTF-8 records in WSAPI is
reasonable, but it does not need to go lower in the stack than that.

- Bob Gezelter, http://www.rlgsc.com

[origial message removed to conserve bandwidth]