XEP-0369: Mediated Information eXchange (MIX)

3.6.1 Messages Node

Items in this node will contain a message identified by a unique ID. A MIX implementation SHOULD NOT make messages available for retrieval from this node using pubsub. The recommended approach is that zero history is held in the messages node, and that this node is used for publication only. The recommended approach to retrieve message history is MAM. Users subscribe to this node to receive messages.

Private Messages are not stored in the messages node.

3.6.2 Subject Node

The subject node publishes the current subject of channel. Subject history is stored in MAM. The id of each node is the current value of the channel subject. A single item is stored in this node at a time. Users subscribe to this node to receive subject updates. The following example shows the format of a item in the Subject node.

Example 1. Subject Node

    <items node='urn:xmpp:mix:nodes:subject'>
      <item id='How to use Toads' />
    </items>
      

3.6.3 Participants Node

Each channel participant is represented as an item of the 'urn:xmpp:mix:nodes:participants' channel node. Each item is named by the bare JID of the participant. For example 'coven+123456@mix.shakespeare.example' might name the node item associated with participant 'hag66@shakespeare.example'. The nick associated with the user is mandatory and is stored in the item. This node may be subscribed to for jid-visible channels that permit subscription to this node - this will allow users to see changes to channel membership.

QUESTION: Is there a requirement to mandate format of nick?

Example 2. Value of Participants Node

    <items node='urn:xmpp:mix:nodes:participants'>
      <item id='coven+123456@mix.shakespeare.example/8765'>
        <participant xmlns='urn:xmpp:mix:0'
                     nick='thirdwitch'/>
      </item>
    </items>
      

3.6.4 JID Map Node

The JID Map node is used to map from proxy bare JID to real bare JID. Each item is identified by proxy bare JID, mapping to the real bare JID. This node is used to give administrator access to real JIDs and participant access to real JIDs in jid-visible channels. In JID visible channels, all participants may subscribe to this node. In JID hidden channels, only administrators can subscribe.

Example 3. Value of JID Map Node

    <items node='urn:xmpp:mix:nodes:jidmap'>
      <item id='coven+123456@mix.shakespeare.example'>
        <participant xmlns='urn:xmpp:mix:0'
                     jid='hecate@mix.shakespeare.example'/>
      </item>
    </items>
      

3.6.5 Presence Node

The presence node contains the presence value for clients belonging to participants that choose to publish presence to the channel. A MIX channel may require that all participants publish presence. Each item in the presence node is identified by the full anonymized proxy JID, and contains the current presence value for that JID. The presence is encoded in the same way as data that would be sent in a presence message. The full anonymized JID is always used in this node. In MIX it is possible to have a 'presence-less channel' by not using this node. Access Control may be set to enforce that for each of the full JIDs in this list, the bare JID MUST be in the participants list.

QUESTION: The current specification allows channels to be configured so that node subscription is not restricted to participants (although this restriction is the default). Is this flexibility desirable, or should we restrict to participants?

This node may be subscribed to by users using bare JID. So presence of online clients is sent to all users subscribed to this node, noting that presence is always sent using standard presence protocol.

Example 4. Value of Presence Node

    <items node='urn:xmpp:mix:nodes:presence'>
      <item id='coven+123456@mix.shakespeare.example/8765'>
        <presence xmlns:”jabber:client">
          <show>dnd</show>
          <status>Making a Brew</status>
        </presence>
      </item>
    </items>
      

3.6.6 Configuration Node

The Configuration node holds the configuration of the channel as a single item, named by the date-time of the last update to the configuration. A single item is stored in the node at a time, with previous configuration history accessed by MAM. Users subscribed to the configuration node will enable notification of configuration change. The configuration node is optional for a MIX channel. For example, configuration choices could be fixed and not exposed. A subset of the defined configuration options may be used and additional non-standard configuration options may be added. If configuration options to control functionality of the nature described here are provided, the options defined in this standard MUST be used. The following configuration options are provided:

