From e71b4c6061aeb10c1fb201a68768a572a33d2e44 Mon Sep 17 00:00:00 2001
From: Steve Kille <Steve Kille>
Date: Wed, 7 Sep 2016 13:48:50 +0100
Subject: [PATCH] Add Client Discovery Capability

---
 xep-0369.xml | 31 +++++++++++++++++++++++++++++--
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/xep-0369.xml b/xep-0369.xml
index f5b48585..f19d56ca 100644
--- a/xep-0369.xml
+++ b/xep-0369.xml
@@ -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>