diff --git a/xep-0045.xml b/xep-0045.xml index ce02892f..3df9f93a 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -51,14 +51,20 @@ &stpeter; - 1.25rc2 - in progress, last updated 2011-01-21 + 1.25rc3 + in progress, last updated 2011-08-15 psa
  • Clarified the fact that room roles and affiliations are shortcuts to bundles of privileges.
  • Removed references to service discovery feature for "gc-1.0" since it is now obsolete.
  • Added security consideration about information leaks related to service discovery.
    • +
  • Corrected some examples of presence and message errors so that the 'from' and 'to' addresses are merely swapped, in accordance with RFC 6120; also added 'by' attribute to show that the room itself generated the error.
    • +
  • Added 'nick' attribute to <actor/> element so that an action can be attributed either to a real JID or to a roomnick.
    • +
  • Clarified the meaning of status code 100.
    • +
  • Corrected delayed delivery examples so that the 'from' address is that of the room.
    • +
  • Added 'id' attributes to most examples, especially message and presence stanzas generated by the room since IDs can be used for tracking purposes and ghost detection.
    • +
  • Added term "Occupant JID" to differentiate between the JID of a <room@service> and the JID of a <room@service/nick>.
 @@ -214,7 +220,7 @@ 1.5 2003-09-11 psa -

Specified that ban occurs by JID, not roomnick; allowed privileged users to send messages to the room even if not present in the room; added note that service should remove occupant if a delivery-related stanza error occurs; enabled user to disco the room in order to discover registered roomnick; specified that "banning" by domain or regex is a service-level configuration matter and therefore out of scope for MUC; specified that role should be decremented as appropriate if affiliation is lowered; added some clarifying text to room creation workflow; added implementation note about sending an out-of-band message if a user's affiliation changes while the user is not in the room; fixed stringprep references (room nicks use Resourceprep); clarified relationship between Room ID (i.e., node identifier of Room JID, which may be opaque) and natural-language Room Name; specified Field Standardization profile per XEP-0068; defined XMPP Registrar submissions; added schema locations.

 +

Specified that ban occurs by JID, not roomnick; allowed privileged users to send messages to the room even if not present in the room; added note that service should remove occupant if a delivery-related stanza error occurs; enabled user to disco the room in order to discover registered roomnick; specified that "banning" by domain or regex is a service-level configuration matter and therefore out of scope for MUC; specified that role should be decremented as appropriate if affiliation is lowered; added some clarifying text to room creation workflow; added implementation note about sending an out-of-band message if a user's affiliation changes while the user is not in the room; fixed stringprep references (room nicks use Resourceprep); clarified relationship between Room ID (i.e., node identifier of Room JID or Occupant JID, which may be opaque) and natural-language Room Name; specified Field Standardization profile per XEP-0068; defined XMPP Registrar submissions; added schema locations.

 1.4 @@ -292,7 +298,7 @@ 0.16 2002-10-20 psa -

Added the <item/> element to presence stanzas of type "unavailable" in order to improve the tracking of user states in the room; consolidated <invitee/> and <invitor/> elements into an <invite/> element with 'from' and 'to' attributes; made <reason/> element always a child of <item/> or <invite/> in the muc#user namespace; moved the alternate room location in room destruction to a 'jid' attribute of the <alt/> element; further specified several error messages; disallowed simultaneous modifications of both affiliations and roles by a moderator or admin; added several more rules regarding handling of XML stanzas; added use cases for granting and revoking administrative privileges; adjusted DTD to track all changes.

 +

Added the <item/> element to presence stanzas of type "unavailable" in order to improve the tracking of user states in the room; consolidated <invitee/> and <inviter/> elements into an <invite/> element with 'from' and 'to' attributes; made <reason/> element always a child of <item/> or <invite/> in the muc#user namespace; moved the alternate room location in room destruction to a 'jid' attribute of the <alt/> element; further specified several error messages; disallowed simultaneous modifications of both affiliations and roles by a moderator or admin; added several more rules regarding handling of XML stanzas; added use cases for granting and revoking administrative privileges; adjusted DTD to track all changes.

 0.15 @@ -316,7 +322,7 @@ 0.12 2002-10-16 psa -

