From 34cac59db511d15e626570ab4ce0eb34593d3b90 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Mon, 8 Apr 2013 09:40:05 -0600 Subject: [PATCH] 0.8 --- xep-0301.xml | 334 +++++++++++++++++++++++++++++---------------------- 1 file changed, 189 insertions(+), 145 deletions(-) diff --git a/xep-0301.xml b/xep-0301.xml index b959b4eb..40787e4c 100644 --- a/xep-0301.xml +++ b/xep-0301.xml @@ -7,7 +7,9 @@
In-Band Real Time Text - This is a specification for real-time text transmitted in-band over an XMPP session. + This is a specification for real-time text transmitted in-band over an XMPP session. + Real-time text is text transmitted instantly while it is being typed or + created. &LEGALNOTICE; 0301 Experimental @@ -16,7 +18,8 @@ Council XMPP Core - XEP-0020 + XMPP IM + XEP-0030 @@ -28,6 +31,15 @@ markybox@gmail.com http://www.realjabber.org + + 0.8 + 2013-04-08 + MDR +

Several clarifications made to several sections. + Removed references to proprietary products. New "Processing Rules" section added. + Set a default <rtt/> event attribute value of 'edit', if no event + attribute is specified.

 + 0.7 2012-08-08 @@ -98,66 +110,65 @@

This document defines a specification for real-time text transmitted in-band over an XMPP network.

-

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. Real-time text has been around for decades in various implementations:

+

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. It allows text to be used as conversationally as a telephone conversation, including in situations where speech is not practical (e.g. environments that must be quiet, environments too noisy to hear, restrictions on phone use, situations where speaking is a privacy or security concern, and/or when participant(s) are deaf or hard of hearing). It is also used for transmission of live speech transcription.

+

