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

Loïc Hoguin <> Fri, 21 October 2016 16:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6A224129413 for <>; Fri, 21 Oct 2016 09:41:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.352
X-Spam-Status: No, score=-7.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Dn4YSnQf_aww for <>; Fri, 21 Oct 2016 09:41:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 619CA1293FF for <>; Fri, 21 Oct 2016 09:41:32 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1bxcmP-0007wx-B2 for; Fri, 21 Oct 2016 16:34:49 +0000
Resent-Date: Fri, 21 Oct 2016 16:34:49 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bxcmI-0007w2-GY for; Fri, 21 Oct 2016 16:34:42 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1bxcmE-0004Ec-O6 for; Fri, 21 Oct 2016 16:34:41 +0000
Received: from [] ([]) by (mreue102) with ESMTPSA (Nemesis) id 0MS22s-1cLFGs3dj0-00TDhO; Fri, 21 Oct 2016 18:34:10 +0200
To: Takeshi Yoshino <>
References: <> <> <>
Cc: " Group" <>, Wenbo Zhu <>
From: =?UTF-8?Q?Lo=c3=afc_Hoguin?= <>
Organization: Nine Nines
Message-ID: <>
Date: Fri, 21 Oct 2016 18:34:00 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:bdfH2/ggwh6Qn0qYC+J/HmD2acfSMVwUBFGxsk+b/HmYAcD+DIA n6r+8VO5R2jrpnWCetkD2RlPcSBv3RP8hfwhHkQUOnjwnDQLYn+b7s3vhZ/9KXgO1l72KuI rpRa5Vomq4GUYWJVBXtH3yBpIzXDL4bkLo/jcBt/Aa6xIryHUkJbw4gKYK9rXo+T2SrOmGA qnBT4xI6b3Ih7UDgtC2rg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:uou8RA54BjQ=:RiU4CxshDIsu8d62vhIYl+ eaFby0J+PwnxeARiD9OXMkchb4e4d/fm5tswIN76zsNJJ51HjML3INZp5KN6THCejw4q5zliM 2nus8YM7zGupELtdN16eGVMfyUQu4FXESnL5ctbrEG2J4GMv8uELpF1/kWAsp9V0I8Myn8ENs PigXZQX8zVU0wWjYsjDHPN3YVTp0Biv1fADrO1kh6Di6KqmHFSG6W2FNI0UYF0gdcipgwuUtf YTebR7bgD6tKJ4a0yOtRwi0bwD6L4o1ytaIT/uVFAS5y98t9k/6psZO2cjSD4Yn+aJMUvLjIF DtWq615PJEPIXVQcDpTIeh91yk1Kxm0rprBOIs+aavBm1UuO3xVZXqe+1/yFeFqI+9c2r2Rd1 RdZEoYCvimOY3sClkICykndVcXYkSWbz4g/ny7pK1A+6AFwfOVnqRnBkkomY0QEbukfcBk5xM kbNGkE28xMkgcNEXLmr9qcPlB1QafvBLKwwP7k+cbJQRi77+sozi4kge8ky58ky9ip79QhGoj 9V07Agy2I3pMRtVzvDCUPM0qzOWhUvNDW+JOen9rkRJZycu6dR5Rmj4MHKdXyDtuKUqQYrASf +mboKM3dp5O08xLFHztE+evJLD1lI3Jcmn5j3KeExnjU6zENbP/lZRsQHWnnXru/Yd04XQ3Hg l4uEr091nW8rKwZyayk0p+nsYSpDWCVyl7Q6vBpueMnyqQPNTwO8zG0O2bKde+Xn6Wa/QCbg+ rFdQryhIrqrZHsON
Received-SPF: none client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1bxcmE-0004Ec-O6 0ff3a6a2918da45f11a82f0d4d99b12b
Subject: Re: WiSH: A General Purpose Message Framing over Byte-Stream Oriented Wire Protocols (HTTP)
Archived-At: <>
X-Mailing-List: <> archive/latest/32662
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 10/21/2016 03:04 PM, Takeshi Yoshino wrote:
> <snip>
> Good point. I was thinking about using the media type suffix convention
> like +json, +xml, etc. (RFC 6839, RFC 7303) when we need to represent
> the type of the messages. As the WebSocket subprotocol is required to
> conform to the token ABNF, they can be embedded into the subtype part.

