XEP-XXXX: New MUC

3.1 Occupancy Sessions¶

Whenever a client joins a room, they start an "occupancy session". There can also be an occupancy session for their bare JID, which is independent of any client session. If at least one occupancy session exists, the room will contain an occupant JID, and the user will be considered an occupant of the room for all purposes.

3.2 Addressing¶

In MUC2, occupants are addressed by a JID consisting of the room's bare JID (see XEP-0045) and the occupant-id as resource. This requires that in MUC2, servers MUST provide an occupant-id, and also that servers MUST use an occupant-id generation algorithm that results in a valid resource. In addition, MUC1 nicknames MUST NOT be allowed to clash with occupant-ids, and as such, servers SHOULD prefix the occupant-id in the resource with some prefix, such as "-", to enforce this.

A client joining via MUC1's presence-based joins will not see these addresses, but instead sees the nickname-based addressing.

MUC2 rooms MUST include the nickname within presence as a nickname element qualified by the urn:xmpp:muc:0 namespace within the usual <x/>.

<presence to='bastanio@shakespeare.example/wimsy-192837' from='court@venice.example/-deadbeefcafe'>
  <x xmlns='http://jabber.org/protocol/muc#user'>
    <item affiliation='admin' role='moderator'/>
    <nickname xmlns='urn:xmpp:muc:0'>Bastanio</nickname>
  </x>
</presence>
      

3.3 Joining via Presence¶

Joining a MUC1 room can be done with (relatively) simple presence. MUC2, as well, can be done this way, though this will not automatically create a bare JID occupancy session. To do so, the same joining presence stanza is used, but the <x/> element includes a muc2 element qualified by the urn:xmpp:muc:0 namespace, and the presence is sent to the bare JID. This will indicate to the room that MUC2 is expected, and will cause the occupancy session to be a MUC2 session.

While rooms can be configured as "anonymous", "semi-anonymous", and so on, users MAY express their preference as well via the <visibility/> element. If a user requests anonymity, the room MUST either honour that request or reject the join. Note that if the user has an existing occupancy session joined non-anonymously, this conflict MUST also reject the join. Typically, rooms will accept a non-anonymous join to a room that defaults to anonymous, but they MAY reject that.

<presence from='bastanio@shakespeare.example/wimsy-192837' to='court@venice.example'>
  <x xmlns='http://jabber.org/protocol/muc'>
    <muc2 xmlns='urn:xmpp:muc:0'/>
      <nickname>Bastanio</nickname>
      <presence level='full'/>
      <visibility type='anonymous'/>
    </muc2>
  </x>
</presence>
      

The sequence of joining either type of room is broadly identical. The differences are listed in the following sections:

3.4 Bare JID occupancy sessions¶

In order to handle the offline case, an iq-based joining protocol is also included. Clients joining the room in this way essentially request to be visible as an occupant (subject to the room's configuration), and also to receive messages to their bare JIDs. Groupchat messages sent to bare JIDs do not, by default, get sent to clients, and, by default, are bounced with a <service-unavailable/> error. Therefore clients MUST first establish if their server has MUC2-PAM support; if it does not, they MUST avoid this mechanism and use presence-based joins instead.

Bare JIDs join the room with an <iq/> request to the room's bare JID of type "set", containing a join element within the namespace urn:xmpp:muc:0, containing a nickname element. The room processes this, sending the room's current subject in the same way as a join - containing the MAM summary - and respond with an <iq/> of type result which reflects the join element within urn:xmpp:muc:0 also containing the nickname element. This allows the room to assign a different nickname as needed.

To trigger this, a client performs an iq-set request to their own bare JID, with a join element, this time with a "room" attribute containing the bare JID of the room, and containing a <nickname/>. The client will receive a response containing the same join element with the nickname element, once the join is complete.

Copyright

This XMPP Extension Protocol is copyright © 1999 – 2024 by the XMPP Standards Foundation (XSF).

Permissions

Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).

Visual Presentation

The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.