XEP-0369: Mediated Information eXchange (MIX)

Abstract:This document defines Mediated Information eXchange (MIX), an XMPP protocol extension for the exchange of information among multiple participants through a mediating service. The protocol can be used to model group communication applications such as chatrooms, although with greater flexibility and extensibility than existing groupchat technologies such as Multi-User Chat (MUC). Although MIX supports standard groupchat features such as discussion topics and invitations, and also defines a strong access control model similar to that of MUC, it enables users to participate without sharing presence, allows communication of any structured data (not only textual messages), reuses Publish-Subscribe so that users can receive only the information formats in which they are interested, and reuses Message Archive Management (MAM) to provide more robust storage and archiving.
Authors:Kevin Smith, Peter Saint-Andre
Copyright:© 1999 - 2016 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status:Experimental
Type:Standards Track
Version:0.1
Last Updated:2016-01-07

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. MIX and PubSub
    3.2. MIX and MAM
    3.3. Standard Nodes
4. Discovery
    4.1. Discovering a MIX service
    4.2. Discovering the Conversations on a Service
    4.3. Discovering Conversation Information
    4.4. Discovering Nodes at a Conversation
    4.5. Discovering Participants in a Conversation
5. Use Cases
    5.1. Common User Use Cases
       5.1.1. Joining a Conversation
       5.1.2. Registering with a MIX Service
       5.1.3. Coming Online
       5.1.4. Going Offline
       5.1.5. Sending a Message
       5.1.6. Leaving a Conversation
       5.1.7. Inviting a Contact To a Conversation
       5.1.8. Sending Private Messages
    5.2. Administrative Use Cases
       5.2.1. Checking For Permission To Create a Conversation
       5.2.2. Creating a Conversation
       5.2.3. Configuring a Conversation
       5.2.4. Destroying a Conversation
       5.2.5. Modifying User Affiliations
       5.2.6. Removing a User From a Conversation (Kicking)
6. Configuration options
    6.1. Transparency
7. Internationalization Considerations
8. Security Considerations
9. IANA Considerations
10. XMPP Registrar Considerations
11. XML Schema
12. Acknowledgements

Appendices
    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

Multi-User Chat (MUC) is a major application of XMPP that was developed in 2002 and standardized in Multi-User Chat (XEP-0045) [1]. This Mediated Infromation eXchange (MIX) protocol defined here implements the same basic MUC patterns in a more flexible and extensible way in order to address requirements that have emerged since MUC was developed. MIX supports all of the core chatroom features that are familiar from MUC, such as discussion topics and invitations. Like MUC, it also defines a strong access control model, including the ability to kick and ban users, to name moderators and administrators, and to require membership in order to participate in conversations.

MUC exists and works, so why replace it? There are several reasons:

Because it is anticipated that there will significant co-existence between MUC and MIX, this specification is designed so that:

If a server wishes to expose both MUC and MIX representations of chatrooms, it SHOULD do so by serving MUC and MIX on different domains. The MIX service SHOULD include a reference to the MUC mirror, so that clients understanding both protocols can choose to only show one copy of the service.

2. Requirements

3. Concepts

The following concepts underlie the design of MIX.

3.1 MIX and PubSub

MIX is based upon domains providing a MIX service, such as `mix.shakespeare.example`. Note that although PubSub communication is used, a domain used for MIX is a MIX domain and not a standard Publish-Subscribe (XEP-0060) [8] domain. (Note that, like in MUC, there is no requirement on the naming of these domains; the label 'mix' and the fact that it is a subdomain of a 'shakespeare.example' service is purely an example).

Every MIX conversation is an addressable PubSub service (with additional MIX semantics) that will be addressed by an XMPP client using a bare JID, for example coven@mix.shakespeare.example. While Publish-Subscribe (XEP-0060) [9] is used as the basis for the MIX model, some protocol is added or optimised in this document for the MIX use cases. For example, when a message is published to the 'urn:xmpp:mix:nodes:messages' node, a message unlike a Publish-Subscribe (XEP-0060) [10] payload is distributed to occupants (more akin to the old Multi-User Chat (XEP-0045) [11]); this enables standard XMPP semantics of message stanzas to be used.

