[Standards] MIX Discussion topics for the Summit

Dave Cridland dave at cridland.net
Wed Jan 4 15:43:01 UTC 2017

On 4 Jan 2017 09:34, "Steve Kille" <steve.kille at isode.com> wrote:

I thought it would   be helpful to set out a list of topics for
discussion/review at the Summit at the end of this month.   I will update
this message if more topics are suggested or otherwise come to light before
the meeting.

I would encourage review looking to identify further topics for discussion.

Discussion of topics before the meeting is fine, but key focus should be to
build the list, not resolve items on the list.

This is based on 0.6.3 of MIX.    I may well make further MIX edits before
the summit, particularly if straightforward or editorial points arise.

I am choosing to include my views on the answers (marked SEK).     I hope
that this is seen as helpful.

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)
xsf at muc.xmpp.org 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).

Q2.   Should we retain MIX Subject?

SEK:   The spec currently supports XEP-0045 style Subject.   Subject
reflects a style of Room use where the discussion topic is set and changed
in line with the discussion by moderators or participants.     This does not
reflect the type of room usage I observe or use in modern real time chat
services such as Slack.    I think that use of Description (MIX information
node) would be a better way of handling the way I see subject used (e.g.,
XSF subject is the fairly static: " XSF discussion room | Logs:
http://logs.xmpp.org/xsf/ | Agenda
https://trello.com/b/Dn6IQOu0/board-meetings | XMPP Summit:
summit at muc.xmpp.org").    So, I would suggest that we drop Subject, unless a
significant real use requirement is identified.  I do not think we should
retain it simply for MUC backwards compatibility.

This seems broadly sensible. One could even note that bookmarks seem to be
a common coercion of the MUC Subject. (Something trivial to do in MIX).

Q3.  Should we include Voice Control?

SEK:  I have explicitly excluded voice control, although it would not be
hard to add in.  I believe that this belongs to a type of room use that
simply does not happen.   If we choose to retain Subject and identify
requirements,  I think it makes sense to consider if we want voice control.
I feel that this is a bit of complexity that MIX can do without.

Q4.   Should we allow password controlled rooms?

SEK:  These are not in the current MIX.  I think that this is lousy security
and we should drop this (the current text reflects this view).   If someone
really wants this, an additional XEP could be written.  I am very strongly
opposed to putting this into core MIX.

Q5.  Should MIX Channels be added to the roster?

SEK:  The current spec does this and I think it is a clean and elegant
approach, which I would like to retain.  It seems to me that it re-uses a
lot of core XMPP functionality in a sensible way.   Georg Lukas has argued
that this function should be in MIX Proxy and roster should not be used.
I note that for operation where all clients have same MIX channel use,
roster works nicely.   If different clients have different sets of channels,
"correct" behaviour (which I set out in the MIX proxy section) needs MIX
specific behaviour for the roster handling.   I prefer to address this by
allowing roster extension to address this (rather than discarding the whole

Q6. Where MIX Proxy is specified?

SEK:  The original intent was to specify all of this in PAM.   I wrote a MIX
Proxy section in MIX, as I felt it was important to set out what behaviour
is needed.   This section currently notes that the text might move to PAM or
a separate XEP.    Looking at the result,  I think that it should stay in
the MIX specification as it is central to how MIX works and there is a good
deal of MIX specific stuff in it.

Q7. Should we change the name "MIX Proxy"?

SEK:  Georg Lukas suggested the "MIX Agent" would be better.    I don't have
strong views on this, but I think "MIX Proxy" is fine and I prefer it to
"MIX Agent" (which sounds like paint thinner).

Q8.  Should it be easy to obtain your own Proxy JID?

SEK: Georg Lukas has argued that there should be an easier way to do this
than at present.   I don't think it is worth doing, as clients have no real
need to know their own proxy JID.

Two other areas of ongoing work may have impact on MIX and may be sensible
to discuss.

1.   MAM Updates.  There are some changes under discussion in MAM which will
quite likely lead to MAM IDs being included in payload.   If these have
happened, we need to discuss in context of MIX.

2.   SIMS and how this works with MIX.

Please let me have any suggested additions to this list of question to be

Looking forward to the discussions in Brussels


Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: Standards-unsubscribe at xmpp.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20170104/b09b8667/attachment.html>

More information about the Standards mailing list