[Standards] XEP-0301 Session handling
stpeter at stpeter.im
Wed Feb 29 02:46:01 UTC 2012
On 2/28/12 7:33 PM, Mark Rejhon wrote:
> On Tue, Feb 28, 2012 at 9:02 PM, Peter Saint-Andre <stpeter at stpeter.im
> <mailto:stpeter at stpeter.im>> 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
> 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
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.
More information about the Standards