0.8 published

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3028 4b5297f7-1745-476d-ba37-a9c6900126ab
2024-11-28 20:22:24 -05:00 · 2009-04-10 00:17:38 +00:00 · 2009-04-10 00:17:38 +00:00 · ddea3e03f5
commit ddea3e03f5
parent f59293e368
1 changed files with 99 additions and 93 deletions
--- a/xep-0198.xml
+++ b/xep-0198.xml
@ -25,9 +25,18 @@
  &fabio;
  <revision>
    <version>0.8</version>
-    <date>2009-04-08</date>
+    <date>2009-04-09</date>
-    <initials>ff/jk/psa</initials>
+    <initials>ff/jk/jjh/psa</initials>
-    <remark><p>Simplified protocol by making the sequence number increment per stanza and removing the u attribute (which is now unnecessary); added &lt;t/&gt; element for throttling notifications.</p></remark>
+    <remark>
      <ul>
        <li>Added &lt;t/&gt; element for throttling notifications, including 'stanzas' attribute for dynamic adjustment of the stanzas window.</li>
        <li>Simplified protocol by making the sequence number increment per stanza and removing the u attribute (which is now unnecessary).</li>
        <li>Removed 'h' attribute from &lt;r/&gt; element.</li>
        <li>Added 'max' and 'stanzas' attributes to both &lt;enable/&gt; and &lt;enabled/&gt; elements, and removed those attributes from the &lt;sm/&gt; element.</li>
        <li>Incremented the protocol version from 1 to 2.</li>
        <li>Added in-depth usage scenarios.</li>
      </ul>
    </remark>
  </revision>
  <revision>
    <version>0.7</version>
@ -41,7 +50,7 @@
    <initials>psa</initials>
    <remark>
      <ul>
-        <li>Incremented protocol number from 0 to 1.</li>
+        <li>Incremented protocol version from 0 to 1.</li>
        <li>Changed attribute names from c (?) and b (?) to u (unacknowledged) and h (handled).</li>
        <li>Added stanzas attribute to specify maximum number of stanzas between acking requests.</li>
        <li>More clearly defined error handling using &lt;failed/&gt; element plus stanza error conditions.</li>
@ -116,8 +125,8 @@
 </section1>
 <section1 topic='Stream Feature' anchor='feature'>
-  <p>After negotiating use of TLS and authenticating via SASL, the receiving entity returns a new stream header to the intiating entity along with stream features, where the features include an &lt;sm/&gt; element qualified by the 'urn:xmpp:sm:1' namespace &VNOTE;.</p>
+  <p>After negotiating use of TLS and authenticating via SASL, the receiving entity returns a new stream header to the intiating entity along with stream features, where the features include an &lt;sm/&gt; element qualified by the 'urn:xmpp:sm:2' namespace &VNOTE;.</p>
-  <p>The stream management feature MUST NOT be offered unless the initiating entity has been authenticated via SASL, &xep0078;, or &xep0220;.</p>
+  <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'
@ -129,29 +138,7 @@ S: <stream:features>
     <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
       <required/>
     </bind>
