The server then returns the services that are associated with it.
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.
@@ -1053,7 +1053,7 @@ type='get'>The service MUST return its identity and the features it supports.
The service SHOULD return a full list of the public rooms it hosts (i.e., not return any rooms that are hidden).
If the full list of rooms is large (see XEP-0030 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 is not the full result set.
The room MUST return its identity and SHOULD return the features it supports:
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 XMPP Registrar section of this document).
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:
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 muc#roomconfig FORM_TYPE can be included in the extended service discovery fields (as shown above for the "muc#roomconfig_changesubject" field).
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 Field Standardization section of this document.
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.
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.
If the list of occupants is private, the room MUST return an empty &QUERY; element, in accordance with XEP-0030.
The client SHOULD return its identity and the features it supports.
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'.
Optionally, the contact MAY include its roomnick as the value of the 'name' attribute:
...
- ]]>
+]]>
If this information is private, the user MUST return an empty &QUERY; element, in accordance with XEP-0030.
In this example, a user with a full JID of "hag66@shakespeare.lit/pda" has requested to enter the room "coven" on the "chat.shakespeare.lit" chat service with a room nickname of "thirdwitch".
If the user does not specify a room nickname (note the bare JID on the 'from' address in the following example), the service MUST return a &badjid; error:
Note: The presence stanza used to join a room MUST NOT possess a 'type' attribute, i.e., it must be available presence. For further discussion, see the Presence business rules.
@@ -1383,7 +1383,7 @@ to='coven@chat.shakespeare.lit/thirdwitch'>Before attempting to enter the room, a MUC-compliant client SHOULD first discover its reserved room nickname (if any) by following the protocol defined in the Discovering Reserved Room Nickname section of this document.
@@ -1407,7 +1407,7 @@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 participant's occupant JID to the full JIDs of all the occupants (including the new occupant).
In this example, initial room presence is being sent from the new occupant (thirdwitch) to all occupants, including the new occupant.
As shown in the last stanza, the "self-presence" sent by the room to the new user MUST include a status code of 110 so that the user knows this presence refers to itself as an occupant. This self-presence MUST NOT be sent to the new occupant until the room has sent the presence of all other occupants to the new occupant; this enables the new occupant to know when it has finished receiving the room roster.
The service MAY rewrite the new occupant's roomnick (e.g., if roomnicks are locked down or based on some other policy).
@@ -1455,7 +1455,7 @@If the user has connected using a MUC client (as indicated on joining the room by inclusion of the MUC extension), then the service MUST allow the client to enter the room, modify the nick in accordance with the lockdown policy, and include a status code of "210" in the presence broadcast that it sends to the new occupant.
Note: The order of the presence stanzas sent to the new occupant is important. The service MUST first send the complete list of the existing occupants to the new occupant and only then send the new occupant's own presence to the new occupant. This helps the client know when it has received the complete "room roster". For tracking purposes, the room might also reflect the original 'id' value if provided in the presence stanza sent by the user.
After sending the presence broadcast (and only after doing so), the service MAY then send discussion history, the room subject, live messages, presence updates, and other in-room traffic.
@@ -1488,7 +1488,7 @@ [ ... ] - ]]> +]]>If the user is entering a room that is non-anonymous (i.e., which informs all occupants of each occupant's full JID as shown above), the service MUST warn the user by including a status code of "100" in the initial presence that the room sends to the new occupant:
The inclusion of the status code assists clients in presenting their own notification messages (e.g., information appropriate to the user's locality).
@@ -1524,7 +1524,7 @@Passwords SHOULD be supplied with the presence stanza sent when entering the room, contained within an <x/> element qualified by the 'http://jabber.org/protocol/muc' namespace and containing a <password/> child. Passwords are to be sent as cleartext; no other authentication methods are supported at this time, and any such authentication or authorization methods shall be defined in a separate specification (see the Security Considerations section of this document).
However, if the bare JID &LOCALBARE; of the present occupant matches the bare JID of the user seeking to enter the room, then the service SHOULD allow entry to the user, so that the user has two (or more) in-room "sessions" with the same roomnick, one for each resource. If a service allows more than one occupant with the same bare JID and the same room nickname, it MUST route in-room messages to all of the user's resources and allow all of the user's resources to send messages to the room; it is up to the implementation whether to route private messages to all resources or only one resource (based on presence priority or some other algorithm); however, it is RECOMMENDED to route to all resources.
How nickname conflicts are determined is up to the implementation (e.g., whether the service applies a case folding routine, a stringprep profile such as Resourceprep or Nodeprep, etc.).
Alternatively, the room could kick an "idle user" in order to free up space (where the definition of "idle user" is up to the implementation).
If the room has reached its maximum number of occupants and a room admin or owner attempts to join, the room MUST allow the admin or owner to join, up to some reasonable number of additional occupants; this helps to prevent denial of service attacks caused by stuffing the room with non-admin users.
@@ -1619,7 +1619,7 @@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. 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.
@@ -1698,7 +1698,7 @@ - ]]> +]]>Obviously the service SHOULD NOT return all messages sent in the room since the beginning of the Unix era, and SHOULD appropriately limit the amount of history sent to the user based on service or room defaults.
If there is no subject set, the room MUST return an empty &SUBJECT; element.
Note: In accordance with the core definition of XML stanzas, any message can contain a &SUBJECT; element; only a message that contains a &SUBJECT; but no &BODY; element shall be considered a subject change for MUC purposes.
If the sender has voice in the room (this is the default except in moderated rooms) and the message does not violate any service-level or room-level policies (e.g., policies regarding message content or size), the service MUST change the 'from' attribute to the sender's occupant JID and reflect the message out to the full JID of each occupant.
Note well that for tracking purposes this service assigns a new 'id' to each message it generates (here using a UUID as defined in &rfc4122;).
If the sender is a visitor (i.e., does not have voice in a moderated room), the service MUST return a &forbidden; error to the sender and MUST NOT reflect the message to all occupants. If the sender is not an occupant of the room, the service SHOULD return a ¬acceptable; error to the sender and SHOULD NOT reflect the message to all occupants; the only exception to this rule is that an implementation MAY allow users with certain privileges (e.g., a room owner, room admin, or service-level admin) to send messages to the room even if those users are not occupants.
@@ -1911,7 +1911,7 @@ type='chat'> I'll give thee a wind. - ]]> +]]>The service is responsible for changing the 'from' address to the sender's occupant JID and delivering the message to the intended recipient's full JID.
If the sender attempts to send a private message of type "groupchat" to a particular occupant, the service MUST refuse to deliver the message (since the recipient's client would expect in-room messages to be of type "groupchat") and return a &badrequest; error to the sender:
If the sender attempts to send a private message to an occupant JID that does not exist, the service MUST return an ¬found; error to the sender.
If the sender is not an occupant of the room in which the intended recipient is visiting, the service MUST return a ¬acceptable; error to the sender.
@@ -1954,7 +1954,7 @@ from='hag66@shakespeare.lit/pda' id='ifd1c35' to='coven@chat.shakespeare.lit/oldhag'/> - ]]> +]]>The service then sends two presence stanzas to the full JID of each occupant (including the occupant who is changing his or her room nickname), one of type "unavailable" for the old nickname and one indicating availability for the new nickname.
The unavailable presence MUST contain the following as extended presence information in an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace:
If the service modifies the user's nickname in accordance with local service policies, it MUST include a MUC status code of 210 in the presence stanza sent to the user. An example follows (here the service changes the nickname to all lowercase).
If the user attempts to change his or her room nickname to a room nickname that is already in use by another user (or that is reserved by another user affiliated with the room, e.g., a member or owner), the service MUST deny the nickname change request and inform the user of the conflict; this is done by returning a presence stanza of type "error" specifying a &conflict; error condition:
However, if the bare JID &LOCALBARE; of the present occupant matches the bare JID of the user seeking to change his or her nickname, then the service MAY allow the nickname change. See the Nickname Conflict section of this document for details.
If the user attempts to change their room nickname but nicknames are "locked down", the service MUST either deny the nickname change request and return a presence stanza of type "error" with a ¬acceptable; error condition:
The user SHOULD then discover its reserved nickname as specified in the Discovering Reserved Room Nickname section of this document.
@@ -2096,7 +2096,7 @@If the room is configured to broadcast presence from entities with the occupant's role, the service then sends a presence stanza from the occupant changing his or her presence to the full JID of each occupant, including extended presence information about the occupant's role and full JID to those with privileges to view such information:
The &ROOMJID; itself MUST then add a 'from' address to the <invite/> element whose value is the bare JID, full JID, or occupant JID of the inviter and send the invitation to the invitee specified in the 'to' address; the room SHOULD add the password if the room is password-protected):
If the room is members-only, the service MAY also add the invitee to the member list. (Note: Invitation privileges in members-only rooms SHOULD be restricted to room admins; if a member without privileges to edit the member list attempts to invite another user, the service SHOULD return a &forbidden; error to the occupant; for details, see the Modifying the Member List section of this document.)
If the inviter supplies a non-existent JID, the room SHOULD return an ¬found; error to the inviter.
The invitee MAY choose to formally decline (as opposed to ignore) the invitation; and this is something that the sender might want to be informed about. In order to decline the invitation, the invitee MUST send a message of the following form to the &ROOMJID; itself:
@@ -2173,7 +2173,7 @@ - ]]> +]]>It may be wondered why the invitee does not send the decline message directly to the inviter. The main reason is that certain implementations might choose to base invitations on occupant JIDs rather than bare JIDs (so that, for example, an occupant could invite someone from one room to another without knowing that person's bare JID). Thus the service needs to handle both the invites and declines.
@@ -2214,7 +2214,7 @@Now the first person decides to include a third person in the discussion, so she does the following:
Note: Use of the Delayed Delivery protocol enables the room creator to specify the datetime of each message from the one-to-one chat history (via the 'stamp' attribute), as well as the JID of the original sender of each message (via the 'from' attribute); note well that the 'from' here is not the room itself, since the originator of the message is the delaying party. The room creator might send the complete one-to-one chat history before inviting additional users to the room, and also send as history any messages appearing in the one-to-one chat interface after joining the room and before the second person joins the room; if the one-to-one history is especially large, the sending client might want to send the history over a few seconds rather than all at once (to avoid triggering rate limits). The service SHOULD NOT add its own delay elements (as described in the Discussion History section of this document) to prior chat history messages received from the room owner.
Note: Since the inviter's client knows the full JID of the person with whom the inviter was having a one-to-one chat, it SHOULD include the full JID (rather than the bare JID) in its invitation to that user.
The invitations are delivered to the invitees:
When the client being used by <wiccarocks@shakespeare.lit/laptop> receives the invitation, it can either auto-join the room or prompt the user whether to join (subject to user preferences) and then seamlessly convert the existing one-to-one chat window into a multi-user conferencing window:
If the room does not exist, the service MUST return an ¬found; error.
If the user requesting registration requirements is not allowed to register with the room (e.g., because that privilege has been restricted), the room MUST return a ¬allowed; error to the user.
If the user is already registered, as described in XEP-0077 the room MUST reply with an IQ stanza of type "result", which MUST contain an empty <registered/> element and SHOULD contain at least a <username/> element that specifies the user's registered nickname in the room.
Otherwise, the room MUST then return a Data Form to the user (as described in &xep0004;). The information required to register might vary by implementation or deployment and is not fully specified in this document (e.g., the fields registered by this document for the 'http://jabber.org/protocol/muc#register' FORM_TYPE might be supplemented in the future via the mechanisms described in the Field Standardization section of this document). The following can be taken as a fairly typical example:
The user SHOULD then submit the form:
If the desired room nickname is already reserved for that room, the room MUST return a &conflict; error to the user:
If the room or service does not support registration, it MUST return a &unavailable; error to the user:
If the user did not include a valid data form, the room MUST return a &badrequest; error to the user:
Otherwise, the room MUST inform the user that the registration request was successfully received:
After the user submits the form, the service MAY request that the submission be approved by a room admin/owner (see the Approving Registration Requests section of this document), MAY immediately add the user to the member list by changing the user's affiliation from "none" to "member", or MAY perform some service-specific checking (e.g., email verification).
If the service changes the user's affiliation and the user is in the room, it MUST send updated presence from this individual to all occupants, indicating the change in affiliation by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "member".
If the user's nickname is modified by the service as a result of registration and the user is in the room, the service SHOULD include status code "210" in the updated presence notification that it sends to all users.
If a user has registered with a room, the room MAY choose to restrict the user to use of the registered nickname only in that room. If it does so, it SHOULD modify the user's nickname to be the registered nickname (instead of returning a ¬acceptable; error) if the user attempts to join the room with a roomnick other than the user's registered roomnick (this enables a room to "lock down" roomnicks for consistent identification of occupants).
It is OPTIONAL for a multi-user chat service to support the foregoing service discovery node. If the room or service does not support the foregoing service discovery node, it MUST return a &feature; error to the user. If it does and the user has a registered nickname, it MUST return the nickname to the user as the value of the 'name' attribute of a Service Discovery <identity/> element (for which the category/type SHOULD be "conference/text"):
If the user does not have a registered nickname, the room MUST return a service discovery &QUERY; element that is empty (in accordance with XEP-0030).
Even if a user has registered one room nickname, the service SHOULD allow the user to specify a different nickname on entering the room (e.g., in order to join from different client resources), although the service MAY choose to "lock down" nicknames and therefore deny entry to the user, including a ¬acceptable; error. The service MUST NOT return an error to the user if his or her client sends the foregoing request after having already joined the room, but instead SHOULD reply as previously described.
If another user attempts to join the room with a nickname reserved by the first user, the service MUST deny entry to the second user and return a &conflict; error as previously described.
@@ -2603,7 +2603,7 @@ - ]]> +]]>The service then proceeds as described in the Approving Voice Requests section of this document.
@@ -2614,7 +2614,7 @@ from='hag66@shakespeare.lit/pda' to='coven@chat.shakespeare.lit/thirdwitch' type='unavailable'/> - ]]> +]]>The service MUST then send a presence stanzas of type "unavailable" from the departing user's occupant JID to the departing occupant's full JIDs, including a status code of "110" to indicate that this notification is "self-presence":
Note: The presence stanza used to exit a room MUST possess a 'type' attribute whose value is "unavailable". For further discussion, see the Presence business rules.
The service MUST then send presence stanzas of type "unavailable" from the departing user's occupant JID to the full JIDs of the remaining occupants:
Presence stanzas of type "unavailable" reflected by the room MUST contain extended presence information about roles and affiliations; in particular, the 'role' attribute MUST be set to a value of "none" to denote that the individual is no longer an occupant.
The occupant MAY include normal <status/> information in the unavailable presence stanzas; this enables the occupant to provide a custom exit message if desired:
Normal presence stanza generation rules apply as defined in &xmppim;, so that if the user sends a general unavailable presence stanza, the user's server will broadcast that stanza to the client's &OCCUPANTJID;; as a result, there is no need for the leaving client to send directed unavailable presence to its occupant JID. It is possible that a user might not be able to gracefully exit the room by sending unavailable presence. If the user goes offline without sending unavailable presence, the user's server is responsible for sending unavailable presence on behalf of the user (in accordance with RFC 6121).
Note: See Ghost Users for suggestions regarding room occupants that appear to be present in the room but that are actually offline.
Note: If the room is not persistent and this occupant is the last to exit, the service is responsible for destroying the room.
@@ -2705,7 +2705,7 @@ type='groupchat'>The MUC service MUST reflect the message to all other occupants with a 'from' address equal to the room JID or to the occupant JID that corresponds to the sender of the subject change:
As explained under , when a new occupant joins the room the room SHOULD include the last subject change after the discussion history.
A MUC client that receives such a message MAY choose to display an in-room message, such as the following:
If someone without appropriate privileges attempts to change the room subject, the service MUST return a message of type "error" specifying a &forbidden; error condition:
In order to remove the existing subject but not provide a new subject (i.e., set the subject to be empty), the client shall send an empty <subject/> element (i.e., either "<subject/>" or "<subject></subject>").
The service MUST remove the kicked occupant by sending a presence stanza of type "unavailable" to each kicked occupant, including status code 307 in the extended presence information, optionally along with the reason (if provided) and the roomnick or bare JID of the user who initiated the kick.
The inclusion of the status code assists clients in presenting their own notification messages (e.g., information appropriate to the user's locality). The optional inclusion of the reason and actor enable the kicked user to understand why he or she was kicked, and by whom if the kicked occupant would like to discuss the matter.
After removing the kicked occupant(s), the service MUST then inform the moderator of success:
After informing the moderator, the service MUST then inform all of the remaining occupants that the kicked occupant is no longer in the room by sending presence stanzas of type "unavailable" from the individual's roomnick (&OCCUPANTJID;) to all the remaining occupants (just as it does when occupants exit the room of their own volition), including the status code and optionally the reason and actor.
A user cannot be kicked by a moderator with a lower affiliation. Therefore, if a moderator who is a member attempts to kick an admin or a moderator who is a member or admin attempts to kick an owner, the service MUST deny the request and return a ¬allowed; error to the sender:
If a moderator attempts to kick himself, the service MAY deny the request and return a &conflict; error to the sender. (Although the act of kicking oneself may seem odd, it is common in IRC as a way of apologizing for one's actions in the room.)
The <reason/> element is OPTIONAL:
The service MUST then inform the moderator of success:
The service MUST then send updated presence from this individual's &OCCUPANTJID; to all occupants, indicating the addition of voice privileges by including an <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 "participant".
The <reason/> element is OPTIONAL:
The service MUST then inform the moderator of success:
The service MUST then send updated presence from this individual to all occupants, indicating the removal of voice privileges by sending a presence element that contains an <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 "visitor".
A moderator MUST NOT be able to revoke voice from a user whose affiliation is at or above the moderator's level. In addition, a service MUST NOT allow the voice privileges of an admin or owner to be removed by anyone. If a moderator attempts to revoke voice privileges from such a user, the service MUST deny the request and return a ¬allowed; error to the sender along with the offending item(s):
The service MUST then return the voice list to the moderator; each item MUST include the 'nick' and 'role' attributes and SHOULD include the 'affiliation' and 'jid' attributes:
The moderator can then modify the voice list if desired. In order to do so, the moderator MUST send the changed items (i.e., only the "delta") back to the service; each item MUST include the 'nick' attribute and 'role' attribute (normally set to a value of "participant" or "visitor") but SHOULD NOT include the 'jid' attribute and MUST NOT include the 'affiliation' attribute (which is used to manage affiliations such as owner rather than the participant role):
The service MUST then inform the moderator of success:
The service MUST then send updated presence for any affected individuals to all occupants, indicating the change in voice privileges by sending the appropriate extended presence stanzas as described in the foregoing use cases.
As noted, voice privileges cannot be revoked from a room owner or room admin, nor from any user with a higher affiliation than the moderator making the request. If a room admin attempts to revoke voice privileges from such a user by modifying the voice list, the service MUST deny the request and return a ¬allowed; error to the sender:
In order to approve the request, a moderator shall submit the form:
If a moderator approves the voice request, the service shall grant voice to the occupant and send a presence update as described in the Granting Voice to a Visitor section of this document.
The <reason/> element is OPTIONAL.
The service MUST add that bare JID to the ban list, MUST remove the outcast's nickname from the list of registered nicknames, and MUST inform the admin or owner of success:
The service MUST also remove any banned users who are in the room by sending a presence stanza of type "unavailable" to each banned occupant, including status code 301 in the extended presence information, optionally along with the reason (if provided) and the roomnick or bare JID of the user who initiated the ban.
The inclusion of the status code assists clients in presenting their own notification messages (e.g., information appropriate to the user's locality). The optional inclusion of the reason and actor enable the banned user to understand why he or she was banned, and by whom if the banned user would like to discuss the matter.
The service MUST then inform all of the remaining occupants that the banned user is no longer in the room by sending presence stanzas of type "unavailable" from the banned user to all remaining occupants (just as it does when occupants exit the room of their own volition), including the status code and optionally the reason and actor:
As with Kicking an Occupant, a user cannot be banned by an admin with a lower affiliation. Therefore, if an admin attempts to ban an owner, the service MUST deny the request and return a ¬allowed; error to the sender:
If an admin or owner attempts to ban himself, the service MUST deny the request and return a &conflict; error to the sender. (Note: This is different from the recommended service behavior on kicking oneself.)
@@ -3173,7 +3173,7 @@The service MUST then return the list of banned users to the admin; each item MUST include the 'affiliation' and 'jid' attributes but SHOULD NOT include the 'nick' and 'role' attributes:
The admin can then modify the ban list if desired. In order to do so, the admin MUST send the changed items (i.e., only the "delta") back to the service; each item MUST include the 'affiliation' attribute (normally set to a value of "outcast" to ban or "none" to remove ban) and 'jid' attribute but SHOULD NOT include the 'nick' attribute and MUST NOT include the 'role' attribute (which is used to manage roles such as participant rather than affiliations such as outcast); in addition, the reason and actor elements are OPTIONAL:
After updating the ban list, the service MUST inform the admin of success:
The service MUST then remove the affected occupants (if they are in the room) and send updated presence (including the appropriate status code) from them to all the remaining occupants as described in the "Banning a User" use case. (The service MUST also remove each banned user's reserved nickname from the list of reserved roomnicks, if appropriate.)
When an entity is banned from a room, an implementation SHOULD match JIDs in the following order (these matching rules are the same as those defined for privacy lists in &xep0016;):
The <reason/> element is OPTIONAL.
The service MUST add the user to the member list and then inform the admin of success:
If the user is in the room, the service MUST then send updated presence from this individual to all occupants, indicating the granting of membership by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "member".
The <reason/> element is OPTIONAL.
The service MUST remove the user from the member list and then inform the moderator of success:
The service MUST then send updated presence from this individual to all occupants, indicating the loss of membership by sending a presence element that contains an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "none".
If the room is members-only, the service MUST remove the user from the room, including a status code of 321 to indicate that the user was removed because of an affiliation change, and inform all remaining occupants:
Note: A service SHOULD also return the member list to any occupant in a members-only room; i.e., it SHOULD NOT generate a &forbidden; error when a member in the room requests the member list. This functionality can assist clients in showing all the existing members even if some of them are not in the room, e.g. to help a member determine if another user should be invited. A service SHOULD also allow any member to retrieve the member list even if not yet an occupant.
The service MUST then return the full member list to the admin qualified by the 'http://jabber.org/protocol/muc#admin' namespace; each item MUST include the 'affiliation' and 'jid' attributes and MAY include the 'nick' and 'role' attributes for each member that is currently an occupant.
The admin can then modify the member list if desired. In order to do so, the admin MUST send the changed items (i.e., only the "delta") to the service; each item MUST include the 'affiliation' attribute (normally set to a value of "member" or "none") and 'jid' attribute but SHOULD NOT include the 'nick' attribute (unless modifying the user's reserved nickname) and MUST NOT include the 'role' attribute (which is used to manage roles such as participant rather than affiliations such as member):
The service MUST modify the member list and then inform the moderator of success:
The service MUST change the affiliation of any affected user. If the user has been removed from the member list, the service MUST change the user's affiliation from "member" to "none". If the user has been added to the member list, the service MUST change the user's affiliation to "member".
If a removed member is currently in a members-only room, the service SHOULD kick the occupant by changing the removed member's role to "none" and send appropriate presence to the removed member as previously described. The service MUST subsequently refuse entry to the user.
For all room types, the service MUST send updated presence from this individual to all occupants, indicating the change in affiliation by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "none".
@@ -3418,7 +3418,7 @@ [ ... ] - ]]> +]]>In addition, the service SHOULD send an invitation to any user who has been added to the member list of a members-only room if the user is not currently affiliated with the room (note that the following example includes a password but not a reason -- both child elements are OPTIONAL):
Although only admins and owners SHOULD be allowed to modify the member list, an implementation MAY provide a configuration option that opens invitation privileges to any member of a members-only room. In such a situation, any invitation sent SHOULD automatically trigger the addition of the invitee to the member list. However, if invitation privileges are restricted to admins and a mere member attempts to a send an invitation, the service MUST deny the invitation request and return a &forbidden; error to the sender:
Invitations sent through an open room MUST NOT trigger the addition of the invitee to the member list.
If a user is added to the member list of an open room and the user is in the room, the service MUST send updated presence from this individual to all occupants, indicating the change in affiliation by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "member".
The <reason/> element is OPTIONAL.
The service MUST add the user to the moderator list and then inform the admin of success:
The service MUST then send updated presence from this individual to all occupants, indicating the addition of moderator status by including an <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".
The <reason/> element is OPTIONAL.
The service MUST remove the user from the moderator list and then inform the admin of success:
The service MUST then send updated presence from this individual to all occupants, indicating the removal of moderator status by sending a presence element that contains an <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 "participant".
As noted, an admin MUST NOT be allowed to revoke moderator status from a user whose affiliation is "owner" or "admin". If an admin attempts to revoke moderator status from such a user, the service MUST deny the request and return a ¬allowed; error to the sender:
The service MUST then return the moderator list to the admin; each item MUST include the 'nick' and 'role' attributes, and MAY include the 'jid' and 'affiliation' attributes:
The admin can then modify the moderator list if desired. In order to do so, the admin MUST send the changed items (i.e., only the "delta") back to the service; each item MUST include the 'nick' attribute and 'role' attribute (set to a value of "moderator" to grant moderator status or "participant" to revoke moderator status), but SHOULD NOT include the 'jid' attribute and MUST NOT include the 'affiliation' attribute (which is used to manage affiliations such as admin rather than the moderator role):
The service MUST modify the moderator list and then inform the admin of success:
The service MUST then send updated presence for any affected individuals to all occupants, indicating the change in moderator status by sending the appropriate extended presence stanzas as described in the foregoing use cases.
As noted, moderator status cannot be revoked from a room owner or room admin. If a room admin attempts to revoke moderator status from such a user by modifying the moderator list, the service MUST deny the request and return a ¬allowed; error to the sender:
If the admin approves the registration request, the service shall register the user with the room.
More advanced registration approval mechanisms (e.g., retrieving a list of registration requests using &xep0050; as is done in &xep0060;) are out of scope for this document.
If access is not restricted, the service MUST allow the user to create a room as described below.
From the perspective of room creation, there are in essence two kinds of rooms:
If the room does not yet exist, the service SHOULD create the room (subject to local policies regarding room creation), assign the bare JID of the requesting user as the owner, add the owner to the room, and acknowledge successful creation of the room by sending a presence stanza of the following form:
After receiving notification that the room has been created, the room owner needs to decide whether to accept the default room configuration (i.e., create an "instant room") or configure the room to use something other than the default room configuration (i.e., create a "reserved room"). The protocol flows for completing those two use cases are shown in the following sections.
Note: If the presence stanza sent to a nonexistent room does not include an &X; element qualified by the 'http://jabber.org/protocol/muc' namespace as shown above, the service SHOULD create a default room without delay (i.e., it MUST assume that the client supports groupchat 1.0 rather than MUC and therefore it MUST NOT lock the room while waiting for the room creator to either accept an instant room or configure a reserved room).
@@ -3770,7 +3770,7 @@The service MUST then unlock the room and allow other entities to join it.
@@ -3783,7 +3783,7 @@ type='get'>If the room does not already exist, the service MUST return an initial room configuration form to the user. (Note: The following example shows a representative sample of configuration options. A full list of x:data fields registered for use in room creation and configuration is maintained by the XMPP Registrar; see the XMPP Registrar Considerations section of this document.)
Note: The _whois configuration option specifies whether the room is non-anonymous (a value of "anyone"), semi-anonymous (a value of "moderators"), or fully anonmyous (a value of "none", not shown here).
If there are no configuration options available, the service MUST return an empty query element to the room owner:
The room owner SHOULD then fill out the form and submit it to the service.
If room creation is successful, the service MUST inform the new room owner of success:
If the room creation fails because the specified room configuration options violate one or more service policies (e.g., because the password for a password-protected room is blank), the service MUST return a ¬acceptable; error.
Alternatively, the room owner MAY cancel the configuration process:
If the room owner cancels the initial configuration, the service MUST destroy the room, making sure to send unavailable presence to the room owner (see the "Destroying a Room" use case for protocol details).
If the room owner becomes unavailable for any reason before submitting the form (e.g., a lost connection), the service will receive a presence stanza of type "unavailable" from the owner to the owner's &OCCUPANTJID;. The service MUST then destroy the room, sending a presence stanza of type "unavailable" from the room to the owner including a <destroy/> element and reason (if provided) as defined in the Destroying a Room section of this document.
@@ -4095,7 +4095,7 @@ type='get'>If the <user@host> of the 'from' address does not match the bare JID of a room owner, the service MUST return a &forbidden; error to the sender:
Otherwise, the service MUST send a configuration form to the room owner with the current options set as defaults:
If there are no configuration options available, the service MUST return an empty query element to the room owner as shown in the previous use case.
The room owner then submits the form with updated configuration information. (Example not shown.)
Alternatively, the room owner MAY cancel the configuration process:
@@ -4308,7 +4308,7 @@If the room owner cancels the subsequent configuration, the service MUST leave the configuration of the room as it was before the room owner initiated the subsequent configuration process.
If as a result of a change in the room configuration a room admin loses admin status while in the room, the room MUST send updated presence for that individual to all occupants, denoting the change in status by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "member" or "none" and the 'role' attribute set to a value of "participant" or "visitor" as appropriate for the affiliation level and the room type:
If as a result of a change in the room configuration a user gains admin status while in the room, the room MUST send updated presence for that individual to all occupants, denoting the change in status by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "admin" and the 'role' attribute set to a value of "moderator":
If as a result of a change in the room configuration a room owner loses owner status while that owner is in the room, the room MUST send updated presence for that individual to all occupants, denoting the change in status by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "admin" and the 'role' attribute set to an appropriate value given the affiliation and room type ("moderator" is recommended).
A service MUST NOT allow an owner to revoke his or her own owner status if there are no other owners; if an owner attempts to do this, the service MUST return a &conflict; error to the owner. However, a service SHOULD allow an owner to revoke his or her own owner status if there are other owners.
If as a result of a change in the room configuration a user gains owner status while in the room, the room MUST send updated presence for that individual to all occupants, denoting the change in status by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "owner" and the 'role' attribute set to an appropriate value given the affiliation and room type ("moderator" is recommended).
If as a result of a change in the room configuration the room type is changed to members-only but there are non-members in the room, the service MUST remove any non-members from the room and include a status code of 322 in the presence unavailable stanzas sent to those users as well as any remaining occupants.
A room MUST send notification to all occupants when the room configuration changes in a way that has an impact on the privacy or security profile of the room. This notification shall consist of a &MESSAGE; stanza containing an &X; element qualified by the 'http://jabber.org/protocol/muc#user' namespace, which shall contain only a <status/> element with an appropriate value for the 'code' attribute. Here is an example:
@@ -4379,7 +4379,7 @@The codes to be generated as a result of a privacy-related change in room configuration are as follows:
The <reason/> element is OPTIONAL.
The service MUST add the user to the owner list and then inform the owner of success:
If the user is in the room, the service MUST then send updated presence from this individual to all occupants, indicating the granting of owner status by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "owner" and the 'role' attribute set to an appropriate value given the affiliation and room type ("moderator" is recommended).
If the user is not in the room, the service MAY send a message from the room itself to the room occupants, indicating the granting of owner status by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "owner".
The <reason/> element is OPTIONAL.
A service MUST NOT allow an owner to revoke his or her own owner status if there are no other owners; if an owner attempts to do this, the service MUST return a &conflict; error to the owner. However, a service SHOULD allow an owner to revoke his or her own owner status if there are other owners.
If an implementation does not allow one owner to revoke another user's owner status, the implementation MUST return a ¬authorized; error to the owner who made the request.
Note: Allowing an owner to remove another user's owner status can compromise the control model for room management; therefore this feature is OPTIONAL, and implementations are encouraged to support owner removal through an interface that is open only to individuals with service-wide admin status.
@@ -4493,7 +4493,7 @@ id='owner2' to='crone1@shakespeare.lit/desktop' type='result'/> - ]]> +]]>If the user is in the room, the service MUST then send updated presence from this individual to all occupants, indicating the loss of owner status by sending a presence element that contains an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value other than "owner" and the 'role' attribute set to an appropriate value:
If the <user@host> of the 'from' address does not match the bare JID of a room owner, the service MUST return a &forbidden; error to the sender.
Otherwise, the service MUST then return the owner list to the owner; each item MUST include the 'affiliation' and 'jid' attributes and MAY include the 'nick' and 'role' attributes for any owner that is currently an occupant:
The owner can then modify the owner list if desired. In order to do so, the owner MUST send the changed items (i.e., only the "delta") back to the service;
Only owners shall be allowed to modify the owner list. If a non-owner attempts to view or modify the owner list, the service MUST deny the request and return a &forbidden; error to the sender:
A service MUST NOT allow an owner to revoke his or her own owner status if there are no other owners; if an owner attempts to do this, the service MUST return a &conflict; error to the owner. However, a service SHOULD allow an owner to revoke his or her own owner status if there are other owners.
In all other cases, the service MUST modify owner list and then inform the owner of success:
The service MUST also send presence notifications related to any affiliation changes that result from modifying the owner list as previously described.
The <reason/> element is OPTIONAL.
The service MUST add the user to the admin list and then inform the owner of success:
If the user is in the room, the service MUST then send updated presence from this individual to all occupants, indicating the granting of admin status by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "admin" and the 'role' attribute set to an appropriate value given the affiliation and room type (typically "moderator").
If the user is not in the room, the service MAY send a message from the room itself to the room occupants, indicating the granting of admin status by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value of "admin".
The <reason/> element is OPTIONAL.
The service MUST remove the user from the admin list and then inform the owner of success:
If the user is in the room, the service MUST then send updated presence from this individual to all occupants, indicating the loss of admin status by sending a presence element that contains an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value other than "admin" or "owner" and the 'role' attribute set to an appropriate value given the affiliation level and the room type (typically "participant").
If the user is not in the room, the service MAY send a message from the room itself to the room occupants, indicating the loss of admin status by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value other than "admin".
If the <user@host> of the 'from' address does not match the bare JID of a room owner, the service MUST return a &forbidden; error to the sender.
Otherwise, the service MUST then return the admin list to the owner; each item MUST include the 'affiliation' and 'jid' attributes and MAY include the 'nick' and 'role' attributes for any admin that is currently an occupant:
The owner can then modify the admin list if desired. In order to do so, the owner MUST send the changed items (i.e., only the "delta") back to the service;
Only owners shall be allowed to modify the admin list. If a non-owner attempts to view or modify the admin list, the service MUST deny the request and return a &forbidden; error to the sender.
Otherwise, the service MUST modify the admin list and then inform the owner of success:
The service MUST also send presence notifications related to any affiliation changes that result from modifying the admin list as previously described.
The service is responsible for removing all the occupants. It SHOULD NOT broadcast presence stanzas of type "unavailable" from all occupants, instead sending only one presence stanza of type "unavailable" to each occupant so that the user knows he or she has been removed from the room. If extended presence information specifying the JID of an alternate location and the reason for the room destruction was provided by the room owner, the presence stanza MUST include that information.
If the <user@host> of the 'from' address received on a destroy request does not match the bare JID of a room owner, the service MUST return a &forbidden; error to the sender:
The registrant may register more than one status code at a time, each contained in a separate <statuscode/> element.
@@ -5418,7 +5418,7 @@ because the MUC service is being shut down - ]]> +]]> @@ -5429,24 +5429,24 @@The "join" querytype is registered as a MUC-related action, with an optional key of "password".
The application MUST either present an interface enabling the user to provide a room nickname or populate the room nickname based on configured preferences or nickname discovery.
The join action MAY include a password for the room. Naturally, access to a URI that includes a room password MUST be appropriately controlled.
The following submission registers the "join" querytype.
@@ -5461,14 +5461,14 @@ xmpp:coven@chat.shakespeare.lit?join;password=cauldronburn
- ]]>
+]]>
The "invite" querytype is registered as a MUC-related action, with an optional key of "jid".
If the joining user is not yet in the room, the application MUST send two stanzas: the first to join the room and the second to invite the other individual. If the joining user is in the room already, the application shall send only the invitation stanza.
The URI can include multiple invitees:
The URI can also include a password:
The following submission registers the "invite" querytype.
@@ -5527,7 +5527,7 @@ xmpp:coven@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=cauld
- ]]>
+]]>
If a service does not discard any namespaces, it MUST return a &unavailable; error:
- ]]>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.
@@ -5802,7 +5802,7 @@ xmpp:coven@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=cauld - ]]> +]]>