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

Peter Saint-Andre stpeter at stpeter.im
Fri Jul 11 16:01:26 UTC 2014


FWIW, I tend to agree that it would make sense for us to define how XMPP 
can be used as a transport for data formats that are defined elsewhere, 
since we're not necessarily experts on topics like sensor data or 
demand-response systems. This is how folks like OpenADR have used XMPP.

However, I admit that I still need to spend some quality time with the 
entire "suite" of IoT XEPs...

Peter

On 7/11/14, 9:18 AM, Peter Waher wrote:
> 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.
>
> Thoughts?
>
> 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!
>
> Best,
>
> Rikard
>
> *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>>:
>
> All;
> 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.
>
> Best,
> Michael
>
> Michael Holdmann
> Executive Vice President | Sales | Marketing | Strategy
> Coversant, Inc.
> mholdmann at coversant.com <mailto:mholdmann at coversant.com>
> mholdmann.wordpress.com <http://mholdmann.wordpress.com>
> @mholdmann
> @coversant
> (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
>




More information about the Standards mailing list