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

Edwin Mons jsf at edwinm.ik.nu
Wed Apr 2 14:25:25 UTC 2014

On 02/04/14 16:14, Peter Waher wrote:
> 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.

You seem to confuse Historical with Deprecated.  Although the XEP is
historical, the status is active.  Furthermore, all servers I have used
so far support XEP-0114: this is a core feature of most implementations.


More information about the Standards mailing list