(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 <stpe...@stpeter.im> wrote: > > 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: http://xmpp.org/extensions/xep-0301.html#message_reset 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 standard. __________ 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 clients) -- some clients will activate real-time text upon a button/menu/etc (e.g. mainstream) -- 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 conversations. 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. Cheers Mark Rejhon
