On Wed, 10 Oct 2018 at 09:28, Ralph Meijer <[email protected]> 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 <[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] > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
