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

Gregg Vanderheiden gv at trace.wisc.edu
Wed Jul 11 22:33:31 UTC 2012


Well one thing missed is that the emergency responder (9-1-1 PSAP) is always responding. 
So I think you should have it that the first message from EITHER party should be able to use <rtt/> to ping.  

What about if you are in the middle of a message and it becomes clear that it should move to rtt? 



On Jul 11, 2012, at 10:27 PM, Dave Cridland 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.
> 
> 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/20120712/cced1720/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7318 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120712/cced1720/attachment.bin>


More information about the Standards mailing list