Edits recommended from public discussion.
Lots of edits. Simplifications, improvements and corrections. Forward and backward compatible with version 0.1.
Real-time text is text transmitted live while it is being typed or created. The recipient can immediately read the sender's typing, without waiting before reading. This is similar to a telephone conversation where one listens "as words are spoken". This allows text to be used conversationally, provides a sense of contact, eliminates waiting times found in messaging, and is favored by deaf individuals who prefer text conversation. For a visual animation of real-time text, see RealJabber.org +
Real-time text is text transmitted instantly while it is being typed or created. The recipient can immediately read the sender's text as it is written, without waiting. Text can be used conversationally, similar to a telephone conversation, where one listens while the other is speaking. It eliminates waiting times found in messaging, and is favored by deaf and hard of hearing individuals who prefer text conversation. For a visual animation of real-time text, see RealJabber.org
Real-time text has been around for decades in various implementations:
Real-time text is suitable for smooth and rapid mainstream communication in text, as an all-inclusive technology to complement instant messaging. At the same time, real-time text has special usefulness to many audiences including the deaf and other people who cannot use speech on the telephone. This document defines a specification for real-time text transmitted in-band over an XMPP network.
+Real-time text is suitable for smooth and rapid mainstream communication in text, as an all-inclusive technology to complement instant messaging. At the same time, real-time text has special usefulness to many audiences including the deaf, hard of hearing, and other people who cannot use speech on the telephone. Real-time text is also beneficial in emergency situations, due to its immediacy. This document defines a specification for real-time text transmitted in-band over an XMPP network.
real-time text – Text transmitted live while it is being typed or created.
-real-time message – Recipient's real-time live view of the sender's message still being typed or created.
+real-time – A conversational latency of less than 1 second, as defined by ITU-T Rec. F.700
real-time text – Text transmitted in real-time while it is being typed or created.
+real-time message – Recipient's real-time view of the sender's message still being typed or created.
real-time message edit – An edit operation done by the remote sender, that is transmitted in real-time to the recipient.
action element – An XML element that represents a single real-time message edit, such as text insertion or deletion.
RTT – Acronym for real-time text.
Real-time text is transmitted via an <rtt/> child element of a <message/> stanza. The <rtt/> element is transmitted at regular intervals by the sender while a chat message is being composed, to allow the recipient to watch the sender type (and edit) the message before the full message is sent in a <body/> element.
+Real-time text is transmitted via an <rtt/> child element of a <message/> stanza. The <rtt/> element is transmitted at regular intervals by the sender while a message is being composed, to allow the recipient to see the sender type (and edit) the message before the full message is sent in a <body/> element.
This is a basic example of a real-time message "Hello, my Juliet!", transmitted live while it is being typed, before a final message delivery:
Example 1: Introductory Example
The <rtt/> element contains a series of one or more child elements called action elements that represent real-time message edits such as text being appended, inserted, or deleted. Example 1 illustrates only the <t/> action element, which appends text to the end of a message. For more information, see Real-Time Message Editing. Transmission of <rtt/> occurs at regular intervals whenever the sender is actively composing a message. If there are no changes to the message since the last transmission, no transmission occurs. For more information, see Transmission Interval. The namespace of the <rtt/> element is “urn:xmp:rtt:0”. The <rtt/> element contains a series of one or more child elements called action elements that represent real-time message edits such as text being appended, inserted, or deleted. Example 1 illustrates only the <t/> action element, which appends text to the end of a message. See Real-Time Text Operations. Transmission of the <rtt/> element occurs at regular intervals whenever the sender is actively composing a message. If there are no changes to the message since the last transmission, no transmission occurs. See Transmission Interval. The namespace of the <rtt/> element is “urn:xmpp:rtt:0”. There MUST NOT be more than one <rtt/> element per <message/> stanza.
@@ -150,183 +157,248 @@
-
This REQUIRED attribute is a counter to maintain the integrity of a real-time message. Senders MUST increment the seq attribute by 1 for each subsequent <rtt/> transmitted. Recipients MUST monitor the seq value to verify that it is incrementing. For more info, see Automatic Recovery of Real-Time Text.
-The bounds of seq is 31-bits, the range of positive values of a signed integer. The exception to the incrementing rule is <rtt/> elements with an 'event' attribute. In this case, senders MAY use any seq value as the new starting value. For best integrity, seq SHOULD be randomized. The new starting value SHOULD be less than 1 million to allow plenty of incrementing room, and to keep <rtt/> compact.
+This REQUIRED attribute is a counter to maintain the integrity of real-time text. (The bounds of seq is 31-bits, the range of positive values of a signed integer.)
+Senders MUST increment the seq attribute by 1 in each subsequent <rtt/> transmitted without an event attribute. When an <rtt/> element has an event attribute, senders MAY instead use any value as the new starting value for seq. A random starting seq value is RECOMMENDED for best integrity during Usage With Multi-User Chat and Simultaneous Logins. Senders MAY limit the size of the new starting seq value, to keep <rtt/> compact, and allow plenty of incrementing room without overflow.
+Recipients MUST monitor the seq value to verify the integrity of real-time text. See Keeping Real-Time Text Synchronized.
This attribute signals events for real-time messages, such as the start of a new real-time message. The event attribute is omitted from the <rtt/> element, when it is not needed, except in the following situations:
-event='new'
- Senders MUST use this value on the first <rtt/> element of a new message, which also delivers the first character(s) being typed in a message. Recipients MUST initialize a new real-time message for display, and then process action elements within this <rtt/>. A new seq value MAY be used.
event='reset'
- Identical to event='new', except it replaces the existing real-time message. Senders MAY use this attribute during Automatic Recovery of Real-Time Text. Recipients MUST support this attribute, and process action elements within this <rtt/> to replace the existing real-time message.
event='cancel'
- Senders MAY use this value to signal recipient to stop transmitting real-time text. Recipients SHOULD clear the real-time message, and discontinue sending back <rtt/> for the remainder of the current chat session until the sender sends another <rtt/> to resume real-time text. No action elements should be included within <rtt/>.
The first <rtt/> element in a chat session, signals the start of real-time text. The <rtt event='cancel'/> signals the end of real-time text in a chat session. There MUST NOT be more than one <rtt/> element per <message/>.
+This attribute signals events for real-time text, such as the start of a new real-time message. The event attribute MAY be omitted from the <rtt/> element during regular real-time text transmission. Recipients MUST ignore <rtt/> containing unsupported event values.
+| event | +Description | +Sender Support | +Recipient Support | +
|---|---|---|---|
| new | +Begin a new real-time message. | +REQUIRED | +REQUIRED | +
| reset | +Reset the current real-time message. | +RECOMMENDED | +REQUIRED | +
| init | +Initiate a real-time text session. | +OPTIONAL | +OPTIONAL | +
| cancel | +End a real-time text session. | +OPTIONAL | +OPTIONAL | +
event='new'
+ Senders MUST use this value when transmitting the first <rtt/> element containing Action Elements (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 <rtt/> 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 <rtt/> elements that do not contain an event attribute.
event='reset'
+ Recipients MUST treat 'reset' the same as 'new'. Senders MUST use 'new' only when the sender has started composing a new message, and use 'reset' when re-transmitting a real-time message. See Message Reset, used for Keeping Real-Time Text Synchronized and Basic Real-Time Text.
event='init'
+ Clients MAY use this value to signal the other end that real-time text is being activated. If used, this <rtt/> element MUST be empty with no action elements. See Activating and Deactivating Real-Time Text.
event='cancel'
+ Clients MAY use this value to signal the other end to stop transmitting real-time text. If used, this <rtt/> element MUST be empty with no action elements. Recipients SHOULD discontinue sending back <rtt/> elements for the remainder of the same chat session (or unless 'init' is used again). See Activating and Deactivating Real-Time Text.
Upon receipt of <body/>, the message becomes permanent and can not be edited any further. The delivered message is displayed instead of the real-time message. In the ideal case, the message from <body/> is redundant since this delivered message is identical to the final contents of the real-time message. When the sender begins composing a new message after a <body/> is sent, the next <rtt/> transmitted by the sender MUST contain the event='new' attribute.
+The real-time message is considered complete upon receipt of a <body/> element in a message stanza. The delivered message is displayed instead of the real-time message. In the ideal case, the message from <body/> is redundant since this delivered message is identical to the final contents of the real-time message.
+Senders MUST include an event attribute in the next <rtt/> element that is transmitted after a message stanza containing a <body/> element.
The real-time text standard simply provides early delivery of text before the <body/> element. The <body/> element continues to follow the &xmppcore; standard. Clients that do not support real-time text, will continue to behave normally, displaying complete lines of messages as they are delivered.
+The real-time text standard simply provides early delivery of text before the <body/> element. The <body/> element continues to follow the &xmppcore; specification. In particular, XMPP implementations need to ignore XML elements they do not understand. Clients that do not support real-time text, will continue to behave normally, displaying complete lines of messages as they are delivered.
For the best balance between interoperability and usability, the transmission interval of <rtt/> for a continuously-changing message SHOULD be approximately 0.7 second. This interval meets ITU-T Rec. F.700
For the best balance between interoperability and usability, the transmission interval of <rtt/> elements for a continuously-changing message SHOULD be approximately 0.7 second. This interval meets ITU-T Rec. F.700 for real-time conversation. If a different transmission interval needs to be used, the interval SHOULD be between 0.3 second and 1 second.
A longer interval will lead to a less optimal user experience. Conversely, a much shorter interval may more frequently trigger throttling or flooding protection algorithms in public XMPP servers, leading to dropped <message/> elements and/or Congestion Considerations.
To provide fluid real-time text, one or more of the following methods can be used:
The <rtt/> element MAY contain one or more action elements representing real-time message editing operations, including text being appended, inserted, or deleted.
-Most chat clients allow a sender to edit their message before sending (i.e. via a Send button, or hitting Enter). The inclusion of real-time functionality to existing chat client software must not degrade the sender's existing expectation of being able to edit their messages before sending. Thus, in a chat session with real-time text, the recipient can watch the sender compose and edit their message before it is delivered.
-This is a short summary of action elements that operate on a real-time message. For detailed information, see Action Elements.
+The <rtt/> element MAY contain one or more action elements representing real-time text operations, including text being appended, inserted, or deleted.
+Many chat clients allow a sender to edit their message before sending (via a Send button, or pressing Enter). The inclusion of real-time text functionality to existing client software, needs to preserve the sender's existing expectation of being able to edit their messages before sending. In a chat session with real-time text, the recipient can watch the sender compose and edit their message before it is delivered.
+This is a short summary of action elements that operate on a real-time message. For detailed information, see List of Action Elements.
| Action | Element | Description | +Sender Support | +Recipient Support | |
|---|---|---|---|---|---|
| Insert Text | <t p='#'>text</t> | -REQUIRED. Insert specified text at position p in message. | +Insert specified text at position p in message. | +REQUIRED | +REQUIRED |
| Backspace | <e p='#' n='#'/> | -REQUIRED. Remove n characters before position p in message. | +Remove n characters before position p in message. | +RECOMMENDED | +REQUIRED |
| Forward Delete | <d p='#' n='#'/> | -REQUIRED. Remove n characters starting at position p in message. | +Remove n characters starting at position p in message. | +RECOMMENDED | +REQUIRED |
| Interval | <w n='#'/> | -RECOMMENDED. Execute a pause of n thousandths of a second. | +Wait n thousandths of a second. | +RECOMMENDED | +RECOMMENDED |
The n attribute represents a length value. If the n attribute is omitted, the default value for n MUST be 1.
The p attribute represents an absolute position value. This is a 0-based index, where 0 represents the first character of the real-time message. If p is omitted, p MUST be treated as the length of the message (points to end of the real-time message).
For text modifications, both n and p attributes are based on Unicode Character Counting. Also see Ensuring Accuracy Of Attribute Values.
The n attribute is a length value.
+ If n is omitted, the default value of n MUST be 1.
The p attribute is an absolute position value, as a 0-based index (0 represents beginning of message).
+ If p is omitted, the default value of p MUST be the current message length (p defaults to end of message).
For text modifications, length and position (n and p) is based on Unicode Character Counting.
+ Also see Accurate Processing of Action Elements.
Senders MUST NOT use negative values for any attribute, nor use p values beyond the current message length. However, recipients receiving such values MUST clip negative values to 0, and clip excessively high p values to the current length of the real-time message. Modifications only occur within the boundaries of the current real-time message, and not other delivered messages.
Recipients are REQUIRED to support <t/>, <e/> and <d/> action elements for incoming <rtt/> transmissions, even if not all elements are used for outgoing <rtt/> transmissions. Support for <w/> is RECOMMENDED for both senders and recipients in order to accommodate Preserving Key Press Intervals. Recipients MUST ignore unexpected or unsupported elements within <rtt/>, while continuing to process subsequent action elements. Action elements are immediate child elements of the <rtt/> element, and are never nested. Examples can be found in Use Cases.
+Recipients MUST be able to process all <t/>, <e/> and <d/> action elements for incoming <rtt/> transmissions, even if senders do not use these for outgoing <rtt/> transmissions (e.g. Basic Real-Time Text). Support for <w/> is RECOMMENDED for both senders and recipients in order to accommodate Preserving Key Press Intervals. Recipients MUST ignore unexpected or unsupported elements within <rtt/>, while continuing to process subsequent action elements (Compatibility is ensured via Namespace Versioning). Action elements are immediate child elements of the <rtt/> element, and are never nested. See examples in Use Cases.
REQUIRED. Supports the transmission of key presses, text block inserts, and text being pasted.
- Note: Any text normally used in the <body/> element of a <message/> may be used. If the <t/> element is empty, no text modification takes place.
Supports transmission of text, including key presses, and text block inserts.
+ Note: Text can be any subset of text allowed in the <body/> element of a <message/>. If <t/> is empty, no text modification takes place.
text]]>
Appends specified text at the end of message. (p defaults to message length).
+ Note: This action element is the minimum sender support REQUIRED for Basic Real-Time Text.
text]]>
Inserts specified text at position p in the message text.
-text]]>
Appends specified text at the end of message. (p defaults to message length)
+ + +REQUIRED. Supports the behavior of Backspace key presses.
- Note: Excess backspaces, at the start of the message, MUST be ignored.
]]>
Remove n characters before position p in message.
+Supports the behavior of Backspace key presses. Text is removed towards beginning of the message.
+ Note: Excess backspaces MUST be ignored, with text being backspaced only to the beginning of the message in this case.
]]>
Remove 1 character from end of message. (Both n and p at default values)
]]>
Remove 1 character before position p in message. (n defaults to 1)
]]>
Remove n characters from end of message. (p defaults to message length)
-]]>
Remove 1 character from end of message. (Both n and p at default values)
+]]>
Remove n characters before position p in message.
+ + +REQUIRED. Supports the behavior of Delete key presses, text block deletes, and text being cut.
- Note: Excess deletes, beyond end of message, MUST be ignored.
]]>
Remove n characters beginning at position p in message.
+Supports the behavior of Delete key presses, and text block deletes. Text is removed towards end of the message.
+ Note:Excess deletes MUST be ignored, with text being deleted only to the end of the message in this case.
]]>
Remove 1 character beginning at position p in message. (n defaults to 1)
+]]>
Remove n characters beginning at position p in message.
RECOMMENDED. Allows the transmission of intervals between real-time message edits, such as the pauses between key presses. For more information, see Preserving Key Press Intervals.
+Allows the transmission of intervals between real-time message edits, such as the pauses between key presses. See Preserving Key Press Intervals.
]]>
Executes a pause of n thousandths of a second. This pause may be approximate, and not necessarily be of millisecond precision. The n value SHOULD NOT exceed the Transmission Interval. Also, if a Body Element arrives, pauses SHOULD be interrupted to prevent a delay in message delivery.
+Wait n thousandths of a second before processing the next action element. This pause MAY be approximate, and not necessarily be of millisecond precision. The n value SHOULD NOT exceed the Transmission Interval. Also, if a Body Element arrives, pauses SHOULD be interrupted to prevent a delay in message delivery.
Real-time message edits work only within the boundaries of the current real-time message, and do not affect previous messages. Senders MUST NOT use negative values for any attribute, nor use p values beyond the current message length. However, recipients receiving such values MUST clip negative values to 0, and clip excessively high p values to the current message length.
-For senders, p and n values are calculated relative to the plain text version of the message. This is the message otherwise normally transmitted in a <body/> element after all processing is complete, including emoticon graphics as plain text. For recipients, p and n are calculated relative to the message text immediately after XML processing, and before any further processing.
-Regardless of the original format of line breaks during XMPP transmission, line breaks are treated as a single code point (LINE FEED U+000A). Conversion of line breaks into a single line feed is REQUIRED for XML processors, according to section 2.11 of XML
For platform-independent interoperability, calculations of p and n values MUST be based on Unicode code points. Different platforms use different internal Unicode encodings, which may be different from the transmission encoding (UTF-8) for XMPP. Consider these factors:
+Real-time text is generated based on text normally allowed to be transmitted within the <body/> element.
+Incorrectly generated action elements may lead to inconsistencies between the sender and recipient during real-time editing. The Unicode characters of the real-time text needs to make it transparently from the sender to the recipient, without further Unicode character modifications. This is the chain between the sender's creation of real-time text, to the recipient's processing of real-time text. Transparent transmission of Unicode characters is possible with sender pre-processing, as long as the transmission from the sender to the recipient remains standards-compliant, including compliant XML processors and compliant XMPP servers.
+Any inconsistencies that occur during real-time message editing (i.e. non-compliant XMPP server that modifies messages) will recover during the next Message Reset, and also via Basic Real-Time Text.
+Senders MUST generate real-time text based on the plain text version of the sender's message with all processing completed. Processing include Unicode normalization, conversion of emoticons graphics to text, removal of illegal characters, line-break conversion, and all other Unicode character modifications. This MAY be done in parallel to the sender client's displayed version of the message (i.e. graphics, formatting, &xep0071;).
+For the purpose of calculating n and p values, line breaks MUST be treated as a single character, if line breaks are used within real-time text. It is noted conversion of line breaks into a single LINE FEED U+000A is REQUIRED for XML processors, according to section 2.11 of XML
For recipients, p and n are calculated relative to real-time text obtained from a compliant XML processor, before any further Unicode character modifications. (This includes recipient-side Unicode normalization. In an ideal and compliant scenario, normalizing an already normalized Unicode string, will result in no character modifications, and will not cause any issues.) Recipients MUST NOT do Unicode normalization (or any other code point modifications) on their internal copy of the real-time message, for accurate processing of subsequent action elements. (The recipient client can process the same text separately for display).
+Note that Element <t/> – Insert Text is allowed to contain any subset sequence of Unicode characters from the real-time message. This may result in certain situations where the text transmitted in <t/> elements is allowed to be temporarily an incorrectly-formed Unicode string. (i.e. non spacing characters, orphaned diacritic, orphaned control character including direction-change character for bidirectional Unicode, incompletely formed glyphs, etc.) but becomes correct when inserted into the middle of the recipient's real-time message, and passes recipient validation/normalization with no character modifications. Note that a compliant XML processor does not modify or fix Unicode errors caused by taking only a subset of characters from correctly-formed Unicode text. One alternative way for implementers to visualize this, is to visualize the Unicode text as an array of individual code points, and treat the p and n values accordingly.
+For platform-independent interoperability, calculations of length and position values (p and n) MUST be based on Unicode code points. A single UTF-8 encoded character equals one code point. However, many platforms use different internal encodings (i.e. string formats) that is different from the transmission encoding (UTF-8). Consider these factors:
Multiple Unicode code points may represent one displayable Unicode glyph (i.e. combining marks).
- Action elements operate on Unicode code points, not on displayable character glyphs.
Characters U+10000 through U+1FFFF, which are single code points, but are represented as multiple surrogate code units in certain Unicode encodings (i.e. UTF-16).
- Action elements operate on Unicode code points, not on individual surrogate code units.
Some Unicode encodings use a variable number of bytes per Unicode character (i.e. UTF-8).
Action elements operate on Unicode code points, not on individual bytes.
Multiple Unicode code points (e.g. combining marks) may combine into one displayable character.
+ Action elements operate on individual Unicode code points, not on displayable characters.
Unicode code points for characters U+10000 through U+10FFFF are represented as a surrogate pair in some Unicode encodings (e.g. UTF-16).
+ Action elements operate on individual Unicode code points, not on the separate components of a surrogate pair.
Some Unicode encodings use a variable number of bytes per Unicode code point (e.g. UTF-8).
Action elements operate on individual Unicode code points, not on individual bytes.
Incorrectly calculated p and n values may cause scrambled text during real-time message editing for many languages. This scrambled text persists until full message delivery, or Message Retransmission. From the perspective of p and n values, a real-time message is treated equivalent to an editable array of Unicode code points, even if not necessarily stored as such.
-Incorrectly calculated length and position values (p and n) can result in inconsistencies in the real-time message, such as scrambled text. If this happens, this situation can recover during the Message Reset.
+Length and position values (p and n) are relative to the internal Unicode text of the real-time message, independently of the directionality of actual displayed text. Any existing Unicode text direction can be used (right-to-left, left-to-right, and bidirectional). From the perspective of length and position values (p and n), a real-time message is treated equivalent to an editable array of Unicode code points, even if not necessarily stored as such.
+ +In a chat session with real-time text, it is critical that the real-time message is identical on both the sender and recipient ends. The loss of a single <rtt/> transmission can represent missing text, or a missing edit. This leads to the real-time message getting out of sync. Recovery of in-progress real-time message is useful in several situations:
+In a chat session, it is important that real-time text stays identical on both the sender and recipient ends. The loss of a single <rtt/> transmission could represent missing text or missing edits. Also, recipients can connect after the sender has already started composing a message. Recovery of in-progress real-time message via Message Reset is useful in several situations:
To stay synchronized, for <rtt/> elements that do not contain an 'event' attribute:
+For <rtt/> elements that does not contain an event attribute:
The sync is considered lost if the seq attribute of the <rtt/> element does not increment as expected. Trying to process certain action elements, after loss of sync, can result in scrambled text. Therefore, to avoid this situation:
-Recipients MUST keep track of separate real-time messages per sender, including maintaining independent seq values. Recipients MAY also use additional methods to distinguish Simultaneous Logins, including using the full JID and/or <thread/>.
Recovery occurs when any of the following happens:
-In order to prevent recipients from waiting for Recovery From Loss of Sync, senders SHOULD retransmit the contents of a partially-composed message, in the following situations:
+Loss of sync occurs if the seq attribute does not increment as expected when Staying In Sync. In this case:
A message retransmit is done using the <rtt/> attribute event='reset' (see RTT Attributes).
+Recovery occurs when the recipient receives the following:
+A message reset is a retransmission of the sender's partially composed text. The recipient refreshes the real-time message as a result. It allows real-time text conversation to resume quickly, without waiting for senders to start a new message.
+Retransmission SHOULD be done at an average interval of 10 seconds during active typing or composing. This interval is frequent enough to minimize user waiting time, while being infrequent enough to reduce bandwidth overhead. This interval MAY vary in order to reduce average bandwidth requirements for minor message changes and/or for long messages. For quicker recovery, senders MAY adjust the timing of the message retransmissions to occur right after any of the following additional events:
+A message reset is done using the <rtt/> attribute event value of 'reset' (see RTT Attributes).
Retransmission SHOULD be done at a regular interval of 10 seconds, unless there are no message changes. This interval is frequent enough to minimize user waiting time, while being infrequent enough to reduce bandwidth overhead. This interval MAY vary in order to reduce average bandwidth requirements for minor message changes and/or for long messages.
+Note: That there are no restrictions on using multiple Action Elements during a message reset. (e.g. typing or backspacing occurring at the end of a retransmitted message.)
If a client supports this real-time text protocol, it MUST advertise that fact in its responses via &xep0030; information ("disco#info") requests by returning a feature of urn:xmpp:rtt:0
+If a client supports this real-time text protocol, it is strongly RECOMMENDED to advertise that fact in its responses via &xep0030; information ("disco#info") requests by returning a feature of urn:xmpp:rtt:0
Example 1. A disco#info query
If this successful response of <feature var='urn:xmpp:rtt:0'/> is not received, the client SHOULD NOT transmit any outgoing <rtt/> elements in <message/> transmissions. This avoids unnecessary consumption of bandwidth to clients that do not support this protocol.
+Enabling/disabling of discovery is SHOULD NOT be the default method of activating/deactivating real-time text. See Activating and Deactivating Real-Time Text.
+In the absence of feature discovery, sender clients MAY send a single blank <rtt/> element at the beginning of the session (or upon sender attempting to initiate real-time text), as a method of indicating to the recipient that real-time text is permitted until the end of the chat session. Senders SHOULD NOT send any further <rtt/> until incoming <rtt/> is received during the same chat session, or when support is confirmed via discovery.
The recipient can watch the sender fluidly compose/edit their message in real-time without any “bursting” effects. This is “Natural Typing”, and appears indistinguishable from local typing. When key press intervals are preserved at high precision, all subtleties of typing are preserved, including the 'mood' (calm typing versus panicked or emphatic typing, etc). For an example transmission of key intervals, see Full Message Including Key Press Intervals.
There are specialized situations such as live transcriptions and captioning (i.e. transcription service, closed captioning provider, captioned telephone, relay services, Remote CART) that demands low latency transmission. Such systems typically use voice recognition and/or stenotype machines, which output text in word bursts rather than a character at a time. Senders with bursty output MAY immediately transmit word bursts of text without buffering. This eliminates any lag caused by the Transmission Interval. It is NOT REQUIRED to monitor or transmit Element <w/> – Interval for transcription. If additional accuracy is required, it is also possible to timecode the <rtt/> elements.
+There are specialized situations such as live transcriptions and captioning (e.g. transcription service, closed captioning provider, captioned telephone, Communication Access Realtime Translation (CART), relay services) that demands low latency transmission. Such systems typically use voice recognition and/or stenotype machines, which output text in word bursts rather than a character at a time. It is acceptable for senders with bursty output to immediately transmit word bursts of text without buffering. This eliminates any lag caused by the Transmission Interval. It is not necessary to transmit Element <w/> – Interval for real-time transcription.
Some software platforms (i.e. JavaScript, BOSH, mobile devices, etc.) may have low-precision timers that impact Transmission Interval and/or Preserving Key Press Intervals. Clients MAY optimize for bandwidth, performance and/or screen repaints by eliminating, merging, or ignoring Element <w/> – Interval selectively, especially those containing shorter intervals. The transmission interval of <rtt/> MAY also vary, either intentionally for optimizations, or due to precision limitation.
-Clients MAY choose to implement alternate text-smoothing methods, such as adaptive-rate character-at-a-time output, and/or word buffering for incoming real-time text. Word buffering prevents most typing mistakes from being displayed, which can be a useful mode of operation for certain recipients who may dislike watching the sender's typing mistakes.
+Some software platforms (e.g. JavaScript, BOSH, mobile devices) may have low-precision timers that impact Transmission Interval and/or Preserving Key Press Intervals. Clients can optimize for bandwidth, performance and/or screen repaints by eliminating, merging, or ignoring Element <w/> – Interval selectively, especially those containing shorter intervals. It is acceptable for the transmission interval of <rtt/> to vary, either intentionally for optimizations, or due to precision limitation.
+Clients can choose to implement alternate text-smoothing methods, such as adaptive-rate character-at-a-time output, and/or word buffering for incoming real-time text. Word buffering prevents most typing mistakes from being displayed, which can be a useful mode of operation for certain recipients who may dislike watching the sender's typing mistakes.
For sending clients, there are several potential methods of capturing typing and message edits, in order to generate action elements for an <rtt/> transmission. However, instead of monitoring key presses directly, the most reliable and practical method is to monitor the text changes to the local message text field:
+Implementors can choose a preferred activation method for real-time text. For example, clients in the assistive market can choose to do immediate activation of real-time text. Popular mainstream clients might do user-initiated activation/confirmation of real-time text. The confirmation process could be similar to common activation methods used for audio/video. It is also beneficial for senders and recipients to easily synchronize the enabling/disabling of real-time text.
+Activation of real-time text in a chat session (immediate or user-initiated) can be done by:
In a text change event, the current message string can be compared to the previous message string in order to calculate what text changes took place. The appropriate action elements are then generated, to represent text insertions and deletions. If Preserving Key Press Intervals are supported, then the interval is implemented as the time elapsed between text change events. For additional information, see Action Elements and Rules for Attribute Values. The following guidelines are for clients that use keyboard input.
+Recipients can respond to incoming real-time text with an appropriate response, such as:
+It is not necessary for senders or recipients to transmit <rtt event='init'/> first, as any incoming RTT Element (other than <rtt event='cancel'/>) signals the start of incoming real time text. However, it permits signaling before the sender begins typing. It also permits sender signaling of a desire to begin real-time text, regardless of discovery in Determining Support.
+It is acceptable for recipients to display incoming real-time text without activating outgoing real-time text (such as while waiting for user confirmation). Care needs to be taken to prevent this situation from becoming confusing to the user. Implementors can add other additional behaviors that are appropriate, such as an introductory message upon first activation, for Privacy considerations.
Real-time text can be deactivated by any of:
Monitor typing via the technique in Monitoring Message Edits to generate action elements, and add these action elements to a buffer. This is equivalent to recording a small sequence of typing.
During every Transmission Interval, all buffered action elements are transmitted in <rtt/> element of a <message/>. This is equivalent to transmitting a small sequence of typing at a time.
If there are no changes to the real-time message, then no unnecessary <rtt/> transmission takes place.
Recipients can respond to deactivation by any one or more of the following:
Upon receipt of a <message/> containing an <rtt/> element, the action elements in <rtt/> are added to a queue, in the order that they are received. This provides immunity to variable network conditions, since the buffering action smooths out the latency fluctuations of <message/> delivery.
The recipient software should interpret the action elements in the playback queue in sequential order, including <w/> elements (intervals), into a real-time message. This is equivalent to playing back the sender's original typing, including key press intervals.
Processing of intervals (<w/> elements) SHOULD be done via non-blocking programming techniques.
Upon receiving a <message/> containing <body/> indicating a completed message, the full message SHOULD be displayed immediately in place of the real-time message, and unprocessed action elements cleared from the playback queue. This ensures final message delivery is not delayed by late processing of action elements.
If support for the <w/> element is not possible, receiving software SHOULD use an alternate text-smoothing method. See Reduced Precision Text Smoothing Methods for more info.
If the playback queue contains too much delay in <w/> elements (i.e. <w/> elements from two <rtt/> transmissions ago), the recipient client MAY ignore or shorten the intervals of <w/> elements, to allow lagged real-time text to "catch up" more quickly.
Sending an <rtt event='cancel'/> is useful in situations where the user closes a chat window, and ends the chat session. It is useful when the user wants to deactivate real-time text, while still continuing the chat session. After deactivation, either party may reactivate real-time text again in accordance to Activation Methods.
Recipient clients MAY choose to display a cursor (or caret) within incoming real-time messages. This enhances usability of real-time text further, since it becomes easier for a recipient to observe the sender's real-time message edits. Recipient clients that do not support a remote cursor, can simply ignore calculating a cursor position, and skip this section.
+Recipient clients might choose to display a cursor (or caret) within incoming real-time messages. This enhances usability of real-time text further, since it becomes easier for a recipient to observe the sender's real-time message edits.
+Recipient clients that do not support a remote cursor, can simply ignore calculating a cursor position, and skip this section. All action elements only have absolute positioning, and positioning does not depend on previous action elements, so clients do not need to remember the previous cursor position.
All action elements always have absolute cursor positioning. When <t/>, <e/>, or <d/> action elements are processed in incoming real-time text, the beginning value for the cursor position calculation is the absolute position value of the p attribute, according to Rules for Attribute Values. The cursor position immediately after an action element, is calculated as follows:
+When <t/>, <e/>, or <d/> action elements are processed in incoming real-time text, the beginning value for the cursor position calculation is the absolute position value of the p attribute, according to Summary of Attribute Values. The recipient can calculate the cursor position as follows:
After Element <t/> – Insert Text, the cursor position is the p attribute plus the length of the text being inserted. The cursor position is put at the end of inserted text.
- This mimics normal forward cursor movement during text insertion.
After Element <e/> – Backspace, the cursor position is the p attribute minus the n attribute. If the n value is greater than p, then cursor position becomes 0.
- This mimics normal cursor response to a Backspace key.
After Element <e/> – Backspace, the cursor position is the p attribute minus the n attribute.
+ This is the normal backwards cursor movement to a Backspace key.
After Element <d/> – Forward Delete, the cursor position is the p attribute, unaffected by the n attribute.
- This mimics normal cursor response to a Delete key.
After an empty Element <t/> – Insert Text (in the format of <t p='#'/> with no text to insert), the cursor position is the p attribute, and no text modification is done.
This allows cursor response to arrow keys and/or mouse repositioning the cursor.
The remote cursor SHOULD be clearly distinguishable from the sender's real local cursor. One example is to use a non-blinking cursor, easily emulated with a Unicode character or the vertical bar character '|'.
-Whenever the cursor is moving without any text modifications (via arrow keys or mouse), the sender MAY transmit extra Element <t/> – Insert Text with an empty string to update the remote cursor position via attribute p. This maintains accurate positioning for the remote cursor in recipients that support a remote cursor. These extra elements are ignored by recipients that do not support a remote cursor.
-Monitoring the actual cursor position may need to be done via a “selection changed” event of a text box field in many programming platforms. This event typically monitors text marking/selection operations, and doubles as the event for monitoring the cursor position.
+The remote cursor needs to be clearly distinguishable from the sender's real local cursor. One example is to use a non-blinking cursor, easily emulated with a Unicode character or the vertical bar character '|'.
+It is acceptable for the sender to transmit Element <t/> – Insert Text as empty elements (with the cursor position in the p attribute) whenever the cursor position is changing without any text modifications (i.e. via arrow keys or mouse). This allows recipients supporting a remote cursor, to show the cursor movements. These extra elements are ignored by recipients that do not support a remote cursor.
There are other special basic considerations for real-time message transmissions that need to be considered by implementors.
-A large sequence of rapid message changes may generate a large series of action elements in an <rtt/> element, resulting in the <message/> exceeding the XMPP server's maximum allowed length of a <message/> stanza. This may result in dropped messages. It is acceptable to simply retransmit the whole real-time message using <rtt event='reset'/> if the length of the <rtt/> element would otherwise exceed the application's maximum chat message length.
-For long messages, the final <rtt/> transmission may be made in a separate <message/> than the <message/> containing the <body/>. For example:
-
-
The message MAY be split into two separate message transmissions:
-Senders may choose to implement Message Reset as the only method of transmitting changes to real-time message. The entire message is simply retransmitted every Transmission Interval whenever there are any text changes. The below is a transmission of the real-time message “HELLO THERE BOB!” at regular intervals while the sender is typing. The advantage is very simple sender implementation. However, disadvantages include the lack of Preserving Key Press Intervals, and extra bandwidth consumption that can occur with longer messages. The use of Element <t/> – Insert Text without any attributes, simply appends text to the end of a message, while the use of Element <e/> – Backspace without any attributes, simply deletes text from the end of the message. This is useful if mid-message editing capabilities are not used (e.g. news tickers, relay services, captioned telephone). If mid-message editing is needed without adding sender support for other Action Elements, the use of Message Reset can be a simple solution to support this situation. In this situation, disadvantages include the lack of Preserving Key Press Intervals, and extra bandwidth consumption that can occur with longer messages. Real-time text can be generated via a key press event. However, this does not have the advantages of Monitoring Message Changes Instead Of Key Presses. Care needs be taken with automatic changes to the message, generated by means other than key presses. This includes spell check auto-correct, copy and pastes, transcription, input method editors, and multiple key presses required to compose a character (i.e. accents). As a result, experience has found that key press events are not the best way to do real-time text over messaging. Experience has found that the most reliable and practical method is to monitor the text changes to the local message text field, since: During a text change event, the current message string can be compared to the previous message string, in order to calculate what text changes took place. The first changed character and last changed character is determined. From this, it is then possible to generate action elements for text insertion and deletions. In addition, if Preserving Key Press Intervals are supported, then the interval is implemented as the time elapsed between text change events. For additional information, see Action Elements and Summary of Attribute Values. Monitor the message change event. Whenever message change occur, compute action elements and add these action elements to a buffer. This is equivalent to recording a small sequence of typing. During every Transmission Interval, all buffered action elements are transmitted in <rtt/> element of a <message/>. This is equivalent to transmitting a small sequence of typing at a time. If there are no changes to the real-time message, then no unnecessary <rtt/> transmission takes place. Upon receving <rtt/> elements, the action elements are added to a queue, in the order that they are received. This provides immunity to variable network conditions, since the buffering action smooths out the latency fluctuations of message transmission. The recipient software interprets the action elements in the queue in sequential order, including pauses from Element <w/> – Interval. This is equivalent to playing back the sender's original typing, including key press intervals. Upon receiving a <body/> element indicating a completed message, the full message can be displayed immediately in place of the real-time message, and unprocessed action elements cleared from the playback queue. This ensures final message delivery is not delayed by late processing of action elements. If the playback queue contains too much delay in <w/> elements (i.e. <w/> elements from two <rtt/> transmissions ago), the recipient client can ignore or shorten the intervals of <w/> elements, to allow lagged real-time text to "catch up" more quickly. It is best to process Element <w/> – Interval via non-blocking programming techniques. There are other special basic considerations for real-time message transmissions that need to be considered by implementors. 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 Preserving Key Press Intervals 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 Message Reset can instead be used, in order to save bandwidth. (Stream compression is another approach.) 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 Message Reset. 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/>. For specialized clients that sends continuous real-time text (e.g. news ticker, captioning, transcription, TTY gateway), an automatic-send feature can be implemented when messages reaches a certain length. This allows continuous real-time text without real-time messages becoming excessively large. Real-time text MAY be accompanied with XEP-0085 &xep0085;. These are simple guidelines for <message/> stanzas that include an <rtt/> element: Real-time text can be used in conjunction with XEP-0085 &xep0085;. These are simple guidelines for <message/> stanzas that include an <rtt/> element: The in-band nature of this real-time text standard allows one-to-many situations. Thus, real-time text is compatible with &xep0045; (MUC), as well as concurrent simultaneous logins. Support for real-time text in MUC is OPTIONAL, and is fully Backwards Compatible with group chat participants that do not support real-time text. 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. For MUC, the RTT Element event attribute value of 'cancel' SHOULD NOT be used. This prevents one participant from suppressing real-time text for all participants in a group chat. Participants that turn off real-time text for themselves, can simply ignore incoming <rtt/> and not transmitting outgoing <rtt/>. Participant clients without real-time text (whether unsupported or turned off) will simply see group chat function normally on a line-by-line basis. Participants that enable real-time text during group chat, need to keep track of separate real-time messages on a per-participant basis, via full JID. As a result, participants with real-time text, will see real-time text coming from each participant that have real-time text enabled. Software MAY hide idle real-time messages to minimize on-screen clutter when more than one person is typing. Congestion control MAY also be used, via automatic adjustment of Transmission Interval, see Congestion Considerations. Clients can implement this specification only for one-on-one chat. However, it is appropriate to support <rtt/> elements in MUC, even if not all participants support real-time text. Participants that enable real-time text during group chat, need to keep track of multiple concurrent real-time messages on a per-participant basis. As a result, participants with real-time text, will see real-time text coming from each participant that have real-time text enabled. Participants that turn off real-time text for themselves, can simply ignore incoming <rtt/> and not transmit outgoing <rtt/>. Participant clients without real-time text (whether unsupported or turned off) will simply see group chat function normally on a line-by-line basis, since it is Backwards Compatible. For the same participant logged in multiple times in the same room, see Simultaneous Logins. For <rtt/> elements, the event attribute of 'init' or 'cancel' is not appropriate for MUC since they are intended for one-on-one use. To minimize on-screen clutter of multiple idle real-time messages, clients can hide idle messages, clear old Stale Messages, and/or prioritize the display of the most useful real-time messages. Prioritization can be recent typists and/or moderators (e.g. classroom teacher, convention speaker). In situations of simultaneous typing by a large number of participants, see Congestion Considerations. 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, the existing Automatic Recovery of Real-Time Text already catches this situation until there is only one typist. A good implementation of Message Retransmission will improve user experience, regardless of whether or not XEP-0296 is used (&xep0296;). Alternatively, clients MAY choose to improve on this behavior, by keeping track of multiple separate real-time messages per full JID, similar to Multi-User Chat. 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, Keeping Real-Time Text Synchronized will pause the real-time message upon conflicting <rtt/>, and resume during the next Message Reset, presumably from the active login. This provides a seamless system-switching experience. A good implementation of Message Reset 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 Multi-User Chat, with the Stale Messages being timed-out. 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 Multi-User Chat. In addition, it may be a resource-consumption concern, as part of Congestion Considerations. 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 Multi-User Chat, 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). Senders that resumes composing a message (i.e. continues a partially-composed message hours later) can transmit a Message Reset, which allows recipients to redisplay the real-time message. With real-time text, frequent screen updates may occur. Screen updates are a potential performance bottleneck, because fast typists type many key presses per second. Optimizing screen updates becomes especially important for slower platforms. Real-time messages should be updated efficiently in a flicker-free manner. Alternatively, to improve performance, the display of real-time messages may be implemented as a separate window or separate display element. Battery life considerations are closely related to performance, as the addition of real-time text may impact battery life. If Preserving Key Press Intervals are supported, then the implementation of Element <w/> – Interval should be implemented in a battery-efficient manner. The Transmission Interval may vary dynamically to optimize for battery life and wireless reception. For devices where screen updates are an unavoidable inefficient bottleneck, see Reduced Precision Text Smoothing Methods to reduce the number of screen updates per second. Also see &xep0286;. With real-time text, frequent screen updates may occur. Screen updates are a potential performance bottleneck, because fast typists type many key presses per second. Optimizing screen updates becomes especially important for slower platforms. Real-time messages needs to be updated efficiently in a flicker-free manner. Alternatively, to improve performance, the display of real-time messages may be implemented as a separate window or separate display element. Battery life considerations are closely related to performance, as the addition of real-time text may impact battery life. If Preserving Key Press Intervals are supported, then the implementation of Element <w/> – Interval needs to be implemented in a battery-efficient manner. The Transmission Interval may vary dynamically to optimize for battery life and wireless reception. For devices where screen updates are an unavoidable inefficient bottleneck, see Low-Bandwidth And Low-Precision Text Smoothing to reduce the number of screen updates per second. Also see &xep0286;. According to ITU-T Rec. F.703, the “Total Conversation” accessibility standard defines the simultaneous use of audio, video, and real-time text. For convenience, chat applications may be designed to have automatic negotiation of as many as possible of the three media preferred by the users. In the XMPP session environment, the Jingle protocol (&xep0166;) is available for negotiation and transport of the more time-critical, real-time audio and video media. Any combination of audio, video, and real-time text MAY be used together simultaneously. According to ITU-T Rec. F.703, the “Total Conversation” accessibility standard defines the simultaneous use of audio, video, and real-time text. For convenience, messaging applications may be designed to have automatic negotiation of as many as possible of the three media preferred by the users. In the XMPP session environment, the Jingle protocol (&xep0166;) is available for negotiation and transport of the more time-critical, real-time audio and video media. Any combination of audio, video, and real-time text can be used together simultaneously.
-
+
+
+
+
+
+
+
Most of these examples are deliberately kept simple. In software implementations supporting key press intervals, transmissions will most resemble the last example, Full Message Including Key Press Intervals.
-Most of these examples are deliberately kept simple. In complete software implementations supporting key press intervals, transmissions will most resemble the last example, Full Message Including Key Press Intervals. All three examples shown below result in the same real-time message "HELLO" created by writing "HLL", backspacing two times, and then "ELLO". Resulting real-time message: "Hello back" The above code sends the misspelled "HLL", then <e/><e/> backspaces 2 times, then sends "HELLO". Resulting real-time message: "Hello back" The above code shows that <e n='2'/> does the same thing as <e/><e/>. The above code splits the same real-time text over multiple stanzas, which would occur if the typing was occurring more slowly, over several Transmission Interval cycles. The below example represents a short chat session of three separate messages: Resulting real-time message: "Hello back" This is based on a moderate typing speed transmitted at a normal Transmission Interval. This example also illustrates the following: Resulting real-time message: "Hello, this is Alice!" Final result of real-time message: "Hello, this is Alice!" Resulting real-time message: "Hello Bob, this is Alice!" Final result of real-time message: "Hello Bob, this is Alice!" Resulting real-time message: "Hello Bob, this is Alice!" Final result of real-time message: "Hello Bob, this is Alice!" This is an example message containing multiple consecutive real-time message edits. Normally, the action elements are split into multiple separate transmissions. This example also does not illustrate Preserving Key Press Intervals. The Cursor Pos column is only relevant if the Optional Remote Cursor is implemented. Representing a short chat session of three separate messages: This example also illustrates the following: Normally, the action elements are split into multiple separate transmissions. This example also does not illustrate Preserving Key Press Intervals. *The Cursor Position column is only relevant if the Optional Remote Cursor is implemented. This example is a transmission of “Hello there!” while Preserving Key Press Intervals. It illustrates a four-second typing sequence: In between each key press, is Element <w/> – Interval to allow the receiving client execute a small pause between action elements, which allows the playback of the typing at its original look-and-feel. This example also illustrate the following:
-
+
- This code sends the misspelled "Hello bcak", then <e/><e/><e/> backspaces 3 times, then sends "ack".
-
- This code is the same as the previous example, demonstrating that <e n='3'/> does the same thing as <e/><e/><e/>.
-
+ Bob says: "Hello Alice"
+ Bob says: "This is Bob"
+ Bob says: "How are you?"
+
- This code results in the same final text as the previous two examples, segmented into four separate messages.
+
-
+
This code outputs "Hello Bob, this is Alice!" then <d n='4' p='5'/> deletes 4 characters from position 5.
(This erases the text " Bob" including the preceding space character).
-
+
This is because the code outputs "Hello, this is Alice!" then the <t p='5'> inserts the specified text " Bob" at position 5.
-
+
This code outputs "Hello Bob, tihsd is Alice!", then <d p='11' n='5'/> deletes 5 characters at position 11 in the string of text. (erases the mistyped word "tihsd"). Finally, <t p='11'>this</t> inserts the text "this" place of the original misspelled word.
- Element
Action
Real -Time Message
- Cursor Pos
+ Cursor Position*
- <t>Helo</t>
@@ -632,67 +815,9 @@
12
- Bob says: "Hello Alice"
- Bob says: "This is Bob"
- Bob says: "How are you?"
-
-
-
-
-
-
There are other real-time text formats with interoperability considerations relating to the session setup level, the media transport level, and presentation level. For each environment where interoperability is supported, an interoperability specification should be documented that covers addressing, session control, media negotiation and media transcoding.
+There are other real-time text formats with interoperability considerations relating to the session setup level, the media transport level, and presentation level. For each environment where interoperability is supported, an interoperability specification needs to be documented that covers addressing, session control, media negotiation and media transcoding.
It is noted there is also another real-time text standard (RFC 4103, IETF RFC 5194
It is noted there is also another real-time text standard (RFC 4103, IETF RFC 5194
One environment for such interoperability considerations is SIP with real-time text (also called Text over IP, or ToIP) as specified in ITU-T T.140 and IETF RFC 4103. This protocol combination is specified by IETF, and by regional emergency service organizations, to be one of the protocols supported for IP based real-time emergency calls that support real-time text. Another reason is that SIP is the currently dominating peering protocol between services, and many implementations of real-time text in SIP exist.
+One environment for interoperability considerations is SIP with real-time text (also called Text over IP, or ToIP) as specified in ITU-T T.140 and IETF RFC 4103. This protocol combination is specified by IETF, and by some emergency service organizations, to be one of the protocols supported for IP based real-time emergency calls that support real-time text. Another reason is that SIP is a popular real-time session control protocol. Also, there are many implementations of real-time text that is being controlled by SIP.
Interoperability implies addressing translation, media negotiation and translation, and media transcoding. For media transcoding between this specification and T.140/RFC 4103, the real-time text transcoding is straight forward, except the editing feature of this specification. Backwards positioning and insertion or deletion far back in the message can cause a large number of erase operations in T.140, that takes time and bandwidth to convey.
-It should be noted that T.140 specifies use of ISO 6429 control codes for presentation characteristics such as text color etc, that are not covered in this version of this specification. All control codes from both sides that cannot be presented on the other side of the conversion, must be filtered off in order to not disturb the presentation of text.
+It is noted that T.140 specifies the use of ISO 6429 control codes for presentation characteristics, such as text color, that are not covered in this version of this specification. All control codes from both sides that cannot be presented on the other side of the conversion, needs to be filtered off in order to not disturb the presentation of text.
Also, see Total Conversation – Combination With Audio And Video.
The main internationalization consideration involve real-time message editing of international and mixed-language text. Correct calculations for Action Elements based on Unicode Character Counting is necessary to avoid scrambled text for many languages.
+The primary internationalization consideration involve real-time message editing via Action Elements, where text is inserted and deleted using index and position values. In particular, correct Unicode Character Counting needs to be followed, due to the existence of variable-length encodings and right-to-left text. Also, Accurate Processing of Action Elements will ensure that all possible valid Unicode text can be used via this protocol. This can include text containing multiple scripts/languages, ideographic symbols (e.g. Chinese), right-to-left text (e.g. Arabic), and bidirectional text.
+For accessibility considerations, there is an International Symbol of Real-Time Text
+
It is important for implementors of real-time text to educate users about real-time text. Users of real-time text should be aware that their typing in the local input buffer is now visible to everyone in the current chat conversation. This may have security implications if users copy & paste private information into their chat entry buffer (i.e. a shopping invoice) before editing out the private parts of the pasted text (i.e. a credit card number) before they send the message. With real-time message editing, recipients can watch all text changes that occur in the sender's text, before the sender sends the final message.
+It is important for implementors of real-time text to educate users about real-time text. Users of real-time text needs to be aware that their typing is now visible in real-time to everyone in the current chat conversation. This may have security implications if users copy & paste private information into their chat entry buffer (e.g. a shopping invoice) before editing out the private parts of the pasted text (e.g. a credit card number) before they send the message. With real-time message editing, recipients can watch all text changes that occur in the sender's text, before the sender sends the final message. Implementation behaviors and improved education can be added to reduce privacy issues. Examples include introduction upon first activation of feature, special handling for copy and pastes (i.e. preventing them, or prompting for confirmation), recipient confirmation of real-time text via Activating and Deactivating Real-Time Text, etc.
+Real-time text (<rtt/> elements) transmit the content contained within messages. Therefore, a client that encrypts <body/>, also needs to also encrypt <rtt/> as well:
+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.
Encryption at the stanza level (e.g. &xep0200;) can be used for all stanzas containing either <rtt/> or <body/>. It is worth noting that stanza-level encryption produces significantly more overhead, due to the increased number of stanzas that real-time text causes, leading to Congestion Considerations.
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.
The nature of real-time text result in more frequent transmission of <message/> elements than may otherwise happen in a non-real-time text conversation. This may lead to increased network and server loading of XMPP networks. Care SHOULD to be taken to use a reasonable Transmission Interval, and avoid transmitting messages at an excessive rate, to avoid creating unnecessary congestion on public XMPP networks. Also, see &xep0205;.
-Network monitoring mechanisms (i.e. &xep0184; and/or &xep0199;, etc.) MAY be used to monitor reliability and latency, in order to temporarily adjust the interval to prevent failure of real-time text transmissions during extreme network conditions. This is also useful for mission-critical applications such as Next Generation 9-1-1 emergency services.
-The load between participants using this specification in the recommended way, will cause a load that is only marginally higher than a user communicating without this specification. Bandwidth overhead of real-time text is very low compared to many other activities possible on XMPP networks including VoIP and file transfers.
+The nature of real-time text result in more frequent transmission of <message/> stanzas than may otherwise happen in a non-real-time text conversation. This may lead to increased network and server loading of XMPP networks.
+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 Transmission Interval 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 Message Reset can also retransmit real-time text lost by poor network conditions, including stanzas dropped by the server. This is also useful for mission-critical applications such as Next Generation 9-1-1 emergency services.
+Excess numbers of real-time messages (e.g. during DoS scenario in Multi-User Chat) might cause local resource-consumption issues, which can be mitigated by accelerated time-out of Stale Messages.
+Use of this specification in the recommended way will cause a load that is only marginally higher than a user communicating without this specification. Bandwidth overhead of real-time text is very low compared to many other activities possible on XMPP networks including in-band file transfers and audio.
The author would like to thank Real-Time Text Taskforce (R3TF) at www.realtimetext.org for their contribution to the technology documented in this specification. Members of R3TF who have contributed to this document, including corrections and edits, include Gunnar Helstrom, Barry Dingle, Paul E. Jones, Arnoud van Wijk, and Gregg Vanderheiden.
-“Natural Typing”, the technique of preserving key press intervals, is acknowledged as an invention by Mark Rejhon, who is deaf. This technology is provided to XMPP.org as part of this specification in compliance of the XSF's Intellectual Property Rights Policy at http://xmpp.org/extensions/ipr-policy.shtml. For more information, see Appendix C: Legal Notices.
+The author would like to thank Real-Time Text Taskforce (R3TF) at www.realtimetext.org for their contribution to the technology documented in this specification. Mark Rejhon leads the Jabber/XMPP Taskgroup at R3TF. Members of R3TF who have contributed to this document, include Gunnar Helstrom (Omnitor), Paul E. Jones (Cisco), Gregg Vanderheiden (Trace R&D Center, University of Wisconsin), Barry Dingle (Interopability Leader, R3TF), and Arnoud van Wijk (Founder, R3TF). Others contributors include Bernard Aboba (Microsoft), Austin McKinley (Facebook), Christian Vogler (Gallaudet University), Norm Williams (Gallaudet University).
+“Natural Typing”, the technique of preserving key press intervals, is acknowledged as an invention by Mark Rejhon, who is deaf. This technology is provided to XMPP.org as part of this specification in compliance of the XSF's Intellectual Property Rights Policy at http://xmpp.org/extensions/ipr-policy.shtml.
+