Initial chop

This commit is contained in:
Steve Kille 2018-05-21 09:33:55 +01:00
parent 3afbdf0ee4
commit 18ca8d4ad4
1 changed files with 188 additions and 0 deletions

188
xep-0408.xml Normal file
View File

@ -0,0 +1,188 @@
<?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): C0-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>0404</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-PRESENCE</shortname>
&ksmithisode;
&skille;
<revision>
<version>0.1.0</version>
<date>2018-05-14</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 capbilities are specified in &xep0369; (MIX-CORE).
</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p></p>
</section1>
<section1 topic="Supporting MIX and MUC together" anchor="mix-and-muc-together">
<p>
MIX is specified as a service that can be used independent of MUC and a MIX service MAY be implemented without MUC. 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 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 MIX service that also supported MUC would respond:</p>
<example caption="Service responds with Disco Info result showing MIX and MUC support" ><![CDATA[
<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:1'/>
<feature var='http://jabber.org/protocol/muc'/>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:1#serviceinfo</value>
</field>
</x>
</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 MIX. If is not set, MUC room specific information is returned.
</p>
<p>For the partially integrated service, it will be useful for clients that support both MIX and MUC to be able to determine that the server supports both protocols. For a MIX client, it will be useful to know the MUC service, so that this information can be shared with a MUC client invitation. This information is provided by the initial service discovery:</p>
<example caption="MIX Service responds with Disco Info result sharing MUC service location" ><![CDATA[
<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:1'/>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE' type='hidden'>
<value>urn:xmpp:mix:1#serviceinfo</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:1#serviceinfo'. The field with var='muc-mirror' is the value of which is the mirrored MUC domain's JID. </p>
<p>Where a client supporting both MIX and MUC is given a reference to a MUC room, it is desirable that the client can determine the MIX channel and join using MIX. This is achieved by an equivalent extension to MUC service discover.</p>
<example caption="MUC Service responds with Disco Info result sharing MIX service location" ><![CDATA[
<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:1#serviceinfo</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:1#serviceinfo'. 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
<link url='#mix-client-discovery'>Discovering Client MIX Capability</link>. If the client supports MIX a MIX invite SHOULD be sent.
</p>
</section2>
</section1>
<section1 topic='Internationalization Considerations' anchor='i18n'>
<p>See considerations in MIX-CORE.
</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>See considerations in MIX-CORE.</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 MIX-CORE for a list of contributors to the MIX Family of specifications.</p>
</section1>
</xep>