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

Georg Lukas georg at op-co.de
Tue Aug 23 20:55:40 UTC 2016


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.

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.

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

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

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

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

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

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


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 ||_________________________________________________||
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: Digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160823/70837ae4/attachment.sig>


More information about the Standards mailing list