Offline messaging is a problem in the sense that you would expect to be able to hold a reliable conversation with someone who is intermittently available rather

Offline messaging is a problem in the sense that you would expect to be able to hold a reliable conversation with someone who is intermittently available rather than getting errors about the other person being unavailable, or messages being lost in the aether. If the person is actually offline, you should be able to rely on the other server to actually deliver the message when they get back. I don't think XMPP has very good systems for ensuring reliable message receipt at the protocol level. There are, I understand, draft standards (XEP-0198, XEP-0013) that would improve things but nothing implements it (at least consistently). File transfer: Clients I've used are Adium, Pidgin and Google Talk. What normally happens with file transfers is that either the person at the other end doesn't know I've tried to send a file, or if they do know, they click accept and the file never transfers, or if the file does transfer, my client somehow doesn't realise and the file transfer stays active forever. Usually there'll be a double-NAT in the way. The only time it does mostly work is GTalk to GTalk. Multi user chat: Is very confusing to set up, and while it is possible to get it working, in practise I've found nobody can figure out how to use it. It's sort of like the complexity of email multiplied by the complexity of IRC. This is unlike other chat protocols/clients where it's just a matter of inviting someone to your conversation. This isn't even getting into the other issues with the protocol, such as voice/video/sip/o-o-b stuff, the general efficiency of the protocol and it's applicability to mobile users (It's not great). I have set up corporate XMPP servers (ejabberd/openfire) before and am very aware of the difficulties of trying to get things to all work together. In the end people just end up opting for something [awful] like Microsoft Lync instead.