3.2 MIX and MAM

Message Archive Management is used for all storage of historical data (such as the history of messages sent within the conversation). Each node can be archived separately (e.g., the presence node or the configuration node). MIX clients can retrieve information archived in MAM in order to quickly resync with regard to a conversation, and can do so without necessarily providing presence information.

3.3 Standard Nodes

The standard nodes are as follows (although note that not every conversation will necessarily use each node):

4. Discovery

4.1 Discovering a MIX service

To determine if a domain hosts a MIX service, a Service Discovery (XEP-0030) [12] info query should be sent in the usual manner

Example 1. Entity queries a service

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

The MIX service then MUST return its identity and the features it supports, which MUST include the 'urn:xmpp:mix:0' feature, and the identity MUST have a category of 'conference' and a type of 'text'. TODO: do we want a different type?

Example 2. Service responds with Disco Info result

<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 var='urn:xmpp:mix:nodes:muc_mirror'
             label='Location of MUC mirror service'>
        <value>chat.shakespeare.example</value>
      </field>
    </x>
  </query>
</iq>

If the MIX service is mirrored to a MUC service for backwards-compatibility, this SHOULD be signaled by the inclusion of a 'urn:xmpp:mix:nodes:muc_mirror' field, the value of which is the mirrored MUC domain, in the extended disco results in a form whose type value is 'urn:xmpp:mix:0#serviceinfo'. Note that the MIX service itself doesn't advertise support for Message Archive Management (XEP-0313) [13], nor is support for generic Publish-Subscribe (XEP-0060) [14] advertised.

4.2 Discovering the Conversations on a Service

There is no need for using Service Discovery here, since the MIX service provides a node "urn:xmpp:mix:nodes:conversations" that pushes out one event for each conversation that has been created at the service.

4.3 Discovering Conversation Information

In order to find out more information about a given conversation, a user can send a disco#info query to the conversation.

Example 3. Entity Queries for Information about a Specific Conversation

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

The conversation MUST return its identity and the features it supports:

Example 4. Conversation Returns Disco Info Result

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

4.4 Discovering Nodes at a Conversation

Use disco#items to find the nodes associated with a conversation.

Example 5. Entity Queries for Nodes at a Conversation

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

Example 6. Room Returns Disco Items Result

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

4.5 Discovering Participants in a Conversation

*Not* done with disco#items (which returns nodes), instead query items on the "urn:xmpp:mix:nodes:participants" node (if you're allowed).

5. Use Cases

5.1 Common User Use Cases

5.1.1 Joining a Conversation

A user joins a conversation by sending a MIX "join" command. There's no default set of nodes: all nodes must be specified if the user wants that information (but clients should pick the standard MIX ones at least by default for normal usage). It's possible to forward-subscribe to nodes that don't yet exist, in case they're added (e.g., presence added to a MUC). The server injects a new item into the "urn:xmpp:mix:nodes:participants" node automatically. TODO: include the nickname at this point?

Example 7. User Joins a Conversation

<iq type='set'
    from='hag66@shakespeare.example'
    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'/>
  </pubsub>
</iq>

The conversation must process the join atomically. The conversation responds with an IQ-result. This stanza includes the nodes to which the user was subscribed, as well as the JID that will be used for the user in this room (real JID for non-anonymous rooms, proxy JID for semi-anonymous rooms). TODO: does this need to always be a proxyJID? List discussion.

Example 8. Conversation Successfully Processes Join

<iq type='result'
    from='coven@mix.shakespeare.example'
    to='hag66@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:presence'/>
    <subscribe node='urn:xmpp:mix:nodes:participants'/>
    <subscribe node='urn:xmpp:mix:nodes:subject'/>
    <subscribe node='urn:xmpp:mix:nodes:config'/>
  </pubsub>
</iq>

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

Example 9. Conversation Processes Join With Modifications

<iq type='result'
    from='hag66@shakespeare.example'
    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'/>
  </pubsub>
</iq>

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

