Dave, Appreciate your review comments. Detailed comments below.
I have made the changes noted, and you can review on my github account. I'll hold off pushing a 0.9.5 for a bit, and wait for any further comments/discussion. > -----Original Message----- > From: Standards [mailto:[email protected]] On Behalf Of Dave > Cridland > Sent: 02 January 2018 17:40 > To: XMPP Standards <[email protected]> > Subject: Re: [Standards] UPDATED: XEP-0369 (Mediated Information > eXchange (MIX)) > > 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? [Steve Kille] This is a very detailed point to have at end of introduction. I have replaced with a short note that this spec gives guidance on supporting MIX and MUC together. Section 8 now sets out the choices without recommendation. It may make sense to make recommendations once we have implementation experience of the options. > > * 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? [Steve Kille] I would not want to relax the restriction unless someone gives a very good reason as to why this might be useful. Doing this feels like something that is just asking for trouble. > > * 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). [Steve Kille] You are technically right, and I've tweaked words to address this. > > * 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. [Steve Kille] The wording is laying it on with a trowel, but I think this requirement is not (initially) intuitive and needs setting out in detail. I can't see much benefit in adding duplicate text to introduce earlier. This is the fifth "concept" section, and something the reader needs to get head around. I don't see a need for change here. > > * 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? [Steve Kille] I’ll tighten. If a MIX message arrives for a non-subscribed channel, something has gone wrong! > > * 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. [Steve Kille] Yup - tidied this. The first option is now "Prefer Visible" and default is Prefer Hidden. > > * 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. [Steve Kille] Handling all of this with PubSub affiliations might be possible, and I have a note to review this with my co-author. The current scheme gives a MIX-oriented model. This gives a model that I see as well suited to MIX, and the whole thing works. From what I can see, setting out a scheme with PubSub affiliations would need a lot of specification. I would not be happy to go down this path until someone has evaluated the implications in some detail. My intuition is that having an access control model at the MIX channel level (as the current doc) is the best approach. However, I think that the alternative of using PubSub access control on each node has not been adequately considered. > 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. [Steve Kille] Agreed. I was thinking of scenarios where an owner makes sense, but there are others where it is not. I'll make optional. > > * §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? [Steve Kille] There is an inconsistency here, as 6.1.5 is clear that Nick is optional, but needed to send messages or register presence. I'll bring 3.9.4 in line with this. > > * §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. [Steve Kille] This all comes out of requirements (clearly agreed) to control JID visibility. It is quite complex, but I think is a clean way to address the requirements. > > * §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. [Steve Kille] This is not driven by a core requirement, but there definitely was a request/requirement somewhere to have participation by clients that are not participants. Default is "participants" only. This is complexity that I'd be quite happy to lose, but I am certain that there was a good reason it went in! 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? [Steve Kille] The normal behaviour of presence node makes it the least pubsub-like node in MIX. It seems helpful to model everything as a PubSub node. My thinking of the MUST NOT here was: a) I can't conceive of a sensible use; and b) It will enable this to be implemented another way > > * §3.9.8 - did we really decide to keep name and description? Oh, well. [Steve Kille] Yes. There was a LOT of discussion, and this is where we ended up. > > * §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". [Steve Kille] I re-read, and I think the wording is fine. > > * §3.9.11 - That's a lot of options. [Steve Kille] Yes. Could do with detailed review. Ties to the access control model comment above. > > * §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. [Steve Kille] Typo fixed. Point is right, but I don't see a need to change the text. > > * §4 - I'm not sure what this section is trying to say. Follow these other > specs? [Steve Kille] There are some XEPs that give examples of all possible error conditions. I find that this adds large volume to the specs, without adding anything, and losing readability. This is trying to say that MIX documents success cases. Send sensible compliant errors and be prepared to accept any valid error. > > * §5.3 - the node='mix' here seems superfluous, I think, though I could be > wrong. [Steve Kille] The reason for this is to support MUC/MIX sharing. If you don't see node=mix, the query is from a MUC client, and you should not send confusing MIX stuff. > > * §5.5 has a typo in Example 18, the close quote has been replaced by an > additional '>'. [Steve Kille] Oops! Fixed, plus another error in the example. > > I'll go through the rest later. > [Steve Kille] Look forward to it. Thanks for all the review Steve _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
