[Standards] XEP-0301 Session handling
stpeter at stpeter.im
Wed Feb 29 02:48:36 UTC 2012
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.
> 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.
> 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. :)
More information about the Standards