moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

Roster Marker

This commit is contained in:
Steve Kille 2017-02-08 11:32:57 +00:00 committed by Sam Whited
parent 528e4d269c
commit f462915ed9
1 changed files with 24 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
xep-0369.xml
View File

@ -45,6 +45,7 @@
Remove Explicit Client Activation and replace with client capability discovery;
Limit Indirect to Join/Leave;
Clarify Server use of Disco of Client;
Add MIX capability information to Roster;
</p></remark>
</revision>
<revision>
@ -2165,14 +2166,14 @@ the participant is not be subscribed to all nodes associated with the channel (i
<section2 topic="Server Identification of MIX Capabable Clients" anchor="server-identification-mix-clients">
<p>
A MIX User's server MUST determine which online clients support MIX. This will enable the server to send MIX traffic to all MIX capable clients. A MIX capable client MAY choose to come online an not advertize MIX capability.
A MIX User's server MUST determine which online clients support MIX. This will enable the server to send MIX traffic to all MIX capable clients. A MIX capable client MAY choose to come online an not advertize MIX capability. The mechanism for a server to discover client capability is described in <link url="#mix-client-discovery">Discovering Client MIX Capability</link>.
</p>
</section2>
<section2 topic="Messages From MIX Channels" anchor="mix-from">
<p>
Messages from a MIX channel will usually go to the participant's server. The only exception to this is where the MIX channel is responding directly to messages from the client. Messages and presence distributed but a MIX channel will always be sent to the participant's server and addressed to the user's bare JID. The participant's server will simply send on the messages from the channel to each of the user's online clients which advertise MIX capability. If there are no such clients activated, the message is dropped. The mechanism for a server to discover client capability is described in <link url="#mix-client-discovery">Discovering Client MIX Capability</link>.
Messages from a MIX channel will usually go to the participant's server. The only exception to this is where the MIX channel is responding directly to messages from the client. Messages and presence distributed but a MIX channel will always be sent to the participant's server and addressed to the user's bare JID. The participant's server will simply send on the messages from the channel to each of the user's online clients which advertise MIX capability. If there are no such clients activated, the message is dropped.
</p>
<p>
Messages sent to the participant's sever will always be addressed to the user's bare JID. The participant’s server will modify the recipient to the full JID of each client to which the message is forwarded. The participant's server MUST NOT make any other modifications to each message. The following example, repeated from earlier, shows a message distributed by a MIX channel and directed to the participant’s server with the participant's bare JID.
@ -2275,14 +2276,32 @@ the participant is not be subscribed to all nodes associated with the channel (i
<section2 topic="Roster Management" anchor="proxy-roster">
<p>
The participant's server is responsible for ensuring that MIX channels are correctly entered into the user's roster. This is provided as a generic client independent service for the user.
The participant's server is responsible for ensuring that MIX channels are correctly entered into the user's roster when user's join MIX channels and for removing them when they leave.
</p>
<p>
The participant's server SHOULD ensure that only presence information from activated MIX clients is sent to the MIX channel. So, if a user has two online clients, but only one is activated for a given MIX channel, then the channel SHOULD only receive presence information relating to the activated client.
The participant's server MUST ensure that only presence information from clients that advertize MIX capability is sent to the MIX channel. So, if a user has two online clients, but only one is MIX capable, then the channel will only receive presence information relating to the MIX client.
</p>
</section2>
<section2 topic="MIX Roster Item Capability Sharing" anchor="mix-roster-capability-sharing">
<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>
<example caption="Standard Roster Item Encoding"><![CDATA[
<item jid='romeo@example.net'/>
]]></example>
<p>
In order to present channels usefully to the end user a client MAY disco the domain of a roster entry to discover if it is a MIX service. As MIX services MUST NOT support end users, this information MAY be cached help the client distinguish MIX channels in the roster.
MIX channels in the roster have an attribute 'channel' set to true.
</p>
<example caption="Roster Item Encoding of a MIX Channel"><![CDATA[
<item jid='romeo@example.net'/ channel='true' xmlns='urn:xmpp:mix:0'/>
]]></example>
<p>
When sending roster information to a client that advertises MIX capability, the server MUST return all MIX channels and MUST use this encoding. Where a client does not advertize MIX capability, the server MUST NOT return MIX channels as roster items.
</p>
</section2>
<section2 topic="MAM Archive Support" anchor="proxy-mam">