[Standards] Dealing with the choice to have a different MIX roster format
steve.kille at isode.com
Thu Jun 15 12:20:50 UTC 2017
I've gone with your option #4, as this seems clean, does not add roundtrips and avoids other issues.
> -----Original Message-----
> From: Standards [mailto:standards-bounces at xmpp.org] On Behalf Of Jonas
> 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:
> > > 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
> > > 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
> > > 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,
More information about the Standards