-     <sm xmlns='urn:xmpp:sm:1'>
+     <sm xmlns='urn:xmpp:sm:2'>
       <optional/>
     </sm>
   </stream:features>
  ]]></example>
  <p>The &lt;sm/&gt; element MAY include a 'stanzas' attribute whose value indicates the server's preferred maximum number of received stanzas between acks. For example, if the 'stanzas' attribute has a value of "10" then a server would prefer that a connected client request an ack after the client has sent at most ten stanzas to the server.</p>
  <example caption='Stream features with stanzas attribute'><![CDATA[
 S: <stream:features>
     <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
       <required/>
     </bind>
     <sm xmlns='urn:xmpp:sm:1' stanzas='10'>
       <optional/>
     </sm>
   </stream:features>
  ]]></example>
  <p>If the receiving entity offers stream resumption in addition to stanza acks, the &lt;sm/&gt; element MUST include a 'max' attribute that specifies the longest allowable time period for session resumption (in seconds).</p>
  <example caption='Stream features for resumption'><![CDATA[
 S: <stream:features>
     <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
       <required/>
     </bind>
     <sm xmlns='urn:xmpp:sm:1' max='600' stanzas='10'>
       <optional/>
     </sm>
   </stream:features>
@ -159,23 +146,27 @@ S: <stream:features>
 </section1>
 <section1 topic='Enabling Stream Management' anchor='enable'>
-  <p>To enable use of stream management, the client sends an &lt;enable/&gt; command to the server.</p>
+  <p>To enable use of stream management, the initiating entity sends an &lt;enable/&gt; command to the receiving entity.</p>
  <example caption='Client enables stream management'><![CDATA[
-C: <enable xmlns='urn:xmpp:sm:1'/>
+C: <enable xmlns='urn:xmpp:sm:2'/>
  ]]></example>
-  <p>If the client wants to be allowed to resume the stream, it includes a boolean 'resume' attribute, which defaults to false &BOOLEANNOTE;. For information about resuming a previous session, see the <link url='#resumption'>Resumption</link> section of this document.</p>
+  <p>If the initiating entity wants to be allowed to resume the stream, it includes a boolean 'resume' attribute, which defaults to false &BOOLEANNOTE;. For information about resuming a previous session, see the <link url='#resumption'>Resumption</link> section of this document.</p>
-  <p>Upon receiving the enable request, the receiving entity MUST reply with an &lt;enabled/&gt; element or a &lt;failed/&gt; element qualified by the 'urn:xmpp:sm:1' namespace. The &lt;failed/&gt; element indicates that there was a problem establishing the stream management "session". The &lt;enabled/&gt; element indicates successful establishment of the stream management session.</p>
+  <p>The &lt;enable/&gt; element MAY include a 'max' attribute to specify the initiating entity's preferred maximum resumption time.</p>
  <p>The &lt;enable/&gt; element MAY include a 'stanzas' attribute to specify the initiating entity's preferred number of stanzas between acks.</p>
  <p>Upon receiving the enable request, the receiving entity MUST reply with an &lt;enabled/&gt; element or a &lt;failed/&gt; element qualified by the 'urn:xmpp:sm:2' namespace. The &lt;failed/&gt; element indicates that there was a problem establishing the stream management "session". The &lt;enabled/&gt; element indicates successful establishment of the stream management session.</p>
  <example caption='Server enables stream management'><![CDATA[
-S: <enabled xmlns='urn:xmpp:sm:1'/>
+S: <enabled xmlns='urn:xmpp:sm:2'/>
  ]]></example>
  <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:1' resume='true'/>
+S: <enabled xmlns='urn:xmpp:sm:2' resume='true'/>
  ]]></example>
-  <p>For client-to-server connections, the client SHOULD NOT attempt to enable stream management until after it has completed Resource Binding (unless it is resuming a previous session). The server MAY enforce this order and return a &lt;failed/&gt; element in response (see <link url='#errors'>Error Handling</link>).</p>
+  <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>
  <p>For client-to-server connections, the client SHOULD 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>). The server MAY enforce this order and return a &lt;failed/&gt; element in response (see <link url='#errors'>Error Handling</link>).</p>
  <example caption='Server returns error if client attempts to enable stream management before resource binding'><![CDATA[
-S: <failed xmlns='urn:xmpp:sm:1'>
+S: <failed xmlns='urn:xmpp:sm:2'>
     <unexpected-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
   </failed>
  ]]></example>
