Proposed

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2539 4b5297f7-1745-476d-ba37-a9c6900126ab

xep-0166.xml

@@ -7,10 +7,10 @@
 <xep>
 <header>
   <title>Jingle</title>
-  <abstract>This specification defines an XMPP protocol extension for initiating and managing peer-to-peer media sessions between two XMPP entities in a way that is interoperable with existing Internet standards. The protocol provides a pluggable model that enables the core session management semantics to be used for a wide variety of application types (e.g., voice chat, video chat, file sharing) and with a wide variety of transport methods (e.g., TCP, UDP, ICE, application-specific transports).</abstract>
+  <abstract>This specification defines an XMPP protocol extension for initiating and managing peer-to-peer media sessions between two XMPP entities in a way that is interoperable with existing Internet standards. The protocol provides a pluggable model that enables the core session management semantics (compatible with SIP) to be used for a wide variety of application types (e.g., voice chat, video chat, file sharing) and with a wide variety of transport methods (e.g., TCP, UDP, ICE, application-specific transports).</abstract>
   &LEGALNOTICE;
   <number>0166</number>
-  <status>Experimental</status>
+  <status>Proposed</status>
   <type>Standards Track</type>
   <sig>Standards</sig>
   <approver>Council</approver>
@@ -301,13 +301,13 @@
 </header>
 <section1 topic='Introduction' anchor='intro'>
   <p>The purpose of Jingle is to enable one-to-one, peer-to-peer media sessions between XMPP entities, where the negotiation occurs over the XMPP "channel" and the media is exchanged outside the XMPP channel using technologies such as the Real-time Transport Protocol (RTP; &rfc3550;), the User Datagram Protocol (UDP; &rfc0768;), and &ice;.</p>
-  <p>One target application for Jingle is simple voice chat (see &xep0167;). We stress the word "simple". The purpose of Jingle is not to build a full-fledged telephony application that supports call waiting, call forwarding, call transfer, hold music, IVR systems, find-me-follow-me functionality, conference calls, and the like. These features are of interest to some user populations, but adding support for them to the core Jingle layer would introduce unnecessary complexity into a technology that is designed for basic multimedia interaction.</p>
-  <p>The purpose of Jingle is not to supplant or replace technologies based on Session Initiation Protocol (SIP; &rfc3261;). Because dual-stack XMPP+SIP clients are difficult to build, Jingle was designed as a pure XMPP signalling protocol. However, Jingle is at the same time designed to interwork with SIP so that the millions of deployed XMPP clients can be added onto existing Voice over Internet Protocol (VoIP) networks, rather than limiting XMPP users to a separate and distinct network.</p>
-  <p>Jingle is designed in a modular way so that developers can easily add support for multimedia session types other than voice chat, such as application sharing, file sharing, collaborative editing, whiteboarding, and torrent broadcasting. The transport methods are also modular, so that Jingle implementations can use any appropriate media transport (including proprietary methods not standardized through the XMPP Standards Foundation).</p>
+  <p>One target application for Jingle is simple voice and video chat (see &xep0167;). We stress the word "simple". The purpose of the core Jingle technology is not to build a full-fledged telephony application that supports call waiting, call forwarding, call transfer, hold music, IVR systems, find-me-follow-me functionality, conference calls, and the like. These features are of interest to some user populations, but adding support for them to the core Jingle layer would introduce unnecessary complexity into a technology that is designed for basic multimedia interaction.</p>
+  <p>In addition, the purpose of Jingle is not to supplant or replace existing Internet technologies based on Session Initiation Protocol (SIP; &rfc3261;). Because dual-stack XMPP+SIP clients are difficult to build, Jingle was designed as a pure XMPP signalling protocol. However, Jingle is at the same time designed to interwork with SIP so that the millions of deployed XMPP clients can be added onto existing Voice over Internet Protocol (VoIP) networks, rather than limiting XMPP users to a separate and distinct network.</p>
+  <p>Jingle is designed in a modular way so that developers can easily add support for multimedia session types other than voice and video chat, such as application sharing, file sharing, collaborative editing, whiteboarding, and torrent broadcasting. The transport methods are also modular, so that Jingle implementations can use any appropriate media transport (including proprietary methods not standardized through the XMPP Standards Foundation).</p>
 </section1>
 <section1 topic='How It Works' anchor='howitworks'>
   <p>This section provides a friendly introduction to Jingle.</p>
