13 Nov
2016
13 Nov
'16
1:09 p.m.
CC'ed to standards@ since I think it is of general interest. But please
keep the discussion in the iot(a)xmpp.org mailing list.
I enjoyed working with Rikard in the past few months, implementing the
Internet of Things (IoT) XEPs in Smack [1] and developing a prototype
App for Android using the XEPs.
The XEPs involved where
- XEP-0323 - Data
- XEP-0324 - Provisioning
- XEP-0325 - Control
- XEP-0347 - Discovery
What do you expect from XEPs for IoT? I've asked this question many
people in the last few months, and received a broad range of answers,
including "Do we need XEPs for IoT?" and "I don't know!".
The Provisioning and Discovery XEPs are the most interesting ones
regarding this question. The IoT XEPs introduce the concept of
*friendship* between things. Friends of things can make use of them,
e.g. reading out their data or remotely controlling them. Thanks to the
fact that XMPP is federated, a thing from one manufacturer could become
a friend of a thing from a different manufacturer. This is described in
XEP-0324 - Provisioning.
Furthermore a thing can be owned by an XMPP entity. It can register
itself with a registry, so that other things can find it. This is
described in XEP-0347 - Discovery.
Now, one key issue that the XEPs try to solve is that a thing — think of
the light-bulb next to you — can not decide on its own if another thing
is his friend or not. So, if the thing receives a friendship request, it
basically proxies the request to its provisioning server (PS), which
will wait for an decision from the thing's owner. This process is
described in the Provisioning XEP and is basically a proxy mechanism for
XMPP subscription requests.
And here lies one of the issues we need to discuss.
The concept of friendship is a fundamental building block of the IoT
XEPs, yet it is nowhere formal specified what friendship actually is in
terms of XMPP. The XEPs appear map friendship between things to
subscription states between XMPP entities, but they do not specify if
friendship is a symmetric relation or an asymmetric one. XMPP
subscription states are asymmetric: Just because I'm subscribed to your
presence, it doesn't mean that your are subscribed to mine. I believe
that the IoT XEPs assume that an thing is a friend if both are
subscribed to each others presence. But do we really want that?
I think the answer must be 'no', because things are (usually) not
interested in the presence states of their friends, and so, we should
avoid the overhead introduced by presence notifications where possible.
Think of a thing with many friends: If the thing is subscribed to the
presence of its friends, it will receive a large amount of presences. We
definitely need to discuss this.
While implementing we also discovered that the XEPs do not discuss an
important protocol flow. One of the test scenarios I implemented in
Smack consists of a provisioning server (PS), a thing, a owner and an
XMPP entity trying to become a friend of the thing (the 'requestor').
The requestor sends a subscription request to the thing, in order to
befriend the thing. Now the thing asks the PS whether or not the
requestor is a friend and the PS will immediately return that the
requestor is not a friend, because there was no decision from the owner
yet. Here ends the story in the XEPs. In our scenario, the owner will
eventually accept or reject the friendship request in the PS's web
interface. But how does the requestor get notified about the owners
decision? Possible XEP-0324 § 3.2.4 — but do we want the requestor to
act on recommendations send from arbitrary JIDs? We also need to discuss
this.
My general impression is that the current IoT XEPs are to large and to
complex. It reminds me of the XEP-0136 Messaging Archiving situation,
where this big and complex XEP got not much traction because it is so
heavyweight and hard to implement. And now we have XEP-0313 Message
Archive Management, which is simple, covers most uses cases and is easy
to extend, thus allowing the missing use cases to be added on top. We
should think big, but write simple and modular XEPs.
I started an alternative draft to the IoT XEPs, called "Simple IoT"
(SIoT). It's not really meant for submission, just to have a basis for
discussion. You can find it at
http://geekplace.eu/xeps/xep-siot/xep-siot.html
I believe that XMPP has much to offer for IoT. But I think there is a
little bit room for improvement when it comes to the IoT XEPs as they
are now.
What follows are the polished notes I took while implementing the XEPs.
General
=======
The XEPs are written in style which possible assumes that examples are
normative: Some sections consist mostly of figures and examples. The IoT
XEPs need more normative texts.
XEP-0323 - Data
===============
The data read scheme out should follow the scheme we re-introduced in
XEP-0313: Message Archive Management: IQ-request → data1 → … → dataN →
IQ-result. This would allow to remove the 'done' attribute and this
scheme is a little bit easier to implement. I going to repeat myself,
because I said this in MAM thread years ago: I believe we always should
use this very scheme when requesting data which we expect to be
delivered by multiple stanzas.
Timestamp is not using XEP-0082: XMPP Date and Time Profiles.
Why does it not re-use XSD data types? (SenML [2] also seems like a
potential candidate. Haven had time to look into it though.)
The 32/64-bit integer types: Are they signed or unsigned? I shouldn't be
required to look in § 10. XML Schema to find that out.
Example 7 shows an IQ send to a bare JID. This is likely meant to be an
IQ addressed to a full JID.
It's unclear if things without a node are allowed.
XEP-0324 - Provisioning
====================
§ 3.1.1 "…if the provisioning server is not available in the roster of
the device…"
This falsely mixes the existence of an roster entry with presence
subscription. But the XMPP Roster and Presence Subscription are two
(mostly) orthogonal concepts. You can have a presence subscription
established without a related roster item, and you can have a roster
item without being subscribed.
§ 3.2.2 "Any resource information in the JID must be ignored by the
provisioning server."
Some XEPs of the IoT XEPs go with a different approach of explicitly
disallowing the JID value to be a JID with resourcepart. I suggest
consistency and I would favor the approach of explicitly forbidding the
JID to contain a resourcepart instead of ignoring the resourcepart.
§ 3.2.4 "isFriend(jid) optional, for security"
There is no gain in security if the Device asks the provisioning server
if it really should add the JID as friend. If an attacker is able to
spoof messages with a 'from' JID of the provisioning server, then he is
very likely also able to spoof IQ replies too.
§ 3.5.1
Example 20 uses a bare JID for IQ. Also why isn't the response just an
empty IQ result?
XEP-0325 - Control
=================
Why should we us this instead of XEP-0050: Ad-Hoc Commands? I've seen
people controlling their 2015 home automation system (Homematic) with an
very old Psi version using XEP-0050. Ad-Hoc Commands and Data Forms are
a key strength of XMPP.
§ 3.2.2/3: The 32/64-bit integer types: Are they signed or unsigned? I
shouldn't be required to look in § 10. XML Schema to find that out.
§ 3.1.2: Can we have an empty result IQ instead of an empty
<setResponse/> result?
§ 3.1.2 and § 6.2: Why put 'xml:lang' in <set/> instead of simply in
<iq/>?
XEP-0347 - Discovery
====================
§ 3.9: Claiming a thing: Why are 5 values required to claim a thing,
when a tuple of ID and Key would be sufficient and provide the same
security guarantees? Do we really want the user to enter 5 strings,
every one adding another error source, in order to claim a thing? Or is
it up to the registry/thing/whatever to decide what is sufficient to
claim a thing?
Claiming should be as simple as possible. I've claimed over a hundert
devices in the past months and was always annoyed that I had to enter 5
values.
Example 13 is missing 'cacheId'.
<claimed/> has two semantic: success response to <mine/> *and* claimed
notification to thing. I suggest using two different elements.
Example 46 and 47: When to use a full JID and when to use a bare JID as
value of 'jid' in <disown/>?
§ 5.2 Meta Tags: Why is 'V' (Version Number) of type 'numeric'? Is it
supposed to be an integer, or a version string like "1.2.3-beta4"?
- Florian
1:
https://community.igniterealtime.org/blogs/ignite/2016/07/23/support-for-io…
2: https://www.ietf.org/id/draft-ietf-core-senml-04.txt
13 Nov
13 Nov
1:47 p.m.
I'll write a more detailed response to this later, but two things for now:
1) Thanks for writing this, it's extremely useful.
2) Please do submit that XEP you've written, even if you think - especially
if you think - it's just for discussion. Without a successful submission,
it's not a XEP (minor issue) and is not under the XSF's IPR rules (major
issue).
On 13 Nov 2016 19:05, "Florian Schmaus" <flo(a)geekplace.eu> wrote:
CC'ed to standards@ since I think it is of general
interest. But please
keep the discussion in the iot(a)xmpp.org mailing list.
I enjoyed working with Rikard in the past few months, implementing the
Internet of Things (IoT) XEPs in Smack [1] and developing a prototype
App for Android using the XEPs.
The XEPs involved where
- XEP-0323 - Data
- XEP-0324 - Provisioning
- XEP-0325 - Control
- XEP-0347 - Discovery
What do you expect from XEPs for IoT? I've asked this question many
people in the last few months, and received a broad range of answers,
including "Do we need XEPs for IoT?" and "I don't know!".
The Provisioning and Discovery XEPs are the most interesting ones
regarding this question. The IoT XEPs introduce the concept of
*friendship* between things. Friends of things can make use of them,
e.g. reading out their data or remotely controlling them. Thanks to the
fact that XMPP is federated, a thing from one manufacturer could become
a friend of a thing from a different manufacturer. This is described in
XEP-0324 - Provisioning.
Furthermore a thing can be owned by an XMPP entity. It can register
itself with a registry, so that other things can find it. This is
described in XEP-0347 - Discovery.
Now, one key issue that the XEPs try to solve is that a thing — think of
the light-bulb next to you — can not decide on its own if another thing
is his friend or not. So, if the thing receives a friendship request, it
basically proxies the request to its provisioning server (PS), which
will wait for an decision from the thing's owner. This process is
described in the Provisioning XEP and is basically a proxy mechanism for
XMPP subscription requests.
And here lies one of the issues we need to discuss.
The concept of friendship is a fundamental building block of the IoT
XEPs, yet it is nowhere formal specified what friendship actually is in
terms of XMPP. The XEPs appear map friendship between things to
subscription states between XMPP entities, but they do not specify if
friendship is a symmetric relation or an asymmetric one. XMPP
subscription states are asymmetric: Just because I'm subscribed to your
presence, it doesn't mean that your are subscribed to mine. I believe
that the IoT XEPs assume that an thing is a friend if both are
subscribed to each others presence. But do we really want that?
I think the answer must be 'no', because things are (usually) not
interested in the presence states of their friends, and so, we should
avoid the overhead introduced by presence notifications where possible.
Think of a thing with many friends: If the thing is subscribed to the
presence of its friends, it will receive a large amount of presences. We
definitely need to discuss this.
While implementing we also discovered that the XEPs do not discuss an
important protocol flow. One of the test scenarios I implemented in
Smack consists of a provisioning server (PS), a thing, a owner and an
XMPP entity trying to become a friend of the thing (the 'requestor').
The requestor sends a subscription request to the thing, in order to
befriend the thing. Now the thing asks the PS whether or not the
requestor is a friend and the PS will immediately return that the
requestor is not a friend, because there was no decision from the owner
yet. Here ends the story in the XEPs. In our scenario, the owner will
eventually accept or reject the friendship request in the PS's web
interface. But how does the requestor get notified about the owners
decision? Possible XEP-0324 § 3.2.4 — but do we want the requestor to
act on recommendations send from arbitrary JIDs? We also need to discuss
this.
My general impression is that the current IoT XEPs are to large and to
complex. It reminds me of the XEP-0136 Messaging Archiving situation,
where this big and complex XEP got not much traction because it is so
heavyweight and hard to implement. And now we have XEP-0313 Message
Archive Management, which is simple, covers most uses cases and is easy
to extend, thus allowing the missing use cases to be added on top. We
should think big, but write simple and modular XEPs.
I started an alternative draft to the IoT XEPs, called "Simple IoT"
(SIoT). It's not really meant for submission, just to have a basis for
discussion. You can find it at
http://geekplace.eu/xeps/xep-siot/xep-siot.html
I believe that XMPP has much to offer for IoT. But I think there is a
little bit room for improvement when it comes to the IoT XEPs as they
are now.
What follows are the polished notes I took while implementing the XEPs.
General
=======
The XEPs are written in style which possible assumes that examples are
normative: Some sections consist mostly of figures and examples. The IoT
XEPs need more normative texts.
XEP-0323 - Data
===============
The data read scheme out should follow the scheme we re-introduced in
XEP-0313: Message Archive Management: IQ-request → data1 → … → dataN →
IQ-result. This would allow to remove the 'done' attribute and this
scheme is a little bit easier to implement. I going to repeat myself,
because I said this in MAM thread years ago: I believe we always should
use this very scheme when requesting data which we expect to be
delivered by multiple stanzas.
Timestamp is not using XEP-0082: XMPP Date and Time Profiles.
Why does it not re-use XSD data types? (SenML [2] also seems like a
potential candidate. Haven had time to look into it though.)
The 32/64-bit integer types: Are they signed or unsigned? I shouldn't be
required to look in § 10. XML Schema to find that out.
Example 7 shows an IQ send to a bare JID. This is likely meant to be an
IQ addressed to a full JID.
It's unclear if things without a node are allowed.
XEP-0324 - Provisioning
====================
§ 3.1.1 "…if the provisioning server is not available in the roster of
the device…"
This falsely mixes the existence of an roster entry with presence
subscription. But the XMPP Roster and Presence Subscription are two
(mostly) orthogonal concepts. You can have a presence subscription
established without a related roster item, and you can have a roster
item without being subscribed.
§ 3.2.2 "Any resource information in the JID must be ignored by the
provisioning server."
Some XEPs of the IoT XEPs go with a different approach of explicitly
disallowing the JID value to be a JID with resourcepart. I suggest
consistency and I would favor the approach of explicitly forbidding the
JID to contain a resourcepart instead of ignoring the resourcepart.
§ 3.2.4 "isFriend(jid) optional, for security"
There is no gain in security if the Device asks the provisioning server
if it really should add the JID as friend. If an attacker is able to
spoof messages with a 'from' JID of the provisioning server, then he is
very likely also able to spoof IQ replies too.
§ 3.5.1
Example 20 uses a bare JID for IQ. Also why isn't the response just an
empty IQ result?
XEP-0325 - Control
=================
Why should we us this instead of XEP-0050: Ad-Hoc Commands? I've seen
people controlling their 2015 home automation system (Homematic) with an
very old Psi version using XEP-0050. Ad-Hoc Commands and Data Forms are
a key strength of XMPP.
§ 3.2.2/3: The 32/64-bit integer types: Are they signed or unsigned? I
shouldn't be required to look in § 10. XML Schema to find that out.
§ 3.1.2: Can we have an empty result IQ instead of an empty
<setResponse/> result?
§ 3.1.2 and § 6.2: Why put 'xml:lang' in <set/> instead of simply in
<iq/>?
XEP-0347 - Discovery
====================
§ 3.9: Claiming a thing: Why are 5 values required to claim a thing,
when a tuple of ID and Key would be sufficient and provide the same
security guarantees? Do we really want the user to enter 5 strings,
every one adding another error source, in order to claim a thing? Or is
it up to the registry/thing/whatever to decide what is sufficient to
claim a thing?
Claiming should be as simple as possible. I've claimed over a hundert
devices in the past months and was always annoyed that I had to enter 5
values.
Example 13 is missing 'cacheId'.
<claimed/> has two semantic: success response to <mine/> *and* claimed
notification to thing. I suggest using two different elements.
Example 46 and 47: When to use a full JID and when to use a bare JID as
value of 'jid' in <disown/>?
§ 5.2 Meta Tags: Why is 'V' (Version Number) of type 'numeric'? Is it
supposed to be an integer, or a version string like "1.2.3-beta4"?
- Florian
1:
https://community.igniterealtime.org/blogs/ignite/2016/07/23/support-for-
iot-xeps-added-to-smack
2: https://www.ietf.org/id/draft-ietf-core-senml-04.txt
_______________________________________________
IOT mailing list
IOT(a)xmpp.org
https://mail.jabber.org/mailman/listinfo/iot
14 Nov
14 Nov
2:11 a.m.
Florian,
Thanks for your valuable thoughts and inputs!
/Rikard
Get Outlook for iOS<https://aka.ms/o0ukef>
_____________________________
From: Florian Schmaus <flo@geekplace.eu<mailto:flo@geekplace.eu>>
Sent: Sunday, November 13, 2016 8:05 PM
Subject: [IOT] An implementer's review of the IoT XEPs
To: XMPP in the Internet of Things <iot@xmpp.org<mailto:iot@xmpp.org>>
Cc: XMPP Standards <standards@xmpp.org<mailto:standards@xmpp.org>>
CC'ed to standards@ since I think it is of general interest. But please
keep the discussion in the iot@xmpp.org<mailto:iot@xmpp.org> mailing list.
I enjoyed working with Rikard in the past few months, implementing the
Internet of Things (IoT) XEPs in Smack [1] and developing a prototype
App for Android using the XEPs.
The XEPs involved where
- XEP-0323 - Data
- XEP-0324 - Provisioning
- XEP-0325 - Control
- XEP-0347 - Discovery
What do you expect from XEPs for IoT? I've asked this question many
people in the last few months, and received a broad range of answers,
including "Do we need XEPs for IoT?" and "I don't know!".
The Provisioning and Discovery XEPs are the most interesting ones
regarding this question. The IoT XEPs introduce the concept of
*friendship* between things. Friends of things can make use of them,
e.g. reading out their data or remotely controlling them. Thanks to the
fact that XMPP is federated, a thing from one manufacturer could become
a friend of a thing from a different manufacturer. This is described in
XEP-0324 - Provisioning.
Furthermore a thing can be owned by an XMPP entity. It can register
itself with a registry, so that other things can find it. This is
described in XEP-0347 - Discovery.
Now, one key issue that the XEPs try to solve is that a thing — think of
the light-bulb next to you — can not decide on its own if another thing
is his friend or not. So, if the thing receives a friendship request, it
basically proxies the request to its provisioning server (PS), which
will wait for an decision from the thing's owner. This process is
described in the Provisioning XEP and is basically a proxy mechanism for
XMPP subscription requests.
And here lies one of the issues we need to discuss.
The concept of friendship is a fundamental building block of the IoT
XEPs, yet it is nowhere formal specified what friendship actually is in
terms of XMPP. The XEPs appear map friendship between things to
subscription states between XMPP entities, but they do not specify if
friendship is a symmetric relation or an asymmetric one. XMPP
subscription states are asymmetric: Just because I'm subscribed to your
presence, it doesn't mean that your are subscribed to mine. I believe
that the IoT XEPs assume that an thing is a friend if both are
subscribed to each others presence. But do we really want that?
I think the answer must be 'no', because things are (usually) not
interested in the presence states of their friends, and so, we should
avoid the overhead introduced by presence notifications where possible.
Think of a thing with many friends: If the thing is subscribed to the
presence of its friends, it will receive a large amount of presences. We
definitely need to discuss this.
While implementing we also discovered that the XEPs do not discuss an
important protocol flow. One of the test scenarios I implemented in
Smack consists of a provisioning server (PS), a thing, a owner and an
XMPP entity trying to become a friend of the thing (the 'requestor').
The requestor sends a subscription request to the thing, in order to
befriend the thing. Now the thing asks the PS whether or not the
requestor is a friend and the PS will immediately return that the
requestor is not a friend, because there was no decision from the owner
yet. Here ends the story in the XEPs. In our scenario, the owner will
eventually accept or reject the friendship request in the PS's web
interface. But how does the requestor get notified about the owners
decision? Possible XEP-0324 § 3.2.4 — but do we want the requestor to
act on recommendations send from arbitrary JIDs? We also need to discuss
this.
My general impression is that the current IoT XEPs are to large and to
complex. It reminds me of the XEP-0136 Messaging Archiving situation,
where this big and complex XEP got not much traction because it is so
heavyweight and hard to implement. And now we have XEP-0313 Message
Archive Management, which is simple, covers most uses cases and is easy
to extend, thus allowing the missing use cases to be added on top. We
should think big, but write simple and modular XEPs.
I started an alternative draft to the IoT XEPs, called "Simple IoT"
(SIoT). It's not really meant for submission, just to have a basis for
discussion. You can find it at
http://geekplace.eu/xeps/xep-siot/xep-siot.html
I believe that XMPP has much to offer for IoT. But I think there is a
little bit room for improvement when it comes to the IoT XEPs as they
are now.
What follows are the polished notes I took while implementing the XEPs.
General
=======
The XEPs are written in style which possible assumes that examples are
normative: Some sections consist mostly of figures and examples. The IoT
XEPs need more normative texts.
XEP-0323 - Data
===============
The data read scheme out should follow the scheme we re-introduced in
XEP-0313: Message Archive Management: IQ-request → data1 → … → dataN →
IQ-result. This would allow to remove the 'done' attribute and this
scheme is a little bit easier to implement. I going to repeat myself,
because I said this in MAM thread years ago: I believe we always should
use this very scheme when requesting data which we expect to be
delivered by multiple stanzas.
Timestamp is not using XEP-0082: XMPP Date and Time Profiles.
Why does it not re-use XSD data types? (SenML [2] also seems like a
potential candidate. Haven had time to look into it though.)
The 32/64-bit integer types: Are they signed or unsigned? I shouldn't be
required to look in § 10. XML Schema to find that out.
Example 7 shows an IQ send to a bare JID. This is likely meant to be an
IQ addressed to a full JID.
It's unclear if things without a node are allowed.
XEP-0324 - Provisioning
====================
§ 3.1.1 "…if the provisioning server is not available in the roster of
the device…"
This falsely mixes the existence of an roster entry with presence
subscription. But the XMPP Roster and Presence Subscription are two
(mostly) orthogonal concepts. You can have a presence subscription
established without a related roster item, and you can have a roster
item without being subscribed.
§ 3.2.2 "Any resource information in the JID must be ignored by the
provisioning server."
Some XEPs of the IoT XEPs go with a different approach of explicitly
disallowing the JID value to be a JID with resourcepart. I suggest
consistency and I would favor the approach of explicitly forbidding the
JID to contain a resourcepart instead of ignoring the resourcepart.
§ 3.2.4 "isFriend(jid) optional, for security"
There is no gain in security if the Device asks the provisioning server
if it really should add the JID as friend. If an attacker is able to
spoof messages with a 'from' JID of the provisioning server, then he is
very likely also able to spoof IQ replies too.
§ 3.5.1
Example 20 uses a bare JID for IQ. Also why isn't the response just an
empty IQ result?
XEP-0325 - Control
=================
Why should we us this instead of XEP-0050: Ad-Hoc Commands? I've seen
people controlling their 2015 home automation system (Homematic) with an
very old Psi version using XEP-0050. Ad-Hoc Commands and Data Forms are
a key strength of XMPP.
§ 3.2.2/3: The 32/64-bit integer types: Are they signed or unsigned? I
shouldn't be required to look in § 10. XML Schema to find that out.
§ 3.1.2: Can we have an empty result IQ instead of an empty
<setResponse/> result?
§ 3.1.2 and § 6.2: Why put 'xml:lang' in <set/> instead of simply in
<iq/>?
XEP-0347 - Discovery
====================
§ 3.9: Claiming a thing: Why are 5 values required to claim a thing,
when a tuple of ID and Key would be sufficient and provide the same
security guarantees? Do we really want the user to enter 5 strings,
every one adding another error source, in order to claim a thing? Or is
it up to the registry/thing/whatever to decide what is sufficient to
claim a thing?
Claiming should be as simple as possible. I've claimed over a hundert
devices in the past months and was always annoyed that I had to enter 5
values.
Example 13 is missing 'cacheId'.
<claimed/> has two semantic: success response to <mine/> *and* claimed
notification to thing. I suggest using two different elements.
Example 46 and 47: When to use a full JID and when to use a bare JID as
value of 'jid' in <disown/>?
§ 5.2 Meta Tags: Why is 'V' (Version Number) of type 'numeric'? Is it
supposed to be an integer, or a version string like "1.2.3-beta4"?
- Florian
1:
https://community.igniterealtime.org/blogs/ignite/2016/07/23/support-for-io…
2: https://www.ietf.org/id/draft-ietf-core-senml-04.txt
15 Nov
15 Nov
7:44 a.m.
Thanks Florian for your thoughts and for the new proposed
XEP.
Just to add my opinion about your first question about
friendship:
I totally agree, one of the main issues indicated by the
“opponents” to the use of XMPP in IoT is about its
overhead,
compared with other protocols, like MQTT.
So, I think that we need to avoid to have the friendship
equivalent to a symmetric presence subscription.
In the same time, the possibility to have presence
notifications must remain as an option,
since I can imagine several scenarios where these
notifications can be useful.
For this reason, I think that, we need to allow both the
requestor and the owner to ask the subscription to
presence notifications in the friendship creation process,
while the friendship must be only a connection among the
entities, stored in the provisioning server.
Davide
On Sun, 13 Nov 2016 20:09:41 +0100
Florian Schmaus <flo(a)geekplace.eu> wrote:
CC'ed to standards@ since I think it is of general
interest. But please
keep the discussion in the iot(a)xmpp.org mailing list.
I enjoyed working with Rikard in the past few months,
implementing the
Internet of Things (IoT) XEPs in Smack [1] and
developing a prototype
App for Android using the XEPs.
The XEPs involved where
- XEP-0323 - Data
- XEP-0324 - Provisioning
- XEP-0325 - Control
- XEP-0347 - Discovery
What do you expect from XEPs for IoT? I've asked this
question many
people in the last few months, and received a broad
range of answers,
including "Do we need XEPs for IoT?" and "I don't
know!".
The Provisioning and Discovery XEPs are the most
interesting ones
regarding this question. The IoT XEPs introduce the
concept of
*friendship* between things. Friends of things can make
use of them,
e.g. reading out their data or remotely controlling
them. Thanks to the
fact that XMPP is federated, a thing from one
manufacturer could become
a friend of a thing from a different manufacturer. This
is described in
XEP-0324 - Provisioning.
Furthermore a thing can be owned by an XMPP entity. It
can register
itself with a registry, so that other things can find
it. This is
described in XEP-0347 - Discovery.
Now, one key issue that the XEPs try to solve is that a
thing — think of
the light-bulb next to you — can not decide on its own
if another thing
is his friend or not. So, if the thing receives a
friendship request, it
basically proxies the request to its provisioning server
(PS), which
will wait for an decision from the thing's owner. This
process is
described in the Provisioning XEP and is basically a
proxy mechanism for
XMPP subscription requests.
And here lies one of the issues we need to discuss.
The concept of friendship is a fundamental building
block of the IoT
XEPs, yet it is nowhere formal specified what friendship
actually is in
terms of XMPP. The XEPs appear map friendship between
things to
subscription states between XMPP entities, but they do
not specify if
friendship is a symmetric relation or an asymmetric one.
XMPP
subscription states are asymmetric: Just because I'm
subscribed to your
presence, it doesn't mean that your are subscribed to
mine. I believe
that the IoT XEPs assume that an thing is a friend if
both are
subscribed to each others presence. But do we really
want that?
I think the answer must be 'no', because things are
(usually) not
interested in the presence states of their friends, and
so, we should
avoid the overhead introduced by presence notifications
where possible.
Think of a thing with many friends: If the thing is
subscribed to the
presence of its friends, it will receive a large amount
of presences. We
definitely need to discuss this.
While implementing we also discovered that the XEPs do
not discuss an
important protocol flow. One of the test scenarios I
implemented in
Smack consists of a provisioning server (PS), a thing, a
owner and an
XMPP entity trying to become a friend of the thing (the
'requestor').
The requestor sends a subscription request to the thing,
in order to
befriend the thing. Now the thing asks the PS whether or
not the
requestor is a friend and the PS will immediately return
that the
requestor is not a friend, because there was no decision
from the owner
yet. Here ends the story in the XEPs. In our scenario,
the owner will
eventually accept or reject the friendship request in
the PS's web
interface. But how does the requestor get notified about
the owners
decision? Possible XEP-0324 § 3.2.4 — but do we want the
requestor to
act on recommendations send from arbitrary JIDs? We also
need to discuss
this.
My general impression is that the current IoT XEPs are
to large and to
complex. It reminds me of the XEP-0136 Messaging
Archiving situation,
where this big and complex XEP got not much traction
because it is so
heavyweight and hard to implement. And now we have
XEP-0313 Message
Archive Management, which is simple, covers most uses
cases and is easy
to extend, thus allowing the missing use cases to be
added on top. We
should think big, but write simple and modular XEPs.
I started an alternative draft to the IoT XEPs, called
"Simple IoT"
(SIoT). It's not really meant for submission, just to
have a basis for
discussion. You can find it at
http://geekplace.eu/xeps/xep-siot/xep-siot.html
I believe that XMPP has much to offer for IoT. But I
think there is a
little bit room for improvement when it comes to the IoT
XEPs as they
are now.
What follows are the polished notes I took while
implementing the XEPs.
General
=======
The XEPs are written in style which possible assumes
that examples are
normative: Some sections consist mostly of figures and
examples. The IoT
XEPs need more normative texts.
XEP-0323 - Data
===============
The data read scheme out should follow the scheme we
re-introduced in
XEP-0313: Message Archive Management: IQ-request → data1
→ … → dataN →
IQ-result. This would allow to remove the 'done'
attribute and this
scheme is a little bit easier to implement. I going to
repeat myself,
because I said this in MAM thread years ago: I believe
we always should
use this very scheme when requesting data which we
expect to be
delivered by multiple stanzas.
Timestamp is not using XEP-0082: XMPP Date and Time
Profiles.
Why does it not re-use XSD data types? (SenML [2] also
seems like a
potential candidate. Haven had time to look into it
though.)
The 32/64-bit integer types: Are they signed or
unsigned? I shouldn't be
required to look in § 10. XML Schema to find that out.
Example 7 shows an IQ send to a bare JID. This is likely
meant to be an
IQ addressed to a full JID.
It's unclear if things without a node are allowed.
XEP-0324 - Provisioning
====================
§ 3.1.1 "…if the provisioning server is not available in
the roster of
the device…"
This falsely mixes the existence of an roster entry with
presence
subscription. But the XMPP Roster and Presence
Subscription are two
(mostly) orthogonal concepts. You can have a presence
subscription
established without a related roster item, and you can
have a roster
item without being subscribed.
§ 3.2.2 "Any resource information in the JID must be
ignored by the
provisioning server."
Some XEPs of the IoT XEPs go with a different approach
of explicitly
disallowing the JID value to be a JID with resourcepart.
I suggest
consistency and I would favor the approach of explicitly
forbidding the
JID to contain a resourcepart instead of ignoring the
resourcepart.
§ 3.2.4 "isFriend(jid) optional, for security"
There is no gain in security if the Device asks the
provisioning server
if it really should add the JID as friend. If an
attacker is able to
spoof messages with a 'from' JID of the provisioning
server, then he is
very likely also able to spoof IQ replies too.
§ 3.5.1
Example 20 uses a bare JID for IQ. Also why isn't the
response just an
empty IQ result?
XEP-0325 - Control
=================
Why should we us this instead of XEP-0050: Ad-Hoc
Commands? I've seen
people controlling their 2015 home automation system
(Homematic) with an
very old Psi version using XEP-0050. Ad-Hoc Commands and
Data Forms are
a key strength of XMPP.
§ 3.2.2/3: The 32/64-bit integer types: Are they signed
or unsigned? I
shouldn't be required to look in § 10. XML Schema to
find that out.
§ 3.1.2: Can we have an empty result IQ instead of an
empty
<setResponse/> result?
§ 3.1.2 and § 6.2: Why put 'xml:lang' in <set/> instead
of simply in <iq/>?
XEP-0347 - Discovery
====================
§ 3.9: Claiming a thing: Why are 5 values required to
claim a thing,
when a tuple of ID and Key would be sufficient and
provide the same
security guarantees? Do we really want the user to enter
5 strings,
every one adding another error source, in order to claim
a thing? Or is
it up to the registry/thing/whatever to decide what is
sufficient to
claim a thing?
Claiming should be as simple as possible. I've claimed
over a hundert
devices in the past months and was always annoyed that I
had to enter 5
values.
Example 13 is missing 'cacheId'.
<claimed/> has two semantic: success response to <mine/>
*and* claimed
notification to thing. I suggest using two different
elements.
Example 46 and 47: When to use a full JID and when to
use a bare JID as
value of 'jid' in <disown/>?
§ 5.2 Meta Tags: Why is 'V' (Version Number) of type
'numeric'? Is it
supposed to be an integer, or a version string like
"1.2.3-beta4"?
- Florian
1:
https://community.igniterealtime.org/blogs/ignite/2016/07/23/support-for-io…
2: https://www.ietf.org/id/draft-ietf-core-senml-04.txt
18 Dec
18 Dec
2:47 p.m.
On 15.11.2016 14:44, CONZON DAVIDE wrote:
I totally agree, one of the main issues indicated by
the “opponents” to
the use of XMPP in IoT is about its overhead,
compared with other protocols, like MQTT.
I don't think that XMPP has an inherent overhead besides it being XML
based. And that overhead can likely be heavily reduced by EXI and the like.
The main problem, and that is not specific to XMPP, is bad protocol
design which imposes unnecessary packets (in XMPPs' case: stanzas) on
the wire.
So, I think that we need to avoid to have the
friendship equivalent to a
symmetric presence subscription.
In the same time, the possibility to have presence notifications must
remain as an option,
Of course. No one is talking about forbidding it. But symmetric presence
subscription should not be be *required*. And I think we should design
the XMPP IoT protocol(s) based on that assumption.
since I can imagine several scenarios where these
notifications can be
useful.
Could you elaborate on those?
- Florian
4:16 p.m.
On Sun, 18 Dec 2016 21:47:17 +0100
Florian Schmaus <flo(a)geekplace.eu> wrote:
I don't think that XMPP has an inherent overhead
besides
it being XML
based. And that overhead can likely be heavily reduced
by EXI and the like.
The main problem, and that is not specific to XMPP, is
bad protocol
design which imposes unnecessary packets (in XMPPs'
case: stanzas) on
the wire.
Probably also the point that you have indicated needs to
be addressed, but for my personal experience,
what people is indicating generally as one of the main
issues of XMPP compared with other IoT protocols
is related to the use of XML. But I agree that this issue
can be addressed with the integration of EXI
like proposed in XEP-0322.
Of course. No one is talking about forbidding it. But
symmetric presence
subscription should not be be *required*. And I think we
should design
the XMPP IoT protocol(s) based on that assumption.
Totally agree.
Could you elaborate on those?
Sure, I think that the presence mechanism is one of the
most important feature that XMPP can provide
in the IoT scenario. If every "Thing" is associated with a
XMPP JID, its presence can be used to know in
real-time if it is online or not and possibly more
specific info, using the status.
As I said, this feature can be useful in several scenario:
- smart-factory, where the presences can be used to keep
monitored the devices in one ore more industrial plants,
- smart-home, where the same feature can be used for the
equiments and sensors deployed in an home.
- smart city, where this feature can be used to monitor
the status of smart objects spread in the city scenario.
More in general, every time can be useful to know in
real-time if one device (or virtual entity) is available
or not and take a decision based on this information.
I hope I made myself clear,
Best Regards,
Davide
3344
days inactive
3379
days old
5 comments
4 participants
participants (4)
-
CONZON DAVIDE -
Dave Cridland -
Florian Schmaus -
Rikard Strid