diff --git a/xep-0220.xml b/xep-0220.xml
index 05bcc167e..489bfbf69 100644
--- a/xep-0220.xml
+++ b/xep-0220.xml
@@ -7,7 +7,7 @@
 <xep>
 <header>
   <title>Server Dialback</title>
-  <abstract>This document provides documentation of the server dialback protocol.</abstract>
+  <abstract>This specification defines the server dialback protocol, which is used between XMPP servers to provide identity verification. Server dialback uses the Domain Name System (DNS) as the basis for verifying identity; the basic approach is that when a receiving server receives a server-to-server connection requesting from an originating server, it does not accept the request until it has verified a key with an authoritative server for the domain asserted by the originating server. Although server dialback does not provide strong authentication or trusted federation and although it is subject to DNS poisoning attacks, since its development in the year 2000 it has effectively prevented most instances of address spoofing on the XMPP network.</abstract>
   &LEGALNOTICE;
   <number>0220</number>
   <status>Experimental</status>
@@ -22,6 +22,12 @@
   <shortname>dialback</shortname>
   &stpeter;
   &jer;
+  <revision>
+    <version>0.2</version>
+    <date>2007-12-26</date>
+    <initials>psa</initials>
+    <remark><p>Separated sections into subsections, as has been done for xmppbis Internet-Drafts; explained and illustrated failure cases more completely; added motivating text about different federation models; added explanatory text about scenarios in which server dialback is used and not used.</p></remark>
+  </revision>
   <revision>
     <version>0.1</version>
     <date>2007-07-11</date>
@@ -37,6 +43,36 @@
 </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>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>