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

Steve Kille steve.kille at isode.com
Tue Jan 10 15:51:13 UTC 2017



I've updated this list of questions to reflect various discussions and that
MIX 0.6.4 has obsoleted two of the questions.

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


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


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


Q4.  Should MIX Proxy allow a user's clients to have different channel
participation

SEK: The current spec allows this and enables clients to select channel
membership.    This adds flexibility, but I can see merits in a simpler
approach of requiring all clients to have the same membership.


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 
(see Q5) "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).



Q6. Where MIX Proxy is specified and what is the relationship to PAM?

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 MIX/PAM specification.    Looking at the result,  I think that it
should stay in
the MIX specification for now as it is central to how MIX works and there is
a good
deal of MIX specific stuff in it.    A decision on this may need to be
deferred until further work has been done on PAM.


Q7. What should we change the name "MIX Proxy" to?


SEK:  I introduced MIX Proxy as a term to group and make very clear
behaviour of the User's Server which is important to MIX.   It is essential
to draw this out clearly as this requirement is not intuitive.    This is a
behaviour of the User's Server and one way to address this is simply to now
describe as "MIX behaviour of the User's Server".    Or we could find a
special term for the behaviour such as "MIX Behaviour of the User's Server"
(or something snappier).    I think it is important that we describe in a
way which does not give the sense of some sort of separate entity.


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

SEK.  Some have argued  that proxy JIDs add too much
complexity to MIX.   Proxy JIDs are used to support JID Hidden channels.   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.



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

SEK:  Georg Lukas has argued that this is imperative.   I do not think that
this make sense to add to core MIX, but it may make sense to write as a
separate XEP once people have implementation experience.





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