powered by Jive Software

ChatManager name checks and case-sensitivity

ChatManager keeps track of chats in a case-sensitive map, which can cause issues for applications where the jabber credentials may be fetched from another source, such as a support or personnel database, if that source has different cases than the jabber server. When a Chat is created, ChatManager will create and track it using:

Chat chat = new Chat(this, userJID, threadID);
    this.threadChats.put(threadID, chat);
    this.jidChats.put(userJID, chat);
    this.baseJidChats.put(StringUtils.parseBareAddress(userJID), chat);

So, if our application initiates a chat from FirstNameLastName@domain.org, we have maps like this pseudo-json:


When the server responds to firstnamelastname@domain.org, chat1 will not be found in the maps. A new chat is created, so our map becomes:

{FirstNameLastName@domain.org:chat1, firstnamelastname@domain.org:chat2}

The message will appear to the server to be delivered, but the application using smack will not see the response, because the response goes to chat2 and its MessageListener, not to chat1.



It appears that nodes should be compared in “case-normalized canonical form”, domains are case-inensitive, and resources are case-sensitive, but the maps in ChatManager do not behave that way. Is this a bug in smack, or do applications need to consult the Presence roster and normalize cases themselves before initiating any chat?

I’d say, it’s your responsibility, not that of ChatManager, to normalize the JID before you assign it to the “to” attribute of the message.

AFAIK, JIDs must be normalized before sending it over the stream anyway.

This can be seen as unsolved problem in Smack. There is no immediate normalization of the XMPP address format as defined in RFC6122. So CSH is right here: Whenever you see a String in Smack that represents a JID, you have the responsibilty to normalize it before.

We are currently working on a XMPPStringprep interface for Smack, which is the fist step to solve this problem. The second step would be a JID class with a FullJID subclass, which takes care of normalization. I wouldn’t expect this to happen within the near feature, it’s something for a 4.1 or even 4.2 release.