[IOT] An implementer's review of the IoT XEPs

CC'ed to standards@ since I think it is of general interest. But please keep the discussion in the iot(a)xmpp.org mailing list. I enjoyed working with Rikard in the past few months, implementing the Internet of Things (IoT) XEPs in Smack [1] and developing a prototype App for Android using the XEPs. The XEPs involved where - XEP-0323 - Data - XEP-0324 - Provisioning - XEP-0325 - Control - XEP-0347 - Discovery What do you expect from XEPs for IoT? I've asked this question many people in the last few months, and received a broad range of answers, including "Do we need XEPs for IoT?" and "I don't know!". The Provisioning and Discovery XEPs are the most interesting ones regarding this question. The IoT XEPs introduce the concept of *friendship* between things. Friends of things can make use of them, e.g. reading out their data or remotely controlling them. Thanks to the fact that XMPP is federated, a thing from one manufacturer could become a friend of a thing from a different manufacturer. This is described in XEP-0324 - Provisioning. Furthermore a thing can be owned by an XMPP entity. It can register itself with a registry, so that other things can find it. This is described in XEP-0347 - Discovery. Now, one key issue that the XEPs try to solve is that a thing — think of the light-bulb next to you — can not decide on its own if another thing is his friend or not. So, if the thing receives a friendship request, it basically proxies the request to its provisioning server (PS), which will wait for an decision from the thing's owner. This process is described in the Provisioning XEP and is basically a proxy mechanism for XMPP subscription requests. And here lies one of the issues we need to discuss. The concept of friendship is a fundamental building block of the IoT XEPs, yet it is nowhere formal specified what friendship actually is in terms of XMPP. The XEPs appear map friendship between things to subscription states between XMPP entities, but they do not specify if friendship is a symmetric relation or an asymmetric one. XMPP subscription states are asymmetric: Just because I'm subscribed to your presence, it doesn't mean that your are subscribed to mine. I believe that the IoT XEPs assume that an thing is a friend if both are subscribed to each others presence. But do we really want that? I think the answer must be 'no', because things are (usually) not interested in the presence states of their friends, and so, we should avoid the overhead introduced by presence notifications where possible. Think of a thing with many friends: If the thing is subscribed to the presence of its friends, it will receive a large amount of presences. We definitely need to discuss this. While implementing we also discovered that the XEPs do not discuss an important protocol flow. One of the test scenarios I implemented in Smack consists of a provisioning server (PS), a thing, a owner and an XMPP entity trying to become a friend of the thing (the 'requestor'). The requestor sends a subscription request to the thing, in order to befriend the thing. Now the thing asks the PS whether or not the requestor is a friend and the PS will immediately return that the requestor is not a friend, because there was no decision from the owner yet. Here ends the story in the XEPs. In our scenario, the owner will eventually accept or reject the friendship request in the PS's web interface. But how does the requestor get notified about the owners decision? Possible XEP-0324 § 3.2.4 — but do we want the requestor to act on recommendations send from arbitrary JIDs? We also need to discuss this. My general impression is that the current IoT XEPs are to large and to complex. It reminds me of the XEP-0136 Messaging Archiving situation, where this big and complex XEP got not much traction because it is so heavyweight and hard to implement. And now we have XEP-0313 Message Archive Management, which is simple, covers most uses cases and is easy to extend, thus allowing the missing use cases to be added on top. We should think big, but write simple and modular XEPs. I started an alternative draft to the IoT XEPs, called "Simple IoT" (SIoT). It's not really meant for submission, just to have a basis for discussion. You can find it at http://geekplace.eu/xeps/xep-siot/xep-siot.html I believe that XMPP has much to offer for IoT. But I think there is a little bit room for improvement when it comes to the IoT XEPs as they are now. What follows are the polished notes I took while implementing the XEPs. General ======= The XEPs are written in style which possible assumes that examples are normative: Some sections consist mostly of figures and examples. The IoT XEPs need more normative texts. XEP-0323 - Data =============== The data read scheme out should follow the scheme we re-introduced in XEP-0313: Message Archive Management: IQ-request → data1 → … → dataN → IQ-result. This would allow to remove the 'done' attribute and this scheme is a little bit easier to implement. I going to repeat myself, because I said this in MAM thread years ago: I believe we always should use this very scheme when requesting data which we expect to be delivered by multiple stanzas. Timestamp is not using XEP-0082: XMPP Date and Time Profiles. Why does it not re-use XSD data types? (SenML [2] also seems like a potential candidate. Haven had time to look into it though.) The 32/64-bit integer types: Are they signed or unsigned? I shouldn't be required to look in § 10. XML Schema to find that out. Example 7 shows an IQ send to a bare JID. This is likely meant to be an IQ addressed to a full JID. It's unclear if things without a node are allowed. XEP-0324 - Provisioning ==================== § 3.1.1 "…if the provisioning server is not available in the roster of the device…" This falsely mixes the existence of an roster entry with presence subscription. But the XMPP Roster and Presence Subscription are two (mostly) orthogonal concepts. You can have a presence subscription established without a related roster item, and you can have a roster item without being subscribed. § 3.2.2 "Any resource information in the JID must be ignored by the provisioning server." Some XEPs of the IoT XEPs go with a different approach of explicitly disallowing the JID value to be a JID with resourcepart. I suggest consistency and I would favor the approach of explicitly forbidding the JID to contain a resourcepart instead of ignoring the resourcepart. § 3.2.4 "isFriend(jid) optional, for security" There is no gain in security if the Device asks the provisioning server if it really should add the JID as friend. If an attacker is able to spoof messages with a 'from' JID of the provisioning server, then he is very likely also able to spoof IQ replies too. § 3.5.1 Example 20 uses a bare JID for IQ. Also why isn't the response just an empty IQ result? XEP-0325 - Control ================= Why should we us this instead of XEP-0050: Ad-Hoc Commands? I've seen people controlling their 2015 home automation system (Homematic) with an very old Psi version using XEP-0050. Ad-Hoc Commands and Data Forms are a key strength of XMPP. § 3.2.2/3: The 32/64-bit integer types: Are they signed or unsigned? I shouldn't be required to look in § 10. XML Schema to find that out. § 3.1.2: Can we have an empty result IQ instead of an empty <setResponse/> result? § 3.1.2 and § 6.2: Why put 'xml:lang' in <set/> instead of simply in <iq/>? XEP-0347 - Discovery ==================== § 3.9: Claiming a thing: Why are 5 values required to claim a thing, when a tuple of ID and Key would be sufficient and provide the same security guarantees? Do we really want the user to enter 5 strings, every one adding another error source, in order to claim a thing? Or is it up to the registry/thing/whatever to decide what is sufficient to claim a thing? Claiming should be as simple as possible. I've claimed over a hundert devices in the past months and was always annoyed that I had to enter 5 values. Example 13 is missing 'cacheId'. <claimed/> has two semantic: success response to <mine/> *and* claimed notification to thing. I suggest using two different elements. Example 46 and 47: When to use a full JID and when to use a bare JID as value of 'jid' in <disown/>? § 5.2 Meta Tags: Why is 'V' (Version Number) of type 'numeric'? Is it supposed to be an integer, or a version string like "1.2.3-beta4"? - Florian 1: https://community.igniterealtime.org/blogs/ignite/2016/07/23/support-for-io… 2: https://www.ietf.org/id/draft-ietf-core-senml-04.txt