[Standards] MIX (XEP-0369) channel discovery

Ralph Meijer ralphm at ik.nu
Wed Oct 10 08:28:02 UTC 2018


Hi Dave,

This seems to assume that all results from a disco#items request are 
uniform. This doesn't jive with my idea of how XMPP in general, and 
especially Service Discovery, should work. XEP-0030 clearly explains 
that after getting the items, you have to send a separate request to 
find out details for such items. From section 2:

   Discovering information about a child item MUST be accomplished by
   sending a separate discovery request to that item, not to the parent
   entity. (One result of this is that discovering complete information
   about an entire tree will require multiple request/response pairs in
   order to "walk the tree".)

I also note that there is a difference in how the items are returned for
MUC and MIX. For MUC, the items representing occupants have no node
attribute, whereas for MIX the items representing nodes naturally do
have a node attribute.

Section 4.2 (Items Nodes) also seems to imply that the node attribute
for Service Discovery is not meant as a filtering mechanism.

I am curious if just combining them would actually cause problems in
practice. Has this been tested?

-- 
ralphm


On 2018-09-25 22:32, Dave Cridland wrote:
> Ralph,
> 
> As I vaguely recall, the problem wasn't disco#info clashing between MUC 
> and MIX - as you say, those shouldn't clash.
> 
> The problem is disco#items, where MIX and MUC use disco#items to yield 
> entirely different information. MUC will respond with room occupants, 
> whereas MIX responds with channel nodes. It's the only clash between the 
> protocols.
> 
> Seems fair to have the channel nodes be children of an abstract mix 
> node. But this should only be needed for disco#items, not disco#info.
> 
> Dave.
> 
> On Thu, 20 Sep 2018 at 08:43, Ralph Meijer <ralphm at ik.nu 
> <mailto:ralphm at ik.nu>> wrote:
> 
>     Hi,
> 
>     Recently I have been looking at discovery of entities to determine what
>     kind of thing it is, knowing nothing more than its JID. The starting
>     point is a client that shows a list of entities, based on past
>     conversations (MAM), ordered by last interaction. Entities could be
>     regular user accounts, bots, group chat rooms, etc.
> 
>     The core idea behind XEP-0030 (Service Discovery) is that given a JID,
>     you can find out what kind of entity it is, by sending a Disco Info
>     request and getting one or more identities in return. Additional
>     information like supported features/protocols, and meta-data as Disco
>     Extension Data Forms (XEP-0128), can be included there, too.
> 
>     Reading XEP-0369, section 6.3, on discovering channel information, I
>     see
>     that it currently requires the node attribute to be set to 'mix'. From
>     what I understand this is to allow a particular JID to support both MUC
>     and MIX, and have a way to request the MIX specific information.
> 
>     The problem I have with this, is that it requires prior knowledge of a
>     certain JID (also) being a MIX channel. So you can't find out the
>     identity (the thing that's telling you what a JID is) without knowing
>     what the thing is. I do understand this works if you start out with
>     discovering the MIX service first, but I don't believe that should be
>     the only entry point.
> 
>     I don't see the need for explicitly asking for the MIX information
>     (only). XEP-0030 and XEP-0128 support returning multiple identities as
>     well as multiple extension forms. So a Disco Info result, without node,
>     could look like this:
> 
>     <iq from='coven at mix.shakespeare.example'
>           id='ik3vs715'
>           to='hag66 at shakespeare.example/UUID-c8y/1573'
>           type='result'>
>         <query xmlns='http://jabber.org/protocol/disco#info'>
>           <identity
>               category='conference'
>               name='A Dark Cave'
>               type='mix'/>
>           <identity
>               category='conference'
>               name='A Dark Cave'
>               type='text'/>
>           <feature var='urn:xmpp:mix:core:0'/>
>           <feature var='urn:xmpp:mam:2'/>
>           <feature var='http://jabber.org/protocol/muc'/
>     <http://jabber.org/protocol/muc%27/>>
>           <feature var='http://jabber.org/protocol/muc#stable_id'/
>     <http://jabber.org/protocol/muc#stable_id%27/>>
>           <feature var='muc_passwordprotected'/>
>           <feature var='muc_hidden'/>
>           <feature var='muc_temporary'/>
>           <feature var='muc_open'/>
>           <feature var='muc_unmoderated'/>
>           <feature var='muc_nonanonymous'/>
>           <x xmlns='jabber:x:data' type='result'>
>             <field var='FORM_TYPE' type='hidden'>
>               <value>urn:xmpp:mix:core:0</value>
>             </field>
>             <field var='Name'>
>               <value>Witches Coven</value>
>             </field>
>             <field var='Description'>
>               <value>A location not far from the blasted heath where
>                      the three witches meet</value>
>             </field>
>           </x>
>           <x xmlns='jabber:x:data' type='result'>
>             <field var='FORM_TYPE' type='hidden'>
>               <value>http://jabber.org/protocol/muc#roominfo</value>
>             </field>
>             <field var='muc#roominfo_description'
>                    label='Description'>
>               <value>The place for all good witches!</value>
>             </field>
>           </x>
>         </query>
>     </iq>
> 
>     Note that I included the channel info from section 6.5 here. I was
>     surprised to find we aren't using XEP-0128 disco extensions instead of
>     doing a pubsub items request here. I /do/ see the value for having the
>     pubsub node as way to get notifications on changes, so having both
>     would
>     be even better. If you have to do a Disco Info request anyway, it saves
>     one request.
> 
>     Finally, section 12, on Registrar Considerations, doesn't mention the
>     required registration [1] of the identity conference/mix. Unfortunately
>     one identity can have at most one extension form, so reusing
>     conference/text is probably not a good idea.
> 
>     [1] https://xmpp.org/registrar/disco-categories.html#conference
> 
>     -- 
>     ralphm
>     _______________________________________________
>     Standards mailing list
>     Info: https://mail.jabber.org/mailman/listinfo/standards
>     Unsubscribe: Standards-unsubscribe at xmpp.org
>     <mailto:Standards-unsubscribe at xmpp.org>
>     _______________________________________________
> 
> 
> 
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
> 



More information about the Standards mailing list