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 while allowing 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 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='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.

This OPTIONAL attribute is used only if &xep0308; (XEP-0308) is implemented. Sender clients MAY use this attribute to allow recipient clients to have improved presentation of real-time text during message correction (e.g. shown as in-place editing of previous message).

This id attribute refers to the <message/> stanza containing the <body/> that is being edited (See 'Business Rules' in XEP-0308). If used at all, then id MUST be included in all <rtt/> elements transmitted during message correction of the previous message. When switching messages being edited (i.e. editing the current message versus editing the previous message), the first <rtt/> element MUST contain an event attribute value, such as 'reset' (See Message Reset).

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.

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

• 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 in other delivered messages.

Recipients MUST be able to process all <t/>, <e/> and <d/> action elements for incoming <rtt/> transmissions, even if senders do not use all of these for outgoing <rtt/> transmissions (e.g. 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.

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.

For <rtt/> elements that do not contain an event attribute:

1. Senders MUST increment the seq attribute for consecutively transmitted <rtt/> elements.
2. Recipients MUST monitor the seq attribute value of received <rtt/> elements, to verify that it is incrementing.

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

Loss of sync occurs if the seq attribute does not increment as expected when Staying In Sync. In this case:

• Recipients MUST freeze the current real-time message; and
• Recipients MUST ignore action elements within the current and subsequent <rtt/> elements; and
• An indication can be used to show the loss of sync (e.g. color coding, modified chat state message).

Recovery occurs when the recipient receives the following:

• A <body/> element. The Body Element supersedes the real-time message.
• An <rtt/> element containing an event attribute (e.g. new message, or Message Reset).

A message reset is a retransmission of the sender's partially composed text. The recipient can redisplay the real-time message as a result. It allows real-time text conversation to resume quickly, without waiting for senders to start a new message.

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: 

• When the recipient starts sending messages from a different full JID (e.g. switched systems);
• When the recipient sends a presence update (e.g. from offline to online);

• When the sender resumes composing after an extended pause (e.g. recovery from Stale Messages handling);

• When the conversation is unlocked (e.g. section 5.1 of &xmppim;);

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

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

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 long Transmission Interval is used without Preserving Key Press Intervals, then incoming text will appear in intermittent bursts if the display of text is not smoothed. This hurts user experience of real-time text.

For high quality presentation of real-time text, the original look-and-feel of typing can be preserved independently of the transmission interval. This is achieved using Element <w/> – Wait Interval between other Action Elements. Sender clients can transmit the length of pauses between key presses, and send multiple key presses in a single <message/> stanza. Recipient clients that process <w/> elements are able to display the sender's typing smoothly, without sudden bursts of text. See Examples of Key Press Intervals.

When key press intervals are preserved at high precision, all subtleties of typing are preserved, including the 'mood' (calm typing versus panicked or emphatic typing, etc.). Much as VoIP allows accurate packet transmission of sound, this spec allows accurate packet transmission of original typing look-and-feel. This enables the real-time feel of typing over virtually any network connection, without requiring frequent transmission intervals. Look and feel of typing is also preserved over variable latency connections including &xep0206;, mobile phone, satellite and long international connections with heavy packet-bursting tendencies.

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/> – Wait Interval for real-time transcription.

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/> – Wait Interval selectively, especially those containing shorter intervals. In addition, it is acceptable for the transmission interval of <rtt/> to vary, either intentionally for optimizations, or due to precision limitation. &xep0138; can also be used.

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.

Activation of real-time text in a chat session (immediate or user-initiated) can be done by:

• Immediately transmitting real-time text (if allowed after Determining Support); or
• Signaling first (by transmitting a single <rtt event='init'/> and waiting for response).

Recipient clients can respond to incoming real-time text with an appropriate response, such as:

• Accepting immediately (by activating in response); or
• Accepting after recipient confirmation (by also activating in response, after a user confirmation prompt); or
• Deny (by transmitting <rtt event='cancel'/> which is used in Deactivation Methods); or
• Ignoring (by discarding incoming <rtt/> as a last resort, without using Deactivation Methods).

If Determining Support allows, then 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 allows signaling of activation before the sender begins typing.

In the absence of Determining Support, sender clients can send a single <rtt event='init'/> element to attempt to activate real-time text. It is inappropriate for sender clients to send any further <rtt/> elements unless support is confirmed by discovery, or when the recipient client responds with incoming <rtt/> elements during the same chat session.

It can be acceptable for software to display incoming real-time text without activating outgoing real-time text. Displaying incoming real-time text while waiting for user confirmation, can be educational to users unfamiliar with real-time text. Care needs to be taken to prevent this situation from becoming confusing to the user. Implementers can add other additional behaviors that are appropriate, such as an introductory note upon first activation, for Privacy considerations.

Real-time text can be deactivated by any of:

• Sending a signal (using <rtt event='cancel'/> upon deactivation, deny, or end of chat session); or
• Simply ending the chat session (without transmitting any further <rtt/> elements).

Recipient clients can respond to deactivation with appropriate responses, such as:

• Deactivating in response (stop transmitting <rtt/> elements); and
• Handling any unfinished incoming real-time message (clearing and/or saving it); and
• Inform the recipient user that real-time text has ended (or denied/cancelled, if no real-time text was received).

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.

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 is the normal forward cursor movement during text insertion.

• 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 is the normal stationary 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 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.

Experience has found that the most reliable method for generating real-time text, is to monitor for text changes to the sender’s message entry field, instead of key press events. Text change events have the following advantages:

• It captures all typing, including edits and deletes.
• It captures copy & paste operations, as well as edits made via a pointing device.
• It captures all automatic text changes (e.g. spell checker, auto-correct, macros, transcription, assistive devices).
• It captures characters requiring multiple key presses to compose (e.g. accents, combining marks).
• It makes no assumptions about different keyboards or input method editors (e.g. Chinese).
• Text change events are more portable across platforms, including on mobile phones.

During a text change event, the sender’s current message text can be compared to the old message text (from before the text change event). In order to calculate what text changes took place, the first changed character and the last changed character is determined. From this, it is possible to generate Action Elements for any text insertion and deletions. In addition, if Preserving Key Press Intervals is supported, then Element <w/> – Wait Interval records the time elapsed between text change events.

Sender software can do the following:

1. Monitor for text changes in the sender’s message. Whenever a text change event occurs, compute action elements and append these action elements to a buffer. This is equivalent to recording a small sequence of typing.

2. During every Transmission Interval, all buffered action elements are transmitted in <rtt/> element in a <message/> stanza. This is equivalent to transmitting a small sequence of typing at a time.

3. If there are no message changes occurring, no unnecessary transmission takes place.

Real-time text can be generated via monitoring key presses. 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). Key press events do not capture these text changes, and this can cause real-time text to go out of sync between the sender and the recipient.

