moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-24 10:12:19 -05:00
Code Issues Releases Wiki Activity

1.0 DRAFT

Browse Source
This commit is contained in:
Peter Saint-Andre 2013-10-09 12:02:42 -06:00
parent 3d001ba5a4
commit 3fc634902a
1 changed files with 14 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
xep-0301.xml
View File

@ -12,8 +12,7 @@
created.</abstract>
&LEGALNOTICE;
<number>0301</number>
<status>Proposed</status>
<lastcall>2013-06-28</lastcall>
<status>Draft</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
@ -24,7 +23,7 @@
</dependencies>
<supersedes/>
<supersededby/>
<shortname>NOT_YET_ASSIGNED</shortname>
<shortname>rtt</shortname>
<author>
<firstname>Mark</firstname>
<surname>Rejhon</surname>
@ -38,6 +37,12 @@
<email>gunnar.hellstrom@omnitor.se</email>
<uri>http://www.omnitor.se</uri>
</author>
<revision>
<version>1.0</version>
<date>2013-10-08</date>
<initials>psa</initials>
<remark><p>Per a vote of the XMPP Council, advanced status to Draft.</p></remark>
</revision>
<revision>
<version>0.12</version>
<date>2013-09-25</date>
@ -137,20 +142,16 @@
</revision>
</header>
<section1 topic="Introduction" anchor="introduction">
<section1 topic="Introduction" anchor="introduction">
<p>This document defines a specification for real-time text transmitted in-band over an XMPP network.</p>
<p>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.</p>
<p>Real-time text is found in various implementations:</p>
<ul>
<li>The 'talk' command on UNIX systems since the 1970's.</li>
<li>Session Initiation Protocol (SIP), utilizing <span class="ref"><strong><link url="http://tools.ietf.org/html/rfc4103">RFC 4103</link></strong></span>
<note>RFC 4103: RTP Payload for Text Conversation &lt;<link url="http://tools.ietf.org/html/rfc4103">http://tools.ietf.org/html/rfc4103</link>&gt;.</note> real-time text.</li>
<li>Session Initiation Protocol (SIP), utilizing &rfc4103; real-time text.</li>
<li>Instant messaging enhancements, including a <span class="ref"><strong><link url="http://tap.gallaudet.edu/rtt/">Gallaudet University</link></strong></span>
<note>Gallaudet University Technology Access Program collaboration project: Real-Time Text &lt;<link url="http://tap.gallaudet.edu/rtt/">http://tap.gallaudet.edu/rtt/</link>&gt;.</note> collaboration.</li>
<li>Next generation emergency services (<span class="ref"><strong><link url="http://tools.ietf.org/html/rfc6443">RFC 6443</link></strong></span>
<note>RFC 6443: Framework for Emergency Calling Using Internet Multimedia &lt;<link url="http://tools.ietf.org/html/rfc6443">http://tools.ietf.org/html/rfc6443</link>&gt;.</note>).</li>
<li>Next generation emergency services (&rfc6443;).</li>
</ul>
<p>For a visual animation of real-time text, see <span class="ref"><strong><link url="http://www.realtimetext.org">Real-Time Text Taskforce</link></strong></span>
<note>Real-Time Text Taskforce, a foundation for real-time text standardization &lt;<link url="http://www.realtimetext.org">http://www.realtimetext.org</link>&gt;.</note>.</p>
@ -1002,8 +1003,7 @@
<note>RFC 5194: Framework for Real-Time Text over IP Using the Session Initiation Protocol (SIP) &lt;<link url="http://tools.ietf.org/html/rfc5194">http://tools.ietf.org/html/rfc5194</link>&gt;.</note> and <strong>ITU-T T.140</strong>. 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.</p>
<section2 topic="RFC 4103 and T.140" anchor="rfc_4103_and_t140">
<p>In the SIP environment, real-time text is specified in <strong>RFC 4103</strong> and <strong>ITU-T T.140</strong>. 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.</p>
<p>Interoperability considerations include addressing translation, media negotiation and translation, and media transcoding. Transcoding is straightforward between this specification and <strong>T.140</strong> / <strong>RFC 4103</strong>, 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 <strong>T.140</strong> that consume time and bandwidth. <strong>T.140</strong> 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. Guidance on address translation and conveyance between XMPP and SIP can be found at <span class="ref"><strong><link url="http://tools.ietf.org/html/draft-ietf-stox-core">IETF stox</link></strong></span>
<note>Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Addresses and Error Conditions &lt;<link url=" http://tools.ietf.org/html/draft-ietf-stox-core">http://tools.ietf.org/html/draft-ietf-stox-core</link>&gt;.</note>.</p>
<p>Interoperability considerations include addressing translation, media negotiation and translation, and media transcoding. Transcoding is straightforward between this specification and <strong>T.140</strong> / <strong>RFC 4103</strong>, 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 <strong>T.140</strong> that consume time and bandwidth. <strong>T.140</strong> 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. Guidance on address translation and conveyance between XMPP and SIP can be found in &stoxcore;.</p>
</section2>
<section2 topic="Total Conversation – Combination with Audio and Video" anchor="total_conversation_combination_with_audio_and_video">
<p>According to <strong>ITU-T Rec. F.703</strong>, 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.</p>
@ -1034,7 +1034,7 @@
<p>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 <link url="#transmission_interval">Transmission Interval</link> 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 <link url="#message_refresh">Message Refresh</link> 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).</p>
<p>Excess numbers of real-time messages (e.g., during a Denial of Service (DoS) scenario in <link url="#usage_with_multiuser_chat">Usage with Multi-User Chat</link>) might cause local resource-consumption issues, which can be mitigated by accelerated time-out of <link url="#stale_messages">Stale Messages</link>. Also see &xep0205;.</p>
<p>According to multiple university studies worldwide (including <span class="ref"><strong><link url="http://seattle.intel-research.net/~davraham/pubs/Avrahami_CSCW_06.pdf">Carnegie Mellon University Study</link></strong></span>
<note>Communication Characteristcs of Instant Messaging: Effects and Predictions of Interpersonal Relationships &lt;<link url="http://seattle.intel-research.net/~davraham/pubs/Avrahami_CSCW_06.pdf">http://seattle.intel-research.net/~davraham/pubs/Avrahami_CSCW_06.pdf</link>&gt;.</note>), 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).</p>
<note>Communication Characteristics of Instant Messaging: Effects and Predictions of Interpersonal Relationships &lt;<link url="http://seattle.intel-research.net/~davraham/pubs/Avrahami_CSCW_06.pdf">http://seattle.intel-research.net/~davraham/pubs/Avrahami_CSCW_06.pdf</link>&gt;.</note>), 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).</p>
</section2>
</section1>
<section1 topic="IANA Considerations" anchor="iana_considerations">
@ -1042,7 +1042,7 @@
</section1>
<section1 topic="XMPP Registrar Considerations" anchor="xmpp_registrar_considerations">
<section2 topic="Protocol Namespaces" anchor="protocol_namespaces">
<p>The XMPP Registrar should include "urn:xmpp:rtt:0" in its registry of protocol namespaces (see &lt;<link url="http://xmpp.org/registrar/namespaces.html">http://xmpp.org/registrar/namespaces.html</link>&gt;).</p>
<p>The &REGISTRAR; includes "urn:xmpp:rtt:0" in its registry of protocol namespaces (see &lt;<link url="http://xmpp.org/registrar/namespaces.html">http://xmpp.org/registrar/namespaces.html</link>&gt;).</p>
</section2>
<section2 topic="Namespace Versioning" anchor="namespace_versioning">
<p>If the protocol defined in this specification undergoes a revision that is not fully backwards-compatible with an older version, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of XEP-0053.</p>