[Standards] Need help with problems regarding XEP-0114.

Waqas Hussain waqas20 at gmail.com
Mon Apr 7 20:09:37 UTC 2014


On Mon, Apr 7, 2014 at 1:30 PM, Peter Waher <Peter.Waher at clayster.com>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='unittest at clayster.cl/2e2b3ea4'
> type='get' id='1'><query xmlns="http://jabber.org/protocol/disco#info
> "/></iq>
>
> S: <iq from="unittest at clayster.cl/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="unittest at clayster.cl/2e2b3ea4"
> type="get" id="1"><query xmlns="http://jabber.org/protocol/disco#info
> "/></iq>
>
> C: <iq from='unittest at clayster.cl/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="unittest at clayster.cl" type="probe"/>
>
> S: <presence type="error" to="test.clayster.cl" from="unittest at clayster.cl"><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="unittest at clayster.cl" 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="
> unittest at test.clayster.cl" to="unittest at clayster.cl" type="probe"/>
>
> S: <presence type="error" to="unittest at test.clayster.cl" from="
> unittest at clayster.cl"><error code="401" type="auth"><not-authorized
> xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/></error></presence>
>
> C: <presence id="e107698373251736e53678e2e4fc1a2d" from="
> unittest at test.clayster.cl" to="unittest at clayster.cl" 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20140407/a6453a34/attachment.html>


More information about the Standards mailing list