ProtoXEP RSF v0.0.2 (redux) - changes based on Council feedback

inbox/rsf.xml

@@ -23,7 +23,6 @@
   <dependencies>
     <spec>XMPP Core</spec>
     <spec>XEP-0001</spec>
-    <spec>XEP-0033</spec>
     <spec>XEP-0060</spec>
     <spec>XEP-0115</spec>
   </dependencies>
@@ -54,13 +53,14 @@
   <ul>
     <li>it's impossible to be subscribed to a person's feed if the person is not subscribed to you because in this case his server doesn't know your presence information and your capabilities and hence it can't filter the messages appropriately, so you won't receive any notifications at all;</li>
     <li>servers need to know not only their users' capabilities but also the capabilities of all the users that it wants to communicate;</li>
-    <li>we can't reduce amount of S2S traffic by sending one notification for each server, we need to send as much notifications as much users are subscribed on it;</li>
     <li>clients can't decide what kind of notifications they want to receive; node owner decides instead, but clients might not be interested in some of notifications or vice versa.</li>
   </ul>
   <p>The most actual example of the problems that are beget with these disadvantages is the &xep0277;: you won't be able to subscribe to a user's blog if he doesn't want to read your blog as well. This will be a big problem for popular bloggers that can't read all the feeds of their readers.</p>
+  <p>Another one is a bot which want to gather information from a lot of users. For instance, we can want to write a bot which gather geo-location from a lot of devices, then it will subscribe to these devices but they may not want to do so. The new protocol will allow such bots to operate this way.</p>
+  <p>Also, some clients may want to receive retract items events to appropriately update their feed data storage but some other clients may not want to store feeds at all and just show the recent events and corollary don't need in these events. This standard allows the first one to receive those events and the last one to get rid of them saving traffic, regardless of node settings which can be configured solely by the node's owner.</p>
 </section1>
 <section1 topic='Requirements' anchor='reqs'>
-  <p>The new protocol is needed to solve the stated problems that will allow to move the notifications filtering process from the sender side to the recipient side, that will allow us to filter them in a more sufficient way. Also, we must care of:</p>
+  <p>The new protocol is needed to solve the stated problems that will allow to move the notifications filtering process from the sender side to the recipient side, that will allow us to filter them in a more flexible way. Also, we must care of:</p>
   <ul>
     <li>backwards-compatibility: users of servers that don't support this XEP should be able to receive the notifications through the old protocol;</li>
     <li>users should be able to control what kind of events they want to receive besides the nodes types.</li>
@@ -81,20 +81,12 @@
   <section2 topic="Sending and receiving a notification">
     <p>When using this protocol to deliver notifications, the server MUST follow these rules:</p>
     <ul>
-      <li>send all the notifications that can be generated by the pubsub node without any care of node settings to make it possible for users to choose which notifications they want to receive instead;</li>
+      <li>send all the notifications that can be generated by the pubsub node without any care of node settings to make it possible for users to choose which notifications they want to receive instead.</li>
-      <li>sender's server MUST send the only notification to each recipients' server;</li>
-      <li>sender's server MUST set "to" attribute of the notification stanza to bare recipient's server JID (e.g. "example.net");</li>
-      <li>sender's server MUST keep "from" attribute as usual;</li>
-      <li>sender's server MUST include the exact addresses the notification should be delivered to using &xep0033;'s "bcc" address type.</li>
     </ul>
     <example caption='Sending the notification'>
         <![CDATA[
 <message from='user@example.net'
-         to='example.com'>
+         to='user1@example.com'>
-  <addresses xmlns='http://jabber.org/protocol/address'>
-      <address type='bcc' jid='temas@jabber.org'/>
-      <address type='bcc' jid='jer@jabber.org'/>
-  </addresses>
   <event xmlns='http://jabber.org/protocol/pubsub#event'>
     <items node='n48ad4fj78zn38st734'>
       <item id='i1s2d3f4g5h6bjeh936'>
@@ -107,9 +99,24 @@
     </items>
   </event>
 </message>
+<message from='user@example.net'
+         to='user2@example.com'>
+  <event xmlns='http://jabber.org/protocol/pubsub#event'>
+    <items node='n48ad4fj78zn38st734'>
+      <item id='i1s2d3f4g5h6bjeh936'>
+        <geoloc xmlns='http://jabber.org/protocol/geoloc'>
+          <description>Venice</description>
+          <lat>45.44</lat>
+          <lon>12.33</lon>
+        </geoloc>
+      </item>
+    </items>
+  </event>
+</message>
+... and so on
         ]]>
     </example>
-    <p>If a server receives such an event to its bare address it MUST process it as described in &xep0033; copying the message to the necessary recipients and removing the "bcc" addresses from the stanza.</p>
+    <p>Recipient server is responsible now to filter out and broadcast that messages with events that were request by each user's resource.</p>
   </section2>
   <section2 topic="Advertising client's filtering preferences">
     <p>As described at &xep0060;'s "Filtered notifications" section, client should add payload's NodeID and "+notify" postfix to tell which types of content it can and want to process.</p>
@@ -141,4 +148,3 @@
   <p>This protocol doesn't define any XML stanzas.</p>
 </section1>
 </xep>
-