Capital letters in jid

[fbeutel]

I recently came across an error when using QXmppMucManager:

When adding a room with a JID that contains capital letters (e.g. mucmanager->addRoom("TeSt@example.com"), QXmpp doesn't recognize a successful join, because the server response presence is being sent using lower letters ("test@example.com"), so the jid comparisons don't work.

Since jid comparisons are probably not very uncommon in QXmpp, this might be hiding at other places, too.

Now I'm not sure what the best solution would be. Obviously, QXmpp could demand of the users that jids be always using lower letters, but that doesn't seem right for several reasons.
First, it is still prone to errors like the one above if the user isn't super careful - it's too easy to introduce such bugs.
Second, couldn't a server implementation (in theory) also use upper letters in it's responses?

Instead, maybe the easiest way is to add a jid comparison function to QXmppUtils and consistantly use that for comparisons.
Another option would be to introduce some kind of case-insenitive QString-compatible class to store JIDs and everywhere, where we store a JID, use that class instead of QString...

What do you think?

[0xd34df00d]

I had the very same issue a couple of weeks ago. I fixed it by just lowercasing all the room JIDs in the right place of my client's code. I could not find anything in XEP-0045 or anywhere else about the requirement of lowercasing the JIDs, though, so I'm not sure it's the right thing to implement in QXmpp itself. Anyway, having a separate JID class seems like a good solution, bringing more type safety. Note that not only comparisons will have to be case-insensitive, but also the hash function as well.

[jlaine]

On 02/29/2016 09:14 PM, Georg Rudoy wrote:

I had the very same issue a couple of weeks ago. I fixed it by just
lowercasing all the room JIDs in the right place of my client's code.

I could not find anything in XEP-0045 or anywhere else about the
requirement of lowercasing the JIDs, though, so I'm not sure it's the
right
thing to implement in QXmpp itself.

I had a look at RFC 3920, and it would seem:

• the "node" (~username) part of the JID is indeed case insensitive. The
  NODEPREP profile refers to STRINGPREP tables B.1 and B.2 for mapping
• the "resource" part of the JID is case sensitive. The RESOURCEPREP
  profile refers only to STRINGPREP table B.1 for mapping.

Anyway, having a separate JID class seems like a good solution, bringing
more type safety.

I am not super fond of introducing a JID class, as it's too late to use
it in QXmpp's public API : it would mean major API breakage.

Note that not only comparisons will have to be case-insensitive, but also
the hash function as well.

It's unfortunately a lot more involved that just case sensitivity...

Jeremy