Real-time text is found in various implementations:

  • The 'talk' command on UNIX systems since the 1970's.
    • -
  • TTY and text telephones.
    • -
  • For SIP, real-time text is sent using IETF RFC 4103 RFC 4103: RTP Payload for Text Conversation. <http://tools.ietf.org/html/rfc4103>. with ITU-T T.140 ITU-T T.140: Protocol for multimedia application text conversation. <http://www.itu.int/rec/T-REC-T.140>. presentation coding.
    • -
  • The Real-Time IM AOL AIM Real Time Text: <http://help.aol.com/help/microsites/microsite.do?cmd=displayKC&externalId=223568>. feature found in AOL Instant Messenger.
    • -
  • A component within Total Conversation, used by Reach112 Reach112: European emergency service with real-time text. <http://www.reach112.eu>. in Europe, an accessible emergency service with real-time text.
    • +
  • Session Initiation Protocol (SIP), utilizing IETF RFC 4103 + RFC 4103: RTP Payload for Text Conversation <http://tools.ietf.org/html/rfc4103>. real-time text.
    • +
  • Instant messaging enhancements, including a Gallaudet University collaboration, Real-Time IM + Gallaudet University Technology Access Program collaboration project: Real-Time IM <http://tap.gallaudet.edu/text/aol/>..
    • +
  • Next generation emergency services (IETF RFC 6443 + RFC 6443: Framework for Emergency Calling Using Internet Multimedia <http://tools.ietf.org/html/rfc6443>.).
- - - -

Real-time text allows continuous and rapid communication in text, to complement general-purpose instant messaging. It can also allow immediate conversation in situations where speech cannot be used (e.g. quiet environments, privacy, deaf and hard of hearing). Real-time text is also beneficial in emergency situations, due to its immediacy. For a visual animation of real-time text, see Real-Time Text Taskforce +

For a visual animation of real-time text, see Real-Time Text Taskforce Real-Time Text Taskforce, a foundation for real-time text standardization <http://www.realtimetext.org>..
    -
  1. Allow transmission of real-time text with a low latency.
    2. -
  2. Balance low latencies versus system, network and server limitations.
    3. +
  3. Allow reliable transmission of real-time text with a low latency.
  4. Support message editing in real-time, including text insertions and deletions.
  5. Support transmission and reproduction of the original intervals between key presses, to preserve look-and-feel of typing independently of transmission intervals.
    -
  1. Reliable real-time text delivery.
  2. Be backwards compatible with XMPP clients that do not support real-time text.
    3. -
  3. Minimize reliance on network traversal mechanisms and/or out-of-band transmission protocols.
    4. -
  4. Compatible with multi-user chat (MUC) and simultaneous logins.
    5. +
  5. Be compatible with multi-user chat (MUC) and simultaneous logins.
    6. +
  6. Minimize reliance on out-of-band transmission protocols, for simpler network traversal.
    -
  1. Allow use within existing instant-messaging user interfaces, with minimal UI modifications.
    2. -
  2. Allow alternate optional presentations of real-time text, including split screen and/or other layouts.
    3. -
  3. Protocol design ensures integrity of real-time text, and allows extensions for new features.
    4. -
  4. Allow use within gateways to interoperate with other real-time text protocols, including RFC 4103 and ITU-T T.140.
    5. +
  5. Allow seamless integration of real-time text into instant messaging clients, with minimal user interface modifications.
    6. +
  6. Be able to function over intermittent and unreliable connections, including mobile phones.
    7. +
  7. Allow use within gateways to interoperate with other real-time text protocols, including RFC 4103 and ITU-T T.140 + ITU-T T.140: Protocol for multimedia application text conversation <http://www.itu.int/rec/T-REC-T.140>..
    -
  1. Allow XMPP to follow the ITU-T Rec. F.703 ITU-T Rec. F.703: Multimedia conversational services. <http://www.itu.int/rec/T-REC-F.703>. Total Conversation standard for simultaneous voice, video, and real-time text.
    2. +
  2. Allow XMPP applications to be able to implement ITU-T Rec. F.703 + ITU-T Rec. F.703: Multimedia conversational services <http://www.itu.int/rec/T-REC-F.703>. Total Conversation standard for simultaneous voice, video, and real-time text.
  3. Be a candidate technology for use with next generation emergency services (e.g. 9-1-1 and 1-1-2).
  4. Be suitable for transcription services and (when coupled with voice at user's choice) for TTY/text telephone alternatives, relay services, and captioned telephone systems.
    5. -
  5. Allow immediate conversational text through mobile phone text messaging and mainstream instant messaging.

action element – An XML element that represents a single real-time message edit, such as text insertion or deletion.

character - A single Unicode code point. See Unicode Character Counting.

-

real-time – A conversational latency of less than 1 second, as defined by ITU-T Rec. F.700 ITU-T Rec. F.700: Framework Recommendation for multimedia services <http://www.itu.int/rec/T-REC-F.700>., section 2.1.2.1.

-

real-time text – Text transmitted instantly while it is being typed or created.

+

real-time – A conversational latency of less than 1 second, as defined by ITU-T Rec. F.700 + ITU-T Rec. F.700: Framework Recommendation for multimedia services <http://www.itu.int/rec/T-REC-F.700>., section 2.1.2.1.

+

real-time text – Text transmitted instantly while it is being typed or created, to allow recipient(s) to immediately read the sender's text as it is written, without waiting.

real-time message – Recipient's real-time view of the sender's message still being typed or created.

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 client while a message is being composed, to allow the recipient to see the latest message text from the sender, without waiting for the full message sent in a <body/> element.

-

This is a basic example of a real-time message "Hello, my Juliet!” transmitted in real-time while it is being typed, before a final message delivery in a <body/> element (to remain Backwards Compatible):

+

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 client while a message is being composed. This allows the recipient to see the latest message text from the sender, without waiting for the full message to be sent in a <body/> element.

+

This is a basic example of a real-time message "Hello, my Juliet!” transmitted in real-time while it is being typed, before a final message delivery in a <body/> element (to remain Backwards Compatible):

Example 1: Introductory Example

@@ -167,13 +178,13 @@ - my + my J - Juliet! + uliet! @@ -183,86 +194,105 @@ -

The <rtt/> element contains a series of one or more child elements called action elements that represent Real-Time Text Actions 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.

+

The <rtt/> element contains one or more child elements that represent Real-Time Text Actions 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.

Transmission of the <rtt/> element occurs at a regular Transmission Interval whenever the sender is actively composing a message. If there are no changes to the message since the last transmission, no transmission occurs.

There MUST NOT be more than one <rtt/> element per <message/> stanza.

The namespace of the <rtt/> element is “urn:xmpp:rtt:0”.

 -

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 SHOULD limit the size of the new starting seq value, to keep <rtt/> compact while allowing plenty of incrementing room, and prevent wraparound from ever happening.

-

Recipients MUST monitor the seq value to verify the integrity of real-time text. See Keeping Real-Time Text Synchronized.

+

This REQUIRED attribute is a counter to maintain the integrity of real-time text. Senders MUST increment this value by 1 for each subsequent edit to the same real-time message, including when appending new text. Recipients MUST monitor the seq value as an integrity check on received 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. Recipient clients MUST ignore <rtt/> containing unsupported event values. The use of <rtt/> elements without an event attribute is for transmitting changes to an existing real-time message. The event attribute is used in the situations specified below:

+

This attribute signals events for real-time text.

+ + - + + + + + + + + + - + + - + +
event DescriptionAction Elements Sender Support Recipient Support
new Begin a new real-time message.Yes REQUIRED REQUIRED
resetReset the current real-time message.Re-initialize the real-time message.Yes RECOMMENDED REQUIRED
editModify existing real-time message.YesOPTIONALREQUIRED
initSignals the start of real-time text.Signals activation of real-time text.No OPTIONAL RECOMMENDED
cancelSignals the end of real-time text.Signals deactivation of real-time text.No OPTIONAL RECOMMENDED
-

event='new'
- Senders MUST use this value when transmitting the first <rtt/> element containing Action Elements (i.e. when sending the first character(s) of a new message). Recipient clients MUST initialize a new real-time message for display, and then process action elements within the <rtt/> element. If a real-time message already exists, from the same sender in the same chat session, its content MUST be replaced (i.e. cleared prior to processing action elements). Senders MAY send subsequent <rtt/> elements that do not contain an event attribute.

-

event='reset'
- For recipients, both 'new' and 'reset' are logically identical, and differ only for implementation purposes (e.g. highlighting newly-started messages). Recipient clients MUST initialize a new real-time message for display, and then process action elements within the <rtt/> element. If a real-time message already exists, from the same sender in the same chat session, its content MUST be replaced (i.e. cleared prior to processing action elements). Senders MAY send subsequent <rtt/> elements that do not contain an event attribute. Recipients MUST be able to process 'reset' without first receiving 'new'. 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. It can be used to signal activation of real-time text before starting a new real-time message (since it may take a while before the sender starts composing). If used, this <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.

+

If the event attribute is omitted, event='edit' is assumed as the default. When Action Elements are used (e.g. text appends, insertions and deletions), the <rtt/> element MAY contain one or more of any action elements, in any order. When action elements are not allowed, the <rtt/> element MUST be empty. Recipient clients MUST ignore <rtt/> elements containing unrecognized event values.

 -

This attribute is used only if &xep0308; (XEP-0308) is implemented at the same time as this specification. If a client supports both XEP-0301 and XEP-0308, clients MUST use this attribute if real-time text is used during editing of the previously delivered message.

-

This id attribute refers to the <message/> stanza containing the <body/> that is being edited (See 'Business Rules' in XEP-0308). When used, id MUST be included in all <rtt/> elements transmitted during message correction of the previous message. The whole message MUST be retransmitted via <rtt event='reset'/> (Message Reset) when beginning to edit the previous message, or when switching between messages (e.g. editing the new partially-composed message versus editing of the previously delivered message).

+

This attribute is used only if Last Message Correction (XEP-0308) is implemented along with this specification. See Usage with Last Message Correction to enable real-time text during editing of the previous message.

 + +
    +

  • Initialize a new real-time message: <rtt event='new'/> and <rtt event='reset'/>
    + Sender clients MUST use either element as the first <rtt/> transmission of a new real-time message. Recipient clients MUST initialize a new blank real-time message for display, and then process all Action Elements (e.g. text insertions and deletions) included within the <rtt/> element. If a real-time message already exists from the same sender in the same chat session, its content MUST be seamlessly replaced (i.e. cleared prior to immediately processing action elements).

    • +

  • Both <rtt event='new'/> and <rtt event='reset'/> are logically identical to recipients, except for presentation:
    + For recipients, these differ only for optional presentation purposes (e.g. highlighting newly started incoming messages). Senders SHOULD use event='new' when sending the first text of a new message (e.g. the first key presses), and only use event='reset' when doing Message Refresh or Simple Real-Time Text. See Keeping Real-Time Text Synchronized.

    • +

  • Sending modifications of a real-time message: Outgoing <rtt event='edit'/> or <rtt/>
    Sender clients SHOULD transmit this element at a regular Transmission Interval while the message is being modified. The seq attribute MUST increment by 1 for every consecutive modification transmitted. See Sending Real-Time Text.

    • +

  • Receiving modifications of a real-time message: Incoming <rtt event='edit'/> or <rtt/>
    Recipient clients must verify that the seq attribute increments by 1 in consecutively received <rtt/> elements from the same sender. If seq increments as expected, the Action Elements (e.g. text insertions and deletions) included with this element MUST be processed to modify the existing real-time message. Otherwise, if seq does not increment as expected, or if no real-time message already exists, the real-time message is considered out of sync and all subsequent modifications MUST be ignored until a new real-time message is initialized via event='new' or event='reset'. See Keeping Real-Time Text Synchronized.

    • +

  • Committing a real-time message: Delivery of a <body/> element
    + A real-time message is considered complete upon receiving <body/>. See Body Element.

    • +

  • Starting real-time text: <rtt event='init'/>
    + Clients MAY use this value to signal activation of real-time text without first starting a real-time message, since the sender may not start composing immediately. The seq attribute is ignored by recipient clients. See Activating and Deactivating Real-Time Text.

    • +

  • Ending real-time text: <rtt event='cancel'/>
    + Clients MAY use this value to signal deactivation of real-time text. Clients receiving this element SHOULD also discontinue sending <rtt/> elements for the remainder of the same one-on-one chat session (until event='init' is used again), and handle any unfinished real-time messages appropriately (e.g. clearing or saving the message). The seq attribute is ignored by recipient clients. See Activating and Deactivating Real-Time Text.

    • +

  • Starting value for seq attribute:
    Sender clients MAY use any new starting value for seq when initializing a real-time message using event='new' or event='reset'. Recipient clients receiving such elements MUST use this seq value as the new starting value. A random value is RECOMMENDED for improved integrity during Usage with Multi-User Chat and Simultaneous Logins. The bounds of seq are 31-bits, the range of positive values for a signed 32-bit integer.

    • +
+ -

The real-time message is considered complete upon receipt of a <body/> element in a <message/> stanza. The delivered text in the <body/> element is considered the final message text, and supersedes the real-time message. In the ideal case, the text from the <body/> element is redundant since this delivered text is identical to the final contents of the real-time message.

-

Senders MAY transmit the <body/> element in the same or separate message stanza as the one containing the <rtt/> element. 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 message is considered complete upon receipt of a standard <body/> element (as qualified by the 'jabber:client' namespace in &xmppim;). The delivered text within <body/> is considered the final message text, and supersedes the real-time message. In the ideal case, the text within <body/> is redundant since it is identical to the final contents of the real-time message.

+

Sender clients MAY transmit the <body/> element in the same or separate <message/> stanza as the one containing the final <rtt/> element for the real-time message. To continue sending real-time text in subsequent <message/> stanzas, the sender client MUST first initialize a new real-time message according to Processing Rules.

-

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 real-time text standard simply provides early delivery of text before the <body/> element. The <body/> element continues to follow the XMPP IM 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 default transmission interval of <rtt/> elements for a continuously-changing message SHOULD be approximately 0.7 seconds. This interval meets ITU-T Rec. F.700 Section A.3.2.1 for good quality real-time conversation. If a different transmission interval needs to be used, the interval SHOULD be between 0.3 seconds and 1 second.

-

A longer interval will lead to a less optimal user experience in most network conditions. Conversely, a much shorter interval can lead to Congestion Considerations. To provide fluid real-time text, one or more of the following methods can be used:

+

For the best balance between interoperability and usability, the default transmission interval of <rtt/> elements for a continuously-changing message SHOULD be approximately 700 milliseconds. This interval makes it possible for clients to meet ITU-T Rec. F.700 Section A.3.2.1 for good quality real-time text conversation in many network environments. If a different transmission interval needs to be used, the interval SHOULD be between 300 and 1000 milliseconds.

+

A longer interval will lead to a less optimal user experience. Conversely, a much shorter interval can lead to Congestion Considerations. To provide fluid real-time text, one or more of the following methods can be used:

  • Preserving Key Press Intervals for natural typing display, independently of the transmission interval.
    • -
  • Use of Time Critical and Low Latency Methods, for real-time captioning/transcription.
    • +
  • Use of Time Critical and Low Latency Methods, for real-time captioning/speech transcription.
  • For other options or reduced-precision options, see Low-Bandwidth and Low-Precision Text Smoothing.
 -

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, in existing client software, needs to preserve the sender's existing expectation of being able to edit their messages. In a chat session with real-time text, the recipient can see the sender compose and edit their message before it is completed.

+

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 seamless inclusion of real-time text functionality, in existing client software, needs to preserve the sender's existing expectation of being able to edit their messages. In a chat session with real-time text, the recipient can see the sender compose and edit their message before it is completed.

-

This is a short summary of action elements that operate on a real-time message. These elements are kept compact in order to save bandwidth, since a single <rtt/> element can contain a huge number of action elements (e.g. during Preserving Key Press Intervals). For detailed information, see List of Action Elements.

+

This is a short summary of action elements that operate on a real-time message.

@@ -293,6 +323,7 @@
ActionRECOMMENDED
+

These elements are kept compact in order to save bandwidth, since a single <rtt/> element can contain a huge number of action elements (e.g. during Preserving Key Press Intervals). See List of Action Elements for details.
    @@ -301,17 +332,17 @@

  • For Element <t/> – Insert Text and Element <e/> – Erase Text:
    The p attribute is an absolute position value, as a character position index into the real-time message, where 0 represents the beginning of the message. If p is omitted, the default value of p MUST point to the end of the message (i.e. p is set to the current length of the real-time message).

  • For the purpose of this specification, the word "character" represents a single Unicode code point. See Unicode Character Counting.

    • -

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

    • +

  • Senders MUST NOT use negative values for any attribute, nor use p values bigger than 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.

 -

Recipients MUST be able to process all <t/> and <e/> 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.

+

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

Supports the 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.

+ Note: Text can be any subset of text allowed in the <body/> element of a <message/>. If <t/> is empty or blank, no text modification takes place.

text]]>

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

