[Standards] XEP-0301 Session handling

Peter Saint-Andre stpeter at stpeter.im
Wed Feb 29 00:04:18 UTC 2012

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 Saint-Andre

More information about the Standards mailing list