[Standards] XEP-0301 Fallback Mechanism of Determining Support (Accessibility)

Mark Rejhon markybox at gmail.com
Wed Jul 11 23:08:58 UTC 2012


On 2012-07-11 4:27 PM, "Dave Cridland" <dave at cridland.net> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120711/af55682c/attachment.html>


More information about the Standards mailing list