XEP-xxxx: Communities

This document specifies an XMPP protocol extension for centrally-managed contact lists that can be shared among all the members of a particular community of interest.


WARNING: This document has not yet been accepted for consideration or approved in any official manner by the XMPP Standards Foundation, and this document must not be referred to as an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at <http://www.xmpp.org/extensions/> and announced on the <standards@xmpp.org> mailing list.


Document Information

Series: XEP
Number: xxxx
Publisher: XMPP Standards Foundation
Status: ProtoXEP
Type: Standards Track
Version: 0.0.1
Last Updated: 2007-08-29
Approving Body: XMPP Council
Dependencies: XMPP Core
Supersedes: None
Superseded By: None
Short Name: NOT YET ASSIGNED

Author Information

Bruno van Haetsdaele

Email: bruno@wimba.com
JabberID: bruno.vanhaetsdaele@gmail.com

Yann Bianchieri

Email: yann@wimba.com

Peter Saint-Andre

Email: stpeter@jabber.org
JabberID: stpeter@jabber.org

Legal Notice

This XMPP Extension Protocol is copyright 1999 - 2007 by the XMPP Standards Foundation (XSF) and is in full conformance with the XSF's Intellectual Property Rights Policy <http://www.xmpp.org/extensions/ipr-policy.shtml>. This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).

Discussion Venue

The preferred venue for discussion of this document is the Standards discussion list: <http://mail.jabber.org/mailman/listinfo/standards>.

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.

Conformance Terms

The following 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".


Table of Contents


1. Introduction
    1.1. Motivation
    1.2. Requirements
    1.3. Approach
    1.4. How It Works
2. Use Cases
    2.1. Registering With a Community
    2.2. Being Invited to Join a Community
    2.3. Sharing Presence With the Community
    2.4. Sending a Message to the Community
    2.5. Determining Support
    2.6. Creating and Configuring a Community
3. Security Considerations
4. IANA Considerations
5. XMPP Registrar Considerations
    5.1. Service Discovery Identities
6. Acknowledgements
Notes
Revision History


1. Introduction

1.1 Motivation

XMPP IM [1] specifies among other things a technology for user-defined contact lists, called rosters. However, there are many situtations in which it would be helpful to have contact lists that are not defined by or limited to a particular user. Examples include companies (e.g., one list per department), schools (e.g., one list per course), and membership organizations such as clubs. Ideally such lists are maintained by an administrator or other authorized person and automatically disseminated to the members of the relevant group.

Many existing XMPP server implementations include technologies for this functionality, which is often called communities or shared groups. However, those technologies are not interoperable and are not publicly specified. Therefore this document specifies a common protocol for shared contact lists.

1.2 Requirements

This document addresses the following requirements:

  1. Enable authorized entities to create shared contact lists ("communities").
  2. Enable communities to be defined across domains.
  3. Reuse existing XMPP technologies where possible.

1.3 Approach

Instead of designing an all-new protocol for communities, the authors investigated the possibility of re-using an existing XMPP technology. Although both Publish-Subscribe [2] and Roster Item Exchange [3] could be re-used for this purpose, the closest fit is with Multi-User Chat [4], since MUC already includes support for groups of people (albeit in the context of a real-time text conference).

This specification uses a subset of the MUC functionality. In particular, whereas MUC defines a conference of type "text", this specification defines a conference of type "community", which has the following properties:

It is envisioned that a community service will be deployed as a separate service (i.e., a MUC service and a community service would be deployed separately, although they may use the same underlying codebase configured in different ways).

1.4 How It Works

The basic concept behind communities is that a user (e.g., <romeo@montague.lit>) may be a member of a community (e.g., <characters@communities.shakespeare.lit>) whose list of members is maintained by a person with appropriate administrative privileges (e.g., <bard@shakespeare.lit>). Once the user has added the community to his roster, he can share presence with the community when he logs in to the network. Thereafter he can retrieve the list of members and can also receive presence information about available members. If members are added to the community, he receives a message from the community about the new member. The information flow is shown in the following examples.

