[Standards] MIX (XEP-0369) channel discovery

Dave Cridland dave at cridland.net
Wed Oct 10 14:35:04 UTC 2018


On Wed, 10 Oct 2018 at 09:28, Ralph Meijer <ralphm at ik.nu> wrote:

> 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".)
>
>
Yup. To every item. Maybe that's somewhere we could do some optimisation in
the protocol - although this is to deal with naive legacy clients so won't
help here.


> 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.
>
>
Yes, true.


> Section 4.2 (Items Nodes) also seems to imply that the node attribute
> for Service Discovery is not meant as a filtering mechanism.
>
>
Although we use it for precisely that in, for example, XEP-0050. I'm not
sure there's a real distinction here.

In general, I dislike "well-known nodes" because it means you can't
discover them, which feels rather against the point of XEP-0030.


> I am curious if just combining them would actually cause problems in
> practice. Has this been tested?
>
>
Nope. It just seemed like a pragmatic solution. It's not even clear to me
if any MUC clients actually use the disco#items at all. I know some *can*,
but I think only in generic "Service Discovery" UIs.

If MIX allows hundreds or thousands of participants in a channel, the MUC
disco interface is going to be pretty useless and/or deliberately
incomplete.


> --
> 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
> > _______________________________________________
> >
>
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20181010/51519756/attachment.html>


More information about the Standards mailing list