Sender clients 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!” at regular intervals while the sender is typing.

Hel Hello th Hello there! ]]>

The advantage is very simple implementation. However, disadvantages include the lack of Preserving Key Press Intervals, and extra bandwidth consumption that can occur with longer messages, unless stream compression is used.

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 erases text from the end of the message. These simple action elements are useful if mid-message editing capabilities are not used (e.g. simple transcription, news tickers, relay services, captioned telephone).

If editing is needed in the middle of a message, without adding sender support for other Action Elements, the use of Message Reset supports situations where mid-message editing takes place. In this situation, the disadvantages include the lack of Preserving Key Press Intervals, and extra bandwidth consumption that can occur with longer messages, unless stream compression is used.

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 send continuous real-time text (e.g. news ticker, captioning, transcription, TTY gateway), a Body Element can be automatically sent when messages reach a certain length. This allows continuous real-time text without real-time messages becoming excessively large.

Real-time text can be used in conjunction 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 appropriate for use with &xep0045; (MUC), as well as concurrent simultaneous logins.

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 resume 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 can occur. Screen updates are a potential performance bottleneck, since fast typists type many key presses per second. Optimizing screen updates becomes especially important for slower platforms. Real-time messages need to be displayed efficiently in a flicker-free manner. The real-time message might be implemented as a separate window or separate display element.

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/> – Wait 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.

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.

