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

0.12

This commit is contained in:
Peter Saint-Andre 2013-09-25 13:11:03 -06:00
parent 3fddad40dc
commit aa6e99df45
1 changed files with 155 additions and 146 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

301
xep-0301.xml
View File

@ -38,6 +38,12 @@
<email>gunnar.hellstrom@omnitor.se</email>
<uri>http://www.omnitor.se</uri>
</author>
<revision>
<version>0.12</version>
<date>2013-09-25</date>
<initials>MDR</initials>
<remark><p>Add discovery for support during Multi-User Chat (XEP-0045), plus minor editorial changes.</p></remark>
</revision>
<revision>
<version>0.11</version>
<date>2013-07-31</date>
@ -135,15 +141,15 @@
<section1 topic="Introduction" anchor="introduction">
<p>This document defines a specification for real-time text transmitted in-band over an XMPP network.</p>
<p>Real-time text is text transmitted instantly while it is being typed or created. The recipient can immediately read the sender's text as it is written, without waiting. It allows text to be used as conversationally as a telephone conversation, including in situations where speech is not practical (e.g. environments that must be quiet, environments too noisy to hear, restrictions on phone use, situations where speaking is a privacy or security concern, and/or when participant(s) are deaf or hard of hearing). It is also used for transmission of live speech transcription.</p>
<p>Real-time text is text transmitted instantly while it is being typed or created. The recipient can immediately read the sender's text as it is written, without waiting. It allows text to be used as conversationally as a telephone conversation, including in situations where speech is not practical (e.g., environments that must be quiet, environments too noisy to hear, restrictions on phone use, situations where speaking is a privacy or security concern, and/or when participant(s) are deaf or hard of hearing). It is also used for transmission of live speech transcription.</p>
<p>Real-time text is found in various implementations:</p>
<ul>
<li>The 'talk' command on UNIX systems since the 1970's.</li>
<li>Session Initiation Protocol (SIP), utilizing <span class="ref"><strong><link url="http://tools.ietf.org/html/rfc4103">IETF RFC 4103</link></strong></span>
<li>Session Initiation Protocol (SIP), utilizing <span class="ref"><strong><link url="http://tools.ietf.org/html/rfc4103">RFC 4103</link></strong></span>
<note>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> real-time text.</li>
<li>Instant messaging enhancements, including a <span class="ref"><strong><link url="http://tap.gallaudet.edu/rtt/">Gallaudet University</link></strong></span>
<note>Gallaudet University Technology Access Program collaboration project: Real-Time Text &lt;<link url="http://tap.gallaudet.edu/rtt/">http://tap.gallaudet.edu/rtt/</link>&gt;.</note> collaboration.</li>
<li>Next generation emergency services (<span class="ref"><strong><link url="http://tools.ietf.org/html/rfc6443">IETF RFC 6443</link></strong></span>
<li>Next generation emergency services (<span class="ref"><strong><link url="http://tools.ietf.org/html/rfc6443">RFC 6443</link></strong></span>
<note>RFC 6443: Framework for Emergency Calling Using Internet Multimedia &lt;<link url="http://tools.ietf.org/html/rfc6443">http://tools.ietf.org/html/rfc6443</link>&gt;.</note>).</li>
</ul>
<p>For a visual animation of real-time text, see <span class="ref"><strong><link url="http://www.realtimetext.org">Real-Time Text Taskforce</link></strong></span>
@ -160,7 +166,7 @@
<section2 topic="In-Band Transmission" anchor="inband_transmission">
<ol>
<li>Be backwards compatible with XMPP clients that do not support real-time text.</li>
<li>Be compatible with multi-user chat (MUC) and simultaneous logins.</li>
<li>Be compatible with &xep0045; and simultaneous logins.</li>
<li>Minimize reliance on out-of-band transmission protocols, for simpler network traversal.</li>
</ol>
</section2>
@ -168,7 +174,7 @@
<ol>
<li>Allow seamless integration of real-time text into instant messaging clients, with minimal user interface modifications.</li>
<li>Be able to function securely over intermittent and unreliable connections, including mobile phones.</li>
<li>Allow use within gateways to interoperate with other real-time text protocols, including RFC 4103 and <span class="ref"><strong><link url="http://www.itu.int/rec/T-REC-T.140">ITU-T T.140</link></strong></span>
<li>Allow use within gateways to interoperate with other real-time text protocols, including <strong>RFC 4103</strong> and <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>.</li>
<li>Be usable in an international setting.</li>
</ol>
@ -177,20 +183,20 @@
<ol>
<li>Allow XMPP applications to be able to implement <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 emergency services (e.g. 9-1-1 and 1-1-2).</li>
<li>Be a candidate technology for use with next generation emergency services (e.g., 9-1-1 and 1-1-2).</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>
</ol>
</section2>
</section1>
<section1 topic="Glossary" anchor="glossary">
<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>character</strong> - A single Unicode code point. See <link url="#unicode_character_counting">Unicode Character Counting</link>.</p>
<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 instantly while it is being typed or created, to allow recipient(s) to immediately read the sender's text as it is written, without waiting.</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>RTT</strong> – Acronym for real-time text.</p>
<p><strong>simultaneous login</strong> – Multiple simultaneous sessions, on multiple clients, using the same login (Jabber Identifier).</p>
<dl><di><dt>action element</dt><dd>An XML element that represents a single real-time message edit, such as text insertion or deletion.</dd></di>
<di><dt>character</dt><dd>A single Unicode code point. See <link url="#unicode_character_counting">Unicode Character Counting</link>.</dd></di>
<di><dt>real-time</dt><dd>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.</dd></di>
<di><dt>real-time text</dt><dd>Text transmitted instantly while it is being typed or created, to allow recipient(s) to immediately read the sender's text as it is written, without waiting.</dd></di>
<di><dt>real-time message</dt><dd>Recipient's real-time view of the sender's message still being typed or created.</dd></di>
<di><dt>RTT</dt><dd>Acronym for real-time text.</dd></di>
<di><dt>simultaneous login</dt><dd>Multiple simultaneous sessions, on multiple clients, using the same login (Jabber Identifier).</dd></di></dl>
</section1>
<section1 topic="Protocol" anchor="protocol">
<section2 topic="RTT Element" anchor="rtt_element">
@ -228,7 +234,7 @@
</section2>
<section2 topic="RTT Attributes" anchor="rtt_attributes">
<section3 topic="seq" anchor="seq">
<p>This REQUIRED attribute is a counter to maintain synchronization of real-time text. Senders MUST increment this value by 1 for each subsequent edit to the same real-time message, including when appending new text. Receiving clients MUST monitor this seq value as a lightweight verification on the synchronization of real-time text messages. The bounds of <em><strong>seq</strong></em> is 31-bits, the range of positive values for a signed 32-bit integer. See <link url="#keeping_realtime_text_synchronized">Keeping Real-Time Text Synchronized</link>.</p>
<p>This REQUIRED attribute is a counter to maintain synchronization of real-time text. Senders MUST increment this value by 1 for each subsequent edit to the same real-time message, including when appending new text. Receiving clients MUST monitor this 'seq' value as a lightweight verification on the synchronization of real-time text messages. The bounds of 'seq' is 31-bits, the range of positive values for a signed 32-bit integer. See <link url="#keeping_realtime_text_synchronized">Keeping Real-Time Text Synchronized</link>.</p>
</section3>
<section3 topic="event" anchor="event">
<p>This attribute signals events for real-time text.</p>
@ -276,28 +282,28 @@
<td>RECOMMENDED</td>
</tr>
</table>
<p>If the <em><strong>event</strong></em> attribute is omitted, <em><strong>event='edit'</strong></em> is assumed as the default. When <link url="#action_elements">Action Elements</link> are used (e.g. text appends, insertions and deletions), the &lt;rtt/&gt; element MAY contain one or more of any action elements, in any order. When action elements are not allowed, the &lt;rtt/&gt; element MUST be empty. Recipient clients MUST ignore &lt;rtt/&gt; elements containing unrecognized <em><strong>event</strong></em> values.</p>
<p>If the 'event' attribute is omitted, event="edit" is assumed as the default. When <link url="#action_elements">Action Elements</link> are used (e.g., text appends, insertions and deletions), the &lt;rtt/&gt; element MAY contain one or more of any action elements, in any order. When action elements are not allowed, the &lt;rtt/&gt; element MUST be empty. Recipient clients MUST ignore &lt;rtt/&gt; elements containing unrecognized 'event' values.</p>
</section3>
<section3 topic="id" anchor="id">
<p>This attribute is used only if Last Message Correction (XEP-0308) is implemented along with this specification. See <link url="#usage_with_last_message_correction">Usage with Last Message Correction</link> to enable real-time text during editing of the previous message.</p>
<p>This attribute is used only if &xep0308; is implemented along with this specification. See <link url="#usage_with_last_message_correction">Usage with Last Message Correction</link> to enable real-time text during editing of the previous message.</p>
</section3>
</section2>
<section2 topic="Processing Rules" anchor="processing_rules">
<ul>
<li><p><strong>Initialize a new real-time message: &lt;rtt event='new'/&gt; and &lt;rtt event='reset'/&gt;</strong><br />
Sender clients MUST use an &lt;rtt/&gt; element containing either <strong>event='new'</strong> or <strong>event='reset'</strong> in the first transmission of a new real-time message. Recipient clients MUST initialize a new blank real-time message for display, and then process all <link url="#action_elements">Action Elements</link> (e.g. text insertions and deletions) included within the &lt;rtt/&gt; element. If a real-time message already exists from the same sender in the same chat session, its content MUST be seamlessly replaced (i.e. cleared prior to immediately processing action elements).</p></li>
<li><p><strong>Both &lt;rtt event='new'/&gt; and &lt;rtt event='reset'/&gt; are logically identical to recipients, except for presentation:</strong><br />
For recipients, these differ only for optional presentation purposes (e.g. highlighting newly started incoming messages). Senders SHOULD use <em><strong>event='new'</strong></em> when sending the first text of a new message (e.g. the first key presses), and only use <em><strong>event='reset'</strong></em> when doing <link url="#message_refresh">Message Refresh</link> or <link url="#simple_realtime_text">Simple Real-Time Text</link>. See <link url="#keeping_realtime_text_synchronized">Keeping Real-Time Text Synchronized</link>.</p></li>
<li><p><strong>Sending modifications of a real-time message: Outgoing &lt;rtt event='edit'/&gt; or &lt;rtt/&gt;<br /></strong>Sender clients SHOULD transmit this element at a regular <link url="#transmission_interval">Transmission Interval</link> while the message is being modified. The <em><strong>seq</strong></em> attribute MUST increment by 1 for every consecutive modification transmitted. See <link url="#sending_realtime_text">Sending Real-Time Text</link>.</p></li>
<li><p><strong>Receiving modifications of a real-time message: Incoming &lt;rtt event='edit'/&gt; or &lt;rtt/&gt;<br /></strong>Recipient clients must verify that the <em><strong>seq</strong></em> attribute increments by 1 in consecutively received &lt;rtt/&gt; elements from the same sender. If <strong>seq</strong> increments as expected, the <link url="#action_elements">Action Elements</link> (e.g. text insertions and deletions) included with this element MUST be processed to modify the existing real-time message. Otherwise, if <em><strong>seq</strong></em> does not increment as expected, or if no real-time message already exists, the real-time message is considered out of sync and all subsequent modifications MUST be ignored until a new real-time message is initialized via <em><strong>event='new'</strong></em> or <em><strong>event='reset'</strong></em>. See <link url="#keeping_realtime_text_synchronized">Keeping Real-Time Text Synchronized</link>.</p></li>
<li><p><strong>Initialize a new real-time message: &lt;rtt event="new"/&gt; and &lt;rtt event="reset"/&gt;</strong><br />
Sender clients MUST use an &lt;rtt/&gt; element containing either event="new" or event="reset" in the first transmission of a new real-time message. Recipient clients MUST initialize a new blank real-time message for display, and then process all <link url="#action_elements">Action Elements</link> (e.g., text insertions and deletions) included within the &lt;rtt/&gt; element. If a real-time message already exists from the same sender in the same chat session, its content MUST be seamlessly replaced (i.e., cleared prior to immediately processing action elements).</p></li>
<li><p><strong>Both &lt;rtt event="new"/&gt; and &lt;rtt event="reset"/&gt; are logically identical to recipients, except for presentation:</strong><br />
For recipients, these differ only for optional presentation purposes (e.g., highlighting newly started incoming messages). Senders SHOULD use event="new" when sending the first text of a new message (e.g., the first key presses), and only use event="reset" when doing <link url="#message_refresh">Message Refresh</link> or <link url="#simple_realtime_text">Simple Real-Time Text</link>. See <link url="#keeping_realtime_text_synchronized">Keeping Real-Time Text Synchronized</link>.</p></li>
<li><p><strong>Sending modifications of a real-time message: Outgoing &lt;rtt event="edit"/&gt; or &lt;rtt/&gt;<br /></strong>Sender clients SHOULD transmit this element at a regular <link url="#transmission_interval">Transmission Interval</link> while the message is being modified. The 'seq' attribute MUST increment by 1 for every consecutive modification transmitted. See <link url="#sending_realtime_text">Sending Real-Time Text</link>.</p></li>
<li><p><strong>Receiving modifications of a real-time message: Incoming &lt;rtt event="edit"/&gt; or &lt;rtt/&gt;<br /></strong>Recipient clients must verify that the 'seq' attribute increments by 1 in consecutively received &lt;rtt/&gt; elements from the same sender. If 'seq' increments as expected, the <link url="#action_elements">Action Elements</link> (e.g., text insertions and deletions) included with this element MUST be processed to modify the existing real-time message. Otherwise, if 'seq' does not increment as expected, or if no real-time message already exists, the real-time message is considered out of sync and all subsequent modifications MUST be ignored until a new real-time message is initialized via event="new" or event="reset". See <link url="#keeping_realtime_text_synchronized">Keeping Real-Time Text Synchronized</link>.</p></li>
<li><p><strong>Committing a real-time message: Delivery of a &lt;body/&gt; element</strong><br />
A real-time message is considered complete upon receiving &lt;body/&gt;. See <link url="#body_element">Body Element</link>.</p></li>
<li><p><strong>Starting real-time text: &lt;rtt event='init'/&gt;</strong><br />
Clients MAY use this value to signal activation of real-time text without first starting a real-time message, since the sender may not start composing immediately. The <em><strong>seq</strong></em> attribute is ignored by recipient clients. See <link url="#guidelines_for_initiating_realtime_text">Guidelines for Initiating Real-Time Text</link>.</p></li>
<li><p><strong>Ending real-time text: &lt;rtt event='cancel'/&gt;</strong><br />
Clients MAY use this value to signal deactivation of real-time text. Clients receiving this element SHOULD also discontinue sending &lt;rtt/&gt; elements for the remainder of the same one-to-one chat session (until <em><strong>event='init'</strong></em> is used again), and handle any unfinished real-time messages appropriately (e.g. clearing or saving the message). The <em><strong>seq</strong></em> attribute is ignored by recipient clients. See <link url="#guidelines_for_initiating_realtime_text">Guidelines for Initiating Real-Time Text</link>.</p></li>
<li><p><strong>Starting real-time text: &lt;rtt event="init"/&gt;</strong><br />
Clients MAY use this value to signal activation of real-time text without first starting a real-time message, since the sender may not start composing immediately. The 'seq' attribute is ignored by recipient clients. See <link url="#guidelines_for_initiating_realtime_text">Guidelines for Initiating Real-Time Text</link>.</p></li>
<li><p><strong>Ending real-time text: &lt;rtt event="cancel"/&gt;</strong><br />
Clients MAY use this value to signal deactivation of real-time text. Clients receiving this element SHOULD also discontinue sending &lt;rtt/&gt; elements for the remainder of the same one-to-one chat session (until event="init" is used again), and handle any unfinished real-time messages appropriately (e.g., clearing or saving the message). The 'seq' attribute is ignored by recipient clients. See <link url="#guidelines_for_initiating_realtime_text">Guidelines for Initiating Real-Time Text</link>.</p></li>
<li><p><strong>Starting value for seq attribute:</strong><br />
Sender clients MAY use any new starting value for <em><strong>seq</strong></em> when initializing a real-time message using <em><strong>event='new'</strong></em> or <em><strong>event='reset'</strong></em>. Recipient clients receiving such elements MUST use this <em><strong>seq</strong></em> value as the new starting value. A random starting value is RECOMMENDED to improve reliability of <link url="#keeping_realtime_text_synchronized">Keeping Real-Time Text Synchronized</link> during <link url="#usage_with_multiuser_chat_and_simultaneous_logins">Usage with Multi-User Chat and Simultaneous Logins</link>.</p></li>
Sender clients MAY use any new starting value for 'seq' when initializing a real-time message using event="new" or event="reset". Recipient clients receiving such elements MUST use this 'seq' value as the new starting value. A random starting value is RECOMMENDED to improve reliability of <link url="#keeping_realtime_text_synchronized">Keeping Real-Time Text Synchronized</link> during <link url="#usage_with_multiuser_chat">Usage with Multi-User Chat</link> and <link url="#simultaneous_logins">Simultaneous Logins</link>.</p></li>
</ul>
</section2>
<section2 topic="Body Element" anchor="body_element">
@ -308,7 +314,7 @@
</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>700 milliseconds</strong>. This interval makes it possible for clients to meet ITU-T Rec. F.700 Section A.3.2.1 for good quality real-time text conversation in many network environments. If a different transmission interval needs to be used, the interval SHOULD be <strong>between 300 and 1000 milliseconds</strong>.</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>700 milliseconds</strong>. This interval makes it possible for clients to meet <strong>ITU-T Rec. F.700</strong> Section A.3.2.1 for good quality real-time text conversation in many network environments. If a different transmission interval needs to be used, the interval SHOULD be <strong>between 300 and 1000 milliseconds</strong>.</p>
<p>A longer interval will lead to a less optimal user experience. Conversely, a much shorter interval can lead to <link url="#congestion_considerations">Congestion Considerations</link>. 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>
@ -332,47 +338,47 @@
<tr>
<td>Insert&nbsp;Text</td>
<td>&lt;t&nbsp;p='#'&gt;text&lt;/t&gt;</td>
<td>Insert specified <em><strong>text</strong></em> at position <em><strong>p</strong></em> in message.</td>
<td>Insert specified <strong>text</strong> at position 'p' in message.</td>
<td><strong>REQUIRED</strong></td>
<td><strong>REQUIRED</strong></td>
</tr>
<tr>
<td>Erase&nbsp;Text</td>
<td>&lt;e&nbsp;p='#'&nbsp;n='#'/&gt;</td>
<td>Remove <em><strong>n</strong></em> characters before position <em><strong>p</strong></em> in message<em>.</em></td>
<td>Remove 'n' characters before position 'p' in message<em>.</em></td>
<td>RECOMMENDED</td>
<td><strong>REQUIRED</strong></td>
</tr>
<tr>
<td>Wait&nbsp;Interval</td>
<td>&lt;w&nbsp;n='#'/&gt;</td>
<td>Wait <em><strong>n</strong></em> milliseconds.</td>
<td>Wait 'n' milliseconds.</td>
<td>RECOMMENDED</td>
<td>RECOMMENDED</td>
</tr>
</table>
<p>These elements are kept compact in order to save bandwidth, since a single &lt;rtt/&gt; element can contain a large number of action elements (e.g. during <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>). See <link url="#list_of_action_elements">List of Action Elements</link> for details.</p>
<p>These elements are kept compact in order to save bandwidth, since a single &lt;rtt/&gt; element can contain a large number of action elements (e.g., during <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>). See <link url="#list_of_action_elements">List of Action Elements</link> for details.</p>
</section3>
<section3 topic="Attribute Values" anchor="attribute_values">
<ul>
<li><p>For <link url="#element_e_erase_text">Element &lt;e/&gt; – Erase Text</link>:<br />
The <em><strong>n</strong></em> attribute is a length value, in number of characters. If <em><strong>n</strong></em> is omitted, the default value of <em><strong>n</strong></em> MUST be 1.</p></li>
The 'n' attribute is a length value, in number of characters. If 'n' is omitted, the default value of 'n' MUST be “1”.</p></li>
<li><p>For <link url="#element_t_insert_text">Element &lt;t/&gt; – Insert Text</link> and <link url="#element_e_erase_text">Element &lt;e/&gt; – Erase Text</link>:<br />
The <em><strong>p</strong></em> attribute is an absolute position value, as a character position index into the real-time message, where 0 represents the beginning of the message. If <em><strong>p</strong></em> is omitted, the default value of <em><strong>p</strong></em> MUST point to the end of the message (i.e. <em><strong>p</strong></em> is set to the current length of the real-time message).</p></li>
The 'p' attribute is an absolute position value, as a character position index into the real-time message, where “0” represents the beginning of the message. If 'p' is omitted, the default value of 'p' MUST point to the end of the message (i.e., 'p' is set to the current length of the real-time message).</p></li>
<li><p>For the purpose of this specification, the word "character" represents a single Unicode code point. See <link url="#unicode_character_counting">Unicode Character Counting</link>.</p></li>
<li><p>Senders MUST NOT use negative values for any attribute, nor use <em><strong>p</strong></em> values bigger than the current message length. However, recipients receiving such values MUST clip negative values to 0, and clip excessively high <em><strong>p</strong></em> values to the current length of the real-time message. Modifications only occur within the boundaries of the current real-time message.</p></li>
<li><p>Senders MUST NOT use negative values for any attribute, nor use 'p' values bigger than the current message length. However, recipients receiving such values MUST clip negative values to “0”, and clip excessively high 'p' values to the current length of the real-time message. Modifications only occur within the boundaries of the current real-time message.</p></li>
</ul>
</section3>
<section3 topic="List of Action Elements" anchor="list_of_action_elements">
<p>Recipients MUST be able to process all &lt;t/&gt; and &lt;e/&gt; action elements for incoming &lt;rtt/&gt; transmissions, even if senders do not use all of these for outgoing &lt;rtt/&gt; transmissions (e.g. <link url="#simple_realtime_text">Simple Real-Time Text</link>). Support for &lt;w/&gt; is RECOMMENDED for both senders and recipients, in order to accommodate <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>. Recipients MUST ignore unexpected or unsupported elements within &lt;rtt/&gt;, while continuing to process subsequent action elements. Compatibility is ensured via <link url="#namespace_versioning">Namespace Versioning</link>. Action elements are immediate child elements of the &lt;rtt/&gt; element, and are never nested. See examples in <link url="#use_cases">Use Cases</link>.</p>
<p>Recipients MUST be able to process all &lt;t/&gt; and &lt;e/&gt; action elements for incoming &lt;rtt/&gt; transmissions, even if senders do not use all of these for outgoing &lt;rtt/&gt; transmissions (e.g., <link url="#simple_realtime_text">Simple Real-Time Text</link>). Support for &lt;w/&gt; is RECOMMENDED for both senders and recipients, in order to accommodate <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>. Recipients MUST ignore unexpected or unsupported elements within &lt;rtt/&gt;, while continuing to process subsequent action elements. Compatibility is ensured via <link url="#namespace_versioning">Namespace Versioning</link>. Action elements are immediate child elements of the &lt;rtt/&gt; element, and are never nested. See examples in <link url="#use_cases">Use Cases</link>.</p>
<section4 topic="Element &lt;t/&gt; – Insert Text" anchor="element_t_insert_text">
<p>Supports the transmission of text, including key presses, and text block inserts.<br />
<em>Note: Text can be any</em> <em>subset of text allowed in the &lt;body/&gt; element of a &lt;message/&gt;. If &lt;t/&gt; is empty or blank, no text modification takes place.</em></p>
<p><code><![CDATA[<t>text</t>]]></code></p>
<p>Append specified <em><strong>text</strong></em> at the end of message. (<em><strong>p</strong></em> defaults to message length).<br />
<em>Note: This action element is the minimum support REQUIRED for sender clients (i.e. speech transcription, chat bots, and <link url="#simple_realtime_text">Simple Real-Time Text</link> are still possible without supporting additional action elements).</em></p>
<p>Append specified <strong>text</strong> at the end of message. ('p' defaults to message length).<br />
<em>Note: This action element is the minimum support REQUIRED for sender clients (i.e., speech transcription, chat bots, and <link url="#simple_realtime_text">Simple Real-Time Text</link> are still possible without supporting additional action elements).</em></p>
<p><code><![CDATA[<t p='#'>text</t>]]></code></p>
<p>Inserts specified <em><strong>text</strong></em> at position <em><strong>p</strong></em> in the message text.</p>
<p>Inserts specified <strong>text</strong> at position 'p' in the message text.</p>
@ -381,66 +387,66 @@
<p>Supports the behavior of backspace key presses. Text is removed towards beginning of the message. This element is also used for all delete operations, including the backspace key, the delete key, and text block deletes.<br />
<em>Note: Excess backspaces MUST be ignored by the receiving client. Thus, text is backspaced only to the beginning of the message, in situations where n is larger than p.</em></p>
<p><code><![CDATA[<e/>]]></code></p>
<p>Remove 1 character from end of message. (<em><strong>n</strong></em> defaults to 1, and <em><strong>p</strong></em> defaults to message length)</p>
<p>Remove 1 character from end of message. ('n' defaults to “1”, and 'p' defaults to message length)</p>
<p><code><![CDATA[<e p='#'/>]]></code></p>
<p>Remove 1 character before character position <em><strong>p</strong></em> in message. (<em><strong>n</strong></em> defaults to 1)</p>
<p>Remove 1 character before character position 'p' in message. ('n' defaults to “1”)</p>
<p><code><![CDATA[<e n='#'/>]]></code></p>
<p>Remove <em><strong>n</strong></em> characters from end of message. (<em><strong>p</strong></em> defaults to message length)</p>
<p>Remove 'n' characters from end of message. ('p' defaults to message length)</p>
<p><code><![CDATA[<e n='#' p='#'/>]]></code></p>
<p>Remove <em><strong>n</strong></em> characters before character position <em><strong>p</strong></em> in message.</p>
<p>Remove 'n' characters before character position 'p' in message.</p>
</section4>
<section4 topic="Element &lt;w/&gt; – Wait Interval" anchor="element_w_wait_interval">
<p>Allow for the transmission of intervals, between real-time text actions, to recreate the pauses between key presses. See <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>.</p>
<p><code><![CDATA[<w n='#'/>]]></code></p>
<p>Wait <em><strong>n</strong></em> milliseconds before processing the next action element. This pause MAY be approximate, and not necessarily be of millisecond precision. Sender clients SHOULD NOT send large <em><strong>n</strong></em> values that exceed the average <link url="#transmission_interval">Transmission Interval</link>. Recipient clients MAY selectively shorten or ignore the pauses (<em><strong>n</strong></em>) in &lt;w/&gt; action elements to avoid lag in a chat session. Situations such as network congestion can result in a surge of &lt;w/&gt; elements where the total of pauses exceeds a transmission interval cycle. See <link url="#receiving_realtime_text">Receiving Real-Time Text</link>.</p>
<p>Wait 'n' milliseconds before processing the next action element. This pause MAY be approximate, and not necessarily be of millisecond precision. Sender clients SHOULD NOT send large 'n' values that exceed the average <link url="#transmission_interval">Transmission Interval</link>. Recipient clients MAY selectively shorten or ignore the pauses ('n') in &lt;w/&gt; action elements to avoid lag in a chat session. Situations such as network congestion can result in a surge of &lt;w/&gt; elements where the total of pauses exceeds a transmission interval cycle. See <link url="#receiving_realtime_text">Receiving Real-Time Text</link>.</p>
</section4>
</section3>
</section2>
<section2 topic="Keeping Real-Time Text Synchronized" anchor="keeping_realtime_text_synchronized">
<p>During a chat session, real-time text needs to be identical on both the sender and recipient ends. A missing &lt;rtt/&gt; transmission can represent missing text or missing edits. Also, recipients can connect after the sender has already started composing a message. To address this, a <link url="#message_refresh">Message Refresh</link> mechanism allows recipient clients to recover the sender's real-time message that is actively in-progress. This synchronizes real-time text in many situations, including:</p>
<ul>
<li>After recipient client reconnections (e.g. due to wireless reception, due to user restarting client).</li>
<li>After recipient client discarded <link url="#stale_messages">Stale Messages</link> (e.g. sender resumes composing hours later).</li>
<li><link url="#simultaneous_logins">Simultaneous Logins</link> (e.g. user switching between devices/clients or between windows/tabs in a client).</li>
<li>During <link url="#multiuser_chat">Multi-User Chat</link> (e.g. participants joining/leaving while other participants are composing).</li>
<li>After message stanzas are lost in transit (e.g. <link url="#congestion_considerations">Congestion Considerations</link>).</li>
<li>After recipient client reconnections (e.g., due to wireless reception, due to user restarting client).</li>
<li>After recipient client discarded <link url="#stale_messages">Stale Messages</link> (e.g., sender resumes composing hours later).</li>
<li><link url="#simultaneous_logins">Simultaneous Logins</link> (e.g., user switching between devices/clients or between windows/tabs in a client).</li>
<li>During <link url="#usage_with_multiuser_chat">Usage with Multi-User Chat</link> (e.g., participants joining/leaving while other participants are composing).</li>
<li>After message stanzas are lost in transit (e.g., <link url="#congestion_considerations">Congestion Considerations</link>).</li>
</ul>
<p>Recipient clients MUST keep track of separate real-time messages on a per-contact basis, including tracking independent <em><link url="#seq">seq</link></em> values. Recipient clients MAY track incoming &lt;rtt/&gt; elements per bare JID &LOCALBARE; to keep only one real-time message per contact. The remainder of this section automatically handles conflicting &lt;rtt/&gt; elements (e.g. typing coming concurrently from separate <link url="#simultaneous_logins">Simultaneous Logins</link>, contrary to the common case of one typist per contact). Alternatively, recipient clients MAY track incoming &lt;rtt/&gt; elements per full JID &LOCALFULL; and/or per &lt;thread/&gt;, to keep multiple separate real-time messages for the same contact. For more information about &lt;thread/&gt;, see &xep0201;.</p>
<p>Recipient clients MUST keep track of separate real-time messages on a per-contact basis, including tracking independent '<link url="#seq">seq</link>' attribute values. Recipient clients MAY track incoming &lt;rtt/&gt; elements per bare JID &LOCALBARE; to keep only one real-time message per contact. The remainder of this section automatically handles conflicting &lt;rtt/&gt; elements (e.g., typing coming concurrently from separate <link url="#simultaneous_logins">Simultaneous Logins</link>, contrary to the common case of one typist per contact). Alternatively, recipient clients MAY track incoming &lt;rtt/&gt; elements per full JID &LOCALFULL; and/or per &lt;thread/&gt;, to keep multiple separate real-time messages for the same contact. For more information about &lt;thread/&gt;, see &xep0201;.</p>
<section3 topic="Staying In Sync" anchor="staying_in_sync">
<p>By following <link url="#processing_rules">Processing Rules</link>, the recipient client creates a new real-time message when receiving &lt;rtt event='new'/&gt; or &lt;rtt event='reset'/&gt;. Thereafter, when receiving text modifications (i.e. &lt;rtt event='edit'/&gt; or &lt;rtt/&gt; without an <em><link url="#event">event</link></em> attribute):</p>
<p>By following <link url="#processing_rules">Processing Rules</link>, the recipient client creates a new real-time message when receiving &lt;rtt event="new"/&gt; or &lt;rtt event="reset"/&gt;. Thereafter, when receiving text modifications (i.e., &lt;rtt event="edit"/&gt; or &lt;rtt/&gt; without an 'event' attribute):</p>
<ol>
<li>There MUST be an existing real-time message (created via &lt;rtt event='new'/&gt; or &lt;rtt event='reset'/&gt;);</li>
<li>Senders MUST increment the <em><link url="#seq">seq</link></em> attribute in steps of 1, for consecutively transmitted text modifications.</li>
<li>Recipients MUST verify that the <em><link url="#seq">seq</link></em> attribute is incrementing by 1, for consecutively received text modifications.</li>
<li>There MUST be an existing real-time message (created via &lt;rtt event="new"/&gt; or &lt;rtt event="reset"/&gt;);</li>
<li>Senders MUST increment the 'seq' attribute in steps of 1, for consecutively transmitted text modifications.</li>
<li>Recipients MUST verify that the 'seq' attribute is incrementing by 1, for consecutively received text modifications.</li>
</ol>
</section3>
<section3 topic="Recovery From Loss of Sync" anchor="recovery_from_loss_of_sync">
<p>Loss of sync occurs during receiving text modifications if the <em><link url="#seq">seq</link></em> attribute does not increment by 1 as expected, or if no real-time message exists. In this case:</p>
<p>Loss of sync occurs during receiving text modifications if the 'seq' attribute does not increment by 1 as expected, or if no real-time message exists. In this case:</p>
<ul>
<li>Recipients MUST keep the real-time message unchanged (if any exists); and</li>
<li>Recipients MUST ignore subsequent text modifications (i.e. &lt;rtt event='edit'/&gt; or &lt;rtt/&gt; without an <em><link url="#event">event</link></em> attribute); and</li>
<li>An indication can be used to show the loss of sync (e.g. color coding, modified chat state message).</li>
<li>Recipients MUST ignore subsequent text modifications (i.e., &lt;rtt event="edit"/&gt; or &lt;rtt/&gt; without an 'event' attribute); and</li>
<li>An indication can be used to show the loss of sync (e.g., color coding, modified chat state message).</li>
</ul>
<p>Recovery occurs when the recipient receives the following:</p>
<ul>
<li>A &lt;body/&gt; element. The <link url="#body_element">Body Element</link> supersedes the real-time message.</li>
<li>An &lt;rtt/&gt; element with an <em><link url="#event">event</link></em> attribute of 'new' or 'reset' (e.g. new message, or <link url="#message_refresh">Message Refresh</link>).</li>
<li>An &lt;rtt/&gt; element with an 'event' attribute of 'new' or 'reset' (e.g., new message, or <link url="#message_refresh">Message Refresh</link>).</li>
</ul>
</section3>
<section3 topic="Message Refresh" anchor="message_refresh">
<p>A message refresh is the sender's partially composed text being (re)transmitted via &lt;rtt event='reset'/&gt;. The recipient client(s) can seamlessly redisplay the real-time message as a result. This allows real-time text to resume quickly, without waiting for senders to start a new message:</p>
<p>A message refresh is the sender's partially composed text being (re)transmitted via &lt;rtt event="reset"/&gt;. The recipient client(s) can seamlessly redisplay the real-time message as a result. This allows real-time text to resume quickly, without waiting for senders to start a new message:</p>
<p><code><![CDATA[<rtt event='reset' seq='#' xmlns='urn:xmpp:rtt:0'>
<t>This is a retransmission of the entire real-time message.</t>
</rtt>]]></code></p>
<p>The message refresh SHOULD be transmitted at intervals during active typing or composing. The RECOMMENDED interval is 10 seconds. This interval is frequent enough to minimize user waiting time, while being infrequent enough to not cause a significant bandwidth overhead. This interval can be varied, or be set to a longer time period, in order to reduce average bandwidth (e.g. long messages, infrequent or minor message changes). To save bandwidth, message refreshes SHOULD NOT occur continuously while the sender is idle. To allow quicker resumption of real-time text, sender clients MAY adjust the timing of the message refresh to occur right after any of the following additional events:</p>
<p>The message refresh SHOULD be transmitted at intervals during active typing or composing. The RECOMMENDED interval is 10 seconds. This interval is frequent enough to minimize user waiting time, while being infrequent enough to not cause a significant bandwidth overhead. This interval can be varied, or be set to a longer time period, in order to reduce average bandwidth (e.g., long messages, infrequent or minor message changes). To save bandwidth, message refreshes SHOULD NOT occur continuously while the sender is idle. To allow quicker resumption of real-time text, sender clients MAY adjust the timing of the message refresh to occur right after any of the following additional events:</p>
<ul>
<li>When the recipient starts sending messages from a different full JID (e.g. switched clients);</li>
<li>When the recipient presence changes to a more available state (e.g. &lt;show/&gt; value of 'chat');</li>
<li>When the sender resumes composing after an extended pause (e.g. recipient may have cleared <link url="#stale_messages">Stale Messages</link>);</li>
<li>When the conversation is unlocked (e.g. section 5.1 of XMPP IM);</li>
<li>When the recipient starts sending messages from a different full JID (e.g., switched clients);</li>
<li>When the recipient presence changes to a more available state (e.g., &lt;show/&gt; value of “chat”);</li>
<li>When the sender resumes composing after an extended pause (e.g., recipient may have cleared <link url="#stale_messages">Stale Messages</link>);</li>
<li>When the conversation is unlocked (e.g., section 5.1 of XMPP IM);</li>
</ul>
<p>If the recipient already has an existing real-time message from the sender, <link url="#processing_rules">Processing Rules</link> require that the real-time message MUST be seamlessly replaced. Thus, if the recipient is successfully <link url="#staying_in_sync">Staying In Sync</link>, the recipient user sees no visible effect since the text contained within &lt;rtt event='reset'/&gt; is a duplicate of the existing real-time message. If the recipient client was out of sync (<link url="#recovery_from_loss_of_sync">Recovery From Loss of Sync</link>) or it has no real-time message, the recipient user sees the real-time message immediately “catch up”.</p>
<p>Note: The use of &lt;rtt event='reset'/&gt; is not limited to message refresh, as it can contain any number of <link url="#action_elements">Action Elements</link> in any order. Sender clients MAY combine a message refresh with additional action elements (e.g. re-transmitting a whole message in one <link url="#element_t_insert_text">Element &lt;t/&gt; – Insert Text</link>, followed by some additional action elements, such as additional typing or backspacing, to seamlessly allow <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>).</p>
<p>If the recipient already has an existing real-time message from the sender, <link url="#processing_rules">Processing Rules</link> require that the real-time message MUST be seamlessly replaced. Thus, if the recipient is successfully <link url="#staying_in_sync">Staying In Sync</link>, the recipient user sees no visible effect since the text contained within &lt;rtt event="reset"/&gt; is a duplicate of the existing real-time message. If the recipient client was out of sync (<link url="#recovery_from_loss_of_sync">Recovery From Loss of Sync</link>) or it has no real-time message, the recipient user sees the real-time message immediately “catch up”.</p>
<p>Note: The use of &lt;rtt event="reset"/&gt; is not limited to message refresh, as it can contain any number of <link url="#action_elements">Action Elements</link> in any order. Sender clients MAY combine a message refresh with additional action elements (e.g., re-transmitting a whole message in one <link url="#element_t_insert_text">Element &lt;t/&gt; – Insert Text</link>, followed by some additional action elements, such as additional typing or backspacing, to seamlessly allow <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>).</p>
</section3>
</section2>
<section2 topic="Accurate Processing of Action Elements" anchor="accurate_processing_of_action_elements">
@ -448,34 +454,34 @@
<p>Incorrectly generated <link url="#action_elements">Action Elements</link> and <link url="#attribute_values">Attribute Values</link> can lead to inconsistencies between the sender and recipient during real-time editing. The Unicode characters of the real-time text need to be transmitted unaltered from the sender to the recipient, without unexpected modifications after sender pre-processing. This is the chain between the sender's creation of real-time text, to the recipient's processing of real-time text. Unaltered transmission of Unicode characters is possible with sender pre-processing, as long as the transmission from the sender to the recipient remains standards-compliant, including compliant XML processors and compliant XMPP servers.</p>
<p>If unexpected Unicode inconsistencies occur during real-time message editing, the recipient client will normally recover the message upon receiving a <link url="#body_element">Body Element</link> or a <link url="#message_refresh">Message Refresh</link>.</p>
<section3 topic="Unicode Character Counting" anchor="unicode_character_counting">
<p>For this specification, a "character" represents a single Unicode code point. This is the same definition used in section 1.1 of <span class="ref"><strong><link url="http://tools.ietf.org/html/rfc5198">IETF RFC 5198</link></strong></span>
<p>For this specification, a "character" represents a single Unicode code point. This is the same definition used in section 1.1 of <span class="ref"><strong><link url="http://tools.ietf.org/html/rfc5198">RFC 5198</link></strong></span>
<note>RFC 5198: Unicode Format for Network Interchange &lt;<link url="http://tools.ietf.org/html/rfc5198">http://tools.ietf.org/html/rfc5198</link>&gt;.</note>. For platform-independent interoperability of <link url="#action_elements">Action Elements</link>, calculations on <link url="#attribute_values">Attribute Values</link> (<em><strong>p</strong></em> and <em><strong>n</strong></em>) MUST be based on counts of Unicode code points.</p>
<p>Many platforms use different internal encodings (i.e. string formats) that are different from the transmission encoding (UTF-8). These factors need to be considered:</p>
<p>Many platforms use different internal encodings (i.e., string formats) that are different from the transmission encoding (UTF-8). These factors need to be considered:</p>
<ul>
<li><p>Multiple Unicode code points (e.g. combining marks, accents) can form a combining character sequence. This can occur in situations where there isn't a visually equivalent composite character of a single code point (e.g. when doing Unicode normalization).<br />
<li><p>Multiple Unicode code points (e.g., combining marks, accents) can form a combining character sequence. This can occur in situations where there isn't a visually equivalent composite character of a single code point (e.g., when doing Unicode normalization).<br />
<em>Action elements operate on Unicode code points individually.</em></p></li>
<li><p>Unicode code points U+10000 through U+10FFFF are represented as a surrogate pair in some Unicode encodings (e.g. UTF-16).<br />
<li><p>Unicode code points U+10000 through U+10FFFF are represented as a surrogate pair in some Unicode encodings (e.g., UTF-16).<br />
<em>Action elements operate on Unicode code points as a whole, not on separate components of a surrogate pair.</em></p></li>
<li><p>XMPP transmission uses UTF-8, which uses a variable number of bytes per Unicode code point.<br /><em>Action elements operate on Unicode code points as a whole, not on separate bytes.</em></p></li>
</ul>
<p>Lengths and positions in <link url="#attribute_values">Attribute Values</link> are relative to the internal Unicode text of the real-time message, independently of the directionality of actual displayed text. As a result, any valid Unicode text direction can be used with real-time text (right-to-left, left-to-right, and bidirectional). One way for implementers to visualize this, is to simply visualize Unicode text as an array of individual code points, and treat <link url="#attribute_values">Attribute Values</link> as array indexes.</p>
</section3>
<section3 topic="Guidelines for Senders" anchor="guidelines_for_senders">
<p>Sender clients MUST generate real-time text (<link url="#action_elements">Action Elements</link> and <link url="#attribute_values">Attribute Values</link>) based on the plain text version of the sender's message with pre-processing completed. This is separate from and concurrent to any displayed presentation of the same message (e.g. formatting, emoticon graphics, &xep0071;).</p>
<p>Sender clients MUST generate real-time text (<link url="#action_elements">Action Elements</link> and <link url="#attribute_values">Attribute Values</link>) based on the plain text version of the sender's message with pre-processing completed. This is separate from and concurrent to any displayed presentation of the same message (e.g., formatting, emoticon graphics, &xep0071;).</p>
<p>Pre-processing before generating real-time text includes Unicode normalization, conversion of emoticons graphics to text, removal of illegal characters, line-break conversion, and any other necessary text modifications. For Unicode normalization, sender clients SHOULD ensure the message is in <span class="ref"><strong><link url="http://www.unicode.org/reports/tr15/">Unicode Normalization Form C</link></strong></span>
<note>Unicode Standard Annex #15: Unicode Normalization Forms &lt;<link url="http://www.unicode.org/reports/tr15/">http://www.unicode.org/reports/tr15/</link>&gt;.</note> ("NFC"), as recommended within section 3 of RFC 5198, and within many other standards such as Canonical XML 1.0.</p>
<p>If Unicode combining character sequences (e.g. letter with multiple accents) are used for <link url="#element_t_insert_text">Element &lt;t/&gt; – Insert Text</link>, then complete combining character sequences SHOULD be sent. In situations where modifications are required to an existing combining character sequence (e.g. adding an additional accent), an <link url="#element_e_erase_text">Element &lt;e/&gt; – Erase Text</link> SHOULD be used to delete the existing combining character sequence, before transmitting a complete replacement sequence via the &lt;t/&gt; element. (However, recipients SHOULD NOT assume this behavior from sending clients. See <link url="#guidelines_for_recipients">Guidelines for Recipients</link>.)</p>
<note>Unicode Standard Annex #15: Unicode Normalization Forms &lt;<link url="http://www.unicode.org/reports/tr15/">http://www.unicode.org/reports/tr15/</link>&gt;.</note> ("NFC"), as recommended within section 3 of <strong>RFC 5198</strong>, and within many other standards such as Canonical XML 1.0.</p>
<p>If Unicode combining character sequences (e.g., letter with multiple accents) are used for <link url="#element_t_insert_text">Element &lt;t/&gt; – Insert Text</link>, then complete combining character sequences SHOULD be sent. In situations where modifications are required to an existing combining character sequence (e.g., adding an additional accent), an <link url="#element_e_erase_text">Element &lt;e/&gt; – Erase Text</link> SHOULD be used to delete the existing combining character sequence, before transmitting a complete replacement sequence via the &lt;t/&gt; element. (However, recipients SHOULD NOT assume this behavior from sending clients. See <link url="#guidelines_for_recipients">Guidelines for Recipients</link>.)</p>
<p>For the purpose of calculating <link url="#attribute_values">Attribute Values</link>, any line breaks MUST be treated as a single character. Conversion of line breaks into a single LINE FEED U+000A is REQUIRED for XML processors, according to section 2.11 of <span class="ref"><strong><link url="http://www.w3.org/TR/xml/">XML</link></strong></span>
<note>XML: Extensible Markup Language 1.0 (Fifth Edition) &lt;<link url="http://www.w3.org/TR/xml/">http://www.w3.org/TR/xml/</link>&gt;.</note>.</p>
</section3>
<section3 topic="Guidelines for Recipients" anchor="guidelines_for_recipients">
<p>For <link url="#element_t_insert_text">Element &lt;t/&gt; – Insert Text</link>, text MUST be obtained using compliant XML processing (including entities converted to characters). Recipient clients SHOULD ensure that the received text is in Unicode Normalization Form C ("NFC"). After this, recipient clients MUST NOT do any other modifications to resulting real-time messages. This is to allow accurate processing of subsequent <link url="#action_elements">Action Elements</link> and <link url="#attribute_values">Attribute Values</link> (the recipient client can separately process/modify a copy of the same real-time message text, if necessary for the purpose of display presentation).</p>
<p>It is possible for sender clients to send <link url="#element_t_insert_text">Element &lt;t/&gt; – Insert Text</link> with an incomplete combining character sequence (e.g. combining mark(s) without a Unicode base character). This is valid when extending an existing combining character sequence into a longer valid complete combining character sequence (e.g. adding an additional accent mark). It is also possible for senders to send <link url="#element_e_erase_text">Element &lt;e/&gt; – Erase Text</link> to remove code points from an existing combining character sequence, into a shorter valid complete combining character sequence (e.g. removing an accent mark). In all cases, recipient clients MUST process these elements in accordance to <link url="#action_elements">Action Elements</link>.</p>
<p>It is possible for sender clients to send <link url="#element_t_insert_text">Element &lt;t/&gt; – Insert Text</link> with an incomplete combining character sequence (e.g., combining mark(s) without a Unicode base character). This is valid when extending an existing combining character sequence into a longer valid complete combining character sequence (e.g., adding an additional accent mark). It is also possible for senders to send <link url="#element_e_erase_text">Element &lt;e/&gt; – Erase Text</link> to remove code points from an existing combining character sequence, into a shorter valid complete combining character sequence (e.g., removing an accent mark). In all cases, recipient clients MUST process these elements in accordance to <link url="#action_elements">Action Elements</link>.</p>
</section3>
</section2>
</section1>
<section1 topic="Determining Support" anchor="determining_support">
<p>If a client supports this real-time text protocol, it MUST advertise that fact in its responses to &xep0030; information requests ("disco#info") by returning a feature of <strong>urn:xmpp:rtt:0</strong></p>
<p>If a client supports this real-time text protocol, it MUST advertise that fact in its responses to &xep0030; information requests ("disco#info") by returning a feature of ‘<strong>urn:xmpp:rtt:0</strong>’.</p>
<p><strong>Example 1. A disco#info query</strong></p>
<p><code><![CDATA[<iq from='romeo@montague.lit/orchard'
id='disco1'
@ -498,33 +504,38 @@
]]></code></p>
<p>In order for an application to determine whether an entity supports this protocol, where possible it SHOULD use the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.</p>
<p>See <link url="#guidelines_for_initiating_realtime_text">Guidelines for Initiating Real-Time Text</link> for more information, including implicit discovery.</p>
</section1>
<section2 topic="Support for Groupchat" anchor="support_for_groupchat">
<p>Real-time text MAY also be used with <strong>Multi-User Chat</strong>. Before transmitting &lt;rtt/&gt; elements to a groupchat room, clients MUST follow section 17.1.1 of <strong>XEP-0045</strong> to verify that the service allows any extension or that ‘urn:xmpp:rtt:0’ is listed as an allowable namespace.</p>
<p>Services explicitly allowing this extension MUST follow section 17.1.1 of <strong>XEP-0045</strong> to include ‘urn:xmpp:rtt:0’ as an allowable namespace.</p>
<p>See <link url="#usage_with_multiuser_chat">Usage with Multi-User Chat</link>.</p>
</section2>
</section1>
<section1 topic="Guidelines for Initiating Real-Time Text" anchor="guidelines_for_initiating_realtime_text">
<p>Some clients can choose to send outgoing real-time text at all times by default. Other clients might choose to do user-initiated activation (e.g. via a button). These guidelines provide interoperability between clients that use different methods of initiating real-time text.</p>
<p>Some clients can choose to send outgoing real-time text at all times by default. Other clients might choose to do user-initiated activation (e.g., via a button). These guidelines provide interoperability between clients that use different methods of initiating real-time text.</p>
<section2 topic="Activating Real-Time Text" anchor="activating_realtime_text">
<p>In the simplest case, sender clients MAY simply begin transmitting real-time text (i.e. send &lt;rtt/&gt; elements) upon determining support.</p>
<p>In the simplest case, sender clients MAY simply begin transmitting real-time text (i.e., send &lt;rtt/&gt; elements) upon determining support.</p>
<p>For one-to-one chats, it can be beneficial for clients to easily synchronize the enabling/disabling of real-time text. Upon receiving incoming real-time text, recipient clients MAY automatically do an appropriate response, such as:</p>
<ul>
<li>Activate immediately (begin transmitting &lt;rtt/&gt; elements too); or</li>
<li>Activate after user confirmation prompt (for <link url="#privacy">Privacy</link> considerations); or</li>
<li>Deny (transmit &lt;rtt event='cancel'/&gt;); or</li>
<li>Deny (transmit &lt;rtt event="cancel"/&gt;); or</li>
<li>Ignore (discard incoming &lt;rtt/&gt; elements); or</li>
<li>Display only incoming real-time text (e.g. <link url="#multiuser_chat">Multi-User Chat</link> participants control their own outgoing real-time text).</li>
<li>Display only incoming real-time text (e.g., <link url="#usage_with_multiuser_chat">Usage with Multi-User Chat</link> participants control their own outgoing real-time text).</li>
</ul>
<p>To prevent transmission loops, senders SHOULD NOT transmit &lt;rtt event='init'/&gt; automatically in response to incoming &lt;rtt event='init'/&gt;. Upon sending any &lt;rtt/&gt; elements (except &lt;rtt event='cancel'/&gt;), real-time text is considered activated on the sender side and it is not necessary to transmit &lt;rtt event='init'/&gt; again for the chat session while real-time text is active.</p>
<p>For any client, the preferred first &lt;rtt/&gt; element to send is &lt;rtt <link url="#event">event</link>='init'/&gt; as it can quickly signal activation of real-time text, without waiting for the sender to begin composing a new message, and since it is usable regardless of discovery. Also, if the sender was already composing a message when activating real-time text, <link url="#message_refresh">Message Refresh</link> handles this situation.</p>
<p>While explicit discovery is strongly RECOMMENDED (see <link url="#determining_support">Determining Support</link>), the sender client MAY implicitly request and discover the use of real-time text, by sending &lt;rtt event='init'/&gt; upon activation. Senders SHOULD NOT send any further &lt;rtt/&gt; elements, until support is confirmed either by incoming &lt;rtt/&gt; elements or via discovery. Implicit discovery makes it possible to use real-time text as an enhancement to &xep0085; (XEP-0085 Section 5.1), during all situations where it can be used (e.g. when an actively-composing recipient appears invisible/offline to the sender). See <link url="#usage_with_chat_states">Usage with Chat States</link>.</p>
<p>To prevent transmission loops, senders SHOULD NOT transmit &lt;rtt event="init"/&gt; automatically in response to incoming &lt;rtt event="init"/&gt;. Upon sending any &lt;rtt/&gt; elements (except &lt;rtt event="cancel"/&gt;), real-time text is considered activated on the sender side and it is not necessary to transmit &lt;rtt event="init"/&gt; again for the chat session while real-time text is active.</p>
<p>For any client, the preferred first &lt;rtt/&gt; element to send is &lt;rtt <link url="#event">event</link>="init"/&gt; as it can quickly signal activation of real-time text, without waiting for the sender to begin composing a new message, and since it is usable regardless of discovery. Also, if the sender was already composing a message when activating real-time text, <link url="#message_refresh">Message Refresh</link> handles this situation.</p>
<p>While explicit discovery is REQUIRED where possible (see <link url="#determining_support">Determining Support</link>), it is not possible to use explicit discovery when the sender does not share a presence subscription with the the contact and knows only their bare JID (e.g., they have yet to receive stanzas from the contact). In this case, the sender client MAY implicitly request and discover the use of real-time text, by sending &lt;rtt event="init"/&gt; upon activation. Senders SHOULD NOT send any further &lt;rtt/&gt; elements, until support is confirmed either by incoming &lt;rtt/&gt; elements or via discovery. Implicit discovery makes it possible to use real-time text as an enhancement to &xep0085; (Section 5.1), during all situations where it can be used (e.g., when an actively-composing sender appears invisible/offline to the recipient). See <link url="#usage_with_chat_states">Usage with Chat States</link>.</p>
</section2>
<section2 topic="Deactivating Real-Time Text" anchor="deactivating_realtime_text">
<p>Real-time text MAY be deactivated by transmitting &lt;rtt <link url="#event">event</link>='cancel'/&gt;, or simply by ending the chat session. Recipient clients SHOULD respond to deactivation with appropriate response(s), including:</p>
<p>Real-time text MAY be deactivated by transmitting &lt;rtt <link url="#event">event</link>="cancel"/&gt;, or simply by ending the chat session. Recipient clients SHOULD respond to deactivation with appropriate response(s), including:</p>
<ul>
<li>Stop transmitting &lt;rtt/&gt; elements as well (not applicable to <link url="#multiuser_chat">Multi-User Chat</link>); and</li>
<li>Stop transmitting &lt;rtt/&gt; elements as well (not applicable to <link url="#usage_with_multiuser_chat">Usage with Multi-User Chat</link>); and</li>
<li>Handle the sender's unfinished incoming real-time message; 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>Any client MAY also send an &lt;rtt event='cancel'/&gt; when ending the chat session (e.g. user closes a chat window) or when deactivating real-time text while continuing the chat session. Clients receiving &lt;rtt event='cancel'/&gt; do not need to also transmit &lt;rtt event='cancel'/&gt; back.</p>
<p>Senders deactivating real-time text while in the middle of composing a message can continue composing their message without real-time text being sent. Completed messages continue to be transmitted normally via the <link url="#body_element">Body Element</link>. Recipients that no longer receive further real-time updates, MAY handle the incomplete sender's real-time message appropriately (e.g. clearing/greying-out/saving the message, or using <link url="#stale_messages">Stale Messages</link> handling).</p>
<p>After deactivation, any client MAY reactivate real-time text again using &lt;rtt event='init'/&gt;.</p>
<p>Any client MAY also send an &lt;rtt event="cancel"/&gt; when ending the chat session (e.g., user closes a chat window) or when deactivating real-time text while continuing the chat session. Clients receiving &lt;rtt event="cancel"/&gt; do not need to also transmit &lt;rtt event="cancel"/&gt; back.</p>
<p>Senders deactivating real-time text while in the middle of composing a message can continue composing their message without real-time text being sent. Completed messages continue to be transmitted normally via the <link url="#body_element">Body Element</link>. Recipients that no longer receive further real-time updates, MAY handle the incomplete sender's real-time message appropriately (e.g., clearing/greying-out/saving the message, or using <link url="#stale_messages">Stale Messages</link> handling).</p>
<p>After deactivation, any client MAY reactivate real-time text again using &lt;rtt event="init"/&gt;.</p>
</section2>
</section1>
<section1 topic="Implementation Notes" anchor="implementation_notes">
@ -537,10 +548,10 @@
<p>When key press intervals are preserved at high precision, all subtleties of typing are preserved, including the 'mood' (calm typing versus panicked or emphatic typing, etc.). Much as Voice over IP (VoIP) allows accurate packet transmission of sound, this spec allows accurate packet transmission of original typing look-and-feel. This enables the real-time feel of typing over virtually any network connection, without requiring frequent transmission intervals. Look and feel of typing is also preserved over variable latency connections including &xep0206;, mobile phone, satellite and long international connections with heavy packet-bursting tendencies.</p>
</section3>
<section3 topic="Time Critical and Low Latency Methods" anchor="time_critical_and_low_latency_methods">
<p>There are specialized situations such as live transcriptions and captioning (e.g. transcription service, closed captioning provider, captioned telephone, Communication Access Realtime Translation (CART), relay services) that demand low latency transmission. Such systems typically use voice recognition and/or stenotype machines, which output text in word or phrase bursts rather than a character at a time. It can be acceptable for senders with bursty output to immediately transmit word or phrase bursts of text without buffering, as long as the average stanza rate is not excessive. This eliminates any lag caused by the <link url="#transmission_interval">Transmission Interval</link>. It is not necessary to transmit <link url="#element_w_wait_interval">Element &lt;w/&gt; – Wait Interval</link> for real-time transcription.</p>
<p>There are specialized situations such as live transcriptions and captioning (e.g., transcription service, closed captioning provider, captioned telephone, Communication Access Realtime Translation (CART), relay services) that demand low latency transmission. Such systems typically use voice recognition and/or stenotype machines, which output text in word or phrase bursts rather than a character at a time. It can be acceptable for senders with bursty output to immediately transmit word or phrase bursts of text without buffering, as long as the average stanza rate is not excessive. This eliminates any lag caused by the <link url="#transmission_interval">Transmission Interval</link>. It is not necessary to transmit <link url="#element_w_wait_interval">Element &lt;w/&gt; – Wait Interval</link> for real-time transcription.</p>
</section3>
<section3 topic="Low-Bandwidth and Low-Precision Text Smoothing" anchor="lowbandwidth_and_lowprecision_text_smoothing">
<p>Some software platforms (e.g. JavaScript, BOSH, mobile devices) may have low-precision timers that impact <link url="#transmission_interval">Transmission Interval</link> and/or <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>. Clients can optimize for bandwidth, performance and/or screen repaints by eliminating, merging, or ignoring <link url="#element_w_wait_interval">Element &lt;w/&gt; – Wait Interval</link> selectively, especially those containing shorter intervals. In addition, it is acceptable for the transmission interval of &lt;rtt/&gt; to vary, either intentionally for optimizations, or due to precision limitation, preferably within the range recommended by <link url="#transmission_interval">Transmission Interval</link>. Compression can also be used to reduce bandwidth (e.g. TLS compression or &xep0138;).</p>
<p>Some software platforms (e.g., JavaScript, BOSH, mobile devices) may have low-precision timers that impact <link url="#transmission_interval">Transmission Interval</link> and/or <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>. Clients can optimize for bandwidth, performance and/or screen repaints by eliminating, merging, or ignoring <link url="#element_w_wait_interval">Element &lt;w/&gt; – Wait Interval</link> selectively, especially those containing shorter intervals. In addition, it is acceptable for the transmission interval of &lt;rtt/&gt; to vary, either intentionally for optimizations, or due to precision limitation, preferably within the range recommended by <link url="#transmission_interval">Transmission Interval</link>. Compression can also be used to reduce bandwidth (e.g., TLS compression or &xep0138;).</p>
<p>Clients can choose to implement alternate text-smoothing methods, such as adaptive-rate character-at-a-time output, and/or word buffering for incoming real-time text. Word buffering prevents most typing mistakes from being displayed, which can be a useful mode of operation for certain recipients who may dislike watching the sender's typing mistakes.</p>
</section3>
</section2>
@ -548,11 +559,11 @@
<p>Recipient clients can choose to display a remote cursor within incoming real-time messages. A remote cursor is a separate cursor/caret indicator within incoming real-time messages, separate of the user's local cursor for outgoing messages. This can improve usability of real-time text, since it becomes easier for a recipient to observe the sender's real-time message edits. For clients that do not implement a remote cursor, skip this section.</p>
<p><link url="#action_elements">Action Elements</link> use only absolute positioning (relative positions are not used by this specification), so clients do not need to remember the position value from previous action elements. Recipient software can calculate the remote cursor position as follows:</p>
<ul>
<li><p>Upon receiving <link url="#element_t_insert_text">Element &lt;t/&gt; – Insert Text</link>, the cursor position is the <em><strong>p</strong></em> attribute plus the length of the text being inserted. The cursor position is put at the end of the inserted text.<br />
<li><p>Upon receiving <link url="#element_t_insert_text">Element &lt;t/&gt; – Insert Text</link>, the cursor position is the 'p' attribute plus the length of the text being inserted. The cursor position is put at the end of the inserted text.<br />
<em>This allows normal forward cursor movement during text insertion.</em></p></li>
<li><p>Upon receiving <link url="#element_e_erase_text">Element &lt;e/&gt; – Erase Text</link>, the cursor position is the <em><strong>p</strong></em> attribute minus the <em><strong>n</strong></em> attribute.<br />
<li><p>Upon receiving <link url="#element_e_erase_text">Element &lt;e/&gt; – Erase Text</link>, the cursor position is the 'p' attribute minus the 'n' attribute.<br />
<em>This allows normal backwards cursor movement to a backspace key.</em></p></li>
<li><p>Upon receiving an empty <link url="#element_t_insert_text">Element &lt;t/&gt; – Insert Text</link> (e.g. &lt;t p='#'/&gt; or &lt;t p='#'&gt;&lt;/t&gt;), the cursor position is the <strong>p</strong> attribute and no text modification is done. Senders can send these elements when only the cursor position has changed (e.g. arrow keys, mouse repositioning). These are non-operative elements on recipients that do not implement a remote cursor.</p></li>
<li><p>Upon receiving an empty <link url="#element_t_insert_text">Element &lt;t/&gt; – Insert Text</link> (e.g., &lt;t p='#'/&gt; or &lt;t p='#'&gt;&lt;/t&gt;), the cursor position is the 'p' attribute and no text modification is done. Senders can send these elements when only the cursor position has changed (e.g., arrow keys, mouse repositioning). These are non-operative elements on recipients that do not implement a remote cursor.</p></li>
</ul>
</section2>
<section2 topic="Sending Real-Time Text" anchor="sending_realtime_text">
@ -562,12 +573,12 @@
<ul>
<li>It captures all typing, including edits and deletes.</li>
<li>It captures copy &amp; paste operations, as well as edits made via a pointing device.</li>
<li>It captures all automatic text changes (e.g. spell checker, auto-correct, macros, transcription, assistive devices).</li>
<li>It captures characters requiring multiple key presses to compose (e.g. accents, combining marks).</li>
<li>It makes no assumptions about different keyboards or input method editors (e.g. Chinese).</li>
<li>It captures all automatic text changes (e.g., spell checker, auto-correct, macros, transcription, assistive devices).</li>
<li>It captures characters requiring multiple key presses to compose (e.g., accents, combining marks).</li>
<li>It makes no assumptions about different keyboards or input method editors (e.g., Chinese).</li>
<li>Text change events are more portable across platforms, including on mobile phones.</li>
</ul>
<p>During a text change event, the sender’s current message text can be compared to the old message text from the previous text change event. The difference in text, between consecutive text change events, is typically a one character difference (e.g. key press) or one text block difference (e.g. auto-correct, cut, paste). In order to calculate what text changes took place, the first changed character and the last changed character are determined. From this, it is simple to generate <link url="#action_elements">Action Elements</link> for a single text block deletion and/or insertion. In addition, if <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link> is supported, then <link url="#element_w_wait_interval">Element &lt;w/&gt; – Wait Interval</link> records the time elapsed between text change events.</p>
<p>During a text change event, the sender’s current message text can be compared to the old message text from the previous text change event. The difference in text, between consecutive text change events, is typically a one character difference (e.g., key press) or one text block difference (e.g., auto-correct, cut, paste). In order to calculate what text changes took place, the first changed character and the last changed character are determined. From this, it is simple to generate <link url="#action_elements">Action Elements</link> for a single text block deletion and/or insertion. In addition, if <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link> is supported, then <link url="#element_w_wait_interval">Element &lt;w/&gt; – Wait Interval</link> records the time elapsed between text change events.</p>
<p>Sender software can do the following:</p>
<ol>
<li><p>Monitor for text changes in the sender’s message. Whenever a text change event occurs, compute action element(s) and append these action element(s) to a buffer. Repeating this step during every text change event, is equivalent to recording a small sequence of typing.</p></li>
@ -576,10 +587,10 @@
</ol>
</section3>
<section3 topic="Monitoring Key Presses Directly" anchor="monitoring_key_presses_directly">
<p>Real-time text can be generated via monitoring key presses. However, this does not have the advantages of <link url="#monitoring_message_changes_instead_of_key_presses">Monitoring Message Changes Instead Of Key Presses</link>. Care needs be taken with automatic changes to the message, generated by means other than key presses. This includes spell check auto-correct, copy and pastes, transcription, input method editors, and multiple key presses required to compose a character (i.e. accents). Key press events can miss these text changes, and this can potentially cause incorrect real-time text to be transmitted.</p>
<p>Real-time text can be generated via monitoring key presses. However, this does not have the advantages of <link url="#monitoring_message_changes_instead_of_key_presses">Monitoring Message Changes Instead Of Key Presses</link>. Care needs be taken with automatic changes to the message, generated by means other than key presses. This includes spell check auto-correct, copy and pastes, transcription, input method editors, and multiple key presses required to compose a character (i.e., accents). Key press events can miss these text changes, and this can potentially cause incorrect real-time text to be transmitted.</p>
</section3>
<section3 topic="Append-Only Real-Time Text" anchor="appendonly_realtime_text">
<p>The use of <link url="#element_t_insert_text">Element &lt;t/&gt; – Insert Text</link> without any attributes, simply appends text to the end of a message, while the use of <link url="#element_e_erase_text">Element &lt;e/&gt; – Erase Text</link> without any attributes, simply erases text from the end of the message. This sending method can also be useful for special-purpose clients where mid-message editing capabilities are not used (e.g. simple transcription, news tickers, relay services, captioned telephone).</p>
<p>The use of <link url="#element_t_insert_text">Element &lt;t/&gt; – Insert Text</link> without any attributes, simply appends text to the end of a message, while the use of <link url="#element_e_erase_text">Element &lt;e/&gt; – Erase Text</link> without any attributes, simply erases text from the end of the message. This sending method can also be useful for special-purpose clients where mid-message editing capabilities are not used (e.g., simple transcription, news tickers, relay services, captioned telephone).</p>
</section3>
<section3 topic="Simple Real-Time Text" anchor="simple_realtime_text">
<p>It is possible for sender clients to use <link url="#message_refresh">Message Refresh</link> to simply re-transmit the whole real-time message, as a method of transmitting text changes. The advantage is very simple implementation. Disadvantages can include the lack of <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>, and extra bandwidth consumption that can occur with longer messages, unless stream compression is used. The below illustrates transmission of the real-time message “<strong>Hello there!</strong>” at a regular <link url="#transmission_interval">Transmission Interval</link> while the sender is typing.</p>
@ -600,54 +611,52 @@
<t>Hello there!</t>
</rtt>
</message>]]></code></p>
<p>Note: The <em><strong>seq</strong></em> attribute can be restarted at any value with &lt;rtt event='reset'/&gt; and &lt;rtt event='new'/&gt;. See <link url="#processing_rules">Processing Rules</link>.</p>
<p>Note: The 'seq' attribute can be restarted at any value with &lt;rtt event="reset"/&gt; and &lt;rtt event="new"/&gt;. See <link url="#processing_rules">Processing Rules</link>.</p>
</section3>
</section2>
<section2 topic="Receiving Real-Time Text" anchor="receiving_realtime_text">
<p>In order to allow <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link> in incoming real-time text, recipient clients can do the following:</p>
<ol>
<li><p>Upon receiving <link url="#action_elements">Action Elements</link> in incoming &lt;rtt/&gt; elements, they are added to a queue in the order they are received. This provides immunity to variable network conditions, since the queueing action will smooth out incoming transmission (e.g. receiving new &lt;rtt/&gt; while still processing action elements from a delayed &lt;rtt/&gt;).</p></li>
<li><p>Upon receiving <link url="#action_elements">Action Elements</link> in incoming &lt;rtt/&gt; elements, they are added to a queue in the order they are received. This provides immunity to variable network conditions, since the queueing action will smooth out incoming transmission (e.g., receiving new &lt;rtt/&gt; while still processing action elements from a delayed &lt;rtt/&gt;).</p></li>
<li><p>The recipient client processes action elements in the queue in sequential order, including pauses from <link url="#element_w_wait_interval">Element &lt;w/&gt; – Wait Interval</link>, if supported. This is equivalent to playing back the sender's original typing.</p></li>
</ol>
<p>If <link url="#element_w_wait_interval">Element &lt;w/&gt; – Wait Interval</link> is supported, excess lag in incoming real-time text can occur when delayed &lt;rtt/&gt; elements get delivered (e.g. congestion, intermittent wireless reception). To avoid delayed presentation of real-time text, the recipient client needs to speed up processing of action elements. This can be accomplished through a variety of techniques, such as shortening the pauses (<em><strong>n</strong></em> value) in &lt;w/&gt; elements, ignoring excess &lt;w/&gt; elements, immediately outputting action elements that are still queued, and/or keeping action elements from a limited number of &lt;rtt/&gt; elements queued (immediately outputting any prior action elements). This allows lagged real-time text to catch up more quickly.</p>
<p>If <link url="#element_w_wait_interval">Element &lt;w/&gt; – Wait Interval</link> is supported, excess lag in incoming real-time text can occur when delayed &lt;rtt/&gt; elements get delivered (e.g., congestion, intermittent wireless reception). To avoid delayed presentation of real-time text, the recipient client needs to speed up processing of action elements. This can be accomplished through a variety of techniques, such as shortening the pauses ('n' value) in &lt;w/&gt; elements, ignoring excess &lt;w/&gt; elements, immediately outputting action elements that are still queued, and/or keeping action elements from a limited number of &lt;rtt/&gt; elements queued (immediately outputting any prior action elements). This allows lagged real-time text to catch up more quickly.</p>
<p>Upon receiving a <link url="#body_element">Body Element</link> indicating a completed message, it is acceptable for the full message text from &lt;body/&gt; to be displayed immediately in place of the real-time message, and discard any unprocessed action elements. This prevents any delay in displaying the final message delivery, however, this may cause a sudden surge of text in some situations.</p>
<p>If the &lt;w/&gt; element is not supported, receiving clients can use an alternate text-smoothing method in order to <link url="#avoid_bursty_text_presentation">Avoid Bursty Text Presentation</link> (e.g. time-smoothed progressive output of received real-time text).</p>
<p>If the &lt;w/&gt; element is not supported, receiving clients can use an alternate text-smoothing method in order to <link url="#avoid_bursty_text_presentation">Avoid Bursty Text Presentation</link> (e.g., time-smoothed progressive output of received real-time text).</p>
</section2>
<section2 topic="Other Guidelines" anchor="other_guidelines">
<section3 topic="Message Length" anchor="message_length">
<p>A large sequence of action elements can result in an &lt;rtt/&gt; larger than the size of a message &lt;body/&gt;. This can occur normally during fast typing when <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link> during small messages. However, if the &lt;rtt/&gt; element becomes unusually large (e.g. macros, multiple copy and pastes, leading to an &lt;rtt/&gt; exceeding one kilobyte) a <link url="#message_refresh">Message Refresh</link> can instead be used, in order to save bandwidth. (Stream compression is another approach.)</p>
<p>A large sequence of action elements can result in an &lt;rtt/&gt; larger than the size of a message &lt;body/&gt;. This can occur normally during fast typing when <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link> during small messages. However, if the &lt;rtt/&gt; element becomes unusually large (e.g., macros, multiple copy and pastes, leading to an &lt;rtt/&gt; exceeding one kilobyte) a <link url="#message_refresh">Message Refresh</link> can instead be used, in order to save bandwidth. (Stream compression is another approach.)</p>
<p>Clients can limit the length of the text input for the sender's message, in order to keep the size of &lt;message/&gt; stanzas reasonable, including during <link url="#message_refresh">Message Refresh</link>. Also, large &lt;rtt/&gt; elements might occur in situations such as large copy and pastes. To keep message stanza sizes reasonable, &lt;rtt/&gt; can be transmitted in a separate &lt;message/&gt; than the one containing &lt;body/&gt;.</p>
<p>For clients that send continuous real-time text (e.g. news ticker, captioning, speech transcription, TTY/text telephone gateway), a <link url="#body_element">Body Element</link> can be sent and then a new real-time message started immediately after, every time a message reaches a specific size. This allows continuous real-time text without real-time messages becoming excessively large.</p>
<p>For clients that send continuous real-time text (e.g., news ticker, captioning, speech transcription, TTY/text telephone gateway), a <link url="#body_element">Body Element</link> can be sent and then a new real-time message started immediately after, every time a message reaches a specific size. This allows continuous real-time text without real-time messages becoming excessively large.</p>
</section3>
<section3 topic="Usage with Chat States" anchor="usage_with_chat_states">
<p>Real-time text can be used in conjunction with Chat State Notifications (XEP-0085). It is best to handle XEP-0301 and XEP-0085 transmissions in separate &lt;message/&gt; stanzas. Chat states such as &lt;composing/&gt; or &lt;active/&gt; are sent separately from &lt;rtt/&gt; elements.</p>
<p>Chat states are handled as specified by XEP-0085. The continuous transmission of real-time text corresponds to a &lt;composing/&gt; chat state. Therefore, the timing of the &lt;composing/&gt; chat state coincides with the beginning of continuous &lt;rtt/&gt; transmission.&nbsp;</p>
<p>Real-time text can be used in conjunction with <strong>Chat State Notifications</strong>. It is best to handle <strong>XEP-0301</strong> and <strong>XEP-0085</strong> transmissions in separate &lt;message/&gt; stanzas. Chat states such as &lt;composing/&gt; or &lt;active/&gt; are sent separately from &lt;rtt/&gt; elements.</p>
<p>Chat states are handled as specified by <strong>XEP-0085</strong>. The continuous transmission of real-time text corresponds to a &lt;composing/&gt; chat state. Therefore, the timing of the &lt;composing/&gt; chat state coincides with the beginning of continuous &lt;rtt/&gt; transmission.&nbsp;</p>
</section3>
<section3 topic="Usage with Last Message Correction" anchor="usage_with_last_message_correction">
<p>It is possible to use &xep0308; (XEP-0308) with real-time text. If XEP-0308 is implemented in concert with this specification, the following rules apply:</p>
<p>It is possible to use <strong>Last Message Correction</strong> with real-time text. If <strong>XEP-0308</strong> is implemented in concert with this specification, the following rules apply:</p>
<ul>
<li><p>For all &lt;rtt/&gt; elements transmitted during composing a new message, the <em><link url="#id">id</link></em> attribute of &lt;rtt/&gt; is not used.</p></li>
<li><p>For all &lt;rtt/&gt; elements transmitted during editing of the previous message, the <em><strong>id</strong></em> attribute of &lt;rtt/&gt; matches the <em><strong>id</strong></em> attribute of the old &lt;message/&gt; stanza containing the &lt;body/&gt; text being edited (see 'Business Rules' in XEP-0308). This enables recipient clients to display real-time text while the sender is editing the previously-delivered message.</p></li>
<li><p>Senders clients need to transmit a <link url="#message_refresh">Message Refresh</link> when transmitting &lt;rtt/&gt; for a different message than the previously transmitted &lt;rtt/&gt; (i.e. the value of the <em><strong>id</strong></em> attribute changes, <em><strong>id</strong></em> becomes included, or <em><strong>id</strong></em> becomes not included). This keeps real-time text synchronized when beginning to edit a previously delivered message versus continuing to compose a new message.</p></li>
<li><p>The XEP-0301 and XEP-0308 protocols operate concurrently via separate message stanzas. Thus, a message stanza never simultaneously includes both &lt;rtt/&gt; and &lt;replace/&gt;.</p></li>
<li><p>The <link url="#body_element">Body Element</link> delivers a finished new message or a finished message correction (&lt;replace/&gt; is used with &lt;body/&gt; in accordance to XEP-0308).</p></li>
<li><p>For all &lt;rtt/&gt; elements transmitted during composing a new message, the '<link url="#id">id</link>' attribute of &lt;rtt/&gt; is not used.</p></li>
<li><p>For all &lt;rtt/&gt; elements transmitted during editing of the previous message, the 'id' attribute of &lt;rtt/&gt; matches the 'id' attribute of the old &lt;message/&gt; stanza containing the &lt;body/&gt; text being edited (see 'Business Rules' in <strong>XEP-0308</strong>). This enables recipient clients to display real-time text while the sender is editing the previously-delivered message.</p></li>
<li><p>Senders clients need to transmit a <link url="#message_refresh">Message Refresh</link> when transmitting &lt;rtt/&gt; for a different message than the previously transmitted &lt;rtt/&gt; (i.e., the value of the 'id' attribute changes, 'id' becomes included, or 'id' becomes not included). This keeps real-time text synchronized when beginning to edit a previously delivered message versus continuing to compose a new message.</p></li>
<li><p>The <strong>XEP-0301</strong> and <strong>XEP-0308</strong> protocols operate concurrently via separate message stanzas. Thus, a message stanza never simultaneously includes both &lt;rtt/&gt; and &lt;replace/&gt;.</p></li>
<li><p>The <link url="#body_element">Body Element</link> delivers a finished new message or a finished message correction (&lt;replace/&gt; is used with &lt;body/&gt; in accordance to <strong>XEP-0308</strong>).</p></li>
</ul>
</section3>
<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 specification makes it possible to seamlessly integrate real-time text into &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-to-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="#deactivating_realtime_text">Deactivating Real-Time Text</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 situations where there are multiple sessions from the same JID (i.e. simultaneous logins on multiple clients/devices), 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 multiple sessions under the same JID, <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_refresh">Message Refresh</link>, presumably from the active session. This provides a seamless system-switching experience. A good implementation of <link url="#message_refresh">Message Refresh</link> will improve user experience, regardless of whether or not the client follows &xep0296;. 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>
</section4>
</section3>
<section3 topic="Usage with Multi-User Chat" anchor="usage_with_multiuser_chat">
<p>For simplicity, clients can implement real-time text only for one-to-one chat, and not for <strong>Multi-User Chat</strong>. However, it can be appropriate to support &lt;rtt/&gt; elements in groupchat rooms, even if not all participants support real-time text, as long as the service allows it (See <link url="#support_for_groupchat">Support for Groupchat</link>).</p>
<p>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 groupchat receiving an incoming &lt;rtt <link url="#event">event</link>=’cancel’/&gt; needs to keep outgoing transmission unaffected during <link url="#deactivating_realtime_text">Deactivating Real-Time Text</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> for handling this situation. In situations of simultaneous typing by a large number of participants, see <link url="#congestion_considerations">Congestion Considerations</link>.</p>
</section3>
<section3 topic="Simultaneous Logins" anchor="simultaneous_logins">
<p>In situations where there are multiple sessions from the same JID (i.e., simultaneous logins on multiple clients/devices), 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 multiple sessions under the same JID, <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_refresh">Message Refresh</link>, presumably from the active session. This provides a seamless system-switching experience. A good implementation of <link url="#message_refresh">Message Refresh</link> will improve user experience, regardless of whether or not the client follows &xep0296;. 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="#usage_with_multiuser_chat">Usage with Multi-User Chat</link>, with the <link url="#stale_messages">Stale Messages</link> being timed-out.</p>
</section3>
<section3 topic="Stale Messages" anchor="stale_messages">
<p>There are situations where senders pause typing indefinitely. This can result in recipients displaying a real-time message for an extended time period. It may also be a screen clutter concern during <link url="#multiuser_chat">Multi-User Chat</link>. In addition, it may be a resource-consumption concern, as part of <link url="#congestion_considerations">Congestion Considerations</link>.</p>
<p>It is acceptable for recipients to clear (and/or save) incoming real-time messages that have been idle for an extended time period. There is no specific time-out period defined by this specification. For <link url="#multiuser_chat">Multi-User Chat</link>, the time-out period might be shorter because of the need to reduce screen clutter. For one-to-one chat sessions, the time-out period might need to be longer to allow reasonable interruptions (i.e. sender pausing during a long phone call or other interruption).</p>
<p>Senders that resume composing a message (i.e. continues a partially-composed message hours later) can do a <link url="#message_refresh">Message Refresh</link>, which allows recipients to redisplay the real-time message.</p>
<p>There are situations where senders pause typing indefinitely. This can result in recipients displaying a real-time message for an extended time period. It may also be a screen clutter concern during <link url="#usage_with_multiuser_chat">Usage with Multi-User Chat</link>. In addition, it may be a resource-consumption concern, as part of <link url="#congestion_considerations">Congestion Considerations</link>.</p>
<p>It is acceptable for recipients to clear (and/or save) incoming real-time messages that have been idle for an extended time period. There is no specific time-out period defined by this specification. For <link url="#usage_with_multiuser_chat">Usage with Multi-User Chat</link>, the time-out period might be shorter because of the need to reduce screen clutter. For one-to-one chat sessions, the time-out period might need to be longer to allow reasonable interruptions (i.e., sender pausing during a long phone call or other interruption).</p>
<p>Senders that resume composing a message (i.e., continues a partially-composed message hours later) can do a <link url="#message_refresh">Message Refresh</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 is more important on slower platforms. The real-time message might be implemented as a separate window or separate display element.</p>
@ -757,11 +766,11 @@
<p>The example above represents moderate typing speed during a normal <link url="#transmission_interval">Transmission Interval</link>, such as 700 milliseconds between &lt;message/&gt; stanzas for continuous typing. It illustrates the following:</p>
<p>The example above represents moderate typing speed during a normal <link url="#transmission_interval">Transmission Interval</link>, such as 700 milliseconds between &lt;message/&gt; stanzas for continuous typing. It illustrates the following <link url="#rtt_attributes">RTT Attributes</link>:</p>
<ul>
<li>The <em><link url="#event">event</link></em> attribute equals 'new' for the start of every new message.</li>
<li>The <em><link url="#seq">seq</link></em> attribute increments within the same message.</li>
<li>The <em><link url="#seq">seq</link></em> attribute randomizes when beginning a new message.</li>
<li>The 'event' attribute equals “new” for the start of every new message.</li>
<li>The 'seq' attribute increments within the same message.</li>
<li>The 'seq' attribute randomizes when beginning a new message.</li>
</ul>
</section2>
<section2 topic="Examples of Message Edits" anchor="examples_of_message_edits">
@ -989,43 +998,43 @@
</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 at Real-Time Text Taskforce (R3TF).</p>
<p>Implementers ought to choose the most appropriate real-time text approach for the session control technology in use during a particular session. For example, clients that use XMPP can utilize this XEP-0301 specification, and clients that use SIP might utilize IETF RFC 4103, <span class="ref"><strong><link url="http://tools.ietf.org/html/rfc5194">IETF RFC 5194</link></strong></span>
<note>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, might need to utilize multiple real-time text technologies. To interoperate between incompatible real-time text technologies, gateway servers can transcode between different real-time text technologies, along with other media such as audio and video. This can include TTY and textphones.</p>
<p>Implementers ought to choose the most appropriate real-time text approach for the session control technology in use during a particular session. For example, clients that use XMPP can utilize this <strong>XEP-0301</strong> specification, and clients that use SIP might utilize <strong>RFC 4103</strong>, <span class="ref"><strong><link url="http://tools.ietf.org/html/rfc5194">RFC 5194</link></strong></span>
<note>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 <strong>ITU-T T.140</strong>. Clients that run on multiple networks, might need to utilize multiple real-time text technologies. To interoperate between incompatible real-time text technologies, gateway servers can transcode between different real-time text technologies, along with other media such as audio and video. This can include TTY and textphones.</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 emergency services in some regions.</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. Guidance on address translation and conveyance between XMPP and SIP can be found at <span class="ref"><strong><link url="http://tools.ietf.org/html/draft-ietf-stox-core">IETF stox</link></strong></span>
<p>In the SIP environment, real-time text is specified in <strong>RFC 4103</strong> and <strong>ITU-T T.140</strong>. SIP is a popular real-time session control protocol, and there are many implementations of real-time text controlled by SIP. This includes emergency services in some regions.</p>
<p>Interoperability considerations include addressing translation, media negotiation and translation, and media transcoding. Transcoding is straightforward between this specification and <strong>T.140</strong> / <strong>RFC 4103</strong>, 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 <strong>T.140</strong> that consume time and bandwidth. <strong>T.140</strong> 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. Guidance on address translation and conveyance between XMPP and SIP can be found at <span class="ref"><strong><link url="http://tools.ietf.org/html/draft-ietf-stox-core">IETF stox</link></strong></span>
<note>Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Addresses and Error Conditions &lt;<link url=" http://tools.ietf.org/html/draft-ietf-stox-core">http://tools.ietf.org/html/draft-ietf-stox-core</link>&gt;.</note>.</p>
</section2>
<section2 topic="Total Conversation – Combination with Audio and Video" anchor="total_conversation_combination_with_audio_and_video">
<p>According to ITU-T Rec. F.703, the “Total Conversation” standard defines the simultaneous use of audio, video, and real-time text. For convenience, real-time communication applications can be designed to have automatic negotiation of as many as possible of the three media preferred by the users.</p>
<p>According to <strong>ITU-T Rec. F.703</strong>, the “Total Conversation” standard defines the simultaneous use of audio, video, and real-time text. For convenience, real-time communication applications can be designed to have automatic negotiation of as many as possible of the three media preferred by the users.</p>
<p>In the XMPP session environment, the Jingle protocol (&xep0166;) is available for negotiation and transport of the more time-critical, real-time audio and video media. Any combination of audio, video, and real-time text can be used together simultaneously.</p>
</section2>
</section1>
<section1 topic="Internationalization Considerations" anchor="internationalization_considerations">
<p>The primary internationalization consideration involves real-time message editing using <link url="#action_elements">Action Elements</link>, where text is inserted and deleted using position and length values. For this, <link url="#accurate_processing_of_action_elements">Accurate Processing of Action Elements</link> including correct <link url="#unicode_character_counting">Unicode Character Counting</link> will ensure that all possible valid Unicode text can be used via this protocol. This includes text containing multiple scripts/languages, ideographic symbols (e.g. Chinese), right-to-left text (e.g. Arabic), and bidirectional text.</p>
<p>The primary internationalization consideration involves real-time message editing using <link url="#action_elements">Action Elements</link>, where text is inserted and deleted using position and length values. For this, <link url="#accurate_processing_of_action_elements">Accurate Processing of Action Elements</link> including correct <link url="#unicode_character_counting">Unicode Character Counting</link> will ensure that all possible valid Unicode text can be used via this protocol. This includes text containing multiple scripts/languages, ideographic symbols (e.g., Chinese), right-to-left text (e.g., Arabic), and bidirectional text.</p>
<p>For accessibility considerations, there is an <span class="ref"><strong><link url="http://www.fasttext.org">International Symbol of Real-Time Text</link></strong></span>
<note>The International Symbol of Real-Time Text &lt;<link url="http://www.fasttext.org">http://www.fasttext.org</link>&gt;.</note> to alert users to the existence of this feature.</p>
</section1>
<section1 topic="Security Considerations" anchor="security_considerations">
<section2 topic="Privacy" anchor="privacy">
<p>It is important for users to be made aware of real-time text (e.g. user consent, software notice, introductory explanation). Users of real-time text need to be aware that their typing is now visible in real-time to everyone in the current chat conversation. There can be potential 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) and then sending the message. There can also be implications for chat clients that suddenly pop up a chat window upon incoming messages and takes keyboard focus unexpectedly, resulting in the sender typing sensitive information into the wrong window. These accidental privacy risks are also apparent for traditional chat (e.g. accidentally sending a message) but are more immediate for real-time text. With real-time message editing, recipients can watch all text changes that occur in the sender's text, before the sender finishes the message.</p>
<p>Such risks can be avoided by good user interface design. In addition, 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="#guidelines_for_initiating_realtime_text">Guidelines for Initiating Real-Time Text</link>, etc.</p>
<p>It is important for users to be made aware of real-time text (e.g., user consent, software notice, introductory explanation). Users of real-time text need to be aware that their typing is now visible in real-time to everyone in the current chat conversation. There can be potential 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) and then sending the message. There can also be implications for chat clients that suddenly pop up a chat window upon incoming messages and takes keyboard focus unexpectedly, resulting in the sender typing sensitive information into the wrong window. These accidental privacy risks are also apparent for traditional chat (e.g., accidentally sending a message) but are more immediate for real-time text. With real-time message editing, recipients can watch all text changes that occur in the sender's text, before the sender finishes the message.</p>
<p>Such risks can be avoided by good user interface design. In addition, 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="#guidelines_for_initiating_realtime_text">Guidelines for Initiating Real-Time Text</link>, etc.</p>
</section2>
<section2 topic="Encryption" anchor="encryption">
<p>Real-time text (&lt;rtt/&gt; elements) transmits the content contained within messages. Therefore, a client that encrypts &lt;body/&gt; also needs to encrypt &lt;rtt/&gt; as well:</p>
<ul>
<li><p>Encryption at the stream level (e.g. TLS) can be used normally with this specification. Stream-level encryption is the most common form of encryption.</p></li>
<li><p>Encryption at the &lt;message/&gt; stanza level (e.g. XEP-0200) can be used for all stanzas containing either &lt;rtt/&gt; or &lt;body/&gt;. It is noted that real-time text can have a higher rate of message stanzas, contributing to additional overhead. See <link url="#congestion_considerations">Congestion Considerations</link>.</p></li>
<li><p>Encryption at the &lt;body/&gt; level (e.g. deprecated XEP-0027) does not encrypt &lt;rtt/&gt;. In this case, &lt;rtt/&gt; needs to be encrypted separately. It is preferable to use a broader level of encryption, where possible.</p></li>
<li><p>Encryption at the stream level (e.g., TLS) can be used normally with this specification. Stream-level encryption is the most common form of encryption.</p></li>
<li><p>Encryption at the &lt;message/&gt; stanza level (e.g., XEP-0200) can be used for all stanzas containing either &lt;rtt/&gt; or &lt;body/&gt;. It is noted that real-time text can have a higher rate of message stanzas, contributing to additional overhead. See <link url="#congestion_considerations">Congestion Considerations</link>.</p></li>
<li><p>Encryption at the &lt;body/&gt; level (e.g., deprecated XEP-0027) does not encrypt &lt;rtt/&gt;. In this case, &lt;rtt/&gt; needs to be encrypted separately. It is preferable to use a broader level of encryption, where possible.</p></li>
</ul>
<p>It is possible for the timing of individual key presses to be used as a timing attack on encryption. Protection against this is provided by buffering of key presses into a regular <link url="#transmission_interval">Transmission Interval</link>. As an additional measure of security, the risk of timing attacks can be further mitigated by padding &lt;rtt/&gt; elements to lengths not clearly related to the number of characters in the message. Alternatively, general XMPP protection mechanisms hiding length information can be applied on the complete message exchange instead of (or in concert with) &lt;rtt/&gt; specific protection mechanisms.</p>
</section2>
<section2 topic="Congestion Considerations" anchor="congestion_considerations">
<p>The nature of real-time text can result in more frequent transmission of &lt;message/&gt; stanzas than would otherwise happen in a non-real-time text conversation. This can lead to increased network and server loading of XMPP networks.</p>
<p>Transmission of real-time text can be throttled temporarily during poor network conditions. It is appropriate to use latency monitoring mechanisms (e.g. &xep0184; or &xep0198;) in order to temporarily adjust the <link url="#transmission_interval">Transmission Interval</link> of real-time text beyond the recommended range. This results in lagged text (less real-time) but is better than failure during poor network conditions. The use of <link url="#message_refresh">Message Refresh</link> can also retransmit real-time text lost by poor network conditions, including stanzas dropped during a network issue or server error. These techniques are useful for mission-critical applications such as next generation emergency services (e.g. text to 9-1-1).</p>
<p>Excess numbers of real-time messages (e.g. during a Denial of Service (DoS) scenario in <link url="#multiuser_chat">Multi-User Chat</link>) might cause local resource-consumption issues, which can be mitigated by accelerated time-out of <link url="#stale_messages">Stale Messages</link>. Also see &xep0205;.</p>
<p>Transmission of real-time text can be throttled temporarily during poor network conditions. It is appropriate to use latency monitoring mechanisms (e.g., &xep0184; or &xep0198;) in order to temporarily adjust the <link url="#transmission_interval">Transmission Interval</link> of real-time text beyond the recommended range. This results in lagged text (less real-time) but is better than failure during poor network conditions. The use of <link url="#message_refresh">Message Refresh</link> can also retransmit real-time text lost by poor network conditions, including stanzas dropped during a network issue or server error. These techniques are useful for mission-critical applications such as next generation emergency services (e.g., text to 9-1-1).</p>
<p>Excess numbers of real-time messages (e.g., during a Denial of Service (DoS) scenario in <link url="#usage_with_multiuser_chat">Usage with Multi-User Chat</link>) might cause local resource-consumption issues, which can be mitigated by accelerated time-out of <link url="#stale_messages">Stale Messages</link>. Also see &xep0205;.</p>
<p>According to multiple university studies worldwide (including <span class="ref"><strong><link url="http://seattle.intel-research.net/~davraham/pubs/Avrahami_CSCW_06.pdf">Carnegie Mellon University Study</link></strong></span>
<note>Communication Characteristcs of Instant Messaging: Effects and Predictions of Interpersonal Relationships &lt;<link url="http://seattle.intel-research.net/~davraham/pubs/Avrahami_CSCW_06.pdf">http://seattle.intel-research.net/~davraham/pubs/Avrahami_CSCW_06.pdf</link>&gt;.</note>), the average length of instant messages is under 40 characters. The additional incremental bandwidth overhead of real-time text can be very low for an existing XMPP client, especially one already using many extensions. Bandwidth can also be further mitigated using stream compression, to benefit bandwidth-constrained networks (e.g. GPRS, 3G, satellite).</p>
<note>Communication Characteristcs of Instant Messaging: Effects and Predictions of Interpersonal Relationships &lt;<link url="http://seattle.intel-research.net/~davraham/pubs/Avrahami_CSCW_06.pdf">http://seattle.intel-research.net/~davraham/pubs/Avrahami_CSCW_06.pdf</link>&gt;.</note>), the average length of instant messages is under 40 characters. The additional incremental bandwidth overhead of real-time text can be very low for an existing XMPP client, especially one already using many extensions. Bandwidth can also be further mitigated using stream compression, to benefit bandwidth-constrained networks (e.g., GPRS, 3G, satellite).</p>
</section2>
</section1>
<section1 topic="IANA Considerations" anchor="iana_considerations">