I've to correct my statement, as I just made a similar experience with openfire and unicode emojis from a range that is greater then 0xFFFF, for example 0x1F634: Prior r13995 openfire would simply cleanly close the connection if such a code point was detected in the XML stream. This is wrong because
- Suche code points are allowed in XMPP streams
- Even if not, openfire should terminate the connection with a stream error, so that Smack's connectionClosedOnError callback is invoked
This was not the case, therefore Smack went silently to the disconnected state, without informing the application about it.
I've fixed that now, starting with todays trunk, openfire is able to process the valid unicode stanzas, and this includes the emojis defined in unicode, correctly.