Example 10. Conversation 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='33EB6D2A-3473-4FFB-82DF-C4290FB761E4'>
        <participant xmlns='urn:xmpp:mix:0'
                     jid='hag66@shakespeare.example'
                     nick='thirdwitch'/>
      </item>
    </items>
  </event>
</message>

Each <participant> element includes a 'jid' attribute, which is the stable participant identifier for this user in this conversation. TODO: proxy/realJID mapping (admins might see real JIDs even in a semianon room)

5.1.2 Registering with a MIX Service

A user can register with the MIX service (not any particular conversation) by sending a <register/> command to the service. TODO: This should be available either room or service-based, with discovery.

Example 11. 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 12. 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 13. 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 (this SHOULD be a UUID). TODO: Discuss - is there any reason for this to be a UUID? Surely anything the server wants to assign is fine (with security consideration about leaking JID information).

5.1.3 Coming Online

Participation in the conversation is decoupled from sending presence through the conversation. A participant comes online by publishing availability to the "urn:xmpp:mix:nodes:presence" node. TODO: Move back to using presence normally (suggested with rooms in rosters), for correct 'offline' behaviour, etc.

Example 14. User Comes Online in the Conversation

<iq type='set'
    from='hag66@shakespeare.example/pda'
    to='coven@mix.shakespeare.example'
    id='hysf1v37'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='urn:xmpp:mix:nodes:presence'>
      <item>
        <presence xmlns='jabber:client'>
          <nick xmlns='http://jabber.org/protocol/nick'>thirdwitch</nick>
          <c xmlns='http://jabber.org/protocol/caps'
             hash='sha-1'
             node='http://code.google.com/p/exodus'
             ver='QgayPKawpkPSDYmwT/WM94uAlu0='/>
        </presence>
      </item>
    </publish>
  </pubsub>
</iq>

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. TODO: List discussion on the benefits of wrapping vs. normal presence.

Example 15. Conversation Distributes Presence

<message from='mix.shakespeare.example'
         to='hecate@shakespeare.example'
         id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='urn:xmpp:mix:nodes:presence'>
      <item id='ae890ac52d0df67ed7cfdf51b644e901'
            publisher='3608A5E0C4C8'>
        <presence xmlns='jabber:client'>
          <nick xmlns='http://jabber.org/protocol/nick'>thirdwitch</nick>
          <c xmlns='http://jabber.org/protocol/caps'
             hash='sha-1'
             node='http://code.google.com/p/exodus'
             ver='QgayPKawpkPSDYmwT/WM94uAlu0='/>
        </presence>
      </item>
    </items>
  </event>
</message>

5.1.4 Going Offline