Example 1. User Logs In

<presence from='romeo@montague.lit/orchard'>
  <c xmlns='http://jabber.org/protocol/caps' 
     algo='sha-1'
     node='http://exodus.jabberstudio.org/;0.9.1'
     ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
</presence>
    

Example 2. Presence is Delivered to Community

<presence from='romeo@montague.lit/orchard' to='characters@communities.shakespeare.lit'>
  <c xmlns='http://jabber.org/protocol/caps' 
     algo='sha-1'
     node='http://exodus.jabberstudio.org/;0.9.1'
     ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
</presence>
    

Example 3. Community Sends Presence to User

<presence from='characters@communities.shakespeare.lit' to='romeo@montague.lit/orchard'>
  <c xmlns='http://jabber.org/protocol/caps' 
     algo='sha-1'
     node='http://code.example.org/XmppCommServ;1.0'
     ver='geVjHRiksZsAxbqMk5ucIXUe/cI='/>
</presence>
    

Note: Inclusion of the Entity Capabilities [5] information enables the community to advertise its capabilities, including a Service Discovery [6] identity of "conference/community". [7]

Based on the identity of the community service, the user can decide whether to share his availability information (presence) with the other members of the community or only to retrieve the list of members.

In order to retrieve the member list, the user sends a memberlist retrieval request to the room as specified in XEP-0045.

Example 4. User Requests Member List

<iq from='romeo@montague.lit/orchard'>
    id='member1'
    to='characters@communities.shakespeare.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='member'/>
  </query>
</iq>
    

Example 5. Service Returns Member List

<iq from='characters@communities.shakespeare.lit'
    id='member1'
    to='romeo@montague.lit/orchard'>
    type='result'>
  <query xmlns='http://jabber.org/protocol/muc#admin'>
    <item affiliation='member'
          jid='juliet@capulet.lit'
          nick='JuliC'/>
    <item affiliation='member'
          jid='romeo@montague.lit'
          nick='MyRomeo'/>
    [ ... ]
  </query>
</iq>
    

In order to share presence with the other community members, the user sends presence to the room and includes a resource identifier (just as in XEP-0045).

Example 6. User Shares Presence With Community Members

<presence from='romeo@montague.lit/orchard' to='characters@communities.shakespeare.lit/MyRomeo'>
  <c xmlns='http://jabber.org/protocol/caps' 
     algo='sha-1'
     node='http://exodus.jabberstudio.org/;0.9.1'
     ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
  <x xmlns='http://jabber.org/protocol/muc'/>
</presence>
    

The community then sends presence from other available community members to the user.

Example 7. Community Sends Presence of Available Community Members to User

<presence from='characters@communities.shakespeare.lit/JuliC' to='romeo@montague.lit/orchard'>
  <c xmlns='http://jabber.org/protocol/caps' 
     algo='sha-1'
     node='http://psi-im.org/;0.11'
     ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member' 
          jid='juliet@capulet.lit/chamber'
          role='participant'/>
  </x>
</presence>

<presence from='characters@communities.shakespeare.lit/TheBard' to='romeo@montague.lit/orchard'>
  <c xmlns='http://jabber.org/protocol/caps' 
     algo='sha-1'
     node='http://www.chatopus.com/;2.2'
     ver='zHyEOgxTrkpSdGcQKH8EFPLsriY='/>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='owner' 
          jid='bard@shakespeare.lit/globe'
          role='moderator'/>
  </x>
</presence>

[ ... ]
    

Example 8. Community Sends Presence of User to Available Community Members

<presence from='characters@communities.shakespeare.lit/MyRomeo' to='juliet@capulet.lit/chamber'>
  <c xmlns='http://jabber.org/protocol/caps' 
     algo='sha-1'
     node='http://exodus.jabberstudio.org/;0.9.1'
     ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member' 
          jid='romeo@montague.lit/orchard'
          role='participant'/>
  </x>
