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

Steve Kille steve.kille at isode.com
Tue Sep 6 15:15:39 UTC 2016


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




More information about the Standards mailing list