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

[Takeshi Yoshino <[e-mail]>]

Thanks for the comments, Loïc.

On Thu, Oct 20, 2016 at 7:11 PM, Loïc Hoguin <[e-mail]> wrote:

<snip>


> 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. https://www.ietf.org/mail-archive/web/hybi/current/
msg10347.html).

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.

Until https://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-00,
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.

<snip>