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

Kevin Smith kevin.smith at isode.com
Thu Aug 25 09:00:44 UTC 2016


On 23 Aug 2016, at 22:09, Dave Cridland <dave at cridland.net> wrote:
> 
> 
> 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.

Indeed. Although maybe two-way references make sense, so that a MIX client invited to a MUC can know to join the MIX instead.

> > 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.

Right. For MIX clients I think we want to be communicating about the MIX, and have the MUC interface cut out as much as possible.

> 
> > > 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.

I think this is likely true for M-Link as well, FWIW. There will be code re-use, but it won’t be a trivial interface on the existing abstractions.

> > > > 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.

I don’t think this point about presences causing errors is right.

> 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.

Yes.

> 
> > > Using the roster to hold MIX JIDs is elegant and has some significant benefit.
> >
> > 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.

Same.

> > > 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.

Yes. This hinges on the account having more ownership of things that are currently state held by each client.

/K


More information about the Standards mailing list