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: http://xmpp.org/extensions/xep-0155.html 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 -- Peter Saint-Andre https://stpeter.im/