+ Note: This action element is the minimum support REQUIRED for sender clients (i.e. speech transcription, chat bots, and Simple Real-Time Text are still possible without supporting additional action elements).

text]]>

Inserts specified text at position p in the message text.

@@ -319,8 +350,8 @@ -

Supports the behavior of backspace key presses. Text is removed towards beginning of the message. This element is also used for all delete operations, including the delete key, and text block deletes.
- Note: Excess backspaces MUST be ignored. Thus, text is backspaced only to the beginning of the message, in situations where the value of p is excessively large.

+

Supports the behavior of backspace key presses. Text is removed towards beginning of the message. This element is also used for all delete operations, including the backspace key, the delete key, and text block deletes.
+ Note: Excess backspaces MUST be ignored. Thus, text is backspaced only to the beginning of the message, in situations where n is larger than p.

]]>

Remove 1 character from end of message. (n defaults to 1, and p defaults to message length)

]]>

@@ -333,65 +364,67 @@

Allow for the transmission of intervals, between real-time text actions, to recreate the pauses between key presses. See Preserving Key Press Intervals.

]]>

-

Wait n milliseconds 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.

+

Wait n milliseconds before processing the next action element. This pause MAY be approximate, and not necessarily be of millisecond precision. Sender clients SHOULD NOT send large n values that exceed the average Transmission Interval. Upon receiving a Body Element, recipient clients SHOULD interrupt all pending pauses for the current real-time message, in order to prevent a delay in displaying the final message.

 -

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:

