1.0 DRAFT

xep-0260.xml

@@ -10,8 +10,7 @@
   <abstract>This specification defines a Jingle transport method that results in sending data via the SOCKS5 Bytestreams (S5B) protocol defined in XEP-0065. Essentially this transport method reuses XEP-0065 semantics for sending the data and defines native Jingle methods for starting and ending an S5B session.</abstract>
   &LEGALNOTICE;
   <number>0260</number>
-  <status>Experimental</status>
+  <status>Draft</status>
-  <lastcall>2011-07-15</lastcall>
   <type>Standards Track</type>
   <sig>Standards</sig>
   <dependencies>
@@ -22,27 +21,37 @@
   <supersedes/>
   <supersededby/>
   <shortname>jingle-s5b</shortname>
+  <schemaloc>
+    <url>http://xmpp.org/schemas/jingle-transports-s5b.xsd</url>
+  </schemaloc>
   <discuss>jingle</discuss>
   &stpeter;
   &dmeyer;
   &infiniti;
   &mlundblad;
+  &tobias;
   <author>
     <firstname>Klaus</firstname>
     <surname>Hartke</surname>
     <email>klaus.hartke@googlemail.com</email>
     <jid>nx@jabber.org</jid>
   </author>
+  <revision>
+    <version>1.0</version>
+    <date>2011-09-23</date>
+    <initials>psa</initials>
+    <remark><p>Per a vote of the XMPP Council, advanced specification from Experimental to Draft; also added a further note about calculation of the 'dstaddr' attribute.</p></remark>
+  </revision>
   <revision>
     <version>0.9</version>
     <date>2011-09-13</date>
-    <initials>psa</initials>
+    <initials>psa/tm</initials>
     <remark><p>Further clarified use of the dstaddr attribute, especially when the responder shares a proxy candidate with the initiator.</p></remark>
   </revision>
   <revision>
     <version>0.8</version>
     <date>2011-09-08</date>
-    <initials>psa</initials>
+    <initials>psa/tm</initials>
     <remark><p>More clearly described how to activate the bytestream.</p></remark>
   </revision>
   <revision>
@@ -54,7 +63,7 @@
   <revision>
     <version>0.6</version>
     <date>2011-08-26</date>
-    <initials>psa</initials>
+    <initials>psa/tm</initials>
     <remark><p>Added a 'dstaddr' attribute for feature-parity with XEP-0065.</p></remark>
   </revision>
   <revision>
@@ -156,7 +165,7 @@ Initiator                        Responder
     <p>Just as with the &QUERY; element from <cite>XEP-0065</cite>, here the &lt;transport/&gt; element contains the candidates. The following rules apply to the defined attributes of the &lt;transport/&gt; element when sent by the initiator in a Jingle session-initate message:</p>
     <ol>
       <li>The 'sid' attribute MUST be included. This attribute specifies the Stream ID for this bytestream.</li>
-      <li>The 'dstaddr' attribute SHOULD be included if the initiator includes at least one candidate of the "proxy" type. This attribute enables the initiator to communicate the value it has calculated for the SOCKS5 DST.ADDR field (see Section 5.3.2 and Section 7 of <cite>XEP-0065</cite>) so that the responder can provide an accurate value to the proxy during SOCKS5 negotiation. Here the value is calculated as SHA1(SID + Initiator JID + Responder JID) since the initiator will be the entity that activates the bytestream at the proxy.</li>
+      <li>The 'dstaddr' attribute SHOULD be included if the initiator includes at least one candidate of the "proxy" type. This attribute enables the initiator to communicate the value it has calculated for the SOCKS5 DST.ADDR field (see Section 5.3.2 and Section 7 of <cite>XEP-0065</cite>) so that the responder can provide an accurate value to the proxy during SOCKS5 negotiation. Here the value is calculated as SHA1(SID + Initiator JID + Responder JID) since the initiator will be the entity that activates the bytestream at the proxy. <note>In <cite>XEP-0065</cite>, the DST.ADDR is always calculated as SHA1(SID + Requester JID + Target JID); in <cite>XEP-0260</cite> the Jingle "initiator" is the SOCKS5 Bytestreams "requester" and the Jingle "responder" is the SOCKS5 Bytestreams "target", so for proxy candidates sent from the initiator/requester to the responder/target the DST.ADDR is calculated as SHA1(SID + Initiator JID + Responder JID). Note well that the calcuation for proxy candidates sent from the responder/target to the initiator/requester is SHA1(SID + Responder JID + Initiator JID); this scenario is not covered by <cite>XEP-0065</cite> since in that specification only the SOCKS5 Bytestreams "requester" provides candidates.</note></li>
       <li>The 'mode' attribute MAY be included. This attribute specifies whether the underlying transport for the bytestream will be TCP (a value of "tcp", which is the default) or UDP (a value of "udp", see Section 8 of <cite>XEP-0065</cite>).</li>
     </ol>
     <p>In the following example, Romeo's client has two interfaces, one on port 5086 and the other on port 5087. The provided candidates are the IPv4 address of one interface, the IPv4 address of the second interface, and a proxy address at streamer.shakespeare.lit. Because Romeo's client has included a proxy candidate, it includes its computed value for the DST.ADDR field in the 'dstaddr' attribute (here computed as the SHA-1 hash of "vj3hs98yromeo@montague.lit/orchardjuliet@capulet.lit/balcony").</p>
