[Standards] UPDATED: XEP-0369 (Mediated Information eXchange (MIX))

Dave Cridland dave at cridland.net
Tue Aug 23 21:09:17 UTC 2016

On 23 Aug 2016 21:56, "Georg Lukas" <georg at op-co.de> wrote:
> Hi Steve,
> thanks for the clarifications. I'm still not quite sure about the
> implications of some of the things though, maybe you can clarify...
> * Steve Kille <steve.kille at isode.com> [2016-08-17 17:33]:
> > 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.
> I anticipate that day. We are only some decades away from it ;)
> > 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.
> I'd assume that this feature should be implemented by having the MUC
> reference the MIX domain, and not the other way around. That would allow
> interop between MIX and MUC users, as the MIX-capable clients can look
> up the MIX JID when invited to an "upgradable" MUC.
> It doesn't make much sense to implement a MUC reference on the MIX JID,
> because a MIX client will obviously use the MIX, and MUC clients won't
> be able to obtain the MUC reference from a MIX JID.

I think it's needed to allow a MIX client to communicate a MUC jid to
another client.

> This would boil down to people communicating the MUC JID and smart
> clients automatically upgrading to MIX, which has the same UX as #3
> below, with a higher technical complexity on the client side.

No, it means that the common currency, as it were, is the MUC jid, not the
MIX jid, and MUC becomes baked in for interop for decades.

> > 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.
> I think it makes sense to force servers that will support both MUC and
> MIX to implement #3 as the default interop mode, as it will immediately
> upgrade all MUCs on MIX-enabled servers to MUC+MIX, increasing the MIX
> propagation significantly.
> Also, I'm not convinced that it will be really challenging on the
> server-side, besides of the disco#list clash I outlined in my first
> email. Could you (or server implementors) please provide the reasons why
> this is going to be complicated?

I don't know.

It's not wholly clear to me, yet, that a MUC interface onto MIX is going to
be all that simple. I *am* certain that a MIX service needs to be written
afresh, at least for Openfire, and a MUC interface to it needs to be
written distinct from the existing MUC code.

> > Co-existence is important, but I think that the priority is to get MIX
> Indeed, but if we can provide seamless MUC+MIX interop at the cost of
> some small technical tweaks to MIX, we should at least discuss the
> trade-off and make a well-founded decision on this. So far I don't see
> how this interop prevents us from making MIX right.

This too. I'd be very interested to write down what MUC interactions are
needed, and how those map to MIX. Note that we probably don't need full MUC
semantics everywhere.

> > > 2. Use of client's bare JID
> > [Steve Kille]
> >
> > 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.
> I understand the design decision to make MIX membership a long-term
> thing bound to the user account.  However, by sending messages to the
> bare JID you are introducing technical interop problems with RFC6121
> message routing.
> The MIX XEP is currently not very clear in regard to this. If I am a
> member of the MIX and subscribed my account to both presence and
> messages, but haven't announced any presence, will the MIX service send
> messages to my bare JID? Will it send presence packets?
> If yes, and my clients are currently offline, messages will land in my
> account's MAM / offline storage, and presences will trigger error
> responses to the MIX. If a non-MIX client is/comes online, that client
> is going to receive (and fail to properly display) MIX messages sent to
> the bare JID.
> If no, a MIX-enabled client needs to send some kind of trigger
> (e.g. presence) to the MIX to start receiving MIX messages and
> presences, so we could as well direct these stanzas to the client's full
> JID.

We need PAM to be MIX-aware, basically.

> > Using the roster to hold MIX JIDs is elegant and has some significant
> Could you please outline the benefits as compared to e.g. bookmarks?
> This needs special handling in the client anyway (i.e. the client needs
> to remember / disco#info / caps-check) all roster JIDs anyway to see
> which are users and which are MIXes.

I'm not entirely sure it does. It'd be nice if it didn't.

> > 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.
> Except for MIX messages that are sent to the bare JID and inadvertently
> received by non-MIX clients. The only way to prevent this is by sending
> messages to the full JID of MIX clients, which have to announce their
> MIX-ability to the MIX.

Again, PAM needs to take care of this.

> > > 3. Message tracking
> > [Steve Kille]
> > I'd welcome a detailed proposal on how to address this
> There is XEP-0359 "Unique and Stable Stanza IDs" with 'client-id', which
> is probably the most progressed proposal for this idea. My only gripe
> with it is that it introduces another extension element with a namespace
> and an ID distinct from the initial packet ID, so it's adding some 50
> bytes to each message. But I think I'm optimizing the wrong thing
> here...

Because the client's full jid is mapped through, I'm not sure the same
problems apply here. But we need to ensure the use-cases are captured here.

> Georg
> --
> || http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
> || gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
> || Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y?   ||
> ++ IRCnet OFTC OPN ||_________________________________________________||
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160823/c75591c4/attachment.html>

More information about the Standards mailing list