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

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