[Standards] XEP-0369 (MIX) Feedbacks and proposals

Steve Kille steve.kille at isode.com
Fri Dec 2 08:47:04 UTC 2016




Thanks for this input.    I’m delighted to see this, as I think that implementer review and input is key to moving MIX forward.


Let me go over your comments.


From: Standards [mailto:standards-bounces at xmpp.org] On Behalf Of edhelas
Sent: 30 November 2016 11:48
To: standards at xmpp.org
Subject: [Standards] XEP-0369 (MIX) Feedbacks and proposals


Hi everyone,

I'm currently planning to implement MIX in Movim in the upcoming months. I have a few remarks to do regarding the current XEP (v0.5) and some proposals to do.

4.1 Example 9, typo in the title

[Steve Kille] 

Fixed.   Annoying that oXygen spell check did not catch this.


4.5 Determining Information about a Channel : Is it possible to standardize the fields of the Channel Information? Using mix#name, mix#description and mix#contact for example?

[Steve Kille] 

I am keen that we keep the number of ways to access types of information down to a minimum (one approach in most cases).   I’m advised that XEP-0004 forms is the preferred approach (the XMPP way) for extensible data.      I’m not a big fan of 0004, but I think it works fine.

The standardized attributes for the information object are defined in 3.7.7, which enables easy automation of access to standard attributes.  I think this suffices.


5.1.1 Joining a Channel : What are the nodes to join to be added automatically to "urn:xmpp:mix:nodes:participants", any of them? If I only join "urn:xmpp:mix:nodes:participants" or "urn:xmpp:mix:nodes:subject" will I still be counted as a participant? The standard should be more precises here to be sure that we have a consistent implementation in the servers and clients.

[Steve Kille] 

5.1.1.  says “There is no default set of nodes, so user MUST specify the set of nodes to be subscribed to.”, which I think is clear.

The function of each node is described in 3.7.   The nature of Participants (which are optional) can be best understood from the roles description in 3.7.1.


Also XEP-0060: Pubsub-Subscribe is using the <subscribe> tag here. Is it not better to re-use it instead of <join> to be more consistent?

[Steve Kille] 

The action is “join a channel” and I think it makes sense to have the element match this.   Subscribing to various nodes is part of the joining process, but I think it is more than just a pubsub subscribe action.


5.1.3 User Preferences and Additional Information : Same as 4.5, we should standardize the fields (mix#jid_visibility, mix#private_messages, mix#vcard and mix#presence)

[Steve Kille] 

Same response as for 4.5.   The XEP-0004 standard values are clearly specified in Table 7.


5.1.6 Registering a Nick : Should we add an example for the result of the Example 36.? (<feature var="mix_nick_register"/>)

[Steve Kille] 

That’s a sensible idea.   Example added.


5.1.12 Sending a Message : I'm planning to publish Atom entries (like in XEP-0277: Microblogging) using MIX, how does this works here? The IDs management seems quite confusing, is it not better to reuse XEP-0359: Unique and Stable Stanza IDs that was made for that?


[Steve Kille] 

I’ve tweaked the words a bit to improve clarity.

The key point is that distributed messages use the MAM ID.   This was a key decision from XMPP summit at the start of this year.   Any change to this would need broad discussion.    I think that it is important that these IDs are unique/stable, but this is something for MAM (not MIX) to specify.

The sending client  picks the original ID.  MIX provides a mechanism to enable the sender to correlate the distributed message.   I don’t think there is a reason for MIX to put any particular constraints on this ID.


5.1.3 User Preferences and Additional Information : Example 31, is it not better to use this form to set/register the User nickname instead of using 5.1.6 Registering a Nick? It will simplify the implementation and we can use 

[Steve Kille] 

5.1.3 is per channel and 5.1.6 is per MIX service, so they need separate mechanisms.


5.1.14 Setting the Channel Subject : Why are we using <subject> here? This looks like a relic from XEP-0045: Multi-User Chat. Here I'm proposing to simply set the subject using the "urn:xmpp:mix:nodes:info" node with a mix#subject field

[Steve Kille] 

I think that subject needs to be on a separate node.   The access control plan is that granularity is per node, so you group things which you want to have the same access control.   I’d expect the info node to be controlled by a channel administrator.   Subject may well be settable by any participant.

The radical change for Subject would be to drop it altogether.   I think it makes more sense to use threads in a channel, rather than have a “global” subject.

However, MIX is (currently) taking the conservative approach of retaining subject, as it is in 0045.    It is not hard to include this, and easy to not use if where it is not desired (simply create a channel without a subject node).    Using protocol compatible with XEP-0045 seems a simple approach.


5.1.18 Requesting vCard : I'd definitely not recommend to use vcard-temp here but more XEP-0292: vCard4 Over XMPP


[Steve Kille] 

MIX is just relaying vCard requests.   I think it makes sense to support both vcard-temp, which is widely used and 292, which is seen as a future direction.

Specification updated.

5.5.2 Creating a Channel : Example 62. Same as 4.5, standardize the fields (mix#owner, mix#message_node_subscription, mix#jid_visibility, mix#no_private_message). 

[Steve Kille] 

Answer as for 4.5

Also in this example theres two Owner fields, is it a bug or a feature? :p

[Steve Kille] 

The example is correct.  If you look at Table 6 (3.7.10),  this field is specified as jid-multi


In XEP-0060: Publish-Subscribe we used a <configure> node as a wrapper for the creation/configuration of pubsub nodes (see Example 133. or the 0060). It's not the case here (see Example 62.), can this be considered as an inconsistency?


[Steve Kille] 

It is clearly inconsistent.    

The XML here was what I considered sensible.   I dislike the verbiage that 0004 gives, and would prefer to avoid more wrapping.    

However, I will be happy to follow whatever guidance is given by XMPP experts here.    It is not clear to me what the right approach is here.

5.5.5 Destroying a Channel : we are using the <destroy> keyword here, 0060 is using <delete>. Is this also an inconsistency?

[Steve Kille] 

As for Joining,  I think that the MIX description and keyword should match.    As the MIX level action is more than  just some 0060 actions,  I think there is benefit to different terminology.

5.5.7 Modifying Channel Information and 5.5.8 Modifying Channel Configuration, I'm not really fond of using <config> and <info> to get/set "urn:xmpp:mix:nodes:info" and "urn:xmpp:mix:nodes:config" or we need to define those "shortcuts" somewhere. What about the extensibility (if I want to add a "urn:xmpp:mix:nodes:location" for example)? Will it not be better to use the same XML structure that we are already using in Pubsub/PEP? 

<iq from='juliet at capulet.lit/balcony' to='coven at mix.shakespeare.example' type='set' id='pub1'>
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
    <publish node='urn:xmpp:mix:nodes:config'>
       <x xmlns='jabber:x:data' type='form'>
        <field var='FORM_TYPE' type='hidden'>
[Steve Kille] 
This is VERY sensible.   I should have done it this way!     I’ve updated the spec.

I'll maybe have other feedbacks to give soon but I'm open to talk about those ones first :)


Timothée Jaussoin 

[Steve Kille] 

Thanks for all this feedback.   I will share updates shortly.






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20161202/a6bddc03/attachment-0001.html>

More information about the Standards mailing list