W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

Re: WiSH: A General Purpose Message Framing over Byte-Stream Oriented Wire Protocols (HTTP)

From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
Date: Thu, 1 Dec 2016 16:36:36 +0900
To: Andy Green <andy@warmcat.com>, Van Catha <vans554@gmail.com>, Mike Bishop <Michael.Bishop@microsoft.com>
CC: Poul-Henning Kamp <phk@phk.freebsd.dk>, Mark Nottingham <mnot@mnot.net>, Takeshi Yoshino <tyoshino@google.com>, Willy Tarreau <w@1wt.eu>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>, Wenbo Zhu <wenboz@google.com>, Martin Thomson <martin.thomson@gmail.com>
Message-ID: <e737791e-7c55-9b2c-714a-c9255719d581@it.aoyama.ac.jp>
On 2016/12/01 12:36, Andy Green wrote:
> On Wed, 2016-11-30 at 22:06 -0500, Van Catha wrote:

>> see more success.  The reason for this is both protocols (HTTP2 and
>> QUIC) have their own way of trammiting data frames.  Websocket in
>> this case should become an alternative frame type, basically one
>> carrying a binary payload.  All the previous baggage of websocket1
>> can be dropped like the distinction between text/binary frames as
>
> The logical ws implemention in JS needs that distinction to be carried
> over the link though, as it lets you choose and TEXT differs on the
> other end by enforcing only valid UTF-8 in the message.  So that's not
> a ws 1 wire-implementation-only type thing that can just be binned.

Yes indeed. Even if it could be binned, it shouldn't. The distinction 
between TEXT (UTF-8 only!) and BINARY may be of no concern at all to the 
transport infrastructure, but it is essential for the next layer above. 
Without this distinction, the risk that JS code monkeys get the 
conversion from text to binary and back wrong is just way too high. Even 
just not having to do the conversion by hand is very helpful, and having 
the character encoding nailed down makes different servers and clients 
much more interoperable.

Regards,   Martin.
Received on Thursday, 1 December 2016 07:37:16 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 1 December 2016 07:37:24 UTC