0.10

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

xep-0198.xml

@@ -18,11 +18,17 @@
   </dependencies>
   <supersedes>None</supersedes>
   <supersededby>None</supersededby>
-  <shortname>NOT_YET_ASSIGNED</shortname>
+  <shortname>sm</shortname>
   &infiniti;
   &hildjj;
   &stpeter;
   &fabio;
+  <revision>
+    <version>0.10</version>
+    <date>2009-06-11</date>
+    <initials>psa</initials>
+    <remark><p>Editorial review.</p></remark>
+  </revision>
   <revision>
     <version>0.9</version>
     <date>2009-06-03</date>
@@ -143,7 +149,7 @@
   <p>The stream management feature MUST NOT be offered unless the initiating entity has been authenticated (e.g., by means of SASL, &xep0078;, or &xep0220;).</p>
   <example caption='Server sends new stream header along with stream features'><![CDATA[
 S: <stream:stream
-       to='example.com'
+       from='example.com'
        xmlns='jabber:client'
        xmlns:stream='http://etherx.jabber.org/streams'
        version='1.0'>
@@ -174,7 +180,7 @@ S: <enabled xmlns='urn:xmpp:sm:2'/>
   <p>The parties can then the use stream management features defined below.</p>
   <p>If the receiving entity allows session resumption, it MUST include a 'resume' attribute set to a value of "true" or "1".</p>
   <example caption='Server enables stream management with session resumption'><![CDATA[
-S: <enabled xmlns='urn:xmpp:sm:2' resume='true'/>
+S: <enabled xmlns='urn:xmpp:sm:2' 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 'stanzas' attribute to specify the receiving entity's preferred number of stanzas between acks.</p>
@@ -189,7 +195,7 @@ S: <failed xmlns='urn:xmpp:sm:2'>
 <section1 topic='Acks' anchor='acking'>
   <p>After enabling stream management, the initiating or receiving entity can send ack elements at any time over the stream. An ack element is one of the following:</p>
   <ul>
-    <li>The &lt;a/&gt; element is used to <strong>answer</strong> a request for acknowledgement or send an unrequested ack.</li>
+    <li>The &lt;a/&gt; element is used to <strong>answer</strong> a request for acknowledgement or to send an unrequested ack.</li>
     <li>The &lt;r/&gt; element is used to <strong>request</strong> acknowledgement of received stanzas.</li>
   </ul>
   <p>The following attribute is defined:</p>
@@ -198,7 +204,7 @@ S: <failed xmlns='urn:xmpp:sm:2'>
   </ul>
   <p>An &lt;a/&gt; element MUST possess an 'h' attribute.</p>
   <p>An &lt;r/&gt; element SHOULD NOT possess any 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 receiver. By "handled" we mean that the receiver 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 receiver, it is the responsibility of the sender (e.g., to resend it or generate an error if it is never affirmed as handled by the receiver).</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 receiver. By "handled" we mean that the receiver 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 receiver, 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 receiver).</p>
   <p>Note: The value of 'h' starts at zero for the first stanza handled and is incremented 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 following 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[
@@ -217,10 +223,10 @@ S: <a xmlns='urn:xmpp:sm:2' h='0'>
   ]]></example>
   <p>When an &lt;r/&gt; element ("request") is received, the recipient MUST acknowledge it by sending an &lt;a/&gt; element to the sender containing a value of 'h' that is equal to the number of stanzas handled by the recipient of the &lt;r/&gt; element. The response SHOULD be sent as soon as possible after receiving the &lt;r/&gt; element, and MUST NOT be withheld for any condition other than a timeout. For example, a client with a slow connection might want to collect many stanzas over a period of time before acking, and a server might want to throttle incoming stanzas. The sender does not have to wait for an ack to continue sending stanzas. Because acks indicate stanza acceptance, a server that is throttling stanzas MUST delay the response until the client is no longer being penalized (but SHOULD notify the client that it is throttling incoming stanzas, as described under <link url='#throttling'>Throttling</link>).</p>
   <p>When a party returns an ack in response to an &lt;r/&gt; element or receives such an ack, it SHOULD keep a record of the 'h' value returned as the sequence number of the last handled stanza for the current stream (and discard the previous 'h' value).</p>
-  <p>If a stream ends and it is not resumed within the time specified in the acknowledgement feature element, the sequence number and any associated state MAY be discarded by both parties. Before the session state is discarded, implementations SHOULD take alternative action regarding any unhandled stanzas (e.g. stanzas sent after the most recent 'h' value):</p>
+  <p>If a stream ends and it is not resumed within the time specified in the original &lt;enabled/&gt; element, the sequence number and any associated state MAY be discarded by both parties. Before the session state is discarded, implementations SHOULD take alternative action regarding any unhandled stanzas (i.e., stanzas sent after the most recent 'h' value):</p>
   <ul>
     <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 inform the user of the failure via appropriate user-interface elements.</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>
 </section1>
 
@@ -254,18 +260,22 @@ S: <enabled xmlns='urn:xmpp:sm:2' id='some-long-sm-id' resume='true'/>
   </ol>
   <p>To request resumption of the former stream, the initiating entity sends a &lt;resume/&gt; element qualified by the 'urn:xmpp:sm:2' 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 receiving entity 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>
   <example caption='Stream resumption request'><![CDATA[
-C: <resume xmlns='urn:xmpp:sm:2' previd='some-long-sm-id' h='some-sequence-number'/>
+C: <resume xmlns='urn:xmpp:sm:2' 
+           h='some-sequence-number'
+           previd='some-long-sm-id'/>
   ]]></example>
   <p>If the receiving entity can resume the former stream, it MUST return a &lt;resumed/&gt; element that includes 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 receiving entity; if there is no such sequence number for the former stream, the 'h' attribute MUST NOT be included.</p>
   <example caption='Stream resumed'><![CDATA[
-S: <resumed xmlns='urn:xmpp:sm:2' previd='some-long-sm-id' h='another-sequence-number'/>
+S: <resumed xmlns='urn:xmpp:sm:2' 
+            h='another-sequence-number'
+            previd='some-long-sm-id'/>
   ]]></example>
-  <p>If the receiving entity does not support session resumption, it MUST return a &lt;failed/&gt; element, which SHOULD include an error condition of &feature;. If the receiving entity 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 receiving entity SHOULD allow the initiating entity to bind a resource at this point rather than forcing the initiating entity to restart the stream and re-authenticate.</p>
+  <p>If the receiving entity does not support session resumption, it MUST return a &lt;failed/&gt; element, which SHOULD include an error condition of &feature;. If the receiving entity 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 receiving entity 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 former stream is resumed and the receiving entity 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 SHOULD proceed as follows:</p>
   <ul>
-    <li>Both parties SHOULD retransmit any stanzas that were not accepted during the previous session, based on the sequence number reported by the peer.</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 resumes.</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>
     <li>Both parties SHOULD NOT try to re-establish state information (e.g., &xep0030; information).</li>
   </ul>
@@ -281,7 +291,7 @@ S: <t xmlns='urn:xmpp:sm:2'/>
   <example caption='Throttling notification with acking adjustment'><![CDATA[
 S: <t xmlns='urn:xmpp:sm:2' stanzas='5'/>
   ]]></example>
-  <p>If the number of unacknowledged stanzas is greater than or equal to the value of the 'stanzas' attribute, a peer MUST NOT send any further stanzas.</p>
+  <p>If the number of unacknowledged stanzas is greater than or equal to the value of the 'stanzas' attribute, a throttled peer MUST NOT send any further stanzas.</p>
   <p>If an entity sets the value of 'stanzas' to zero, it has stopped reading from the stream entirely.</p>
   <p>For as long as the initiating entity is throttled, the receiving entity SHOULD periodically send a throttling notification to the initiating entity (e.g., every 30 seconds) to obviate the need for pings generated by the initating entity (which the receiving entity will ignore because the initiating entity is throttled).</p>
 </section1>
@@ -301,11 +311,11 @@ S: <failed xmlns='urn:xmpp:sm:2'>
   <p>The following scenarios illustrate several different uses of stream management. The examples are that of a client and a server, but stream management can also be used for server-to-server streams.</p>
 
   <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. In fact, a basic implementation might not even care about sequence numbers and therefore would do the following:</p>
+    <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 receiving entity, 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;, 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>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 outbond 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>
     </ul>
     <p>This is enough of an implementation to minimally satisfy the peer, and allows basic tracking of each outbound stanza. If the stream connection is broken, the application has a queue of unacknowledged stanzas that it can choose to handle appropriately (e.g., warn a human user or silently send after reconnecting).</p>
@@ -326,7 +336,7 @@ C: <iq id='ls72g593' type='get'>
 
 C: <r xmlns='urn:xmpp:sm:2'/>
     ]]></example>
