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

XEP-0369: Remove whitespace errors

Browse Source
This commit is contained in:
Sam Whited 2016-12-21 12:38:47 -06:00
parent ca9dafcfd6
commit e14947f67f
1 changed files with 12 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
xep-0369.xml
View File

@ -46,7 +46,7 @@
<date>2016-12-05</date>
<initials>sek</initials>
<remark><p>
Clarify Direct PubSub access to each node type
Clarify Direct PubSub access to each node type
</p></remark>
</revision>
<revision>
@ -289,7 +289,6 @@
<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 distributing messages to the channel. Each item of this node will contain a message sent to the channel.</td></tr>
<tr><td>Participants</td><td>'urn:xmpp:mix:nodes:participants'</td><td>For storing the list of participants and the associated nick. Channel participants are added when they join the channel and removed when they leave </td></tr>
<tr><td>JID Map</td><td>'urn:xmpp:mix:nodes:jidmap'</td><td>For storing a list of anonymized bare JIDs from the participants node with a 1:1 mapping to the corresponding real JIDs.</td></tr>
<tr><td>Presence</td><td>'urn:xmpp:mix:nodes:presence'</td><td>For storing information about the availability status of online participants, which may include multiple clients for a single participant.</td></tr>
@ -301,7 +300,7 @@
</table>
<p>
All of the standard nodes are optional. A channel providing a service similar to MUC will typically use all of the standard nodes, but other channels may use combinations of these 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. Some nodes are accessed and managed with PubSub, whereas other nodes define MIX specific mechanisms for their use.
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. Some nodes are accessed and managed with PubSub, whereas other nodes define MIX specific mechanisms for their use.
</p>
<p>
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.
@ -336,7 +335,7 @@
</section3>
<section3 topic="Participants Node" anchor="participants-node">
<p>Each channel participant is represented as an item of the 'urn:xmpp:mix:nodes:participants' channel node. Each item is named by the bare proxy JID of the participant. For example 'coven+123456@mix.shakespeare.example' might name the node item associated with participant 'hag66@shakespeare.example'. The nick associated with the user is mandatory and is stored in the item. The nick for each channel participant MUST be different to the nick of other participants.
<p>Each channel participant is represented as an item of the 'urn:xmpp:mix:nodes:participants' channel node. Each item is named by the bare proxy JID of the participant. For example 'coven+123456@mix.shakespeare.example' might name the node item associated with participant 'hag66@shakespeare.example'. The nick associated with the user is mandatory and is stored in the item. The nick for each channel participant MUST be different to the nick of other participants.
</p>
<p>
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.
@ -354,7 +353,7 @@
</section3>
<section3 topic="JID Map Node" anchor="jid-map-node">
<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.
In JID visible channels, all participants may subscribe to this node. In JID hidden channels, only administrators can subscribe. </p>
<example caption="Value of JID Map Node"><![CDATA[
@ -420,13 +419,11 @@
</items>
]]></example>
</section3>
<section3 topic="Subject Node" anchor="subject-node">
<p>The subject node publishes the current subject of channel. Subject history is stored in MAM. A single item is stored in this node at a time which MUST contain a "text" element and MAY contain additional text elements. Where multiple text elements are provided, each MUST posses an xml:lang attribute that describes the natural language of the subject. </p>
<p>
Setting and sharing subject uses a message with subject element, in a manner compatible with &xep0045;. Clients MAY also write or access this node using pubsub. Writes to this node will lead to update of subject by sending messages. Setting the subject is controlled by configuration; in some channels it may be set by all users and in others restricted to administrators.
The following example shows the format of a item in the subject node.
Setting and sharing subject uses a message with subject element, in a manner compatible with &xep0045;. Clients MAY also write or access this node using pubsub. Writes to this node will lead to update of subject by sending messages. Setting the subject is controlled by configuration; in some channels it may be set by all users and in others restricted to administrators.
The following example shows the format of a item in the subject node.
</p>
<example caption="Subject Node">
<![CDATA[<items node='urn:xmpp:mix:nodes:subject'>
@ -439,7 +436,6 @@
When a user subscribes to the Subject Node, this will cause the channel to send Subject messages to the user through the MIX Proxy. This is done on initial user subscription and on subject change. Clients MAY directly read the channel subject from the Subject Node using PubSub.
</p>
</section3>
<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. Each item contains a real bare JID. The following example shows how the allowed list can specify single JIDs and domains.
@ -1189,10 +1185,9 @@ the participant is not be subscribed to all nodes associated with the channel (i
<p>
The presence information for a channel is stored in the urn:xmpp:mix:nodes:presence node and distributed using standard presence stanzas to the MIX Proxy of users subscribing to this presence node. The user's MIX Proxy will then pass this presence information on to all online clients. This ensures that an online client is kept updated with presence.
When a client goes offline, it will cease getting presence updates. Presence updates will continue to flow to the user's MIX Proxy, and so the MIX Proxy will maintain up to date presence state for the channel.
</p>
</p>
<p>
When the client comes online, it will activate use of the MIX Proxy. The MIX Proxy will then send full presence status to the client using standard presence messages. This will enable the client to update presence information for the channel. Note that this does not need any interaction with the channel.
</p>
</section3>
@ -1205,9 +1200,8 @@ the participant is not be subscribed to all nodes associated with the channel (i
There are two situations where the MIX Proxy will need to get presence status from the channel. The first time is when a user joins the channel as a participant and subscribes to presence. Upon this subscription the MIX channel will send to the MIX Proxy (the user's bare JID) presence for all of the items in the presence node using standard presence stanzas. This will give the MIX Proxy full current presence for the channel.
</p>
<p>
The second scenario is when the MIX Proxy needs to load or refresh presence status for a channel. This will be needed when the MIX Proxy and associated server are started. This MIX Proxy requests presence update by sending a directed presence stanza to the MIX channel from the user's bare JID. The MIX channel can distinguish this from a presence update, which will always be sent from the clients full JID. This special presence stanza will send to the MIX Proxy (the user's bare JID) presence for all of the items in the presence node using standard presence stanzas.
The second scenario is when the MIX Proxy needs to load or refresh presence status for a channel. This will be needed when the MIX Proxy and associated server are started. This MIX Proxy requests presence update by sending a directed presence stanza to the MIX channel from the user's bare JID. The MIX channel can distinguish this from a presence update, which will always be sent from the clients full JID. This special presence stanza will send to the MIX Proxy (the user's bare JID) presence for all of the items in the presence node using standard presence stanzas.
</p>
</section3>
<section3 topic="Determining Real JIDs" anchor="usecase-real-jids">
<p>
@ -1714,11 +1708,11 @@ A client creates a channel by sending a simple request to the MIX service. A c
</section3>
<section3 topic="Converting a 1:1 Conversation to a Channel" anchor="usecase-admin-converting-chat">
<p>
A common use case for an ad hoc channel is where two users are engaged in a 1:1 chat and wish to broaden the discussion. Prior to bringing more users into a channel, using standard invitation process, there is a need to move a dialogue. The first step is for one of the two users to create an ad hoc channel, as described in the previous section. The other user will then be invited, and can switch to the new channel.
A common use case for an ad hoc channel is where two users are engaged in a 1:1 chat and wish to broaden the discussion. Prior to bringing more users into a channel, using standard invitation process, there is a need to move a dialogue. The first step is for one of the two users to create an ad hoc channel, as described in the previous section. The other user will then be invited, and can switch to the new channel.
</p>
<p>
<p>
It may also be useful to share some or all of the messages from the 1:1 discussion into the new channel. The mechanism to do this is to have a special message format that includes information on the original message.
This will generally be done by the user creating the channel before the other user is invited, but may be sent by either the user creating the channel or the 1:1 chat partner at any time.
This will generally be done by the user creating the channel before the other user is invited, but may be sent by either the user creating the channel or the 1:1 chat partner at any time.
These messages are marked as &lt;resend&gt; which includes an number of parameters facilitate appropriate display of this selected chat history. This has the following parameters:
</p>
<ul>
@ -1732,7 +1726,7 @@ A client creates a channel by sending a simple request to the MIX service. A c
id='92vax143g'
type='groupchat'>
<body>Harpier cries: 'tis time, 'tis time.</body>
<resend xmlns='urn:xmpp:mix:0'
<resend xmlns='urn:xmpp:mix:0'
time='2010-07-10T23:08:25Z'
from='hag67@shakespeare.example/pda'
to='hag66@shakespeare.example/pda'