• 'Date of Configuration Change'. Encoded as the item ID.
• 'Last Change Made By'. Bare JID of the user making the last change.
• 'Name'. The name of the channel
• 'Members'. List of JIDs with member rights. The rights of members are configured in the ACL node.
• 'Outcast'. List of JIDs banned from subscribing to any nodes in the MIX channel.

TEMPORARY NOTE AND QUESTION: This is currently work in progress. Suggestions for other items to be included in configuration are welcome.

The format of the Configuration node follows Data Forms (XEP-0004) [13]. This allows configuration to be updated by MIX defined commands and that the results of update commands can be directly written to the PubSub node. Updates to the Configuration may use these commands or direct writing to the PubSub node.

Example 5. Configuration Node

    <items node='urn:xmpp:mix:nodes:config'>
      <item id='2016-05-30T09:00:00'>
       name='A Dark Cave'
      *** TBS ****
      </item>
    </items>
      

3.6.7 ACL Node

The ACL node is closely related to the configuration node, and contains more information that will generally be more restricted as to who can access and modify. An anticipated configuration reflected in the defaults has ACL node configured so that it can be modified by channel owners and read only by channel owners and administrators. The default for the configuration node is update by owners or administrators and visibility to list members. Split of functionality has been made on the basis of this model.

TEMPORARY NOTE AND QUESTION: The split of configuration/acl is arbitrary. It would be possible to merge them, or to split into more nodes, giving finer control granularity. Input is solicited on the split an detailed assignment of items to nodes.

The ACL node holds access control related configuration of the channel as a single item, named by the date-time of the last update to the ACL. History MUST be set to 1. Previous ACL history is accessed by MAM. Users may subscribe to the ACL node if allowed using bare JID. The ACL node is optional for a MIX channel. For example, ACL choices could be fixed and not exposed. A subset of the defined ACL options may be used and additional non-standard ACL options may be added. If configuration options to control functionality of the nature described here are provided, the options defined in this standard MUST be used. The following ACL options are provided:

• 'Date of Configuration Change'. Encoded as the item ID.
• 'Last Change Made By'. Bare JID of the user making the last change.
• 'Owners'. List of bare JIDs with Owner rights as defined in ACL node. When a list is created, the JID creating the list is configured as an owner, unless this attribute is explicitly configured to another value. Owners will generally have full rights to make changes to channel configuration and access control.
• 'Administrators'. List of bare JIDs with Administrator rights. An Administrator has rights to make changes to channel access control and configuration as defined in ACL node. An Administrator also has operational right on a channel, such a kicking users out of the channel. These rights are analogous to moderator rights defined in Multi-User Chat (XEP-0045) [14].
• 'End of Life'. The date and time at which the channel will be automatically removed by the server. If this is not set, the channel is permanent.
• 'Nodes Present'. Specifies which nodes are present: "participants"; "presence"; "subject"; "acl". Note that "config" is implicit, and "jidmap" is implied by "participants".
• 'Message Node Subscription'. Controls who can subscribe to messages node: "members-only"; "participants-only"; "anyone". Users with banned affiliation may not subscribe. Default "participants-only".
• 'Participants Node Subscription'. Controls who can subscribe to participants node: "members-only"; "participants-only"; "anyone"; "nobody". Users with banned affiliation man not subscribe. Default "participants-only".
• 'Participants Node Subscription'. Controls who can subscribe to participants node: "members-only"; "participants-only"; "anyone"; admins-and-owners" "nobody". Users with banned affiliation man not subscribe. Default "participants-only". Note that this value needs to be restricted to "admins-and-owners" for channels with JID visibility set to a value other than "jid-mandatory-visible".
• 'Presence Node Subscription'. Controls who can subscribe to presence node: "members-only"; "participants-only"; "anyone"; "nobody". Users with banned affiliation man not subscribe. Default "participants-only".
• 'Subject Node Subscription'. Controls who can subscribe to subject node: "members-only"; "participants-only"; "anyone"; "nobody". Users with banned affiliation man not subscribe. Default "participants-only".
• 'Configuration Node Access'. Controls who can subscribe to and has read access configuration node: "members-only"; "participants-only"; "admins-and-owners"; "owners-only"; "anyone"; "nobody". Default "admins-and-owners".
• 'ACL Node Access'. Controls who can subscribe to and has read access acl node: "members-only"; "admins-and-owners"; "owners-only"; "anyone"; "nobody". Default "admins-and-owners".
• 'Configuration Node Update'. Controls who can modify configuration node: "owners-only"; "admins-and-owners". Default "admins-and-owners".
• 'ACL Node Update'. Controls who can modify acl node: "owners-only"; "admins-and-owners". Default "owners-only".
• 'JID Visibility'. Choice of "jid-hidden", "jid-optionally-visible", "jid-mandatory-visible".
• 'Open Presence'. If selected, any client may register presence. If not selected, only clients with bare JID in the participants list may register presence.
• 'Allow Message Retraction'. If this option is selected users will be able to retract messages sent to the MIX channel.
• 'Membership Extension by Invitation'. This option extends a members only channel so that an invitation from a channel member will add the invited user to the members list.
• 'No Private Messages'. If this option is selected, private messages may not be used with the channel.

