Hi Florian,
Thanks for your response.
I do not like the term 'friendship' in the IoT XEP so much as it creates a new
terminology for an old concepts (presence subscription) IMO.
I might be unaware but what is the difference between 'friendship' and having a
presence subscription?
If I understand correct from the RFCs the server automatically adds presence subscribers
to the roster of clients. For reasons of scaling it does not do this for components.
Also I believe a reason to be in each other rosters is to make it possible to send IQ
requests to the bare JID. If this is not the case I think these packets will be dropped by
the server.
To be able to send notifications about 'ownership' changes the registry needs to
be able to check the online state of Things otherwise Things might not receive these
messages. For a server component to be able to check the online state via a presence
probe, the component needs to be registered to the Thing's presence state as well.
To me paragraph 5.1 creates fuzz about presence subscriptions.
On 01 Apr 2015, at 15:16, Florian Schmaus
<flo(a)geekplace.eu> wrote:
1. appears to mix the IoT "friend" concept with presence
subscription/roster state.
2. "If the Thing Registry is hosted as a client …, the Thing Registry
must be added to the roster of the client before the client can
communicate with the Thing Registry." There is usually no reason to be
in each others roster in order to exchange data/communicate.
re 1. It is unclear if "become friends" means "subscribe to the
presence" or in terms of XEP-324 § 3.2, because it first says "if
component, then no need to become friends" but then "if client, then
must be added to the roster".
I think § 5.1 needs some some clarification.
The whole IoT XEPs should put more effort into stressing the fact that
"friendship" in IoT is not "having you in the roster", which unaware
readers may think. I suggest adding a 'Friend' item to § 2. Glossary
pointing to XEP-324 § 3.2.
This message may contain information that is not intended for you. If you are not the
addressee or if this message was sent to you by mistake, you are requested to inform the
sender and delete the message. TNO accepts no liability for the content of this e-mail,
for the manner in which you use it and for damage of any kind resulting from the risks
inherent to the electronic transmission of messages.