diff --git a/xep-0060.xml b/xep-0060.xml
index ea4da943..5b10c356 100644
--- a/xep-0060.xml
+++ b/xep-0060.xml
@@ -51,8 +51,8 @@
   &ralphm;
 
   <revision>
-    <version>1.13rc16</version>
-    <date>in progress, last updated 2010-04-07</date>
+    <version>1.13rc17</version>
+    <date>in progress, last updated 2010-04-13</date>
     <initials>psa</initials>
     <remark>
       <ul>
@@ -78,6 +78,7 @@
         <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>
+        <li>Removed informational mapping of node meta-data to Dublin Core.</li>
       </ul>
     </remark>
   </revision>
@@ -460,7 +461,8 @@ And by opposing end them?
     <di><dt>Payload</dt><dd>The XML data that is contained within the &lt;item/&gt; element of a publication request or an event notification. A given payload is defined by an XML namespace and associated schema. A document that defines a payload format SHOULD specify whether the payload can be used only for a NodeID whose value is the same as the XML namespace, or whether the payload can be used for any NodeID. Such a document also SHOULD specify whether it is suggested that node at which such payloads are published are best configured as <link url='#impl-singleton'>Singleton Nodes</link>.</dd></di>
     <di><dt>Personal Eventing</dt><dd>A simplified subset of Publish-Subscribe for use in the context of instant messaging and presence applications, whereby each IM user's JID is a virtual pubsub service; for details, see &xep0163;.</dd></di>
     <di><dt>Presence Access Model</dt><dd>A node access model under which any entity that is subscribed to the owner's presence with a subscription of type "from" or "both" (see &rfc3921;) may subscribe to the node and retrieve items from the node; this access model applies mainly to instant messaging systems.</dd></di>
-    <di><dt>Publisher</dt><dd>An entity that is allowed to publish items to a node.</dd></di>
+    <di><dt>Publisher</dt><dd>An entity that is allowed to publish items to a node and that is automatically subscribed to the node.</dd></di>
+    <di><dt>Publish-Only</dt><dd>An entity that is allowed to publish items to a node but that is not allowed to receive notifications. (This affiliation is useful in the context of nodes that do not have an open access model when automated entities need to generate notifications on behalf of the owner.)</dd></di>
     <di><dt>Pubsub Service</dt><dd>An XMPP server or component that adheres to the protocol defined herein.</dd></di>
     <di><dt>Roster Access Model</dt><dd>A node access model under which any entity that is subscribed to the owner's presence and in the specified roster group(s) may subscribe to the node and retrieve items from the node; this access model applies mainly to instant messaging systems.</dd></di>
     <di><dt>Subscriber</dt><dd>An entity that is subscribed to a node.</dd></di>
@@ -536,7 +538,7 @@ And by opposing end them?
         <td>Publish-Only</td>
         <td>No</td>
         <td>No</td>
-        <td>Yes</td>
+        <td>No</td>
         <td>No *</td>
         <td>Yes</td>
         <td>No</td>
@@ -946,17 +948,6 @@ And by opposing end them?
     ]]></example>
     <p>Note: Node meta-data can be set in many ways. Some of it is based on node configuration (e.g., the owner's JID) whereas some of it may be dynamic (e.g., the number of subscribers). Any static information to be provided in the node meta-data SHOULD be provided as fields in the node configuration form.</p>
     <p>Note: The pubsub#language field SHOULD be list-single so that the pubsub service can present an appropriate list of languages and language codes.</p>
-    <p>Much of the meta-data provided about a node maps directly to selected &DUBLINCORE; meta-data attributes; specifically:</p>
-    <table caption='Dublin Core Metadata Mapping'>
-      <tr><th>Pubsub Field</th><th>Dublin Core Metadata Attribute</th></tr>
-      <tr><td>pubsub#creation_date</td><td>Date <note>The value SHOULD be a DateTime as defined in <cite>XEP-0082</cite>, and MUST conform to one of the profiles defined therein.</note></td></tr>
-      <tr><td>pubsub#creator</td><td>Creator</td></tr>
-      <tr><td>pubsub#description</td><td>Description</td></tr>
-      <tr><td>pubsub#language</td><td>Language</td></tr>
-      <tr><td>pubsub#publisher</td><td>Publisher</td></tr>
-      <tr><td>pubsub#title</td><td>Title</td></tr>
-      <tr><td>pubsub#type</td><td>Type <note>The pubsub type is the namespace that defines the payload (such as 'http://www.w3.org/2005/Atom'), if payloads are supported.</note></td></tr>
-    </table>
   </section2>
 
   <section2 topic='Discover Items for a Node' anchor='entity-discoveritems'>
@@ -3575,7 +3566,7 @@ And by opposing end them?
         ]]></example>
       </section4>
       <section4 topic='Success With Notifications' anchor='owner-configure-process-notify'>
-        <p>If the "pubsub#notify_config" option is set to true, the service MUST notify subscribes of the configuration change. (A service SHOULD support this option for leaf nodes and MUST support it for collection nodes as described in <cite>XEP-0248</cite>.) If the node configuration is set to notification-only, the notification MUST consist of an empty &lt;configuration/&gt; element whose 'node' attribute is set to the NodeID of the node; if the node configuration is set to full payloads, the &lt;configuration/&gt; element MUST in addition contain the node configuration as represented via the <strong>Data Forms</strong> protocol.</p>
+        <p>If the "pubsub#notify_config" option is set to true, the service MUST notify subscribers of the configuration change. (A service SHOULD support this option for leaf nodes and MUST support it for collection nodes as described in <cite>XEP-0248</cite>.) If the node configuration is set to notification-only, the notification MUST consist of an empty &lt;configuration/&gt; element whose 'node' attribute is set to the NodeID of the node; if the node configuration is set to full payloads, the &lt;configuration/&gt; element MUST in addition contain the node configuration as represented via the <strong>Data Forms</strong> protocol.</p>
         <example caption='Service sends configuration change notification (event notification only)'><![CDATA[
 <message from='pubsub.shakespeare.lit' to='francisco@denmark.lit' id='foo'>
   <event xmlns='http://jabber.org/protocol/pubsub#event'>