moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 08:45:04 -05:00
Code Issues Releases Wiki Activity

XEP-0198 v1.4rc1 (interim): Expressed how to handle duplicate enable requests; Noted the use of delay stamping in redelivery/offline messaging by servers.

Browse Source
This commit is contained in:
Matthew A. Miller 2015-07-28 08:43:55 -06:00
commit 7dc7ba4b66
1 changed files with 15 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
xep-0198.xml
View File

@ -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>