[Standards] RTT: no negotiation of the feature

Kurt Zeilenga Kurt.Zeilenga at Isode.COM
Fri Jun 24 14:51:52 UTC 2011


I should note that we'll kill this one way or the other, even if there's no negotiation.  I just rather kill it by disrupting the negotiation.

I just think it's really bad form to have non-negoiated extensions.

-- Kurt

On Jun 24, 2011, at 7:48 AM, Kurt Zeilenga wrote:

> 
> On Jun 24, 2011, at 7:44 AM, Mark Rejhon wrote:
> 
>> On Fri, Jun 24, 2011 at 10:26 AM, Kurt Zeilenga <Kurt.Zeilenga at isode.com> wrote:
>> 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.
>> 
>> We should keep this in perspective: This is XMPP RTT, not in-band bytestreams (i.e. XEP-0096 file transfer). It is low bandwidth the vast majority of the time, and contributes no additional data when nobody is typing.
> 
> Certain operational networks we support cannot deal with the extra traffic.
> 
>> That said, I agree -- it is going to be added to the spec in due time, well before XMPP RTT clients become popular.
> 
> I see reason why a basic yes/no negotiation of the extension cannot be added now, whether by iq or by caps or some other appropriate mechanism.
> 
> If it needs to change later, fine.  But please add something now.
> 
> -- Kurt
> 




More information about the Standards mailing list