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

Hello Florian Thanks for the mail, and thanks for sharing your experiences. I’ll try to answer your comments and questions, one at a time. It’s called ”delegation of trust”: I.e. if the thing cannot make the decision it self, it can delegate the responsibility to one or more third parties (provisioning servers). How these reach a conclusion is not specified more than through example: To ask the owner. A learning mechanism is also mentioned, but not specified. The provisioning server keeps track of friendship relationsships. This is symmetric in the sense, that both can subscribe to the presence of the other, if they want to. They don’t need to. I’ve added a note to add a description, or definition of the friendship relationship, and how it relates to presence subscriptions. If no rules are defined, rejection is returned by default to the device, since immediate feedback is always assumed. It is also assumed the owner is notified of the action. But since the owner might respond to the action at a much later stage, that response is seen as a separate event. If the owner accepts the request, this event is informed asynchronously, as described in §3.2.4, as you mentioned. And yet much smaller than pubsub, which to many seems to be one of the cornerstones of XMPP. They are modular, that’s why they’ve been separated into 322, 323, 324, 325, 326, 347. More normative text, and less examples? Many claim the XEPs are too long. But as you say, most of the text consists of examples. Are you suggesting that using data-forms would be “easier” for transporting sensor data? And that constant polling to extract asynchronously retrieved data would be simpler? I cannot see that that would be easier using any objective standard. It also presupposes knowledge about the amount of data to be retrieved, something that might now be known at the onset of the readout. Time zones are described in §6.1. What XSD data types are you referring to? The field types available are based on the XSD data types. Regarding SenML: I responded to that comment in a previous mail. As it presupposes knowledge about the data being transmitted, it is not a suitable candidate for interoperable interfaces. It works for simple transport of data, if you control all end-points, or if end-points can be adapted to specific hardware. I meant to present the design principles behind XEP-0323 using the following presentation, at the last IoT SIG meeting: https://www.slideshare.net/peterwaher/xmpp-iot-sensor-data-xep0323 Noted. Will update that. I’ve put in the TODO list to update JIDs in examples. How do you mean? You mean in the request, response or data format? I’ve made a note do add some clarifying text regarding this, for devices that do not embed nodes. I agree on the second, but not the first statement. RFC 6121 §2.5.2. clearly states that removing a roster item automatically unsubscribes to any presence. Still, added a note, since I believe the text can be updated to avoid confusion. First, it seems to be Note 2, §3.2.1. But, it seems to be a misunderstanding. What is meant is that rules, in the provisioning server, must be based on the bare JID, not the full JID, of the device. The resource part is assumed to be a random value that can change over time. Very likely is not the same as guaranteed. I’ve made a note to update JIDs in examples. I’ve also made a note to update the clear cache result, as you suggest. There are several reasons. While having access to ad-hoc commands and data forms might be a strength, if you use a full-stack XMPP implementation, it’s not, if you have a light weight implementation, something which is expected, especially within IoT. So, the simplest use cases do not use data forms at all. It’s also possible to map control parameters and sensor data. Another reason is the possibility to execute commands on multiple nodes at the same time, as well as executing multiple control commands in the same request, as well as the added semantics available for interoperability. Noted. Yes. I’ll write that on the TODO-list for XEP-0325. If it’s better that it be placed on the iq element, then we can move it there. By setting it on the set element, I just wanted to make sure the attributed was passed on to the specific handler, regardless of underlying implementation. It’s up to the manufacturer to decide, what is required. And you should not have to enter anything. Instead, another transport method of the conceptual information from device/manufacturer to owner is suggested. The XEP mentions the use of QR-codes, for instance. The point here, is that the number of parameters used in the claim is variable, and defined by the manufacturer. All the XEP does, is require the owner to specify the same set of parameters, in the claim. Note: While from a device perspective, it might be sufficient with the KEY to perform the claim, human users are not good at identifying devices using such information. If a human is claiming multiple devices, one way to inform the user what device is actually being claimed, is by presenting humanly understandable information at the same time, together with the machine understandable information. Depending on situation, it is therefore very possible, that the manufacturer wants to add such conceptual information to the claim, to make sure the owner understands what device is being claimed. You mean cacheType? nodeId, sourceId and cacheType, are all optional, and provide 3 additional axes of identification of nodes behind a concentrator. More about these in XEP-0326. Ok. I’ll write this on the TODO list. Example 47 contains an error. Full JIDs are only used in the stanzas, for addressing. Rules and logic are based on bare JIDs. So, the jid attribute in Example 47 should be a bare JID. It’s numeric, to allow for numeric comparison. You might want to do a search for specific devices reporting a version larger than 8 for instance. You would want such a search to contain devices of version 10. Having it as a number, allows for only one decimal separator (major.minor). If (release.build) is also desired, or other information, such as beta, etc., you can always report those using other tag names. No such tag names have been specified however. Best regards, Peter