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

0.9

This commit is contained in:
Peter Saint-Andre 2013-05-18 10:56:13 -06:00
parent 116d67aeec
commit 9214f124e5
1 changed files with 35 additions and 34 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

69
xep-0301.xml
View File

@ -31,6 +31,18 @@
<jid>markybox@gmail.com</jid>
<uri>http://www.realjabber.org</uri>
</author>
<author>
<firstname>Gunnar</firstname>
<surname>Hellstrom</surname>
<email>gunnar.hellstrom@omnitor.se</email>
<uri>http://www.omnitor.se</uri>
</author>
<revision>
<version>0.9</version>
<date>2013-05-18</date>
<initials>MDR</initials>
<remark><p>Minor corrections and clarifications.</p></remark>
</revision>
<revision>
<version>0.8</version>
<date>2013-04-08</date>
@ -116,8 +128,8 @@
<li>The 'talk' command on UNIX systems since the 1970's.</li>
<li>Session Initiation Protocol (SIP), utilizing <span class="ref"><strong><link url="http://tools.ietf.org/html/rfc4103">IETF RFC 4103</link></strong></span>
<note>RFC 4103: RTP Payload for Text Conversation &lt;<link url="http://tools.ietf.org/html/rfc4103">http://tools.ietf.org/html/rfc4103</link>&gt;.</note> real-time text.</li>
<li>Instant messaging enhancements, including a Gallaudet University collaboration, <span class="ref"><strong><link url="http://tap.gallaudet.edu/text/aol/">Real-Time IM</link></strong></span>
<note>Gallaudet University Technology Access Program collaboration project: Real-Time IM &lt;<link url="http://tap.gallaudet.edu/text/aol/">http://tap.gallaudet.edu/text/aol/</link>&gt;.</note>.</li>
<li>Instant messaging enhancements, including a <span class="ref"><strong><link url="http://tap.gallaudet.edu/rtt/">Gallaudet University</link></strong></span>
<note>Gallaudet University Technology Access Program collaboration project: Real-Time Text &lt;<link url="http://tap.gallaudet.edu/rtt/">http://tap.gallaudet.edu/rtt/</link>&gt;.</note> collaboration.</li>
<li>Next generation emergency services (<span class="ref"><strong><link url="http://tools.ietf.org/html/rfc6443">IETF RFC 6443</link></strong></span>
<note>RFC 6443: Framework for Emergency Calling Using Internet Multimedia &lt;<link url="http://tools.ietf.org/html/rfc6443">http://tools.ietf.org/html/rfc6443</link>&gt;.</note>).</li>
</ul>
@ -201,7 +213,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>seq</em> value as an integrity check on received real-time text. See <link url="#keeping_realtime_text_synchronized">Keeping Real-Time Text Synchronized</link>.</p>
<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>
</section3>
<section3 topic="event" anchor="event">
<p>This attribute signals events for real-time text.</p>
@ -249,7 +261,7 @@
<td>RECOMMENDED</td>
</tr>
</table>
<p>If the <em>event</em> attribute is omitted, <em>event='edit'</em> is assumed as the default. When <link url="#action_elements">Action Elements</link> are used (e.g. text appends, insertions and deletions), the &lt;rtt/&gt; element MAY contain one or more of any action elements, in any order. When action elements are not allowed, the &lt;rtt/&gt; element MUST be empty. Recipient clients MUST ignore &lt;rtt/&gt; elements containing unrecognized <em>event</em> values.</p>
<p>If the <em><strong>event</strong></em> attribute is omitted, <em><strong>event='edit'</strong></em> is assumed as the default. When <link url="#action_elements">Action Elements</link> are used (e.g. text appends, insertions and deletions), the &lt;rtt/&gt; element MAY contain one or more of any action elements, in any order. When action elements are not allowed, the &lt;rtt/&gt; element MUST be empty. Recipient clients MUST ignore &lt;rtt/&gt; elements containing unrecognized <em><strong>event</strong></em> values.</p>
</section3>
<section3 topic="id" anchor="id">
<p>This attribute is used only if Last Message Correction (XEP-0308) is implemented along with this specification. See <link url="#usage_with_last_message_correction">Usage with Last Message Correction</link> to enable real-time text during editing of the previous message.</p>
@ -260,16 +272,16 @@
<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>
<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>event='new'</em> when sending the first text of a new message (e.g. the first key presses), and only use <em>event='reset'</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>seq</em> attribute MUST increment by 1 for every consecutive modification transmitted. See <link url="#sending_realtime_text">Sending Real-Time Text</link>.</p></li>
<li><p><strong>Receiving modifications of a real-time message: Incoming &lt;rtt event='edit'/&gt; or &lt;rtt/&gt;<br /></strong>Recipient clients must verify that the <em>seq</em> attribute increments by 1 in consecutively received &lt;rtt/&gt; elements from the same sender. If seq increments as expected, the <link url="#action_elements">Action Elements</link> (e.g. text insertions and deletions) included with this element MUST be processed to modify the existing real-time message. Otherwise, if <em>seq</em> does not increment as expected, or if no real-time message already exists, the real-time message is considered out of sync and all subsequent modifications MUST be ignored until a new real-time message is initialized via <em>event='new'</em> or <em>event='reset'</em>. See <link url="#keeping_realtime_text_synchronized">Keeping Real-Time Text Synchronized</link>.</p></li>
For recipients, these differ only for optional presentation purposes (e.g. highlighting newly started incoming messages). Senders SHOULD use <em><strong>event='new'</strong></em> when sending the first text of a new message (e.g. the first key presses), and only use <em><strong>event='reset'</strong></em> when doing <link url="#message_refresh">Message Refresh</link> or <link url="#simple_realtime_text">Simple Real-Time Text</link>. See <link url="#keeping_realtime_text_synchronized">Keeping Real-Time Text Synchronized</link>.</p></li>
<li><p><strong>Sending modifications of a real-time message: Outgoing &lt;rtt event='edit'/&gt; or &lt;rtt/&gt;<br /></strong>Sender clients SHOULD transmit this element at a regular <link url="#transmission_interval">Transmission Interval</link> while the message is being modified. The <em><strong>seq</strong></em> attribute MUST increment by 1 for every consecutive modification transmitted. See <link url="#sending_realtime_text">Sending Real-Time Text</link>.</p></li>
<li><p><strong>Receiving modifications of a real-time message: Incoming &lt;rtt event='edit'/&gt; or &lt;rtt/&gt;<br /></strong>Recipient clients must verify that the <em><strong>seq</strong></em> attribute increments by 1 in consecutively received &lt;rtt/&gt; elements from the same sender. If <strong>seq</strong> increments as expected, the <link url="#action_elements">Action Elements</link> (e.g. text insertions and deletions) included with this element MUST be processed to modify the existing real-time message. Otherwise, if <em><strong>seq</strong></em> does not increment as expected, or if no real-time message already exists, the real-time message is considered out of sync and all subsequent modifications MUST be ignored until a new real-time message is initialized via <em><strong>event='new'</strong></em> or <em><strong>event='reset'</strong></em>. See <link url="#keeping_realtime_text_synchronized">Keeping Real-Time Text Synchronized</link>.</p></li>
<li><p><strong>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>seq</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="#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-on-one chat session (until <em>event='init'</em> is used again), and handle any unfinished real-time messages appropriately (e.g. clearing or saving the message). The <em>seq</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>seq</em> when initializing a real-time message using <em>event='new'</em> or <em>event='reset'</em>. Recipient clients receiving such elements MUST use this <em>seq</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>. The bounds of <em>seq</em> are 31-bits, the range of positive values for a signed 32-bit integer.</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-on-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>
</ul>
</section2>
<section2 topic="Body Element" anchor="body_element">
@ -351,7 +363,7 @@
</section4>
<section4 topic="Element &lt;e/&gt; – Erase Text" anchor="element_e_erase_text">
<p>Supports the behavior of backspace key presses. Text is removed towards beginning of the message. This element is also used for all delete operations, including the backspace key, the delete key, and text block deletes.<br />
<em>Note: Excess backspaces MUST be ignored. Thus, text is backspaced only to the beginning of the message, in situations where n is larger than p.</em></p>
<em>Note: Excess backspaces MUST be ignored by the receiving client. Thus, text is backspaced only to the beginning of the message, in situations where n is larger than p.</em></p>
<p><code><![CDATA[<e/>]]></code></p>
<p>Remove 1 character from end of message. (<em><strong>n</strong></em> defaults to 1, and <em><strong>p</strong></em> defaults to message length)</p>
<p><code><![CDATA[<e p='#'/>]]></code></p>
@ -364,7 +376,7 @@
<section4 topic="Element &lt;w/&gt; – Wait Interval" anchor="element_w_wait_interval">
<p>Allow for the transmission of intervals, between real-time text actions, to recreate the pauses between key presses. See <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>.</p>
<p><code><![CDATA[<w n='#'/>]]></code></p>
<p>Wait <em><strong>n</strong></em> milliseconds before processing the next action element. This pause MAY be approximate, and not necessarily be of millisecond precision. Sender clients SHOULD NOT send large <em><strong>n</strong></em> values that exceed the average <link url="#transmission_interval">Transmission Interval</link>. Upon receiving a <link url="#body_element">Body Element</link>, recipient clients SHOULD interrupt all pending pauses for the current real-time message, in order to prevent a delay in displaying the final message.</p>
<p>Wait <em><strong>n</strong></em> milliseconds before processing the next action element. This pause MAY be approximate, and not necessarily be of millisecond precision. Sender clients SHOULD NOT send large <em><strong>n</strong></em> values that exceed the average <link url="#transmission_interval">Transmission Interval</link>. Recipient clients MAY selectively shorten or ignore the pauses (<em><strong>n</strong></em>) in &lt;w/&gt; action elements to avoid lag in a chat session. Situations such as network congestion can result in a surge of &lt;w/&gt; elements where the total of pauses exceeds a transmission interval cycle. See <link url="#receiving_realtime_text">Receiving Real-Time Text</link>.</p>
</section4>
</section3>
</section2>
@ -511,7 +523,7 @@
<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 [[Body Element]]. 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>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>
@ -576,11 +588,11 @@
<section2 topic="Receiving Real-Time Text" anchor="receiving_realtime_text">
<p>In order to allow <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link> in incoming real-time text, recipient clients can do the following:</p>
<ol>
<li><p>Upon receiving <link url="#action_elements">Action Elements</link> in incoming &lt;rtt/&gt; elements, they are added to a queue in the order they are received. This provides immunity to variable network conditions, since the queuing action will smooth out incoming transmission (e.g. receiving new &lt;rtt/&gt; while still processing 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>. This is equivalent to playing back the sender's original typing.</p></li>
<li><p>Upon receiving a <link url="#body_element">Body Element</link> indicating a completed message, the full message text from &lt;body/&gt; can be displayed immediately in place of the real-time message, and unprocessed action elements can be cleared from the queue. This ensures that the final message delivery is not delayed by late processing of action elements.</p></li>
<li><p>Upon receiving <link url="#action_elements">Action Elements</link> in incoming &lt;rtt/&gt; elements, they are added to a queue in the order they are received. This provides immunity to variable network conditions, since the queuing 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>In processing <link url="#element_w_wait_interval">Element &lt;w/&gt; – Wait Interval</link>, excess lag in incoming real-time text might occur if multiple delayed &lt;rtt/&gt; elements suddenly get delivered (e.g. congestion, intermittent wireless reception). Recipients can avoid excess lag by monitoring the queue for excess &lt;w/&gt; action elements (e.g. unprocessed &lt;w/&gt; elements from two &lt;rtt/&gt; elements ago) and then ignoring or shortening the intervals in &lt;w/&gt; 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>
<section2 topic="Other Guidelines" anchor="other_guidelines">
@ -590,19 +602,15 @@
<p>For clients that send continuous real-time text (e.g. news ticker, captioning, speech transcription, TTY/text telephone gateway), a <link url="#body_element">Body Element</link> can be sent and then a new real-time message started immediately after, every time a message reaches a specific size. This allows continuous real-time text without real-time messages becoming excessively large.</p>
</section3>
<section3 topic="Usage with Chat States" anchor="usage_with_chat_states">
<p>Real-time text can be used in conjunction with XEP-0085 Chat States. These are simple guidelines for &lt;message/&gt; stanzas that include an &lt;rtt/&gt; element:</p>
<ul>
<li>For &lt;rtt/&gt; transmitted without an accompanying &lt;body/&gt;, include &lt;composing/&gt; chat state.</li>
<li>For &lt;rtt/&gt; transmitted with an accompanying &lt;body/&gt;, include the &lt;active/&gt; chat state.</li>
<li>Other chat states are handled as specified by XEP-0085 Chat States.</li>
</ul>
<p>Real-time text can be used in conjunction with XEP-0085 Chat States. It is best to handle XEP-0301 and XEP-0085 transmissions in separate &lt;message/&gt; stanzas. Chat states such as &lt;composing/&gt; or &lt;active/&gt; are sent separately of &lt;rtt/&gt; elements.</p>
<p>Chat states are handled as specified by XEP-0085 Chat States. The continuous transmission of real-time text corresponds to a &lt;composing/&gt; chat state. Therefore, the timing of the &lt;composing/&gt; chat state coincides with the beginning of continuous &lt;rtt/&gt; transmission.&nbsp;</p>
</section3>
<section3 topic="Usage with Last Message Correction" anchor="usage_with_last_message_correction">
<p>It is possible to have &xep0308; (XEP-0308) with real-time text. If XEP-0308 is implemented at the same time as this specification, the following rules apply:</p>
<ul>
<li><p>For all &lt;rtt/&gt; elements transmitted during composing a new message, the <em><link url="#id">id</link></em> attribute of &lt;rtt/&gt; is not used.</p></li>
<li><p>For all &lt;rtt/&gt; elements transmitted during editing of the previous message, the <em>id</em> attribute of &lt;rtt/&gt; matches the <em>id</em> attribute of the old &lt;message/&gt; stanza containing the &lt;body/&gt; text being edited (See 'Business Rules' in XEP-0308). This enables recipient clients to display real-time text while the sender is editing the previously-delivered message.</p></li>
<li><p>Senders clients need to transmit a <link url="#message_refresh">Message Refresh</link> when transmitting &lt;rtt/&gt; for a different message than the previously transmitted &lt;rtt/&gt; (i.e. the value of the <em>id</em> attribute changes, <em>id</em> becomes included, or <em>id</em> becomes not included). This keeps real-time text synchronized when beginning to edit a previously delivered message versus continuing to compose a new message.</p></li>
<li><p>For all &lt;rtt/&gt; elements transmitted during editing of the previous message, the <em><strong>id</strong></em> attribute of &lt;rtt/&gt; matches the <em><strong>id</strong></em> attribute of the old &lt;message/&gt; stanza containing the &lt;body/&gt; text being edited (See 'Business Rules' in XEP-0308). This enables recipient clients to display real-time text while the sender is editing the previously-delivered message.</p></li>
<li><p>Senders clients need to transmit a <link url="#message_refresh">Message Refresh</link> when transmitting &lt;rtt/&gt; for a different message than the previously transmitted &lt;rtt/&gt; (i.e. the value of the <em><strong>id</strong></em> attribute changes, <em><strong>id</strong></em> becomes included, or <em><strong>id</strong></em> becomes not included). This keeps real-time text synchronized when beginning to edit a previously delivered message versus continuing to compose a new message.</p></li>
<li><p>The XEP-0301 and XEP-0308 protocols operate concurrently via separate message stanzas. Thus, a message stanza never simultaneously includes both &lt;rtt/&gt; and &lt;replace/&gt;.</p></li>
<li><p>The <link url="#body_element">Body Element</link> delivers a finished new message or a finished message correction (&lt;replace/&gt; is used with &lt;body/&gt; in accordance to XEP-0308).</p></li>
</ul>
@ -686,7 +694,6 @@
<rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
<t>Hello</t>
</rtt>
<composing xmlns='http://jabber.org/protocol/chatstates'/>
</message>
<message to='alice@example.com' from='bob@example.com/home' type='chat' id='b02'>
@ -694,7 +701,6 @@
<t> Alice</t>
</rtt>
<body>Hello Alice</body>
<active xmlns='http://jabber.org/protocol/chatstates'/>
</message>
@ -702,7 +708,6 @@
<rtt xmlns='urn:xmpp:rtt:0' seq='456001' event='new'>
<t>This i</t>
</rtt>
<composing xmlns='http://jabber.org/protocol/chatstates'/>
</message>
<message to='alice@example.com' from='bob@example.com/home' type='chat' id='d04'>
@ -710,7 +715,6 @@
<t>s Bob</t>
</rtt>
<body>This is Bob</body>
<active xmlns='http://jabber.org/protocol/chatstates'/>
</message>
@ -718,14 +722,12 @@
<rtt xmlns='urn:xmpp:rtt:0' seq='789001' event='new'>
<t>How a</t>
</rtt>
<composing xmlns='http://jabber.org/protocol/chatstates'/>
</message>
<message to='alice@example.com' from='bob@example.com/home' type='chat' id='f06'>
<rtt xmlns='urn:xmpp:rtt:0' seq='789002'>
<t>re yo</t>
</rtt>
<composing xmlns='http://jabber.org/protocol/chatstates'/>
</message>
<message to='alice@example.com' from='bob@example.com/home' type='chat' id='g07'>
@ -733,7 +735,6 @@
<t>u?</t>
</rtt>
<body>How are you?</body>
<active xmlns='http://jabber.org/protocol/chatstates'/>
</message>]]></code></p>
@ -743,7 +744,6 @@
<li>The <em><link url="#event">event</link></em> attribute equals 'new' for the start of every new message.</li>
<li>The <em><link url="#seq">seq</link></em> attribute increments within the same message.</li>
<li>The <em><link url="#seq">seq</link></em> attribute randomizes when beginning a new message.</li>
<li>This shows <link url="#usage_with_chat_states">Usage with Chat States</link>.</li>
</ul>
</section2>
<section2 topic="Examples of Message Edits" anchor="examples_of_message_edits">
@ -1003,7 +1003,8 @@
<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>According to multiple university studies worldwide ([[[, 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>
<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>
</section1>
<section1 topic="IANA Considerations" anchor="iana_considerations">