IoT SIG - 2019-09-04

So I started laying out the building blocks needed for a new approach to IoT. Now I would like to start working on the XEP(s). Should I create one single XEP or is it better when I spit stuff up into multiple XEPs. Any advice here? Planed topics: Registration, Discovery, Data Access, Trust Management, (Device Automatisation)

COM8, I don't think that it does not matter that much at an early stage if you split or not. In general, splitting large XEPs in optional parts is usually a good idea

COM8, I usually recommend setting up a system which automatically builds the XEPs from source and place the resulting html onto a webserver

Ok, sounds good. Since splitting up can be done later I will start working on one compact XEP

COM8, also, be aware that writing a standard and getting it published is not an easy task

I suggest to gather feedback early and to seek for a way has the highest chance to get consensus

I think IoT is especially challenging here, since it has so many different meanings and everyone has a slight different requirements etc

Aaaaaaaaaaaand: running code, you want to develop a standard hand-in-hand with a (prototype) implementation

Also an important note: a suite of IoT XEPs covering these topics was already published some years ago

MattJ, I think COM8 is aware of the waher xeps

Ok, good

flow: Yes, I'm aware of that. At the moment I'm working on the overall system design. So as soon as I got this done I will try to create a first draft for discussion.

Mattj: Yes, since they have been revoked/deferred I started working on this.

revoked and deferred are two very different things

"deferred" just means they haven't been updated for a while, and nobody tried to advance them

I don't think that's good enough reason to just do the same thing again

a while == 12 months currently, iirc

MattJ, are you sure that its the same thing? :) Also if someone feels like it, why not?

I don't think much is salvageable from the existing XEPs, actually I can only think of one thing

"why not?" => it's a waste of time just to gain 4 more XEPs that will be also deferred in 18 months from now

Also they were focusing more or less on automatisation/handling for large scale IoT networks and didn't had the simple enduser in mind. I want to define an XEP which lets enduser Bob register and handel his smart lightbulb/thermometer/... and control all of his devices in a way that is as simple and secure as possible.

To be clear: I'm not against new XEPs, the old ones have plenty of issues

But I think you need a clear objective that sets the new XEPs apart from the old ones

COM8, people are already controlling light bulbs over XMPP, just ask ralphm

Accomplished by registering a user account for a bot, and sending the bot a message

We already have registration mechanisms in XMPP

Why does IoT need something different?

MattJ, well, even if they get deferred, there is probably a leasson learned or two, potentially only for COM8, but still

MattJ, one issue that XMPP is missing is access control

how do you set ACLs for your lightbulp?

*lightbulb

flow, by making the bot only accept requests from users on its roster

MattJ, that is what I have for coarse grained ACLs in mind

and the bot can manage its roster however it wants

but how do roster entries get added and removed?

How do ACL entries get added or removed? :)

Mattj: That is exactly what I do not want. I don't want an interface that is text based. I want that the device to provied a XEP004 based form where the user can change the color, brightnes, ... via a slider, color picker, ...

Well we don't have a generic standard for that, that's the point i guess

COM8, ok, so ad-hoc commands already exist, you're done :)

and i think a generic standard for this would be benefical

https://xmpp.org/extensions/xep-0050.html

The gateway/bot can expose any commands it wants to, and serve forms

And best of all: many clients and libraries already implement this

MattJ, now some entity requests presence subscription from your thermometer, so that it can read its value. How does the thermometer forward the request to the owner of the thermometer?

I aggree that existing building blocks should be used whenever sensible

and it is probably sensible in most cases

flow, https://xmpp.org/extensions/xep-0060.html#subscriber-subscribe-approval

MattJ, so the full JID of the thermometer becomes a pubsub service?

Why not the bare JID, which already is?

that works for the pubsub case, but what if I want to pull the data?

You can pull from pubsub

live data, which some extra metadata what and how it should be pulled

or you mean, you don't want the device to push to pubsub at all?

i.e., when you don't want to talk to a pubsub service on the bare jid, but with the device itself via the full jid

MattJ, it depends on the use case i'd say. Sure, for something like temperature, pubsub would be nice for most use-cases

but there may be uses cases where you have to directly talk to the device

https://xmpp.org/extensions/xep-0244.html may fit then

for example because you don't want to read out a sensor, but talk to an actor

