From 6e1c1f7c56ab495b8615663e9fadeb378d5108d4 Mon Sep 17 00:00:00 2001 From: Sam Whited Date: Thu, 18 Aug 2016 17:38:52 -0500 Subject: [PATCH] XEP-0369: Phrasing and grammar tweaks --- xep-0369.xml | 36 ++++++++++++++++-------------------- 1 file changed, 16 insertions(+), 20 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index a445f470..daa714c9 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -35,14 +35,12 @@ Steve.Kille@isode.com Steve.Kille@isode.com - &stpeter; - 0.2.1 - 2016-08-25 - egp -

Link Mauve (Emmanuel Gil PEYROT) editorial changes

 + 2016-08-26 + ssw, egp +

Phrasing and grammar.

 0.2 @@ -70,8 +68,8 @@ -

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.

-

MUC exists and works, so why replace it? There are several reasons:

+

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.

+

Several reasons exist for replacing MUC:

-

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).

+

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.

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.

-

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.

+

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.

- 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.

- 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.

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.

@@ -236,10 +234,8 @@ ]]> - -

- 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.

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?

@@ -287,7 +283,7 @@

  • 'Date of Configuration Change'. Encoded as the item ID.
  • 'Last Change Made By'. Bare JID of the user making the last change.
  • '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.
    • -
  • '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;.
    • +
  • '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 Multi-User Chat.
  • '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.
  • 'Nodes Present'. Specifies which nodes are present: "participants"; "presence"; "subject"; "acl". Note that "config" is implicit, and "jidmap" is implied by "participants".
    • @@ -367,7 +363,7 @@ ]]>

    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.

    -

    Note that the MIX service itself doesn't advertise support for &xep0313;, nor is support for generic &xep0060; advertised.

    +

    Note that the MIX service doesn't advertise support for &xep0313;, nor is support for generic &xep0060; advertised.

    The list of channels supported by a MIX service is obtained by a disco command.