Openfire does not send user presence information to all resources of the user
Any way, Openfire (3.7.0) doesn't return presence information to the resource which generated it, and according to RFC 6121 #4.4.2, it MUST do it:
The user's server MUST also send the presence stanza to all of the
user's available resources (including the resource that generated the
presence notification in the first place).
I tested it with the xml console of gajim:
<!-- Out -->
<presence xmlns="jabber:client" id="171">
<c xmlns="http://jabber.org/protocol/caps" node="http://gajim.org" ver="I8g2pphLu5w2XvNV8HDES9gqRaw=" hash="sha-1" />
<!-- In -->
<iq type="result" id="172" to="email@example.com/Gajim"/>
(And now openfire should broadcast the presence to everybody including me, but it doesn't)
Testing presence info scenarios in Openfire 4.0.0 (5th Jan nightly), and appears to be working as expected. Not sure if I've hit all scenarios as outlined, wondering if this ticket should be split out to cater for individual scenarios?
Anybody watching this issue able to comment on its relevance for 3.10.2 openfire release?
I am reopening this issue, because it's not fixed as pointed out in https://community.igniterealtime.org/thread/54598 and as Florian's comment suggests. My testing also shows, that it's not fixed.
The changes which were introduced with http://fisheye.igniterealtime.org/changelog/openfire?cs=13745 now make Openfire broadcast presence twice as far as I can tell from debugging.
Will look into it.
Added back the change that allows sending presence back to the originating resource.
Tested with a custom client, presence packages are received. However, Pidgin, Spark and Apple's Messages ignore them - presence is not updated when changed from another client connected using the same account. This is obviously no longer an Openfire issue, but something to keep in mind nonetheless.
The issue I saw was that when I have two clients connected and one of them changes presence, the other won't see it.
The missing lines just propagate the presence back to the originating client, it just looked like extra traffic. But if it's required by the RFC, I can add it back, no problem.