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

Steffen Larsen zooldk at gmail.com
Wed Apr 2 14:25:13 UTC 2014


Hi Peter et. al.

Just a quick one about XE-0114 (external components): Most xmpp developers are putting their business logic there and its dead simple and every server out there supports it. + since its a protocol and can be run as client or server it makes it very portable and robust. :-)

/Steffen

On 02 Apr 2014, at 16:14, Peter Waher <Peter.Waher at clayster.com> 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.
> 
> 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
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4130 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20140402/36c791b3/attachment.bin>


More information about the Standards mailing list