Re: [Standards] MIX (XEP-0369) channel discovery

[Steve Kille]

I will make time to do a MIX spec edit next week

Steve

> -Original Message-
> From: Standards  On Behalf Of Daniel Gultsch
> Sent: 06 December 2018 16:00
> To: XMPP Standards 
> Subject: Re: [Standards] MIX (XEP-0369) channel discovery
> 
> Hi,
> 
> I ran into the same problem today and I support removing node=mix from the
> disco#info.
> 
> Maybe with the filter aspect that Florian suggested. But querying a JID
should
> reveal whether or not that JID is a mix channel without having to make two
IQs.
> 
> As for disco#items that could potentially still have the node attribute.
If you
> make that request you probably know what kind of service you are talking
to.
> 
> cheers
> Daniel
> Am Do., 20. Sept. 2018 um 09:45 Uhr schrieb Ralph Meijer :
> >
> > 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:
> >
> >  >  id='ik3vs715'
> >  to='hag66@shakespeare.example/UUID-c8y/1573'
> >  type='result'>
> >
> >   >  category='conference'
> >  name='A Dark Cave'
> >  type='mix'/>
> >   >  category='conference'
> >  name='A Dark Cave'
> >  type='text'/>
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >  
> >
> >  urn:xmpp:mix:core:0
> >
> >
> >  Witches Coven
> >
> >
> >  A location not far from the blasted heath where
> > the three witches meet
> >
> >  
> >  
> >
> >  http://jabber.org/protocol/muc#roominfo
> >
> > >   label='Description'>
> >  The place for all good witches!
> >
> >  
> >
> > 
> >
> > 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
> > ___
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MIX (XEP-0369) channel discovery

[Daniel Gultsch]

Hi,

I ran into the same problem today and I support removing node=mix from
the disco#info.

Maybe with the filter aspect that Florian suggested. But querying a
JID should reveal whether or not that JID is a mix channel without
having to make two IQs.

As for disco#items that could potentially still have the node
attribute. If you make that request you probably know what kind of
service you are talking to.

cheers
Daniel
Am Do., 20. Sept. 2018 um 09:45 Uhr schrieb Ralph Meijer :
>
> 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:
>
>   id='ik3vs715'
>  to='hag66@shakespeare.example/UUID-c8y/1573'
>  type='result'>
>
>category='conference'
>  name='A Dark Cave'
>  type='mix'/>
>category='conference'
>  name='A Dark Cave'
>  type='text'/>
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>
>  urn:xmpp:mix:core:0
>
>
>  Witches Coven
>
>
>  A location not far from the blasted heath where
> the three witches meet
>
>  
>  
>
>  http://jabber.org/protocol/muc#roominfo
>
>   label='Description'>
>  The place for all good witches!
>
>  
>
> 
>
> 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
> ___
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MIX (XEP-0369) channel discovery

[Dave Cridland]

On Wed, 10 Oct 2018 at 09:28, Ralph Meijer  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  > > 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:
> >
> >  >   id='ik3vs715'
> >   to='hag66@shakespeare.example/UUID-c8y/1573'
> >   type='result'>
> > 
> >>   category='conference'
> >   name='A Dark Cave'
> >   type='mix'/>
> >>   category='conference'
> >   name='A Dark Cave'
> >   type='text'/>
> >   
> >   
> >> >
> >> 

Re: [Standards] MIX (XEP-0369) channel discovery

[Ralph Meijer]

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 > 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:



  
  
  
  
  http://jabber.org/protocol/muc%27/>>
  http://jabber.org/protocol/muc#stable_id%27/>>
  
  
  
  
  
  
  

  urn:xmpp:mix:core:0


  Witches Coven


  A location not far from the blasted heath where
 the three witches meet

  
  

  http://jabber.org/protocol/muc#roominfo


  The place for all good witches!

  



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
Unsubscrib

Re: [Standards] MIX (XEP-0369) channel discovery

[Steve Kille]

Dave,

 

From: Standards  On Behalf Of Dave Cridland
Sent: 25 September 2018 21:32
To: XMPP Standards 
Subject: Re: [Standards] MIX (XEP-0369) channel discovery

 

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.

[Steve Kille]

Thanks for this clarification.

 

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.

[Steve Kille]

I wonder:

1.  Is it going to confuse a MUC client if it gets both?
2.  Is there value to any entity in returning both?
3.  If feels a bit ugly to have different behaviour for disco#items and 
disco#info

 

I propose to make the change for disco#info, as Ralph’s argument is clear

 

I propose to not make any change to disco#items, and add clarifying text as to 
why this uses node=’mix’

 

I can also see a case to remove for both.Anyone care to argue the case?

 

 

Steve

 

___

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MIX (XEP-0369) channel discovery

