I forgot to add: On Tue, Nov 3, 2015 at 10:37 PM, Mark Rejhon <[email protected]> wrote:
> On Tue, Nov 3, 2015 at 9:02 PM, Christian Vogler < > [email protected]> wrote: > >> a. I don't see the use case for tracking RTT state by full JID. It seems >> to me that in most situations, tracking by bare JID would result in the >> most consistent and best user experience. This could perhaps be made >> clearer. >> > > I should stress doing by full JID is OPTIONAL. > > Conversely there have been people in the past who say bare JID makes no > sense. > Different people have argued in both directions in the last 4 years. > Some example use cases: > > -- Tracking by full JID can allow RTT message switching to be faster > during device-switching situations. > By tracking by bare JID, you have to wait for the next Message Refresh > before the RTT message "switches over" to active typist. But by keeping > track by full JID, synchronization of all Simultaneous Logins is > maintained, you can control the timing of the switchover (and even animate > it, such as fade-in, or poof-reappear animation, etc) independently of the > timing of Message Refresh events. With full JID tracking, the implementer > of the recipient has more timing control over which RTT message to display > during a device-switch situation. Tracking multiple RTT messages doesn't > necessarily have to mean displaying all of them at once. > > -- Tracking by full JID can work well in clients that choose to implement > a MUC-style user interface. > Clients can choose to display all of the RTT messages simultaneously. > The full JID would have separate real time messages during simultaneous > logins with different typists. (e.g. husband and a wife logging in on two > devices using same ID in the same IRC-style channel). Simultaneous Logins > often work anyway with IRC-style chatting, and I didn't want to make it > impossible for an implementer to map RTT seamlessly into that, if they > wished. > Another excellent use case I missed: -- Text transcription / captioning in multiple languages. A text transcription viewing client may choose to use Simultaneous Logins (different full jids with different xml:lang attribute for each) for localization situations. Each full JID could be a separate typist/transcriptionist handling a different language. Clients that keyed separate RTT messages on either the lang attribute AND/OR the full jid, would successfully concurrently track all the separate text streams under the same bare JID. Let's say, European Union meetings someday decide to stream their live text transcriptions through XEP-0301, the door is open to an implementer to be able to do so.