@@ -210,7 +219,7 @@ Initiator                        Responder
     <p>The following rules apply to the defined attributes of the &lt;transport/&gt; element when sent by the responder in a Jingle session-accept message:</p>
     <ol>
       <li>The 'sid' attribute MUST be included and MUST be the same Stream ID communicated by the initiator in the Jingle session-initiate message.</li>
-      <li>The 'dstaddr' attribute SHOULD be included if the responder includes at least one candidate of the "proxy" type. This attribute enables the responder to communicate the value it has calculated for the SOCKS5 DST.ADDR field (see Section 5.3.2 and Section 7 of <cite>XEP-0065</cite>) so that the initiator can provide an accurate value to the proxy during SOCKS5 negotiation. Here the value is calculated as SHA1(SID + Responder JID + Initiator JID) since the responder will be the entity that activates the bytestream at the proxy.</li>
+      <li>The 'dstaddr' attribute SHOULD be included if the responder includes at least one candidate of the "proxy" type. This attribute enables the responder to communicate the value it has calculated for the SOCKS5 DST.ADDR field (see Section 5.3.2 and Section 7 of <cite>XEP-0065</cite>) so that the initiator can provide an accurate value to the proxy during SOCKS5 negotiation. Here the value is calculated as SHA1(SID + Responder JID + Initiator JID) since the responder will be the entity that activates the bytestream at the proxy. <note>As noted, the calculation for proxy candidates sent from the responder/target to the initiator/requester is SHA1(SID + Responder JID + Initiator JID); this scenario is not covered by <cite>XEP-0065</cite> since in that specification only the SOCKS5 Bytestreams "requester" provides candidates.</note></li>
       <li>The 'mode' attribute MUST NOT be included since the underlying transport for the bytestream is determined by the initiator.</li>
     </ol>
     <p>In the following example, Juliet's client opens one port. The provided candidates are the (private) IPv4 address of the interface, a (public) IPv6 address, the public IPv4 address created by mapping the private IP address/port using NAT-PMP, and a proxy address. Because Juliet's client has included a proxy candidate, it includes its computed value for the DST.ADDR field in the 'dstaddr' attribute (here computed as the SHA-1 hash of "vj3hs98yjuliet@capulet.lit/balconyromeo@montague.lit/orchard").</p>
@@ -580,8 +589,14 @@ Romeo                               Juliet
 </section1>
 
 <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
+  <section2 topic='Protocol Namespaces' anchor='registrar-ns'>
+    <p>The &REGISTRAR; includes 'urn:xmpp:jingle:transports:s5b:1' in its registry of protocol namespaces at &NAMESPACES;, as described in Section 4 of &xep0053;.</p>
+  </section2>
+  <section2 topic='Protocol Versioning' anchor='registrar-versioning'>
+    &NSVER;
+  </section2>
   <section2 topic='Jingle Transport Methods' anchor='registrar-transports'>
-    <p>The &REGISTRAR; shall add to its registry of Jingle transport methods a definition for the "jingle-s5b" transport method. The registry submission is as follows:</p>
+    <p>The &REGISTRAR; includes "jingle-s5b" in its registry of Jingle transport methods at &JINGLETRANSPORTS;. The registry submission is as follows:</p>
     <code><![CDATA[
 <transport>
   <name>s5b</name>
@@ -605,6 +620,13 @@ Romeo                               Juliet
     xmlns='urn:xmpp:jingle:transports:s5b:1'
     elementFormDefault='qualified'>
 
+  <xs:annotation>
+    <xs:documentation>
+      The protocol documented by this schema is defined in
+      XEP-0260: http://www.xmpp.org/extensions/xep-0260.html
+    </xs:documentation>
+  </xs:annotation>
+
   <xs:element name='transport'>
     <xs:complexType>
       <xs:choice>
@@ -693,7 +715,7 @@ Romeo                               Juliet
 </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>
+  <p>Thanks to Steffen Larsen, Florian Schmaus, Kevin Smith, and Remko Tronçon for their feedback.</p>
 </section1>
 
 </xep>