XEP-0403: Mediated Information eXchange (MIX): Presence Support.

Abstract:This document defines an extension to Mediated Information eXchange (MIX) specified in XEP-0369 to provide presence information for MIX clients to MIX channel participants.
Authors:Kevin Smith, Steve Kille
Copyright:© 1999 – 2017 XMPP Standards Foundation. SEE LEGAL NOTICES.
Type:Standards Track
Last Updated:2018-05-21

WARNING: This Standards-Track document is Experimental. Publication as an XMPP Extension Protocol does not imply approval of this proposal by the XMPP Standards Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems are advised to carefully consider whether it is appropriate to deploy implementations of this protocol before it advances to a status of Draft.

Table of Contents

1. Introduction
2. Requirements
3. Concepts
    3.1. User Presence in MIX
    3.2. MIX Channels in Roster
    3.3. Presence Node
4. Use Cases
    4.1. Common User Use Cases
       4.1.1. Setting User Presence
       4.1.2. Client Coming Online and Obtaining Presence from the Local Server
       4.1.3. Going Offline
       4.1.4. User Leaving a Channel
5. Presence Initializion
6. Internationalization Considerations
7. Security Considerations
8. IANA Considerations
9. XMPP Registrar Considerations
10. XML Schema
11. Acknowledgements

    A: Document Information
    B: Author Information
    C: Legal Notices
    D: Relation to XMPP
    E: Discussion Venue
    F: Requirements Conformance
    G: Notes
    H: Revision History

1. Introduction

The Mediated Information eXchange (MIX) protocol framework and core capabilities for message distribution are specified in Mediated Information eXchange (MIX) (XEP-0369) [1] (MIX-CORE). This specification enables presence status of online clients belonging to channel participants to be shared through the channel with participants that wish to see this presence status. This is a achieved by a MIX presence node, which channel participants may subscribe to.

2. Requirements

This specification addressed a number of presence requirements:

  1. The mechanism must work cleanly for participants with multiple clients.
  2. Standard presence messages must be used to share presence.
  3. Nick changes should be visible as changes (and not as a new user).
  4. Where Mediated Information eXchange (MIX): JID Hidden Channels. (XEP-0404) [2] is not used, participants must be able to directly contact other participants.

3. Concepts

3.1 User Presence in MIX

MIX channels store presence of each online client for a user that chooses to publish presence. Presence is stored in the presence node and is encoded using a full proxy JID. Where a user publishes presence for one or more clients, this information is available to all users subscribing to the channel presence.

A client participating in a MUC channel MAY send it's presences status to the MIX channel using standard presence. The mechanisms to do this are summarized in the next section and standardized in Mediated Information eXchange (MIX): Participant Server Requirements (XEP-0405) [3].

The MIX channel will distribute received presence to participants that have subscribed to the participants node. The client to which each presence update refers is identified by the <from> of the presence sent by the MIX channel. This is also the JID stored in the MIX presence node. This JID is built from two components:

  1. The bare proxy JID of the client, as specified in Mediated Information eXchange (MIX) (XEP-0369) [1]. This encodes channel and a stable random ID in a JID associated with the MIX domain, which enables it to be used for sending presence.
  2. The resource taken from the client’s full JID, except when Mediated Information eXchange (MIX): JID Hidden Channels. (XEP-0404) [2] is used, when the resource is hidden.

A client receiving this presence can use information from the channel participant's node to derive the full JID of the client and an associated Nick. When Mediated Information eXchange (MIX): JID Hidden Channels. (XEP-0404) [2] is used to hide JIDs, only the Nick can be derived.

Presence updates are distributed by a channel to the bare JID of each participant and then the subscriber's server will distribute to each of the participant's currently online clients following the rules set out in Mediated Information eXchange (MIX): Participant Server Requirements (XEP-0405) [3].

3.2 MIX Channels in Roster

