Hello Waqas & community. Thanks a lot for taking your time to help. See my comments to each one of your responses. It seems they do not work.
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. 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? 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: 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 ... 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. 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? What happens between servers when I add a contact to an account on server 1? Does roster requests between client and server1 get propagated to server 2 also? Is this not handled by the presence stanza? Furthermore, I find in ยง3.1.1 in RFC 6121 the following statement: Implementation Note: Many XMPP clients prompt the user for information about the potential contact (e.g., "handle" and desired roster group) when generating an outbound presence subscription request and therefore send a roster set before sending the outbound presence subscription request. This behavior is OPTIONAL, because a client MAY instead wait until receiving the initial roster push from the server before uploading user-provided information about the contact. A server MUST process a roster set and outbound presence subscription request in either order (i.e., in whatever order generated by the client). Does that not mean that roster handling is optional before sending a presence subscription (and therefore must not affect if a presence subscription is delivered or not)? But I cannot see how this roster handling should be applied anyway, in the component case, since it seems to be a client-to-server protocol. Have I misunderstood? Best regards, Peter Waher
