Hi Peter, > Trying this on the server I use (OpenFire), messages (and IQ stanzas) > sent to bare JIDs are not forwarded to the corresponding client. > Should it?
iq stanzas are never forwarded. Message stanzas are only forwarded to "available resources", i.e. resources that that sent initial presence.
Sending two messages from the component: C: <message from="test.clayster.cl" to="[email protected]/f9e7b2c1" id="1" xml:lang="sv" type="normal">Normal message<body>hej</body></message> C: <message from="test.clayster.cl" to="[email protected]" id="2" xml:lang="sv" type="normal">Normal message<body>hej</body></message> However, on the client side, only one message is received, the one with the resource. Furthermore, no error message is returned:
Have you checked offline storage?
S: <message from="test.clayster.cl" to="[email protected]/f9e7b2c1" id="1" xml:lang="sv" type="normal">Normal message<body>hej</body></message> Which XMPP server do you use, where this works? Is it possible for me to try to connect to a component to that server and see if it works differently then OpenFire? Searching RFC 6120, I cannot see if sending messages and IQ stanzas to bare JIDs is actually allowed or not. What I find in RFC 6120 is that "responding differently" to requests sent to bare JIDs and full JIDs allows for directory harvesting, which is considered bad. I interpret this as a recommendation to disallow (and not respond) to messages/requests sent to bare JIDs, since it's the only way to avoid responding differently ...
Both is allowed and useful. Note that sending iq to the bare jid is typically only useful for things like requesting the vcard.
Does anybody has some light to shed on this? 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. I do send a presence stanza with a presence subscription request, in case the probe fails. Regarding roster: Since the roster is handled (or simulated) by the component, in what way other than sending a presence subscription stanza, should the component perform roster handling with the server? I thought roster handling was between client and its server, but not between servers or between component and server.
Well, your component ought to manage it's subscriptions, but trying to send a probe and then dealing with an error might be a good-enough approach. Note that sending probes and getting errors back might not work like this on all implementations. You might get unsubscribed instead, regardless of whether the account exists (re directory harvesting)
What I do is: <presence id="e107698373251736e53678e2e4fc1a2d" from="[email protected]" to="[email protected]" type="subscribe"/> A corresponding presence is not received by the client. What case of roster handling is supposed to happen before?
Have you sent presence and requested the roster on the client? Roster pushes (i.e. what happens on the server after receiving a presence type=subscribe) are only sent to "interested resources".
