From e95d88f598c4ccc28ea1c492d2df2fb188dc80ac Mon Sep 17 00:00:00 2001 From: "Matthew A. Miller" Date: Thu, 19 Jun 2014 20:55:22 -0600 Subject: [PATCH] XEP-0220 v1.1rc2: see revision log --- xep-0220.xml | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-) diff --git a/xep-0220.xml b/xep-0220.xml index 37af07cf..68868ffd 100644 --- a/xep-0220.xml +++ b/xep-0220.xml @@ -11,7 +11,6 @@ &LEGALNOTICE; 0220 Draft - Standards Track Standards Council @@ -28,10 +27,16 @@ &stpeter; &fippo; - 1.1rc1 - 2014-05-28 - ph -

Added resource-constraint dialback error condition.

 + 1.1rc2 + 2014-06-18 + ph/psa + +
    +
  • Added resource-constraint dialback error condition.
    • +
  • Provided guidance on the usage of the <failed/> dialback error.
    • +
  • Clarified that the dialback error conditions table is not exhaustive and any stanza error condition can be used.
    • +
+ 1.0 @@ -521,7 +526,7 @@ send: ]]> -

If the type is "invalid", the Initiating Server is attempting to spoof the Sender Domain. The Receiving Server MUST NOT accept stanzas from the Initiating Server for the Sender Domain, ought to log the attempt, and MUST close the XML stream.

+

If the result is "invalid", the Initiating Server is either attempting to spoof the Sender Domain, or misconfigured. The Receiving Server MUST NOT accept stanzas from the Initiating Server for the Sender Domain and ought to log the attempt. If no other valid domain pairs exist for this connection (ie, if this is the first attempt), the Receiving Server SHOULD send a result with type "invalid" and MUST close the XML stream. If there exist other valid domain pairs for this connection, the Initiating Server might merely have a misconfiguration for the Sender Domain. In this case, the Receiving Server MAY return an error condition of <forbidden/> as described under Section 2.5 of this document.

@@ -612,7 +617,7 @@ send:

RFC 3920 introduced stream errors for any errors related to dialback. However, this turned out to be overly aggressive, particularly if the XML stream was used to multiplex stanzas for more than one domain pair (since closing the stream would result in throwing away accumulated dialback state for a potentially large number of domain pairs). Therefore this specification defines a third value for the 'type' attribute: "error".

This usage of the 'error' value for the 'type' attribute is not fully backward compatible with RFC 3920. However, the server that generates the error SHOULD still attempt to send the dialback error instead of terminating the stream, as the worst thing that can happen is that the remote server terminates the stream if it does not understand the error or if it eventually times out the connection. Dialback errors are to be considered non-fatal for the XML stream, but the Initiating Server MUST return queued stanzas to the respective senders with a &timeout; stanza error. If an error is encountered in Step 3 of the dialback negotiation, the Receiving Server MUST send a <remote-server-not-found/> dialback error to the Initiating Server.

-

When the <db:verify/> or <db:result/> element is of type "error", the element MUST contain an <error/> element (implicitly qualified by the 'jabber:server' namespace), which MUST in turn contain an XML element qualified by the 'urn:ietf:params:xml:ns:xmpp-stanzas' namespace (i.e., a stanza error condition), in accordance with the following table.

+

When the <db:verify/> or <db:result/> element is of type "error", the element MUST contain an <error/> element (implicitly qualified by the 'jabber:server' namespace), which MUST in turn contain an XML element qualified by the 'urn:ietf:params:xml:ns:xmpp-stanzas' namespace (i.e., a stanza error condition) as those errors are defined in RFC 6120. The following table provides additional guidance regarding the most relevant stanza error conditions:

Condition