[Standards] UPDATED: XEP-0369 (Mediated Information eXchange (MIX))
steve.kille at isode.com
Wed Aug 17 15:30:27 UTC 2016
Thanks for your comments. Let me go over these.
> -----Original Message-----
> From: Standards [mailto:standards-bounces at xmpp.org] On Behalf Of Georg Lukas
> Sent: 17 August 2016 12:06
> To: standards at xmpp.org
> Subject: Re: [Standards] UPDATED: XEP-0369 (Mediated Information eXchange (MIX))
> * XMPP Extensions Editor <editor at xmpp.org> [2016-08-16 12:33]:
> > Version 0.2 of XEP-0369 (Mediated Information eXchange (MIX)) has been released.
> Thanks to everybody involved! Let's get this one moving fast, now! :)
> I like the overall design, but I think some aspects of it can be improved.
> 1. Sharing a domain between MUC and MIX
> I think this is imperative for easy coexistence and upgradeability from the current MUC infrastructure to using MIX. We should
> explicitly support accessing the same chatroom via both protocols under the same
> JID: This will make the UX much smoother and spare us the pains and debugging problems of a hidden actual service JID that needs to
> be communicated between MUC-vs-MIX clients. I would even ask for allowing a user to use a MIX and a MUC client at the same time,
> sharing a nickname.
> From the protocol side, the only clash I can see is disco#items on a room JID, which returns the participant list for MUC, and the
> supported nodes for MIX. I'm not sure if there is an elegant way to discriminate these use cases with the query (Have a separate well-
> known query JID for MIX nodes? Add a custom element to the iq-get? Have some namespace for the query? Return both MUC
> participants and pubsub nodes?), but I would be ready to settle with a less elegant solution for the sake of better UX and interop.
MIX permits three modes with MUC:
1. No MUC. There is no requirement to support MUC. This may make sense for specialised implementations now, and more generally in the future.
2. MIX and MUC on separate domains. This can work well for many environments, particularly where a limited set of clients are used, and where clients have good support for MIX/MUC co-existence. A MIX domain may reference an associated MUC domain, which will help clients supporting this setup.
3. MIX and MUC on the same domain. This will be trickier server side, and I do not think it makes sense to force servers to implement this. You are right that this will improve migration and co-existence. So for some servers, this may well be the right way to go.
Co-existence is important, but I think that the priority is to get MIX right.
> 2. Use of client's bare JID
> Sending of presence and message packets to the user's bare JID is going to break things. First, message routing is server-defined, and
> will cause different behavior on different servers. Second, a client with a negative presence priority will not be able to receive data
> from MIX.
> Third, messages and presence stanzas will end up routed to clients that do not support MIX or do not know which channels the user
> is on, causing weird UX issues. Fourth, client authors will have to implement and enable carbons, and handle carbonated MIX
> messages like regular MIX messages (whereas carbonated private messages might have slightly different semantics). Fifth, these
> messages will end up in the user's offline storage, probably confusing a later resync.
> As not all clients are going to implement MIX overnight, the protocol should not force new types of messages onto legacy clients.
> Therefore I propose to make MIX participation more explicit:
> a) always use the client's full JID to send MIX related stanzas
> b) require a MIX capable client to explicitly send directed presence to all MIX rooms it is interested in (§5.1.6 is okay in this regard,
> though I'd like to see an explicit extension element akin to MUC-join; a dumb client could just put both MUC and MIX extensions into
> a presence packet and see what comes back ;-)).
> c) As a consequence, MIX JIDs should not be part of the user's roster. I don't particularly like the alternative (bookmarks), but it still
> sounds better to me than breaking legacy clients.
> d) As another consequence, the MIX service would send copies of a MIX message/presence to each client of each user, instead of only
> once per user. However, this will avoid the mess that RFC6120 message routing + Carbons is.
A key design decision of MIX was to separate Presence and Messages. Users can register presence for multiple clients or none at all. Another decision was to make membership long term, so that messages get sent irrespective of presence. A consequence of this is that messages HAVE to go to the bare JID.
Using the roster to hold MIX JIDs is elegant and has some significant benefit.
To use MIX, clients have to support MIX and the servers they use have to support MIX (e.g.., PAM - XEP-0376). So legacy clients are not going to see MIX stuff.
> 3. Message tracking
> Initially, MIX messages were going to be handled like pubsub events. The text in §5.1.11 still claims so (I suppose this is an overlooked
> remnant). Example 30 shows a regular message with a rewritten 'id'.
I will look at both of these points as editorial actions.
> I'm still strongly in favor of having a stable way for a client to identify a reflection of an outgoing message, as discussed in .
> If we use MAM, reflected messages should be identified by their MAM archive id, allowing for a later follow-up sync. However, client-
> originated messages are not identifiable with this approach, and it would be great to have the original packet ID reflected, or at least
> an additional element with the original packet ID, so that the client can mark the message as "delivered".
I'd welcome a detailed proposal on how to address this
> 4. Capability Reduction
> I'm not quite sure why MIX allows to register a service-wide nickname, but passwords and voice control got kicked. Personally, I would
> also kick the nickname registration feature: IMHO it doesn't make very much sense in a federated environment where most chat
> rooms are distributed over different service domains anyway, and where the real JID is the only reliable identifier anyway.
This does not add value for a "service provider" type solution. I note this type of registration is optional.
However, for an enterprise type solution, ensuring consistency of Nicks across channels may be highly desirable. I think that this is a useful feature for some types of deployment.
> While we are at it, I don't like the idea of proxy JIDs very much either, and I'd rather have gone with the MUC-light proposal of just
> using users' real JIDs everywhere. It would make the implementations much easier and less error-prone... And we are living in a post-
> privacy world anyway...
Real JIDs everywhere has been discussed. It will work well for some types of deployment. However it was clear from input to the discussion that hiding JIDs is important for some services and for some users. An example situation would be a channel with wide access, to prevent malicious JID harvesting. I believe that hiding real JIDs is important to include, although it adds an annoying level of complexity
Thanks for the comments
More information about the Standards