XEP-0140: Shared Groups

Abstract
This document defines a protocol profile for centrally defined and administered roster groups; the protocol described herein has been retracted in favor of XEP-0144: Roster Item Exchange.
Author
Peter Saint-Andre
Copyright
© 2004 – 2004 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status

Retracted

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 (XEP-0144).
Superseded By
XEP-0144
Type
Informational
Version
0.2 (2004-10-27)
Document Lifecycle
  1. Experimental
  2. Retracted
  3. Proposed
  4. Active

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 (XEP-0093) [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 (XEP-0060) [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:

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).

3.1 Creating a Shared Group

A group is implemented as a pubsub node. If a contact is a member of multiple groups, the contact MUST be added to each pubsub node separately. There is a one-to-one relationship between a group and a node. It is OPTIONAL for the NodeID to include the name of the group (e.g., "groups/Marketing"), although in general it is best not to overload NodeIDs and this is unnecessary given the structure of the groups protocol as described below.

Example 1. Admin Creates a Group
<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>
Example 2. Service Informs Admin of Success
<iq type='result'
    from='pubsub.example.com'
    to='bofh@example.com/daygig'
    id='create1'/>

3.2 Adding a Member to the Group

There are two steps to adding a member to a group, which SHOULD be performed in this order:

  1. Add new member to subscriber list. (OPTIONAL)
  2. Publish member information to node.
Example 3. Admin Adds Member to Subscriber List
<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>
Example 4. Service Informs Admin of Success
<iq type='result'
    from='pubsub.example.com'
    to='bofh@example.com/daygig'
    id='sub1'/>

(Naturally, a member of a shared group need not be informed of changes to the group, and an entity that is informed of changes to the group need not be a member of the group. However, in most applications a group member will be a pubsub subscriber and vice-versa.)

Now the admin publishes information about the member to the group node.

Example 5. Admin Publishes Member Information
<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>

The member information is then delivered to all subscribers:

Example 6. Member Information is Delivered to All Subscribers
<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>
.
.
.

Note: It is the receiving application's responsibility to add the newly-published roster item to the recipient's roster by following the protocols defined in XMPP IM. The receiving application SHOULD NOT prompt the recipient regarding whether or not to add the roster item, but if and only the roster item is received via pubsub (i.e., it SHOULD prompt the user when roster items are received from individual users and not via pubsub).

3.3 Removing a Member from the Group

There are two steps to adding a member to a group, which SHOULD be performed in this order:

  1. Remove member from subscriber list.
  2. Purge member information from node.
Example 7. Admin Removes Member from Subscriber List
<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>
Example 8. Service Informs Admin of Success
<iq type='result'
    from='pubsub.example.com'
    to='bofh@example.com/daygig'
    id='del1'/>

(As noted, the group member need not be a pubsub subscriber, in which case the foregoing step may not be necessary.)

Now admin can remove the member from the shared group.

Example 9. Admin Removes Member
<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>

All remaining subscribers are then informed that the node has been deleted:

Example 10. Tune Information is Delivered to All Subscribers
<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

4.1 Group Hierarchies

An administrator may wish to define a hierarchy of shared groups (e.g., "Marketing/Europe" and "Marketing/North America"). This can be done using collection nodes as defined in Section 9 of XEP-0060. The receiving application MAY use Nested Roster Groups (XEP-0083) [4] to define the roster group names.

4.2 Exchanging Presence

Presence is exchanged via the normal mechanisms defined in XMPP IM.

4.3 Sending Messages

In order to send a message to all members of a shared group, a group member's sending application (usually an end-user client) SHOULD either send multiple messages or use Extended Stanza Addressing (XEP-0033) [5].

4.4 Sending Groupchat Invites

In order to invite all members of a shared group to a groupchat room, a group member's sending application SHOULD use the mechanisms defined in Multi-User Chat (XEP-0045) [6].

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

Peter Saint-Andre
Email
stpeter@stpeter.im
JabberID
stpeter@jabber.org
URI
https://stpeter.im/

Copyright

This XMPP Extension Protocol is copyright © 1999 – 2024 by the XMPP Standards Foundation (XSF).

Permissions

Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).

Visual Presentation

The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.

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 <https://xmpp.org/community/> 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. RFC 6121: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://tools.ietf.org/html/rfc6121>.

2. XEP-0093: Roster Item Exchange <https://xmpp.org/extensions/xep-0093.html>.

3. XEP-0060: Publish-Subscribe <https://xmpp.org/extensions/xep-0060.html>.

4. XEP-0083: Nested Roster Groups <https://xmpp.org/extensions/xep-0083.html>.

5. XEP-0033: Extended Stanza Addressing <https://xmpp.org/extensions/xep-0033.html>.

6. XEP-0045: Multi-User Chat <https://xmpp.org/extensions/xep-0045.html>.

7. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.

8. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <https://xmpp.org/registrar/>.

Appendix H: Revision History

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

  1. Version 0.2 (2004-10-27)
    Retracted in favor of XEP-0144.
    psa
  2. Version 0.1 (2004-07-26)
    Initial version.
    psa

Appendix I: Bib(La)TeX Entry

@report{saint-andre2004groups,
  title = {Shared Groups},
  author = {Saint-Andre, Peter},
  type = {XEP},
  number = {0140},
  version = {0.2},
  institution = {XMPP Standards Foundation},
  url = {https://xmpp.org/extensions/xep-0140.html},
  date = {2004-07-26/2004-10-27},
}

END