1.3rc3

xep-0198.xml

@@ -30,8 +30,8 @@
   &dcridland;
   &mwild;
   <revision>
-    <version>1.3rc2</version>
+    <version>1.3rc3</version>
-    <date>in progress, last updated 2011-06-01</date>
+    <date>in progress, last updated 2011-06-20</date>
     <initials>psa/mw</initials>
     <remark><p>Corrected the value of 'h' in several examples; removed an extraneous 'stanzas' attribute from one example; clarified terminology; added note about the order of events in the stream negotiation process.</p></remark>
   </revision>
@@ -235,7 +235,7 @@ S: <failed xmlns='urn:xmpp:sm:3'>
   <p>The &lt;r/&gt; element has no defined attributes.</p>
   <p class='def'><strong>Definition:</strong> Acknowledging a previously-received ack element indicates that the stanza(s) sent since then have been "handled" by the server. By "handled" we mean that the server has accepted responsibility for a stanza or stanzas (e.g., to process the stanza(s) directly, deliver the stanza(s) to a local entity such as another connected client on the same server, or route the stanza(s) to a remote entity at a different server); until a stanza has been affirmed as handled by the server, that stanza is the responsibility of the sender (e.g., to resend it or generate an error if it is never affirmed as handled by the server).</p>
   <p>Receipt of an &lt;r/&gt; element does not imply that new stanzas have been transmitted by the peer; receipt of an &lt;a/&gt; element only indicates that new stanzas have been processed if the 'h' attribute has been incremented.</p>
