0.0.3

inbox/realtimetext.xml

@@ -30,11 +30,17 @@
   <author>
     <firstname>Mark</firstname>
     <surname>Rejhon</surname>
-    <email>markybox@gmail.com</email>
+    <email>mark@realjabber.org</email>
     <jid>markybox@gmail.com</jid>
     <org>RealJabber.org and Rejhon Technologies Inc.</org>
     <uri>http://www.realjabber.com</uri>
   </author>
+  <revision>
+    <version>0.0.3</version>
+    <date>2011-06-24</date>
+    <initials>MDR</initials>
+    <remark><p>Third draft, minor edits.</p></remark>
+  </revision>
   <revision>
     <version>0.0.2</version>
     <date>2011-06-15</date>
@@ -82,7 +88,7 @@
     </section2>
     <section2 topic="In-Band Transmission" anchor="inband_transmission">
     <ol>
-      <li>Reliable message delivery.</li>
+      <li>Reliable real-time text delivery.</li>
       <li>Provide a high level XML mechanism of transmitting real-time text.</li>
       <li>Minimize reliance on knowledge of network transversal protocols and/or out-of-band transmission protocols.</li>
     </ol>
@@ -139,13 +145,14 @@
 
 
     <p>The &lt;rtt&gt; element contains a series of one or more child elements representing <em><strong>real-time actions</strong></em> including <em><strong>edit actions</strong></em> and/or <em><strong>presentation actions</strong></em>. Example 1 illustrates only a single edit action, the &lt;t&gt; <em><strong>action element</strong></em>, which simply adds text to the end of a message. For more information about action elements, see <link url="#realtime_actions">Real-Time Actions</link>.</p>
+    <p>If the recipient client does not support this real-time text standard, the sender SHOULD NOT transmit the &lt;rtt&gt; element. For more information, see <link url="#determining_support">Determining Support</link>.</p>
     </section2>
     <section2 topic="RTT Attributes" anchor="rtt_attributes">
         <section3 topic="xmlns" anchor="xmlns">
     <p>This REQUIRED attribute MUST be <strong>urn:xmpp:rtt:0</strong></p>
     </section3>
     <section3 topic="seq" anchor="seq">
-    <p>This REQUIRED attribute indicates the sequence number, and SHOULD begin at 0 in the first &lt;rtt&gt; element sent at the start of a <em><strong>real-time chat session</strong></em>. This attribute MUST increment by 1 for every &lt;rtt&gt; element sent until the end of the session. This value may be used by the receiver to detect lost &lt;message&gt; elements, which affects the integrity of real-time text. For more information, see <link url="#error_recovery_of_realtime_text">Error Recovery of Real-Time Text</link>.</p>
+    <p>This REQUIRED attribute indicates the sequence number, and MUST begin at 0 in the first &lt;rtt&gt; element sent at the start of a <em><strong>real-time chat session</strong></em>. This attribute MUST increment by 1 for every &lt;rtt&gt; element sent until the end of the session. This value may be used by the receiver to detect lost &lt;message&gt; elements, which affects the integrity of real-time text. For more information, see <link url="#error_recovery_of_realtime_text">Error Recovery of Real-Time Text</link>.</p>
     </section3>
     <section3 topic="event" anchor="event">
     <p>This attribute signals session events for real-time messages, such as the start of a new real-time message. The <strong>event</strong> attribute is omitted from the &lt;rtt&gt; element, when it is not needed.</p>
@@ -155,30 +162,28 @@
       <li><p><strong>event='reset'</strong><br />
         The sender MAY use this value to retransmit a real-time message. The recipient MUST clear the existing real-time message, before processing the &lt;rtt&gt; payload. One use case is for error recovery. Another use case is where the recipient logs off and on, all while the sender is still composing a message. This allows the recipient re-display the real-time message.</p></li>
       <li><p><strong>event='start'</strong><br />
-        The sender MAY use this value to indicate the start of a real-time session. This also signals the recipient that the sender supports real-time text. The &lt;rtt&gt; payload MUST be empty, with no real-time actions.</p></li>
+        The sender MAY use this value to indicate the start of a real-time session. The &lt;rtt&gt; payload MUST be empty, with no real-time actions.</p></li>
-      <li><p><strong>event='stop'</strong><br />
+      <li><p><strong>event='cancel'</strong><br />
         The sender MAY use this value to indicate the end of a real-time session. The recipient SHOULD clear or close the current real-time message, if any is still displayed. An example case is closing a chat window before a message is delivered. The &lt;rtt&gt; payload MUST be empty, with no real-time actions.</p></li>
     </ol>
-    <p>One event is allowed per &lt;rtt&gt; element. To transmit multiple events at once, use multiple consecutive &lt;message&gt;'s.</p>
+    <p>Only one &lt;rtt&gt; element is allowed per &lt;message&gt;. Therefore, to transmit multiple events, use multiple consecutive &lt;message&gt;'s.</p>
-    <p><em>Note: In subsequent versions of this spec, this attribute may be extended to cover real-time chat session negotiation (event='accept' / event='reject'), to provide a real-time text session initiation mechanism that is similar and familiar to users of other real-time instant messaging implementations, including AOL AIM's Real-Time IM.</em></p>
     </section3>
 </section2>
     <section2 topic="Body Element" anchor="body_element">
     <p>To turn a real-time message into a permanent delivered message, the sender MUST transmit the whole message as a standard &lt;body&gt; child element within the &lt;message&gt; stanza.</p>
         <section3 topic="Backwards Compatible" anchor="backwards_compatible">
-    <p>The &lt;body&gt; element complies with the &xmppcore; standard. This is backwards compatible with XMPP clients that do not support this specification. Such clients will continue to behave normally, displaying complete lines of messages as they are delivered.</p>
+    <p>The &lt;body&gt; element continues to follow the &xmppcore; standard. This keeps backwards compatibility with XMPP clients that do not support this specification. Such clients will continue to behave normally, displaying complete lines of messages as they are delivered.</p>
     </section3>
     <section3 topic="Behavior in Clients Supporting This Specification" anchor="behavior_in_clients_supporting_this_specification">
