On 2/28/12 4:47 PM, Mark Rejhon wrote: > I'm interested in feedback about session negotiation techniques, and > about simplifying XEP-0301 by removing the start/cancel attributes > (which are OPTIONAL) which are actually not currently used in any of the > several XEP-0301 implementations I have seen, including the latest > version of RealJabber (software installer package now available at > www.realjabber.org <http://www.realjabber.org> ...) > > I also need to define a mechanism where both sides of a XEP-0301 > compliant client can negotiate the simultaneous enabling of real-time > text on both sides, on an example mainstream client that might have RTT > disabled by default. For example, it should be possible for software > vendors to add an activation button for real-time text -- like there's > already a button for audio or video in many popular IM clients. One > technical method behind the scenes is to use the > event=start/event=cancel , but a different method is to also > automatically prompt to send return RTT if it detects incoming RTT. > > *Use Case Example #1:* > Alice messages Bob. Alice enables real-time text by clicking a button. > On Bob machine, when his software receives an <rtt> element for the > first time, the software can prompt Bob to enable the real-time text > feature, as follows: > /**** Alice is now sending real-time text. Click [Accept] to transmit > your typing live too./ > > *Use Case Example #2:* > Alice messages Bob. Alice enables real-time text by clicking a button. > Bob's IM client is preconfigured to automatically accept real-time text. > Upon receiving Alice's real-time text in <rtt>, Bob automatically > enables sending of <rtt>. A notification message simply gets displayed > in the message history: > *** /Alice has activated real-time text. / /Your typing is now being > transmitted live./ > > If this method is done, then it is not necessary to worry about using > the event='start' / event='cancel' for the purposes of RTT-specific > session signalling, and I can just remove it from XEP-0301 to simplify. > Also, it is noted that XEP-0301 section 5 already provides a mechanism > for a client to detect whether the remote client has RTT support, before > transmitting outgoing unsolicited <rtt>.
Mark, the model you're searching for is what we use in XEP-0085. Please take a look at the text there and see if you can re-use it for RTT. Peter -- Peter Saint-Andre https://stpeter.im/
