[Standards] XEP-0369 (MIX) and sorting out co-existence of MUC and MIX on a single domain

Piotr Nosek piotr.nosek at erlang-solutions.com
Wed Jan 11 08:01:05 UTC 2017


On Tue, Jan 10, 2017 at 3:43 PM, Dave Cridland <dave at cridland.net> wrote:

> On 10 January 2017 at 14:37, Kevin Smith <kevin.smith at isode.com> wrote:
> >
> >
> > On 10/01/2017 14:27, Dave Cridland wrote:
> >>
> >> On 10 January 2017 at 13:30, Kevin Smith <kevin.smith at isode.com> wrote:
> >>>
> >>> On 10/01/2017 12:05, Steve Kille wrote:
> >>>>
> >>>> I have just issued a PR for MIX version 0.6.4.
> >>>>
> >>>> There is clear desire to have the option for  MUC and MIX to use the
> >>>> same
> >>>> domain.    The difficulty in achieving this was incompatible disco
> >>>> results.
> >>>> This version has made a change to
> >>>>     add node='mix' to channel disco that will enable the queries to be
> >>>> disambiguated.
> >>>
> >>> I haven't been able to think of a case other than disco#items on the
> room
> >>> JID where MUC and MIX are likely to collide. This change doesn't make
> it
> >>> *easy* to implement both on the same domain, but I think it makes it
> >>> viable
> >>> - please shout if anyone can think of other cases.
> >>>
> >> I agree. Further, I only know of a single client that would ever hit
> >> disco#items on a room, and that's Psi in its generic disco "browser".
> >>
> > Are you suggesting that this approach isn't necessary, and it'd be
> > sufficient to 'break' disco#items handling for MUC-only clients?
> >
>
> I'd not thought of this approach, but I was considering advocating
> "just break". I think this means we don't have to.


What about using Entity Capabilities to establish whether the client should
receive MIX or MUC stanzas and syntax? I know that it's mandatory for every
client to announce its caps but in such case the server could failover to
default mode. I don't know unfortunately if all major clients include their
version in initial presence...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20170111/079591c5/attachment.html>


More information about the Standards mailing list