To the Stadards group, I bring up a question separate from the Session Handling. (many questions have already been answered -- thank you very much)
*Scenario: *XEP-0301 real-time text gets added to a mainstream client such as Pidgin or Miranda within 12 months. *Question: *What is the simplest possible and easiest method of safely introduce real-time text politely to a mainstream client, in a non-intrusive manner? (i.e. privacy) Especially if one end has RTT enabled by default (i.e. intentionally enabled by user), and the other end has RTT disabled by default (i.e. default installation) *Details of Scenarios:* - People don't normally expect their typing to be transmitted in real time. Therefore, feature shold be off by default in such mainstream clients. - However, it should be easy as possible to enable. Therefore, such mainstream clients will always advertise XEP-0301 compatibility via disco (section 5) but not necessarly enable the transmission of outgoing XEP-0301, including for privacy reasons. - Some people, such as deaf users, will want to change the software preference to permanently allow XEP-0301. (i.e. in software preferences) - However, even when disabled by default, we want users to make it easy for XEP-0301-aware recipients to enable the feature for responding to other XEP-0301 clients. (i.e. per-chat-session activation feature, such as a button) *Potential popularity in 10 years* Just like all television sets have a closed caption decoder, and is usually turned off by default, but easily turned on -- eventually, we hope XEP-0301 becomes mainstream within 10 years, as a replacement for obsolete deaf TDD/TTY teletypewriters. In even my limited testing (non-deaf family, friends, coworkers, etc), I found that once they understood what RTT was, it was a more popular feature than audio and video. So RTT has a lot of potential to improve the IM experience, even if it's an option feature enabled only a few percent of the time. Although more scientific surveys need to be done once it's already a part of Adium/Miranda/etc, it shows that sometimes people like to switch to the conversational mode via RTT rather than via audio, since they can talk very conversationally without making noise. Other times, people are in an asynchronous mood, like text messaging, regular instant messages, or email. But it apparently shows that there's more frequently a mood to be conversational via RTT than via audio or video, from this limited testing. Thus, we need to be prepared for the potential possibility that it may show up in mainstream clients. NOTE: We've also got a new logo for real-time text at www.fasttext.orgwhich we'll be starting to use in the next 12 months for future programming. Advertising XEP-0301 capability is done by a caps detection. Presumably, this will always be the case in all clients that supports XEP-0301. We see three situations where chat is activated between two XEP-0301 aware clients: 1. Both clients advertise XEP-0301 capability, but does not send XEP-0301 by default. 2. Both clients advertise XEP-0301 capability, but only recipient sends XEP-0301 by default. 3. Both clients advertise XEP-0301 capability, but only sender sends XEP-0301 by default. We want to make it easy for both ends to start sending RTT in scenario 2 and 3, even if disabled by default. *Example "Accessible" future use case **(which will happen!):* -- Alice is a deaf user, using a year 2014 build of Adium. She has XEP-0301 enabled. -- Bob is a hearing user, not aware of real-time text, but is using a year 2014 build of Pidgin that has XEP-0301 support but does not transmit RTT by default. -- Alice sends a message to Bob. She immediately sends RTT. Her typing is transmitted in real time. -- Bob's client software detects this but does not automatically send Bob's typing in real time. *The big question: What should happen afterwards?* *Possible Ideas/Methods of negotiating RTT activation* - XEP-0020? Bob instant messaging client, should be able to activate a session negotiation feature. As you remember, we added an XEP-0020 session negotiation feature in Version 0.0.1 of XMPP-RTT, but it got removed from Version 0.0.2 of XMPP-RTT. It is overkill/complesx. - Jingle? I think it's still overkill, since we want to operate 100% in-band - XEP-0030? We should always advertise XEP-0301 even if the client doesn't send outgoing RTT by default. This allows clients that DO WANT to send RTT, to go ahead and send RTT anyway - XEP-0085? Nope, it is not suitable. - The existing XEP-0301 featuer of *event='start' *and *event='cancel'? *Yes, this is a possibility, but if I can simplify things by removing these... (as long as I have an alternative to cover the above use case.) *The simplest method I have though of, to cover such use case:* 1. Alice's software verifies Bob's softtware does support RTT via caps detection. (Section 5 of XEP-0301) 2. Alcie Send RTT. 3. Bob's client, upon detecting incoming <RTT> automatically displays a message *** Alice is sending real-time text. Click [Activate] now to also send your typing live in real-time, too! 4. Bob clicks "Activate", realizing that he's watching Alice's typing live. (Note: Bob can continue to send line-by-line instant messages asking what real-time text is, etc, before clicking the Activate button, etc.) 5. Bob is now sending real-time text even though his RTT was disabled by default in his default install of his mass-market instant messaging software. *We need to emphasive RTT is an accessibility issue too* -- that it may be available but disabled in mass-market software clients. So I want to hear from the Standards group, about the ideal usage cases for XEP-0301 in a mass-market client. It's an interoperability issue, because if we have multiple different standards of negotiating activation of RTT, then it does not work very well. At the same time, we need: -- Keep it simple as possible, while staying accessible -- Minimum amount of protocol overhead, while staying accessible -- Keep it in-band, while staying accessible Has anybody else found an even simpler method, or a reason to use a more complex activation method for RTT? Thanks, Mark Rejhon