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

Mark Rejhon markybox at gmail.com
Thu Jul 12 04:24:49 UTC 2012


On Wed Jul 11 22:33:31 UTC 2012, Gregg Vanderheiden <gv at trace.wisc.edu>
 wrote:

> 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?


Good news -- This is already covered --
There are multiple mechanisms:

1. An implementer can choose to simply transmit the whole contents of the
partially-composed message in a new real-time message via <rtt
event='new'/>.  Instead of the first key presses, it's the whole partially
composed message being transmitted all at once.   Much like a Message Reset
- except you're using 'new' instead of 'reset'.

2. An implementer can choose to use Message Reset to transmit a
partially-composed message that you started composing while real-time text
was turned off.
http://xmpp.org/extensions/xep-0301.html#message_reset
Using <rtt event='reset'/> is a legal first <rtt/> element of a
conversation.  It is legal to use event='reset' without using event='new'
first.
http://xmpp.org/extensions/xep-0301.html#event
I also mention that senders can start typing before a recipient logs on
(see top of section 4.6).
http://xmpp.org/extensions/xep-0301.html#keeping_realtime_text_synchronized

I would suggest approach #2 since it signals that the message was already
composed, rather than being a new message.

It bears mentioning that the event attribute values of 'new' and 'reset'
has been made virtually identical now, and some XEP-0301 implementations
can treat both 'new' and 'reset' as exactly identical with no implemented
differences at all.   However, rich clients can implement distinguishing
behavior if they wish to do so -- e.g. recording the start time of a
message compose, or signalling differently for new versus existing
real-time messages. (such as recipient logging on after sender starts
composing).  All of which would not be possible if new/reset is merged.

Thanks
Mark Rejhon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120712/e12f7d64/attachment.html>


More information about the Standards mailing list