1.2rc2

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

xep-0163.xml

@@ -26,6 +26,12 @@
   <shortname>pep</shortname>
   &stpeter;
   &ksmith;
+  <revision>
+    <version>1.2rc2</version>
+    <date>in progress, last updated 2009-04-17</date>
+    <initials>psa</initials>
+    <remark><p>Removed the one-node-per-namespace rule (community consensus that it is overly restrictive); clarified the meaning of auto-subscribe.</p></remark>
+  </revision>
   <revision>
     <version>1.1</version>
     <date>2007-09-26</date>
@@ -300,7 +306,6 @@
   <ol start='1'>
     <li>Every account a pubsub service.</li>
     <li>One publisher per node.</li>
-    <li>One node per namespace.</li>
     <li>Use presence.</li>
     <li>Filter notifications based on expressed interest.</li>
     <li>Smart defaults.</li>
@@ -312,9 +317,6 @@
   <section2 topic='One Publisher Per Node' anchor='approach-publisher'>
     <p>There is no need for multiple publishers to a PEP service, since by definition the service generates information associated with only one entity. The owner-publisher for every node is the bare JID of the account owner.</p>
   </section2>
-  <section2 topic='One Node Per Namespace' anchor='approach-onenode'>
-    <p>There is only one publish-subscribe node associated with any given payload type (XML namespace) for the account owner (e.g., there is one pubsub node for geolocation events, one node for tune events, and one node for mood events). This simplifies node creation, discovery, publishing, and subscribing.</p>
-  </section2>
   <section2 topic='Use Presence' anchor='approach-presence'>
     <p>Although generic publish-subscribe services do not necessarily have access to presence information about subscribers, PEP services are integrated with presence in the following ways:</p>
     <ul>
@@ -366,7 +368,7 @@
     <li>The entity is the account owner itself, in which case the PEP service shall send notifications to all of the account owner's available resources (subject to <link url='#notify-filter'>notification filtering</link>).</li>
   </ol>
   <section2 topic='Automatic Subscriptions' anchor='notify-autosubscribe'>
-    <p>A PEP service MUST support the "auto-subscribe" feature defined in Section 9.1 of <cite>XEP-0060</cite>. This implies that when a user has an XMPP presence subscription to the account owner's presence, the user automatically also has a pubsub subscription account owner's root collection node (i.e., bare JID), with a subscription_type of "items" and a subscription_depth of "all".</p>
+    <p>A PEP service MUST support the "auto-subscribe" feature defined in Section 9.1 of <cite>XEP-0060</cite>. This implies that when a user has an XMPP presence subscription to the account owner's presence, the user automatically also has the right to subscribe to any of the account owner's PEP nodes (if the access model is the default of "presence") and to retrieve items from such PEP nodes.</p>
   </section2>
   <section2 topic='Notification Filtering' anchor='notify-filterednotifications'>
     <p>A PEP service MUST support the "filtered-notifications" feature defined in Section 9.2 of <cite>XEP-0060</cite>. This implies that when an automatic subscriber can specify which event payloads it wants to receive by including appropriate feature bundles in the <cite>XEP-0115</cite> information it broadcasts.</p>
@@ -396,6 +398,7 @@
     </section3>
     <section3 topic='Sending the Last Published Item' anchor='notify-last'>
       <p>As mentioned, a PEP service MUST send the last published item to all new subscribers and to all newly-available resources for each subscriber, including the account owner itself. (That is, the default value of the "pubsub#send_last_published_item" node configuration field must be "on_sub_and_presence"; this behavior essentially mimics the functionality of presence as defined in <cite>XMPP IM</cite>.)</p>
+      <p class='box'>Note: The "on_sub_and_presence" setting relates to the <em>subscriber's</em> presence, not the publisher's presence.</p>
       <example caption='Subscriber sends presence from newly-available resource'><![CDATA[
 <presence from='romeo@montague.lit/orchard'>
   <c xmlns='http://jabber.org/protocol/caps' 
@@ -503,6 +506,10 @@
     </ol>
     <p>If the modification results in a loss of access, the service MUST cancel the entity's subscription. In addition, the service MAY send a message to the (former) subscriber informing it of the cancellation (for information about the format of messages sent to notify subscribers of subscription cancellation, see the "Notification of Subscription Denial or Cancellation" section of <cite>XEP-0060</cite>).</p>
   </section2>
+  <section2 topic='One Node Per Namespace' anchor='impl-onenode'>
+    <p>An earlier version of this document specified that there there could be only one publish-subscribe node associated with any given payload type (XML namespace) for the account owner (e.g., there could be only one pubsub node for geolocation events, one node for tune events, and one node for mood events, etc.). However, this rule is now considered overly restrictive because some data formats can be used to encapsulate many different kinds of information; the canonical example is Atom as defined in &rfc4287;, for which many extensions exist.</p>
+    <p>A specification that defines a given payload format for use in PEP MUST specify whether there shall be only one node per namespace, or whether multiple NodeIDs for the same namespace are allowable.</p>
+  </section2>
 </section1>
 
 <section1 topic='Security Considerations' anchor='security'>