On 3 January 2018 at 15:25, Steve Kille <[email protected]> wrote: >> * 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. >
Feels, yes. But I can't see what trouble it would cause. That's why I'm wondering if this ought to be a SHOULD NOT. Undoing a MUST NOT later on is harder work. >> * 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. > Not that this is a hill to die upon, but the fact that MIX isn't end-to-end is going to be a surprise to many, I think. Worth getting the surprises out of the way earlier. I'll make a specific text suggestion. > >> >> * 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! > Yes - and we'll need to figure out error cases like this properly at some point. Not an immediate thing to worry about, though. >> * 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. > I'm not wed to the idea of exclusively using pubsub affiliations, nor abandoning roles. But revisiting this might be interesting. >> * §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. Well, there's two issues here: a) jidmap works fine if all its items might not be visible to everyone. This feels much cleaner than having multiple nodes to handle jid mapping for different access levels. b) Keeping the jidmap solely in a pubsub node made presenting the real jid against messages very painful, especially in the case where the jidmap contained many more items than the message node had archived messages. >> * §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! > > I can totally agree that non-participant clients MAY be able to access message archives, and other read-only cases. But it seems wrong that a non-participant could share presence. > 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 > I think archive access might be useful to see historical presence. Not that I'm delighted by the idea (and we never implemented presence). But if we can share presence without having a formal presence node, that implies that we only ever need one if we want to have archived presence. > >> >> * §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. > Not a hill to die on. But a hill to look at, shake my head, and sigh. I do like the UI guidance there, though. >> >> * §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. Yes, but you have the advantage of knowing what it says. I genuinely misread this. Got there in the end, though. > > >> >> * §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. Indeed - here it certainly looks the sensible option. > > >> >> * §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. > Thinking further, do we need any text on how custom nodes can be created? Can a client do so, or must they be done by code or configuration on the service? > >> >> * §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. > I agree with this. > This is trying to say that MIX documents success cases. Send sensible > compliant errors and be prepared to accept any valid error. > But not with this. I think there's a happy medium. I think the specification here wants to say that not every error case is documented, but I think some error cases we do need to document. > >> >> * §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. > I think that's needed in §5.4's disc#items, but not in §5.3's disco#info. If a disco#info response with both MIX and MUC confuses clients, something is broken in XEP-0030. In addition, how does a client know to try a disco#info with node='mix'? It would need to discover MIX support first, surely? Dave. _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
