mirror of
https://github.com/moparisthebest/xeps
synced 2024-12-21 23:28:51 -05:00
Merge commit 'refs/pull/564/head' of https://github.com/xsf/xeps into feature/xep-0369
This commit is contained in:
Jonas Wielicki
commit
4691bf0d2a
33
xep-0369.xml
33
xep-0369.xml
@ -37,6 +37,17 @@
|
||||
&skille;
|
||||
&stpeter;
|
||||
<revision>
|
||||
<version>0.9.5</version>
|
||||
<date>2018-02-03</date>
|
||||
<initials>sek</initials>
|
||||
<remark><p>
|
||||
Various Clarifications from Dave Cridland review:
|
||||
Remove Recommendation to do MIX/MUC on separate domains,
|
||||
Sort Default JID Visibility Preference,
|
||||
Make Owner optional,
|
||||
Clarify that Nick is optional;
|
||||
</p></remark>
|
||||
</revision> <revision>
|
||||
<version>0.9.4</version>
|
||||
<date>2018-01-02</date>
|
||||
<initials>sek</initials>
|
||||
@ -55,7 +66,8 @@
|
||||
Change Retract to use MAM-ID;
|
||||
Ensure use of .example throughout (follow RFC conventions);
|
||||
</p></remark>
|
||||
</revision> <revision>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.9.3</version>
|
||||
<date>2017-07-18</date>
|
||||
<initials>sek</initials>
|
||||
@ -326,7 +338,7 @@
|
||||
<li>XMPP clients can implement MUC and this specification in a way that provides a coherent user experience.</li>
|
||||
<li>XMPP servers can implement this specification and also provide a MUC interface in order to support clients that only implement MUC.</li>
|
||||
</ul>
|
||||
<p>If a server wishes to expose both MUC and MIX representations of chatrooms, it is RECOMMENDED to do so by serving MUC and MIX on different domains, but a server MAY serve them on the same domain.</p>
|
||||
<p>This specification gives guidance on supporting both MUC and MIX representations of chatrooms.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Requirements' anchor='reqs'>
|
||||
@ -379,7 +391,7 @@
|
||||
</section2>
|
||||
<section2 topic="MIX and PubSub" anchor="concepts-pubsub">
|
||||
<p>MIX is based upon domains providing a MIX service, such as 'mix.shakespeare.example'. Note that although PubSub communication is used, a domain used for MIX is a MIX domain and not a standard &xep0060; domain. Like MUC, there is no requirement on the naming of these domains; the label 'mix' used in examples in this specification and the fact that it is a subdomain of a 'shakespeare.example' service are purely for example.</p>
|
||||
<p>Every MIX channel is an addressable PubSub service (with additional MIX semantics) that will be addressed using a bare JID by other XMPP entities, for example coven@mix.shakespeare.example. While &xep0060; is used as the basis for the MIX model, MIX uses standard presence and groupchat messages to provide an interface to the MIX service that does not expose PubSub protocol for many of the more common functions.
|
||||
<p>Every MIX channel is an addressable service based on PubSub (with additional MIX semantics) that will be addressed using a bare JID by other XMPP entities, for example coven@mix.shakespeare.example. While &xep0060; is used as the basis for the MIX model, MIX uses standard presence and groupchat messages to provide an interface to the MIX service that does not expose PubSub protocol for many of the more common functions.
|
||||
</p>
|
||||
</section2>
|
||||
<section2 topic="MIX and MAM" anchor="concepts-mam">
|
||||
@ -397,7 +409,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
|
||||
<li>Messages from a MIX client to a MIX channel will go direct to the MIX service. They are relayed, but not modified, by the participant's server.</li>
|
||||
<li>Messages from a MIX channel to a MIX client are always sent to the MIX participant's server (addressed by bare JID) and MUST be handled by the MIX participant's server.</li>
|
||||
<li>All messages received by the MIX participant's server MUST be stored using MAM.</li>
|
||||
<li>All MIX messages received by the MIX participant's server for a participant MUST be stored using MAM in the participant's archive.</li>
|
||||
<li>The MIX participant's server will only forward messages to online clients and will not forward messages if no clients are online.
|
||||
This means that a MIX client needs to resynchronize with all MIX channels when it comes online. This message synchronization will happen between the MIX client and the MAM archive held on the MIX participant's server.</li>
|
||||
|
||||
@ -444,13 +456,13 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
</p>
|
||||
<table caption="JID Visibility Preference Options">
|
||||
<tr><th>Preference</th><th>Description</th></tr>
|
||||
<tr><td>'No JID Visibility Preference'</td><td>The users JID will be visible if the channel is JID Visible or JID Maybe Visible channels and hidden if the channel is JID Hidden. </td></tr>
|
||||
<tr><td>'Prefer Visible'</td><td>The users JID will be visible if the channel is JID Visible or JID Maybe Visible channels and hidden if the channel is JID Hidden. </td></tr>
|
||||
<tr><td>'Prefer Hidden'</td><td>The user's JID will be hidden if the channel is JID Maybe Visible and shown if the channel is JID Visible .</td></tr>
|
||||
<tr><td>'Enforce Hidden'</td><td>The user's JID will never be shown and the user will be removed from channel if channel mode is changed to JID Visible.</td></tr>
|
||||
<tr><td>'Enforce Visible'</td><td>The users JID will always be shown and the user will be removed from channel if mode is changed to 'JID Hidden'.</td></tr>
|
||||
</table>
|
||||
<p>
|
||||
For JID Visible and JID Hidden channels the default user visibility preference is No JID Visibility Preference. For JID Maybe Visible channels, the default user visibility preference is Prefer Hidden, so that JIDs will only be visible when users explicitly permit this.
|
||||
The default value is 'Prefer Hidden'.
|
||||
</p>
|
||||
<p>
|
||||
The primary representation of a participant in a MIX channel is a proxy JID, which is an anonymized JID using the same domain as the channel and with the name of the channel encoded, using the format "<generated identifier>#<channel>@<mix domain>". The generated identifier MUST NOT contain the '#', '/' or '@' characters. The Channel name MAY contain the '#' character. For example in the channel 'coven@mix.shakespeare.example', the user 'hag66@shakespeare.example' might have a proxy JID of '123456#coven@mix.shakespeare.example'. The reason for the proxy JID is to support JID Hidden channels. Proxy JIDs are also used in JID Visible channels, for consistency and to enable switching of JID visibility. The "urn:xmpp:mix:nodes:jidmap" node maps from proxy JID to real JID. Servers and clients MUST determine that a JID is a proxy JID from context and MUST NOT infer that a JID is a proxy JID because it contains the '#' character.
|
||||
@ -507,7 +519,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
<tr><td>Anyone</td><td>Any user, including users in the banned node.</td></tr>
|
||||
</table>
|
||||
<p>
|
||||
There MUST always be at least one Owner for a Channel. Administrators, Participants, and Allowed are optional and do not need to be set. Rights are defined in a strictly hierarchical manner following the order of this table, so that for example Owners will always have rights that Administrators have.
|
||||
There MUST always be at least one Owner for a Channel. Owners, Administrators, Participants, and Allowed are optional and do not need to be set. Where no owner is explicitly set, it is anticipated that a server administrator will have owner rights. Rights are defined in a strictly hierarchical manner following the order of this table, so that for example Owners will always have rights that Administrators have.
|
||||
</p>
|
||||
</section3>
|
||||
|
||||
@ -525,7 +537,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
</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 '123456#coven@mix.shakespeare.example' might name the node item associated with participant 'hag66@shakespeare.example'. Information is stored in a <participant/> element qualified by the 'urn:xmpp:mix:1' namespace. The nick associated with the user is mandatory and is stored in a <nick/> child element of the <participant/> element. 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 '123456#coven@mix.shakespeare.example' might name the node item associated with participant 'hag66@shakespeare.example'. Information is stored in a <participant/> element qualified by the 'urn:xmpp:mix:1' namespace. The nick associated with the user is optional and is stored in a <nick/> child element of the <participant/> element. 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 proxy JID is added to the participants node by the MIX service. When a user leaves a channel, the user's bare proxy JID is removed from the participants node. The participants node MUST NOT be directly modified using pubsub.
|
||||
@ -713,7 +725,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
</section2>
|
||||
<section2 topic="Non-Standard Nodes" anchor="non-standard-nodes">
|
||||
<p>
|
||||
The MIX standard allows channels to use non-standard nodes, using names that do no conflict with the standard nodes. Non-Standard nodes MUST NOT duplicate or otherwise provide capability that can be provided by standard nodes.
|
||||
The MIX standard allows channels to use non-standard nodes, using names that do not conflict with the standard nodes. Non-Standard nodes MUST NOT duplicate or otherwise provide capability that can be provided by standard nodes.
|
||||
</p>
|
||||
</section2>
|
||||
</section1>
|
||||
@ -885,8 +897,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
|
||||
to='hag66@shakespeare.example/UUID-c8y/1573'
|
||||
type='result'>
|
||||
<pubsub xlns='http://jabber.org/protocol/pubsub'>
|
||||
<items node='urn:xmpp:mix:nodes:info>>
|
||||
<item>
|
||||
<items node='urn:xmpp:mix:nodes:info'>
|
||||
<item id='2016-05-30T09:00:00' xmlns='urn:xmpp:mix:1'>
|
||||
<x xmlns='jabber:x:data' type='result'>
|
||||
<field var='FORM_TYPE' type='hidden'>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user