Hello Eelco. Thanks for your responses. Some comments:

...

2. There is currently no best practises in using pubsub or PEP for IoT.

Perhaps it’s time to retake the XEP-writing effort and write down some guidelines for IoT on XMPP using pubsub…

Perhaps it is. I would not mind participating.

Great! I have to retake this effort, as I mentioned. I’ll make sure to include you.

...

4. I proposed an alternative pubsub like service, that I called ‘dealer’, which acts as a IoT concentrator towards the subscribers and that would subscribe to all Things the clients would want to receive events from.

Ok, not sure I understand. Please tell me more. Would it be an entity that subscribes to data from multiple nodes, and then makes it accessible using XEP-326 to other interested parties?

Something like that except I would use IoT events (https://xmpp.org/extensions/inbox/iot-events.html) and let the ‘dealer’ optimise the subscriptions towards the ‘Things’.

In the dealer pattern the client applications, that want to subscribe to sensor data from the Things, instead subscribe to the dealer service. Once subscribed the clients receive the measurements from all the Things via the dealer. The dealer is responsible to subscribe to all the individual Things and when it receives new measurements it will instantly publish these measurement to clients that subscribed to the dealer. Sounds interesting! This immediately creates several follow-up ideas. Since you base it on iot-events, it provides a unqie way of providing tailored information to subscribers, based on different security considerations.

The first idea is a slight modification of the approach: Instead of having the dealer subscribe to all nodes. This might require a lot of administrative communication, and also a lot of monitoring/supervision for make sure it recovers from different error states. An alternative is to make a component connection (XEP-0114) and publish the dealer as a pubsub server component on the xmpp server, replacing perhaps the “normal” pubsub server. In this way, the dealer would not need to maintain all subscriptions, instead, it would be the owner of the nodes itself. Perhaps the added effort here, is comparable or less than the effort needed to subscribe to all events from a pubsub server, that as you say, anyway might be lacking in some regards. The dealer could still use the iot-event subscription architecture, and so, there would not be a need to implement that part, since it doesn’t provide subscribers to request tailored sets of data. The second idea, is a continuation of the above, but providing a “normal” pubsub subscription interface: Today, the pubsub pattern has a great weakness: It’s not possible to adapt contents based on rights for individual subscriptions. You need to publish different sets of content on different nodes, which quickly grows to infinity if you allow fine-grained control, as is the case for IoT. This not only becomes complicated, it also quickly removes any gains provided by pubsub, as the basic idea is to reduce the number of packets required for the publisher, to efficiently publish information to a larger set of subscribers. So, while one is creating a component for a new type of pubsub service above, you might build in a connection to a provisioning server (XEP-0324), or build in the same functionality in the same component, and use <canRead> to check what type of information is allowed for different subscribers implicitly, removing the need for a tailored subscription request, as well as a tailored publication, still tailoring output to each subscriber. That would lift the burden from the device, and provide a completely new type of service: Context sensitive, or individually tailored, publish/subscribe. I have thought about implementing the second idea above, myself. I think such a component might have a very important role for the publish/subscribe pattern in XMPP, and solves many of the security issues in other pubsub solutions. Would you be interested in investigating this further? A third idea, based on the second idea above is the following: Something that is missing from the XMPP pubsub model, but is available in MQTT, is multi-layered publish/subscribe. While implementing a new context-sensitive pubsub service, this might be something to add. In MQTT you can listen to a “parent node”, or wildcards, and receive events from all its (grand*)child nodes for example. Example: Consider you publish a temperature on node building/floor/apartment/room/temp1. How would you do to listen to all sensors in that room? Or all sensors in that apartment, floor or building? Or all temperature sensors in that building (leaving out other kinds of sensors)? Using a wildcard character (*) you could do this by subscribing to “building/floor/apartment/room/*”, “building/floor/apartment/*”, “building/floor/*”, “building/*” and “building/*/*/*/temp*” respectively in one go. That would provide a great way to subscribe to larger sets of contents, without having to maintain huge amounts of smaller individual subscriptions. Best regards, Peter Waher Från: Cramer, E.R. (Eelco) [mailto:Eelco.Cramer@tno.nl] Skickat: den 29 april 2015 11:10 Till: XMPP in the Internet of Things Ämne: Re: [IOT] Feedback on pubsub for IoT Hi Peter, Thanks a lot for your comprehensive answer! I agree with your view on MQTT but from discussion I’m having not a lot of organisations see federation as something that adds value and go for a short term win. You provide me with some good arguments against that :-)

2. There is currently no best practises in using pubsub or PEP for IoT.

Perhaps it’s time to retake the XEP-writing effort and write down some guidelines for IoT on XMPP using pubsub… Perhaps it is. I would not mind participating.

3. Management of pubsub nodes (manage subscribers and publishers) is cumbersome and not all functions (authorization schemes) are supported by all XMPP servers.

Some kind of minimum supported server pubsub functionality might be necessary, together with a validation procedure. I know similar work is being done by UPnP to make sure XMPP servers support a minimum set of functionality required. Much of the administration might be taken care of if the server supports model “authorize” which allows node owners to approve or deny subscriptions. The owner can tie this into provisioning (XEP-0324) (canRead), for automated decisionmaking and a single interface for both momentary readouts and publish/subscribe. That is sort of the approach I wanted to take for pubsub but did not link it to XEP-0324 yet. Thanks.

4. I proposed an alternative pubsub like service, that I called ‘dealer’, which acts as a IoT concentrator towards the subscribers and that would subscribe to all Things the clients would want to receive events from.

Ok, not sure I understand. Please tell me more. Would it be an entity that subscribes to data from multiple nodes, and then makes it accessible using XEP-326 to other interested parties? Something like that except I would use IoT events (https://xmpp.org/extensions/inbox/iot-events.html) and let the ‘dealer’ optimise the subscriptions towards the ‘Things’. In the dealer pattern the client applications, that want to subscribe to sensor data from the Things, instead subscribe to the dealer service. Once subscribed the clients receive the measurements from all the Things via the dealer. The dealer is responsible to subscribe to all the individual Things and when it receives new measurements it will instantly publish these measurement to clients that subscribed to the dealer. Best regards, Eelco

Hi Peter and Eelco, I've read your discussion about pubsub & XMPP IoT, here some hint fromme:  > Perhaps it’s time to retake the XEP-writingeffort and write down some guidelines for IoT on XMPP using pubsub…  I could be interested in working on this, if you start to write it, pleaseconsider to include also me.   > I have thought about implementing the second ideaabove, myself. I think such a component might have a very important role forthe publish/subscribe pattern in XMPP, and solves many of the security issuesin other pubsub solutions. Would you be interested in investigating thisfurther?   Also in this case I would like to join, so if I can help, please contactme.   A third idea, based on the second idea above is thefollowing: Something that is missing from the XMPP pubsub model, but isavailable in MQTT, is multi-layered publish/subscribe. While implementing a newcontext-sensitive pubsub service, this might be something to add. In MQTT youcan listen to a “parent node”, or wildcards, and receive events from all its(grand*)child nodes for example. Example: Consider you publish a temperature onnode building/floor/apartment/room/temp1. How would you do to listen to allsensors in that room? Or all sensors in that apartment, floor or building? Orall temperature sensors in that building (leaving out other kinds of sensors)?Using a wildcard character (*) you could do this by subscribing to“building/floor/apartment/room/*”, “building/floor/apartment/*”,“building/floor/*”, “building/*” and “building/*/*/*/temp*” respectively in onego. That wo uld provid e a great way to subscribe to larger sets of contents,without having to maintain huge amounts of smaller individual subscriptions.  About this idea...have youthought about the possibility to use collection nodes on the server side, toimplement this? My suggestion for the subscriptions using wildcards is to usethe collection nodes provided by the XEP-0060 (http://xmpp.org/extensions/xep-0060.html). The idea is to create ahiearchy of nodes, inserting the ones of the "Things" (leaf nodes) incollection nodes related with the type of data published or their location.Then, when the server component receive the subscription containing thewildcards, it can translate the request in a subscription to the collectionnode(s) corresponding with the request. Following your example, for the node temp1:building/floor/apartment/room/temp1, you have thishiearchy of nodes:  building (collection)     --> floor (collection)           -> apartment (collection)               -> room (collection)                 -> temp(collection)                   -> temp1(leaf)  And you can translate the "wildcard" subscriptions in this way:  building/floor/apartment/room/*   -> subscription to room collection node building/floor/apartment/*  -> subscription to apartment collectionnode building/floor/* -> subscription tofloor collection node building/* -> subscription to buildingcollection node building/*/*/*/temp -> subscription to all the collection nodes of type temp in insertedin the building collection node Thanks,Davide  -- Davide Conzon Istituto Superiore Mario Boella (ISMB) via P.C. Boggio, 61 - 10138 Torino (ITALY) tel. (+39) 011.2276.710 Informativa - Art. 13 D.lgs. 196/03 ========================== Il trattamento dei dati ha la finalità di permettere lo svolgimento delle attività di ricerca, formazione e studio, oltre agli ulteriori servizi messi a disposizione dall’Istituto Superiore Mario Boella I dati saranno trattati con modalità manuali, informatiche e/o telematiche; non verranno per nessuna ragione comunicati ad altri soggetti ed Enti senza previa autorizzazione. Potranno venire a conoscenza dei Vostri dati il responsabile del trattamento e le categorie di soggetti incaricati del trattamento. In ogni momento potrà rivolgersi al nostro servizio Privacy per conoscere i suoi dati e farli integrare, modificare o cancellare per violazione di legge, od opporsi al loro trattamento e/o per esercitare gli altri diritti previsti dall’art. 7 del D.lgs 196/03. Titolare del trattamento è la società Istituto Superiore Mario Boella con sede in Via P. Carlo Boggio n. 61- 10138 Torino. All information and attachments are reserved and an Istituto Superiore Mario Boella intellectual property, if you receive this message for error please delete it and contact info@ismb.it. Da: "Cramer, E.R. (Eelco)" <Eelco.Cramer@tno.nl> A: XMPP in the Internet of Things <iot@xmpp.org> Inviato: Giovedì 30 Aprile 2015 10:26 Oggetto: Re: [IOT] Feedback on pubsub for IoT Hi Peter, Interesting! Please see my comments below. On 29 Apr 2015, at 16:44, Peter Waher <Peter.Waher@clayster.com> wrote: The first idea is a slight modification of the approach: Instead of having the dealer subscribe to all nodes. This might require a lot of administrative communication, and also a lot of monitoring/supervision for make sure it recovers from different error states. An alternative is to make a component connection (XEP-0114) and publish the dealer as a pubsub server component on the xmpp server, replacing perhaps the “normal” pubsub server. In this way, the dealer would not need to maintain all subscriptions, instead, it would be the owner of the nodes itself. Perhaps the added effort here, is comparable or less than the effort needed to subscribe to all events from a pubsub server, that as you say, anyway might be lacking in some regards. The dealer could still use the iot-event subscription architecture, and so, there would not be a need to implement that part, since it doesn’t provide subscribers to request tailored sets of data. This is sort of how I was planning to specify this. Except for the need of the ‘dealer’ to be the ‘owner’ of the device. The second idea, is a continuation of the above, but providing a “normal” pubsub subscription interface: Today, the pubsub pattern has a great weakness: It’s not possible to adapt contents based on rights for individual subscriptions. You need to publish different sets of content on different nodes, which quickly grows to infinity if you allow fine-grained control, as is the case for IoT. This not only becomes complicated, it also quickly removes any gains provided by pubsub, as the basic idea is to reduce the number of packets required for the publisher, to efficiently publish information to a larger set of subscribers. So, while one is creating a component for a new type of pubsub service above, you might build in a connection to a provisioning server (XEP-0324), or build in the same functionality in the same component, and use <canRead> to check what type of information is allowed for different subscribers implicitly, removing the need for a tailored subscription request, as well as a tailored publication, still tailoring output to each subscriber. That would lift the burden from the device, and provide a completely new type of service: Context sensitive, or individually tailored, publish/subscribe. In the ‘dealer’ service I was planning to add a ‘canSubscribe’ message in the provisioning protocol. The dealer should send that message to the provisioning to see if a subscription was valid. I like the idea to specify something that makes it as simple as possible for Things and subscribers to use. I have thought about implementing the second idea above, myself. I think such a component might have a very important role for the publish/subscribe pattern in XMPP, and solves many of the security issues in other pubsub solutions. Would you be interested in investigating this further? Sure. A third idea, based on the second idea above is the following: Something that is missing from the XMPP pubsub model, but is available in MQTT, is multi-layered publish/subscribe. While implementing a new context-sensitive pubsub service, this might be something to add. In MQTT you can listen to a “parent node”, or wildcards, and receive events from all its (grand*)child nodes for example. Example: Consider you publish a temperature on node building/floor/apartment/room/temp1. How would you do to listen to all sensors in that room? Or all sensors in that apartment, floor or building? Or all temperature sensors in that building (leaving out other kinds of sensors)? Using a wildcard character (*) you could do this by subscribing to “building/floor/apartment/room/*”, “building/floor/apartment/*”, “building/floor/*”, “building/*” and “building/*/*/*/temp*” respectively in one go. That would provide a great way to subscribe to larger sets of contents, without having to maintain huge amounts of smaller individual subscriptions. I agree. This is something that needs to be taken into account. Thanks,Eelco  This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages. _______________________________________________ IOT mailing list IOT@xmpp.org http://mail.jabber.org/mailman/listinfo/iot

Hi Eelco, Thanks for your reply!Here my answers:     That is a nice idea. I like the separation of collection and nodes. Are nested nodes possible like you described?     Yes, because you can put every collection node as a "parent" of other nodes (both collection and leaf).     What worries me is that pubsub collection nodes (http://xmpp.org/extensions/xep-0248.html) is a deferred XEP. Do you know if there are any XMPP     servers that implement this? It would be worth checking why this XEP was deferred… Reading here http://standards.xmpp.narkive.com/kR8qE7AS/deferred-xep-0248-pubsub-collecti..., I think that the XEP has been deferred, because it needed some revision (the discussion is quite old, but probably, since this discussion there have been other priorities for the protocol). I know for sure that the extension is already implemented in Openfire (I'm actually using it), and in this page (not recentely updated)  http://en.wikipedia.org/wiki/Comparison_of_XMPP_server_software, it is marked as implemented also in ejabberd.  Thanks,Davide  Davide Conzon  Istituto Superiore Mario Boella (ISMB)  via P.C. Boggio, 61 - 10138 Torino (ITALY) tel. (+39) 011.2276.710  Informativa - Art. 13 D.lgs. 196/03  ==========================  Il trattamento dei dati ha la finalità di permettere lo svolgimento delle attività di ricerca, formazione e studio, oltre agli ulteriori servizi messi a disposizione dall’Istituto Superiore Mario Boella I dati saranno trattati con modalità manuali, informatiche e/o telematiche; non verranno per nessuna ragione comunicati ad altri soggetti ed Enti senza previa autorizzazione. Potranno venire a conoscenza dei Vostri dati il responsabile del trattamento e le categorie di soggetti incaricati del trattamento. In ogni momento potrà rivolgersi al nostro servizio Privacy per conoscere i suoi dati e farli integrare, modificare o cancellare per violazione di legge, od opporsi al loro trattamento e/o per esercitare gli altri diritti previsti dall’art. 7 del D.lgs 196/03. Titolare del trattamento è la società Istituto Superiore Mario Boella con sede in Via P. Carlo Boggio n. 61- 10138 Torino.  All information and attachments are reserved and an Istituto Superiore Mario Boella intellectual property, if you receive this message for error please delete it and contact info@ismb.it.