Removed SHA1 passwords; specified that room shall add passwords on invitations to password-protected rooms (not supplied by invitor).

 +

Removed SHA1 passwords; specified that room shall add passwords on invitations to password-protected rooms (not supplied by inviter).

 0.11 @@ -490,8 +496,8 @@
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.
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.
 +
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 Occupant 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 Occupant JID.
GC
The minimal "groupchat 1.0" protocol developed within the Jabber community in 1999; MUC is backwards-compatible with GC.
History
A limited number of message stanzas sent to a new occupant to provide the context of current discussion.
Invitation
A special message sent from one user to another asking the recipient to join a room; the invitation can be sent directly (see &xep0249;) or mediated through the room (as described under Inviting Another User to a Room).
 @@ -503,6 +509,7 @@
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).
 +
Occupant JID
The <room@service/nick> by which an occupant is identified within the context of a room; contrast with Bare JID and Full JID.
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).
 @@ -510,9 +517,9 @@
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 JID
The <room@service/nick> by which an occupant is identified within the context of a room; contrast with Bare JID and Full JID.
 +
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 a Room JID (see Business Rules for syntax); this is the "friendly name" by which an occupant is known in the room.
 +
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.
Room Owner
The user who created the room or a user who has been designated by the room creator or owner as someone with owner privileges (if allowed); an owner is allowed to change the room configuration and destroy the room, in addition to all administrative privileges. An owner has an affiliation of "owner".
Room Roster
A client's representation of the occupants in a room.
Server
An XMPP server that may or may not have associated with it a text-based conferencing service.
 @@ -604,7 +611,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 broadcast to the room).

+

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

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

@@ -757,7 +764,7 @@ -

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 (if the room is configured to broadcast presence for a given role). Role changes and their triggering actions are specified in the following table.

+

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 (if the room is configured to broadcast presence from entities with a given role). Role changes and their triggering actions are specified in the following table.

@@ -815,7 +822,7 @@

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 (if the room is configured to broadcast presence for a given role).

+

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

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 all the privileges possessed by the next-lowest affiliation, plus additional privileges; these privileges are specified in the following table.

>
@@ -921,7 +928,7 @@ -

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 (if the room is configured to broadcast presence for a given role). Affiliation changes and their triggering actions are specified in the following table.

+

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 (if the room is configured to broadcast presence from entities with a given role). Affiliation changes and their triggering actions are specified in the following table.

@@ -1277,16 +1284,18 @@ ]]>

In this example, a user with a full JID of "hag66@shakespeare.lit/pda" has requested to enter the room "coven" on the "chat.shakespeare.lit" chat service with a room nickname of "thirdwitch".

If the user does not specify a room nickname, the service MUST return a &badjid; error:

- + @@ -1298,6 +1307,7 @@ @@ -1305,11 +1315,12 @@

Note: If an error occurs in relation to joining a room, the service SHOULD include the MUC child element (i.e., <x xmlns='http://jabber.org/protocol/muc'/>) in the &PRESENCE; stanza of type "error".

- + @@ -1318,10 +1329,11 @@ -

If the service is able to add the user to the room, it MUST send presence from all the existing occupants' room JIDs to the new occupant's full JID, including extended presence information about roles in a single <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'role' attribute set to a value of "moderator", "participant", or "visitor", and with the 'affiliation' attribute set to a value of "owner", "admin", "member", or "none" as appropriate. The &PRESENCE; element MUST NOT include more than once instance of the &X; qualified by the 'http://jabber.org/protocol/muc#user' namespace.

+

