On Jun 24, 2011, at 8:53 AM, Mark Rejhon wrote: > On Fri, Jun 24, 2011 at 11:43 AM, Kurt Zeilenga <kurt.zeile...@isode.com> > wrote: > > earlier? I think this will make most people happy, and will only add a > > few lines to the spec. See for example XEP-0085, section 4: > > http://xmpp.org/extensions/xep-0085.html > > > > Kurt et cetra, would this be satisfactory in the short term? > > Yes. > > Ok, it's not a painful change, and allows me to get the spec up sooner before > too many companies do damage with proprietary RTT. Kurt? > > > > It would at least mean XMPP RTT would now have a basic mechanism of > > discovering whether the other end supports RTT, and being able to restrain > > from sending RTT if the other end does not support RTT. This would not be > > the complete session negotiation algorithm, but would allay the cheif > > concern of Kurt. > > Correct, and it would allow for fall back to unextended XMPP if RTT was not > available end-to-end, which I would think quite important in emergency and > deaf communications. > > Yes, but RTT is backwards compatible, so both RTT and non-RTT conversations > look exactly the same to a client that do not support RTT.
My point is that if one uses an extension without it first being successfully negotiated, one runs the risk of blocking which is far more disrupting approach than simple feature negotiation disruption. Where an extension causes harm (or is perceived to be harmful), one can expect service/network operators to take steps to prevent that harm (or perceived harm). Operators would much rather just prevent such extensions by disrupting the negotiation of the feature's use than taking more disruptive action, such as dropping the XMPP sessions of the clients which send RTT without first successfully completing negotiation of the feature. But if push comes to shove, the network need to generally well operate will likely trump the desire of a few users to use some extension deemed harmful to the network. -- Kurt
