<?xml version='1.0' encoding='UTF-8'?> <!DOCTYPE xep SYSTEM 'xep.dtd' [ <!ENTITY % ents SYSTEM 'xep.ent'> %ents; ]> <?xml-stylesheet type='text/xsl' href='xep.xsl'?> <?xml-stylesheet type="text/css" href="xmpp.css"?> <xep> <header> <title>Mediated Information eXchange (MIX): Co-existence with MUC</title> <abstract>This document defines an extension to Mediated Information eXchange (MIX) specified in XEP-0369. It specifies how MIX and MUC can be operated together. </abstract> &LEGALNOTICE; <number>0408</number> <status>Deferred</status> <type>Standards Track</type> <sig>Standards</sig> <approver>Council</approver> <dependencies> <spec>XMPP Core</spec> <spec>XMPP IM</spec> <spec>XEP-0004</spec> <spec>XEP-0030</spec> <spec>XEP-0054</spec> <spec>XEP-0060</spec> <spec>XEP-0084</spec> <spec>XEP-0128</spec> <spec>XEP-0198</spec> <spec>XEP-0292</spec> <spec>XEP-0297</spec> <spec>XEP-0313</spec> <spec>XEP-0372</spec> </dependencies> <supersedes/> <supersededby/> <shortname>MIX-MUC</shortname> &ksmithisode; &skille; <revision> <version>0.1.0</version> <date>2018-05-21</date> <initials>sek</initials> <remark><p> Split out from MIX 0.10.0; </p></remark> </revision> </header> <section1 topic='Introduction' anchor='intro'> <p>The Mediated Information eXchange (MIX) protocol framework and core capabilities are specified in &xep0369; (MIX-CORE). MIX can be used independently of &xep0045; (MUC). </p> <p> It may be desirable to operate a service that provides MIX and MUC together. This specification specifies three options for achieving this. </p> </section1> <section1 topic="Supporting MIX and MUC together" anchor="mix-and-muc-together"> <p> If both MIX and MUC are implemented, three approaches are noted. </p> <ol> <li>Entirely separate MIX and MUC implementation, with MIX and MUC using separate domains and MIX channels being completely separate from MUC rooms.</li> <li>Fully integrated MIX and MUC implementation, with MIX and MUC sharing a single domain and rooms/channels equivalent.</li> <li>Partially integrated MIX and MUC implementation, with MIX and MUC using separate domains, but all rooms/channel are common. This means that each MIX channel will have MUC room of the same name and same participants. </li> </ol> <p>The fully integrated approach would be transparent to clients. The following example shows how a service that supports MIX and MUC in a fully integrated manner would respond following the specification of &xep0369;:</p> <example caption="Client uses Disco to show fully integrated MIX and MUC support" ><![CDATA[ <iq from='hag66@shakespeare.example/UUID-c8y/1573' 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/UUID-c8y/1573' type='result'> <query xmlns='http://jabber.org/protocol/disco#info'> <identity category='conference' name='Shakespearean Chat Service' type='text'/> <feature var='urn:xmpp:mix:core:0'/> <feature var='http://jabber.org/protocol/muc'/> <feature var='urn:xmpp:mix:core:0#searchable'> </query> </iq> ]]></example> <p>In the fully integrated service item discovery on the MIX/MUC service determines a list of channels. The protocol used for this is the same in MUC and MIX. Discovery actions on a channel in MIX MUST use 'node=mix' attribute in the discovery which will lead to the return of MIX channel specific information, as mandated for this discovery in &xep0369;. If is not set, MUC room specific information is returned. </p> <p>For the partially integrated service, MIX servers will reference the associated MUC server and MUC servers will reference the associated MIX service. This will allow a client that only support MUC or only supports MIX to find the right server if it is given a reference to the other one. For a client that supports both MUC and MIX, it will enable the client to select its preferred service. For a MIX client, it will also be useful to know the MUC service, so that this information can be shared with a MUC client invitation. The following example shows how a MIX server identifies the associated MUC server. Note that MUC MUST NOT be advertized as a feature: </p> <example caption="Client uses Disco to find MUC server assocated with MIX server" ><![CDATA[ <iq from='hag66@shakespeare.example/UUID-c8y/1573' 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/UUID-c8y/1573' type='result'> <query xmlns='http://jabber.org/protocol/disco#info'> <identity category='conference' name='Shakespearean Chat Service' type='text'/> <feature var='urn:xmpp:mix:core:0'/> <x xmlns='jabber:x:data' type='result'> <field var='FORM_TYPE' type='hidden'> <value>urn:xmpp:mix:muc:0#muc-mirror</value> </field> <field var='muc-mirror' type='jid-single' label='Location of MUC mirror service'> <value>chat.shakespeare.example</value> </field> </x> </query> </iq> ]]></example> <p>The result is returned in an extended disco results in a form whose type value is 'urn:xmpp:mix:muc:0#muc-mirror'. The field with var='muc-mirror' is the value of which is the mirrored MUC domain's JID. </p> <p>Similarly, a MUC service can advertise an associated MIX doming. The following example shows discovery of a MUC domain. Note that MIX MUST NOT be advertized as a feature</p> <example caption="Client uses Disco to find MIX server assocated with MUC server" ><![CDATA[ <iq from='hag66@shakespeare.example/UUID-c8y/1573' id='lx09df27' to='mix.shakespeare.example' type='get'> <query xmlns='http://jabber.org/protocol/disco#info'> </iq> <iq from='chat.shakespeare.example' id='lx09df27' to='hag66@shakespeare.example/UUID-c8y/1573' type='result'> <query xmlns='http://jabber.org/protocol/disco#info'> <identity category='conference' name='Shakespearean Chat Service' type='text'/> <feature var='http://jabber.org/protocol/muc'/> <x xmlns='jabber:x:data' type='result'> <field var='FORM_TYPE' type='hidden'> <value>urn:xmpp:mix:muc:0#mix-mirror</value> </field> <field var='mix-mirror' type='jid-single' label='Location of MUC mirror service'> <value>mix.shakespeare.example</value> </field> </x> </query> </iq> ]]></example> <p>The result is returned in an extended disco results in a form whose type value is 'urn:xmpp:mix:muc:0#mux-mirror'. The field with var='mix-mirror' is the value of which is the mirrored MIX domain's JID. </p> <section2 topic="Choosing Which Invite to Send" anchor="mix-muc-invite-choice"> <p> Where a client supports MUC and MIX and has determined that for a channel that the server also supports a MUC room, the client has a choice as to which type of invite to send. This SHOULD be done by determining if the client support MIX using the mechanism specified in &xep0369;. If the client supports MIX a MIX invite SHOULD be sent. </p> </section2> </section1> <section1 topic='Internationalization Considerations' anchor='i18n'> <p>See considerations in &xep0369;. </p> </section1> <section1 topic='Security Considerations' anchor='security'> <p>See considerations in &xep0369;.</p> <p> When converting a 1:1 conversation to a channel there is potential to expose sensitive information and to present invalid information. </p> </section1> <section1 topic='IANA Considerations' anchor='iana'> <p>None.</p> </section1> <section1 topic='XMPP Registrar Considerations' anchor='registrar'> <p>The urn:xmpp:mix namespace needs to be registered.</p> </section1> <section1 topic='XML Schema' anchor='schema'> <p>To be supplied when MIX progresses to proposed standard.</p> </section1> <section1 topic='Acknowledgements' anchor='ack'> <p>See &xep0369; for a list of contributors to the MIX Family of specifications.</p> </section1> </xep>