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

0.10

This commit is contained in:
Peter Saint-Andre 2013-06-27 19:03:41 -06:00
parent 54813063de
commit 32f69a49e3
1 changed files with 25 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

39
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.10</version>
<date>2013-06-24</date>
<initials>MDR</initials>
<remark><p>Changes from Last Call feedback.</p></remark>
</revision>
<revision>
<version>0.9</version>
<date>2013-05-18</date>
@ -155,9 +161,10 @@
<section2 topic="Flexible and Interoperable" anchor="flexible_and_interoperable">
<ol>
<li>Allow seamless integration of real-time text into instant messaging clients, with minimal user interface modifications.</li>
<li>Be able to function over intermittent and unreliable connections, including mobile phones.</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>
<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>
</section2>
<section2 topic="Accessible" anchor="accessible">
@ -177,6 +184,7 @@
<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>
</section1>
<section1 topic="Protocol" anchor="protocol">
<section2 topic="RTT Element" anchor="rtt_element">
@ -214,7 +222,7 @@
</section2>
<section2 topic="RTT Attributes" anchor="rtt_attributes">
<section3 topic="seq" anchor="seq">
<p>This REQUIRED attribute is a counter to maintain the integrity 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. Recipients MUST monitor the <em><strong>seq</strong></em> value as an integrity check on received real-time text. 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 <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>
</section3>
<section3 topic="event" anchor="event">
<p>This attribute signals events for real-time text.</p>
@ -271,7 +279,7 @@
<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 either element as the first &lt;rtt/&gt; 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>
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>
@ -282,7 +290,7 @@
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>
<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>
<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 value is RECOMMENDED for improved integrity 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">
@ -390,7 +398,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 &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 &LOCALFULL; and/or per &lt;thread/&gt; (&xep0201;).</p>
<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>
<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>
@ -400,7 +408,7 @@
</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> attributes do 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 <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>
<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>
@ -420,7 +428,7 @@
<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>
<ul>
<li>When the recipient starts sending messages from a different full JID (e.g. switched clients);</li>
<li>When the recipient becomes available (e.g. presence changes to 'chat');</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>
@ -491,7 +499,7 @@
</section3>
<section3 topic="Preserving Key Press Intervals" anchor="preserving_key_press_intervals">
<p>For high quality presentation of real-time text, the original look-and-feel of typing can be preserved independently of the transmission interval. This is achieved using <link url="#element_w_wait_interval">Element &lt;w/&gt; – Wait Interval</link> between other <link url="#action_elements">Action Elements</link>. Sender clients can transmit the length of pauses between key presses, and send multiple key presses in a single &lt;message/&gt; stanza. Recipient clients that process &lt;w/&gt; elements are able to display the sender's typing smoothly without sudden bursts of text. See <link url="#examples_of_key_press_intervals">Examples of Key Press Intervals</link>.</p>
<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 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>
<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>
@ -529,7 +537,7 @@
</section3>
</section2>
<section2 topic="Optional Remote Cursor" anchor="optional_remote_cursor">
<p>Recipient clients can choose to display a separate cursor/caret indicator within incoming real-time 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>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 />
@ -592,7 +600,7 @@
<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 (<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>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>
</section2>
@ -624,7 +632,7 @@
<p>To minimize on-screen clutter of multiple idle real-time messages, clients can hide idle messages, clear old <link url="#stale_messages">Stale Messages</link>, and/or prioritize the display of the most useful real-time messages. Prominent visibility of real-time text can be assigned to recent typists and/or moderators (e.g. classroom teacher, convention speaker). For the same participant logged in multiple times in the same room, see <link url="#simultaneous_logins">Simultaneous Logins</link>. In situations of simultaneous typing by a large number of participants, see <link url="#congestion_considerations">Congestion Considerations</link>.</p>
</section4>
<section4 topic="Simultaneous Logins" anchor="simultaneous_logins">
<p>In simultaneous login situations, transmitting of &lt;rtt/&gt; works in one-to-many situations without any special software support. For many-to-one situations where there is incoming &lt;rtt/&gt; from more than one simultaneous login, <link url="#keeping_realtime_text_synchronized">Keeping Real-Time Text Synchronized</link> will pause the real-time message upon conflicting &lt;rtt/&gt;, and resume during the next <link url="#message_refresh">Message Refresh</link>, presumably from the active login. 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>
<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="Stale Messages" anchor="stale_messages">
@ -633,7 +641,7 @@
<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 becomes especially important for slower platforms. The real-time message might be implemented as a separate window or separate display element.</p>
<p>With real-time text, frequent screen updates can occur. Screen updates are a potential performance bottleneck, since fast typists type many key presses per second. Optimizing screen updates is more important on slower platforms. The real-time message might be implemented as a separate window or separate display element.</p>
<p>Battery life considerations are closely related to performance, as the addition of real-time text can have an impact on battery life. If <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link> is supported, then support for <link url="#element_w_wait_interval">Element &lt;w/&gt; – Wait Interval</link> needs to be implemented in a battery-efficient manner. The <link url="#transmission_interval">Transmission Interval</link> can vary dynamically to optimize for battery life and wireless reception. For devices where screen updates are an unavoidable, inefficient bottleneck, see <link url="#lowbandwidth_and_lowprecision_text_smoothing">Low-Bandwidth and Low-Precision Text Smoothing</link> to reduce the number of screen updates per second.</p>
</section3>
</section2>
@ -976,7 +984,9 @@
<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.</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>
<note>draft-saintandre-sip-xmpp-im: Interworking between the Session Initiation Protocol (SIP) and the
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>
@ -999,11 +1009,12 @@
<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 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>.</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>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>
</section2>