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