moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 08:45:04 -05:00
Code Issues Releases Wiki Activity

Whitespace fixes

Browse Source
This commit is contained in:
Jonas Wielicki 2018-05-22 15:19:59 +02:00
parent c6700251c1
commit 5a1c79f217
6 changed files with 166 additions and 166 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

64
xep-0403.xml
View File

@ -45,18 +45,18 @@
Split out from MIX 0.10.0;
</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>The Mediated Information eXchange (MIX) protocol framework and core capabilities for message distribution are specified in &xep0369; (MIX-CORE). This specification enables presence status of online clients belonging to channel participants to be shared through the channel with participants that wish to see this presence status. This is a achieved by a MIX presence node, which channel participants may subscribe to.
</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>This specification addressed a number of presence requirements:</p>
<ol>
<li>The mechanism must work cleanly for participants with multiple clients.</li>
<li>Standard presence messages must be used to share presence.</li>
@ -64,12 +64,12 @@
<li>Where MIX-ANON is not used, participants must be able to directly contact other participants.</li>
</ol>
</section1>
<section1 topic='Concepts' anchor='concepts'>
<section2 topic="User Presence in MIX" anchor="concepts-presence">
<p>
MIX channels store presence of each online client for a user that chooses to publish presence. Presence is stored in the presence node and is encoded using a full proxy JID. Where a user publishes presence for one or more clients, this information is available to all users subscribing to the channel presence.
@ -77,7 +77,7 @@
<p>
A client participating in a MUC channel MAY send it's presences status to the MIX channel using standard presence. The mechanisms to do this are summarized in the next section and standardized in MIX-PAM.
</p>
<p>
The MIX channel will distribute received presence to participants that have subscribed to the participants node. The client to which each presence update refers is identified by the &lt;from&gt; of the presence sent by the MIX channel. This is also the JID stored in the MIX presence node. This JID is built from two components:
</p>
@ -88,13 +88,13 @@
<p>
A client receiving this presence can use information from the channel participant's node to derive the full JID of the client and an associated Nick. When MIX-ANON is used to hide JIDs, only the Nick can be derived.
</p>
<p>
Presence updates are distributed by a channel to the bare JID of each participant and then the subscriber's server will distribute to each of the participant's currently online clients following the rules set out in MIX-PAM.
</p>
</section2>
<section2 topic="MIX Channels in Roster" anchor="concepts-roster">
<p>
@ -107,24 +107,24 @@
</li>
</ol>
</section2>
<section2 topic="Presence Node" anchor="prsence-node">
<p>MIX defines one node to support presence, as summarized in the table below. This node is required to support this specification.</p>
<table caption="MIX Presence Node">
<tr><th>Name</th><th>Node</th><th>Description</th><th>Update</th><th>Distribution</th></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><td>Presence</td><td>Presence</td></tr>
</table>
<p>
The presence node contains the presence value for clients belonging to participants that choose to publish presence to the channel. A MIX channel MAY require that all participants publish presence, so that active channel participants are visible. It is not possible to enforce this in the server, so participants in a channel with this option MUST publish presence. Each item in the presence node is identified by a JID constructed from the proxy JID and the resource for the client. The presence is encoded as a standard a presence stanza using a &lt;presence/&gt; element qualified by the 'jabber:client' namespace.
</p>
@ -142,9 +142,9 @@
</item>
</items>
]]></example>
</section2>
</section1>
@ -154,7 +154,7 @@
<section1 topic='Use Cases' anchor='usecases'>
<section2 topic='Common User Use Cases' anchor='usecases-user'>
<section3 topic='Setting User Presence' anchor='usecase-user-presence'>
<p>
@ -176,7 +176,7 @@ A user MAY share presence information with the channel, for one or more online c
<p>
A user setting status is now used as an example. Unlike in &xep0045; where coming online is a special action, coming online in MIX is implicit when presence status is set. Going offline is a achieved by setting presence status to unavailable, which removes the client full JID entry from the presence node. When a user sets a presence status, the user's server sends updated presence to the MIX channel, and the MIX service then publishes the user's availability to the "urn:xmpp:mix:nodes:presence" node. If there is not an item named by the full JID of the client with updated presence status, this item is created. The sequence is shown in the following examples, starting with a client setting presences status on the connected server.</p>
<example caption="Client Sets Presence Status on Server">
<![CDATA[<presence xmlns='jabber:client'
<![CDATA[<presence xmlns='jabber:client'
from='hag66@shakespeare.example/UUID-a1j/7533'>
<show>dnd</show>
<status>Making a Brew</status>
@ -208,24 +208,24 @@ A user MAY share presence information with the channel, for one or more online c
The history of the presence node MAY be archived using MAM. The MAM archive stores the node in PubSub format, following the node specification. This enables presence history to be retrieved using PubSub.
</p>
</section3>
<section3 topic="Client Coming Online and Obtaining Presence from the Local Server" anchor="usecase-obtaining-presence">
<p>
MIX Clients obtain presence from their local server. This is specified in MIX-PAM.
</p>
</section3>
<section3 topic='Going Offline' anchor='usecase-user-offline'>
<p>When a client goes offline, this presence update is sent by the client's server to the MIX channel. From the client perspective, this is the same as any other presence change. The MIX Channel also needs to remove the client from the participant's node.</p>
@ -235,7 +235,7 @@ A user MAY share presence information with the channel, for one or more online c
to='coven@mix.shakespeare.example'/>
]]></example>
<p>The MIX channel will retract (remove) the item in the presence node of the MIX channel identified by the client's full JID. The MIX channel will notify subscribers to the presence node of the user going offline by sending a presence stanza to the full JID of each client. The presence stanza will reference the full proxy JID of the client that is going offline, as shown in the following example:</p>
<example caption="Channel Distributes Notification of Client going Offline">
<![CDATA[<presence from='12345#coven@mix.shakespeare.example/UUID-a1j/7533'
to='hecate@shakespeare.example'

70
xep-0404.xml
View File

@ -45,23 +45,23 @@
Split out from MIX 0.10.0;
</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>The Mediated Information eXchange (MIX) protocol framework and core capabilities are specified in &xep0369; (MIX-CORE). This specification provides mechanisms to hide participant JIDs from other participants. This is needed to address privacy concerns and to prevent JID harvesting. It also addresses privacy issues, and gives participants options to control sharing of information.
</p>
</section1>
<section1 topic='Concepts' anchor='concepts'>
<section2 topic="Private Messages" anchor="concepts-pm">
<p>
MIX-CORE exposes participant JIDs to other participants, and so messages can always be sent directly. When JIDs are hidden this is no longer possible.
@ -70,10 +70,10 @@
</p>
</section2>
<section2 topic="JID Visibility Services" anchor="proxy-jid-services">
<p>
MIX channels have three modes controlling JID visibility, defined to prevent JID harvesting:
</p>
@ -97,55 +97,55 @@
The default value is 'Prefer Hidden'.
</p>
</section2>
<section2 topic="JID Visibility Architecture" anchor="proxy-jid-architecture">
<p>
MUC hides real JIDs by using Nicks to identify room occupants. This has problems with Nick changing and with multiple active clients for the same user. MIX identifies channel participants by a proxy JID, which is an anonymized stable JID format identifier for each participant. In MIX-CORE, the participants node provides a mapping from the proxy JID to the real JID. To hide JIDs, this specification makes two key changes
</p>
<ol>
<li>The requirement to include real JID in the participants list is relaxed for channels that are not "JID Visible". For a "JID Hidden" channel, real JIDs MUST NOT be included in the participants list. For a "JID Maybe Visible" channel, real JIDs will be included in the participants node according to participant preference. </li>
<li>In presence messages, the client resource is anonymized, to prevent leakage of information through the resource.</li>
</ol>
<p>
This change means that the client will not be able to determine real JID of the participant using the participant node, as it can with MIX-CORE.
</p>
<p>
It is important that MUC owners and administrators are able to see the real JIDs of participant. For this reason, a MIX channel following this specification MUST hold a JID Map node, which gives a mapping between proxy JID and real JID.
</p>
</section2>
<section2 topic="Resource Hiding" anchor="proxy-jid-resource">
<p>
When JIDs are being hidden, the resource of the full JIDs stored in the presence node MUST also be anonymized using a similar mechanism.
First the bare JID in presence is a proxy JID, as defined in MIX-CORE. Where the JID is not being hidden, the resource is simply the resource of the clients full JID. Where the JID is hidden, the resource is replaced with a generated value. For example, 'hag66@shakespeare.example/UUID-a1j/7533' in the channel coven might have a proxy JID of '123456#coven@mix.shakespeare.example/789'. There is no client visible mapping of proxy full JIDs maintained as this is not needed. The MIX channel will need to maintain a mapping, to support directly addressing clients, such as for client to client disco#info queries. While an full proxy JID is held in the presence node, the mapping to real JID MUST NOT be changed. When adding a client to the presence node, the server MAY add the same anonymized JID as used before by that client, or it MAY create a different anonymized JID.
</p>
</section2>
<section2 topic="JID Map Node" anchor="concepts-nodes">
<p>This specification defines a JID Map node, so that administrators can see real JIDs for JID Hidden channels.</p>
<table caption="JID Map Node">
<tr><td>JID Map</td><td>'urn:xmpp:mix:nodes:jidmap'</td><td>For storing a list of bare proxy JIDs from the participants node with a 1:1 mapping to the corresponding real JIDs.</td><td>Automatic</td><td>PubSub</td></tr>
</table>
@ -161,18 +161,18 @@ This change means that the client will not be able to determine real JID of the
</item>
</items>
]]></example>
</section2>
</section1>
<section1 topic='Use Cases' anchor='usecases'>
<section2 topic="User Preferences and Additional Information" anchor="usecase-visibilty-pref">
<p>A channel MAY store user preferences and parameters with each user. A user JID visibility preference has the following values:
</p>
@ -332,7 +332,7 @@ This change means that the client will not be able to determine real JID of the
<section2 topic='Sending Private Messages' anchor='usecase-user-private-messages'>

142
xep-0405.xml
View File

@ -45,12 +45,12 @@
Split out from MIX 0.10.0;
</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>The Mediated Information eXchange (MIX) protocol framework and core capabilities are specified in &xep0369; (MIX-CORE). MIX-CORE and MIX-PRESENCE define behaviour of a MIX server supporting MIX channels. In order for a MIX system to operate correctly, the XMPP server connecting MIX clients MUST follow the rules set out in this specification to achieve correct MIX operation. This specification also sets out requirements for XMPP clients, so a MIX client MUST follow both the rules of XMPP-CORE and this specification.
</p>
<p>
A MIX channel does not send messages and presence directly to the MIX client of a channel participant, but addresses them to the participant using the participant's bare JID. The participant's server MUST then handle these messages and pass them on to zero, one or multiple clients. To enable MIX to work, this behaviour is necessary and so the server of every MIX client MUST follow the rules set out in this specification.
@ -74,14 +74,14 @@ This approach enables flexible support of multiple clients for a MIX channel pa
Messages from a MIX channel to a MIX participant (which will be of type=groupchat), presence information, and other information sent as a result of MIX channel subscription are sent to the participant's server using the participant's bare JID. This means that the MIX participant's server MUST implement the modification of the standard &rfc6121; message processing rules specified here.
</p>
</section1>
<section1 topic="Use Cases" anchor="pam-use-cases">
@ -189,15 +189,15 @@ This approach enables flexible support of multiple clients for a MIX channel pa
Channel Join and Leave functions operate indirectly through the participant's server. The reason for this is that where a channel shares user presence, the channel is included in the user's roster which is managed in the local server. The Join and Leave functions lead to roster changes and so they MUST go through the participant's server. To achieve this, this specification wraps the operations so that the server can correctly route messages.
</p>
</section2>
<section2 topic='Joining a Channel' anchor='usecase-user-join'>
<p>A user joins a channel by sending a MIX "client-join" command from one of the user's clients, which wraps the "join" command specified in MIX-CORE. MIX-CORE specifies how the join command works, and so this specification considers only the wrapping and client actions.
The &lt;client-join/&gt; is a child element of &lt;iq/&gt; element. The &lt;client-join/&gt; element is qualified by the 'urn:xmpp:mix:pam:0' namespace. The channel being joined is specified by a 'channel' attribute in the &lt;client-join/&gt; element, which is used by the server to correctly address the join. The &lt;join&gt; is specified in MIX-CORE and is a child element of &lt;client-join/&gt;.
</p>
<example caption="Client sends request to local server to Join a MIX Channel"><![CDATA[
<iq type='set'
from='hag66@shakespeare.example/UUID-a1j/7533'
@ -233,7 +233,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<p>
The MIX service will process this request and respond as specified by MIX-CORE. An example response taken from MIX-CORE is shown below.
</p>
<example caption="Channel responds to User's Server"><![CDATA[
<iq type='result'
from='coven@mix.shakespeare.example'
@ -247,12 +247,12 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</join>
</iq>
]]></example>
<p>
The user's server will then make roster modifications as set out in a later section of this specification.
After making these changes, the user's server will send the client-join response containing the server's join response back to the client that made the join request. This has the 'from' set to the user's bare JID and the 'to' set to the client's full JID. This is illustrated below:
</p>
<example caption="User's Server sends response to Client"><![CDATA[
<iq type='result'
from='hag66@shakespeare.example'
@ -269,12 +269,12 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</client-join>
</iq>
]]></example>
</section2>
@ -283,8 +283,8 @@ This approach enables flexible support of multiple clients for a MIX channel pa
The &lt;client-leave/&gt; is a child element of &lt;iq/&gt; element. The &lt;client-leave/&gt; element is qualified by the 'urn:xmpp:mix:pam:0' namespace. The channel being left is specified by a 'channel' attribute in the &lt;client-leave/&gt; element, which is used by the server to correctly address the join. The &lt;leave&gt; is specified in MIX-CORE and is a child element of &lt;client-leave/&gt;.
This shown in the following example.</p>
<example caption="Client Requests to Leave a Channel"><![CDATA[
<iq type='set'
from='hag66@shakespeare.example/UUID-a1j/7533'
@ -296,11 +296,11 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</client-leave>
</iq>
]]></example>
<p>
The user's server will then generate a matching leave request to the MIX channel based on this information. This example is taken from MIX-CORE.
</p>
<example caption="User's Server sends Leave Request to a Channel"><![CDATA[
<iq type='set'
from='hag66@shakespeare.example'
@ -309,7 +309,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<leave xmlns='urn:xmpp:mix:core:0'/>
</iq>
]]></example>
<p>
The MIX channel will then process the leave and respond. The following example is taken from MIX-CORE.
</p>
@ -321,13 +321,13 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<leave xmlns='urn:xmpp:mix:core:0'/>
</iq>
]]></example>
<p>
After receiving the confirmation that the user has left the MIX channel, the user's server will remove the MIX channel entry from the user's roster and follow other processing as specified below. The user's server will then notify the client with the servers response.
This wraps the response from the server with a client-leave, with the 'from' set to the user's bare JID and the 'to' set to the client's full JID. This is illustrated below:
</p>
<example caption="User's Server Confirms Leave to Client"><![CDATA[
<iq type='result'
from='hag66@shakespeare.example'
@ -338,25 +338,25 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</client-leave>
</iq>
]]></example>
</section2>
<section2 topic="Roster Management" anchor="proxy-roster">
<p>
As part of the channel joining process, the user's server MUST add the MIX channel to the user's roster. This is done to share the user's presence status with the channel and channel participants subscribing to presence, when the user wishes this presence to be shared. These roster entries also enables the user's client to quickly determine which channels the user has joined. The user's server will need to record those roster entries that are associated with MIX channels in order to correctly handle MIX processing.
This roster entry will lead to the user's server correctly sending user's presence from all the user's MIX clients to the MIX channel. Where the user wishes to share presence, the roster subscription is configured with one way presence, as presence is sent to the MIX channel but no presence information about the MIX channel is sent to the user.
</p>
<p>
The participant's server MUST ensure that only presence information from clients that advertise 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>
<p>
If the user does not wish to publish presence information to the channel, the user's server will add the roster entry with mode subscription=none. The roster entry will be present to record that the user has joined the channel, but it will not send presence information to the channel. The user's server MUST do this when the user has chosen Presence preference of 'not share' as specified in MIX-ANON. If the user changes the value of the preference, the server MUST modify subscription mode to reflect this.
@ -364,17 +364,17 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<p>
The user's server MUST remove the user's roster entry when the user leaves the channel.
</p>
<p>
A channel MAY publish an Avatar following &xep0084;. A client MAY make use of this information to associate an Avatar with the roster entry for a channel.
</p>
<section3 topic='Setting User Presence' anchor='usecase-user-presence'>
<p>
@ -384,14 +384,14 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<p>
A user MAY share presence information with the channel, for the user's online clients.
A user MAY share presence information with the channel, for the user's online clients.
This is achieved by a roster entry for the channel configured with one way presence, which will cause all presence changes for the user's MIX clients to be sent to the channel.
When an XMPP client comes online or changes presence status, this will be communicated by the user to the user's server using broadcast presence. The user's XMPP server is then responsible to share this presence information to each entry in the roster and in particular to each MIX channel in the roster.
When an XMPP client comes online or changes presence status, this will be communicated by the user to the user's server using broadcast presence. The user's XMPP server is then responsible to share this presence information to each entry in the roster and in particular to each MIX channel in the roster.
</p>
<p>
A user setting status is now used as an example. Unlike in &xep0045; where coming online is a special action, coming online in MIX is implicit when presence status is set. Going offline is a achieved by setting presence status to unavailable, which removes the client full JID entry from the presence node. When a user sets a presence status, the user's server sends updated presence to the MIX channel, and the MIX service then publishes the user's availability to the presence node. If there is not an item named by the full JID of the client with updated presence status, this item is created. The sequence is shown in the following examples, starting with a client setting presences status on the connected server.</p>
@ -410,9 +410,9 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<show>dnd</show>
<status>Making a Brew</status>
</presence>]]></example>
</section3>
<section3 topic='Receiving User Presence' anchor='usecase-user-presence-receive'>
<p>
A MIX channel will send out presence information to participants that subscribe to the presence node, as specified in MIX-PRESENCE. An example is shown below:
@ -433,30 +433,30 @@ This approach enables flexible support of multiple clients for a MIX channel pa
id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'>
<show>dnd</show>
<status>Making a Brew</status>
</presence>]]></example>
</presence>]]></example>
<p>
The user's local server will receive a flow of all presence updates for the user. It will pass this presence information on to all online clients. This ensures that an online client is kept updated with presence.
The user's local server will receive a flow of all presence updates for the user. It will 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 local server, and so the local server is able maintain up to date presence state for the channel, even when there are no online clients. When a user had no online clients the user's server MAY continue to maintain MIX presence status for the user or MAY discard inbound MIX presence information.
</p>
<p>
The client receiving the presence can parse the proxy JID, specified in MIX-CORE to identify the channel to which the message relates. The proxy JID can be looked up in the Participant's node to determine Nick and real bare JID. The real bare JID can be combined with the resource form the presence stanza to determine the full real JID of the sender. This is described in MIX-CORE.
</p>
</section3>
<section3 topic="Client Coming Online and Obtaining Presence from the Local Server" anchor="usecase-obtaining-presence">
<p>
When the client comes online, it will activate use of the MIX. When the user's server has been maintaining MIX presence, it will then send full presence status to the client using standard presence messages. This will enable the client to update presence information for the subscribed MIX channels. Note that this does not need any interaction with MIX servers.
</p>
<p>
There are two situations where a MIX participant's server will need to get presence status from the channel, before it can send presence to the client. 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 participant's server (using the user's bare JID) presence for all of the items in the presence node using standard presence stanzas. This will give the participant's full current presence for the channel.
</p>
@ -467,12 +467,12 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<section3 topic="Determining Real JIDs" anchor="usecase-real-jids">
<p>
Presence information is provided with a proxy JID. A MIX client will usually wish to map this to the real JID. This will be done using the participants node, which has a list of all participants identified by proxy JID with real JIDs where this can be shared. Where real JIDs are not available, the Nick will be available. Clients will typically load the participants node on start-up and use a subscription to the participants node to keep this up to date.
</p>
</section3>
</section3>
<section3 topic='Going Offline' anchor='usecase-user-offline'>
<p>When a client goes offline, this presence update is sent by the client's server to the MIX channel. From the client perspective, this is the same as any other presence change. Going online and offline will simply be presence updates. </p>
<example caption="Client Goes Offline and Sends Presence to Channel"><![CDATA[
@ -480,18 +480,18 @@ This approach enables flexible support of multiple clients for a MIX channel pa
from='hag66@shakespeare.example/UUID-a1j/7533'
to='coven@mix.shakespeare.example'/>
]]></example>
<p>
It is desirable to prevent clients from going offline briefly and then coming back online again, as this will lead to "flapping presence". The RECOMMENDED approach to achieve this is use of &xep0198; to maintain an XMPP client connection in the event of short term TCP failure.
</p>
</section3>
</section2>
<section2 topic="MIX Roster Item Capability Sharing" anchor="mix-roster-capability-sharing">
<p>It is 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 MIX client MAY request that the server return this additional information that annotates roster elements with MIX capability. The server MUST return the additional information. The request is made by extending the standard roster get request by adding a child element &lt;annotate/&gt; to the &lt;query/&gt; element. The &lt;annotate/&gt; element is qualified by the ‘urn:xmpp:mix:roster:0' namespace.</p>

28
xep-0406.xml
View File

@ -51,28 +51,28 @@
<section1 topic='Introduction' anchor='intro'>
<p>The Mediated Information eXchange (MIX) protocol framework and core capabilities are specified in &xep0369; (MIX-CORE). This document defines a framework for administering a MIX service, including MIX-CORE, MIX-PRESENCE and MIX-ANON. It defines MIX channel configuration in a standardized manner, to enable consistent MIX administration using standard capabilities.
</p>
</section1>
<section1 topic="Admininstrative MIX Nodes" anchor="concepts-nodes">
<p>This specification defines three standard nodes to support configuration. The configuration node is required to support this specification and the other two nodes are optional:</p>
<table caption="Administrative MIX Nodes">
<tr><td>Allowed</td><td>'urn:xmpp:mix:nodes:allowed'</td><td>For storing JIDs that are allowed to be channel participants.</td><td>PubSub</td><td>PubSub</td></tr>
<tr><td>Banned</td><td>'urn:xmpp:mix:nodes:banned'</td><td>For storing JIDs that are not allowed to be channel participants. </td><td>PubSub</td><td>PubSub</td></tr>
<tr><td>Configuration</td><td>'urn:xmpp:mix:nodes:config'</td><td>For storing channel configuration. </td><td>PubSub</td><td>PubSub</td></tr>
</table>
<p>
</p>
<section2 topic="Roles" anchor="roles">
<p>
@ -92,8 +92,8 @@
</p>
</section2>
<section2 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 allowed 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.
@ -180,17 +180,17 @@
<section1 topic='Administrative Use Cases' anchor='usecases-admin'>
<section2 topic='Modifying Channel Information' anchor='usecase-admin-information'>
<p>Authorized users, typically owners and sometimes administrators, MAY modify the channel information. The client MAY issue a pubsub get command to obtain a form that will facilitate update of the information node. The values in the form show current values, which be defaults or MAY have been explicitly set. In the following example, the channel name was previously set, but other values were not. </p>

26
xep-0407.xml
View File

@ -44,14 +44,14 @@
Split out from MIX 0.10.0;
</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>The Mediated Information eXchange (MIX) protocol framework and core capabilities are specified in &xep0369; (MIX-CORE). This specification defines six extensions to this core:
</p>
<ol>
<li>Avatar Publishing.</li>
<li>Nick Registration.</li>
@ -60,9 +60,9 @@
<li>Invitation by reference.</li>
<li>Converting 1:1 conversation to a channel.</li>
</ol>
<p>These extensions are independent. An implementation of this specification should identify clearly which extensions are implemented.</p>
</section1>
<section1 topic="Avatar Publishing" anchor="avatar">
@ -75,13 +75,13 @@
<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>
</section1>
<section1 topic='Registering a Nick' anchor='usecase-user-register'>
<p>A nick MAY be associated with a user's bare JID. A user can register a nick with the MIX service. Nick registration can be used ensure that a user is able to use the same nick in all channels in the service and to prevent other users from using a registered nick. This can help achieve a consistent experience across a set of channels and prevent user confusion. Support for nick registration by a MIX service is OPTIONAL. Where nick registration is supported, nick registration MAY be OPTIONAL or MANDATORY.
Where a user has registered a Nick with the MIX service, it MAY be used by each channel according to policy for the channel. A channel MAY enforce use of a registered nick. A channel MUST NOT use a registered nick for any other participant.
@ -154,9 +154,9 @@
</section1>
<section1 topic="Retracting a Message" anchor="usecase-retract">
<p>
@ -315,8 +315,8 @@
<section1 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 create and populate a channel. 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.

2
xep-0408.xml
View File

@ -43,7 +43,7 @@
Split out from MIX 0.10.0;
</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>The Mediated Information eXchange (MIX) protocol framework and core capabilities are specified in &xep0369; (MIX-CORE).