[IOT] Comments on discovery paragraph 5.1

Joachim Lindborg joachim.lindborg at sust.se
Wed Apr 1 15:54:56 UTC 2015

I have done the same using "friendship" for "mutal precense subscription".
It is very useful when talking to non xmpp folks since it is a way for
showing a level of granted access rights used in social media. Eg. *giving
access to your "friends" *

Agree that this isn't something to be part of the xep it should be clear
that we talk about "presence subscription" in different directions.

I think we also need in IoT to have servers dropping messages to the full
JID if you don't have presence subscriptions in place. Otherwise devices
need to do that through the provisioning (XEP 324) blocking untrusted JID's


*Time for Global IoTDay April 9th join us at KTH for a full day of
connected devices <http://simplesignup.se/event/57527>*

Joachim Lindborg
CTO, systems architect

Sustainable Innovation  SUST.se
Barnhusgatan 3 111 23 Stockholm
Email: Joachim.lindborg at sust.se
linkedin: http://www.linkedin.com/in/joachimlindborg
Tel +46 706-442270

2015-04-01 15:56 GMT+02:00 Cramer, E.R. (Eelco) <Eelco.Cramer at tno.nl>:

> 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 at 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.
> _______________________________________________
> IOT mailing list
> IOT at xmpp.org
> http://mail.jabber.org/mailman/listinfo/iot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/iot/attachments/20150401/0769c5be/attachment.html>

More information about the IOT mailing list