From 3180fab3bd8bcc6248235526536310850b761efa Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Wed, 22 Aug 2007 01:22:15 +0000 Subject: [PATCH] 1.23pre1 git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1175 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0045.xml | 333 +++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 321 insertions(+), 12 deletions(-) diff --git a/xep-0045.xml b/xep-0045.xml index bb0178e6..3e334370 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -49,6 +49,12 @@ &stpeter; + + 1.23pre1 + in progress, updated 2007-08-20 + psa +

Added outsider role, including outsider use cases and admin management of outsider role; defined "getmemberlist" room configuration option.

 + 1.22 2007-04-10 @@ -447,7 +453,7 @@ -

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.

+

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.

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

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.

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.

@@ -462,6 +468,7 @@

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

+

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

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.

@@ -524,13 +531,15 @@

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.

-

There are four defined roles that an occupant may have:

+

The following roles are defined:

  1. Moderator
  2. Participant
  3. Visitor
    4. +
  4. Outsider
  5. None (the absence of a role)
+

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

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

There is no one-to-one mapping between roles and affiliations (e.g., a member could be a participant or a visitor).

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.

@@ -542,6 +551,7 @@ Privilege None + Outsider Visitor Participant Moderator @@ -549,6 +559,7 @@ Present in Room No + No Yes Yes Yes @@ -556,13 +567,31 @@ Receive Messages No + No Yes Yes Yes + + Receive Occupant Presence + No + Yes* + Yes + Yes + Yes + + + Presence Broadcasted to Room + No + No + Yes* + Yes + Yes + Change Availability Status No + No Yes Yes Yes @@ -570,6 +599,7 @@ Change Room Nickname No + No Yes* Yes Yes @@ -577,6 +607,7 @@ Send Private Messages No + No Yes* Yes Yes @@ -584,6 +615,7 @@ Invite Other Users No + No Yes* Yes* Yes @@ -592,12 +624,14 @@ Send Messages to All No No** + No*** Yes Yes Modify Subject No + No No* Yes* Yes @@ -607,6 +641,7 @@ No No No + No Yes @@ -614,6 +649,7 @@ No No No + No Yes @@ -621,12 +657,14 @@ No No No - Yes*** + 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.

+

** An implementation SHOULD allow outsiders to receive the presence of room occupants and to send messages to the room.

+

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

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.

@@ -672,7 +710,7 @@ -

There are five defined affiliations that a user may have in relation to a room:

+

The following affiliations are defined:

  1. Owner
  2. Admin
    3. @@ -680,10 +718,12 @@
  3. Outcast
  4. None (the absence of an affiliation)
+

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

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.

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.

+

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.

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.

@@ -705,13 +745,21 @@ Yes - Register with an Open Room + Register with Open Room No Yes N/A N/A N/A + + Retrieve Member List + No + No** + Yes + Yes + Yes + Enter Members-Only Room No @@ -741,8 +789,8 @@ No No No - Yes** - Yes** + Yes*** + Yes*** Edit Admin List @@ -778,7 +826,8 @@

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

+

** Depending on the value of the "muc#roomconfig_getmemberlist" configuration option, an outsider MAY be allowed to retrieve the member list.

+

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

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.

@@ -1071,6 +1120,150 @@ ]]> + +

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:

+
    +
  • An outsider SHOULD be allowed to send messages to all occupants of the room.
    • +
  • An outsider SHOULD be allowed to retrieve the list of room members.
    • +
  • An outsider SHOULD be allowed to see the presence of all occupants of the room.
    • +
  • An outsider SHOULD NOT receive messages sent to all occupants of the room.
    • +
  • An outsider SHOULD NOT have its presence broadcasted to the occupants of the room.
    • +
+

The foregoing functionality is defined elsewhere in this document. This section describes special aspects of that functionality when applied to the outsider role.

+ +

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.

+ + How now? + + ]]> + + How now? + + + + + + How now? + + + + + + How now? + + + + + ]]> + + +

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

+ + + + + + ]]> +

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

+ + + + + + + ]]> +

If the outsider is not allowed to retrieve the member list, the room shall return an error of &forbidden;.

+ + + + + + ]]> + + +

In order to receive presence from the room occupants, an outsider sends presence to the room's JID with no resource:

+ + + + ]]> + + + + + + + + + + + + + + + + + + + + + +[ ... ] + ]]> + +

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:

    @@ -1947,7 +2140,7 @@ Harpier cries: 'tis time, 'tis time. ]]> -

    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.

    +

    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.

    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.

    @@ -2106,6 +2299,9 @@ ]]>

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

     + +

    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 Modifying the Member List section of this document.

    +

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

    ]]> -

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

    +

    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.

    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.

    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.

     + +

    An admin can grant outsider status to a user by changing the role associated with the user's bare JID to "outsider".

    + + + + + + ]]> +

    The service MUST add the user to the outsider list and then inform the admin of success:

    + + ]]> +     + +

    An admin can revoke a user's outsider status by changing the user's role to "none":

    + + + + + + ]]> +

    The service MUST remove the user from the outsider list and then inform the moderator of success:

    + + ]]> +     + +

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

    + + + + + + ]]> + + + + + + + + ]]> +

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

    + + + + + + ]]> +

    The service MUST modify the outsider list and then inform the admin of success:

    + + ]]> +

    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.

    @@ -3246,6 +3525,19 @@ + + moderator + participant + visitor + outsider + + + + + participant + + moderator + participant + visitor + outsider + + + + + +