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
