[Standards] Request from Coversant for discussion of non IoT activity from XSF.

Peter Waher Peter.Waher at clayster.com
Fri Jul 11 15:18:10 UTC 2014

Hello Dave

Thanks for your input concerning the IoT XEPs, and taking the time to go through them. My comments to your concerns, in red below. Cc to the standards list, for information.

Best regards,
Peter Waher

From: drichards at coversant.com [mailto:drichards at coversant.com]
Sent: den 10 juli 2014 23:57
To: 'Dave Cridland'; Rikard Strid
Cc: Peter Waher; 'Joachim Lindborg'
Subject: RE: Request from Coversant for discussion of non IoT activity from XSF.

I’ve been struggling with the IoT XEPs for a slightly different reason.  There are quite a few attempts in various industries to codify sensor and machine data in various protocols and I don’t think many industries are going to take seriously a spec coming out of XMPP land.
It sounds a bit harsh. I mean, XMPP has had more success than Obix (for instance) in getting some of its specs noticed. But at the end of the day, it shouldn’t matter what name the organization flags, but if the specification is useful or not that matters. Is a wanting spec from a well-known organization better than a better spec from a less known organization? Hasn’t it been how the Internet has evolved since day one, taking what works, even though large companies try to stifle invention by creating large standardization bodies that only large companies can participate in successfully? XSF has the advantage of being truly open, with no membership fees. Oasis is by many not seen as a standardization organization, but a promotional agency clothed in a standardization body outfit. Personally, I wouldn’t go that far, even though there are some points to it.

For example, I was technical chair for oBIX (http://www.obix.org/, https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=obix) back in 2003 time frame and worked with the BACnet folks for much if the 2000’s (http://www.bacnet.org/WG/XML/, http://www.bacnet.org/WG/DM/index.html) in both the binary protocol and the XML-ized version and both of these had pretty much the same goal as the IoT XEPs but much earlier.
I have been aware of the obix spec for many years, and others, some earlier than obix, others more complete than obix. The point of the data definition in the XEPs is to be able to solve all use cases presented by previous attempts, i.e. not limit anybody. The loosely coupled architecture used by obix is a good one, even though the obix spec lacks a lot of other important elements.

Looking through the sensor data XEP was like reading the oBIX 1.0 spec with a couple of minor adds.
Minor here is a subjective term. When I compare against the obix schema, I would say major differences. The point with the spec in XEP-0323 (&325), apart from solving previous use cases, is to create a loosely coupled architecture that can be extended at will by manufacturers, without needing software to be updated, or software to aggregate implicit information, and that the data can be accessible by both human users (in a localized environment) and machine users at the same time, and still be interoperable. Obix simply does not allow that. Furthermore, obix lacks QoS information and other crucial information such as a time axis. What the data format shares with the obix format, is a loosely coupled architecture, that doesn’t presume a certain set of fields for given object (node). (Other formats don’t.)
I had even talked to the oBIX folks (2004) about adding an XMPP transport definition (only http at the time) but left my company and with it my OASIS membership so I was not able to pursue that avenue and without a champion the idea died.
Which is why XSF is a better organization to work such things out, since it doesn’t require a company-backed membership, and allows a community interested in these topics to develop what best suits them.

Rather than try to reinvent the functionality within XMPP XEP’s,
It’s not reinvent, it’s taking requirements that exists, add new requirements, and make a better solution. It joins requirements from across different areas to create a new format that can be used by as many as possible, without introducing restrictions. It’s the accumulated experience of M2M since 1994, that goes into this simple but powerful data format. I don’t presume everything is covered, just everything that we’re aware of has been covered. I’m happy to receive any input and suggestions how to improve the format, in case there are use cases not covered.

a more practical approach would be to get these other groups to use XMPP as a transport for their already-defined XML.
Practical for whom? Those with that format already implemented, controlling the entire value chain prohibiting third party to access devices? It would definitely not be practical for those wishing for interoperable communication, since everybody trying to create interoperable services on-top of an existing network would have to implement all these data formats. Those promoting their own formats are companies trying to take control of the entire value chain.

Furthermore: The XML is not complicated, in any of the solutions provided. It is not as if the complexity of the XML will deter implementation in itself…

And lastly: I am aware of many attempts to use XMPP, where they only use XMPP “as a transport”. In my view, that is not something to recommend, since they lose many of the other benefits of using XMPP. My guess is that they use XMPP in this way, to fit it into their pre-existing architecture, that presupposes communication to be done in a certain manner. In my view, it would be more beneficial to review the architecture, to see how it can be adapted to use the full power of the protocols used.

And there are many other efforts in various industries in various stages of maturity to define XML versions of their protocols.
The formats in the XEPs are not difficult to implement. But we will provide example code to help people overcome this obstacle.

Some of these are even planning to use XMPP or at least have that as a candidate transport without any intervention from the XMPP community (or maybe unpublicized intervention).
I know. I am member of several such groups myself. It’s not a recipe that benefits interoperability.

Except maybe with niche players that are not involved with some other protocol already, I believe it will be extremely difficult to get any traction for IoT specs coming out of XSF.
Might be, might not be. If it is the case, that there need to be a discussion at another standardization organization about these formats, perhaps we need to start such a discussion. The features this format solves is wanting in other contexts. I am not familiar with a single data format that solves the same set of issues. And I’ve searched. The format provided in these XEPs definitely have value outside of the community of XMPP.

Another trend I have noticed with the building automation space of late is a shift from XML to JSON.
I’ve noted such a movement also. Especially from web developers developing in javascript. But there’s another movement also: Back to binary for constrained networks. Binary seems to be preferred by many embedded developers. There might be a need to support serialization of the same type of data in all three formats.

Around 10 years ago things shifted from binary to XML and now to JSON,
I wouldn’t say it has shifted (depends on your perspective), I would say it has diversified. One part of the developing community desires JSON. Others do not want to use it, since it adds another layer of complexity, and it removes many features solved by XMPP.

and who knows to what in the future.  Figuring out the features XMPP proper needs to gain in order to be considered the messaging bus of choice in IoT and then promoting how to use that to carry the payload-of-the-day seems to me to be the most practical course of action.  I think probably 324 and 326 (provisioning and concentrators) are worth pursuing and there are some pubsub and reconnect features that would be useful feature adds for XMPP, but the sensor data and control stuff is already covered elsewhere.
As I explained earlier, it is not covered elsewhere. Furthermore, XEP 323 and 325 contains important communication patterns not covered elsewhere as well. I’m happy you see value in XEP-0324 and 0326, but as you see, they require 323 and 325.

Sorry my thoughts are a bit scrambled on this but I haven’t had a chance to talk them out as yet.


Dave Richards

From: Dave Cridland [mailto:dave at cridland.net]
Sent: Wednesday, July 09, 2014 3:50 AM
To: Rikard Strid
Cc: Dave Richards; Peter Waher; Joachim Lindborg
Subject: Re: Request from Coversant for discussion of non IoT activity from XSF.

I've dropped the non-tech people to avoid boring them to death for this bit. :-)

One problem I think is facing you guys with the IoT specs is that - and I may be alone here - I find the specs really hard to get a handle on. I suspect I'm not alone here, because to my mind, we should be able to use this specs as a natural fit for things like server monitoring, even a sort of SNMP-like handling of software servers. Yet I don't see this done.

It could be that people simply haven't thought about this, but I'd note that Isode's M-Link server now (I think - I'm no longer involved of course) does self-monitoring over XMPP, but I don't think it uses the IoT specs to do so, and they certainly do know about them, so it's not an obvious thing. I think this is in part because the specs are pretty dense, and in part because it's focussed on outré things that people don't have, like temp sensors and water flow valves.

