powered by Jive Software

Presence subscribe bug

I have been looking through an issue with subscribe.

I have joined the discussion here. http://www.igniterealtime.org/community/message/195334#195334

The defects listed are http://www.igniterealtime.org/issues/browse/ OF-38 and more importantly http://www.igniterealtime.org/issues/browse/JM-384

My opinion reading through the RFC, I think openfire is incorrectly not ignoring the last subscribed message.


I think openfire is incorrectly sending a presence “subscribed” message to a subscribe request to a user that is already subscribe. This should not be done, as it causing a failure with the section (important distinction underlined):

“9.Upon receiving the presence stanza of type “subscribed”, the user SHOULD acknowledge receipt of that subscription state notification through either “affirming” it by sending a presence stanza of type “subscribe” to the contact or “denying” it by sending a presence stanza of type “unsubscribe” to the contact; this step does not necessarily affect the subscription state , but instead lets the** user’s server know that it MUST no longer send notification of the subscription state change to the user** .”

Also in 9.3 Subscription States:

The user’s server SHOULD NOT route a presence stanza of type “subscribed” or “unsubscribed” to the contact if the stanza does not result in a subscription state change from the user’s perspective, and MUST NOT make a state change. If the stanza results in a subscription state change, the user’s server MUST route the stanza to the contact and MUST make the appropriate state change. These rules are summarized in the following tables.

Reading this I think the server should eat a subscribe request to a subscribed contact.

This has caused lots of problems with other libraries.

Since this is a bigger change I would be interested if there are any other comments on this issue.

I think the issue is in the PresenceSubscribeHandler line 141 where it auto-delivers a “subscribed” packet if the user is already subscribed to a roster, this line could be removed to make it meet the RFC.

I have just resolved OF-38. In my opinion, JM-384 / OF-56 is a sort of ‘inverse’ definition of the same problem, in this aspect. Do you agree on that (and, could you verify that the latest code from trunk fixes your problem?)