From 5851e7adf27b6a9bf59f5f669fb1f4a56c40757f Mon Sep 17 00:00:00 2001
From: Steve Kille <Steve Kille>
Date: Tue, 4 Oct 2016 15:52:52 +0100
Subject: [PATCH] Remove references to "member/membership" and one to occupant

---
 xep-0369.xml | 60 ++++++++++++++++++++++++++--------------------------
 1 file changed, 30 insertions(+), 30 deletions(-)

diff --git a/xep-0369.xml b/xep-0369.xml
index abb48c25..a653fe6b 100644
--- a/xep-0369.xml
+++ b/xep-0369.xml
@@ -102,7 +102,7 @@
   </revision>
 </header>
 <section1 topic='Introduction' anchor='intro'>
-  <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>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 provide controls as to which users can participate in channels.</p>
   <p>Several reasons exist for replacing MUC:</p>
   <ul>
     <li>A number of use cases for group communication have emerged since MUC was first published.</li>
@@ -153,7 +153,7 @@
     <li>A user's participation in a channel outlives their client sessions. A client which is offline will not share presence within the channel, but the associated user will still be listed as an participant. </li>
     <li>Presence is sent to all participants using bare JID, whether or not the user has an online client. </li>
     <li>Online clients MAY register presence, which is then shared with participants who have subscribed to presence.</li>
-    <li>MIX decouples addressing of occupants from their nicknames, so that nickname changes do not affect addressing.</li>
+    <li>MIX decouples addressing of channel participants 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 (also anonymized) are then constructed, allowing visibility into the number of online resources participating in a channel.</li>
     <li>MIX requires client support and server support from the server providing the MIX service.  Although some protocol is shared with MUC, MUC clients are not interoperable with MIX servers.  This means that where a user chooses to use MIX, all of the users clients need to support MIX.</li>
   </ol>
@@ -239,13 +239,13 @@
     </p>
     <table caption="JID Visibility Modes">
       <tr><th>Mode</th><th>Description</th></tr>
-      <tr><td>'JID Visible'</td><td>In these channels, some or all participant JIDs are visible to all channel members.</td></tr>
+      <tr><td>'JID Visible'</td><td>In these channels, some or all participant JIDs are visible to all channel participants.</td></tr>
       
-      <tr><td>'JID&nbsp;Hidden'</td><td>In these channels, no participant JIDs are visible to channel members, but they are visible to channel administrators.</td></tr>
+      <tr><td>'JID&nbsp;Hidden'</td><td>In these channels, no participant JIDs are visible to channel participants, but they are visible to channel administrators.</td></tr>
     </table>
    
     <p>
-      A channel member may specify their preferences for JID visibility, with one of the following values:
+      A channel participant may specify their preferences for JID visibility, with one of the following values:
     </p>
     <table caption="JID Visibility Preference Options">
       <tr><th>Preference</th><th>Description</th></tr>
