moved some text to forthcoming federation spec

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1593 4b5297f7-1745-476d-ba37-a9c6900126ab

xep-0220.xml

@@ -43,37 +43,8 @@
 </header>
 
 <section1 topic="Introduction" anchor="intro">
-  <section2 topic="Motivation" anchor="motivation">
-    <p>The client-server model used by Jabber/XMPP technologies makes it desirable to enable communication among servers. Such server-to-server or inter-domain communication is often called "federation". There are three main models for federation:</p>
-    <table caption='Federation Models'>
-      <tr>
-        <th>Model</th>
-        <th>Definition</th>
-        <th>Comments</th>
-        <th>Status</th>
-      </tr>
-      <tr>
-        <td>Promiscuous</td>
-        <td>Accept a connection from any peer, even without verification or authentication of the peer's identity</td>
-        <td>Lack of peer verification or authentication means that domains can be spoofed</td>
-        <td>Promiscuous federation has not been allowed on the Jabber network since the release of the jabberd 1.2 server in October 2000</td>
-      </tr>
-      <tr>
-        <td>Verified</td>
-        <td>Accept a connection only after the peer's identity has been verified via DNS-based mechanisms, specifically server dialback</td>
-        <td>The use of identity verification effectively prevents domain spoofing, but federation requires proper DNS setup and is still subject to DNS poisoning attacks</td>
-        <td>Verified federation has been standard practice on the Jabber network since October 2000</td>
-      </tr>
-      <tr>
-        <td>Trusted</td>
-        <td>Accept a connection only if the peer presents a certificate issued by a certification authority (CA) that is a trusted root according to the accepting domain (or, less commonly, if the peers have previously exchanged keys out of band)</td>
-        <td>The use of trusted domain certificates effectively prevents DNS poisoning attacks but makes federation more difficult since typically such certificates are not easy to obtain</td>
-        <td>Trusted federation has been possible since the definition of XMPP 1.0 (including TLS and SASL) in 2004 but is not yet common on the Jabber network because certificates are not widely available; typically, deployed Jabber services accept a mix of verified and trusted federation</td>
-      </tr>
-    </table>
-    <p>This document defines server dialback, a native Jabber protocol for peer identity verification that results in verified (but not trusted) federation between Jabber/XMPP servers.</p>
-  </section2>
-  <p>Server dialback, formerly documented in &rfc3920; but now canonically documented in this specification, is a weak identify verification method that is made possible by the existence of the Domain Name System (DNS), since one server can (normally) discover the authoritative server for a given domain.  Dialback is a native XMPP method that occurs over XML streams, with the result that it is more difficult to spoof XMPP server domains and XML stanzas sent over XML streams between servers.</p>
+  <p>The client-server architecture used by Jabber/XMPP technologies makes it desirable to enable communication among servers. Such server-to-server or inter-domain communication is often called "federation". This document defines server dialback, a native Jabber protocol for federation with weak identity verification between Jabber/XMPP servers.</p>
+  <p>Server dialback, which was formerly documented in &rfc3920; but now is canonically documented in this specification, is a weak identify verification method that is made possible by the existence of the Domain Name System (DNS), since one server can (normally) discover the authoritative server for a given domain.  Dialback is a native XMPP method that occurs over XML streams, with the result that it is more difficult to spoof XMPP server domains and XML stanzas sent over XML streams between servers.</p>
   <p>Server dialback is not a security mechanism, and results only in weak verification of server identities.  Domains requiring robust security SHOULD use TLS and SASL.  If SASL is used for server-to-server authentication, dialback SHOULD NOT be used since it is unnecessary.  However, depending on local policies, a service may wish to use dialback to provide weak identity verification in cases where SASL negotiation would not result in strong authentication (e.g., because the certificate presented by the peer service during TLS negotiation is self-signed and thus provides even weaker identity verification than DNS).</p>
   <p>Server dialback is uni-directional, and results in weak identity verification for one stream in one direction.  Because server dialback is not an authentication mechanism, mutual authentication is not possible via dialback.  Therefore, server dialback MUST be completed in each direction in order to enable bi-directional communications between two domains.</p>
   <p>The method for generating and verifying the keys used in server dialback MUST take into account the hostnames being used, the stream ID generated by the receiving server, and a secret known by the authoritative server's network; see <link url='#generation'>Dialback Key Generation</link>.</p>
@@ -228,7 +199,7 @@ A2R: <stream:features>
 
   <section2 topic='Verification Request' anchor='proto-verify'>
     <p>The Receiving Server sends the Authoritative Server a request for verification of a key:</p>
-    <example caption="Stream Header"><![CDATA[
+    <example caption="Verification Request"><![CDATA[
 R2A: <db:verify
          from='xmpp.example.com'
          id='D60000229F'