-    <p>Upon receipt of &lt;body&gt;, the recipient MUST replace any currently-displayed real-time message with the message text in &lt;body&gt;. This signals the recipient that the real-time message is finished, and is considered delivered. The message is made permanent and can not be edited any further.</p>
+    <p>Upon receipt of &lt;body&gt;, the recipient MUST replace the real-time message with the final delivered message from &lt;body&gt;. The message is thus becomes permanent and can not be edited any further.</p>
-    <p>In the ideal case, the message in a &lt;body&gt; is redundant since it simply repeats the entire contents of the real-time message. This provides error recovery, in the event that there are lost &lt;message&gt; elements that affect the integrity of the real-time message.</p>
+    <p>In the ideal case, the message in a &lt;body&gt; is redundant since it simply repeats the entire contents of the real-time message. In the event that there are lost &lt;messages&gt;, the delivery of the &lt;body&gt; permits <link url="#error_recovery_of_realtime_text">Error Recovery of Real-Time Text</link>.</p>
-    <p>After delivering a completed message as a &lt;body&gt;, the sender may create a new real-time message, using the <strong>event='new'</strong> attribute.</p>
+    <p>After sending a completed message as a &lt;body&gt;, the sender may begin a real-time message, using the <strong>event='new'</strong> attribute.</p>
     </section3>
 </section2>
     <section2 topic="Transmission Interval" anchor="transmission_interval">
     <p>For the best balance between interoperability and usability, the interval of transmission of &lt;rtt&gt; for a continuously-changing real-time message SHOULD be once every <strong>1 second</strong>. If there has been no changes to the real-time message, no transmission should take place.</p>
-    <p>A shorter interval may more frequently trigger the flooding protection algorithms in XMPP servers, leading to dropped &lt;message&gt; elements. A longer interval will lead to a less optimal user experience. One second is a balance that meets the requirements of real-time text. This interval is mentioned in other real-time text standards, including section 5.4 of IETF RFC 4103 and section 5.2.2 of <span class="ref"><strong><link url="http://tools.ietf.org/html/rfc5194">IETF RFC 5194</link></strong></span> <note>IETF RFC 5194: Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP). &lt;<link url="http://tools.ietf.org/html/rfc5194">http://tools.ietf.org/html/rfc5194</link>&gt;.</note>, used for SIP.</p>
+    <p>A much shorter interval may more frequently trigger the flooding protection algorithms in XMPP servers, leading to dropped &lt;message&gt; elements and/or <link url="#congestion_considerations">Congestion Considerations</link>. A longer interval will lead to a less optimal user experience. One second is a balance that meets the requirements of real-time text. This interval is mentioned in other real-time text standards, including section 5.4 of IETF RFC 4103 and section 5.2.2 of <span class="ref"><strong><link url="http://tools.ietf.org/html/rfc5194">IETF RFC 5194</link></strong></span> <note>IETF RFC 5194: Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP). &lt;<link url="http://tools.ietf.org/html/rfc5194">http://tools.ietf.org/html/rfc5194</link>&gt;.</note>, used for SIP.</p>
-    <p>For mission-critical applications, it is acceptable to use network monitoring mechanisms (i.e. &xep0184; and/or &xep0199;, etc.) to monitor reliability and latency, in order to temporarily adjust the interval to prevent failure of real-time text transmissions during extreme network conditions.</p>
+    <p>To smooth the output of text, this specification supports transmission of the sender's original <link url="#key_press_intervals">Key Press Intervals</link>. This allows the recipient software to display the sender's typing at the original speed, regardless of the transmission interval.</p>
-    <p>To smooth the output of text, this specification supports transmission of the sender's original <link url="#key_press_intervals">Key Press Intervals</link>. This allows the recipient software to display the sender's typing at the original speed, regardless of the transmission interval. For more information, see the next section <link url="#realtime_actions">Real-Time Actions</link>.</p>
     </section2>
     <section2 topic="Real-Time Actions" anchor="realtime_actions">
     <p>The &lt;rtt&gt; element is used to transmit a series of one or more real-time actions, including edit actions and presentation actions.</p>
@@ -189,8 +194,9 @@
       <li>Cursor movements, to make it easier for the recipient to watch edits being made by the sender;</li>
       <li>Visual flash (beep) to allow the sender to catch the attention of the recipient.</li>
     </ul>
-    <p>Each real-time action is represented by an <em><strong>action element</strong></em><em>.</em></p>
+    <p>Each real-time action is represented by an <em><strong>action element</strong></em><em>.</em> Examples can be found in <link url="#use_cases">Use Cases</link>.</p>
         <section3 topic="Summary of Action Elements" anchor="summary_of_action_elements">
+    <p>The following is a short summary. For more detailed information, see <link url="#action_elements">Action Elements</link>.</p>
         <section4 topic="Edit Actions (Tier 1)" anchor="edit_actions_tier_1">
         <table>
           <tr>
@@ -245,20 +251,25 @@
       <li>If the <em><strong>n</strong></em> attribute is omitted, the default value for <em><strong>n</strong></em> is 1.</li>
       <li>If the <em><strong>p</strong></em> attribute is omitted, the default value for <em><strong>p</strong></em> is the length of the current real-time message.</li>
       <li>A <em><strong>p</strong></em> value of 0 represents the start of the message.</li>
+      <li><em><strong>n</strong></em> and <em><strong>p</strong></em> values are counts of individual Unicode code points.</li>
     </ul>
-    <p>Note: <em><strong>n</strong></em> and <em><strong>p</strong></em> values assume lengths and indexes within the real-time message string before presentation processing. This is the original Unicode string before processing text replacements, emoticon graphics, text decorations, combining marks, Unicode normalization, multiple Unicode characters representing one displayable character, etc. In addition, <em><strong>n</strong></em> and <em><strong>p</strong></em> values are optimized for 16-bit Unicode. As a result, Characters U+10000 through U+10FFFF are counted as 2 each, because they return a string length of 2 in programming platforms that use 16-bit Unicode strings. For more information, see <link url="#internationalization_considerations">Internationalization Considerations</link>.</p>
+    <p>For interoperability of <em><strong>p</strong></em> and <em><strong>n</strong></em> values, processing MUST be done on the original Unicode real-time message. For both senders and receivers, this is the version of the Unicode message text without Unicode normalization, emoticon graphics images, display text formatting, processing of Unicode combining marks, etc. For recipients obtaining text from the &lt;t&gt; element, this is the Unicode text immediately after XML processing, and before any further processing. From the perspective of <em><strong>p</strong></em> and <em><strong>n</strong></em> values, a real-time message is treated as an editable array of Unicode code points.</p>
+    <p>Regardless of the original format of line breaks during XMPP transmission, line breaks are treated as a single code unit (LINE FEED U+000A) for the purposes of real-time message processing. Conversion of line breaks into a single U+000A character 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>, so a compliant XML processor already do this automatically, and already provide the correct original Unicode text for interoperability.</p>
+    <p><strong>NOTE WELL</strong>: Extreme care MUST be taken to correctly calculate n and p values based on Unicode code points, to avoid corruption of the real-time message during real-time editing. For more information, see <link url="#internationalization_considerations">Internationalization Considerations</link>.</p>
     </section4>
 </section3>
     <section3 topic="Action Elements" anchor="action_elements">
         <section4 topic="Element &lt;t&gt; – Insert Text" anchor="element_t_insert_text">
