On 2012-07-11 4:27 PM, "Dave Cridland" <[email protected]> wrote: > > 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.
Yep. In short: You just summed up the fallback mechanism that I came up with, that has been debated from various angles for various reasons (interop, bandwidth, chat states, privacy, etc, etc) Which I only later discovered is similar to the way done in XEP-0085 chat states section 5.1. It's interesting I accidentally invented a similar fallback algorithm. It is interesting my past testing and mental interoperability scenario analysis sort of 'reverse engineered' a similiar type of a fallback algorithm to solve the "two willing clients wont talk to each other" algorithm problem. Which Peter agreed about, too, (even if history could be rolled back and newer XEP's enforced.) I observe several of us agree that XEP-0301 can behave as an enhanced chat state. Therefore, it has to be compatible in all situations that chatstates are usable in, even in private/invisible mode. Many of my animations of RTT makes it look like an enhanced chat state. So, we have agreement in general. (Spec section 5 will be refined though, keep tuned) Mark Rejhon
