diff --git a/xep-0060.xml b/xep-0060.xml
index 7919e8ef..b2dd233d 100644
--- a/xep-0060.xml
+++ b/xep-0060.xml
@@ -51,8 +51,8 @@
   &ralphm;
 
   <revision>
-    <version>1.13rc13</version>
-    <date>in progress, 2009-12-07</date>
+    <version>1.13rc14</version>
+    <date>in progress, 2010-03-30</date>
     <initials>psa</initials>
     <remark>
       <ul>
@@ -65,6 +65,7 @@
         <li>Defined "room" value for itemreply config option.</li>
         <li>Added optional 'publisher' attribute to &lt;item/&gt; element.</li>
         <li>Added optional &lt;redirect/&gt; child to &lt;delete/&gt; element.</li>
+        <li>Based redirects on URIs for consistency with rfc3920bis gone and redirect errors.</li>
         <li>Clarified meaning of filtered notifications (they are based on NodeIDs, not payload namespaces).</li>
         <li>Added pubsub-on-a-jid service discovery feature for explicit discovery that an IM and presence account also functions as a virtual pubsub service.</li>
         <li>Added purge_offline node configuration option for purging the node when the relevant publisher goes offline, for use in certain extended presence applications.</li>
@@ -74,7 +75,6 @@
         <li>Clarified suggested rules for payload definitions.</li>
         <li>Mentioned that singleton pattern can be enforced by setting max_items to 1.</li>
         <li>Removed subids from subscription approval forms because subscribers can have only one unapproved subscription request per node at a given time.</li>
-        <li>Added optional support for delivery of notifications via XMPP IQ stanzas.</li>
         <li>Removed the notion of batch publishing because it makes information coherence and atom handling excessively difficult.</li>
         <li>Added error handling for too-many-subscriptions to help prevent a certain denial of service attack.</li>
         <li>Added process for retrieving default subscription configuration options for leaf nodes, by omitting the 'node' attribute on the &lt;default/&gt; element (also added the &lt;default/&gt; element to the schema for the http://jabber.org/protocol/pubsub namespace, since it was missing).</li>
@@ -3810,7 +3810,7 @@ And by opposing end them?
     id='delete1'>
   <pubsub xmlns='http://jabber.org/protocol/pubsub#owner'>
     <delete node='princely_musings'>
-      <redirect jid='hamlet@denmark.lit' node='blog'/>
+      <redirect uri='xmpp:hamlet@denmark.lit?;node=blog'/>
     </delete>
   </pubsub>
 </iq>
@@ -3827,13 +3827,17 @@ And by opposing end them?
       <example caption='Subscribers are notified of node deletion'><![CDATA[
 <message from='pubsub.shakespeare.lit' to='francisco@denmark.lit' id='foo'>
   <event xmlns='http://jabber.org/protocol/pubsub#event'>
-    <delete node='princely_musings'/>
+    <delete node='princely_musings'>
+      <redirect uri='xmpp:hamlet@denmark.lit?;node=blog'/>
+    </delete>
   </event>
 </message>
 
 <message from='pubsub.shakespeare.lit' to='bernardo@denmark.lit' id='bar'>
   <event xmlns='http://jabber.org/protocol/pubsub#event'>
-    <delete node='princely_musings'/>
+    <delete node='princely_musings'>
+      <redirect uri='xmpp:hamlet@denmark.lit?;node=blog'/>
+    </delete>
   </event>
 </message>
       ]]></example>
@@ -5233,30 +5237,6 @@ And by opposing end them?
     <p>Implementations of pubsub MAY deliver event notifications only when the subscriber is online. In these cases, the option may be a node configuration option as shown in the examples above. To facilitate this, the pubsub service needs to subscribe to the subscriber's presence and check the subscriber's current presence information before sending any event notifications (as described in <cite>RFC 3921</cite>). Presence subscriptions MUST be based on the subscribed JID.</p>
   </section2>
 
-  <section2 topic='IQ Notifications' anchor='impl-iqnotify'>
-    <p>If the pubsub service supports presence-based delivery and a node is configured to enable such delivery, the service MAY offer a value of "iq" for the "pubsub#notification_type" node configuration option. If this value is chosen, the service shall deliver notifications in XMPP IQ stanzas instead of in XMPP message stanzas. Because IQ stanzas are addressed to full JIDs &LOCALFULL;, if the service does not know the full JID of a given subscriber then it SHOULD NOT send an event notification at all (just as it would not for presence-based delivery via &MESSAGE; stanzas). The IQ stanza containing an event notification shall be of type "set", and in accordance with the semantics of the IQ stanza defined in <cite>RFC 3920</cite> the recipient MUST return either an IQ stanza of type "result" or an IQ stanza of type "error". An example follows.</p>
-    <example caption='Service Notifies Subscriber via IQ'><![CDATA[
-<iq from='pubsub.shakespeare.lit'
-    id='jc9jn253'
-    to='francisco@denmark.lit/barracks'
-    type='set'>
-  <event xmlns='http://jabber.org/protocol/pubsub#event'>
-    <items node='princely_musings'>
-      <item id='ae890ac52d0df67ed7cfdf51b644e901'>
-        [ ... ENTRY ... ]
-      </item>
-    </items>
-  </event>
-</iq>
-    ]]></example>
-    <example caption='Subscriber Indicates Success'><![CDATA[
-<iq from='francisco@denmark.lit/barracks'
-    id='jc9jn253'
-    to='pubsub.shakespeare.lit'
-    type='result'/>
-    ]]></example>
-  </section2>
-
   <section2 topic='Not Routing Events to Offline Storage' anchor='impl-offline'>
     <p>Sending events to users of existing Jabber servers may force event notifications to be routed to offline storage for later delivery (as described in &xep0160;). This may not always be desirable. The possible ways of preventing this behavior include:</p>
     <ul>
@@ -6257,9 +6237,6 @@ xmpp:pubsub.shakespeare.lit?pubsub;action=retrieve;node=princely_musings;item=ae
     <option label='Messages of type headline'>
       <value>headline</value>
     </option>
-    <option label='IQ stanzas (works only with presence-based delivery)'>
-      <value>iq</value>
-    </option>
   </field>
   <field var='pubsub#notify_config'
          type='boolean'