diff --git a/xep-0220.xml b/xep-0220.xml
index 08407e2f..7ed49e6f 100644
--- a/xep-0220.xml
+++ b/xep-0220.xml
@@ -27,6 +27,12 @@
Modified stream features to incorporate versioning, thus removing the need for an <errors/> child element; clarified a few points in the text. 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. 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 RFC 6120. 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. 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 Dialback with Error Handling. 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. 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. In addition to the values "valid" and "invalid", the 'type' attribute can also have a value of "error"; see Dialback with Error Handling for a detailed explanation.
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.
Note: The Receiving Server MUST continue to accept and process stanzas for already verified domain pairs, and MUST continue to process both <db:result/> and <db:verify/> elements.
-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 RFC 6120, since the stream might already be used for sending XML stanzas for other domain pairs.
+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.2, is not a stream error and therefore MUST NOT result in closing of the stream as described in Section 4.4 of RFC 6120, since the stream might already be used for sending XML stanzas for other domain pairs.
Support for the server dialback protocol is indicated by inclusion of the dialback namespace declaration in the stream header.
+Support for the traditional server dialback protocol (originally specified in RFC 3920) is indicated by inclusion of the dialback namespace declaration in the stream header.
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 <dialback/> element qualified by the 'urn:xmpp:features:dialback' namespace, including an empty <errors/> element.
+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 <dialback/> element qualified by the 'urn:xmpp:features:dialback:1' namespace.
RFC 3920 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".
-This usage of the 'error' value for the 'type' attribute is not fully backward compatible with RFC 3920. 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 <remote-server-not-found/> error to the Originating Server.
+RFC 3920 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".
+This usage of the 'error' value for the 'type' attribute is not fully backward compatible with RFC 3920. 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 <remote-server-not-found/> error to the Originating Server.
When the <db:verify/> or <db:result/> element is of type "error", the element MUST contain an <error/> element, which is similar to a "stanza error" as specified in &xmppcore;. This specification re-uses the following stanza error conditions.