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

1.23pre1

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1175 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-08-22 01:22:15 +00:00
parent 8ed2ba51aa
commit 3180fab3bd
1 changed files with 321 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

333
xep-0045.xml
View File

@ -49,6 +49,12 @@
</schemaloc>
<registry/>
&stpeter;
<revision>
<version>1.23pre1</version>
<date>in progress, updated 2007-08-20</date>
<initials>psa</initials>
<remark><p>Added outsider role, including outsider use cases and admin management of outsider role; defined "getmemberlist" room configuration option.</p></remark>
</revision>
<revision>
<version>1.22</version>
<date>2007-04-10</date>
@ -447,7 +453,7 @@
</section1>
<section1 topic='Terminology' anchor='terms'>
<section2 topic='General Terms' anchor='terms-general'>
<p>Affiliation -- a long-lived association or connection with a room; the possible affiliations are "owner", "admin", "member", and "outcast" (naturally it is also possible to have no affiliation); affiliation is distinct from role. An affiliation lasts across a user's visits to a room.</p>
<p>Affiliation -- a long-lived association or connection with a room; the possible affiliations are "owner", "admin", "member", "outcast", and "outsider" (naturally it is also possible to have no affiliation); affiliation is distinct from role. An affiliation lasts across a user's visits to a room.</p>
<p>Ban -- to remove a user from a room such that the user is not allowed to re-enter the room (until and unless the ban has been removed). A banned user has an affiliation of "outcast".</p>
<p>Bare JID -- the &lt;user@host&gt; by which a user is identified outside the context of any existing session or resource; contrast with Full JID and Room JID.</p>
<p>Full JID -- the &lt;user@host/resource&gt; by which an online user is identified outside the context of a room; contrast with Bare JID and Room JID.</p>
@ -462,6 +468,7 @@
<p>MUC -- the multi-user chat protocol for text-based conferencing specified in this document.</p>
<p>Occupant -- any Jabber user who is in a room (this is an "abstract class" and does not correspond to any specific role).</p>
<p>Outcast -- a user who has been banned from a room. An outcast has an affiliation of "outcast".</p>
<p>Outsider -- an unaffiliated user who is not in the room but who may interact with the room in certain limited ways. An outsider has a role of "outsider".</p>
<p>Participant -- an occupant who does not have administrative privileges; in a moderated room, a participant is further defined as having voice (in contrast to a visitor). A participant has a role of "participant".</p>
<p>Private Message -- a message sent from one occupant directly to another's room JID (not to the room itself for broadcasting to all occupants).</p>
<p>Role -- a temporary position or privilege level within a room, distinct from a user's long-lived affiliation with the room; the possible roles are "moderator", "participant", and "visitor" (it is also possible to have no defined role). A role lasts only for the duration of an occupant's visit to a room.</p>
@ -524,13 +531,15 @@
<section1 topic='Roles and Affiliations' anchor='connections'>
<p>There are two dimensions along which we can measure a user's connection with or position in a room. One is the user's long-lived affiliation with a room -- e.g., a user's status as an owner or an outcast. The other is a user's role while an occupant of a room -- e.g., an occupant's position as a moderator with the ability to kick visitors and participants. These two dimensions are distinct from each other, since an affiliation lasts across visits, while a role lasts only for the duration of a visit. In addition, there is no one-to-one correspondence between roles and affiliations; for example, someone who is not affiliated with a room may be a (temporary) moderator, and a member may be a participant or a visitor in a moderated room. These concepts are explained more fully below.</p>
<section2 topic='Roles' anchor='roles'>
<p>There are four defined roles that an occupant may have:</p>
<p>The following roles are defined:</p>
<ol start='1'>
<li>Moderator</li>
<li>Participant</li>
<li>Visitor</li>
<li>Outsider</li>
<li>None (the absence of a role)</li>
</ol>
<p>Support for the Moderator and Participant roles is REQUIRED. Support for the Visitor role is RECOMMENDED. Support for the Outsider role is OPTIONAL. (The "None" role is the absence of a role.)</p>
<p>Roles are temporary in that they do not necessarily persist across a user's visits to the room and MAY change during the course of an occupant's visit to the room. An implementation MAY persist roles across visits and SHOULD do so for moderated rooms (since the distinction between visitor and participant is critical to the functioning of a moderated room).</p>
<p>There is no one-to-one mapping between roles and affiliations (e.g., a member could be a participant or a visitor).</p>
<p>A moderator is the most powerful occupant within the context of the room, and can to some extent manage other occupants' roles in the room. A participant has fewer privileges than a moderator, although he or she always has the right to speak. A visitor is a more restricted role within the context of a moderated room, since visitors are not allowed to send messages to all occupants.</p>
@ -542,6 +551,7 @@
<tr>
<th>Privilege</th>
<th>None</th>
<th>Outsider</th>
<th>Visitor</th>
<th>Participant</th>
<th>Moderator</th>
@ -549,6 +559,7 @@
<tr>
<td>Present in Room</td>
<td>No</td>
<td>No</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
@ -556,13 +567,31 @@
<tr>
<td>Receive Messages</td>
<td>No</td>
<td>No</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Receive Occupant Presence</td>
<td>No</td>
<td>Yes*</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Presence Broadcasted to Room</td>
<td>No</td>
<td>No</td>
<td>Yes*</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Change Availability Status</td>
<td>No</td>
<td>No</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
@ -570,6 +599,7 @@
<tr>
<td>Change Room Nickname</td>
<td>No</td>
<td>No</td>
<td>Yes*</td>
<td>Yes</td>
<td>Yes</td>
@ -577,6 +607,7 @@
<tr>
<td>Send Private Messages</td>
<td>No</td>
<td>No</td>
<td>Yes*</td>
<td>Yes</td>
<td>Yes</td>
@ -584,6 +615,7 @@
<tr>
<td>Invite Other Users</td>
<td>No</td>
<td>No</td>
<td>Yes*</td>
<td>Yes*</td>
<td>Yes</td>
@ -592,12 +624,14 @@
<td>Send Messages to All</td>
<td>No</td>
<td>No**</td>
<td>No***</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Modify Subject</td>
<td>No</td>
<td>No</td>
<td>No*</td>
<td>Yes*</td>
<td>Yes</td>
@ -607,6 +641,7 @@
<td>No</td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>Yes</td>
</tr>
<tr>
@ -614,6 +649,7 @@
<td>No</td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>Yes</td>
</tr>
<tr>
@ -621,12 +657,14 @@
<td>No</td>
<td>No</td>
<td>No</td>
<td>Yes***</td>
<td>No</td>
<td>Yes****</td>
</tr>
</table>
<p>* Default; configuration settings MAY modify this privilege.</p>
<p>** An implementation MAY grant voice by default to visitors in unmoderated rooms.</p>
<p>*** A moderator MUST NOT be able to revoke voice privileges from an admin or owner.</p>
<p>** An implementation SHOULD allow outsiders to receive the presence of room occupants and to send messages to the room.</p>
<p>*** An implementation MAY grant voice by default to visitors in unmoderated rooms.</p>
<p>**** A moderator MUST NOT be able to revoke voice privileges from an admin or owner.</p>
</section3>
<section3 topic='Changing Roles' anchor='roles-change'>
<p>The ways in which an occupant's role changes are well-defined. Sometimes the change results from the occupant's own action (e.g., entering or exiting the room), whereas sometimes the change results from an action taken by a moderator, admin, or owner. If an occupant's role changes, a MUC service implementation MUST change the occupant's role to reflect the change and communicate the change to all occupants. Role changes and their triggering actions are specified in the following table.</p>
@ -672,7 +710,7 @@
</section3>
</section2>
<section2 topic='Affiliations' anchor='affil'>
<p>There are five defined affiliations that a user may have in relation to a room:</p>
<p>The following affiliations are defined:</p>
<ol start='1'>
<li>Owner</li>
<li>Admin</li>
@ -680,10 +718,12 @@
<li>Outcast</li>
<li>None (the absence of an affiliation)</li>
</ol>
<p>Support for the Owner affiliation is REQUIRED. Support for the Admin, Member, and Outcast affiliations is RECOMMENDED. (The "None" affiliation is the absence of an affiliation.)</p>
<p>These affiliations are long-lived in that they persist across a user's visits to the room and are not affected by happenings in the room. In addition, there is no one-to-one mapping between these affiliations and an occupant's role within the room. Affiliations are granted, revoked, and maintained based on the user's bare JID.</p>
<p>If a user without a defined affiliation enters a room, the user's affiliation is defined as "none"; however, this affiliation does not persist across visits (i.e., a service does not maintain a "none list" across visits).</p>
<p>The member affiliation provides a way for a room owner or admin to specify a "whitelist" of users who are allowed to enter a members-only room. When a member enters a members-only room, his or her affiliation does not change, no matter what his or her role is. The member affiliation also provides a way for users to effectively register with an open room and thus be lastingly associated with that room in some way (one result may be that the user's nickname is reserved in the room).</p>
<p>An outcast is a user who has been banned from a room and who is not allowed to enter the room.</p>
<p>An outsider is a user who may receive presence from room occupants and send messages to the room while not an occupant. A service should not send the outsider's presence to the room occupants or deliver room messages to the outsider.</p>
<p>Information about affiliations MUST be sent in all presence stanzas generated or reflected by the room and sent to occupants.</p>
<section3 topic='Privileges' anchor='affil-priv'>
<p>For the most part, affiliations exist in a hierarchy. For instance, an owner can do anything an admin can do, and an admin can do anything a member can do. Each affiliation has privileges not possessed by the next-lowest affiliation; these privileges are specified in the following table.</p>
@ -705,13 +745,21 @@
<td>Yes</td>
</tr>
<tr>
<td>Register with an Open Room</td>
<td>Register with Open Room</td>
<td>No</td>
<td>Yes</td>
<td>N/A</td>
<td>N/A</td>
<td>N/A</td>
</tr>
<tr>
<td>Retrieve Member List</td>
<td>No</td>
<td>No**</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Enter Members-Only Room</td>
<td>No</td>
@ -741,8 +789,8 @@
<td>No</td>
<td>No</td>
<td>No</td>
<td>Yes**</td>
<td>Yes**</td>
<td>Yes***</td>
<td>Yes***</td>
</tr>
<tr>
<td>Edit Admin List</td>
@ -778,7 +826,8 @@
</tr>
</table>
<p>* As a default, an unaffiliated user enters a moderated room as a visitor, and enters an open room as a participant. A member enters a room as a participant. An admin or owner enters a room as a moderator.</p>
<p>** An admin or owner MUST NOT be able to revoke moderation privileges from another admin or owner.</p>
<p>** Depending on the value of the "muc#roomconfig_getmemberlist" configuration option, an outsider MAY be allowed to retrieve the member list.</p>
<p>*** An admin or owner MUST NOT be able to revoke moderation privileges from another admin or owner.</p>
</section3>
<section3 topic='Changing Affiliations' anchor='affil-change'>
<p>The ways in which a user's affiliation changes are well-defined. Sometimes the change results from the user's own action (e.g., registering as a member of the room), whereas sometimes the change results from an action taken by an admin or owner. If a user's affiliation changes, a MUC service implementation MUST change the user's affiliation to reflect the change and communicate that to all occupants. Affiliation changes and their triggering actions are specified in the following table.</p>
@ -1071,6 +1120,150 @@
]]></code>
</section2>
</section1>
<section1 topic='Outsider Use Cases' anchor='outsider'>
<p>A service implementation MAY support the "outsider" role. This role enables an unaffiliated user who is not in the room to interact with the room in certain limited ways. The following settings and privileges are RECOMMENDED:</p>
<ul>
<li>An outsider SHOULD be allowed to send messages to all occupants of the room.</li>
<li>An outsider SHOULD be allowed to retrieve the list of room members.</li>
<li>An outsider SHOULD be allowed to see the presence of all occupants of the room.</li>
<li>An outsider SHOULD NOT receive messages sent to all occupants of the room.</li>
<li>An outsider SHOULD NOT have its presence broadcasted to the occupants of the room.</li>
</ul>
<p>The foregoing functionality is defined elsewhere in this document. This section describes special aspects of that functionality when applied to the outsider role.</p>
<section2 topic='Sending a Message' anchor='outsider-message'>
<p>When an outsider sends a message to all occupants of a room, the outsider is not "in" the room and therefore does not have a roomnick. Therefore the room MUST send the message from the JID of the room itself. In order for room occupants to reply to the message if desired, the message MUST include an indication of the sender's full JID, as illustrated in the following example.</p>
<example caption='Outsider Sends Message to Room'><![CDATA[
<message
from='macbeth@shakespeare.lit/castle'
to='darkcave@macbeth.shakespeare.lit'
type='groupchat'>
<body>How now?</body>
</message>
]]></example>
<example caption='Room Reflects Message to all Occupants'><![CDATA[
from='macbeth@shakespeare.lit/castle'
<message
from='darkcave@macbeth.shakespeare.lit'
to='crone1@shakespeare.lit/desktop'
type='groupchat'>
<body>How now?</body>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='none'
jid='macbeth@shakespeare.lit/castle'
role='outsider'/>
</x>
</message>
<message
from='darkcave@macbeth.shakespeare.lit'
to='wiccarocks@shakespeare.lit/laptop'
type='groupchat'>
<body>How now?</body>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='none'
jid='macbeth@shakespeare.lit/castle'
role='outsider'/>
</x>
</message>
<message
from='darkcave@macbeth.shakespeare.lit'
to='hag66@shakespeare.lit/pda'
type='groupchat'>
<body>How now?</body>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='none'
jid='macbeth@shakespeare.lit/castle'
role='outsider'/>
</x>
</message>
]]></example>
</section2>
<section2 topic='Retrieving the Member List' anchor='outsider-memberlist'>
<p>An outsider can retrieve the member list by sending an IQ-get to the room containing a request for all users who have an affiliation of "member".</p>
<example caption='Outsider Requests Member List'><![CDATA[
<iq from='macbeth@shakespeare.lit/castle'
id='getmembers1'
to='darkcave@macbeth.shakespeare.lit'
type='get'>
<query xmlns='http://jabber.org/protocol/muc#admin'>
<item affiliation='member'/>
</query>
</iq>
]]></example>
<p>If the outsider is allowed to retrieve the member list, the room shall return the list, where the 'jid' attribute shows the bare JIDs of the members (and without including the 'nick' and 'role' attributes).</p>
<example caption='Service Sends Member List to Outsider'><![CDATA[
<iq from='darkcave@macbeth.shakespeare.lit'
id='getmembers'
to='macbeth@shakespeare.lit/castle'
type='result'>
<query xmlns='http://jabber.org/protocol/muc#admin'>
<item affiliation='member' jid='hag66@shakespeare.lit'/>
<item affiliation='member' jid='wiccarocks@shakespeare.lit'/>
</query>
</iq>
]]></example>
<p>If the outsider is not allowed to retrieve the member list, the room shall return an error of &forbidden;.</p>
<example caption='Service Returns Forbidden Error'><![CDATA[
<iq from='darkcave@macbeth.shakespeare.lit'
id='getmembers'
to='macbeth@shakespeare.lit/castle'
type='error'>
<error code='403' type='auth'>
<forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
]]></example>
</section2>
<section2 topic='Receiving Occupant Presence' anchor='outsider-presence'>
<p>In order to receive presence from the room occupants, an outsider sends presence to the room's JID with no resource:</p>
<example caption='Occupant Sends Presence to Room'><![CDATA[
<presence
from='macbeth@shakespeare.lit/castle'
to='darkcave@macbeth.shakespeare.lit'>
<c xmlns='http://jabber.org/protocol/caps'
node='http://exodus.jabberstudio.org/#0.9.1'
ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
</presence>
]]></example>
<example caption='Room Sends Presence of Occupants to Outsider'><![CDATA[
<presence from='darkcave@macbeth.shakespeare.lit/firstwitch' to='macbeth@shakespeare.lit/castle'>
<c xmlns='http://jabber.org/protocol/caps'
node='http://psi-im.org/#0.11'
ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='owner'
jid='crone1@shakespeare.lit/desktop'
role='moderator'/>
</x>
</presence>
<presence from='darkcave@macbeth.shakespeare.lit/secondwitch' to='macbeth@shakespeare.lit/castle'>
<c xmlns='http://jabber.org/protocol/caps'
node='http://exodus.jabberstudio.org/#0.9.1'
ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='admin'
jid='wiccarocks@shakespeare.lit/laptop'
role='moderator'/>
</x>
</presence>
<presence from='darkcave@macbeth.shakespeare.lit/thirdwitch' to='macbeth@shakespeare.lit/castle'>
<c xmlns='http://jabber.org/protocol/caps'
node='http://www.chatopus.com/#2.2'
ver='zHyEOgxTrkpSdGcQKH8EFPLsriY='/>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='member'
jid='hag66@shakespeare.lit/laptop'
role='participant'/>
</x>
</presence>
[ ... ]
]]></example>
</section2>
</section1>
<section1 topic='Occupant Use Cases' anchor='user'>
<p>The main actor in a multi-user chat environment is the occupant, who can be said to be located "in" a multi-user chat room and to participate in the discussions held in that room (for the purposes of this specification, participants and visitors are considered to be "mere" occupants, since they possess no administrative privileges). As will become clear, the protocol elements proposed in this document to fulfill the occupant use cases fall into three categories:</p>
<ol start='1'>
@ -1947,7 +2140,7 @@
<body>Harpier cries: 'tis time, 'tis time.</body>
</message>
]]></example>
<p>If the sender is a visitor (i.e., does not have voice in a moderated room), the service MAY return a &forbidden; error to the sender and MUST NOT reflect the message to all occupants. If the sender is not an occupant of the room, the service SHOULD return a &notacceptable; error to the sender and SHOULD NOT reflect the message to all occupants; the only exception to this rule is that an implementation MAY allow users with certain privileges (e.g., a room owner, room admin, or service-level admin) to send messages to the room even if those users are not occupants.</p>
<p>If the sender is a visitor (i.e., does not have voice in a moderated room), the service MAY return a &forbidden; error to the sender and MUST NOT reflect the message to all occupants. If the sender is not an occupant of the room, the service SHOULD return a &notacceptable; error to the sender and SHOULD NOT reflect the message to all occupants; the only exception to this rule is that an implementation MAY allow users with certain privileges (e.g., a room owner, room admin, service-level admin, or outsider) to send messages to the room even if those users are not occupants.</p>
</section2>
<section2 topic='Registering with a Room' anchor='register'>
<p>An implementation MAY allow an unaffiliated user (in a moderated room, normally a participant) to register with a room and thus become a member of the room (conversely, an implementation MAY restrict this privilege and allow only room admins to add new members). In particular, it is not possible to join a members-only room without being on the member list, so an entity may need to request membership in order to join such a room.</p>
@ -2106,6 +2299,9 @@
]]></example>
<p>If a user has registered with a room, the room MAY choose to restrict the user to use of the registered nickname only in that room. If it does so, it SHOULD return a &notacceptable; error to the user if the user attempts to join the room with a roomnick other than the user's registered roomnick (this enables a room to "lock down" roomnicks for consistent identification of occupants).</p>
</section2>
<section2 topic='Getting Member List' anchor='getmemberlist'>
<p>If allowed in accordance with room configuration, an occupant or outsider MAY be allowed to retrieve the list of room members. For details, see the <link url='#modifymember'>Modifying the Member List</link> section of this document.</p>
</section2>
<section2 topic='Discovering Reserved Room Nickname' anchor='reservednick'>
<p>A user MAY have a reserved room nickname, for example through explicit room registration, database integration, or nickname "lockdown". A user SHOULD discover his or her reserved nickname before attempting to enter the room. This is done by sending a Service Discovery information request to the room JID while specifying a well-known Service Discovery node of "x-roomuser-item".</p>
<example caption="User Requests Reserved Nickname"><![CDATA[
@ -2775,7 +2971,7 @@
</query>
</iq>
]]></example>
<p>(A service SHOULD also return the member list to any occupant in a members-only room; i.e., it SHOULD NOT generate a &forbidden; error when a member in the room requests the member list. This functionality may assist clients in showing all the existing members even if some of them are not in the room, e.g. to help a member determine if another user should be invited.)</p>
<p>Note: A service SHOULD also return the member list to any occupant in a members-only room; i.e., it SHOULD NOT generate a &forbidden; error when a member in the room requests the member list. This functionality may assist clients in showing all the existing members even if some of them are not in the room, e.g. to help a member determine if another user should be invited. A service SHOULD also allow any member to retrieve the member list even if not yet an occupant. A service MAY also allow configured "outsiders" to retrieve the member list.</p>
<p>The service MUST then return the full member list to the admin qualified by the 'http://jabber.org/protocol/muc#admin' namespace; each item MUST include the 'affiliation' and 'jid' attributes and MAY include the 'nick' and 'role' attributes for each members that is currently an occupant.</p>
<example caption='Service Sends Member List to Admin'><![CDATA[
<iq from='darkcave@macbeth.shakespeare.lit'
@ -3083,6 +3279,89 @@
<p>If the admin approves the registration request, the service shall register the user with the room.</p>
<p>More advanced registration approval mechanisms (e.g., retrieving a list of registration requests using &xep0050; as is done in &xep0060;) are out of scope for this document.</p>
</section2>
<section2 topic='Granting Outsider Status' anchor='grantoutsider'>
<p>An admin can grant outsider status to a user by changing the role associated with the user's bare JID to "outsider".</p>
<example caption='Admin Grants Outsider Status'><![CDATA[
<iq from='crone1@shakespeare.lit/desktop'
id='outsider1'
to='darkcave@macbeth.shakespeare.lit'
type='set'>
<query xmlns='http://jabber.org/protocol/muc#admin'>
<item role='outsider' jid='macbeth@shakespeare.lit'/>
</query>
</iq>
]]></example>
<p>The service MUST add the user to the outsider list and then inform the admin of success:</p>
<example caption='Service Informs Admin of Success'><![CDATA[
<iq from='darkcave@macbeth.shakespeare.lit'
id='outsider1'
to='crone1@shakespeare.lit/desktop'
type='result'/>
]]></example>
</section2>
<section2 topic='Revoking Outsider Status' anchor='revokeoutsider'>
<p>An admin can revoke a user's outsider status by changing the user's role to "none":</p>
<example caption='Admin Revokes Outsider Status'><![CDATA[
<iq from='crone1@shakespeare.lit/desktop'
id='outsider2'
to='darkcave@macbeth.shakespeare.lit'
type='set'>
<query xmlns='http://jabber.org/protocol/muc#admin'>
<item role='none' jid='macbeth@shakespeare.lit'/>
</query>
</iq>
]]></example>
<p>The service MUST remove the user from the outsider list and then inform the moderator of success:</p>
<example caption='Service Informs Admin of Success'><![CDATA[
<iq from='darkcave@macbeth.shakespeare.lit'
id='outsider2'
to='crone1@shakespeare.lit/desktop'
type='result'/>
]]></example>
</section2>
<section2 topic='Modifying the Outsider List' anchor='modifyoutsider'>
<p>The outsider list is a list of users who are allowed to interact with the room from the outside without having any other affiliation with the room. (If a service allows unaffiliated users to interact with the room from outside, it SHOULD also allow affiliated users -- i.e., members, admins, and owners -- to do so.) </p>
<example caption='Admin Requests Outsider List'><![CDATA[
<iq from='crone1@shakespeare.lit/desktop'
id='outsider3'
to='darkcave@macbeth.shakespeare.lit'
type='get'>
<query xmlns='http://jabber.org/protocol/muc#admin'>
<item role='outsider'/>
</query>
</iq>
]]></example>
<example caption='Service Sends Outsider List to Admin'><![CDATA[
<iq from='darkcave@macbeth.shakespeare.lit'
id='outsider3'
to='crone1@shakespeare.lit/desktop'
type='result'>
<query xmlns='http://jabber.org/protocol/muc#admin'>
<item role='outsider' jid='shakespeare.lit'/>
<item role='outsider' jid='romeo@montague.lit'/>
<item role='outsider' jid='juliet@capulet.lit'/>
</query>
</iq>
]]></example>
<p>The admin MAY then modify the outsider list. In order to do so, the admin MUST send the changed items (i.e., only the "delta") to the service; each item MUST include the 'role' attribute (set to a value of "outsider" or "none") and 'jid' attribute but SHOULD NOT include the 'nick' attribute and MUST NOT include the 'affiliatino' attribute (which is used to manage affiliations such as member rather than the outsider role):</p>
<example caption='Admin Sends Modified Outsider List to Service'><![CDATA[
<iq from='crone1@shakespeare.lit/desktop'
id='outsider4'
to='darkcave@macbeth.shakespeare.lit'
type='set'>
<query xmlns='http://jabber.org/protocol/muc#admin'>
<item role='none' jid='romeo@capulet.lit'/>
</query>
</iq>
]]></example>
<p>The service MUST modify the outsider list and then inform the admin of success:</p>
<example caption='Service Informs Admin of Success'><![CDATA[
<iq from='darkcave@macbeth.shakespeare.lit'
id='outsider4'
to='crone1@shakespeare.lit/desktop'
type='result'/>
]]></example>
</section2>
</section1>
<section1 topic='Owner Use Cases' anchor='owner'>
<p>Every room MUST have at least one owner, and that owner (or a successor) is a long-lived attribute of the room for as long as the room exists (e.g., the owner does not lose ownership on exiting a persistent room). This document assumes that the (initial) room owner is the individual who creates the room and that only a room owner has the right to change defining room configuration settings such as the room type. Ideally, room owners will be able to specify not only the room types (password-protected, members-only, etc.) but also certain attributes of the room as listed in the <link url='#reqs'>Requirements</link> section of this document. In addition, it would be good if an owner were able to specify the JIDs of other owners, but that shall be determined by the implementation.</p>
@ -3246,6 +3525,19 @@
<option label='Participant'><value>participant</value></option>
<option label='Visitor'><value>visitor</value></option>
</field>
<field
label='Roles and Affiliations that May Retrieve Member List'
type='list-multi'
var='muc#roomconfig_getmemberlist'>
<value>moderator</value>
<value>participant</value>
<value>visitor</value>
<value>outsider</value>
<option label='Moderator'><value>moderator</value></option>
<option label='Participant'><value>participant</value></option>
<option label='Visitor'><value>visitor</value></option>
<option label='Outsider'><value>outsider</value></option>
</field>
<field
label='Make Room Publicly Searchable?'
type='boolean'
@ -3549,6 +3841,19 @@
<option label='Participant'><value>participant</value></option>
<option label='Visitor'><value>visitor</value></option>
</field>
<field
label='Roles and Affiliations that May Retrieve Member List'
type='list-multi'
var='muc#roomconfig_getmemberlist'>
<value>moderator</value>
<value>participant</value>
<value>visitor</value>
<value>outsider</value>
<option label='Moderator'><value>moderator</value></option>
<option label='Participant'><value>participant</value></option>
<option label='Visitor'><value>visitor</value></option>
<option label='Outsider'><value>outsider</value></option>
</field>
<field
label='Make Room Publicly Searchable?'
type='boolean'
@ -4381,6 +4686,10 @@
var='muc#roomconfig_enablelogging'
type='boolean'
label='Whether to Enable Public Logging of Room Conversations'/>
<field
var='muc#roomconfig_getmemberlist'
type='list-multi'
label='Roles and Affiliations that May Retrieve Member List'/>
<field
var='muc#roomconfig_lang'
type='text-single'