Georg, > -----Original Message----- > From: Standards [mailto:[email protected]] On Behalf Of Georg > Lukas > Sent: 22 December 2016 10:27 > To: [email protected] > Subject: [Standards] MIX clarity, MAM, and client-proxy interactions > > Hi Steve, > > let's agree to disagree on the design decisions. I think this really needs to > be > tackled in Brussels, where we have a larger number of experienced protocol > designers. It would just be important to discuss the trade-offs imposed by > the alternatives, and to write down the design decisions and their rationale > into the XEP. [Steve Kille]
I think we need to get max buy-in to decisions made and document choices clearly. I think we need to be careful about putting too much into a spec about options NOT chosen. > > I'd still like to use this thread to better understand the current design and > to > resolve the remaining questions I have. > > * Steve Kille <[email protected]> [2016-12-22 09:47]: > > Note that for a MIX client, the local MAM archive is used. This is > > the one on the same server as the MIX Proxy. > > Wow, I absolutely missed that update. Now, on rereading §5.4 it makes > sense to me, and I see how this can be solved by the new MAM-binding. We > might need to hook MIX activation into the new binding mechanism, but it all > looks solvable to me now. [Steve Kille] Great! > > > > I can't see how having the client's bare JID reflected in an IQ > > > respsone makes any sense. > > [Steve Kille] > > This will cause it to be directed to MIX proxy, rather than the client. > > This points out a fundamental problem I have with understanding the XEP. > > There are at least four types of interactions: > > * client <-> MIX service/channel - service/channel discovery, sometimes > MAM > * client <-> proxy - activation, regular MAM, message/presence delivery? > * proxy <-> channel - message/presence delivery > * client <-> other participant's client - IQs and PMs > > There are also chained interactions, where the client sends something to the > proxy (e.g. to initiate a join), and the proxy sends something else to the MIX > channel (e.g. Example 28). And maybe also interactions where the client > sends something to a channel, but its proxy performs local actions or > manipulates the packets transparently (like filtering undirected presence > transmission to non-activated MIX channels). > > All this is very complicated and demands clear language and a proper spec of > all the steps involved in an action. However, the XEP does not specify many > of the client interactions, and in many cases doesn't explicitly state which > parties are interacting in a given example. [Steve Kille] I think that the approach to address this is to identify specific points that are not clear and improve the text. It is hard to edit based on such a broad comment. > > The XEP further states in §3.4 that "The behaviour of a MIX Proxy and the > protocol between MIX Proxy and MIX Client is not currently defined in this > specification. It will be defined in one of three places." -- I'm not sure if > this is > a leftover from an older revision or if we really are designing only one half > of > the protocol.> [Steve Kille] This was left over text from before the MIX proxy section was added. I have removed this, and the change will be in 0.6.3, as the PR has not been taken yet. > You already noticed my confusion and misunderstanding, and I think it is > based to a large part on not understanding from the text and examples > which parties are involved in a given place. > > I'll gladly re-read and provide a list of places that should be made more > explicit, but for that I need to know if the XEP is also supposed to define > the > client<->proxy interaction protocol. [Steve Kille] This is in Section 6 currently. Summit may decide to move this to PAM or to another XEP > > > > The client needs to know their own proxy JID because it is the > > > sender JID of reflected messages. > > Ah! The 0.6.2 does have messages sent out with proxy JID. I > > believe that this is a mistake, which I have now corrected. > > This is another incarnation of my understanding problem. Before your last > change, Example 45 was showing a full-proxy-JID to bare-real-JID groupchat > message which was sent from the MIX channel to the MIX proxy. > That allowed the MIX proxy (and the user's client) to attribute the actual > message to a given client of the sender. The new format is essentially a MUC > message from the MUC-JID-with-sender-nick-as-resource, > a format that we wanted to get rid of because it does not allow the > addressing of (and message attribution to) a given client. It also contradicts > §3.7, "The primary representation of a participant in a MIX channel is a proxy > JID". [Steve Kille] I think that 3.7 is correct. I do not think there is a need to attribute messages to specific clients. From a recipient perspective, messages come from other users. There are reasons to expose multiple clients (primarily presence). > > > It is also not easy to find their own proxy JID based on > > > the NICK because the NICK is optional. > > If a client sends messages, nick is mandatory. > > This is a very unfortunate protocol design: > > You get a proxy-JID assigned on join, but you need to use an unrelated, > optional, feature to obtain it (and another two roundtrips). [Steve Kille] I don't see this as a big deal > > [Proxy JID in <join> response] > > Disagree. We can review in Brussels. > > Please do so. > > > I also just realized that we have a wording conflict here: a "MIX proxy" > is a module running on your server, and the "proxy JID" is a virtual address > that is associated to users/clients in a given MIX channel. > These two proxies don't have anything in common, and it would be great to > rename one of them to better separate the concerns. > > My suggestion would be to rename "MIX proxy" into "MIX agent", which is a > well-matching term from the Mobile Computing domain for a small remote > application that performs actions on behalf of a user. [Steve Kille] I think that it makes sense to review terminology here in Brussels. We may end up folding all of this in with PAM. I am not wedded to the MIX Proxy name. > > > Thanks very much for your tireless work, [Steve Kille] I'm enjoying working on the MIX spec > > > Georg [Steve Kille] Best Regards Steve _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
