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

Jonas Wielicki jonas at wielicki.name
Wed Jun 14 07:24:56 UTC 2017


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20170614/2ddc2a71/attachment.sig>


More information about the Standards mailing list