moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-24 10:12:19 -05:00
Code Issues Releases Wiki Activity

0.7

Browse Source
This commit is contained in:
Peter Saint-Andre 2012-08-09 08:58:36 -06:00
parent ed79155100
commit 05fb4901a2
1 changed files with 66 additions and 72 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

138
xep-0301.xml
View File

@ -28,10 +28,16 @@
<jid>markybox@gmail.com</jid>
<uri>http://www.realjabber.org</uri>
</author>
<revision>
<version>0.7</version>
<date>2012-08-08</date>
<initials>MDR</initials>
<remark><p>Simplifications and grammatical corrections. Some sections (1, 6.2, 6.4) shortened with simpler language.</p></remark>
</revision>
<revision>
<version>0.6</version>
<date>2012-07-28</date>
<initials>MDR</initials>
<initials>MDR</initials>
<remark><p>Changes and improvements in preparation for advance to Draft. Unified
&lt;e/&gt; element (Erase Text) to handle all possible text deletions.
Clarify the Unicode terminology used in this specification, and move
@ -92,20 +98,18 @@
<section1 topic="Introduction" anchor="introduction">
<p>This document defines a specification for real-time text transmitted in-band over an XMPP network.</p>
<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.</p>
<p>Real-time text has been around for decades in various implementations:</p>
<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. 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>
<li>ICQ had a peer-to-peer split screen mode from 1996-1999.</li>
<li>TTY and text telephones for the deaf and hard of hearing.</li>
<li>TTY and text telephones.</li>
<li>For SIP, real-time text is sent using <span class="ref"><strong><link url="http://tools.ietf.org/html/rfc4103">IETF RFC 4103</link></strong></span> <note>RFC 4103: RTP Payload for Text Conversation. &lt;<link url="http://tools.ietf.org/html/rfc4103">http://tools.ietf.org/html/rfc4103</link>&gt;.</note> with <span class="ref"><strong><link url="http://www.itu.int/rec/T-REC-T.140">ITU-T T.140</link></strong></span> <note>ITU-T T.140: Protocol for multimedia application text conversation. &lt;<link url="http://www.itu.int/rec/T-REC-T.140">http://www.itu.int/rec/T-REC-T.140</link>&gt;.</note> presentation coding.</li>
<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&amp;externalId=223568">AOL Real-Time IM</link></strong></span> <note>AOL AIM Real Time Text: &lt;<link url="http://help.aol.com/help/microsites/microsite.do?cmd=displayKC&amp;externalId=223568">http://help.aol.com/help/microsites/microsite.do?cmd=displayKC&amp;externalId=223568</link>&gt;.</note> feature.</li>
<li>The <span class="ref"><strong><link url="http://help.aol.com/help/microsites/microsite.do?cmd=displayKC&amp;externalId=223568">Real-Time IM</link></strong></span> <note>AOL AIM Real Time Text: &lt;<link url="http://help.aol.com/help/microsites/microsite.do?cmd=displayKC&amp;externalId=223568">http://help.aol.com/help/microsites/microsite.do?cmd=displayKC&amp;externalId=223568</link>&gt;.</note> feature found in AOL Instant Messenger.</li>
<li>A component within Total Conversation, used by <span class="ref"><strong><link url="http://www.reach112.eu">Reach112</link></strong></span> <note>Reach112: European emergency service with real-time text. &lt;<link url="http://www.reach112.eu">http://www.reach112.eu</link>&gt;.</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. 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. For a visual animation of real-time text, see <span class="ref"><strong><link url="http://www.realtimetext.org">Real-Time Text Taskforce</link></strong></span>
<p>Real-time text allows continuous and rapid communication in text, to complement general-purpose 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. For a visual animation of real-time text, see <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 &lt;<link url="http://www.realtimetext.org">http://www.realtimetext.org</link>&gt;.</note>.</p>
</section1>
<section1 topic="Requirements" anchor="requirements">
@ -136,22 +140,23 @@
<section2 topic="Accessible" anchor="accessible">
<ol>
<li>Allow XMPP to follow the <span class="ref"><strong><link url="http://www.itu.int/rec/T-REC-F.703">ITU-T Rec. F.703</link></strong></span> <note>ITU-T Rec. F.703: Multimedia conversational services. &lt;<link url="http://www.itu.int/rec/T-REC-F.703">http://www.itu.int/rec/T-REC-F.703</link>&gt;.</note> Total Conversation standard for simultaneous voice, video, and real-time text.</li>
<li>Be a candidate technology for use with Next Generation 9-1-1 / 1-1-2 emergency services.</li>
<li>Be a candidate technology for use with next generation emergency services (e.g. 9-1-1 and 1-1-2).</li>
<li>Be suitable for transcription services and (when coupled with voice at user's choice) for TTY/text telephone alternatives, relay services, and captioned telephone systems.</li>
<li>Allow immediate conversational text through mobile phone text messaging and mainstream instant messaging.</li>
</ol>
</section2>
</section1>
<section1 topic="Glossary" anchor="glossary">
<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>character</strong> - A single Unicode code point. See <link url="#unicode_character_counting">Unicode Character Counting</link>.</p>
<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 &lt;<link url="http://www.itu.int/rec/T-REC-F.700">http://www.itu.int/rec/T-REC-F.700</link>&gt;.</note>, section 2.1.2.1.</p>
<p><strong>real-time text</strong> – Text transmitted instantly 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>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 &lt;rtt/&gt; child element of a &lt;message/&gt; stanza. The &lt;rtt/&gt; element is transmitted at regular intervals by the sender client while a message is being composed, to allow the recipient to see the latest message text, without waiting for the full message sent in a &lt;body/&gt; element.</p>
<p>Real-time text is transmitted via an &lt;rtt/&gt; child element of a &lt;message/&gt; stanza. The &lt;rtt/&gt; element is transmitted at regular intervals by the sender client while a message is being composed, to allow the recipient to see the latest message text from the sender, without waiting for the full message sent in a &lt;body/&gt; element.</p>
<p>This is a basic example of a <em><strong>real-time message</strong></em> "Hello, my Juliet!” transmitted in real-time while it is being typed, before a final message delivery in a &lt;body/&gt; 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'>
@ -212,40 +217,40 @@
</tr>
<tr>
<td>init</td>
<td>Initiate a real-time text session.</td>
<td>Signals the start of real-time text.</td>
<td>OPTIONAL</td>
<td>RECOMMENDED</td>
</tr>
<tr>
<td>cancel</td>
<td>End a real-time text session.</td>
<td>Signals the end of real-time text.</td>
<td>OPTIONAL</td>
<td>RECOMMENDED</td>
</tr>
</table>
<p><strong>event='new'</strong><br />
Senders MUST use this value when transmitting the first &lt;rtt/&gt; element containing <link url="#action_elements">Action Elements</link> (i.e. the first character(s) of a new message). Recipient clients MUST initialize a new real-time message for display, and then process action elements within the &lt;rtt/&gt; element. If a real-time message already exists in the same chat session, its content MUST be replaced (i.e. cleared prior to processing action elements). Senders MAY send subsequent &lt;rtt/&gt; elements that do not contain an <strong>event</strong> attribute.</p>
Senders MUST use this value when transmitting the first &lt;rtt/&gt; element containing <link url="#action_elements">Action Elements</link> (i.e. when sending the first character(s) of a new message). Recipient clients MUST initialize a new real-time message for display, and then process action elements within the &lt;rtt/&gt; element. If a real-time message already exists, from the same sender in the same chat session, its content MUST be replaced (i.e. cleared prior to processing action elements). Senders MAY send subsequent &lt;rtt/&gt; elements that do not contain an <strong>event</strong> attribute.</p>
<p><strong>event='reset'</strong><br />
For recipients, both <strong>'new'</strong> and <strong>'reset'</strong> are logically identical, and differ only for implementation purposes (e.g. highlighting newly-started messages). Recipient clients MUST initialize a new real-time message for display, and then process action elements within the &lt;rtt/&gt; element. If a real-time message already exists in the same chat session, its content MUST be replaced (i.e. cleared prior to processing action elements). Senders MAY send subsequent &lt;rtt/&gt; elements that do not contain an <strong>event</strong> attribute. Recipients MUST be able to process <strong>'reset'</strong> without first receiving <strong>'new'</strong>. See <link url="#message_reset">Message Reset</link>, used for <link url="#keeping_realtime_text_synchronized">Keeping Real-Time Text Synchronized</link> and <link url="#basic_realtime_text">Basic Real-Time Text</link>.</p>
For recipients, both <strong>'new'</strong> and <strong>'reset'</strong> are logically identical, and differ only for implementation purposes (e.g. highlighting newly-started messages). Recipient clients MUST initialize a new real-time message for display, and then process action elements within the &lt;rtt/&gt; element. If a real-time message already exists, from the same sender in the same chat session, its content MUST be replaced (i.e. cleared prior to processing action elements). Senders MAY send subsequent &lt;rtt/&gt; elements that do not contain an <strong>event</strong> attribute. Recipients MUST be able to process <strong>'reset'</strong> without first receiving <strong>'new'</strong>. See <link url="#message_reset">Message Reset</link>, used for <link url="#keeping_realtime_text_synchronized">Keeping Real-Time Text Synchronized</link> and <link url="#basic_realtime_text">Basic Real-Time Text</link>.</p>
<p><strong>event='init'</strong><br />
Clients MAY use this value to signal the other end that real-time text is being activated. It can be used to signal activation of real-time text before starting a new real-time message. If used, this &lt;rtt/&gt; element MUST be empty with no action elements. See <link url="#activating_and_deactivating_realtime_text">Activating and Deactivating Real-Time Text</link>.</p>
Clients MAY use this value to signal the other end that real-time text is being activated. It can be used to signal activation of real-time text before starting a new real-time message (since it may take a while before the sender starts composing). If used, this &lt;rtt/&gt; element MUST be empty with no action elements. See <link url="#activating_and_deactivating_realtime_text">Activating and Deactivating Real-Time Text</link>.</p>
<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 &lt;rtt/&gt; element MUST be empty with no action elements. Recipients SHOULD discontinue sending back &lt;rtt/&gt; 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 attribute is used only if &xep0308; (XEP-0308) is implemented at the same time as this specification. If a client supports both XEP-0301 and XEP-0308, clients SHOULD 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 &lt;message/&gt; stanza containing the &lt;body/&gt; that is being edited (See 'Business Rules' in XEP-0308). When used, <strong>id</strong> MUST be included in all &lt;rtt/&gt; elements transmitted during message correction of the previous message. A <link url="#message_reset">Message Reset</link> MUST be used when switching between messages being edited (i.e. switching between editing the new partially-composed message versus editing of the previously delivered message).</p>
<p>This attribute is used only if &xep0308; (XEP-0308) is implemented at the same time as this specification. If a client supports both XEP-0301 and XEP-0308, clients MUST use this attribute if real-time text is used during editing of the previously delivered message.</p>
<p>This <strong>id</strong> attribute refers to the &lt;message/&gt; stanza containing the &lt;body/&gt; that is being edited (See 'Business Rules' in XEP-0308). When used, <strong>id</strong> MUST be included in all &lt;rtt/&gt; elements transmitted during message correction of the previous message. The whole message MUST be retransmitted via &lt;rtt event='reset'/&gt; (<link url="#message_reset">Message Reset</link>) when beginning to edit the previous message, or when switching between messages (e.g. editing the new partially-composed message versus editing of the previously delivered message).</p>
</section3>
</section2>
<section2 topic="Body Element" anchor="body_element">
<p>The real-time message is considered complete upon receipt of a &lt;body/&gt; element in a &lt;message/&gt; stanza. The delivered text in the &lt;body/&gt; element is considered the final message text, and supersedes the real-time message. In the ideal case, the text from &lt;body/&gt; is redundant since this delivered text 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 &lt;rtt/&gt; element that is transmitted after a message stanza containing a &lt;body/&gt; element.</p>
<p>The real-time message is considered complete upon receipt of a &lt;body/&gt; element in a &lt;message/&gt; stanza. The delivered text in the &lt;body/&gt; element is considered the final message text, and supersedes the real-time message. In the ideal case, the text from the &lt;body/&gt; element is redundant since this delivered text is identical to the final contents of the real-time message.</p>
<p>Senders MAY transmit the &lt;body/&gt; element in the same or separate message stanza as the one containing the &lt;rtt/&gt; element. Senders MUST include an <link url="#event">event</link> attribute in the next &lt;rtt/&gt; element that is transmitted after a message stanza containing a &lt;body/&gt; element.</p>
<section3 topic="Backwards Compatible" anchor="backwards_compatible">
<p>The real-time text standard simply provides early delivery of text before the &lt;body/&gt; element. The &lt;body/&gt; 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 default transmission interval of &lt;rtt/&gt; elements for a continuously-changing message SHOULD be approximately <strong>0.7 second</strong>. This interval meets ITU-T Rec. F.700 Section A.3.2.1 for good quality 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 &lt;rtt/&gt; elements for a continuously-changing message SHOULD be approximately <strong>0.7 seconds</strong>. This interval meets ITU-T Rec. F.700 Section A.3.2.1 for good quality real-time conversation. If a different transmission interval needs to be used, the interval SHOULD be <strong>between 0.3 seconds and 1 second</strong>.</p>
<p>A longer interval will lead to a less optimal user experience in most network conditions. Conversely, a much shorter interval can lead to <link url="#congestion_considerations">Congestion Considerations</link>. 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>
@ -283,7 +288,7 @@
<tr>
<td>Wait&nbsp;Interval</td>
<td>&lt;w&nbsp;n='#'/&gt;</td>
<td>Wait <em><strong>n</strong></em> thousandths of a second.</td>
<td>Wait <em><strong>n</strong></em> milliseconds.</td>
<td>RECOMMENDED</td>
<td>RECOMMENDED</td>
</tr>
@ -296,13 +301,13 @@
<li><p>For <link url="#element_t_insert_text">Element &lt;t/&gt; – Insert Text</link> and <link url="#element_e_erase_text">Element &lt;e/&gt; – Erase Text</link>:<br />
The <em><strong>p</strong></em> attribute is an absolute position value, as a character position index into the real-time message, where 0 represents the beginning of the message. If <em><strong>p</strong></em> is omitted, the default value of <em><strong>p</strong></em> MUST point to the end of the message (i.e. <em><strong>p</strong></em> is set to the current length of the real-time message).</p></li>
<li><p>For the purpose of this specification, the word "character" represents a single Unicode code point. See <link url="#unicode_character_counting">Unicode Character Counting</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 <em><strong>p</strong></em> 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.</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.</p></li>
</ul>
</section3>
<section3 topic="List of Action Elements" anchor="list_of_action_elements">
<p>Recipients MUST be able to process all &lt;t/&gt; and &lt;e/&gt; action elements for incoming &lt;rtt/&gt; transmissions, even if senders do not use all of these for outgoing &lt;rtt/&gt; transmissions (e.g. <link url="#basic_realtime_text">Basic Real-Time Text</link>). Support for &lt;w/&gt; 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 &lt;rtt/&gt;, 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 &lt;rtt/&gt; element, and are never nested. See examples in <link url="#use_cases">Use Cases</link>.</p>
<section4 topic="Element &lt;t/&gt; – Insert Text" anchor="element_t_insert_text">
<p>Support the transmission of text, including key presses, and text block inserts.<br />
<p>Supports 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 &lt;body/&gt; element of a &lt;message/&gt;. If &lt;t/&gt; is empty, no text modification takes place.</em></p>
<p><code><![CDATA[<t>text</t>]]></code></p>
<p>Append specified <em><strong>text</strong></em> at the end of message. (<em><strong>p</strong></em> defaults to message length).<br />
@ -314,7 +319,7 @@
</section4>
<section4 topic="Element &lt;e/&gt; – Erase Text" anchor="element_e_erase_text">
<p>Support the behavior of Backspace key presses. Text is removed towards beginning of the message. This element is also used for all delete operations, including the Delete key, and text block deletes.<br />
<p>Supports the behavior of backspace key presses. Text is removed towards beginning of the message. This element is also used for all delete operations, including the delete key, and text block deletes.<br />
<em>Note: Excess backspaces MUST be ignored. Thus, text is backspaced only to the beginning of the message, in situations where the value of p is excessively large.</em></p>
<p><code><![CDATA[<e/>]]></code></p>
<p>Remove 1 character from end of message. (<em><strong>n</strong></em> defaults to 1, and <em><strong>p</strong></em> defaults to message length)</p>
@ -326,9 +331,9 @@
<p>Remove <em><strong>n</strong></em> characters before character position <em><strong>p</strong></em> in message.</p>
</section4>
<section4 topic="Element &lt;w/&gt; – 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>Allow for the transmission of intervals, between real-time text actions, to recreate the pauses between key presses. See <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>.</p>
<p><code><![CDATA[<w n='#'/>]]></code></p>
<p>Wait <em><strong>n</strong></em> 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>
<p>Wait <em><strong>n</strong></em> milliseconds before processing the next action element. This pause MAY be approximate, and not necessarily be of millisecond precision. 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>
</section3>
</section2>
@ -368,7 +373,7 @@
<ul>
<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>When the sender resumes composing after an extended pause (e.g. recovery from <link url="#stale_messages">Stale Messages</link> handling);</li>
<li>When the sender resumes composing after an extended pause (e.g. recipient may have cleared <link url="#stale_messages">Stale Messages</link>);</li>
<li>When the conversation is unlocked (e.g. section 5.1 of &xmppim;);</li>
</ul>
<p>A message reset is done using the &lt;rtt/&gt; attribute <link url="#event">event</link> value of <strong>'reset'</strong> (see <link url="#rtt_attributes">RTT Attributes</link>).</p>
@ -381,7 +386,7 @@
<section2 topic="Accurate Processing of Action Elements" anchor="accurate_processing_of_action_elements">
<p>Real-time text is generated based on text normally allowed to be transmitted within the &lt;body/&gt; element.</p>
<p>Incorrectly generated <link url="#action_elements">Action Elements</link> and <link url="#attribute_values">Attribute Values</link> can 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 unexpected modifications after sender pre-processing. 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 (e.g. non-compliant servers that modifies messages, incorrect <link url="#unicode_character_counting">Unicode Character Counting</link>) will recover upon delivery of the <link url="#body_element">Body Element</link>, upon the next <link url="#message_reset">Message Reset</link>, and/or during <link url="#basic_realtime_text">Basic Real-Time Text</link>.</p>
<p>Any inconsistencies that occur during real-time message editing (e.g. non-compliant servers that modify messages, incorrect <link url="#unicode_character_counting">Unicode Character Counting</link>) will recover upon delivery of the <link url="#body_element">Body Element</link>, upon the next <link url="#message_reset">Message Reset</link>, and/or during <link url="#basic_realtime_text">Basic Real-Time Text</link>.</p>
<section3 topic="Unicode Character Counting" anchor="unicode_character_counting">
<p>For this specification, a "character" represents a single Unicode code point. This is the same definition used in section 1.1 of <span class="ref"><strong><link url="http://tools.ietf.org/html/rfc5198">IETF RFC 5198</link></strong></span> <note>RFC 5198: Unicode Format for Network Interchange. &lt;<link url="http://tools.ietf.org/html/rfc5198">http://tools.ietf.org/html/rfc5198</link>&gt;.</note>. For platform-independent interoperability of <link url="#action_elements">Action Elements</link>, calculations on <link url="#attribute_values">Attribute Values</link> (<em><strong>p</strong></em> and <em><strong>n</strong></em>) MUST be based on counts of Unicode code points.</p>
<p>Many platforms use different internal encodings (i.e. string formats) that are different from the transmission encoding (UTF-8). These factors need to be considered:</p>
@ -398,7 +403,7 @@
<p>Sender clients MUST generate real-time text (<link url="#action_elements">Action Elements</link> and <link url="#attribute_values">Attribute Values</link>) based on the plain text version of the sender's message with pre-processing completed. This is separate and concurrent to any displayed presentation of the same message (e.g. formatting, emoticon graphics, &xep0071;).</p>
<p>Pre-processing before generating real-time text, include Unicode normalization, conversion of emoticons graphics to text, removal of illegal characters, line-break conversion, and any other necessary text modifications. For Unicode normalization, sender clients SHOULD ensure the message is in Unicode Normalization Form C ("NFC"), specified by section 3 of RFC 5198, and within many other standards such as Canonical XML 1.0.</p>
<p>If Unicode combining character sequences (e.g. letter with multiple accents) are used for <link url="#element_t_insert_text">Element &lt;t/&gt; – Insert Text</link>, then complete combining character sequences SHOULD be sent. In situations where modifications are required to an existing combining character sequence (e.g. adding an additional accent), an <link url="#element_e_erase_text">Element &lt;e/&gt; – Erase Text</link> SHOULD be used to delete the existing combining character sequence, before transmitting a complete replacement sequence via the &lt;t/&gt; element. (However, recipients SHOULD NOT assume this behavior from sending clients. See <link url="#guidelines_for_recipients">Guidelines for Recipients</link>).</p>
<p>For the purpose of calculating <link url="#attribute_values">Attribute Values</link>, 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). &lt;<link url="http://www.w3.org/TR/xml/">http://www.w3.org/TR/xml/</link>&gt;.</note>. In addition, XML character entities are counted as a single character.</p>
<p>For the purpose of calculating <link url="#attribute_values">Attribute Values</link>, any line breaks MUST be treated as a single character. Conversion of line breaks into a single LINE FEED U+000A is REQUIRED for XML processors, according to section 2.11 of <span class="ref"><strong><link url="http://www.w3.org/TR/xml/">XML</link></strong></span> <note>XML: Extensible Markup Language 1.0 (Fifth Edition). &lt;<link url="http://www.w3.org/TR/xml/">http://www.w3.org/TR/xml/</link>&gt;.</note>. In addition, XML character entities are counted as a single character.</p>
</section3>
<section3 topic="Guidelines for Recipients" anchor="guidelines_for_recipients">
<p>For <link url="#element_t_insert_text">Element &lt;t/&gt; – Insert Text</link>, text MUST be obtained using compliant XML processing (including entities converted to characters). Recipient clients SHOULD ensure that the received text is in Unicode Normalization Form C ("NFC"). After this, recipient clients MUST NOT do any other modifications to resulting real-time messages. This is to allow accurate processing of subsequent <link url="#action_elements">Action Elements</link> and <link url="#attribute_values">Attribute Values</link> (The recipient client can separately process/modify a copy of the same real-time message text, if necessary for the purpose of display presentation).</p>
@ -449,38 +454,28 @@
</section3>
</section2>
<section2 topic="Activating and Deactivating Real-Time Text" anchor="activating_and_deactivating_realtime_text">
<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. 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>
<p>There are many possible ways to implement turning on/off real-time text. Clients can send outgoing real-time text by default. Other clients might choose to do user-initiated activation (e.g. via a button).</p>
<section3 topic="Activation Guidelines" anchor="activation_guidelines">
<p>Sender clients can <strong>simply begin transmitting real-time text</strong> (i.e. send &lt;rtt/&gt; elements), either immediately or upon user-initiated activation.</p>
<p>For one-on-one chats, it can be beneficial for clients to easily synchronize the enabling/disabling of real-time text. Upon receiving incoming real-time text, recipient clients can automatically do an appropriate response, such as:</p>
<ul>
<li>Begin transmitting real-time text (by sending any valid &lt;rtt/&gt; elements); or</li>
<li>Signaling first (by transmitting &lt;rtt <link url="#event">event</link>='init'/&gt; as the first &lt;rtt/&gt; element).</li>
<li>Activate immediately (begin transmitting &lt;rtt/&gt; elements too); or</li>
<li>Activate after user confirmation prompt (for <link url="#privacy">Privacy</link> considerations); or</li>
<li>Deny (transmit &lt;rtt event='cancel'/&gt;); or</li>
<li>Ignore (discard incoming &lt;rtt/&gt; elements); or</li>
<li>Display only incoming real-time text (e.g. <link url="#multiuser_chat">Multi-User Chat</link> participants control their own outgoing real-time text).</li>
</ul>
<p>Recipient clients can respond to any incoming &lt;rtt/&gt; with appropriate response(s), such as any of:</p>
<ul>
<li>Accepting immediately (by activating in response); or</li>
<li>Accepting after recipient confirmation (by activating in response, after a user confirmation prompt); or</li>
<li>Deny (by transmitting &lt;rtt event='cancel'/&gt; which is used in <link url="#deactivation_methods">Deactivation Methods</link>); or</li>
<li>Ignoring (by discarding incoming &lt;rtt/&gt; as a last resort, without using <link url="#deactivation_methods">Deactivation Methods</link>).</li>
<li>Other appropriate responses (e.g. only display incoming real-time text during <link url="#multiuser_chat">Multi-User Chat</link>).</li>
</ul>
<p>Before transmitting &lt;rtt/&gt; elements, it is preferable for a sender client to explicitly discover whether the recipient client supports the protocol defined herein (using <link url="#determining_support">Determining Support</link>). Once confirmed, it is useful for sender clients to signal activation using &lt;rtt event=’init’/&gt;, since it may be a while before the user starts to compose a new message.</p>
<p>In the absence of explicit discovery or negotiation, the sender client can implicitly request and discover the use of real-time text, by sending &lt;rtt event='init'/&gt; upon activation. It is inappropriate to send any further &lt;rtt/&gt; elements, until the recipient client responds with incoming &lt;rtt/&gt; elements during the same chat session. Implicit discovery allows usage of real-time text as an enhancement to &xep0085; (XEP-0085 Section 5.1), during all situations where it can be used. See <link url="#usage_with_chat_states">Usage with Chat States</link>.</p>
<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>
<p>For any client, the preferred first &lt;rtt/&gt; element to send is &lt;rtt <link url="#event">event</link>='init'/&gt; as it can quickly signal activation of real-time text, without waiting for the sender to begin composing a new message, and since it is usable regardless of discovery.</p>
<p>Before sending real-time text, it is preferable for a sender client to explicitly discover whether the recipient client supports the protocol defined herein (using <link url="#determining_support">Determining Support</link>). In the absence of explicit discovery or negotiation, the sender client can implicitly request and discover the use of real-time text, by sending &lt;rtt event='init'/&gt; upon activation. It is inappropriate to send any further &lt;rtt/&gt; elements, until support is confirmed either by incoming &lt;rtt/&gt; elements or via discovery. Implicit discovery allows usage of real-time text as an enhancement to &xep0085; (XEP-0085 Section 5.1), during all situations where it can be used. See <link url="#usage_with_chat_states">Usage with Chat States</link>.</p>
</section3>
<section3 topic="Deactivation Methods" anchor="deactivation_methods">
<p>Real-time text can be deactivated by any of:</p>
<section3 topic="Deactivation Guidelines" anchor="deactivation_guidelines">
<p>Real-time text can be deactivated by transmitting &lt;rtt <link url="#event">event</link>='cancel'/&gt;, or simply by ending the chat session. Recipient clients can respond to deactivation with appropriate response(s), including:</p>
<ul>
<li>Sending a signal (using &lt;rtt <link url="#event">event</link>='cancel'/&gt; upon deactivation, deny, or end of chat session); or</li>
<li>Simply ending the chat session (without transmitting any further &lt;rtt/&gt; elements).</li>
</ul>
<p>Recipient clients can respond to deactivation with appropriate response(s), including:</p>
<ul>
<li>Discontinue transmission of &lt;rtt/&gt; elements as well (not applicable to <link url="#multiuser_chat">Multi-User Chat</link>); and</li>
<li>Stop transmitting &lt;rtt/&gt; elements as well (not applicable to <link url="#multiuser_chat">Multi-User Chat</link>); and</li>
<li>Handle the sender's unfinished incoming real-time message (such as clearing it and/or saving it); and</li>
<li>Inform the recipient user that sender ended real-time text (or denied/cancelled, if no real-time text was received).</li>
</ul>
<p>Sending an &lt;rtt event='cancel'/&gt; 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, any client can reactivate real-time text again in accordance to <link url="#activation_methods">Activation Methods</link>.</p>
<p>Sending an &lt;rtt event='cancel'/&gt; is also useful in situations where the user closes a chat window, and ends the chat session. It is also useful when the user wants to deactivate or deny real-time text, while still continuing the chat session. After &lt;rtt event='cancel'/&gt;, any client can reactivate real-time text again using &lt;rtt event='init'/&gt;.</p>
</section3>
</section2>
<section2 topic="Optional Remote Cursor" anchor="optional_remote_cursor">
@ -492,7 +487,7 @@
<li><p>After <link url="#element_t_insert_text">Element &lt;t/&gt; – Insert Text</link>, the cursor position is the <em><strong>p</strong></em> attribute plus the length of the text being inserted. The cursor position is put at the end of the inserted text.<br />
<em>This is the normal forward cursor movement during text insertion.</em></p></li>
<li><p>After <link url="#element_e_erase_text">Element &lt;e/&gt; – Erase Text</link>, the cursor position is the <em><strong>p</strong></em> attribute minus the <em><strong>n</strong></em> attribute.<br />
<em>This is the normal backwards cursor movement to a Backspace key.</em></p></li>
<em>This is the normal backwards cursor movement to a backspace key.</em></p></li>
<li><p>After an empty <link url="#element_t_insert_text">Element &lt;t/&gt; – Insert Text</link> (in the format of <strong>&lt;t p='#'/&gt;</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>
@ -521,10 +516,13 @@
</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>
<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 can miss these text changes, and this can potentially cause incorrect real-time text to be transmitted.</p>
</section3>
<section3 topic="Append-Only Real-Time Text" anchor="appendonly_realtime_text">
<p>The use of <link url="#element_t_insert_text">Element &lt;t/&gt; – Insert Text</link> without any attributes, simply appends text to the end of a message, while the use of <link url="#element_e_erase_text">Element &lt;e/&gt; – Erase Text</link> without any attributes, simply erases text from the end of the message. This sending method can also be useful for special-purpose clients where mid-message editing capabilities are not used (e.g. simple transcription, news tickers, relay services, captioned telephone).</p>
</section3>
<section3 topic="Basic Real-Time Text" anchor="basic_realtime_text">
<p>It is possible for sender clients to implement <link url="#message_reset">Message Reset</link> as the only method of transmitting changes to a real-time message. This method of sending real-time text is generally discouraged in most general-use clients. 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>It is possible for sender clients to use <link url="#message_reset">Message Reset</link> to retransmit the whole real-time message, whenever there are text changes. The advantage is very simple implementation. Disadvantages can 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. The below illustrates transmission of the real-time message “<strong>Hello there!</strong>” at a regular <link url="#transmission_interval">Transmission Interval</link> 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>Hel</t>
@ -542,11 +540,6 @@
<t>Hello there!</t>
</rtt>
</message>]]></code></p>
<p>The advantage is very simple implementation. However, major 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 &lt;t/&gt; – Insert Text</link> without any attributes, simply appends text to the end of a message, while the use of <link url="#element_e_erase_text">Element &lt;e/&gt; – Erase Text</link> without any attributes, simply erases text from the end of the message. This sending method is unsuitable for most general-purpose clients, but is 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 are the same as <link url="#basic_realtime_text">Basic Real-Time Text</link>, including 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>
</section2>
<section2 topic="Receiving Real-Time Text" anchor="receiving_realtime_text">
@ -576,7 +569,7 @@
<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>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 &lt;rtt/&gt; elements in MUC, even if not all participants support real-time text. Participants that enable real-time text during group chat need to keep track of multiple concurrent real-time messages on a per-participant basis. Participants, with real-time text, will see real-time text coming from each participant that has real-time text enabled. Participant clients without real-time text (whether unsupported or turned off) will simply see group chat function normally on a line-by-line basis, since it is <link url="#backwards_compatible">Backwards Compatible</link>.</p>
<p>Participants that turn off real-time text for themselves, can simply ignore incoming &lt;rtt/&gt; and not transmit outgoing &lt;rtt/&gt;. Participant clients in MUC receiving an incoming &lt;rtt <link url="#event">event</link>=’cancel’/&gt; needs to keep outgoing transmission unaffected during <link url="#deactivation_methods">Deactivation Methods</link> (otherwise, one participant could deny real-time text between other willing participants).</p>
<p>Participants that turn off real-time text for themselves, can simply ignore incoming &lt;rtt/&gt; and not transmit outgoing &lt;rtt/&gt;. Participant clients in MUC receiving an incoming &lt;rtt <link url="#event">event</link>=’cancel’/&gt; needs to keep outgoing transmission unaffected during <link url="#deactivation_guidelines">Deactivation Guidelines</link> (otherwise, one participant could deny real-time text between other willing participants).</p>
<p>To minimize on-screen clutter of multiple idle real-time messages, clients can hide idle messages, clear old <link url="#stale_messages">Stale Messages</link>, and/or prioritize the display of the most useful real-time messages. Prominent visibility of real-time text can be assigned to recent typists and/or moderators (e.g. classroom teacher, convention speaker). For the same participant logged in multiple times in the same room, see <link url="#simultaneous_logins">Simultaneous Logins</link>. In situations of simultaneous typing by a large number of participants, see <link url="#congestion_considerations">Congestion Considerations</link>.</p>
</section4>
<section4 topic="Simultaneous Logins" anchor="simultaneous_logins">
@ -651,7 +644,7 @@
<rtt xmlns='urn:xmpp:rtt:0' seq='123001' event='new'>
<t>Hello</t>
</rtt>
<composing/>
<composing xmlns='http://jabber.org/protocol/chatstates'/>
</message>
<message to='alice@example.com' from='bob@example.com/home' type='chat' id='b02'>
@ -659,7 +652,7 @@
<t> Alice</t>
</rtt>
<body>Hello Alice</body>
<active/>
<active xmlns='http://jabber.org/protocol/chatstates'/>
</message>
@ -667,7 +660,7 @@
<rtt xmlns='urn:xmpp:rtt:0' seq='456001' event='new'>
<t>This i</t>
</rtt>
<composing/>
<composing xmlns='http://jabber.org/protocol/chatstates'/>
</message>
<message to='alice@example.com' from='bob@example.com/home' type='chat' id='d04'>
@ -675,7 +668,7 @@
<t>s Bob</t>
</rtt>
<body>This is Bob</body>
<active/>
<active xmlns='http://jabber.org/protocol/chatstates'/>
</message>
@ -683,14 +676,14 @@
<rtt xmlns='urn:xmpp:rtt:0' seq='789001' event='new'>
<t>How a</t>
</rtt>
<composing/>
<composing xmlns='http://jabber.org/protocol/chatstates'/>
</message>
<message to='alice@example.com' from='bob@example.com/home' type='chat' id='f06'>
<rtt xmlns='urn:xmpp:rtt:0' seq='789002'>
<t>re yo</t>
</rtt>
<composing/>
<composing xmlns='http://jabber.org/protocol/chatstates'/>
</message>
<message to='alice@example.com' from='bob@example.com/home' type='chat' id='g07'>
@ -698,7 +691,7 @@
<t>u?</t>
</rtt>
<body>How are you?</body>
<active/>
<active xmlns='http://jabber.org/protocol/chatstates'/>
</message>]]></code></p>
@ -965,7 +958,7 @@
</section2>
<section2 topic="Congestion Considerations" anchor="congestion_considerations">
<p>The nature of real-time text can result in more frequent transmission of &lt;message/&gt; stanzas than would otherwise happen in a non-real-time text conversation. This can lead to increased network and server loading of XMPP networks.</p>
<p>Transmission of real-time text can be throttled temporarily during poor network conditions. It is appropriate to use latency monitoring mechanisms (e.g. &xep0184; or &xep0198;) in order to temporarily adjust the <link url="#transmission_interval">Transmission Interval</link> of real-time text beyond the recommended range. This results in lagged text (less real-time) but is better than failure during poor network conditions. The use of <link url="#message_reset">Message Reset</link> can also retransmit real-time text lost by poor network conditions, including stanzas dropped during a network issue or server error. These techniques are useful for mission-critical applications such as Next Generation 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 during a network issue or server error. These techniques are useful for mission-critical applications such as next generation emergency services (e.g. text to 9-1-1).</p>
<p>Excess numbers of real-time messages (e.g. during DoS scenario in <link url="#multiuser_chat">Multi-User Chat</link>) might cause local resource-consumption issues, which can be mitigated by accelerated time-out of <link url="#stale_messages">Stale Messages</link>.</p>
<p>According to multiple university studies worldwide, the average length of instant messages is under 40 characters. The additional incremental bandwidth overhead of real-time text can be very low for an existing XMPP client, especially one already using many extensions. Bandwidth can also be further mitigated using stream compression, to benefit bandwidth-constrained networks (e.g. GPRS, 3G, satellite).</p>
</section2>
@ -1005,6 +998,7 @@
<xs:restriction base="xs:string">
<xs:enumeration value="new"/>
<xs:enumeration value="reset"/>
<xs:enumeration value="init"/>
<xs:enumeration value="cancel"/>
</xs:restriction>
</xs:simpleType>
@ -1046,7 +1040,7 @@
</xs:schema>]]></code></p>
</section1>
<section1 topic="Acknowledgments" anchor="acknowledgments">
<p>The members of the Real-Time Text Taskforce (R3TF), <link class="western" href="http://www.realtimetext.org/">www.realtimetext.org</link>, has contributed greatly specification. Mark Rejhon leads the Jabber/XMPP Taskgroup at R3TF. Members of R3TF who have contributed to this specification include Gunnar Hellstrom, Paul E. Jones, Gregg Vanderheiden, Barry Dingle, and Arnoud van Wijk. Others contributors include Bernard Aboba, Mark Grady, Darren Sturman, Christian Vogler, Norm Williams, and several members from the XMPP Standards Mailing List, including Kevin Smith, Peter Saint Andre and many others.</p>
<p>The members of the Real-Time Text Taskforce (R3TF), <link class="western" href="http://www.realtimetext.org/">www.realtimetext.org</link>, made significant contributions to this specification. Mark Rejhon leads the Jabber/XMPP Taskgroup at R3TF. Members of R3TF who have contributed to this specification include Gunnar Hellstrom, Paul E. Jones, Gregg Vanderheiden, Barry Dingle, and Arnoud van Wijk. Others contributors include Bernard Aboba, Mark Grady, Darren Sturman, Christian Vogler, Norm Williams, and several members from the XMPP Standards Mailing List, including Kevin Smith, Peter Saint Andre and many others.</p>
<p>The technique of <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>, otherwise called "natural typing", was created by Mark Rejhon, who is deaf. It is incorporated into 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>