TEMPORARY NOTE: This is currently work in progress. Suggestions for other items to be included in ACL are welcome.

The format of the ACL node follows Data Forms (XEP-0004) [15].

Example 6. ACL Node

    <items node='urn:xmpp:mix:nodes:acl'>
      <item id='2016-05-30T09:00:00'>
      *** TBS ****
      </item>
    </items>
      

<iq from='hag66@shakespeare.example/intibo24'
    id='lx09df27'
    to='mix.shakespeare.example'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

<iq from='mix.shakespeare.example'
    id='lx09df27'
    to='hag66@shakespeare.example/intibo24'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity
        category='conference'
        name='Shakespearean Chat Service'
        type='text'/>
    <feature var='urn:xmpp:mix:0'/>
    <x xmlns='jabber:x:data' type='result'>
      <field var='FORM_TYPE' type='hidden'>
        <value>urn:xmpp:mix:0#serviceinfo</value>
      </field>
      <field
             label='Location of MUC mirror service'>
        <value>chat.shakespeare.example</value>
      </field>
    </x>
  </query>
</iq>

<iq from='hag66@shakespeare.lit/pda'
    id='ik3vs715'
    to='coven@mix.shakespeare.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
    

<iq from='coven@mix.shakespeare.lit'
    id='ik3vs715'
    to='hag66@shakespeare.lit/pda'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity
        category='conference'
        name='A Dark Cave'
        type='mix'/>
    <feature var='urn:xmpp:mix:0'/>
  </query>
</iq>
    

<iq from='hag66@shakespeare.lit/pda'
    id='kl2fax27'
    to='coven@mix.shakespeare.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>
    

<iq from='coven@mix.shakespeare.lit'
    id='kl2fax27'
    to='hag66@shakespeare.lit/pda'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#items'>
    <item jid='coven@mix.shakespeare.example'
          node='urn:xmpp:mix:nodes:presence'/>
    <item jid='coven@mix.shakespeare.example'
          node='urn:xmpp:mix:nodes:participants'/>
    <item jid='coven@mix.shakespeare.example'
          node='urn:xmpp:mix:nodes:messages'/>
    <item jid='coven@mix.shakespeare.example'
          node='urn:xmpp:mix:nodes:subject'/>
    <item jid='coven@mix.shakespeare.example'
          node='urn:xmpp:mix:nodes:config'/>
  </query>
</iq>
    

5.1.1 Joining a Channel

A user joins a channel by sending a MIX "join" command. There is no default set of nodes, so user MUST specify the set of nodes to be subscribed to. To achieve the equivalent service to MUC, a user would subscribe to messages, presence and subject. This will lead to the server subscribing the user to each of the requested nodes associated with the channel. The MIX server will also add the user to the participant list by injecting a new item into the "urn:xmpp:mix:nodes:participants" node automatically.

