<p dir="ltr"></p>
<p dir="ltr">On 7 Sep 2016 06:44, "Daurnimator" <<a href="mailto:quae@daurnimator.com">quae@daurnimator.com</a>> wrote:<br>
><br>
> On 7 September 2016 at 01:15, Steve Kille <<a href="mailto:steve.kille@isode.com">steve.kille@isode.com</a>> wrote:<br>
> > Daurnimator,<br>
> ><br>
> > Thanks for your comments.<br>
> ><br>
> >> -----Original Message-----<br>
> >> From: Standards [mailto:<a href="mailto:standards-bounces@xmpp.org">standards-bounces@xmpp.org</a>] On Behalf Of<br>
> >> Daurnimator<br>
> >> Sent: 06 September 2016 09:00<br>
> >> To: XMPP Standards<br>
> >> Subject: Re: [Standards] UPDATED: XEP-0369 (Mediated Information<br>
> >> eXchange (MIX))<br>
> >><br>
> >><br>
> >> Section 5.1.1:<br>
> >> > The channel must process the join atomically.<br>
> >> ...<br>
> >> > If a user cannot be subscribed to one or more of the requested nodes<br>
> >> (e.g., because the node does not exist), but can be subscribed to some the<br>
> >> response simply lists the nodes successfully subscribed. If none of the<br>
> > nodes<br>
> >> requested are successfully subscribed to, and error response is sent<br>
> >> indicating the reason that the first node requested was not subscribed to.<br>
> >><br>
> >> That doesn't sound like atomic to me.<br>
> > [Steve Kille]<br>
> ><br>
> > I corrected typo (and -> an) in this para<br>
> ><br>
> > I think this is atomic.   The rules for processing the request are<br>
> > unambiguous. I can't see what the issue is<br>
><br>
> Atomic means indivisble: that the whole action either fails or<br>
> succeeds as one step; there should be no "partially-worked" outcome.<br>
></p>
<p dir="ltr">I agree this isn't "atomic"; I don't think it's meant to be.</p>
<p dir="ltr">> >> Section 5.1.6:<br>
> >> > Unlike in Multi-User Chat (XEP-0045) [24] where coming online is a<br>
> >> > special action, coming online in MIX is implicit when presence status<br>
> >> > is set<br>
> >><br>
> >> In MUC it didn't have to be; infact, often joining a room was no different<br>
> > to<br>
> >> updating your presence.<br>
> > [Steve Kille]<br>
> ><br>
> > Kevin Smith responded on this point.<br>
><br>
> The <x/> muc element is optional, see<br>
> <a href="https://xmpp.org/extensions/xep-0045.html#enter-gc">https://xmpp.org/extensions/xep-0045.html#enter-gc</a><br>
></p>
<p dir="ltr">The MUC element is optional in the same way that SASL authentication is optional... Joining by sending presence alone is a legacy path.</p>
<p dir="ltr">> >> Section 5.1.15:<br>
> >> The outlined process doesn't allow retrieval of non-current vcards.<br>
> >> IMO historical vcards should be available.<br>
> > [Steve Kille]<br>
> ><br>
> > This sounds quite tricky to achieve.   What entity would you expect to hold<br>
> > vCard history?<br>
><br>
> I'm not sure; however if an entity doesn't have to treat vcards<br>
> differently to 'normal', then I see no reason to mention vcards<br>
> explicity....<br>
></p>
<p dir="ltr">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?</p>
<p dir="ltr">> >> Section 7.1:<br>
> >> Aren't passwords just a multi-use invite token?<br>
> > [Steve Kille]<br>
> ><br>
> > You could think of them like that.   I think the term  "password" gives a<br>
> > sense of security, which is why it is time to drop the mechanism.<br>
><br>
> In that case, the mechanism isn't dropped; just the nomenclature.<br>
><br>
> >>   - How should/can invites be sent to a party that you're not sure<br>
> > supports<br>
> >> MUC vs MIX?<br>
> > [Steve Kille]<br>
> ><br>
> > The MUC and MIX section shows how you can determine if a service supports<br>
> > both.<br>
> ><br>
> > You would need to use lookup of client capability to see which to send.  Do<br>
> > you think this needs documenting in MIX?<br>
><br>
> I'm not sure this is sufficient: how are you to know if a friend's<br>
> client supports MUC vs MIX?<br>
> The only satisfactory answer would be to send both MIX and MUC invites<br>
> (assuming the room is available as both).<br>
> However, the recipient will need to know that the 2 invites they<br>
> receive are for the same room (and hence if they support MIX, the MUC<br>
> invite can be ignored).<br>
> This necessitates that a 'linked muc' (if one exists) should be<br>
> specified *in* a MIX invite.<br>
></p>
<p dir="ltr">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.</p>
<p dir="ltr">> >>   - What if a channel transitions from presence-less to presence-ful?<br>
> > [Steve Kille]<br>
> ><br>
> > I think this just falls out in the wash.   A presence node is added.<br>
> > Client would need to check channel capabilities (seems generally sensible to<br>
> > do from time to time) and react to the change.<br>
></p>
<p dir="ltr">I think this would be horrible. Polling continuously to detect a new node is going to be painful.</p>
<p dir="ltr">> I mean: if a channel turns on presences: you will be missing presences<br>
> in the archive from before it was turned on.....<br>
> Clients will still *want* a presence I think, so they'll end up<br>
> auto-generating a fake one.<br>
> This might be something worth standardising: what to consider as the<br>
> presence if no presence is present.</p>
<p dir="ltr">Clients already have a state displayed for entities in an unknown state - they need this for cases where there's no subscription, etc.</p>
<p dir="ltr">> _______________________________________________<br>
> Standards mailing list<br>
> Info: <a href="https://mail.jabber.org/mailman/listinfo/standards">https://mail.jabber.org/mailman/listinfo/standards</a><br>
> Unsubscribe: <a href="mailto:Standards-unsubscribe@xmpp.org">Standards-unsubscribe@xmpp.org</a><br>
> _______________________________________________<br></p>