> >> 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 _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
