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

Steve Kille steve.kille at isode.com
Thu Jun 15 12:20:50 UTC 2017


Jonas,

I've gone with your option #4, as this seems clean, does not add roundtrips and avoids other issues.   

Change in:
   https://github.com/stevekille/xeps/commit/da21b293484855e9ab2b58f11a749eab37dc66f9



Steve


> -----Original Message-----
> From: Standards [mailto:standards-bounces at xmpp.org] On Behalf Of Jonas
> Wielicki
> Sent: 14 June 2017 08:25
> To: XMPP Standards
> Subject: Re: [Standards] Dealing with the choice to have a different MIX
> roster format
> 
> 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.
> 
> 
> > > 2.   Have the server work out client capability.     If the server does
> > > not know when it gets a roster request, it has to ask the client before
> > > responding to the request.   This is what the spec currently says.
> > > Some clients might not work with this (if they block on the roster
> > > request), which could be a problem we want to avoid.   We can fix for
> > > newer clients by having a mechanism for clients to share MIX
> > > capability early, but this may not help legacy clients.
> 
> I had not thought about clients possibly blocking on the roster reply. That
> makes the situation worse, indeed.
> 
> 
> > > 3.  Have a new MIX operation to be used before any roster request,
> > > declaring the desire for extended roster information (you suggestion).
> > > I can see much sense in this approach.
> 
> I’d go farther than that. I’d suggest a mix-enable IQ without which MIX is
> essentially disabled for the session. The session would behave as if the
> currently-specified protocol did not find a MIX feature in the clients
> disco#info: no messages, no roster entries, plus a <not-acceptable/> (from
> reading RFC 6120, this might be appropriate in that situation) or something
> like that when attempting to join a MIX (to avoid inconsistencies).
> 
> 
> > 4. Flag on the roster request that you’re mix?
> 
> I feel that this would require the client to know that the server supports MIX
> -- generally not a problem, since the client needs to know server features for
> many modern things in any case.
> 
> 
> > 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’m concerned (without evidence) that the extra roundtrip might be more
> > harmful than just a roundtrip, but might actually break clients if they
> > consider roster requests to be
> > pre-ready-to-start-handling-arbitrary-requests.
> 
> I agree that this may be a problem.
> 
> 
> kind regards & thanks,
> Jonas



More information about the Standards mailing list