mirror of https://github.com/moparisthebest/xeps
Steve Kille
Sam Whited
parent
9ef9c942c7
commit
4cf4d0b8e0
54
xep-0369.xml
54
xep-0369.xml
|
|
@ -263,9 +263,9 @@
|
|||
</p>
|
||||
</section2>
|
||||
<section2 topic="Standard Nodes" anchor="concepts-nodes">
|
||||
<p>The standard nodes are as follows (although note that not every channel will necessarily use each node):</p>
|
||||
<p>MIX defines a number standard nodes are as follows (although note that not every channel will necessarily use each node):</p>
|
||||
|
||||
<table caption="Standard Nodes">
|
||||
<table caption="Standard MIX Nodes">
|
||||
<tr><th>Name</th><th>Node</th><th>Description</th></tr>
|
||||
|
||||
<tr><td>Messages</td><td>'urn:xmpp:mix:nodes:messages'</td><td>For publishing messages. Each item of this node will contain a message sent to the channel.</td></tr>
|
||||
|
|
@ -278,7 +278,7 @@
|
|||
|
||||
<tr><td>Presence</td><td>'urn:xmpp:mix:nodes:presence'</td><td>For publishing information about the availability status of online participants, which may include multiple clients for a single participant.</td></tr>
|
||||
|
||||
<tr><td>Information</td><td>'urn:xmpp:mix:nodes:info'</td><td>For storing general channel information, such as description and avatar. </td></tr>
|
||||
<tr><td>Information</td><td>'urn:xmpp:mix:nodes:info'</td><td>For storing general channel information, such as description. </td></tr>
|
||||
|
||||
<tr><td>Allowed</td><td>'urn:xmpp:mix:nodes:allowed'</td><td>For storing JIDs that are allowed to be channel participants.</td></tr>
|
||||
|
||||
|
|
@ -292,8 +292,18 @@
|
|||
All of the standard nodes are optional. A channel providing a service similar to MUC will typically use all of the standard nodes.
|
||||
MIX provides mechanisms to allow users to conveniently subscribe to a chosen set of nodes and to unsubscribe to all nodes with a single operation.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
The structure of each of the standard nodes is now considered in more detail in the rest of this section, after explaining roles.
|
||||
MIX also makes use of two nodes for support of Avatars. These nodes and their use is defined in &xep0084;. These nodes may be created as part of a MIX channel, where it is desired to publish an avatar associated with the channel.
|
||||
</p>
|
||||
|
||||
<table caption="MIX Nodes for Avatar Support">
|
||||
<tr><th>Name</th><th>Node</th><th>Description</th></tr>
|
||||
<tr><td>Avatar Data</td><td>'urn:xmpp:avatar:data'</td><td>For publishing an Avatar</td></tr>
|
||||
<tr><td>Avatar Metadata</td><td>'urn:xmpp:avatar:metadata'</td><td>For publishing Avatar metadata</td></tr>
|
||||
</table>
|
||||
<p>
|
||||
The structure of each of the standard nodes defined by MIX is now considered in more detail in the rest of this section, after explaining roles.
|
||||
</p>
|
||||
<section3 topic="Roles" anchor="roles">
|
||||
<p>
|
||||
|
|
@ -395,8 +405,6 @@
|
|||
<li>'Description'. A longer description of the channel.</li>
|
||||
|
||||
<li>'Contact'. The JID of the person or role responsible for the channel. This MAY be the JID of a MIX channel.</li>
|
||||
|
||||
<li>'Avatar'. An Avatar associated with the channel. This MAY be used in rosters that hold information on the channel and MAY be displayed by clients using the channel. The avatar is stored using the base 64 encoded format defined in &xep0084;</li>
|
||||
|
||||
</ul>
|
||||
|
||||
|
|
@ -419,9 +427,6 @@
|
|||
<field var='Contact'>
|
||||
<value>greymalkin@shakespeare.lit</value>
|
||||
</field>
|
||||
<field var='Avatar'>
|
||||
<value>base64-encoded-data</value>
|
||||
</field>
|
||||
</x>
|
||||
</item>
|
||||
</items>
|
||||
|
|
@ -475,7 +480,7 @@
|
|||
|
||||
<tr><td>'End of Life'</td><td>The date and time at which the channel will be automatically removed by the server. If this is not set, the channel is permanent.</td><td>text-single</td><td>-</td><td>-</td></tr>
|
||||
|
||||
<tr><td>'Nodes Present'</td><td>Specifies which nodes are present. Presence of config nodes is implicit. Jidmap node MUST be present if participants node is present.</td><td>list-multi</td><td>'participants'; 'presence'; 'subject'; 'information'; 'allowed'; 'banned'</td><td>-</td></tr>
|
||||
<tr><td>'Nodes Present'</td><td>Specifies which nodes are present. Presence of config nodes is implicit. Jidmap node MUST be present if participants node is present. 'avatar' means that both Avatar Data and Avatar Metadata nodes are present.</td><td>list-multi</td><td>'participants'; 'presence'; 'subject'; 'information'; 'allowed'; 'banned'; 'avatar'</td><td>-</td></tr>
|
||||
|
||||
<tr><td>'Message Node Subscription'</td><td>Controls who can subscribe to messages node.</td><td>list-single</td><td>'participants'; 'allowed'; 'anyone'</td><td>'participants'</td></tr>
|
||||
|
||||
|
|
@ -495,12 +500,19 @@
|
|||
|
||||
<tr><td>'Information Node Update Rights'</td><td>Controls who can make changes to the information node</td><td>list-single</td><td>'participants'; 'admins'; 'owners' </td><td>'admins'</td></tr>
|
||||
|
||||
|
||||
<tr><td>'Avatar Nodes Update Rights'</td><td>Controls who can make changes to the avatar data and metadata nodes</td><td>list-single</td><td>'participants'; 'admins'; 'owners' </td><td>'admins'</td></tr>
|
||||
|
||||
|
||||
<tr><td>'Kick Rights'</td><td>Controls who can kick users from the channel.</td><td>list-single</td><td>'admins'; 'owners'; 'nobody' </td><td>'admins'</td></tr>
|
||||
|
||||
<tr><td>'JID Visibility'</td><td>Controls JID visibility in the channel.</td><td>list-single</td><td>'jid-hidden'; 'jid-optionally-visible'; 'jid-mandatory-visible'</td><td>'jid-hidden'</td></tr>
|
||||
|
||||
<tr><td>'Open Presence'</td><td>If selected, any client may register presence. If not selected, only clients with bare JID in the participants list may register presence.</td><td>boolean</td><td>-</td><td>false</td></tr>
|
||||
|
||||
<tr><td>'Participants Must Provide Presence'</td><td>If selected, all channel participants are required to share presence information with the channel.</td><td>boolean</td><td>-</td><td>false</td></tr>
|
||||
|
||||
|
||||
<tr><td>'Allow Message Retraction</td><td>If this option is selected users will be able to retract messages sent to the MIX channel.</td><td>boolean</td><td>-</td><td>false</td></tr>
|
||||
|
||||
<tr><td>'Participation Addition by Invitation from Participant'</td><td>This option extends a channel so that a channel participant has rights to invite and enable other users as participants.</td><td>boolean</td><td>-</td><td>false</td></tr>
|
||||
|
|
@ -702,9 +714,6 @@
|
|||
<field var='Contact'>
|
||||
<value>greymalkin@shakespeare.lit</value>
|
||||
</field>
|
||||
<field var='Avatar'>
|
||||
<value>base64-encoded-data</value>
|
||||
</field>
|
||||
</x>
|
||||
</query>
|
||||
</iq>
|
||||
|
|
@ -837,9 +846,6 @@ the participant is not be subscribed to all nodes associated with the channel (i
|
|||
</message>
|
||||
]]></example>
|
||||
<p>The user that has been added to the channel is identified by the item id of the item added to the pubsub node, which is the proxy JID of the new channel participant. Each <participant> element will include the nick of the user being added, which will be how the user will typically be shown in the channel.</p>
|
||||
<p>
|
||||
Following the MIX server side processing, the user's server will usually add the MIX channel to the user's roster using one way presence. This means that the MIX channel will get presence information from the user. This roster entry will lead to correct handling of the user's presence in the MIX channel. If the user does not wish to publish presence and the channel permits this, then this roster addition does not happen. If the channel requires presence and the user removes the channel from the user's roster, the channel MAY remove the user as a channel participant.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
A user may subsequently modify subscription to nodes in a channel by sending a subscription modification request, as shown in the following example.
|
||||
|
|
@ -865,6 +871,22 @@ the participant is not be subscribed to all nodes associated with the channel (i
|
|||
</iq>
|
||||
]]></example>
|
||||
</section3>
|
||||
|
||||
|
||||
<section3 topic="Roster Management" anchor="usecase-roster-management">
|
||||
|
||||
<p>
|
||||
After the user has jointed the channel, the user's MIX Proxy MAY add the MIX channel to the user's roster using standard XMPP to update the roster. This is done to share the user's presence status with the channel and so the MIX channel will get presence information from the user. This roster entry will lead to the user's server correctly sending user's presence from all clients to the MIX channel. The roster subscription is configured with one way presence, as presence is sent to the MIX channel but no presence information is sent about the MIX channel. The user's MIX Proxy MUST remove this roster entry after the user leaves the channel.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
If the user does not wish to publish presence information to the channel, the user will not add the roster entry. A channel may require presence to be provided by all channel participants, which is controlled by the 'Participants Must Provide Presence' option. The channel MAY check that channel participants have done this and MAY remove participants that do not do this.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
A channel MAY publish an Avatar following &xep00084;. A client MAY make use of this information to associate an Avatar with the roster entry for a channel.
|
||||
</p>
|
||||
</section3>
|
||||
|
||||
<section3 topic="User Preferences and Additional Information" anchor="usecase-visibilty-pref">
|
||||
<p>A channel MAY store user preferences and parameters with each user. There are two preference options.
|
||||
|
|
|
|||
Loading…
Reference in New Issue