[Standards] UPDATED: XEP-0369 (Mediated Information eXchange (MIX))

Daurnimator quae at daurnimator.com
Tue Sep 6 08:00:17 UTC 2016


On 6 September 2016 at 00:59, XMPP Extensions Editor <editor at xmpp.org> wrote:
> Version 0.3 of XEP-0369 (Mediated Information eXchange (MIX)) has been released.
>
> Abstract: This document defines Mediated Information eXchange (MIX), an XMPP protocol extension for the exchange of information among multiple users through a mediating service. The protocol can be used to provide human group communication and communication between non-human entities using channels, although with greater flexibility and extensibility than existing groupchat technologies such as Multi-User Chat (MUC).   MIX uses Publish-Subscribe to provide flexible access and publication, and uses Message Archive Management (MAM) to provide storage and archiving.
>
> Changelog: Addressing comments from review of 0.2 and expansion/clarification of MUC/MIX dual working (sek)
>
> Diff: https://xmpp.org/extensions/diff/api/xep/0369/diff/0.2.3/vs/0.3
>
> URL: http://xmpp.org/extensions/xep-0369.html

Comments:

Section 3:
> Each participant is addressable by a single bare JID, which is a proxy JID (not the user's real JID) to make it straightforward to hide the user's real JID from other channel participants. Full JIDs comprised of this bare JID plus a resource are then constructed, allowing visibility into the number of online resources 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.

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 nodes 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.

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 are ignored. c) User options can be requested (as a form). If clients require an option to be supported, they should request the form.

This suggestion sounds good to me.

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) resources?

Section 5.1.6:
> Unlike in Multi-User Chat (XEP-0045) [24] 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 to updating your presence.

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. Need to be explicit as to compliant behaviour. Input as to whether the ID should 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)

Section 5.1.15:
The outlined process doesn't allow retrieval of non-current vcards.
IMO historical vcards should be available.

Section 7.1:
Aren't passwords just a multi-use invite token?

Other:
  - Declines are not specified; this was an important MUC feature to me.
  - How should/can invites be sent to a party that you're not sure
supports MUC vs MIX?
  - What if a channel transitions from presence-less to presence-ful?


More information about the Standards mailing list