XEP-0140: Shared Groups

WARNING: This document has been retracted by the author(s). Implementation of the protocol described herein is not recommended. Developers desiring similar functionality are advised to implement the protocol that supersedes this one (if any).

Table of Contents

1. Introduction

XMPP IM [1] defines a protocol for personal rosters (also known as contact lists). So far all Jabber rosters are personal rosters that are defined by a single user and accessed only by that user. However, in some contexts it would be helpful to centrally define and administer roster groups so that they can be shared among a user population in an organized fashion. This functionality is often called "shared groups".

One context in which shared groups might be useful is the enterprise environment. For example, when Alice is hired by the marketing department of Big Company Enterprises, it makes sense for her to automatically have the other members of the marketing department in her roster the first time she logs in, and for the rest of the marketing department to have Alice in their rosters as soon as her account has been set up. Similarly, when Bob in logistics gets fired, it makes sense for him to disappear from the rosters of everyone else in the logistics department.

This functionality is not limited to the enterprise environment. It could prove quite useful in academic settings, social networking applications, consumer IM services, and anywhere else that it is important to build and manage small communities of users.

Although Roster Item Exchange [2] defines a format for sharing roster items between two users and therefore enables one user to send roster items to another user, it does not currently provide a way to share or coordinate a group of roster items in an organized fashion. To make that possible, this document extends XEP-0093 by defining Publish-Subscribe [3] as the distribution mechanism, resulting in a basic solution for shared groups over Jabber.

2. Requirements

This document addresses the following use cases:

1. Creating a shared group.
2. Adding a member to the group.
3. Removing a member from the group.

This document does not address the following use cases, which instead are discussed in the Implementation Guidelines section of this document:

• Exchanging presence with members of a shared group.
• Sending a message to all members of a shared group.
• Inviting all members of a shared group to a groupchat room.

3. Use Cases

The following examples show the protocol flow for an administrator to complete the use cases defined above. Naturally, these tasks could be performed just as well by an automated application that is tied to an existing user database (e.g., LDAP).

<iq type='set'
    from='bofh@example.com/daygig'
    to='pubsub.example.com'
    id='create1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <create node-id='groups/Marketing/Europe'/>
  </pubsub>
</iq>
    

<iq type='result'
    from='pubsub.example.com'
    to='bofh@example.com/daygig'
    id='create1'/>
    

<iq type='set'
    from='bofh@example.com/daygig'
    to='pubsub.example.com'
    id='sub1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <entities node='groups/Marketing/Europe'>
      <entity jid='alice@example.com'
              affiliation='none'
              subscription='subscribed'/>
    </entities>
  </pubsub>
</iq>
    

<iq type='result'
    from='pubsub.example.com'
    to='bofh@example.com/daygig'
    id='sub1'/>
    

<iq type='set'
    from='bofh@example.com/daygig'
    to='pubsub.example.com'
    id='pub1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='groups/Marketing/Europe'>
      <item id='alice@example.com'>
        <x xmlns='jabber:x:roster'
           jid='alice@example.com' 
           name='Alice Rosenbaum'>
          <group>Marketing/Europe</group>
        </x>
      </item>
    </publish>
  </pubsub>
</iq>
    

<message
    from='pubsub.example.com'
    to='cathy@example.com'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='groups/Marketing/Europe'>
      <item id='alice@example.com'>
        <x xmlns='jabber:x:roster'
           jid='alice@example.com' 
           name='Alice Rosenbaum'>
          <group>Marketing/Europe</group>
        </x>
      </item>
    </items>
  </event>
</message>
.
.
.
    

<iq type='set'
    from='bofh@example.com/daygig'
    to='pubsub.example.com'
    id='del1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <entities node='groups/Marketing/Europe'>
      <entity jid='alice@example.com'
              affiliation='none'
              subscription='none'/>
    </entities>
  </pubsub>
</iq>
    

<iq type='result'
    from='pubsub.example.com'
    to='bofh@example.com/daygig'
    id='del1'/>
    

<iq type='set'
    from='bofh@example.com/daygig'
    to='pubsub.example.com'
    id='purge1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <retract node='groups/Marketing/Europe'>
      <item id='alice@example.com'/>
    </retract>
  </pubsub>
</iq>
    

<message
    from='pubsub.example.com'
    to='cathy@example.com'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <retract node='groups/Marketing/Europe'>
      <item id='alice@example.com'/>
    </retract>
  </event>
</message>
.
.
.
    

4. Implementation Guidelines

5. Security Considerations

This protocol introduces no security considerations above and beyond those defined in XEP-0060: Publish-Subscribe and XEP-0093: Roster Item Exchange.

6. IANA Considerations

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

7. XMPP Registrar Considerations

This document requires no interaction with the XMPP Registrar [8].

Appendices

Appendix A: Document Information

Series: XEP
Number: 0140
Publisher: XMPP Standards Foundation
Status: Retracted
Type: Informational
Version: 0.2
Last Updated: 2004-10-27
Approving Body: XMPP Council
Dependencies: XMPP Core, XMPP IM, XEP-0060, XEP-0093
Supersedes: None
Superseded By: XEP-0144
Short Name: groups
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 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

Appendix H: Revision History

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

END