-    <p>(Tier 1) REQUIRED. Supports the transmission of key presses, text block inserts, and text being pasted. Any text permitted in the &lt;body&gt; element of a &lt;message&gt; may be used, subject to the rules in XMPP Core, which implies section 2.2 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>. Line breaks are treated as a single new line character (U+000A) that can be backspaced or deleted.</p>
+    <p>(Tier 1) REQUIRED. Supports the transmission of key presses, text block inserts, and text being pasted.<br />
+    <em>Note:</em> <em>Any text permitted in the &lt;body&gt; element of a &lt;message&gt; may be used, subject to the rules in XMPP Core. More examples can be found in <link url="#use_cases">Use Cases</link>.</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><code><![CDATA[<t>text</t>]]></code></p>
     <p>Appends specified <em><strong>text</strong></em> at the end of message. (<em><strong>p</strong></em> defaults to message length)</p>
     </section4>
     <section4 topic="Element &lt;e&gt; – Backspace" anchor="element_e_backspace">
-    <p>(Tier 1) REQUIRED. Supports the behavior of Backspace key presses.</p>
+    <p>(Tier 1) REQUIRED. Supports the behavior of Backspace key presses.<br />
+    <em>Note: Direction 'left' represents the numeric direction. Thus, for right-to-left text (i.e. Arabic), numeric 'left' represents visible 'right'.</em></p>
     <p><code><![CDATA[<e n='#' p='#'/>]]></code></p>
     <p>Remove <em><strong>n</strong></em> characters to the left of position <em><strong>p</strong></em> in message.</p>
     <p><code><![CDATA[<e p='#'/>]]></code></p>
@@ -269,7 +280,8 @@
     <p>Remove 1 character from end of message. (Both <em><strong>n</strong></em> and <em><strong>p</strong></em> at default values)</p>
     </section4>
     <section4 topic="Element &lt;d&gt; – Forward Delete" anchor="element_d_forward_delete">
-    <p>(Tier 1) REQUIRED. Supports the behavior of Delete key presses, text block deletes, and text being cut.</p>
+    <p>(Tier 1) REQUIRED. Supports the behavior of Delete key presses, text block deletes, and text being cut.<br />
+    <em>Note: Direction 'right' represents the numeric direction. Thus, for right-to-left text (i.e. Arabic), numeric 'right' represents visible 'left'.</em></p>
     <p><code><![CDATA[<d p='#' n='#'/>]]></code></p>
     <p>Remove <em><strong>n</strong></em> characters to the right of position <em><strong>p</strong></em> in message.</p>
     <p><code><![CDATA[<d p='#'/>]]></code></p>
@@ -278,7 +290,7 @@
     <section4 topic="Element &lt;w&gt; – Interval" anchor="element_w_interval">
     <p>(Tier 2) RECOMMENDED. Allows the transmission of the original intervals between real-time actions, including the pauses between key presses. For more information, see <link url="#key_press_intervals">Key Press Intervals</link>.</p>
     <p><code><![CDATA[<w n='#'/>]]></code></p>
-    <p>Executes a pause of <em><strong>n</strong></em> thousandths of a second.</p>
+    <p>Executes a pause of <em><strong>n</strong></em> thousandths of a second. The <em><strong>n</strong></em> value SHOULD NOT exceed the <link url="#transmission_interval">Transmission Interval</link>. Also, if a <link url="#body_element">Body Element</link> arrives, pauses SHOULD be interrupted to prevent message delivery delay.</p>
     </section4>
     <section4 topic="Element &lt;c&gt; – Cursor Position" anchor="element_c_cursor_position">
     <p>(Tier 2) OPTIONAL. Allows the transmission of cursor positions. This allows the recipient to see the sender's cursor in their real-time message, and makes it easier to track the sender's message edits. For more information, see <link url="#remote_cursor">Remote Cursor</link>.</p>
@@ -286,28 +298,29 @@
     <p>Moves cursor (caret) to the character position <em><strong>p</strong></em> in message.</p>
     </section4>
     <section4 topic="Element &lt;g&gt; – Flash" anchor="element_g_flash">
-    <p>(Tier 2) OPTIONAL. Allows a flash/beep/buzz feature. This supports real-time text interoperability with similar features in text telephones for the deaf (TTY / TDD), ITU-T T.140 implementations, and Control-G beep at terminals. In addition, this permits a feature similar to BlackBerry 'Ping', Windows Live 'Nudge', Yahoo 'Buzz', etc.</p>
+    <p>(Tier 2) OPTIONAL. Allows a flash/beep/buzz feature. This feature is the real-time version of &xep0224;, and MAY execute the same alerting method.<br />
+    <em>Note: This supports real-time text interoperability with similar features in text telephones for the deaf (TTY / TDD), ITU-T T.140 implementations, and Control-G beep at consoles.</em></p>
     <p><code><![CDATA[<g/>]]></code></p>
-    <p>Executes a brief visual flash, beep or buzz.</p>
+    <p>Executes a brief flash, sound, vibration, etc.</p>
     </section4>
 </section3>
     <section3 topic="Processing Rules" anchor="processing_rules">
     <ul>
       <li>There MUST not be more than one &lt;rtt&gt; child element per &lt;message&gt;.</li>
-      <li>The &lt;rtt&gt; element MAY be empty, or contain one or more action elements.</li>
+      <li>The &lt;rtt&gt; element MAY be an empty element, or contain one or more action elements.</li>
       <li>Action elements MUST be immediate children of &lt;rtt&gt;. Nesting is not allowed.</li>
-      <li>Support of Tier 1 edit actions is REQUIRED.</li>
+      <li>Support of all Tier 1 edit actions is REQUIRED.</li>
-      <li>Support of Tier 2 presentation actions is RECOMMENDED.</li>
       <li>Tier 2 presentation actions MUST NOT affect the contents of the real-time message string.</li>
