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 <[email protected]
<mailto:[email protected]>> 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='[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'/
<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: [email protected]
<mailto:[email protected]>
_______________________________________________
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
