On Fri, Mar 2, 2012 at 10:27 AM, Mark Rejhon <[email protected]> wrote:
> On Fri, Mar 2, 2012 at 8:45 AM, Kevin Smith <[email protected]> wrote: > >> I think the simplest way that satisfies most requirements is a pair of > > switches in a client: >> 1) Request RTT sessions (default false) >> 2) Provide RTT session if requested (maybe default true) >> I'm not yet sure if this is entirely sufficient, but it's pretty simple. >> > [snip] > I think it is essentially your recommendation, with a variant: > 1) If RTT is supported, it is strongly RECOMMENDED to advertise RTT > capability via disco#info (section 5 of XEP-0301) > 2) Request RTT sessions > Configurable Preference: per-session | always > Default: per-session (in mass-market clients) > 3) Accept RTT session > Configurable Preference: auto-accept | prompt-user-confirm-first | reject > Default: prompt-user-confirm-first (in mass-market clients) > [snip] > On a related subject, I have been thinking of the important section 5 of XEP-0301: http://xmpp.org/extensions/xep-0301.html#determining_support It would certainly surely simplify a lot of my programming if I could make it 100% self-contained into the <rtt/> element, because programming a real-time library (for things like strophe, libpurple, jabber-net, etc) is most easily done without worrying about using <iq> stanzas. I am seriously considering making disco#info section 5 optional, and making REQUIRED an alternate backup capabilities-detection mechanism: 1. Clients that support XEP-0301, shall send one, single empty <rtt xmlns='urn:xmpp:rtt:0'/> element at the beginning of a chat session. This does not indicate an invitation to establish an RTT session, but merely to advertise a capability. No further <rtt> elements shall be transmitted unless the other client advertises RTT support too (either via disco#info or via having ever received <rtt>) This simplifies the programming of real-time libraries for Adium, Pidgin, Miranda, and any other instant messaging clients -- because 100% of the XEP-0301 protocol is solely confined to <rtt/> elements. Sincerely, Mark Rejhon
