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

Takeshi Yoshino <> Fri, 21 October 2016 13:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D5F112971E for <>; Fri, 21 Oct 2016 06:17:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.951
X-Spam-Status: No, score=-6.951 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, RCVD_IN_SORBS_SPAM=0.5, 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 gYMCzp8XOYr0 for <>; Fri, 21 Oct 2016 06:17:10 -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 2E2A012971B for <>; Fri, 21 Oct 2016 06:17:09 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1bxZcc-000495-VK for; Fri, 21 Oct 2016 13:12:30 +0000
Resent-Date: Fri, 21 Oct 2016 13:12:30 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bxZcV-00046E-3A for; Fri, 21 Oct 2016 13:12:23 +0000
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bxZcS-0008Tg-Ka for; Fri, 21 Oct 2016 13:12:22 +0000
Received: by with SMTP id 4so238866157itv.0 for <>; Fri, 21 Oct 2016 06:12:00 -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=U0yzTii+5FDafaFr2ZTWbkMfXPgzamm6rf3DUvzS1IE=; b=IVzO0fYS404WLl0AcQIX+Wio0r1RrE5Ua1fIGKv8E8ziKT5gCzLPpDv/FfPaQa4p87 H276hh7gdlpGimoLVR9IUFEtkusITXAzr/5AE0Zg+4RKT7B7xoaBF79Rn0xNkj5yEeSR YpD74Mgz8s5FDHV/RFaQLDT+JkKcNjrAFg0Q9iNlA6mMGCExrP8vA/IprqYxrFzOMVQ/ 3jbcNJHlAmH0BkhNsMzdfmM4flMV3aT4BJMUCQ/DJKE4AW+dO4edofxP0GzfKziqoH5H nLeNigLs9UWmNdwJF63VFPLs6uw8BorZZMxE5TRBEgMEnt2RqnTqoOX4OS97hDTQLuN4 eX/g==
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=U0yzTii+5FDafaFr2ZTWbkMfXPgzamm6rf3DUvzS1IE=; b=Njg0VQNKVNVaEY39D/7fe/GaWzcjw6UB1evfAiI69lzVKXkTWcww20xMmYM0G/gn/+ TlXDrTvf3SkofFoNgLYbtydJLWSPpF9vUIxlDL96dlTrZE+uPHZ0YPWyizdrD+gh3yXS Ieej68yb12Ao4WM8Q02oe4aHEupeOGC40O0UWEamoGfddMUCZQ8DtwAwkrEHuZSCfP/B qDZuUzKqI9vUMIzA0q7lzaIPtCNa7ZFNZH8wI3u7Tlto198T/8MuSsfG4GeeMePdX2XU Qb59elAOm+R6xZBLxU6o2JEJVtmImJ9kO4VNNgM08FcPUGak12OPzvfzdR/ApwnKmOY0 ZCwA==
X-Gm-Message-State: AA6/9RnUI/xZtIcII7m7fqkWNKMrzx/hGh5iV/QjyT1UGKeV5pae/Ekie7DiNZAINa78j4h3MD82jyb9VTjGEt+d
X-Received: by with SMTP id m203mr14008000itm.31.1477055062167; Fri, 21 Oct 2016 06:04:22 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 21 Oct 2016 06:04:01 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Takeshi Yoshino <>
Date: Fri, 21 Oct 2016 22:04:01 +0900
Message-ID: <>
To: Loïc Hoguin <>
Cc: " Group" <>, Wenbo Zhu <>
Content-Type: multipart/alternative; boundary="001a113f78124bb678053f5fae67"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-6.2
X-W3C-Hub-Spam-Report: AWL=0.285, 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_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.322, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1bxZcS-0008Tg-Ka b1601b7c0a0084f34113e872a28ec7a5
Subject: Re: WiSH: A General Purpose Message Framing over Byte-Stream Oriented Wire Protocols (HTTP)
Archived-At: <>
X-Mailing-List: <> archive/latest/32661
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Thanks for the comments, Loïc.

On Thu, Oct 20, 2016 at 7:11 PM, Loïc Hoguin <> wrote:


> You write:
>    The Content-Type header value of the underlying HTTP request/response
>    message MUST be "application/webstream".
> With the current draft this media type is not enough to indicate what the
> frames will actually contain. Websocket has sec-websocket-protocol for that
> purpose. SSE allows defining event types for each events. WiSH currently
> only has payload frames with no meaning beyond text or binary.
> Maybe have the media type define an optional parameter "protocol", for
> example? Then clients can use content negotiation to request protocols they
> accept. For example:
> Client sends:
>   Accept: application/webstream;protocol=v12.stomp;q=1,
>           application/webstream;protocol=mqtt;q=0.5,
>           text/event-stream;q=0.1, */*
> Server picks the appropriate type and replies:
>   Content-type: application/webstream;protocol=v12.stomp
> Using content negotiation doesn't require extra logic which is a big plus.
> And we can still use the existing Websocket subprotocol registry, which
> will be required if Websocket compatibility is a concern.

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.

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.

But this is important to ease migration of existing WebSocket apps, yes,
and I agree that the Accept header would be one of the good candidates for
carrying it.

> You write:
>    The message type distinction by the opcode field (text and binary) is
>    kept to allow better Web support.  One of the possible use cases is
>    to use the text type for exchaning meta data encoded in JSON, etc.,
>    and the binary type for exchanging non-meta data messages.
> In practice when using JSON and where performance is a concern, I have
> seen users use binary for everything. The problem being that Websocket text
> frames must be valid UTF-8; but so does JSON. The server not providing
> functionality to disable the Websocket UTF-8 check (and JSON decoders not
> able to), users just dropped text frames entirely.

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

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

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.

> Typos:
> * Page 3: there are two "furthur" that probably should be "further".
> * Page 5: there is "exchaning" instead of "exchanging".

Thanks! I'll fix them on the next draft submission.