moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 15:18:51 -05:00
Code Issues Releases Wiki Activity

Fixes to Node Type

Browse Source
This commit is contained in:
Steve Kille 2017-02-09 08:20:08 +00:00 committed by Sam Whited
parent 3dff15fcba
commit 8b72a34cdc
1 changed files with 15 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
xep-0369.xml
View File

@ -407,8 +407,14 @@ This approach enables flexible support of multiple clients for a MIX channel pa
There will always be at least one owner and "anyone" will always have role occupants. Other roles MAY NOT have any role occupants. Rights are defined in a strictly hierarchical manner, so that for example Owners will always have rights that Administrators have.
</p>
</section3>
<section3 topic="Node Archiving" anchor="node-archiving">
<p>
Nodes MAY be archived and where this is done MAM MUST be used. Archiving of the Messages node MUST be done as part of the MIX specification. Archiving of other nodes is OPTIONAL.
</p>
</section3>
<section3 topic="Messages Node" anchor="messages-node">
<p>Items in this node will contain a message identified by the MAM ID used for the message in the channels MAM archive. &xep0313; rules MUST be used to ensure this ID is unique. A MIX implementation SHOULD NOT make messages available for retrieval from this node using pubsub and MUST NOT allow direct pubsub publishing to this node. Messages are published by sending messages to the channel. The Messages node is a transient node and so there is no PubSub history. Message history is retrieved by use of MAM. Users subscribe to this node to indicate that messages from the channel are to be sent to them.</p>
<p>Items in this node will contain a message identified by the MAM ID used for the message in the channels MAM archive. &xep0313; rules MUST be used to ensure this ID is unique. A MIX implementation SHOULD NOT make messages available for retrieval from this node using pubsub and MUST NOT allow direct pubsub publishing to this node. Messages are published by sending messages to the channel. The Messages node is a transient node and so no PubSub items are held. Message history is retrieved by use of MAM. Users subscribe to this node to indicate that messages from the channel are to be sent to them.</p>
<p>Private Messages are not stored in the messages node.</p>
</section3>
@ -419,7 +425,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
When a user joins a channel, the user's bare JID is added to the participants node by the MIX service. When a user leaves a channel, they are removed from the participants node. The participants node MUST NOT be directly modified using pubsub.
This node MAY be subscribed to for jid-visible channels that permit subscription to this node - this will allow users to see changes to the channel participants.
</p>
<p>The participants node is OPTIONAL. If the Participants Node is not used, information on channel participants is not shared. If there is no participants node, the access control value 'participants' MUST NOT be used. The Participants node is a permanent node and PubSub history MAY be stored.</p>
<p>The participants node is OPTIONAL. If the Participants Node is not used, information on channel participants is not shared. If there is no participants node, the access control value 'participants' MUST NOT be used. The Participants node is a permanent node with one item per participant.</p>
<example caption="Value of Participants Node"><![CDATA[
<items node='urn:xmpp:mix:nodes:participants'>
<item id='coven+123456@mix.shakespeare.example'>
@ -433,7 +439,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<p>The JID Map node is used to associate a proxy bare JID to its corresponding real bare JID. The JID Map node MUST have one entry for each entry in the Participants node. This value is added when a user joins the channel and is removed when the user leaves the channel.
Each item is identified by proxy bare JID, mapping to the real bare JID. This node is used to give administrator access to real JIDs and participant access to real JIDs in jid-visible channels. This node MUST NOT be modified directly using pubsub.
In JID visible channels, all participants MAY subscribe to this node. In JID hidden channels, only administrators can subscribe. The JID MAP node is a permanent node and PubSub history MAY be stored.</p>
In JID visible channels, all participants MAY subscribe to this node. In JID hidden channels, only administrators can subscribe. The JID MAP node is a permanent node with one item per participant.</p>
<example caption="Value of JID Map Node"><![CDATA[
<items node='urn:xmpp:mix:nodes:jidmap'>
<item id='coven+123456@mix.shakespeare.example'>
@ -449,7 +455,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</p>
<p>
This node MAY be subscribed to by users and this subscription MUST use the users bare JID. So presence of online clients is sent to the user's server for each user subscribed to this node. Presence is always sent using standard presence protocol and NOT using pubsub protocol. Clients MUST NOT directly access the presence node using pubsub. The Presence node is a transient PubSub node.
This node MAY be subscribed to by users and this subscription MUST use the users bare JID. So presence of online clients is sent to the user's server for each user subscribed to this node. Presence is always sent using standard presence protocol and NOT using pubsub protocol. Clients MUST NOT directly access the presence node using pubsub. The Presence node is a permanent PubSub node.
</p>
<example caption="Value of Presence Node"><![CDATA[
<items node='urn:xmpp:mix:nodes:presence'>
@ -464,8 +470,8 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</section3>
<section3 topic="Information Node" anchor="info-node">
<p>The Information node holds information about the channel. The information node contains a single item with the current information. Information node history is RECOMENDED to be held in MAM.
The information node is named by the date/time at which the item was created. The information node is accessed and managed using standard pubsub. The Information node is a transient node and so no PubSub history is stored. Users MAY subscribe to this node to receive information updates. The Information node item MAY contain the following attributes, each of which is OPTIONAL:
<p>The Information node holds information about the channel. The information node contains a single item with the current information.
The information node is named by the date/time at which the item was created. The information node is accessed and managed using standard pubsub. The Information node is a permanent node with a maximum of one item. Users MAY subscribe to this node to receive information updates. The Information node item MAY contain the following attributes, each of which is OPTIONAL:
</p>
<table caption="Information Node Attributes">
<tr><th>Name</th><th>Description</th><th>Field Type</th><th>Values</th><th>Default</th></tr>
@ -504,7 +510,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<section3 topic="Allowed" anchor="allowed-node">
<p>
This node represents a list of JIDs that are allowed to become participants. If the allowed node is not present, all JIDs are allowed. This node is accessed and managed using standard pubsub. The allowed list is always considered in conjunction with the banned list, stored in the banned node. Only Administrators and Owners have write permission to the allowed node and are also the only roles that are allows to subscribe to this node. The Allowed node is a permanent node and PubSub history MAY be stored. Each item contains a real bare JID. The following example shows how the allowed list can specify single JIDs and domains.
This node represents a list of JIDs that are allowed to become participants. If the allowed node is not present, all JIDs are allowed. This node is accessed and managed using standard pubsub. The allowed list is always considered in conjunction with the banned list, stored in the banned node. Only Administrators and Owners have write permission to the allowed node and are also the only roles that are allows to subscribe to this node. The Allowed node is a permanent node. Each item contains a real bare JID. The following example shows how the allowed list can specify single JIDs and domains.
</p>
<example caption="Allowed Node"><![CDATA[
<items node='urn:xmpp:mix:nodes:allowed'>
@ -515,7 +521,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</section3>
<section3 topic="Banned" anchor="banned-node">
<p>
This node represents a list of JIDs that are explicitly not allowed to become participants. The values in this list take priority over values in the allowed node. This node is accessed and managed using standard pubsub Only Administrators and Owners have write permission to the allowed node and are also the only roles that are allows to subscribe to this node. Each item contains a real bare JID. The Banned node is a permanent node and PubSub history MAY be stored.
This node represents a list of JIDs that are explicitly not allowed to become participants. The values in this list take priority over values in the allowed node. This node is accessed and managed using standard pubsub Only Administrators and Owners have write permission to the allowed node and are also the only roles that are allows to subscribe to this node. Each item contains a real bare JID. The Banned node is a permanent node.
</p>
<example caption="Banned Node"><![CDATA[
<items node='urn:xmpp:mix:nodes:banned'>
@ -526,7 +532,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</section3>
<section3 topic="Configuration Node" anchor="config-node">
<p>
The Configuration node holds the configuration of the channel as a single item, named by the date-time of the last update to the configuration. The Configuration Node is a transient PubSub node with no history. It is RECOMMENDED to store Configuration Node history in MAM. Previous configuration history MUST be accessed by MAM. Users with read access to the configuration node MAY subscribe to the configuration node to get notification of configuration change. This node is accessed and managed using standard pubsub. The configuration node is OPTIONAL for a MIX channel. For example, configuration choices could be fixed and not exposed. A subset of the defined configuration options MAY be used and additional non-standard configuration options MAY be added. JIDs in the configuration MUST be real bare JIDs and not proxy JIDs. If configuration options to control functionality of the nature described here are provided, the options defined in this standard MUST be used. The following configuration attributes are defined:
The Configuration node holds the configuration of the channel as a single item, named by the date-time of the last update to the configuration. The Configuration node is a permanent node with a maximum of one item. Previous configuration history MAY be accessed by MAM. Users with read access to the configuration node MAY subscribe to the configuration node to get notification of configuration change. This node is accessed and managed using standard pubsub. The configuration node is OPTIONAL for a MIX channel. For example, configuration choices could be fixed and not exposed. A subset of the defined configuration options MAY be used and additional non-standard configuration options MAY be added. JIDs in the configuration MUST be real bare JIDs and not proxy JIDs. If configuration options to control functionality of the nature described here are provided, the options defined in this standard MUST be used. The following configuration attributes are defined:
</p>
<table caption="Configuration Node Attributes">
<tr><th>Name</th><th>Description</th><th>Field Type</th><th>Values</th><th>Default</th></tr>