It might be worth trying to ensure that the simple cases are simple, and making sure people are aware of this - maybe a disk-space monitoring app as an example?

On 9 July 2014 03:56, Rikard Strid <Rikard at strid.it<mailto:Rikard at strid.it>> wrote:
I add Laura and Dave to the conversation, so they can give an perspective from XMPP Foundation.

Hi Laura and Dave,

There is some very cool things going on about XMPP and IoT in the world. One year ago XMPP came in as an underdog and today it is one of the most buzzed technologies for IoT. It is awesome and I am very proud being part of something as big pushing XMPP to be the no.1 protocol for IoT. UPnP Forum, Intel, AllSeen etc. all are using XMPP for IoT, but no one say they do. Don’t know if it is because there is no publications on XMPP.org about IoT?

I think it would be great if possible to create a branch for IoT (as Michael say) under XMPP Foundation to show that XMPP stretch outside IM? Let me know how we can work together to make sure that XMPP Foundation get the recognition it deserves as well as more companies to pay for membership!


From: Joachim Lindborg <joachim.lindborg at sust.se<mailto:joachim.lindborg at sust.se>>
Date: Friday, July 4, 2014 at 6:46 PM
To: Michael Holdmann <mholdmann at coversant.com<mailto:mholdmann at coversant.com>>
Cc: Dave Richards <drichards at coversant.com<mailto:drichards at coversant.com>>, Rikard Strid <rikard at strid.it<mailto:rikard at strid.it>>, Peter Waher <Peter.Waher at clayster.com<mailto:Peter.Waher at clayster.com>>, "info at xmpp.org<mailto:info at xmpp.org>" <info at xmpp.org<mailto:info at xmpp.org>>
Subject: Re: Request from Coversant for discussion of non IoT activity from XSF.

I would say that all at the summit agreed that they liked the initiative but didn't understand or had any Knowledge in the field other than the pure xmpp XML talk
Den 4 jul 2014 17:50 skrev "Michael Holdmann" <mholdmann at coversant.com<mailto:mholdmann at coversant.com>>:
I am curious as to what the XSF's commitment to XMPP IoT is.  I am seeing
many protocol standards bodies joining alliances, DDS and Industrial
Internet Consortium, OPC UA with Industrie 4.0 for example, yet I see no
activity whatsoever from XSF other than what myself at Coversant, Rikard
Strid and Peter Waher at Clayster and Joachim Lindborg are doing.  I see no
speaking engagements at any of the IoT conferences, blogging or posts with
in numerous groups etc.

I would like to understand the reasoning behind this, and if it is simply
that there is no desire to expand XMPP in this natural fit industry for the
protocol and only keep at a siloed Chat between humans protocol, I would
like to discuss creating a separate sister standards body that for XMPP IoT.

It is getting quite tiring being out here all alone.


Michael Holdmann
Executive Vice President | Sales | Marketing | Strategy
Coversant, Inc.
mholdmann at coversant.com<mailto:mholdmann at coversant.com>
(o) 916-577-1977 x6015<tel:916-577-1977%20x6015>
(m) 775-830-9755<tel:775-830-9755>

This e-mail message is intended only for the named recipient(s) above and is
covered by the Electronic Communications Privacy Act 18 U.S.C. Section
2510-2521. This e-mail is confidential and may contain information that is
privileged or exempt from disclosure under applicable law. If you have
received this message in error please immediately notify the sender by
return e-mail and delete this e-mail message from your computer.

No virus found in this message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 2014.0.4716 / Virus Database: 3986/7823 - Release Date: 07/09/14
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20140711/b507f847/attachment.html>

More information about the Standards mailing list