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: [email protected]"). 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 _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
