[Standards] XEP-0301 Session handling

Mark Rejhon markybox at gmail.com
Tue Feb 28 23:47:10 UTC 2012

2012/2/28 Gunnar Hellström <gunnar.hellstrom at omnitor.se>

> Sometimes it is very helpful with a clear beginning and a clear end of an
> XMPP text session.
> For example if you are gatewaying to a SIP call, and want to cause a
> hangup on the SIP side, or get an indication to the XMPP side when the SIP
> side has closed the session.
> *Question*:
> I wonder if there is a session start - session end indication that has
> dominating support among XMPP text messaging implementations that can be
> used as the default mechanism for XEP-0301 real-time text session control.

Gunnar brings up an excellent question, of which I am considering as well.
This refers to Section 4.2.3 --
Right now, session negotiation is also a question that I have about

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...)

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

*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
***** 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>.

I could go elaborate and use feature negotiation (XEP-0020) or disco
(XEP-0030) to negotiate an RTT session in a more synchronous manner, but I
think that's overkill at this stage, and I think that the two above use
cases are sufficient?

If everyone agrees, then I will be removing *event='start'* and *
event='cancel'* from section 4.2.3 of my XMPP specification,
http://xmpp.org/extensions/xep-0301.html#event in order to simplify the


Mark Rejhon

Right now in XEP-0301, there is an "start" event and a "cancel" event
> defined in section 4.2.3 with indications that they MAY be used to indicate
> session start and end.
> See http://xmpp.org/extensions/xep-0301.html
> I have found some other mechanisms, and I wonder if the "start" and
> "cancel" events should be deleted from XEP-0301, and instead some already
> existing mechanism used, in order to not increase the number of optional
> ways to handle session start and end.
> It seems to me that there is a basic mechanism for session control defined
> in RFC 6121 section 5.1
> Initiation of a session should begin with a message with type=chat,
> Both parties shall set their presence <show/> to "chat"
> End of session should be signaled by indicating directed presence
> "unavailable".
> A change of <show/> to anything else than chat should also be taken as
> indication of end of session.
> An example is presented in section 7 of RFC 6121.
> I assume that there are a multitude of exceptions when this sequence does
> not occur, but it seems to me to be a good basic sequence to support.
> On top of that, there seems to be a range of more comprehensive session
> control options:
> -XEP-0166 Jingle session establishment.
> -XEP-0155 Session establishment
> -XEP-0045 Multi-User Chat  ( that also uses directed "unavailable"
> presence for closing the session as the main method above.)
> *
> Proposal:*
> So, for XEP-0301, I want to check if it would be wise to delete the
> "start" and "cancel" events from chapter  4.2.3 and instead insert a new
> subsection in chapter 6 saying:
> "6.4 Session control
> Session control is essentially out of scope for this media related
> extension.
> A recommendation is though to follow the basic principles described in RFC
> 6121 section 5.1.
> Any further session handling such as Jingle, MUC or the Session
> establishment extension may be added as found suitable for each specific
> application of this extension."
> --
> ___________________________________________________
> Gunnar Hellström
> Omnitorgunnar.hellstrom at omnitor.se+46708204288
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120228/96a7f4c3/attachment.html>

More information about the Standards mailing list