[Standards] RTT: no negotiation of the feature

Mark Rejhon markybox at gmail.com
Fri Jun 24 14:10:03 UTC 2011


Re: http://www.xmpp.org/extensions/inbox/realtimetext.html

On Fri, Jun 24, 2011 at 9:44 AM, Kurt Zeilenga <Kurt.Zeilenga at isode.com>wrote:

> I am quite concerned that the current spec offers zero negotiation of the
> extension before its use.
> I urge the authors to add some negotiation, preferable before it's
> published as XEP.
>

I agree, we are going to be developing a session negotiation mechanism over
time:
However, it is not necessary for interoperability right now:

There was a negotiation mechanism in the previous spec, but it was claimed
to be overly complicated. Due to section 4.3.1 (backwards compatible), it is
not necessary to even use 'start' or 'stop' since RTT clients can work
without 'start' and 'stop'. A sender can send RTT right away, and a
recipient can interpret RTT right away.

Experimentation during the Experimental stage is needed to determine best
interoperability for the process of starting a real-time-text session and
signalling the remote end that a session has started (in the future, it
might be a process where one end starts a session, and the other end does an
Accept/Reject -- similiar to AOL AIM Real Time IM.   Or it might be a
different preferred method of starting a RTT session). It is also a "out in
the field" user preference that might influence the preferred session
negotiation algorithm, and several companies (4) are already working on XMPP
RTT based on this standard. Due to section 4.3.1, failure of signalling is
not a catastrophe at this early experimental stage, RTT will simply be
turned off but the chat conversation will continue to function normally.

I covered some of this discussion in the "Supplemental" document at
www.realjabber.org as a potential candidate mechanism to mimic the AIM
Real-Time IM capability.

Mark Rejhon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20110624/09bd6c16/attachment.html>


More information about the Standards mailing list