[Standards] XEP-0301 Fallback Mechanism of Determining Support (Accessibility)
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:
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
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
4. (more good reasons exist, but will limit to above to keep email short)
*1. Permits sender attempts to initiate real-time text even when recipients
-- 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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards