Start list of protocols and platform dialects to describe

[mkovatsc]

We need a list of protocols that serves as input to find the vocabulary needed to have protocol binding descriptions. The list items should be prioritized in the sense where to begin; this should be based on the available information and experts to help. Overall, this will be related to the liaisons W3C WoT has.

Initial (unsorted) list to be extended:

• ("vanilla") HTTP
• ("vanilla") CoAP
  • CoAP
  • CoAP-over-TCP
  • CoAP-over-WebSockets
• OCF
  • OCF CoAP
• oneM2M
  • oneM2M HTTP
  • oneM2M CoAP
  • oneM2M MQTT
  • oneM2M WebSockets
• ("vanilla") MQTT (lets use MQTT5, since previous versions do not provide the facilities required for open, WoT-like systems (e.g., no headers for Media Type etc.)
• OPC UA
  • UA-Binary over TCP

[zhangyongjing]

Note that oneM2M also has WebSocket binding, but we could put it in the parking lot for the time being. I suggest to start with HTTP and CoAP.

[mkovatsc]

Thanks for the comment; let's still put them on the list (updated post).

[mmccool]

Glad to see this; we definitely need this list to prioritize security analysis, for instance. Could add Mozilla proposal to list. While the basic REST web interface should be straightforward, the WebSocket interface may need a little more focus.

[mjkoster]

Current strawman list from recent discussions:

• Simple CoAP
• Simple HTTP
• Events using websocket protocol
• Events using MQTT
• Events using EventSource
• OCF flavor of CoAP
• LWM2M flavor of CoAP
• Proxy Bindings for Interconnected Servient use case
• Echonet

[draggett]

WebSockets are useful for properties, actions, events and metadata updates, i.e. you should drop "Events using " before "websocket protocol".

[mmccool]

Echonet/BACnet

[mmccool]

use cases for pub-sub pattern (or eventing):

• sleeping devices (power constrained devices) Ex: humidity sensor waking up once an hour, or sending an update only upon a significant change
• reactive design pattern (software engineering) Ex: combining flows, eg for sensor filtering and triggering actions; IFTT end-user-programming
• low latency response for rare events (real time systems) Ex: alarm system; call the police, quick! Or even a simple button (eg a light switch).
• lossy events Ex: temperature updates, not all of which need to be delivered, as long as some get through once in a while
• loose coupling, especially with named topics (reader and writer are not directly connected) Ex: abstract sensor that may be generated by intermediate processing in many different ways, eg presence
• broadcast pattern (one writer, many readers) Ex: configuration update
• confluence pattern (many writers, one reader) Ex: sensor data gathering
• privacy (with named topics) - loose coupling, reader/writer do not know about each other Ex: anonymous data collection
• streaming (producer, not reader, controls timing) - writer has little memory, can't buffer indefinitely Ex: continuous sensor updates

One issue: are named topics to be covered explictly, or mapped onto resources via a CREATE/UPDATE/EVENT model? They are important to several of the above patterns.

[mmccool]

also important that we look at industrial use cases, especially where it breaks assumptions of home use cases

[egekorkan]

I will be closing this issue and moving the discussion to #92. Currently, the following protocols from the https://github.com/w3c/wot-binding-templates/issues/1#issuecomment-323921856 are done already:

• Simple CoAP
• Simple HTTP
• Events using MQTT