Resuming the Accessibility discussions from last week, since Gunnar brought up concern.
We recall Kevin and Kurt's concerns, including Kurt saying: > 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' I have fixed the specification to satisfy Kurt and Kevin's concerns, and Gregg Vanderheiden seems happy with it, as am I: http://xmpp.org/extensions/xep-0301.html#determining_support *"Enabling/disabling of discovery is SHOULD NOT be the default method of activating/deactivating real-time text. See Activating and Deactivating Real-Time Text<http://xmpp.org/extensions/xep-0301.html#activating_and_deactivating_realtime_text>. * *In the absence of feature discovery, sender clients MAY send a single blank <rtt/> element at the beginning of the session (or upon sender attempting to initiate real-time text), as a method of indicating to the recipient that real-time text is permitted until the end of the chat session. Senders SHOULD NOT send any further <rtt/> until incoming <rtt/> is received during the same chat session, or when support is confirmed via discovery."* Since I now claim the use of disco as the sole tool for this method, is flawed from an Accessibility perspective, and nobody objected to my intent to allow senders to signal a desire to begin real-time text According to Activating/Deactivating Real-Time Text, sending a single <rtt event='start'/> upon sender initation of real time text is suggested) http://xmpp.org/extensions/xep-0301.html#activating_and_deactivating_realtime_text Given, XEP-0301 may be used in situations where is certain deaf people's (like me) real-time conversational (sub-1-second latency), where text is used conversationally, like telephone users use audio conversationally.... and we have accessibility legislators in both USA and Europe that are interested in citing XEP-0301 (I even posted quotes from those emails two weeks ago, and Peter Saint Andre has expedited his reviews as a result of this, too.), and because I am deaf (cannot use the phone), I am defending Accessibility aspects of this specification. It has very important "Accessibility" advantages, for the modification that I made: *1. It satisfies Accessibility requirements by giving senders a chance to signal.* (Rather than recipient blocking real-time text) *2. It allows "Accessible" implementations from both a sender and/or recipient perspective:* -- Sender can attempt to initiate an RTT call, by signalling. -- Recipient can be informed of incoming RTT call attempts even if ignored (because sender did send a signal) *3. It satisfies Kurt and Kevin's concerns last week; implementations can still choose to ignore (Section 6.2.1 Activation Methods)* (That means any potential Accessibility blame is shifted to such implementation that turns off disco to deactivate RTT; and the "accessible implementations" have immunity from blame. There might be excellent reasons (i.e. transcription bot services, DoS/security concerns, etc.). However, it makes Accessibility responsibilities pretty plainly clear for both senders/recipients, and it's easier to tell who's complying with accessibility norms, and who's not complying with accessibility norms. All satisfied now by the sender allowed ability to send a single <rtt event='start'/> upon initation. (which uses less bandwidth than disco anyway between the sender and the recipient) And because sending a single <rtt event='start'/> is now allowed, the disco (flawed for meeting accessibility needs) is downgraded from REQUIRED to RECOMMENDED. http://xmpp.org/extensions/xep-0301.html#determining_support Even if the <rtt event='start'/> signal is used, the disco is still useful -- as a persistent "I'm accepting real-time text calls" announcement if the software clients wish to support such a feature. (To easily list which buddies support real-time text and freely stream multiple <rtt/> elements right away to, without further confirmation.) Ease of Real-Time Text: ....Also, a secondary reason of permitting <rtt/> be used as the alternate method of determining support, is that it greatly simplifies implementations in many situations. It allows implementations where <rtt/> is completely inline. In one situation earlier this year, I have wasted at least 8 hours trying to figure out how to properly add disco to a fairly poorly documented XMPP library, that was otherwise able to function well with <rtt/> extension. Although the blame is on the poor documentation, it does lead to simpler implementations when trying to rapidly create many implementations, and makes it easier to create real-time text "plug-ins" since I only need to plug-in into the extension. ....Peter/Kevin did express last year it was not "xmpp-ish", but a majority of people I correspond with, say Accessibility concerns is more important. (See above) ....XEP-0301 is slightly an outlier of a standard here, because it contains lots of elements normally reserved for other layers. It essentially has its own error detection and recovery, which is already proven necessary in real-world testing (mentioned in past messages, and now encapsulated at http://xmpp.org/extensions/xep-0301.html#keeping_realtime_text_synchronized ). It's so self-contained that it's making better and better sense (due to Accessibility, too), to put activation/deactivation capabilities inline into it, irregardless of disco. ....Bandwidth concern was mentioned last year but sending a single <rtt/> element actually uses less bandwidth than sending a disco iq. So the bandwidth concern is essentially moot. ....Again, I also like the simplification that putting activation/deactivation features inline into <rtt/> does, making "XEP-0301 plugins" much easier for many existing clients using their existing XMPP libraries? I'd like to hear comments from other people about this "Accessible" improvement to "Determining Support". If there are anybody here who dislikes this, I'd like suggestions of alternatives that still meets the 1-2-3 accessibility requirements mentioned above. Thanks, Mark Rejhon