The default MIX model is that only channel participants may subscribe to nodes. A MIX channel MAY allow non-participant subscription. This will be handled by clients directly subscribing to the desired PubSub nodes.

Example 13. User Joins a Channel

<iq type='set'
    from='hag66@shakespeare.example/pda'
    to='coven@mix.shakespeare.example'
    id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
  <join xmlns='urn:xmpp:mix:0'>
    <subscribe node='urn:xmpp:mix:nodes:messages'/>
    <subscribe node='urn:xmpp:mix:nodes:presence'/>
    <subscribe node='urn:xmpp:mix:nodes:participants'/>
    <subscribe node='urn:xmpp:mix:nodes:subject'/>
    <subscribe node='urn:xmpp:mix:nodes:config'/>
  </join>
</iq>

The channel must process the join atomically. The channel responds with an IQ-result. This stanza includes the nodes to which the user has been successfully subscribed, as well as the bare JID that will be used for the user in this channel and added to the participant list. If a user cannot be subscribed to one or more of the requested nodes (e.g., because the node does not exist), but can be subscribed to some the response simply lists the nodes successfully subscribed. If none of the nodes requested are successfully subscribed to, and error response is sent indicating the reason that the first node requested was not subscribed to. This response will also include other nodes requested where subscription failed for the same reason. A user may subsequently request subscription to nodes in a channel to which the user was not initially subscribed.

Example 14. Channel Successfully Processes Join

<iq type='result'
    from='coven@mix.shakespeare.example'
    to='hag66@shakespeare.example/pda'
    id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
  <join xmlns='urn:xmpp:mix:0' jid='hag66@shakespeare.example'>
    <subscribe node='urn:xmpp:mix:nodes:messages'/>
    <subscribe node='urn:xmpp:mix:nodes:presence'/>
    <subscribe node='urn:xmpp:mix:nodes:participants'/>
    <subscribe node='urn:xmpp:mix:nodes:subject'/>
    <subscribe node='urn:xmpp:mix:nodes:config'/>
  </join>
</iq>
      

As noted, the participant might not be subscribed to all nodes associated with the channel (in this case only messages, participants, and subject).

Example 15. Channel Processes Join With Modifications

<iq type='result'
    from='hag66@shakespeare.example/pda'
    to='coven@mix.shakespeare.example'
    id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
  <join xmlns='urn:xmpp:mix:0' jid='hag66@shakespeare.example'>
    <subscribe node='urn:xmpp:mix:nodes:messages'/>
    <subscribe node='urn:xmpp:mix:nodes:participants'/>
    <subscribe node='urn:xmpp:mix:nodes:subject'/>
  </join>
</iq>
      

The channel also adds the user to the participants node and sends a notification.

Example 16. Channel Adds User to Participants Node

<message from='coven@mix.shakespeare.example'
         to='hecate@shakespeare.example'
         id='5A9C7398-DB13-4BFA-A091-2D466C710AAF'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='urn:xmpp:mix:nodes:participants'>
      <item id='123456@mix.shakespeare.example'>
        <participant xmlns='urn:xmpp:mix:0'
                     nick='thirdwitch'/>
      </item>
    </items>
  </event>
</message>
      

The user that has been added to the channel is identified by the item id of the item added to the pubsub node, which is the proxy JID of the new channel participant. Each <participant> element will include the nick of the user being added, which will be how the user will typically be shown in the channel.

Following the MIX server side processing, the user's server will usually add the MIX channel to the user's roster using one way presence. This means that the MIX channel will get presence information from the user. This roster entry will lead to correct handling of the user's presence in the MIX channel. If the user does not wish to publish presence and the channel permits this, then this roster addition does not happen. If the channel requires presence and the user removes the channel from the user's roster, the channel MAY remove the user as a channel participant.

