added note about publisher presence

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

xep-0060.xml

@@ -51,8 +51,8 @@
   &ralphm;
 
   <revision>
-    <version>1.13rc15</version>
-    <date>in progress, 2010-03-31</date>
+    <version>1.13rc16</version>
+    <date>in progress, last updated 2010-04-07</date>
     <initials>psa</initials>
     <remark>
       <ul>
@@ -4630,6 +4630,7 @@ And by opposing end them?
 
 <section1 topic='IM Account Integration' anchor='presence'>
   <p>Publish-subscribe functionality can be integrated into existing instant messaging and presence services (see <cite>RFC 3921</cite>), such that each registered account functions as a virtual pubsub service (sometimes called "pubsub-on-a-JID"). In such deployments, the root pubsub node for each virtual pubsub service has the same address as the bare JID &BAREJID; of the account, which is typically associated with an IM user (e.g., &lt;hamlet@denmark.lit&gt;). Since an IM user typically has a roster of "buddies" and shares presence information with those buddies, the virtual pubsub service can use roster and presence information to provide some helpful shortcuts for subscribers, in particular the auto-subscribe and filtered-notifications features described in this section.</p>
+  <p class='box'>Note: PEP ties the receipt of PEP notifications to the subscriber's presence, but does not tie the generation of PEP notifications to the publisher's presence. If the publisher wishes to stop generating PEP events (or to generate an "empty" event as can be done for some PEP payloads) before ending its presence session, the publisher MUST direct its client to do so and MUST NOT depend on the PEP service to automatically "zero out" its PEP information when the PEP service receives unavailable presence from the publisher.</p>
   <p>If an instant messaging and presence account is also a virtual pubsub service, service discovery information ("disco#info") responses from the bare JID of the account MUST include a feature of "http:/jabber.org/protocol/pubsub#pubsub-on-a-jid":</p>
   <example caption='IM server returns supported features on behalf of IM account'><![CDATA[
 <iq from='hamlet@denmark.lit'

xep-0163.xml

@@ -28,8 +28,8 @@
   &stpeter;
   &ksmith;
   <revision>
-    <version>1.2rc4</version>
-    <date>in progress, last updated 2009-10-29</date>
+    <version>1.2rc5</version>
+    <date>in progress, last updated 2010-04-07</date>
     <initials>psa</initials>
     <remark><p>Removed the one-node-per-namespace rule (community consensus indicates that this rule was overly restrictive); clarified the meaning of auto-subscribe; clarified that sending the last published item does not prevent the service from sending additional items in some circumstances; discouraged the use of directed presence for the purpose of implicit subscriptions.</p></remark>
   </revision>
@@ -329,7 +329,7 @@
       <li>A service automatically sends notifications to all of the account owner's connected resources (subject to notification filtering).</li>
     </ul>
     <p>These uses of presence simplify the task of developing compliant clients (cf. &xep0134;).</p>
-    <p class='box'>It is strongly NOT RECOMMENDED to use directed presence with Entity Capabilities data that differs from the data included in broadcast presence for the purpose of establishing implicit PEP subscriptions to another entity, because the directed presence information will be overwritten by any subsequent presence broadcast.</p>
+    <p class='box'>Note: It is strongly NOT RECOMMENDED to use directed presence with Entity Capabilities data that differs from the data included in broadcast presence for the purpose of establishing implicit PEP subscriptions to another entity, because the directed presence information will be overwritten by any subsequent presence broadcast.</p>
   </section2>
   <section2 topic='Filtered Notifications' anchor='approach-filter'>
     <p>By default, the existence of an XMPP presence subscription is used to establish a PEP subscription to the account owner's personal eventing data. In order to filter which notifications are sent by the PEP service, the contact's client includes extended &xep0115; information in the presence notifications it sends to the account owner. Because the PEP service supports the "filtered-notifications" feature, it sends only those notifications that match the contact's expressed notification preferences.</p>
@@ -361,6 +361,7 @@
   <p>If the node does not already exist, the PEP service MUST create the node. This "auto-create" feature (defined in <cite>XEP-0060</cite>) MUST be supported by a PEP service. (Naturally, the account owner's client MAY follow the node creation use case specified in <cite>XEP-0060</cite> before attempting to publish an item.)</p>
   <p>A PEP service SHOULD also support the "publish-options" feature defined in <cite>XEP-0060</cite>.</p>
   <p>If the publication logic dictates that event notifications shall be sent, the account owner's server generates notifications and sends them to all appropriate entities as described in the <link url='#notify'>Receiving Event Notifications</link> section of this document, as well as to any of the account owner's available resources.</p>
+  <p class='box'>Note: PEP ties the receipt of PEP notifications to the subscriber's presence, but does not tie the generation of PEP notifications to the publisher's presence. If the publisher wishes to stop generating PEP events (or to generate an "empty" event as can be done for some PEP payloads) before ending its presence session, the publisher MUST direct its client to do so and MUST NOT depend on the PEP service to automatically "zero out" its PEP information when the PEP service receives unavailable presence from the publisher.</p>
 </section1>
 
 <section1 topic='Receiving Event Notifications' anchor='notify'>