XEP-: PEP Inbox

Abstract:This specification defines an XMPP protocol extension for offline storage of PEP events in a user inbox (itself a PEP node) so that clients can easily retrieve offline messages. This extension is part of the OneSocialWeb suite of XMPP extensions. In the future, it could be evolved into a more generic offline PubSub extension, or replaced by an other means to manage offline notifications.
Author:Laurent Eschenauer
Copyright:© 2010 Vodafone Group R&D.
Status:
Type:
Version:0.2
Last Updated:2010-04-09


Table of Contents


1. Introduction
    1.1. Overview
2. Requirements
3. Glossary
4. Reader Use Cases
    4.1. Query Latest Notifications
    4.2. Paginate Through Notifications
    4.3. Filter Notifications
    4.4. Search Notifications
    4.5. Combination of Search, Filter and Paginate
5. Business Rules
6. Implementation Notes
7. Accessibility Considerations
8. Internationalization Considerations
9. Security Considerations
10. IANA Considerations
11. XMPP Registrar Considerations
12. XML Schema

Appendices
    A: Document Information
    B: Author Information
    C: Legal Notices
    D: Relation to XMPP
    E: Discussion Venue
    F: Requirements Conformance
    G: Notes
    H: Revision History


1. Introduction

1.1 Overview

The XMPP Extension defined in this document is part of a collection of XMPP extensions that forms the OneSocialWeb (OSW) protocol. The purpose of the OneSocialWeb protocol is to enable free, open, and decentralized social applications on the web. In particular, this protocol can be used to turn any XMPP server into a full fledged social network, participating in the OneSocialWeb federation. The suite of extension covers all the usual social networking use cases such as user profiles, relationships, activity streams and third party applications. In addition, it provides support for fine grained access control, realtime notification and collaboration.

Onesocialweb is using PubSub event messages as a means to share real-time notification across users and servers. This specification explains how these notifications are stored offline for later use by clients. In the future, it could be evolved into a more generic offline PubSub extension, or replaced by an other means to manage offline notifications.

2. Requirements

STRONGLY RECOMMENDED.

3. Glossary

OPTIONAL.

4. Reader Use Cases

This section defines the use cases for and protocols to be used by any entity that wishes to query its notification inbox. In particular, an entity can paginate through the archived notifications, filter them, search them and delete them.

The inbox is effectively a PEP node, so these use cases are the same as the PubSub subscriber use cases [1] in a PEP context, towards the user 'http://onesocialweb.org/spec/1.0/inbox' PEP node. We reproduce a simplified version in the next sections as an introduction but in case of doubts, better to refer to the Publish-Subscribe [2] and Personal Eventing Protocol [3] specifications.

4.1 Query Latest Notifications

An entity can query the latest events in its inbox by sending an <item /> pubsub request to the inbox PEP node of the user. The server replies to this request with the latest events. If a large number of events is available, the answer SHOULD comply with Result Set Management [4].

As an example, we have the entity, <hamlet@denmark.lit> opening its social networking client. The client immediately fetches the inbox of Hamlet so that he can see all the latest activities of his friends. The client sends the following request:

Example 1. User Request Latest Notifications

<iq type='get'
    from='hamlet@denmark.lit/snsclient'
    to='hamlet@denmark.lit'
    id='osw2'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <items node='http://onesocialweb.org/spec/1.0/inbox'/>
  </pubsub>
</iq>
    

To which Hamlet's server replies with the latest notifications in Hamlet's inbox. There are only two items in Hamlet's inbox: a status update by a friend and a relationship request by Othello.

Example 2. Service Reply With Latest Notifications

<iq type="result" 
    from='denmark.lit'
    to='hamlet@denmark.lit/snsclient'
    id='osw2'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <items node='http://onesocialweb.org/spec/1.0/inbox'>
     <item id='urn:uuid:0bfb71a4-d8fd-4410-b119-199c3596f296'>
        <entry xmlns="http://www.w3.org/2005/Atom"> 
          [ ... ENTRY DETAILS ... ]
        </entry>
     </item>
   </items>
  </pubsub>
</iq>
    

4.2 Paginate Through Notifications

[TODO: Simple example using result set management]

4.3 Filter Notifications

[TODO: How far do we want to go ? Basic filtering by type ? Filtering inside payloads ? Allow for more specific rules supporting comparators etc... almost replicating a full blown SQL ? We need to strike a balance between filtering on server and in the client.]

4.4 Search Notifications

[TODO: Similar and linked to previous item: how far to go ?]

4.5 Combination of Search, Filter and Paginate

[TODO: Depends on decision for previous points

5. Business Rules

OPTIONAL.

6. Implementation Notes

OPTIONAL.

7. Accessibility Considerations

OPTIONAL.

8. Internationalization Considerations

OPTIONAL.

9. Security Considerations

REQUIRED.

10. IANA Considerations

REQUIRED.

11. XMPP Registrar Considerations

REQUIRED.

12. XML Schema

REQUIRED for protocol specifications.


Appendices


Appendix A: Document Information

Series: XEP
Number:
Publisher: XMPP Standards Foundation
Status:
Type:
Version: 0.2
Last Updated: 2010-04-09
Approving Body: XMPP Council
Dependencies: XMPP Core, XEP-0030, XEP-0059
Supersedes: None
Superseded By: None
Short Name: NOT_YET_ASSIGNED
Source Control: HTML  RSS


Appendix B: Author Information

Laurent Eschenauer

Email: laurent.eschenauer@vodafone.com
JabberID:


Appendix C: Legal Notices


Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) 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

1. Detailed in http://xmpp.org/extensions/xep-0060.html#subscriber-subscribe.

2. XEP-0060: Publish-Subscribe <http://xmpp.org/extensions/xep-0060.html>.

3. XEP-0163: Personal Eventing Protocol <http://xmpp.org/extensions/xep-0163.html>.

4. XEP-0059: Result Set Management <http://xmpp.org/extensions/xep-0059.html>.


Appendix H: Revision History

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

Version 0.2 (2010-04-09)

Evolved to pusbsub.

(le)

Version 0.0.1 (2010-01-25)

First draft.

(le)

END