On 2/28/12 7:33 PM, Mark Rejhon wrote: > On Tue, Feb 28, 2012 at 9:02 PM, Peter Saint-Andre <[email protected] > <mailto:[email protected]>> wrote: > > I'm suggesting that you use a model similar to XEP-0085 -- if the other > side advertises it (disco/caps), send the first message with some kind > of RTT element. If the response comes back without an RTT element, don't > include any RTT elements in subsequent messages within that > conversation. > > > Hello! > This works in niche clients. > > However, when bringing real-time text to the mass market, it is presumed > that vendors (i.e. Microsoft, Google) will want it to be disabled by > default.
That's a client configuration and UI issue, not a protocol issue. 1. If the interlocutor doesn't advertise support for RTT, consider RTT unavailable for this conversation and don't proceed to #2. 2. If the interlocutor advertises support for RTT, prompt your user about whether to try RTT (or have some setting about "try RTT with known contacts" or somesuch). 3. If you try RTT but the interlocutor doesn't include RTT extensions, don't include RTT in subsequent messages. I still don't see the need for protocol-level *negotiation* here. However, if you are convinced that we need it, then we already have a protocol for that: Jingle. Peter -- Peter Saint-Andre https://stpeter.im/
