[Standards] XEP-0369 (MIX): Early stages of a clients connection

Steve Kille steve.kille at isode.com
Tue Jun 13 16:08:00 UTC 2017

Jonas, Georg, Dave,

I've just made changes for MIX 0.9.3,  in which I have attempted to address the three issues raised here.   The approaches are simple and have not added a lot of text.

I have also made two small protocol changes, in line with discussion on the list.

Thanks for the input, and in particular for Jonas writing it up.

The changes are available on Github:   

I have not pushed as a PR because of namespace numbering.      It seems likely that if a change is pushed every time we make a protocol tweak, there is going to be a serious problem of namespace number proliferation.

I think the options are:

1.  Keep changes on a working branch and defer pushing.    This gives less visibility of work in progress.

2.  Push and increment namespace.   Problem noted above.

3.  Push the PR and leave version number on mix:0.    I think this may be the pragmatic solution,  provided it does not cause a problem for those coding.

Let me know


> -----Original Message-----
> From: Standards [mailto:standards-bounces at xmpp.org] On Behalf Of Jonas
> Wielicki
> Sent: 18 May 2017 16:10
> To: standards at xmpp.org
> Subject: [Standards] XEP-0369 (MIX): Early stages of a clients connection
> Dear Steve and others,
> In the xsf@ MUC, we were discussion the interaction of MIX and roster, and
> the question what happens with roster versioning and MIX entries came up.
> The key scenario which is unclear is the following: Assuming a server and
> client both support and use roster versioning, what happens when the client
> gains MIX capability in an update? The client connects to the server and posts
> its roster version X to the server. How does the server reply? Of course, the
> server can "overlay" the addition of MIX (from the point of view of the
> client) ontop of the changes accumulated since version X.
> I think this should at least be discussed in the MIX XEP.
> A somewhat related point brought up by Dave was *how* does the server
> find out whether a client supports MIX when asked for the roster? The
> theory was that the server would know, because of XEP-0115 Entity
> Capabilities or similar mechanisms. However, at the point the roster is
> requested, the client may easily not have sent presence yet.
> So the server might need to make a disco#info request while letting the
> client wait for the roster response. An extra round-trip, which is not even
> obvious to the client.
> Steve and others on the list, opinions?
> kind regards,
> Jonas
> P.S.: It also seems underspecified in the MIX XEP whether a client needs to
> send available presence to receive MIX messages and whether a client which
> sent available presence, but with negative priority, receives MIX messages.
> But I think Steve already took note of that in the xsf@ MUC. Only including it
> here for completeness.
> P.P.S.: None of these issues were found by me (the first was found by
> Georg, the second and third by Dave); I am just re-laying those to the list
> since we don’t have logs currently and I think those are worth discussing.

More information about the Standards mailing list