XEP-0351: Recipient Server Side Notifications Filtering

WARNING: This Standards-Track document is Experimental. Publication as an XMPP Extension Protocol does not imply approval of this proposal by the XMPP Standards Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems are advised to carefully consider whether it is appropriate to deploy implementations of this protocol before it advances to a status of Draft.

Table of Contents

1. Introduction

Publish-Subscribe (XEP-0060) [1] in conjuction with Entity Capabilities (XEP-0115) [2] defines a way for a client to get rid of unwanted pubsub notifications and hence save significant amount of traffic. The protocol is quite flexible and reliable and is able to work even with servers that don't support filtering. Unfortunately, this reliability has its costs and the protocol has the following disadvantages:

• 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;
• servers need to know not only their users' capabilities but also the capabilities of all the users that it wants to communicate;
• 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.

The most actual example of the problems that are beget with these disadvantages is the Microblogging Over XMPP (XEP-0277) [3]: 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.

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.

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.

2. Requirements

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:

• backwards-compatibility: users of servers that don't support this XEP should be able to receive the notifications through the old protocol;
• users should be able to control what kind of events they want to receive besides the nodes types.

3. Use Cases

This document should cover the following use cases:

• switching to the new protocol if the recipient's server support it;
• sending a notification;
• receiving a notification by server and broadcasting it to its users;
• advertising client's filtering preferences.

        
<message from='user@example.net'
         to='user1@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>
<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

    

4. Security Considerations

PENDING

5. IANA Considerations

This document requires no interaction with the Internet Assigned Numbers Authority (IANA).

6. XMPP Registrar Considerations

REQUIRED.

7. XML Schema

This protocol doesn't define any XML stanzas.

Appendices

Appendix A: Document Information

Series: XEP
Number: 0351
Publisher: XMPP Standards Foundation
Status: Experimental
Type: Standards Track
Version: 0.1
Last Updated: 2014-08-28
Approving Body: XMPP Council
Dependencies: XMPP Core, XEP-0001, XEP-0060, XEP-0115
Supersedes: None
Superseded By: None
Short Name: NOT_YET_ASSIGNED
Source Control: HTML
This document in other formats: XML  PDF

Appendix B: Author Information

Appendix C: Legal Notices

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Appendix G: Notes

Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

END