mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-24 18:22:24 -05:00
0.4
This commit is contained in:
Peter Saint-Andre
parent
8e30862364
commit
187566ecdb
400
xep-0301.xml
400
xep-0301.xml
@ -29,9 +29,15 @@
|
||||
<org>RealJabber.org and Rejhon Technologies Inc.</org>
|
||||
<uri>http://www.realjabber.com</uri>
|
||||
</author>
|
||||
<revision>
|
||||
<version>0.4</version>
|
||||
<date>2012-07-20</date>
|
||||
<initials>MDR</initials>
|
||||
<remark><p>Spelling, grammar, and clarification edits, including section clarifications recommended from public discussion. Interop with XEP-0308 message correction.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.3</version>
|
||||
<date>2012-07-07</date>
|
||||
<date>2012-06-07</date>
|
||||
<initials>MDR</initials>
|
||||
<remark><p>Edits recommended from public discussion.</p></remark>
|
||||
</revision>
|
||||
@ -68,10 +74,10 @@
|
||||
</header>
|
||||
|
||||
|
||||
|
||||
|
||||
<section1 topic="Introduction" anchor="introduction">
|
||||
<p><strong>Real-time text is text transmitted instantly while it is being typed or created.</strong> The recipient can immediately read the sender's text as it is written, without waiting. Text can be used conversationally, similar to a telephone conversation, where one listens while the other is speaking. It eliminates waiting times found in messaging, and is favored by deaf and hard of hearing individuals who prefer text conversation. For a visual animation of real-time text, see <span class="ref"><strong><link url="http://www.realjabber.org">RealJabber.org</link></strong></span>
|
||||
<note>RealJabber.org is the author's web site containing work related to this specification, including animation examples of what real time text looks like. <<link url="http://www.realjabber.org">http://www.realjabber.org</link>>.</note>.</p>
|
||||
<note>RealJabber.org, the author's website covering this specification, including animation examples of what real time text looks like. <<link url="http://www.realjabber.org">http://www.realjabber.org</link>>.</note>.</p>
|
||||
<p>Real-time text has been around for decades in various implementations:</p>
|
||||
<ul>
|
||||
<li>The 'talk' command on UNIX systems since the 1970's.</li>
|
||||
@ -81,10 +87,10 @@
|
||||
<li>In 2008, AOL AIM 6.8 gained the <span class="ref"><strong><link url="http://help.aol.com/help/microsites/microsite.do?cmd=displayKC&externalId=223568">AOL Real-Time IM</link></strong></span> <note>AOL AIM Real Time Text: <<link url="http://help.aol.com/help/microsites/microsite.do?cmd=displayKC&externalId=223568">http://help.aol.com/help/microsites/microsite.do?cmd=displayKC&externalId=223568</link>>.</note> feature.</li>
|
||||
<li>Deployment of <span class="ref"><strong><link url="http://www.reach112.eu">Reach112</link></strong></span> <note>Reach112: European emergency service with real-time text. <<link url="http://www.reach112.eu">http://www.reach112.eu</link>>.</note> in Europe, an accessible emergency service with real-time text.</li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
||||
|
||||
<p>Real-time text is suitable for smooth and rapid mainstream communication in text, as an all-inclusive technology to complement instant messaging. At the same time, real-time text has special usefulness to many audiences including the deaf, hard of hearing, and other people who cannot use speech on the telephone. Real-time text is also beneficial in emergency situations, due to its immediacy. This document defines a specification for real-time text transmitted in-band over an XMPP network.</p>
|
||||
<p>Real-time text is suitable for smooth and rapid mainstream communication in text, as an all-inclusive technology to complement instant messaging. It can also allow immediate conversation in situations where speech cannot be used (e.g. quiet environments, privacy, deaf and hard of hearing). Real-time text is also beneficial in emergency situations, due to its immediacy. This document defines a specification for real-time text transmitted in-band over an XMPP network.</p>
|
||||
</section1>
|
||||
<section1 topic="Requirements" anchor="requirements">
|
||||
<section2 topic="Fluid Real-Time Text" anchor="fluid_realtime_text">
|
||||
@ -124,14 +130,13 @@
|
||||
<p><strong>real-time</strong> – A conversational latency of less than 1 second, as defined by <span class="ref"><strong><link url="http://www.itu.int/rec/T-REC-F.700">ITU-T Rec. F.700</link></strong></span> <note>ITU-T Rec. F.700: Framework Recommendation for multimedia services <<link url="http://www.itu.int/rec/T-REC-F.700">http://www.itu.int/rec/T-REC-F.700</link>>.</note>, section 2.1.2.1.</p>
|
||||
<p><strong>real-time text</strong> – Text transmitted in real-time while it is being typed or created.</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>real-time message edit</strong> – An edit operation done by the remote sender, that is transmitted in real-time to the recipient.</p>
|
||||
<p><strong>action element</strong> – An XML element that represents a single real-time message edit, such as text insertion or deletion.</p>
|
||||
<p><strong>RTT</strong> – Acronym for real-time text.</p>
|
||||
</section1>
|
||||
<section1 topic="Protocol" anchor="protocol">
|
||||
<section2 topic="RTT Element" anchor="rtt_element">
|
||||
<p>Real-time text is transmitted via an <rtt/> child element of a <message/> stanza. The <rtt/> element is transmitted at regular intervals by the sender while a message is being composed, to allow the recipient to see the sender type (and edit) the message before the full message is sent in a <body/> element.</p>
|
||||
<p>This is a basic example of a <em><strong>real-time message</strong></em> "Hello, my Juliet!", transmitted live while it is being typed, before a final message delivery:</p>
|
||||
<p>Real-time text is transmitted via an <rtt/> child element of a <message/> stanza. The <rtt/> element is transmitted at regular intervals by the sender client while a message is being composed, to allow the recipient to see the sender type the message, without waiting for the full message sent in a <body/> element.</p>
|
||||
<p>This is a basic example of a <em><strong>real-time message</strong></em> "Hello, my Juliet!” transmitted live while it is being typed, before a final message delivery in a <body/> element (to remain <link url="#backwards_compatible">Backwards Compatible</link>):</p>
|
||||
<p><strong>Example 1: Introductory Example</strong></p>
|
||||
<p><code><![CDATA[<message to='juliet@capulet.lit' from='romeo@montague.lit/orchard' type='chat' id='a01'>
|
||||
<rtt xmlns='urn:xmpp:rtt:0' seq='0' event='new'>
|
||||
@ -154,17 +159,18 @@
|
||||
<message to='juliet@capulet.lit' from='romeo@montague.lit/orchard' type='chat' id='a04'>
|
||||
<body>Hello, my Juliet!</body>
|
||||
</message>]]></code></p>
|
||||
|
||||
|
||||
|
||||
|
||||
<p>The <rtt/> element contains a series of one or more child elements called <em><strong>action elements</strong></em> that represent <em><strong>real-time message edits</strong></em> such as text being appended, inserted, or deleted. Example 1 illustrates only the <t/> action element, which appends text to the end of a message. See <link url="#realtime_text_operations">Real-Time Text Operations</link>.</p>
|
||||
<p>Transmission of the <rtt/> element occurs at regular intervals whenever the sender is actively composing a message. If there are no changes to the message since the last transmission, no transmission occurs. See <link url="#transmission_interval">Transmission Interval</link>.</p>
|
||||
<p>The namespace of the <rtt/> element is “urn:xmpp:rtt:0”. There MUST NOT be more than one <rtt/> element per <message/> stanza.</p>
|
||||
<p>The <rtt/> element contains a series of one or more child elements called <em><strong>action elements</strong></em> that represent <link url="#realtime_text_actions">Real-Time Text Actions</link> such as text being appended, inserted, or deleted. Example 1 illustrates only the <t/> action element, which appends text to the end of a message.</p>
|
||||
<p>Transmission of the <rtt/> element occurs at a regular <link url="#transmission_interval">Transmission Interval</link> whenever the sender is actively composing a message. If there are no changes to the message since the last transmission, no transmission occurs.</p>
|
||||
<p>There MUST NOT be more than one <rtt/> element per <message/> stanza.</p>
|
||||
<p>The namespace of the <rtt/> element is “urn:xmpp:rtt:0”.</p>
|
||||
</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. (The bounds of <strong>seq</strong> is 31-bits, the range of positive values of a signed integer.)</p>
|
||||
<p>Senders MUST increment the <strong>seq</strong> attribute by 1 in each subsequent <rtt/> transmitted without an <strong>event</strong> attribute. When an <rtt/> element has an <strong>event</strong> attribute, senders MAY instead use any value as the new starting value for <strong>seq</strong>. A random starting <strong>seq</strong> value is RECOMMENDED for best integrity during <link url="#usage_with_multiuser_chat_and_simultaneous_logins">Usage With Multi-User Chat and Simultaneous Logins</link>. Senders MAY limit the size of the new starting <strong>seq</strong> value, to keep <rtt/> compact, and allow plenty of incrementing room without overflow.</p>
|
||||
<p>Senders MUST increment the <strong>seq</strong> attribute by 1 in each subsequent <rtt/> transmitted without an <link url="#event">event</link> attribute. When an <rtt/> element has an <link url="#event">event</link> attribute, senders MAY instead use any value as the new starting value for <strong>seq</strong>. A random starting <strong>seq</strong> value is RECOMMENDED for best integrity during <link url="#usage_with_multiuser_chat_and_simultaneous_logins">Usage with Multi-User Chat and Simultaneous Logins</link>. Senders MAY limit the size of the new starting <strong>seq</strong> value, to keep <rtt/> compact while allowing plenty of incrementing room without overflow.</p>
|
||||
<p>Recipients MUST monitor the <strong>seq</strong> value to verify the integrity of real-time text. See <link url="#keeping_realtime_text_synchronized">Keeping Real-Time Text Synchronized</link>.</p>
|
||||
</section3>
|
||||
<section3 topic="event" anchor="event">
|
||||
@ -210,27 +216,31 @@
|
||||
<p><strong>event='cancel'</strong><br />
|
||||
Clients MAY use this value to signal the other end to stop transmitting real-time text. If used, this <rtt/> element MUST be empty with no action elements. Recipients SHOULD discontinue sending back <rtt/> elements for the remainder of the same chat session (or unless <strong>'init'</strong> is used again). See <link url="#activating_and_deactivating_realtime_text">Activating and Deactivating Real-Time Text</link>.</p>
|
||||
</section3>
|
||||
<section3 topic="id" anchor="id">
|
||||
<p>This OPTIONAL attribute is used only if &xep0308; (XEP-0308) is implemented. Sender clients MAY use this attribute to allow recipient clients to have improved presentation of real-time text during message correction (e.g. shown as in-place editing of previous message).</p>
|
||||
<p>This <strong>id</strong> attribute refers to the <message/> stanza containing the <body/> that is being edited (See 'Business Rules' in XEP-0308). If used at all, then <strong>id</strong> MUST be included in all <rtt/> elements transmitted during message correction of the previous message. When switching messages being edited (i.e. editing the current message versus editing the previous message), the first <rtt/> element MUST contain an <link url="#event">event</link> attribute value, such as 'reset' (See <link url="#message_reset">Message Reset</link>).</p>
|
||||
</section3>
|
||||
</section2>
|
||||
<section2 topic="Body Element" anchor="body_element">
|
||||
<p>The real-time message is considered complete upon receipt of a <body/> element in a message stanza. The delivered message is displayed instead of the real-time message. In the ideal case, the message from <body/> is redundant since this delivered message is identical to the final contents of the real-time message.</p>
|
||||
<p>The real-time message is considered complete upon receipt of a <body/> element in a message stanza. The delivered message in the <body/> element is displayed instead of the real-time message. In the ideal case, the message from <body/> is redundant since this delivered message is identical to the final contents of the real-time message.</p>
|
||||
<p>Senders MUST include an <link url="#event">event</link> attribute in the next <rtt/> element that is transmitted after a message stanza containing a <body/> element.</p>
|
||||
<section3 topic="Backwards Compatible" anchor="backwards_compatible">
|
||||
<p>The real-time text standard simply provides early delivery of text before the <body/> element. The <body/> element continues to follow the &xmppcore; specification. In particular, XMPP implementations need to ignore XML elements they do not understand. Clients that do not support real-time text, will continue to behave normally, displaying complete lines of messages as they are delivered.</p>
|
||||
<p>The real-time text standard simply provides early delivery of text before the <body/> element. The <body/> element continues to follow the &xmppcore; specification. In particular, XMPP implementations need to ignore XML elements they do not understand. Clients, that do not support real-time text, will continue to behave normally, displaying complete lines of messages as they are delivered.</p>
|
||||
</section3>
|
||||
</section2>
|
||||
<section2 topic="Transmission Interval" anchor="transmission_interval">
|
||||
<p>For the best balance between interoperability and usability, the transmission interval of <rtt/> elements for a continuously-changing message SHOULD be approximately <strong>0.7 second</strong>. This interval meets ITU-T Rec. F.700 for real-time conversation. If a different transmission interval needs to be used, the interval SHOULD be <strong>between 0.3 second and 1 second</strong>.</p>
|
||||
<p>For the best balance between interoperability and usability, the default transmission interval of <rtt/> elements for a continuously-changing message SHOULD be approximately <strong>0.7 second</strong>. This interval meets ITU-T Rec. F.700 for real-time conversation. If a different transmission interval needs to be used, the interval SHOULD be <strong>between 0.3 second and 1 second</strong>.</p>
|
||||
<p>A longer interval will lead to a less optimal user experience. Conversely, a much shorter interval may more frequently trigger throttling or flooding protection algorithms in public XMPP servers, leading to dropped <message/> elements and/or <link url="#congestion_considerations">Congestion Considerations</link>.</p>
|
||||
<p>To provide fluid real-time text, one or more of the following methods can be used:</p>
|
||||
<ul>
|
||||
<li><link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link> for natural typing display, independently of the transmission interval.</li>
|
||||
<li>Use of <link url="#time_critical_and_low_latency_methods">Time Critical And Low Latency Methods</link>, for real-time captioning/transcription.</li>
|
||||
<li>For other options or reduced-precision options, see <link url="#lowbandwidth_and_lowprecision_text_smoothing">Low-Bandwidth And Low-Precision Text Smoothing</link>.</li>
|
||||
<li>Use of <link url="#time_critical_and_low_latency_methods">Time Critical and Low Latency Methods</link>, for real-time captioning/transcription.</li>
|
||||
<li>For other options or reduced-precision options, see <link url="#lowbandwidth_and_lowprecision_text_smoothing">Low-Bandwidth and Low-Precision Text Smoothing</link>.</li>
|
||||
</ul>
|
||||
</section2>
|
||||
<section2 topic="Real-Time Text Operations" anchor="realtime_text_operations">
|
||||
<section2 topic="Real-Time Text Actions" anchor="realtime_text_actions">
|
||||
<p>The <rtt/> element MAY contain one or more <em><strong>action elements</strong></em> representing real-time text operations, including text being appended, inserted, or deleted.</p>
|
||||
<p>Many chat clients allow a sender to edit their message before sending (via a Send button, or pressing Enter). The inclusion of real-time text functionality to existing client software, needs to preserve the sender's existing expectation of being able to edit their messages before sending. In a chat session with real-time text, the recipient can watch the sender compose and edit their message before it is delivered.</p>
|
||||
<p>Many chat clients allow a sender to edit their message before sending (via a Send button, or pressing Enter). The inclusion of real-time text functionality, in existing client software, needs to preserve the sender's existing expectation of being able to edit their messages. In a chat session with real-time text, the recipient can watch the sender compose and edit their message before it is delivered.</p>
|
||||
<section3 topic="Action Elements" anchor="action_elements">
|
||||
<p>This is a short summary of action elements that operate on a real-time message. For detailed information, see <link url="#list_of_action_elements">List of Action Elements</link>.</p>
|
||||
<table>
|
||||
@ -263,7 +273,7 @@
|
||||
<td><strong>REQUIRED</strong></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Interval</td>
|
||||
<td>Wait Interval</td>
|
||||
<td><w n='#'/></td>
|
||||
<td>Wait <em><strong>n</strong></em> thousandths of a second.</td>
|
||||
<td>RECOMMENDED</td>
|
||||
@ -279,25 +289,25 @@
|
||||
If <em><strong>p</strong></em> is omitted, the default value of <em><strong>p</strong></em> MUST be the current message length (<em><strong>p</strong></em> defaults to end of message).</p></li>
|
||||
<li><p>For text modifications, length and position (<em><strong>n</strong></em> and <em><strong>p</strong></em>) is based on <link url="#unicode_character_counting">Unicode Character Counting</link>.<br />
|
||||
Also see <link url="#accurate_processing_of_action_elements">Accurate Processing of Action Elements</link>.</p></li>
|
||||
<li><p>Senders MUST NOT use negative values for any attribute, nor use <em><strong>p</strong></em> values beyond the current message length. However, recipients receiving such values MUST clip negative values to 0, and clip excessively high <em><strong>p</strong></em> values to the current length of the real-time message. Modifications only occur within the boundaries of the current real-time message, and not other delivered messages.</p></li>
|
||||
<li><p>Senders MUST NOT use negative values for any attribute, nor use <em><strong>p</strong></em> values beyond the current message length. However, recipients receiving such values MUST clip negative values to 0, and clip excessively high <em><strong>p</strong></em> values to the current length of the real-time message. Modifications only occur within the boundaries of the current real-time message, and not in other delivered messages.</p></li>
|
||||
</ul>
|
||||
</section3>
|
||||
<section3 topic="List of Action Elements" anchor="list_of_action_elements">
|
||||
<p>Recipients MUST be able to process all <t/>, <e/> and <d/> action elements for incoming <rtt/> transmissions, even if senders do not use these for outgoing <rtt/> transmissions (e.g. <link url="#basic_realtime_text">Basic Real-Time Text</link>). Support for <w/> is RECOMMENDED for both senders and recipients in order to accommodate <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>. Recipients MUST ignore unexpected or unsupported elements within <rtt/>, while continuing to process subsequent action elements (Compatibility is ensured via <link url="#namespace_versioning">Namespace Versioning</link>). Action elements are immediate child elements of the <rtt/> element, and are never nested. See examples in <link url="#use_cases">Use Cases</link>.</p>
|
||||
<p>Recipients MUST be able to process all <t/>, <e/> and <d/> action elements for incoming <rtt/> transmissions, even if senders do not use all of these for outgoing <rtt/> transmissions (e.g. <link url="#basic_realtime_text">Basic Real-Time Text</link>). Support for <w/> is RECOMMENDED for both senders and recipients, in order to accommodate <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>. Recipients MUST ignore unexpected or unsupported elements within <rtt/>, while continuing to process subsequent action elements (Compatibility is ensured via <link url="#namespace_versioning">Namespace Versioning</link>). Action elements are immediate child elements of the <rtt/> element, and are never nested. See examples in <link url="#use_cases">Use Cases</link>.</p>
|
||||
<section4 topic="Element <t/> – Insert Text" anchor="element_t_insert_text">
|
||||
<p>Supports transmission of text, including key presses, and text block inserts.<br />
|
||||
<p>Support the transmission of text, including key presses, and text block inserts.<br />
|
||||
<em>Note: Text can be any</em> <em>subset of text allowed in the <body/> element of a <message/>. If <t/> is empty, no text modification takes place.</em></p>
|
||||
<p><code><![CDATA[<t>text</t>]]></code></p>
|
||||
<p>Appends specified <em><strong>text</strong></em> at the end of message. (<em><strong>p</strong></em> defaults to message length).<br />
|
||||
<p>Append specified <em><strong>text</strong></em> at the end of message. (<em><strong>p</strong></em> defaults to message length).<br />
|
||||
<em>Note: This action element is the minimum sender support REQUIRED for <link url="#basic_realtime_text">Basic Real-Time Text</link>.</em></p>
|
||||
<p><code><![CDATA[<t p='#'>text</t>]]></code></p>
|
||||
<p>Inserts specified <em><strong>text</strong></em> at position <em><strong>p</strong></em> in the message text.</p>
|
||||
|
||||
|
||||
|
||||
|
||||
</section4>
|
||||
<section4 topic="Element <e/> – Backspace" anchor="element_e_backspace">
|
||||
<p>Supports the behavior of Backspace key presses. Text is removed towards beginning of the message.<br />
|
||||
<p>Support the behavior of Backspace key presses. Text is removed towards beginning of the message.<br />
|
||||
<em>Note: Excess backspaces MUST be ignored, with text being backspaced only to the beginning of the message in this case.</em></p>
|
||||
<p><code><![CDATA[<e/>]]></code></p>
|
||||
<p>Remove 1 character from end of message. (Both <em><strong>n</strong></em> and <em><strong>p</strong></em> at default values)</p>
|
||||
@ -307,20 +317,20 @@
|
||||
<p>Remove <em><strong>n</strong></em> characters from end of message. (<em><strong>p</strong></em> defaults to message length)</p>
|
||||
<p><code><![CDATA[<e n='#' p='#'/>]]></code></p>
|
||||
<p>Remove <em><strong>n</strong></em> characters before position <em><strong>p</strong></em> in message.</p>
|
||||
|
||||
|
||||
|
||||
|
||||
</section4>
|
||||
<section4 topic="Element <d/> – Forward Delete" anchor="element_d_forward_delete">
|
||||
<p>Supports the behavior of Delete key presses, and text block deletes. Text is removed towards end of the message.<br />
|
||||
<em>Note:Excess deletes MUST be ignored, with text being deleted only to the end of the message in this case.</em></p>
|
||||
<p>Support the behavior of Delete key presses, and text block deletes. Text is removed towards end of the message.<br />
|
||||
<em>Note: Excess deletes MUST be ignored, with text being deleted only to the end of the message in this case.</em></p>
|
||||
<p><code><![CDATA[<d p='#'/>]]></code></p>
|
||||
<p>Remove 1 character beginning at position <em><strong>p</strong></em> in message. (<em><strong>n</strong></em> defaults to 1)</p>
|
||||
<p><code><![CDATA[<d p='#' n='#'/>]]></code></p>
|
||||
<p>Remove <em><strong>n</strong></em> characters beginning at position <em><strong>p</strong></em> in message.</p>
|
||||
</section4>
|
||||
<section4 topic="Element <w/> – Interval" anchor="element_w_interval">
|
||||
<p>Allows the transmission of intervals between real-time message edits, such as the pauses between key presses. See <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>.</p>
|
||||
<section4 topic="Element <w/> – Wait Interval" anchor="element_w_wait_interval">
|
||||
<p>Allow the transmission of intervals, between real-time text actions, to support 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> thousandths of a second before processing the next action element. This pause MAY be approximate, and not necessarily be of millisecond precision. The <em><strong>n</strong></em> value SHOULD NOT exceed the <link url="#transmission_interval">Transmission Interval</link>. Also, if a <link url="#body_element">Body Element</link> arrives, pauses SHOULD be interrupted to prevent a delay in message delivery.</p>
|
||||
</section4>
|
||||
@ -329,13 +339,13 @@
|
||||
<p>Real-time text is generated based on text normally allowed to be transmitted within the <body/> element.</p>
|
||||
<p>Incorrectly generated action elements may lead to inconsistencies between the sender and recipient during real-time editing. The Unicode characters of the real-time text needs to make it transparently from the sender to the recipient, without further Unicode character modifications. This is the chain between the sender's creation of real-time text, to the recipient's processing of real-time text. Transparent transmission of Unicode characters is possible with sender pre-processing, as long as the transmission from the sender to the recipient remains standards-compliant, including compliant XML processors and compliant XMPP servers.</p>
|
||||
<p>Any inconsistencies that occur during real-time message editing (i.e. non-compliant XMPP server that modifies messages) will recover during the next <link url="#message_reset">Message Reset</link>, and also via <link url="#basic_realtime_text">Basic Real-Time Text</link>.</p>
|
||||
<section4 topic="Guidelines For Senders" anchor="guidelines_for_senders">
|
||||
<p>Senders MUST generate real-time text based on the plain text version of the sender's message with all processing completed. Processing include Unicode normalization, conversion of emoticons graphics to text, removal of illegal characters, line-break conversion, and all other Unicode character modifications. This MAY be done in parallel to the sender client's displayed version of the message (i.e. graphics, formatting, &xep0071;).</p>
|
||||
<p>For the purpose of calculating <em><strong>n</strong></em> and <em><strong>p</strong></em> values, line breaks MUST be treated as a single character, if line breaks are used within real-time text. It is noted 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). <<link url="http://www.w3.org/TR/xml/">http://www.w3.org/TR/xml/</link>>.</note>.</p>
|
||||
<section4 topic="Guidelines for Senders" anchor="guidelines_for_senders">
|
||||
<p>Senders MUST generate real-time text based on the plain text version of the sender's message with all processing already completed. Processing include Unicode normalization, conversion of emoticons graphics to text, removal of illegal characters, line-break conversion, and all other Unicode character modifications. This is done concurrently to the displayed version of the same message (which may continue to have formatting, emoticon graphics, &xep0071;, etc.).</p>
|
||||
<p>For the purpose of calculating <em><strong>n</strong></em> and <em><strong>p</strong></em> values, line breaks MUST be treated as a single character, if line breaks are used within real-time text. 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). <<link url="http://www.w3.org/TR/xml/">http://www.w3.org/TR/xml/</link>>.</note>.</p>
|
||||
</section4>
|
||||
<section4 topic="Guidelines For Recipients" anchor="guidelines_for_recipients">
|
||||
<p>For recipients, <em><strong>p</strong></em> and <em><strong>n</strong></em> are calculated relative to real-time text obtained from a compliant XML processor, before any further Unicode character modifications. (This includes recipient-side Unicode normalization. In an ideal and compliant scenario, normalizing an already normalized Unicode string, will result in no character modifications, and will not cause any issues.) Recipients MUST NOT do Unicode normalization (or any other code point modifications) on their internal copy of the real-time message, for accurate processing of subsequent action elements. (The recipient client can process the same text separately for display).</p>
|
||||
<p>Note that <link url="#element_t_insert_text">Element <t/> – Insert Text</link> is allowed to contain any subset sequence of Unicode characters from the real-time message. This may result in certain situations where the text transmitted in <t/> elements is allowed to be temporarily an incorrectly-formed Unicode string. (i.e. non spacing characters, orphaned diacritic, orphaned control character including direction-change character for bidirectional Unicode, incompletely formed glyphs, etc.) but becomes correct when inserted into the middle of the recipient's real-time message, and passes recipient validation/normalization with no character modifications. Note that a compliant XML processor does not modify or fix Unicode errors caused by taking only a subset of characters from correctly-formed Unicode text. One alternative way for implementers to visualize this, is to visualize the Unicode text as an array of individual code points, and treat the <em><strong>p</strong></em> and <em><strong>n</strong></em> values accordingly.</p>
|
||||
<section4 topic="Guidelines for Recipients" anchor="guidelines_for_recipients">
|
||||
<p>For recipients, <em><strong>p</strong></em> and <em><strong>n</strong></em> are calculated relative to real-time text obtained from a compliant XML processor, before any further Unicode character modifications. Recipients MUST NOT do Unicode normalization (or any other code point modifications) on their copy of the real-time message. This is to allow accurate processing of subsequent action elements (For display purposes, the recipient client can separately process/normalize a copy of the same real-time message text).</p>
|
||||
<p>Note that <link url="#element_t_insert_text">Element <t/> – Insert Text</link> is allowed to contain any subset sequence of Unicode characters from the real-time message. This may result in certain situations where the text transmitted in <t/> elements is allowed to be temporarily an incorrectly-formed Unicode string (e.g. incompletely formed glyphs, non-spacing characters, orphaned diacritic character, standalone control character including direction-change character for bidirectional Unicode) but becomes correct when inserted into the middle of the recipient's real-time message, and consequently passes recipient validation/normalization with no character modifications. Note that a compliant XML processor does not modify or fix Unicode errors caused by taking only a subset of characters from correctly-formed Unicode text. One alternative way for implementers to visualize this, is to visualize the Unicode text as an array of individual code points, and treat the <em><strong>p</strong></em> and <em><strong>n</strong></em> values accordingly.</p>
|
||||
</section4>
|
||||
<section4 topic="Unicode Character Counting" anchor="unicode_character_counting">
|
||||
<p>For platform-independent interoperability, calculations of length and position values (<em><strong>p</strong></em> and <em><strong>n</strong></em>) MUST be based on Unicode code points. A single UTF-8 encoded character equals one code point. However, many platforms use different internal encodings (i.e. string formats) that is different from the transmission encoding (UTF-8). Consider these factors:</p>
|
||||
@ -347,7 +357,7 @@
|
||||
<li><p>Some Unicode encodings use a variable number of bytes per Unicode code point (e.g. UTF-8).<br /><em>Action elements operate on individual Unicode code points, not on individual bytes.</em></p></li>
|
||||
</ul>
|
||||
<p>Incorrectly calculated length and position values (<em><strong>p</strong></em> and <em><strong>n</strong></em>) can result in inconsistencies in the real-time message, such as scrambled text. If this happens, this situation can recover during the <link url="#message_reset">Message Reset</link>.</p>
|
||||
<p>Length and position values (<em><strong>p</strong></em> and <em><strong>n</strong></em>) are relative to the internal Unicode text of the real-time message, independently of the directionality of actual displayed text. Any existing Unicode text direction can be used (right-to-left, left-to-right, and bidirectional). From the perspective of length and position values (<em><strong>p</strong></em> and <em><strong>n</strong></em>), a real-time message is treated equivalent to an editable array of Unicode code points, even if not necessarily stored as such.</p>
|
||||
<p>Length and position values (<em><strong>p</strong></em> and <em><strong>n</strong></em>) are relative to the internal Unicode text of the real-time message, independently of the directionality of actual displayed text. As a result, any valid Unicode text direction can be used with real-time text (right-to-left, left-to-right, and bidirectional).</p>
|
||||
</section4>
|
||||
</section3>
|
||||
</section2>
|
||||
@ -360,7 +370,7 @@
|
||||
<li>Multiple <link url="#simultaneous_logins">Simultaneous Logins</link> (e.g. switching systems, switching windows, simultaneous typing).</li>
|
||||
</ul>
|
||||
<section3 topic="Staying In Sync" anchor="staying_in_sync">
|
||||
<p>For <rtt/> elements that does not contain an <link url="#event">event</link> attribute:</p>
|
||||
<p>For <rtt/> elements that do not contain an <link url="#event">event</link> attribute:</p>
|
||||
<ol>
|
||||
<li>Senders MUST increment the <link url="#seq">seq</link> attribute for consecutively transmitted <rtt/> elements.</li>
|
||||
<li>Recipients MUST monitor the <link url="#seq">seq</link> attribute value of received <rtt/> elements, to verify that it is incrementing.</li>
|
||||
@ -381,13 +391,13 @@
|
||||
</ul>
|
||||
</section3>
|
||||
<section3 topic="Message Reset" anchor="message_reset">
|
||||
<p>A message reset is a retransmission of the sender's partially composed text. The recipient refreshes the real-time message as a result. It allows real-time text conversation to resume quickly, without waiting for senders to start a new message.</p>
|
||||
<p>A message reset is a retransmission of the sender's partially composed text. The recipient can redisplay the real-time message as a result. It allows real-time text conversation to resume quickly, without waiting for senders to start a new message.</p>
|
||||
<p>Retransmission SHOULD be done 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 reduce bandwidth overhead. This interval MAY vary in order to reduce average bandwidth requirements for minor message changes and/or for long messages. For quicker recovery, senders MAY adjust the timing of the message retransmissions to occur right after any of the following additional events: </p>
|
||||
<ul>
|
||||
<li>When a recipient starts sending messages from a different full JID (e.g. switched systems);</li>
|
||||
<li>When a recipient sends a presence update (e.g. from offline to online);</li>
|
||||
<li>When a recipient sends a chat state notification. See <link url="#usage_with_chat_states">Usage With Chat States</link>.</li>
|
||||
<li>When a conversation is unlocked via &xep0296;;</li>
|
||||
<li>When the recipient starts sending messages from a different full JID (e.g. switched systems);</li>
|
||||
<li>When the recipient sends a presence update (e.g. from offline to online);</li>
|
||||
<li><p>When the sender resumes composing after an extended pause (e.g. recovery from <link url="#stale_messages">Stale Messages</link> handling);</p></li>
|
||||
<li><p>When the conversation is unlocked (e.g. section 5.1 of &xmppim;);</p></li>
|
||||
</ul>
|
||||
<p>A message reset is done using the <rtt/> attribute <link url="#event">event</link> value of <strong>'reset'</strong> (see <link url="#rtt_attributes">RTT Attributes</link>).</p>
|
||||
<p><code><![CDATA[<rtt event='reset' seq='#' xmlns='urn:xmpp:rtt:0'>
|
||||
@ -398,7 +408,7 @@
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic="Determining Support" anchor="determining_support">
|
||||
<p>If a client supports this real-time text protocol, it is strongly RECOMMENDED to advertise that fact in its responses via &xep0030; information ("disco#info") requests by returning a feature of <strong>urn:xmpp:rtt:0</strong></p>
|
||||
<p>If a client supports this real-time text protocol, it MUST advertise that fact in its responses to &xep0030; information requests ("disco#info") by returning a feature of <strong>urn:xmpp:rtt:0</strong></p>
|
||||
<p><strong>Example 1. A disco#info query</strong></p>
|
||||
<p><code><![CDATA[<iq from='romeo@montague.lit/orchard'
|
||||
id='disco1'
|
||||
@ -419,45 +429,44 @@
|
||||
</iq>
|
||||
|
||||
]]></code></p>
|
||||
<p>If this successful response of <strong><feature var='urn:xmpp:rtt:0'/></strong> is not received, the client SHOULD NOT transmit any outgoing <rtt/> elements in <message/> transmissions. This avoids unnecessary consumption of bandwidth to clients that do not support this protocol.</p>
|
||||
<p>Enabling/disabling of discovery is SHOULD NOT be the default method of activating/deactivating real-time text. See <link url="#activating_and_deactivating_realtime_text">Activating and Deactivating Real-Time Text</link>.</p>
|
||||
<p>In the absence of feature discovery, sender clients MAY send a single blank <rtt/> element at the beginning of the session (or upon sender attempting to initiate real-time text), as a method of indicating to the recipient that real-time text is permitted until the end of the chat session. Senders SHOULD NOT send any further <rtt/> until incoming <rtt/> is received during the same chat session, or when support is confirmed via discovery.</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>
|
||||
</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">
|
||||
<p>If a long <link url="#transmission_interval">Transmission Interval</link> is used without <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>, then text will appear in intermittent bursts if the display of text is not smoothed. This hurts user experience of real-time text.</p>
|
||||
<p>If a long <link url="#transmission_interval">Transmission Interval</link> is used without <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>, then incoming text will appear in intermittent bursts if the display of text is not smoothed. This hurts user experience of real-time text.</p>
|
||||
</section3>
|
||||
<section3 topic="Preserving Key Press Intervals" anchor="preserving_key_press_intervals">
|
||||
<p>For the highest quality display of text being typed, using <link url="#element_w_interval">Element <w/> – Interval</link> allows the original look-and-feel of typing to be preserved, independently of the transmission interval. Using the <w/> element, the sender can record multiple key presses including key press intervals, and transmit them over the XMPP network in a single <message/>. The recipient can then play back the sender's typing in real-time at original typing speed including the intervals between key presses.</p>
|
||||
<p>Much like VoIP is a packetization of sound, this spec enables packetization of typing including the original key press intervals. This enables the real-time feel of typing over virtually any 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>The recipient can watch the sender fluidly compose/edit their message in real-time without any “bursting” effects. This is “Natural Typing”, and appears indistinguishable from local typing. 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). For an example transmission of key intervals, see <link url="#full_message_including_key_press_intervals">Full Message Including Key Press Intervals</link>.</p>
|
||||
<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 <w/> – 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 <message/> stanza. Recipient clients that process <w/> 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>
|
||||
</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 demands low latency transmission. Such systems typically use voice recognition and/or stenotype machines, which output text in word bursts rather than a character at a time. It is acceptable for senders with bursty output to immediately transmit word bursts of text without buffering. This eliminates any lag caused by the <link url="#transmission_interval">Transmission Interval</link>. It is not necessary to transmit <link url="#element_w_interval">Element <w/> – Interval</link> for real-time transcription.</p>
|
||||
<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 demands low latency transmission. Such systems typically use voice recognition and/or stenotype machines, which output text in word bursts rather than a character at a time. It is acceptable for senders with bursty output to immediately transmit word bursts of text without buffering. 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 <w/> – Wait Interval</link> for real-time transcription.</p>
|
||||
</section3>
|
||||
<section3 topic="Low-Bandwidth And Low-Precision Text Smoothing" anchor="lowbandwidth_and_lowprecision_text_smoothing">
|
||||
<p>Some software platforms (e.g. JavaScript, BOSH, mobile devices) may have low-precision timers that impact <link url="#transmission_interval">Transmission Interval</link> and/or <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>. Clients can optimize for bandwidth, performance and/or screen repaints by eliminating, merging, or ignoring <link url="#element_w_interval">Element <w/> – Interval</link> selectively, especially those containing shorter intervals. It is acceptable for the transmission interval of <rtt/> to vary, either intentionally for optimizations, or due to precision limitation.</p>
|
||||
<section3 topic="Low-Bandwidth and Low-Precision Text Smoothing" anchor="lowbandwidth_and_lowprecision_text_smoothing">
|
||||
<p>Some software platforms (e.g. JavaScript, BOSH, mobile devices) may have low-precision timers that impact <link url="#transmission_interval">Transmission Interval</link> and/or <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>. Clients can optimize for bandwidth, performance and/or screen repaints by eliminating, merging, or ignoring <link url="#element_w_wait_interval">Element <w/> – Wait Interval</link> selectively, especially those containing shorter intervals. In addition, it is acceptable for the transmission interval of <rtt/> to vary, either intentionally for optimizations, or due to precision limitation. &xep0138; can also be used.</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>Implementors can choose a preferred activation method for real-time text. For example, clients in the assistive market can choose to do immediate activation of real-time text. Popular mainstream clients might do user-initiated activation/confirmation of real-time text. The confirmation process could be similar to common activation methods used for audio/video. It is also beneficial for senders and recipients to easily synchronize the enabling/disabling of real-time text.</p>
|
||||
<p>Implementers can choose a preferred activation method for real-time text. For example, clients in the assistive market can choose to do immediate activation of real-time text. Popular mainstream clients might do user-initiated activation/confirmation of real-time text. The confirmation process could be similar to common activation methods used for audio/video. It is also beneficial for senders and recipients to easily synchronize the enabling/disabling of real-time text.</p>
|
||||
<section3 topic="Activation Methods" anchor="activation_methods">
|
||||
<p>Activation of real-time text in a chat session (immediate or user-initiated) can be done by:</p>
|
||||
<ul>
|
||||
<li>Immediately transmitting real-time text (if allowed after <link url="#determining_support">Determining Support</link>); or</li>
|
||||
<li>Signaling first (by transmitting a single <rtt event='init'/> and waiting for response).</li>
|
||||
</ul>
|
||||
<p>Recipients can respond to incoming real-time text with an appropriate response, such as:</p>
|
||||
<p>Recipient clients can respond to incoming real-time text with an appropriate response, such as:</p>
|
||||
<ul>
|
||||
<li>Accepting immediately (by also activating as well, during the next message); or</li>
|
||||
<li>Accepting after recipient confirmation (by also activating after a user confirmation prompt); or</li>
|
||||
<li>Accepting immediately (by activating in response); or</li>
|
||||
<li>Accepting after recipient confirmation (by also activating in response, after a user confirmation prompt); or</li>
|
||||
<li>Deny (by transmitting <rtt event='cancel'/> which is used in <link url="#deactivation_methods">Deactivation Methods</link>); or</li>
|
||||
<li>Ignoring (by discarding incoming <rtt/> as a last resort, without using <link url="#deactivation_methods">Deactivation Methods</link>).</li>
|
||||
</ul>
|
||||
<p>It is not necessary for senders or recipients to transmit <rtt event='init'/> first, as any incoming <link url="#rtt_element">RTT Element</link> (other than <rtt event='cancel'/>) signals the start of incoming real time text. However, it permits signaling before the sender begins typing. It also permits sender signaling of a desire to begin real-time text, regardless of discovery in <link url="#determining_support">Determining Support</link>.</p>
|
||||
<p>It is acceptable for recipients to display incoming real-time text without activating outgoing real-time text (such as while waiting for user confirmation). Care needs to be taken to prevent this situation from becoming confusing to the user. Implementors can add other additional behaviors that are appropriate, such as an introductory message upon first activation, for <link url="#privacy">Privacy</link> considerations.</p>
|
||||
<p>If <link url="#determining_support">Determining Support</link> allows, then it is not necessary for senders or recipients to transmit <rtt event='init'/> first, as any incoming <link url="#rtt_element">RTT Element</link> (other than <rtt event='cancel'/>) signals the start of incoming real time text. However, it allows signaling of activation before the sender begins typing.</p>
|
||||
<p>In the absence of <link url="#determining_support">Determining Support</link>, sender clients can send a single <rtt event='init'/> element to attempt to activate real-time text. It is inappropriate for sender clients to send any further <rtt/> elements unless support is confirmed by discovery, or when the recipient client responds with incoming <rtt/> elements during the same chat session.</p>
|
||||
<p>It can be acceptable for software to display incoming real-time text without activating outgoing real-time text. Displaying incoming real-time text while waiting for user confirmation, can be educational to users unfamiliar with real-time text. Care needs to be taken to prevent this situation from becoming confusing to the user. Implementers can add other additional behaviors that are appropriate, such as an introductory note upon first activation, for <link url="#privacy">Privacy</link> considerations.</p>
|
||||
</section3>
|
||||
<section3 topic="Deactivation Methods" anchor="deactivation_methods">
|
||||
<p>Real-time text can be deactivated by any of:</p>
|
||||
@ -465,18 +474,18 @@
|
||||
<li>Sending a signal (using <rtt event='cancel'/> upon deactivation, deny, or end of chat session); or</li>
|
||||
<li>Simply ending the chat session (without transmitting any further <rtt/> elements).</li>
|
||||
</ul>
|
||||
<p>Recipients can respond to deactivation by any one or more of the following:</p>
|
||||
<p>Recipient clients can respond to deactivation with appropriate responses, such as:</p>
|
||||
<ul>
|
||||
<li>Deactivating in response (stop transmitting <rtt/> elements); and/or</li>
|
||||
<li>Handling unfinished incoming real-time message (clearing and/or saving it); and/or</li>
|
||||
<li>Inform the recipient that real-time text has ended (or denied/cancelled, if no real-time text was received).</li>
|
||||
<li>Deactivating in response (stop transmitting <rtt/> elements); and</li>
|
||||
<li>Handling any unfinished incoming real-time message (clearing and/or saving it); and</li>
|
||||
<li>Inform the recipient user that real-time text has ended (or denied/cancelled, if no real-time text was received).</li>
|
||||
</ul>
|
||||
<p>Sending an <rtt event='cancel'/> is useful in situations where the user closes a chat window, and ends the chat session. It is useful when the user wants to deactivate real-time text, while still continuing the chat session. After deactivation, either party may reactivate real-time text again in accordance to <link url="#activation_methods">Activation Methods</link>.</p>
|
||||
</section3>
|
||||
</section2>
|
||||
<section2 topic="Optional Remote Cursor" anchor="optional_remote_cursor">
|
||||
<p>Recipient clients might choose to display a cursor (or caret) within incoming real-time messages. This enhances usability of real-time text further, since it becomes easier for a recipient to observe the sender's real-time message edits.</p>
|
||||
<p>Recipient clients that do not support a remote cursor, can simply ignore calculating a cursor position, and skip this section. All action elements only have absolute positioning, and positioning does not depend on previous action elements, so clients do not need to remember the previous cursor position.</p>
|
||||
<p>If a remote cursor is not used, then clients can simply ignore calculating a cursor position and skip this section. All action elements only have absolute positioning, and positioning does not depend on previous action elements, so clients do not need to remember the previous cursor position.</p>
|
||||
<section3 topic="Calculating Cursor Position" anchor="calculating_cursor_position">
|
||||
<p>When <t/>, <e/>, or <d/> action elements are processed in incoming real-time text, the beginning value for the cursor position calculation is the absolute position value of the <em><strong>p</strong></em> attribute, according to <link url="#summary_of_attribute_values">Summary of Attribute Values</link>. The recipient can calculate the cursor position as follows:</p>
|
||||
<ul>
|
||||
@ -486,78 +495,79 @@
|
||||
<em>This is the normal backwards cursor movement to a Backspace key.</em></p></li>
|
||||
<li><p>After <link url="#element_d_forward_delete">Element <d/> – Forward Delete</link>, the cursor position is the <em><strong>p</strong></em> attribute, unaffected by the <em><strong>n</strong></em> attribute.<br />
|
||||
<em>This is the normal stationary cursor response to a Delete key.</em></p></li>
|
||||
<li><p>After an empty <link url="#element_t_insert_text">Element <t/> – Insert Text</link> (in the format of <strong><t p='#'/></strong> with no text to insert), the cursor position is the <strong>p</strong> attribute, and no text modification is done.<br /><em>This allows cursor response to arrow keys and/or mouse repositioning the cursor.</em></p></li>
|
||||
<li><p>After an empty <link url="#element_t_insert_text">Element <t/> – Insert Text</link> (in the format of <strong><t p='#'/></strong> with no text to insert), the cursor position is the <strong>p</strong> attribute, and no text modification is done.<br />
|
||||
<em>This allows cursor response to arrow keys and/or mouse repositioning the cursor.</em></p></li>
|
||||
</ul>
|
||||
<p>The remote cursor needs to be clearly distinguishable from the sender's real local cursor. One example is to use a non-blinking cursor, easily emulated with a Unicode character or the vertical bar character '|'.</p>
|
||||
<p>It is acceptable for the sender to transmit <link url="#element_t_insert_text">Element <t/> – Insert Text</link> as empty elements (with the cursor position in the <em><strong>p</strong></em> attribute) whenever the cursor position is changing without any text modifications (i.e. via arrow keys or mouse). This allows recipients supporting a remote cursor, to show the cursor movements. These extra elements are ignored by recipients that do not support a remote cursor.</p>
|
||||
</section3>
|
||||
</section2>
|
||||
<section2 topic="Real-Time Text Transmission Methodologies" anchor="realtime_text_transmission_methodologies">
|
||||
<section3 topic="Basic Real-Time Text" anchor="basic_realtime_text">
|
||||
<p>Senders may choose to implement <link url="#message_reset">Message Reset</link> as the only method of transmitting changes to real-time message. The entire message is simply retransmitted every <link url="#transmission_interval">Transmission Interval</link> whenever there are any text changes. The below is a transmission of the real-time message “HELLO THERE BOB!” at regular intervals while the sender is typing.</p>
|
||||
<section2 topic="Sending Real-Time Text" anchor="sending_realtime_text">
|
||||
<p>This section lists several possible methods of generating real-time text for transmission. For most situations, the preferred methodology is <link url="#monitoring_message_changes_instead_of_key_presses">Monitoring Message Changes Instead Of Key Presses</link>.</p>
|
||||
<section3 topic="Monitoring Message Changes Instead Of Key Presses" anchor="monitoring_message_changes_instead_of_key_presses">
|
||||
<p>Experience has found that the most reliable method for generating real-time text, is to monitor for <strong>text changes</strong> to the sender’s message entry field, instead of key press events. Text change events have the following advantages:</p>
|
||||
<ul>
|
||||
<li>It captures all typing, including edits and deletes.</li>
|
||||
<li>It captures copy & paste operations, as well as edits made via a pointing device.</li>
|
||||
<li>It captures all automatic text changes (e.g. spell checker, auto-correct, macros, transcription, assistive devices).</li>
|
||||
<li>It captures characters requiring multiple key presses to compose (e.g. accents, combining marks).</li>
|
||||
<li>It makes no assumptions about different keyboards or input method editors (e.g. Chinese).</li>
|
||||
<li>Text change events are more portable across platforms, including on mobile phones.</li>
|
||||
</ul>
|
||||
<p>During a text change event, the sender’s current message text can be compared to the old message text (from before the text change event). In order to calculate what text changes took place, the first changed character and the last changed character is determined. From this, it is possible to generate <link url="#action_elements">Action Elements</link> for any text insertion and deletions. In addition, if <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link> is supported, then <link url="#element_w_wait_interval">Element <w/> – Wait Interval</link> records the time elapsed between text change events.</p>
|
||||
<p>Sender software can do the following:</p>
|
||||
<ol>
|
||||
<li><p>Monitor for text changes in the sender’s message. Whenever a text change event occurs, compute action elements and append these action elements to a buffer. This is equivalent to recording a small sequence of typing.</p></li>
|
||||
<li><p>During every <link url="#transmission_interval">Transmission Interval</link>, all buffered action elements are transmitted in <rtt/> element in a <message/> stanza. This is equivalent to transmitting a small sequence of typing at a time.</p></li>
|
||||
<li><p>If there are no message changes occurring, no unnecessary transmission takes place.</p></li>
|
||||
</ol>
|
||||
</section3>
|
||||
<section3 topic="Monitoring Key Presses Directly" anchor="monitoring_key_presses_directly">
|
||||
<p>Real-time text can be generated via monitoring key presses. However, this does not have the advantages of <link url="#monitoring_message_changes_instead_of_key_presses">Monitoring Message Changes Instead Of Key Presses</link>. Care needs be taken with automatic changes to the message, generated by means other than key presses. This includes spell check auto-correct, copy and pastes, transcription, input method editors, and multiple key presses required to compose a character (i.e. accents). Key press events do not capture these text changes, and this can cause real-time text to go out of sync between the sender and the recipient.</p>
|
||||
</section3>
|
||||
<section3 topic="Basic Real-Time Text" anchor="basic_realtime_text">
|
||||
<p>Sender clients may choose to implement <link url="#message_reset">Message Reset</link> as the only method of transmitting changes to real-time message. The entire message is simply retransmitted every <link url="#transmission_interval">Transmission Interval</link> whenever there are any text changes. The below is a transmission of the real-time message “<strong>Hello there!</strong>” at regular intervals while the sender is typing.</p>
|
||||
<p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
|
||||
<rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
|
||||
<t>HELLO</t>
|
||||
<t>Hel</t>
|
||||
</rtt>
|
||||
</message>
|
||||
|
||||
<message to='bob@example.com' from='alice@example.com/home' type='chat' id='b02'>
|
||||
<rtt xmlns='urn:xmpp:rtt:0' seq='456002' event='reset'>
|
||||
<t>HELLO THERE</t>
|
||||
<t>Hello th</t>
|
||||
</rtt>
|
||||
</message>
|
||||
|
||||
<message to='bob@example.com' from='alice@example.com/home' type='chat' id='c03'>
|
||||
<rtt xmlns='urn:xmpp:rtt:0' seq='789003' event='reset'>
|
||||
<t>HELLO THERE BOB!</t>
|
||||
<t>Hello there!</t>
|
||||
</rtt>
|
||||
</message>]]></code></p>
|
||||
<p>The advantage is very simple sender implementation. However, disadvantages include the lack of <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>, and extra bandwidth consumption that can occur with longer messages.</p>
|
||||
<p>The advantage is very simple implementation. However, disadvantages include the lack of <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>, and extra bandwidth consumption that can occur with longer messages, unless stream compression is used.</p>
|
||||
</section3>
|
||||
<section3 topic="Append-Only Real-Time Text" anchor="appendonly_realtime_text">
|
||||
<p>The use of <link url="#element_t_insert_text">Element <t/> – Insert Text</link> without any attributes, simply appends text to the end of a message, while the use of <link url="#element_e_backspace">Element <e/> – Backspace</link> without any attributes, simply deletes text from the end of the message. This is useful if mid-message editing capabilities are not used (e.g. news tickers, relay services, captioned telephone).</p>
|
||||
<p>If mid-message editing is needed without adding sender support for other <link url="#action_elements">Action Elements</link>, the use of <link url="#message_reset">Message Reset</link> can be a simple solution to support this situation. In this situation, disadvantages include the lack of <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>, and extra bandwidth consumption that can occur with longer messages.</p>
|
||||
<p>The use of <link url="#element_t_insert_text">Element <t/> – Insert Text</link> without any attributes, simply appends text to the end of a message, while the use of <link url="#element_e_backspace">Element <e/> – Backspace</link> without any attributes, simply erases text from the end of the message. These simple action elements are useful if mid-message editing capabilities are not used (e.g. simple transcription, news tickers, relay services, captioned telephone).</p>
|
||||
<p>If editing is needed in the middle of a message, without adding sender support for other <link url="#action_elements">Action Elements</link>, the use of <link url="#message_reset">Message Reset</link> supports situations where mid-message editing takes place. In this situation, the disadvantages include the lack of <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>, and extra bandwidth consumption that can occur with longer messages, unless stream compression is used.</p>
|
||||
</section3>
|
||||
<section3 topic="Monitoring Key Presses Directly" anchor="monitoring_key_presses_directly">
|
||||
<p>Real-time text can be generated via a key press event. However, this does not have the advantages of <link url="#monitoring_message_changes_instead_of_key_presses">Monitoring Message Changes Instead Of Key Presses</link>. Care needs be taken with automatic changes to the message, generated by means other than key presses. This includes spell check auto-correct, copy and pastes, transcription, input method editors, and multiple key presses required to compose a character (i.e. accents). As a result, experience has found that key press events are not the best way to do real-time text over messaging.</p>
|
||||
</section3>
|
||||
<section3 topic="Monitoring Message Changes Instead Of Key Presses" anchor="monitoring_message_changes_instead_of_key_presses">
|
||||
<p>Experience has found that the most reliable and practical method is to monitor the <strong>text changes</strong> to the local message text field, since:</p>
|
||||
<ul>
|
||||
<li>it captures all typing, including edits and deletes.</li>
|
||||
<li>it captures copy & paste operations, as well as edits made via a pointing device.</li>
|
||||
<li>it captures all automatic text changes (e.g. spell check auto-correct, macros, transcription, assistive devices).</li>
|
||||
<li>it captures characters requiring multiple key presses to compose (e.g. accents, combining marks).</li>
|
||||
<li>it makes no assumptions about different keyboards or input method editors (e.g. Chinese).</li>
|
||||
<li>text change events are more portable across platforms, including on mobile phones.</li>
|
||||
</ul>
|
||||
<p>During a text change event, the current message string can be compared to the previous message string, in order to calculate what text changes took place. The first changed character and last changed character is determined. From this, it is then possible to generate action elements for text insertion and deletions. In addition, if <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link> are supported, then the interval is implemented as the time elapsed between text change events. For additional information, see <link url="#action_elements">Action Elements</link> and <link url="#summary_of_attribute_values">Summary of Attribute Values</link>.</p>
|
||||
<section4 topic="Suggested Guidelines for Senders" anchor="suggested_guidelines_for_senders">
|
||||
<ul>
|
||||
<li><p>Monitor the message change event. Whenever message change occur, compute action elements and add these action elements to a buffer. This is equivalent to recording a small sequence of typing.</p></li>
|
||||
<li><p>During every <link url="#transmission_interval">Transmission Interval</link>, all buffered action elements are transmitted in <rtt/> element of a <message/>. This is equivalent to transmitting a small sequence of typing at a time.</p></li>
|
||||
<li><p>If there are no changes to the real-time message, then no unnecessary <rtt/> transmission takes place.</p></li>
|
||||
</ul>
|
||||
</section4>
|
||||
<section4 topic="Suggested Guidelines for Receivers" anchor="suggested_guidelines_for_receivers">
|
||||
<ul>
|
||||
<li><p>Upon receving <rtt/> elements, the action elements are added to a queue, in the order that they are received. This provides immunity to variable network conditions, since the buffering action smooths out the latency fluctuations of message transmission.</p></li>
|
||||
<li><p>The recipient software interprets the action elements in the queue in sequential order, including pauses from <link url="#element_w_interval">Element <w/> – Interval</link>. This is equivalent to playing back the sender's original typing, including key press intervals.</p></li>
|
||||
<li><p>Upon receiving a <body/> element indicating a completed message, the full message can be displayed immediately in place of the real-time message, and unprocessed action elements cleared from the playback queue. This ensures final message delivery is not delayed by late processing of action elements.</p></li>
|
||||
<li><p>If the playback queue contains too much delay in <w/> elements (i.e. <w/> elements from two <rtt/> transmissions ago), the recipient client can ignore or shorten the intervals of <w/> elements, to allow lagged real-time text to "catch up" more quickly.</p></li>
|
||||
<li><p>It is best to process <link url="#element_w_interval">Element <w/> – Interval</link> via non-blocking programming techniques.</p></li>
|
||||
</ul>
|
||||
</section4>
|
||||
</section3>
|
||||
</section2>
|
||||
<section2 topic="Receiving Real-Time Text" anchor="receiving_realtime_text">
|
||||
<p>In order to allow <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link> in incoming real-time text, recipient clients can do the following:</p>
|
||||
<ol>
|
||||
<li><p>Upon receiving <link url="#action_elements">Action Elements</link> in incoming <rtt/> elements, they are added to a queue in the order they are received. This provides immunity to variable network conditions, since the queueing action smooth out the latency fluctuations of incoming transmission.</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 <w/> – 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 <body/> can be displayed immediately in place of the real-time message, and unprocessed action elements can be cleared from the queue. This ensures final message delivery is not delayed by late processing of action elements.</p></li>
|
||||
</ol>
|
||||
<p>In processing <link url="#element_w_wait_interval">Element <w/> – Wait Interval</link>, excess lag in incoming real-time text might occur if multiple delayed <rtt/> elements suddenly get delivered (e.g. congestion, intermittent wireless reception). Recipients can avoid excess lag by monitoring the queue for excess <w/> action elements (e.g. unprocessed <w/> elements from two <rtt/> elements ago) and then ignoring or shortening the intervals in <w/> elements. This allows lagged real-time text to "catch up" more quickly. In addition, it is best to process <w/> elements using non-blocking programming techniques.</p>
|
||||
</section2>
|
||||
<section2 topic="Other Guidelines" anchor="other_guidelines">
|
||||
<p><link name="_Hlk168620696"></link>There are other special basic considerations for real-time message transmissions that need to be considered by implementors.</p>
|
||||
<p><link name="_Hlk168620696"></link>There are other special basic considerations for real-time message transmissions that need to be considered by implementers.</p>
|
||||
<section3 topic="Message Length" anchor="message_length">
|
||||
<p>A large sequence of action elements can result in an <rtt/> larger than the size of a message <body/>. This can occur normally during fast typing when <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link> during small messages. However, if the <rtt/> element becomes unusually huge (e.g. macros, multiple copy and pastes, leading to an <rtt/> exceeding one kilobyte) a <link url="#message_reset">Message Reset</link> can instead be used, in order to save bandwidth. (Stream compression is another approach.)</p>
|
||||
<p>Clients can limit the length of the text input for the sender's message, in order to keep the size of <message/> stanzas reasonable, including during <link url="#message_reset">Message Reset</link>. Also, large <rtt/> elements may occur in situations such as large copy and pastes. To keep message stanza sizes reasonable, <rtt/> can be transmitted in a separate <message/> than the one containing <body/>.</p>
|
||||
<p>For specialized clients that sends continuous real-time text (e.g. news ticker, captioning, transcription, TTY gateway), an automatic-send feature can be implemented when messages reaches a certain length. This allows continuous real-time text without real-time messages becoming excessively large.</p>
|
||||
<p>For specialized clients that send continuous real-time text (e.g. news ticker, captioning, transcription, TTY gateway), a <link url="#body_element">Body Element</link> can be automatically sent when messages reach a certain length. 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">
|
||||
<section3 topic="Usage with Chat States" anchor="usage_with_chat_states">
|
||||
<p>Real-time text can be used in conjunction with XEP-0085 &xep0085;. These are simple guidelines for <message/> stanzas that include an <rtt/> element:</p>
|
||||
<ul>
|
||||
<li>For <rtt/> transmitted without an accompanying <body/>, include <composing/> chat state.</li>
|
||||
@ -565,10 +575,10 @@
|
||||
<li>Other chat states are handled as specified by XEP-0085 Chat States.</li>
|
||||
</ul>
|
||||
</section3>
|
||||
<section3 topic="Usage With Multi-User Chat and Simultaneous Logins" anchor="usage_with_multiuser_chat_and_simultaneous_logins">
|
||||
<section3 topic="Usage with Multi-User Chat and Simultaneous Logins" anchor="usage_with_multiuser_chat_and_simultaneous_logins">
|
||||
<p>The in-band nature of this real-time text standard allows one-to-many situations. Thus, real-time text is appropriate for use with &xep0045; (MUC), as well as concurrent simultaneous logins.</p>
|
||||
<section4 topic="Multi-User Chat" anchor="multiuser_chat">
|
||||
<p>Clients can implement this specification only for one-on-one chat. However, it is appropriate to support <rtt/> 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. As a result, participants with real-time text, will see real-time text coming from each participant that have real-time text enabled. Participants that turn off real-time text for themselves, can simply ignore incoming <rtt/> and not transmit outgoing <rtt/>. 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>. For the same participant logged in multiple times in the same room, see <link url="#simultaneous_logins">Simultaneous Logins</link>. For <rtt/> elements, the <link url="#event">event</link> attribute of 'init' or 'cancel' is not appropriate for MUC since they are intended for one-on-one use. 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. Prioritization can be recent typists and/or moderators (e.g. classroom teacher, convention speaker). In situations of simultaneous typing by a large number of participants, see <link url="#congestion_considerations">Congestion Considerations</link>.</p>
|
||||
<p>For simplicity, clients can implement real-time text only for one-on-one chat, and not for MUC. However, it can be appropriate to support <rtt/> 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. Participants that turn off real-time text for themselves, can simply ignore incoming <rtt/> and not transmit outgoing <rtt/>. 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>. For the same participant logged in multiple times in the same room, see <link url="#simultaneous_logins">Simultaneous Logins</link>. Participant clients in MUC receiving an <rtt <link url="#event">event</link>=’cancel’/> should not automatically turn off outgoing real-time text (otherwise, one participant could deny real-time text between other willing participants). 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). 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 <rtt/> works in one-to-many situations without any special software support. For many-to-one situations where there is incoming <rtt/> 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 <rtt/>, and resume during the next <link url="#message_reset">Message Reset</link>, presumably from the active login. This provides a seamless system-switching experience. A good implementation of <link url="#message_reset">Message Reset</link> will improve user experience, regardless of whether or not the client follows Best Practices For Resource Locking (XEP-0296). Clients can choose to distinguish the <rtt/> streams (via full JID and/or via <thread/>) 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>
|
||||
@ -577,13 +587,13 @@
|
||||
<section3 topic="Stale Messages" anchor="stale_messages">
|
||||
<p>There are situations where senders pause typing indefinitely. This can result in recipients displaying a real-time message for an extended time period. It may also be a screen clutter concern during <link url="#multiuser_chat">Multi-User Chat</link>. In addition, it may be a resource-consumption concern, as part of <link url="#congestion_considerations">Congestion Considerations</link>.</p>
|
||||
<p>It is acceptable for recipients to clear (and/or save) incoming real-time messages that have been idle for an extended time period. There is no specific time-out period defined by this specification. For <link url="#multiuser_chat">Multi-User Chat</link>, the time-out period might be shorter because of the need to reduce screen clutter. For normal chat sessions, the time-out period might need to be longer to allow reasonable interruptions (i.e. sender pausing during a long phone call).</p>
|
||||
<p>Senders that resumes composing a message (i.e. continues a partially-composed message hours later) can transmit a <link url="#message_reset">Message Reset</link>, which allows recipients to redisplay the real-time message.</p>
|
||||
<p>Senders that resume composing a message (i.e. continues a partially-composed message hours later) can transmit a <link url="#message_reset">Message Reset</link>, which allows recipients to redisplay the real-time message.</p>
|
||||
</section3>
|
||||
<section3 topic="Performance & Efficiency" anchor="performance_efficiency">
|
||||
<p>With real-time text, frequent screen updates may occur. Screen updates are a potential performance bottleneck, because fast typists type many key presses per second. Optimizing screen updates becomes especially important for slower platforms. Real-time messages needs to be updated efficiently in a flicker-free manner. Alternatively, to improve performance, the display of real-time messages may 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 may impact battery life. If <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link> are supported, then the implementation of <link url="#element_w_interval">Element <w/> – Interval</link> needs to be implemented in a battery-efficient manner. The <link url="#transmission_interval">Transmission Interval</link> may 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. Also see &xep0286;.</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 becomes especially important for slower platforms. Real-time messages need to be displayed efficiently in a flicker-free manner. 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 may impact battery life. If <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link> are supported, then the implementation of <link url="#element_w_wait_interval">Element <w/> – Wait Interval</link> needs to be implemented in a battery-efficient manner. The <link url="#transmission_interval">Transmission Interval</link> may 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>
|
||||
<section3 topic="Total Conversation – Combination With Audio And Video" anchor="total_conversation_combination_with_audio_and_video">
|
||||
<section3 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” accessibility standard defines the simultaneous use of audio, video, and real-time text. For convenience, messaging applications may be designed to have automatic negotiation of as many as possible of the three media preferred by the users.</p>
|
||||
<p>In the XMPP session environment, the Jingle protocol (&xep0166;) is available for negotiation and transport of the more time-critical, real-time audio and video media. Any combination of audio, video, and real-time text can be used together simultaneously.</p>
|
||||
</section3>
|
||||
@ -592,7 +602,7 @@
|
||||
<section1 topic="Use Cases" anchor="use_cases">
|
||||
<p>Most of these examples are deliberately kept simple. In complete software implementations supporting key press intervals, transmissions will most resemble the last example, <link url="#full_message_including_key_press_intervals">Full Message Including Key Press Intervals</link>.</p>
|
||||
<section2 topic="Example of Simple Real Time Text" anchor="example_of_simple_real_time_text">
|
||||
<p>All three examples shown below result in the same real-time message "<strong>HELLO</strong>" created by writing "<strong>HLL</strong>", backspacing two times, and then "<strong>ELLO</strong>".</p>
|
||||
<p>All three examples shown below result in the same real-time message "<strong>HELLO</strong>" created by writing "<strong>HLL</strong>", backspacing two times, and then "<strong>ELLO</strong>". The action elements are <link url="#element_t_insert_text">Element <t/> – Insert Text</link> and <link url="#element_e_backspace">Element <e/> – Backspace</link>.</p>
|
||||
<p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
|
||||
<rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
|
||||
<t>HLL</t>
|
||||
@ -600,10 +610,10 @@
|
||||
<t>ELLO</t>
|
||||
</rtt>
|
||||
</message>]]></code></p>
|
||||
|
||||
|
||||
|
||||
|
||||
<p>The above code sends the misspelled "<strong>HLL</strong>", then <strong><e/><e/></strong> backspaces 2 times, then sends "<strong>HELLO</strong>".</p>
|
||||
<p>The example above sends the misspelled "<strong>HLL</strong>", then <strong><e/><e/></strong> backspaces 2 times, then sends "<strong>HELLO</strong>".</p>
|
||||
<p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
|
||||
<rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
|
||||
<t>HLL</t>
|
||||
@ -611,10 +621,10 @@
|
||||
<t>ELLO</t>
|
||||
</rtt>
|
||||
</message>]]></code></p>
|
||||
|
||||
|
||||
|
||||
|
||||
<p>The above code shows that <strong><e n='2'/></strong> does the same thing as <strong><e/><e/></strong>.</p>
|
||||
<p>The example above shows that <strong><e n='2'/></strong> does the same thing as <strong><e/><e/></strong>.</p>
|
||||
<p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
|
||||
<rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
|
||||
<t>HLL</t>
|
||||
@ -632,13 +642,13 @@
|
||||
<t>ELLO</t>
|
||||
</rtt>
|
||||
</message>]]></code></p>
|
||||
|
||||
|
||||
|
||||
|
||||
<p>The above code splits the same real-time text over multiple stanzas, which would occur if the typing was occurring more slowly, over several <link url="#transmission_interval">Transmission Interval</link> cycles.</p>
|
||||
<p>The example above splits the same real-time text over multiple <message/> stanzas, which would occur if the typing was occurring more slowly, over several <link url="#transmission_interval">Transmission Interval</link> cycles.</p>
|
||||
</section2>
|
||||
<section2 topic="Example of Multiple Messages" anchor="example_of_multiple_messages">
|
||||
<p>The below example represents a short chat session of three separate messages:<br />
|
||||
<p>The example below represents a short chat session of three separate messages:<br />
|
||||
Bob says: "Hello Alice"<br />
|
||||
Bob says: "This is Bob"<br />
|
||||
Bob says: "How are you?"</p>
|
||||
@ -648,7 +658,7 @@
|
||||
</rtt>
|
||||
<composing/>
|
||||
</message>
|
||||
|
||||
|
||||
<message to='alice@example.com' from='bob@example.com/home' type='chat' id='b02'>
|
||||
<rtt xmlns='urn:xmpp:rtt:0' seq='123002'>
|
||||
<t> Alice</t>
|
||||
@ -656,14 +666,15 @@
|
||||
<body>Hello Alice</body>
|
||||
<active/>
|
||||
</message>
|
||||
|
||||
|
||||
|
||||
<message to='alice@example.com' from='bob@example.com/home' type='chat' id='c03'>
|
||||
<rtt xmlns='urn:xmpp:rtt:0' seq='456001' event='new'>
|
||||
<t>This i</t>
|
||||
</rtt>
|
||||
<composing/>
|
||||
</message>
|
||||
|
||||
|
||||
<message to='alice@example.com' from='bob@example.com/home' type='chat' id='d04'>
|
||||
<rtt xmlns='urn:xmpp:rtt:0' seq='456002'>
|
||||
<t>s Bob</t>
|
||||
@ -671,21 +682,22 @@
|
||||
<body>This is Bob</body>
|
||||
<active/>
|
||||
</message>
|
||||
|
||||
|
||||
|
||||
<message to='alice@example.com' from='bob@example.com/home' type='chat' id='e05'>
|
||||
<rtt xmlns='urn:xmpp:rtt:0' seq='789001' event='new'>
|
||||
<t>How a</t>
|
||||
</rtt>
|
||||
<composing/>
|
||||
</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/>
|
||||
</message>
|
||||
|
||||
|
||||
<message to='alice@example.com' from='bob@example.com/home' type='chat' id='g07'>
|
||||
<rtt xmlns='urn:xmpp:rtt:0' seq='789003'>
|
||||
<t>u?</t>
|
||||
@ -693,18 +705,20 @@
|
||||
<body>How are you?</body>
|
||||
<active/>
|
||||
</message>]]></code></p>
|
||||
|
||||
|
||||
|
||||
|
||||
<p>This is based on a moderate typing speed transmitted at a normal <link url="#transmission_interval">Transmission Interval</link>. This example also illustrates the following:</p>
|
||||
<p>The example above represents moderate typing speed during a normal <link url="#transmission_interval">Transmission Interval</link>, such as 0.7 seconds between <message/> stanzas for continuous typing. It illustrates the following:</p>
|
||||
<ul>
|
||||
<li>The <strong>type</strong> attribute equals 'new' for the start of every new message.</li>
|
||||
<li>The <strong>seq</strong> attribute increments during the same message.</li>
|
||||
<li>The <strong>event</strong> attribute indicating the start of a new message, while <strong>seq</strong> is randomized to a new starting value.</li>
|
||||
<li>This shows <link url="#usage_with_chat_states">Usage With Chat States</link>.</li>
|
||||
<li>The <strong><link url="#event">event</link></strong> attribute equals 'new' for the start of every new message.</li>
|
||||
<li>The <strong><link url="#seq">seq</link></strong> attribute increments within the same message.</li>
|
||||
<li>The <strong><link url="#seq">seq</link></strong> attribute randomizes when beginning of 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">
|
||||
<p>These examples illustrate real-time message editing via <link url="#action_elements">Action Elements</link>.<br />
|
||||
Note: In most situations, during normal human typing speeds at a normal <link url="#transmission_interval">Transmission Interval</link>, smaller fragments of text will be spread over multiple <rtt/>, than these demonstration <rtt/> examples below. See <link url="#sending_realtime_text">Sending Real-Time Text</link>.</p>
|
||||
<section3 topic="Deleting Text From Message" anchor="deleting_text_from_message">
|
||||
<p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
|
||||
<rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
|
||||
@ -712,27 +726,29 @@
|
||||
<d n='4' p='5'/>
|
||||
</rtt>
|
||||
</message>]]></code></p>
|
||||
|
||||
|
||||
|
||||
|
||||
<p>Final result of real-time message: "<strong>Hello, this is Alice!</strong>"<br />
|
||||
This code outputs "<strong>Hello Bob, this is Alice!</strong>" then <strong><d n='4' p='5'/></strong> deletes 4 characters from position 5.<br />
|
||||
(This erases the text " <strong>Bob</strong>" including the preceding space character).</p>
|
||||
This example outputs "<strong>Hello Bob, this is Alice!</strong>" then <strong><d n='4' p='5'/></strong> deletes 4 characters from position 5. The <link url="#element_d_forward_delete">Element <d/> – Forward Delete</link> removes the text " <strong>Bob</strong>" including the preceding space character.</p>
|
||||
</section3>
|
||||
<section3 topic="Inserting Text Into Message" anchor="inserting_text_into_message">
|
||||
|
||||
|
||||
|
||||
<p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
|
||||
<rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
|
||||
<t>Hello, this is Alice!</t>
|
||||
<t p='5'> Bob</t>
|
||||
</rtt>
|
||||
</message>]]></code></p>
|
||||
|
||||
|
||||
|
||||
|
||||
<p>Final result of real-time message: "<strong>Hello Bob, this is Alice!</strong>"<br />
|
||||
This is because the code outputs "<strong>Hello, this is Alice!</strong>" then the <strong><t p='5'></strong> inserts the specified text " <strong>Bob</strong>" at position 5.</p>
|
||||
This is because this example outputs "<strong>Hello, this is Alice!</strong>" then the <strong><t p='5'></strong> inserts the specified text " <strong>Bob</strong>" at position 5, using <link url="#element_t_insert_text">Element <t/> – Insert Text</link>.</p>
|
||||
</section3>
|
||||
<section3 topic="Deleting And Replacing Text In Message" anchor="deleting_and_replacing_text_in_message">
|
||||
<section3 topic="Deleting and Replacing Text In Message" anchor="deleting_and_replacing_text_in_message">
|
||||
<p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
|
||||
<rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
|
||||
<t>Hello Bob, tihsd is Alice!</t>
|
||||
@ -740,16 +756,14 @@
|
||||
<t p='11'>this</t>
|
||||
</rtt>
|
||||
</message>]]></code></p>
|
||||
|
||||
|
||||
|
||||
|
||||
<p>Final result of real-time message: "<strong>Hello Bob, this is Alice!</strong>"<br />
|
||||
This code outputs "<strong>Hello Bob, tihsd is Alice!</strong>", then <strong><d p='11' n='5'/></strong> deletes 5 characters at position 11 in the string of text. (erases the mistyped word "<strong>tihsd</strong>"). Finally, <strong><t p='11'>this</t></strong> inserts the text "<strong>this</strong>" place of the original misspelled word.</p>
|
||||
This example outputs "<strong>Hello Bob, tihsd is Alice!</strong>", then <strong><d p='11' n='5'/></strong> deletes 5 characters at position 11 in the string of text (which erases the mistyped word "<strong>tihsd</strong>"). Finally, <strong><t p='11'>this</t></strong> inserts the text "<strong>this</strong>" place of the original misspelled word.</p>
|
||||
</section3>
|
||||
</section2>
|
||||
<section2 topic="Examples of Full Spec Support" anchor="examples_of_full_spec_support">
|
||||
<section3 topic="Multiple Message Edits" anchor="multiple_message_edits">
|
||||
<p>This is an example message containing multiple consecutive real-time message edits.</p>
|
||||
<section3 topic="Multiple Message Edits" anchor="multiple_message_edits">
|
||||
<p>This is an example message containing multiple consecutive real-time message edits. This illustrates valid use of the <rtt/> element.</p>
|
||||
<p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
|
||||
<rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
|
||||
<t>Helo</t>
|
||||
@ -761,10 +775,10 @@
|
||||
<t p='5'> there,</t>
|
||||
</rtt>
|
||||
</message>]]></code></p>
|
||||
|
||||
|
||||
|
||||
|
||||
<p>Resulting real-time message: "<strong>Hello there, World</strong>", completed in the following series of steps:</p>
|
||||
<p>Resulting real-time message: "<strong>Hello there, World</strong>", completed in the following series of action elements:</p>
|
||||
<table>
|
||||
<tr>
|
||||
<th>Element</th>
|
||||
@ -815,17 +829,49 @@
|
||||
<td>12</td>
|
||||
</tr>
|
||||
</table>
|
||||
<p>Normally, the action elements are split into multiple separate transmissions. This example also does not illustrate <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>. *The Cursor Position column is only relevant if the <link url="#optional_remote_cursor">Optional Remote Cursor</link> is implemented.</p>
|
||||
<p>*The Cursor Position column is only relevant if the <link url="#optional_remote_cursor">Optional Remote Cursor</link> is implemented.</p>
|
||||
<p>This example does not illustrate <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>. Also, it is noted that most situations, during normal typing speeds at a normal <link url="#transmission_interval">Transmission Interval</link>, the series of <link url="#action_elements">Action Elements</link> will typically be spread over multiple separate <rtt/> elements.</p>
|
||||
</section3>
|
||||
</section2>
|
||||
<section2 topic="Examples of Key Press Intervals" anchor="examples_of_key_press_intervals">
|
||||
<section3 topic="Comparison With and Without Intervals" anchor="comparison_with_and_without_intervals">
|
||||
<p>All examples shown below, result in the same real-time message “<strong>HELLO</strong>”. Only the last example follows <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>.</p>
|
||||
<p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
|
||||
<rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
|
||||
<t>HELLO</t>
|
||||
</rtt>
|
||||
</message>]]></code></p>
|
||||
<p>The above example outputs “<strong>HELLO</strong>” in a single action element (<link url="#element_t_insert_text">Element <t/> – Insert Text</link>).</p>
|
||||
<p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
|
||||
<rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
|
||||
<t>H</t>
|
||||
<t>E</t>
|
||||
<t>L</t>
|
||||
<t>L</t>
|
||||
<t>O</t>
|
||||
</rtt>
|
||||
</message>]]></code></p>
|
||||
<p>The above example outputs “<strong>HELLO</strong>” in separate action elements for each key press.</p>
|
||||
<p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
|
||||
<rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
|
||||
<t>H</t><w n='101'/>
|
||||
<t>E</t><w n='110'/>
|
||||
<t>L</t><w n='125'/>
|
||||
<t>L</t><w n='103'/>
|
||||
<t>O</t><w n='110'/>
|
||||
</rtt>
|
||||
</message>]]></code></p>
|
||||
<p>The above example outputs “<strong>HELLO</strong>” in separate action elements for each key press, while also <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>. The <link url="#element_w_wait_interval">Element <w/> – Wait Interval</link> specifies the number of milliseconds between key presses, to allow smooth presentation in recipient clients that support <w/> action elements.</p>
|
||||
</section3>
|
||||
<section3 topic="Full Message Including Key Press Intervals" anchor="full_message_including_key_press_intervals">
|
||||
<p>This example is a transmission of “Hello there!” while <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>. It illustrates a four-second typing sequence:</p>
|
||||
<ul>
|
||||
<li>The misspelled phrase “Hello tehre!” is typed;</li>
|
||||
<li>Three cursor-left movements back to the typing mistake;</li>
|
||||
<li>Optional transmission of cursor movements towards the typing mistake;</li>
|
||||
<li>Two backspaces to delete the typing mistake;</li>
|
||||
<li>Two correct key presses to correctly spell the word “there”.</li>
|
||||
</ul>
|
||||
<p>In between each key press, is <link url="#element_w_interval">Element <w/> – Interval</link> to allow the receiving client execute a small pause between action elements, which allows the playback of the typing at its original look-and-feel.</p>
|
||||
<p>The use <link url="#element_w_wait_interval">Element <w/> – Wait Interval</link>, between key presses, allows the receiving client execute a small pause between action elements. This allows recipient clients to play back the sender's typing fluidly.</p>
|
||||
<p><code><![CDATA[<message to='bob@example.com' from='alice@example.com/home' type='chat' id='a01'>
|
||||
<rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
|
||||
<t>H</t>
|
||||
@ -875,34 +921,31 @@
|
||||
</rtt>
|
||||
<body>Hello there!</body>
|
||||
</message>]]></code></p>
|
||||
|
||||
|
||||
|
||||
|
||||
<p>This example also illustrate the following:</p>
|
||||
<p>This example also illustrates the following:</p>
|
||||
<ul>
|
||||
<li>Typing is done via <link url="#element_t_insert_text">Element <t/> – Insert Text</link>.</li>
|
||||
<li>Backspaces are done via <link url="#element_e_backspace">Element <e/> – Backspace</link>.</li>
|
||||
<li>There is a final transmission with a <link url="#body_element">Body Element</link>, when the message is finished.</li>
|
||||
<li>Intervals between key presses are done via <link url="#element_w_interval">Element <w/> – Interval</link>.</li>
|
||||
<li>Each <message/> is delivered every 0.7 seconds, the default <link url="#transmission_interval">Transmission Interval</link>.</li>
|
||||
<li>Cursor movements are done via empty <t/> elements, for an <link url="#optional_remote_cursor">Optional Remote Cursor</link>.</li>
|
||||
<li>Recipient that do not support <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>, will still display this message normally.</li>
|
||||
<li>The total sum of all values in <link url="#element_w_interval">Element <w/> – Interval</link> in one <message/> equal the <link url="#transmission_interval">Transmission Interval</link> during periods of continuous typing. This also results in some <w/> interval elements being split between consecutive messages. Although not critical, it can improve the fluidity of typing playback</li>
|
||||
<li>Intervals between key presses are done via <link url="#element_w_wait_interval">Element <w/> – Wait Interval</link>.</li>
|
||||
<li>Each <message/> is delivered at a regular <link url="#transmission_interval">Transmission Interval</link>, typically 0.7 seconds.</li>
|
||||
<li>Cursor movements via empty <t/> elements. Sender transmission is not essential, but can be desirable for recipient clients supporting an <link url="#optional_remote_cursor">Optional Remote Cursor</link>.</li>
|
||||
<li>Recipient clients that do not support <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link> and/or <link url="#optional_remote_cursor">Optional Remote Cursor</link>, will still display this message normally.</li>
|
||||
<li>The total sum of all values in <link url="#element_w_wait_interval">Element <w/> – Wait Interval</link> in one <message/> equal the <link url="#transmission_interval">Transmission Interval</link> during periods of continuous typing. This also results in some <w/> interval elements being split between consecutive messages. Although not critical, it can further improve the fluidity of <link url="#receiving_realtime_text">Receiving Real-Time Text</link>.</li>
|
||||
<li>See <link url="#monitoring_message_changes_instead_of_key_presses">Monitoring Message Changes Instead Of Key Presses</link> for more info.</li>
|
||||
</ul>
|
||||
</section3>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic="Interoperability Considerations" anchor="interoperability_considerations">
|
||||
<p>There are other real-time text formats with interoperability considerations relating to the session setup level, the media transport level, and presentation level. For each environment where interoperability is supported, an interoperability specification needs to be documented that covers addressing, session control, media negotiation and media transcoding.</p>
|
||||
<section2 topic="Other Real-Time Text Standards" anchor="other_realtime_text_standards">
|
||||
<p>It is noted there is also another real-time text standard (RFC 4103, <span class="ref"><strong><link url="http://tools.ietf.org/html/rfc5194">IETF RFC 5194</link></strong></span> <note>IETF RFC 5194: Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP). <<link url="http://tools.ietf.org/html/rfc5194">http://tools.ietf.org/html/rfc5194</link>>.</note>), used for SIP sessions with real-time text. In the situation where an implementor needs to decide which real-time text standard to use, it makes sense to use the real-time text specification of the specific session control standard in use for that particular session. This varies from implementation to implementation. For example, Google Talk network uses XMPP messaging for instant messages sent during audio/video conversations. Therefore, in this situation, it makes sense to use this XEP-0301 specification to add real-time text functionality. However, there can be situations where it is necessary to support multiple real-time-text standards, and to interoperate between the multiple real-time text standards.</p>
|
||||
</section2>
|
||||
<section2 topic="RFC 4103 and T.140" anchor="rfc_4103_and_t140">
|
||||
<p>One environment for interoperability considerations is SIP with real-time text (also called Text over IP, or ToIP) as specified in ITU-T T.140 and IETF RFC 4103. This protocol combination is specified by IETF, and by some emergency service organizations, to be one of the protocols supported for IP based real-time emergency calls that support real-time text. Another reason is that SIP is a popular real-time session control protocol. Also, there are many implementations of real-time text that is being controlled by SIP.</p>
|
||||
<p>Interoperability implies addressing translation, media negotiation and translation, and media transcoding. For media transcoding between this specification and T.140/RFC 4103, the real-time text transcoding is straight forward, except the editing feature of this specification. Backwards positioning and insertion or deletion far back in the message can cause a large number of erase operations in T.140, that takes time and bandwidth to convey.</p>
|
||||
<p>It is noted that T.140 specifies the use of ISO 6429 control codes for presentation characteristics, such as text color, that are not covered in this version of this specification. All control codes from both sides that cannot be presented on the other side of the conversion, needs to be filtered off in order to not disturb the presentation of text.</p>
|
||||
<p>Also, see <link url="#total_conversation_combination_with_audio_and_video">Total Conversation – Combination With Audio And Video</link>.</p>
|
||||
<p>There are other real-time text formats with interoperability considerations relating to the session setup level, the media transport level, and presentation level. Interoperability specifications between multiple real-time text formats can be found in the Interoperability section of <span class="ref"><strong><link url="http://www.realtimetext.org">Real-Time Text Taskforce</link></strong></span>
|
||||
<note>Real-Time Text Taskforce, a foundation for real-time text standardization - <<link url="http://www.realtimetext.org">http://www.realtimetext.org</link>>.</note>.</p>
|
||||
<p>It is appropriate for implementers to choose the most appropriate real-time text standard for the session control standard in use during a particular session. Clients that use XMPP (e.g. Google Talk) would utilize this XEP-0301 specification. Clients that use SIP can utilize IETF RFC 4103, <span class="ref"><strong><link url="http://tools.ietf.org/html/rfc5194">IETF RFC 5194</link></strong></span> <note>IETF RFC 5194: Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP). <<link url="http://tools.ietf.org/html/rfc5194">http://tools.ietf.org/html/rfc5194</link>>.</note> and ITU-T T.140. Clients that run on multiple networks, may need to utilize multiple real-time text standards. To interoperate between incompatible real-time text standards, gateway servers can transcode between different real-time text standards, along with other media such as audio and video. See <link url="#total_conversation_combination_with_audio_and_video">Total Conversation – Combination with Audio and Video</link>.</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 some emergency service organizations (e.g. Reach 112).</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>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic="Internationalization Considerations" anchor="internationalization_considerations">
|
||||
@ -912,21 +955,21 @@
|
||||
</section1>
|
||||
<section1 topic="Security Considerations" anchor="security_considerations">
|
||||
<section2 topic="Privacy" anchor="privacy">
|
||||
<p>It is important for implementors of real-time text to educate users about real-time text. Users of real-time text needs 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 & 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) before they send the message. With real-time message editing, recipients can watch all text changes that occur in the sender's text, before the sender sends the final message. Implementation behaviors and improved education can be added to reduce privacy issues. Examples include 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 implementers of real-time text to educate users about real-time text. Users of real-time text needs 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 & 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) before they send the message. With real-time message editing, recipients can watch all text changes that occur in the sender's text, before the sender sends the final message. Implementation behaviors and improved education can be added to reduce privacy issues. Examples include 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>
|
||||
</section2>
|
||||
<section2 topic="Encryption" anchor="encryption">
|
||||
<p>Real-time text (<rtt/> elements) transmit the content contained within messages. Therefore, a client that encrypts <body/>, also needs to also encrypt <rtt/> as well:</p>
|
||||
<ul>
|
||||
<li><p>Encryption at the stream level (e.g. TLS) can be used normally with this specification. Stream-level encryption is the most common form of encryption.</p></li>
|
||||
<li><p>Encryption at the stanza level (e.g. &xep0200;) can be used for all stanzas containing either <rtt/> or <body/>. It is worth noting that stanza-level encryption produces significantly more overhead, due to the increased number of stanzas that real-time text causes, leading to <link url="#congestion_considerations">Congestion Considerations</link>.</p></li>
|
||||
<li><p>Encryption at the <message/> stanza level (e.g. deferred XEP-0200) can be used for all stanzas containing either <rtt/> or <body/>. It is worth noting that stanza-level encryption produces significantly more overhead, due to the increased number of stanzas that real-time text causes, leading to <link url="#congestion_considerations">Congestion Considerations</link>.</p></li>
|
||||
<li><p>Encryption at the <body/> level (e.g. deprecated XEP-0027) do not encrypt <rtt/>. In this case, <rtt/> needs to be encrypted separately. It is preferable to use a broader level of encryption, where possible.</p></li>
|
||||
</ul>
|
||||
</section2>
|
||||
<section2 topic="Congestion Considerations" anchor="congestion_considerations">
|
||||
<p>The nature of real-time text result in more frequent transmission of <message/> stanzas than may otherwise happen in a non-real-time text conversation. This may 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_reset">Message Reset</link> can also retransmit real-time text lost by poor network conditions, including stanzas dropped by the server. This is also useful for mission-critical applications such as Next Generation 9-1-1 emergency services.</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_reset">Message Reset</link> can also retransmit real-time text lost by poor network conditions, including stanzas dropped by an overloaded server. This is also useful for mission-critical applications such as Next Generation 9-1-1 emergency services.</p>
|
||||
<p>Excess numbers of real-time messages (e.g. during 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>Use of this specification in the recommended way will cause a load that is only marginally higher than a user communicating without this specification. Bandwidth overhead of real-time text is very low compared to many other activities possible on XMPP networks including in-band file transfers and audio.</p>
|
||||
<p>Use of this specification in the recommended way will cause a load that is only marginally higher than a user communicating without this specification. Bandwidth overhead of real-time text is very low compared to many other activities possible on XMPP networks including in-band file transfers and audio. 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">
|
||||
@ -968,6 +1011,7 @@
|
||||
</xs:restriction>
|
||||
</xs:simpleType>
|
||||
</xs:attribute>
|
||||
<xs:attribute name='id' type='xs:string' use='optional'>
|
||||
<xs:sequence>
|
||||
<xs:element ref='t' minOccurs='0' maxOccurs='unbounded'/>
|
||||
<xs:element ref='e' minOccurs='0' maxOccurs='unbounded'/>
|
||||
@ -1012,9 +1056,9 @@
|
||||
</xs:schema>]]></code></p>
|
||||
</section1>
|
||||
<section1 topic="Acknowledgments" anchor="acknowledgments">
|
||||
<p>The author would like to thank Real-Time Text Taskforce (R3TF) at <link class="western" href="http://www.realtimetext.org/">www.realtimetext.org</link> for their contribution to the technology documented in this specification. Mark Rejhon leads the Jabber/XMPP Taskgroup at R3TF. Members of R3TF who have contributed to this document, include Gunnar Helstrom (Omnitor), Paul E. Jones (Cisco), Gregg Vanderheiden (Trace R&D Center, University of Wisconsin), Barry Dingle (Interopability Leader, R3TF), and Arnoud van Wijk (Founder, R3TF). Others contributors include Bernard Aboba (Microsoft), Austin McKinley (Facebook), Christian Vogler (Gallaudet University), Norm Williams (Gallaudet University).</p>
|
||||
<p>“Natural Typing”, the technique of preserving key press intervals, is acknowledged as an invention by Mark Rejhon, who is deaf. This technology is provided to XMPP.org as part of this specification in compliance of the XSF's Intellectual Property Rights Policy at <link class="western" href="http://xmpp.org/extensions/ipr-policy.shtml">http://xmpp.org/extensions/ipr-policy.shtml</link>.</p>
|
||||
|
||||
<p>The author would like to thank Real-Time Text Taskforce (R3TF) at <link class="western" href="http://www.realtimetext.org/">www.realtimetext.org</link> for their contribution to the technology documented in this specification. Mark Rejhon leads the Jabber/XMPP Taskgroup at R3TF. Members of R3TF who have contributed to this document include Gunnar Helstrom (Omnitor), Paul E. Jones (Cisco), Gregg Vanderheiden (Trace R&D Center, University of Wisconsin), Barry Dingle (Interopability Leader, R3TF), and Arnoud van Wijk (Founder, R3TF). Others contributors include Bernard Aboba (Microsoft), Darren Sturman (Teligent Telecom), Christian Vogler (Gallaudet University), Norm Williams (Gallaudet University), and several members from the XMPP Standards Mailing List, including Kevin Smith (XSF), Peter Saint Andre (XSF), and many others.</p>
|
||||
<p>“Natural Typing”, the technique of <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>, is acknowledged as an invention by Mark Rejhon, who is deaf. This technology is provided to XMPP.org as part of this specification in compliance of the XSF's Intellectual Property Rights Policy at <link class="western" href="http://xmpp.org/extensions/ipr-policy.shtml">http://xmpp.org/extensions/ipr-policy.shtml</link>.</p>
|
||||
|
||||
|
||||
</section1>
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user