If the service is able to add the user to the room, it MUST send presence from all the existing occupants' room JIDs to the new occupant's full JID, including extended presence information about roles in a single <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with the 'role' attribute set to a value of "moderator", "participant", or "visitor", and with the 'affiliation' attribute set to a value of "owner", "admin", "member", or "none" as appropriate. The &PRESENCE; element MUST NOT include more than once instance of the &X; element qualified by the 'http://jabber.org/protocol/muc#user' namespace.

@@ -1330,6 +1342,7 @@ @@ -1337,10 +1350,11 @@ ]]>

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

@@ -1349,6 +1363,7 @@ @@ -1357,6 +1372,7 @@ @@ -1370,6 +1386,7 @@ @@ -1378,7 +1395,7 @@ ]]> -

Note: The order of the presence stanzas sent to the new occupant is important. The service MUST first send the complete list of the existing occupants to the new occupant and only then send the new occupant's own presence to the new occupant. This helps the client know when it has received the complete "room roster".

+

Note: The order of the presence stanzas sent to the new occupant is important. The service MUST first send the complete list of the existing occupants to the new occupant and only then send the new occupant's own presence to the new occupant. This helps the client know when it has received the complete "room roster". The room SHOULD also reflect the original 'id' value, if provided in the presence stanza sent by the user.

After sending the presence broadcast (and only after doing so), the service may then send discussion history, the room subject, live messages, presence updates, and other in-room traffic.

 @@ -1387,6 +1404,7 @@ @@ -1414,7 +1433,7 @@ -

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

 @@ -1422,11 +1441,12 @@

If the room requires a password and the user did not supply one (or the password provided is incorrect), the service MUST deny access to the room and inform the user that they are unauthorized; this is done by returning a presence stanza of type "error" specifying a ¬authorized; error:

- + @@ -1435,6 +1455,7 @@ cauldronburn @@ -1447,11 +1468,12 @@

If the room is members-only but the user is not on the member list, the service MUST deny access to the room and inform the user that they are not allowed to enter the room; this is done by returning a presence stanza of type "error" specifying a ®istration; error condition:

- + @@ -1462,11 +1484,12 @@

If the user has been banned from the room (i.e., has an affiliation of "outcast"), the service MUST deny access to the room and inform the user of the fact that they are banned; this is done by returning a presence stanza of type "error" specifying a &forbidden; error condition:

- + @@ -1477,11 +1500,12 @@

If the room already contains another user with the nickname desired by the user seeking to enter the room (or if the nickname is reserved by another user on the member list), the service MUST deny access to the room and inform the user of the conflict; this is done by returning a presence stanza of type "error" specifying a &conflict; error condition:

- + @@ -1494,11 +1518,12 @@

If the room has reached its maximum number of occupants, the service SHOULD deny access to the room and inform the user of the restriction; this is done by returning a presence stanza of type "error" specifying a &unavailable; error condition:

- + @@ -1511,11 +1536,12 @@

If a user attempts to enter a room while it is "locked" (i.e., before the room creator provides an initial configuration and therefore before the room officially exists), the service MUST refuse entry and return an ¬found; error to the user:

- + @@ -1531,6 +1557,7 @@ @@ -1548,31 +1575,34 @@ Thrice the brinded cat hath mew'd. Thrice and once the hedge-pig whined. Harpier cries 'Tis time, 'tis time. ]]> @@ -1615,6 +1645,7 @@ @@ -1624,6 +1655,7 @@ @@ -1633,6 +1665,7 @@ @@ -1642,6 +1675,7 @@ @@ -1652,6 +1686,7 @@ @@ -1665,11 +1700,13 @@ Fire Burn and Cauldron Bubble! ]]> +

Note: In accordance with the core definition of XML stanzas, any message can contain a &SUBJECT; element; only a message that contains a &SUBJECT; but no other child elements shall be considered a subject change for MUC purposes.

@@ -1687,6 +1724,7 @@ Harpier cries: 'tis time, 'tis time. @@ -1696,31 +1734,36 @@ Harpier cries: 'tis time, 'tis time. Harpier cries: 'tis time, 'tis time. Harpier cries: 'tis time, 'tis time. ]]> +

