# SOLIOT--Decentralized Data Control and Interactions for IoT
## 6 Mapping and Interaction Model
### Protocol Bindings
#### 6.3.2 MQTT and SOLIOT Events  
Different to CoAP and HTTP, MQTT is a message-based protocol and event-driven. While it is possible to realize all listed interactions through explicit descriptions in the message body--for instance, a READ request could be encoded as an especially formatted JSON attribute--such an approach would shift the interpretation task to every receiver of a message. The additional effort to parse and interpret the complete content before realizing its meaning seems not an efficient pattern. Therefore, a three-stage process is applied to encode messages. The first step is realized by the native MQTT method itself. PUBLISH, SUBSCRIBE and UNSUBSCRIBE define the native separation of messages and are interpreted by the message broker without regarding the rest of the message (cf. Table 6). The second step is specified by the root part of the used topic. The reserved upper-level topic _soliot_ tells the involved parties that the following message corresponds to the SOLIOT interaction semantics. The distinct interaction is then listed at the second position of the topic string. Please note that for the SUBSCRIBE and UNSUBSCRIBE calls reflect the variability with the wildcard at the second position as their meaning is already completely defined by the combination of the method itself and the _soliot_ topic itself. The data flow is also already defined at this stage. The SOLIOT servers--origin servers acting as MQTT clients--react to the unsafe interactions 'Extend' ('soliot/patch/#') and 'Overwrite' ('soliot/put/#'). These messages originate at the user agents--also MQTT clients--and must contain a valid JSON-LD object. The SOLIOT server is therefore required to also subscribe to all topics related to its own MQTT-enabled resources. These resources are placed at the third part of the topic sequence through their base64-encoded URI identifier. However, even though receiving a change request, the origin server may or may not actually change the targeted resource. The MQTT Message Brokers as proxies are responsible to handle the core MQTT methods PUBLISH, SUBSCRIBE and UNSUBSCRIBE. It is recommended that the message broker enforces encrypted communication (MQTT over TLS using default port 8883). Additional protection can be gained by maintaining access-control lists directly at the message broker and restrict access to known users. Using ACLs and user authentication at the MQTT Broker however creates redundancy with the native SOLIOT access control scheme using Web Access Control and maintaining the permissions directly at the resource. User agents, also appearing as MQTT clients, signal resource changes to the origin server ('Extend' or 'Overwrite'). This usually applies when the clients get informed by the resource itself, for instance a sensor sending a new observation. The user agent must regard the 'Extend' interaction as not idempotent, meaning that repeatedly submitting the same event will create an inconsistent state at the origin server. In addition, notifications and alarms are triggered by the origin server. In both cases, the subscribed MQTT clients are the information sinks. Similar to the update interactions, the server can use the topics'soliot/patched/#' to only send the added attributes or'soliot/putted/#' with the complete new state. In contrast to CoAP, the MQTT binding only regards the event-driven interactions. Create, Read, and Delete are not regarded as their context is state-based, therefore being more effectively implemented by either CoAP or HTTP. Furthermore, Tables 4 and 6 both do not specify the invocations of remote functions or services. Even though this functionality is mentioned by several requirement lists, the exact semantic of such remote service calls is highly use case specific. For now, the given protocol bindings for their description and execution are intentionally left open for future work. The _header_ of MQTT are not intended for the transfer of rich interaction information.