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

Peter Waher Peter.Waher at clayster.com
Mon Mar 31 22:16:01 UTC 2014


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




More information about the Standards mailing list