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.
http://xmpp.org/rfcs/rfc3921.html#roster
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.