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. > This may be sufficient for mention in the spec (I do want to add at least a few sentences to Implementation Notes), but there are also the other pressing criteria: * A technique that keeps it simple for the end-user * Yet keep it easily accessible. * Not everyone will want to view RTT * Not everyone will want to send back RTT. Some of these are UI considerations (how easy or difficult it is to enable), and some of them require some basic standards (in order to maintain interop) 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) This essentially means, the following: -- Senders: Requesting outgoing RTT session: Just simply transmit outgoing <rtt> (if recipient capability is available) -- Recipients: Detecting incoming RTT session request: Recipient simply detects incoming <rtt>. Recipient client SHOULD NOT display RTT until recipient also enables/confirms RTT. -- In addition, when detecting remote RTT capability via disco#info, a small notification/indicator should happen. An example is automatically enabling a button that needs to be activated per-session, and/or displaying a status message inside the Message History "*** Real-time text is available for this session. *Click to enable*." -- If "prompt-user-confirm-first" is enabled, a confirmation message should show (preferably non-intrusive, such as one that pops up into the message history, "*** Sender is using real-time text. Click [*Activate*] to transmit your text live while you type.") ... Only one confirmation should show per chat session (i.e. until the a new session starts, or if a new window is opened). Incoming <rtt> transmissions are ignored until real-time text is accepted/enabled. This keeps RTT non-intrusive but very accessible and easy to enable. This mechanism is also MUC compatible.
