[Standards] Proposed XMPP Extension: Internet of Things - Discovery

Peter Waher Peter.Waher at clayster.com
Wed Apr 2 14:14:36 UTC 2014


Hello Philipp

Thanks for your insightful input. My response to the main item:

>>> section 3.4:
>>> I don't think IBR should be recommended anymore.
>>
>> IoT requires automatic account creation. However, I agree it must also be secure, from the point of view of the server administrator, especially if servers are publically available. I will post a separate XEP soon, that provides a secure in-band registration mechanism that can be used by things.
>>
>>> section 3.5:
>>> I would recommend moving the discovery to standard disco#items and to use components (xep-0114) -- those are not much harder to write than standard clients and have many advantages in terms of managability.
>>
>> Note sure here how this relates to 3.5. Was it a particular step you referred to?
>
> Basically I'd like to see the method #3 in 3.5 as the one and only way to do it, with examples. Basically a slightly expanded version of the "determining support" section:
> disco#items to the server
> then disco#info to each item to look for something which has a urn:xmpp:iot:discovery.
>
>xep-0114 style components are just a very convenient way to do this in most server implementation, but I assumed that you had implemented this using a registry which was running over c2s. So I mixed up implementation comments and protocol comments :-/
>
>I don't have a strong opinion whether that should be done before accepting it or afterwards. Might be handy to pretend the other methods never existed.

Ok. I will certainly have a look at the Jabber Components Protocol (XEP-0114). Even though it is historical, it looks promising. Is there any more recent information available than http://xmpp.org/extensions/xep-0114.html?

One of the mayor problems is that in IoT architecture, we can in many cases not choose the XMPP server. In some cases we do, but not in the most important cases where for instance large operators or companies already have their XMPP server chosen (their own in many cases). Since the XMPP server has already been chosen by the operator in these cases, we need a solution that can work regardless of XMPP server used.

This does not mean XEP-0114 is not a good idea to use, especially if available. The problem is, this cannot be guaranteed. I will most certainly explore this. However, is it possible that we do this during experimental phase? This gives me some time to investigate how widespread the support for XEP-0114 in the XMPP servers chosen for us is. It will also give us some feedback if this can be said to be the main option, or a supplementary option to use.

Ok?

Another concern is the following description in the introduction: "While this component protocol is minimal and will probably be superseded by a more comprehensive component protocol at some point".

Do you know anything about such plans for a future more comprehensive component protocol?

Best regards,
Peter Waher




More information about the Standards mailing list