To go offline, the user sends a normal unavailable stanza (usually through their server's usual offline broadcast rules).

Example 16. User Goes Offline in the Conversation

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

The conversation retracts the item and notifies subscribers to the presence node. TODO: Update depending on discussion about events vs. presence.

5.1.5 Sending a Message

A user sends a message by publishing it to messages node. TODO: List discussion about type=groupchat messages vs. xep60 publish.

Example 17. User Sends Message to Conversation

<iq type='set'
    from='hag66@shakespeare.example/pda'
    to='coven@mix.shakespeare.example'
    id='92vax143g'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='urn:xmpp:mix:nodes:messages'>
      <item>
        <body xmlns='jabber:client'>Harpier cries: 'tis time, 'tis time.</body>
      </item>
    </publish>
  </pubsub>
</iq>

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

Example 18. Conversation Reflects Message to Participants

<message from='mix.shakespeare.example'
         to='hecate@shakespeare.example'
         id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'>
  <event xmlns='http://jabber.org/protocol/pubsub#event'>
    <items node='urn:xmpp:mix:nodes:messages'>
      <item id='bnd81g37d61f49fgn581'
            publisher='3608A5E0C4C8'>
        <body xmlns='jabber:client'>Harpier cries: 'tis time, 'tis time.</body>
      </item>
    </items>
  </event>
</message>

5.1.6 Leaving a Conversation

In order to permanently leave a conversation, a user sends a MIX "leave" command.

Example 19. User Leaves a Conversation

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

Note that leaving the conversation is a permanent action for a user across all clients, not just a matter of telling the conversation that the user is not currently available (as in MUC), or for a single client. If the user leaves the conversation, the MIX service is responsible for unsubscribing the user from all nodes in the conversation, and also for telling participants that the user is offline.

5.1.7 Inviting a Contact To a Conversation

User sends to conversation requesting invite, receives it, forwards it to contact. Solves issues with both directed and mediated invites. ### TODO: Dave had a point about contact preverification about users' invites. Discuss.

5.1.8 Sending Private Messages

Users' JIDs are available from the "urn:xmpp:mix:nodes:participants" node if the conversation is transparent.

5.2 Administrative Use Cases

5.2.1 Checking For Permission To Create a Conversation

Example 20.

5.2.2 Creating a Conversation

Example 21.

5.2.3 Configuring a Conversation

Example 22.

5.2.4 Destroying a Conversation

Example 23.

5.2.5 Modifying User Affiliations

Example 24.

5.2.6 Removing a User From a Conversation (Kicking)

Example 25.

6. Configuration options

6.1 Transparency

TODO: transparent vs. opaque conversations

7. Internationalization Considerations

TBD.

Discuss normalization of nicknames.

8. Security Considerations

TBD.

Topics to cover:

9. IANA Considerations

None.

10. XMPP Registrar Considerations

Register a namespace.

11. XML Schema

TBD.

12. Acknowledgements

Thanks to the participants in XMPP Summit 18 for their significant input during design sessions: Dave Cridland, Philipp Hancke, Waqas Hussain, Lance Stout, Sam Whited, and Matthew Wild.

Appendices

Appendix A: Document Information

Series: XEP
Number: 0369
Publisher: XMPP Standards Foundation
Status: Experimental
Type: Standards Track
Version: 0.1
Last Updated: 2016-01-07
Approving Body: XMPP Council
Dependencies: XMPP Core, XMPP IM, XEP-0004, XEP-0030, XEP-0060, XEP-0313
Supersedes: None
Superseded By: None
Short Name: MIX
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

Peter Saint-Andre

Email: peter@andyet.net
JabberID: stpeter@stpeter.im
URI: https://stpeter.im/

Appendix C: Legal Notices

Copyright

This XMPP Extension Protocol is copyright © 1999 - 2016 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 <http://xmpp.org/about-xmpp/xsf/xsf-ipr-policy/> or obtained by writing to XMPP Standards Foundation, 1899 Wynkoop Street, Suite 600, Denver, CO 80202 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-0045: Multi-User Chat <http://xmpp.org/extensions/xep-0045.html>.

2. XEP-0060: Publish-Subscribe <http://xmpp.org/extensions/xep-0060.html>.

3. XEP-0313: Message Archive Management <http://xmpp.org/extensions/xep-0313.html>.

4. XEP-0289: Federated MUC for Constrained Environments <http://xmpp.org/extensions/xep-0289.html>.

5. XEP-0030: Service Discovery <http://xmpp.org/extensions/xep-0030.html>.

6. XEP-0163: Personal Eventing Protocol <http://xmpp.org/extensions/xep-0163.html>.

7. XEP-0313: Message Archive Management <http://xmpp.org/extensions/xep-0313.html>.

8. XEP-0060: Publish-Subscribe <http://xmpp.org/extensions/xep-0060.html>.

9. XEP-0060: Publish-Subscribe <http://xmpp.org/extensions/xep-0060.html>.

10. XEP-0060: Publish-Subscribe <http://xmpp.org/extensions/xep-0060.html>.

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

12. XEP-0030: Service Discovery <http://xmpp.org/extensions/xep-0030.html>.

13. XEP-0313: Message Archive Management <http://xmpp.org/extensions/xep-0313.html>.

14. XEP-0060: Publish-Subscribe <http://xmpp.org/extensions/xep-0060.html>.

Appendix H: Revision History

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

Version 0.1 (2016-01-07)

Initial published version approved by the XMPP Council.

(XEP Editor (asw))

Version 0.0.1 (2015-10-12)

First draft.

(kis/psa)

END