Hello Matthew Thank you for your constructive input, and sorry for the late reply. I'll try to respond to your questions, comments and doubts one at a time:
> This specification was pending acceptance by the council. I have taken the > decision to block its publication for now, until some further discussion has > taken place. > > Any technical points made below are based on my current understanding, > someone correct me if I am misunderstanding anything. > > Although the title and text reference sensors heavily, the document is > primarily about a way to delegate trust to a third-party (which the document > calls the 'provisioning server', but I shall simply call the authority). This is a valid point. I've received this comment from many, both within the XSF community as within the IEEE/IEC/ISO WG. So, I've renamed the files and most references made to sensor networks to the more general term: Internet of Things. However, provisioning is a well-known and accepted term. It's main use case is to allow for easy configuration of existing and new services in networks in general, and in this case in Internet of Things in particular. I've updated the introduction to the XEP, to better explain what provisioning means, and what is required by it to work in Internet of Things: 1) What Things knows what Things 2) What Things can read data from what Things, and what data. 3) What Things can control what Things, and what parts. 4) Control of Users in the network. 5) Control of Services in the network. 6) Control generic boolean User Privileges in the network. > For any given action that an entity is requested to perform by an actor, the > entity may present the authority with the actor's credentials and the action > they wish to perform. The authority can either allow or deny this action. The > actor's credentials can be anything from a JID or IP address to a physical > location (for example if the actor is a physical user). This is true only for some cases (those controlled by (6) in the list above). Many operations in Internet of Things are not simple Boolean privileges (either you have it or you don't). Example: Probably the most common use case is to read data from a device, perhaps a sensor: In this case, the question is: Can ThingA read data from ThingB (true/false), and then what data fields (non-boolean)? Converting the latter into a sequence of Boolean access requests will be completely unscalable: Consider that the Internet of Things will probably contain tens, hundreds or thousands of times more clients than human users (Ericsson estimates 50 billion connected Things by 2020), each Thing may have hundreds of fields. If each time a new read-out is requested that would generate one question per field to read, the entire communication process would spam the provisioning server and would be both unpractical, unscalable and impossible to practically implement. So, for the Internet of Things, (2) and (3) are vital. > As far as I can tell, this one protocol flow covers most of the cases > described in the spec (even though it currently uses a slightly different > protocol for each separate case). It only covers (6) really. This is however, a very important use case for services in Internet of Things, but it is not sufficient. > I believe the spec would benefit from being more general. We don't currently > have a protocol for this in XMPP. Sensors need it, other people need it, and > it would receive more widespread usage and review if it were not > sensor-specific. I've generalized it by removing the Sensor Network part, which might have been too restrictive, and changed it to Internet of Things, which is very general and generic. Some might think it is still not generic enough, but compared to other XEP's that have been published providing specific solutions (like multi-user chat, social networking or micro-blogging), I believe the concept of Internet of Things should be sufficiently general to be accepted by the XSF. By its size it has the possibility to dwarf other use cases, at least when it comes to number of clients, but possible also in number of implementations, and this in a not too distant future. > This same thought applies to many of the other "sensor" XEPs that are really > not about sensors. EXI for example - no mention of it belongs here. I suggest > that the ideal solution would be a single informational XEP that describes > how sensor networks can employ XMPP - which XEPs they should use, and how. > The glossary and table of XEPs from each of these sensor documents would then > live there, and there only. One such XEP is already in the making: Interoperability. It will explain how different XEP's are used in different cases to maximize interoperability. I've also, as stated above, generalized the concept of sensor networks lifting it into the realm of Internet of Things. I think one XEP describing Internet of Things would have no practical use, it's simply too big. However, Joachim is building a site where these documents will be discussed in more detail. He is also planning to write information about this in the XMPP wiki. I've left these references for the time being in the document, since I believe they have a value being there, informing interested parties of other XEPs relating to Internet of Things. It should not be sufficient reason to block the XEP from being published. However, if this item blocks the publication of the XEP, I will of course remove it. > In general the XSF is good at protocols, few of us know anything of the world > of sensors or any other niche that XMPP finds its way into. I think it would be best to keep working on good reusable protocol building-blocks, and not get distracted too much by working on single-use protocols and specifications. > > I'm happy to help with transformation of this spec, or creation of a new one > to meet these criteria. > > Regards, > Matthew We are of course also happy to help with any information regarding Internet of Things (and also Web 3.0) and related technologies. If you have any questions, I'm happy to answer them both privately or in this mailing list. The standards list did not allow me to attach the new version of the document. I'll mail the new version to Peter Saint-Andres in hopes he updates the inbox. Anybody interested in the new version meanwhile, can view the latest version on Github: http://htmlpreview.github.io/?https://github.com/joachimlindborg/XMPP-IoT/blob/master/sensor-network-provisioning.html Sincerely, Peter Waher
