protocol negotiation, media types for binary/text messages; metadata and control messages

[wenbozhu]

Some thoughts on how to map a protocol like webchannel (or RS) atop WiSH (based on the feedback on http-wg).

protocol negotiation

1. standard Accept/C-T should work. WiSH doesn't have to define any fixed media-type parameter name for specifying the protocol.
2. application defined request/response headers
3. application defined first message (in either direction)

   data (binary) and metadata (text)

Media type for data and metadata can be specified as part of protocol negotiation, e.g. using a separate parameter.

If metadata is also a binary type, see below.

Media type for metadata, per-stream/per-message metadata

WiSH only supports binary/text messages at the framing level (with opcode)

Media type for metadata messages can be specified as part of protocol negotiation.

Per-stream metadata is a form of control message, i.e. metadata for subsequent [1...n] messages. See below.

Per-message metadata is to be delivered as part of the data message. Not used by WebChannel.

In RS, per-message metadata is allowed but optional. Maybe too much overhead? May flatten the nested structure as "metadata for the subsequent [1] message" + message

@benjchristensen

Questions

how to register and dispatch control messages explicitly?

This is missing in WiSH but required for both RS and WebChannel.

What we need here is an id for each control message (unit32), a single media type for all control messages (see above), e.g. JSON, CBOR etc, and a namespace.

The namespace could be the "protocol" / "version" string, identified as part of HTTP request/response negotiation.

how do we encode control-message ids with WiSH to denote/dispatch control messages?

opcode is too small in size (4 bits).

So control messages have to be self-identified. E.g. the first field of JSON as {"id": "1"}

For RS, it could be the c-struct defined by its current wire format.

Summary

To summarize, we want to make sure it's possible to layer a high-level protocol on top of WiSH 1) without introducing another embedded framing for metadata/control messages; 2) without breaking standard HTTP request/response (handshake) headers, if so desired.

[tyoshino]

I've marked up the OP (added headings markup)

[wenbozhu]

Still need distinguish metadata/control messages and data messages. While the media-type for control messages can be a fixed one (with negotiation), the media type for data message can be anything and may not be known to the upper-level protocol (e.g. frameworks, infrastructure layers).

Should we use RSV2 bit for this? RSV1 is for compression.

If RSV1 is not yet widely deployed, I'd suggest we use RSV1 for metadata/control messages.

We can't use opcode, which is not a bitmap; and therefore will break compatibility with the websocket wire protocol.

@tyoshino thoughts?

[wenbozhu]

Revive this issue.

Propose to use RSV2 for metadata/control messages.

[wenbozhu]

Or opcodes: text-metadata (03), binary-metadata (04)

[tyoshino]

Done by adding new opcodes #18