On 4 Jan 2017 09:34, "Steve Kille" <[email protected]> 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) [email protected] 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: [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. 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 approach). 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 addressed Looking forward to the discussions in Brussels Steve _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
