[Standards] RTT: no negotiation of the feature

Kurt Zeilenga Kurt.Zeilenga at Isode.COM
Fri Jun 24 14:26:38 UTC 2011


On Jun 24, 2011, at 7:10 AM, Mark Rejhon wrote:

> 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

We need to keep experiments from harming our production networks.  If this extensions gets used blindly, it might well trash some production network.

I don't care how this feature is negotiated between the two entities intended to experiment with it, I only care that I have some ability to disrupt that negotiation so I can prevent this extensions use and hence protect my network from the real harm that would come by its use on my network.

-- Kurt

> 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




More information about the Standards mailing list