+      <li>Excess Backspaces and Forward Deletes beyond start/end of the message, MUST be ignored.</li>
       <li>Recipients MUST process supported action elements in the same order as received within the &lt;rtt&gt; element. Unrecognized action elements MUST be ignored.</li>
-      <li>Real-time actions only work within the boundaries of the current real-time message, and MUST NOT affect previous messages.</li>
+      <li>Real-time actions work only within the boundaries of the current real-time message, and MUST NOT affect previous messages.</li>
-      <li>Real-time actions MUST be processed on the original unmodified real-time message string, before it is formatted for display (i.e. word wrap line breaks, emotion graphics, text decorations, etc).</li>
+      <li>Values for <em><strong>p</strong></em> and <em><strong>n</strong></em> attributes MUST be calculated according to <link url="#rules_for_attribute_values">Rules for Attribute Values</link>.</li>
     </ul>
     </section3>
 </section2>
     <section2 topic="Error Recovery of Real-Time Text" anchor="error_recovery_of_realtime_text">
     <p>In a real-time chat session, it is critical that the real-time message is identical on both the sender and recipient ends. The loss of a single &lt;rtt&gt; transmission can represent missing text, or a missing edit. This leads to the real-time message getting out of sync, the message becoming different on the sender versus the recipient ends.</p>
-    <p>Transmissions of &lt;message&gt; elements may be lost for several reasons. One reason is that a recipients may disconnect and reconnect while a sender is still typing a message. Another reason is some XMPP servers may drop &lt;message&gt; elements automatically (i.e. flooding protection).</p>
+    <p>Transmissions of &lt;message&gt; elements may be lost for several reasons. One reason is that a recipient may disconnect and reconnect while a sender is still typing a message. Another reason is some XMPP servers may drop &lt;message&gt; elements automatically (i.e. flooding protection).</p>
         <section3 topic="Staying In Sync" anchor="staying_in_sync">
     <p>To stay synchronized:</p>
     <ol>
@@ -317,11 +330,10 @@
     </ol>
     </section3>
     <section3 topic="Detecting Loss of Sync" anchor="detecting_loss_of_sync">
-    <p>The sync is considered lost if the <strong>seq</strong> attribute of &lt;rtt&gt; element does not increment as expected. When this happens:</p>
+    <p>The sync is considered lost if the <strong>seq</strong> attribute of the &lt;rtt&gt; element does not increment as expected. Trying to process certain real-time edit actions after loss of sync, will result in scrambled text. Therefore, to avoid this situation:</p>
     <ol>
-      <li>The recipient MUST stop processing all subsequent real-time action elements.</li>
+      <li>The recipient MUST stop processing all subsequent real-time action elements, and freeze the current real-time message.</li>
-      <li>The recipient MUST freeze the current real-time message in its present state.</li>
+      <li>An indicator (i.e. reception bars, color code, missing text indicator) or a chat state message (i.e. “Typing Frozen...”) MAY be used by the recipient to indicate the loss of sync.</li>
-      <li>An indicator (reception bars, color code, missing text indicator) or a message (“Typing Frozen...”) MAY be used by the recipient to indicate the loss of sync.</li>
     </ol>
     </section3>
     <section3 topic="Recovery From Loss of Sync" anchor="recovery_from_loss_of_sync">
@@ -339,43 +351,68 @@
     </section3>
 </section2>
 </section1>
+    <section1 topic="Determining Support" anchor="determining_support">
+    <p>If a client supports the Real Time Text protocol, it MUST advertise that fact in its responses via &xep0030; information ("disco#info") requests 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'
+    to='juliet@capulet.lit/balcony'
+    type='get'>
+  <query xmlns='http://jabber.org/protocol/disco#info'/>
+</iq>
+
+]]></code></p>
+    <p><strong>Example 2. A disco#info response</strong></p>
+    <p><code><![CDATA[<iq from='juliet@capulet.lit/balcony'
+    id='disco1'
+    to='romeo@montague.lit/orchard'
+    type='result'>
+  <query xmlns='http://jabber.org/protocol/disco#info'>
+    <feature var='urn:xmpp:rtt:0'/>
+  </query>
+</iq>
+
+]]></code></p>
+    <p>If this successful response of <strong>&lt;feature var='urn:xmpp:rtt:0'/&gt;</strong> is not received, the client SHOULD NOT transmit any outgoing &lt;rtt&gt; elements in &lt;message&gt; transmissions. This avoids unnecessary consumption of bandwidth to clients that do not support this protocol.</p>
+    </section1>
     <section1 topic="Implementation Notes" anchor="implementation_notes">
         <section2 topic="Key Press Intervals" anchor="key_press_intervals">
         <section3 topic="Avoid Bursty Text Presentation" anchor="avoid_bursty_text_presentation">
-    <p>To prevent flooding the public XMPP network, transmissions of messages containing real-time text is rate-limited to the recommended &lt;rtt&gt; message transmission interval, normally 1 second in <link url="#transmission_interval">Transmission Interval</link>. If the display of text is not smoothed, text will appear in intermittent bursts. This hurts usability of real-time text, and is NOT RECOMMENDED.</p>
+    <p>To prevent flooding the public XMPP network, transmissions of messages containing real-time text is rate-limited to the recommended &lt;rtt&gt; message transmission interval, usually 1 second according to <link url="#transmission_interval">Transmission Interval</link>. If the display of text is not smoothed, text will appear in intermittent bursts. This hurts usability of real-time text.</p>
     </section3>
     <section3 topic="Preserving Key Press Intervals" anchor="preserving_key_press_intervals">
     <p>Through the use of the RECOMMENDED <link url="#element_w_interval">Element &lt;w&gt; – Interval</link>, the original look-and-feel of typing can be preserved, despite the long transmission interval. Using the &lt;w&gt; element, the sender can record multiple key presses including key press intervals, and transmit them over the XMPP network in a single &lt;message&gt;. The recipient can then play back the sender's typing in real-time at original typing speed including the intervals between key presses. The text is displayed exactly as it was typed.</p>
     <p>Much like VoIP is a packetization of sound, this spec enables packetization of typing including the original key press intervals. This enables the real-time feel of typing over virtually any Internet connection, and without requiring shorter transmission intervals. Look and feel of typing is also preserved over polled XMPP including &xep0206;, as well as over satellite and long international connections with heavy packet-bursting tendencies and variable latencies.</p>
     <p>The recipient can watch the sender fluidly compose/edit their message in real-time without any “bursting” effects. This is “Natural Typing”, and appears indistinguishable from local typing. Since all key press intervals are preserved at a high precision, all subtleties of typing are preserved, including the 'mood' (calm typing versus panicked or emphatic typing, etc).</p>
