> In one of our chat clients we have developed it is possible for a user to > have what amounts to multiple conversations occurring at the same time with a > single other user (I.e. In our case a user can have multiple chat tabs open > to another user). > > Reading the 301 spec, there doesn't seem to be any way to relate the rtt > messages to the final message other than the sequence they are received.
For other XEPs that introduce some sort of session, there has typically been a session ID attribute to distinguish sessions between the same full JIDs. In the case that multiple chat window sessions are active between the same *full* JIDs, then the use of <thread /> elements in both the normal and RTT messages would easily resolve the issue, especially since that is the only standard way I'm aware of that would even allow for that situation to occur reliably. > It's also how you would treat MUC (groupchat) -- correspond RTT with each > full JID. However, regarding a user joining a MUC multiple times, I think that your expectations fail when multiple sessions are allowed under the same room nick. I.e, a user with two active connections "[email protected]/foo" and "[email protected]/bar" joins a MUC with both JIDs as "[email protected]/user", which is allowed by XEP-0045 section 7.2.9. MUC participants who are not allowed to see the actual JIDs of other participants will have issues recognizing the situation. There would be two interleaved RTT streams, both from the full JID "[email protected]/user" and so the RTT buffers in the receivers would become garbled until a reset, and then only a single RTT session would "win." Again, the use of a <thread /> element or an optional sid attribute would remedy the issue. -- Lance