[Dave Cridland]

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  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:
>
>   id='ik3vs715'
>  to='hag66@shakespeare.example/UUID-c8y/1573'
>  type='result'>
>
>category='conference'
>  name='A Dark Cave'
>  type='mix'/>
>category='conference'
>  name='A Dark Cave'
>  type='text'/>
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>
>  urn:xmpp:mix:core:0
>
>
>  Witches Coven
>
>
>  A location not far from the blasted heath where
> the three witches meet
>
>  
>  
>
>  http://jabber.org/protocol/muc#roominfo
>
>   label='Description'>
>  The place for all good witches!
>
>  
>
> 
>
> 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
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MIX (XEP-0369) channel discovery

[Peter Saint-Andre]

On 9/25/18 10:58 AM, Steve Kille wrote:
> Ralph,
> 
> 
>> -Original Message-
>> From: Standards  On Behalf Of Ralph Meijer
>> Sent: 20 September 2018 08:43
>> To: XMPP Standards 
>> 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:
>>
>> >  id='ik3vs715'
>>  to='hag66@shakespeare.example/UUID-c8y/1573'
>>  type='result'>
>>
>>  >  category='conference'
>>  name='A Dark Cave'
>>  type='mix'/>
>>  >  category='conference'
>>  name='A Dark Cave'
>>  type='text'/>
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>
>>  urn:xmpp:mix:core:0
>>
>>
>>  Witches Coven
>>
>>
>>  A location not far from the blasted heath where
>> the three witches meet
>>
>>  
>>  
>>
>>  http://jabber.org/protocol/muc#roominfo
>>
>>>   label='Description'>
>>  The place for all good witches!
>>
>>  
>>
>> 
>>
>> Note that I included the channel info from section 6.5 here. I was
> surprised to
>> find we aren't using XEP-0

Re: [Standards] MIX (XEP-0369) channel discovery

[Steve Kille]

Ralph,


> -Original Message-
> From: Standards  On Behalf Of Ralph Meijer
> Sent: 20 September 2018 08:43
> To: XMPP Standards 
> 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?

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.


> 
> 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:
> 
>   id='ik3vs715'
>  to='hag66@shakespeare.example/UUID-c8y/1573'
>  type='result'>
>
>category='conference'
>  name='A Dark Cave'
>  type='mix'/>
>category='conference'
>  name='A Dark Cave'
>  type='text'/>
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>
>  urn:xmpp:mix:core:0
>
>
>  Witches Coven
>
>
>  A location not far from the blasted heath where
> the three witches meet
>
>  
>  
>
>  http://jabber.org/protocol/muc#roominfo
>
>   label='Description'>
>  The place for all good witches!
>
>  
>
> 
> 
> 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  ?  

I will edit to reflect this, unless anyone suggests a preferable approach


> 
> --
> ralphm

[Steve Kille] 

Steve


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MIX (XEP-0369) channel discovery

[Florian Schmaus]

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:
> 
>      id='ik3vs715'
>     to='hag66@shakespeare.example/UUID-c8y/1573'
>     type='result'>
>   
>          category='conference'
>     name='A Dark Cave'
>     type='mix'/>
>          category='conference'
>     name='A Dark Cave'
>     type='text'/>
>     
>     
>     
>     
>     
>     
>     
>     
>     
>     
>     
>   
>     urn:xmpp:mix:core:0
>   
>   
>     Witches Coven
>   
>   
>     A location not far from the blasted heath where
>    the three witches meet
>   
>     
>     
>   
>     http://jabber.org/protocol/muc#roominfo
>   
>     label='Description'>
>     The place for all good witches!
>   
>     
>   
> 

+1

- Florian



signature.asc
Description: OpenPGP digital signature
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MIX (XEP-0369) channel discovery

[Manuel Rubio]

Hi,

even it's a bit more complicated in the context of MAM and MIX because 
you are storing conversations which could belongs to users who are not 
in the system anymore. I mean, if you created a bot, for example, that's 
an account with specific features, and it's registered to a MIX channel 
and sent to you some messages (directly and via that channel), if the 
bot removes its account, you can retrieve the conversations but when you 
try to obtain information about what was that exactly, you only can 
figure out that was an user (account) and that's all.


Maybe something like a general record for JIDs, only to store 
information like features and kind of account (identities) could be a 
good idea in this case to keep the information about what is/was that 
JID.


Kind regards.
Manuel Rubio.

El 2018-09-20 09:43, Ralph Meijer escribió:

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:


  













  
urn:xmpp:mix:core:0
  
  
Witches Coven
  
  
A location not far from the blasted heath where
   the three witches meet
  


  
http://jabber.org/protocol/muc#roominfo
  
  
The place for all good witches!
  

  


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
___

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] MIX (XEP-0369) channel discovery

[Ralph Meijer]

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:



  













  
urn:xmpp:mix:core:0
  
  
Witches Coven
  
  
A location not far from the blasted heath where
   the three witches meet
  


  
http://jabber.org/protocol/muc#roominfo
  
  
The place for all good witches!
  

  


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
___