-    <p>The server returns the roster and immediately sends an &lt;a/&gt; element to acknowledge handling of the stanza.</p>
+    <p>The server immediately sends an &lt;a/&gt; element to acknowledge handling of the stanza and then returns the roster.</p>
     <example caption='Server acknowledges handling of client stanza and sends a stanza'><![CDATA[
 S: <a xmlns='urn:xmpp:sm:2' h='0'/>
 
@@ -346,11 +356,12 @@ C: <presence/>
 
 C: <r xmlns='urn:xmpp:sm:2'/>
     ]]></example>
-    <p>The server handles the stanza by broadcasting the user's presence and immediately sends an &lt;a/&gt; element to acknowledge handling of the stanza.</p>
+    <p>The server immediately sends an &lt;a/&gt; element to acknowledge handling of the stanza and then broadcasts the user's presence (including to the client itself as shown below).</p>
     <example caption='Server acknowledges handling of client stanza and sends a stanza'><![CDATA[
 S: <a xmlns='urn:xmpp:sm:2' h='1'/>
 
-S: <presence from='romeo@montague.lit/orchard' to='romeo@montague.lit/orchard'/>
+S: <presence from='romeo@montague.lit/orchard' 
+             to='romeo@montague.lit/orchard'/>
     ]]></example>
     <p>The client then acks the server's second stanza and sends an outbound message followed by an &lt;r/&gt; element.</p>
     <example caption='Client sends a stanza and requests acknowledgement'><![CDATA[
@@ -362,7 +373,7 @@ C: <message to='juliet@capulet.lit'>
 
 C: <r xmlns='urn:xmpp:sm:2'/>
     ]]></example>
