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

Jonas Wielicki jonas at wielicki.name
Mon Feb 20 06:23:34 UTC 2017


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

Steve,

On Montag, 20. Februar 2017 03:32:37 CET Steve Kille wrote:
> Thanks for the responses.

Thanks for taking care of them. For the record, MIX already reads a lot better 
to me than half a year ago when I first took a (very brief) look into it :-).

> > § 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.
> 
> [Steve Kille]
> 
> I see this as a clear statement of what is going on.   What is unclear about
> this?

I was combining a few quotes and formulating a question on all of those later 
on, which you answered. No worries.

> > 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?
> 
> [Steve Kille]
> 
> The repeated field is jid-multi.   Surely you can just repeat this?   I
> can't see otherwise how jid-multi wold be encoded.   Have I missed
> something here?

The correct way to encode multiple jid-multi values is:

    <field var="foo" type="jid-multi">
        <value>ab at cd.e</value>
        <value>fg at hi.j</value>
    </field>

Thanks!
Jonas
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEG/EPV+Xzd5wEoQQIwGIDJZdiWIoFAliqi2YACgkQwGIDJZdi
WIpLNQ/9E3X//DyegWgd9P7lxFM+2QjN6uDhxBnXdJhPoJhS3y1WSzQJg8s/Tda4
9QVffn3VlqpzQdKoZiRn3vPzznwbz723+rWlV8CxMgG7m34tEZL7WVG9yfs28xT4
MNJ7WOjMs/ffGmcdz3R9I1yBs1qgiA7ncZEscD2i8DRhJw8E5u2GkPGmipWfj1Ba
hdYA9G9QFcUvMV6K6HNibWPDUyFsf8FMQx0vuU58vTvV2fAyW9ff6wdWqvfUgaYc
r45XT9HBixKf2GAwMcJVx1YrWT6swUtRKbP5tFOKoCA9dZ00j+BSyDNb4keL/pkg
eGE+6nz8iQIRfN21gV1+84LAatz81cj/YMcIVxlgTdcVG3EJ8zLrT7sa+JWBfvrR
LkuNHIlZxR0FNMt1lxp591NyFa3Id1kghS2dRVt3i30tOqwLfgJ+FYeXVpmOFH4o
p85z/5P64ubB/wHokKiahhS7VZ9PIY3FP1DsKtVFZKQJSqtQCMACRMS6lEjzsNOr
OxzFTKTS7YiO46zyfHm6bbn+YWORx63tGyHvI86QVaJ4ptW34+TBD7f1Eq1WcHcE
4F0xZDvirCLArxtd4bMNwKTVOlRjUEEoX6hClVjc5Cw6RoXSZDAP42vdGegok916
04m2ub712JkidY6Ji2KB9cSekXKPUp38i1v96YjWA4sAjNSWdhk=
=MABw
-----END PGP SIGNATURE-----



More information about the Standards mailing list