Subject: Re: [hybi] Binary/Text Distinction

From: "Bob Gezelter" <[email-masked]>
Date: Tue, 16 Aug 2011 06:24:44 -0700

> 
> * Bob Gezelter wrote:
> >I agree with I?aki that the distinction between text/binary data is
> >unnecessary. Similarly, I agree with Dave Endicott's and I?aki's
> >comments about the mixing of different classes of functionality in the
> >WebSocket protocol.
> 
> Not having this distinction in the protocol would mean the information
> is lost in transit and has to be coordinated out of protocol. I know of
> no notable system where this has not caused problems. On the contrary,
> it is common practise now to design systems to maintain the distinction,
> new programming languages for instance typically have dedicated types
> for binary data and separate types for text data.
> 
> If you want this to be reconsidered, show us systems where the need to
> convey this meta data out of band has not lead to problems and has not
> lead to complaints about how unwiedly use of the system is; or systems
> where rates of both are very low, or systems where this distinction is
> maintained where that has lead to something worse.
> 
> Note that the general expectation is that WebSocket-based protocols do
> not enjoy the level of coordination, documentation, standardization, we
> would expect of TCP-based protocols. With TCP you might say "Oh, HTTP
> will handle that" (and HTTP might say media types handle that) but the
> asumptions are do not involve standardized lower levels in the same way.
> 
> JavaScript applications are a primary target for the protocol. In JS,
> the distinction between text and binary data is maintained through its
> data types. Your argument is that instead of letting computers maintain
> the distinction, humans should expend extra effort to re-establish it.
> I understand not liking the distinction, but that doesn't make it wrong.
> -- 
> Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
> Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
> 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Bjoern,

On the contrary, I am not suggesting that the information be
out-of-band. It is properly the responsibility of the applications layer
that is the client of the WebSocket protocol transport layer. It is true
that in many small applications, the "applications layer" protocol is
nothing more than an informal agreement between developers, but it is
quite real. 

In the context of the base, often referenced, WHATWG WebSockets API, the
mode question can be addressed by API to API communications at session
establishment. While I recall many comments about the UTF-8 mode being
"necessary" to accommodate the Websockets API JavaScript-based
limitations, I do not recall any arguments that it would be appropriate
to switch modes between text/binary on a record-to-record (or
frame-to-frame) basis. Thus, the inclusion of that information in every
quantum of information is both redundant and potentially dangerous, in
that it clearly cannot be relied upon.

Looking at the rest of the Internet protocol stack, one only see
declarations of binary/text content in contexts such as FTP, where the
declaration is needed to permit (or suppress, depending upon your
perspective) formatting conversions at either end of the connection. As
one who was around early in the Internet, when character codes and file
formats were far more diverse, it was regrettably eminently necessary. A
similar set of declarations exists for TELNET, for similar reasons. 

A transport or network level protocol without need for code conversions,
has no need to make any statements about the contents of the bit stream
that it is carrying as payload. Control frames and channel (subchannel
in the mux case) initiation dialogues are a different matter, and in
that respect I do not disagree with the IETF standard of using UTF-8 for
that administrative traffic.

If the WebSockets API (managed by WHATWG, if I recall) wishes to
restrict the use of the WebSocket protocol to UTF-8, based upon
limitations of JavaScript, it is a question for the API. (IMHO, that
decision would be a serious misjudgement; JavaScript support for binary
data is in the ascendant, as shown by the Files API use of BLOB objects,
and the XHR2 revisions.)

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

---

From: John Tamplin <[email-masked]>
Date: Tue, 16 Aug 2011 10:16:48 -0400

> that it clearly cannot be relied upon.

Actually, it seems quite likely that both text and binary data will be
transferred on one connection.  For example, a chat program will frequently
exchange text messages (perhaps JSON) and yet also needs to be able to
transfer images and user files.

> data is in the ascendant, as shown by the Files API use of BLOB objects,

Which is exactly why binary frames are supported.

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