Hello, I need some comments about existing protocol specification of XEP-0301 to permit session-like behaviour of real-time text. Right now, the current XEP-0301 specification permits the scenario to be possible, *at the implementor's option*
*EXAMPLE SCENARIO of an "RTT session"* *** Normal instant messaging conversation is occuring. No real-time text. *** Real-time text is *activated *as follows: - A sender clicks a button or menu to activate RTT. (privacy confirmation may be used first) - Sender client begins to transmit <rtt/> - Recipient client detects incoming <rtt/> - Recipient client asks user for confirmation such as "*Sender is sending Real-Time Text. -Accept- or -Reject-?*" (or other/more descriptive message) - (Recipient client can continue to display incoming real-time text while waiting for -Accept- or -Reject- to be clicked. This is a convenient way to educate the recipient what real-time text really is.) - Recipient decides to clicks -Accept- - Thereafter, recipient client is now also sending <rtt/> *** Instant messaging conversation continues with real-time text enabled from both ends. *** When either party wants to stop real-time text, they *deactivate *as follows: - A sender clicks a button or menu to deactivate - Sender client transmits <rtt event='cancel'/> (This is also used if recipient clicks -Reject- instead too) - Recipient client stops transmitting <rtt/>. (notification message to say RTT has ended) *** Instant message conversation continues normally. This is made possible if the implementor follows the protocol as follows: * clients always advertises existence XEP-0301, in compliance with Section 5. (To allow it to be possible for senders to *initiate* an XEP-0301 session) * clients does not transmit outgoing <rtt/> by default. Essentially "real time text is turned off at the moment." from the end-user's perspective. * clients listens for incoming <rtt/>. The first <rtt/> signals the start of a session. Section 4.1 and 4.2 of XEP-0301 covers some of this information (end of section 4.2.2 says the first <rtt/> signals the start) (Note: Assistive clients may use a different scenario, such as automatic attempt at activation, or automatic acceptance. This can also be a configuration/preference, at the implementor's option. This would be an implementation issue, not a protocol issue) QUESTIONS as follows: 1. Are there other scenarios that XEP-0301 implementors want to see "made possible", not currently possible with the current protocol? 2. Are there other unresolved protocol gotchas from the above example scenarios? (i.e. high latency causing <rtt event='cancel'/> not to cause incoming <rtt/> to stop for a while, causing client to think it's a new session attempt? Guard delay needed? Does this warrant re-adding the <rtt event='start'/> that was removed from the spec in the last revision? etc.) This is an important aspect of XEP-0301, with inquiries from vendors, and I need to be certain that the protocol works. Sincerely, Mark Rejhon
