<p>It will be useful for a MIX client to know which roster members are MIX channels, as this will facilitate convenient presentation of subscribed MIX channels to the user. A standard roster item is encoded as follows.</p>
<p>It is useful for a MIX client to know which roster members are MIX channels, as this will facilitate convenient presentation of subscribed MIX channels to the user. A standard roster item is encoded as follows.</p>
MIX channels in the roster have an attribute 'channel' set to true.
MIX channels in the roster have an empty element 'channel' included in the roster item.
</p>
<examplecaption="Roster Item Encoding of a MIX Channel"><![CDATA[
<itemjid='romeo@example.net'>
<itemjid='balcony@example.net'>
<channelxmlns=‘urn:xmpp:mix:0'/>
</item>
]]></example>
<p>
A server following the MIX specification MUST determine whether or not a client supports MIX. The server will often have this information prior to the roster request, due to &xep0115; Entity Capabilities. If the server does not have this information it MUST use service discovery to determine it before providing roster information.
When sending roster information to a client that advertises MIX capability, the server MUST return all MIX channels and MUST use this encoding. Presence of MIX roster items MUST be set to offline (unavailable).
</p>
@ -2542,6 +2544,9 @@ This approach enables flexible support of multiple clients for a MIX channel pa
Where a client does not advertise MIX capability, the server MAY choose to not return MIX channels as roster items. If this is done care needs to be taken, in particular around support of roster versioning &xep0237;.
</p>
<p>
When a server determines that a client has added or removed MIX capability, the entire roster MUST be sent and roster version reset. This is not a particularly efficient approach, but this is expected to be a rare event and so a simple approach is preferred.