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

Dave Cridland dave at cridland.net
Wed Jul 11 09:55:21 UTC 2012


At the risk of opening a whole new can of worms, if you're modelling an RTT
conversation as a textphone call, don't you want to be ringing, and
accepting the call, via Jingle?

If it's modelled as an enhancement of existing IM text chat, then using
XEP-0085's model, with it's fallback from disco and caps seems fine -
though it is a fallback from disco, not a replacement.
On Jul 10, 2012 7:34 PM, "Mark Rejhon" <markybox at gmail.com> wrote:

> (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>
>  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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120711/6051b68e/attachment.html>


More information about the Standards mailing list