On 23 Aug 2016, at 22:09, Dave Cridland <[email protected]> wrote: > > > On 23 Aug 2016 21:56, "Georg Lukas" <[email protected]> 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 <[email protected]> [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 _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