+

During a chat session, real-time text needs to be identical on both the sender and recipient ends. A missing <rtt/> transmission can represent missing text or missing edits. Also, recipients can connect after the sender has already started composing a message. To address this, a Message Refresh mechanism allows recipient clients to recover the sender's real-time message that is actively in-progress. This synchronizes real-time text in many situations, including:

    -
  • Resuming after connecting (e.g. wireless reception, recipient started or restarted software).
    • -
  • Resuming after recipient discarded Stale Messages (e.g. sender resumes composing hours later).
    • -
  • Resuming after lost message stanzas (e.g. Congestion Considerations).
    • -
  • During Simultaneous Logins (e.g. switching systems, switching windows, simultaneous typing).
    • +
  • After recipient client reconnections (e.g. due to wireless reception, due to user restarting client).
    • +
  • After recipient client discarded Stale Messages (e.g. sender resumes composing hours later).
    • +
  • Simultaneous Logins (e.g. user switching between devices/clients or between windows/tabs in a client).
  • During Multi-User Chat (e.g. participants joining/leaving while other participants are composing).
    • +
  • After message stanzas are lost in transit (e.g. Congestion Considerations).
-

Recipient clients MUST keep track of separate real-time message per sender, including maintaining independent seq values. For implementation simplicity, recipient clients MAY track incoming <rtt/> elements per bare JID. Conflicting <rtt/> elements, from separate Simultaneous Logins, is handled via the remainder of this section. Alternatively, recipient clients MAY keep track of separate real-time messages per full JID and/or per <thread/>.

+

Recipient clients MUST keep track of separate real-time messages on a per-sender basis, including tracking independent seq values. For implementation simplicity, recipient clients MAY track incoming <rtt/> elements per &LOCALBARE; to keep only one real-time message per sender. Recipient client handling of conflicting <rtt/> elements (e.g. coming concurrently from separate Simultaneous Logins) is described in the remainder of this section. Alternatively, recipient clients MAY keep track of separate real-time messages per &LOCALFULL; and/or per <thread/> (&xep0201;).

-

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

+

By following Processing Rules, the recipient client creates a new real-time message when receiving <rtt event='new'/> or <rtt event='reset'/>. Thereafter, when receiving text modifications (i.e. <rtt event='edit'/> or <rtt/> without an event attribute):

    -
  1. Senders MUST increment the seq attribute in steps of 1, for consecutively transmitted <rtt/> elements.
    2. -
  2. Recipients MUST monitor the seq attribute value of received <rtt/> elements, to verify that it is incrementing by 1.
    3. +
  3. There MUST be an existing real-time message (created via <rtt event='new'/> or <rtt event='reset'/>);
    4. +
  4. Senders MUST increment the seq attribute in steps of 1, for consecutively transmitted text modifications.
    5. +
  5. Recipients MUST verify that the seq attribute is incrementing by 1, for consecutively received text modifications.
 -

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

+

Loss of sync occurs during receiving text modifications if the seq attribute do not increment by 1 as expected, or if no real-time message exists. In this case:

    -
  • Recipients MUST keep the pre-existing real-time message unchanged; and
    • -
  • Recipients MUST ignore action elements within the current and subsequent <rtt/> elements; and
    • +
  • Recipients MUST keep the real-time message unchanged (if any exists); and
    • +
  • Recipients MUST ignore subsequent text modifications (i.e. <rtt event='edit'/> or <rtt/> without an event attribute); 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).
    • +
  • An <rtt/> element with an event attribute of 'new' or 'reset' (e.g. new message, or Message Refresh).
 - -

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 to a longer interval, in order to reduce average bandwidth (e.g. long messages, infrequent or minor message changes). For quicker recipient 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. recipient may have cleared Stale Messages);
    • -
  • 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).

+ +

A message refresh is the sender's partially composed text being (re)transmitted via <rtt event='reset'/>. The recipient client(s) can seamlessly redisplay the real-time message as a result. This allows real-time text to resume quickly, without waiting for senders to start a new message:

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

-

Note: 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).

+

The message refresh SHOULD be transmitted regularly 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 not cause a significant bandwidth overhead. This interval MAY vary, or be set to a longer time period, in order to reduce average bandwidth (e.g. long messages, infrequent or minor message changes). To save bandwidth, message refreshes SHOULD NOT occur continuously while the sender is idle. To allow quicker resumption of real-time text, sender clients MAY adjust the timing of the message refresh to occur right after any of the following additional events:

