0.11

xep-0301.xml

@@ -38,6 +38,12 @@
     <email>gunnar.hellstrom@omnitor.se</email>
     <uri>http://www.omnitor.se</uri>
   </author>
+  <revision>
+    <version>0.11</version>
+    <date>2013-07-31</date>
+    <initials>MDR</initials>
+    <remark><p>Changes recommended by Kevin Smith during Last Call. One section moved (activation/deactivation guidelines).</p></remark>
+  </revision>
   <revision>
     <version>0.10</version>
     <date>2013-06-24</date>
@@ -287,10 +293,11 @@
       <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="#activating_and_deactivating_realtime_text">Activating and Deactivating Real-Time Text</link>.</p></li>
+        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="#activating_and_deactivating_realtime_text">Activating and Deactivating Real-Time Text</link>.</p></li>
+        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 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>
+      <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>
     </ul>
     </section2>
     <section2 topic="Body Element" anchor="body_element">
@@ -398,7 +405,7 @@
       <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>
     </ul>
-    <p>Recipient clients MUST keep track of separate real-time messages on a per-sender basis, including tracking independent <em><link url="#seq">seq</link></em> values. For implementation simplicity, recipient clients MAY track incoming &lt;rtt/&gt; elements per bare JID &LOCALBARE; to keep only one real-time message per sender. Recipient client handling of conflicting &lt;rtt/&gt; elements (e.g. coming concurrently from separate <link url="#simultaneous_logins">Simultaneous Logins</link>) is described in the remainder of this section. Alternatively, recipient clients MAY keep track of separate real-time messages per full JID &LOCALFULL; and/or per &lt;thread/&gt; (&xep0201;).</p>
+    <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>
         <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>
     <ol>
@@ -425,7 +432,7 @@
     <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 regularly at an average interval of 10 seconds during active typing or composing. This interval is frequent enough to minimize user waiting time, while being infrequent enough to not cause a significant bandwidth overhead. This interval MAY vary, 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>
@@ -459,7 +466,7 @@
   <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>
     <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>. In addition, XML character entities are counted as a single character.</p>
+  <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>
@@ -490,8 +497,36 @@
 
 ]]></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="#activating_and_deactivating_realtime_text">Activating and Deactivating Real-Time Text</link> for more information, including implicit discovery.</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>
+    <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>
+        <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>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>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>
+    </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>
+    </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>
+    <ul>
+      <li>Stop transmitting &lt;rtt/&gt; elements as well (not applicable to <link url="#multiuser_chat">Multi-User Chat</link>); and</li>
+      <li>Handle the sender's unfinished incoming real-time message; 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>
+    </section2>
+</section1>
     <section1 topic="Implementation Notes" anchor="implementation_notes">
         <section2 topic="Text Presentation" anchor="text_presentation">
         <section3 topic="Avoid Bursty Text Presentation" anchor="avoid_bursty_text_presentation">
@@ -508,33 +543,6 @@
     <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>
-    <section2 topic="Activating and Deactivating Real-Time Text" anchor="activating_and_deactivating_realtime_text">
-    <p>There are many possible ways to implement turning on/off real-time text. Clients can send outgoing real-time text by default. Other clients might choose to do user-initiated activation (e.g. via a button).</p>
-        <section3 topic="Activation Guidelines" anchor="activation_guidelines">
-    <p>Sender clients can <strong>simply begin transmitting real-time text</strong> (i.e. send &lt;rtt/&gt; elements), either immediately or upon user-initiated activation.</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 can 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>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>
-    </ul>
-    <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. Conversely, 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 preferred (see <link url="#determining_support">Determining Support</link>), the sender client can implicitly request and discover the use of real-time text, by sending &lt;rtt event='init'/&gt; upon activation. In the case of one-to-one chats, it is inappropriate to 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. See <link url="#usage_with_chat_states">Usage with Chat States</link>.</p>
-    </section3>
-    <section3 topic="Deactivation Guidelines" anchor="deactivation_guidelines">
-    <p>Real-time text can be deactivated by transmitting &lt;rtt <link url="#event">event</link>='cancel'/&gt;, or simply by ending the chat session. Recipient clients can 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>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 can 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, can 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 can reactivate real-time text again using &lt;rtt event='init'/&gt;.</p>
-    </section3>
 </section2>
     <section2 topic="Optional Remote Cursor" anchor="optional_remote_cursor">
     <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>
@@ -592,6 +600,7 @@
     <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>
     </section3>
 </section2>
     <section2 topic="Receiving Real-Time Text" anchor="receiving_realtime_text">
@@ -628,7 +637,7 @@
     <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="#deactivation_guidelines">Deactivation Guidelines</link> (otherwise, one participant could deny real-time text between other willing participants).</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">
@@ -984,9 +993,8 @@
   <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>
         <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-saintandre-sip-xmpp-im-03">Interworking between SIP and XMPP: Instant Messaging</link></strong></span>
+    <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>
-  <note>draft-saintandre-sip-xmpp-im: Interworking between the Session Initiation Protocol (SIP) and the
+  <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>
-  Extensible Messaging and Presence Protocol (XMPP): Instant Messaging &lt;<link url="http://tools.ietf.org/html/draft-saintandre-sip-xmpp-im-03">http://tools.ietf.org/html/draft-saintandre-sip-xmpp-im-03</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>
@@ -1000,7 +1008,8 @@
     </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. This may have security implications if users copy &amp; paste private information into their chat entry buffer (e.g. a shopping invoice) before editing out the private parts of the pasted text (e.g. a credit card number) and then sending the message. With real-time message editing, recipients can watch all text changes that occur in the sender's text, before the sender finishes the message. Implementation behaviors and improved education can be added to reduce privacy issues. Examples include showing an introduction upon first activation of feature, special handling for copy and pastes (i.e. preventing them, or prompting for confirmation), recipient confirmation of real-time text via <link url="#activating_and_deactivating_realtime_text">Activating and Deactivating Real-Time Text</link>, etc.</p>
+    <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>