Hello Bob, this is Alice! ]]>

Final result of real-time message: "Hello, this is Alice!"
This example outputs "Hello Bob, this is Alice!" then <d n='4' p='5'/> deletes 4 characters from position 5. The Element <d/> – Forward Delete removes the text " Bob" including the preceding space character.

Hello, this is Alice! Bob ]]>

Final result of real-time message: "Hello Bob, this is Alice!"
This is because this example outputs "Hello, this is Alice!" then the <t p='5'> inserts the specified text " Bob" at position 5, using Element <t/> – Insert Text.

Hello Bob, tihsd is Alice! this ]]>

Final result of real-time message: "Hello Bob, this is Alice!"
This example outputs "Hello Bob, tihsd is Alice!", then <d p='11' n='5'/> deletes 5 characters at position 11 in the string of text (which erases the mistyped word "tihsd"). Finally, <t p='11'>this</t> inserts the text "this" place of the original misspelled word.

This is an example message containing multiple consecutive real-time message edits. This illustrates valid use of the <rtt/> element.

Helo lo...planet World there, ]]>

Resulting real-time message: "Hello there, World", completed in the following series of action elements:

*The Cursor Position column is only relevant if the Optional Remote Cursor is implemented.

This example does not illustrate Preserving Key Press Intervals. Also, it is noted that most situations, during normal typing speeds at a normal Transmission Interval, the series of Action Elements will typically be spread over multiple separate <rtt/> elements.

All examples shown below, result in the same real-time message “HELLO”. Only the last example follows Preserving Key Press Intervals.

HELLO ]]>

The above example outputs “HELLO” in a single action element (Element <t/> – Insert Text).

H E L L O ]]>

The above example outputs “HELLO” in separate action elements for each key press.

H E L L O ]]>

The above example outputs “HELLO” in separate action elements for each key press, while also Preserving Key Press Intervals. The Element <w/> – Wait Interval specifies the number of milliseconds between key presses, to allow smooth presentation in recipient clients that support <w/> action elements.

This example is a transmission of “Hello there!” while Preserving Key Press Intervals. It illustrates a four-second typing sequence:

• The misspelled phrase “Hello tehre!” is typed;
• Optional transmission of cursor movements towards the typing mistake;
• Two backspaces to delete the typing mistake;
• Two correct key presses to correctly spell the word “there”.

The use Element <w/> – Wait Interval, between key presses, allows the receiving client execute a small pause between action elements. This allows recipient clients to play back the sender's typing fluidly.

H e l l o t e h r e ! h e Hello there! ]]>

This example also illustrates the following:

• Typing is done via Element <t/> – Insert Text.
• Backspaces are done via Element <e/> – Backspace.
• There is a final transmission with a Body Element, when the message is finished.
• Intervals between key presses are done via Element <w/> – Wait Interval.
• Each <message/> is delivered at a regular Transmission Interval, typically 0.7 seconds.
• Cursor movements via empty <t/> elements. Sender transmission is not essential, but can be desirable for recipient clients supporting an Optional Remote Cursor.
• Recipient clients that do not support Preserving Key Press Intervals and/or Optional Remote Cursor, will still display this message normally.
• The total sum of all values in Element <w/> – Wait Interval in one <message/> equal the Transmission Interval during periods of continuous typing. This also results in some <w/> interval elements being split between consecutive messages. Although not critical, it can further improve the fluidity of Receiving Real-Time Text.
• See Monitoring Message Changes Instead Of Key Presses for more info.