mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-21 16:55:07 -05:00
XEP Editor review
This commit is contained in:
Peter Saint-Andre
parent
767ca95260
commit
1f7b08ee34
66
xep-0301.xml
66
xep-0301.xml
@ -281,7 +281,7 @@
|
||||
<li><p><strong>Starting real-time text: <rtt event='init'/></strong><br />
|
||||
Clients MAY use this value to signal activation of real-time text without first starting a real-time message, since the sender may not start composing immediately. The <em><strong>seq</strong></em> attribute is ignored by recipient clients. See <link url="#activating_and_deactivating_realtime_text">Activating and Deactivating Real-Time Text</link>.</p></li>
|
||||
<li><p><strong>Ending real-time text: <rtt event='cancel'/></strong><br />
|
||||
Clients MAY use this value to signal deactivation of real-time text. Clients receiving this element SHOULD also discontinue sending <rtt/> elements for the remainder of the same one-on-one chat session (until <em><strong>event='init'</strong></em> is used again), and handle any unfinished real-time messages appropriately (e.g. clearing or saving the message). The <em><strong>seq</strong></em> attribute is ignored by recipient clients. See <link url="#activating_and_deactivating_realtime_text">Activating and Deactivating Real-Time Text</link>.</p></li>
|
||||
Clients MAY use this value to signal deactivation of real-time text. Clients receiving this element SHOULD also discontinue sending <rtt/> elements for the remainder of the same one-to-one chat session (until <em><strong>event='init'</strong></em> is used again), and handle any unfinished real-time messages appropriately (e.g. clearing or saving the message). The <em><strong>seq</strong></em> attribute is ignored by recipient clients. See <link url="#activating_and_deactivating_realtime_text">Activating and Deactivating Real-Time Text</link>.</p></li>
|
||||
<li><p><strong>Starting value for seq attribute:</strong><br />Sender clients MAY use any new starting value for <em><strong>seq</strong></em> when initializing a real-time message using <em><strong>event='new'</strong></em> or <em><strong>event='reset'</strong></em>. Recipient clients receiving such elements MUST use this <em><strong>seq</strong></em> value as the new starting value. A random value is RECOMMENDED for improved integrity during <link url="#usage_with_multiuser_chat_and_simultaneous_logins">Usage with Multi-User Chat and Simultaneous Logins</link>.</p></li>
|
||||
</ul>
|
||||
</section2>
|
||||
@ -336,7 +336,7 @@
|
||||
<td>RECOMMENDED</td>
|
||||
</tr>
|
||||
</table>
|
||||
<p>These elements are kept compact in order to save bandwidth, since a single <rtt/> element can contain a huge number of action elements (e.g. during <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>). See <link url="#list_of_action_elements">List of Action Elements</link> for details.</p>
|
||||
<p>These elements are kept compact in order to save bandwidth, since a single <rtt/> element can contain a large number of action elements (e.g. during <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>). See <link url="#list_of_action_elements">List of Action Elements</link> for details.</p>
|
||||
</section3>
|
||||
<section3 topic="Attribute Values" anchor="attribute_values">
|
||||
<ul>
|
||||
@ -400,7 +400,7 @@
|
||||
</ol>
|
||||
</section3>
|
||||
<section3 topic="Recovery From Loss of Sync" anchor="recovery_from_loss_of_sync">
|
||||
<p>Loss of sync occurs during receiving text modifications if the <em><link url="#seq">seq</link></em> attribute do not increment by 1 as expected, or if no real-time message exists. In this case:</p>
|
||||
<p>Loss of sync occurs during receiving text modifications if the <em><link url="#seq">seq</link></em> attributes do not increment by 1 as expected, or if no real-time message exists. In this case:</p>
|
||||
<ul>
|
||||
<li>Recipients MUST keep the real-time message unchanged (if any exists); and</li>
|
||||
<li>Recipients MUST ignore subsequent text modifications (i.e. <rtt event='edit'/> or <rtt/> without an <em><link url="#event">event</link></em> attribute); and</li>
|
||||
@ -424,13 +424,13 @@
|
||||
<li>When the sender resumes composing after an extended pause (e.g. recipient may have cleared <link url="#stale_messages">Stale Messages</link>);</li>
|
||||
<li>When the conversation is unlocked (e.g. section 5.1 of XMPP IM);</li>
|
||||
</ul>
|
||||
<p>If the recipient already has an existing real-time message from the sender, <link url="#processing_rules">Processing Rules</link> require that the real-time message MUST be seamlessly replaced. Thus, if the recipient is successfully <link url="#staying_in_sync">Staying In Sync</link>, the recipient user sees no visible effect since the text contained within <rtt event='reset'/> is a duplicate of the existing real-time message. If the recipient client was out of lost sync (<link url="#recovery_from_loss_of_sync">Recovery From Loss of Sync</link>) or it has no real-time message, the recipient user sees the real-time message immediately “catch up”.</p>
|
||||
<p>If the recipient already has an existing real-time message from the sender, <link url="#processing_rules">Processing Rules</link> require that the real-time message MUST be seamlessly replaced. Thus, if the recipient is successfully <link url="#staying_in_sync">Staying In Sync</link>, the recipient user sees no visible effect since the text contained within <rtt event='reset'/> is a duplicate of the existing real-time message. If the recipient client was out of sync (<link url="#recovery_from_loss_of_sync">Recovery From Loss of Sync</link>) or it has no real-time message, the recipient user sees the real-time message immediately “catch up”.</p>
|
||||
<p>Note: The use of <rtt event='reset'/> is not limited to message refresh, as it can contain any number of <link url="#action_elements">Action Elements</link> in any order. Sender clients MAY combine a message refresh with additional action elements (e.g. re-transmitting a whole message in one <link url="#element_t_insert_text">Element <t/> – Insert Text</link>, followed by some additional action elements, such as additional typing or backspacing, to seamlessly allow <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link>).</p>
|
||||
</section3>
|
||||
</section2>
|
||||
<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 <body/> 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 be transmitted unaltered 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. Unaltered 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>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 need to be transmitted unaltered 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. Unaltered 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>If unexpected Unicode inconsistencies occur during real-time message editing, the recipient client will normally recover the message upon receiving a <link url="#body_element">Body Element</link> or a <link url="#message_refresh">Message Refresh</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>
|
||||
@ -441,7 +441,7 @@
|
||||
<em>Action elements operate on Unicode code points individually.</em></p></li>
|
||||
<li><p>Unicode code points U+10000 through U+10FFFF are represented as a surrogate pair in some Unicode encodings (e.g. UTF-16).<br />
|
||||
<em>Action elements operate on Unicode code points as a whole, not on separate components of a surrogate pair.</em></p></li>
|
||||
<li><p>XMPP transmission uses UTF-8, which use a variable number of bytes per Unicode code point.<br /><em>Action elements operate on Unicode code points as a whole, not on separate bytes.</em></p></li>
|
||||
<li><p>XMPP transmission uses UTF-8, which uses a variable number of bytes per Unicode code point.<br /><em>Action elements operate on Unicode code points as a whole, not on separate bytes.</em></p></li>
|
||||
</ul>
|
||||
<p>Lengths and positions in <link url="#attribute_values">Attribute Values</link> 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). One way for implementers to visualize this, is to simply visualize Unicode text as an array of individual code points, and treat <link url="#attribute_values">Attribute Values</link> as array indexes.</p>
|
||||
</section3>
|
||||
@ -449,12 +449,12 @@
|
||||
<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 from 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 includes 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 <span class="ref"><strong><link url="http://www.unicode.org/reports/tr15/">Unicode Normalization Form C</link></strong></span>
|
||||
<note>Unicode Standard Annex #15: Unicode Normalization Forms <<link url="http://www.unicode.org/reports/tr15/">http://www.unicode.org/reports/tr15/</link>>.</note> ("NFC"), as recommended within section 3 of RFC 5198, and within many other standards such as Canonical XML 1.0.</p>
|
||||
<p>If Unicode combining character sequences (e.g. letter with multiple accents) are used for <link url="#element_t_insert_text">Element <t/> – 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 <e/> – Erase Text</link> SHOULD be used to delete the existing combining character sequence, before transmitting a complete replacement sequence via the <t/> element. (However, recipients SHOULD NOT assume this behavior from sending clients. See <link url="#guidelines_for_recipients">Guidelines for Recipients</link>).</p>
|
||||
<p>If Unicode combining character sequences (e.g. letter with multiple accents) are used for <link url="#element_t_insert_text">Element <t/> – 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 <e/> – Erase Text</link> SHOULD be used to delete the existing combining character sequence, before transmitting a complete replacement sequence via the <t/> element. (However, recipients SHOULD NOT assume this behavior from sending clients. See <link url="#guidelines_for_recipients">Guidelines for Recipients</link>.)</p>
|
||||
<p>For the purpose of calculating <link url="#attribute_values">Attribute Values</link>, any line breaks MUST be treated as a single character. Conversion of line breaks into a single LINE FEED U+000A is REQUIRED for XML processors, according to section 2.11 of <span class="ref"><strong><link url="http://www.w3.org/TR/xml/">XML</link></strong></span>
|
||||
<note>XML: Extensible Markup Language 1.0 (Fifth Edition) <<link url="http://www.w3.org/TR/xml/">http://www.w3.org/TR/xml/</link>>.</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 <t/> – 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>
|
||||
<p>For <link url="#element_t_insert_text">Element <t/> – 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>
|
||||
<p>It is possible for sender clients to send <link url="#element_t_insert_text">Element <t/> – Insert Text</link> with an incomplete combining character sequence (e.g. combining mark(s) without a Unicode base character). This is valid when extending an existing combining character sequence into a longer valid complete combining character sequence (e.g. adding an additional accent mark). It is also possible for senders to send <link url="#element_e_erase_text">Element <e/> – Erase Text</link> to remove code points from an existing combining character sequence, into a shorter valid complete combining character sequence (e.g. removing an accent mark). In all cases, recipient clients MUST process these elements in accordance to <link url="#action_elements">Action Elements</link>.</p>
|
||||
</section3>
|
||||
</section2>
|
||||
@ -494,7 +494,7 @@
|
||||
<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 or phrase bursts rather than a character at a time. It can be acceptable for senders with bursty output to immediately transmit word or phrase bursts of text without buffering, as long as the average stanza rate is not excessive. This eliminates any lag caused by the <link url="#transmission_interval">Transmission Interval</link>. It is not necessary to transmit <link url="#element_w_wait_interval">Element <w/> – Wait Interval</link> for real-time transcription.</p>
|
||||
<p>There are specialized situations such as live transcriptions and captioning (e.g. transcription service, closed captioning provider, captioned telephone, Communication Access Realtime Translation (CART), relay services) that demand low latency transmission. Such systems typically use voice recognition and/or stenotype machines, which output text in word or phrase bursts rather than a character at a time. It can be acceptable for senders with bursty output to immediately transmit word or phrase bursts of text without buffering, as long as the average stanza rate is not excessive. This eliminates any lag caused by the <link url="#transmission_interval">Transmission Interval</link>. It is not necessary to transmit <link url="#element_w_wait_interval">Element <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_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, preferably within the range recommended by <link url="#transmission_interval">Transmission Interval</link>. Compression can also be used to reduce bandwidth (e.g. TLS compression or &xep0138;).</p>
|
||||
@ -505,7 +505,7 @@
|
||||
<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 <rtt/> 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>
|
||||
<p>For one-to-one chats, it can be beneficial for clients to easily synchronize the enabling/disabling of real-time text. Upon receiving incoming real-time text, recipient clients can automatically do an appropriate response, such as:</p>
|
||||
<ul>
|
||||
<li>Activate immediately (begin transmitting <rtt/> elements too); or</li>
|
||||
<li>Activate after user confirmation prompt (for <link url="#privacy">Privacy</link> considerations); or</li>
|
||||
@ -514,7 +514,7 @@
|
||||
<li>Display only incoming real-time text (e.g. <link url="#multiuser_chat">Multi-User Chat</link> participants control their own outgoing real-time text).</li>
|
||||
</ul>
|
||||
<p>For any client, the preferred first <rtt/> element to send is <rtt <link url="#event">event</link>='init'/> as it can quickly signal activation of real-time text, without waiting for the sender to begin composing a new message, and since it is usable regardless of discovery. Conversely, if the sender was already composing a message when activating real-time text, <link url="#message_refresh">Message Refresh</link> handles this situation.</p>
|
||||
<p>While explicit discovery is preferred (See <link url="#determining_support">Determining Support</link>), the sender client can implicitly request and discover the use of real-time text, by sending <rtt event='init'/> upon activation. In the case of one-on-one chats, it is inappropriate to send any further <rtt/> elements, until support is confirmed either by incoming <rtt/> elements or via discovery. Implicit discovery makes it possible to use real-time text as an enhancement to &xep0085; (XEP-0085 Section 5.1), during all situations where it can be used. See <link url="#usage_with_chat_states">Usage with Chat States</link>.</p>
|
||||
<p>While explicit discovery is preferred (see <link url="#determining_support">Determining Support</link>), the sender client can implicitly request and discover the use of real-time text, by sending <rtt event='init'/> upon activation. In the case of one-to-one chats, it is inappropriate to send any further <rtt/> elements, until support is confirmed either by incoming <rtt/> elements or via discovery. Implicit discovery makes it possible to use real-time text as an enhancement to &xep0085; (XEP-0085 Section 5.1), during all situations where it can be used. See <link url="#usage_with_chat_states">Usage with Chat States</link>.</p>
|
||||
</section3>
|
||||
<section3 topic="Deactivation Guidelines" anchor="deactivation_guidelines">
|
||||
<p>Real-time text can be deactivated by transmitting <rtt <link url="#event">event</link>='cancel'/>, or simply by ending the chat session. Recipient clients can respond to deactivation with appropriate response(s), including:</p>
|
||||
@ -530,7 +530,7 @@
|
||||
</section2>
|
||||
<section2 topic="Optional Remote Cursor" anchor="optional_remote_cursor">
|
||||
<p>Recipient clients can choose to display a separate cursor/caret indicator within incoming real-time messages. This can improve usability of real-time text, since it becomes easier for a recipient to observe the sender's real-time message edits. For clients that do not implement a remote cursor, skip this section.</p>
|
||||
<p><link url="#action_elements">Action Elements</link> use only absolute positioning (relative positions are not used by this standard), so clients do not need to remember the position value from previous action elements. Recipient software can calculate the remote cursor position as follows:</p>
|
||||
<p><link url="#action_elements">Action Elements</link> use only absolute positioning (relative positions are not used by this specification), so clients do not need to remember the position value from previous action elements. Recipient software can calculate the remote cursor position as follows:</p>
|
||||
<ul>
|
||||
<li><p>Upon receiving <link url="#element_t_insert_text">Element <t/> – 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 allows normal forward cursor movement during text insertion.</em></p></li>
|
||||
@ -551,7 +551,7 @@
|
||||
<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 the previous text change event. The difference in text, between consecutive text change events, is typically a one character difference (e.g. key press) or one text block difference (e.g. auto-correct, cut, paste). In order to calculate what text changes took place, the first changed character and the last changed character is determined. From this, it is simple to generate <link url="#action_elements">Action Elements</link> for a single text block deletion and/or insertion. 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>During a text change event, the sender’s current message text can be compared to the old message text from the previous text change event. The difference in text, between consecutive text change events, is typically a one character difference (e.g. key press) or one text block difference (e.g. auto-correct, cut, paste). In order to calculate what text changes took place, the first changed character and the last changed character are determined. From this, it is simple to generate <link url="#action_elements">Action Elements</link> for a single text block deletion and/or insertion. 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 element(s) and append these action element(s) to a buffer. Repeating this step during every text change event, is equivalent to recording a small sequence of typing.</p></li>
|
||||
@ -589,7 +589,7 @@
|
||||
<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 queuing action will smooth out incoming transmission (e.g. receiving new <rtt/> while still processing action elements from a delayed <rtt/>).</p></li>
|
||||
<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 will smooth out incoming transmission (e.g. receiving new <rtt/> while still processing action elements from a delayed <rtt/>).</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>, if supported. This is equivalent to playing back the sender's original typing.</p></li>
|
||||
</ol>
|
||||
<p>If <link url="#element_w_wait_interval">Element <w/> – Wait Interval</link>] is supported, excess lag in incoming real-time text can occur when delayed <rtt/> elements get delivered (e.g. congestion, intermittent wireless reception). To avoid delayed presentation of real-time text, the recipient client needs to speed up processing of action elements. This can be accomplished through a variety of techniques, such as shortening the pauses (<em><strong>n</strong></em> value) in <w/> elements, ignoring excess <w/> elements, immediately outputting action elements that are still queued, and/or keeping action elements from a limited number of <rtt/> elements queued (immediately outputting any prior action elements). This allows lagged real-time text to catch up more quickly.</p>
|
||||
@ -598,43 +598,43 @@
|
||||
</section2>
|
||||
<section2 topic="Other Guidelines" anchor="other_guidelines">
|
||||
<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_refresh">Message Refresh</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_refresh">Message Refresh</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>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 large (e.g. macros, multiple copy and pastes, leading to an <rtt/> exceeding one kilobyte) a <link url="#message_refresh">Message Refresh</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_refresh">Message Refresh</link>. Also, large <rtt/> elements might 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 clients that send continuous real-time text (e.g. news ticker, captioning, speech transcription, TTY/text telephone gateway), a <link url="#body_element">Body Element</link> can be sent and then a new real-time message started immediately after, every time a message reaches a specific size. This allows continuous real-time text without real-time messages becoming excessively large.</p>
|
||||
</section3>
|
||||
<section3 topic="Usage with Chat States" anchor="usage_with_chat_states">
|
||||
<p>Real-time text can be used in conjunction with XEP-0085 Chat States. It is best to handle XEP-0301 and XEP-0085 transmissions in separate <message/> stanzas. Chat states such as <composing/> or <active/> are sent separately of <rtt/> elements.</p>
|
||||
<p>Chat states are handled as specified by XEP-0085 Chat States. The continuous transmission of real-time text corresponds to a <composing/> chat state. Therefore, the timing of the <composing/> chat state coincides with the beginning of continuous <rtt/> transmission. </p>
|
||||
<p>Real-time text can be used in conjunction with Chat State Notifications (XEP-0085). It is best to handle XEP-0301 and XEP-0085 transmissions in separate <message/> stanzas. Chat states such as <composing/> or <active/> are sent separately from <rtt/> elements.</p>
|
||||
<p>Chat states are handled as specified by XEP-0085. The continuous transmission of real-time text corresponds to a <composing/> chat state. Therefore, the timing of the <composing/> chat state coincides with the beginning of continuous <rtt/> transmission. </p>
|
||||
</section3>
|
||||
<section3 topic="Usage with Last Message Correction" anchor="usage_with_last_message_correction">
|
||||
<p>It is possible to have &xep0308; (XEP-0308) with real-time text. If XEP-0308 is implemented at the same time as this specification, the following rules apply:</p>
|
||||
<p>It is possible to use &xep0308; (XEP-0308) with real-time text. If XEP-0308 is implemented in concert with this specification, the following rules apply:</p>
|
||||
<ul>
|
||||
<li><p>For all <rtt/> elements transmitted during composing a new message, the <em><link url="#id">id</link></em> attribute of <rtt/> is not used.</p></li>
|
||||
<li><p>For all <rtt/> elements transmitted during editing of the previous message, the <em><strong>id</strong></em> attribute of <rtt/> matches the <em><strong>id</strong></em> attribute of the old <message/> stanza containing the <body/> text being edited (See 'Business Rules' in XEP-0308). This enables recipient clients to display real-time text while the sender is editing the previously-delivered message.</p></li>
|
||||
<li><p>For all <rtt/> elements transmitted during editing of the previous message, the <em><strong>id</strong></em> attribute of <rtt/> matches the <em><strong>id</strong></em> attribute of the old <message/> stanza containing the <body/> text being edited (see 'Business Rules' in XEP-0308). This enables recipient clients to display real-time text while the sender is editing the previously-delivered message.</p></li>
|
||||
<li><p>Senders clients need to transmit a <link url="#message_refresh">Message Refresh</link> when transmitting <rtt/> for a different message than the previously transmitted <rtt/> (i.e. the value of the <em><strong>id</strong></em> attribute changes, <em><strong>id</strong></em> becomes included, or <em><strong>id</strong></em> becomes not included). This keeps real-time text synchronized when beginning to edit a previously delivered message versus continuing to compose a new message.</p></li>
|
||||
<li><p>The XEP-0301 and XEP-0308 protocols operate concurrently via separate message stanzas. Thus, a message stanza never simultaneously includes both <rtt/> and <replace/>.</p></li>
|
||||
<li><p>The <link url="#body_element">Body Element</link> delivers a finished new message or a finished message correction (<replace/> is used with <body/> in accordance to XEP-0308).</p></li>
|
||||
</ul>
|
||||
</section3>
|
||||
<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 makes it possible to seamlessly integrate real-time text into &xep0045; (MUC), as well as concurrent simultaneous logins.</p>
|
||||
<p>The in-band nature of this real-time text specification makes it possible to seamlessly integrate real-time text into &xep0045; (MUC), as well as concurrent simultaneous logins.</p>
|
||||
<section4 topic="Multi-User Chat" anchor="multiuser_chat">
|
||||
<p>For simplicity, clients can implement real-time text only for one-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. 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>For simplicity, clients can implement real-time text only for one-to-one chat, and not for MUC. However, it can be appropriate to support <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. 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 <rtt/> and not transmit outgoing <rtt/>. Participant clients in MUC receiving an incoming <rtt <link url="#event">event</link>=’cancel’/> 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">
|
||||
<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_refresh">Message Refresh</link>, presumably from the active login. This provides a seamless system-switching experience. A good implementation of <link url="#message_refresh">Message Refresh</link> will improve user experience, regardless of whether or not the client follows 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>
|
||||
<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_refresh">Message Refresh</link>, presumably from the active login. This provides a seamless system-switching experience. A good implementation of <link url="#message_refresh">Message Refresh</link> will improve user experience, regardless of whether or not the client follows &xep0296;. Clients can choose to distinguish the <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>
|
||||
</section4>
|
||||
</section3>
|
||||
<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>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 one-to-one chat sessions, the time-out period might need to be longer to allow reasonable interruptions (i.e. sender pausing during a long phone call or other interruption).</p>
|
||||
<p>Senders that resume composing a message (i.e. continues a partially-composed message hours later) can do a <link url="#message_refresh">Message Refresh</link>, which allows recipients to redisplay the real-time message.</p>
|
||||
</section3>
|
||||
<section3 topic="Performance & Efficiency" anchor="performance_efficiency">
|
||||
<p>With real-time text, frequent screen updates can occur. Screen updates are a potential performance bottleneck, since fast typists type many key presses per second. Optimizing screen updates becomes especially important for slower platforms. The real-time message might be implemented as a separate window or separate display element.</p>
|
||||
<p>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>
|
||||
<p>Battery life considerations are closely related to performance, as the addition of real-time text can have an impact on battery life. If <link url="#preserving_key_press_intervals">Preserving Key Press Intervals</link> is supported, then support for <link url="#element_w_wait_interval">Element <w/> – Wait Interval</link> needs to be implemented in a battery-efficient manner. The <link url="#transmission_interval">Transmission Interval</link> can vary dynamically to optimize for battery life and wireless reception. For devices where screen updates are an unavoidable, inefficient bottleneck, see <link url="#lowbandwidth_and_lowprecision_text_smoothing">Low-Bandwidth and Low-Precision Text Smoothing</link> to reduce the number of screen updates per second.</p>
|
||||
</section3>
|
||||
</section2>
|
||||
</section1>
|
||||
@ -902,7 +902,7 @@
|
||||
<li>Two backspaces to delete the typing mistake;</li>
|
||||
<li>Two correct key presses to correctly spell the word “there”.</li>
|
||||
</ul>
|
||||
<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>The use <link url="#element_w_wait_interval">Element <w/> – Wait Interval</link>, between key presses, allows the receiving client to 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>
|
||||
@ -972,8 +972,8 @@
|
||||
</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. Interoperability specifications between multiple real-time text formats can be found at Real-Time Text Taskforce (R3TF).</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. For example, clients that use XMPP can utilize this XEP-0301 specification, and clients that use SIP might utilize IETF RFC 4103, <span class="ref"><strong><link url="http://tools.ietf.org/html/rfc5194">IETF RFC 5194</link></strong></span>
|
||||
<note>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, might 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. This can include TTY and textphones.</p>
|
||||
<p>Implementers ought to choose the most appropriate real-time text approach for the session control technology in use during a particular session. For example, clients that use XMPP can utilize this XEP-0301 specification, and clients that use SIP might utilize IETF RFC 4103, <span class="ref"><strong><link url="http://tools.ietf.org/html/rfc5194">IETF RFC 5194</link></strong></span>
|
||||
<note>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, might need to utilize multiple real-time text technologies. To interoperate between incompatible real-time text technologies, gateway servers can transcode between different real-time text technologies, along with other media such as audio and video. This can include TTY and textphones.</p>
|
||||
<section2 topic="RFC 4103 and T.140" anchor="rfc_4103_and_t140">
|
||||
<p>In the SIP environment, real-time text is specified in IETF RFC 4103 and ITU-T T.140. SIP is a popular real-time session control protocol, and there are many implementations of real-time text controlled by SIP. This includes emergency services in some regions.</p>
|
||||
<p>Interoperability considerations include addressing translation, media negotiation and translation, and media transcoding. Transcoding is straightforward between this specification and T.140/RFC4103, except for editing in the middle of messages. Text insertions or deletions, occurring far back in the message, can cause a large number of erase operations in T.140 that consume time and bandwidth. T.140 specifies the use of ISO 6429 control codes for presentation characteristics, such as text color, that are not supported by this specification. During transcoding, these control codes needs to be filtered off in order to not disturb the presentation of text.</p>
|
||||
@ -984,20 +984,20 @@
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic="Internationalization Considerations" anchor="internationalization_considerations">
|
||||
<p>The primary internationalization consideration involve real-time message editing using <link url="#action_elements">Action Elements</link>, where text is inserted and deleted using position and length values. For this, <link url="#accurate_processing_of_action_elements">Accurate Processing of Action Elements</link> including correct <link url="#unicode_character_counting">Unicode Character Counting</link> will ensure that all possible valid Unicode text can be used via this protocol. This includes text containing multiple scripts/languages, ideographic symbols (e.g. Chinese), right-to-left text (e.g. Arabic), and bidirectional text.</p>
|
||||
<p>The primary internationalization consideration involves real-time message editing using <link url="#action_elements">Action Elements</link>, where text is inserted and deleted using position and length values. For this, <link url="#accurate_processing_of_action_elements">Accurate Processing of Action Elements</link> including correct <link url="#unicode_character_counting">Unicode Character Counting</link> will ensure that all possible valid Unicode text can be used via this protocol. This includes text containing multiple scripts/languages, ideographic symbols (e.g. Chinese), right-to-left text (e.g. Arabic), and bidirectional text.</p>
|
||||
<p>For accessibility considerations, there is an <span class="ref"><strong><link url="http://www.fasttext.org">International Symbol of Real-Time Text</link></strong></span>
|
||||
<note>The International Symbol of Real-Time Text <<link url="http://www.fasttext.org">http://www.fasttext.org</link>>.</note> to alert users to the existence of this feature.</p>
|
||||
</section1>
|
||||
<section1 topic="Security Considerations" anchor="security_considerations">
|
||||
<section2 topic="Privacy" anchor="privacy">
|
||||
<p>It is important for users to be made aware of real-time text (e.g. user consent, software notice, introductory explanation). Users of real-time text 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 finishes the message. Implementation behaviors and improved education can be added to reduce privacy issues. Examples include showing an introduction upon first activation of feature, special handling for copy and pastes (i.e. preventing them, or prompting for confirmation), recipient confirmation of real-time text via <link url="#activating_and_deactivating_realtime_text">Activating and Deactivating Real-Time Text</link>, etc.</p>
|
||||
<p>It is important for users to be made aware of real-time text (e.g. user consent, software notice, introductory explanation). Users of real-time text need to be aware that their typing is now visible in real-time to everyone in the current chat conversation. 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) and then sending the message. With real-time message editing, recipients can watch all text changes that occur in the sender's text, before the sender finishes the message. Implementation behaviors and improved education can be added to reduce privacy issues. Examples include showing an introduction upon first activation of feature, special handling for copy and pastes (i.e. preventing them, or prompting for confirmation), recipient confirmation of real-time text via <link url="#activating_and_deactivating_realtime_text">Activating and Deactivating Real-Time Text</link>, etc.</p>
|
||||
</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 encrypt <rtt/> as well:</p>
|
||||
<p>Real-time text (<rtt/> elements) transmits the content contained within messages. Therefore, a client that encrypts <body/> also needs to 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 <message/> stanza level (e.g. XEP-0200) can be used for all stanzas containing either <rtt/> or <body/>. It is noted that real-time text can have a higher rate of message stanzas, contributing to additional overhead. See <link url="#congestion_considerations">Congestion Considerations</link>.</p></li>
|
||||
<li><p>Encryption at the <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>
|
||||
<li><p>Encryption at the <body/> level (e.g. deprecated XEP-0027) does 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">
|
||||
@ -1086,7 +1086,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>, 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 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>
|
||||
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user