Georg, Thanks for your detailed review comments. Let me go over them.
> -----Original Message----- > From: Standards [mailto:standards-boun...@xmpp.org] On Behalf Of Georg > Lukas > Sent: 05 December 2017 20:04 > To: standards@xmpp.org > Subject: Re: [Standards] UPDATED: XEP-0369 (Mediated Information > eXchange (MIX)) > > Hi, > > so I finally found the time to recover my notes for the first half of MIX, > and to > get through the second half. Notes below :) > > > §3.2 Core Concepts > > | 13. Although some protocol is shared with MUC, MUC clients are not > | interoperable with a MIX service. This means that where a user > | chooses to use MIX, all of the users clients need to support MIX. > > Is that still a requirement / concept? [Steve Kille] Yes. This is quite fundamental to the way MIX works. > > > §3.9.1 Roles > > | Administrators, Participants, and Allowed MAY NOT have any members. > > There is no "MAY NOT" in RFC 2119, and this is probably a typo anyway. > Probably "MAY be empty" would be better? [Steve Kille] Yes, the text is wrong. I will sort out, probably with your suggested words. > > > §3.9.4 Participants Node > > | When a user joins a channel, the user's bare JID is added to the > | participants node by the MIX service. > > From context, this should be the user's bare proxy JID. [Steve Kille] Yes - will clarify > > > §6.1.1 Joining a Channel > > When I join / leave a MIX channel with one of my clients, I would like to know > what happens to my other clients, i.e. what kind of information do they get > (roster push? pubsub notifications?). It would be great to have according text > in the XEP, plus examples of the anticipated XML - as a client developer, I > need to cope with a situation where I will receive seemingly unrequested > data. [Steve Kille] Key point is that USER joins a channel. The join request is sent by a client to the user's server. This indirection is needed because the user's server needs to make roster updates to reflect the join. The MIX channel response to the channel join goes back to the user's server, and then the server sends the response back to the user's client that made the request. I will add some text to emphasise that this is the only client getting the response (which is to match the original request). The update made to the user's roster needs to be reflected back to ALL clients. This will happen by "normal operation". I will add text to make this clear. The client experience will be that if one client adds a MIX channel, that this will then appear in the roster of all the user's online clients. > > > §6.1.5 Setting a Nick > > How are other channel participants informed about a nickname change? Do > they have to subscribe to the Participants node? Or will there be a presence > update (§6.1.7 has a presence example that contains the nickname)? > > When the user joins, they don't have a nickname at all, it is only assigned > with <setnick/> - does that mean each join causes two Participants updates - > one with the proxy JID and another one with the nickname? [Steve Kille] The Nick is best thought of as a parameter associated with the user. As the introduction to 6.1.5 makes clear, this needs to be set for a user to share presence or to send a message. When presence is shared, the server will add the user's configured Nick. (see example 45) When presence is shared, the server will add the user's configured Nick. (see example 52) For messages and presence, the proxy JID does not change. This means that the client will be able to "do the right thing" when a nick changes. A client that wants to track Nick changes as they happen can subscribe to the participants node. I don't think any text changes are needed. > > > §6.1.8 Client Coming Online and Obtaining Presence from the Local Server > > | Presence updates will continue to flow to the user's local server, and > | so the local server is able maintain up to date presence state for the > | channel. > > Does that mean that a server must keep a cache of all client presences of all > participants of all MIXes of all users? Even if the local user abandoned their > account a long time ago? That sounds like you could DDoS an XMPP server by > registering an account, joining a large number of large MIXes and causing > significant ingress traffic. > [Steve Kille] There is no requirement to cache client presence, although a server MAY cache. I'll tweak the text to make this optionality clear. If there are no online clients, the server can choose to maintain roster state, or can discard the messages. > > §6.1.12 Going Offline > > | The MIX channel will notify subscribers to the presence node of the > | user going offline by sending a presence stanza to the full proxy JID > | of each client. > > I suppose here it's actually the full JID and not the proxy JID ;-) [Steve Kille] Ooops! It is status of the full Proxy JID that is shared. Will fix the text. > > > §6.1.14 Retracting a Message > > The <retract> element references the message ID - not the MAM ID. I'm not > sure what the time frame is where it is allowed for a client to retract, and > whether the <retract> message will be reflected to all MIX participants or > only stored in MAM (and which ID will be contained in the reflected > retraction). If I want to retract a message I sent from another client / > before > a client restart, do I need to persist the original message ID now (and so > does > the MIX service)? [Steve Kille] The retract goes into the message stream, so clients will get this in they way they get all new messages to a channel. I will add a note on timeframe, allowing servers to time limit when retract applies. > > Maybe we should move Retraction into its own XEP as well? Or maybe use > Last Message Correction for that, instead? (Though LMC also relies on the > message ID, which I consider unfortunate if we also have stable-stanza-IDs). [Steve Kille] LMC is simply a new message updating the previous one. Retraction removes the message from the record, which can be important. It is a simple and clear spec, so I think fine to leave in core MIX. > > > §6.1.16 Inviting another User to join a Channel that the user does not > have Permission to Join > > I like the principal protocol here, though I think it would be acceptable to > remove the <inviter> and <invitee> elements from the <invitation> element. > The server needs to verify the JIDs anyway and can not rely on what is > passed by the invitee (but it could encrypt the fields into the token). > > I'm not sure if the inviter needs to bind the invitation to a given invitee > JID or > if an "unbound" invitation would be acceptable - but there is really no > technical need to carry on the <inviter> field. [Steve Kille] Technically, you could remove this information, and simply rely on context to determine what the token means. I think that having the information explicit is going to help both implementation and deployment. It makes things easier of you can clearly see what the invitation is doing. I don't see any real benefits in removing the information. > > > §6.1.17 Sending Private Messages > > I think we need to get rid of ressource locking for messages, and that the > receiver's server always needs to forward the message to all MIX-joined (or > maybe even MIX-enabled) clients. It would make the table less complex > because there would be no more need to distinguish between "first" and > further messages. [Steve Kille] I'd like to make this change. It seems sensible to me. However, I recollect that this choice was driven by a specific requirement. The model of starting with bare JID, and moving to full JID (explicit single client) is how 1:1 works. This is all going to interact with carbons, and there has been much thinking about this of late. I'd like feedback from others before I make any changes here. > > It might also make sense to explicitly state the message types that are > allowed to be sent as private messages (everything but 'groupchat'? Only > 'chat' and 'error'?) [Steve Kille] I think that making "not groupchat" explicit is a good idea. > > > §6.3 Ensuring Message Delivery > > | When there is a long term connection failure, the MIX channel will > | receive an error from the XMPP server indicating that a message failed > | to transfer to a recipient. > > Unfortunately, there is no guarantee that 'groupchat' messages will be > bounced on error. It might be better to have a mechanism that lets the user's > server know about a network outage and allows it to MAM-sync from the > MIX channel archive. [Steve Kille] I think we need to make the delivery reliable. I suspect that this area of the spec is going to need work as we gain experience. The MIX model is that messages need to get reliably to the user's server. I think that trying to make the user's server responsible for sync is fraught with difficulty. I think we should try the mechanism described in the section, and refine based on experience. > > > §6.5.2 Creating a Channel > > I would suggest to change the wording from "channel name" to "channel > identifier" and to explicitly state that this will become the local-part of > the > channel JID. A channel _name_ might as well mean the human-readable free > text field that is returned as the identity name field to disco#info. > > There might be merit in letting the client also define this identity name at > the > same time when creating a channel. [Steve Kille] I think that "name" is good here. Seems a clear and sensible term to me, and the term is only used in this section. I will add a note to make clear that this is the param that ends up in LHS of JID. > > > §6.5.4 Converting a 1:1 Conversation to a Channel > > There are two security implications when forwarding message history. > First, it would expose private/encrypted/sensitive messages to the MIX > service. [Steve Kille] A client can expose this info in many ways. I will add a note on this, as it makes sense for the user to confirm that they want to share history with users who subsequently join the (private) channel. Second, there is no way to verify the authenticity of the messages, > so the sender could easily fake a conversation history. > A joining client now needs to distinguish normal messages from messages- > forwarded-by-somebody in the UI to make that clear to the user. [Steve Kille] Yes - this is potentially nasty. > > | ... MAY be sent by either the user creating the channel or the 1:1 > | chat partner at any time subsequently. > > A malicious MIX participant could use this mechanism to inject fake messages > at any time. After finding out the hard way that a dozen client > implementations failed to check the source of Carbons [0], I consider this > feature as highly problematic. [Steve Kille] Here is how I propose to address this. 1. Require that if history is added, it is done by the user creating the room before any other client is added. Allowing history to be added later is I think too risky, 2. Recommend that when the other 1:1 client joins the room that it validates the history. If it does not match, alert the user, who can take appropriate action. What do you think? > > > §8. Supporting MIX and MUC together > > Thanks very much for making the fully integrated approach compatible and > supported. Now, can we remove the partially integrated one, please? It adds > complexity to the protocol and to clients, and it really has no benefit over > the > fully integrated one, except maybe as a short-cut for server > implementations. [Steve Kille] I think that the partially integrated approach remains a good option. I believe that many implementers will want to take this approach. The fully integrated approach has a number of non-trivial issues to address and I think it would be a serious mistake to not include the partially integrated approach. > > > > Thanks, > > Georg [Steve Kille] Thanks again for the very useful comments I plan to make the changes before Christmas. Steve _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