-  <p>In essence, Jingle enables two XMPP entities (e.g., [email protected] and [email protected]) to set up, manage, and tear down a multimedia session. The negotiation takes place over XMPP, and the media transfer takes place outside of XMPP. The simplest session flow is as follows:</p>
+  <p>In essence, Jingle enables two XMPP entities (e.g., [email protected] and [email protected]) to set up, manage, and tear down a multimedia session. The negotiation takes place over XMPP, and the media transfer generally takes place outside of XMPP. A simplified session flow would be as follows:</p>
   <code><![CDATA[
 Romeo                         Juliet
   |                             |
@@ -328,7 +328,7 @@ Romeo                         Juliet
   |                             |
   ]]></code>
   <p>Naturally, more complex scenarios are possible; such scenarios are described in other specifications, such as <cite>XEP-0167</cite> for voice chat.</p>
-  <p>The simplest flow might happen as follows. The example is that of a voice chat offer, where the transport method is &xep0176;.</p>
+  <p>The simplest flow might happen as follows. The example is that of a voice chat offer, where the transport method is &xep0176; and the initiator offers several different codec possibilities.</p>
   <example caption="Initiator sends session-initiate"><![CDATA[
 <iq from='[email protected]/orchard'
     id='jingle1'
@@ -359,7 +359,7 @@ Romeo                         Juliet
     to='[email protected]/orchard'
     type='result'/>
   ]]></example>
-  <p>After successful transport negotiation (not shown here), the responder accepts the session by sending a session-accept action to the initiator.</p>
+  <p>After successful transport negotiation (not shown here), the responder accepts the session by sending a session-accept action to the initiator (including the negotiated transport details and the subset of offered codecs that the responder supports).</p>
   <example caption="Responder definitively accepts the session"><![CDATA[
 <iq from='[email protected]/balcony'
     id='accept1'

xep-0167.xml

@@ -10,7 +10,7 @@
   <abstract>This specification defines a Jingle application type for negotiating one or more sessions that use the Real-time Transport Protocol (RTP) to exchange media such as voice or video. The application type includes a straightforward mapping to Session Description Protocol (SDP) for interworking with SIP media endpoints.</abstract>
   &LEGALNOTICE;
   <number>0167</number>
-  <status>Experimental</status>
+  <status>Proposed</status>
   <type>Standards Track</type>
   <sig>Standards</sig>
   <approver>Council</approver>

xep-0176.xml

@@ -11,7 +11,7 @@
   <abstract>This specification defines a Jingle transport method that results in sending media data using raw datagram sockets via the User Datagram Protocol (UDP). This transport method is negotiated via the Interactive Connectivity Establishment (ICE) methodology defined by the IETF and thus provides robust NAT traversal for media traffic.</abstract>
   &LEGALNOTICE;
   <number>0176</number>
-  <status>Experimental</status>
+  <status>Proposed</status>
   <type>Standards Track</type>
   <sig>Standards</sig>
   <approver>Council</approver>

xep-0177.xml

@@ -10,7 +10,7 @@
   <abstract>This specification defines a Jingle transport method that results in sending media data using raw datagram sockets via the User Datagram Protocol (UDP). This simple transport method does not provide NAT traversal, and the ICE-UDP transport method should be used if NAT traversal is required.</abstract>
   &LEGALNOTICE;
   <number>0177</number>
-  <status>Experimental</status>
+  <status>Proposed</status>
   <type>Standards Track</type>
   <sig>Standards</sig>
   <approver>Council</approver>