[Standards] MIX (XEP-0369) post-summit update to 0.8

Jonas Wielicki jonas at wielicki.name
Thu Feb 16 19:51:09 UTC 2017


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hey Steve,

I’m new to MIX and new in the XSF, so please bear with me if I’m raising 
things which have been discussed already. In that case it would be great to 
have rationale in the XEP.

Steve, you also should have gotten a mail directly addressed to you with some 
minor language nitpicks with which I didn’t want to clutter the mailinglist.


I’m having trouble with § 3.9.7 and Example 4. The text says:

> The name and description values MUST contain a "text" element and MAY 
> contain additional text elements. Where multiple text elements are provided, 
> each MUST posses an xml:lang attribute that describes the natural language 
> of the element. The format of the Information node follows Data Forms 
> (XEP-0004) [9].

I’m not sure how that would look like, and it would be nice to have an example 
of that. From my reading of XEP-0004, there is no such thing as multiple text 
values (even with distinct xml:lang attributes) for text-single fields.


Aside: Is Example 21 (§ 5.7) actually legal (or required…)? The <query/> in 
there response has a different node than the <query/> in the request ...


§ 6.1.2 and also § 6.1.3: I don’t quite understand the roster management at 
place there yet. There is (in § 6.1.2):

> As part of the channel joining process, the user's server MAY add the MIX 
> channel to the user's roster using standard XMPP to update the roster.

and later:

> As part of the channel joining process, the user's server MAY add the MIX 
> channel to the user's roster using standard XMPP to update the roster.

In § 6.1.3 there’s also:

> The user MAY specify that presence is not to be shared, which will prevent 
> the MIX Channel from sending a presence probe for the user on channel start-
> up. The user will also choose to not include the MIX channel in the user's 
> roster, so that presence will not be updated.

How exactly does the user choose whether or not to include the MIX channel in 
the roster? Is this only controlled by the data form sent while joining?

Also, is there a way to have such a MIX channel in the roster with 
subscription="none" state? I find this more sensible than not adding the MIX 
at all; this would allow clients to query the list of MIX channels from a 
single place to show the currently joined MIX channels to the user.


I just now saw the new {urn:xmpp:mix:0}feature elements in the disco#info. Are 
these really necessary? It seems to introduce a new element for the job an 
existing element is doing "just fine". This complicates handling of disco#info 
replies. Maybe a middle-ground would be to use the {namespace}local-name 
notation for the @var attribute, like this:

    <feature var="{urn:xmpp:mix:0}mix_nick_register" />

(one could also drop the mix_ prefix of the right hand side right away)


In § 6.1.16, I would like additional language which specifies that the inviter 
MUST ensure that the invitee actually supports MIX, e.g. via disco.


In § 6.3.:
> When the MIX channel detects a failure it will make use of an IQ Marker 
> message to determine when the connection to the peer server is working 
> again. Once the channel has received a response to the marker IQ it will 
> retransmit the pending messages. 

What’s wrong with simply reusing XEP-199 (XMPP Ping)?


Is the usage of XEP-0004 in Example 64 (§ 6.5.2) and also earlier in Example 7 
valid? XEP-0004 states: "If the <field/> element type is anything other than 
"fixed" (see below), it MUST possess a 'var' attribute that uniquely 
identifies the field in the context of the form (if it is "fixed", it MAY 
possess a 'var' attribute).". This sounds as if no two fields may have the 
same @var, which is clearly violated in the examples. Those should be jid-
multi fields with multiple <value/>s, right?


Thanks for your work on this! 

best regards,
Jonas
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEG/EPV+Xzd5wEoQQIwGIDJZdiWIoFAlimAq0ACgkQwGIDJZdi
WIoW9Q/+OdEPtuenZUYorUC9CAYhgh9Up6WyY6CKZ926TYW/guuMfr1LXMpIl30K
l9CsnU+TEZCMDaPcQimMFAyksloy3/K5pMF9spnFecGQfaO9RLoM8WaN1DiiTUsC
gMuWspI4NYGVnmsidBkbvtqAfH6BotyjheQ3vbCsaVugtPER5KonyF4bbzaJqklV
91vvjhZnF6zrx3A1q6Q/Khracsa34LxB8anE0DdDn95vZa781DHNgsZQOP/Tlt0j
3nfPpKM3TVYeX1cyIHBbl5H+NZhdyCtAWtbuRB3pxtDe0qBYjaVlEzLrW2B5RpAh
1VjgyPaWVqNZo8/EvAFFGJqIL8ZsQMr+Ehsj4YdM3h1b40dX0x3+stIh8mP7BXOE
ci3OqvoerXOruR4lS30egFqJxB3+xEZbnIM6G/PGFeSDisPpbV8aDFQYmqCFR3Ck
mKMuzTxMkHfo9Vd4/pKGmRBpS+bxgB/wINayvg1iR25zllxXZuz3yfMW1JojiXxT
7t1UtBxxQht3QWMGy7A8M+qzYwKo5fKVrNTAEoIIETF4RedKg8cHzPzilJwBpaHy
zGfTdg5bznpvS2l7hFbQnbOibHVJK1245/SK5msRcBnDMeqnXX0x/2A/nk54ZDxh
6ssDqk9382QTtcnndgCJLUKuFTvW0+rfI0zfEffGmf7tGrU9IaA=
=VkbR
-----END PGP SIGNATURE-----



More information about the Standards mailing list