[Standards] Dealing with the choice to have a different MIX roster format
steve.kille at isode.com
Wed Jun 14 07:04:53 UTC 2017
Thanks for the clarification here.
> -----Original Message-----
> From: Standards [mailto:standards-bounces at xmpp.org] On Behalf Of Jonas
> Sent: 14 June 2017 07:23
> To: XMPP Standards
> Subject: Re: [Standards] XEP-0369 (MIX): Early stages of a clients connection
> On Mittwoch, 14. Juni 2017 08:17:22 CEST Jonas Wielicki wrote:
> > I‘m still not happy with the extra round-trip required by the server
> > for discovering the feature before responding with the roster, but
> > from discussion in xsf@ (if I recall correctly, mainly with Dave),
> > this may be a general problem we’d like to solve in a different
> > protocol (like gratuitous entity capabilities sent by clients to the
> > server before presence or something similar).
> To clarify, the extra round-trip I’m talking about stems from:
> From <https://github.com/xsf/xeps/compare/
> > A server following the MIX specification MUST determine whether or not a
> > client supports MIX. If the server does not have this information it
> > MUST use service discovery to determine it before providing roster
> > information.
> The other solution for that would be what other protocols which modify
> server behaviour such as Message Carbons do: Have the client explicitly
> enable it.
> kind regards,
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)
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.
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.
What do others think?
More information about the Standards