mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-28 20:22:24 -05:00
Partial Permanent/Transient Edit
This commit is contained in:
parent
7d89f52916
commit
7014eb97f4
18
xep-0369.xml
18
xep-0369.xml
@ -404,7 +404,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
|||||||
</p>
|
</p>
|
||||||
</section3>
|
</section3>
|
||||||
<section3 topic="Messages Node" anchor="messages-node">
|
<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. Zero history is held in the messages node. 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 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>Private Messages are not stored in the messages node.</p>
|
<p>Private Messages are not stored in the messages node.</p>
|
||||||
</section3>
|
</section3>
|
||||||
|
|
||||||
@ -415,7 +415,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.
|
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.
|
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>
|
||||||
<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.</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>
|
||||||
<example caption="Value of Participants Node"><![CDATA[
|
<example caption="Value of Participants Node"><![CDATA[
|
||||||
<items node='urn:xmpp:mix:nodes:participants'>
|
<items node='urn:xmpp:mix:nodes:participants'>
|
||||||
<item id='coven+123456@mix.shakespeare.example'>
|
<item id='coven+123456@mix.shakespeare.example'>
|
||||||
@ -429,7 +429,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.
|
<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.
|
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. </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 and PubSub history MAY be stored.</p>
|
||||||
<example caption="Value of JID Map Node"><![CDATA[
|
<example caption="Value of JID Map Node"><![CDATA[
|
||||||
<items node='urn:xmpp:mix:nodes:jidmap'>
|
<items node='urn:xmpp:mix:nodes:jidmap'>
|
||||||
<item id='coven+123456@mix.shakespeare.example'>
|
<item id='coven+123456@mix.shakespeare.example'>
|
||||||
@ -445,7 +445,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
|||||||
</p>
|
</p>
|
||||||
|
|
||||||
<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.
|
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.
|
||||||
</p>
|
</p>
|
||||||
<example caption="Value of Presence Node"><![CDATA[
|
<example caption="Value of Presence Node"><![CDATA[
|
||||||
<items node='urn:xmpp:mix:nodes:presence'>
|
<items node='urn:xmpp:mix:nodes:presence'>
|
||||||
@ -460,8 +460,8 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
|||||||
</section3>
|
</section3>
|
||||||
<section3 topic="Information Node" anchor="info-node">
|
<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 held in MAM.
|
<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. Users MAY subscribe to this node to receive information updates. The Information node item MAY contain the following attributes, each of which is OPTIONAL:
|
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>
|
</p>
|
||||||
<table caption="Information Node Attributes">
|
<table caption="Information Node Attributes">
|
||||||
<tr><th>Name</th><th>Description</th><th>Field Type</th><th>Values</th><th>Default</th></tr>
|
<tr><th>Name</th><th>Description</th><th>Field Type</th><th>Values</th><th>Default</th></tr>
|
||||||
@ -500,7 +500,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
|||||||
|
|
||||||
<section3 topic="Allowed" anchor="allowed-node">
|
<section3 topic="Allowed" anchor="allowed-node">
|
||||||
<p>
|
<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. 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 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.
|
||||||
</p>
|
</p>
|
||||||
<example caption="Allowed Node"><![CDATA[
|
<example caption="Allowed Node"><![CDATA[
|
||||||
<items node='urn:xmpp:mix:nodes:allowed'>
|
<items node='urn:xmpp:mix:nodes:allowed'>
|
||||||
@ -511,7 +511,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
|||||||
</section3>
|
</section3>
|
||||||
<section3 topic="Banned" anchor="banned-node">
|
<section3 topic="Banned" anchor="banned-node">
|
||||||
<p>
|
<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.
|
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.
|
||||||
</p>
|
</p>
|
||||||
<example caption="Banned Node"><![CDATA[
|
<example caption="Banned Node"><![CDATA[
|
||||||
<items node='urn:xmpp:mix:nodes:banned'>
|
<items node='urn:xmpp:mix:nodes:banned'>
|
||||||
@ -522,7 +522,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
|||||||
</section3>
|
</section3>
|
||||||
<section3 topic="Configuration Node" anchor="config-node">
|
<section3 topic="Configuration Node" anchor="config-node">
|
||||||
<p>
|
<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. A single item is stored in the node, with previous configuration history 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 Configuraton Node is a transient PubSub node with no history. It is RECOMMENDED to store Configuraton 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:
|
||||||
</p>
|
</p>
|
||||||
<table caption="Configuration Node Attributes">
|
<table caption="Configuration Node Attributes">
|
||||||
<tr><th>Name</th><th>Description</th><th>Field Type</th><th>Values</th><th>Default</th></tr>
|
<tr><th>Name</th><th>Description</th><th>Field Type</th><th>Values</th><th>Default</th></tr>
|
||||||
|
Loading…
Reference in New Issue
Block a user