+
    +
  • When the recipient starts sending messages from a different full JID (e.g. switched clients);
    • +
  • When the recipient becomes available (e.g. presence changes to 'chat');
    • +
  • When the sender resumes composing after an extended pause (e.g. recipient may have cleared Stale Messages);
    • +
  • When the conversation is unlocked (e.g. section 5.1 of XMPP IM);
    • +
+

If the recipient already has an existing real-time message from the sender, Processing Rules require that the real-time message MUST be seamlessly replaced. Thus, if the recipient is successfully Staying In Sync, the recipient user sees no visible effect since the text contained within <rtt event='reset'/> is a duplicate of the existing real-time message. If the recipient client was out of lost sync (Recovery From Loss of Sync) or it has no real-time message, the recipient user sees the real-time message immediately “catch up”.

+

Note: The use of <rtt event='reset'/> is not limited to message refresh, as it can contain any number of Action Elements in any order. Sender clients MAY combine a message refresh with additional action elements (e.g. re-transmitting a whole message in one Element <t/> – Insert Text, followed by some additional action elements, such as additional typing or backspacing, to seamlessly allow Preserving Key Press Intervals).

Real-time text is generated based on text normally allowed to be transmitted within the <body/> element.

-

Incorrectly generated Action Elements and Attribute Values can lead to inconsistencies between the sender and recipient during real-time editing. The Unicode characters of the real-time text needs to make it transparently from the sender to the recipient, without unexpected modifications after sender pre-processing. This is the chain between the sender's creation of real-time text, to the recipient's processing of real-time text. Transparent transmission of Unicode characters is possible with sender pre-processing, as long as the transmission from the sender to the recipient remains standards-compliant, including compliant XML processors and compliant XMPP servers.

-

Any inconsistencies that occur during real-time message editing (e.g. non-compliant servers that modify messages, incorrect Unicode Character Counting) will recover upon delivery of the Body Element, upon the next Message Reset, and/or during Basic Real-Time Text.

+

Incorrectly generated Action Elements and Attribute Values can lead to inconsistencies between the sender and recipient during real-time editing. The Unicode characters of the real-time text needs to be transmitted unaltered from the sender to the recipient, without unexpected modifications after sender pre-processing. This is the chain between the sender's creation of real-time text, to the recipient's processing of real-time text. Unaltered transmission of Unicode characters is possible with sender pre-processing, as long as the transmission from the sender to the recipient remains standards-compliant, including compliant XML processors and compliant XMPP servers.

+

If unexpected Unicode inconsistencies occur during real-time message editing, the recipient client will normally recover the message upon receiving a Body Element or a Message Refresh.

-

For this specification, a "character" represents a single Unicode code point. This is the same definition used in section 1.1 of IETF RFC 5198 RFC 5198: Unicode Format for Network Interchange. <http://tools.ietf.org/html/rfc5198>.. For platform-independent interoperability of Action Elements, calculations on Attribute Values (p and n) MUST be based on counts of Unicode code points.

+

For this specification, a "character" represents a single Unicode code point. This is the same definition used in section 1.1 of IETF RFC 5198 + RFC 5198: Unicode Format for Network Interchange <http://tools.ietf.org/html/rfc5198>.. For platform-independent interoperability of Action Elements, calculations on Attribute Values (p and n) MUST be based on counts of Unicode code points.

Many platforms use different internal encodings (i.e. string formats) that are different from the transmission encoding (UTF-8). These factors need to be considered:

    -

  • Multiple Unicode code points (e.g. combining marks, accents) can form a combining character sequence.
    +

  • Multiple Unicode code points (e.g. combining marks, accents) can form a combining character sequence. This can occur in situations where there isn't a visually equivalent composite character of a single code point (e.g. when doing Unicode normalization).
    Action elements operate on Unicode code points individually.

  • Unicode code points U+10000 through U+10FFFF are represented as a surrogate pair in some Unicode encodings (e.g. UTF-16).
    Action elements operate on Unicode code points as a whole, not on separate components of a surrogate pair.

    • @@ -400,14 +433,16 @@

    Lengths and positions in Attribute Values are relative to the internal Unicode text of the real-time message, independently of the directionality of actual displayed text. As a result, any valid Unicode text direction can be used with real-time text (right-to-left, left-to-right, and bidirectional). One way for implementers to visualize this, is to simply visualize Unicode text as an array of individual code points, and treat Attribute Values as array indexes.

    -

    Sender clients MUST generate real-time text (Action Elements and Attribute Values) based on the plain text version of the sender's message with pre-processing completed. This is separate and concurrent to any displayed presentation of the same message (e.g. formatting, emoticon graphics, &xep0071;).

    -

    Pre-processing before generating real-time text, include Unicode normalization, conversion of emoticons graphics to text, removal of illegal characters, line-break conversion, and any other necessary text modifications. For Unicode normalization, sender clients SHOULD ensure the message is in Unicode Normalization Form C ("NFC"), specified by section 3 of RFC 5198, and within many other standards such as Canonical XML 1.0.

    +

    Sender clients MUST generate real-time text (Action Elements and Attribute Values) based on the plain text version of the sender's message with pre-processing completed. This is separate from and concurrent to any displayed presentation of the same message (e.g. formatting, emoticon graphics, &xep0071;).

    +

    Pre-processing before generating real-time text includes Unicode normalization, conversion of emoticons graphics to text, removal of illegal characters, line-break conversion, and any other necessary text modifications. For Unicode normalization, sender clients SHOULD ensure the message is in Unicode Normalization Form C + Unicode Standard Annex #15: Unicode Normalization Forms <http://www.unicode.org/reports/tr15/>. ("NFC"), as recommended within section 3 of RFC 5198, and within many other standards such as Canonical XML 1.0.

    If Unicode combining character sequences (e.g. letter with multiple accents) are used for Element <t/> – Insert Text, then complete combining character sequences SHOULD be sent. In situations where modifications are required to an existing combining character sequence (e.g. adding an additional accent), an Element <e/> – Erase Text SHOULD be used to delete the existing combining character sequence, before transmitting a complete replacement sequence via the <t/> element. (However, recipients SHOULD NOT assume this behavior from sending clients. See Guidelines for Recipients).

    -

    For the purpose of calculating Attribute Values, any line breaks MUST be treated as a single character. Conversion of line breaks into a single LINE FEED U+000A is REQUIRED for XML processors, according to section 2.11 of XML XML: Extensible Markup Language 1.0 (Fifth Edition). <http://www.w3.org/TR/xml/>.. In addition, XML character entities are counted as a single character.

    +

    For the purpose of calculating Attribute Values, any line breaks MUST be treated as a single character. Conversion of line breaks into a single LINE FEED U+000A is REQUIRED for XML processors, according to section 2.11 of XML + XML: Extensible Markup Language 1.0 (Fifth Edition) <http://www.w3.org/TR/xml/>.. In addition, XML character entities are counted as a single character.

    For Element <t/> – Insert Text, text MUST be obtained using compliant XML processing (including entities converted to characters). Recipient clients SHOULD ensure that the received text is in Unicode Normalization Form C ("NFC"). After this, recipient clients MUST NOT do any other modifications to resulting real-time messages. This is to allow accurate processing of subsequent Action Elements and Attribute Values (The recipient client can separately process/modify a copy of the same real-time message text, if necessary for the purpose of display presentation).

    -

    It is possible for Element <t/> – Insert Text to contain any subset sequence of Unicode code points from the sender’s message. This can result in situations where text transmitted in <t/> elements is an incomplete combining character sequence (e.g. Unicode combining mark(s) without a base character) which becomes a complete sequence when inserted within the recipient's real-time message (e.g. additional accent for an existing combining character sequence). These are still complete individual code points, even if the sequence is incomplete.

    +

    It is possible for sender clients to send Element <t/> – Insert Text with an incomplete combining character sequence (e.g. combining mark(s) without a Unicode base character). This is valid when extending an existing combining character sequence into a longer valid complete combining character sequence (e.g. adding an additional accent mark). It is also possible for senders to send Element <e/> – Erase Text to remove code points from an existing combining character sequence, into a shorter valid complete combining character sequence (e.g. removing an accent mark). In all cases, recipient clients MUST process these elements in accordance to Action Elements.

     @@ -442,14 +477,14 @@

    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.

    +

    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.

    +

    There are specialized situations such as live transcriptions and captioning (e.g. transcription service, closed captioning provider, captioned telephone, Communication Access Realtime Translation (CART), relay services) that demands low latency transmission. Such systems typically use voice recognition and/or stenotype machines, which output text in word or phrase bursts rather than a character at a time. It can be acceptable for senders with bursty output to immediately transmit word or phrase bursts of text without buffering, as long as the average stanza rate is not excessive. This eliminates any lag caused by the 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, preferably within the range recommended by Transmission Interval. Compression can also be used to reduce bandwidth (e.g. TLS compression or &xep0138;) .

    +

    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, preferably within the range recommended by Transmission Interval. Compression can also be used to reduce bandwidth (e.g. TLS compression or &xep0138;).

    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.

     @@ -465,36 +500,32 @@
  • Ignore (discard incoming <rtt/> elements); or
  • Display only incoming real-time text (e.g. Multi-User Chat participants control their own outgoing real-time text).
