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 <[email protected]> 
> 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

Reply via email to