On 20.09.2018 09:43, Ralph Meijer 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.
While I could see to exclusively ask for MIX information, I too fail to understand why it is required to disco#info against a special node attribute in order to support MUC/MIX under the same JID. I could imagine an approach where a disco#info without 'node' attribute would return all services provided under this particular JID, and where a disco#info with a 'node' attribute would limit the disco#info results essentially based on the node's name. > So a Disco Info result, without node, > could look like this: > > <iq from='[email protected]' > id='ik3vs715' > to='[email protected]/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'/> > <feature var='http://jabber.org/protocol/muc#stable_id'/> > <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> +1 - Florian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