-    <p>The server handles the stanza by routing it to the remote contact and immediately sends an &lt;a/&gt; element to acknowledge handling of the stanza.</p>
+    <p>The server immediately sends an &lt;a/&gt; element to acknowledge handling of the stanza and then routes the stanza to the remote contact (not shown here because the server does not send a stanza to the client).</p>
     <example caption='Server acknowledges handling of the stanza'><![CDATA[
 S: <a xmlns='urn:xmpp:sm:2' h='2'/>
     ]]></example>
@@ -392,36 +403,55 @@ S: <a h='9'/>
   </section2>
 
   <section2 topic='Throttling Scenario' anchor='scenarios-throttle'>
-    <p>As mentioned, many servers will impose rate limiting on clients that send large amounts of traffic. In the following scenario, we assume that the first two messages sent by the client are rather large, so the server voluntarily throttles the client. The server then sends throttling notifications every 30 seconds, dynamically adjusting the maximum number of stanzas between acks as a rough indicator of how serious the throttling is.</p>
+    <p>As mentioned, many servers will impose rate limiting on clients that send large amounts of traffic. In the following scenario, we assume that the first three messages sent by the client are rather large, so the server voluntarily throttles the client. The server then sends throttling notifications every 30 seconds, dynamically adjusting the maximum number of stanzas between acks as a rough indicator of how serious the throttling is.</p>
     <example caption='A session with throttling'><![CDATA[
 C: <enable/>
 S: <enabled stanzas='10'/>
 C: <message/>
 C: <message/>
 C: <message/>
+
    [throttling kicks in]
+
 S: <t stanzas='3'/>
+
    [client requests an ack for the first three messages, but
    does not send any more messages until throttling ends]
+
 C: <r/>
+
    [client still throttled, server ignores <r/> for now]
+
    [30 seconds go by]
+
 S: <t/>
+
    [30 seconds go by]
+
 S: <t/>
+
    [backlog starts to ease, server adjusts 'stanzas' value]
+
 S: <t stanzas='5'/>
+
    [client sends another message just because it can]
+
 C: <message/>
+
    [server has handled the first 3 messages so it finally replies to <r/>]
+
 S: <a h='2'/>
 C: <message/>
 C: <message/>
 C: <message/>
 C: <message/>
+
    [client has sent 5 messages so requests an ack]
+
 C: <r/>
+
    [throttling is over, server replies to 2nd <r/> and sets 'stanzas' back to 10]
+
 S: <a h='7'/>
 S: <t stanzas='10'/>
     ]]></example>
