[Standards] MIX Status (0.6.1), review, and Brussels Summit
steve.kille at isode.com
Wed Dec 21 10:48:59 UTC 2016
Thanks for this careful review. I really appreciate it, and I think that this can be helpful to facilitate discussion before the summit.
Let me go over your points.
> -----Original Message-----
> From: Standards [mailto:standards-bounces at xmpp.org] On Behalf Of Georg
> Sent: 19 December 2016 23:42
> To: standards at xmpp.org
> Subject: Re: [Standards] MIX Status (0.6.1), review, and Brussels Summit
> * Steve Kille <steve.kille at isode.com> [2016-12-05 16:25]:
> > Careful expert review and work on initial implementations is going to
> > raise issues that will lead to updates.
> Thanks very much for your work so far. I've finally worked through the XEP
> and will try to organize my points a bit.
> # General issues
> ## Required Software Support
> Generally, we are putting up a very very high bar by requiring support from
> all of the user's clients, their server and from the MIX service.
> Let's hope adoption is faster than with other XMPP sub-protocols.
> §3 item 13: "[...] where a user chooses to use MIX, all of the users clients
> need to support MIX."
> §3.3 item 1: "[...] MIX messages will only be sent to clients that support MIX."
You are right that a high bar has been set. I think that this is a consequence of the MIX objectives. I strongly believe that now is the time for a bold leap forwards. XMPP is losing out to proprietary services and we need to bring the protocols forward so that modern services can be achieved with open standards.
Operationally, I believe that this will be mitigated by server implementations that support both MIX and MUC, and following the procedures of section 7. This will enable transitional operation.
> I think §3 item 13 needs to be updated and it also needs to mention that the
> user's _server_ must support the MIX proxy functionality.
Agreed that MIX Proxy needs noting here. I've added item 14.
> We might need to codify how a MIX-enabled client connected to a non-MIX
> server should behave (MUC fallback?).
I don't think this is needed. A client can implement both MIX and MUC. The standards do not need to proscribe how this interacts in user experience.
> ## Race Condition During Sync
> With the introduction of MAM, we have created a very interesting protocol
> combination (carbons, offline messages, MAM synchronization) which is
> almost impossible to do right. Depending on the order in which a client
> executes the queries, there will either be a moment for which it will not
> receive any messages, or for which it will receive duplicates.
> §3.3 item 5 introduces the same race condition with "The MIX Proxy will only
> send messages to online clients and will discard messages if no clients are
> online. This means that a MIX client needs to resynchronize with the MIX
> service when it comes online. This synchronization will happen directly
> between the MIX client and MIX channel."
> With MUC, at least we had a cleaner synchronization protocol where the
> client could identify the last received message and request anything after
> that (though using the timestamp for this sync surely isn't appropriate any
> I have no idea how to elegantly solve this problem for messages. For
> presence, it seems to be solved in §5.1.8 by using a client's outgoing
> presence as the synchronization point.
There is an issue here. Kevin Smith and Matthew Wild are discussing an approach to modify client bind in order to address this.
I do not think there is any specific MIX issue, although I believe that MIX will be dependent on this new specification.
> ## Subscription and Presence Management
> I'm still not convinced it is a good idea to add MIXes to the roster.
I strongly view that having MIX channels in the roster is a good thing. It allows presence to work for MIX using standard XMPP mechanisms.
> In theory this gives automatic forwarding of presence to the MIX. In practice,
> a client needs to send a MIX activation (§6.1) anyway.
MIX activation is primarily about control of which clients MIX messages get sent to, not about communication to the MIX.
Section 6.4 recommends (SHOULD), but does not require, that only presence from active MIX clients is sent to the channel. This will lead to "right behaviour", but may be tricky for servers to implement as it leads to MIX specific behaviour at a fairly low level. In most situations, I'd guess that the simple approach will often do the right thing (in scenarios where all clients support MIX and activate for all channels, which I guess will be the most common).
> Furthermore, the roster does not provide a way to distinguish MIXes from
> regular contacts, unless the roster format is also extended.
I think that for most clients/users this will not matter. It will be easy for me to distinguish MIX channels, and I would likely group in the roster. The client can easily work out if a roster member is a MIX channel and can "do clever things" if it wishes. I suggest we get some implementation experience; it could be that a roster format change would help client implementers.
> A client needs a way to obtain the list of all joined MIXes (e.g. from the MIX
> proxy), so it can decide which MIXes to activate.
I had pictured that many clients will take a simple approach of just activating all MIX channels. This fits a lot of use cases and is easy. Another approach would be to tie to bookmarks, so that essentially you activate a MIX channel on startup if bookmarked.
A client can find a list of MIX channels in which the user is participating from the roster. A MIX proxy command to list channels might be helpful in the future. Let's review after client implementation experience.
> Once the client sends
> activation, the MIX proxy could forward the client's presence to the MIXes,
> so we don't need to put them onto the roster for this either.
This is a possible alternate approach. It puts some quite low level requirements onto the MIX Proxy and it feels to me preferable to use the roster and RFC 6121.
I'm happy to put this onto the agenda for Brussels.
> §5.1.8 "When the full JID of a client is added to the MIX channel presence
> node and that full JID is not in the presence list, the MIX channel will send to
> the client presence for all of the items in the presence node using standard
> presence stanzas." -- this approach has a significant drawback we already
> have in some MUC implementations. If the MIX thinks that the client is still
> "joined" (i.e. presence from this client is in the MIX presence table), it will
> not provide a full presence list to the client. However, a c2s disconnect or an
> s2s disconnect can lead to the client becoming desynchronized, requiring a
> full presence list.
> My current approach to the full-resync in MUCs is to send a <presence-
> unavailable/><presence-join> to the MUC, which is a horrible hack. We
> should provide something better for MIX.
It is important to understand that (unlike MUC), a MIX channel does not have a model of client status. It simply has a set of presence information (which clients update using standard presence mechanism) and this information is distributed (using standard presence protocol) to any participants subscribed to the presence node. A flow of presence updates gets sent to the full JID of the client (MIX Proxy).
For a new channel participant, presence status is shared as described in second para 5.1.8 that you quote here. This only happens when the user joins the channel, not online/offline.
The core mechanism for coming online and updating presence is described in the first para of 5.1.8. The client sends directed presence to the channel and the MIX channel sends presence information.
I realised on review that the role of MIX proxy has not been written up. In most cases the MIX Proxy will hold current presence information and so when a client comes online, it can get this information from the MIX Proxy. I have added text to cover this.
I think we have a good clean mechanism here, and there is no need for "horrible hacks".
> ## Message Routing
> As soon as a user joins a MIX, their MIX proxy will receive copies of all MIX
> messages. If the user becomes frustrated with XMPP, disconnects and
> uninstalls their client, the XMPP server is doomed to receive and drop MIX
> messages from all joined MIXes forever. This might cause significant traffic
> and processing overhead to public XMPP servers once MIX lifts off.
This is a scenario to consider, but I think this is primarily an account management issue for the server where the user registered and vanished, not a MIX issue.
> It would be good to have a better solution to this problem, e.g. by having the
> MIX proxy forward activation+presence to the MIX channel, and a MIX
> channel to only send messages to activated proxies.
I think this is not a sensible approach.
> Maybe it is possible to solve this together with the MAM race condition in an
> elegant way that I don't see.
I think that this problem is solved by account management and that a solution is planned for MAM race condtion.
> ## Internal Consistency
> The standard nodes in §3.7 have very different usage semantics. Some are
> accessible via PubSub, some forbid PubSub. Others can be accessed directly
> via presences, other via messages, others via MAM. It would be great to
> have more consistency in the spec.
This inconsistency has arisen for a number of good reasons, or more accurately because of the consequences and interaction of the good reasons.
1. The desire to model everything with PubSub.
2. The desire to only have one way to perform an action. This makes things easier for implementers, gives flexibility in choice of implementation, and reduces risk of inconsistency.
3. Use of standard XMPP groupchat and presence protocol to maximize compatibility with XEP-0045
This means that core things like message distribution are very MUC-like, and newer capabilities use PubSub.
> Second to that, it would be nice to have
> the possible access mechanisms explicitly stated in the individual sections,
> also saying which parties (client / MIX proxy / MIX
> service) interact with each other.
I have tried to be clear. Detailed suggestions on sections to clarify are welcome.
> ## MUC Interop
> The XEP is stating that a MIX service may implement a subset of the MUC
> protocol on the same domain.
> However, a MUC channel and a MIX channel react differently to disco#info
> and disco#items. While the disco#info response could include both the MIX
> and the MUC data, MUC disco#items is specified to return a list of
> participants, whereas MIX disco#items returns the list of nodes.
> To allow interop, it would be great to use a different xmlns for the list of MIX
> nodes, e.g. "urn:xmpp:mix:0#get-nodes". maybe it would even be sensible
> to merge the nodes list with channel-info, so that a client can obtain both
> with a single query.
I am not convinced that implementing MUC and MIX on the same domain is viable. It is certainly not going to be easy. Your note points out an issue.
My recommendation would be to not allow this and to require MIX and MUC domains to be distinct. I suggest that we discuss in Brussels.
> ## Joining a MIX
> The current join protocol has two drawbacks:
> 1. there is no way for a client/proxy to obtain their proxy JID. The join
> response (example 24) has a 'jid' element which could be used to return the
> proxy JID.
I think that in 24, it is desirable to use a JID that matches the real jid, as part of the client confirmation.
In practice, there is little reason for a client to need to know their own proxy JID. So I don't see a need to extend the protocol. A client can easily find proxy JID by matching their own NICK in the participants list.
> 2. there is no way to specify the nickname while joining. Another roundtrip is
> needed for that (§5.1.5), and the MIX service can not publish the nickname in
> the first participants node update (ex. 26).
Errors for Nicks and Joining are quite distinct, and I think it is cleaner to do this in two stages. There is no need for a Nick on joining. I have fixed example 26 to address the problem you have flagged.
> ## Converting a 1:1 Chat
> §5.5.4 "It may also be useful to share some or all of the messages from the
> 1:1 discussion into the new channel. This is done by sending these messages
> to the channel." -- it is not clear which client is responsible for sending these
> messages, and how author attribution is to be preserved.
Ah yes, there are some issues here. I have updated. Let me know what you think of the new text.
> # Wording
> The XEP is hard to understand because it is not using a consistent wording. It
> would be great to have another editorial run and to use consistent terms
> everywhere ('user' and 'server' are ambiguous; it is not always clear which
> tasks are performed by the client and which by the proxy, and if the user's
> server or the MIX server is meant). I would suggest to write 'MIX service'
> instead of 'MIX server' and to only use 'server' for the user's XMPP server (or
> even better 'MIX proxy').
This sort of generic comment is very hard to address. It is more useful to point out specific problem paragraphs, as you have done below.
I agree on MIX server, and have replaced references with MIX service.
> §3.3 item 2 "MIX client sends these MIX management queries to the MIX
> Proxy using the clients full JID" - is this describing the 'from' or the 'to' JID?
> 'from' is always the full JID anyway, and for 'to' this doesn't make much
I've clarified as from. This is required, but I think important to set out because of the next sentence.
> §3.6 the paragraph after table 2 ends with "the mapping between real JID
> and proxy JID MUST NOT be changed," - there should be some more text?
I think sentence was complete, but comma needed replacing with a full stop.
> §3.7.10 are the "bare JIDs" mentioned there proxy or real JIDs?
Real - added a note to clarify
> Table 8: The default value for 'JID Visibility' should be 'Default'
Ta - fixed
> §5.1.7 "Presence updates are sent out to subscribing using standard
> XEP-0045 compatible presence stanzas." -- what are XEP-0045 compatible
> presence stanzas? Presence like in RFC6121? Presence with a MUC element
> (<x xmlns='http://jabber.org/protocol/muc'/>)?
I've deleted the "45 compatible" as this is just confusing!
> Thanks & kind regards,
Thanks for all of the input.
I have incorporated changes and issues a PR for 0.6.2, so you will be able to review the changes soon
More information about the Standards