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
