moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 16:55:07 -05:00
Code Issues Releases Wiki Activity

Add Client Discovery Capability

Browse Source
This commit is contained in:
Steve Kille 2016-09-07 13:48:50 +01:00
parent 2a5599dafa
commit e71b4c6061
1 changed files with 29 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
xep-0369.xml
View File

@ -509,6 +509,31 @@
Online clients in the channel are determined from the presence node. Participants in the channel are determined from the "urn:xmpp:mix:nodes:participants" node which will give proxy JID and nick. The jidmap node is used to map to real JIDs. </p>
<p>AUTHOR'S NOTE: Add example</p>
</section2>
<section2 topic="Discovering Client MIX Capability" anchor="mix-client-discovery">
<p>
Where a client supports MIX, it MUST advertise this capability in response to a Disco request. This will enable other entities to determine if a client supports MIX. The following example shows a Disco response from a client that supports both MIX and MUC.
</p>
<example caption='Disco Response showing MIX support'><![CDATA[
<iq from='romeo@montague.lit/orchard'
id='disco1'
to='juliet@capulet.lit/chamber'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://code.google.com/p/exodus#QgayPKawpkPSDYmwT/WM94uAlu0='>
<identity category='client' name='Exodus 0.9.1' type='pc'/>
<feature var='http://jabber.org/protocol/caps'/>
<feature var='http://jabber.org/protocol/disco#info'/>
<feature var='http://jabber.org/protocol/disco#items'/>
<feature var='http://jabber.org/protocol/muc'/>
<feature var='http://jabber.org/protocol/mix'/>
</query>
</iq>
]]></example>
</section2>
</section1>
<section1 topic='Use Cases' anchor='usecases'>
@ -1147,9 +1172,11 @@
<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. A simple approach might be to always send a MUC invite, and anticipate that a MIX capable client will be able to perform the same calculation and join the MIX channel based on a MUC invite. Another simple approach would be to try the MIX invite and only fall back to MUC invite if the MIX invite failes.
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>
<p>QUESTION: Input on this is invited. What can/should be recommended.</p>
</section2>
</section1>