-

For any client, the preferred first <rtt/> element to send is <rtt event='init'/> as it can quickly signal activation of real-time text, without waiting for the sender to begin composing a new message, and since it is usable regardless of discovery.

-

Before sending real-time text, it is preferable for a sender client to explicitly discover whether the recipient client supports the protocol defined herein (using Determining Support). In the absence of explicit discovery or negotiation, the sender client can implicitly request and discover the use of real-time text, by sending <rtt event='init'/> upon activation. It is inappropriate to send any further <rtt/> elements, until support is confirmed either by incoming <rtt/> elements or via discovery. Implicit discovery allows usage of real-time text as an enhancement to &xep0085; (XEP-0085 Section 5.1), during all situations where it can be used. See Usage with Chat States.

+

For any client, the preferred first <rtt/> element to send is <rtt event='init'/> as it can quickly signal activation of real-time text, without waiting for the sender to begin composing a new message, and since it is usable regardless of discovery. Conversely, if the sender was already composing a message when activating real-time text, Message Refresh handles this situation.

+

While explicit discovery is preferred (See Determining Support), the sender client can implicitly request and discover the use of real-time text, by sending <rtt event='init'/> upon activation. In the case of one-on-one chats, it is inappropriate to send any further <rtt/> elements, until support is confirmed either by incoming <rtt/> elements or via discovery. Implicit discovery makes it possible to use real-time text as an enhancement to &xep0085; (XEP-0085 Section 5.1), during all situations where it can be used. See Usage with Chat States.

Real-time text can be deactivated by transmitting <rtt event='cancel'/>, or simply by ending the chat session. Recipient clients can respond to deactivation with appropriate response(s), including:

  • Stop transmitting <rtt/> elements as well (not applicable to Multi-User Chat); and
    • -
  • Handle the sender's unfinished incoming real-time message (such as clearing it and/or saving it); and
    • +
  • Handle the sender's unfinished incoming real-time message; and
  • Inform the recipient user that sender ended real-time text (or denied/cancelled, if no real-time text was received).
-

Sending an <rtt event='cancel'/> is also useful in situations where the user closes a chat window, and ends the chat session. It is also useful when the user wants to deactivate or deny real-time text, while still continuing the chat session. After <rtt event='cancel'/>, any client can reactivate real-time text again using <rtt event='init'/>.

+

Any client can send an <rtt event='cancel'/> when ending the chat session (e.g. user closes a chat window) or when deactivating real-time text while continuing the chat session. Clients receiving <rtt event='cancel'/> do not need to also transmit <rtt event='cancel'/> back.

+

Senders deactivating real-time text while in the middle of composing a message, can continue composing their message without real-time text being sent. Completed messages continue to be transmitted normally via the [[Body Element]]. Recipients that no longer receive further real-time updates, can handle the incomplete sender's real-time message appropriately (e.g. clearing/greying-out/saving the message, or using Stale Messages handling).

+

After deactivation, any client can reactivate real-time text again using <rtt event='init'/>.

 -

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.

-

If a remote cursor is not used, then clients can simply ignore calculating a cursor position and skip this section. Action Elements only use absolute positioning (relative positions are not used by this standard), so clients do not need to remember the position value from previous action elements.

- -

When <t/> or <e/> 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 Attribute Values. The recipient can calculate the cursor position as follows:

+

Recipient clients can choose to display a separate cursor/caret indicator within incoming real-time messages. This can improve usability of real-time text, since it becomes easier for a recipient to observe the sender's real-time message edits. For clients that do not implement a remote cursor, skip this section.