@@ -430,14 +460,14 @@ S: <t stanzas='10'/>
 </section1>
 
 <section1 topic='Security Considerations' anchor='security'>
-  <p>A receiving entity MUST NOT allow an initiating entity to resume a stream management session until after the initiating entity has authenticated; this helps to prevent session hijacking.</p>
+  <p>As noted, a receiving entity 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>
 </section1>
 
 <section1 topic='IANA Considerations' anchor='iana'>
   <p>This XEP requires no interaction with &IANA;. </p>
 </section1>
 
-<section1 topic='Jabber Registrar Considerations' anchor='registrar'>
+<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
   <section2 topic='Protocol Namespaces' anchor='registrar-ns'>
     <p>This specification defines the following XML namespace:</p>
     <ul>
@@ -449,7 +479,7 @@ S: <t stanzas='10'/>
     &NSVER;
   </section2>
   <section2 topic='Stream Features' anchor='registrar-stream'>
-    <p>Upon approval of this specification, the XMPP Registrar shall add 'urn:xmpp:sm:2:feature' to its registry of stream features.</p>
+    <p>Upon approval of this specification, the XMPP Registrar shall add 'urn:xmpp:sm:2' to its registry of stream features.</p>
   </section2>
 </section1>
 
@@ -463,7 +493,17 @@ S: <t stanzas='10'/>
     xmlns='urn:xmpp:sm:2'
     elementFormDefault='qualified'>
 
-  <xs:element name='a' type='ackElementType'/>
+  <xs:element name='a'>
+    <xs:complexType>
+      <xs:simpleContent>
+        <xs:extension base='empty'>
+          <xs:attribute name='h' 
+                        type='xs:integer' 
+                        use='required'/>
+        </xs:extension>
+      </xs:simpleContent>
+    </xs:complexType>
+  </xs:element>
 
   <xs:element name='enable'>
     <xs:complexType>
@@ -508,13 +548,25 @@ S: <t stanzas='10'/>
 
   <xs:element name='failed'>
     <xs:complexType>
-      <xs:sequence xmlns:err='urn:ietf:params:xml:ns:xmpp-stanzas' minOccurs='0'>
+      <xs:sequence xmlns:err='urn:ietf:params:xml:ns:xmpp-stanzas' 
+                   minOccurs='0'
+                   minOccurs='1'>
         <xs:group ref='err:stanzaErrorGroup'/>
       </xs:sequence>
     </xs:complexType>
   </xs:element>
 
-  <xs:element name='r' type='ackElementType'/>
+  <xs:element name='r'>
+    <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'>
 
@@ -522,13 +574,10 @@ S: <t stanzas='10'/>
 
   <xs:element name='sm'>
     <xs:complexType>
-      <xs:simpleContent>
+      <xs:choice>
-        <xs:extension base='empty'>
+        <xs:element name='optional' type='empty'/>
-          <xs:attribute name='id' 
+        <xs:element name='required' type='empty'/>
-                        type='xs:string' 
+      </xs:choice>
-                        use='required'/>
-        </xs:extension>
-      </xs:simpleContent>
     </xs:complexType>
   </xs:element>
 
@@ -544,16 +593,6 @@ S: <t stanzas='10'/>
     </xs:complexType>
   </xs:element>
 
-  <xs:complexType name='ackElementType'>
-    <xs:simpleContent>
-      <xs:extension base='empty'>
-        <xs:attribute name='h' 
-                      type='xs:integer' 
-                      use='optional'/>
-      </xs:extension>
-    </xs:simpleContent>
-  </xs:complexType>
-
   <xs:complexType name='resumptionElementType'>
     <xs:simpleContent>
       <xs:extension base='empty'>