When a user joins a MIX channel, the channel MUST be added to the user's roster, as specified in Mediated Information eXchange (MIX): Participant Server Requirements (XEP-0405) [3]. There are two reasons for this.

  1. It enables a client to determine which channels the user has joined and so may expect messages and/or presence updates from (dependent on what the user has subscribed to).
  2. When the user has chosen to share presence with the channel, it enables this to happen using standard presence mechanisms. This avoids the need for MIX-specific mechanisms for clients to update presence on a channel. When a client comes online, presence information will be sent to each MIX channel that the user participates in. This will update other channel participants. It will also lead to a presence update for each MIX channel being sent to the client. So a user will receive channel presence information as the user comes online, in contrast to being subsequent to a MUC Join.

3.3 Presence Node

MIX defines one node to support presence, as summarized in the table below. This node is required to support this specification.

Table 1: MIX Presence Node

Presence'urn:xmpp:mix:nodes:presence'For storing information about the availability status of online participants, which MAY include multiple clients for a single participant.PresencePresence

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, so that active channel participants are visible. It is not possible to enforce this in the server, so participants in a channel with this option MUST publish presence. Each item in the presence node is identified by a JID constructed from the proxy JID and the resource for the client. The presence is encoded as a standard a presence stanza using a <presence/> element qualified by the 'jabber:client' namespace.

This node MAY be subscribed to by users using the user's bare JID. So presence of online clients is sent to the user's server for each user subscribed to this node. Presence is always sent using standard presence protocol and MUST NOT be sent using pubsub protocol. Clients MUST NOT directly access the presence node using pubsub. The Presence node is a permanent PubSub node. The following example shows a presence node value for the full JID 'hecate@shakespeare.example/UUID-x4r/2491'.

Example 1. Value of Presence Node

<items node='urn:xmpp:mix:nodes:presence'>
  <item id='123456#coven@mix.shakespeare.example/UUID-x4r/2491'>
    <presence xmlns='jabber:client'>
      <status>Making a Brew</status>

4. Use Cases

4.1 Common User Use Cases

4.1.1 Setting User Presence

A user joins a channel over an extended period, and participation in a channel does not generally change when user goes online or offline. The user's participation in a 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. The channel is entered by the user's server into the user's roster when the user subscribes to the channel as specified in Mediated Information eXchange (MIX): Participant Server Requirements (XEP-0405) [3]. Where a user shares presence information with a channel, the subscription is configured with one way presence, which will cause all presence changes for the client to be sent 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 node item for that client to be removed from the presence node.

Presence status and availability is set in a MIX channel by standard presence stanzas sent to the MIX channel by the user's server. Users wishing to receive presence updates will subscribe to the MIX channel presence node. Presence updates are sent out to subscribing participants using standard presence stanzas.

A user setting status is now used as an example. Unlike in Multi-User Chat (XEP-0045) [4] 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 service 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. The sequence is shown in the following examples, starting with a client setting presences status on the connected server.

Example 2. Client Sets Presence Status on Server

<presence xmlns='jabber:client'
  <status>Making a Brew</status>

The server then sends the presence information to roster entries. The following example then shows the presence message from the client's server to the MIX channel.

Example 3. Server sends Presence Status to MIX Channel

<presence  from='hag66@shakespeare.example/UUID-a1j/7533'
  <status>Making a Brew</status>

The user's presence information is then published by the service to the "urn:xmpp:mix:nodes:presence" node. The MIX channel then broadcasts the presence change to all users who are subscribed to the "urn:xmpp:mix:nodes:presence" node. The presence stanza is sent from the full proxy JID of the client updating status. Note that presence is associated with a client and so will have a full JID. The following example shows a presence message as distributed by the server to a presences subscriber.

Example 4. Channel Distributes Presence

        <presence from='123435#coven@mix.shakespeare.example/UUID-a1j/7533'
  <status>Making a Brew</status>

The presence is distributed to those subscribing to the MIX channel presence node using a standard XMPP presence stanza. The presence change is recorded on the "urn:xmpp:mix:nodes:presence" node.

The history of the presence node MAY be archived using MAM. The MAM archive stores the node in PubSub format, following the node specification. This enables presence history to be retrieved using PubSub.

4.1.2 Client Coming Online and Obtaining Presence from the Local Server

