1 Apr
2015
1 Apr
'15
5:52 a.m.
Hi,
Paragraph 5.1 of XEP-0347 says it is only needed to ‘become friends’ with the Thing
registry if the registry isn’t a server component.
5.1 JID vs Component Thing Registries <>
A client must treat the connection between a Thing Registry differently if it is hosted
as a client, having a JID, or if it is hosted as a Jabber Server Component. If it is
hosted as a server component, there's no need for the thing to become friends with the
Thing Registry. Messages and requests can be made directly to the server component without
having to add it to the roster or request presence subscriptions. If the Thing Registry is
hosted as a client, having a JID (@ in the address), the Thing Registry must be added to
the roster of the client before the client can communicate with the Thing Registry.
However, for the registry to determine if a Thing is online or offline (to check
if it is able to notifiy it about claimed, disowned and removed states) the Thing registry
needs a presence subscription with the Thing. This does not mean that the Thing also has a
presence subscription on the registry but there must be some kind of ‘friendship’ relation
between the 2. So the text above is ambiguous in my opinion.
Also paragraph “3.6 Registering a Thing” states that a Thing must find and befriend a
registry before the Thing can register itself with the registry.
Should paragraph 5.1 be updated or removed?
Thanks,
Eelco
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.
1 Apr
1 Apr
7:16 a.m.
On 01.04.2015 13:52, Cramer, E.R. (Eelco) wrote:
Hi,
Paragraph 5.1 of XEP-0347 says it is only needed to ‘become friends’
with the Thing registry if the registry isn’t a server component.
I'm by no means an XMPP-IoT expert but XEP-347 § 5.1:
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.
- Florian
5.1 JID vs Component Thing Registries
A client must treat the connection between a Thing Registry
differently if it is hosted as a client, having a JID, or if it is
hosted as a Jabber Server Component. If it is hosted as a server
component, there's no need for the thing to become friends with the
Thing Registry. Messages and requests can be made directly to the
server component without having to add it to the roster or request
presence subscriptions. If the Thing Registry is hosted as a client,
having a JID (@ in the address), the Thing Registry must be added to
the roster of the client before the client can communicate with the
Thing Registry.
However, for the registry to determine if a Thing is online or offline
(to check if it is able to notifiy it about claimed, disowned and
removed states) the Thing registry needs a presence subscription with
the Thing. This does not mean that the Thing also has a presence
subscription on the registry but there must be some kind of ‘friendship’
relation between the 2. So the text above is ambiguous in my opinion.
Also paragraph “3.6 Registering a Thing” states that a Thing must find
and befriend a registry before the Thing can register itself with the
registry.
Should paragraph 5.1 be updated or removed?
7:56 a.m.
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.
9:54 a.m.
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
/joachim
*Time for Global IoTDay April 9th join us at KTH for a full day of
connected devices <http://simplesignup.se/event/57527>*
*Regards*
Joachim Lindborg
CTO, systems architect
Sustainable Innovation SUST.se
Barnhusgatan 3 111 23 Stockholm
Email: Joachim.lindborg(a)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(a)tno.nl>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(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.
_______________________________________________
IOT mailing list
IOT(a)xmpp.org
http://mail.jabber.org/mailman/listinfo/iot
3456
days inactive
3456
days old
3 comments
3 participants
participants (3)
-
Cramer, E.R. (Eelco) -
Florian Schmaus -
Joachim Lindborg