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