</presence>

<presence from='characters@communities.shakespeare.lit/MyRomeo' to='benvolio@capulet.lit/pda'>
  <c xmlns='http://jabber.org/protocol/caps' 
     algo='sha-1'
     node='http://exodus.jabberstudio.org/;0.9.1'
     ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member' 
          jid='romeo@montague.lit/orchard'
          role='participant'/>
  </x>
</presence>

[ ... ]
    

2. Use Cases

2.1 Registering With a Community

Although typically a community is centrally managed, a user can request to join a community by sending a registration request as specified in XEP-0045.

2.2 Being Invited to Join a Community

When a user is added to a community (either directly by the community administrator or upon approval of a registration request), the community sends a presence subscription request to the user.

Example 9. Community Sends Presence Subscription Request to User

<presence from='characters@communities.shakespeare.lit' 
          to='romeo@montague.lit'
          type='subscribe'
          xml:lang='en'>
  <status>
    You have been invited to join the Shakespearean Characters community!
    To accept the invitation, please approve this subscription request.
  </status>
</presence>
    

To user then either joins the community by approving the subscription request or does not join the community by declining the subscription request. The user's client may attempt to gather additional information about the community before presenting the subscription request to the user; one method for doing so is to query the community using the Service Discovery protocol as described in the Determining Support section of this document.

Example 10. User Joins Community

<presence from='romeo@montague.lit'
          to='characters@communities.shakespeare.lit' 
          type='subscribed'/>
    

OR

Example 11. User Does Not Join Community

<presence from='romeo@montague.lit'
          to='characters@communities.shakespeare.lit' 
          type='unsubscribed'/>
    

Note: A client MAY enable the user to configure the client so that it automatically accepts invitations from a known community service.

If the user approves the subscription request, the client should add the community to the user's roster before sending the subscription approval.

Example 12. Roster Set

<iq from='romeo@montague.lit/orchard'
    type='set'
    id='b89c5r7fb574'>
  <query xmlns='jabber:iq:roster'>
    <item jid='characters@communities.shakespeare.lit'
          name='Shakespearean Characters'
          subscription='none'>
      <group>Communities</group>
    </item>
  </query>
</iq>
    

A client MAY also subscribe to the presence of the community, but a bidirectional subscription is not necessary to enable the community functionality.

2.3 Sharing Presence With the Community

As noted, when a user logs in the user's server sends presence from the user to the community (since the community is subscribed to the user's presence).

Example 13. User Logs In

<presence from='romeo@montague.lit/orchard'>
  <c xmlns='http://jabber.org/protocol/caps' 
     algo='sha-1'
     node='http://exodus.jabberstudio.org/;0.9.1'
     ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
</presence>
    

Example 14. Presence is Delivered to Community

<presence from='romeo@montague.lit/orchard' to='characters@communities.shakespeare.lit'>
  <c xmlns='http://jabber.org/protocol/caps' 
     algo='sha-1'
     node='http://exodus.jabberstudio.org/;0.9.1'
     ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
</presence>
    

Example 15. Community Sends Presence to User

<presence from='characters@communities.shakespeare.lit' to='romeo@montague.lit/orchard'>
  <c xmlns='http://jabber.org/protocol/caps' 
     algo='sha-1'
     node='http://code.example.org/XmppCommServ;1.0'
     ver='geVjHRiksZsAxbqMk5ucIXUe/cI='/>
</presence>
    

So far the user has shared presence only with the community itself, not with the community members. The user's client may want to complete the Retrieving the Member List use case before proceeding (this is functionally equivalent to retrieving the roster before sending presence as described in XMPP-IM).

The user shares presence with the community members by sending presence to a nickname at the community (just as a user joins a multi-user chat room by sending presence to a <room@service/nick>).

Example 16. User Shares Presence With Community Members