MIX Clients obtain presence from their local server. This is specified in Mediated Information eXchange (MIX): Participant Server Requirements (XEP-0405) [3].

4.1.3 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. The MIX Channel also needs to remove the client from the participant's node.

Example 5. Client Goes Offline in the Channel

<presence type='unavailable'

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 by sending a presence stanza to the full JID of each client. The presence stanza will reference the full proxy JID of the client that is going offline, as shown in the following example:

Example 6. Channel Distributes Notification of Client going Offline

        <presence from='12345#coven@mix.shakespeare.example/UUID-a1j/7533'

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 service MAY take steps to address this, for example by probing client with a disco for presence items that remain unchanged for a long period.

4.1.4 User Leaving a Channel

The primary actions for a user leaving a channel are specified in Mediated Information eXchange (MIX) (XEP-0369) [1]. This section sets out additional actions for handling presence. When a user leaves the channel, all entries for the user's clients MUST be removed from the participants node. The MIX channel MUST distribute unavailable presence notifications for each client removed to all subscribers of the participants node.

Example 7. Channel Distributes Notification when User Leaves Channel

        <presence from='12345#coven@mix.shakespeare.example/UUID-a1j/7533'

5. Presence Initializion

For an active MIX Channel, the presence node is updated as channel participants change status and presence information is sent to the channel. When a MIX channel starts, typically when the associated MIX Service and Server start, there is a need to initialize the presence node. This is done by the XMPP server associated with the MIX channel sending out a presence probe for each channel participant, following the presence probe process specified in RFC 6121 [5]. A presence probe MUST NOT be sent for users who have set presence preference to not sharing.

6. Internationalization Considerations

See considerations in Mediated Information eXchange (MIX) (XEP-0369) [1].

7. Security Considerations

See considerations in Mediated Information eXchange (MIX) (XEP-0369) [1].

When converting a 1:1 conversation to a channel there is potential to expose sensitive information and to present invalid information.

8. IANA Considerations


9. XMPP Registrar Considerations

The urn:xmpp:mix namespace needs to be registered.

10. XML Schema

To be supplied when MIX progresses to proposed standard.

11. Acknowledgements

See Mediated Information eXchange (MIX) (XEP-0369) [1] for a list of contributors to the MIX Family of specifications.


Appendix A: Document Information

Series: XEP
Number: 0403
Publisher: XMPP Standards Foundation
Status: Experimental
Type: Standards Track
Version: 0.1.0
Last Updated: 2018-05-21
Approving Body: XMPP Council
Dependencies: XMPP Core, XMPP IM, XEP-0004, XEP-0030, XEP-0054, XEP-0060, XEP-0084, XEP-0128, XEP-0198, XEP-0292, XEP-0297, XEP-0313, XEP-0369, XEP-0372, XEP-0405
Supersedes: None
Superseded By: None
Source Control: HTML
This document in other formats: XML  PDF

Appendix B: Author Information

Kevin Smith

Email: kevin.smith@isode.com
JabberID: kevin.smith@isode.com

Steve Kille

Email: steve.kille@isode.com
JabberID: steve.kille@isode.com

Appendix C: Legal Notices


This XMPP Extension Protocol is copyright © 1999 – 2018 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.

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

Appendix D: Relation to XMPP

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.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> 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 <editor@xmpp.org>.

Appendix F: Requirements Conformance

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

Appendix G: Notes

1. XEP-0369: Mediated Information eXchange (MIX) <https://xmpp.org/extensions/xep-0369.html>.

2. XEP-0404: Mediated Information eXchange (MIX): JID Hidden Channels. <https://xmpp.org/extensions/xep-0404.html>.

3. XEP-0405: Mediated Information eXchange (MIX): Participant Server Requirements <https://xmpp.org/extensions/xep-0405.html>.

4. XEP-0045: Multi-User Chat <https://xmpp.org/extensions/xep-0045.html>.

5. RFC 6121: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://tools.ietf.org/html/rfc6121>.

Appendix H: Revision History

Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/

Version 0.1.0 (2018-05-21)

Split out from MIX 0.10.0;