mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-09 19:05:05 -05:00
29bee13867
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@320 4b5297f7-1745-476d-ba37-a9c6900126ab
232 lines
11 KiB
XML
232 lines
11 KiB
XML
<?xml version='1.0' encoding='UTF-8'?>
|
|
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
|
<!ENTITY % ents SYSTEM 'xep.ent'>
|
|
%ents;
|
|
]>
|
|
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
|
<xep>
|
|
<header>
|
|
<title>Shared Groups</title>
|
|
<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.</abstract>
|
|
&LEGALNOTICE;
|
|
<number>0140</number>
|
|
<status>Retracted</status>
|
|
<type>Informational</type>
|
|
<sig>Standards</sig>
|
|
<dependencies>
|
|
<spec>XMPP Core</spec>
|
|
<spec>XMPP IM</spec>
|
|
<spec>XEP-0060</spec>
|
|
<spec>XEP-0093</spec>
|
|
</dependencies>
|
|
<supersedes/>
|
|
<supersededby>
|
|
<spec>XEP-0144</spec>
|
|
</supersededby>
|
|
<shortname>groups</shortname>
|
|
&stpeter;
|
|
<revision>
|
|
<version>0.2</version>
|
|
<date>2004-10-27</date>
|
|
<initials>psa</initials>
|
|
<remark>Retracted in favor of XEP-0144.</remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.1</version>
|
|
<date>2004-07-26</date>
|
|
<initials>psa</initials>
|
|
<remark>Initial version.</remark>
|
|
</revision>
|
|
</header>
|
|
<section1 topic='Introduction' anchor='intro'>
|
|
<p>&xmppim; 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".</p>
|
|
<p>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.</p>
|
|
<p>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.</p>
|
|
<p>Although &xep0093; 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 &xep0060; as the distribution mechanism, resulting in a basic solution for shared groups over Jabber.</p>
|
|
</section1>
|
|
<section1 topic='Requirements' anchor='reqs'>
|
|
<p>This document addresses the following use cases:</p>
|
|
<ol>
|
|
<li>Creating a shared group.</li>
|
|
<li>Adding a member to the group.</li>
|
|
<li>Removing a member from the group.</li>
|
|
</ol>
|
|
<p>This document does not address the following use cases, which instead are discussed in the <link url="#impl">Implementation Guidelines</link> section of this document:</p>
|
|
<ul>
|
|
<li>Exchanging presence with members of a shared group.</li>
|
|
<li>Sending a message to all members of a shared group.</li>
|
|
<li>Inviting all members of a shared group to a groupchat room.</li>
|
|
</ul>
|
|
</section1>
|
|
<section1 topic='Use Cases' anchor='usecases'>
|
|
<p>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).</p>
|
|
<section2 topic='Creating a Shared Group' anchor='create'>
|
|
<p>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.</p>
|
|
<example caption='Admin Creates a Group'><![CDATA[
|
|
<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>
|
|
<example caption='Service Informs Admin of Success'><![CDATA[
|
|
<iq type='result'
|
|
from='pubsub.example.com'
|
|
to='bofh@example.com/daygig'
|
|
id='create1'/>
|
|
]]></example>
|
|
</section2>
|
|
<section2 topic='Adding a Member to the Group' anchor='add'>
|
|
<p>There are two steps to adding a member to a group, which SHOULD be performed in this order:</p>
|
|
<ol>
|
|
<li>Add new member to subscriber list. (OPTIONAL)</li>
|
|
<li>Publish member information to node.</li>
|
|
</ol>
|
|
<example caption='Admin Adds Member to Subscriber List'><![CDATA[
|
|
<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>
|
|
<example caption='Service Informs Admin of Success'><![CDATA[
|
|
<iq type='result'
|
|
from='pubsub.example.com'
|
|
to='bofh@example.com/daygig'
|
|
id='sub1'/>
|
|
]]></example>
|
|
<p>(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.)</p>
|
|
<p>Now the admin publishes information about the member to the group node.</p>
|
|
<example caption='Admin Publishes Member Information'><![CDATA[
|
|
<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>
|
|
]]></example>
|
|
<p>The member information is then delivered to all subscribers:</p>
|
|
<example caption='Member Information is Delivered to All Subscribers'><![CDATA[
|
|
<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>
|
|
.
|
|
.
|
|
.
|
|
]]></example>
|
|
<p>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 <strong>XMPP IM</strong>. 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).</p>
|
|
</section2>
|
|
<section2 topic='Removing a Member from the Group' anchor='remove'>
|
|
<p>There are two steps to adding a member to a group, which SHOULD be performed in this order:</p>
|
|
<ol>
|
|
<li>Remove member from subscriber list.</li>
|
|
<li>Purge member information from node.</li>
|
|
</ol>
|
|
<example caption='Admin Removes Member from Subscriber List'><![CDATA[
|
|
<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>
|
|
<example caption='Service Informs Admin of Success'><![CDATA[
|
|
<iq type='result'
|
|
from='pubsub.example.com'
|
|
to='bofh@example.com/daygig'
|
|
id='del1'/>
|
|
]]></example>
|
|
<p>(As noted, the group member need not be a pubsub subscriber, in which case the foregoing step may not be necessary.)</p>
|
|
<p>Now admin can remove the member from the shared group.</p>
|
|
<example caption='Admin Removes Member'><![CDATA[
|
|
<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>
|
|
]]></example>
|
|
<p>All remaining subscribers are then informed that the node has been deleted:</p>
|
|
<example caption='Tune Information is Delivered to All Subscribers'><![CDATA[
|
|
<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>
|
|
.
|
|
.
|
|
.
|
|
]]></example>
|
|
</section2>
|
|
</section1>
|
|
<section1 topic='Implementation Guidelines' anchor='impl'>
|
|
<section2 topic='Group Hierarchies' anchor='impl-hier'>
|
|
<p>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 &xep0083; to define the roster group names.</p>
|
|
</section2>
|
|
<section2 topic='Exchanging Presence' anchor='impl-pres'>
|
|
<p>Presence is exchanged via the normal mechanisms defined in <strong>XMPP IM</strong>.</p>
|
|
</section2>
|
|
<section2 topic='Sending Messages' anchor='impl-msg'>
|
|
<p>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 &xep0033;.</p>
|
|
</section2>
|
|
<section2 topic='Sending Groupchat Invites' anchor='impl-gc'>
|
|
<p>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 &xep0045;.</p>
|
|
</section2>
|
|
</section1>
|
|
<section1 topic='Security Considerations' anchor='security'>
|
|
<p>This protocol introduces no security considerations above and beyond those defined in <strong>XEP-0060: Publish-Subscribe</strong> and <strong>XEP-0093: Roster Item Exchange</strong>.</p>
|
|
</section1>
|
|
<section1 topic='IANA Considerations' anchor='iana'>
|
|
<p>This document requires no interaction with &IANA;.</p>
|
|
</section1>
|
|
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
|
<p>This document requires no interaction with the ®ISTRAR;.</p>
|
|
</section1>
|
|
</xep>
|