+

Action Elements use only absolute positioning (relative positions are not used by this standard), so clients do not need to remember the position value from previous action elements. Recipient software can calculate the remote cursor position as follows:

    -

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

    • -

  • After Element <e/> – Erase Text, the cursor position is the p attribute minus the n attribute.
    - This is the normal backwards cursor movement to a backspace 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.

    • +

  • Upon receiving 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 the inserted text.
    + This allows normal forward cursor movement during text insertion.

    • +

  • Upon receiving Element <e/> – Erase Text, the cursor position is the p attribute minus the n attribute.
    + This allows normal backwards cursor movement to a backspace key.

    • +

  • Upon receiving an empty Element <t/> – Insert Text (e.g. <t p='#'/> or <t p='#'></t>), the cursor position is the p attribute and no text modification is done. Senders can send these elements when only the cursor position has changed (e.g. arrow keys, mouse repositioning). These are non-operative elements on recipients that do not implement a remote 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.

- - +

This section lists several possible methods of generating real-time text for transmission. For most situations, the preferred methodology is Monitoring Message Changes Instead Of Key Presses.

@@ -521,8 +552,8 @@

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/> – Erase Text without any attributes, simply erases text from the end of the message. This sending method can also be useful for special-purpose clients where mid-message editing capabilities are not used (e.g. simple transcription, news tickers, relay services, captioned telephone).

 - -

It is possible for sender clients to use Message Reset to retransmit the whole real-time message, whenever there are text changes. The advantage is very simple implementation. Disadvantages can include the lack of Preserving Key Press Intervals, and extra bandwidth consumption that can occur with longer messages, unless stream compression is used. The below illustrates transmission of the real-time message “Hello there!” at a regular Transmission Interval while the sender is typing.

+ +

It is possible for sender clients to use Message Refresh to simply re-transmit the whole real-time message, as a method of transmitting text changes. The advantage is very simple implementation. Disadvantages can include the lack of Preserving Key Press Intervals, and extra bandwidth consumption that can occur with longer messages, unless stream compression is used. The below illustrates transmission of the real-time message “Hello there!” at a regular Transmission Interval while the sender is typing.

Hel @@ -547,15 +578,16 @@

  1. Upon receiving Action Elements in incoming <rtt/> elements, they are added to a queue in the order they are received. This provides immunity to variable network conditions, since the queuing action will smooth out incoming transmission (e.g. receiving new <rtt/> while still processing a delayed <rtt/>).

  2. The recipient client processes action elements in the queue in sequential order, including pauses from Element <w/> – Wait Interval. This is equivalent to playing back the sender's original typing.

    3. -

  3. Upon receiving a Body Element indicating a completed message, the full message text from <body/> can be displayed immediately in place of the real-time message, and unprocessed action elements can be cleared from the queue. This ensures final message delivery is not delayed by late processing of action elements.

    4. +

  4. Upon receiving a Body Element indicating a completed message, the full message text from <body/> can be displayed immediately in place of the real-time message, and unprocessed action elements can be cleared from the queue. This ensures that the final message delivery is not delayed by late processing of action elements.

In processing Element <w/> – Wait Interval, excess lag in incoming real-time text might occur if multiple delayed <rtt/> elements suddenly get delivered (e.g. congestion, intermittent wireless reception). Recipients can avoid excess lag by monitoring the queue for excess <w/> action elements (e.g. unprocessed <w/> elements from two <rtt/> elements ago) and then ignoring or shortening the intervals in <w/> elements. This allows lagged real-time text to "catch up" more quickly.

+

If the <w/> element is not supported, receiving clients can use an alternate text-smoothing method in order to Avoid Bursty Text Presentation (e.g. time-smoothed progressive output of received real-time text).

 -

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 sent and then a new real-time message started immediately after, every time a message reaches a reasonable size. This allows continuous real-time text without real-time messages becoming excessively large.

+

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 Refresh 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 Refresh. 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 clients that send continuous real-time text (e.g. news ticker, captioning, speech transcription, TTY/text telephone gateway), a Body Element can be sent and then a new real-time message started immediately after, every time a message reaches a specific size. This allows continuous real-time text without real-time messages becoming excessively large.

Real-time text can be used in conjunction with XEP-0085 Chat States. These are simple guidelines for <message/> stanzas that include an <rtt/> element:

