> Re: XMPP Real Time Text: > http://xmpp.org/extensions/xep-0301.html > > CALL FOR COMMENTS
Adding request for comment: - Transmission intervals. Right now, the balance for RECOMMENDED transmission interval is every 1 second, and encoding keypress intervals allow the original typing "look and feel" to be preserved, even if there's more than one keypress per second. However, the programming for this can get complicated for some people. (See the 3rd column in the animaton demo: http://www.realjabber.org/real_time_text_demo.html ). This is called "Natural Typing". In some cases, when it means the difference of implementing XEP-0301 and not implementing XEP-0301, it is generally preferred that XEP-0301 be implemented anyway (See the 2nd column in the animation demo link above). However, 1 second bursting of text is very ugly. Also, timed text smoothing output has its own programming complications too, especially if we don't know in advance what the sender's transmission. Therefore, I am proposing an adjustment that would RECOMMEND a 300ms transmission interval WHENEVER keypress interval support (the W element) is not supported. This would yield smoother real time text output, and is similiar to the interval that AOL Instant Messenger uses. In this specific situation where someone is continuously typing, this would mean a little over 3 XMPP mesages a second. Incidentally, bandwidth requirements are similiar to 1 message per second with Natural Typing. (In the XEP-0301 specification document, think of it as comparing the first <message> of Example 7.8 and the first <message> of Example 7.9). Also, once someone types 120 WPM, that becomes 10 keypresses per second. Here, for 10 keypresses in one second, we're comparing around 3 XMPP messages a second (with one T element each, for fragments of text, ala Example 7.8 style), versus 20 XMPP messages a second (single keypress T elements with keypress interval W elements, ala Example 7.9 style). When text is being inserted in the middle of a line instead of end of the line, the position "p" attribute is added to the insert text "t" elements, that actually increases the size of <message>'s in example 7.9 very significantly, with a message stanza of about 750 bytes in some cases. At this point, three small XMPP messages a second becomes less bandwidth than one XMPP message a second, even with the TCP/IP header. (A very simple text-fragment transmission can be as small as less than 200 bytes including TCP/IP header, with more than 3/4 being the TCP/IP header and the <message> elements themselves.) The main rationale is actually keeping the text output comfortably smooth, while keeping programming as simple as possible. The bandwidth comparision is merely to allay people's concerns about using too many XMPP messages a second; However, I'd like comments from other people. We definitely do want to simplify programming for XEP-0301 when people are limited for time. (At the same time, Natural Typing is still vastly superior, even to 300ms interval) Be noted that the real time message transmission stop, whenever the typist stops. Bandwidth/server resources is consumed only during active typing. Any comments about the special case of recommending 300ms interval, in the specific situation for a continuously-active typist, whenever the W interval elements are not supported by the client? Is this too high a message rate for XMPP networks? It works great in our testing on several networks, including federated XMPP networks. Any comments from people who run message-rate-throttled XMPP servers? Thanks! Mark Rejhon On Tue, Aug 16, 2011 at 1:48 AM, Mark Rejhon <[email protected]> wrote: > Please chime in if you have any suggestion/requested change to > XEP-0301 (In-Band Real Time Text.) > Over the next few weeks, I'm going to incorporate commonly requested > changes from the realtimetext.org people to XEP-0301. > However I'm interested in hearing from YOU -- to ensure that XEP-0301 > meets your needs. > > Animation Demo, as a reminder of what Real Time Text looks like: > http://www.marky.com/realjabber/real_time_text_demo.html > > Changes already planned: > - Rewrite paragraphs at end of section 4.5.1.3 for clearer language > relating to Unicode code points (in real time editing) > - Add very small mention of RTT being compatible with groupchat. (RTT > is already compatible with groupchat, but RTT spec does not mention > groupchat. However, mention has now become necessary because the > NG911 standards for emergency responder services, has a potential > instant-message/texting 911 mechanism and online real time text is > preferred over legacy TDD / TTY for the deaf. One company has already > implemented XEP-0301 into demonstration software. Thus, this is too > important to omit groupchat mention from the spec.) > - No functionality changes are presently planned for this cycle of changes. > > Comment desired on potential changes: > - Negotiation methods / best practices on enabling/disabling of real > time text. > - Any change necessary to be compatible with text messaging systems on > cellphones? > A lot of text messaging is increasingly done over XMPP instead of SMS, > thanks to Apple iMessenger, Google Talk on Android, Facebook Chat, > etc. All of which use XMPP transmission for messages, and can benefit > from XEP-0301. No change seems to be needed, however, the ability to > limit maximum message length may be desireable. Does any XMPP-based > text messaging systems enforce a message length; as well as are there > XMPP-to-SMS gateway considerations that warrant negotiation of > limiting the textbox for outgoing messages to ~160 characters? And, > it is worth noting XEP-0301 is a potential candidate of someday > becoming a mandated assistive feature on cellphones (i.e. > substitute/replacement for TDD / TTY) just by the virtue of being an > add-on to XMPP-based text messaging that's increasingly becoming > common. In addition, some of the many IP-Relay services can be > reached by instant messaging (i.e. ip-relay.com, relaycall.com, etc) > and the use of real time text would benefit this. > > Sincerely, > Mark Rejhon >
