XSF Discussion - 2019-08-16

Is there a reason why all XEPs related to IoT are "Retracted" or "Deferred"?

COM8: yes, lack of author commitment.

hmm so what's the state of XMPP for IoT then?

COM8: very sad

nice :D

I'm not sure whether there is a set of actually usable IoT protocols, and AFAIK there is no set of libraries / widget toolkits / whatever at the middleware layer.

I believe these protocols are actually being used, mostly in collaboration with their author. However, I would say they deviate XEP-0134: XMPP Design Guidelines.

In the sense that there seem to be preexisting models which where then modeled on top of XMPP.

Ge0rG: Yes, noticed that too since I was doing research on it. I'm currently planning to create a XMPP-IoT extension for my client (UWPX) and setup a simple image for ESP32s.

I think it would be great if someone took a fresh look at this domain and design a set of protocols that use existing building blocks and disregard this prior work, to see what it would look like. I think it could be all a lot simpler and more elegant.

ralphm: yes, that was also my general impression.

But then again, "IoT" means something different to everybody, so we should maybe try to define more precise scopes, and have a first phase of distinct protocol desings for each, and then look how we can aggregate them

Sure

Going the good ol' design-by-committee route of the XSF will lead to yet another monstrosity that's impossible to implement

because everybody will bring in their pet feature, and in the end it will be unbearably unmaintainable

The problem with the current set of IoT protocols was that they were not designed by people with previous XMPP protocol knowledge.

I have knowledge of XMPP and I have knowlede of home automation, but I lack the time.

And that everyone in our community didn't really have the cycles to make it better aligned.

I'm not a fan of design by committee; having three or so people, with some XMPP experience, hammering it out with running code, is usually pretty good.

Agreed.

But sometimes this is hard, like with Jingle.

there is now a Triage permission on github which allows to read and clone a repo, plus manage issues and PRs.

this would be excellent for folks like pep. who want to get their hands dirty on editor tasks, but are not official editor team members and thus should not be given +w on the repository

When I did my own IoT deployment, I ended up reinventing the wheel on top of MQTT. I really wish we had an XMPP based middleware for sensors and actors, and maybe a bunch of pre-defined profiles like "RGB light"

Ge0rG: I think XMPP shines as a routing mechanism, using simpler protocols locally (on resource constrained devices) and bridging them.

I wrote the "Simple IoT" XEP after working with peter wahers XEPs (the "IoT XEPs"): http://geekplace.eu/xeps/xep-siot/xep-siot.html Most of his XEPs re-invent the wheel when existing building blocks could be used IMHO

flow: didn't I just say that? 🤣

"Last Updated: 2016-09-04" 😞

ralphm, just wanted to confirm that

Of course, everyones idea of "IoT" is different

flow: while you are there, I've recently had an ugly (but non-breaking) stacktrace from the Smack debugger during roster load: https://op-co.de/tmp/smack-roster-trace.txt

Ge0rG, where is the source of org.yaxim.androidclient.util.JULHandler ?

> Ge0rG> "Last Updated: 2016-09-04" 😞 I am not sure what this is trying to express: Disappointed because I did not work at it? Or because nobody cared enough to try it and continue working on it?

Also I believe XMPP already has most things for IoT. Any further/new IoT XEP would probably be a specification allowing vendor interoperability. And since vendors do not have interest in that, we see no activity in this regard. If you want to do IoT for your own, e.g. control your lightbulb, you probably would just go ahead and implement it based on ad-hoc commands (which would allow your 10 year old PSI instance to control it FWIW \o/)

If it hasn't been submitted to the editor, then indeed chances are it is not being looked at

flow: https://github.com/ge0rg/yaxim/blob/appcompat/src/org/yaxim/androidclient/util/JULHandler.java

Ge0rG, used Smack version?

what ralphm said.

flow: 4.3.5 snapshot

Besides exposure, submission of XEP creates a more clear legal situation for others to contribute.

a

a.k.a. "don't call it a (proto)XEP until it's submitted"

ralphm, I am not sure I would agree, at least I don't see why that is the case

But it's not like I have problems submitting XEPs, I guess you know that ;)

flow: before you submit it to the XSF, it's just an XML or HTML file on your web server.

Ge0rG, the question is why submission or the acceptance as protoXEP creates a more clear legal situation for others to contribute?

I mean, yes the editor asks you questions, but those questions could also be seen as answered by writing the xml/html file

and publishing it

Ge0rG, which smack version is it, because the stacktrace does not match what is at https://github.com/igniterealtime/Smack/blob/4.3/smack-im/src/main/java/org/jivesoftware/smack/roster/Roster.java#L1601

flow: because by submitting it as a proto-XEP, you accept the https://xmpp.org/about/xsf/ipr-policy

I'd say I already accept that by publishing a document which states that it is full conformance of the XSF's IPR

Having a document with rights assigned to the XSF, but not formally received or hosted by it, makes it muddy.

Regarding IoT: Since I'm working on it anyway for my B.Sc. Thesis I will try to come up with a protocol that uses already existing features of XMPP and try (once I got it up and running) to standardize it.

flow: the stacktrace also doesn't match my source files (WTF?), but the error happens in `LOGGER.log(Level.FINE, "RosterResultListener received {}", packet);` when single-stepping

COM8: you might or might not use http://geekplace.eu/xeps/xep-siot/xep-siot.html as a foundation

COM8: splendid

Ge0rG: well, maybe. As I said, muddy.

COM8, also feel free to join iot@muc.xmpp.org

Ge0rG: Thanks will have a look at it

flow: 👍🏻

COM8: what kind of IoT are you doing?

flow: if you believe your document is worthy of being worked on, just send it to the editor. Even if it results in major rewrites

I know that Cisco and some others are pushing XMPP for IT Security Incident data exchange, which is also a hot topic for me

Ge0rG: interesting. Is any of them in our community?

ralphm: no :(

ralphm: https://blogs.cisco.com/security/cisco-scores-big-with-a-new-ietf-approved-internet-standard

well PSA is listed as author for xmpp-grid (RFC8600)

Ge0rG: Home automation so trying to provide an interface for all sensors/devices in XMPP apps (DataForms).

ralphm: Yes

I'm not opposed to do work in the IETF, t.b.h.

at a high level, you need to define sensor / actor types ("switch", "temperature sensor", "RGB light", ...) which probably map to abstract types like "1x binary", "3x float value (0...1)"

and then have a discovery mechanism, a config mechanism and a pubsub mechanism

So is it reasonable?

I think I looked at it before. This work started in 2016 or so

And MILE is older.

https://tools.ietf.org/wg/mile/charters

Is M2M the same as IoT?

I think so

Or at least some subset

We are depressingly understaffed.

flow: are you interested in corrected line numbers from the stacktrace?

Ge0rG, no, I think I found the bug

flow: great!