1.2rc2

xep-0198.xml

@@ -30,8 +30,8 @@
   &dcridland;
   &mwild;
   <revision>
-    <version>1.2rc1</version>
-    <date>2011-02-11</date>
+    <version>1.2rc2</version>
+    <date>2011-02-17</date>
     <initials>psa/dc/mw</initials>
     <remark><p>Simplification based on implementation experience: removed acking per number of stanzas exchanged because either entity can request an ack at any time; moved throttling feature to a separate specification; removed 'stanzas' attribute from &lt;enable/&gt; element; added 'location' attribute to &lt;enabled/&gt; element; clarified several implementation issues in the text; fixed several examples; versioned the XML namespace from urn:xmpp:sm:2 to urn:xmpp:sm:3.</p></remark>
   </revision>
@@ -204,7 +204,7 @@ S: <enabled xmlns='urn:xmpp:sm:3'/>
 S: <enabled xmlns='urn:xmpp:sm:3' id='some-long-sm-id' resume='true'/>
   ]]></example>
   <p>The &lt;enabled/&gt; element MAY include a 'max' attribute to specify the receiving entity's preferred maximum resumption time.</p>
-  <p>The &lt;enabled/&gt; element MAY include a 'location' attribute to specify the receiving entity's preferred IP address or hostname (optionally with a port) for reconnection; if reconnection to that location fails, the standard XMPP connection algorithm specified in &xmppcore; applies.</p>
+  <p>The &lt;enabled/&gt; element MAY include a 'location' attribute to specify the receiving entity's preferred IP address or hostname (optionally with a port) for reconnection, in the form specified in Section 4.9.3.19 of &rfc3920bis; (i.e., "domainpart:port", where IPv6 addresses are enclosed in square brackets "[...]" as described in &rfc5952;); if reconnection to that location fails, the standard XMPP connection algorithm specified in &xmppcore; applies.</p>
   <p>The initiating entity MUST NOT attempt to negotiate stream management until it is authenticated; i.e., it MUST NOT send an &lt;enable/&gt; element until after authentication (such as SASL, &xep0078; or &xep0220;) has been completed successfully.</p>
   <p>For client-to-server connections, the client MUST NOT attempt to enable stream management until after it has completed Resource Binding <em>unless it is resuming a previous session</em> (see <link url='#resumption'>Resumption</link>).</p>
   <p>The server SHALL enforce this order and return a &lt;failed/&gt; element in response if the order is violated (see <link url='#errors'>Error Handling</link>).</p>
@@ -248,14 +248,15 @@ C: <message from='laurence@example.net/churchyard'
 
    <!-- Note that client need not wait for a response. -->
 
-S: <enabled xmlns='urn:xmpp:sm:3' location='cm66.example.net'/>
+S: <enabled xmlns='urn:xmpp:sm:3'/>
 
-     <!-- Server receives enable, and responds,
-          setting both inbound and outbound counts
-          to zero. 
-          
-          In addition, client sets inbound count to zero. 
-     -->
+   <!-- 
+        Server receives enable, and responds,
+        setting both inbound and outbound counts
+        to zero. 
+        
+        In addition, client sets inbound count to zero. 
+   -->
 
 C: <r xmlns='urn:xmpp:sm:3'/>
 
@@ -283,8 +284,16 @@ C: <enable xmlns='urn:xmpp:sm:3' resume='true'/>
 S: <enabled xmlns='urn:xmpp:sm:3' id='some-long-sm-id' resume='true'/>
   ]]></example>
   <p class='def'><strong>Definition:</strong> The 'id' attribute defines a unique identifier for purposes of stream management (an "SM-ID"). The SM-ID MUST be generated by the receiving entity (server). The initiating entity MUST consider the SM-ID to be opaque and therefore MUST NOT assign any semantic meaning to the SM-ID. The receiving entity MAY encode any information it deems useful into the SM-ID, such as the full JID &LOCALFULL; of a connected client (e.g., the full JID plus a nonce value). Any characters allowed in an XML attribute are allowed. The SM-ID MUST NOT be reused for simultaneous or subsequent sessions (but the server need not ensure that SM-IDs are unique for all time, only for as long as the server is continuously running). The SM-ID SHOULD NOT be longer than 4000 bytes.</p>
+  <p>As noted, the &lt;enabled/&gt; element MAY include a 'location' attribute that specifies the server's preferred location for reconnecting (e.g., a particular connection manager that hold session state for the connected client).</p>
+  <example caption='Server prefers reconnection at a particular location'><![CDATA[
+S: <enabled xmlns='urn:xmpp:sm:3'
+            id='some-long-sm-id'
+            location='[2001:41D0:1:A49b::1]:9222'
+            resume='true'/>
+  ]]></example>
   <p>If the stream is terminated unexpectedly, the initiating entity would then open a TCP connection to the receiving entity. The order of events is as follows:</p>
   <ol start='1'>
+    <li>After disconnection, the initiating entity opens a new TCP connection to the receiving entity, preferring the address specified in the 'location' attribute (if any).</li>
     <li>Initiating entity sends initial stream header.</li>
     <li>Receiving entity sends response stream header.</li>
     <li>Receiving entity sends stream features.</li>