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

Steve Kille steve.kille at isode.com
Wed Sep 7 06:49:40 UTC 2016



> >> 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.
[Steve Kille] 


I don't think I agree with you, but I can see that the "atomic" statement is
potentially confusing.   It does not add anything to the spec, so I have
zapped the sentence.


> 
> >> 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
[Steve Kille] 

I will defer to Kev and other 45 experts to resolve this.


> 
> >> 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....
[Steve Kille] 

This section header is a place holder.   Can we review the value of the
section after it is written?    

> 
> >> 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.
[Steve Kille] 

I am proposing to drop the mechanism.   

Changing the nomenclature is a possibility (which I prefer if we keep the
mechanism).   

I'd like to understand requirements/use case.   To me "it has always been
there" feels very weak.



> 
> >>   - 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.
[Steve Kille] 

This is an important question, and the best approach is not immediately
clear.

I have added a short section noting two simple approaches and asking for
input.    Sending both invites simultaneously feels wrong to me.   


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

[Steve Kille] 

This is over-engineering for a specialized case.  Most channels will have
presence from the get go.   A channel configured without presence will
usually be done this way for a good reason (e.g., to save bandwidth in a
sensitive environment).    Turning on/off presence will be pretty unusual.
I think that having the spec go into details here would not be helpful.

Thanks for your input.

Change pushed.


Steve




More information about the Standards mailing list