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

Merge pull request #231 from SamWhited/xep0369_phrasing_grammar

Browse Source 
XEP-0369: Phrasing and grammar tweaks
This commit is contained in:
Sam Whited 2016-08-25 07:00:04 -07:00 committed by GitHub
commit 2f8a009c75
1 changed files with 16 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
xep-0369.xml
View File

@ -35,14 +35,12 @@
<email>Steve.Kille@isode.com</email> <email>Steve.Kille@isode.com</email>
<jid>Steve.Kille@isode.com</jid> <jid>Steve.Kille@isode.com</jid>
</author> </author>
&stpeter; &stpeter;
<revision> <revision>
<version>0.2.1</version> <version>0.2.1</version>
<date>2016-08-25</date> <date>2016-08-26</date>
<initials>egp</initials> <initials>ssw, egp</initials>
<remark><p>Link Mauve (Emmanuel Gil PEYROT) editorial changes</p></remark> <remark><p>Phrasing and grammar.</p></remark>
</revision> </revision>
<revision> <revision>
<version>0.2</version> <version>0.2</version>
@ -70,8 +68,8 @@
</revision> </revision>
</header> </header>
<section1 topic='Introduction' anchor='intro'> <section1 topic='Introduction' anchor='intro'>
<p>Multi-User Chat (MUC) is a major application of XMPP that was developed in 2002 and standardized in &xep0045;. The Mediated Infromation eXchange (MIX) protocol defined here implements the same basic MUC patterns in a more flexible and extensible way in order to address requirements that have emerged since MUC was developed. MIX supports all of the core chatroom features that are familiar from MUC, such as discussion topics and invitations. Like MUC, it also defines a strong access control model, including the ability to kick and ban users, to name administrators, and to require membership in order to participate in channels. MIX is intended as a medium term replacement for MUC.</p> <p>The Mediated Information eXchange (MIX) protocol is intended as a replacement for Multi-User Chat (MUC). MUC is a major application of XMPP that was developed in 2002 and standardized in &xep0045;. MIX implements the same basic MUC patterns in a more flexible and extensible way in order to address requirements that have emerged since MUC was developed. MIX supports all of the core chatroom features that are familiar from MUC, such as discussion topics and invitations. Like MUC, it also defines a strong access control model, including the ability to kick and ban users, to name administrators, and to require membership in order to participate in channels.</p>
<p>MUC exists and works, so why replace it? There are several reasons:</p> <p>Several reasons exist for replacing MUC:</p>
<ul> <ul>
<li>A number of use cases for group communication have emerged since MUC was first published.</li> <li>A number of use cases for group communication have emerged since MUC was first published.</li>
<li>Experience has shown that it is difficult to use MUC to build several kinds of communication applications (such as a multimedia conference focus) without undesirable adaptations.</li> <li>Experience has shown that it is difficult to use MUC to build several kinds of communication applications (such as a multimedia conference focus) without undesirable adaptations.</li>
@ -113,29 +111,29 @@
</li> </li>
<li>&xep0313; (MAM) is used for all history access, with each node being individually addressable for MAM queries. This simplifies implementation compared to MUC (which had a specialized and rather limited history retrieval mechanism).</li> <li>&xep0313; (MAM) is used for all history access, with each node being individually addressable for MAM queries. This simplifies implementation compared to MUC (which had a specialized and rather limited history retrieval mechanism).</li>
<li>A client can achieve a 'quick resync' of a node by requesting just those changes it has not yet received, using standard MAM protocol. This solves the old MUC issue of either receiving duplicate messages when rejoining a room or potentially missing messages.</li> <li>A client can achieve a 'quick resync' of a node by requesting just those changes it has not yet received, using standard MAM protocol. This solves the old MUC issue of either receiving duplicate messages when rejoining a room or potentially missing messages.</li>
<li>Because MAM is used for history, only those nodes that have a 'current value' need to store any items in them - e.g., 'urn:xmpp:mix:nodes:presence' and 'urn:xmpp:mix:nodes:subject' would store their current values (with older values being queryable through MAM), while 'urn:xmpp:mix:nodes:messages' would store no items.</li> <li>Because MAM is used for history, only those nodes that have a 'current value' need to store any items in them &mdash; e.g., 'urn:xmpp:mix:nodes:presence' and 'urn:xmpp:mix:nodes:subject' would store their current values (with older values being queryable through MAM), while 'urn:xmpp:mix:nodes:messages' would store no items.</li>
<li>A user's participation in a channel outlives their presence session. A user who is offline will not share presence within the channel, but will still be listed as an participant. This too is a significant departure from MUC.</li> <li>A user's participation in a channel outlives their session. A user who is offline will not share presence within the channel, but will still be listed as an participant. This too is a significant departure from MUC.</li>
<li>MIX decouples addressing of occupants from their nicknames, so that nickname changes do not affect addressing.</li> <li>MIX decouples addressing of occupants from their nicknames, so that nickname changes do not affect addressing.</li>
<li>Each participant is addressable by a single bare JID, which is a proxy JID (not the user's real JID) to make it straightforward to hide the user's real JID from other channel participants. Full JIDs comprised of this bare JID plus a resource are then constructed, allowing transparency when a user has multiple online resources participating in the MIX.</li> <li>Each participant is addressable by a single bare JID, which is a proxy JID (not the user's real JID) to make it straightforward to hide the user's real JID from other channel participants. Full JIDs comprised of this bare JID plus a resource are then constructed, allowing visibility into the number of online resources participating in a channel.</li>
</ul> </ul>
<section2 topic="MIX and PubSub" anchor="concepts-pubsub"> <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. (Note that, like in MUC, there is no requirement on the naming of these domains; the label 'mix' and the fact that it is a subdomain of a 'shakespeare.example' service are each purely an example).</p> <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' 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 by an XMPP client using a bare JID, 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 for many of the more common functions. <p>Every MIX channel is an addressable PubSub service (with additional MIX semantics) that will be addressed by an XMPP client using a bare JID, 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 for many of the more common functions.
</p> </p>
</section2> </section2>
<section2 topic="MIX and MAM" anchor="concepts-mam"> <section2 topic="MIX and MAM" anchor="concepts-mam">
<p>Message Archive Management is used for all storage of historical data (such as the history of messages sent within the channel). Each node can be archived separately (e.g., the presence node or the configuration node). MIX clients can retrieve information archived in MAM in order to quickly resync messages with regard to a channel, and can do so without necessarily providing presence information.</p> <p>Message Archive Management is used for all storage of historical data (such as the history of messages sent within the channel). Each node can be archived separately (e.g., the presence node or the configuration node). MIX clients can retrieve archived information with MAM in order to quickly resync messages with regard to a channel, and may do so without providing presence information.</p>
</section2> </section2>
<section2 topic="Delivering Messages to Users" anchor="concepts-delivery"> <section2 topic="Delivering Messages to Users" anchor="concepts-delivery">
<p> <p>
The primary model is that a user will join a channel over an extended period, and that the user (not a specific client used by the user) joins the channel. The primary subscription is with the clients bare JID. The user will receive messages from the channel and/or access channel presence from time to time with one or more clients. The primary model is that a user will join a channel over an extended period, and that the user (not a specific client used by the user) joins the channel. The primary subscription is with the client's bare JID. The user will receive messages from the channel and/or access channel presence from time to time with one or more clients.
</p> </p>
<p> <p>
Where a user has no clients active, the approach expected by MIX is that messages will be archived using MAM and that when clients come online they will use MAM to access messages that have not been delivered to the client. Following the rules of &rfc6121;, arriving MIX messages (which will be of type=groupchat) will be discarded if all clients are offline. Offline messages are not used with MIX. Where a user has no clients active, the approach expected by MIX is that messages will be archived using MAM and that when clients come online they will use MAM to access messages that have not been delivered to the client. Following the rules of &rfc6121;, arriving MIX messages (which will be of type=groupchat) will be discarded if all clients are offline. Offline messages are not used with MIX.
</p> </p>
<p> <p>
Online clients are handled use &xep0376;. Online clients are handled use &xep0376;.
The model is that the server will know which of the user's clients are interested in MIX messages, possibly filtered by MIX channel, and will deliver messages appropriately to these clients. MIX will simply send messages to the user's server addressed with the bare JID of the user. The user's server will then deliver messages to the user's clients, in a manner that is transparent to the MIX server. The same approach is used for sending presence updates to the user, noting that presence information is distributed by a channel to the bare JID of subscribers and then the user's server will distribute to clients as appropriate. The model is that the server will know which of the user's clients are interested in MIX messages, possibly filtered by MIX channel, and will deliver messages appropriately to these clients. MIX will send messages to the user's server addressed with the bare JID of the user. The user's server will then deliver messages to the user's clients, in a manner that is transparent to the MIX server. The same approach is used for sending presence updates to the user, noting that presence information is distributed by a channel to the bare JID of subscribers and then the user's server will distribute to clients as appropriate.
</p> </p>
</section2> </section2>
<section2 topic="User Presence in MIX" anchor="concepts-presence"> <section2 topic="User Presence in MIX" anchor="concepts-presence">
@ -236,10 +234,8 @@
]]></example> ]]></example>
</section3> </section3>
<section3 topic="Presence Node" anchor="presence-node"> <section3 topic="Presence Node" anchor="presence-node">
<p> <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. Each item in the presence node is identified by the full anonymized proxy JID, and contains the current presence value for that JID. The presence is encoded in the same way as data that would be sent in a presence message. The full anonymized JID is always used in this node. In MIX it is possible to have a 'presence-less channel' by not using this node. Access Control may be set to enforce that for each of the full JIDs in this list, the bare JID MUST be in the participants list. 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. Each item in the presence node is identified by the full proxy JID, and contains the current presence value for that JID. The presence is encoded in the same way as data that would be sent in a presence message. The full JID is always used in this node. In MIX it is possible to have a 'presence-less channel' by not using this node. Access Control may be set to enforce that for each of the full JIDs in this list, the bare JID MUST be in the participants list.
</p> </p>
<p>QUESTION: The current specification allows channels to be configured so that node subscription is not restricted to participants (although this restriction is the default). Is this flexibility desirable, or should we restrict to participants?</p> <p>QUESTION: The current specification allows channels to be configured so that node subscription is not restricted to participants (although this restriction is the default). Is this flexibility desirable, or should we restrict to participants?</p>
<p> <p>
@ -287,7 +283,7 @@
<li>'Date of Configuration Change'. Encoded as the item ID.</li> <li>'Date of Configuration Change'. Encoded as the item ID.</li>
<li>'Last Change Made By'. Bare JID of the user making the last change.</li> <li>'Last Change Made By'. Bare JID of the user making the last change.</li>
<li>'Owners'. List of bare JIDs with Owner rights as defined in ACL node. When a list is created, the JID creating the list is configured as an owner, unless this attribute is explicitly configured to another value. Owners will generally have full rights to make changes to channel configuration and access control.</li> <li>'Owners'. List of bare JIDs with Owner rights as defined in ACL node. When a list is created, the JID creating the list is configured as an owner, unless this attribute is explicitly configured to another value. Owners will generally have full rights to make changes to channel configuration and access control.</li>
<li>'Administrators'. List of bare JIDs with Administrator rights. An Administrator has rights to make changes to channel access control and configuration as defined in ACL node. An Administrator also has operational right on a channel, such a kicking users out of the channel. These rights are analogous to moderator rights defined in &xep0045;.</li> <li>'Administrators'. List of bare JIDs with Administrator rights. An Administrator has rights to make changes to channel access control and configuration as defined in ACL node. An Administrator also has operational right on a channel, such a kicking users out of the channel. These rights are analogous to moderator rights defined in <cite>Multi-User Chat</cite>.</li>
<li>'End of Life'. The date and time at which the channel will be automatically removed by the server. If this is not set, the channel is permanent.</li> <li>'End of Life'. The date and time at which the channel will be automatically removed by the server. If this is not set, the channel is permanent.</li>
<li>'Nodes Present'. Specifies which nodes are present: "participants"; "presence"; "subject"; "acl". Note that "config" is implicit, and "jidmap" is implied by "participants". </li> <li>'Nodes Present'. Specifies which nodes are present: "participants"; "presence"; "subject"; "acl". Note that "config" is implicit, and "jidmap" is implied by "participants". </li>
@ -367,7 +363,7 @@
]]></example> ]]></example>
<p>The result is returned in an extended disco results in a form whose type value is 'urn:xmpp:mix:0#serviceinfo'. <p>The result is returned in an extended disco results in a form whose type value is 'urn:xmpp:mix:0#serviceinfo'.
If the MIX service is mirrored to a MUC service for backwards-compatibility, this SHOULD be signaled by the inclusion of field with var='muc-mirror', the value of which is the mirrored MUC domain's JID. Where a MIX server supports MIX channels as &xep0045; rooms, the domain used for MUC may be different to the MIX domain or it MAY be the same.</p> If the MIX service is mirrored to a MUC service for backwards-compatibility, this SHOULD be signaled by the inclusion of field with var='muc-mirror', the value of which is the mirrored MUC domain's JID. Where a MIX server supports MIX channels as &xep0045; rooms, the domain used for MUC may be different to the MIX domain or it MAY be the same.</p>
<p>Note that the MIX service itself doesn't advertise support for &xep0313;, nor is support for generic &xep0060; advertised.</p> <p>Note that the MIX service doesn't advertise support for &xep0313;, nor is support for generic &xep0060; advertised.</p>
</section2> </section2>
<section2 topic='Discovering the Channels on a Service' anchor='disco-channel-list'> <section2 topic='Discovering the Channels on a Service' anchor='disco-channel-list'>
<p>The list of channels supported by a MIX service is obtained by a disco command.</p> <p>The list of channels supported by a MIX service is obtained by a disco command.</p>