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

Daurnimator quae at daurnimator.com
Wed Sep 7 04:44:09 UTC 2016

On 7 September 2016 at 01:15, Steve Kille <steve.kille at isode.com> wrote:
> Daurnimator,
> Thanks for your comments.
>> -----Original Message-----
>> From: Standards [mailto:standards-bounces at xmpp.org] On Behalf Of
>> Daurnimator
>> Sent: 06 September 2016 09:00
>> To: XMPP Standards
>> Subject: Re: [Standards] UPDATED: XEP-0369 (Mediated Information
>> eXchange (MIX))
>> 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.
> [Steve Kille]
> 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

Atomic means indivisble: that the whole action either fails or
succeeds as one step; there should be no "partially-worked" outcome.

>> 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.
> [Steve Kille]
> Kevin Smith responded on this point.

The <x/> muc element is optional, see

>> Section 5.1.15:
>> The outlined process doesn't allow retrieval of non-current vcards.
>> IMO historical vcards should be available.
> [Steve Kille]
> This sounds quite tricky to achieve.   What entity would you expect to hold
> vCard history?

I'm not sure; however if an entity doesn't have to treat vcards
differently to 'normal', then I see no reason to mention vcards

>> Section 7.1:
>> Aren't passwords just a multi-use invite token?
> [Steve Kille]
> 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.

In that case, the mechanism isn't dropped; just the nomenclature.

>>   - How should/can invites be sent to a party that you're not sure
> supports
>> MUC vs MIX?
> [Steve Kille]
> The MUC and MIX section shows how you can determine if a service supports
> both.
> You would need to use lookup of client capability to see which to send.  Do
> you think this needs documenting in MIX?

I'm not sure this is sufficient: how are you to know if a friend's
client supports MUC vs MIX?
The only satisfactory answer would be to send both MIX and MUC invites
(assuming the room is available as both).
However, the recipient will need to know that the 2 invites they
receive are for the same room (and hence if they support MIX, the MUC
invite can be ignored).
This necessitates that a 'linked muc' (if one exists) should be
specified *in* a MIX invite.

>>   - What if a channel transitions from presence-less to presence-ful?
> [Steve Kille]
> 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.

I mean: if a channel turns on presences: you will be missing presences
in the archive from before it was turned on.....
Clients will still *want* a presence I think, so they'll end up
auto-generating a fake one.
This might be something worth standardising: what to consider as the
presence if no presence is present.

More information about the Standards mailing list