+    <p>For an example transmission of key intervals, see <link url="#real_world_message_with_key_press_intervals">Real World Message With Key Press Intervals</link>.</p>
     </section3>
 </section2>
     <section2 topic="Real-time Transmission" anchor="realtime_transmission">
         <section3 topic="Monitoring Message Edits" anchor="monitoring_message_edits">
     <p>For sending clients, there are several methods of capturing typing and message edits, in order to generate action elements for an &lt;rtt&gt; transmission. The most reliable and practical method is to monitor the <strong>text change event</strong> of a text box field (rather than monitoring key press events) since:</p>
     <ul>
-      <li><p>it captures all typing, including edits and deletes.</p></li>
+      <li>it captures all typing, including edits and deletes.</li>
-      <li><p>it captures cut &amp; paste operations, as well as edits made via a pointing device.</p></li>
+      <li>it captures cut &amp; paste operations, as well as edits made via a pointing device.</li>
-      <li><p>it captures automatic text changes, such as done by spell checker, macros, assistive devices, etc.</p></li>
+      <li>it captures automatic text changes, such as done by spell checker, macros, assistive devices, etc.</li>
-      <li><p>it captures accented characters, Chinese, Arabic and other characters that require multiple key presses to compose. For more information, see <link url="#internationalization_considerations">Internationalization Considerations</link>.</p></li>
+      <li>it captures accented characters, Chinese, Arabic and other characters that require multiple key presses to compose.</li>
-      <li><p>it makes no assumptions about different keyboards or input entry methods.</p></li>
+      <li>it makes no assumptions about different keyboards or input entry methods.</li>
-      <li><p>text change events are more cross-platform portable, including on mobile phones.</p></li>
+      <li>text change events are more cross-platform portable, including on mobile phones.</li>
     </ul>
-    <p>In the text change event, the current message string can be compared to the previous message string in order to calculate what text changes took place. The appropriate action elements are then generated, to represent text insertions and deletions. The key press interval can be measured as the time elapsed in milliseconds between text change events.</p>
+    <p>In the text change event, the current message string can be compared to the previous message string in order to calculate what text changes took place. For more information, see <link url="#rules_for_attribute_values">Rules for Attribute Values</link>. The appropriate action elements are then generated, to represent text insertions and deletions. The key press interval can be measured as the time elapsed in milliseconds between text change events.</p>
     </section3>
     <section3 topic="Guidelines for Senders" anchor="guidelines_for_senders">
     <ul>
-      <li><p>Monitor typing via the technique in <link url="#monitoring_message_edits">Monitoring Message Edits</link> to generate action elements, and add these action elements to a buffer. This is equivalent to recording a sequence of typing.</p></li>
+      <li><p>Monitor typing via the technique in <link url="#monitoring_message_edits">Monitoring Message Edits</link> to generate action elements, and add these action elements to a buffer. This is equivalent to recording a small sequence of typing.</p></li>
-      <li><p>During every transmission interval (1 second), all buffered action elements are transmitted in &lt;rtt&gt; element of a &lt;message&gt;. This is equivalent to transmitting a 1 second sequence of typing at a time.</p></li>
+      <li><p>During every <link url="#transmission_interval">Transmission Interval</link>, all buffered action elements are transmitted in &lt;rtt&gt; element of a &lt;message&gt;. This is equivalent to transmitting a small sequence of typing at a time.</p></li>
-      <li><p>If there are no changes to the real-time message, no unnecessary &lt;rtt&gt; transmission should take place.</p></li>
+      <li><p>If there are no changes to the real-time message, and no cursor movements, no unnecessary &lt;rtt&gt; transmission takes place.</p></li>
     </ul>
     </section3>
     <section3 topic="Guidelines for Receivers" anchor="guidelines_for_receivers">
     <ul>
-      <li><p>Upon receipt of a &lt;message&gt; containing an &lt;rtt&gt; element, the action elements in &lt;rtt&gt; should be added to a playback queue, in the order that they are received. This provides immunity to variable network conditions, since the buffering action smooths out the latency fluctuations of &lt;message&gt; delivery.</p></li>
+      <li><p>Upon receipt of a &lt;message&gt; containing an &lt;rtt&gt; element, the action elements in &lt;rtt&gt; should be added to a queue, in the order that they are received. This provides immunity to variable network conditions, since the buffering action smooths out the latency fluctuations of &lt;message&gt; delivery.</p></li>
-      <li><p>The recipient software should interpret the action elements in the playback queue in sequential order, including &lt;w&gt; elements (intervals). This is equivalent to playing back the sender's original typing, including key press intervals.</p></li>
+      <li><p>The recipient software should interpret the action elements in the playback queue in sequential order, including &lt;w&gt; elements (intervals), into a real-time message. This is equivalent to playing back the sender's original typing, including key press intervals.</p></li>
-      <li><p>Processing of intervals (&lt;w&gt; elements) should be accomplished using non-blocking programming techniques such as timers or multi-threaded programming, to ensure full responsiveness of the client user interface.</p></li>
+      <li><p>Processing of intervals (&lt;w&gt; elements) SHOULD be done via non-blocking programming techniques.</p></li>
-      <li><p>Upon receiving a &lt;message&gt; containing &lt;body&gt; indicating a completed message, processing of action elements should discontinue immediately &amp; the full message displayed immediately. This ensures final message delivery is not delayed by late processing of action elements. In some cases, this may cause typing to "suddenly catch up".</p></li>
+      <li><p>Upon receiving a &lt;message&gt; containing &lt;body&gt; indicating a completed message, the full message SHOULD be displayed immediately in place of the real-time message, and unprocessed action elements cleared from the playback queue. This ensures final message delivery is not delayed by late processing of action elements.</p></li>
       <li><p>If support for the &lt;w&gt; element is not possible, receiving software SHOULD use an alternate text-smoothing method, such as time-smoothed progressive output of received text.</p></li>
     </ul>
     </section3>
