WebSocket Binding

[benfrancis]

Would it make sense for there to be a WebSocket Binding document?

The WebSocket protocol is a bit unusual in that whilst it has its own URI scheme and defines things like an opening handshake and data framing, it relies on the definition of sub-protocols for any useful communication.

The current draft of the Bindings Registry document says that in a binding document "There MUST be at least one operation mapped to a protocol message/vocabulary term."

Because WebSockets lack any semantics of their own it is difficult to imagine what vocabulary terms would be useful. As far as I can tell the only useful metadata you can provide for a WebSocket endpoint in Form in a TD is the subprotocol member, which is already a first class member of a Forms. It therefore seems impossible to satisfy this requirement without defining a sub-protocol to provide the mappings.

[benfrancis]

Proposal: Adopt the Web Thing Protocol as an official WebSocket Binding for WoT

The W3C Web Thing Protocol Community Group (of which I am the Chair) has recently published a first draft of the Web Thing Protocol WebSocket Sub-protocol, as a dedicated real-time protocol for the Web of Things.

The charter of that group says that the specification is intended to eventually join a standards track at a standards body such as the W3C or IETF. Whilst I realise that Binding documents will probably be Group Notes rather than W3C Recommendations and are therefore technically not standards track documents, I wonder whether a possible path for standardising the Web Thing Protocol could be as a Binding Document under the W3C WoT Working Group?

A WebSocket Binding document could start by explaining how WebSockets can be described in Thing Descriptions in general, by formally establishing a mapping between the subprotocol member of Forms and the Sec-WebSocket-Protocol field in a WebSocket handshake.

It could then go on to define the Web Thing Protocol as a dedicated sub-protocol for the Web of Things which can be opted into by using "subprotocol":"webthingprotocol". Things could choose to use other sub-protocols, but by defining a sub-protocol inside the Binding document it would satisfy the requirements of being a valid entry in the Bindings Registry.

Just an idea.

[egekorkan]

From my point of view, it would be a Web Thing Protocol Binding. Indeed it is a bit special so some requirements may not apply directly, to be discussed. Some thoughts:

• It should be possible to have other WebSocket bindings. Especially relevant for MQTT over WS, CoAP over WS and probably many other ones.
• We need to discuss what is a binding for "socket" protocols, also relevant for stuff like JSON-RPC. The mapping is not a method but more the message format. Maybe the binding for readproperty is simple what is contained at https://w3c.github.io/web-thing-protocol/#readproperty . Also see the editor's note under https://w3c.github.io/wot-binding-registry/#entry-format

[benfrancis]

@egekorkan wrote:

From my point of view, it would be a Web Thing Protocol Binding.

I thought you might say that, but...

Maybe the binding for readproperty is simple what is contained at https://w3c.github.io/web-thing-protocol/#readproperty

I don't think that really makes any sense because it implies binding an operation to a generic message format but the message format is already specific to that operation. The binding really has no value.

Somewhat uniquely for the Web Thing Protocol (which is designed specifically and only for the Web of Things), if there is already a Web Thing Protocol specification then a separate Web Thing Protocol Binding document has exactly zero value. The sub-protocol specification already stands on its own using the sub-protocol mechanism, which is an integral part of using WebSockets and a first class member of Forms in a TD.

I just thought that if the Web Thing Protocol specification was (part of) the WebSocket Binding document (not as a default sub-protocol, but a built-in sub-protocol) then the WebSocket Binding would actually have a purpose, and the Web Thing Protocol could be a really neat first-class citizen of the Web of Things. Maybe a crazy idea.

It should be possible to have other WebSocket bindings. Especially relevant for MQTT over WS, CoAP over WS and probably many other ones.

I agree that should be possible, there's just not much for a WebSocket Binding document to do in this case since it's just wrapping other existing bindings in a WebSocket.

Also see the editor's note under https://w3c.github.io/wot-binding-registry/#entry-format

Aside: Big -1 from me for a protocol member in Forms, since that's the whole point of URI schemes and the defining characteristic that puts the "Web" in Web of Things.

[egekorkan]

I don't think that really makes any sense because it implies binding an operation to a generic message format but the message format is already specific to that operation. The binding really has no value.

No matter what we say in the specs anywhere, a binding always happens. So in this case, you are still binding, just slightly different than a WoT-agnostic protocol like HTTP. I don't know how to handle WoT-aware protocols in the binding registry.

I just thought that if the Web Thing Protocol specification was (part of) the WebSocket Binding document (not as a default sub-protocol, but a built-in sub-protocol) then the WebSocket Binding would actually have a purpose, and the Web Thing Protocol could be a really neat first-class citizen of the Web of Things. Maybe a crazy idea.

I don't think this is crazy ;)

I agree that should be possible, there's just not much for a WebSocket Binding document to do in this case since it's just wrapping other existing bindings in a WebSocket.

I agree, the binding document would be very lightweight.