An entity often discovers a MUC service by sending a Service Discovery items ("disco#items") request to its own server.

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.

The service MUST return its identity and the features it supports.

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 the entity occupies.

The service MUST return a full list of the rooms the entity occupies. The server SHOULD include room name and version in each item.

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 MUST 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.

Every occupant in the room MAY broadcast messages to other occupants. In order to do so, the client MUST send a groupchat message to the room bare JID.

The room automatically assumes that occupants' nicks are equal to their bare JIDs. MUC light is designed for applications where it is not important to hide behind nicknames. On the contrary - it is up to th client to replace pure JIDs with user-friendly names like phone numbers or full names if necessary.

Room MUST route all messages of type 'groupchat'.

The service MAY allow room occupants to set the room subject by changing "subject" configuration field. A standard configuration stanza is used in this case. Subject change is announced like an ordinary configuration change.

Room occupant may request room information (configuration and/or occupants list) by information version. It is up to service to define the version string, the only requirement for it is to be unique per room. Please note there are no separate versions for configuration and occupant list alone.

If the server side version does not match the one provided by the client (or if the client does not provide one, i.e. 'version' element is empty), the service MUST respond with a current version string and full configuration and/or occupant list.

If the version strings match, server MUST reply with an empty result.

Only room occupants can get room information.

Every occupant is allowed to leave the room at any time. It is done by modifying own affiliation.

A user MAY choose to automatically deny being added to the room. All stanzas must be directed to MUC Light service. User MAY send more than one item in a single request and mix both 'user' and 'room' elements.

If the occupant tries to add another user to the room, and this user has set a blocking policy, the server MUST ignore the attempt. No error is returned, this user is simply skipped when processing affiliation change query.

A room is created by submitting a dedicated stanza. The client application should pick random room node name, since human-readable room name is in configuration.

For rules that apply to the configuration options, please see "Setting room configuration" chapter.

The client MAY include initial configuration and occupant list (the list MUST NOT include the creator). The server MAY allow sending incomplete configuration form. In such case the server MUST use default values for missing fields. The server MAY enforce a minimal occupant list length.

The service MAY either give the creator the 'owner' or 'member' status. In the latter case all users are equal.

Upon room creation success, the service MUST reply with an empty IQ result.

The following rules (similar to the ones relevant to the affiliation change request) apply to the occupant list:

• 'none' affiliation cannot be used.
• All user bare JIDs must be unique
• At most one owner can be chosen. In such case the room creator will become "just" a 'member'.