5.1.2 User Preferences and Additional Information

A channel may store additional user preferences and parameters. Where the channel requires a value to be explicitly a Data Forms (XEP-0004) [20] form will be returned in response to the join request with mandatory and optional fields. If parameters are optional, the user may request to set them.

A user may set their JID visibility preference to one of the following values:

1. 'Use Channel Default'. In this setting, the channel default value will be used. This value is used if another value is not explicitly set.
2. 'Never Show JID'. If this is set, JID will never be shared and user will be removed from the channel if its mode changes to JID-visible-mandatory.
3. 'Prefer Not Show JID. If this is set, JID will only be shared if mode is JID-visible-mandatory.

AUTHOR'S NOTE AND QUESTION: Add protocol specifications and examples. Are there any other specific per user values that should be listed here?

5.1.3 Leaving a Channel

Users generally remain in a channel for an extended period of time. In particular membership of the channel does not change when the user goes offline as happens with Multi-User Chat (XEP-0045) [21]. So, leaving the channel is a permanent action for a user across all clients, not just a matter of telling the channel that the user is not currently available or for a single client. In order to leave a channel, a user sends a MIX "leave" command to the channel. When a user leaves the channel, the user's server will remove the channel from the user's roster.

Example 17. User Leaves a Channel

<iq type='set'
    from='hag66@shakespeare.example/pda'
    to='coven@mix.shakespeare.example'
    id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
  <leave xmlns='urn:xmpp:mix:0'/>
</iq>
      

When the user leaves the channel, the MIX service is responsible for unsubscribing the user from all nodes in the channel and for removing the user from the participants and presence list. If the user has online presence when the user leaves the channel, the change of presence status caused by removing the user's entry or entries from the presence node will ensure that subscribers to the presence node are correctly updated on presence status. Deletion from the participants and presence functions as if the item (channel member) had been deleted using the PubSub retract mechanism with notification set to true. Notification of the deletion is sent to clients subscribed to the participants PubSub nodes, as shown in the example below.

Example 18. Reporting when User Leaves a Channel

        <message from='coven@mix.shakespeare.example' to='hecate@shakespeare.example' id='foo'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='urn:xmpp:mix:nodes:participants'>
      <retract id='123456@mix.shakespeare.example'/>
    </items>
  </event>
</message>

      <message from='coven@mix.shakespeare.example' to='hecate@shakespeare.example' id='bar'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='urn:xmpp:mix:nodes:presence'>
      <retract id='123456@mix.shakespeare.example/8765'/>
    </items>
  </event>
</message>
      

5.1.4 Setting a Nick

<iq type='set'
    from='hag66@shakespeare.example/pda'
    to='coven@mix.shakespeare.example'
    id='7nve413p'>
  <query xmlns='urn:xmpp:mix:0'>
    <nick>thirdwitch</nick>
  </query>
</iq>
      

<iq type='result'
    from='hag66@shakespeare.example/pda'
    to='coven@mix.shakespeare.example'
    id='7nve413p'>
  <query xmlns='urn:xmpp:mix:0'>
    <nick>thirdwitch</nick>
  </query>
</iq>
      

5.1.5 Registering a Nick

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 Nick is associated with the user's bare JID.

In order to determine if a Nick may be registered, the user may use disco to determine capabilities of the MIX service.

Example 21. User Determines features of the MIX service

<iq type='get'
    from='hag66@shakespeare.example/pda'
    to='mix.shakespeare.example'
    id='7nve413p'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
      

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="mix_nick_register"/>.

To register a nick with the MIX service the user sends a <register/> command to the service.

Example 22. User Registers with Service

<iq type='set'
    from='hag66@shakespeare.example/pda'
    to='mix.shakespeare.example'
    id='7nve413p'>
  <register xmlns='urn:xmpp:mix:0'>
    <nick>thirdwitch</nick>
  </register>
</iq>
      

On success, the service informs the user of its nick. The nick that is issued might be different from the nick that was requested, for example if the service completes normalization of nicknames for purposes of internationalization.

