corrected transport terminology

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

xep-0166.xml

@@ -53,7 +53,7 @@
     <initials>psa/ram</initials>
     <remark>
       <ul>
-        <li>Changed "reliable" vs. "lossy" to "stream" vs. "datagram", since reliability or dependability is orthogonal to the streaming nature of the transport.</li>
+        <li>Changed "reliable" vs. "lossy" to "streaming" vs. "datagram", since reliability or dependability is orthogonal to the streaming nature of the transport.</li>
         <li>Deleted the "content-remove" action.</li>
         <li>Added "transport-replace" action (answered by "transport-accept").</li>
         <li>Removed &lt;condition/&gt; element as container for Jingle condition elements inside &lt;reason/&gt;, since it introduced an unnecessary layer of indirection.</li>
@@ -463,7 +463,7 @@ Romeo                         Juliet
     </tr>
     <tr>
       <td>Transport Method</td>
-      <td>The method for establishing data stream(s) between entities. Possible transports might include ICE-TCP, Raw UDP, inband data, etc. This is the 'how' of the session. In Jingle XML syntax this is the namespace of the &TRANSPORT; element. The transport method defines how to transfer bits from one host to another. Each transport method must specify whether it is datagram (thus suitable for applications where some packet loss is tolerable) or stream (thus suitable for applications where packet loss is not tolerable).</td>
+      <td>The method for establishing data stream(s) between entities. Possible transports might include ICE-TCP, Raw UDP, inband data, etc. This is the 'how' of the session. In Jingle XML syntax this is the namespace of the &TRANSPORT; element. The transport method defines how to transfer bits from one host to another. Each transport method must specify whether it is datagram (thus suitable for applications where some packet loss is tolerable) or streaming (thus suitable for applications where packet loss is not tolerable).</td>
     </tr>
   </table>
   </section2>
@@ -551,7 +551,7 @@ PENDING  o----------------------+   |
       <li>session-terminate -- End an existing session.</li>
       <li>transport-accept -- Accept a transport-replace action received from another party.</li>
       <li>transport-info -- Exchange transport candidates.</li>
-      <li>transport-replace -- Redefine a transport method.</li>
+      <li>transport-replace -- Redefine a transport method or replace it with a different method.</li>
     </ul>
   </section2>
 </section1>
@@ -943,7 +943,7 @@ PENDING  o----------------------+   |
       <p>The <strong>transport-info</strong> action is used to exchange transport candidates; it is mainly used in <cite>XEP-0176</cite> but might be used in other transport specifications.</p>
     </section3>
     <section3 topic='transport-replace' anchor='def-action-transport-replace'>
-      <p>The <strong>transport-replace</strong> action is used to redefine a transport method.</p>
+      <p>The <strong>transport-replace</strong> action is used to redefine a transport method, typically for fallback to a different method (e.g., changing from ICE-UDP to Raw UDP for a datagram transport, or changing from &xep0065; to &xep0047; for a streaming transport).</p>
     </section3>
     <section3 topic='Tie Breaking Related to Jingle Actions' anchor='def-action-ties'>
       <p>It is possible that two instances of certain actions can be sent at the same time in the context of an existing session, one by each party; for example, both parties might simulaneously attempt to send a content-add, content-modify, or content-remove action. In all such cases, the action sent by the initiator MUST overrule the action sent by the responder; i.e., both parties MUST accept the action sent by the initiator and the initiator MUST return an &unexpected; error to the responder for the duplicate action.</p>
@@ -1097,8 +1097,8 @@ PENDING  o----------------------+   |
       <li>How successful application format negotiation occurs.</li>
       <li>A &DESCRIPTION; element and associated semantics for representing the application format.</li>
       <li>If and how the application format can be mapped to the Session Description Protocol, including the appropriate SDP media type (see Section 8.2.1 of <cite>RFC 4566</cite>).</li>
-      <li>Whether the media for the application format shall be sent over a stream transport method or a datagram transport method (or, if both, which is preferred).</li>
+      <li>Whether the media for the application format shall be sent over a streaming transport method or a datagram transport method (or, if both, which is preferred).</li>
-      <li>Exactly how the media is to be sent and received over a stream or datagram transport.</li>
+      <li>Exactly how the media is to be sent and received over a streaming or datagram transport.</li>
     </ol>
   </section2>
   <section2 topic='Transport Methods' anchor='conformance-transports'>
@@ -1106,7 +1106,7 @@ PENDING  o----------------------+   |
     <ol>
       <li>How successful transport negotiation occurs.</li>
       <li>A &TRANSPORT; element and associated semantics for representing the transport method.</li>
-      <li>Whether the transport is stream or datagram.</li>
+      <li>Whether the transport is streaming or datagram.</li>
       <li>If and how the transport handles "components" (e.g., for the Real Time Control Protocol).</li>
     </ol>
   </section2>
@@ -1148,7 +1148,7 @@ PENDING  o----------------------+   |
   <name>The name of the application format.</name>
   <desc>A natural-language summary of the application format.</desc>
   <transport>
-    Whether the media can be sent over a "stream" transport, 
+    Whether the media can be sent over a "streaming" transport, 
     a "datagram" transport, or "both".
   </transport>
   <doc>The document in which the application format is specified.</doc>
