[Standards] XEP-0301 -- starting and stopping real-time text in a chat session.

Mark Rejhon markybox at gmail.com
Sun Jul 1 15:38:09 UTC 2012


On 2012-07-01 4:25 AM, "Kevin Smith" <kevin at kismith.co.uk> wrote:
>
> On Sun, Jul 1, 2012 at 7:59 AM, Gregg Vanderheiden <gv at trace.wisc.edu>
wrote:
> > You did not comment on the fact that turning off RTT in a way that
emergency
> > personnel cannot determine that RTT is an option can put users at
greater
> > risk in an emergency.   Did you note that?
>
> The argument I'm making here is that if the user says "I do not want
> to ever do RTT, I do not want to receive it, I do not want to be
> prompted to receive it" then they shouldn't receive it, they shouldn't
> be prompted to receive it, and people chatting to them shouldn't be
> misled into thinking they might be able to use it.

Unfortunately, this is frequently /indistinguishable/ from actual user
intent;
'I want to do RTT and be notified about it, but my software only lets me
turn off RTT for everyone'
'My RTT is off because I dont know what RTT is and my software has it off
by default'
'I forgot to turn it on'

Again, I am NOT going to be a willing author of XEP-0301 under the flawed
model (section 5) with what Kevin has pointed out.

-- However, Section 5 has now already been modified to permit Kevin's and
Kurt's preferences to disable RTT completely.
(ie like putting phone into non-real-time VM or SMS mode)

-- Yet still allow senders to send a signal of a desire to start RTT.
(ie, there is no padlock on the originator's phone keypad, preventing an
attempt to dial for an interactive conversation)

Servers can still block it, if they are desparate to prevent it.
(ie, like an office  phone network restricting certain types of calls
beyond your control)

Crisis solved with the single blank <rtt/> signal.
I hope it survives last call scrutiny.

Sincerely,
Mark Rejhon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120701/ecb6c39e/attachment.html>


More information about the Standards mailing list