Daurnimator, Thanks for your comments.
> -----Original Message----- > From: Standards [mailto:[email protected]] On Behalf Of > Daurnimator > Sent: 06 September 2016 09:00 > To: XMPP Standards > Subject: Re: [Standards] UPDATED: XEP-0369 (Mediated Information > eXchange (MIX)) > > > Section 3: > > Each participant is addressable by a single bare JID, which is a proxy JID (not > the user's real JID) to make it straightforward to hide the user's real JID from > other channel participants. Full JIDs comprised of this bare JID plus a resource > are then constructed, allowing visibility into the number of online resources > participating in a channel. > > Are the resources of full jids masked too? > If not, it could be easy to figure out who a user is by their > (relatively) unique resource. [Steve Kille] Yes. I have added a couple of words at this point to make this clear. > > 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 > > Section 5.1.2: > > AUTHOR'S NOTE AND QUESTION: Dave Cridland has suggested. I would > prefer: a) User options be sent in the initial join/>. b) Unknown options are > ignored. c) User options can be requested (as a form). If clients require an > option to be supported, they should request the form. > > This suggestion sounds good to me. [Steve Kille] Noted. I'd welcome other views on this, as we do need to make a choice on the details of the mechanism here. I can see merits in both approaches. > > Section 5.1.3: > > leaving the channel is a permanent action for a user across all > > clients, not just a matter of telling the channel that the user is not > > currently available or for a single client > > How can a user opt out of receiving messages on one of their (many) > resources? [Steve Kille] The next version of MIX will address this > > 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. > > Section 5.1.11: > > AUTHOR NOTE AND QUESTION: Message id coming back is different in > example. This is because the reflected message uses MAM ID, which seems > helpful. However, it makes it harder for sender to correlate reflections. Need > to be explicit as to compliant behaviour. Input as to whether the ID should > change is solicited. A more complex option would be to include both IDs in > some way. > > Client generated ids cannot be trusted to be unique (or conforming to > whatever some arbitrary server considers an acceptable mam message id) [Steve Kille] That is right. You cannot use the client generated ID as the MAM ID. However, I don't think this answers the question > > 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 think there would need to be a quite compelling use case to justify adding this. > > 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. Multi-invite token feels less of a problem. Is there really a requirement/use case? > > Other: > - Declines are not specified; this was an important MUC feature to me. [Steve Kille] I've added a short note on this as an editing reminder. It seems a sensible feature to include, assuming it comes out cleanly. > - 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? > - 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. Thanks for your comments [Steve Kille] I have pushed the changes noted Steve _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
