[Standards] XEP-0301 Session handling

Peter Saint-Andre stpeter at stpeter.im
Wed Feb 29 02:02:13 UTC 2012


On 2/28/12 6:13 PM, Mark Rejhon wrote:
> 
> 
> On Tue, Feb 28, 2012 at 7:04 PM, Peter Saint-Andre <stpeter at stpeter.im
> <mailto:stpeter at stpeter.im>> wrote:
> 
>     On 2/28/12 4:47 PM, Mark Rejhon wrote: 
> 
>     [snip]
> 
>     > *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>. 
> 
>     [snip]
> 
>      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.
> 
> 
> Hello,
> Yes, but it does not answer the question of how to negotiate the
> enabling of RTT.   There are three angles that are covered, two of them
> answered, and one of them not.
> 
> *[Answered] **Matter of Compatibility between XEP-0301 and XEP-0085:*
> XEP-0085, if used, is very easily complementary with RTT.  You just
> simply send <composing/> with the first <rtt/> element transmitted from
> any other state (i.e. <active/> or <paused/>) .... I should add a
> sentence about this general practice.
> 
> *[Answered] Matter of Simplifying XEP-0305 by removing its session
> signalling*
> XEP-0085 can easily justify the removal of the *event='start'* and
> *event='cancel'*
> *
> *
> *[To Discuss] Matter of negotiation of activation of RTT feature*
> /However/, XEP-0085 doesn't answer the question of an appropriate
> negotiation model for deciding whether or not to enable RTT for a chat
> session.  (RTT is most ideal when both ends enable it)  Peter, do you
> think that my use case examples seem appropriate behaviour?
> 
> Comments would be appreciated about this.

I'm suggesting that you use a model similar to XEP-0085 -- if the other
side advertises it (disco/caps), send the first message with some kind
of RTT element. If the response comes back without an RTT element, don't
include any RTT elements in subsequent messages within that conversation.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/





More information about the Standards mailing list