-  <p>The value of 'h' starts at zero at the point stream management is enabled or requested to be enabled, is incremented to one for the first stanza handled, and is incremented by one again with each subsequent stanza handled. In the unlikely case that the number of stanzas handled during a stream management session exceeds the number of digits that can be represented by the unsignedInt datatype as specified in &w3xmlschema2; (i.e., 2<span class='super'>32</span>), the value of 'h' SHALL be reset from 2<span class='super'>32</span>-1 back to zero (rather than being incremented to 2<span class='super'>32</span>).</p>
+  <p>The value of 'h' starts at zero at the point stream management is enabled or requested to be enabled (see note below). The value of 'h' is then incremented to one for the first stanza handled and incremented by one again with each subsequent stanza handled. In the unlikely case that the number of stanzas handled during a stream management session exceeds the number of digits that can be represented by the unsignedInt datatype as specified in &w3xmlschema2; (i.e., 2<span class='super'>32</span>), the value of 'h' SHALL be reset from 2<span class='super'>32</span>-1 back to zero (rather than being incremented to 2<span class='super'>32</span>).</p>
   <p class='box'>Note: There are two values of 'h' for any given stream: one maintained by the client to keep track of stanzas it has handled from the server, and one maintained by the server to keep track of stanzas it has handled from the client. The client initializes its value to zero when it sends &lt;enable/&gt; to the server, and the server initializes its value to zero when it receives &lt;enabled/&gt; from the client (it is expected that the server will respond immediately to &lt;enable/&gt; and set its counter to zero at that time). After this initialization, the client increments its value of 'h' for each stanza it handles from server, and the server increments its value of 'h' for each stanza it handles from the client.</p>
   <p>The following annotated example shows a message sent by the client, a request for acknowledgement, and an ack of the stanza.</p>
    <example caption='Simple stanza acking'><![CDATA[
@@ -276,12 +276,13 @@ S: <a xmlns='urn:xmpp:sm:3' h='1'/>
     <li>A server SHOULD treat unacknowledged stanzas in the same way that it would treat a stanza sent to an unavailable resource, by either returning an error to the sender or committing the stanza to offline storage.</li>
     <li>A user-oriented client SHOULD try to silently resend the stanzas upon reconnection or inform the user of the failure via appropriate user-interface elements.</li>
   </ul>
+  <p>Because unacknowledged stanzas might have been received by the other party, resending them might result in duplicates; there is no way to prevent such a result in this protocol, although use of the XMPP 'id' attribute on all stanzas can at least assist the intended recipients in weeding out duplicate stanzas.</p>
 </section1>
 
 <section1 topic='Resumption' anchor='resumption'>
   <p>It can happen that an XML stream is terminated unexpectedly (e.g., because of network outages). In this case, it is desirable to quickly resume the former stream rather than complete the tedious process of stream establishment, roster retrieval, and presence broadcast.</p>
   <p>In addition, this protocol exchanges the sequence numbers of the last received stanzas on the previous connection, allowing entities to establish definitively which stanzas require retransmission and which do not, eliminating duplication through replay.</p>
-  <p>To request that the stream will be resumable, when enabling stream management the initiating entity MUST add a 'resume' attribute to the &lt;enable/&gt; element with a value of "true" or "1" &BOOLEANNOTE;.</p>
+  <p>To request that the stream will be resumable, when enabling stream management the client MUST add a 'resume' attribute to the &lt;enable/&gt; element with a value of "true" or "1" &BOOLEANNOTE;.</p>
   <example caption='Client enables stream management'><![CDATA[
 C: <enable xmlns='urn:xmpp:sm:3' resume='true'/>
   ]]></example>
@@ -289,7 +290,7 @@ C: <enable xmlns='urn:xmpp:sm:3' resume='true'/>
   <example caption='Server allows stream resumption'><![CDATA[
 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 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 server 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 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 server. The client MUST consider the SM-ID to be opaque and therefore MUST NOT assign any semantic meaning to the SM-ID. The server 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'
@@ -297,41 +298,43 @@ S: <enabled xmlns='urn:xmpp:sm:3'
             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 server. The order of events is as follows:</p>
+  <p>If the stream is terminated unexpectedly, the client would then open a TCP connection to the server. The order of events is as follows:</p>
   <ol start='1'>
-    <li>After disconnection, the initiating entity opens a new TCP connection to the server, preferring the address specified in the 'location' attribute (if any).</li>
+    <li>After disconnection, the client opens a new TCP connection to the server, preferring the address specified in the 'location' attribute (if any).</li>
-    <li>Initiating entity sends initial stream header.</li>
+    <li>Client sends initial stream header.</li>
-    <li>Receiving entity sends response stream header.</li>
+    <li>Server sends response stream header.</li>
-    <li>Receiving entity sends stream features.</li>
+    <li>Server sends stream features.</li>
-    <li>Initiating entity sends STARTTLS request.</li>
+    <li>Client sends STARTTLS request.</li>
-    <li>Receiving entity informs initiating entity to proceed with the TLS negotiation.</li>
+    <li>Server informs client to proceed with the TLS negotiation.</li>
     <li>The parties complete a TLS handshake. (Note: When performing session resumption and also utilizing TLS, it is RECOMMENDED to take advantage of TLS session resumption to further optimize the resumption of the XML stream.)</li>
-    <li>Initiating entity sends new initial stream header.</li>
+    <li>Client sends new initial stream header.</li>
-    <li>Receiving entity sends response stream header.</li>
+    <li>Server sends response stream header.</li>
-    <li>Receiving entity sends stream features, requiring SASL negotiation and offering appropriate SASL mechanisms. (Note: If the server considers the information provided during TLS session resumption to be sufficient authentication, it MAY offer the SASL EXTERNAL mechanism; for details, refer to &sasltls;.)</li>
+    <li>Server sends stream features, requiring SASL negotiation and offering appropriate SASL mechanisms. (Note: If the server considers the information provided during TLS session resumption to be sufficient authentication, it MAY offer the SASL EXTERNAL mechanism; for details, refer to &sasltls;.)</li>
     <li>The parties complete SASL negotiation.</li>
-    <li>Initiating entity sends new initial stream header.</li>
+    <li>Client sends new initial stream header.</li>
-    <li>Receiving entity sends response stream header.</li>
+    <li>Server sends response stream header.</li>
-    <li>Receiving entity sends stream features, offering the SM feature.</li>
+    <li>Server sends stream features, offering the SM feature.</li>
-    <li>Initiating entity requests resumption of the former stream.</li>
+    <li>Client requests resumption of the former stream.</li>
   </ol>
   <p>Note: The order of events might differ from those shown above, depending on when the server offers the SM feature, whether the client chooses STARTTLS, etc. Furthermore, in practice server-to-server streams often do not complete SASL negotiation or even TLS negotiation. The foregoing text does not modify any rules about the stream negotiation process specified in <cite>RFC 6120</cite>. However, since stream management applies to the exchange of stanzas (not any other XML elements), it makes sense for the server to offer the SM feature when it will be possible for the other party to start sending stanzas, not before. See also &xep0170;.</p>
-  <p>To request resumption of the former stream, the initiating entity sends a &lt;resume/&gt; element qualified by the 'urn:xmpp:sm:3' namespace. The &lt;resume/&gt; element MUST include a 'previd' attribute whose value is the SM-ID of the former stream and MAY include an 'h' attribute that identifies the sequence number of the last handled stanza sent over the former stream from the server to the initiating entity (if stream management was being used in both directions); if there is no such sequence number for the former stream, the 'h' attribute MUST NOT be included.</p>
+  <p>To request resumption of the former stream, the client sends a &lt;resume/&gt; element qualified by the 'urn:xmpp:sm:3' namespace. The &lt;resume/&gt; element MUST include a 'previd' attribute whose value is the SM-ID of the former stream and MUST include an 'h' attribute that identifies the sequence number of the last handled stanza sent over the former stream from the server to the client (in the unlikely case that the client never received any stanzas, it would set 'h' to zero).</p>
   <example caption='Stream resumption request'><![CDATA[
 C: <resume xmlns='urn:xmpp:sm:3' 
            h='some-sequence-number'
            previd='some-long-sm-id'/>
   ]]></example>
-  <p>If the server can resume the former stream, it MUST return a &lt;resumed/&gt; element, which MUST include a 'previd' attribute set to the SM-ID of the former stream. The &lt;resumed/&gt; element MAY also include an 'h' attribute set to the sequence number of the last handled stanza sent over the former stream from the initiating entity to the server; if there is no such sequence number for the former stream, the 'h' attribute MUST NOT be included.</p>
+  <p>If the server can resume the former stream, it MUST return a &lt;resumed/&gt; element, which MUST include a 'previd' attribute set to the SM-ID of the former stream and MUST also include an 'h' attribute set to the sequence number of the last handled stanza sent over the former stream from the client to the server (in the unlikely case that the server never received any stanzas, it would set 'h' to zero).</p>
   <example caption='Stream resumed'><![CDATA[
 S: <resumed xmlns='urn:xmpp:sm:3' 
             h='another-sequence-number'
             previd='some-long-sm-id'/>
   ]]></example>
-  <p>If the server does not support session resumption, it MUST return a &lt;failed/&gt; element, which SHOULD include an error condition of &feature;. If the server does not recognize the 'previd' as an earlier session (e.g., because the former session has timed out), it MUST return a &lt;failed/&gt; element, which SHOULD include an error condition of &notfound;. In both of these failure cases, the server SHOULD allow the initiating entity to bind a resource at this point rather than forcing the initiating entity to restart the stream negotiation process and re-authenticate.</p>
+  <p>If the server does not support session resumption, it MUST return a &lt;failed/&gt; element, which SHOULD include an error condition of &feature;. If the server does not recognize the 'previd' as an earlier session (e.g., because the former session has timed out), it MUST return a &lt;failed/&gt; element, which SHOULD include an error condition of &notfound;. In both of these failure cases, the server SHOULD allow the client to bind a resource at this point rather than forcing the client to restart the stream negotiation process and re-authenticate.</p>
   <p>If the former stream is resumed and the server still has the stream for the previously-identified session open at this time, the old stream SHOULD be terminated.</p>
   <p>When a session is resumed, the parties proceed as follows:</p>
   <ul>
+    <li>The sequence values are carried over from the previous session and are not reset for the new stream.</li>
+    <li>Upon receiving a &lt;resume/&gt; or &lt;resumed/&gt; element the client and server use the 'h' attribute to retransmit any stanzas lost by the disconnection. In effect, it should handle the element's 'h' attribute as it would handle it on an &lt;a/&gt; element (i.e., marking stanzas in its outgoing queue as handled), except that after processing it MUST re-send to the peer any stanzas that are still marked as unhandled.</li>
     <li>Both parties SHOULD retransmit any stanzas that were not handled during the previous session, based on the sequence number reported by the peer.</li>
     <li>A reconnecting client SHOULD NOT request the roster, because any roster changes that occurred while the client was disconnected will be sent to the client after the stream management session resumes.</li>
     <li>The client SHOULD NOT resend presence stanzas in an attempt to restore its former presence state, since this state will have been retained by the server.</li>
@@ -361,7 +364,7 @@ S: <failed xmlns='urn:xmpp:sm:3'>
   <section2 topic='Basic Acking Scenario' anchor='scenarios-basic'>
     <p>The Stream Management protocol can be used to improve reliability using acks without the ability to resume a session. A basic implementation would do the following:</p>
     <ul>
-      <li>As an initiating entity, send &lt;enable/&gt; with no attributes, and ignore the attributes on the &lt;enabled/&gt; response.</li>
+      <li>As a client, send &lt;enable/&gt; with no attributes, and ignore the attributes on the &lt;enabled/&gt; response.</li>
       <li>As a server, ignore the attributes on the &lt;enable/&gt; element received, and respond via &lt;enabled/&gt; with no attributes.</li>
       <li>When receiving an &lt;r/&gt; element, immediately respond via an &lt;a/&gt; element where the value of 'h' returned is the sequence number of the last handled stanza.</li>
       <li>Keep an integer X for this stream session, initially set to zero. When about to send a stanza, first put the stanza (paired with the current value of X) in an "unacknowleged" queue. Then send the stanza over the wire with &lt;r/&gt; to request acknowledgement of that outbound stanza, and increment X by 1. When receiving an &lt;r/&gt; or &lt;a/&gt; element with an 'h' attribute, all stanzas whose paired value (X at the time of queueing) is less than or equal to the value of 'h' can be removed from the unacknowledged queue.</li>
@@ -431,7 +434,7 @@ S: <a xmlns='urn:xmpp:sm:3' h='3'/>
     <p>The basic acking scenario is wasteful because the client requested an ack for each stanza. A more efficient approach is to periodically request acks (e.g., every 5 stanzas). This is shown schematically in the following pseudo-XML.</p>
     <example caption='An efficient session'><![CDATA[
 C: <enable/>
-S: <enabled>
+S: <enabled/>
 C: <message/>
 C: <message/>
 C: <message/>
@@ -452,7 +455,7 @@ S: <a h='10'/>
 </section1>
 
 <section1 topic='Security Considerations' anchor='security'>
-  <p>As noted, a server MUST NOT allow an initiating entity to resume a stream management session until after the initiating entity has authenticated (for some value of "authentication"); this helps to prevent session hijacking.</p>
+  <p>As noted, a server MUST NOT allow an client to resume a stream management session until after the client has authenticated (for some value of "authentication"); this helps to prevent session hijacking.</p>
 </section1>
 
 <section1 topic='IANA Considerations' anchor='iana'>
@@ -555,17 +558,7 @@ S: <a h='10'/>
     </xs:complexType>
   </xs:element>
 
-  <xs:element name='r'>
+  <xs:element name='r' type='empty'/>
-    <xs:complexType>
-      <xs:simpleContent>
-        <xs:extension base='empty'>
-          <xs:attribute name='h' 
-                        type='xs:integer' 
-                        use='optional'/>
-        </xs:extension>
-      </xs:simpleContent>
-    </xs:complexType>
-  </xs:element>
 
   <xs:element name='resume' type='resumptionElementType'/>