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 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:

1. 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.

2. 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.

3. 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/>. 

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.

This is a short summary of action elements that operate on a real-time message. For detailed information, see Action Elements.

• 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.

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.

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 XML: Extensible Markup Language 1.0 (Fifth Edition). <http://www.w3.org/TR/xml/>., so a compliant XML processor already do this automatically, and already provide the correct original Unicode text for interoperability.

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:

• 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.

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.

To stay synchronized, for <rtt/> elements that do not contain an 'event' attribute:

1. The sender MUST increment the seq attribute for consecutive <rtt/> element.
2. The recipient MUST monitor the seq attribute value of received <rtt/> elements, to verify that it is incrementing.
3. The seq values for incoming messages, versus outgoing messages, are independent and kept track of separately.

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:

1. The recipient MUST stop processing all subsequent action elements, and pause the current real-time message.
2. An indicator MAY be used by the recipient to indicate the loss of sync. (i.e. reception bars, color code, missing text indicator, chat state message)

Recovery occurs when any of the following happens:

1. A message <body/> is delivered. The Body Element replaces the real-time message.
2. The event attribute of <rtt/> has a value of new or reset. Processing of real-time MUST restart, with the new starting seq value obtained from this <rtt/> element.

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:

• When the recipient's presence changes. (i.e. offline to online)
• When the recipient sends a <message/> from a different full JID than before. (i.e. Simultaneous Logins)
• At regular intervals, to allow recovery from unexpected situations such as lost <message/> stanzas.

A message retransmit is done using the <rtt/> attribute event='reset' (see RTT Attributes).

This is a retransmission of the entire real-time message. ]]>

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.

If a long Transmission Interval is used without Preserving Key Press Intervals, then text will appear in intermittent bursts if the display of text is not smoothed. This hurts user experience of real-time text.

For the highest quality display of text being typed, using Element <w/> – Interval allows the original look-and-feel of typing to be preserved, independently of the transmission interval. Using the <w/> element, the sender can record multiple key presses including key press intervals, and transmit them over the XMPP network in a single <message/>. The recipient can then play back the sender's typing in real-time at original typing speed including the intervals between key presses.

Much like VoIP is a packetization of sound, this spec enables packetization of typing including the original key press intervals. This enables the real-time feel of typing over virtually any network connection, without requiring frequent transmission intervals. Look and feel of typing is also preserved over variable latency connections including &xep0206;, mobile phone, satellite and long international connections with heavy packet-bursting tendencies.

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.

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.

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:

• it captures all typing, including edits and deletes.
• it captures cut & paste operations, as well as edits made via a pointing device.
• it captures automatic text changes, such as done by spell checker, macros, assistive devices, etc.
• it captures accented characters, Chinese, Arabic and other characters that require multiple key presses to compose.
• it makes no assumptions about different keyboards or input entry methods.
• text change events are more cross-platform portable, including on mobile phones.

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.

• 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.

• 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.

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:

• 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 <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.

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:

Hello World...In a Super Long Message! [etc] Hello World...In a Super Long Message! [etc] ]]>

The message MAY be split into two separate message transmissions:

Hello World...In a Super Long Message! [etc] Hello World...In a Super Long Message! [etc] ]]>

Real-time text MAY be accompanied with XEP-0085 &xep0085;. These are simple guidelines for <message/> stanzas that include an <rtt/> element:

• For <rtt/> transmitted without an accompanying <body/>, include <composing/> chat state.
• For <rtt/> transmitted with an accompanying <body/>, include the <active/> chat state.
• Other chat states are handled as specified by XEP-0085 Chat States.

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.

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;.

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.