<presence from='romeo@montague.lit/orchard' to='characters@communities.shakespeare.lit/MyRomeo'>
  <c xmlns='http://jabber.org/protocol/caps' 
     algo='sha-1'
     node='http://exodus.jabberstudio.org/;0.9.1'
     ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
  <x xmlns='http://jabber.org/protocol/muc'/>
</presence>
    

The community then sends presence from other available community members to the user.

Example 17. Community Sends Presence of Available Community Members to User

<presence from='characters@communities.shakespeare.lit/JuliC' to='romeo@montague.lit/orchard'>
  <c xmlns='http://jabber.org/protocol/caps' 
     algo='sha-1'
     node='http://psi-im.org/;0.11'
     ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member' 
          jid='juliet@capulet.lit/chamber'
          role='participant'/>
  </x>
</presence>

<presence from='characters@communities.shakespeare.lit/TheBard' to='romeo@montague.lit/orchard'>
  <c xmlns='http://jabber.org/protocol/caps' 
     algo='sha-1'
     node='http://www.chatopus.com/;2.2'
     ver='zHyEOgxTrkpSdGcQKH8EFPLsriY='/>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='owner' 
          jid='bard@shakespeare.lit/globe'
          role='moderator'/>
  </x>
</presence>

[ ... ]
    

Example 18. Community Sends Presence of User to Available Community Members

<presence from='characters@communities.shakespeare.lit/MyRomeo' to='juliet@capulet.lit/chamber'>
  <c xmlns='http://jabber.org/protocol/caps' 
     algo='sha-1'
     node='http://exodus.jabberstudio.org/;0.9.1'
     ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member' 
          jid='romeo@montague.lit/orchard'
          role='participant'/>
  </x>
</presence>

<presence from='characters@communities.shakespeare.lit/MyRomeo' to='benvolio@capulet.lit/pda'>
  <c xmlns='http://jabber.org/protocol/caps' 
     algo='sha-1'
     node='http://exodus.jabberstudio.org/;0.9.1'
     ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member' 
          jid='romeo@montague.lit/orchard'
          role='participant'/>
  </x>
</presence>

[ ... ]
    

2.4 Sending a Message to the Community

A multi-user chat room is essentially a message reflector (one message is reflected to all occupants) that includes presence sharing among the occupants. Such rooms use messages of type "groupchat" to differentiate the in-room messages from messages sent in the context of a one-to-one chat session or other environments. A community may also support messaging, but the messages sent in the context of a community SHOULD be of type "normal" (not of type "groupchat") so that receiving clients do not expect to present such messages in a traditional multi-user interface. A community that supports message reflection MUST advertise a feature of "http://jabber.org/protocol/muc#broadcast" so that community members know if they can send messages to the entire community.

Example 19. Member Sends Message to Room

<message from='romeo@montague.lit/orchard' to='characters@communities.shakespeare.lit'>
  <body>How now?</body>
</message>
    

The community then broadcasts the message to the available community members, including a notation of the sender.

Example 20. Community Broadcasts Messages to Available Community Members

<message from='characters@communities.shakespeare.lit' to='benvolio@capulet.lit/pda'>
  <body>How now?</body>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member' 
          jid='romeo@montague.net'
          role='participant'/>
  </x>
</message>

<message from='characters@communities.shakespeare.lit' to='juliet@capulet.lit/chamber'>
  <body>How now?</body>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='member' 
          jid='romeo@montague.net'
          role='participant'/>
  </x>
</message>

[ ... ]
    

Note: A community MAY support the "outsider" affiliation specified in XEP-0045, thus enabling non-members to send messages to the community.

2.5 Determining Support

A community service MUST return a service discovery identity of "conference/community" in response to disco#info requests.

Example 21. User Queries Community Service

<iq from='romeo@montague.lit/orchard'
    id='disco1'
    to='characters.shakespeare.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
    

Example 22. Community Returns Service Discovery Information

