We are developing a custom XMPP client. When interoperating with Spark, we see that the value of the in packets sent by Spark in response to a chat initiated by our client does not match the value of the in the message we send to Spark.
This turns out to be a problem because we are using the Smack library in our client. And it cannot associate the incoming message with the chat we created. The Smack library tries to match on thread. When that fails, it tries to match based on “from” against an existing chat. In our case, though, we are sending a bare JID in the “to” of the outgoing whereas the reply message comes back with a full JID in the “from”. Therefore, the address-based matching in the Smack library also doesn’t find the match.
It’s easy to fix the Smack library to deal with the second problem. But I’d really prefer not to do that to fix what is essentially a bug in the Spark client. I realize that the XMPP RFC says “should” regarding the return the same value. But, come on! Why not just do it right?