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