@@ -310,7 +310,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.
-      This node MAY be subscribed to for jid-visible channels that permit subscription to this node - this will allow users to see changes to channel membership.
+      This node MAY be subscribed to for jid-visible channels that permit subscription to this node - this will allow users to see changes to the channel participants.
       </p>
       <p>If the Participants Node is not used, information on channel participants is not shared.</p>
       <example caption="Value of Participants Node"><![CDATA[
@@ -405,23 +405,23 @@
         <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>'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> 'Members'.  List of JIDs with member rights.  The rights of members are configured in the configuration node.  </li>
+      
         <li>'Outcast'.  List of JIDs banned from subscribing to any nodes in the MIX channel.  </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>'Message Node Subscription'.  Controls who can subscribe to messages node: "members-only"; "participants-only"; "anyone".  Users with banned affiliation may not subscribe.  Default "participants-only".</li>
-        <li>'Participants Node Subscription'.  Controls who can subscribe to participants node: "members-only"; "participants-only"; "anyone"; "nobody".  Users with banned affiliation may not subscribe.  Default "participants-only".</li>
-        <li>'Participants Node Subscription'.  Controls who can subscribe to participants node: "members-only"; "participants-only"; "anyone"; admins-and-owners" "nobody".  Users with banned affiliation may not subscribe.  Default "participants-only".   Note that this value needs to be restricted to "admins-and-owners" for channels with JID visibility set to a value other than "jid-mandatory-visible".</li>
-        <li>'Presence Node Subscription'.  Controls who can subscribe to presence node: "members-only"; "participants-only"; "anyone"; "nobody".  Users with banned affiliation may not subscribe.  Default "participants-only".</li>
-        <li>'Subject Node Subscription'.  Controls who can subscribe to subject node: "members-only"; "participants-only"; "anyone"; "nobody".  Users with banned affiliation may not subscribe.  Default "participants-only".</li>
-        <li>'Configuration Node Access'.  Controls who can subscribe to and has read access configuration node: "members-only"; "participants-only"; "admins-and-owners"; "owners-only"; "anyone"; "nobody". Default "admins-and-owners".</li>
-        <li>'Information Node Access'.  Controls who can subscribe to and has read access acl node: "members-only"; "participants-only"; "admins-and-owners"; "owners-only"; "anyone"; "nobody". Default "participants-only".</li>
+        <li>'Message Node Subscription'.  Controls who can subscribe to messages node:  "participants-only"; "anyone".  Users with banned affiliation may not subscribe.  Default "participants-only".</li>
+        <li>'Participants Node Subscription'.  Controls who can subscribe to participants node: "participants-only"; "anyone"; "nobody".  Users with banned affiliation may not subscribe.  Default "participants-only".</li>
+        <li>'Participants Node Subscription'.  Controls who can subscribe to participants node:  "participants-only"; "anyone"; admins-and-owners" "nobody".  Users with banned affiliation may not subscribe.  Default "participants-only".   Note that this value needs to be restricted to "admins-and-owners" for channels with JID visibility set to a value other than "jid-mandatory-visible".</li>
+        <li>'Presence Node Subscription'.  Controls who can subscribe to presence node:  "participants-only"; "anyone"; "nobody".  Users with banned affiliation may not subscribe.  Default "participants-only".</li>
+        <li>'Subject Node Subscription'.  Controls who can subscribe to subject node: "participants-only"; "anyone"; "nobody".  Users with banned affiliation may not subscribe.  Default "participants-only".</li>
+        <li>'Configuration Node Access'.  Controls who can subscribe to and has read access configuration node:  "participants-only"; "admins-and-owners"; "owners-only"; "anyone"; "nobody". Default "admins-and-owners".</li>
+        <li>'Information Node Access'.  Controls who can subscribe to and has read access acl node:  "participants-only"; "admins-and-owners"; "owners-only"; "anyone"; "nobody". Default "participants-only".</li>
         <li>'Configuration Node Update'.  Controls who can modify configuration node: "owners-only"; "admins-and-owners". Default "admins-and-owners".</li>
         
         <li>'JID Visibility'. Choice of "jid-hidden", "jid-optionally-visible", "jid-mandatory-visible". </li>
         <li>'Open Presence'.  If selected, any client may register presence.  If not selected, only clients with bare JID in the participants list may register presence.</li>
         <li>'Allow Message Retraction'.  If this option is selected users will be able to retract messages sent to the MIX channel.</li>
-        <li>'Membership Extension by Invitation'.  This option extends a members only channel so that an invitation from a channel member will add the invited user to the members list.
+        <li>'Participation Extension by Invitation'.  This option extends a channel  so that an invitation from a channel participant will add the invited user to the allowed list.
         </li>
         <li>'No Private Messages'.  If this option is selected, private messages may not be used with the channel.</li>
 
@@ -916,7 +916,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
    </section3>
 
     <section3 topic='Leaving a Channel' anchor='usecase-user-leaving'>
-      <p>Users generally remain in a channel for an extended period of time.  In particular membership of the channel does not change when the user goes offline as happens with &xep0045;. So, leaving the channel is a permanent action for a user across all clients, not just a matter of telling the channel that the user is not currently available or for a single client.  In order to  leave a channel, a user sends a MIX "leave" command to the channel. When a user leaves the channel, the user's client will remove the channel from the user's roster.</p>
+      <p>Users generally remain in a channel for an extended period of time.  In particular the user remains as a participant the channel does not change when the user goes offline as happens with &xep0045;. So, leaving the channel is a permanent action for a user across all clients, not just a matter of telling the channel that the user is not currently available or for a single client.  In order to  leave a channel, a user sends a MIX "leave" command to the channel. When a user leaves the channel, the user's client will remove the channel from the user's roster.</p>
       <example caption="User Leaves a Channel"><![CDATA[
 <iq type='set'
     from='hag66@shakespeare.example'
@@ -928,7 +928,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
       <p>When the user leaves the channel, the MIX service is responsible for unsubscribing the user from all nodes in the channel and for removing the user from the participants and presence list.  If the user has online presence when the user leaves the channel, the change of presence status caused by removing the user's entry or entries from the presence node will ensure that subscribers to the presence node are correctly updated on presence status.
 
 
-        Deletion from the participants and presence functions as if the item (channel member) had been deleted using the PubSub retract mechanism with notification set to true.    Notification of the deletion is sent to clients subscribed to the participants  PubSub nodes, as shown in the example below.
+        Deletion from the participants and presence functions as if the item (channel participant) had been deleted using the PubSub retract mechanism with notification set to true.    Notification of the deletion is sent to clients subscribed to the participants  PubSub nodes, as shown in the example below.
         </p>
       <example caption="Reporting when User Leaves a Channel"><![CDATA[
 <message from='coven@mix.shakespeare.example' to='hecate@shakespeare.example' id='foo'>
@@ -953,7 +953,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
 
     <section3 topic="Setting a Nick" anchor="usecase-setting-nick">
     <p>
-      Each member of a channel may have a nick, which is how other users in the channel will see the user.  In some cases a nick is not needed, for example where a user reads messages in a channel but does not send messages or share presence information.    A nick MUST be present for a user to send a message to a channel or for a user's presence to be shared on a channel.   There are four ways that a user's nick can be obtained.   The choice of mechanism or mechanisms is dependent on channel policy:
+      Each participant of a channel may have a nick, which is how other users in the channel will see the user.  In some cases a nick is not needed, for example where a user reads messages in a channel but does not send messages or share presence information.    A nick MUST be present for a user to send a message to a channel or for a user's presence to be shared on a channel.   There are four ways that a user's nick can be obtained.   The choice of mechanism or mechanisms is dependent on channel policy:
     </p>
     <ol>
       <li>The nick is registered with the user account in some way, for example as part of user provisioning with nick configured as an attribute in a directory service.   This may be chosen by corporate services that wish to ensure consistent nick values for a set of users and channels.</li>
@@ -1056,7 +1056,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
     <section3 topic='Setting User Presence' anchor='usecase-user-presence'>
       <p>
 
-        A user joins a channel over an extended period, and membership in a channel does not generally change when user goes online or offline.   The users  membership of the channel is reflected by the user's bare JID in the participant node.   All messages to the channel are sent to this JID.
+        A user joins a channel over an extended period, and participation in a channel does not generally change when user goes online or offline.   The user's  participation in a channel is reflected by the user's bare JID in the participant node.   All messages to the channel are sent to this JID.
 
       </p>
       <p>
@@ -1064,7 +1064,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
         A user may share presence information with the channel, for one or more online clients.   Where a user shares presence information with a channel, the channel is entered by the user's server into the user's roster when the user subscribes 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.  The MIX channel will update the "urn:xmpp:mix:nodes:presence" node with any change of status and the updated presence information and then share this updated presence with users subscribed to this node, as described below.   When the user sets an explicit status, this is used to modify the presence node in the channel.   When a client being used by the user goes offline, the associated server will send presence status "unavailable" to the MIX channel, which will cause the full JID for that client to be removed from the presence node.
       </p>
       <p>
-        A channel may require that all channel members share presence information with the channel, which is represented in the "urn:xmpp:mix:nodes:presence" node.   If sharing presences is required by the channel, an XMPP client conforming to this specification SHALL share presence with the channel by including the channel in the user's roster. Note that the MIX server cannot generally enforce this, but it can require and enforce that when a message is sent to the channel, that the sender of the message is in the presence list.
+        A channel may require that all channel participants share presence information with the channel, which is represented in the "urn:xmpp:mix:nodes:presence" node.   If sharing presences is required by the channel, an XMPP client conforming to this specification SHALL share presence with the channel by including the channel in the user's roster. Note that the MIX server cannot generally enforce this, but it can require and enforce that when a message is sent to the channel, that the sender of the message is in the presence list.
       </p>
       <p>
       Presence status and availability is set in a MIX channel by standard presence stanzas sent to the MIX channel by the user's server.   User's wishing to receive presence updates will subscribe to the MIX channel presence node.   Presence updates are sent out to subscribing using standard XEP-0045 compatible presence stanzas.
@@ -1214,26 +1214,26 @@ the participant is not be subscribed to all nodes associated with the channel (i
       </p>
     </section3>
     <section3 topic='Inviting another user to join a Channel' anchor='usecase-user-invite'>
-      <p>When a channel member invites another user to join a channel, a sequence of steps are followed.
+      <p>When a channel participant invites another user to join a channel, a sequence of steps are followed.
 
       </p>
       <ol>
-        <li>The channel member sends to the channel requesting an invite for the user.</li>
+        <li>The channel participant sends to the channel requesting an invite for the user.</li>
         <li>The channel sends an invitation to the user requesting the invite.</li>
-        <li>The channel member sends the invitation to the invitee.</li>
+        <li>The channel participant sends the invitation to the invitee.</li>
         <li>The invitee uses the invitation to construct a request to join the channel.</li>
       </ol>
       <p> AUTHOR'S NOTES AND QUESTION:   Need to consider including declines.   To be expanded considerably and perhaps modified based on the following:  Dave Cridland notes: 
-        > There are three actors - the Member (who is the inviter), the Invitee, and
+        > There are three actors - the participant (who is the inviter), the Invitee, and
         > the Channel.
         > 
-        > A) The Member obtains an Invitation (containing a verifiable token) from the
+        > A) The participant obtains an Invitation (containing a verifiable token) from the
         > Channel. This allows the Channel to reject attempts to invite users who
         > should not be able to join the channel, but it might provide the token anyway
         > to avoid probes discovering who is allowed to join the room. This is your step
         > 1.
         > 
-        > B) The Member sends this Invitation (including the token) to the Invitee.
+        > B) The participant sends this Invitation (including the token) to the Invitee.
         > (Step 2)
         > 
         > C) The Invitee can optionally request from the Channel the validity of the
@@ -1242,8 +1242,8 @@ the participant is not be subscribed to all nodes associated with the channel (i
         > D) The Invitee can use the Invitation. (Step 3)
         > 
         > The idea behind my step C is that it allows a client to validate that the entity
-        > sending an invitation really is a member of the channel, and could
-        > legitimately act as a Member. This could be folded into (D), although it
+        > sending an invitation really is a participant of the channel, and could
+        > legitimately act as a participant. This could be folded into (D), although it
         > depends on whether we want to present the Invitation without knowing its
         > validity.
         > 
@@ -1493,7 +1493,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
     
     <li>Fully integrated MIX and MUC implementation, with MIX and MUC sharing a single domain and rooms/channels equivalent.</li>
     
-    <li>Partially integrated MIX and MUC implementation, with MIX and MUC using separate domains, but rooms/channel are common.  This means that each MIX channel will have MUC room of the same name and common membership.</li>
+    <li>Partially integrated MIX and MUC implementation, with MIX and MUC using separate domains, but rooms/channel are common.  This means that each MIX channel will have MUC room of the same name and same participants.</li>
   </ol>
   
   <p>The fully integrated approach would be transparent to clients.    Disco of a room or channel would show support for both MUC and MIX, which would enable a client to choose whether to use MUC or MIX.  The following example shows how a MIX service that also supported MUC would respond:</p>
@@ -1602,7 +1602,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
    <p>This section lists a number of capabilities not specified in this version of MIX which were provided in &xep0045;.   </p>
    <section2 topic="Password Controlled Channels" anchor="password-control">
      <p>
-       &xep0045; provides a mechanism to control access to MUC rooms using passwords.  An equivalent mechanism is not included in MIX, as it has a number of security issues.  Control of access to channels is better achieved using an explicit members list.
+       &xep0045; provides a mechanism to control access to MUC rooms using passwords.  An equivalent mechanism is not included in MIX, as it has a number of security issues.  Control of access to channels is better achieved using an explicit list of participants.
      </p>
    </section2>