0.13: removed the <received/> info message

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

xep-0177.xml

@@ -26,6 +26,12 @@
   &scottlu;
   &hildjj;
   &seanegan;
+  <revision>
+    <version>0.13</version>
+    <date>2008-12-07</date>
+    <initials>psa</initials>
+    <remark><p>Per list consensus, removed the &lt;received/&gt; info message.</p></remark>
+  </revision>
   <revision>
     <version>0.12</version>
     <date>2008-10-20</date>
@@ -108,7 +114,7 @@
 </header>
 <section1 topic='Introduction' anchor='intro'>
   <p>&xep0166; defines a framework for negotiating and managing out-of-band data sessions over XMPP. In order to provide a flexible framework, the base Jingle specification defines neither data transport methods nor application formats, leaving that up to separate specifications. The current document defines a transport method for establishing and managing data between XMPP entities using a raw User Datagram Protocol (UDP) "connection" (see &rfc0768;). This "raw-udp" method results in a datagram transport method suitable for use in media applications where some packet loss is tolerable (e.g., audio and video).</p>
-  <p>Note: The Raw UDP transport does not provide end-to-end traversal of Network Address Translators (NATs); if NAT traversal is needed, Jingle clients SHOULD use &ice; as described in &xep0176;. The Raw UDP transport method is defined only for the purpose of specifying the IP address and port that an entity considers "most likely to succeed" and is a "hit-or-miss" method that might work end-to-end in some circumstances. However, this method can prove useful when the communications architecture includes intermediate gateways or relays, as described in <cite>XEP-0176</cite>.</p>
+  <p>Note: The Raw UDP transport does not provide end-to-end traversal of Network Address Translators (NATs); if NAT traversal is needed, Jingle clients SHOULD use &ice; as described in &xep0176;. The Raw UDP transport method is defined only for the purpose of specifying the IP address and port that an entity considers "most likely to succeed" and is a "hit-or-miss" method that might work end-to-end in some circumstances (especially when the sending entity is a gateway or relay, for example when a back-to-back user agent or call manager sends an early media offer to the initiator on behalf of the responder, as described in &xep0167;).</p>
 </section1>
 <section1 topic='Requirements' anchor='reqs'>
   <p>The Jingle transport method defined herein is designed to meet the following requirements:</p>
@@ -145,10 +151,6 @@ INITIATOR                            RESPONDER
     |<-----------------------------------|
     |  ack                               |
     |----------------------------------->|
-    |  session-info: received            |
-    |----------------------------------->|
-    |  ack                               |
-    |<-----------------------------------|
     |  session-accept                    |
     |<-----------------------------------|
     |  ack                               |
@@ -280,44 +282,17 @@ INITIATOR                            RESPONDER
     to='juliet@capulet.com/balcony'
     type='result'/>
       ]]></example>
-      <p>Naturally, the initiator SHOULD also attempt to send media to the responder as specified above. This media, too, might or might not get through, but if it does then the other party MUST acknowledge success by sending a &lt;received/&gt; message.</p>
+      <p>Naturally, the initiator SHOULD also attempt to send media to the responder as specified above. This media, too, might or might not get through.</p>
-    </section3>
-    <section3 topic='Sending a Received Message' anchor='response-received'>
-      <p>Because delivery of UDP data is not acknowledged (as is TCP data), a party that receives media MUST send an informational message of &lt;received/&gt;, including the candidate ID for tracking purposes.</p>
-      <example caption="Initiator sends received message"><![CDATA[
-<iq from='romeo@montague.net/orchard'
-    id='received1'
-    to='juliet@capulet.com/balcony'
-    type='set'>
-  <jingle xmlns='urn:xmpp:jingle:0'
-          action='session-info'
-          initiator='romeo@montague.net/orchard'
-          sid='a73sjjvkla37jfea'>
-    <received xmlns='urn:xmpp:jingle:transports:raw-udp:info:0'
-              id='a9j3mnbtu1'/>
-  </jingle>
-</iq>
-      ]]></example>
-      <example caption="Responder acknowledges received message"><![CDATA[
-<iq from='juliet@capulet.lit/balcony'
-    id='received1'
-    to='romeo@montague.lit/orchard'
-    type='result'/>
-      ]]></example>
     </section3>
   </section2>
 
   <section2 topic='Informational Messages' anchor='protocol-info'>
-    <p>Informational messages are sent within the context of the Raw UDP transport to communicate whether the party has attempted to send media or has received media. The informational message MUST be an IQ-set containing a &JINGLE; element of type "session-info", where the informational message is a payload  element qualified by the 'urn:xmpp:jingle:transports:raw-udp:info:0' namespace &VNOTE;. The following payload elements are defined:</p>
+    <p>Informational messages are sent within the context of the Raw UDP transport to communicate whether the party has attempted to send media. The informational message MUST be an IQ-set containing a &JINGLE; element of type "session-info", where the informational message is a payload  element qualified by the 'urn:xmpp:jingle:transports:raw-udp:info:0' namespace &VNOTE;. Only the following payload element is defined:</p>
     <table caption='Information Payload Elements'>
       <tr>
         <th>Element</th>
         <th>Meaning</th>
       </tr>
-      <tr>
-        <td>&lt;received/&gt;</td>
-        <td>The party has received media.</td>
-      </tr>
       <tr>
         <td>&lt;trying/&gt;</td>
         <td>The party is trying to send media.</td>
@@ -353,7 +328,7 @@ INITIATOR                            RESPONDER
 </section1>
 
 <section1 topic='Security Considerations' anchor='security'>
-  <p>In order to secure the data stream that is negotiated via the Jingle ICE-UDP transport, implementations SHOULD use encryption methods appropriate to the transport method and media being exchanged (for details regarding RTP sessions, refer to &xep0167;).</p>
+  <p>In order to secure the data stream that is negotiated via the Jingle ICE-UDP transport, implementations SHOULD use encryption methods appropriate to the transport method and media being exchanged (for details regarding RTP sessions, refer to <cite>XEP-0167</cite>).</p>
 </section1>
 
 <section1 topic='IANA Considerations' anchor='iana'>
@@ -438,8 +413,6 @@ INITIATOR                            RESPONDER
     xmlns='urn:xmpp:jingle:transports:raw-udp:info:0'
     elementFormDefault='qualified'>
 
-  <xs:element name='received' type='infoElementType'/>
-
   <xs:element name='trying' type='infoElementType'/>
 
   <xs:complexType name='infoElementType'>
@@ -455,6 +428,6 @@ INITIATOR                            RESPONDER
   </section2>
 </section1>
 <section1 topic='Acknowledgements' anchor='ack'>
-  <p>Thanks to Olivier Cr&#234;te, Steffen Larsen, Robert McQueen, and Mike Ruprecht for their feedback.</p>
+  <p>Thanks to Paul Chitescu, Diana Cionoiu, Olivier Cr&#234;te, Steffen Larsen, Robert McQueen, Mike Ruprecht, and Paul Witty for their feedback.</p>
 </section1>
 </xep>