From e0b29fe060bf4056534bf16e2cf97cbcaeb2d3d1 Mon Sep 17 00:00:00 2001 From: Dave Cridland Date: Mon, 27 Jul 2015 22:48:59 +0100 Subject: [PATCH] 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 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 | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/xep-0198.xml b/xep-0198.xml index 8492c2b4..7dd8f2c9 100644 --- a/xep-0198.xml +++ b/xep-0198.xml @@ -28,6 +28,18 @@ &fabio; &dcridland; &mwild; + + + 1.4rc1 + 2015-07-27 + dc + +
    +
  • Expressed how to handle duplicate enable requests.
    • +
  • Noted the use of delay stamping in redelivery/offline messaging by servers.
    • +
+ + 1.3 2011-06-29 @@ -224,6 +236,8 @@ S: ]]> +

Note that a client SHALL only make at most one attempt to enable stream management. If a server receives a second <enable/> element it SHOULD respond with a stream error, thus terminating the client connection + .

@@ -278,7 +292,7 @@ S:

When a party receives an <a/> 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).

If a stream ends and it is not resumed within the time specified in the original <enabled/> 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):

    -
  • 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.
    • +
  • 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;).
  • 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.

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.