@@ -1162,7 +1162,7 @@ PENDING  o----------------------+   |
 <transport>
   <name>the name of the transport method</name>
   <desc>a natural-language summary of the transport method</desc>
-  <type>whether the transport method can be "stream", "datagram", or "both"</type>
+  <type>whether the transport method can be "streaming", "datagram", or "both"</type>
   <doc>the document in which this transport method is specified</doc>
 </transport>
     ]]></code>

xep-0167.xml

@@ -129,7 +129,7 @@
     <version>0.9</version>
     <date>2007-04-17</date>
     <initials>psa</initials>
-    <remark><p>Specified Jingle conformance, including the preference for lossy transports over reliable transports and the process of sending and receiving audio content over each transport type.</p></remark>
+    <remark><p>Specified Jingle conformance, including the preference for datagram transports over streaming transports and the process of sending and receiving audio content over each transport type.</p></remark>
   </revision>
   <revision>
     <version>0.8</version>
@@ -218,12 +218,12 @@
      <li><p>The application format negotiation process is defined in the <link url='#negotiation'>Negotiating a Jingle RTP Session</link> section of this document.</p></li>
      <li><p>The semantics of the &DESCRIPTION; element are defined in the <link url='#format'>Application Format</link> section of this document.</p></li>
      <li><p>A mapping of Jingle semantics to the Session Description Protocol is provided in the <link url='#sdp'>Mapping to Session Description Protocol</link> section of this document.</p></li>
-     <li><p>A Jingle RTP session SHOULD use a lossy transport method such as &xep0177; or the "ice-udp" method specified in &xep0176;, but MAY use a reliable transport such as "ice-tcp" if a low-bandwidth codec is employed and the media negotiated is not unduly heavy (e.g., it might be possible to use a reliable transport for audio, but not for video).</p></li>
+     <li><p>A Jingle RTP session SHOULD use a datagram transport method such as &xep0177; or the "ice-udp" method specified in &xep0176;, but MAY use a streaming transport such as "ice-tcp" if a low-bandwidth codec is employed and the media negotiated is not unduly heavy (e.g., it might be possible to use a streaming transport for audio, but not for video).</p></li>
      <li>
        <p>Content is to be sent and received as follows:</p>
        <ul>
-         <li><p>For lossy transports, outbound content shall be encoded into RTP packets and each packet shall be sent individually over the transport. Each inbound packet received over the transport is an RTP packet.</p></li>
+         <li><p>For datagram transports, outbound content shall be encoded into RTP packets and each packet shall be sent individually over the transport. Each inbound packet received over the transport is an RTP packet.</p></li>
-         <li><p>For reliable transports, outbound content shall be encoded into RTP packets and each packet data shall be sent in succession over the transport. Incoming data received over the transport shall be processed as a stream of RTP packets, where each RTP packet boundary marks the location of the next packet.</p></li>
+         <li><p>For streaming transports, outbound content shall be encoded into RTP packets and each packet data shall be sent in succession over the transport. Incoming data received over the transport shall be processed as a stream of RTP packets, where each RTP packet boundary marks the location of the next packet.</p></li>
        </ul>
      </li>
    </ol>
@@ -1644,7 +1644,7 @@ Romeo                         Juliet
     Jingle sessions that support media exchange 
     via the Real-time Transport Protocol.
   </desc>
-  <transport>lossy</transport>
+  <transport>datagram</transport>
   <doc>XEP-0167</doc>
 </application>
     ]]></code>

xep-0177.xml

@@ -61,7 +61,7 @@
     <version>0.6</version>
     <date>2007-04-17</date>
     <initials>psa</initials>
-    <remark><p>Specified Jingle conformance, including definition of transport type as lossy; added section on service discovery.</p></remark>
+    <remark><p>Specified Jingle conformance, including definition of transport type as datagram; added section on service discovery.</p></remark>
   </revision>
   <revision>
     <version>0.5</version>
@@ -95,7 +95,7 @@
   </revision>
 </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 lossy transport method suitable for use in media applications where some packet loss is tolerable (e.g., audio and video).</p>
+  <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>
 </section1>
 <section1 topic='Requirements' anchor='reqs'>
@@ -111,7 +111,7 @@
    <ol>
      <li><p>The transport negotiation process is defined in the <link url='#protocol'>Protocol Description</link> section of this document.</p></li>
      <li><p>The semantics of the &TRANSPORT; element are defined in the <link url='#initiate'>Transport Initiation</link> section of this document.</p></li>
-     <li><p>Successful negotiation of the Raw UDP method results in use of a lossy transport that is suitable for applications where some packet loss is tolerable, such as audio and video.</p></li>
+     <li><p>Successful negotiation of the Raw UDP method results in use of a datagram transport that is suitable for applications where some packet loss is tolerable, such as audio and video.</p></li>
      <li><p>If multiple components are to be communicated over the transport, the first component shall be associated with the port in the transport initiation stanza and the second component (e.g., for RTCP) shall be associated with a UDP port that is one number higher than the specified port (e.g., if the specified port is 13540 then the port for the second component shall be 13541).</p></li>
    </ol>
 </section1>
@@ -328,7 +328,7 @@
 <transport>
   <name>raw-udp</name>
   <desc>A method for exchanging data over raw UDP datagrams.</desc>
-  <type>lossy</type>
+  <type>datagram</type>
   <doc>XEP-0177</doc>
 </transport>
     ]]></code>