[Standards] XEP-0301 Session handling

Florian Zeitz florob at babelmonkeys.de
Wed Feb 29 02:42:00 UTC 2012

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.


More information about the Standards mailing list