On Mon, Apr 7, 2014 at 1:30 PM, Peter Waher <[email protected]>wrote:
> Hello > > > > I've now examined the possibility to use Jabber Components (XEP-0114) for > IoT Discovery and Provisioning, but have some problems. Since it's very > hard to find documentation on this XEP, and searching the internet for > solutions only returns pages with people having the same problems (but no > solutions), I'm turning to the XSF community to see if somebody has any > good input. > > > > First, I can mention that I can send and receive messages and iq stanzas > to and from normal JIDs and a component, as long as I have the resource of > the corresponding JID I want to communicate with. This is no problem, if > the client itself initiates communication. But what if the server component > needs to initiate communication? How does the server component obtain the > resource(s) of a corresponding bare JID? > > > > I've tried a presence probe. That only returns a not-authorized response. > The reason being that otherwise, it would be a security problem, if the > component was able to probe the presence of a JID, without being a friend. > (However, sending messages and iq stanzas to the JID, if you had the > resource, was OK, even without friendship.) > > > > The next thing I tried was to send a presence subscription to the JID from > the component. This request was not received by the client, regardless if I > tried with sending it from the component itself, or a virtual JID simulated > by the component. Searching the internet, this was the response I was > given: You needed to simulate accounts behind the component (using the same > component domain name). > > > > Is there a step that needs to be taken before sending the presence > subscription, for it to be routed correctly to the device? > > > > Or is presence subscriptions somehow disabled in server components? > > > > Or might this behave differently on different XMPP servers? (I'm using an > OpenFire XMPP server to test my implementation.) > > > > Example of communication that goes well. Here the component, given the > full JID of a client, is able to perform an IQ get & receive a response: > > > > C: <iq from='test.clayster.cl' to='[email protected]/2e2b3ea4' > type='get' id='1'><query xmlns="http://jabber.org/protocol/disco#info > "/></iq> > > S: <iq from="[email protected]/2e2b3ea4" to="test.clayster.cl" > type="result" id="1"><query > xmlns="http://jabber.org/protocol/disco#info";><identity > category="client" type="pc" name="Clayster"/><feature var=" > http://jabber.org/protocol/disco#info"/><feature var=" > http://jabber.org/protocol/disco#items"/><feature > var="jabber:iq:roster"/><feature var="jabber:iq:version"/><feature > var="vcard-temp"/></query></iq> > > > > While, on the client side, it looks as follows: > > > > S: <iq from="test.clayster.cl" to="[email protected]/2e2b3ea4" > type="get" id="1"><query xmlns="http://jabber.org/protocol/disco#info > "/></iq> > > C: <iq from='[email protected]/2e2b3ea4' to='test.clayster.cl' > type='result' id='1'><query > xmlns="http://jabber.org/protocol/disco#info";><identity > category="client" type="pc" name="Clayster"/><feature var=" > http://jabber.org/protocol/disco#info"/><feature var=" > http://jabber.org/protocol/disco#items"/><feature > var="jabber:iq:roster"/><feature var="jabber:iq:version"/><feature > var="vcard-temp"/></query></iq> > > > > > > This is how the failed attempt looks like, where the component itself > makes a presence probe to retrieve the resource of a bare JID. When it > fails it tries to request a subscription on presence. > > > > C: <presence id="dba12ec4de04b5575d1070ae730aa351" from="test.clayster.cl" > to="[email protected]" type="probe"/> > > S: <presence type="error" to="test.clayster.cl" > from="[email protected]"><error > code="401" type="auth"><not-authorized > xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/></error></presence> > > C: <presence id="dba12ec4de04b5575d1070ae730aa351" from="test.clayster.cl" > to="[email protected]" type="subscribe"/> > > > > Nothing is received on the client side. I try the same thing, but with a > simulated account behind the component domain: > > > > C: <presence id="e107698373251736e53678e2e4fc1a2d" from=" > [email protected]" to="[email protected]" type="probe"/> > > S: <presence type="error" to="[email protected]" from=" > [email protected]"><error code="401" type="auth"><not-authorized > xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/></error></presence> > > C: <presence id="e107698373251736e53678e2e4fc1a2d" from=" > [email protected]" to="[email protected]" type="subscribe"/> > > > > Nothing is received by the client. > > > > Hopefully, somebody with more insight can answer the above questions, or > give other insights on how to proceed. If I can initiate communication from > a server component, it would be a very good option to use in the IoT > Discovery XEP proposal and the Provisioning XEP. > > > > Best regards, > > Peter Waher > > > Your component can send messages to the bare JID of the user, which would then be sent to the resources with highest priority (depending on server config, etc). That's the normal way to initiate a conversation with a bare JID when you don't have a full JID available. Regarding presence subscriptions, is your component doing any roster handling? It has to send a subscription request to the user, and receive the user's subscription acceptance, optionally storing this information (as the component's roster), after which it can probe the user (assuming the user accepted). The XMPP server does not manage rosters or subscriptions for XEP-0114 components. It only does so for users. The server mainly handles XMPP Core (RFC 6120) for components, while everything in XMPP IM (RFC 6121) is up to the components themselves. Prosody plug: I've switched to writing components as Prosody plugins, so I can reuse a lot of Prosody's c2s machinery, and I wrote mod_component_client to then allow Prosody to act as a XEP-0114 component to other servers. -- Waqas Hussain