Note well that for tracking purposes this service assigns a new 'id' to each message it generates (here using a UUID as defined in &rfc4122;).

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.

-

Since each occupant has a unique room JID, an occupant MAY send a "private message" to a selected occupant via the service by sending a message to the occupant's room JID. The message type SHOULD be "chat" and MUST NOT be "groupchat", but MAY be left unspecified (i.e., a normal message). This privilege SHOULD be allowed to any occupant (even a visitor in a moderated room).

+

Since each occupant has a unique room JID, an occupant can send a "private message" to a selected occupant via the service by sending a message to the intended recipient's room JID. The message type SHOULD be "chat" and MUST NOT be "groupchat", but MAY be left unspecified (i.e., a normal message). This privilege is controlled by the "muc#roomconfig_allowpm" room configuration option.

I'll give thee a wind. @@ -1729,7 +1772,8 @@

The service is responsible for changing the 'from' address to the sender's room JID and delivering the message to the intended recipient's full JID.

I'll give thee a wind. @@ -1739,17 +1783,19 @@ I'll give thee a wind. I'll give thee a wind. - + @@ -1759,10 +1805,11 @@ -

A common feature of multi-user chat rooms is the ability for an occupant to change his or her nickname within the room. In MUC this is done by sending updated presence information to the room, specifically by sending presence to a new room JID in the same room (changing only the resource identifier in the room JID).

+

A common feature of chat rooms is the ability for an occupant to change his or her nickname within the room. In MUC this is done by sending updated presence information to the room, specifically by sending presence to a new room JID in the same room (changing only the resource identifier in the room JID).

]]>

The service then sends two presence stanzas to the full JID of each occupant (including the occupant who is changing his or her room nickname), one of type "unavailable" for the old nickname and one indicating availability for the new nickname.

@@ -1775,6 +1822,7 @@ @@ -1787,6 +1835,7 @@ @@ -1799,6 +1848,7 @@ @@ -1813,6 +1863,7 @@ If the user attempts to change his or her room nickname to a room nickname that is already in use by another user (or that is reserved by another user affiliated with the room, e.g., a member or owner), the service MUST deny the nickname change request and inform the user of the conflict; this is done by returning a presence stanza of type "error" specifying a &conflict; error condition:

- + @@ -1856,11 +1910,12 @@

If the user attempts to change his or her room nickname but room nicknames are "locked down", the service MUST deny the nickname change request and return a presence stanza of type "error" specifying a ¬acceptable; error condition:

- + @@ -1869,19 +1924,21 @@ -

In multi-user chat systems such as IRC, one common use for changing one's room nickname is to indicate a change in one's availability (e.g., changing one's room nickname to "thirdwitch|away"). In XMPP, availability is of course noted by a change in presence (specifically the <show/> and <status/> elements), which can provide important context within a chatroom. An occupant changes availability status within the room by sending the updated presence to its &ROOMJID;.

+

In text chat systems such as IRC, one common use for changing one's room nickname is to indicate a change in one's availability (e.g., changing one's room nickname to "thirdwitch|away"). In XMPP, availability is of course noted by a change in presence (specifically the <show/> and <status/> elements), which can provide important context within a chatroom. An occupant changes availability status within the room by sending updated presence to its &ROOMJID;.

xa gone where the goblins go ]]> -

The service then sends a presence stanza from the occupant changing his or her presence to the full JID of each occupant, including extended presence information about the occupant's role and full JID to those with privileges to view such information:

+

If the room is configured to broadcast presence from entities with the occupant's role, the service then sends a presence stanza from the occupant changing his or her presence to the full JID of each occupant, including extended presence information about the occupant's role and full JID to those with privileges to view such information:

xa gone where the goblins go @@ -1897,15 +1954,20 @@ + +

There are two ways of inviting another user to a room: direct invitations and mediated invitations.

+

