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

typo 

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1628 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2008-01-30 21:32:25 +00:00
parent 80fde9ae41
commit 6d2593a4e4
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
xep-0220.xml
View File

@ -336,7 +336,7 @@ that is,
<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>
</ol>
<p>The former method is preferred, but the latter method is also specified herein for the purpose of backward-compatibility with older "XMPP 0.9" deployments.</p>
<p>The former method is preferred, but the latter method is also specified herein for the purpose of backwards-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 &lt;dialback/&gt; element MAY also include an empty &lt;required/&gt; element, indicating that the entity sending the stream features requires dialback to be negotiated for the stream.</p>
<example caption="Stream Features"><![CDATA[
<stream:features>
@ -354,7 +354,7 @@ that is,
from='example.com'
to='example.net'>
]]></example>
<p>No matter which method is used, a service SHOULD advertise support for server dialback only at a point in the stream negotiation when it will accept negotiation of server dialback for that stream. For example, if a service wishes to be backward-compatible with older "XMPP 0.9" deployments, it SHOULD include the server dialback namespace declaration in the initial stream header it sends to other servers (so that "XMPP 0.9" servers can proceed with dialback in the absence of TLS and SASL authentication). However, in the midst of stream negotiation with an XMPP 1.0 or higher server, a service SHOULD advertise the dialback stream feature only at a point when negotiation of server dialback is allowed in accordance with local service policies (e.g., after TLS negotiation in the case when a self-signed certificate was presented by the Originating Server and local service policies stipulate that it is preferable to weakly identify the Originating Server via server dialback rather than depend on the self-signed certificate for identity verification).</p>
<p>No matter which method is used, a service SHOULD advertise support for server dialback only at a point in the stream negotiation when it will accept negotiation of server dialback for that stream. For example, if a service wishes to be backwards-compatible with older "XMPP 0.9" deployments, it SHOULD include the server dialback namespace declaration in the initial stream header it sends to other servers (so that "XMPP 0.9" servers can proceed with dialback in the absence of TLS and SASL authentication). However, in the midst of stream negotiation with an XMPP 1.0 or higher server, a service SHOULD advertise the dialback stream feature only at a point when negotiation of server dialback is allowed in accordance with local service policies (e.g., after TLS negotiation in the case when a self-signed certificate was presented by the Originating Server and local service policies stipulate that it is preferable to weakly identify the Originating Server via server dialback rather than depend on the self-signed certificate for identity verification).</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>