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" <marky...@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 <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 > >
