OK, so, loosely: 1) If you know the remote disco (via caps, typically, or by a previous query), then you can follow that. Sending protocol to a remote endpoint that you *know* cannot support it is not going to make people happy. This will cover anyone in your roster, and indeed almost anyone you know to be online.
2) If you do not know the remote disco, then sending an "exploratory" <rtt/>, as in XEP-0085, seems reasonable, in the first message (only) in a conversation. This would most certainly include emergency services. 3) If, on the other hand, you're responding to a message - that is, your first message is a reply to another - then you'd only use <rtt/> if the contact does. There is one edge case - where the contact does not advertise RTT, yet is sending it to you. In this case, you print out every XEP, roll them up, track down the implementor, and whack them over the head. What am I missing? Dave. On Jul 11, 2012 3:03 PM, "Mark Rejhon" <[email protected]> wrote: > > On 2012-07-11 5:55 AM, "Dave Cridland" <[email protected]> wrote: > > > > At the risk of opening a whole new can of worms, if you're modelling an > RTT conversation as a textphone call, don't you want to be ringing, and > accepting the call, via Jingle? > > > > If it's modelled as an enhancement of existing IM text chat, then using > XEP-0085's model, with it's fallback from disco and caps seems fine - > though it is a fallback from disco, not a replacement. > > Both. I am designing for both scenario. I am an ardent advocate of > maximizing flexibility "where reasonable". There are extenuating use cases > in both directions (and other directions too!) > > In several years, who knows -- ringing could be added as a separate XEP > for enhanced RTT mode (which may include HTML and last message editing, > etc.) depending on how the real world usage evolves. > > Priority is keeping it as simple as a chat state, AND deliverable if > message body is deliverable (which means even in private mode). A whole > implementation can just follow "Basic Real Time Text" (without key > intervals) and ignore 90 percent of the document. The protocol section is > only a quarter the size of the rest of document (for good reason) > > Mark Rejhon >
