> For example, every client that successfully connected to an XMPP server must first send a "<presence>" message. Otherwise, it won't receive any messages despite their successful connection.
That statement is wrong. Sending an initial presence merely indicates your availability to entities subscribed to your presence. Not sending the initial presence does not prevent you from receiving message stanzas.
Addendum: As Zash pointed out[1], this is documented behavior for offline messages, i.e. messages send while the user was offline. Those are only send if the user announced availability via a presence or if XEP-13: Flexible Offline Message Retrieval is used. This is to prevent storms of offline messages when the client (re-)connects.
But it's certainly not true that you "won't receive any message despite ... successful connection".
Indeed, my description was rough and from memories a few year ago. But I believe it still demonstrates the point I was trying to illustrate:
There is unneccessary complex behaviour in XMPP that you must write extra code in your client for. Otherwise it will work mostly, but not always and not reliably.
Really? The old Google Talk service used to do this, but I didn't think ejabberd did. There's a bunch of non-IM use-cases which need presence-less messaging.
That statement is wrong. Sending an initial presence merely indicates your availability to entities subscribed to your presence. Not sending the initial presence does not prevent you from receiving message stanzas.