I'm using bookmarks (XEP-0048) to automatically join several MUC rooms. This works fine, when only using one single resource/client, say resource "A". But with Openfire 3.6.0 a participant is kicked from MUC, if the same account connects from another resource (say "B") with the same nickname. When using Psi 0.12, the resource "A" gets kicked by the server:
(When pressing "Ok" resource "B" gets also kicked, but that's not important here.)
This is a bug in Openfire? XEP says nothing about kicking users from the room in case of an nickname conflict!
XEP-0045: Multi-User Chat
7.1.10 Nickname Conflict
If the room already contains another user with the nickname desired by the user seeking to enter the room (or if the nickname is reserved by another user on the member list), the service MUST deny access to the room and inform the user of the conflict; this is done by returning a presence stanza of type "error" specifying a<conflict/> error condition:
Example 29. Service Denies Access Because of Nick Conflict<presence from='darkcave@chat.shakespeare.lit' to='hag66@shakespeare.lit/pda' type='error'> <x xmlns='http://jabber.org/protocol/muc'/> <error type='cancel'> <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> </error></presence>However, if the bare JID <localpart@domain.tld> of the present occupant matches the bare JID of the user seeking to enter the room, then the service SHOULD allow entry to the user, so that the user has two (or more) in-room "sessions" with the same roomnick, one for each resource. If a service allows more than one occupant with the same bare JID and the same room nickname, it SHOULD route in-room messages to all of the user's resources and allow all of the user's resources to send messages to the room; it is up to the implementation to determine how to appropriately handle presence from the user's resources and how to route private messages to all or only one resource (based on presence priority or some other algorithm).
How nickname conflicts are determined is up to the implementation (e.g., whether the service applies a case folding routine, a stringprep profile such as Resourceprep or Nodeprep, etc.).
However, it will take probably some time until this is fixed. Is there a simple way to restore the old behavior of Openfire 3.5.x? Openfire 3.5.x simply denies connection to the MUC room, if there is already someone with the same nickname.