Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery
Hi Peter, On 03 Apr 2014, at 14:03, Peter Waher peter.wa...@clayster.com wrote: Hello Edwin Co. 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. Actually, I do not. I am aware of the difference. What historical tells me, apart from it being historical, i.e. part of the Jabber project before being formalized, is that it: * Is not sufficiently important to have been lifted and issues discussed and fixed, to become draft or final (or RFC). * Any changes to it are not guaranteed to be backwards compatible. * It's future is unclear, which is also stated in the XEP. * It's use and implementation variants are unclear. * Security aspects are unclear. * It is not recommended by XSF or xmpp.org anywhere. After having investigated XEP-0114 now in some more detail, there are various aspects which concerns me. Since Jabber components seems to be a third way to connect to an XMPP server (the other two being c2s and s2s), and a very useful one at that I must agree, I think the XSF should take some time and effort in formalizing this XEP a bit, and fixing some of its flaws. I'm told that it uses an old version of XMPP (0.9), and I wonder if it is not in everybody's interest to lift it to v1.0, and allow things such as starttls, etc. to make it more secure. Today, there is no way for the client (component) to validate that the server is who it pretends to be, which makes MITM attacks quite easy. And since you get such a direct access to the server, it looks very much like a backdoor to me. I completely agree about making XEP-0114 (external components) more suitable and secure like any other S2S scenario. Lifting it to a XMPP version 1.0 stage would be great, but would also break a lot of implementations. Best regards, Peter Waher -Cheers /Steffen smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery
On 7 April 2014 08:27, Steffen Larsen zoo...@gmail.com wrote: I completely agree about making XEP-0114 (external components) more suitable and secure like any other S2S scenario. Lifting it to a XMPP version 1.0 stage would be great, but would also break a lot of implementations. I'm not entirely sure. I've seen *some* implementations break when they receive stream features they weren't expecting, but most existing implementations don't send the version attribute, so won't get them. So it'll break *some* implementations, and an implementation *might* want to offer component support on ports that suppress all features as a result. How widespread the problem would be is, I think, an unknown at this point. The alternative is we just say Components are privately-authenticated S2S connections, and invoke BiDi and SASL auth and make it happen. This is functionally equivalent, but differs in that components are no longer special in any way (aside from near-mandatory support for XEP-0288), aren't backwards compatible with the older protocol, which becomes obsolete. That appeals to my sense of purity, and is likely significantly more secure in a number of ways. (At the very least, the security profile would be better understood). Dave.
Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery
The alternative is we just say Components are privately-authenticated S2S connections, and invoke BiDi and SASL auth and make it happen. This is functionally equivalent, but differs in that components are no longer special in any way (aside from near-mandatory support for XEP-0288), aren't backwards compatible with the older protocol, which becomes obsolete. That appeals to my sense of purity, and is likely significantly more secure in a number of ways. (At the very least, the security profile would be better understood). Well, I think the primary differences are that a) components will appear in disco#items b) a server won't attempt to connect to a component
Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery
On 7 April 2014 10:04, Philipp Hancke fi...@goodadvice.pages.de wrote: The alternative is we just say Components are privately-authenticated S2S connections, and invoke BiDi and SASL auth and make it happen. This is functionally equivalent, but differs in that components are no longer special in any way (aside from near-mandatory support for XEP-0288), aren't backwards compatible with the older protocol, which becomes obsolete. That appeals to my sense of purity, and is likely significantly more secure in a number of ways. (At the very least, the security profile would be better understood). Well, I think the primary differences are that a) components will appear in disco#items I think that's orthogonal, actually - you could list ancilliary services hosted on full S2S via disco#items as well. For example, a site might choose to host their FT proxy or media relay on entirely different hosting to their IM services. So I suspect that while components are *often* listed, they're not always. Besides which, my proposal isn't that components wouldn't need provisioning of their own - it's just a protocol change, not a deployment one. b) a server won't attempt to connect to a component That's not strictly true either, but again, I think you'd provision components nonetheless - this is purely unifying the protocol. They'd need to be provisioned, possibly given a password, and so on. There's an implication here that a component *could* be connected to, as well, but you'd obviously need to manually specify the endpoint in the server's configuration. However, by moving on from XEP-0114, we'd be able to reduce the attack surface - it'd be no different to C2S/S2S from a security standpoint (though possibly with additional considerations given trusted components and allowed spoofing, etc). Dave.
Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery
Hello Edwin Co. 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. Actually, I do not. I am aware of the difference. What historical tells me, apart from it being historical, i.e. part of the Jabber project before being formalized, is that it: * Is not sufficiently important to have been lifted and issues discussed and fixed, to become draft or final (or RFC). * Any changes to it are not guaranteed to be backwards compatible. * It's future is unclear, which is also stated in the XEP. * It's use and implementation variants are unclear. * Security aspects are unclear. * It is not recommended by XSF or xmpp.org anywhere. After having investigated XEP-0114 now in some more detail, there are various aspects which concerns me. Since Jabber components seems to be a third way to connect to an XMPP server (the other two being c2s and s2s), and a very useful one at that I must agree, I think the XSF should take some time and effort in formalizing this XEP a bit, and fixing some of its flaws. I'm told that it uses an old version of XMPP (0.9), and I wonder if it is not in everybody's interest to lift it to v1.0, and allow things such as starttls, etc. to make it more secure. Today, there is no way for the client (component) to validate that the server is who it pretends to be, which makes MITM attacks quite easy. And since you get such a direct access to the server, it looks very much like a backdoor to me. Best regards, Peter Waher
Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery
Example: Consider 100'000 devices connecting to an XMPP server they've found somehow, and then need to find a Thing Registry to register themselves. One might be preconfigured, but I want to include the case when one is not. 100'000 devices cannot start looping through all possible JIDs and ask service discovery to find out who can what. So it needs, as a last attempt, to try to find it somehow. How do you suggest this done, if you do not accept the methods proposed (as the last resource)? The approach we would suggest is that the Thing Registry be implemented as a server component (and thanks to XEP-0114 can be used with any XMPP server that supports XEP-0114, which is to say all of them). A Thing would then iterate over the items in a disco#items result for the XMPP server, looking for one that provides the registry feature. The disco#items result for a server is on the order of tens, not hundreds of thousands. For example, that process is how a user discovers SOCKS5 proxies for file transfers. Implementing a service like the IoT Thing Registry using a client connection is, from our collective experience as XMPP devs, ill advised even though it is technically possible. Note that several sections of the proposed XEP exist solely to work around issues from using a client connection (presence subscriptions and limitations with roster sizes) that a server component does not need to deal with. XEP-0055 has several shortcomings when it comes to the search function we've proposed. This is why we did not used it. Agreed that XEP-0055 does not meet the needs for this case. However, in terms of re-using existing protocol building blocks, you should look into XEP-0077 some more. People seem to overlook that XEP-0077 is not just IBR for new XMPP account provisioning, but also a protocol letting an existing JID register with an arbitrary service, and then later update or remove that registration. Even the cases where you need additional information (such as when Concentrators are used) can be handled using XEP-0077 if that extra data can be expressed via data forms. Implementing some new service as a component, and letting users (which in this case would be Things) opt-in for that service using XEP-0077 is a common historical pattern. — Lance signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery
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
Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery
Hello Lance Thanks for taking the time to read the proposal and your input. My responses to your concerns below: Example: Consider 100'000 devices connecting to an XMPP server they've found somehow, and then need to find a Thing Registry to register themselves. One might be preconfigured, but I want to include the case when one is not. 100'000 devices cannot start looping through all possible JIDs and ask service discovery to find out who can what. So it needs, as a last attempt, to try to find it somehow. How do you suggest this done, if you do not accept the methods proposed (as the last resource)? The approach we would suggest is that the Thing Registry be implemented as a server component (and thanks to XEP-0114 can be used with any XMPP server that supports XEP-0114, which is to say all of them). A Thing would then iterate over the items in a disco#items result for the XMPP server, looking for one that provides the registry feature. The disco#items result for a server is on the order of tens, not hundreds of thousands. For example, that process is how a user discovers SOCKS5 proxies for file transfers. Implementing a service like the IoT Thing Registry using a client connection is, from our collective experience as XMPP devs, ill advised even though it is technically possible. Note that several sections of the proposed XEP exist solely to work around issues from using a client connection (presence subscriptions and limitations with roster sizes) that a server component does not need to deal with. As I responded to Philipp, XEP-0114 looks promising. I take the liberty to copy the response to the same argument: 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? However, in terms of re-using existing protocol building blocks, you should look into XEP-0077 some more. People seem to overlook that XEP-0077 is not just IBR for new XMPP account provisioning, but also a protocol letting an existing JID register with an arbitrary service, and then later update or remove that registration. Even the cases where you need additional information (such as when Concentrators are used) can be handled using XEP-0077 if that extra data can be expressed via data forms. Implementing some new service as a component, and letting users (which in this case would be Things) opt-in for that service using XEP-0077 is a common historical pattern. Not sure exactly what you mean here. In what sense do you see XEP-0077 to be used in this proposal, apart from IBR? Best regards, Peter Waher
Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery
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.wa...@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 smime.p7s Description: S/MIME cryptographic signature
Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery
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. Edwin
Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery
Hi Peter, section 3.3.1 describes how to find an xmpp servers. The methods described there aren't limited to iot (at least the dhcp one), so it might be a good idea to split them off. Not sure how useful that is however. Ok. Can we break this out at a later stage? I agree it makes sense to have §3.3 in a separate XEP. But can we wait with this until Experimental phase, when it is more complete and we have experimented with it a bit? Works for me. 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. Having hardcoded accounts like 'discovery' is a no-go imo, even with the security considerations. Ok. Have removed the hardcoded accounts. Thanks. I'll try to review that before the next council meeting. philipp
Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery
On Thu, Mar 27, 2014 at 2:31 PM, Philipp Hancke fi...@goodadvice.pages.de wrote: Am 13.03.2014 17:26, schrieb XMPP Extensions Editor: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Internet of Things - Discovery Abstract: This specification describes an architecture based on the XMPP protocol whereby Things can be installed and safely discovered by their owners and connected into networks of Things. URL: http://xmpp.org/extensions/inbox/iot-discovery.html The XMPP Council will decide in the next two weeks whether to accept this proposal as an official XEP. some comments after reviewing it: section 3.3.1 describes how to find an xmpp servers. The methods described there aren't limited to iot (at least the dhcp one), so it might be a good idea to split them off. Not sure how useful that is however. I think it's potentially useful outside IoT. section 3.4: I don't think IBR should be recommended anymore. 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. Having hardcoded accounts like 'discovery' is a no-go imo, even with the security considerations. Affects all examples, but that might be a simple search-replace. I agree with Fippo that using hard-coded account/nicks isn't right. This seems to be standard disco all the way - it then doesn't matter what form the JID takes, be it user-style or domain-style. 3.14 seems, at first glance, like it would be a candidate for 55 with extended forms rather than inventing new protocol. Thoughts? /K
Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery
Hello Philipp Thanks a lot for the input, and taking the time to read the proposal. I'll try to address your concerns one at a time: section 3.3.1 describes how to find an xmpp servers. The methods described there aren't limited to iot (at least the dhcp one), so it might be a good idea to split them off. Not sure how useful that is however. Ok. Can we break this out at a later stage? I agree it makes sense to have §3.3 in a separate XEP. But can we wait with this until Experimental phase, when it is more complete and we have experimented with it a bit? 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? Having hardcoded accounts like 'discovery' is a no-go imo, even with the security considerations. Ok. Have removed the hardcoded accounts. Affects all examples, but that might be a simple search-replace. Not really. The examples, are only examples. Now, with the hardcoded step discovery@domain, is just a JID, like any other. section 3.11: the comment from 3.5 applies here as well. Hardcoded accounts have been removed. example 36 closes update instead of search. Updated. Best regards, Peter Waher
Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery
Hello Ivan. Thanks for your question. As the XEP has been written it says “This can be done using one of several methods:”, that is, one of the options is sufficient. But the XEP lists different options (i.e. strategies) that might be useful in different scenarios. Best regards, Peter Waher From: Ivan Vučica [mailto:i...@vucica.net] Sent: den 27 mars 2014 19:38 To: XMPP Standards Subject: Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery Re: section 3.3.x Doesn't more choices for discovery mean servers and clients need to implement all choices? I'd go with the mDNS/DNSSD method only as it is already widely used for other discovery uses. DHCP may not be easily configurable by the XMPP server administrator. sent from phone On Mar 27, 2014 2:36 PM, Philipp Hancke fi...@goodadvice.pages.demailto:fi...@goodadvice.pages.de wrote: Am 13.03.2014 17:26, schrieb XMPP Extensions Editor: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Internet of Things - Discovery Abstract: This specification describes an architecture based on the XMPP protocol whereby Things can be installed and safely discovered by their owners and connected into networks of Things. URL: http://xmpp.org/extensions/inbox/iot-discovery.html The XMPP Council will decide in the next two weeks whether to accept this proposal as an official XEP. some comments after reviewing it: section 3.3.1 describes how to find an xmpp servers. The methods described there aren't limited to iot (at least the dhcp one), so it might be a good idea to split them off. Not sure how useful that is however. section 3.4: I don't think IBR should be recommended anymore. 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. Having hardcoded accounts like 'discovery' is a no-go imo, even with the security considerations. Affects all examples, but that might be a simple search-replace. section 3.11: the comment from 3.5 applies here as well. example 36 closes update instead of search.
Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery
Hello Kevin Thanks for taking the time to read the proposal, and come with input. I'll address your concerns one at a time: section 3.3.1 describes how to find an xmpp servers. The methods described there aren't limited to iot (at least the dhcp one), so it might be a good idea to split them off. Not sure how useful that is however. I think it's potentially useful outside IoT. As I responded to Philipp: Ok. Can we break this out at a later stage? I agree it makes sense to have §3.3 in a separate XEP. But can we wait with this until Experimental phase, when it is more complete and we have experimented with it a bit? I agree with Fippo that using hard-coded account/nicks isn't right. This seems to be standard disco all the way - it then doesn't matter what form the JID takes, be it user-style or domain-style. The hard-coded accounts have been removed. But there seems to be a misunderstanding somewhere, since you and Philipp both refer to server-side components for detecting Thing Registries and Provisioning Servers. These two are not (necessarily) XMPP Servers. The default case will be that they are not XMPP servers. I.e. the XMPP Server is just a replaceable infrastructure component, and does not actually host any IoT logic. Example: Consider 100'000 devices connecting to an XMPP server they've found somehow, and then need to find a Thing Registry to register themselves. One might be preconfigured, but I want to include the case when one is not. 100'000 devices cannot start looping through all possible JIDs and ask service discovery to find out who can what. So it needs, as a last attempt, to try to find it somehow. How do you suggest this done, if you do not accept the methods proposed (as the last resource)? 3.14 seems, at first glance, like it would be a candidate for 55 with extended forms rather than inventing new protocol. Thoughts? XEP-0055 has several shortcomings when it comes to the search function we've proposed. This is why we did not used it. The main arguments against the use of XEP-0055 are: * XEP-0055 require you to get a data form with possible search options. Consider a Thing Registry with hundreds of different tags (perhaps thousands, since all things can invent their own, and only a few tags are standardized in the since they have fixed tag names and meaning, as defined in the document). How would such a search form look like? One field for every tag in the server? It would quickly diverge into something completely unusable. The other method is to have a set of field pairs, one with tag name, and one with value. But how many such pairs should be available in the form? The only way to solve this without imposing limits is to use dynamic forms that can dynamically extend the form as your input values. Needless to say, this is a very complex method of accomplishing a simple task. * We want to include search operation and ranges into the search. Doing this would add even further fields to the form. You would need up to 4 fields per tag. And again, the fourth field only have meaning if a range operator is used. Even here, dynamic forms would be required to make sense of it all. * How do you solve data types and validation? If you in the form don't know beforehand what tag is to be used? Validation of values can only be done if all tags are listed (and data types for tags are consistent). But as mentioned above, listing all tags in a form is simply not practically an option. * There are today no validation schemes available to XEP-0055 for the type of input this search required (cross field validation). Some shortcomings may be amended by dynamic forms, but the resulting form would just be too complicated, according to my point of view. (And I've written the dynamic forms extension.) * Since Interoperability is very important in IoT, if data forms are to be used, the resulting form type must be registered and agreed on, a task that I simply judged to be impossible for this case. (i.e. make everybody agree on a form type, and then implement support for it) To conclude: The implementation effort used to build this kind of search (or query) on-top of XEP-0055 and data forms would be, in my judgment, far greater, and with poor results, than by just including a new search element for this particular query, and skipping the data form altogether. Since XEP-0055 is a Historic XEP, and not a Draft or Final XEP, it cannot be considered to have to be used for every search query done over XMPP networks. If it is the work search that is bothersome here (since there are many queries being done over XMPP that does not use XEP-0055), do you want me to rephrase this section to discuss how to perform a query instead of a search? Best regards, Peter Waher
Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery
Am 13.03.2014 17:26, schrieb XMPP Extensions Editor: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Internet of Things - Discovery Abstract: This specification describes an architecture based on the XMPP protocol whereby Things can be installed and safely discovered by their owners and connected into networks of Things. URL: http://xmpp.org/extensions/inbox/iot-discovery.html The XMPP Council will decide in the next two weeks whether to accept this proposal as an official XEP. some comments after reviewing it: section 3.3.1 describes how to find an xmpp servers. The methods described there aren't limited to iot (at least the dhcp one), so it might be a good idea to split them off. Not sure how useful that is however. section 3.4: I don't think IBR should be recommended anymore. 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. Having hardcoded accounts like 'discovery' is a no-go imo, even with the security considerations. Affects all examples, but that might be a simple search-replace. section 3.11: the comment from 3.5 applies here as well. example 36 closes update instead of search.
Re: [Standards] Proposed XMPP Extension: Internet of Things - Discovery
Re: section 3.3.x Doesn't more choices for discovery mean servers and clients need to implement all choices? I'd go with the mDNS/DNSSD method only as it is already widely used for other discovery uses. DHCP may not be easily configurable by the XMPP server administrator. sent from phone On Mar 27, 2014 2:36 PM, Philipp Hancke fi...@goodadvice.pages.de wrote: Am 13.03.2014 17:26, schrieb XMPP Extensions Editor: The XMPP Extensions Editor has received a proposal for a new XEP. Title: Internet of Things - Discovery Abstract: This specification describes an architecture based on the XMPP protocol whereby Things can be installed and safely discovered by their owners and connected into networks of Things. URL: http://xmpp.org/extensions/inbox/iot-discovery.html The XMPP Council will decide in the next two weeks whether to accept this proposal as an official XEP. some comments after reviewing it: section 3.3.1 describes how to find an xmpp servers. The methods described there aren't limited to iot (at least the dhcp one), so it might be a good idea to split them off. Not sure how useful that is however. section 3.4: I don't think IBR should be recommended anymore. 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. Having hardcoded accounts like 'discovery' is a no-go imo, even with the security considerations. Affects all examples, but that might be a simple search-replace. section 3.11: the comment from 3.5 applies here as well. example 36 closes update instead of search.
[Standards] Proposed XMPP Extension: Internet of Things - Discovery
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Internet of Things - Discovery Abstract: This specification describes an architecture based on the XMPP protocol whereby Things can be installed and safely discovered by their owners and connected into networks of Things. URL: http://xmpp.org/extensions/inbox/iot-discovery.html The XMPP Council will decide in the next two weeks whether to accept this proposal as an official XEP.
