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@mix.shakespeare.example'
id='ik3vs715'
to='hag66@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'/>
<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>
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-unsubscr...@xmpp.org
_______________________________________________
