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

0.7

This commit is contained in:
stpeter 2011-04-14 11:18:55 -06:00
parent 2927387c61
commit 81509563ee
1 changed files with 22 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

40
xep-0220.xml
View File

@ -27,6 +27,12 @@
<surname>Hancke</surname>
<jid>fippo@psyced.org</jid>
</author>
<revision>
<version>0.7</version>
<date>2011-04-14</date>
<initials>ph/psa</initials>
<remark><p>Removed stream feature for advertising mere protocol support, using it only for advertising support for enhanced error handling.</p></remark>
</revision>
<revision>
<version>0.6</version>
<date>2011-04-13</date>
@ -391,30 +397,28 @@ send: <db:verify
</section2>
<section2 topic="Advertisement" anchor='advertisement'>
<p>Support for the server dialback protocol can be indicated in two ways:</p>
<ul>
<li>By inclusion of the server dialback feature in a given set of stream features.</li>
<li>By inclusion of the dialback namespace declaration in the stream header.</li>
</ul>
<p>The former method is preferred, and XMPP 1.0 servers MUST support and send the stream feature. However, the latter method is also specified herein for the purpose of backward-compatibility with older "XMPP 0.9" deployments.</p>
<p>The server dialback stream feature is advertised by including in any given set of stream features a &lt;dialback/&gt; element qualified by the 'urn:xmpp:features:dialback' namespace; the <dialback/> element MAY also include an empty &lt;errors/&gt; element, indicating that the entity sending the stream features supports graceful handling of dialback errors as described in Section 2.4.</p>
<example caption="Stream Features"><![CDATA[
<stream:features>
<dialback xmlns='urn:xmpp:features:dialback'>
<errors/>
</dialback>
</stream:features>
]]></example>
<p>Note: If the Sender Domain was authenticated using SASL, the &lt;dialback/&gt; element SHOULD NOT be present in stream features. If a server offers both SASL and dialback, dialback SHOULD be mandatory-to-negotiate and SASL SHOULD be voluntary-to-negotiate as those terms are described in <cite>RFC 6120</cite>.</p>
<p>As mentioned, support for the server dialback protocol can also be advertised by including the dialback namespace declaration in a stream header.</p>
<example caption="Stream Header"><![CDATA[
<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>
<example caption="Stream Header"><![CDATA[
<stream:stream
xmlns='jabber:server'
xmlns:db='jabber:server:dialback'
xmlns:stream='http://etherx.jabber.org/streams'
from='target.tld'
to='sender.tld'>
]]></example>
]]></example>
<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 in 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>
<example caption="Stream Features With &lt;errors/&gt; Element"><![CDATA[
<stream:features>
<dialback xmlns='urn:xmpp:features:dialback'>
<errors/>
</dialback>
</stream:features>
]]></example>
</section3>
</section2>
<section2 topic="Dialback Error Conditions" anchor='errors'>
<!-- credits: Matthias in http://mail.jabber.org/pipermail/standards/2007-June/015662.html -->