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