@ -184,16 +175,16 @@ S: <failed xmlns='urn:xmpp:sm:1'>
 <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;r/&gt; element is used to <strong>request</strong> acknowledgement of received stanzas.</li>
    <li>The &lt;a/&gt; element is used to <strong>answer</strong> a request for acknowledgement.</li>
  </ul>
  <p>The following attribute is defined:</p>
  <ul>
    <li>The 'h' attribute identifies the last <strong>handled</strong> stanza (i.e., the last stanza that the receiver will acknowledge as having received).</li>
  </ul>
-  <p>An &lt;r/&gt; element MAY contain an 'h' attribute (if acking is done in both directions).</p>
+  <p>An &lt;a/&gt; element MUST possess an 'h' attribute.</p>
-  <p>An &lt;a/&gt; element MUST contain 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 stanzas have been accepted by the receiver, not necessarily that they have been fully processed by the receiver, delivered to a local entity such as another connected client on the same server, or routed to a remote entity at a different server.</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 stanzas have been accepted by the receiver, not necessarily that they have been fully processed by the receiver, delivered to a local entity such as another connected client on the same server, or routed to a remote entity at a different server. Therefore value of 'h' starts at one (the first stanza handled) and is incremented with each subsequent stanza handled.</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[
 C: <message from='laurence@example.net/churchyard'
@ -205,9 +196,9 @@ C: <message from='laurence@example.net/churchyard'
     </body>
   </message>
-C: <r xmlns='urn:xmpp:sm:1'>
+C: <r xmlns='urn:xmpp:sm:2'>
-S: <a xmlns='urn:xmpp:sm:1' h='1'>
+S: <a xmlns='urn:xmpp:sm:2' h='1'>
  ]]></example>
  <p>When an &lt;r/&gt; element ("request") is received, the recipient MUST acknowledge it by sending an ack element (either &lt;a/&gt; or &lt;r/&gt;) to the sender. The sender does not have to wait for an ack to continue sending stanzas. The response MUST contain 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. 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>
@ -222,14 +213,14 @@ S: <a xmlns='urn:xmpp:sm:1' h='1'>
  <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>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>
  <example caption='Client enables stream management'><![CDATA[
-C: <enable xmlns='urn:xmpp:sm:1' resume='true'/>
+C: <enable xmlns='urn:xmpp:sm:2' resume='true'/>
  ]]></example>
  <p>If the receiving entity will allow the stream to be resumed, it MUST include a 'resume' attribute set to "true" or "1" on the &lt;enabled/&gt; element and MUST include an 'id' attribute that specifies an identifier for the stream.</p>
  <example caption='Server allows stream resumption'><![CDATA[
-S: <enabled xmlns='urn:xmpp:sm:1' id='some-long-sm-id' resume='true'/>
+S: <enabled xmlns='urn:xmpp:sm:2' 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 (as long as the receiving entity is available). The SM-ID SHOULD NOT be longer than 4000 bytes.</p>
-  <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 envisioned to be as follows:</p>
+  <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>Initiating entity sends initial stream header.</li>
    <li>Receiving entity sends response stream header.</li>
@ -246,13 +237,13 @@ S: <enabled xmlns='urn:xmpp:sm:1' id='some-long-sm-id' resume='true'/>
    <li>Receiving entity sends stream features, offering the SM feature.</li>
    <li>Initiating entity requests resumption of the former stream.</li>
  </ol>
-  <p>To request resumption of the former stream, the initiating entity sends a &lt;resume/&gt; element qualified by the 'urn:xmpp:sm:1' 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>
+  <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:1' previd='some-long-sm-id' h='some-sequence-number'/>
+C: <resume xmlns='urn:xmpp:sm:2' previd='some-long-sm-id' h='some-sequence-number'/>
  ]]></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:1' previd='some-long-sm-id' h='another-sequence-number'/>
+S: <resumed xmlns='urn:xmpp:sm:2' previd='some-long-sm-id' h='another-sequence-number'/>
  ]]></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 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>