Direct invitations were the original method used in the early Jabber community's "groupchat 1.0" protocol. Mediated invitations were added in Multi-User Chat as a way to handle invitations in the context of members-only rooms (so that the room could exercise control over the issuance of invitations). The existence of two different invitation methods might cause confusion among client developers. Because the room needs to be involved in the invitation process only for members-only rooms, because members-only rooms are relatively rare, and because mediated invitations do not work when &xep0016; or similar technologies are used to block communication from entities not in a user's roster, client developers are encouraged to use direct invitations for all other room types.

+ -

A method for sending a direct invitation (not mediated by the room itself) is defined in &xep0249;. Sending the invitation directly can help to work around communications blocking on the part of the invitee (which might refuse communication with entities not in its roster).

+

A method for sending a direct invitation (not mediated by the room itself) is defined in &xep0249;. Sending the invitation directly can help to work around communications blocking on the part of the invitee (which might reject or discard messages from entities not in its roster).

 -

It can be useful to invite another user to a room in which one is an occupant. To do this, a MUC client MUST send XML of the following form to the &ROOM; itself (the reason is OPTIONAL and the message MUST be explicitly or implicitly of type "normal"):

- It can be useful to invite another user to a room in which one is an occupant. To send a mediated invitation, a MUC client MUST send XML of the following form to the &ROOM; itself (the reason is OPTIONAL and the message MUST be explicitly or implicitly of type "normal"):

+ @@ -1916,10 +1978,11 @@ ]]> -

The &ROOM; itself MUST then add a 'from' address to the <invite/> element whose value is the bare JID, full JID, or room JID of the invitor and send the invitation to the invitee specified in the 'to' address (the service MAY include a message body explaining the invitation or containing the reason, for the sake of older clients; in addition, the room SHOULD add the password if the room is password-protected):

+

The &ROOM; itself MUST then add a 'from' address to the <invite/> element whose value is the bare JID, full JID, or room JID of the inviter and send the invitation to the invitee specified in the 'to' address; the room SHOULD add the password if the room is password-protected):

@@ -1932,11 +1995,12 @@ ]]>

If the room is members-only, the service MAY also add the invitee to the member list. (Note: Invitation privileges in members-only rooms SHOULD be restricted to room admins; if a member without privileges to edit the member list attempts to invite another user, the service SHOULD return a &forbidden; error to the occupant; for details, see the Modifying the Member List section of this document.)

-

If the invitor supplies a non-existent JID, the room SHOULD return an ¬found; error to the invitor.

+

If the inviter supplies a non-existent JID, the room SHOULD return an ¬found; error to the inviter.

The invitee MAY choose to formally decline (as opposed to ignore) the invitation; and this is something that the sender may want to be informed about. In order to decline the invitation, the invitee MUST send a message of the following form to the &ROOM; itself:

@@ -1950,6 +2014,7 @@ @@ -1960,17 +2025,18 @@ ]]> -

It may be wondered why the invitee does not send the decline message directly to the invitor. The main reason is that certain implementations MAY choose to base invitations on room JIDs rather than bare JIDs (so that, for example, an occupant could invite someone from one room to another without knowing that person's bare JID). Thus the service MUST handle both the invites and declines.

+

It may be wondered why the invitee does not send the decline message directly to the inviter. The main reason is that certain implementations might choose to base invitations on room JIDs rather than bare JIDs (so that, for example, an occupant could invite someone from one room to another without knowing that person's bare JID). Thus the service needs to handle both the invites and declines.

 -

Sometimes it is desirable to convert a one-to-one chat into a multi-user conference. The process flow is shown in the following examples.

+

Sometimes it is desirable to convert a one-to-one chat into a multi-user conference. The process is as follows.

First, two users begin a one-to-one chat.

e0ffe42b28561960c6b12b944a092794b9683a38 @@ -1979,16 +2045,17 @@ e0ffe42b28561960c6b12b944a092794b9683a38 Thrice and once the hedge-pig whined. ]]> -

Now the first person decides to include a third person in the discussion, so she (or, more precisely, her client) does the following:

+

