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