moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

0.5

This commit is contained in:
Peter Saint-Andre 2012-07-22 21:03:03 -06:00
parent 187566ecdb
commit 047b355f7a
1 changed files with 35 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

60
xep-0301.xml
View File

@ -29,6 +29,12 @@
<org>RealJabber.org and Rejhon Technologies Inc.</org>
<uri>http://www.realjabber.com</uri>
</author>
<revision>
<version>0.5</version>
<date>2012-07-22</date>
<initials>MDR</initials>
<remark><p>Minor corrections and clarifications.</p></remark>
</revision>
<revision>
<version>0.4</version>
<date>2012-07-20</date>
@ -76,6 +82,7 @@
<section1 topic="Introduction" anchor="introduction">
<p>This document defines a specification for real-time text transmitted in-band over an XMPP network.</p>
<p><strong>Real-time text is text transmitted instantly while it is being typed or created.</strong> The recipient can immediately read the sender's text as it is written, without waiting. Text can be used conversationally, similar to a telephone conversation, where one listens while the other is speaking. It eliminates waiting times found in messaging, and is favored by deaf and hard of hearing individuals who prefer text conversation. For a visual animation of real-time text, see <span class="ref"><strong><link url="http://www.realjabber.org">RealJabber.org</link></strong></span>
<note>RealJabber.org, the author's website covering this specification, including animation examples of what real time text looks like. &lt;<link url="http://www.realjabber.org">http://www.realjabber.org</link>&gt;.</note>.</p>
<p>Real-time text has been around for decades in various implementations:</p>
@ -85,12 +92,12 @@
<li>TTY and text telephones for the deaf and hard of hearing.</li>
<li>For SIP, real-time text is sent using <span class="ref"><strong><link url="http://tools.ietf.org/html/rfc4103">IETF RFC 4103</link></strong></span> <note>IETF RFC 4103: RTP Payload for Text Conversation. &lt;<link url="http://tools.ietf.org/html/rfc4103">http://tools.ietf.org/html/rfc4103</link>&gt;.</note> with <span class="ref"><strong><link url="http://www.itu.int/rec/T-REC-T.140">ITU-T T.140</link></strong></span> <note>ITU-T T.140: Protocol for multimedia application text conversation. &lt;<link url="http://www.itu.int/rec/T-REC-T.140">http://www.itu.int/rec/T-REC-T.140</link>&gt;.</note> presentation coding.</li>
<li>In 2008, AOL AIM 6.8 gained the <span class="ref"><strong><link url="http://help.aol.com/help/microsites/microsite.do?cmd=displayKC&amp;externalId=223568">AOL Real-Time IM</link></strong></span> <note>AOL AIM Real Time Text: &lt;<link url="http://help.aol.com/help/microsites/microsite.do?cmd=displayKC&amp;externalId=223568">http://help.aol.com/help/microsites/microsite.do?cmd=displayKC&amp;externalId=223568</link>&gt;.</note> feature.</li>
<li>Deployment of <span class="ref"><strong><link url="http://www.reach112.eu">Reach112</link></strong></span> <note>Reach112: European emergency service with real-time text. &lt;<link url="http://www.reach112.eu">http://www.reach112.eu</link>&gt;.</note> in Europe, an accessible emergency service with real-time text.</li>
<li>A component within Total Conversation, used by <span class="ref"><strong><link url="http://www.reach112.eu">Reach112</link></strong></span> <note>Reach112: European emergency service with real-time text. &lt;<link url="http://www.reach112.eu">http://www.reach112.eu</link>&gt;.</note> in Europe, an accessible emergency service with real-time text.</li>
</ul>
<p>Real-time text is suitable for smooth and rapid mainstream communication in text, as an all-inclusive technology to complement instant messaging. It can also allow immediate conversation in situations where speech cannot be used (e.g. quiet environments, privacy, deaf and hard of hearing). Real-time text is also beneficial in emergency situations, due to its immediacy. This document defines a specification for real-time text transmitted in-band over an XMPP network.</p>
<p>Real-time text is suitable for smooth and rapid mainstream communication in text, as an all-inclusive technology to complement instant messaging. It can also allow immediate conversation in situations where speech cannot be used (e.g. quiet environments, privacy, deaf and hard of hearing). Real-time text is also beneficial in emergency situations, due to its immediacy.</p>
</section1>
<section1 topic="Requirements" anchor="requirements">
<section2 topic="Fluid Real-Time Text" anchor="fluid_realtime_text">
@ -98,14 +105,14 @@
<li>Allow transmission of real-time text with a low latency.</li>
<li>Balance low latencies versus system, network and server limitations.</li>
<li>Support message editing in real-time, including text insertions and deletions.</li>
<li>Support transmission of the original intervals between key presses, to preserve look-and-feel of typing independently of transmission intervals.</li>
<li>Support transmission and reproduction of the original intervals between key presses, to preserve look-and-feel of typing independently of transmission intervals.</li>
</ol>
</section2>
<section2 topic="In-Band Transmission" anchor="inband_transmission">
<ol>
<li>Reliable real-time text delivery.</li>
<li>Be backwards compatible with XMPP clients that do not support real-time text.</li>
<li>Minimize reliance on network traversal protocols and/or out-of-band transmission protocols.</li>
<li>Minimize reliance on network traversal mechanisms and/or out-of-band transmission protocols.</li>
<li>Compatible with multi-user chat (MUC) and simultaneous logins.</li>
</ol>
</section2>
@ -119,7 +126,7 @@
</section2>
<section2 topic="Accessible" anchor="accessible">
<ol>
<li>Allow XMPP to follow the <span class="ref"><strong><link url="http://www.itu.int/rec/T-REC-F.703">ITU-T Rec. F.703</link></strong></span> <note>ITU-T Rec. F.703: Multimedia conversational services. &lt;<link url="http://www.itu.int/rec/T-REC-F.703">http://www.itu.int/rec/T-REC-F.703</link>&gt;.</note> Total Conversation accessibility standard for simultaneous voice, video, and real-time text.</li>
<li>Allow XMPP to follow the <span class="ref"><strong><link url="http://www.itu.int/rec/T-REC-F.703">ITU-T Rec. F.703</link></strong></span> <note>ITU-T Rec. F.703: Multimedia conversational services. &lt;<link url="http://www.itu.int/rec/T-REC-F.703">http://www.itu.int/rec/T-REC-F.703</link>&gt;.</note> Total Conversation standard for simultaneous voice, video, and real-time text.</li>
<li>Be a candidate technology for use with Next Generation 9-1-1 / 1-1-2 emergency services.</li>
<li>Be suitable for transcription services and (when coupled with voice at user's choice) for TTY/text telephone alternatives, relay services, and captioned telephone systems.</li>
<li>Be an accessible enhancement for mobile phone text messaging and mainstream instant messaging.</li>
@ -128,7 +135,7 @@
</section1>
<section1 topic="Glossary" anchor="glossary">
<p><strong>real-time</strong> – A conversational latency of less than 1 second, as defined by <span class="ref"><strong><link url="http://www.itu.int/rec/T-REC-F.700">ITU-T Rec. F.700</link></strong></span> <note>ITU-T Rec. F.700: Framework Recommendation for multimedia services &lt;<link url="http://www.itu.int/rec/T-REC-F.700">http://www.itu.int/rec/T-REC-F.700</link>&gt;.</note>, section 2.1.2.1.</p>
<p><strong>real-time text</strong> – Text transmitted in real-time while it is being typed or created.</p>
<p><strong>real-time text</strong> – Text transmitted instantly while it is being typed or created.</p>
<p><strong>real-time message</strong> – Recipient's real-time view of the sender's message still being typed or created.</p>
<p><strong>action element</strong> – An XML element that represents a single real-time message edit, such as text insertion or deletion.</p>
<p><strong>RTT</strong> – Acronym for real-time text.</p>
@ -136,7 +143,7 @@
<section1 topic="Protocol" anchor="protocol">
<section2 topic="RTT Element" anchor="rtt_element">
<p>Real-time text is transmitted via an &lt;rtt/&gt; child element of a &lt;message/&gt; stanza. The &lt;rtt/&gt; element is transmitted at regular intervals by the sender client while a message is being composed, to allow the recipient to see the sender type the message, without waiting for the full message sent in a &lt;body/&gt; element.</p>
<p>This is a basic example of a <em><strong>real-time message</strong></em> "Hello, my Juliet!” transmitted live while it is being typed, before a final message delivery in a &lt;body/&gt; element (to remain <link url="#backwards_compatible">Backwards Compatible</link>):</p>
<p>This is a basic example of a <em><strong>real-time message</strong></em> "Hello, my Juliet!” transmitted in real-time while it is being typed, before a final message delivery in a &lt;body/&gt; element (to remain <link url="#backwards_compatible">Backwards Compatible</link>):</p>
<p><strong>Example 1: Introductory Example</strong></p>
<p><code><![CDATA[<message to='juliet@capulet.lit' from='romeo@montague.lit/orchard' type='chat' id='a01'>
<rtt xmlns='urn:xmpp:rtt:0' seq='0' event='new'>
@ -229,8 +236,8 @@
</section3>
</section2>
<section2 topic="Transmission Interval" anchor="transmission_interval">
<p>For the best balance between interoperability and usability, the default transmission interval of &lt;rtt/&gt; elements for a continuously-changing message SHOULD be approximately <strong>0.7 second</strong>. This interval meets ITU-T Rec. F.700 for real-time conversation. If a different transmission interval needs to be used, the interval SHOULD be <strong>between 0.3 second and 1 second</strong>.</p>
<p>A longer interval will lead to a less optimal user experience. Conversely, a much shorter interval may more frequently trigger throttling or flooding protection algorithms in public XMPP servers, leading to dropped &lt;message/&gt; elements and/or <link url="#congestion_considerations">Congestion Considerations</link>.</p>
<p>For the best balance between interoperability and usability, the default transmission interval of &lt;rtt/&gt; elements for a continuously-changing message SHOULD be approximately <strong>0.7 second</strong>. This interval meets ITU-T Rec. F.700 Section A.3.2.1 for good quality real-time conversation. If a different transmission interval needs to be used, the interval SHOULD be <strong>between 0.3 second and 1 second</strong>.</p>
<p>A longer interval will lead to a less optimal user experience in most network conditions. Conversely, a much shorter interval may more frequently trigger throttling or flooding protection algorithms in public XMPP servers, leading to dropped &lt;message/&gt; elements and/or <link url="#congestion_considerations">Congestion Considerations</link>.</p>
<p>To provide fluid real-time text, one or more of the following methods can be used:</p>
<ul>
<li><link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link> for natural typing display, independently of the transmission interval.</li>
@ -240,7 +247,7 @@
</section2>
<section2 topic="Real-Time Text Actions" anchor="realtime_text_actions">
<p>The &lt;rtt/&gt; element MAY contain one or more <em><strong>action elements</strong></em> representing real-time text operations, including text being appended, inserted, or deleted.</p>
<p>Many chat clients allow a sender to edit their message before sending (via a Send button, or pressing Enter). The inclusion of real-time text functionality, in existing client software, needs to preserve the sender's existing expectation of being able to edit their messages. In a chat session with real-time text, the recipient can watch the sender compose and edit their message before it is delivered.</p>
<p>Many chat clients allow a sender to edit their message before sending (via a Send button, or pressing Enter). The inclusion of real-time text functionality, in existing client software, needs to preserve the sender's existing expectation of being able to edit their messages. In a chat session with real-time text, the recipient can watch the sender compose and edit their message before it is completed.</p>
<section3 topic="Action Elements" anchor="action_elements">
<p>This is a short summary of action elements that operate on a real-time message. For detailed information, see <link url="#list_of_action_elements">List of Action Elements</link>.</p>
<table>
@ -378,7 +385,7 @@
<p>Recipients MUST keep track of separate real-time messages per sender, including maintaining independent <link url="#seq">seq</link> values. Recipients MAY also use additional methods to distinguish <link url="#simultaneous_logins">Simultaneous Logins</link>, including using the full JID and/or &lt;thread/&gt;.&nbsp;</p>
</section3>
<section3 topic="Recovery From Loss of Sync" anchor="recovery_from_loss_of_sync">
<p>Loss of sync occurs if the <link url="#seq">seq</link> attribute does not increment as expected when <link url="#staying_in_sync">Staying In Sync</link>. In this case:</p>
<p>Loss of sync occurs if the <link url="#seq">seq</link> attribute do not increment as expected when <link url="#staying_in_sync">Staying In Sync</link>. In this case:</p>
<ul>
<li>Recipients MUST freeze the current real-time message; and</li>
<li>Recipients MUST ignore action elements within the current and subsequent &lt;rtt/&gt; elements; and</li>
@ -396,8 +403,8 @@
<ul>
<li>When the recipient starts sending messages from a different full JID (e.g. switched systems);</li>
<li>When the recipient sends a presence update (e.g. from offline to online);</li>
<li><p>When the sender resumes composing after an extended pause (e.g. recovery from <link url="#stale_messages">Stale Messages</link> handling);</p></li>
<li><p>When the conversation is unlocked (e.g. section 5.1 of &xmppim;);</p></li>
<li>When the sender resumes composing after an extended pause (e.g. recovery from <link url="#stale_messages">Stale Messages</link> handling);</li>
<li>When the conversation is unlocked (e.g. section 5.1 of &xmppim;);</li>
</ul>
<p>A message reset is done using the &lt;rtt/&gt; attribute <link url="#event">event</link> value of <strong>'reset'</strong> (see <link url="#rtt_attributes">RTT Attributes</link>).</p>
<p><code><![CDATA[<rtt event='reset' seq='#' xmlns='urn:xmpp:rtt:0'>
@ -455,7 +462,7 @@
<p>Activation of real-time text in a chat session (immediate or user-initiated) can be done by:</p>
<ul>
<li>Immediately transmitting real-time text (if allowed after <link url="#determining_support">Determining Support</link>); or</li>
<li>Signaling first (by transmitting a single &lt;rtt event='init'/&gt; and waiting for response).</li>
<li>Signaling first (by transmitting a single &lt;rtt <link url="#event">event</link>='init'/&gt; and waiting for response).</li>
</ul>
<p>Recipient clients can respond to incoming real-time text with an appropriate response, such as:</p>
<ul>
@ -463,6 +470,7 @@
<li>Accepting after recipient confirmation (by also activating in response, after a user confirmation prompt); or</li>
<li>Deny (by transmitting &lt;rtt event='cancel'/&gt; which is used in <link url="#deactivation_methods">Deactivation Methods</link>); or</li>
<li>Ignoring (by discarding incoming &lt;rtt/&gt; as a last resort, without using <link url="#deactivation_methods">Deactivation Methods</link>).</li>
<li>Other appropriate responses (e.g. only display incoming real-time text during <link url="#multiuser_chat">Multi-User Chat</link>).</li>
</ul>
<p>If <link url="#determining_support">Determining Support</link> allows, then it is not necessary for senders or recipients to transmit &lt;rtt event='init'/&gt; first, as any incoming <link url="#rtt_element">RTT Element</link> (other than &lt;rtt event='cancel'/&gt;) signals the start of incoming real time text. However, it allows signaling of activation before the sender begins typing.</p>
<p>In the absence of <link url="#determining_support">Determining Support</link>, sender clients can send a single &lt;rtt event='init'/&gt; element to attempt to activate real-time text. It is inappropriate for sender clients to send any further &lt;rtt/&gt; elements unless support is confirmed by discovery, or when the recipient client responds with incoming &lt;rtt/&gt; elements during the same chat session.</p>
@ -471,16 +479,16 @@
<section3 topic="Deactivation Methods" anchor="deactivation_methods">
<p>Real-time text can be deactivated by any of:</p>
<ul>
<li>Sending a signal (using &lt;rtt event='cancel'/&gt; upon deactivation, deny, or end of chat session); or</li>
<li>Sending a signal (using &lt;rtt <link url="#event">event</link>='cancel'/&gt; upon deactivation, deny, or end of chat session); or</li>
<li>Simply ending the chat session (without transmitting any further &lt;rtt/&gt; elements).</li>
</ul>
<p>Recipient clients can respond to deactivation with appropriate responses, such as:</p>
<ul>
<li>Deactivating in response (stop transmitting &lt;rtt/&gt; elements); and</li>
<li>Handling any unfinished incoming real-time message (clearing and/or saving it); and</li>
<li>Inform the recipient user that real-time text has ended (or denied/cancelled, if no real-time text was received).</li>
<li>Discontinue transmission of &lt;rtt/&gt; elements as well (not applicable to <link url="#multiuser_chat">Multi-User Chat</link>); and</li>
<li>Handle the sender's unfinished incoming real-time message (such as clearing it and/or saving it); and</li>
<li>Inform the recipient user that sender ended real-time text (or denied/cancelled, if no real-time text was received).</li>
</ul>
<p>Sending an &lt;rtt event='cancel'/&gt; is useful in situations where the user closes a chat window, and ends the chat session. It is useful when the user wants to deactivate real-time text, while still continuing the chat session. After deactivation, either party may reactivate real-time text again in accordance to <link url="#activation_methods">Activation Methods</link>.</p>
<p>Sending an &lt;rtt event='cancel'/&gt; is useful in situations where the user closes a chat window, and ends the chat session. It is useful when the user wants to deactivate real-time text, while still continuing the chat session. After deactivation, any client can reactivate real-time text again in accordance to <link url="#activation_methods">Activation Methods</link>.</p>
</section3>
</section2>
<section2 topic="Optional Remote Cursor" anchor="optional_remote_cursor">
@ -578,7 +586,9 @@
<section3 topic="Usage with Multi-User Chat and Simultaneous Logins" anchor="usage_with_multiuser_chat_and_simultaneous_logins">
<p>The in-band nature of this real-time text standard allows one-to-many situations. Thus, real-time text is appropriate for use with &xep0045; (MUC), as well as concurrent simultaneous logins.</p>
<section4 topic="Multi-User Chat" anchor="multiuser_chat">
<p>For simplicity, clients can implement real-time text only for one-on-one chat, and not for MUC. However, it can be appropriate to support &lt;rtt/&gt; elements in MUC, even if not all participants support real-time text. Participants that enable real-time text during group chat need to keep track of multiple concurrent real-time messages on a per-participant basis. Participants, with real-time text, will see real-time text coming from each participant that has real-time text enabled. Participants that turn off real-time text for themselves, can simply ignore incoming &lt;rtt/&gt; and not transmit outgoing &lt;rtt/&gt;. Participant clients without real-time text (whether unsupported or turned off) will simply see group chat function normally on a line-by-line basis, since it is <link url="#backwards_compatible">Backwards Compatible</link>. For the same participant logged in multiple times in the same room, see <link url="#simultaneous_logins">Simultaneous Logins</link>. Participant clients in MUC receiving an &lt;rtt <link url="#event">event</link>=’cancel’/&gt; should not automatically turn off outgoing real-time text (otherwise, one participant could deny real-time text between other willing participants). To minimize on-screen clutter of multiple idle real-time messages, clients can hide idle messages, clear old <link url="#stale_messages">Stale Messages</link>, and/or prioritize the display of the most useful real-time messages. Prominent visibility of real-time text can be assigned to recent typists and/or moderators (e.g. classroom teacher, convention speaker). In situations of simultaneous typing by a large number of participants, see <link url="#congestion_considerations">Congestion Considerations</link>.</p>
<p>For simplicity, clients can implement real-time text only for one-on-one chat, and not for MUC. However, it can be appropriate to support &lt;rtt/&gt; elements in MUC, even if not all participants support real-time text. Participants that enable real-time text during group chat need to keep track of multiple concurrent real-time messages on a per-participant basis. Participants, with real-time text, will see real-time text coming from each participant that has real-time text enabled. Participant clients without real-time text (whether unsupported or turned off) will simply see group chat function normally on a line-by-line basis, since it is <link url="#backwards_compatible">Backwards Compatible</link>.</p>
<p>Participants that turn off real-time text for themselves, can simply ignore incoming &lt;rtt/&gt; and not transmit outgoing &lt;rtt/&gt;. Participant clients in MUC receiving an incoming &lt;rtt <link url="#event">event</link>=’cancel’/&gt; needs to keep outgoing transmission unaffected during <link url="#deactivation_methods">Deactivation Methods</link> (otherwise, one participant could deny real-time text between other willing participants).</p>
<p>To minimize on-screen clutter of multiple idle real-time messages, clients can hide idle messages, clear old <link url="#stale_messages">Stale Messages</link>, and/or prioritize the display of the most useful real-time messages. Prominent visibility of real-time text can be assigned to recent typists and/or moderators (e.g. classroom teacher, convention speaker). For the same participant logged in multiple times in the same room, see <link url="#simultaneous_logins">Simultaneous Logins</link>. In situations of simultaneous typing by a large number of participants, see <link url="#congestion_considerations">Congestion Considerations</link>.</p>
</section4>
<section4 topic="Simultaneous Logins" anchor="simultaneous_logins">
<p>In simultaneous login situations, transmitting of &lt;rtt/&gt; works in one-to-many situations without any special software support. For many-to-one situations where there is incoming &lt;rtt/&gt; from more than one simultaneous login, <link url="#keeping_realtime_text_synchronized">Keeping Real-Time Text Synchronized</link> will pause the real-time message upon conflicting &lt;rtt/&gt;, and resume during the next <link url="#message_reset">Message Reset</link>, presumably from the active login. This provides a seamless system-switching experience. A good implementation of <link url="#message_reset">Message Reset</link> will improve user experience, regardless of whether or not the client follows Best Practices For Resource Locking (XEP-0296). Clients can choose to distinguish the &lt;rtt/&gt; streams (via full JID and/or via &lt;thread/&gt;) and keep multiple concurrent real-time messages similar in manner to <link url="#multiuser_chat">Multi-User Chat</link>, with the <link url="#stale_messages">Stale Messages</link> being timed-out.</p>
@ -590,7 +600,7 @@
<p>Senders that resume composing a message (i.e. continues a partially-composed message hours later) can transmit a <link url="#message_reset">Message Reset</link>, which allows recipients to redisplay the real-time message.</p>
</section3>
<section3 topic="Performance &amp; Efficiency" anchor="performance_efficiency">
<p>With real-time text, frequent screen updates can occur. Screen updates are a potential performance bottleneck, since fast typists type many key presses per second. Optimizing screen updates becomes especially important for slower platforms. Real-time messages need to be displayed efficiently in a flicker-free manner. The real-time message might be implemented as a separate window or separate display element.</p>
<p>With real-time text, frequent screen updates can occur. Screen updates are a potential performance bottleneck, since fast typists type many key presses per second. Optimizing screen updates becomes especially important for slower platforms. Real-time messages need to be redisplayed efficiently in a flicker-free manner. The real-time message might be implemented as a separate window or separate display element.</p>
<p>Battery life considerations are closely related to performance, as the addition of real-time text may impact battery life. If <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link> are supported, then the implementation of <link url="#element_w_wait_interval">Element &lt;w/&gt; – Wait Interval</link> needs to be implemented in a battery-efficient manner. The <link url="#transmission_interval">Transmission Interval</link> may vary dynamically to optimize for battery life and wireless reception. For devices where screen updates are an unavoidable inefficient bottleneck, see <link url="#lowbandwidth_and_lowprecision_text_smoothing">Low-Bandwidth and Low-Precision Text Smoothing</link> to reduce the number of screen updates per second.</p>
</section3>
<section3 topic="Total Conversation – Combination with Audio and Video" anchor="total_conversation_combination_with_audio_and_video">
@ -941,8 +951,8 @@
</section1>
<section1 topic="Interoperability Considerations" anchor="interoperability_considerations">
<p>There are other real-time text formats with interoperability considerations relating to the session setup level, the media transport level, and presentation level. Interoperability specifications between multiple real-time text formats can be found in the Interoperability section of <span class="ref"><strong><link url="http://www.realtimetext.org">Real-Time Text Taskforce</link></strong></span>
<note>Real-Time Text Taskforce, a foundation for real-time text standardization - &lt;<link url="http://www.realtimetext.org">http://www.realtimetext.org</link>&gt;.</note>.</p>
<p>It is appropriate for implementers to choose the most appropriate real-time text standard for the session control standard in use during a particular session. Clients that use XMPP (e.g. Google Talk) would utilize this XEP-0301 specification. Clients that use SIP can utilize IETF RFC 4103, <span class="ref"><strong><link url="http://tools.ietf.org/html/rfc5194">IETF RFC 5194</link></strong></span> <note>IETF RFC 5194: Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP). &lt;<link url="http://tools.ietf.org/html/rfc5194">http://tools.ietf.org/html/rfc5194</link>&gt;.</note> and ITU-T T.140. Clients that run on multiple networks, may need to utilize multiple real-time text standards. To interoperate between incompatible real-time text standards, gateway servers can transcode between different real-time text standards, along with other media such as audio and video. See <link url="#total_conversation_combination_with_audio_and_video">Total Conversation – Combination with Audio and Video</link>.</p>
<note>Real-Time Text Taskforce, a foundation for real-time text standardization &lt;<link url="http://www.realtimetext.org">http://www.realtimetext.org</link>&gt;.</note>.</p>
<p>It is appropriate for implementers to choose the most appropriate real-time text standard for the session control standard in use during a particular session. Clients that use XMPP (e.g. Google Talk) would utilize this XEP-0301 specification. Clients that use SIP can utilize IETF RFC 4103, <span class="ref"><strong><link url="http://tools.ietf.org/html/rfc5194">IETF RFC 5194</link></strong></span> <note>IETF RFC 5194: Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP). &lt;<link url="http://tools.ietf.org/html/rfc5194">http://tools.ietf.org/html/rfc5194</link>&gt;.</note> and ITU-T T.140. Clients that run on multiple networks, may need to utilize multiple real-time text standards. To interoperate between incompatible real-time text standards, gateway servers can transcode between different real-time text standards, along with other media such as audio and video. This can include TTY and textphones. Also, see <link url="#total_conversation_combination_with_audio_and_video">Total Conversation – Combination with Audio and Video</link>.</p>
<section2 topic="RFC 4103 and T.140" anchor="rfc_4103_and_t140">
<p>In the SIP environment, real-time text is specified in IETF RFC 4103 and ITU-T T.140. SIP is a popular real-time session control protocol, and there are many implementations of real-time text controlled by SIP. This includes some emergency service organizations (e.g. Reach 112).</p>
<p>Interoperability considerations include addressing translation, media negotiation and translation, and media transcoding. Transcoding is straightforward between this specification and T.140/RFC4103, except for editing in the middle of messages. Text insertions or deletions, occurring far back in the message, can cause a large number of erase operations in T.140 that consume time and bandwidth. T.140 specifies the use of ISO 6429 control codes for presentation characteristics, such as text color, that are not supported by this specification. During transcoding, these control codes needs to be filtered off in order to not disturb the presentation of text.</p>
@ -955,7 +965,7 @@
</section1>
<section1 topic="Security Considerations" anchor="security_considerations">
<section2 topic="Privacy" anchor="privacy">
<p>It is important for implementers of real-time text to educate users about real-time text. Users of real-time text needs to be aware that their typing is now visible in real-time to everyone in the current chat conversation. This may have security implications if users copy &amp; paste private information into their chat entry buffer (e.g. a shopping invoice) before editing out the private parts of the pasted text (e.g. a credit card number) before they send the message. With real-time message editing, recipients can watch all text changes that occur in the sender's text, before the sender sends the final message. Implementation behaviors and improved education can be added to reduce privacy issues. Examples include introduction upon first activation of feature, special handling for copy and pastes (i.e. preventing them, or prompting for confirmation), recipient confirmation of real-time text via <link url="#activating_and_deactivating_realtime_text">Activating and Deactivating Real-Time Text</link>, etc.</p>
<p>It is important for implementers of real-time text to educate users about real-time text. Users of real-time text needs to be aware that their typing is now visible in real-time to everyone in the current chat conversation. This may have security implications if users copy &amp; paste private information into their chat entry buffer (e.g. a shopping invoice) before editing out the private parts of the pasted text (e.g. a credit card number) before they send the message. With real-time message editing, recipients can watch all text changes that occur in the sender's text, before the sender sends the final message. Implementation behaviors and improved education can be added to reduce privacy issues. Examples include showing an introduction upon first activation of feature, special handling for copy and pastes (i.e. preventing them, or prompting for confirmation), recipient confirmation of real-time text via <link url="#activating_and_deactivating_realtime_text">Activating and Deactivating Real-Time Text</link>, etc.</p>
</section2>
<section2 topic="Encryption" anchor="encryption">
<p>Real-time text (&lt;rtt/&gt; elements) transmit the content contained within messages. Therefore, a client that encrypts &lt;body/&gt;, also needs to also encrypt &lt;rtt/&gt; as well:</p>
@ -1056,7 +1066,7 @@
</xs:schema>]]></code></p>
</section1>
<section1 topic="Acknowledgments" anchor="acknowledgments">
<p>The author would like to thank Real-Time Text Taskforce (R3TF) at <link class="western" href="http://www.realtimetext.org/">www.realtimetext.org</link> for their contribution to the technology documented in this specification. Mark Rejhon leads the Jabber/XMPP Taskgroup at R3TF. Members of R3TF who have contributed to this document include Gunnar Helstrom (Omnitor), Paul E. Jones (Cisco), Gregg Vanderheiden (Trace R&amp;D Center, University of Wisconsin), Barry Dingle (Interopability Leader, R3TF), and Arnoud van Wijk (Founder, R3TF). Others contributors include Bernard Aboba (Microsoft), Darren Sturman (Teligent Telecom), Christian Vogler (Gallaudet University), Norm Williams (Gallaudet University), and several members from the XMPP Standards Mailing List, including Kevin Smith (XSF), Peter Saint Andre (XSF), and many others.</p>
<p>The author would like to thank Real-Time Text Taskforce (R3TF) at <link class="western" href="http://www.realtimetext.org/">www.realtimetext.org</link> for their contribution to the technology documented in this specification. Mark Rejhon leads the Jabber/XMPP Taskgroup at R3TF. Members of R3TF who have contributed to this document include Gunnar Hellstrom (Omnitor), Paul E. Jones (Cisco), Gregg Vanderheiden (Trace R&amp;D Center, University of Wisconsin), Barry Dingle (Interopability Leader, R3TF), and Arnoud van Wijk (Founder, R3TF). Others contributors include Bernard Aboba (Microsoft), Darren Sturman (Teligent Telecom), Christian Vogler (Gallaudet University), Norm Williams (Gallaudet University), and several members from the XMPP Standards Mailing List, including Kevin Smith (XSF), Peter Saint Andre (XSF), and many others.</p>
<p>“Natural Typing”, the technique of <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>, is acknowledged as an invention by Mark Rejhon, who is deaf. This technology is provided to XMPP.org as part of this specification in compliance of the XSF's Intellectual Property Rights Policy at <link class="western" href="http://xmpp.org/extensions/ipr-policy.shtml">http://xmpp.org/extensions/ipr-policy.shtml</link>.</p>