1.2rc3

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

xep-0163.xml

@@ -27,10 +27,10 @@
   &stpeter;
   &ksmith;
   <revision>
-    <version>1.2rc2</version>
-    <date>in progress, last updated 2009-04-17</date>
+    <version>1.2rc3</version>
+    <date>in progress, last updated 2009-09-18</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>
+    <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.</p></remark>
   </revision>
   <revision>
     <version>1.1</version>
@@ -393,12 +393,12 @@
     <section3 topic='When to Generate Notifications' anchor='notify-when'>
       <ol start='1'>
         <li><p>When an account owner publishes an item to a node, a PEP service MUST generate a notification and send it to all appropriate subscribers (where the number of notifications is determined by the foregoing rules).</p></li>
-        <li><p>When a PEP service receives initial presence information from a subscriber's resource including <cite>XEP-0115</cite> information that indicates an interest in the data format, it MUST generate a notification containing the last published item for that node and send it to the newly-available resource.</p></li>
+        <li><p>When a PEP service receives initial presence information from a subscriber's resource including <cite>XEP-0115</cite> information that indicates an interest in the data format, it MUST generate a notification containing at least the last published item for that node and send it to the newly-available resource; see below under <link url='#notify-last'>Sending the Last Published Item</link>.</p></li>
         <li><p>As an exception to the foregoing MUST rules, a PEP service MUST NOT send notifications to a subscriber if the user has blocked the subscriber from receiving all or any kinds of stanza (presence, message, IQ, or any combination thereof) using communications blocking as specified in &xep0016; or &xep0191;.</p></li>
       </ol>
     </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>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>.) When processing a new subscription, the service MAY send not only the last published item but instead all items that are currently associated with the node (i.e., up to the maximum number of items at the node, which might be one if the node is a "singleton node" as described in <cite>XEP-0060</cite>). If the service has knowledge about the datetime that a subscriber's newly-available resource last received updated information from the node (e.g., as described in &xep0256;) then it MAY also send more items that only the last published item to the newly-available resource.</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'>
@@ -508,7 +508,7 @@
     <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>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 usual example is Atom as defined in &rfc4287;, for which many extensions exist. Therefore, this document now does not specify that there is a one-to-one relationship between NodeIDs and payload namespaces.</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>