@@ -565,21 +597,31 @@
  • Other chat states are handled as specified by XEP-0085 Chat States.
    •  + +

    It is possible to have &xep0308; (XEP-0308) with real-time text. If XEP-0308 is implemented at the same time as this specification, the following rules apply:

    +
      +

    • For all <rtt/> elements transmitted during composing a new message, the id attribute of <rtt/> is not used.

      • +

    • For all <rtt/> elements transmitted during editing of the previous message, the id attribute of <rtt/> matches the id attribute of the old <message/> stanza containing the <body/> text being edited (See 'Business Rules' in XEP-0308). This enables recipient clients to display real-time text while the sender is editing the previously-delivered message.

      • +

    • Senders clients need to transmit a Message Refresh when transmitting <rtt/> for a different message than the previously transmitted <rtt/> (i.e. the value of the id attribute changes, id becomes included, or id becomes not included). This keeps real-time text synchronized when beginning to edit a previously delivered message versus continuing to compose a new message.

      • +

    • The XEP-0301 and XEP-0308 protocols operate concurrently via separate message stanzas. Thus, a message stanza never simultaneously includes both <rtt/> and <replace/>.

      • +

    • The Body Element delivers a finished new message or a finished message correction (<replace/> is used with <body/> in accordance to XEP-0308).

      • +
    +     -

    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.

    +

    The in-band nature of this real-time text standard makes it possible to seamlessly integrate real-time text into &xep0045; (MUC), as well as concurrent simultaneous logins.

    For simplicity, clients can implement real-time text only for one-on-one chat, and not for MUC. However, it can be appropriate to support <rtt/> elements in MUC, even if not all participants support real-time text. Participants that enable real-time text during group chat need to keep track of multiple concurrent real-time messages on a per-participant basis. Participants, with real-time text, will see real-time text coming from each participant that has real-time text enabled. Participant clients without real-time text (whether unsupported or turned off) will simply see group chat function normally on a line-by-line basis, since it is Backwards Compatible.

    Participants that turn off real-time text for themselves, can simply ignore incoming <rtt/> and not transmit outgoing <rtt/>. Participant clients in MUC receiving an incoming <rtt event=’cancel’/> needs to keep outgoing transmission unaffected during Deactivation Guidelines (otherwise, one participant could deny real-time text between other willing participants).

    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. Prominent visibility of real-time text can be assigned to recent typists and/or moderators (e.g. classroom teacher, convention speaker). For the same participant logged in multiple times in the same room, see Simultaneous Logins. 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, 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.

    +

    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 Refresh, presumably from the active login. This provides a seamless system-switching experience. A good implementation of Message Refresh 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 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.

    +

    Senders that resume composing a message (i.e. continues a partially-composed message hours later) can do a Message Refresh, 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. The real-time message might be implemented as a separate window or separate display element.

    @@ -589,7 +631,7 @@

    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. For simplicity, these examples use a bare JID, even in situations where a full JID might be more appropriate.

    - +

    All three examples shown below result in the same real-time message "HELLO" created by writing "HLL", backspacing two times, and then "ELLO". The action elements are Element <t/> – Insert Text and Element <e/> – Erase Text.

    @@ -696,11 +738,11 @@ -

    The example above represents moderate typing speed during a normal Transmission Interval, such as 0.7 seconds between <message/> stanzas for continuous typing. It illustrates the following:

    +

    The example above represents moderate typing speed during a normal Transmission Interval, such as 700 milliseconds between <message/> stanzas for continuous typing. It illustrates the following:

      -
    • The event attribute equals 'new' for the start of every new message.
      • -
    • The seq attribute increments within the same message.
      • -
    • The seq attribute randomizes when beginning a new message.
      • +
    • The event attribute equals 'new' for the start of every new message.
      • +
    • The seq attribute increments within the same message.
      • +
    • The seq attribute randomizes when beginning a new message.
    • This shows Usage with Chat States.
     @@ -918,7 +960,7 @@
  • Backspaces are done via Element <e/> – Erase Text.
  • 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.
    • +
  • Each <message/> is delivered at a regular Transmission Interval, typically 700 milliseconds.
  • 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.
    • @@ -929,13 +971,14 @@

    There are other real-time text formats with interoperability considerations relating to the session setup level, the media transport level, and presentation level. Interoperability specifications between multiple real-time text formats can be found at Real-Time Text Taskforce (R3TF).

    -

    It is appropriate for implementers to choose the most appropriate real-time text standard for the session control standard in use during a particular session. For example, clients that use XMPP can utilize this XEP-0301 specification, and clients that use SIP might utilize IETF RFC 4103, IETF RFC 5194 RFC 5194: Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP). <http://tools.ietf.org/html/rfc5194>. and ITU-T T.140). Clients that run on multiple networks, might need to utilize multiple real-time text standards. To interoperate between incompatible real-time text standards, gateway servers can transcode between different real-time text standards, along with other media such as audio and video. This can include TTY and textphones.

    +

    It is appropriate for implementers to choose the most appropriate real-time text standard for the session control standard in use during a particular session. For example, clients that use XMPP can utilize this XEP-0301 specification, and clients that use SIP might utilize IETF RFC 4103, IETF RFC 5194 + RFC 5194: Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP) <http://tools.ietf.org/html/rfc5194>. and ITU-T T.140). Clients that run on multiple networks, might need to utilize multiple real-time text standards. To interoperate between incompatible real-time text standards, gateway servers can transcode between different real-time text standards, along with other media such as audio and video. This can include TTY and textphones.

    In the SIP environment, real-time text is specified in IETF RFC 4103 and ITU-T T.140. SIP is a popular real-time session control protocol, and there are many implementations of real-time text controlled by SIP. This includes emergency services in some regions.

    Interoperability considerations include addressing translation, media negotiation and translation, and media transcoding. Transcoding is straightforward between this specification and T.140/RFC4103, except for editing in the middle of messages. Text insertions or deletions, occurring far back in the message, can cause a large number of erase operations in T.140 that consume time and bandwidth. T.140 specifies the use of ISO 6429 control codes for presentation characteristics, such as text color, that are not supported by this specification. During transcoding, these control codes needs to be filtered off in order to not disturb the presentation of text.

     -

    According to ITU-T Rec. F.703, the “Total Conversation” accessibility standard defines the simultaneous use of audio, video, and real-time text. This is more widespread in certain regions (e.g. Reach 112 in Europe). For convenience, messaging applications can be designed to have automatic negotiation of as many as possible of the three media preferred by the users.

    +

    According to ITU-T Rec. F.703, the “Total Conversation” standard defines the simultaneous use of audio, video, and real-time text. For convenience, real-time communication applications can 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.

         @@ -958,9 +1001,9 @@

    The nature of real-time text can result in more frequent transmission of <message/> stanzas than would otherwise happen in a non-real-time text conversation. This can 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 during a network issue or server error. These techniques are useful for mission-critical applications such as next generation emergency services (e.g. text to 9-1-1).

    -

    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.

    -

    According to multiple university studies worldwide, the average length of instant messages is under 40 characters. The additional incremental bandwidth overhead of real-time text can be very low for an existing XMPP client, especially one already using many extensions. Bandwidth can also be further mitigated using stream compression, to benefit bandwidth-constrained networks (e.g. GPRS, 3G, satellite).

    +

    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 Refresh can also retransmit real-time text lost by poor network conditions, including stanzas dropped during a network issue or server error. These techniques are useful for mission-critical applications such as next generation emergency services (e.g. text to 9-1-1).

    +

    Excess numbers of real-time messages (e.g. during a DoS scenario in Multi-User Chat) might cause local resource-consumption issues, which can be mitigated by accelerated time-out of Stale Messages.

    +

    According to multiple university studies worldwide ([[[, the average length of instant messages is under 40 characters. The additional incremental bandwidth overhead of real-time text can be very low for an existing XMPP client, especially one already using many extensions. Bandwidth can also be further mitigated using stream compression, to benefit bandwidth-constrained networks (e.g. GPRS, 3G, satellite).

     @@ -993,13 +1036,14 @@ - + - - - - - + + + + + + @@ -1014,20 +1058,20 @@ - + - - + + - +