@@ -403,7 +440,8 @@
     <section2 topic="Other Guidelines" anchor="other_guidelines">
     <p><link name="_Hlk168620696"></link>There are other special basic considerations for real-time message transmissions that need to be considered by implementors.</p>
         <section3 topic="Message Length Limit" anchor="message_length_limit">
-    <p>A large sequence of rapid message changes may generate a large series of action elements in a &lt;rtt&gt; element that exceed the maximum allowed length of a &lt;message&gt; stanza, usually 8 kilobytes. It is acceptable to instead retransmit the whole real-time message using &lt;rtt event='reset'&gt; if the length of the &lt;rtt&gt; element exceeds half this limit. For long messages, the final &lt;rtt&gt; transmission may be made in a separate &lt;message&gt; stanza as the &lt;message&gt; stanza containing the &lt;body&gt;. For example:</p>
+    <p>A large sequence of rapid message changes may generate a large series of action elements in an &lt;rtt&gt; element, resulting in the &lt;message&gt; exceeding the XMPP server's maximum allowed length of a &lt;message&gt; stanza. This may result in dropped messages. It is acceptable to simply retransmit the whole real-time message using &lt;rtt event='reset'&gt; if the length of the &lt;rtt&gt; element would otherwise exceed the application's maximum chat message length. The process of retransmitting the whole real-time message, has the disadvantage of discarding <link url="#key_press_intervals">Key Press Intervals</link> for one &lt;rtt&gt; element.</p>
+    <p>For long messages, the final &lt;rtt&gt; transmission may be made in a separate &lt;message&gt; than the &lt;message&gt; containing the &lt;body&gt;. For example:</p>
     <p><code><![CDATA[<message to='alice@example.com' from='bob@example.com/home' type='chat' id='dda'>
   <rtt xmlns='urn:xmpp:rtt:0' seq='95'>
     <t>Hello World...In a Super Long Message! [etc]</t>
@@ -429,12 +467,12 @@
     <p>The user interface display of the real-time text output, is usually the main performance bottleneck. Care should be taken not to do inefficient entire-screen repainting during every single key press, since fast typists may type over 10 key presses per second. This is especially important for slower platforms. To improve performance, the display of real-time messages may need to be implemented as a separate display element, rather than as a string concatenated to the current message history, so that the display can efficiently be refreshed every key press.</p>
     </section3>
     <section3 topic="Battery Life" anchor="battery_life">
-    <p>Battery life considerations are closely related to Performance. The addition of real-time text to a mobile device, will typically significantly impact battery life due mostly to more frequent screen refreshes. The specific implementation of interval action elements (play back of key press intervals) may play a factor, and this should be programmed efficiently. Also, in cases where screen updates are the primary inefficient bottleneck on a specific mobile device, and the code cannot be sufficiently optimized, the number of repaints per second may need to be throttled in order to prolong battery life, at the slight expense of the look-and-feel of typing transmissions.</p>
+    <p>Battery life considerations are closely related to Performance. The addition of real-time text to a mobile device, will typically significantly impact battery life due mostly to more frequent screen refreshes. The specific implementation of interval action elements (play back of key press intervals) may play a factor, and this should be programmed efficiently. Also, in cases where screen updates are the primary inefficient bottleneck on a specific mobile device, and the code cannot be sufficiently optimized, the number of repaints per second may need to be throttled in order to prolong battery life, at the slight expense of the look-and-feel of typing transmissions. Also see &xep0286;.</p>
     </section3>
 </section2>
 </section1>
     <section1 topic="Use Cases" anchor="use_cases">
-    <p>For simplicity, all use cases exclude the RECOMMENDED <link url="#key_press_intervals">Key Press Intervals</link> except for the last Use Case.</p>
+    <p>The first examples are deliberately kept simple instead of real-world, and are designed to educate in a progressively more difficult manner. For simplicity, most examples do not include the RECOMMENDED <link url="#key_press_intervals">Key Press Intervals</link> except for the last Use Case example. For real-world communications in software implementations supporting key press intervals, most transmissions will tend to resemble the last Use Case example, <link url="#real_world_message_with_key_press_intervals">Real World Message With Key Press Intervals</link>.</p>
         <section2 topic="Three Backspaces" anchor="three_backspaces">
     <p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' id='a01' type='chat'>
   <rtt xmlns='urn:xmpp:rtt:0' seq='0' event='new'>
@@ -474,7 +512,7 @@
 
 <message to='bob@example.com' from='alice@example.com/home' type='chat' id='c03'>
   <rtt xmlns='urn:xmpp:rtt:0' seq='2'>
-    <t><e n='3'/></t>
+    <e n='3'/>
   </rtt>
 </message>
 
@@ -596,10 +634,10 @@
             <td>12</td>
           </tr>
           <tr>
-            <td>&lt;c&nbsp;p='0'/&gt;</td>
+            <td>&lt;c&nbsp;p='18'/&gt;</td>
-            <td>Move&nbsp;cursor&nbsp;to&nbsp;beginning</td>
+            <td>Move&nbsp;cursor&nbsp;to&nbsp;end</td>
             <td>Hello&nbsp;there,&nbsp;World</td>
-            <td>0</td>
+            <td>18</td>
           </tr>
         </table>
     <p>Normally, the action elements are split into multiple separate transmissions, with <link url="#key_press_intervals">Key Press Intervals</link> added.</p>
@@ -663,7 +701,14 @@
     </ul>
     </section2>
     <section2 topic="Real World Message With Key Press Intervals" anchor="real_world_message_with_key_press_intervals">
-    <p>This is an example transmission of “Hello there!” with <link url="#key_press_intervals">Key Press Intervals</link>. The message writing sequence is as follows: The misspelled phrase “Hello tehre!” is typed, then cursor movements back to the typo, then two backspaces to delete the typo, and then two key presses to fix the typo. In between each key press, is <link url="#element_w_interval">Element &lt;w&gt; – Interval</link> to allow the receiving client execute a small pause between action elements, which allows the play back of the typing at its original look-and-feel.</p>
+    <p>This is the most important example. It is a transmission of “Hello there!” with <link url="#key_press_intervals">Key Press Intervals</link>. It illustrates a four-second typing sequence:</p>
+    <ul>
+      <li>The misspelled phrase “Hello tehre!” is typed;</li>
+      <li>Three cursor-left movements back to the mis-typed letters;</li>
+      <li>Two backspaces to delete the two mis-typed letters;</li>
+      <li>Two correct key presses to correctly spell the word “there”.</li>
+    </ul>
+    <p>In between each key press, is <link url="#element_w_interval">Element &lt;w&gt; – Interval</link> to allow the receiving client execute a small pause between action elements, which allows the play back of the typing at its original look-and-feel.</p>
     <p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
   <rtt xmlns='urn:xmpp:rtt:0' seq='0' event='new'>
     <t>H</t>
@@ -716,12 +761,17 @@
     
 
 
-    <p>This example also illustrates the following:</p>
+    <p>This real-world example also illustrate the following:</p>
     <ul>
-      <li>The sum of all the <em><strong>n</strong></em> attributes of &lt;w&gt; elements in one &lt;message&gt; equal a total of 1000 milliseconds. This represent the default <link url="#transmission_interval">Transmission Interval</link> of one &lt;message&gt; element transmitted every 1 second during periods of continuous typing.</li>
+      <li>Typing is done via <link url="#element_t_insert_text">Element &lt;t&gt; – Insert Text</link>.</li>
+      <li>Cursor movements are done via <link url="#element_c_cursor_position">Element &lt;c&gt; – Cursor Position</link>.</li>
+      <li>Backspaces are done via <link url="#element_e_backspace">Element &lt;e&gt; – Backspace</link>.</li>
+      <li>Intervals between key presses are done via <link url="#element_w_interval">Element &lt;w&gt; – Interval</link>.</li>
+      <li>Each &lt;message&gt; is delivered every one second, the default <link url="#transmission_interval">Transmission Interval</link>.</li>
+      <li>To achieve the smoothest playback of typing, the total sum of all values in &lt;w&gt; elements in one &lt;message&gt; equal the <link url="#transmission_interval">Transmission Interval</link> during periods of continuous typing.</li>
       <li>Some &lt;w&gt; interval elements are split between consecutive messages, since key presses are not timed with transmission intervals.</li>
       <li>The &lt;w&gt; interval elements also apply to cursor movements of the <link url="#remote_cursor">Remote Cursor</link>.</li>
-      <li>There is a final transmission with a &lt;body&gt; element, transmitted immediately when the message is finished.</li>
+      <li>There is a final transmission with a <link url="#body_element">Body Element</link>, transmitted immediately when the message is finished.</li>
       <li>These action elements are generated automatically via <link url="#monitoring_message_edits">Monitoring Message Edits</link>.</li>
     </ul>
     </section2>
@@ -730,33 +780,40 @@
     <p>There are other real-time text formats with interoperability considerations relating to the session setup level, the media transport level, and presentation level. For each environment where interoperability is supported, an interoperability specification should be documented that covers addressing, session control, media negotiation and media transcoding.</p>
         <section2 topic="RFC 4103 and T.140" anchor="rfc_4103_and_t140">
     <p>One environment for such interoperability considerations is SIP with real-time text (also called Text over IP, or ToIP) as specified in ITU-T T.140 and IETF RFC 4103. One reason for its importance is that this protocol combination is specified by IETF and by regional emergency service organizations to be the protocols supported for IP based real-time emergency calls that support real-time text. Another reason is that SIP is the currently dominating peering protocol between services, and many implementations of real-time text in SIP exist.</p>
-    <p>Interoperability implies addressing translation, media negotiation and translation, and media transcoding. For media transcoding between this specification and T.140/RFC 4103, the real-time text transcoding is straight forward, except the editing feature of this specification. Backwards positioning and insertion or deletion far back in the message can cause a large number of erase operations in T.140, that takes time and bandwidth to convey. Therefore, it is proposed that the scope of editing can be limited by negotiation to only allow backspacing when connecting to a system that only T.140 real-time message editing capabilities.</p>
+    <p>Interoperability implies addressing translation, media negotiation and translation, and media transcoding. For media transcoding between this specification and T.140/RFC 4103, the real-time text transcoding is straight forward, except the editing feature of this specification. Backwards positioning and insertion or deletion far back in the message can cause a large number of erase operations in T.140, that takes time and bandwidth to convey.</p>
     <p>It should be noted that T.140 specifies use of ISO 6429 control codes for presentation characteristics such as text color etc, that are not possible to represent in plain text according to this specification. All control codes from both sides that cannot be presented on the other side of the conversion, must be filtered off in order to not disturb the presentation of text.</p>
-    <p>Note that a future version of this specification may support real-time text with XHTML-IM. It is possible to transcode many of these ISO 6429 formatting codes to &xep0071;.</p>
+    <p>Note that a future version of this specification may support real-time transmission of XHTML-IM formatting, in order to support transcoding of ISO 6429 formatting codes.</p>
     </section2>
     <section2 topic="Combination With Other Real-Time Media" anchor="combination_with_other_realtime_media">
     <p>In some cases, it may be beneficial in a real-time conversation situation to have simultaneous availability of multiple real-time media.</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. For clients that already support audio and/or video, it is RECOMMENDED to continue providing real-time text according to this specification, regardless of whether audio and/or video is negotiated.</p>
-    <p>It is noted there is also another real-time text standard (RFC 4103, RFC 5194), used for SIP messaging and real-time text. In the situation where an implementor needs to decide which real-time text standard to use, it is generally recommended to use the real-time text extension of the specific instant messaging standard in use for that particular conversation. This varies from implementation to implementation. For example, Google Talk network uses XMPP messaging for instant messages sent during audio/video conversations. Therefore, in this situation, it is recommended to use this XMPP extension document to add real-time text functionality. However, there are other situations where it is necessary to support multiple real-time-text standards, and to interoperate between the multiple real-time text standards. For more information, see the next section.</p>
+    <p>It is noted there is also another real-time text standard (RFC 4103, RFC 5194), used for SIP sessions with real-time text. In the situation where an implementor needs to decide which real-time text standard to use, it is generally recommended to use the real-time text specification of the specific session control standard in use for that particular session. This varies from implementation to implementation. For example, Google Talk network uses XMPP messaging for instant messages sent during audio/video conversations. Therefore, in this situation, it is recommended to use this XMPP extension document to add real-time text functionality. However, there are other situations where it is necessary to support multiple real-time-text standards, and to interoperate between the multiple real-time text standards. For more information, see the next section.</p>
         <section3 topic="Total Conversation" anchor="total_conversation">
     <p>According to <span class="ref"><strong><link url="http://www.itu.int/rec/T-REC-F.703">ITU-T F.703</link></strong></span> <note>ITU-T 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" defines the simultaneous use of audio, video, and real-time text. For convenience, some chat applications may be designed to have automatic negotiation of as many as possible of the three media preferred by the users.</p>
     </section3>
 </section2>
 </section1>
     <section1 topic="Internationalization Considerations" anchor="internationalization_considerations">
-    <p>There are special internationalization considerations involving real-time editing of international text, due to the character positioning and length values used by <link url="#action_elements">Action Elements</link>, in the form of <em><strong>p</strong></em> and <em><strong>n</strong></em> attributes. There are multiple different ways to calculate lengths and indexes into a Unicode string, because multiple Unicode encoding formats exist. This is also further complicated by the use of combining characters and surrogate pairs, with the use of multiple Unicode code points to represent one displayable Unicode character.</p>
+    <p>There are special internationalization considerations involving real-time editing of international text, due to the character positioning and length values used by <link url="#action_elements">Action Elements</link>, in the form of <em><strong>p</strong></em> and <em><strong>n</strong></em> attributes. Different programming platforms use different internal Unicode encodings, which may be different from the transmission encoding (UTF-8) for XMPP. To achieve universally correct calculations for <em><strong>p</strong></em> and <em><strong>n</strong></em> attributes, consider these factors:</p>
-    <p>The indexing standard for positions and lengths is defined based on 16-bit Unicode string variables. For simplicity and performance, most programming languages treat Unicode strings as an array of 16-bit elements. If real-time messages are processed in an a Unicode encoding other than 16-bit, extra care must be taken to calculate <em><strong>p</strong></em> and <em><strong>n</strong></em> attributes correctly:</p>
     <ul>
-      <li><p>Count 1 each for characters U+0000 through U+FFFF.</p></li>
+      <li><p>Multiple Unicode code points may represent one displayable Unicode character (i.e. combining marks).<br />
-      <li><p>Count 2 each for characters U+10000 through U+10FFFF.<br /><em>These characters are represented as a pair of surrogate characters within 16-bit Unicode strings.</em></p></li>
+        <em>Action elements operate on Unicode code points</em><em>, not on displayable characters.</em></p></li>
+      <li><p>Characters U+10000 through U+1FFFF, which are single code points, but are represented as multiple surrogate code units in certain Unicode encodings (i.e. UTF-16).<br />
+        <em>Action elements operate on</em> <em>Unicode</em> <em>code points, not on individual surrogate code units.</em></p></li>
+      <li><p>Some Unicode encodings use a variable number of bytes per Unicode code point (i.e. UTF-8).<br /><em>Action elements operate on Unicode code points, not on individual bytes.</em></p></li>
     </ul>
-    <p>The supported Unicode character range is limited to characters allowable in XMPP Core, which implies section 2.2 of the XML standard.</p>
+    <p>Failure to correctly calculate <em><strong>p</strong></em> and <em><strong>n</strong></em> values by counting individual Unicode code points, will result in interoperability problems in the form of scrambled text during real-time editing. In some cases, this problem do not become visible until a chat session occurs in a different international language for the first time. It is critical to follow <link url="#rules_for_attribute_values">Rules for Attribute Values</link> in order to maintain world-wide interoperability of international text.</p>
     </section1>
     <section1 topic="Security Considerations" anchor="security_considerations">
-    <p>The security considerations are mainly user interface related, which varies in implementation from client to client:</p>
+        <section2 topic="Privacy" anchor="privacy">
-    <p>It is important for implementors of real-time text to educate users about real-time text. Users of real-time text should be aware that their typing in the local input buffer is now visible to everyone in the current chat conversation. This may have security implications if users copy &amp; paste private information into their chat entry buffer (i.e. a shopping invoice) before editing out the private parts of the pasted text (i.e. a credit card number) before they hit Enter or click Send. With real-time editing, recipients can watch all text changes that occur in the sender's text.</p>
+    <p>It is important for implementors of real-time text to educate users about real-time text. Users of real-time text should be aware that their typing in the local input buffer is now visible to everyone in the current chat conversation. This may have security implications if users copy &amp; paste private information into their chat entry buffer (i.e. a shopping invoice) before editing out the private parts of the pasted text (i.e. a credit card number) before they send the message. With real-time editing, recipients can watch all text changes that occur in the sender's text, before the sender sends the final message.</p>
-    <p>Concern shall be taken so that the network and server load of XMPP based real-time text is not excessive to the degree that it causes congestion, and a potential denial-of-service situation.</p>
+    </section2>
-    </section1>
+    <section2 topic="Congestion Considerations" anchor="congestion_considerations">
+    <p>The nature of real-time text result in more frequent transmission of &lt;message&gt; elements than may otherwise happen in a non-real-time text conversation. This may lead to increased network and server loading of XMPP networks. Care SHOULD to be taken to use a reasonable <link url="#transmission_interval">Transmission Interval</link>, and avoid transmitting messages at an excessive rate, to avoid creating unnecessary congestion on public XMPP networks. Also, see &xep0205;.</p>
+    <p>Network monitoring mechanisms (i.e. &xep0184; and/or &xep0199;, etc.) MAY be used to monitor reliability and latency, in order to temporarily adjust the interval to prevent failure of real-time text transmissions during extreme network conditions.</p>
+    <p>That said, the load between participants using this specification in the recommended way, will cause a load that is only marginally higher than a user communicating without this specification. This is very low compared to many other activities possible on XMPP networks including VoIP and file transfers.</p>
+    </section2>
+</section1>
     <section1 topic="IANA Considerations" anchor="iana_considerations">
     <p>This document requires no interaction with the Internet Assigned Numbers Authority (IANA).</p>
     </section1>
@@ -773,13 +830,13 @@
 
 <xs:schema
     xmlns:xs='http://www.w3.org/2001/XMLSchema'
-    targetNamespace='http://jabber.org/protocol/rtt'
+    targetNamespace='urn:xmpp:rtt:0'
-    xmlns='http://jabber.org/protocol/rtt'
+    xmlns='urn:xmpp:rtt:0'
     elementFormDefault='qualified'>
 
   <xs:annotation>
     <xs:documentation>
-      The protocol documented by this schema is not yet defined on XMPP.org until submitted.
+      The protocol documented by this schema is defined in
       XEP-0xxx: http://www.xmpp.org/extensions/xep-0xxx.html
     </xs:documentation>
   </xs:annotation>