From 275711c3aa04060c7c9a659da27572384e0a8aa4 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Wed, 9 Jan 2008 19:32:18 +0000 Subject: [PATCH] ldap fix, removed outsider stuff git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1558 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0045.xml | 261 +-------------------------------------------------- 1 file changed, 1 insertion(+), 260 deletions(-) diff --git a/xep-0045.xml b/xep-0045.xml index d5a77477..78a18bee 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -468,7 +468,6 @@

MUC -- the multi-user chat protocol for text-based conferencing specified in this document.

Occupant -- any Jabber user who is in a room (this is an "abstract class" and does not correspond to any specific role).

Outcast -- a user who has been banned from a room. An outcast has an affiliation of "outcast".

-

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

Private Message -- a message sent from one occupant directly to another's room JID (not to the room itself for broadcasting to all occupants).

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.

@@ -545,12 +544,6 @@ None N/A (the absence of a role) - Participant REQUIRED @@ -571,7 +564,6 @@ Privilege None - Visitor Participant Moderator @@ -579,7 +571,6 @@ Present in Room No - Yes Yes Yes @@ -587,7 +578,6 @@ Receive Messages No - Yes Yes Yes @@ -595,7 +585,6 @@ Receive Occupant Presence No - Yes Yes Yes @@ -603,7 +592,6 @@ Presence Broadcasted to Room No - Yes* Yes Yes @@ -611,7 +599,6 @@ Change Availability Status No - Yes Yes Yes @@ -619,7 +606,6 @@ Change Room Nickname No - Yes* Yes Yes @@ -627,7 +613,6 @@ Send Private Messages No - Yes* Yes Yes @@ -635,7 +620,6 @@ Invite Other Users No - Yes* Yes* Yes @@ -643,7 +627,6 @@ Send Messages to All No - No*** Yes Yes @@ -651,7 +634,6 @@ Modify Subject No - No* Yes* Yes @@ -659,7 +641,6 @@ Kick Participants and Visitors No - No No Yes @@ -667,7 +648,6 @@ Grant Voice No - No No Yes @@ -675,14 +655,12 @@ Revoke Voice No - No No Yes****

* Default; configuration settings MAY modify this privilege.

-

** An implementation MAY grant voice by default to visitors in unmoderated rooms.

*** A moderator MUST NOT be able to revoke voice privileges from an admin or owner.

@@ -743,7 +721,6 @@

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

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

An outcast is a user who has been banned from a room and who is not allowed to enter the room.

-

Information about affiliations MUST be sent in all presence stanzas generated or reflected by the room and sent to occupants.

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.

@@ -846,7 +823,6 @@

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

-

** An admin or owner MUST NOT be able to revoke moderation privileges from another admin or owner.

 @@ -1060,7 +1036,7 @@ 3 - Witches + dc=lit,dc=shakespeare,cn=witches en @@ -1170,156 +1146,6 @@ ]]> -

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:

    @@ -3353,91 +3179,6 @@

    If the admin approves the registration request, the service shall register the user with the room.

    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.

    -

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