0.7

xep-0260.xml

@@ -33,6 +33,12 @@
     <email>klaus.hartke@googlemail.com</email>
     <jid>nx@jabber.org</jid>
   </author>
+  <revision>
+    <version>0.7</version>
+    <date>2011-08-31</date>
+    <initials>psa</initials>
+    <remark><p>Per feedback from the XMPP Council, changed some implementation guidelines from normative to informative and modified the security considerations to remove user interface recommendations and the recommendation to use XTLS (since it is not longer being actively developed).</p></remark>
+  </revision>
   <revision>
     <version>0.6</version>
     <date>2011-08-26</date>
@@ -314,7 +320,7 @@ priority = (2^16)*(type preference) + (local preference)
   <section2 topic='Completing the Negotiation' anchor='complete'>
     <p>The transport negotiation is completed in one of the following ways:</p>
     <ol start='1'>
-      <li>If both parties send a candidate-error notification then the SOCKS5 negotiation has failed and the parties need to fall back to some other transport method, typically IBB; see the <link url='#fallback'>Fallback Methods</link> section of this document for details.</li>
+      <li>If both parties send a candidate-error notification then the SOCKS5 negotiation has failed and the parties need to fall back to some other transport method, typically (but not necessarily) IBB; see the <link url='#fallback'>Fallback Methods</link> section of this document for details.</li>
       <li>If one of the parties sends a candidate-error notification and the other party sends a candidate-used notification, then the candidate-used shall be considered the nominated candidate.</li>
       <li>If both parties send a candidate-used notification but the candidates have a different priority, then the candidate with the higher priority shall be considered the nominated candidate.</li>
       <li>If both parties send a candidate-used notification with candidates having the same priority, then the candidate chosen by the initiator shall be considered the nominated candidate (this is consistent with the rules in <cite>XEP-0166</cite>).</li>
@@ -388,7 +394,7 @@ priority = (2^16)*(type preference) + (local preference)
 </section1>
 
 <section1 topic='Fallback Methods' anchor='fallback'>
-  <p>If the SOCKS5 Bytestreams negotiation fails, the parties might want to "fall back" to the transport of last resort, which for a streaming transport is typically &xep0047; as described for Jingle in &xep0261;. The protocol flow is as follows.</p>
+  <p>If the SOCKS5 Bytestreams negotiation fails, the parties might want to "fall back" to another transport. Currently the transport of last resort for a streaming exchange is &xep0047; as described for Jingle in &xep0261;, however if other transport methods are defined in the future (e.g. &ice-tcp;) then clients could fall back to those methods instead of IBB. The protocol flow for fallback from S5B to IBB is as follows.</p>
   <code><![CDATA[
 Romeo                               Juliet
   |                                  |
@@ -468,16 +474,15 @@ Romeo                               Juliet
     to='romeo@montague.lit/orchard'
     type='result'/>
     ]]></example>
-    <p>Now the parties can send data using In-Band Bytestreams as defined in <cite>XEP-0047</cite>.</p>
+    <p>Now the parties can send data using In-Band Bytestreams as defined in <cite>XEP-0261</cite> and <cite>XEP-0047</cite>.</p>
 </section1>
 
 <section1 topic='Processing Rules and Usage Guidelines' anchor='rules'>
-  <p>The same processing rules and usage guidelines defined in XEP-0065 apply to the Jingle S5B Transport Method. Additional implementation suggestions are:</p>
+  <p>The same processing rules and usage guidelines defined in <cite>XEP-0065</cite> apply to the Jingle S5B Transport Method. This document adds the following implementation suggestions in the context of Jingle:</p>
   <ol>
-    <li>A client SHOULD try the offered candidates in the order of their priority, from highest to lowest.</li>
+    <li>Try the offered candidates in the order of their priority, from highest to lowest.</li>
-    <li>If more than one &lt;candidate/&gt; element is present in a session-initiate or session-accept, a client SHOULD wait 200ms before trying the next one.</li>
+    <li>Stagger the connection attempts (e.g., initiate communications with the highest-priority candidate, then wait 200ms before initiating communications with the second-highest-priority candidate).</li>
-    <li>If the other party offered a direct connection and a proxy connection, its peer MAY wait a little bit longer than 200ms before trying the first proxy.</li>
+    <li>To increase the potential for using a direct connection, consider waiting a bit longer than 200ms to initiate communications with proxy candidates.</li>
-    <li>A client SHOULD NOT wait for a TCP timeout on connect. If it is unable to connect to any candidate within 5 seconds it SHOULD send a candidate-error to the other party.</li>
   </ol>
 </section1>
 
@@ -507,15 +512,10 @@ Romeo                               Juliet
 
 <section1 topic='Security Considerations' anchor='security'>
   <section2 topic='Sharing IP Addresses' anchor='security-sharing'>
-    <p>The exchange of candidates might result in exposure of the sender's IP addresses, which comprise a form of personally identifying information. A Jingle client MUST enable a user to control which entities will be allowed to receive such information. If a human user explicitly accepts a session request, then the client SHOULD consider that action to imply approval of IP address sharing. However, waiting for a human user to explicitly accept the session request can result in delays during session setup, since it is more efficient to immediately begin sharing transport candidates. Therefore, it is RECOMMENDED for the client to immediately send transport candidates to a contact (without waiting for explicit user approval of the session request) in the following cases:</p>
+    <p>The exchange of candidates might result in exposure of the sender's IP addresses, which comprise a form of personally identifying information. A Jingle client MUST enable a user to control which entities will be allowed to receive such information. If a human user explicitly accepts a session request, then the client can consider that action to imply approval of IP address sharing.</p>
-    <ol>
-      <li>The user has permanently and formally authorized the contact to view the user's presence information via a presence subscription as reflected in an XMPP roster item (see &xmppim;).</li>
-      <li>The user has temporarily and dynamically shared presence with the contact via "directed presence" as described in <cite>RFC 6121</cite>.</li>
-      <li>The user has explicitly added the contact to a "whitelist" of entities who are allowed to access the user's personally-identifying information.</li>
-    </ol>
   </section2>
   <section2 topic='Encryption of Media' anchor='security-media'>
-    <p>A Jingle implementation SHOULD support security preconditions that are enforced before application media is allowed to flow over the bytestream, such as those described in &xtls;.</p>
+    <p>This specification, like <cite>XEP-0065</cite> before it, does not directly support end-to-end encryption of the media sent over the transport.</p>
   </section2>
 </section1>
 
@@ -635,4 +635,9 @@ Romeo                               Juliet
 </xs:schema>
   ]]></code>
 </section1>
+
+<section1 topic='Acknowledgements' anchor='acks'>
+  <p>Thanks to Steffen Larsen, Tobias Markmann, Florian Schmaus, Kevin Smith, and Remko Tronçon for their feedback.</p>
+</section1>
+
 </xep>