Now the first person decides to include a third person in the discussion, so she does the following:

  1. Creates a new multi-user chatroom
    2. -
  2. Optionally sends history of the one-to-one chat to the room
    3. +
  3. Sends history of the one-to-one chat to the room (this is purely OPTIONAL; because it might cause information leakage, the client SHOULD warn the user before doing so)
  4. Sends an invitation to the second person and the third person, including a <continue/> element (optionally including a 'thread' attribute).

Note: The new room SHOULD be non-anonymous, MAY be an instant room as specified in the Creating an Instant Room section of this document, and MAY have a unique room name received from the service as specified in the Requesting a Unique Room Name section of this document.

@@ -2012,6 +2079,7 @@ e0ffe42b28561960c6b12b944a092794b9683a38 @@ -2023,19 +2091,21 @@ e0ffe42b28561960c6b12b944a092794b9683a38 Thrice and once the hedge-pig whined. ]]> -

Note: Use of the Delayed Delivery protocol enables the room creator to specify the datetime of each message from the one-to-one chat history (via the 'stamp' attribute), as well as the JID of the original sender of each message (via the 'from' attribute). The room creator SHOULD send the complete one-to-one chat history before inviting additional users to the room, and SHOULD also send as history any messages appearing in the one-to-one chat interface after joining the room and before the second person joins the room; if the one-to-one history is especially large, the sending client may want to send the history over a few seconds rather than all at once (to avoid triggering rate limits). The service SHOULD NOT add its own delay elements (as described in the Discussion History section of this document) to prior chat history messages received from the room owner.

+

Note: Use of the Delayed Delivery protocol enables the room creator to specify the datetime of each message from the one-to-one chat history (via the 'stamp' attribute), as well as the JID of the original sender of each message (via the 'from' attribute); note well that the 'from' here is not the room itself, since the originator of the message is the delaying party. The room creator SHOULD send the complete one-to-one chat history before inviting additional users to the room, and SHOULD also send as history any messages appearing in the one-to-one chat interface after joining the room and before the second person joins the room; if the one-to-one history is especially large, the sending client may want to send the history over a few seconds rather than all at once (to avoid triggering rate limits). The service SHOULD NOT add its own delay elements (as described in the Discussion History section of this document) to prior chat history messages received from the room owner.

@@ -2049,11 +2119,12 @@ ]]> -

Note: Since the invitor's client knows the full JID of the person with whom the invitor was having a one-to-one chat, it SHOULD include the full JID (rather than the bare JID) in the invitation.

+

Note: Since the inviter's client knows the full JID of the person with whom the inviter was having a one-to-one chat, it SHOULD include the full JID (rather than the bare JID) in its invitation to that user.

The invitations are delivered to the invitees:

+ from='coven@chat.shakespeare.lit/firstwitch' + id='DB0414CB-AFBA-407E-9DE3-0E014E84860F' to='wiccarocks@shakespeare.lit/laptop'> @@ -2064,7 +2135,8 @@ + from='coven@chat.shakespeare.lit/firstwitch' + id='89028D79-AB4C-44C0-BE81-B07607C2F4C2' to='hag66@shakespeare.lit'> @@ -2100,45 +2172,79 @@ e0ffe42b28561960c6b12b944a092794b9683a38 Thrice the brinded cat hath mew'd. e0ffe42b28561960c6b12b944a092794b9683a38 Thrice and once the hedge-pig whined. ]]> -

Note: The fact that the messages come from the &ROOM; itself rather than &ROOMJID; is a clue to the receiving client that these messages are prior chat history, since any message from a room occupant will have a 'from' address equal to the sender's room JID.

 -

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.

+

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 might need to request membership in order to join such a room.

If allowed, this functionality SHOULD be implemented by enabling a user to send a request for registration requirements to the room qualified by the 'jabber:iq:register' namespace as described in &xep0077;:

]]> -

