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.
+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 service developers alike. Future specifications might address the topics mentioned above.
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:
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.)
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 nick (and thus implicitly the full JID) as with roles.
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).
-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 register with an open room and thus be lastingly associated with that room in some way (e.g., the user's nickname is reserved in the room).
+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 register with an open room and thus be lastingly associated with that room in some way (e.g., the user's nickname might be reserved in the room).
An outcast is a user who has been banned from a room and who is not allowed to enter the room.
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 from entities with a given role).
A MUC implementation MUST support &xep0030; ("disco"). Any entity can complete the following disco-related use cases.
-An entity often discovers a MUC component by sending a service discovery items ("disco#items") request to its own server.
+An entity often discovers a MUC service by sending a Service Discovery items ("disco#items") request to its own server.
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.
+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 MUC service's JID.
If the service is able to add the user to the room, it MUST send presence from all the existing occupants' room JIDs to the new occupant's full JID, including extended presence information about roles in a single <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'role' attribute set to a value of "moderator", "participant", or "visitor", and with the 'affiliation' attribute set to a value of "owner", "admin", "member", or "none" as appropriate.
If the service is able to add the user to the room, it MUST send presence from all the existing participants' occupant JIDs to the new occupant's full JID, including extended presence information about roles in a single <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'role' attribute set to a value of "moderator", "participant", or "visitor", and with the 'affiliation' attribute set to a value of "owner", "admin", "member", or "none" as appropriate.
In this example, the user from the previous example has entered the room, by which time two other people had already entered the room: a user with a room nickname of "firstwitch" (who is a room owner) and a user with a room nickname of "secondwitch" (who is a room admin).
-Unless the room is configured to not broadcast presence from new occupants below a certain affiliation level (as controlled by the "muc#roomconfig_presencebroadcast" room configuration option), the service MUST also send presence from the new occupant's room JID to the full JIDs of all the occupants (including the new occupant).
+Unless the room is configured to not broadcast presence from new occupants below a certain affiliation level (as controlled by the "muc#roomconfig_presencebroadcast" room configuration option), the service MUST also send presence from the new participant's occupant JID to the full JIDs of all the occupants (including the new occupant).
Discussion history messages MUST be stamped with &xep0203; information qualified by the 'urn:xmpp:delay' namespace to indicate that they are sent with delayed delivery and to specify the times at which they were originally sent. The 'from' attribute MUST be set to the JID of the room itself.
(Note: The 'urn:xmpp:delay' namespace defined in XEP-0203 supersedes the older 'jabber:x:delay' namespace defined in &xep0091;; some implementations include both formats for backward compatibility.)
-The service MUST send all discussion history messages before delivering the room subject and any "live" messages sent after the user enters the room.
+The service MUST send all discussion history messages before delivering the room subject and any "live" messages sent after the user enters the room. Note well that this means the room subject (and changes to the room subject prior to the current subject) are not part of the discussion history.
If the room is non-anonymous, the service MAY include an &xep0033; element that notes the original full JID of the sender by means of the "ofrom" address type:
The service MUST send the smallest amount of traffic that meets any combination of the above criteria, taking into account service-level and room-level defaults. The service MUST send complete message stanzas only (i.e., it MUST not literally truncate the history at a certain number of characters, but MUST send the largest number of complete stanzas that results in a number of characters less than or equal to the 'maxchars' value specified). If the client wishes to receive no history, it MUST set the 'maxchars' attribute to a value of "0" (zero).
-Because not all service implementations support MUC history management, a client SHOULD NOT depend on receiving only the history that it has requested.
+Note: It is known that not all service implementations support MUC history management, so in practice a client might not be able depend on receiving only the history that it has requested.
The following examples illustrate the use of this feature.
After the room has optionally sent the discussion history to the new occupant, it SHALL send the current room subject. This is a &MESSAGE; stanza from the room itself (or from the room JID of the entity that set the subject), with a &SUBJECT; element but no &BODY; element, as shown in the following example.
+After the room has optionally sent the discussion history to the new occupant, it SHALL send the current room subject. This is a &MESSAGE; stanza from the room JID (or from the occupant JID of the entity that set the subject), with a &SUBJECT; element but no &BODY; element, as shown in the following example.