From 72517af33b1e2622aa7ed9f5834ad378818cd84a Mon Sep 17 00:00:00 2001 From: stpeter Date: Mon, 15 Aug 2011 15:27:24 -0600 Subject: [PATCH] 1.25rc4 --- xep-0045.xml | 194 +++++++++++++++++++++++++++++++-------------------- 1 file changed, 119 insertions(+), 75 deletions(-) diff --git a/xep-0045.xml b/xep-0045.xml index dfca8d6e..f3f2d843 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -47,7 +47,7 @@ &stpeter; - 1.25rc3 + 1.25rc4 in progress, last updated 2011-08-15 psa @@ -436,7 +436,7 @@ -

This document addresses common requirements related to configuration of, participation in, and administration of individual text-based conference rooms. All of the requirements addressed herein apply at the level of the individual room and are "common" in the sense that they have been widely discussed within the Jabber community or are familiar from existing text-based conference environments (e.g., Internet Relay Chat as defined in &rfc1459; and its successors: &rfc2810;, &rfc2811;, &rfc2812;, &rfc2813;).

+

This document addresses common requirements related to configuration of, participation in, and administration of individual text-based conference rooms. All of the requirements addressed herein apply at the level of the individual room and are "common" in the sense that they have been widely discussed within the Jabber/XMPP community or are familiar from existing text-based conference environments (e.g., Internet Relay Chat as defined in &rfc1459; and its successors: &rfc2810;, &rfc2811;, &rfc2812;, &rfc2813;).

