Re: [Standards] XEP-0301 Session handling
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/28/12 11:28 PM, Gunnar Hellström wrote: Returning to the initial question of this thread: Is there a common way to indicate session start and session end. Peter Saint-Andre skrev 2012-02-29 04:20: Yes, but that doesn't necessarily mean you need an explicit negotiation protocol. Right. The first need I thought about can in fact be reduced to a text session indicator, not even linked to RTT support. I will take a scenario to make the need clear. Assume that there is a SIP based stock exchange service, sending stock exchange information in text in sessions. It continues as long as a terminal is connected. A terminal indicates by a BYE that it leaves the session, so that the server can release the resources. During the session, the text information may be provided through RFC 4103 or RFC 3428 or RFC 4975. (RFC 4103 makes most sense of course for the RTT example, but let us look at it in general). Also assume that you want to make this service available to XMPP users through a gateway. Setting up a chat session to the gateway causes it to set up a SIP session with the stock exchange server. Messages or real-time text is flowing from the stock exchange server to the XMPP client. Then, the XMPP user want to leave the session. What does the user do and what does the gateway use as an indication that the session is over and it can take down the session towards the server? I really think that if you want to gateway between SIP and XMPP, you want to use Jingle. Such gatewaying was one of the core considerations for Jingle. Now, I haven't looked at RFC 4103 in quite a while, but we can certainly write a spec that defines how to translate between XEP-0301 and RFC 4103 (e.g., how to translate the SDP). Personally I don't think we absolutely need a way to complete a formal negotiation over XMPP itself, because I tend to think that just sending a chat message is a much more natural interaction, but *if* we think we need such a negotiation method, we should just use Jingle. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9OcRQACgkQNL8k5A2w/vzgqwCgiBcvV337uC0aDPVQ0zJ2zY+x dGsAoKhCEcelqsbgJFE5fF1trjKBFkPU =NhyO -END PGP SIGNATURE-
Re: [Standards] XEP-0301 Session handling
Peter Saint-Andre skrev 2012-02-29 19:40: I really think that if you want to gateway between SIP and XMPP, you want to use Jingle. Such gatewaying was one of the core considerations for Jingle. Now, I haven't looked at RFC 4103 in quite a while, but we can certainly write a spec that defines how to translate between XEP-0301 and RFC 4103 (e.g., how to translate the SDP). Yes, that is likely a good thing to do, but not for the simple example I provided. Personally I don't think we absolutely need a way to complete a formal negotiation over XMPP itself, because I tend to think that just sending a chat message is a much more natural interaction, Yes, but the example was a session on the SIP side, and a series of chat messages on the XMPP side. And the tricky thing with the example was that it was not a human operating the SIP side. A human will decide - ah, now the call is over, so I hang up. Then the gateway can detect that and release resources. But if it is a server as in the example, with no real logical end of the session, then we must rely on some session signaling from the XMPP user to tear down the session. Can the directed presence unavailable signaling described in RFC 6121 section 5.1 be relied upon for the purpose of ending the session? /Gunnar
Re: [Standards] XEP-0301 Session handling
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/
Re: [Standards] XEP-0301 Session handling
2012/2/28 Gunnar Hellström gunnar.hellst...@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 -- http://xmpp.org/extensions/xep-0301.html#event Right now, session negotiation is also a question that I have about XEP-0301. 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 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. 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 specification. Thoughts? Thanks, 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
Re: [Standards] XEP-0301 Session handling
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 -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] XEP-0301 Session handling
*[Answered] Matter of Simplifying XEP-0305 by removing its session signalling* When I wrote that, I meant XEP-0301, of course.
Re: [Standards] XEP-0301 Session handling
On 2/28/12 6:13 PM, Mark Rejhon wrote: On Tue, Feb 28, 2012 at 7:04 PM, Peter Saint-Andre stpe...@stpeter.im mailto:stpe...@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/
Re: [Standards] XEP-0301 Session handling
On Tue, Feb 28, 2012 at 9:02 PM, Peter Saint-Andre stpe...@stpeter.imwrote: 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. Hello! This works in niche clients. However, when bringing real-time text to the mass market, it is presumed that vendors (i.e. Microsoft, Google) will want it to be disabled by default. People don't expect their typing to be transmitted live right away. Imagine the fuss if audio and video was enabled by default, too -- that would be a /privacy invasion/ for many users not expecting audio/video to begin transmitting immediately. We've got the goal of having it in mainstream instant messaging programs. (We're planning to add an optional XEP-0301 mode to open source clients such as Pidgin, Adium, Miranda -- over the next 12-24 months and beyond). As a result, eventually mainstream vendors may adopt it, i.e. Google, Microsoft, etc, as a replacement for obsolete deaf TDD/TTY teletypewriters. So, there's a pressure to make sure the XEP-0301 standard has everything it requires to make a standardization of RTT negotiation possible, even if it's as simplistic as the examples I made, or if something more elaborate is needed. [Interesting note: In limited testing with non-deaf audiences when it was 'available to them', RTT proved more popular than using an audio and video feature! Most people don't turn on Audio and Video all the time, anyway. Audio and video is often enabled less than 5% of the time during the instant messaging application's lifetime, anyway. RTT actually proved more popular once the Average Joe Users understood what real time text is. So we'll be standardizing on the new logo at www.fasttext.org when a group of us, myself included, adds it to Adium, Miranda, Pidgin, etc] Opinions from all would be appreciated, on the best approach to introduce RTT 'politely' to the mainstream, since it'll be introduced to major open source instant messengers. That's why I have to be cautious about removing *event='start'* if it ends up suddenly becoming necessary. Apparently XEP-0085 doesn't cover the specific (potentially popular) situation of an RTT-aware mass market client that has RTT disabled by default -- that's the use case that clarification is now needed on before we begin adding it to Adium, Miranda, Pidgin, etc...
Re: [Standards] XEP-0301 Session handling
Am 29.02.2012 03:02, schrieb Peter Saint-Andre: On 2/28/12 6:13 PM, Mark Rejhon wrote: *[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 I tend to disagree with this. It would inherently require that both sides do RTT. I don't see any reason to enforce this artificial requirement. It is perfectly fine for just one side to send RTT messages, while the other one uses normal chat messages. If someone doesn't want to receive RTT messages, he should just not include the feature in the disco response. Also I see absolutely no reason for any session negotiation for this XEP whatsoever, especially without an option for the receiving party to decline the session. A simple on/off switch on the sending end (only availabe when the disco feature is present) seems sufficient to me. As a side note. What you described is actually quite different from what XEP-0085 says. You're mixing the usual disco case with the backwards compatibility case where no feature is present, but chat states might still be supported. Regards, Florian
Re: [Standards] XEP-0301 Session handling
On 2/28/12 7:33 PM, Mark Rejhon wrote: On Tue, Feb 28, 2012 at 9:02 PM, Peter Saint-Andre stpe...@stpeter.im mailto:stpe...@stpeter.im wrote: 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. Hello! This works in niche clients. However, when bringing real-time text to the mass market, it is presumed that vendors (i.e. Microsoft, Google) will want it to be disabled by default. That's a client configuration and UI issue, not a protocol issue. 1. If the interlocutor doesn't advertise support for RTT, consider RTT unavailable for this conversation and don't proceed to #2. 2. If the interlocutor advertises support for RTT, prompt your user about whether to try RTT (or have some setting about try RTT with known contacts or somesuch). 3. If you try RTT but the interlocutor doesn't include RTT extensions, don't include RTT in subsequent messages. I still don't see the need for protocol-level *negotiation* here. However, if you are convinced that we need it, then we already have a protocol for that: Jingle. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] XEP-0301 Session handling
Hi Florian! On 2/28/12 7:42 PM, Florian Zeitz wrote: Am 29.02.2012 03:02, schrieb Peter Saint-Andre: On 2/28/12 6:13 PM, Mark Rejhon wrote: *[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 I tend to disagree with this. It would inherently require that both sides do RTT. That was the assumption behind chat state notifications. I think it's a reasonable assumption, but I also think that reasonable people can disagree about it. I don't see any reason to enforce this artificial requirement. It is perfectly fine for just one side to send RTT messages, while the other one uses normal chat messages. If someone doesn't want to receive RTT messages, he should just not include the feature in the disco response. Sure. Also I see absolutely no reason for any session negotiation for this XEP whatsoever, especially without an option for the receiving party to decline the session. A simple on/off switch on the sending end (only availabe when the disco feature is present) seems sufficient to me. I too agree that we don't need session negotiation. As a side note. What you described is actually quite different from what XEP-0085 says. You're mixing the usual disco case with the backwards compatibility case where no feature is present, but chat states might still be supported. Quite possibly. :) Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] XEP-0301 Session handling
Hello, That's a client configuration and UI issue, not a protocol issue. Actually, we've found it is a very important long-term interoperability issue -- please see my big email, we have plans to add RTT to multiple open source clients. We've explained several scenarios (i.e. a Year 2014 build of Pidgin talking to a Year 2014 build of Adium ) Even if the interoperability is accomplished by a software practice, the software practice still needs to be 'standardized' between different brands, and therefore must be mentioned in XEP-0301, and therefore relevant discussion Mark Rejhon
Re: [Standards] XEP-0301 Session handling
On 2/28/12 8:15 PM, Mark Rejhon wrote: Hello, That's a client configuration and UI issue, not a protocol issue. Actually, we've found it is a very important long-term interoperability issue -- please see my big email, we have plans to add RTT to multiple open source clients. We've explained several scenarios (i.e. a Year 2014 build of Pidgin talking to a Year 2014 build of Adium ) Even if the interoperability is accomplished by a software practice, the software practice still needs to be 'standardized' between different brands, and therefore must be mentioned in XEP-0301, and therefore relevant discussion Yes, but that doesn't necessarily mean you need an explicit negotiation protocol. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] XEP-0301 Session handling
Returning to the initial question of this thread: Is there a common way to indicate session start and session end. Peter Saint-Andre skrev 2012-02-29 04:20: Yes, but that doesn't necessarily mean you need an explicit negotiation protocol. Right. The first need I thought about can in fact be reduced to a text session indicator, not even linked to RTT support. I will take a scenario to make the need clear. Assume that there is a SIP based stock exchange service, sending stock exchange information in text in sessions. It continues as long as a terminal is connected. A terminal indicates by a BYE that it leaves the session, so that the server can release the resources. During the session, the text information may be provided through RFC 4103 or RFC 3428 or RFC 4975. (RFC 4103 makes most sense of course for the RTT example, but let us look at it in general). Also assume that you want to make this service available to XMPP users through a gateway. Setting up a chat session to the gateway causes it to set up a SIP session with the stock exchange server. Messages or real-time text is flowing from the stock exchange server to the XMPP client. Then, the XMPP user want to leave the session. What does the user do and what does the gateway use as an indication that the session is over and it can take down the session towards the server? The indication for setting up seems to be either the basic mechanism for session control defined in RFC 6121 section 5.1 where it is stated that initiation of a session should begin with a message with type=chat. Or XEP-0085 chat state going active But what is most appropriate as indication to the gateway that it is time to take down the session on the SIP side? The XEP-0085 chat states do not seem to be the primary means to use. The user may sit there very actively watching the information coming, but not touching the user interface for half an hour. According to XEP-0085, the chat state would then be gone since long, so taking down the session on gone indication does not seem appropriate. How about relying on RFC 6121 section 5.1 requiring that end of session should be signaled by indicating directed presence unavailable. Will that be normally signalled by most XMPP text clients when the user closes the window where the session was shown? The stock exchange server example is of course artificial. There may be many other cases when a simple session indication is important. And this regardless of the support for and activation of the RTT feature. So my conclusion now is that this is not at all a XEP-0301 issue, but if we get a conclusion, we could document it as a recommendation in XEP-0301. There are other valid cases, when full capability declaration, exchange and negotiation or RTT capability is important, but let us take one case at a time. Thanks Gunnar
