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

0.10

This commit is contained in:
stpeter 2011-05-16 17:55:09 -06:00
parent 0fc34a142d
commit ff4fd12c8e
1 changed files with 28 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
xep-0220.xml
View File

@ -27,6 +27,12 @@
<surname>Hancke</surname>
<jid>fippo@psyced.org</jid>
</author>
<revision>
<version>0.10</version>
<date>2011-05-16</date>
<initials>psa</initials>
<remark><p>Modified stream features to incorporate versioning, thus removing the need for an &lt;errors/&gt; child element; clarified a few points in the text.</p></remark>
</revision>
<revision>
<version>0.9</version>
<date>2011-04-25</date>
@ -250,7 +256,7 @@ recv: <db:result
]]></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 outbound stanzas it has queued up for routing to the Receiving Server for the domain pair.</p>
<p>If the value of the 'type' attribute is "invalid", then the Receiving Server is reporting that Originating Server's identity (as valid for the Sender Domain) could not be verified by the Authoritative Server. In this case, the Originating Server MUST NOT attempt to send any outbound stanzas it has queued up for routing to the Receiving Server for the domain pair. In addition, the Receiving Server MUST close the stream as described in Section 4.4 of <cite>RFC 6120</cite>.</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 the Originating Server MUST return any queued stanzas to the respective senders at the Sender Domain 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 under <link url='#advertisement-errors'>Dialback with Error Handling</link>. Such an error is to be considered non-fatal for the XML stream, but the Originating Server MUST return any queued stanzas to the respective senders at the Sender Domain 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'
@ -295,7 +301,7 @@ recv: <db:verify
type='invalid'>
</db:verify>
]]></example>
<p>In addition to the values "valid" and "invalid", the 'type' attribute can also have a value of "error"; see Section 2.4 for a detailed explanation.</p>
<p>In addition to the values "valid" and "invalid", the 'type' attribute can also have a value of "error"; see <link url='#advertisement-errors'>Dialback with Error Handling</link> for a detailed explanation.</p>
<example caption="Receiving Server Receives Dialback Error from Authoritative Server (Step 3)"><![CDATA[
recv: <db:verify
from='sender.tld'
@ -328,7 +334,7 @@ recv: <db:result
<p>This key MUST be verified before the Originating Server is authorized to send stanzas from the Sender Domain ('sender.tld'). The verification process might fail prematurely, for example, if the Receiving Server's policy states that connections from the Originating Server or the Sender Domain are not allowed.</p>
<p>The usual method for verifying that the Originating Server is authorized to send stanzas for the Sender Domain is to "dial back" the Authoritative Server for the Sender Domain and ask it to validate the dialback key which is contained in the XML character data of the request. Other methods can be used for verifying the identity of the Originating Server, but are out of scope for this document.</p>
<p>Note: The Receiving Server MUST continue to accept and process stanzas for already verified domain pairs, and MUST continue to process both &lt;db:result/&gt; and &lt;db:verify/&gt; elements.</p>
<p>If the Target Domain as given in the 'to' attribute of the element is not a configured domain of the Receiving Server, this results in a dialback error. This error, which is explained further under Section 2.4, is not a stream error and therefore MUST NOT result in closing of the stream as described in Section 4.4 of <cite>RFC 6120</cite>, since the stream might already be used for sending XML stanzas for other domain pairs.</p>
<p>If the Target Domain as given in the 'to' attribute of the element is not a configured domain of the Receiving Server, this results in a dialback error. This error, which is explained further under <link url='#advertisement-errors'>Section 2.4.2</link>, is not a stream error and therefore MUST NOT result in closing of the stream as described in Section 4.4 of <cite>RFC 6120</cite>, since the stream might already be used for sending XML stanzas for other domain pairs.</p>
<example caption="Receiving Server Sends Dialback Error to Originating Server (Step 4)"><![CDATA[
send: <db:result
from='target.tld'
@ -416,8 +422,8 @@ send: <db:verify
<section2 topic="Advertisement" anchor='advertisement'>
<section3 topic="Protocol Support" anchor='advertisement-protocol'>
<p>Support for the server dialback protocol is indicated by inclusion of the dialback namespace declaration in the stream header.</p>
<section3 topic="Traditional Dialback" anchor='advertisement-traditional'>
<p>Support for the traditional server dialback protocol (originally specified in <cite>RFC 3920</cite>) is indicated by inclusion of the dialback namespace declaration in the stream header.</p>
<example caption="Stream Header"><![CDATA[
<stream:stream
xmlns='jabber:server'
@ -429,13 +435,11 @@ send: <db:verify
<p>Although this method of advertising protocol support has been superseded by the use of stream features as originally defined in <cite>RFC 3920</cite>, the server dialback protocol predates the existence of stream features and therefore the namespace declaration method is still used in this instance.</p>
</section3>
<section3 topic="Error Handling" anchor='advertisement-errors'>
<p>If a server supports graceful handling of dialback errors as described under Section 2.4, it MUST advertise that via a stream feature which is a &lt;dialback/&gt; element qualified by the 'urn:xmpp:features:dialback' namespace, including an empty &lt;errors/&gt; element.</p>
<section3 topic="Dialback with Error Handling" anchor='advertisement-errors'>
<p>If a server supports graceful handling of dialback errors as described under Section 2.5, it MUST advertise that though a stream feature which is a &lt;dialback/&gt; element qualified by the 'urn:xmpp:features:dialback:1' namespace.</p>
<example caption="Stream Features With &lt;errors/&gt; Element"><![CDATA[
<stream:features>
<dialback xmlns='urn:xmpp:features:dialback'>
<errors/>
</dialback>
<dialback xmlns='urn:xmpp:features:dialback:1'>
</stream:features>
]]></example>
</section3>
@ -443,8 +447,8 @@ send: <db:verify
<section2 topic="Dialback Error Conditions" anchor='errors'>
<!-- credits: Matthias in http://mail.jabber.org/pipermail/standards/2007-June/015662.html -->
<p><cite>RFC 3920</cite> 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 from more than one domain pair. 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 <cite>RFC 3920</cite>. 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. Furthermore, a server SHOULD send these errors only to XMPP 1.0 peers that advertise support for dialback errors as described under Section 2.3.2. 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><cite>RFC 3920</cite> 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 from 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 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 <cite>RFC 3920</cite>. 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. Furthermore, a server SHOULD send these errors only to XMPP 1.0 peers that advertise support for dialback errors as described under Section 2.3.2. 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>
@ -495,7 +499,7 @@ send: <db:verify
<section3 topic="Multiplexing Target Domains" anchor="targetpiggyback">
<p>Likewise, to send stanzas to rooms at "chat.target.tld" from addresses at "sender.tld", the Originating Server would initiate dialback negotiation with "chat.target.tld" on the same connection that might already be used to send stanzas from "sender.tld" to "target.tld", specifying the Target Domain as "chat.target.tld". Specifying different target domains is called "TARGET PIGGYBACKING".</p>
<p>The Originating Server SHOULD NOT use Target Piggybacking unless the Receiving Server has signalled support for dialback error handling via &lt;stream:features/&gt; as described under Section 2.3.2. The Originating Server MAY then attempt to multiplex a Sender Domain 'B' on the stream to the Receiving Server that is already used for Sender Domain 'A' if the hostname and port resolution results in the same IP address and port combination. For example:</p>
<p>The Originating Server SHOULD NOT use Target Piggybacking unless the Receiving Server has signalled support for dialback error handling via &lt;stream:features/&gt; as described under <link url='#advertisement-errors'>Dialback with Error Handling</link>. The Originating Server MAY then attempt to multiplex a Sender Domain 'B' on the stream to the Receiving Server that is already used for Sender Domain 'A' if the hostname and port resolution results in the same IP address and port combination. For example:</p>
<example caption="DNS SRV Record for the sender.tld Zone"><![CDATA[
_xmpp-server._tcp.target.tld. 86400 IN SRV 10 0 5269 receiver.target.tld
_xmpp-server._tcp.chat.target.tld. 86400 IN SRV 10 0 5269 receiver.target.tld
@ -520,11 +524,21 @@ receiver.target.tld. 86400 IN A 10.44.0.4
</section2>
<section2 topic='Stream Features' anchor='registrar-stream'>
<p>The XMPP Registrar includes 'urn:xmpp:features:dialback' in its registry of stream features (see &STREAMFEATURES;).</p>
<p>The submission is as follows:</p>
<code><![CDATA[
<feature>
<ns>urn:xmpp:features:dialback</ns>
<name>dialback</name>
<element>dialback</element>
<desc>Support for Server Dialback</desc>
<doc>XEP-0220</doc>
</feature>
]]></code>
</section2>
</section1>
<section1 topic='Acknowledgments' anchor='ack'>
<p>Thanks to Dave Cridland, Joe Hildebrand, Justin Karneges, Nina Kirchner, Carlo von Loesch, Ralph Meijer, Rob Norris, Dave Richards, Matthew Wild, and Matthias Wimmer for their comments.</p>
<p>Thanks to Dave Cridland, Jack Erwin, Joe Hildebrand, Justin Karneges, Nina Kirchner, Carlo von Loesch, Ralph Meijer, Chris Newton, Rob Norris, Tory Patnoe, Dave Richards, Matthew Wild, and Matthias Wimmer for their comments.</p>
</section1>
<section1 topic='XML Schema' anchor='schema'>