AW: Seeking WebSocket proposal team

Dear Robert

This solution was not used to integrate services of third party companies which were mostly SOAP and REST based. Solution was used as an internal message format for routing between various endpoints and where there was a freedom of defining AMQP and WS message format.

Okay, thanks. As you might have noticed I am trying to get some experience reports on using WebSockets in particular in a cross-stakeholder setup.

In my opinion, it will be very hard to define “the missing bits” for WebSockets (i.e., an application protocol) that will satisfy everyone. It is not impossible, but the W3C WoT is the wrong place in my opinion to standardize protocols.

CoAP over WebSockets and CoAP message format in general meets our described requirements as well. Only complain I would have is weird mapping of actions and subscription requests to limited set of CoAP methods. But this is matter of opinion and semantic cleanness with no practical limitations.

Yes, in CoAP the Observe functionality is designed as an optional extension (it is the “Observe Option”) that transparently falls back to a normal GET, which can then be compensated by a client through polling. A takeaway is probably that the WoT interaction model (Properties/Actions/Events) should provide an explicit subscribe call. I guess MQTT-over-WebSockets would be even a bit more “complainable”, since there it is even harder to map distinct interactions to only publish and subscribe.

Overall, I read that you would agree that we would require the definition of an application protocol that we speak over WebSockets. For me, it would be interesting to get more opinions on how to tackle this call for a WebSocket binding. Would people agree to standardize something as an RFC or whatever or will everyone push for their current inhouse solution?

Best regards
Matthias