1
0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-25 10:42:19 -05:00

Add MIX Channels in Roster Section;

This commit is contained in:
Steve Kille 2018-05-04 11:05:27 +01:00
parent 26cac6d2ce
commit d03530b2ac

View File

@ -48,7 +48,7 @@
Clarify Mandatory Presence; Clarify Mandatory Presence;
Clarification of MIX annotation of roster updates; Clarification of MIX annotation of roster updates;
Flag that section 6.3 (Ensuring Message Delivery) needs review; Flag that section 6.3 (Ensuring Message Delivery) needs review;
Add MIX Channels in Roster Section;
</p></remark> </p></remark>
</revision> </revision>
<revision> <revision>
@ -420,6 +420,18 @@
<section2 topic="MIX and MAM" anchor="concepts-mam"> <section2 topic="MIX and MAM" anchor="concepts-mam">
<p> Historical data (such as the messages sent to the channel) is stored in an archive supporting Message Archive Management (MAM) so that clients can subsequently access this data with MAM. Each node can be archived separately (e.g., the presence node or the configuration node). MIX messages are archived by both the MIX channel and the user's server, so that clients can generally use their local MAM archiver. MIX clients can retrieve archived information with MAM in order to quickly resync messages with regard to a channel, and can do so without providing presence information.</p> <p> Historical data (such as the messages sent to the channel) is stored in an archive supporting Message Archive Management (MAM) so that clients can subsequently access this data with MAM. Each node can be archived separately (e.g., the presence node or the configuration node). MIX messages are archived by both the MIX channel and the user's server, so that clients can generally use their local MAM archiver. MIX clients can retrieve archived information with MAM in order to quickly resync messages with regard to a channel, and can do so without providing presence information.</p>
</section2> </section2>
<section2 topic="MIX Channels in Roster" anchor="concepts-roster">
<p>
When a user joins a MIX channel, the channel is included in the user's roster. There are two reasons for this.
</p>
<ol>
<li>It enables a client to determine which channels the user has joined and so may expect messages and/or presence updates from (dependent on what the user has subscribed to).</li>
<li>
When the user has chosen to share presence with the channel, it enables this to happen using standard presence mechanisms. This avoids the need for MIX-specific mechanisms for clients to update presence on a channel. When a client comes online, presence information will be sent to each MIX channel that the user participates in. This will update other channel participants. It will also lead to a presence update for each MIX channel being sent to the client. So a user will receive channel presence information as the user comes online, in contrast to being subsequent to a MUC Join.
</li>
</ol>
</section2>
<section2 topic="Behaviour of MIX Participant's Server" anchor="concepts-mix-participant-server"> <section2 topic="Behaviour of MIX Participant's Server" anchor="concepts-mix-participant-server">
<p> <p>
A MIX channel does not send messages and presence directly to the MIX client of a channel participant, but addresses them to the participant using the participant's bare JID. The participant's server MUST then handle these messages and pass them on to zero, one or multiple clients. To enable MIX to work, this behaviour is necessary and so the server of every MIX client MUST follow the rules set out in this specification. A MIX channel does not send messages and presence directly to the MIX client of a channel participant, but addresses them to the participant using the participant's bare JID. The participant's server MUST then handle these messages and pass them on to zero, one or multiple clients. To enable MIX to work, this behaviour is necessary and so the server of every MIX client MUST follow the rules set out in this specification.