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. > 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: [email protected] > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
