[Standards] MIX Discussion topics for the Summit - update #1

Steve Kille steve.kille at isode.com
Thu Jan 5 15:48:15 UTC 2017


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.


Q2.    Should we provide a MUC compatible "Minimal Viable Protocol"
interface to a MIX service.

SEK:  Georg Lukas has argued that this is imperative.   I view that it would
be a lot of effort and would likely hinder us taking MIX in a good forward
direction.   


Q3.  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.


Q4.  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.


Q5.   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.


Q6.  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
approach).



Q7. 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.    


Q8. 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).   


Q9.  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.


Q10.   Do we need to support JID hidden channels and proxy JIDs?

SEK.  It has been correctly observed that proxy JIDs add significant
complexity to MIX.   Proxy JIDs are used to support JID Hidden groups.   A
little complexity could be removed if we dis-allow conversion between JID
hidden/visible, but most of the complexity is inherent to JID Hidden.   I do
not believe there is a better approach to JID Hidden.   The 2016 summit was
clear that we need to support JID Hidden (e.g., to prevent JID harvesting in
public channels).    I think that this means we need to use proxy JIDs.







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
addressed


Looking forward to the discussions in Brussels



Steve






More information about the Standards mailing list