The Mediated Information eXchange (MIX) protocol framework and core capabilities are specified in Mediated Information eXchange (MIX) (XEP-0369)  (MIX-CORE). This specification defines six extensions to this core:
These extensions are independent. An implementation of this specification should identify clearly which extensions are implemented.
Mediated Information eXchange (MIX) (XEP-0369)  defines a framework of nodes associated with each channel, where new nodes can be added to provide new services. Two nodes defined in this specification MAY bey used to support Avatars. These nodes and their use is defined in User Avatar (XEP-0084) . These nodes MAY be created as part of a MIX channel, where it is desired to publish an avatar associated with the channel.
|Avatar Data||'urn:xmpp:avatar:data'||For publishing an Avatar|
|Avatar Metadata||'urn:xmpp:avatar:metadata'||For publishing Avatar metadata|
A nick MAY be associated with a user's bare JID. A user can register a nick with the MIX service. Nick registration can be used ensure that a user is able to use the same nick in all channels in the service and to prevent other users from using a registered nick. This can help achieve a consistent experience across a set of channels and prevent user confusion. Support for nick registration by a MIX service is OPTIONAL. Where nick registration is supported, nick registration MAY be OPTIONAL or MANDATORY. Where a user has registered a Nick with the MIX service, it MAY be used by each channel according to policy for the channel. A channel MAY enforce use of a registered nick. A channel MUST NOT use a registered nick for any other participant.
In order to determine if a Nick is allowed to be registered, the user MAY use disco to determine capabilities of the MIX service.
The response will be a list of features of the MIX channel. If Nick Registration is supported, then the result set will include <feature var="urn:xmpp:mix:misc:0#nick-register"/>.
To register a nick with the MIX service the user sends a register command to the service. This is encoded as a <register/> child element of an <iq/> element. The <register/> element is qualified by the urn:xmpp:mix:misc:0' namespace. The nick is encoded in a <nick/> child element of the <register/> element.
On success, the service informs the user of its nick. MIX SHOULD apply the "nickname" profile of the PRECIS OpaqueString class, as defined in RFC 7700  to the requested nick. This means that nick that is issued might be different from the nick that was requested.
When an Nick is assigned, the MIX server MUST update the Participants Node in the channel to reflect this change. Any users subscribed to this node will be notified of the change of Nick.
The following example shows an example of reporting successful Nick assignment.
If the requested nick is already taken and the MIX service does not assign an alternate nick, the MIX service MUST return a <conflict/> error:
If the register request does not contain a <nick/> element, then the MIX service MUST assign one. It is RECOMMENDED that the assigned nick is a UUID following RFC 4122 .
A MIX channel MAY support message retraction, where the sender of a messages or an authorized administrator deletes a message. A MIX channel MAY limit the time frame in which a message is allowed to be retracted, for example to prevent retraction of very old messages. When a messages is retracted the original message MAY be replaced by a tombstone. Message retraction is done by sending a special message that identifies the original message. This mechanism allows the retraction to be distributed on the same path as the original message so that all participating servers and clients MAY honour the retraction. The protocol to request retraction does this by adding to a message a <retract> element qualified by the 'urn:xmpp:mix:misc:0' namespace. A retract messages MUST NOT have a body. The <retract> element MUST include an 'id' attribute that holds the MAM-ID of the original message. The message sender will need to look up the MAM-ID. The MAM-ID is the convenient message identification for message recipients. A message and its retraction shown in the following example.
The MIX channel will allow a user to retract a message sent by the user if the 'Allow User Message Retraction' option is configured. The MIX channel will allow an administrative user to retract any message if the user is in the group specified by the 'Administrator Message Retraction Rights' option.
If the retraction message is accepted, it MUST be distributed to channel participants. This will allow retraction to happen in the MAM archive of each channel participant and to reflect the retraction in client GUI. A client receiving a retraction message SHOULD ensure that the retracted message is no longer displayed to the end user.
Two approaches to message retraction can be used. In the first approach, the retracted message is simply removed. This is appropriate where retraction is provided as a user service and the user has rights to remove messages sent from the record.
The second approach is to leave a tombstone, which if taken MUST be done in the following manner. It is recommended to use a tombstone, as simply deleting the message may cause confusion with MAM queries. Use of a tombstone is appropriate where it is desired to leave a record of the message that was redacted. With this approach, the original message <body> is removed and replaced with a tombstone using the <retracted> element qualified by the 'urn:xmpp:mix:misc:0' namespace that shows the JID of user performing the retraction and the time of the retraction.
A convenient way to reference another channel is to use References (XEP-0372)  which enables the JID of a channel to be shared. This might be used simply to inform the message recipient about the channel or as mechanism to invite the user to join the channel. This is useful as an invitation mechanism to a channel that any user can join or where the invitee knows that the user is allowed to join (e.g., because the channel is for all users in an organization).
Invitation by reference, as described in the previous section, is a convenient approach to invite a user to join a channel that the user has permission to join. This section describes the approach used when the inviter has permission to grant rights for the invitee to become a channel participant. This might be because the inviter is an administrator of the channel or the channel or if the inviter is a channel participant and the channel allows invitation by participants (this channel capability is controlled by the channel configuration variable 'Participation Addition by Invitation from Participant'). Invitation by reference is used to avoid cluttering the allowed node with JIDs of users who are invited to join, but do not accept the invitation. When a channel participant (the inviter) invites another user (the invitee) to join a channel, the following sequence of steps is followed:
The first step is for the inviter to request an invitation from the channel. The invitation contains inviter, invitee and a token. The channel will evaluate if the inviter has rights to issue the invitation. This will be because the inviter is a channel administrator or if the inviter is a channel participant and the channel allows invitation by participants. If the inviter has rights to make the invitation, the channel will return a token. The token is a string that the channel can subsequently use to validate an invitation. The format of the token is not specified in this standard. The encoded token MAY reflect a validity time. The invitation request is encoded as an <invite/> child element of an <iq/> element. The <invite/> element is qualified by the 'urn:xmpp:mix:misc:0' namespace. <invite/> contains an <invitation/> child element, which contains <inviter/>, <invitee/>, <channel/> and <token/> child elements.
The inviter can now send the invitee a message containing the invitation within the <message/> element, as shown in the following example.
The invitation can now be used by the invitee to join a channel. The <invitation/> child element is simply added to the standard channel <join/> element, so that the channel can validate the invitation using the token. If the allowed node is present and the invitee is not matched against any item, the channel MUST add the invitee to the allowed node as part of the join.
The invitee MAY send an acknowledgement back to the inviter, noting the status of the invitation. This is encoded as an <invitation-ack/> child element of <message/> element. The <invitation-ack/> element is qualified by the 'urn:xmpp:mix:misc:0' namespace. The <invitation-ack/> has an <invitation/> child element that encodes the invitation being acknowledged and a <value/> child element to encode the acknowledgement value. <value/> has the following values:
A common use case for an ad hoc channel is where two users are engaged in a 1:1 chat and wish to broaden the discussion. Prior to bringing more users into a channel, using standard invitation process, there is a need to create and populate a channel. The first step is for one of the two users to create an ad hoc channel, as described in the previous section. The other user will then be invited, and can switch to the new channel.
It can also be useful to share some or all of the messages from the 1:1 discussion into the new channel. The mechanism to do this is to forward messages to be shared to the channel using Stanza Forwarding (XEP-0297) . A body SHOULD NOT be used in the outer message. Sharing history is optional. If history is shared, it MUST be done by the user creating the channel before the other user is invited. Any other use of forwarded messages MUST be treated as a channel participant forwarding a message to the channel and MUST NOT be treated as history sharing.
There are a number of security considerations with sharing 1:1 history in a channel. There may be sensitive information in the 1:1 history, and the user sharing this history should ensure that none of this is sensitive, prior to sharing in this way. The user creating the channel has potential to inject history messages which were not part of the history. It is recommended that the second user joining the channel to validate that the messages match the history and to take appropriate action if they do not.
See considerations in Mediated Information eXchange (MIX) (XEP-0369) .
See considerations in Mediated Information eXchange (MIX) (XEP-0369) .
When converting a 1:1 conversation to a channel there is potential to expose sensitive information and to present invalid information.
The urn:xmpp:mix namespace needs to be registered.
To be supplied when MIX progresses to proposed standard.
See Mediated Information eXchange (MIX) (XEP-0369)  for a list of contributors to the MIX Family of specifications.
This document in other formats: XML PDF
This XMPP Extension Protocol is copyright © 1999 – 2020 by the XMPP Standards Foundation (XSF).
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.
## 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. ##
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.
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).
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The primary venue for discussion of XMPP Extension Protocols is the <email@example.com> discussion list.
Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.
Errata can be sent to <firstname.lastname@example.org>.
The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/
Fix various typos
Split out from MIX 0.10.0;