On 4 January 2017 at 16:02, Steve Kille <[email protected]> wrote: > Dave, > > > > Making the details of sharing a domain work will be hard. > > > > A key point is that MIX defines a way for MUC and MIX domains to cross > reference each other. This means that a MIX capable client will move > transparently from a MUC room to the equivalent MIX channel. This is > all going to be very neat and transparent, and does not need the domain to > be shared. >
OK - my concern (and I think Georg's concern too) is that a MIX client can locate the MIX channel from the MUC interface, but a non-MIX client cannot locate the MUC from the MIX interface, since it will never understand that - meaning that the "address of record" for the chatroom will be that of the MUC service, and not the MIX. That means that retiring the MUC service is going to be very hard, if not impossible. This seems highly undesirable. I have no interest whatsoever in having a *full* MUC service operational on the same domain as the MIX service. But I would like to explore a legacy MUC-compatibility service so we can avoid having whole legacy domains hanging around forever. This is, as you say, something we can discuss further in Brussels - I just don't want it to be considered a lost cause from the outset. > > > We can discuss further in Brussels > > > > > > Steve > > > > > > > > From: Standards [mailto:[email protected]] On Behalf Of Dave > Cridland > Sent: 04 January 2017 15:43 > To: XMPP Standards > Subject: Re: [Standards] MIX Discussion topics for the Summit > > > > > > > Q1. Should MIX Channels and MUC Rooms be allowed to share a domain? > > SEK: The spec currently allows this, and some issues around this have been > identified (by Georg Lukas). I think that trying to make this work will > cause much pain and so we should explicitly require the MUC and MIX do not > share domains. > > > > I think we should try to do this. If we do not, then (for example) > [email protected] will end up being MUC-only, and we'll have to have a new > address for the MIX equivalent. Worse, this will more or less always be the > case until MUC disappears entirely, which will take years. > > > > It feels fundamentally counter to any attempts to build a reasonable > end-user UX to have addressing split on protocol rather than function. > > > > An option to resolve this is to spent some time at the Summit (or before) on > defining a known-safe subset of MUC which is known to (or at least thought > strongly to) be supported by existing clients in normal operation, and > suggest that MIX services implement that. This might, for example, provide > only very limited information, no disco, and so on - but would give a > degraded, but functional, interface for legacy clients (ie, every client > currently in existence). > > > > > > > _______________________________________________ > 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] _______________________________________________
