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

Dave Cridland dave at cridland.net
Wed Sep 7 07:12:47 UTC 2016


On 7 Sep 2016 06:44, "Daurnimator" <quae at daurnimator.com> wrote:
>
> 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.
>

I agree this isn't "atomic"; I don't think it's meant to be.

> >> 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
> https://xmpp.org/extensions/xep-0045.html#enter-gc
>

The MUC element is optional in the same way that SASL authentication is
optional... Joining by sending presence alone is a legacy path.

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

I can see benefits in being able to retrive a vCard for a user that has
since left the channel. There's possibly utility in finding out previous
vCards from existing users. But vCards will, with luck, reduce in
importance since we'll all be using PEP-based avatars, right?

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

This entire area is, I agree, horrible - I'm increasingly thinking that
trying to push it aside is going to bite us very badly in the future.

> >>   - 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 think this would be horrible. Polling continuously to detect a new node
is going to be painful.

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

Clients already have a state displayed for entities in an unknown state -
they need this for cases where there's no subscription, etc.

> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160907/427c6011/attachment-0001.html>


More information about the Standards mailing list