On Fri, Jun 24, 2011 at 11:43 AM, Kurt Zeilenga <[email protected]>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. In fact, if one wanted, one can even have groupchat's with mixed RTT and non-RTT perfectly, even though I don't explicitly mention support for group chats because of the considerations I published at http://www.marky.com/realjabber/XMPP-RTT-Supplement_2011-06-17.pdf ... linked from http://www.realjabber.org Right now, RTT spec is defined for one-on-one conversations (even though the RTT spec can be used verbatim for groupchats). I mentioned group chats in the previous specification, but for simplicity I removed mention/support for group chat even though the RTT protocol continues to be compatible for use in groupchat. Mark Rejhon