MIX services SHOULD apply the "nickname" profile of the PRECIS OpaqueString class, which is defined in draft-ietf-precis-nickname.

Example 23. Service Returns User of Nick

<iq type='result'
    to='mix.shakespeare.example'
    from='hag66@shakespeare.example/pda'
    id='7nve413p'>
  <register xmlns='urn:xmpp:mix:0'>
    <nick>thirdwitch</nick>
  </register>
</iq>
      

If the requested nick is already taken, the MIX service returns a <conflict/> error:

Example 24. Nick is Taken

<iq type='error'
    to='mix.shakespeare.example'
    from='hag66@shakespeare.example/pda'
    id='7nve413p'>
  <register xmlns='urn:xmpp:mix:0'>
    <nick>thirdwitch</nick>
  </register>
  <error type='cancel'>
    <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>
      

If the register request does not contain a <nick/> element, then the MIX service assigns one. It is recommended that the assigned nick is a UUID unique identifier following RFC 4122 [23].

5.1.6 Setting User Presence

A user joins a channel over an extended period, and membership in a channel does not generally change when user goes online or offline. The users membership of the channel is reflected by the user's bare JID in the participant node. All messages to the channel are sent to this JID.

A user may share presence information with the channel, for one or more online clients. Where a user shares presence information with a channel, the channel is entered by the user's server into the user's roster when the user subscribes to the channel. When an XMPP client comes online or changes presence status, this will be communicated by the user to the user's server using broadcast presence. The user's XMPP server is then responsible to share this presence information to each entry in the roster and in particular to each MIX channel in the roster. The MIX channel will update the "urn:xmpp:mix:nodes:presence" node with any change of status and the updated presence information and then share this updated presence with users subscribed to this node, as described below. When the user sets an explicit status, this is used to modify the presence node in the channel. When a client being used by the user goes offline, the associated server will send presence status "unavailable" to the MIX channel, which will cause the full JID for that client to be removed from the presence node.

A channel may require that all channel members share presence information with the channel, which is represented in the "urn:xmpp:mix:nodes:presence" node. If sharing presences is required by the channel, an XMPP client conforming to this specification SHALL share presence with the channel by including the channel in the user's roster. Note that the MIX server cannot generally enforce this, but it can require and enforce that when a message is sent to the channel, that the sender of the message is in the presence list.

Presence status and availability is set in a MIX channel by standard presence messages sent to the MIX channel by the user's server. User's wishing to receive presence updates will subscribe to the MIX channel presence node. Presence updates are sent out to subscribing using standard XEP-0045 compatible presence messages.

A user setting status is now used as an example. Unlike in Multi-User Chat (XEP-0045) [24] where coming online is a special action, coming online in MIX is implicit when presence status is set. Going offline is a achieved by setting presence status to unavailable, which removes the client full JID entry from the presence node. When a user sets a presence status, the user's server sends updated presence to the MIX channel, and the MIX server then publishes the user's availability to the "urn:xmpp:mix:nodes:presence" node. If there is not an item named by the full JID of the client with updated presence status, this item is created. If there is not an item named by the full JID of the client with updated presence status, then an item is created.

Example 25. User Setting Presence Status

        <presence xmlns='jabber:client' from=‘hag66@shakespeare.example/pda’ to='coven@mix.shakespeare.example'>
          <show>dnd</show>
          <status>Making a Brew</status>
        </presence>

      

