[Standards] Fwd: XEP-0301 Accessibility (resurrected)

Mark Rejhon markybox at gmail.com
Mon Jul 9 16:45:21 UTC 2012


...I believe that we are talking about two different kinds of
*I'm talking about mass-market accessibility factors*, like accessible
real-time text activation/deactivation workflows that are as permissive and
as easy to activate as possible, while simultaneously accommodating maximum
privacy and bandwidth concerns.

...I'm focussed on accessibility concerns from a mass market perspective.
 Suppose that XEP-0301 gets introduced into a mass-market messaging
client *used
by* *hundreds of millions* ... this is far more important than
rare interop between incompatible real-time text protocols which can is
done by gateways anyway, see below.   Even if only 1% activate the
real-time text, that's still a few million people!  It combines the privacy
advantages of texting with the immediacy/urgency of conversation --
activated the "chatty moments" via a button, and good for moments where
you're not allowed to make noises (phone calls not allowed).

...I recall you said you dislike deactivation?  Have you considered
accessibility issues when Activation/Deactivation workflows are introduced
to real-time text?  We all concede we must allow some implementors to have
the choice to have an Activation/Deactivation mechanisms for real-time text
(rather than blithely sending <rtt/>).

...And you can see that using disco is flawed because it suggests senders
should not even try to initiate at all.  (Metaphorically speaking, Imagine
a telephone with a dialpad that completely disappears: The recipient
doesn't even want you to even attempt to dial the phone number.)   There
are implementations that WANT to be able to signal the recipient of an
attempt.  There are implementations that WANT to be able to notify the
recipient if the sender signals RTT, even if the recipient has RTT turned
(Example: "*** Incoming Fast Text attempted.  However, you have Fast Text
turned off.  Click for Help Info")

...I need to remind that XEP-0301 is under evaluation by multiple vendors,
whose clients, grand total, are collectively used by more than one billion
people in the world.  Even if might not be used for a few months, years, or
year 2022 ....

On Mon, Jul 9, 2012 at 11:07 AM, Gunnar Hellström <
gunnar.hellstrom at omnitor.se> wrote:
>       28. Chapter 5. last paragraph. I hesitate a lot about this simple
> way of detecting support. We need a proper way to detect RTT capability
> before we start to use it.

This is already solved --
It is simply a gateway server implementation issue -- and the gateway
simply needs to follow section 6.2:
Problem solved, without compromising human-accessibility concerns.

> There may be systems that have to select between different protocols for
> RTT, and they should not need to start sending in one protocol to try to
> discover if RTT is supported.

-- This is moot for all existing RTT protocols such as RFC4103, because
a gateway is needed anyway (see above)
-- For future real-time text protocols that goes under the same umbrella of
<rtt/> (i.e. to support HTML) that can be extended with the xmlns Namespace
Versioning.  Or backwards compatible method, such as adding a new attribute.
-- For the theoretical scenario (probably not used by hundreds of millions)
RTP transmitting RFC4103/T.140 over Jingle, that's going to be a
specialized client anyway created by a few vendors such as you (Omnitor).
 You would still be able to follow your preferred scenario at
attempting to activate at all times.  For fast-response, there are vendors
that want to implement XEP-0301 but do not want to reveal (for privacy
reasons) of XEP-0301 support until confirmed manually by the recipient.
Unfortunately I can't degrade the XEP-0301 standard for a mass-market
Activation/Deactivation scenario -- which you already concede is acceptable
if it permits a mass-market vendor to make XEP-0301 available (in a
"deactive by default") to hundreds of million of people.

Still, I realize the convenience of this simple method, and would let a
> discussion decide if it shall be kept.
> If it is kept, the paranthesis characters on the second line should be
> deleted so that the rapid response on this initiation is made part of the
> protocol.

This is reasonable to make it recommendable, although we have to also
support implementors that want to prompt the recipient for confirmation
first.  (see Activation/Deactivation methods).  So response on this
initiation may not be so quick.
There are some implementors that said they need to be allowed to ask the
recipient for permission first.

Many of us are far more focussed about accessible interoperability concerns
*between XMPP clients* that are used by *hundreds of millions* .... "Hundreds
of millions users" is the key phrase here.

That is far, far, more important than minor interoperability concerns
between incompatible real-time text protocols.  And that problem is solved
by gateways.    You can write your own assistive client (that complies
strongly with disco), so that it "behaves well" with the gateway server, if
the gateway server is very demanding of being able to detect real-time text
capabilities (and has a problem with those vendors that don't want to even
advertise a peep of XEP-0301 support, until activated by the sender -- big
problem -- and we unfortunately need to make such vendors happy.   I am not
totally happy about the solution either, but it's the best found so far.)

I did not understand your reasoning, why the empty <rtt> method to start
> RTT would be more accessible than the Determining support with Disco.
> Please explain!

1. I refer you to Kurt's use case.  Both Gregg and I find disco
unacceptable now.
2. I refer to "*hundreds of millions of users*" and encouraging an
accessible activation/deactivation methodology.   I'm not as concerned
about the occasional interop with other real-time text standards, which can
just be done via a gateway.
You first try to use disco, and if that fails -- you can still attempt to
activate by sending <rtt/> and waiting for confirmation.
Accessibility-market clients and accessibility-market-friendly clients will
likely have a configuration setting that enables real-time text to be
always enabled.  (Thus solving your problem anyway.)  There will always
unfortunately be some implementors that want to stop advertising XEP-0301.
  But we've eliminated the blame from the accessible client, because
accessible senders have now been expressly allowed to make an outgoing
attempt to initiate, without a disco rule banning them from being able to
do so.   (Yes, it unfortunately means there might be non-advertising
recipients that ignore/refuse -- but that's going to happen anyway,
regardless of method of Determining Support)

I wanted to say that I liked the Disco method, because then a multimedia
> system can interrogate what ways it has available to get a real-tine text
> media channel going with another party.
> We see some efforts to declare XMPP media in SIP, and we have RTP
> possibilities in XMPP through Jingle. For these cross-technogy efforts, it
> will be crucial to be able to check detailed functionality of the other
> party to decide what media transport to use.
> It is not sufficient to know that XMPP is supported for a text channel. We
> also need to be able to check if XEP-0301 is supported before we select to
> go the XMPP way with media establishment. Similarly as with the text/t140
> sdp declaration for RFC 4103.

This is important, to permit implementors to make such a specialized
client, and you can already do it if needed.   But it is not a good idea to
downgrade accessibility for hundreds of millions, to only marginally
improve (and possibly no improvement) interop with specialized clients.

Sending empty rtt implies that we have already selected to use XMPP, and
> then want to try to initiate real-time text in that channel. What if the
> other party did not have that support, but had RTP based RFC 4103. Do we
> then need to continue with clunky message-wise texting just because we took
> a chance to check if RTT was available the XMPP-way. That is not what we
> wantwith accessibility.

See above.  I'm talking about a vastly more important accessibility concern.
Making sure it has a maximum chance of succeeding in the mass market.

> However in my comment 28, I also say that I realize that it is simple and
> convenient for cases when you only have XMPP at hand, and need to select
> between clunky or smooth. And thatI want discussions like this lead to a
> decision if both methods shall be mentioned. Options are usually harmful
> and lead to uninteroperability.

Gunnar, do you have any suggestions of alternatives that still meets the
1-2-3 accessibility requirements?
1. It should be possible for senders to signal intent.  (even if some
recipients may ignore)
2. It should be possible for recipients that want to be informed, to
continue to be informed -- even if they turn off RTT, and they don't want
to advertise RTT capability.
3. It should be possible for recipients to completely ignore or reject (as
if not supported), and not even advertise at all. (A few people have been
adamant about being able to do this)

I also want to eliminate any accessibility blame from accessible
Unfortunately, disco does not meet the 1-2-3 criteria above, all of which
have been asked by implementors.
So if the blank <rtt/> is not suitable, I am open to other ideas.  Please
feel free to suggest...

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

More information about the Standards mailing list