If the user requesting registration requirements is not allowed to register with the room (e.g., because that privilege has been restricted), the room MUST return a ¬allowed; error to the user. If the user is already registered, the room MUST reply with an IQ stanza of type "result" that contains an empty <register/> element as described in XEP-0077. If the room does not exist, the service MUST return an ¬found; error.

-

Otherwise, the room MUST then return a Data Form to the user (as described in &xep0004;). The information required to register MAY vary by implementation or deployment and is not fully specified in this document (e.g., the fields registered by this document for the 'http://jabber.org/protocol/muc#register' FORM_TYPE may be supplemented in the future via the mechanisms described in the Field Standardization section of this document). The following can be taken as a fairly typical example:

+

If the room does not exist, the service MUST return an ¬found; error.

+ + + + + + ]]> +

If the user requesting registration requirements is not allowed to register with the room (e.g., because that privilege has been restricted), the room MUST return a ¬allowed; error to the user.

+ + + + + + ]]> +

If the user is already registered, as described in XEP-0077 the room MUST reply with an IQ stanza of type "result", which MUST contain an empty <registered/> element and SHOULD contain at least a <username/> element that specifies the user's registered nickname in the room.

+ + + + thirdwitch + + + ]]> +

Otherwise, the room MUST then return a Data Form to the user (as described in &xep0004;). The information required to register might vary by implementation or deployment and is not fully specified in this document (e.g., the fields registered by this document for the 'http://jabber.org/protocol/muc#register' FORM_TYPE might be supplemented in the future via the mechanisms described in the Field Standardization section of this document). The following can be taken as a fairly typical example:

@@ -2193,7 +2299,7 @@

The user SHOULD then submit the form:

@@ -2226,7 +2332,7 @@

If the desired room nickname is already reserved for that room, the room MUST return a &conflict; error to the user:

@@ -2237,7 +2343,7 @@

If the room or service does not support registration, it MUST return a &unavailable; error to the user:

@@ -2248,7 +2354,7 @@

If the user did not include a valid data form, the room MUST return a &badrequest; error to the user:

@@ -2259,11 +2365,11 @@

Otherwise, the room MUST inform the user that the registration request was successfully received:

]]> -

After the user submits the form, the service MAY request that the submission be approved by a room admin/owner (see the Approving Registration Requests section of this document) or MAY immediately add the user to the member list by changing the user's affiliation from "none" to "member". If the service changes the user's affiliation and the user is in the room, it MUST send updated presence from this individual to all occupants, indicating the change in affiliation 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 of "member".

+

After the user submits the form, the service MAY request that the submission be approved by a room admin/owner (see the Approving Registration Requests section of this document), MAY immediately add the user to the member list by changing the user's affiliation from "none" to "member", or MAY perform some service-specific checking (e.g., email verification). If the service changes the user's affiliation and the user is in the room, it MUST send updated presence from this individual to all occupants, indicating the change in affiliation 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 of "member".

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

@@ -2422,6 +2529,7 @@ Fire Burn and Cauldron Bubble! @@ -2431,6 +2539,7 @@ Fire Burn and Cauldron Bubble! @@ -2446,11 +2555,12 @@

If someone without appropriate privileges attempts to change the room subject, the service MUST return a message of type "error" specifying a &forbidden; error condition:

Fire Burn and Cauldron Bubble! - + @@ -2459,6 +2569,7 @@ @@ -2488,7 +2599,7 @@ type='unavailable'> - + Avaunt, you cullion! @@ -2854,7 +2965,7 @@ type='unavailable'> - + Treason @@ -3016,6 +3127,7 @@ - + @@ -3174,6 +3286,7 @@ @@ -3185,6 +3298,7 @@ @@ -3400,7 +3514,7 @@

If a service does not automatically accept requests to register with a room, it MAY provide a way for room admins to approve or deny registration requests over XMPP (alternatively, it could provide a web interface or some other admin tool). The simplest way to do so is for the service to send a &MESSAGE; stanza to the room admin(s) when the registration request is received, where the &MESSAGE; stanza contains a Data Form asking for approval or denial of the request. The following Data Form is RECOMMENDED but implementations MAY use a different form entirely, or supplement the following form with additional fields.

