On 9/25/18 10:58 AM, Steve Kille wrote: > Ralph, > > >> -----Original Message----- >> From: Standards <[email protected]> On Behalf Of Ralph Meijer >> Sent: 20 September 2018 08:43 >> To: XMPP Standards <[email protected]> >> Subject: [Standards] MIX (XEP-0369) channel discovery >> >> 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. > [Steve Kille] > > Yes, this was the rationale (set out in 6.3). > >> >> 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. > [Steve Kille] > > Your logic for this extra entry point is spot on. I propose to remove > the specification of node=mix, as you suggest. > > I have checked over, and agree with you that there is no conflicting > information. > > > The consequence of this is that: > 1. A MIX client may see MUC information. This should not be an issue > 2. A MUC client will see new MIX information. Is this going to cause any > significant breakage?
It shouldn't cause breakage. > I was specifically asked to make this node=mix change (I cannot remember by > whom, but it was not something that I designed). I could not find any > notes or emails. I'd like confirmation from my co-author before making > this change. > > Can anyone else involved in early MIX discussions think back? This was > put in for a reason, and I'd prefer not to break something by making this > change. The idea behind the 'node' attribute for an information request is to "filter" on desired information for a particular feature supported by the entity; the best example I know of is ad-hoc commands (XEP-0050), where you might want to find more detailed information about a specific command. Such a scenario does not apply in the case of MIX, as far as I can see. >> 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'/> >> <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 > [Steve Kille] > > Good catch. Need to put something in registrations section. I agree > that conference/text is a bad idea. > > Does anyone see any issues with conference/mix ? That feels like the right category/type to me. Peter
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
