mirror of
https://github.com/moparisthebest/xeps
synced 2024-12-21 23:28:51 -05:00
1.25rc1
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3866 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre
parent
c77bca34fd
commit
e2916d5618
254
xep-0045.xml
254
xep-0045.xml
@ -13,6 +13,7 @@
|
||||
&LEGALNOTICE;
|
||||
<number>0045</number>
|
||||
<status>Draft</status>
|
||||
<interim/>
|
||||
<type>Standards Track</type>
|
||||
<sig>Standards</sig>
|
||||
<dependencies>
|
||||
@ -49,6 +50,18 @@
|
||||
</schemaloc>
|
||||
<registry/>
|
||||
&stpeter;
|
||||
<revision>
|
||||
<version>1.25rc1</version>
|
||||
<date>in progress, last updated 2010-01-21</date>
|
||||
<initials>psa</initials>
|
||||
<remark>
|
||||
<ul>
|
||||
<li>Clarified the fact that room roles and affiliations are shortcuts to bundles of privileges.</li>
|
||||
<li>Removed references to service discovery feature for "gc-1.0" since it is now obsolete.</li>
|
||||
<li>Added security consideration about information leaks related to service discovery.</li>
|
||||
</ul>
|
||||
</remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>1.24</version>
|
||||
<date>2008-07-16</date>
|
||||
@ -415,33 +428,33 @@
|
||||
</revision>
|
||||
</header>
|
||||
<section1 topic='Introduction' anchor='intro'>
|
||||
<p>Traditionally, instant messaging is thought to consist of one-to-one chat rather than many-to-many chat, which is called variously "groupchat" or "text conferencing". Groupchat functionality is familiar from systems such as Internet Relay Chat (IRC) and the chatroom functionality offered by popular consumer IM services. The Jabber community developed and implemented a basic groupchat protocol as long ago as 1999. This "groupchat 1.0" protocol provided a minimal feature set for chat rooms but was rather limited in scope. This specification (Multi-User Chat or MUC) builds on the older "groupchat 1.0" protocol in a backwards-compatible manner but provides advanced features such as invitations, room moderation and administration, and specialized room types.</p>
|
||||
<p>Traditionally, instant messaging is thought to consist of one-to-one chat rather than many-to-many chat, which is called variously "groupchat" or "text conferencing". Groupchat functionality is familiar from systems such as Internet Relay Chat (IRC) and the chatroom functionality offered by popular consumer IM services. The Jabber/XMPP community developed and implemented a basic groupchat protocol as long ago as 1999. That "groupchat 1.0" protocol provided a minimal feature set for chat rooms but was rather limited in scope. This specification (Multi-User Chat or MUC) builds on the older "groupchat 1.0" protocol in a backwards-compatible manner but provides advanced features such as invitations, room moderation and administration, and specialized room types.</p>
|
||||
</section1>
|
||||
<section1 topic='Scope' anchor='scope'>
|
||||
<p>This document addresses common requirements related to configuration of, participation in, and administration of individual text-based conference rooms. All of the requirements addressed herein apply at the level of the individual room and are "common" in the sense that they have been widely discussed within the Jabber community or are familiar from existing text-based conference environments outside of Jabber (e.g., Internet Relay Chat as defined in &rfc1459; and its successors: &rfc2810;, &rfc2811;, &rfc2812;, &rfc2813;).</p>
|
||||
<p>This document addresses common requirements related to configuration of, participation in, and administration of individual text-based conference rooms. All of the requirements addressed herein apply at the level of the individual room and are "common" in the sense that they have been widely discussed within the Jabber community or are familiar from existing text-based conference environments (e.g., Internet Relay Chat as defined in &rfc1459; and its successors: &rfc2810;, &rfc2811;, &rfc2812;, &rfc2813;).</p>
|
||||
<p>This document explicitly does <em>not</em> address the following:</p>
|
||||
<ul>
|
||||
<li>Relationships between rooms (e.g., hierarchies of rooms)</li>
|
||||
<li>Management of multi-user chat services (e.g., managing permissions across an entire service or registering a global room nickname); such use cases are specified in &xep0133;</li>
|
||||
<li>Moderation of individual messages</li>
|
||||
<li>Encryption of messages sent through a room</li>
|
||||
<li>Advanced features such as attaching files to a room, integrating whiteboards, and interfacing with audio or video chat services</li>
|
||||
<li>Advanced features such as attaching files to a room, integrating whiteboards, and using MUC rooms as a way to manage the signalling for multi-user audio or video conferencing (see &xep0272;)</li>
|
||||
<li>Interaction between MUC deployments and foreign chat systems (e.g., gateways to IRC or to legacy IM systems)</li>
|
||||
<li>Mirroring or replication of rooms among multiple MUC deployments</li>
|
||||
</ul>
|
||||
<p>This limited scope is not meant to disparage such topics, which are of inherent interest; however, it is meant to focus the discussion in this document and to present a comprehensible protocol that can be implemented by Jabber client and component developers alike. Future specifications may of course address the topics mentioned above.</p>
|
||||
<p>This limited scope is not meant to disparage such topics, which are of inherent interest; however, it is meant to focus the discussion in this document and to present a comprehensible protocol that can be implemented by client and component developers alike. Future specifications might address the topics mentioned above.</p>
|
||||
</section1>
|
||||
<section1 topic='Requirements' anchor='reqs'>
|
||||
<p>This document addresses the minimal functionality provided by existing multi-user chat services in Jabber. For the sake of backwards-compatibility, this document uses the original "groupchat 1.0" protocol for this baseline functionality, with the result that:</p>
|
||||
<p>This document addresses the minimal functionality provided by Jabber-based multi-user chat services that existed in 2002 when development of MUC began. For the sake of backwards-compatibility, this document uses the original "groupchat 1.0" protocol for this baseline functionality, with the result that:</p>
|
||||
<ul>
|
||||
<li>Each room is identified as &ROOM; (e.g., <jdev@conference.jabber.org>), where "room" is the name of the room and "service" is the hostname at which the multi-user chat service is running.</li>
|
||||
<li>Each occupant in a room is identified as &ROOMJID;, where "nick" is the room nickname of the occupant as specified on entering the room or subsequently changed during the occupant's visit.</li>
|
||||
<li>A user enters a room (i.e., becomes an occupant) by sending presence to &ROOMJID;.</li>
|
||||
<li>Messages sent within multi-user chat rooms are of a special type "groupchat" and are addressed to the room itself (room@service), then reflected to all occupants.</li>
|
||||
<li>A user enters a room (i.e., becomes an occupant) by sending directed presence to &ROOMJID;.</li>
|
||||
<li>An occupant can change his or her room nickname and availability status within the room by sending presence information to <room@service/newnick>.</li>
|
||||
<li>Messages sent within multi-user chat rooms are of a special type "groupchat" and are addressed to the room itself (room@service), then reflected to all occupants.</li>
|
||||
<li>An occupant exits a room by sending presence of type "unavailable" to its current &ROOMJID;.</li>
|
||||
</ul>
|
||||
<p>The additional features and functionality addressed in this document include the following:</p>
|
||||
<p>The additional features and functionality addressed in MUC include the following:</p>
|
||||
<ol start='1'>
|
||||
<li>native conversation logging (no in-room bot required)</li>
|
||||
<li>enabling users to request membership in a room</li>
|
||||
@ -453,19 +466,19 @@
|
||||
<li>enabling admins to grant and revoke moderator privileges, and to manage the moderator list</li>
|
||||
<li>enabling admins to ban users from the room, and to manage the ban list</li>
|
||||
<li>enabling admins to grant and revoke membership privileges, and to manage the member list for a members-only room</li>
|
||||
<li>enabling owners to limit the number of occupants</li>
|
||||
<li>enabling owners to configure various room parameters (e.g., limiting the number of occupants)</li>
|
||||
<li>enabling owners to specify other owners</li>
|
||||
<li>enabling owners to grant and revoke administrative privileges, and to manage the admin list</li>
|
||||
<li>enabling owners to destroy the room</li>
|
||||
</ol>
|
||||
<p>In addition, this document provides protocol elements for supporting the following room types:</p>
|
||||
<ol start='1'>
|
||||
<li>public or hidden</li>
|
||||
<li>persistent or temporary</li>
|
||||
<li>password-protected or unsecured</li>
|
||||
<li>members-only or open</li>
|
||||
<li>moderated or unmoderated</li>
|
||||
<li>non-anonymous or semi-anonymous</li>
|
||||
<li>public vs. hidden</li>
|
||||
<li>persistent vs. temporary</li>
|
||||
<li>password-protected vs. unsecured</li>
|
||||
<li>members-only vs. open</li>
|
||||
<li>moderated vs. unmoderated</li>
|
||||
<li>non-anonymous vs. semi-anonymous</li>
|
||||
</ol>
|
||||
<p>The extensions needed to implement these requirements are qualified by the 'http://jabber.org/protocol/muc' namespace (and the #owner, #admin, and #user fragments on the main namespace URI).</p>
|
||||
</section1>
|
||||
@ -476,30 +489,30 @@
|
||||
<di><dt>Ban</dt><dd>To remove a user from a room such that the user is not allowed to re-enter the room (until and unless the ban has been removed). A banned user has an affiliation of "outcast".</dd></di>
|
||||
<di><dt>Bare JID</dt><dd>The <user@host> by which a user is identified outside the context of any existing session or resource; contrast with Full JID and Room JID.</dd></di>
|
||||
<di><dt>Full JID</dt><dd>The <user@host/resource> by which an online user is identified outside the context of a room; contrast with Bare JID and Room JID.</dd></di>
|
||||
<di><dt>GC</dt><dd>The minimal "groupchat 1.0" protocol [<a href="#nt-id36733">7</a>] developed within the Jabber community in 1999; MUC is backwards-compatible with GC.</dd></di>
|
||||
<di><dt>GC</dt><dd>The minimal "groupchat 1.0" protocol developed within the Jabber community in 1999; MUC is backwards-compatible with GC.</dd></di>
|
||||
<di><dt>History</dt><dd>A limited number of message stanzas sent to a new occupant to provide the context of current discussion.</dd></di>
|
||||
<di><dt>Invitation</dt><dd>A special message sent from one user to another asking the recipient to join a room.</dd></di>
|
||||
<di><dt>Invitation</dt><dd>A special message sent from one user to another asking the recipient to join a room; the invitation can be sent directly (see &xep0249;) or mediated through the room (as described under <link url='#invite'>Inviting Another User to a Room</link>).</dd></di>
|
||||
<di><dt>IRC</dt><dd>Internet Relay Chat.</dd></di>
|
||||
<di><dt>Kick</dt><dd>To temporarily remove a participant or visitor from a room; the user is allowed to re-enter the room at any time. A kicked user has a role of "none".</dd></di>
|
||||
<di><dt>Logging</dt><dd>Storage of discussions that occur within a room for public retrieval outside the context of the room.</dd></di>
|
||||
<di><dt>Member</dt><dd>A user who is on the "whitelist" for a members-only room or who is registered with an open room. A member has an affiliation of "member".</dd></di>
|
||||
<di><dt>Moderator</dt><dd>A room role that is usually associated with room admins but that may be granted to non-admins; is allowed to kick users, grant and revoke voice, etc. A moderator has a role of "moderator".</dd></di>
|
||||
<di><dt>MUC</dt><dd>The multi-user chat protocol for text-based conferencing specified in this document.</dd></di>
|
||||
<di><dt>Occupant</dt><dd>Any Jabber user who is in a room (this is an "abstract class" and does not correspond to any specific role).</dd></di>
|
||||
<di><dt>Occupant</dt><dd>Any user who is in a room (this is an "abstract class" and does not correspond to any specific role).</dd></di>
|
||||
<di><dt>Outcast</dt><dd>A user who has been banned from a room. An outcast has an affiliation of "outcast".</dd></di>
|
||||
<di><dt>Participant</dt><dd>An occupant who does not have administrative privileges; in a moderated room, a participant is further defined as having voice (in contrast to a visitor). A participant has a role of "participant".</dd></di>
|
||||
<di><dt>Private Message</dt><dd>A message sent from one occupant directly to another's room JID (not to the room itself for broadcasting to all occupants).</dd></di>
|
||||
<di><dt>Role</dt><dd>A temporary position or privilege level within a room, distinct from a user's long-lived affiliation with the room; the possible roles are "moderator", "participant", and "visitor" (it is also possible to have no defined role). A role lasts only for the duration of an occupant's visit to a room.</dd></di>
|
||||
<di><dt>Room</dt><dd>A virtual space that Jabber users figuratively enter in order to participate in real-time, text-based conferencing with other users.</dd></di>
|
||||
<di><dt>Room Administrator</dt><dd>A user empowered by the room owner to perform administrative functions such as banning users; however, is not allowed to change defining room features. An admin has an affiliation of "admin".</dd></di>
|
||||
<di><dt>Room ID</dt><dd>The node identifier portion of a Room JID, which may be opaque and thus lack meaning for human users (see Business Rules for syntax); contrast with Room Name.</dd></di>
|
||||
<di><dt>Room</dt><dd>A virtual space that users figuratively enter in order to participate in real-time, text-based conferencing with other users.</dd></di>
|
||||
<di><dt>Room Administrator</dt><dd>A user empowered by the room owner to perform administrative functions such as banning users; however, a room administrator is not allowed to change the room configuration or to destroy the room. An admin has an affiliation of "admin".</dd></di>
|
||||
<di><dt>Room ID</dt><dd>The localpart of a Room JID, which may be opaque and thus lack meaning for human users (see under <link url='#bizrules'>Business Rules</link> for syntax); contrast with Room Name.</dd></di>
|
||||
<di><dt>Room JID</dt><dd>The <room@service/nick> by which an occupant is identified within the context of a room; contrast with Bare JID and Full JID.</dd></di>
|
||||
<di><dt>Room Name</dt><dd>A user-friendly, natural-language name for a room, configured by the room owner and presented in Service Discovery queries; contrast with Room ID.</dd></di>
|
||||
<di><dt>Room Nickname</dt><dd>The resource identifier portion of a Room JID (see Business Rules for syntax); this is the "friendly name" by which an occupant is known in the room.</dd></di>
|
||||
<di><dt>Room Owner</dt><dd>The Jabber user who created the room or a Jabber user who has been designated by the room creator or owner as someone with owner privileges (if allowed); is allowed to change defining room features as well as perform all administrative functions. An owner has an affiliation of "owner".</dd></di>
|
||||
<di><dt>Room Roster</dt><dd>A Jabber client's representation of the occupants in a room.</dd></di>
|
||||
<di><dt>Server</dt><dd>A Jabber server that may or may not have associated with it a text-based conferencing service.</dd></di>
|
||||
<di><dt>Service</dt><dd>A host that offers text-based conferencing capabilities; often but not necessarily a sub-domain of a Jabber server (e.g., conference.jabber.org).</dd></di>
|
||||
<di><dt>Room Nickname</dt><dd>The resourcepart of a Room JID (see <link url='#bizrules'>Business Rules</link> for syntax); this is the "friendly name" by which an occupant is known in the room.</dd></di>
|
||||
<di><dt>Room Owner</dt><dd>The user who created the room or a user who has been designated by the room creator or owner as someone with owner privileges (if allowed); an owner is allowed to change the room configuration and destroy the room, in addition to all administrative privileges. An owner has an affiliation of "owner".</dd></di>
|
||||
<di><dt>Room Roster</dt><dd>A client's representation of the occupants in a room.</dd></di>
|
||||
<di><dt>Server</dt><dd>An XMPP server that may or may not have associated with it a text-based conferencing service.</dd></di>
|
||||
<di><dt>Service</dt><dd>A host that offers text-based conferencing capabilities; often but not necessarily a sub-domain of an XMPP server (e.g., conference.jabber.org).</dd></di>
|
||||
<di><dt>Subject</dt><dd>A temporary discussion topic within a room.</dd></di>
|
||||
<di><dt>Visit</dt><dd>A user's "session" in a room, beginning when the user enters the room (i.e., becomes an occupant) and ending when the user exits the room.</dd></di>
|
||||
<di><dt>Visitor</dt><dd>In a moderated room, an occupant who does not have voice (in contrast to a participant). A visitor has a role of "visitor".</dd></di>
|
||||
@ -511,9 +524,9 @@
|
||||
<di><dt>Fully-Anonymous Room</dt><dd>A room in which the full JIDs or bare JIDs of occupants cannot be discovered by anyone, including room admins and room owners; such rooms are NOT RECOMMENDED or explicitly supported by MUC, but are possible using this protocol if a service implementation offers the appropriate configuration options; contrast with Non-Anonymous Room and Semi-Anonymous Room.</dd></di>
|
||||
<di><dt>Hidden Room</dt><dd>A room that cannot be found by any user through normal means such as searching and service discovery; antonym: Public Room.</dd></di>
|
||||
<di><dt>Members-Only Room</dt><dd>A room that a user cannot enter without being on the member list; antonym: Open Room.</dd></di>
|
||||
<di><dt>Moderated Room</dt><dd>A room in which only those with "voice" may send messages to all occupants; antonym: Unmoderated Room.</dd></di>
|
||||
<di><dt>Non-Anonymous Room</dt><dd>A room in which an occupant's full JID is exposed to all other occupants, although the occupant may choose any desired room nickname; contrast with Semi-Anonymous Room and Fully-Anonymous Room.</dd></di>
|
||||
<di><dt>Open Room</dt><dd>A room that anyone may enter without being on the member list; antonym: Members-Only Room.</dd></di>
|
||||
<di><dt>Moderated Room</dt><dd>A room in which only those with "voice" are allowed to send messages to all occupants; antonym: Unmoderated Room.</dd></di>
|
||||
<di><dt>Non-Anonymous Room</dt><dd>A room in which an occupant's full JID is exposed to all other occupants, although the occupant can choose any desired room nickname; contrast with Semi-Anonymous Room and Fully-Anonymous Room.</dd></di>
|
||||
<di><dt>Open Room</dt><dd>A room that anyone is allowed to enter without being on the member list; antonym: Members-Only Room.</dd></di>
|
||||
<di><dt>Password-Protected Room</dt><dd>A room that a user cannot enter without first providing the correct password; antonym: Unsecured Room.</dd></di>
|
||||
<di><dt>Persistent Room</dt><dd>A room that is not destroyed if the last occupant exits; antonym: Temporary Room.</dd></di>
|
||||
<di><dt>Public Room</dt><dd>A room that can be found by any user through normal means such as searching and service discovery; antonym: Hidden Room.</dd></di>
|
||||
@ -549,8 +562,14 @@
|
||||
</table>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Roles and Affiliations' anchor='connections'>
|
||||
<p>There are two dimensions along which we can measure a user's connection with or position in a room. One is the user's long-lived affiliation with a room -- e.g., a user's status as an owner or an outcast. The other is a user's role while an occupant of a room -- e.g., an occupant's position as a moderator with the ability to kick visitors and participants. These two dimensions are distinct from each other, since an affiliation lasts across visits, while a role lasts only for the duration of a visit. In addition, there is no one-to-one correspondence between roles and affiliations; for example, someone who is not affiliated with a room may be a (temporary) moderator, and a member may be a participant or a visitor in a moderated room. These concepts are explained more fully below.</p>
|
||||
<section1 topic='Roles, Affiliations, and Privileges' anchor='associations'>
|
||||
<p>A user might be allowed to perform any number of actions in a room, from joining or sending a message to changing configuration options or destroying the room altogether. We call each permitted action a "privilege". There are two ways we might structure privileges:</p>
|
||||
<ol>
|
||||
<li><p>Define each privilege atomically and explicitly define each user's particular privileges; this is flexible but can be confusing to manage.</p></li>
|
||||
<li><p>Define bundles of privileges that are generally applicable and assign a user-friendly "shortcut" to each bundle (e.g., "moderator" or "admin").</p></li>
|
||||
</ol>
|
||||
<p>MUC takes the second approach.</p>
|
||||
<p>MUC also defines two different associations: long-lived affiliations and session-specific roles. These two association types are distinct from each other in MUC, since an affiliation lasts across visits, while a role lasts only for the duration of a visit. In addition, there is no one-to-one correspondence between roles and affiliations; for example, someone who is not affiliated with a room may be a (temporary) moderator, and a member may be a participant or a visitor in a moderated room. These concepts are explained more fully below.</p>
|
||||
<section2 topic='Roles' anchor='roles'>
|
||||
<p>The following roles are defined:</p>
|
||||
<table caption='Roles'>
|
||||
@ -577,9 +596,9 @@
|
||||
</table>
|
||||
<p>Roles are temporary in that they do not necessarily persist across a user's visits to the room and MAY change during the course of an occupant's visit to the room. An implementation MAY persist roles across visits and SHOULD do so for moderated rooms (since the distinction between visitor and participant is critical to the functioning of a moderated room).</p>
|
||||
<p>There is no one-to-one mapping between roles and affiliations (e.g., a member could be a participant or a visitor).</p>
|
||||
<p>A moderator is the most powerful occupant within the context of the room, and can to some extent manage other occupants' roles in the room. A participant has fewer privileges than a moderator, although he or she always has the right to speak. A visitor is a more restricted role within the context of a moderated room, since visitors are not allowed to send messages to all occupants.</p>
|
||||
<p>A moderator is the most powerful occupant within the context of the room, and can to some extent manage other occupants' roles in the room. A participant has fewer privileges than a moderator, although he or she always has the right to speak. A visitor is a more restricted role within the context of a moderated room, since visitors are not allowed to send messages to all occupants (depending on room configuration, it is even possible that visitors' presence will not be broadcast to the room).</p>
|
||||
<p>Roles are granted, revoked, and maintained based on the occupant's room nickname or full JID rather than bare JID. The privileges associated with these roles, as well as the actions that trigger changes in roles, are defined below.</p>
|
||||
<p>Information about roles MUST be sent in all presence stanzas generated or reflected by the room and thus sent to occupants.</p>
|
||||
<p>Information about roles MUST be sent in all presence stanzas generated or reflected by the room and thus sent to occupants (if the room is configured to broadcast presence for a given role).</p>
|
||||
<section3 topic='Privileges' anchor='roles-priv'>
|
||||
<p>For the most part, roles exist in a hierarchy. For instance, a participant can do anything a visitor can do, and a moderator can do anything a participant can do. Each role has privileges not possessed by the next-lowest role; these privileges are specified in the following table as defaults (an implementation MAY provide configuration options that override these defaults).</p>
|
||||
<table caption='Privileges Associated With Roles'>
|
||||
@ -612,7 +631,7 @@
|
||||
<td>Yes</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Presence Broadcasted to Room</td>
|
||||
<td>Broadcast Presence to All Occupants</td>
|
||||
<td>No</td>
|
||||
<td>Yes*</td>
|
||||
<td>Yes</td>
|
||||
@ -621,7 +640,7 @@
|
||||
<tr>
|
||||
<td>Change Availability Status</td>
|
||||
<td>No</td>
|
||||
<td>Yes</td>
|
||||
<td>Yes*</td>
|
||||
<td>Yes</td>
|
||||
<td>Yes</td>
|
||||
</tr>
|
||||
@ -687,7 +706,7 @@
|
||||
<p>*** A moderator MUST NOT be able to revoke voice privileges from an admin or owner.</p>
|
||||
</section3>
|
||||
<section3 topic='Changing Roles' anchor='roles-change'>
|
||||
<p>The ways in which an occupant's role changes are well-defined. Sometimes the change results from the occupant's own action (e.g., entering or exiting the room), whereas sometimes the change results from an action taken by a moderator, admin, or owner. If an occupant's role changes, a MUC service implementation MUST change the occupant's role to reflect the change and communicate the change to all occupants. Role changes and their triggering actions are specified in the following table.</p>
|
||||
<p>The ways in which an occupant's role changes are well-defined. Sometimes the change results from the occupant's own action (e.g., entering or exiting the room), whereas sometimes the change results from an action taken by a moderator, admin, or owner. If an occupant's role changes, a MUC service implementation MUST change the occupant's role to reflect the change and communicate the change to all occupants (if the room is configured to broadcast presence for a given role). Role changes and their triggering actions are specified in the following table.</p>
|
||||
<table caption='Role State Chart'>
|
||||
<tr>
|
||||
<th>></th>
|
||||
@ -719,14 +738,14 @@
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Moderator</td>
|
||||
<td>Exit room</td>
|
||||
<td>Exit room or be kicked by an admin or owner</td>
|
||||
<td>Admin or owner changes role to visitor *</td>
|
||||
<td>Admin or owner changes role to participant or revokes moderator privileges *</td>
|
||||
<td>--</td>
|
||||
</tr>
|
||||
</table>
|
||||
<p>* A moderator MUST NOT be able to revoke moderator privileges from an occupant who is equal to or above the moderator in the hierarchy of affiliations.</p>
|
||||
<p class='box'>Note: Certain roles are typically implicit in certain privileges. For example, an admin or owner is automatically a moderator, so if an occupant is granted admin status then the occupant will by that fact be granted moderator privileges; similarly, when an occupant is made a member in a moderated room, the occupant automatically has a role of participant. However, the loss of admin status does not necessarily mean that the occupant is no longer a moderator (since a "mere" participant can be a moderator). Therefore, the roles that are gained when an occupant is granted a certain affiliation are stable, whereas the roles that are lost when an occupant loses a certain affilitation are no hardcoded and are left up to the implementation. Since a client cannot predict what the role will be after revoking a certain affiliation, if it wants to remove both admin/owner privileges and the moderator role at the same time then it must specifically request the role change in addition to the affiliation change.</p>
|
||||
<p class='box'>Note: Certain roles are typically implicit in certain affiliations. For example, an admin or owner is automatically a moderator, so if an occupant is granted an affiliation of admin then the occupant will by that fact be granted a role of moderator; similarly, when an occupant is granted an affiliation of member in a moderated room, the occupant automatically has a role of participant. However, the loss of the admin affiliation does not necessarily mean that the occupant no longer has a role of moderator (since a "mere" participant can be a moderator). Therefore, the role that is gained when an occupant is granted a certain affiliation is stable, whereas the role that is lost when an occupant loses a certain affilitation is not hardcoded and is left up to the implementation. Since a client cannot predict what the role will be after revoking a certain affiliation, if it wants to remove both the admin/owner affiliation and the moderator role at the same time then it must specifically request the role change in addition to the affiliation change by including both the 'role' attribute and the 'affiliation' attribute.</p>
|
||||
</section3>
|
||||
</section2>
|
||||
<section2 topic='Affiliations' anchor='affil'>
|
||||
@ -738,12 +757,12 @@
|
||||
<li>Outcast</li>
|
||||
<li>None (the absence of an affiliation)</li>
|
||||
</ol>
|
||||
<p>Support for the Owner affiliation is REQUIRED. Support for the Admin, Member, and Outcast affiliations is RECOMMENDED. (The "None" affiliation is the absence of an affiliation.)</p>
|
||||
<p>These affiliations are long-lived in that they persist across a user's visits to the room and are not affected by happenings in the room. In addition, there is no one-to-one mapping between these affiliations and an occupant's role within the room. Affiliations are granted, revoked, and maintained based on the user's bare JID.</p>
|
||||
<p>Support for the owner affiliation is REQUIRED. Support for the admin, member, and outcast affiliations is RECOMMENDED. (The "None" affiliation is the absence of an affiliation.)</p>
|
||||
<p>These affiliations are long-lived in that they persist across a user's visits to the room and are not affected by happenings in the room. In addition, there is no one-to-one mapping between these affiliations and an occupant's role within the room. Affiliations are granted, revoked, and maintained based on the user's bare JID (not the full JID as with roles).</p>
|
||||
<p>If a user without a defined affiliation enters a room, the user's affiliation is defined as "none"; however, this affiliation does not persist across visits (i.e., a service does not maintain a "none list" across visits).</p>
|
||||
<p>The member affiliation provides a way for a room owner or admin to specify a "whitelist" of users who are allowed to enter a members-only room. When a member enters a members-only room, his or her affiliation does not change, no matter what his or her role is. The member affiliation also provides a way for users to effectively register with an open room and thus be lastingly associated with that room in some way (one result may be that the user's nickname is reserved in the room).</p>
|
||||
<p>An outcast is a user who has been banned from a room and who is not allowed to enter the room.</p>
|
||||
<p>Information about affiliations MUST be sent in all presence stanzas generated or reflected by the room and sent to occupants.</p>
|
||||
<p>Information about affiliations MUST be sent in all presence stanzas generated or reflected by the room and sent to occupants (if the room is configured to broadcast presence for a given role).</p>
|
||||
<section3 topic='Privileges' anchor='affil-priv'>
|
||||
<p>For the most part, affiliations exist in a hierarchy. For instance, an owner can do anything an admin can do, and an admin can do anything a member can do. Each affiliation has privileges not possessed by the next-lowest affiliation; these privileges are specified in the following table.</p>
|
||||
<table caption='Privileges Associated With Affiliations'>
|
||||
@ -774,7 +793,7 @@
|
||||
<tr>
|
||||
<td>Retrieve Member List</td>
|
||||
<td>No</td>
|
||||
<td>No**</td>
|
||||
<td>No</td>
|
||||
<td>Yes</td>
|
||||
<td>Yes</td>
|
||||
<td>Yes</td>
|
||||
@ -828,7 +847,7 @@
|
||||
<td>Yes</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Change Room Definition</td>
|
||||
<td>Change Room Configuration</td>
|
||||
<td>No</td>
|
||||
<td>No</td>
|
||||
<td>No</td>
|
||||
@ -848,7 +867,7 @@
|
||||
<p>** An admin or owner MUST NOT be able to revoke moderation privileges from another admin or owner.</p>
|
||||
</section3>
|
||||
<section3 topic='Changing Affiliations' anchor='affil-change'>
|
||||
<p>The ways in which a user's affiliation changes are well-defined. Sometimes the change results from the user's own action (e.g., registering as a member of the room), whereas sometimes the change results from an action taken by an admin or owner. If a user's affiliation changes, a MUC service implementation MUST change the user's affiliation to reflect the change and communicate that to all occupants. Affiliation changes and their triggering actions are specified in the following table.</p>
|
||||
<p>The ways in which a user's affiliation changes are well-defined. Sometimes the change results from the user's own action (e.g., registering as a member of the room), whereas sometimes the change results from an action taken by an admin or owner. If a user's affiliation changes, a MUC service implementation MUST change the user's affiliation to reflect the change and communicate that to all occupants (if the room is configured to broadcast presence for a given role). Affiliation changes and their triggering actions are specified in the following table.</p>
|
||||
<table caption='Affiliation State Chart'>
|
||||
<tr>
|
||||
<th>></th>
|
||||
@ -903,39 +922,38 @@
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Entity Use Cases' anchor='entity'>
|
||||
<p>A MUC implementation MUST support &xep0030;.</p>
|
||||
<p>A MUC implementation MUST support &xep0030; ("disco"). Any entity can complete the following disco-related use cases.</p>
|
||||
<section2 topic='Discovering Component Support for MUC' anchor='disco-component'>
|
||||
<p>A Jabber entity may wish to discover if a service implements the Multi-User Chat protocol; in order to do so, it sends a service discovery information ("disco#info") query to the component's JID:</p>
|
||||
<example caption='User Queries Chat Service for MUC Support via Disco'><![CDATA[
|
||||
<p>An entity may wish to discover if a service implements the Multi-User Chat protocol; in order to do so, it sends a service discovery information ("disco#info") query to the component's JID.</p>
|
||||
<example caption='Entity Queries Chat Service for MUC Support via Disco'><![CDATA[
|
||||
<iq from='hag66@shakespeare.lit/pda'
|
||||
id='disco1'
|
||||
id='lx09df27'
|
||||
to='chat.shakespeare.lit'
|
||||
type='get'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>The service MUST return its identity and the features it supports:</p>
|
||||
<p>The service MUST return its identity and the features it supports.</p>
|
||||
<example caption='Service Returns Disco Info Results'><![CDATA[
|
||||
<iq from='chat.shakespeare.lit'
|
||||
id='disco1'
|
||||
id='lx09df27'
|
||||
to='hag66@shakespeare.lit/pda'
|
||||
type='result'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'>
|
||||
<identity
|
||||
category='conference'
|
||||
name='Macbeth Chat Service'
|
||||
name='Shakespearean Chat Service'
|
||||
type='text'/>
|
||||
<feature var='http://jabber.org/protocol/muc'/>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>Note: Because MUC is a superset of the old "groupchat 1.0" protocol, a MUC service SHOULD NOT return a <feature var='gc-1.0'/> entry in a disco#info result.</p>
|
||||
</section2>
|
||||
<section2 topic='Discovering Rooms' anchor='disco-rooms'>
|
||||
<p>The service discovery items ("disco#items") protocol enables a user to query a service for a list of associated items, which in the case of a chat service would consist of the specific chat rooms hosted by the service.</p>
|
||||
<example caption='User Queries Chat Service for Rooms'><![CDATA[
|
||||
<p>The service discovery items ("disco#items") protocol enables an entity to query a service for a list of associated items, which in the case of a chat service would consist of the specific chat rooms hosted by the service.</p>
|
||||
<example caption='Entity Queries Chat Service for Rooms'><![CDATA[
|
||||
<iq from='hag66@shakespeare.lit/pda'
|
||||
id='disco2'
|
||||
id='zb8q41f4'
|
||||
to='chat.shakespeare.lit'
|
||||
type='get'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#items'/>
|
||||
@ -944,7 +962,7 @@
|
||||
<p>The service SHOULD return a full list of the rooms it hosts.</p>
|
||||
<example caption='Service Returns Disco Item Results'><![CDATA[
|
||||
<iq from='chat.shakespeare.lit'
|
||||
id='disco2'
|
||||
id='zb8q41f4'
|
||||
to='hag66@shakespeare.lit/pda'
|
||||
type='result'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#items'>
|
||||
@ -959,26 +977,26 @@
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>If the full list of rooms is large (see <cite>XEP-0030</cite> for details), the service MAY return only a partial list of rooms. If it does so, it SHOULD include a <set/> element (as defined in &xep0059;) to indicate that the list not the full result set.</p>
|
||||
<p>If the full list of rooms is large (see <cite>XEP-0030</cite> for details), the service MAY return only a partial list of rooms. If it does so, it SHOULD include a <set/> element qualified by the 'http://jabber.org/protocol/rsm' namespace (as defined in &xep0059;) to indicate that the list not the full result set.</p>
|
||||
<example caption='Service Returns Limited List of Disco Item Results'><![CDATA[
|
||||
<iq from='rooms.shakespeare.lit'
|
||||
id='disco-rsm-1'
|
||||
<iq from='chat.shakespeare.lit'
|
||||
id='hx51v49s'
|
||||
to='hag66@shakespeare.lit/pda'
|
||||
type='result'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#items'>
|
||||
<item jid='alls-well-that-ends-well@rooms.shakespeare.lit'/>
|
||||
<item jid='as-you-like-it@rooms.shakespeare.lit'/>
|
||||
<item jid='cleopatra@rooms.shakespeare.lit'/>
|
||||
<item jid='comedy-of-errors@rooms.shakespeare.lit'/>
|
||||
<item jid='coriolanus@rooms.shakespeare.lit'/>
|
||||
<item jid='cymbeline@rooms.shakespeare.lit'/>
|
||||
<item jid='hamlet@rooms.shakespeare.lit'/>
|
||||
<item jid='henry-the-fourth-one@rooms.shakespeare.lit'/>
|
||||
<item jid='henry-the-fourth-two@rooms.shakespeare.lit'/>
|
||||
<item jid='henry-the-fifth@rooms.shakespeare.lit'/>
|
||||
<item jid='alls-well-that-ends-well@chat.shakespeare.lit'/>
|
||||
<item jid='as-you-like-it@chat.shakespeare.lit'/>
|
||||
<item jid='cleopatra@chat.shakespeare.lit'/>
|
||||
<item jid='comedy-of-errors@chat.shakespeare.lit'/>
|
||||
<item jid='coriolanus@chat.shakespeare.lit'/>
|
||||
<item jid='cymbeline@chat.shakespeare.lit'/>
|
||||
<item jid='hamlet@chat.shakespeare.lit'/>
|
||||
<item jid='henry-the-fourth-one@chat.shakespeare.lit'/>
|
||||
<item jid='henry-the-fourth-two@chat.shakespeare.lit'/>
|
||||
<item jid='henry-the-fifth@chat.shakespeare.lit'/>
|
||||
<set xmlns='http://jabber.org/protocol/rsm'>
|
||||
<first index='0'>alls-well-that-ends-well@rooms.shakespeare.lit</first>
|
||||
<last>henry-the-fifth@rooms.shakespeare.lit</last>
|
||||
<first index='0'>alls-well-that-ends-well@chat.shakespeare.lit</first>
|
||||
<last>henry-the-fifth@chat.shakespeare.lit</last>
|
||||
<count>37</count>
|
||||
</set>
|
||||
</query>
|
||||
@ -986,10 +1004,10 @@
|
||||
]]></example>
|
||||
</section2>
|
||||
<section2 topic='Querying for Room Information' anchor='disco-roominfo'>
|
||||
<p>Using the disco#info protocol, a user may also query a specific chat room for more detailed information about the room. A user SHOULD do so before entering a room in order to determine the privacy and security profile of the room configuration (see the <link url='#security'>Security Considerations</link> for details).</p>
|
||||
<example caption='User Queries for Information about a Specific Chat Room'><![CDATA[
|
||||
<p>Using the disco#info protocol, an entity may also query a specific chat room for more detailed information about the room. An entity SHOULD do so before entering a room in order to determine the privacy and security profile of the room configuration (see the <link url='#security'>Security Considerations</link> for details).</p>
|
||||
<example caption='Entity Queries for Information about a Specific Chat Room'><![CDATA[
|
||||
<iq from='hag66@shakespeare.lit/pda'
|
||||
id='disco3'
|
||||
id='ik3vs715'
|
||||
to='darkcave@chat.shakespeare.lit'
|
||||
type='get'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'/>
|
||||
@ -998,7 +1016,7 @@
|
||||
<p>The room MUST return its identity and SHOULD return the features it supports:</p>
|
||||
<example caption='Room Returns Disco Info Results'><![CDATA[
|
||||
<iq from='darkcave@chat.shakespeare.lit'
|
||||
id='disco3'
|
||||
id='ik3vs715'
|
||||
to='hag66@shakespeare.lit/pda'
|
||||
type='result'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'>
|
||||
@ -1016,11 +1034,11 @@
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>Note: Because MUC is a superset of the old "groupchat 1.0" protocol, a MUC room SHOULD NOT return a <feature var='gc-1.0'/> entry in a disco#info result. The room SHOULD return the materially-relevant features it supports, such as password protection and room moderation (these are listed fully in the feature registry maintained by the XMPP Registrar; see also the <link url='#registrar'>XMPP Registrar</link> section of this document).</p>
|
||||
<p>Note: The room SHOULD return the materially-relevant features it supports, such as password protection and room moderation (these are listed fully in the feature registry maintained by the XMPP Registrar; see also the <link url='#registrar'>XMPP Registrar</link> section of this document).</p>
|
||||
<p>A chatroom MAY return more detailed information in its disco#info response using &xep0128;, identified by inclusion of a hidden FORM_TYPE field whose value is "http://jabber.org/protocol/muc#roominfo". Such information might include a more verbose description of the room, the current room subject, and the current number of occupants in the room:</p>
|
||||
<example caption='Room Returns Extended Disco Info Results'><![CDATA[
|
||||
<iq from='darkcave@chat.shakespeare.lit'
|
||||
id='disco3a'
|
||||
id='ik3vs715'
|
||||
to='hag66@shakespeare.lit/pda'
|
||||
type='result'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'>
|
||||
@ -1042,13 +1060,13 @@
|
||||
<field var='muc#roominfo_description' label='Description'>
|
||||
<value>The place for all good witches!</value>
|
||||
</field>
|
||||
<field var='muc#roominfo_changesubject' label='Whether Occupants May Change the Subject'>
|
||||
<field var='muc#roominfo_changesubject' label='Occupants May Change the Subject'>
|
||||
<value>true</value>
|
||||
</field>
|
||||
<field var='muc#roominfo_contactjid' label='Contact Addresses'>
|
||||
<value>crone1@shakespeare.lit</value>
|
||||
</field>
|
||||
<field var='muc#roominfo_subject' label='Subject'>
|
||||
<field var='muc#roominfo_subject' label='Current Discussion Topic'>
|
||||
<value>Spells</value>
|
||||
</field>
|
||||
<field var='muc#roomconfig_changesubject' label='Subject can be modified'>
|
||||
@ -1073,23 +1091,23 @@
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>Some extended room information may be dynamically generated (e.g., the URL for discussion logs, which may be based on service-wide configuration). Other information may be based on the room configuration, which is why any field defined for the <link url='#registrar-formtype-owner'>muc#roomconfig FORM_TYPE</link> can be included in the extended service discovery fields (as shown above for the muc#roomconfig_changesubject field).</p>
|
||||
<p>Note: The foregoing extended service discovery fields for the 'http://jabber.org/protocol/muc#roominfo' FORM_TYPE may be supplemented in the future via the mechanisms described in the <link url="#registrar-formtype">Field Standardization</link> section of this document.</p>
|
||||
<p>Some extended room information is dynamically generated (e.g., the URL for discussion logs, which may be based on service-wide configuration), whereas other information is based on the more-stable room configuration, which is why any field defined for the <link url='#registrar-formtype-owner'>muc#roomconfig FORM_TYPE</link> can be included in the extended service discovery fields (as shown above for the muc#roomconfig_changesubject field).</p>
|
||||
<p>Note: The foregoing extended service discovery fields for the 'http://jabber.org/protocol/muc#roominfo' FORM_TYPE are examples only and might be supplemented in the future via the mechanisms described in the <link url="#registrar-formtype">Field Standardization</link> section of this document.</p>
|
||||
</section2>
|
||||
<section2 topic='Querying for Room Items' anchor='disco-roomitems'>
|
||||
<p>A user MAY also query a specific chat room for its associated items:</p>
|
||||
<example caption='User Queries for Items Associated with a Specific Chat Room'><![CDATA[
|
||||
<p>An entity MAY also query a specific chat room for its associated items:</p>
|
||||
<example caption='Entity Queries for Items Associated with a Specific Chat Room'><![CDATA[
|
||||
<iq from='hag66@shakespeare.lit/pda'
|
||||
id='disco4'
|
||||
id='kl2fax27'
|
||||
to='darkcave@chat.shakespeare.lit'
|
||||
type='get'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#items'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>An implementation MAY return a list of existing occupants if that information is publicly available, or return no list at all if this information is kept private.</p>
|
||||
<p>An implementation MAY return a list of existing occupants if that information is publicly available, or return no list at all if this information is kept private. Implementations and deployments are advised to turn off such information sharing by default.</p>
|
||||
<example caption='Room Returns Disco Item Results (Items are Public)'><![CDATA[
|
||||
<iq from='darkcave@chat.shakespeare.lit'
|
||||
id='disco4'
|
||||
id='kl2fax27'
|
||||
to='hag66@shakespeare.lit/pda'
|
||||
type='result'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#items'>
|
||||
@ -1099,9 +1117,10 @@
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>Note: These <item/> elements are qualified by the disco#items namespace, not the muc namespace; this means that they cannot possess 'affiliation' or 'role' attributes, for example.</p>
|
||||
<p>If the list of occupants is private, the room MUST return an empty &QUERY; element, in accordance with <cite>XEP-0030</cite>.</p>
|
||||
<example caption='Room Returns Empty Disco Item Results (Items are Private)'><![CDATA[
|
||||
<iq from='darkcave@chat.shakespeare.lit'
|
||||
id='disco4'
|
||||
id='kl2fax27'
|
||||
to='hag66@shakespeare.lit/pda'
|
||||
type='result'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#items'/>
|
||||
@ -1109,22 +1128,22 @@
|
||||
]]></example>
|
||||
</section2>
|
||||
<section2 topic='Querying a Room Occupant' anchor='disco-occupant'>
|
||||
<p>If a non-occupant attempts to send a disco request to an address of the form &ROOMJID;, a MUC service SHOULD return the request to the entity and specify a &badrequest; error condition. If an occupant sends such a request, the service MAY pass it through the intended recipient; see the <link url='#impl'>Implementation Guidelines</link> section of this document for details.</p>
|
||||
<p>If a non-occupant attempts to send a disco request to an address of the form &ROOMJID;, a MUC service MUST return a &badrequest; error. If an occupant sends such a request, the service MAY pass it through the intended recipient; see the <link url='#impl'>Implementation Guidelines</link> section of this document for details.</p>
|
||||
</section2>
|
||||
<section2 topic='Discovering Client Support for MUC' anchor='disco-client'>
|
||||
<p>A Jabber user may want to discover if one of the user's contacts supports the Multi-User Chat protocol. This is done using Service Discovery.</p>
|
||||
<example caption='User Queries Contact Regarding MUC Support'><![CDATA[
|
||||
<p>An entity might want to discover if one of the entity's contacts supports the Multi-User Chat protocol (e.g., before attempting to invite the contact to a room). This can be done using Service Discovery.</p>
|
||||
<example caption='Entity Queries Contact Regarding MUC Support'><![CDATA[
|
||||
<iq from='hag66@shakespeare.lit/pda'
|
||||
id='disco5'
|
||||
id='yh2fs843'
|
||||
to='wiccarocks@shakespeare.lit/laptop'
|
||||
type='get'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>The client SHOULD return its identity and the features it supports:</p>
|
||||
<p>The client SHOULD return its identity and the features it supports.</p>
|
||||
<example caption='Contact Returns Disco Info Results'><![CDATA[
|
||||
<iq from='wiccarocks@shakespeare.lit/laptop'
|
||||
id='disco5'
|
||||
id='yh2fs843'
|
||||
to='hag66@shakespeare.lit/pda'
|
||||
type='result'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'>
|
||||
@ -1137,10 +1156,10 @@
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>A user may also query a contact regarding which rooms the contact is in. This is done by querying the contact's full JID (<user@host/resource>) while specifying the well-known Service Discovery node 'http://jabber.org/protocol/muc#rooms':</p>
|
||||
<example caption='User Queries Contact for Current Rooms'><![CDATA[
|
||||
<p>An entity may also query a contact regarding which rooms the contact is in. This is done by querying the contact's full JID (<user@host/resource>) while specifying the well-known Service Discovery node 'http://jabber.org/protocol/muc#rooms'.</p>
|
||||
<example caption='Entity Queries Contact for Current Rooms'><![CDATA[
|
||||
<iq from='hag66@shakespeare.lit/pda'
|
||||
id='rooms1'
|
||||
id='gp7w61v3'
|
||||
to='wiccarocks@shakespeare.lit/laptop'
|
||||
type='get'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#items'
|
||||
@ -1149,7 +1168,7 @@
|
||||
]]></example>
|
||||
<example caption='Contact Returns Room Query Results'><![CDATA[
|
||||
<iq from='wiccarocks@shakespeare.lit/laptop'
|
||||
id='rooms1'
|
||||
id='gp7w61v3'
|
||||
to='hag66@shakespeare.lit/pda'
|
||||
type='result'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#items'
|
||||
@ -1166,6 +1185,7 @@
|
||||
name='secondwitch'/>
|
||||
...
|
||||
]]></code>
|
||||
<p>If this information is private, the user MUST return an empty &QUERY; element, in accordance with <cite>XEP-0030</cite>.</p>
|
||||
</section2>
|
||||
</section1>
|
||||
<section1 topic='Occupant Use Cases' anchor='user'>
|
||||
@ -1175,11 +1195,11 @@
|
||||
<li><p>straightforward applications of the "groupchat 1.0" protocol, for example to handle some of the errors related to new room types</p></li>
|
||||
<li><p>additional protocol elements to handle functionality not covered by "groupchat 1.0" (room invites, room passwords, extended presence related to room roles and affiliations); these are qualified by the 'http://jabber.org/protocol/muc#user' namespace</p></li>
|
||||
</ol>
|
||||
<p>Note: All client-generated examples herein are presented from the perspective of the service, with the result that all stanzas received by a service contain a 'from' attribute corresponding to the sender's full JID as added by a normal Jabber router or session manager. In addition, normal IQ result stanzas sent upon successful completion of a request (as required by &rfc3920;) are not shown.</p>
|
||||
<p>Note: All client-generated examples herein are presented from the perspective of the service, with the result that all stanzas received by a service contain a 'from' attribute corresponding to the sender's full JID as added by a normal XMPP router or session manager. In addition, normal IQ result stanzas sent upon successful completion of a request (as required by &rfc3920;) are not shown.</p>
|
||||
<section2 topic='Entering a Room' anchor='enter'>
|
||||
<section3 topic='Groupchat 1.0 Protocol' anchor='enter-gc'>
|
||||
<p>In order to participate in the discussions held in a multi-user chat room, a Jabber user MUST first become an occupant by entering the room. In the old "groupchat 1.0" protocol, this was done by sending presence to &ROOMJID;, where "room" is the room ID, "service" is the hostname of the chat service, and "nick" is the user's desired nickname within the room:</p>
|
||||
<example caption='Jabber User Seeks to Enter a Room (Groupchat 1.0)'><![CDATA[
|
||||
<p>In order to participate in the discussions held in a multi-user chat room, a user MUST first become an occupant by entering the room. In the old "groupchat 1.0" protocol, this was done by sending presence to &ROOMJID;, where "room" is the room ID, "service" is the hostname of the chat service, and "nick" is the user's desired nickname within the room:</p>
|
||||
<example caption='User Seeks to Enter a Room (Groupchat 1.0)'><![CDATA[
|
||||
<presence
|
||||
from='hag66@shakespeare.lit/pda'
|
||||
to='darkcave@chat.shakespeare.lit/thirdwitch'/>
|
||||
@ -1198,8 +1218,8 @@
|
||||
]]></example>
|
||||
</section3>
|
||||
<section3 topic='Basic MUC Protocol' anchor='enter-muc'>
|
||||
<p>Compliant multi-user chat services MUST accept the foregoing as a request to enter a room from any Jabber client that knows either the "groupchat 1.0" (GC) protocol or the multi-user chat (MUC) protocol; however, MUC clients SHOULD signal their ability to speak the MUC protocol by including in the initial presence stanza an empty <x/> element qualified by the 'http://jabber.org/protocol/muc' namespace (note the absence of the '#user' fragment):</p>
|
||||
<example caption='Jabber User Seeks to Enter a Room (Multi-User Chat)'><![CDATA[
|
||||
<p>Compliant multi-user chat services MUST accept the foregoing as a request to enter a room from any client that knows either the "groupchat 1.0" (GC) protocol or the multi-user chat (MUC) protocol; however, MUC clients SHOULD signal their ability to speak the MUC protocol by including in the initial presence stanza an empty <x/> element qualified by the 'http://jabber.org/protocol/muc' namespace (note the absence of the '#user' fragment):</p>
|
||||
<example caption='User Seeks to Enter a Room (Multi-User Chat)'><![CDATA[
|
||||
<presence
|
||||
from='hag66@shakespeare.lit/pda'
|
||||
to='darkcave@chat.shakespeare.lit/thirdwitch'>
|
||||
@ -1741,7 +1761,7 @@
|
||||
<p>The user SHOULD then discover its reserved nickname as specified in the <link url='#reservednick'>Discovering Reserved Room Nickname</link> section of this document.</p>
|
||||
</section2>
|
||||
<section2 topic='Changing Availability Status' anchor='changepres'>
|
||||
<p>In multi-user chat systems such as IRC, one common use for changing one's room nickname is to indicate a change in one's availability (e.g., changing one's room nickname to "thirdwitch|away"). In Jabber, availability is of course noted by a change in presence (specifically the <show/> and <status/> elements), which can provide important context within a chatroom. An occupant changes availability status within the room by sending the updated presence to its &ROOMJID;.</p>
|
||||
<p>In multi-user chat systems such as IRC, one common use for changing one's room nickname is to indicate a change in one's availability (e.g., changing one's room nickname to "thirdwitch|away"). In XMPP, availability is of course noted by a change in presence (specifically the <show/> and <status/> elements), which can provide important context within a chatroom. An occupant changes availability status within the room by sending the updated presence to its &ROOMJID;.</p>
|
||||
<example caption='Occupant Changes Availability Status'><![CDATA[
|
||||
<presence
|
||||
from='wiccarocks@shakespeare.lit/laptop'
|
||||
@ -3251,7 +3271,7 @@
|
||||
]]></example>
|
||||
</section2>
|
||||
<section2 topic='Approving Registration Requests' anchor='regapprove'>
|
||||
<p>If a service does not automatically accept requests to register with a room, it MAY provide a way for room admins to approve or deny registration requests over Jabber (alternatively, it could provide a web interface or some other admin tool). The simplest way to do so is for the service to send a &MESSAGE; stanza to the room admin(s) when the registration request is received, where the &MESSAGE; stanza contains a Data Form asking for approval or denial of the request. The following Data Form is RECOMMENDED but implementations MAY use a different form entirely, or supplement the following form with additional fields.</p>
|
||||
<p>If a service does not automatically accept requests to register with a room, it MAY provide a way for room admins to approve or deny registration requests over XMPP (alternatively, it could provide a web interface or some other admin tool). The simplest way to do so is for the service to send a &MESSAGE; stanza to the room admin(s) when the registration request is received, where the &MESSAGE; stanza contains a Data Form asking for approval or denial of the request. The following Data Form is RECOMMENDED but implementations MAY use a different form entirely, or supplement the following form with additional fields.</p>
|
||||
<example caption='Registration Request Approval Form'><![CDATA[
|
||||
<message from='darkcave@chat.shakespeare.lit'
|
||||
id='approve'
|
||||
@ -3343,8 +3363,8 @@
|
||||
<li><p>Once the service receives the completed configuration form from the initial room owner (or receives a request for an instant room), the service MUST "unlock" the room (i.e., allow other users to enter the room) and send an IQ of type "result" to the room owner. If the service receives a cancellation, it MUST destroy the room.</p></li>
|
||||
</ol>
|
||||
<p>The protocol for this workflow is shown in the examples below.</p>
|
||||
<p>First, the Jabber user MUST send presence to the room, including an empty <x/> element qualified by the 'http://jabber.org/protocol/muc' namespace (this is the same stanza sent when seeking to enter a room).</p>
|
||||
<example caption='Jabber User Creates a Room and Signals Support for Multi-User Chat'><![CDATA[
|
||||
<p>First, the user MUST send presence to the room, including an empty <x/> element qualified by the 'http://jabber.org/protocol/muc' namespace (this is the same stanza sent when seeking to enter a room).</p>
|
||||
<example caption='User Creates a Room and Signals Support for Multi-User Chat'><![CDATA[
|
||||
<presence
|
||||
from='crone1@shakespeare.lit/desktop'
|
||||
to='darkcave@chat.shakespeare.lit/firstwitch'>
|
||||
@ -4533,6 +4553,10 @@
|
||||
<section2 topic='Privacy' anchor='security-privacy'>
|
||||
<p>Depending on room configuration, a room may publicly log all discussions held in the room. A service MUST warn the user that the room is publicly logged by returning a status code of "170" with the user's initial presence, and the user's client MUST so warn the user if the room discussion is logged (a user's client SHOULD also query the room for its configuration prior to allowing the user to enter in order to "pre-discover" whether the room is logged). A client MUST also warn the user if the room's configuration is subsequently modified to allow room logging (which the client will discover when the room sends status code 170). Note: In-room history is different from public room logging, and naturally a room cannot effectively prevent occupants from separately maintaining their own room logs, which may become public; users SHOULD exercise due caution and consider any room discussions to be effectively public.</p>
|
||||
</section2>
|
||||
<section2 topic='Information Leaks' anchor='security-leaks'>
|
||||
<p>The "roominfo" data form used in extended service discovery can result in information leaks, e.g., the current discussion topic (via the "roominfo_subject" field). The same is true of service discovery items (disco#items) requests from outside the room (which could be used to discover the list of room occupants).</p>
|
||||
<p>Implementations and deployments are advised to carefully consider the possibility that this information might be leaked, and to turn off information sharing by default for sensitive data.</p>
|
||||
</section2>
|
||||
<section2 topic='Anonymity' anchor='security-anon'>
|
||||
<p>Depending on room configuration, a room MAY expose each occupant's real JID to other occupants (if the room is non-anonymous) and will almost certainly expose each occupant's real JID to the room owners and administrators (if the room is not fully-anonymous). A service MUST warn the user that real JIDs are exposed in the room by returning a status code of "100" with the user's initial presence, and the user's client MUST so warn the user (a user's client SHOULD also query the room for its configuration prior to allowing the user to enter in order to "pre-discover" whether real JIDs are exposed in the room). A client MUST also warn the user if the room's configuration is subsequently modified from semi-anonymous or fully-anonymous to non-anonymous (which the client will discover when the room sends status code 172) and SHOULD warn the user if the room's configuration is subsequently modified from fully-anonymous to semi-anonymous (which the client will discover when the room sends status code 173).</p>
|
||||
</section2>
|
||||
@ -4855,7 +4879,7 @@
|
||||
<field
|
||||
var='muc#roominfo_subject'
|
||||
type='text-single'
|
||||
label='Current Subject or Discussion Topic in Room'/>
|
||||
label='Current Discussion Topic'/>
|
||||
<field
|
||||
var='muc#roominfo_subjectmod'
|
||||
type='boolean'
|
||||
@ -5121,7 +5145,7 @@ xmpp:darkcave@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=ca
|
||||
<section2 topic='Message' anchor='bizrules-message'>
|
||||
<ol start='1'>
|
||||
<li><p>If an occupant wants to send a message to all other occupants, a MUC client MUST set the 'type' attribute to a value of "groupchat". A service MAY ignore messages that are improperly typed, or reject them with a &badrequest; error.</p></li>
|
||||
<li><p>If a MUC service receives a message directed to the room or to a single occupant from a Jabber user who has a role of "none", the service MUST NOT deliver the message and SHOULD return the message to the sender with a &forbidden; error.</p></li>
|
||||
<li><p>If a MUC service receives a message directed to the room or to a single occupant from a user who has a role of "none", the service MUST NOT deliver the message and SHOULD return the message to the sender with a &forbidden; error.</p></li>
|
||||
<li><p>If a MUC service receives a message directed to a room that does not exist or is not yet unlocked, the service SHOULD return the message to the sender with an ¬found; error.</p></li>
|
||||
<li><p>A MUC service SHOULD pass extended information (e.g., an XHTML version of the message body) through to occupants unchanged; however, a MUC service MAY disallow message specific extensions (see the <link url='#impl-service-traffic'>Allowable Traffic</link> section of this document).</p></li>
|
||||
<li><p>A MUC client MAY generate extensions that conform to the &xep0022; or &xep0085; specification; however, a MUC service MAY disallow these extensions (see the <link url='#impl-service-traffic'>Allowable Traffic</link> section of this document).</p></li>
|
||||
@ -5132,7 +5156,7 @@ xmpp:darkcave@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=ca
|
||||
<li><p>A room MUST silently ignore unavailable presence received from a user who has a role of "none".</p></li>
|
||||
<li><p>Only the MUC service itself SHOULD generate extended presence information about roles, affiliations, full JIDs, or status codes qualified by the 'http://jabber.org/protocol/muc#user' namespace (based on information the service knows about occupants, e.g., roles, or as a result of actions taken by a moderator or room administrator). A client SHOULD NOT presume to generate such information. If a MUC service receives such extended presence information from an occupant, it MUST NOT reflect it to other occupants. (A client MAY generate extended presence information qualified by the 'http://jabber.org/protocol/muc#user' namespace in order to supply a password, but naturally this is not reflected to other occupants.)</p></li>
|
||||
<li><p>A MUC service SHOULD allow all other presence information to pass through, although it MAY choose to block extended presence information; see the <link url='#impl-service-traffic'>Allowable Traffic</link> section of this document.</p></li>
|
||||
<li><p>In order to appropriately inform occupants of room roles and affiliations, and to make it easier for Jabber clients to track the current state of all users in the room, MUC service implementations MUST provide extended presence information about roles and affiliations in all presence stanzas, including presence stanzas of type "unavailable" sent when a user exits the room for any reason.</p></li>
|
||||
<li><p>In order to appropriately inform occupants of room roles and affiliations, and to make it easier for clients to track the current state of all users in the room, MUC service implementations MUST provide extended presence information about roles and affiliations in all presence stanzas, including presence stanzas of type "unavailable" sent when a user exits the room for any reason.</p></li>
|
||||
<li><p>If a privilege is revoked, the service MUST note that by sending an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child element with the 'role' and/or 'affiliation' attributes set to a value that indicates the loss of the relevant privilege. All future presence stanzas for the occupant MUST include the updated role and affiliation, until and unless they change again.</p></li>
|
||||
<li><p>A MUC service MUST send extended presence to a client even if the client did not send an empty <x/> element qualified by the 'http://jabber.org/protocol/muc' namespace on entering the room; naturally, a client MUST ignore such information if it does not understand it (in accordance with <cite>RFC 3920</cite>).</p></li>
|
||||
<li><p>Extended presence about roles and affiliations sent in the muc#user namespace MUST include the full JID (not the bare JID) as the value of the 'jid' attribute.</p></li>
|
||||
@ -5161,7 +5185,7 @@ xmpp:darkcave@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=ca
|
||||
<li><p>There is no requirement that a MUC service shall provide special treatment for users of the older "groupchat 1.0" protocol, such as messages that contain equivalents to the extended presence information that is qualified by the 'http://jabber.org/protocol/muc#user' namespace.</p></li>
|
||||
<li><p>Room types MAY be configured in any combination. A MUC service MAY support or allow any desired room types or combinations thereof.</p></li>
|
||||
<li><p>A MUC service MAY limit the number of configuration options presented to an owner after initial configuration has been completed, e.g. because certain options cannot take effect without restarting the service.</p></li>
|
||||
<li><p>A MUC service MAY provide an interface to room creation and configuration (e.g., in the form of a special Jabber user or a Web page), so that the ostensible room owner is actually the application instead of a human user.</p></li>
|
||||
<li><p>A MUC service MAY provide an interface to room creation and configuration (e.g., in the form of a special XMPP entity or a Web page), so that the ostensible room owner is actually the application instead of a human user.</p></li>
|
||||
<li><p>A MUC service MAY choose to make available a special in-room resource that provides an interface to administrative functionality (e.g., a "user" named "ChatBot"), which occupants could interact with directly, thus enabling admins to type <tt>'/command parameter'</tt> in a private message to that "user". Obviously this kind of implementation would require the service to add a 'ChatBot' user to the room when it is created, and to prevent any occupant from having the nickname 'ChatBot' in the room. This might be difficult to ensure in some implementations or deployments. In any case, any such interface is OPTIONAL.</p></li>
|
||||
<li><p>A MUC service SHOULD remove a user if the service receives a delivery-related error in relation to a stanza it has previously sent to the user; the delivery-related errors are &gone;, ¬found;, &recipient;, &redirect;, &remoteserver;, and &timeout;.</p></li>
|
||||
<li><p>A MUC service MAY choose to discard extended presence information that is attached to a &PRESENCE; stanza before reflecting the presence change to the occupants of a room. That is, an implementation MAY choose to reflect only the <show/>, <status/>, and <priority/> child elements of the presence element as specified in the XML schema for the 'jabber:client' namespace, with the result that presence "changes" in extended namespaces (e.g., gabber:x:music:info) are not passed through to occupants. If a service prohibits certain extended namespaces, it SHOULD provide a description of allowable traffic at the well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic' as described in the <link url='#impl-service-traffic'>Allowable Traffic</link> section of this document.</p></li>
|
||||
@ -5209,11 +5233,11 @@ xmpp:darkcave@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=ca
|
||||
</section2>
|
||||
<section2 topic='Clients' anchor='impl-client'>
|
||||
<ol start='1'>
|
||||
<li><p>Jabber clients MAY present room roles by showing ad-hoc groups for each role within a room roster. This will enable occupants to clearly visualize which occupants are moderators, participants, and visitors. However, such a representation is OPTIONAL.</p></li>
|
||||
<li><p>Jabber clients MAY implement a variety of interface styles that provide "shortcuts" to functionality such as changing one's nickname, kicking or banning users, discovering an occupant's full JID, or changing the subject. One option consists of IRC-style commands such as '/nick', '/kick', '/ban', and '/whois'; another is to enable a user to right-click items in a room roster. All such interface styles are OPTIONAL. However, for convenience, a mapping of IRC commands to MUC protocols is provided below.</p></li>
|
||||
<li><p>Clients MAY present room roles by showing ad-hoc groups for each role within a room roster. This will enable occupants to clearly visualize which occupants are moderators, participants, and visitors. However, such a representation is OPTIONAL.</p></li>
|
||||
<li><p>Clients MAY implement a variety of interface styles that provide "shortcuts" to functionality such as changing one's nickname, kicking or banning users, discovering an occupant's full JID, or changing the subject. One option consists of IRC-style commands such as '/nick', '/kick', '/ban', and '/whois'; another is to enable a user to right-click items in a room roster. All such interface styles are OPTIONAL. However, for convenience, a mapping of IRC commands to MUC protocols is provided below.</p></li>
|
||||
</ol>
|
||||
<section3 topic='IRC Command Mapping' anchor='impl-client-irc'>
|
||||
<p>Internet Relay Chat clients use a number of common "shortcut" commands that begin with a forward slash, such as '/nick' and '/ban'. The following table provides a mapping of IRC-style commands to MUC protocols, for use by Jabber clients that wish to support such functionality.</p>
|
||||
<p>Internet Relay Chat clients use a number of common "shortcut" commands that begin with a forward slash, such as '/nick' and '/ban'. The following table provides a mapping of IRC-style commands to MUC protocols, for use by clients that wish to support such functionality.</p>
|
||||
<table caption='IRC Command Mapping'>
|
||||
<tr>
|
||||
<th>Command</th>
|
||||
@ -5311,8 +5335,8 @@ xmpp:darkcave@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=ca
|
||||
]]></code></td>
|
||||
</tr>
|
||||
</table>
|
||||
<p>Note: Because MUC roomnicks follow the Resourceprep profile of stringprep, they are allowed to contain a space character, whereas IRC nicknames do not. Although a given client MAY support quotation characters for this purpose (resulting in commands such as '/ban "king lear" insanity is no defense'), most common quotation characters (such as " and ') are also allowed by Resourceprep, thus leading to added complexity and potential problems with quotation of roomnicks that contain both spaces and quotation characters. Therefore it is NOT RECOMMENDED for Jabber clients to support IRC-style shortcut commands with roomnicks that contain space characters.</p>
|
||||
<p>Note: Many Jabber clients also implement a '/me ' command as described in &xep0245;. This command does not result in any MUC or IRC protocol action and is therefore not shown in the foregoing table.</p>
|
||||
<p>Note: Because MUC roomnicks follow the Resourceprep profile of stringprep, they are allowed to contain a space character, whereas IRC nicknames do not. Although a given client MAY support quotation characters for this purpose (resulting in commands such as '/ban "king lear" insanity is no defense'), most common quotation characters (such as " and ') are also allowed by Resourceprep, thus leading to added complexity and potential problems with quotation of roomnicks that contain both spaces and quotation characters. Therefore it is NOT RECOMMENDED for XMPP clients to support IRC-style shortcut commands with roomnicks that contain space characters.</p>
|
||||
<p>Note: Many XMPP clients also implement a '/me ' command as described in &xep0245;. This command does not result in any MUC or IRC protocol action and is therefore not shown in the foregoing table.</p>
|
||||
</section3>
|
||||
</section2>
|
||||
</section1>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user