The user's presence information is then published by the service to the "urn:xmpp:mix:nodes:presence" node, with the 'publisher' attribute set to the user's participant identifier (the proxy JID. The MIX channel then broadcasts the presence change to all users who are subscribed to the "urn:xmpp:mix:nodes:presence" node. The presence message is sent from the proxy (anonymized) full JID of the user.

Example 26. Channel Distributes Presence

<presence from='coven+123435@mix.shakespeare.example/678'
         to='coven@mix.shakespeare.example'
         id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'>
          <nick xmlns='http://jabber.org/protocol/nick'>thirdwitch</nick>
          <show>dnd</show>
          <status>Making a Brew</status>
        </presence>

      

The presence is distributed to those subscribing to the MIX channel presence node using a standard XMPP presence message. The presence change is recorded on the "urn:xmpp:mix:nodes:presence" node in the item for the full JID of the client to which the presence relates. The history of this node will be held as PubSub format in the MAM archive, so that presence history may be viewed.

5.1.7 Coming Online: Obtaining Presence

The presence information for a channel is stored in the urn:xmpp:mix:nodes:presence node and distributed using standard presence messages to users subscribing to this presence node. The user's server will then pass this presence information on to all online clients. When a client goes offline, it will lose synchronization with the presence node. When the client comes online, the clients server will send a directed presence message to the MIX channel. This will happen as a consequence of the MIX channel being in the user's roster and the MIX channel sending a presence update to the MIX channel. When the MIX channel adds or modifies presence for a client to the roster, this presence change will be distributed to all users subscribing to the presence node.

When the full JID of a client is added to the MIX channel presence node and that full JID is not in the presence list, the MIX channel will send to the client presence for all of the items in the presence node using standard presence messages. This will give the client full current presence.

5.1.8 Determining Real JIDs

Presence information will provide a MIX client with the nicks and anonymized proxy JIDs for participants. For JID visible rooms, the user may look up the real JID using the "urn:xmpp:mix:nodes:jidmap" node. The items in this node are identified by proxy JID, and so the real JID can be retrieved using a straightforward PubSub query. While a user may subscribe to the jidmap node, it is more likely to be used to directly look up JIDs as and when needed.

5.1.9 Coming Online: Synchronizing Message History

A MIX client will typically display message history of the channel to the user. When a client comes online it will need to obtain this message history from the MAM archive associated with the channel. There are three basic approaches a client will take:

1. If the client has previously displayed message history and has been offline for a reasonably small time, the client will wish to retrieve all messages since the last one displayed to the user.
2. The client may wish to display a fixed number of messages, perhaps finding more messages if the client subsequently requests.
3. The client may wish to display messages from a recent time period, perhaps finding more messages if the client subsequently requests.

AUTHOR'S NOTE: Examples to be added

5.1.10 Going Offline

When a client goes offline, this presence update is sent by the client's server to the MIX channel. From the client perspective, this is the same as any other presence change. Handling by the MIX channel is slightly different.

Example 27. Client Goes Offline in the Channel

<presence type='unavailable'
    from='hag66@shakespeare.example/pda'
    to='coven@mix.shakespeare.example'/>
      

The MIX channel will retract (remove) the item in the presence node of the MIX channel identified by the client's full JID. The MIX channel will notify subscribers to the presence node of the user going offline using a presence message from the proxy JID of the client.

Example 28. Channel Distributes Notification of Client going Offline

<presence from='coven+12345@mix.shakespeare.example/678'
         to='hecate@shakespeare.example'
         id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'>
          type=unavailable
        </presence>

      

There is the possibility that the message associated with the user going offline will be lost. If this happens, "ghost" entries will appear in the presence node. A MIX server may take steps to address this, for example by probing client with a disco for presence items that remain unchanged for a long period.

It is desirable to prevent clients from going offline briefly and then coming back online again, as this will lead to "flapping presence". The recommended approach to achieve this is use of Stream Management (XEP-0198) [25] to maintain an XMPP client connection in the event of short term TCP failure.

5.1.11 Sending a Message

A user sends a message to a MIX channel as a standard groupchat message, in exactly the same way as for Multi-User Chat (XEP-0045) [26].

Example 29. User Sends Message to Channel

<message
    from='hag66@shakespeare.example/pda'
    to='coven@mix.shakespeare.example'
    id='92vax143g'
    type=groupchat>
        <body>Harpier cries: 'tis time, 'tis time.</body>
   </message>
      

The message comes from the channel as a pubsub notification, with the 'publisher' attribute set to the participant identifier of the sender.

Example 30. Channel Reflects Message to Participants

<message from='coven+12345@mix.shakespeare.example/678'
         to='hecate@shakespeare.example'
         id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
         type=groupchat>
        <body>Harpier cries: 'tis time, 'tis time.</body>
</message>
      

5.1.12 Retracting a Message

A MIX channel MAY support message retraction, where the sender of a messages deletes a messages from the message history and optionally replace it with another message. This retraction mechanism will be based on the Publish-Subscribe (XEP-0060) [27] retract operation. A client looking at message history may choose to look at "current state" which will show status after the retraction or "full history" which will include the message that was retracted.

AUTHOR'S NOTE: Define new protocol to support this and add example.

5.1.13 Inviting another user to joing a Channel

When a channel member invites another user to join a channel, a sequence of steps are followed.

1. The channel member sends to the channel requesting an invite for the user.
2. The channel sends an invitation to the user requesting the invite.
3. The channel member sends the invitation to the invitee.
4. The invitee uses the invitation to construct a request to join the channel.

AUTHOR'S NOTES AND QUESTION: To be expanded considerably. Dave (Cridland?) raised a point about contact preverification about users' invites. If this is still relevant, please raise it again and we will consider how to address it.

5.1.14 Sending Private Messages

A user may add a proxy JID from the participants node of a MIX channel to the user's roster. This will enable convenient communication with the user through the MIX channel, without the user knowing the real JID of the channel participant.

AUTHOR'S NOTE: To be expanded considerably.

5.1.15 Requesting vCard

A user may request the vCard of a channel participant by sending a requestion through the channel.

AUTHOR'S NOTES: To be expanded considerably.

5.3.1 Checking For Permission To Create a Channel

MIX does not standardize an access control model for creating and deleting MIX channels. The choice is left to the MIX implementer, and could be a very simple or complex approach.

AUTHOR'S NOTE: MIX Protocol to be added to create channel; check for permission to create channel; delete channel

Example 31.

5.3.2 Creating a Channel

AUTHOR'S NOTE: Dave Cridland has suggested the following protocol. <iq to='mix.cridland.im' type='set'> <create channel='some-room-here@mix.cridland.im' xmlns='urn:xmpp:mix:0'> <optional-configuration-form/> </create> </iq>

Example 32.

5.3.3 Creating a Channel for Ad Hoc User

Rooms may be created for ad hoc use between a set of users. Channels of this nature will have channel name created by the server and will not be addressable or discoverable.

Example 33.

5.3.4 Configuring a Channel

Channel jid is set on channel creation and may not be changed. All other channel may be changed if channel configuration allows.

AUTHOR'S NOTE: Allow configuration by direct writes to 'urn:xmpp:mix:nodes:config' and ACL node. Also specify MIX XEP-0004 commands to achieve this.

Example 34.

5.3.5 Destroying a Channel

MIX channels are always explicitly destroyed by an owner of the channel or by a server operator. There is no concept of temporary channel, equivalent to Multi-User Chat (XEP-0045) [29] temporary room which is automatically destroyed by the server when the users leave. However, channels may be configured with an explicit lifetime, after which the channel MUST be removed by the MIX server. Where a channel is created for ad hoc use, it may be desirable to keep the channel for history reference or for re-use by the same set of users.

Note that the owner of the channel does not need to have presence registered in the channel in order to destroy it.

AUTHOR'S NOTE: More TBS

Example 35.

5.3.6 Server Destroying a Channel

Servers may destroy channels which have no participants and/or presence according to local policy. There will often be good reasons to not destroy rooms in these scenarios.

5.3.7 Modifying User Affiliations

Example 36.

5.3.8 Removing a User From a Channel (Kicking)

Example 37.

Significant update based on XMPP Summit discussions

Fix XML in join example.

Initial published version approved by the XMPP Council.

First draft.