moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

s/bounce/returned/ 

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3335 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Philipp Hancke 2009-07-23 19:06:40 +00:00
parent c33637ce92
commit e6ba8bc9c0
1 changed files with 3 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
xep-0220.xml
View File

@ -216,10 +216,10 @@ recv: <db:result
type='invalid'/>
]]></example>
<p>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.</p>
<p>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 &lt;internal-server-error&gt; 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.</p>
<p>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 &lt;internal-server-error&gt; 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.</p>
<!-- bounce mark 1 -->
<!-- FIXME: is it valid to re-attempt validation on the same connection after it has failed? -->
<p>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.</p>
<p>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.</p>
<example caption="Originating Server Receives Dialback Error from Receiving Server (step 4)"><![CDATA[
recv: <db:result
from='target.tld'
@ -230,7 +230,6 @@ recv: <db:result
</error>
</db:result>
]]></example>
<p>The Originating Server then bounces any queued stanzas back to the respective senders, copying the error child.</p>
<!-- bounce mark 2 -->
</section3>
<section3 topic="Verify Request and Response">
@ -404,7 +403,7 @@ send: <db:verify
<section2 topic="Dialback Error Conditions" anchor='errors'>
<!-- credits: Matthias in http://mail.jabber.org/pipermail/standards/2007-June/015662.html -->
<p>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".</p>
<p>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 &lt;remote-server-not-found/&gt; error to the Originating Server.</p>
<p>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 &lt;remote-server-not-found/&gt; error to the Originating Server.</p>
<p>When the &lt;db:verify/&gt; or &lt;db:result/&gt; element is of type "error", the element MUST contain an &lt;error/&gt; element, which is similar to a "stanza error" as specified in &xmppcore;. This specification re-uses the following stanza error conditions.</p>
<table caption='Dialback error conditions'>
<tr>