[Standards] UPDATED: XEP-0369 (Mediated Information eXchange (MIX))
steve.kille at isode.com
Tue Sep 6 15:15:39 UTC 2016
Thanks for your comments.
> -----Original Message-----
> From: Standards [mailto:standards-bounces at xmpp.org] On Behalf Of
> Sent: 06 September 2016 09:00
> To: XMPP Standards
> Subject: Re: [Standards] UPDATED: XEP-0369 (Mediated Information
> eXchange (MIX))
> Section 3:
> > Each participant is addressable by a single bare JID, which is a proxy
> the user's real JID) to make it straightforward to hide the user's real
> other channel participants. Full JIDs comprised of this bare JID plus a
> are then constructed, allowing visibility into the number of online
> participating in a channel.
> Are the resources of full jids masked too?
> If not, it could be easy to figure out who a user is by their
> (relatively) unique resource.
I have added a couple of words at this point to make this clear.
> Section 5.1.1:
> > The channel must process the join atomically.
> > If a user cannot be subscribed to one or more of the requested nodes
> (e.g., because the node does not exist), but can be subscribed to some the
> response simply lists the nodes successfully subscribed. If none of the
> requested are successfully subscribed to, and error response is sent
> indicating the reason that the first node requested was not subscribed to.
> That doesn't sound like atomic to me.
I corrected typo (and -> an) in this para
I think this is atomic. The rules for processing the request are
unambiguous. I can't see what the issue is
> Section 5.1.2:
> > AUTHOR'S NOTE AND QUESTION: Dave Cridland has suggested. I would
> prefer: a) User options be sent in the initial join/>. b) Unknown options
> ignored. c) User options can be requested (as a form). If clients require
> option to be supported, they should request the form.
> This suggestion sounds good to me.
Noted. I'd welcome other views on this, as we do need to make a choice on
the details of the mechanism here. I can see merits in both approaches.
> Section 5.1.3:
> > leaving the channel is a permanent action for a user across all
> > clients, not just a matter of telling the channel that the user is not
> > currently available or for a single client
> How can a user opt out of receiving messages on one of their (many)
The next version of MIX will address this
> Section 5.1.6:
> > Unlike in Multi-User Chat (XEP-0045)  where coming online is a
> > special action, coming online in MIX is implicit when presence status
> > is set
> In MUC it didn't have to be; infact, often joining a room was no different
> updating your presence.
Kevin Smith responded on this point.
> Section 5.1.11:
> > AUTHOR NOTE AND QUESTION: Message id coming back is different in
> example. This is because the reflected message uses MAM ID, which seems
> helpful. However, it makes it harder for sender to correlate reflections.
> to be explicit as to compliant behaviour. Input as to whether the ID
> change is solicited. A more complex option would be to include both IDs in
> some way.
> Client generated ids cannot be trusted to be unique (or conforming to
> whatever some arbitrary server considers an acceptable mam message id)
That is right. You cannot use the client generated ID as the MAM ID.
However, I don't think this answers the question
> Section 5.1.15:
> The outlined process doesn't allow retrieval of non-current vcards.
> IMO historical vcards should be available.
This sounds quite tricky to achieve. What entity would you expect to hold
I think there would need to be a quite compelling use case to justify adding
> Section 7.1:
> Aren't passwords just a multi-use invite token?
You could think of them like that. I think the term "password" gives a
sense of security, which is why it is time to drop the mechanism.
Multi-invite token feels less of a problem. Is there really a
> - Declines are not specified; this was an important MUC feature to me.
I've added a short note on this as an editing reminder. It seems a
sensible feature to include, assuming it comes out cleanly.
> - How should/can invites be sent to a party that you're not sure
> MUC vs MIX?
The MUC and MIX section shows how you can determine if a service supports
You would need to use lookup of client capability to see which to send. Do
you think this needs documenting in MIX?
> - What if a channel transitions from presence-less to presence-ful?
I think this just falls out in the wash. A presence node is added.
Client would need to check channel capabilities (seems generally sensible to
do from time to time) and react to the change.
Thanks for your comments
I have pushed the changes noted
More information about the Standards