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

Dave Cridland dave at cridland.net
Wed Jul 11 20:27:22 UTC 2012


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" <markybox at gmail.com> wrote:

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


More information about the Standards mailing list