<iq from='communities.shakespeare.lit'
    id='disco1'
    to='romeo@montague.lit/orchard'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity category='conference' name='Shakespearean Communities' type='community'/>
    <feature var='http://jabber.org/protocol/disco#info'/>
    <feature var='http://jabber.org/protocol/disco#items'/>
    <feature var='http://jabber.org/protocol/muc'/>
  </query>
</iq>
    

A particular community hosted at a community service also MUST return a service discovery identity of "conference/community" in response to disco#info requests.

Example 23. User Queries Particular Community

<iq from='romeo@montague.lit/orchard'
    id='disco2'
    to='characters@communities.shakespeare.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
    

Example 24. Community Returns Service Discovery Information

<iq from='characters@communities.shakespeare.lit'
    id='disco2'
    to='romeo@montague.lit/orchard'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity category='conference' name='Shakespearean Characters' type='community'/>
    <feature var='http://jabber.org/protocol/disco#info'/>
    <feature var='http://jabber.org/protocol/disco#items'/>
    <feature var='http://jabber.org/protocol/muc'/>
    <feature var='http://jabber.org/protocol/muc#broadcast'/>
    <feature var='http://jabber.org/protocol/muc#presence'/>
  </query>
</iq>
    

Note: If the community is configured to support presence sharing among community members, it shall return a feature of "http://jabber.org/protocol/muc#presence". If the community is configured to support the sending of broadcast messages from one community member to other community members, it shall return a feature of "http://jabber.org/protocol/muc#broadcast".

2.6 Creating and Configuring a Community

Methods for creating and configuring a community over XMPP (similar to the methods described in XEP-0045) will be described in a future version of this specification. A community service may instead provide a web interface to such functionality, or "lock down" community creation so that only service administrators are allowed to create communities, or automaticaly create communities with some default configuration based on information retrieved from a database or other existing data store.

3. Security Considerations

A user may not want one or more members of the community to see his presence; that is, the user may want the community to apply his existing privacy lists as defined by Server-Based Privacy Rules [8]. Methods for doing so may be specified in a future version of this document.

4. IANA Considerations

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

5. XMPP Registrar Considerations

5.1 Service Discovery Identities

The XMPP Registrar [10] shall add a type of "community" to the existing "conference" category in the registry for service discovery identities (see <http://www.xmpp.org/registrar/disco-categories.html>).

The registry submission is as follows:

<category>
  <name>conference</name>
  <type>
    <name>community</name>
    <desc>
      A multi-user community service that provides shared
      contact lists and related services.
    </desc>
    <doc>XEP-xxxx</doc>
  </type>
</category>
    

6. Acknowledgements

The authors wish to thank participants at the second and third XMPP developer conferences (Brussels, Belgium, February 2007; Portland, Oregon, July 2007) for their input and design ideas.


Notes

1. RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://tools.ietf.org/html/rfc3921>.

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

3. XEP-0144: Roster Item Exchange <http://www.xmpp.org/extensions/xep-0144.html>.

4. XEP-0045: Multi-User Chat <http://www.xmpp.org/extensions/xep-0045.html>.

5. XEP-0115: Entity Capabilities <http://www.xmpp.org/extensions/xep-0115.html>.

6. XEP-0030: Service Discovery <http://www.xmpp.org/extensions/xep-0030.html>.

7. In this example, the community has an identity of "conference/community" and supports the "http://jabber.org/protocol/disco#info", "http://jabber.org/protocol/disco#items", "http://jabber.org/protocol/muc", "http://jabber.org/protocol/muc#broadcast", and "http://jabber.org/protocol/muc#presence" features; a SHA-1 hash of the resulting string results in a 'ver' attribute of "geVjHRiksZsAxbqMk5ucIXUe/cI=".

8. XEP-0016: Server-Based Privacy Rules <http://www.xmpp.org/extensions/xep-0016.html>.

9. 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/>.

10. 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 <http://www.xmpp.org/registrar/>.


Revision History

Version 0.0.1 (2007-08-29)

First draft.

(psa/bvh/yb)

END