Hello

 

> I propose that we form a special interest group (see XEP-0002) regarding the

> use of XMPP in the Internet of Things:

> 

> http://xmpp.org/extensions/inbox/iot-sig.html

 

The IoT SIG sounds like an excellent idea.

 

> Firstly, it'd be useful to gather a sense of the current state of

> play. It seems to me we have a number of IoT-related XEPs and

> proposals - due to a huge amount of effort by Peter Waher - but its

> not clear to me which of these have any traction. It would be great if

> people working on IoT (and using XMPP) could say which of these are

> generally working well for them.

 

It might be of interest to you, to know that the IEEE is working to form a new Group on ”IoT Harmonization”, in which XMPP plays an important role. XEPs under consideration at this forming stage are 0323, 0324, 0325, 0326 & 0347. You can review the slides from a presentation I held yesterday on this topic:

 

http://www.slideshare.net/peterwaher/iot-harmonization-using-xmpp

 

Let me know if anybody working with XMPP & IoT is interested to participate in such a working group. The goal is to form the group in January and have a first draft ready for balloting by the end of 2017.

 

> Secondly, I'm of the opinion - and opinions can always be changed -

> that the existing IoT proposals are something of an isolated suite.

 

Yes and no. They have been abstracted. Some are more IoT related (323,324,325,326,347), others are more generic. EXI was written as reaction to the observation that XMPP is too verbose for some IoT applications and some networks. The Event logging (0337) is a generic infrastructural need, but it arose from logging in distributed IoT systems where many clients lack displays. HTTP over XMPP (0332) arose from the need to define web queries among distributed sets of sensors. Dynamic Forms (0336) as a way to create richer data forms, but is used in IoT since data values might take some time to fetch, and fields need to be able to be updated dynamically. Form signatures (0348) is needed to automate the creation of XMPP accounts, in a secure manner. Others that wait approval are also written to be generic, such as the QoS proposal – which originated as a need from IoT but has generic value. Event subscription is more directly IoT-related.

 

> Looking at the IETF MILE Working Group, we have the XMPP-Grid proposal

> which seems a similar shape to the IoT proposal, and similarly uses

> little of the existing mechanics we have. For example, it provides a

> publish-subscribe facility, a registration facility, and so on. The

> payloads are different, but the essential goals the same. I cannot see

> what would drive a difference in the containing protocol between (say)

> counts of stanzas in an XMPP server, temperature readings in a sensor,

> and sightings of a Cyber Observable pattern.

 

There’s already a publish-subscribe based IoT solution defined by the UPnP, and published by the OIC/OCF:

https://openconnectivity.org/resources/specifications/upnp/iot

 

To create another one for this purpose seems unnecessary.

 

While publish/subscribe might work well for several use cases, it’s not sufficient to cover all use cases, not even the most important use cases. It’s sole purpose is to make mass-dissemination more efficient. The IoT XEPs however, allow for a more general architecture, which is not limited to a single communication pattern, but allows for most patterns used today, depending on what is to be accomplished. See my presentation above for more information.

 

Best regards,

Peter Waher

_______________________________________________
IOT mailing list
IOT@xmpp.org
https://mail.jabber.org/mailman/listinfo/iot