[Standards] Dealing with the choice to have a different MIX roster format

Kevin Smith kevin.smith at isode.com
Wed Jun 14 07:33:58 UTC 2017

On 14 Jun 2017, at 08:24, Jonas Wielicki <jonas at wielicki.name> wrote:
> Replies to both Kevin and Steve inline.
> On Mittwoch, 14. Juni 2017 08:11:08 CEST Kevin Smith wrote:
>> On 14 Jun 2017, at 08:04, Steve Kille <steve.kille at isode.com> wrote:
> [snip]
>>> The underlying issue is that we decided to have a different roster format
>>> that marks MIX channels, and have the server behave differently.
>>> I think choices we have are
>>> 1.   Only return roster information one way.   Two choices:
>>>  a) Drop the extended information (seems a bad idea); or
>>>  b) Always send the extended information (might work or might give some
>>>  clients problems)> 
> I don’t think either of this is good. I’d prefer a separate IQ which returns 
> the list of joined channels then. Otherwise this would require to write down 
> somewhere that clients must disco#info roster entries to figure out their true 
> nature.

Which isn’t a bad thing, probably. We already have roster entities that aren’t users (components, at least).

>> This still doesn’t seem great to me, but is likely better than 2 or 3
> I’d like to hear about your arguments against 3 (or rather, what I meant when 
> I suggested it), given that this is how many other XEPs operate.

I’d read it as “Please modify the behaviour of this roster request”, which obviously makes more sense to be part of the roster request you’re sending. If it’s instead “Enable mix for this session”, it makes sense as an individual stanza. It’s icky when this can be expressed through caps immediately after the roster, but possibly not bad.


More information about the Standards mailing list