If the value of the 'type' attribute is "valid", then the connection between the domain pair is considered verified and the Originating Server can send any queued stanzas.
-If the value of the 'type' attribute is "invalid", this means that the Originating Server's identity (as valid for the Sender Domain) could not be verified by the Receiving Server. Queued stanzas MUST be bounced back to the respective senders with a <internal-server-error> stanza error and the underlying stream MAY be closed unless it is being used by other domain pairs. Note that the Receiving Server may choose to terminate the TCP connection.
+If the value of the 'type' attribute is "invalid", this means that the Originating Server's identity (as valid for the Sender Domain) could not be verified by the Receiving Server. Queued stanzas MUST be returned to the respective senders with a <internal-server-error> stanza error and the underlying stream MAY be closed unless it is being used by other domain pairs. Note that the Receiving Server may choose to terminate the TCP connection.
-If the value of the 'type' attribute is "error", this indicates a problem which is not related to the validity of the dialback key provided. The error conditions are explained in detail in section 2.4. Such an error is to be considered non-fatal for the XML stream, but queued stanzas MUST be bounced to the respective senders with a &timeout; stanza error.
+If the value of the 'type' attribute is "error", this indicates a problem which is not related to the validity of the dialback key provided. The error conditions are explained in detail in section 2.4. Such an error is to be considered non-fatal for the XML stream, but queued stanzas MUST be returned to the respective senders with a &timeout; stanza error.
The Originating Server then bounces any queued stanzas back to the respective senders, copying the error child.
RFC 3920 introduced stream errors for any errors related to dialback. However, this turned out to be overly aggressive, particulary if the XML stream was used to multiplex stanzas from more than one receiving domain. Therefore this specification introduces a third value for the 'type' attribute, with the value "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. Those dialback errors are to be considered non-fatal for the XML stream, but queued stanzas MUST be bounced to the respective senders with a &timeout; stanza error. If an error is encountered in step 3, the Receiving Server must send a <remote-server-not-found/> error to the Originating Server.
+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. Those dialback errors are to be considered non-fatal for the XML stream, but queued stanzas MUST be returned to the respective senders with a &timeout; stanza error. If an error is encountered in step 3, the Receiving Server must send a <remote-server-not-found/> error to the Originating Server.
When the <db:verify/> or <db:result/> element is of type "error", the element MUST contain an <error/> element, which is similar to a "stanza error" as specified in &xmppcore;. This specification re-uses the following stanza error conditions.