[Standards] MIX clarity, MAM, and client-proxy interactions
steve.kille at isode.com
Thu Dec 22 11:30:56 UTC 2016
> -----Original Message-----
> From: Standards [mailto:standards-bounces at xmpp.org] On Behalf Of Georg
> Sent: 22 December 2016 10:27
> To: standards at xmpp.org
> 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.
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 <steve.kille at isode.com> [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.
> > > 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
> * 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.
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.>
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.
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
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).
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.
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,
I'm enjoying working on the MIX spec
More information about the Standards