[Standards] Advice on XEP-0301 Mass-Market Use Cases (if XEP-0301 added to Adium/Miranda within 12 months)

Mark Rejhon markybox at gmail.com
Wed Feb 29 03:06:46 UTC 2012


To the Stadards group,

I bring up a question separate from the Session Handling.
(many questions have already been answered -- thank you very much)

*Scenario: *XEP-0301 real-time text gets added to a mainstream client such
as Pidgin or Miranda within 12 months.

*Question: *What is the simplest possible and easiest method of safely
introduce real-time text politely to a mainstream client, in a
non-intrusive manner? (i.e. privacy)
Especially if one end has RTT enabled by default (i.e. intentionally
enabled by user), and the other end has RTT disabled by default (i.e.
default installation)

*Details of Scenarios:*
- People don't normally expect their typing to be transmitted in real time.
 Therefore, feature shold be off by default in such mainstream clients.
- However, it should be easy as possible to enable.  Therefore, such
mainstream clients will always advertise XEP-0301 compatibility via disco
(section 5) but not necessarly enable the transmission of outgoing
XEP-0301, including for privacy reasons.
- Some people, such as deaf users, will want to change the software
preference to permanently allow XEP-0301.
(i.e. in software preferences)
- However, even when disabled by default, we want users to make it easy for
XEP-0301-aware recipients to enable the feature for responding to other
XEP-0301 clients.
(i.e. per-chat-session activation feature, such as a button)

*Potential popularity in 10 years*
Just like all television sets have a closed caption decoder, and is usually
turned off by default, but easily turned on -- eventually, we hope XEP-0301
becomes mainstream within 10 years, as a replacement for obsolete deaf
TDD/TTY teletypewriters.   In even my limited testing (non-deaf family,
friends, coworkers, etc), I found that once they understood what RTT was,
it was a more popular feature than audio and video.   So RTT has a lot of
potential to improve the IM experience, even if it's an option feature
enabled only a few percent of the time.   Although more scientific surveys
need to be done once it's already a part of Adium/Miranda/etc, it shows
that sometimes people like to switch to the conversational mode via RTT
rather than via audio, since they can talk very conversationally without
making noise.   Other times, people are in an asynchronous mood, like text
messaging, regular instant messages, or email.   But it apparently shows
that there's more frequently a mood to be conversational via RTT than via
audio or video, from this limited testing.   Thus, we need to be prepared
for the potential possibility that it may show up in mainstream clients.
NOTE: We've also got a new logo for real-time text at
www.fasttext.orgwhich we'll be starting to use in the next 12 months
for future programming.

Advertising XEP-0301 capability is done by a caps detection.  Presumably,
this will always be the case in all clients that supports XEP-0301.

We see three situations where chat is activated between two XEP-0301 aware
clients:
1. Both clients advertise XEP-0301 capability, but does not send XEP-0301
by default.
2. Both clients advertise XEP-0301 capability, but only recipient sends
XEP-0301 by default.
3. Both clients advertise XEP-0301 capability, but only sender sends
XEP-0301 by default.
We want to make it easy for both ends to start sending RTT in scenario 2
and 3, even if disabled by default.

*Example "Accessible" future use case **(which will happen!):*
-- Alice is a deaf user, using a year 2014 build of Adium.  She has
XEP-0301 enabled.
-- Bob is a hearing user, not aware of real-time text, but is using a year
2014 build of Pidgin that has XEP-0301 support but does not transmit RTT by
default.
-- Alice sends a message to Bob.  She immediately sends RTT.  Her typing is
transmitted in real time.
-- Bob's client software detects this but does not automatically send Bob's
typing in real time.
*The big question: What should happen afterwards?*

*Possible Ideas/Methods of negotiating RTT activation*
- XEP-0020?  Bob instant messaging client, should be able to activate a
session negotiation feature.  As you remember, we added an XEP-0020 session
negotiation feature in Version 0.0.1 of XMPP-RTT, but it got removed from
Version 0.0.2 of XMPP-RTT.   It is overkill/complesx.
- Jingle?  I think it's still overkill, since we want to operate 100%
in-band
- XEP-0030?  We should always advertise XEP-0301 even if the client doesn't
send outgoing RTT by default.  This allows clients that DO WANT to send
RTT, to go ahead and send RTT anyway
- XEP-0085?  Nope, it is not suitable.
- The existing XEP-0301 featuer of *event='start' *and *event='cancel'?  *Yes,
this is a possibility, but if I can simplify things by removing these...
(as long as I have an alternative to cover the above use case.)

*The simplest method I have though of, to cover such use case:*
1. Alice's software verifies Bob's softtware does support RTT via caps
detection. (Section 5 of XEP-0301)
2. Alcie Send RTT.
3. Bob's client, upon detecting incoming <RTT> automatically displays a
message
*** Alice is sending real-time text.  Click [Activate] now to also send
your typing live in real-time, too!
4. Bob clicks "Activate", realizing that he's watching Alice's typing live.

(Note: Bob can continue to send line-by-line instant messages asking what
real-time text is, etc, before clicking the Activate button, etc.)
5. Bob is now sending real-time text even though his RTT was disabled by
default in his default install of his mass-market instant messaging
software.

*We need to emphasive RTT is an accessibility issue too* -- that it may be
available but disabled in mass-market software clients.

So I want to hear from the Standards group, about the ideal usage cases for
XEP-0301 in a mass-market client.   It's an interoperability issue, because
if we have multiple different standards of negotiating activation of RTT,
then it does not work very well.

At the same time, we need:
-- Keep it simple as possible, while staying accessible
-- Minimum amount of protocol overhead, while staying accessible
-- Keep it in-band, while staying accessible
Has anybody else found an even simpler method, or a reason to use a more
complex activation method for RTT?

Thanks,
Mark Rejhon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120228/0f6bbb60/attachment.html>


More information about the Standards mailing list