not sure about xep244, I never understood or forgot the advantage over plain ad-hoc commands, but yes

Mattj: Yes, I know and I also do not want to reinvent the wheel again like it has been done in an earlier iteration. I want to use existing stuff where ever possible and define a simple and standartised way so every enduser even Bob how does not know what XMPP is and just want's to manage his stuff without having to send text messages with an exact sytax you allways have to remember/ look up

COM8, so what will Bob use to interact?

Also going back to https://xmpp.org/extensions/xep-0060.html#subscriber-subscribe-approval: First you said: use the roster, and then you came with pubsub. What is it now? ;)

flow, I'm not claiming to have a specific solution, but I'm also not the person planning on yet more XEPs

and I'll repeat: I'm not against new XEPs, if they're clearly needed

I'd be happy to see gaps filled

What I'm doing it throwing out proposals for reusing existing stuff, and if there's reasons they don't fit, that helps clarify exactly what is needed

But when you tell me you just need an ACL, and we already have the roster being successfully used as an ACL in multiple situations already, I have a duty to point that out :)

and it's very simple to implement, and widely supported

So a XEP that allows delegated authority to approve roster requests may be all that is needed

I live and breathe XMPP, and have done for a long time now. I also love IoT, and have far more home automation set up than the average person

and yet I don't see a clear fit for XMPP into any of the stuff I've done

mattj: Yes that is the question! We have to make it as easy to use for endusers and as easy as possible to implement so everybody jumps ontop of our bandwagon. That's what I hope to archive with my XEP. A XEP that describes the process starting from pushing a button on the IoT device over scanning it's QR Code for registering it on your XMPP server. And once the device is registered how can a user manage and access the device. On top of that we can extend stuff like connecting it to ITTT, ... I'm not aware that any existing XEP describes this.

> MattJ> So a XEP that allows delegated authority to approve roster requests may be all that is needed see topic of this MUC :)

flow, perfect :)

COM8, I think you need a bit more incentive to get people on the bandwagon

Ease-of-use is about UI/UX, and can typically be done on top of any protocol, HTTPS, MQTT, etc.

and given that XMPP won't run on many microcontrollers that can handle CoAP or MQTT, manufacturers probably aren't going to jump on it fast either

It may be a good fit for a hub/gateway device, but they can just as easily speak HTTPS/MQTT, which are already widely supported

I'm not really trying to discourage you, I'm actually trying to help you think about what problem you are trying to solve

I do believe that there should also be a fine grained ACL mechanism, which puts the ACL in a PEP for the devices nodes (N.B. not talking about pubsub nodes here, but "xep30" nodes)

So you don't waste your time

Yes and I'm really thankful for that. That's why I'm in here to discuss with people and see how they look at this stuff.

Here's the way I see things. For a general end-user smart-home situation (which is what I think you are targeting), you have a handful of devices with different roles

You have the device (e.g. a light bulb), a gateway (optional), a hub (also optional), and a controller (e.g. a phone or hardware control of some sort)

Many IoT devices do not speak TCP/IP, or connect directly to a LAN - typically because of power constraints, microcontroller resources, wifi reliability, etc.

So they will use Zigbee, Z-Wave, or something similar to communicate with a gateway/bridge device

So there is no room for XMPP in this part of the stack

Also this part of the stack is typically controlled by a single manufacturer, so doesn't necessarily need to be open, or is already based on an open(ish) standard such as Zigbee, Z-Wave or BLE

For devices that don't need a gateway, but e.g. connect directly to wifi, you'll still generally find them using microcontrollers that are not capable enough to run XMPP

and those devices tend to connect to a manufacturer's proprietary cloud anyway, so the manufacturer doesn't care about interop here

Ok, so then you have the next layer: communication between a hub or controller and the gateway

XMPP /could/ fit here, but why? It necessitates an extra piece of infrastructure (an XMPP server), and I don't see the gain

I certainly don't want to depend on public XMPP services for turning my lights on/off, and neither do I expect everyone to run their own server (separate to all the stuff they'd already have)

You could make the hub be an XMPP server, but again, I'm not sure of the benefit there

That leaves communication between the hub and controlling device - would both need to communicate via an XMPP server instead of directly?

Latency also becomes an issue

If this is stuff you've already thought about, I'd love to hear your thoughts

If not, hopefully it provides you something interesting to think about