The Multi-User Chat (XEP-0045)XEP-0045: Multi-User Chat <https://xmpp.org/extensions/xep-0045.html>. specification does not provide for a mechanism whereby an user might be informed of being mentioned in a Multi-User Chat (MUC) without being present as an occupant of that MUC.
This XEP aims to provide a standardized way in which this might be achieved.
Concerning "being mentioned" in a MUC, we will rely on References (XEP-0372)XEP-0372: References <https://xmpp.org/extensions/xep-0372.html>. as the means whereby someone is explicitly mentioned in a MUC message.
A user's client must be able to receive forwarded groupchat messages from a MUC in which that user is mentioned, while not having an active session in that MUC (i.e. without joining it).
For this to be possible, the MUC needs to know the user's JID and MUC nickname even when that user is not currently present in the MUC. Multi-User Chat (XEP-0045)XEP-0045: Multi-User Chat <https://xmpp.org/extensions/xep-0045.html>. section 7.10 ("Registering with a Room") describes a mechanism whereby a user can register a nickname with a MUC and it is recommended that this is the mechanism used to keep track of users across sessions.
Whether or not mesages are forwarded will be determined by a configuration setting on the MUC.
The MUC owner(s) will therefore determine whether notifications are sent out, and if activated, users may opt in or out (or have that done for them by a privileged user) by having their nicknames registered or not with the MUC.
When an owner creates or configures a MUC, the service offers the option to send out mention notifications to non-present, but still affiliated users:
The owner specifies a value of "1" or "true" In accordance with Section 3.2.2.1 of XML Schema Part 2: Datatypes, the allowable lexical representations for the xs:boolean datatype are the strings "0" and "false" for the concept 'false' and the strings "1" and "true" for the concept 'true'; implementations MUST support both styles of lexical representation. if the feature is desired:
When an affiliated user in a given MUC is referenced in a 'groupchat' message via References (XEP-0372)XEP-0372: References <https://xmpp.org/extensions/xep-0372.html>., and the MUC is configured to forward mentions, then the MUC will forward the message stanza to the user.
secondwitch: Thrice the brinded cat hath mew'd.
]]>
Notice that in the example above, the entire original 'groupchat' message (including elements added server-side, like the Unique and Stable Stanza IDs (XEP-0359)XEP-0359: Unique and Stable Stanza IDs <https://xmpp.org/extensions/xep-0359.html>. stanza-id) is encapsulated inside a Stanza Forwarding (XEP-0297)XEP-0297: Stanza Forwarding <https://xmpp.org/extensions/xep-0297.html>. element.
Similarly to Message Carbons (XEP-0280)XEP-0280: Message Carbons <https://xmpp.org/extensions/xep-0280.html>., the security model assumed by this document is that all of the resources for a single user are in the same trust boundary.
Forwarded groupchat messages leak information of who is currently present in a MUC without requiring the user to join the MUC first to find out.
Any forwarded copies received by a client MUST be from a valid MUC JID which matches the MUC JID of the encapsulated, forwarded mesages;
any copies that do not meet this requirement MUST be ignored.
None.
The XMPP RegistrarThe XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <https://xmpp.org/registrar/>. includes 'urn:xmpp:mmn:0' in its registry of protocol namespaces (see <https://xmpp.org/registrar/namespaces.html>).
urn:xmpp:mmn:0
If the protocol defined in this specification undergoes a revision that is not fully backwards-compatible with an older version, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of XEP-0053.