[Standards] XEP-0301 Session handling

Peter Saint-Andre stpeter at stpeter.im
Tue Feb 28 23:36:35 UTC 2012

Hi Gunnar!

On 2/28/12 4:07 PM, Gunnar Hellström wrote:
> Sometimes it is very helpful with a clear beginning and a clear end of
> an XMPP text session.

Some people have thought so in the past:


That was mainly developed for the purpose of end-to-end encryption
(XEP-0116). Personally I think it would be good to deprecate it.

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

We have Jingle for multimedia session management. We could use it for
managing a text session, although personally I think that's overkill.

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

http://xmpp.org/extensions/xep-0085.html might be most appropriate.

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

Probably a good idea.

> 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 think XEP-0085 (Chat State Notifications) is more relevant. I don't
think it would be good to overload <show/> states because those are
related to presence in general, not a particular chat session.

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

If we want formal session management for RTT sessions then I think
Jingle is the way to go, but I am not convinced that we need formal
session management.

> -XEP-0155 Session establishment

I think we should deprecate that.

> -XEP-0045 Multi-User Chat  ( that also uses directed "unavailable"
> presence for closing the session as the main method above.)

MUC is multi-user, not one-to-one, so I think it's not general enough
for use in RTT.

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

My primary question is: do we need formal management of RTT sessions? I
don't think we do, and I think we can handle them informally using a
combination of RFC 6121 and XEP-0085. However, if we really really need
formal management then I would suggest using Jingle.


Peter Saint-Andre

More information about the Standards mailing list