Dave, > -----Original Message----- > From: Standards [mailto:[email protected]] On Behalf Of Dave > Cridland > Sent: 03 January 2018 16:15 > To: XMPP Standards <[email protected]> > Subject: Re: [Standards] UPDATED: XEP-0369 (Mediated Information > eXchange (MIX)) > > 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. [Steve Kille]
I think MUST NOT is right. Will take other input here. > > >> * 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. [Steve Kille] Happy to look at suggestion. This text is early on, and repeating stuff only makes the doc longer. > > > > >> > >> * 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. [Steve Kille] OK > > >> * §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. [Steve Kille] What do we do instead??? > > >> * §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. [Steve Kille] Might be sensible to clarify requirements for non-participant access to MIX channels. Perhaps an Agenda item in Brussels? > > > 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. [Steve Kille] You are right - archive is a good reason to implement as PubSub I can see requirements arising for archiving presence history > >> > >> * §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. [Steve Kille] If you care enough to suggest alternate text, I'll be fine to review > >> > >> * §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? [Steve Kille] I think some more text will be helpful. I suggest we defer this until we have more experience with the core. > > > > >> > >> * §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. [Steve Kille] Good > > > 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. [Steve Kille] I'm not saying "no errors documented". MIX does show error examples, and in some cases notes which errors to use without example. If there are areas where adding more information/examples will help, point out where and I'll add. > > > > >> > >> * §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. [Steve Kille] You are probably right that 5.3 is OK without, but given that MIX specific information is returned, it feels safer to include. > > In addition, how does a client know to try a disco#info with node='mix'? It > would need to discover MIX support first, surely? [Steve Kille] This is the channel. It will know MIX support from the domain. > > Dave. [Steve Kille] Steve _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
