Minor clarifications to XEP-0198

Two things came up during community review of a patch to Openfire which are
not specified in the XEP. Both seem to be uncontentious, but will require
Council review, etc.

1) The specification makes no recommendation on what to do if the server
receives multiple <enable/> requests.

This is resolved in this instance by recommending (SHOULD, not MUST) that the
server generates a stream error, and stipulates that clients MUST NOT do this.

2) It was noted that redelivery attempts for stanzas require delay stamp
handling.

It is arguably not within this specification's remit to require this, however
it seems compelling that it be documented somewhere and this seems the best
place.

xep-0198.xml

@@ -28,6 +28,18 @@
   &fabio;
   &dcridland;
   &mwild;
+  <interim/>
+  <revision>
+    <version>1.4rc1</version>
+    <date>2015-07-27</date>
+    <initials>dc</initials>
+    <remark>
+      <ul>
+        <li>Expressed how to handle duplicate enable requests.</li>
+        <li>Noted the use of delay stamping in redelivery/offline messaging by servers.</li>
+      </ul>
+    </remark>
+  </revision>
   <revision>
     <version>1.3</version>
     <date>2011-06-29</date>
@@ -224,6 +236,8 @@ S: <failed xmlns='urn:xmpp:sm:3'>
      <unexpected-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
    </failed>
   ]]></example>
+  <p>Note that a client SHALL only make at most one attempt to enable stream management. If a server receives a second &lt;enable/> element it SHOULD respond with a stream error, thus terminating the client connection
+  .</p>
 </section1>
   
 <section1 topic='Acks' anchor='acking'>
@@ -278,7 +292,7 @@ S: <a xmlns='urn:xmpp:sm:3' h='1'/>
   <p>When a party receives an &lt;a/&gt; element, it SHOULD keep a record of the 'h' value returned as the sequence number of the last handled outbound stanza for the current stream (and discard the previous 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 received):</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 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, delivery to an alternate resource, or committing the stanza to offline storage. (Note that servers SHOULD add a delay element with the original (failed) delivery timestamp, as per &xep0203;).</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>