Subject: Re: [hybi] Binary/Text Distinction (Hybi Volume 30, Number 63, et al)

From: "Bob Gezelter" <[email-masked]>
Date: Mon, 22 Aug 2011 14:57:18 -0700

Stephen,

I would agree with you in regards to the OSI model. It was a VERY
(emphasis: VERY) bloated specification, and was not a good example to
emulate. 

However, I was not referring to the OSI stack in terms of the OSI
protocol specifications. I was referring to the Open Systems
Interconnect Model (which long predates the standards).

There are many cases where TCP/IP took good choices, and there are more
than a few places where the choices have proven suboptimal (e.g.,
security). The consequences of these choices remain with us today. 

Removing the character encoding issue from the WebSocket protocol to a
separate small applications protocol for use between two WSAPI
instantiations over a WebSocket messaging connection would clarify the
protocol without costing efficiency.

It also allows the inter-WSAPI interchange to evolve without a need to
change the WebSocket protocol implementation or RFC, which is another
highly desirable result.

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

---

From: John Tamplin <[email-masked]>
Date: Mon, 22 Aug 2011 18:42:58 -0400

> protocol without costing efficiency.

All I see it would do is mean the protocol isn't actually useful for its
intended purpose until an additional standard were agreed upon and
implemented.  As this one has taken years, let's not double the time until
we can use it.

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

---

From: Tobias Oberstein <[email-masked]>
Date: Mon, 22 Aug 2011 16:47:32 -0700

>> protocol without costing efficiency.

Bob,

There is no "issue". An issue is a problem, and there is none.

The term "character" is ill-defined. In the context of Unicode
there are code points and encodings thereof. UTF-8 is well-defined,
so here is no issue. So I assume that what you wanted to say is like
in your earlier remarks, namely that the "issue" that you are trying
to evoke is about having 2 opcodes which differentiate payload types
into text/binary.

However, the reasoning: WS is a transport protocol, and thus should
not include payload types is not pointing to a practical problem
with WS. Where is the practical problem? What does not work with
WS today, because it has opcodes designating payloads into text
or binary?

> implemented.  As this one has taken years, let's not double the time until we
> can use it.

++1 John

Please don't open the pandora's box.

Over the weekend I started playing with FF8 on Android talking to
our servers and PC all via WS + HTML5. It's awesome, it works - today!

Bob, now, you tell me you want to take that away/break again for
months-years to come, because you find it "unclean" to have
that payload type stuff in WS. Well. That's a tough call ...