Some comments: * At the end of the Introduction, the spec says it is RECOMMENDED that MIX and MUC be served on distinct domains. I thought we'd arranged things such that MIX and MUC were now non-conflicting in protocol terms, and we could safely use the same domain (and thus the same address irrespective of the protocol, which I think is a big win). Is this just a hangover from previous versions?
* In §3.2, item 15 is a prohibition on sharing MIX domains with end-user jids. While I suspect this could cause problems, I cannot immediately think what they might be - perhaps this is really a SHOULD NOT? * Second para of §3.3 doesn't seem to be true anymore - I don't *think* that a MIX channel is, strictly, a XEP-0060 pubsub service anymore. It has a lot in common, but you couldn't point a XEP-0060 client at a MIX channel and have it do anything much, mostly due to node='mix' (which is a good thing, mind). * In §3.5, "To enable MIX to work, this behaviour is necessary and so the server of every MIX client MUST follow the rules set out in this specification." seems self-evident. A server wishing to support the specification MUST support the specification, indeed. I think highlighting that there are three actors required for MIX to work back in Section 1 (or at the top of Section 3) might be useful, however - it's only at this point that an implementer might discover that the user's home server requires support as well. * Item 3 in §3.5 seems vague. Presumably, it's all MIX messages - is it all MIX traffic? Is this only for subscribed MIX channels? * The default visibility given in §3.8 seems overwrought. Surely it's always "Prefer Hidden"? This will give exactly the same results, but has the advantage that if the channel's visibility setting changes, the user's visibility changes as appropriate. * In §3.9.1, it seems to me that roles might not be needed. I think they were in MUC, but in MIX, it seems like the permissions for a particular user are explicit due to the affiliations of the nodes. Also, it's not clear to me why a channel has an absolute requirement on having an owner. It feels, to me, like a channel which has no owner is a perfectly reasonable thing to have, and I can't see why it should be an interoperability requirement to have one. That said, the table here might be useful simply to define terms. * §3.9.4 dictates that a nickname is mandatory. I wonder if it really needs to be? Certainly needs to be unique, and one assumes that servers can also reject homoglyphic nicknames and similar. But if users are not given the participants node, can they see a nickname? Would they need to? * §3.9.5 / §3.9.6 still seem massively awkward to me. When we implemented this, we implemented it such that it was a single node which administrators viewed differently to ordinary participants, and it was easy enough to do that way. But our client access was deeply inefficient where we really wanted to show users by their real jids and names. * §3.9.7 is curious - it implies that there may be presence here from non-participants. Is this right? Would this presence still be fanned out to all channel subscribers interested in presence? I feel I'm missing a use-case here. Also, the document clearl;y states that clients MUST NOT ever use this node as a pubsub node - so do we ever need to implement it as one? * §3.9.8 - did we really decide to keep name and description? Oh, well. * §3.9.9 - I misread ", stored in the banned node" as implying that the Allowed list is stored in the banned node, by mentally adding in an "and". Maybe it's simpler to say ", as specified in §3.9.10". * §3.9.11 - That's a lot of options. * §3.10 - "do no conflict" typo. I agree with the sentiment of the MUST NOT, though I think it's largely a lost cause, and problematic when a custom node ends up superseded by standardization. * §4 - I'm not sure what this section is trying to say. Follow these other specs? * §5.3 - the node='mix' here seems superfluous, I think, though I could be wrong. * §5.5 has a typo in Example 18, the close quote has been replaced by an additional '>'. I'll go through the rest later. On 2 January 2018 at 16:14, Jonas Wielicki <[email protected]> wrote: > Version 0.9.4 of XEP-0369 (Mediated Information eXchange (MIX)) has > been released. > > Abstract: > This document defines Mediated Information eXchange (MIX), an XMPP > protocol extension for the exchange of information among multiple > users through a mediating service. The protocol can be used to provide > human group communication and communication between non-human entities > using channels, although with greater flexibility and extensibility > than existing groupchat technologies such as Multi-User Chat (MUC). > MIX uses Publish-Subscribe to provide flexible access and publication, > and uses Message Archive Management (MAM) to provide storage and > archiving. > > Changelog: > > Various Clarifications from Georg Lukas review: > Role Membership reword, > Participant's Node Joining clarification, > Joining Channel Clarification, > Coming online clarification, > Going offline JID error, > Allow servers to limit retract time frame, > Clarify that private messages must not be groupchat, > Creating Channel Clarification, > Address security concerns on Converting a 1:1 Conversation to a > Channel, > Remove requirement for all user clients to support MIX, > Change Retract to use MAM-ID; > Ensure use of .example throughout (follow RFC conventions); > (sek) > > URL: https://xmpp.org/extensions/xep-0369.html > > Note: The information in the XEP list at https://xmpp.org/extensions/ > is updated by a separate automated process and may be stale at the > time this email is sent. The XEP documents linked herein are up-to- > date. > _______________________________________________ > 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] _______________________________________________
