On Wed, Mar 7, 2012 at 3:27 PM, Florian Zeitz <[email protected]>wrote:
> > 2. Advertising of RTT must always be done, for accessibility reasons.
> > We can't disable section 5 or it defeats the ability of deaf people to
> > attempt to initiate a RTT conversation in Adium/Pidgin (and soon
> google, microsoft, etc).
> > The goal of RTT is to become a widespread protocol in ten years, much
> like closed captioning.
> > We want to be able to let the recipient be notified of an incoming RTT
> and to let the recipient decide whether to turn on/off RTT.
> > If we stop advertising RTT, deaf people can't make call and the hearing
> person with the RTT off, won't ever be notified.
> > Can you suggest an alternative method of refusing RTT that does not
> require disabling disco?
> >
> That is possibly quite different though. If a client is configured to
> always reject RTT sessions there is no point in ever offering it to that
> client. Therefore it's perfectly fine for such a client to not send the
> disco feature.
>
I originally thought so, but unfortunately, that does not meet planned
accessibility requirements.
There are two excellent reasons why we need to be able to advertise
capability even if the client auto-rejects
1. It's easier to design a client to display a subtle notification.
("*** Incoming real-time text was rejected since you have it turned off.
[_Click to turn on_]")
This serves as a reminder, especially if they only want it turned off 99%
of the time.
This meets accessibility requirements.
2. It's easier to measure popularity of XEP-0301 supported clients.
Capability advertising provides an important data point. This may
eventually become important statistical data for advocating future paper
work (i.e. government legislation that require real-time text capability on
cell phones, as a replacement for obsolete deaf TTY/teletypewriters)
Also, AOL Instant Messenger's Real-Time IM is an enable/disable feature
much like audio/video can be turned on/off in the middle of a conversation.
I am also preparing for the eventually of Google adding XEP-0301 someday
to their products, so I need to make sure I'm covered with a good balance.
Although I am trying to avoid complicated session control. Different
vendors may do things differently, here is my plan for my work with common
open-source clients (i.e. Adium and Pidgin, etc):
This is the plan when adding XEP-0301 to, including Adium and Pidgin:
-- RTT should be available by default (to stay accessible)
-- RTT should not automatically transmit by default in mainstream clients.
(People aren't expecting their typing to be transmitted live by default.)
-- RTT should be easy to enable "in-situ" even when it's disabled 99% of
the time.
-- RTT should NOT be easy to forget about after it's turned off/disabled.
-- It should be possible to have RTT have at least three settings:
auto-accept, auto-reject, and confirm-first.
-- Compromise default setting is 'confirm-first'. Some people love RTT,
and some people hate RTT.
Session Control is accomplished by:
-- Starting an RTT session is simply by starting to transmit <rtt> elements.
-- Receiving an RTT session is simply detecting incoming <rtt> elements.
-- Deactivating an RTT session might be done by sending <rtt
event='cancel'> (decision still needs to be made)
Clients will, generally, be configurable to at least:
-- auto-accept: Always accept and display incoming RTT, always transmit
outgoing RTT
-- auto-reject: Don't display incoming RTT, don't transmit outgoing RTT
-- confirm-first: (default) If incoming RTT is detected, ask user if they
want outgoing RTT
Clients will automatically display notifications in all three cases..
i.e. Potential example non-intrusive status messages added to message
history (or statusbar) may include the following:
-- auto-accept: "*** Real-time text is active for this chat session"
-- auto-reject: "*** Incoming real-time text detected, but you rejected it.
[Click to Configure...]"
-- confirm-first: (default) "*** Incoming real-time text detected. [Click
Activate] to enable live transmission of your typing too."
Note, these are just example/potential messages, that aims to make it as
easy/accessible as possible even when RTT is turned off.
In the goal of introducing real-time text to the mainstream, I plan to make
it as easy as possible (while not being annoying) for non-technical users
to enable real-time text, even if they have real-time text disabled most of
the time. This is extremely important for deaf-accessibility reasons,
especially since my goal is to make real-time text a standard feature in
instant messaging software. My users include older family members that
barely know how to use a computer, and it's difficult to tell them
step-by-step instructions on how to turn on real-time text.
Now, there are many different session-control standards that can be
invented for XEP-0301, but I'm trying to avoid using protocol or
out-of-band negotiation layers (i.e. Jingle) at the moment. Ideas are
welcome, but make sure that the XEP-0301 specification is able to
accomodate the above plans that are currently planned for a few mainstream
clients. This was a difficult compromise agreement in the Real Time Text
Taskforce (R3TF) that took several days to agree on, and we need to make
sure that XEP-0301 has enough capability to permit the above scenarios.
Thanks,
Mark Rejhon
