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

Wenbo Zhu <> Fri, 28 October 2016 01:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 96BA3129440 for <>; Thu, 27 Oct 2016 18:09:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.451
X-Spam-Status: No, score=-7.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gyBgi0hb6uTp for <>; Thu, 27 Oct 2016 18:09:14 -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 75459129406 for <>; Thu, 27 Oct 2016 18:09:14 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1bzvbV-0004VG-A3 for; Fri, 28 Oct 2016 01:05:05 +0000
Resent-Date: Fri, 28 Oct 2016 01:05:05 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bzvbN-0002uS-0E for; Fri, 28 Oct 2016 01:04:57 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <>) id 1bzvbG-0001tE-Jh for; Fri, 28 Oct 2016 01:04:51 +0000
Received: by with SMTP id n202so80840836oig.3 for <>; Thu, 27 Oct 2016 18:04:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8H04CStOoIIAjWYBRl46OZ75fDfyAjMeBb8zdh8t7VI=; b=WuHQ4oF1M0K3nZqQVKI9mBekHbHRL32PEoK/M09dvga5JwAYcLyIOsSzIZ++jXM/Zp e7Ao/kPoiGI0pkZnizbH0EfIE1FxLeXgMCGUsnmmtZ0Ohd1zJ2vvVgHn3WICqj62ZdUO PTBbe/ui0ES55j42ZfvreyLzXJiq/AsPFDp3a2/SJvYccf6q6V4wdFS8rFoqUU+xnJpc 7adDIjLvSvDlddCANc/xePtH1P2VSrAAyv68jEIShU5zRHctLnCD79TWU711M3/BK7Zr 2rfRQEcg+tY1Xr8tugDtxnwS8oHYNZeaKAN7fqBADTVCjXtBja1/fgQv17u/1Es2XIyA NHuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8H04CStOoIIAjWYBRl46OZ75fDfyAjMeBb8zdh8t7VI=; b=FPRUpsZnHtf5dw8SZF9fxKdacN5hdrYdhQjiP6l2U9ZmBi/sXBjRX9mnF24wvXlMd3 o1h0oEvdJg+RXI95WbTS/nGFIwpqQsjGjTCGisxZxqOCxb4+GkDltmPnFw8xu/P+D+uv mqSaISsfK6QaBPxlM5wj1cu37/3MeDhnZyzjWU6YyK9/fc37tcC76+3/OJqpd9arstcD 8t4EGiKKEUnzvYhSPLOml0XvqX3aw/1TTsehKk36e8aoqw+cmhfkf2Rnzi7iA3UeLIUr AZ3Rf5onlKiw0RAaA5AQ7PF+PitRtMZJ4o5ZbYi6UISP1sBzfmIzmAMZXEmT59iaNerS cAUw==
X-Gm-Message-State: ABUngvcwMCvZTKEqFV/fr86wadgmL4KcOnZOmpXk8abZZRx0TXGN3Xj47bBF8tVuRO3DGLgGHZkDF3RHEWiognXl
X-Received: by with SMTP id h11mr9509833ioi.55.1477616663899; Thu, 27 Oct 2016 18:04:23 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 27 Oct 2016 18:04:23 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Wenbo Zhu <>
Date: Thu, 27 Oct 2016 18:04:23 -0700
Message-ID: <>
To: Loïc Hoguin <>
Cc: Takeshi Yoshino <>, " Group" <>
Content-Type: multipart/alternative; boundary="001a113f9d865e131b053fe270cd"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-6.1
X-W3C-Hub-Spam-Report: AWL=1.021, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.411, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1bzvbG-0001tE-Jh 8c5a0e2634abe70c5eb635d5c16eafad
Subject: Re: WiSH: A General Purpose Message Framing over Byte-Stream Oriented Wire Protocols (HTTP)
Archived-At: <>
X-Mailing-List: <> archive/latest/32694
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Thanks for the feedback.

On Fri, Oct 21, 2016 at 9:34 AM, Loïc Hoguin <> wrote:

> 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
> encoding.
> 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.
Agreed. It's also unclear how to apply a single suffix to text/binary

> 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.
It's also possible to have a non-web-stream request with a web-stream
response (POST).

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

> * The HEAD method behaves as usual. The PUT method is probably not
> compatible with doing this. PATCH and DELETE are not compatible AFAIK.
Not sure why a PUT/PATCH request can't have a streamed body.  I don't think
we want to over-spec how to use HTTP with this media type (which is not the
only stream-able media type either)

> <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