mirror of https://github.com/moparisthebest/xeps
1.23pre4: commented out the outsider role
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1448 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre
parent
7c0340b31a
commit
6adc4a8dcf
133
xep-0045.xml
133
xep-0045.xml
|
|
@ -50,10 +50,10 @@
|
|||
<registry/>
|
||||
&stpeter;
|
||||
<revision>
|
||||
<version>1.23pre3</version>
|
||||
<date>in progress, updated 2007-10-18</date>
|
||||
<version>1.23pre4</version>
|
||||
<date>in progress, updated 2007-12-5</date>
|
||||
<initials>psa</initials>
|
||||
<remark><p>Added optional outsider role, including outsider use cases and admin management of outsider role; defined getmemberlist room configuration option; added direct invitation protoocol; corrected logic regarding admission of room owner/admin when room is full; defined service discovery extension field for associated LDAP group; specified that room config fields can be listed in extended room information; specified message format for affiliation change notifications if user is not in the room.</p></remark>
|
||||
<remark><p>Defined getmemberlist room configuration option; added direct invitation protoocol; corrected logic regarding admission of room owner/admin when room is full; defined service discovery extension field for associated LDAP group; specified that room config fields can be listed in extended room information; specified message format for affiliation change notifications if user is not in the room; added example showing use of Result Set Management.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>1.22</version>
|
||||
|
|
@ -453,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", "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>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>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 <user@host> 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 <user@host/resource> by which an online user is identified outside the context of a room; contrast with Bare JID and Room JID.</p>
|
||||
|
|
@ -468,7 +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>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>
|
||||
|
|
@ -532,14 +532,34 @@
|
|||
<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>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>
|
||||
<table caption='Roles'>
|
||||
<tr>
|
||||
<th>Name</th>
|
||||
<th>Support</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Moderator</td>
|
||||
<td>REQUIRED</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>None</td>
|
||||
<td>N/A (the absence of a role)</td>
|
||||
</tr>
|
||||
<!--
|
||||
<tr>
|
||||
<td>Outsider</td>
|
||||
<td>OPTIONAL</td>
|
||||
</tr>
|
||||
-->
|
||||
<tr>
|
||||
<td>Participant</td>
|
||||
<td>REQUIRED</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Visitor</td>
|
||||
<td>RECOMMENDED</td>
|
||||
</tr>
|
||||
</table>
|
||||
<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>
|
||||
|
|
@ -551,7 +571,7 @@
|
|||
<tr>
|
||||
<th>Privilege</th>
|
||||
<th>None</th>
|
||||
<th>Outsider</th>
|
||||
<!-- <th>Outsider</th> -->
|
||||
<th>Visitor</th>
|
||||
<th>Participant</th>
|
||||
<th>Moderator</th>
|
||||
|
|
@ -559,7 +579,7 @@
|
|||
<tr>
|
||||
<td>Present in Room</td>
|
||||
<td>No</td>
|
||||
<td>No</td>
|
||||
<!-- <td>No</td> -->
|
||||
<td>Yes</td>
|
||||
<td>Yes</td>
|
||||
<td>Yes</td>
|
||||
|
|
@ -567,7 +587,7 @@
|
|||
<tr>
|
||||
<td>Receive Messages</td>
|
||||
<td>No</td>
|
||||
<td>No</td>
|
||||
<!-- <td>No</td> -->
|
||||
<td>Yes</td>
|
||||
<td>Yes</td>
|
||||
<td>Yes</td>
|
||||
|
|
@ -575,7 +595,7 @@
|
|||
<tr>
|
||||
<td>Receive Occupant Presence</td>
|
||||
<td>No</td>
|
||||
<td>Yes*</td>
|
||||
<!-- <td>Yes*</td> -->
|
||||
<td>Yes</td>
|
||||
<td>Yes</td>
|
||||
<td>Yes</td>
|
||||
|
|
@ -583,7 +603,7 @@
|
|||
<tr>
|
||||
<td>Presence Broadcasted to Room</td>
|
||||
<td>No</td>
|
||||
<td>No</td>
|
||||
<!-- <td>No</td> -->
|
||||
<td>Yes*</td>
|
||||
<td>Yes</td>
|
||||
<td>Yes</td>
|
||||
|
|
@ -591,7 +611,7 @@
|
|||
<tr>
|
||||
<td>Change Availability Status</td>
|
||||
<td>No</td>
|
||||
<td>No</td>
|
||||
<!-- <td>No</td> -->
|
||||
<td>Yes</td>
|
||||
<td>Yes</td>
|
||||
<td>Yes</td>
|
||||
|
|
@ -599,7 +619,7 @@
|
|||
<tr>
|
||||
<td>Change Room Nickname</td>
|
||||
<td>No</td>
|
||||
<td>No</td>
|
||||
<!-- <td>No</td> -->
|
||||
<td>Yes*</td>
|
||||
<td>Yes</td>
|
||||
<td>Yes</td>
|
||||
|
|
@ -607,7 +627,7 @@
|
|||
<tr>
|
||||
<td>Send Private Messages</td>
|
||||
<td>No</td>
|
||||
<td>No</td>
|
||||
<!-- <td>No</td> -->
|
||||
<td>Yes*</td>
|
||||
<td>Yes</td>
|
||||
<td>Yes</td>
|
||||
|
|
@ -615,7 +635,7 @@
|
|||
<tr>
|
||||
<td>Invite Other Users</td>
|
||||
<td>No</td>
|
||||
<td>No</td>
|
||||
<!-- <td>No</td> -->
|
||||
<td>Yes*</td>
|
||||
<td>Yes*</td>
|
||||
<td>Yes</td>
|
||||
|
|
@ -623,7 +643,7 @@
|
|||
<tr>
|
||||
<td>Send Messages to All</td>
|
||||
<td>No</td>
|
||||
<td>No**</td>
|
||||
<!-- <td>No**</td> -->
|
||||
<td>No***</td>
|
||||
<td>Yes</td>
|
||||
<td>Yes</td>
|
||||
|
|
@ -631,7 +651,7 @@
|
|||
<tr>
|
||||
<td>Modify Subject</td>
|
||||
<td>No</td>
|
||||
<td>No</td>
|
||||
<!-- <td>No</td> -->
|
||||
<td>No*</td>
|
||||
<td>Yes*</td>
|
||||
<td>Yes</td>
|
||||
|
|
@ -639,7 +659,7 @@
|
|||
<tr>
|
||||
<td>Kick Participants and Visitors</td>
|
||||
<td>No</td>
|
||||
<td>No</td>
|
||||
<!-- <td>No</td> -->
|
||||
<td>No</td>
|
||||
<td>No</td>
|
||||
<td>Yes</td>
|
||||
|
|
@ -647,7 +667,7 @@
|
|||
<tr>
|
||||
<td>Grant Voice</td>
|
||||
<td>No</td>
|
||||
<td>No</td>
|
||||
<!-- <td>No</td> -->
|
||||
<td>No</td>
|
||||
<td>No</td>
|
||||
<td>Yes</td>
|
||||
|
|
@ -655,16 +675,16 @@
|
|||
<tr>
|
||||
<td>Revoke Voice</td>
|
||||
<td>No</td>
|
||||
<td>No</td>
|
||||
<!-- <td>No</td> -->
|
||||
<td>No</td>
|
||||
<td>No</td>
|
||||
<td>Yes****</td>
|
||||
</tr>
|
||||
</table>
|
||||
<p>* Default; configuration settings MAY modify this privilege.</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>
|
||||
<!-- <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>
|
||||
|
|
@ -723,7 +743,7 @@
|
|||
<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>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>
|
||||
|
|
@ -789,8 +809,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>
|
||||
|
|
@ -826,8 +846,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>** 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>
|
||||
<!-- <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>
|
||||
|
|
@ -941,7 +961,31 @@
|
|||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>If the full list of rooms is large (see <cite>XEP-0030</cite> for details), the service MAY return only a partial list of rooms.</p>
|
||||
<p>If the full list of rooms is large (see <cite>XEP-0030</cite> for details), the service MAY return only a partial list of rooms. If it does so, it SHOULD include a <set/> element (as defined in &xep0059;) to indicate that the list not the full result set.</p>
|
||||
<example caption='Service Returns Limited List of Disco Item Results'><![CDATA[
|
||||
<iq from='rooms.shakespeare.lit'
|
||||
id='disco-rsm-1'
|
||||
to='hag66@shakespeare.lit/pda'
|
||||
type='result'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#items'>
|
||||
<item jid='alls-well-that-ends-well@rooms.shakespeare.lit'
|
||||
<item jid='as-you-like-it@rooms.shakespeare.lit'
|
||||
<item jid='cleopatra@rooms.shakespeare.lit'
|
||||
<item jid='comedy-of-errors@rooms.shakespeare.lit'
|
||||
<item jid='coriolanus@rooms.shakespeare.lit'
|
||||
<item jid='cymbeline@rooms.shakespeare.lit'
|
||||
<item jid='hamlet@rooms.shakespeare.lit'
|
||||
<item jid='henry-the-fourth-one@rooms.shakespeare.lit'
|
||||
<item jid='henry-the-fourth-two@rooms.shakespeare.lit'
|
||||
<item jid='henry-the-fifth@rooms.shakespeare.lit'
|
||||
<set xmlns='http://jabber.org/protocol/rsm'>
|
||||
<first index='0'>alls-well-that-ends-well@rooms.shakespeare.lit</first>
|
||||
<last>henry-the-fifth@rooms.shakespeare.lit</last>
|
||||
<count>37</count>
|
||||
</set>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section2>
|
||||
<section2 topic='Querying for Room Information' anchor='disco-roominfo'>
|
||||
<p>Using the disco#info protocol, a user may also query a specific chat room for more detailed information about the room. A user SHOULD do so before entering a room in order to determine the privacy and security profile of the room configuration (see the <link url='#security'>Security Considerations</link> for details).</p>
|
||||
|
|
@ -1126,6 +1170,7 @@
|
|||
]]></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>
|
||||
|
|
@ -1274,6 +1319,7 @@
|
|||
]]></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'>
|
||||
|
|
@ -2151,7 +2197,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 ¬acceptable; 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>
|
||||
<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 ¬acceptable; 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>
|
||||
</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>
|
||||
|
|
@ -2310,7 +2356,7 @@
|
|||
<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 ¬acceptable; 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>
|
||||
<p>If allowed in accordance with room configuration, an occupant 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>
|
||||
|
|
@ -2987,7 +3033,7 @@
|
|||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
<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>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.</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'
|
||||
|
|
@ -3291,6 +3337,7 @@
|
|||
<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[
|
||||
|
|
@ -3332,7 +3379,7 @@
|
|||
]]></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>
|
||||
<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'
|
||||
|
|
@ -3374,6 +3421,7 @@
|
|||
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>
|
||||
|
|
@ -3545,11 +3593,9 @@
|
|||
<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?'
|
||||
|
|
@ -3861,11 +3907,9 @@
|
|||
<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?'
|
||||
|
|
@ -5538,7 +5582,6 @@ xmpp:darkcave@macbeth.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password
|
|||
<xs:restriction base='xs:NCName'>
|
||||
<xs:enumeration value='moderator'/>
|
||||
<xs:enumeration value='none'/>
|
||||
<xs:enumeration value='outsider'/>
|
||||
<xs:enumeration value='participant'/>
|
||||
<xs:enumeration value='visitor'/>
|
||||
</xs:restriction>
|
||||
|
|
|
|||
Loading…
Reference in New Issue