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

Mark Rejhon markybox at gmail.com
Tue Jul 10 18:34:06 UTC 2012

(Starting over, from good grounds)
(NOTE: This big email is regarding what is essentially a *single
controversial sentence* added to XEP-0301 protocol)

On Tue, Jul 10, 2012 at 1:17 PM, Peter Saint-Andre <stpeter at stpeter.im>

> > Metaphorically speaking:

> i.e. in a manner of speaking, we strongly believe senders should be
> > allowed to "dial the phone".
> > Even if we don't know if the phone number is good or not.  i.e. senders
> > should be able to be allowed to try to dial.
> Sure, this is essentially the chat state notifications fallback for
> determining when to generate notifications, applied to the example of
> RTT data:
> http://xmpp.org/extensions/xep-0085.html#bizrules-gen

Oh wow -- This is a massive surprise for me.
*precedent* in a *Final* standard -- that allows bypassing disco!

This is XEP-0085 Chat States (Final standard) advocating sending chat
states without first discovering support!
That's exactly what I am trying to do with the blank <rtt/> fallback
mechanism (that's been controversial) at the end of Section 5 of XEP-0301:

I realize that I may have been overly-defensive of keeping a fallback
mechanism on Accessibility grounds, maybe my approach (is wrong) in
explaining why a fallback mechanism should exist.  Yes, I know I should not
use XEP-0085 as an excuse, but clearly there was apparently enough
agreement to accept the fallback mechanism, and keeping it in a Final


I will now approach from a professional/technical approach, to justify
keeping some modified form of fallback mechanism in XEP-0301:

I want to clarify that the fallback mechanism I designed (which I now know
has precedent) permits the following:
1. Permits sender attempts to initiate real-time text even when recipients
stay private.
2. Permits elimination of bandwidth consumption of unnecessary incoming
<rtt/> while still continuing to be receptive to real-time text.
3. Permits maximum interoperability between widest possible variety of
client implementations.
4. (more good reasons exist, but will limit to above to keep email short)

More detail:

*1. Permits sender attempts to initiate real-time text even when recipients
stay private.*
-- Explained in the previous huge email message.  But wait -- that's not
the only reason. (see below)

*2. Permits elimination of bandwidth consumption of unnecessary incoming
<rtt/> while still continuing to be receptive to real-time text. *
-- Turning on disco loses all control of bandwidth of incoming <rtt/>.  If
your software enables disco, clients are allowed to just transmit you an
<rtt/> every 0.7 seconds, consuming your bandwidth.  (Bandwidth control is
now achievable via <rtt event='init'/> and <rtt event='cancel'/> ...)
-- Feedback has shown that some implementers have high likelihood of
choosing to "turning off disco to stop the bandwidth" (as a secondary
reason to privacy).  This method of turning on/off real-time text is
already discouraged, because it makes it hard for senders/recipients to
optionally synchronize enabling of real time text (without a secondary fall
back mechanism like the one I proposd).  You already know disco is going to
be turned off in possible XEP-0301 implementations (in emails from multiple
people in the last 18 months).  It's a very fine line between "I don't want
to ever receive real time text" (Kurt) and "I don't want to ever receive
real time text, *until you ask me first*" ...Key phrase is "Until you ask
me first".   Fallback mechanism becomes necessary.
-- By providing the fallback mechanism, it is now possible to
have discovery while reducing bandwidth.  The existence of <rtt
event='init'/> and <rtt event='cancel'/> allows vendors some control of
bandwidth of real-time text, and discourage vendors from permanently
turning off disco.

*3. Permits maximum interoperability between widest possible variety of
client implementations.*
Maximum interoperability is possible between the maximum possible,
widest-diverging implementations of real-time text activations:
-- some clients will activate real time text right away (e.g. assistive
-- some clients will activate real-time text upon a button/menu/etc (e.g.
-- some clients will not synchronize enabling of real-time text (e.g.
unidirectional real time text)
-- some recipients may or may not ask user for permission (e.g. like user
prompt during audio/video activation)
-- some clients will keep real-time text private, but want to be signalled
(see previous email, and reason #1)
I want to point out that the fallback mechanism that I designed (blank rtt
element), provides for maximum interopreability of real-time text *between
ALL combinations of ALL the above scenarios. *  This is "Accessible".   I
honestly believe I tried to design well on that basis -- even if it is not
"engineer clean", it's pretty "human compatible" and "Accessible".  Please
rest assured I thought through subtle interaction scenarios, and some may
have been missed.   I am avoiding interop problems between willing
senders/recipients, that end up not talking to each other, only because one
end has lack of disco (including for any silly or stupid reason that we
engineers disagree about).

I realize it may not be 100% perfect protocol design.  But we engineers
--> are designing for human-usable software.
--> are designing for protocols that get popular more quickly because of
flexibility (and maximum interop).
--> more RTT means more deaf can do RTT, more accessible.

The more software that uses RTT, the more chances of successful RTT
Even if I don't like some of the aspects (privacy considerations
interfering with protocol), I am designing for a protocol that both small
and big vendors like, as well as accessible and mainstream vendors.
Maximum adoption is more important than a small petty privacy rule.
And the controversy is just one sentence -- one that apparently already has
precedent in a Final standard (XEP-0085 standard).

However, I now recognize some of the wording choices used are poor.
I am slimming down Section 5, and making it more professional -- but I plan
to be keeping a fallback mechanism.

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

More information about the Standards mailing list