Registration request @@ -3470,7 +3584,7 @@ to='hag66@shakespeare.lit/pda' type='error'> - + @@ -3600,6 +3714,24 @@ var='muc#roomconfig_allowinvites'> 0 + + anyone + + + + + none moderator @@ -3746,6 +3878,9 @@ 0 + + anyone + 10 @@ -3917,6 +4052,24 @@ var='muc#roomconfig_allowinvites'> 0 + + anyone + + + + + none moderator @@ -4109,6 +4262,7 @@

A room MUST send notification to all occupants when the room configuration changes in a way that has an impact on the privacy or security profile of the room. This notification shall consist of a &MESSAGE; stanza containing an &X; element qualified by the 'http://jabber.org/protocol/muc#user' namespace, which shall contain only a <status/> element with an appropriate value for the 'code' attribute. Here is an example:

@@ -4181,6 +4335,7 @@ -

Depending on room configuration, a room MAY expose each occupant's real JID to other occupants (if the room is non-anonymous) and will almost certainly expose each occupant's real JID to the room owners and administrators (if the room is not fully-anonymous). A service MUST warn the user that real JIDs are exposed in the room by returning a status code of "100" with the user's initial presence, and the user's client MUST so warn the user (a user's client SHOULD also query the room for its configuration prior to allowing the user to enter in order to "pre-discover" whether real JIDs are exposed in the room). A client MUST also warn the user if the room's configuration is subsequently modified from semi-anonymous or fully-anonymous to non-anonymous (which the client will discover when the room sends status code 172) and SHOULD warn the user if the room's configuration is subsequently modified from fully-anonymous to semi-anonymous (which the client will discover when the room sends status code 173).

+

Depending on room configuration, a room might expose each occupant's real JID to other occupants (if the room is non-anonymous). If real JIDs are exposed to all occupants in the room, the service MUST warn the user by returning a status code of "100" with the user's initial presence, and the user's client MUST so warn the user (a user's client SHOULD also query the room for its configuration prior to allowing the user to enter in order to "pre-discover" whether real JIDs are exposed in the room). A client MUST also warn the user if the room's configuration is subsequently modified from semi-anonymous to non-anonymous (which the client will discover when the room sends status code 172).

 @@ -4926,6 +5084,10 @@ + + label='Roles for which Presence is Broadcasted'/> 174 message Configuration change - Inform occupants that the room is now fully-anonymous + Inform occupants that the room is now fully-anonymous (unused) 201 @@ -5311,7 +5473,7 @@ xmpp:coven@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=cauld -

In order to provide consistency regarding the addresses captured in room JIDs, Room IDs MUST match the Nodeprep profile of Stringprep and Room Nicknames MUST match the Resourceprep profile of Stringprep (both of these are defined in &rfc3920;). As explicitly stated in RFC 6120, both the Room ID (node) and Room Nickname (resource) portions of a Room JID MUST be of non-zero length. In addition, a MUC service MUST NOT allow empty or invisible Room Nicknames (i.e., Room Nicknames that consist only of one or more space characters).

+

In order to provide consistency regarding the addresses captured in room JIDs, Room IDs MUST match the Nodeprep profile of Stringprep and Room Nicknames MUST match the Resourceprep profile of Stringprep (both of these are defined in &rfc3920;). As explicitly stated in RFC 6120, both the Room ID (node) and Room Nickname (resource) portions of an Occupant JID MUST be of non-zero length. In addition, a MUC service MUST NOT allow empty or invisible Room Nicknames (i.e., Room Nicknames that consist only of one or more space characters).

It is up to the service implementation whether it will further restrict roomnicks (e.g., by applying case folding routines, the Nodeprep profile of stringprep, or other restrictions).

 @@ -5668,7 +5830,8 @@ xmpp:coven@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=cauld - + + @@ -5770,7 +5933,8 @@ xmpp:coven@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=cauld - + +
>