The problem with "+json" and "+xml" is that they do not represent the 
type of the messages, just their encoding.

This is why we have media types like "application/problem+json" instead 
of using "application/json" for everything, where "application/problem" 
indicates what the representation contains, and "+json" indicates its 

Going back to WiSH, having application/webstream+json would only give 
information about the encoding of the response and frames bodies, not 
what they actually contain or how an endpoint should process the frames. 
We would still need more info to process it.

> Regarding negotiation, my impression to the subprotocol mechanism of RFC
> 6455 has been that it's not really necessary thing. The server and JS
> (or native application) may negotiate application level sub-protocol
> using e.g. URL (some parameters in the query part or even the path part
> can encode such info) and the initial message sent following the
> handshake response immediately without any latency loss (this topic was
> discussed at the HyBi WG sometimes e.g.
> <>).

The good thing is that it's standard. There's only one way to select a 
sub-protocol, and you are guaranteed failure (or a normal HTTP response) 
if the endpoint doesn't speak the sub-protocol you want.

The use of a media type is precious to me as it makes it possible to 
write an autonomous client. Making the sub-protocol as part of the media 
type simplifies things greatly.

There are potential issues though and a number of things need to be defined:

* The method used to perform the request is important. A client will not 
be able to speak to the server if the method is GET. Similarly, no 
communication can occur if the method is HEAD. I would advise defining 
behavior for both GET and POST methods.

* The GET method would be used to enable a server->client stream, 
similar to text/event-stream, except with binary frames supported. The 
difference being the lack of event IDs and Last-Event-ID header. In some 
cases it doesn't matter.

* The POST method would be used to enable a bidirectional stream. But 
this implies that the client uses Content-Type: application/webstream in 
the request, along with the Accept header. Otherwise the server has no 
way to know what the request body will contain. Let content negotiation 
deal with both headers, it's already well defined.

* Technically this would allow client->server and server->client streams 
to select and use a different sub-protocol. I'm not sure it's worth 
preventing this in the spec; instead let the servers decide if they want 
to allow this. But we probably need to mention it.

* By the way, don't know if consistency is desirable, by maybe calling 
it application/web-stream is better. Maybe not.

* The HEAD method behaves as usual. The PUT method is probably not 
compatible with doing this. PATCH and DELETE are not compatible AFAIK.

> <snip>
> Oh, interesting. Does this mean that on the browser a JSON codec that
> takes / produces ArrayBuffers is used?

I have no idea about browsers, sorry. :-) Not dealing with them often. 
But as far as I understand it involves using a different type to get 
binaries, yes. I have no idea how this is done.

>     Which brings me to my question: do you think it could be worth
>     adding a note to implementers that perhaps they should consider
>     optionally disabling the UTF-8 check when JSON is expected for text
>     frames?
> We could have removed the valid UTF-8 requirement of RFC 6455. This is
> something need to be enforced at the binding between the Web API and a
> WebSocket protocol stack, but not at the protocol level.
> Until
> <>,
> text frames had to be a valid UTF-8 (strictly speaking, data had to be
> 0xFF-free), but not from the version 01.
> We can choose to omit the valid UTF-8 requirement from the WiSH spec and
> instead have it in the spec for gluing WiSH with the WebSocket API in
> the future. Then, server implementors won't be explicitly encouraged to
> check validness when implementing WiSH.

That sounds like a good idea. I think it should still be mentioned in 
the protocol spec (basically explaining what you said and referring to 
another document) so that implementors are aware of the UTF-8 check and 
decide whether to implement it. If it was only written in a browser RFC 
I would most likely never have seen it, personally.

Loïc Hoguin