@ -261,18 +252,22 @@ S: <resumed xmlns='urn:xmpp:sm:1' previd='some-long-sm-id' h='another-sequence-n
    <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>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>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>
 </section1>
 <section1 topic='Throttling' anchor='throttling'>
  <p>When a server acts as a receiving entity for an XML stream, it might throttle the stream (i.e., impose rate limiting) if the initiating entity (a client or a server) attempts to send too much traffic over the stream (e.g., a very large number of stanzas, or a lesser number of stanzas that are relatively large). The formulas for determining when rate limiting shall be imposed are implementation-specific; however, nearly all XMPP server implementations include support for such throttling (often called "karma"). Therefore it would be helpful if the receiving entity could inform the initiating entity that the stream has been voluntarily throttled by the receiving entity. <note>Some forms of "throttling" can occur naturally at the TCP layer without being voluntarily imposed by the receiving entity; the receiving entity cannot inform the initiating entity about such throttling.</note> It can do so by sending a &lt;t/&gt; element to the receiving entity:</p>
  <example caption='Throttling notification'><![CDATA[
-S: <t xmlns='urn:xmpp:sm:1'/>
+S: <t xmlns='urn:xmpp:sm:2'/>
  ]]></example>
-  <p>The throttling notification MAY include a 'stanzas' attribute so that the receiving entity can inform the initiating entity of changes to the maximum number of stanzas between acks. This enables a server to dynamically adjust stanza acking in response to network conditions or stream usage.</p>
+  <p>Note: Sending a throttling notification to the stream peer does not necessarily indicate that the entity is throwing away all stanzas, only that the entity has voluntarily slowed its processing of incoming stanzas.</p>
  <p>The throttling notification MAY include a 'stanzas' attribute so that the receiving entity can inform the initiating entity of changes to the maximum number of stanzas between acks. This enables the receiving entity to dynamically adjust stanza acking in response to network conditions or stream usage.</p>
  <example caption='Throttling notification with acking adjustment'><![CDATA[
-S: <t xmlns='urn:xmpp:sm:1' stanzas='5'/>
+S: <n 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 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>
@ -280,7 +275,7 @@ S: <t xmlns='urn:xmpp:sm:1' stanzas='5'/>
  <p>If an error occurs with regard to an &lt;enable/&gt; or &lt;resume/&gt; element, the receiving entity MUST return a &lt;failed/&gt; element. This element SHOULD contain an error condition, which MUST be one of the stanza error conditions defined in &rfc3920bis;.</p>
  <p>An example follows.</p>
  <example caption='Server returns error'><![CDATA[
-S: <failed xmlns='urn:xmpp:sm:1'>
+S: <failed xmlns='urn:xmpp:sm:2'>
     <unexpected-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
   </failed>
  ]]></example>
@ -299,14 +294,14 @@ S: <failed xmlns='urn:xmpp:sm:1'>
      <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>
-    <p>The following examples illustrate basic acking.</p>
+    <p>The following examples illustrate basic acking (here the client automatically acks each stanza it has received from the server, without first being prompted via an &lt;r/&gt; element).</p>
    <p>First, after authentication and resource binding, the client enables stream management.</p>
    <example caption='Client enables stream management'><![CDATA[
-C: <enable xmlns='urn:xmpp:sm:1'/>
+C: <enable xmlns='urn:xmpp:sm:2'/>
    ]]></example>
    <p>The server then enables stream management.</p>
  <example caption='Server enables stream management'><![CDATA[
-S: <enabled xmlns='urn:xmpp:sm:1'/>
+S: <enabled xmlns='urn:xmpp:sm:2'/>
    ]]></example>
    <p>The client then retrieves its roster and immediately sends an &lt;r/&gt; element to request acknowledgement.</p>
    <example caption='Client sends a stanza and requests acknowledgement'><![CDATA[
@ -314,10 +309,12 @@ C: <iq id='ls72g593' type='get'>
     <query xmlns='jabber:iq:roster'/>
   </iq>
-C: <r xmlns='urn:xmpp:sm:1'/>
+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>
-    <example caption='Server sends a stanza and acknowledges handling of client stanza'><![CDATA[
+    <example caption='Server acknowledges handling of client stanza and sends a stanza'><![CDATA[
 S: <a xmlns='urn:xmpp:sm:2' h='1'/>
 S: <iq id='ls72g593' type='result'>
     <query xmlns='jabber:iq:roster'>
       <item jid='juliet@capulet.lit'/>
@ -325,31 +322,34 @@ S: <iq id='ls72g593' type='result'>
     </query>
   </iq>
 S: <a xmlns='urn:xmpp:sm:1' h='1'/>
    ]]></example>
-    <p>The client then sends initial presence and immediately sends an &lt;r/&gt; element to request acknowledgement, incrementing by one its internal representation of how many stanzas have been handled by the server.</p>
+    <p>The client then acknowledges receipt of the server's stanza, sends initial presence, and immediately sends an &lt;r/&gt; element to request acknowledgement, incrementing by one its internal representation of how many stanzas have been handled by the server.</p>
    <example caption='Client sends a stanza and requests acknowledgement'><![CDATA[
 C: <a xmlns='urn:xmpp:sm:2' h='1'/>
 C: <presence/>
-C: <r xmlns='urn:xmpp:sm:1'/>
+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>
-    <example caption='Server sends a stanza and acknowledges handling of client stanza'><![CDATA[
+    <example caption='Server acknowledges handling of client stanza and sends a stanza'><![CDATA[
-S: <presence from='romeo@montague.lit/orchard' to='romeo@montague.lit/orchard'/>
+S: <a xmlns='urn:xmpp:sm:2' h='2'/>
-S: <a xmlns='urn:xmpp:sm:1' h='2'/>
+S: <presence from='romeo@montague.lit/orchard' to='romeo@montague.lit/orchard'/>
    ]]></example>
-    <p>The client then sends an outbound message and an &lt;r/&gt; element.</p>
+    <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[
 C: <a xmlns='urn:xmpp:sm:2' h='2'/>
 C: <message to='juliet@capulet.lit'>
     <body>ciao!</body>
   </message>
-C: <r xmlns='urn:xmpp:sm:1'/>
+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>
    <example caption='Server acknowledges handling of the stanza'><![CDATA[
-S: <a xmlns='urn:xmpp:sm:1' h='3'/>
+S: <a xmlns='urn:xmpp:sm:2' h='3'/>
    ]]></example>
    <p>And so on.</p>
  </section2>
@ -377,42 +377,45 @@ S: <a h='5'/>
  </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 few 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 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>
    <example caption='A session with throttling'><![CDATA[
 C: <enable/>
-S: <enabled stanzas='5'/>
+S: <enabled stanzas='10'/>
 C: <message/>
 C: <message/>
 C: <message/>
 [throttling kicks in]
-S: <t stanzas='2'/>
+S: <t stanzas='3'/>
-[client adjusts its expectations and requests an ack]
+[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/>
 C: <message/>
 [backlog starts to ease, server adjusts 'stanzas' value]
-S: <t stanzas='3'/>
+S: <t stanzas='5'/>
 [client sends another message just because it can]
 C: <message/>
-[server has handled the first 5 messages so it finally replies to <r/>]
+[server has handled the first 3 messages so it finally replies to <r/>]
-S: <a h='5'/>
+S: <a h='3'/>
 C: <message/>
 C: <message/>
 C: <message/>
-[client has sent 3 messages so requests an ack]
+C: <message/>
 [client has sent 5 messages so requests an ack]
 C: <r/>
-[throttling is over, server replies to <r/> and sets 'stanzas' back to 5]
+[throttling is over, server replies to 2nd <r/> and sets 'stanzas' back to 10]
-S: <a h='8' stanzas='5'/>
+S: <a h='8'/>
 S: <t stanzas='10'/>
    ]]></example>
  </section2>
 </section1>
 <section1 topic='Security Considerations' anchor='security'>
-  <p>To follow.</p>
+  <p>Intermediate proxies MUST pass through all stanzas, else the parties will go out of sync.</p>
 </section1>
 <section1 topic='IANA Considerations' anchor='iana'>
@ -423,7 +426,7 @@ S: <a h='8' stanzas='5'/>
  <section2 topic='Protocol Namespaces' anchor='registrar-ns'>
    <p>This specification defines the following XML namespace:</p>
    <ul>
-      <li>urn:xmpp:sm:1</li>
+      <li>urn:xmpp:sm:2</li>
    </ul>
    <p>Upon advancement of this specification from a status of Experimental to a status of Draft, the &REGISTRAR; shall add the foregoing namespaces to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.</p>
  </section2>
@ -431,7 +434,7 @@ S: <a h='8' stanzas='5'/>
    &NSVER;
  </section2>
  <section2 topic='Stream Features' anchor='registrar-stream'>
-    <p>Upon approval of this specification, the XMPP Registrar shall add 'urn:xmpp:sm:1:feature' to its registry of stream features.</p>
+    <p>Upon approval of this specification, the XMPP Registrar shall add 'urn:xmpp:sm:2:feature' to its registry of stream features.</p>
  </section2>
 </section1>
@ -441,8 +444,8 @@ S: <a h='8' stanzas='5'/>
 <xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
-    targetNamespace='urn:xmpp:sm:1'
+    targetNamespace='urn:xmpp:sm:2'
-    xmlns='urn:xmpp:sm:1'
+    xmlns='urn:xmpp:sm:2'
    elementFormDefault='qualified'>
  <xs:element name='a' type='ackElementType'/>
@ -451,10 +454,16 @@ S: <a h='8' stanzas='5'/>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='empty'>
          <xs:attribute name='max' 
                        type='xs:positiveInteger' 
                        use='optional'/>
          <xs:attribute name='resume' 
                        type='xs:boolean'
                        use='optional'
                        default='false'/>
          <xs:attribute name='stanzas' 
                        type='xs:unsignedShort' 
                        use='optional'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
@ -467,10 +476,16 @@ S: <a h='8' stanzas='5'/>
          <xs:attribute name='id' 
                        type='xs:string'
                        use='optional'/>
          <xs:attribute name='max' 
                        type='xs:positiveInteger' 
                        use='optional'/>
          <xs:attribute name='resume' 
                        type='xs:boolean'
                        use='optional'
                        default='false'/>
          <xs:attribute name='stanzas' 
                        type='xs:unsignedShort' 
                        use='optional'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
@ -497,12 +512,6 @@ S: <a h='8' stanzas='5'/>
          <xs:attribute name='id' 
                        type='xs:string' 
                        use='required'/>
          <xs:attribute name='max' 
                        type='xs:positiveInteger' 
                        use='optional'/>
          <xs:attribute name='stanzas' 
                        type='xs:unsignedShort' 
                        use='optional'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
@ -526,9 +535,6 @@ S: <a h='8' stanzas='5'/>
        <xs:attribute name='h' 
                      type='xs:integer' 
                      use='optional'/>
          <xs:attribute name='stanzas' 
                        type='xs:unsignedShort' 
                        use='optional'/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
@ -557,7 +563,7 @@ S: <a h='8' stanzas='5'/>
 </section1>
 <section1 topic='Acknowledgements' anchor='ack'>
-  <p>Thanks to Dave Cridland, Philipp Hancke, Curtis King, Tobias Markmann, Pedro Melo, Robin Redeker, and Mickaël Rémond for their feedback.</p>
+  <p>Thanks to Dave Cridland, Jack Erwin, Philipp Hancke, Curtis King, Tobias Markmann, Pedro Melo, Robin Redeker, and Mickaël Rémond for their feedback.</p>
 </section1>
 </xep>