After the room is created (but before receiving IQ result), new occupants (including creator) receive &MESSAGE; from the room with their affiliations (stanza MUST include only recipient's affiliation) and initial room version. <prev-version /> element MUST NOT be included.

A room is automatically destroyed when its occupant list becomes empty or the room owner explicitly sends IQ with a room destroy request.

Before sending an IQ result, every occupant is notified that its affiliation has changed to 'none'. These notifications include &X; element qualified with "urn:xmpp:muclight:0#destroy" namespace.

Only the room owner is allowed to destroy it.

Room destruction notification SHOULD NOT contain version (or "prev-version" information).

Only room owners can modify room configuration but the service MAY allow members to change it too.

All room occupants MUST be notified about a configuration change and both the new and old room version string (<version /> and <prev-version /> respectively).

"version" and "prev-version" configuration field names are NOT ALLOWED - they are reserved for room versioning.

The service MAY allow the client to set the configuration fields with any name but it is NOT RECOMMENDED.

The Data Forms are not used for the configuration. Instead, the config fields are encoded in XML elements with names equal to the key and content equal to the value.

The server SHOULD accept incomplete (i.e. delta) configuration forms. In such case, values of the missing fields SHOULD be preserved.

The occupant list is modified by a direct affiliation change. Following rules apply:

1. There are only 3 affiliations.
   • owner - can do everything in the room
   • member - can send messages to the room and if the service allows it, can also change configuration or change others' affiliations
   • none - not in the room; it's a keyword for marking a user for removal from room
2. Every occupant can change its own affiliation to none in order to leave the room.
3. The only way to join the room is being added by other occupant.
4. The owner can change affiliations at will.
5. If the owner leaves, the server MAY use any strategy to choose a new one.
6. The room can have at most one owner. Giving someone else the 'owner' status effectively causes the current one to lose it.
7. Owner can choose a new owner when leaving by including both 'none' and 'owner' items in affiliation change request.
8. Every user JID can be used in the request at most once.
9. A single request MAY change multiple affiliations.
10. All changes must be meaningful, e.g. setting member's affiliation to 'member' is considered a bad request.
11. Server MAY allow members to add new members but they still cannot make anyone an 'owner' or remove other users from the room.

On success the server will reply with result IQ with all changed items. BEFORE returning the IQ result, the service MUST route a message with affiliation change to all relevant users.

Newcomers, i.e. users that were not occupants before the change, SHOULD receive only their own affiliation and SHOULD NOT receive <prev-version /> element.

The notifications must include both the new and old room version (<version /> and <prev-version /> respectively) string (except for the ones directed to users that have been removed from the room).

The notifications contain a list of items. The item list may be different from the list in IQ set, because some of the changes may require additional operations, e.g. choosing new owner when the old one leaves. Users, that are still in the room after change, will receive full change list. Users, that have been removed from the room with the request, will get only one item: themselves with affiliation 'none'.

The service MAY add user's rooms to its roster. It allows the client to skip separate Disco request to the service. Roster items with rooms MUST belong to the group "urn:xmpp:muclight:0" (MUC Light namespace) and include <version> element. Their subscription type MUST be 'to'.

This section defines the rules for archiving MUC Light events and messages. Stanzas described in the subsections below MUST be archived by the server. The stanzas not included here MUST NOT be archived.

The &MESSAGE; element inside <forwarded> MUST include "from" attribute and MUST NOT include "to" attribute. "id" SHOULD be archived as well.

In case of regular groupchat messages, "from" attribute MUST consist of a room full JID with sender bare JID in the resource part. As for room notification, e.g. create event, "from" MUST be equal to room bare JID.

Examples below use MAM v0.4 protocol. Archive can be fetched only from a specific room, the client MUST NOT query MUC Light service directly.

If a client sends a stanza to the room, that it does not occupy, the service MUST reply with the 'item-not-found' error.

The service MUST ignore all &PRESENCE; stanzas sent by the client.

If service receives a stanza with invalid syntax, it MUST reply with a 'bad-request' error.

If the request sender does not have sufficient privileges (but is a room occupant), the service MUST reply with a 'not-allowed' error.

It occurs in the following cases:

• A member tries to change the configuration but the service is not configured to allow it. It does not apply to the subject change, although it has to be performed by sending &MESSAGE; with &SUBJECT;, not configuration &IQ;.
• A member tries to change anyone's affiliation to 'none' or 'owner'.
• A member tries to change someone's affiliation to 'member' but the service is not configured to allow it.

Some client-side developers might choose to use existing XEP-0045 Multi-User Chat implementations to interface with the new MUC Light. There may be various reasons to do so: using familiar protocol, avoiding additional implementation, quick prototyping etc. This section provides suggestions of mappings between XEP-0045 stanzas and the new ones described in this document.

Operations not described here SHOULD remain unmodified.

MUC Light service may be abused by malicious users, e.g. due to replicating single message for every room occupant. The list below contains suggested configurable limits that SHOULD be implemented.

The service features that might vary depending on specific application are included as well.

• Maximal count of rooms the user occupies.
• Blocking feature enabled/disabled.
• XEP-0045 compatibility mode enabled/disabled.
• Room creator's initial affiliation: owner/member.
• Room configuration may be changed by owner/occupants.
• New members can be invited by owner/occupants.
• Maximal room size.

Since every user is allowed to create rooms in MUC Light, it is possible to achieve high ratio of messages delivered to the clients to messages sent by the clients with little effort. To mitigate or avoid this issue, the service MAY implement additional rules like limiting per-user room count or message rate in a room. Heuristic algorithms for analysing user behaviours MAY be used as well to monitor and detect potential attacks.