You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 
 

207 lines
8.2 KiB

<?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>Experimental</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>