This document explicitly does not address the following:

  • Relationships between rooms (e.g., hierarchies of rooms)
    • @@ -503,7 +503,7 @@
    Kick
    To temporarily remove a participant or visitor from a room; the user is allowed to re-enter the room at any time. A kicked user has a role of "none".
    Logging
    Storage of discussions that occur within a room for public retrieval outside the context of the room.
    Member
    A user who is on the "whitelist" for a members-only room or who is registered with an open room. A member has an affiliation of "member".
     -
    Moderator
    A room role that is usually associated with room admins but that may be granted to non-admins; is allowed to kick users, grant and revoke voice, etc. A moderator has a role of "moderator".
     +
    Moderator
    A room role that is usually associated with room admins but that can be granted to non-admins; is allowed to kick users, grant and revoke voice, etc. A moderator has a role of "moderator".
    MUC
    The multi-user chat protocol for text-based conferencing specified in this document.
    Multi-Session Nick
    If allowed by the service, a user can associate more than one full JID with the same room JID (e.g., the user juliet@capulet.lit is allowed to log in simultaneously as the nick "JuliC" in the characters@chat.shakespeare.lit chatroom from both juliet@capulet.lit/balcony and juliet@capulet.lit/chamber). Multi-session nicks are not currently defined in this document.
    Occupant
    Any user who is in a room (this is an "abstract class" and does not correspond to any specific role).
     @@ -514,7 +514,7 @@
    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.
    Room
    A virtual space that users figuratively enter in order to participate in real-time, text-based conferencing with other users.
    Room Administrator
    A user empowered by the room owner to perform administrative functions such as banning users; however, a room administrator is not allowed to change the room configuration or to destroy the room. An admin has an affiliation of "admin".
     -
    Room ID
    The localpart of a Room JID, which may be opaque and thus lack meaning for human users (see under Business Rules for syntax); contrast with Room Name.
     +
    Room ID
    The localpart of a Room JID, which might be opaque and thus lack meaning for human users (see under Business Rules for syntax); contrast with Room Name.
    Room JID
    The <room@service> address of a room.
    Room Name
    A user-friendly, natural-language name for a room, configured by the room owner and presented in Service Discovery queries; contrast with Room ID.
    Room Nickname
    The resourcepart of an Occupant JID (see Business Rules for syntax); this is the "friendly name" by which an occupant is known in the room.
     @@ -609,7 +609,7 @@

    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 (depending on room configuration, it is even possible that visitors' presence will not be broadcasted to the room).

    +

    A moderator is the most powerful role 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 (depending on room configuration, it is even possible that visitors' presence will not be broadcasted to the room).

    Roles are granted, revoked, and maintained based on the occupant's room nickname or full JID rather than bare JID. The privileges associated with these roles, as well as the actions that trigger changes in roles, are defined below.

    Information about roles MUST be sent in all presence stanzas generated or reflected by the room and thus sent to occupants (if the room is configured to broadcast presence for a given role).

    @@ -801,7 +801,7 @@

    * A moderator MUST NOT be able to revoke moderator status from an occupant who is equal to or above the moderator in the hierarchy of affiliations.

    -

    Note: Certain roles are typically implicit in certain affiliations. For example, an admin or owner is automatically a moderator, so if an occupant is granted an affiliation of admin then the occupant will by that fact be granted a role of moderator; similarly, when an occupant is granted an affiliation of member in a moderated room, the occupant automatically has a role of participant. However, the loss of the admin affiliation does not necessarily mean that the occupant no longer has a role of moderator (since a "mere" occupant can be a moderator). Therefore, the role that is gained when an occupant is granted a certain affiliation is stable, whereas the role that is lost when an occupant loses a certain affilitation is not hardcoded and is left up to the implementation. Since a client cannot predict what the role will be after revoking a certain affiliation, if it wants to remove both the admin/owner affiliation and the moderator role at the same time then it must specifically request the role change in addition to the affiliation change by including both the 'role' attribute and the 'affiliation' attribute.

    +

    Note: Certain roles are typically implicit in certain affiliations. For example, an admin or owner is automatically a moderator, so if an occupant is granted an affiliation of admin then the occupant will by that fact be granted a role of moderator; similarly, when an occupant is granted an affiliation of member in a moderated room, the occupant automatically has a role of participant. However, the loss of the admin affiliation does not necessarily mean that the occupant no longer has a role of moderator (since a "mere" occupant can be a moderator). Therefore, the role that is gained when an occupant is granted a certain affiliation is stable, whereas the role that is lost when an occupant loses a certain affilitation is not hardcoded and is left up to the implementation.

     @@ -816,7 +816,7 @@
  • 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 (not the full JID as with roles).

    +

    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, not the nick (and thus implicitly the full JID) as with roles.

    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.

    @@ -922,7 +922,7 @@

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

    +

    ** An admin or owner MUST NOT be able to revoke moderator status from another admin or owner.

    @@ -1121,34 +1121,44 @@ http://jabber.org/protocol/muc#roominfo - + The place for all good witches! - + true - + crone1@shakespeare.lit - + Spells - + true - + 3 - + dc=lit,dc=shakespeare,cn=witches - + en - + http://www.shakespeare.lit/chatlogs/coven/ - + xmpp:pubsub.shakespeare.lit?;node=the-coven-node @@ -1348,7 +1358,7 @@ ]]>

    In this example, the user from the previous example has entered the room, by which time two other people had already entered the room: a user with a room nickname of "firstwitch" (who is a room owner) and a user with a room nickname of "secondwitch" (who is a room admin).

    -

    Unless the room is configured to not broadcast presence from new occupants below a certain affiliation level as controlled by the 'muc#roomconfig_presencebroadcast' room configuration option, the service MUST also send presence from the new occupant's room JID to the full JIDs of all the occupants (including the new occupant).

    +

    Unless the room is configured to not broadcast presence from new occupants below a certain affiliation level (as controlled by the "muc#roomconfig_presencebroadcast" room configuration option), the service MUST also send presence from the new occupant's room JID to the full JIDs of all the occupants (including the new occupant).

    -

    If the room is semi-anonymous, the service MUST send presence from the new occupant to all occupants as specified above (i.e., unless the room is configured to not broadcast presence from new occupants below a certain affiliation level as controlled by the 'muc#roomconfig_presencebroadcast' room configuration option), but MUST include the new occupant's full JID only in the presence notifications it sends to occupants with a role of "moderator" and not to non-moderator occupants.

    +

    If the room is semi-anonymous, the service MUST send presence from the new occupant to all occupants as specified above (i.e., unless the room is configured to not broadcast presence from new occupants below a certain affiliation level as controlled by the "muc#roomconfig_presencebroadcast" room configuration option), but MUST include the new occupant's full JID only in the presence notifications it sends to occupants with a role of "moderator" and not to non-moderator occupants.

    (Note: All subsequent examples include the 'jid' attribute for each <item/> element, even though this information is not sent to non-moderators in semi-anonymous rooms.)

     @@ -1527,7 +1537,7 @@ ]]>

    Alternatively, the room could kick an "idle user" in order to free up space (whether the definition of "idle user" is up to the implementation).

    -

    If the room has reached its maximum number of occupants and a room admin or owner attempts to join, the room MUST allow the admin or owner to join, up to some reasonable number of additional occupants.

    +

    If the room has reached its maximum number of occupants and a room admin or owner attempts to join, the room MUST allow the admin or owner to join, up to some reasonable number of additional occupants; this helps to prevent denial of service attacks caused by stuffing the room with non-admin users.

     @@ -1770,7 +1780,7 @@ Harpier cries: 'tis time, 'tis time. ]]> -

    If the sender has voice in the room (this is the default except in moderated rooms), the service MUST change the 'from' attribute to the sender's room JID and reflect the message out to the full JID of each occupant.

    +

    If the sender has voice in the room (this is the default except in moderated rooms) and the message does not violate any service-level or room-level policies (e.g., policies regarding message content or size), the service MUST change the 'from' attribute to the sender's room JID and reflect the message out to the full JID of each occupant.

    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 MAY be allowed to retrieve the list of room members. For details, see the Modifying the Member List section of this document.

     @@ -2462,7 +2472,7 @@     -

    It is not possible for a visitor to speak (i.e., send a message to all occupants) in a moderated room. To request voice, a visitor SHOULD send a &MESSAGE; stanza containing a data form to the room itself, where the data form contains only a 'muc#role' field with a value of "participant".

    +

    It is not possible for a visitor to speak (i.e., send a message to all occupants) in a moderated room. To request voice, a visitor SHOULD send a &MESSAGE; stanza containing a data form to the room itself, where the data form contains only a "muc#role" field with a value of "participant".

    gone where the goblins go ]]> -

    Note that normal presence stanza generation rules apply as defined in &xmppim;, so that if the user sends a general unavailable presence stanza, the user's server will broadcast that stanza to the client's &ROOMJID;; as a result, there is no need for the leaving client to send directed unavailable presence to its room JID. It is possible that a user might not be able to gracefully exit the room by sending unavailable presence. If the user goes offline without sending unavailable presence, the user's server is responsible for sending unavailable presence on behalf of the user (in accordance with RFC 6121). However, if there is no activity in the room then the room MAY periodically poll its occupants to ensure that there are no "ghost users" in the room (e.g., by using presence probes or &xep0199;). If the user's server goes offline or connectivity is lost between the user's server and the MUC service to which the user is connected (e.g., in federated communications), the MUC service is responsible for monitoring error stanzas it receives in order to determine if the user has gone offline. If the MUC service determines that the user has gone offline, it must treat the user as if the user had itself sent unavailable presence.

    +

    Normal presence stanza generation rules apply as defined in &xmppim;, so that if the user sends a general unavailable presence stanza, the user's server will broadcast that stanza to the client's &ROOMJID;; as a result, there is no need for the leaving client to send directed unavailable presence to its room JID. It is possible that a user might not be able to gracefully exit the room by sending unavailable presence. If the user goes offline without sending unavailable presence, the user's server is responsible for sending unavailable presence on behalf of the user (in accordance with RFC 6121).

    +

    Note: See Ghost Users for suggestions regarding room occupants that appear to be present in the room but that are actually offline.

    Note: If the room is not persistent and this occupant is the last to exit, the service is responsible for destroying the room.

     @@ -2992,7 +3003,7 @@ type='unavailable'> - + Treason @@ -4360,21 +4371,6 @@ -[ ... ] - ]]>     -

    If the user is not in the room, the service MAY send a message from the room itself to the room occupants, indicating the loss of owner status by including an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'affiliation' attribute set to a value other than "owner".

    - - - - - - [ ... ] ]]> @@ -4404,7 +4400,7 @@ ]]> -

    The owner MAY then modify the owner list. In order to do so, the owner MUST send the changed items (i.e., only the "delta") back to the service; This is different from the behavior of room configuration, wherein the 'muc#roomconfig_roomowners' field specifies the full list of room owners, not the delta. each item MUST include the 'affiliation' and 'jid' attributes but SHOULD NOT include the 'nick' attribute and MUST NOT include the 'role' attribute (which is used to manage roles such as participant rather than affiliations such as owner):

    +

    The owner MAY then modify the owner list. In order to do so, the owner MUST send the changed items (i.e., only the "delta") back to the service; This is different from the behavior of room configuration, wherein the "muc#roomconfig_roomowners" field specifies the full list of room owners, not the delta. each item MUST include the 'affiliation' and 'jid' attributes but SHOULD NOT include the 'nick' attribute and MUST NOT include the 'role' attribute (which is used to manage roles such as participant rather than affiliations such as owner):

    ]]> -

    The owner MAY then modify the admin list. In order to do so, the owner MUST send the changed items (i.e., only the "delta") back to the service; This is different from the behavior of room configuration, wherein the 'muc#roomconfig_roomadmins' field specifies the full list of room admins, not the delta. each item MUST include the 'affiliation' attribute (normally set to a value of "admin" or "none") and 'jid' attribute but SHOULD NOT include the 'nick' attribute and MUST NOT include the 'role' attribute (which is used to manage roles such as participant rather than affiliations such as owner).

    +

    The owner MAY then modify the admin list. In order to do so, the owner MUST send the changed items (i.e., only the "delta") back to the service; This is different from the behavior of room configuration, wherein the "muc#roomconfig_roomadmins" field specifies the full list of room admins, not the delta. each item MUST include the 'affiliation' attribute (normally set to a value of "admin" or "none") and 'jid' attribute but SHOULD NOT include the 'nick' attribute and MUST NOT include the 'role' attribute (which is used to manage roles such as participant rather than affiliations such as owner).

    + label='An associated LDAP group that defines + room membership; this should be an LDAP + Distinguished Name according to an + implementation-specific or + deployment-specific definition of a + group.'/> - the three-digit code number - the stanza type of which it is a child (message or presence) - the use case or situation in which the status is used - a natural-language description of the meaning - the descriptive child element (reserved for future use) + + the three-digit code number + + + the stanza type of which it is a child (message or presence) + + + the use case or situation in which the status is used + + + a natural-language description of the meaning + + + the descriptive child element (reserved for future use) + ]]>

    The registrant may register more than one status code at a time, each contained in a separate <statuscode/> element.

    @@ -5122,25 +5130,33 @@ 100 message or presence Entering a room - Inform user that any occupant is allowed to see the user's full JID + + Inform user that any occupant is allowed to see the user's full JID + 101 message (out of band) Affiliation change - Inform user that his or her affiliation changed while not in the room + + Inform user that his or her affiliation changed while not in the room + 102 message Configuration change - Inform occupants that room now shows unavailable members + + Inform occupants that room now shows unavailable members + 103 message Configuration change - Inform occupants that room now does not show unavailable members + + Inform occupants that room now does not show unavailable members + 104 @@ -5154,89 +5170,117 @@ 110 presence Any room presence - Inform user that presence refers to itself + + Inform user that presence refers to itself + 170 message or initial presence Configuration change - Inform occupants that room logging is now enabled + + Inform occupants that room logging is now enabled + 171 message Configuration change - Inform occupants that room logging is now disabled + + Inform occupants that room logging is now disabled + 172 message Configuration change - Inform occupants that the room is now non-anonymous + + Inform occupants that the room is now non-anonymous + 173 message Configuration change - Inform occupants that the room is now semi-anonymous + + Inform occupants that the room is now semi-anonymous + 174 message Configuration change - Inform occupants that the room is now fully-anonymous (unused) + + Inform occupants that the room is now fully-anonymous (unused) + 201 presence Entering a room - Inform user that a new room has been created + + Inform user that a new room has been created + 210 presence Entering a room - Inform user that service has assigned or modified occupant's roomnick + + Inform user that service has assigned or modified occupant's roomnick + 301 presence Removal from room - Inform user that he or she has been banned from the room + + Inform user that he or she has been banned from the room + 303 presence Exiting a room - Inform all occupants of new room nickname + + Inform all occupants of new room nickname + 307 presence Removal from room - Inform user that he or she has been kicked from the room + + Inform user that he or she has been kicked from the room + 321 presence Removal from room - Inform user that he or she is being removed from the room - because of an affiliation change + + Inform user that he or she is being removed from the room + because of an affiliation change + 322 presence Removal from room - Inform user that he or she is being removed from the room - because the room has been changed to members-only and the user - is not a member + + Inform user that he or she is being removed from the room + because the room has been changed to members-only and the + user is not a member + 332 presence Removal from room - Inform user that he or she is being removed from the room - because the MUC service is being shut down + + Inform user that he or she is being removed from the room + because the MUC service is being shut down + ]]>     @@ -5450,7 +5494,7 @@ xmpp:coven@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=cauld -

    Deployment experience has shown that sometimes a user can appear to be an occupant in a room even though the user's real JID has gone offline since joining. Such users are called "ghosts". To help prevent ghost users, a MUC service SHOULD remove a user if the service receives a delivery-related error in relation to a stanza it has previously sent to the user (in this context, the delivery-related errors are &gone;, ¬found;, &recipient;, &redirect;, &remoteserver;, and &timeout;). A MUC service MAY also use &xep0199; to periodically check the availability of room occupants.

    +

    Deployment experience has shown that sometimes a user can appear to be an occupant in a room even though the user's real JID has gone offline since joining. Such users are called "ghosts". To help prevent ghost users, a MUC service SHOULD remove a user if the service receives a delivery-related error in relation to a stanza it has previously sent to the user (in this context, the delivery-related errors are &gone;, ¬found;, &recipient;, &redirect;, &remoteserver;, and &timeout;). A MUC service MAY also use &xep0199; or similar methods to periodically check the availability of room occupants. If the MUC service determines that the user has gone offline, it must treat the user as if the user had itself sent unavailable presence.