From 1f7b08ee34ffda9861fece8097e27312dfedc405 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Tue, 4 Jun 2013 20:34:59 -0600 Subject: [PATCH] XEP Editor review --- xep-0301.xml | 66 ++++++++++++++++++++++++++-------------------------- 1 file changed, 33 insertions(+), 33 deletions(-) diff --git a/xep-0301.xml b/xep-0301.xml index d35b03d5..8c478ec9 100644 --- a/xep-0301.xml +++ b/xep-0301.xml @@ -281,7 +281,7 @@

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

    • + Clients MAY use this value to signal deactivation of real-time text. Clients receiving this element SHOULD also discontinue sending <rtt/> elements for the remainder of the same one-to-one chat session (until 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.

    • @@ -336,7 +336,7 @@ RECOMMENDED -

    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.

    +

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

    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.

     @@ -449,12 +449,12 @@

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

    +

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

    +

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

     @@ -494,7 +494,7 @@

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

    +

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

    @@ -505,7 +505,7 @@

    There are many possible ways to implement turning on/off real-time text. Clients can send outgoing real-time text by default. Other clients might choose to do user-initiated activation (e.g. via a button).

    Sender clients can simply begin transmitting real-time text (i.e. send <rtt/> elements), either immediately or upon user-initiated activation.

    -

    For one-on-one chats, it can be beneficial for clients to easily synchronize the enabling/disabling of real-time text. Upon receiving incoming real-time text, recipient clients can automatically do an appropriate response, such as:

    +

    For one-to-one chats, it can be beneficial for clients to easily synchronize the enabling/disabling of real-time text. Upon receiving incoming real-time text, recipient clients can automatically do an appropriate response, such as:

    • Activate immediately (begin transmitting <rtt/> elements too); or
    • Activate after user confirmation prompt (for Privacy considerations); or
      • @@ -514,7 +514,7 @@
    • 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. 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.

    +

    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-to-one chats, it is inappropriate to send any further <rtt/> elements, until support is confirmed either by incoming <rtt/> elements or via discovery. Implicit discovery makes it possible to use real-time text as an enhancement to &xep0085; (XEP-0085 Section 5.1), during all situations where it can be used. See 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:

    @@ -530,7 +530,7 @@

    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:

    +

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

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

      • @@ -551,7 +551,7 @@
    • 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 the previous text change event. The difference in text, between consecutive text change events, is typically a one character difference (e.g. key press) or one text block difference (e.g. auto-correct, cut, paste). In order to calculate what text changes took place, the first changed character and the last changed character is determined. From this, it is simple to generate Action Elements for a single text block deletion and/or insertion. In addition, if Preserving Key Press Intervals is supported, then Element <w/> – Wait Interval records the time elapsed between text change events.

    +

    During a text change event, the sender’s current message text can be compared to the old message text from the previous text change event. The difference in text, between consecutive text change events, is typically a one character difference (e.g. key press) or one text block difference (e.g. auto-correct, cut, paste). In order to calculate what text changes took place, the first changed character and the last changed character are determined. From this, it is simple to generate Action Elements for a single text block deletion and/or insertion. 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 element(s) and append these action element(s) to a buffer. Repeating this step during every text change event, is equivalent to recording a small sequence of typing.

      2. @@ -589,7 +589,7 @@

      In order to allow Preserving Key Press Intervals in incoming real-time text, recipient clients can do the following:

        -

      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 action elements from a delayed <rtt/>).

        2. +

      2. 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 queueing action will smooth out incoming transmission (e.g. receiving new <rtt/> while still processing action elements from a delayed <rtt/>).

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

      If Element <w/> – Wait Interval] is supported, excess lag in incoming real-time text can occur when delayed <rtt/> elements get delivered (e.g. congestion, intermittent wireless reception). To avoid delayed presentation of real-time text, the recipient client needs to speed up processing of action elements. This can be accomplished through a variety of techniques, such as shortening the pauses (n value) in <w/> elements, ignoring excess <w/> elements, immediately outputting action elements that are still queued, and/or keeping action elements from a limited number of <rtt/> elements queued (immediately outputting any prior action elements). This allows lagged real-time text to catch up more quickly.

      @@ -598,43 +598,43 @@       -

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

      +

      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 large (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 might occur in situations such as large copy and pastes. To keep message stanza sizes reasonable, <rtt/> can be transmitted in a separate <message/> than the one containing <body/>.

      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. It is best to handle XEP-0301 and XEP-0085 transmissions in separate <message/> stanzas. Chat states such as <composing/> or <active/> are sent separately of <rtt/> elements.

      -

      Chat states are handled as specified by XEP-0085 Chat States. The continuous transmission of real-time text corresponds to a <composing/> chat state. Therefore, the timing of the <composing/> chat state coincides with the beginning of continuous <rtt/> transmission. 

      +

      Real-time text can be used in conjunction with Chat State Notifications (XEP-0085). It is best to handle XEP-0301 and XEP-0085 transmissions in separate <message/> stanzas. Chat states such as <composing/> or <active/> are sent separately from <rtt/> elements.

      +

      Chat states are handled as specified by XEP-0085. The continuous transmission of real-time text corresponds to a <composing/> chat state. Therefore, the timing of the <composing/> chat state coincides with the beginning of continuous <rtt/> transmission. 

       -

      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:

      +

      It is possible to use &xep0308; (XEP-0308) with real-time text. If XEP-0308 is implemented in concert with this specification, the following rules apply:

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

        • +

      • 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 makes it possible to seamlessly integrate real-time text into &xep0045; (MUC), as well as concurrent simultaneous logins.

      +

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

      -

      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.

      +

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

      +

      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 &xep0296;. Clients can choose to distinguish the <rtt/> streams (via full JID and/or via <thread/>) and keep multiple concurrent real-time messages similar in manner to 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).

      +

      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 one-to-one chat sessions, the time-out period might need to be longer to allow reasonable interruptions (i.e. sender pausing during a long phone call or other interruption).

      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.

      -

      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.

      +

      Battery life considerations are closely related to performance, as the addition of real-time text can have an impact on battery life. If Preserving Key Press Intervals is supported, then support for Element <w/> – Wait Interval needs to be implemented in a battery-efficient manner. The Transmission Interval can 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.

             @@ -902,7 +902,7 @@
    2. Two backspaces to delete the typing mistake;
    3. Two correct key presses to correctly spell the word “there”.
      4. -

      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.

      +

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

      H @@ -972,8 +972,8 @@

      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.

      +

      Implementers ought to choose the most appropriate real-time text approach for the session control technology in use during a particular session. For example, clients that use XMPP can utilize this XEP-0301 specification, and clients that use SIP might utilize IETF RFC 4103, 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 technologies. To interoperate between incompatible real-time text technologies, gateway servers can transcode between different real-time text technologies, along with other media such as audio and video. This can include TTY and textphones.

      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.

      @@ -984,20 +984,20 @@       -

      The primary internationalization consideration involve real-time message editing using Action Elements, where text is inserted and deleted using position and length values. For this, Accurate Processing of Action Elements including correct Unicode Character Counting will ensure that all possible valid Unicode text can be used via this protocol. This includes text containing multiple scripts/languages, ideographic symbols (e.g. Chinese), right-to-left text (e.g. Arabic), and bidirectional text.

      +

      The primary internationalization consideration involves real-time message editing using Action Elements, where text is inserted and deleted using position and length values. For this, Accurate Processing of Action Elements including correct Unicode Character Counting will ensure that all possible valid Unicode text can be used via this protocol. This includes text containing multiple scripts/languages, ideographic symbols (e.g. Chinese), right-to-left text (e.g. Arabic), and bidirectional text.

      For accessibility considerations, there is an International Symbol of Real-Time Text The International Symbol of Real-Time Text <http://www.fasttext.org>. to alert users to the existence of this feature.

       -

      It is important for users to be made aware of real-time text (e.g. user consent, software notice, introductory explanation). Users of real-time text needs to be aware that their typing is now visible in real-time to everyone in the current chat conversation. This may have security implications if users copy & paste private information into their chat entry buffer (e.g. a shopping invoice) before editing out the private parts of the pasted text (e.g. a credit card number) before they send the message. With real-time message editing, recipients can watch all text changes that occur in the sender's text, before the sender finishes the message. Implementation behaviors and improved education can be added to reduce privacy issues. Examples include showing an introduction upon first activation of feature, special handling for copy and pastes (i.e. preventing them, or prompting for confirmation), recipient confirmation of real-time text via Activating and Deactivating Real-Time Text, etc.

      +

      It is important for users to be made aware of real-time text (e.g. user consent, software notice, introductory explanation). Users of real-time text need to be aware that their typing is now visible in real-time to everyone in the current chat conversation. This may have security implications if users copy & paste private information into their chat entry buffer (e.g. a shopping invoice) before editing out the private parts of the pasted text (e.g. a credit card number) and then sending the message. With real-time message editing, recipients can watch all text changes that occur in the sender's text, before the sender finishes the message. Implementation behaviors and improved education can be added to reduce privacy issues. Examples include showing an introduction upon first activation of feature, special handling for copy and pastes (i.e. preventing them, or prompting for confirmation), recipient confirmation of real-time text via Activating and Deactivating Real-Time Text, etc.

       -

      Real-time text (<rtt/> elements) transmit the content contained within messages. Therefore, a client that encrypts <body/> also needs to encrypt <rtt/> as well:

      +

      Real-time text (<rtt/> elements) transmits the content contained within messages. Therefore, a client that encrypts <body/> also needs to encrypt <rtt/> as well:

      • Encryption at the stream level (e.g. TLS) can be used normally with this specification. Stream-level encryption is the most common form of encryption.

      • Encryption at the <message/> stanza level (e.g. XEP-0200) can be used for all stanzas containing either <rtt/> or <body/>. It is noted that real-time text can have a higher rate of message stanzas, contributing to additional overhead. See Congestion Considerations.

        • -

      • Encryption at the <body/> level (e.g. deprecated XEP-0027) do not encrypt <rtt/>. In this case, <rtt/> needs to be encrypted separately. It is preferable to use a broader level of encryption, where possible.

        • +

      • Encryption at the <body/> level (e.g. deprecated XEP-0027) does not encrypt <rtt/>. In this case, <rtt/> needs to be encrypted separately. It is preferable to use a broader level of encryption, where possible.

       @@ -1086,7 +1086,7 @@ ]]>

      -

      The members of the Real-Time Text Taskforce (R3TF), www.realtimetext.org, made significant contributions to this specification. Mark Rejhon leads the Jabber/XMPP Taskgroup at R3TF. Members of R3TF who have contributed to this specification include Gunnar Hellstrom, Paul E. Jones, Gregg Vanderheiden, Barry Dingle, and Arnoud van Wijk. Others contributors include Bernard Aboba, Mark Grady, Darren Sturman, Christian Vogler, Norm Williams, and several members from the XMPP Standards Mailing List, including Kevin Smith, Peter Saint Andre and many others.

      +

      The members of the Real-Time Text Taskforce (R3TF), www.realtimetext.org, made significant contributions to this specification. Mark Rejhon leads the Jabber/XMPP Taskgroup at R3TF. Members of R3TF who have contributed to this specification include Gunnar Hellstrom, Paul E. Jones, Gregg Vanderheiden, Barry Dingle, and Arnoud van Wijk. Others contributors include Bernard Aboba, Mark Grady, Darren Sturman, Christian Vogler, Norm Williams, and several members from the XMPP Standards Mailing List, including Kevin Smith, Peter Saint-Andre and many others.

      The technique of Preserving Key Press Intervals, otherwise called "natural typing", was created by Mark Rejhon, who is deaf. It is incorporated into this specification in compliance of the XSF's Intellectual Property Rights Policy at http://xmpp.org/extensions/ipr-policy.shtml.