moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 23:28:51 -05:00
Code Issues Releases Wiki Activity

1.25rc3

Browse Source
This commit is contained in:
stpeter 2011-08-15 12:06:12 -06:00
parent d65b8f951c
commit d90c7b5bf1
1 changed files with 153 additions and 246 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

393
xep-0045.xml
View File

@ -40,10 +40,6 @@
<ns>muc#owner</ns>
<url>http://www.xmpp.org/schemas/muc-owner.xsd</url>
</schemaloc>
<schemaloc>
<ns>muc#unique</ns>
<url>http://www.xmpp.org/schemas/muc-unique.xsd</url>
</schemaloc>
<schemaloc>
<ns>muc#user</ns>
<url>http://www.xmpp.org/schemas/muc-user.xsd</url>
@ -65,6 +61,8 @@
<li>Corrected delayed delivery examples so that the 'from' address is that of the room.</li>
<li>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.</li>
<li>Added term "Occupant JID" to differentiate between the JID of a &lt;room@service&gt; and the JID of a &lt;room@service/nick&gt;.</li>
<li>Removed feature for requesting a unique room name (the client can simply use a UUID).</li>
<li>Clarified many small points in the text and examples.</li>
</ul>
</remark>
</revision>
@ -298,7 +296,7 @@
<version>0.16</version>
<date>2002-10-20</date>
<initials>psa</initials>
<remark><p>Added the &lt;item/&gt; element to presence stanzas of type "unavailable" in order to improve the tracking of user states in the room; consolidated &lt;invitee/&gt; and &lt;inviter/&gt; elements into an &lt;invite/&gt; element with 'from' and 'to' attributes; made &lt;reason/&gt; element always a child of &lt;item/&gt; or &lt;invite/&gt; in the muc#user namespace; moved the alternate room location in room destruction to a 'jid' attribute of the &lt;alt/&gt; 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.</p></remark>
<remark><p>Added the &lt;item/&gt; element to presence stanzas of type "unavailable" in order to improve the tracking of user states in the room; consolidated &lt;invitee/&gt; and &lt;inviter/&gt; elements into an &lt;invite/&gt; element with 'from' and 'to' attributes; made &lt;reason/&gt; element always a child of &lt;item/&gt; or &lt;invite/&gt; in the muc#user namespace; moved the alternate room location in room destruction to a 'jid' attribute of the &lt;alt/&gt; 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 admin status; adjusted DTD to track all changes.</p></remark>
</revision>
<revision>
<version>0.15</version>
@ -476,7 +474,7 @@
<li>enabling admins to grant and revoke membership privileges, and to manage the member list for a members-only room</li>
<li>enabling owners to configure various room parameters (e.g., limiting the number of occupants)</li>
<li>enabling owners to specify other owners</li>
<li>enabling owners to grant and revoke administrative privileges, and to manage the admin list</li>
<li>enabling owners to grant and revoke admin status, and to manage the admin list</li>
<li>enabling owners to destroy the room</li>
</ol>
<p>In addition, this document provides protocol elements for supporting the following room types:</p>
@ -511,7 +509,7 @@
<di><dt>Occupant</dt><dd>Any user who is in a room (this is an "abstract class" and does not correspond to any specific role).</dd></di>
<di><dt>Occupant JID</dt><dd>The &lt;room@service/nick&gt; by which an occupant is identified within the context of a room; contrast with Bare JID and Full JID.</dd></di>
<di><dt>Outcast</dt><dd>A user who has been banned from a room. An outcast has an affiliation of "outcast".</dd></di>
<di><dt>Participant</dt><dd>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".</dd></di>
<di><dt>Participant</dt><dd>An occupant who does not have admin status; in a moderated room, a participant is further defined as having voice (in contrast to a visitor). A participant has a role of "participant".</dd></di>
<di><dt>Private Message</dt><dd>A message sent from one occupant directly to another's room JID (not to the room itself for broadcasting to all occupants).</dd></di>
<di><dt>Role</dt><dd>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.</dd></di>
<di><dt>Room</dt><dd>A virtual space that users figuratively enter in order to participate in real-time, text-based conferencing with other users.</dd></di>
@ -520,7 +518,7 @@
<di><dt>Room JID</dt><dd>The &lt;room@service&gt; address of a room.</dd></di>
<di><dt>Room Name</dt><dd>A user-friendly, natural-language name for a room, configured by the room owner and presented in Service Discovery queries; contrast with Room ID.</dd></di>
<di><dt>Room Nickname</dt><dd>The resourcepart of an Occupant JID (see <link url='#bizrules'>Business Rules</link> for syntax); this is the "friendly name" by which an occupant is known in the room.</dd></di>
<di><dt>Room Owner</dt><dd>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".</dd></di>
<di><dt>Room Owner</dt><dd>The user who created the room or a user who has been designated by the room creator or owner as someone with owner status (if allowed); an owner is allowed to change the room configuration and destroy the room, in addition to all admin status. An owner has an affiliation of "owner".</dd></di>
<di><dt>Room Roster</dt><dd>A client's representation of the occupants in a room.</dd></di>
<di><dt>Server</dt><dd>An XMPP server that may or may not have associated with it a text-based conferencing service.</dd></di>
<di><dt>Service</dt><dd>A host that offers text-based conferencing capabilities; often but not necessarily a sub-domain of an XMPP server (e.g., conference.jabber.org).</dd></di>
@ -1260,7 +1258,7 @@
</section1>
<section1 topic='Occupant Use Cases' anchor='user'>
<p>The main actor in a multi-user chat environment is the occupant, who can be said to be located "in" a multi-user chat room and to participate in the discussions held in that room (for the purposes of this specification, participants and visitors are considered to be "mere" occupants, since they possess no administrative privileges). As will become clear, the protocol elements proposed in this document to fulfill the occupant use cases fall into three categories:</p>
<p>The main actor in a multi-user chat environment is the occupant, who can be said to be located "in" a multi-user chat room and to participate in the discussions held in that room (for the purposes of this specification, participants and visitors are considered to be "mere" occupants, since they possess no admin status). As will become clear, the protocol elements proposed in this document to fulfill the occupant use cases fall into three categories:</p>
<ol start='1'>
<li><p>the basic functionality for joining a room, exchanging messages with all occupants, etc. (supported by the GC protocol that preceded MUC)</p></li>
<li><p>straightforward additions to the basic functionality, such as handling of errors related to new room types</p></li>
@ -1713,6 +1711,48 @@
<p>After the room has optionally sent the room subject, it SHALL begin to send live messages, presence changes, occupant "joins" and "leaves", and other real-time traffic ot the new occupant, as described in other sections of this document.</p>
</section3>
<section3 topic='Error Conditions' anchor='enter-errorcodes'>
<p>The following table summarizes the XMPP error conditions that can be returned to an entity that attempts to enter a MUC room.</p>
<table caption='Error Conditions for Entering a Room'>
<tr>
<th>Condition</th>
<th>Purpose</th>
</tr>
<tr>
<td>&notauthorized;</td>
<td>Inform user that a password is required</td>
</tr>
<tr>
<td>&forbidden;</td>
<td>Inform user that he or she is banned from the room</td>
</tr>
<tr>
<td>&notfound;</td>
<td>Inform user that the room does not exist</td>
</tr>
<tr>
<td>&notallowed;</td>
<td>Inform user that room creation is restricted</td>
</tr>
<tr>
<td>&notacceptable;</td>
<td>Inform user that the reserved roomnick must be used</td>
</tr>
<tr>
<td>&registration;</td>
<td>Inform user that he or she is not on the member list</td>
</tr>
<tr>
<td>&conflict;</td>
<td>Inform user that his or her desired room nickname is in use or registered by another user</td>
</tr>
<tr>
<td>&unavailable;</td>
<td>Inform user that the maximum number of users has been reached</td>
</tr>
</table>
</section3>
</section2>
<section2 topic='Occupant Modification of the Room Subject' anchor='subject-occupant'>
@ -1759,7 +1799,7 @@
</section2>
<section2 topic='Sending a Private Message' anchor='privatemessage'>
<p>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.</p>
<p>Since each occupant has its own 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.</p>
<example caption='Occupant Sends Private Message'><![CDATA[
<message
from='wiccarocks@shakespeare.lit/laptop'
@ -2058,7 +2098,7 @@
<li>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)</li>
<li>Sends an invitation to the second person and the third person, including a &lt;continue/&gt; element (optionally including a 'thread' attribute).</li>
</ol>
<p>Note: The new room SHOULD be non-anonymous, MAY be an instant room as specified in the <link url='#createroom-instant'>Creating an Instant Room</link> section of this document, and MAY have a unique room name received from the service as specified in the <link url='#createroom-instant-unique'>Requesting a Unique Room Name</link> section of this document.</p>
<p>Note: The new room SHOULD be non-anonymous and MAY be an instant room as specified in the <link url='#createroom-instant'>Creating an Instant Room</link> section of this document.</p>
<p>Note: If the one-to-one chat messages included a &THREAD; element, the person who creates the room SHOULD include the ThreadID with the history messages, specify the ThreadID in the invitations as the value of the &lt;continue/&gt; element's 'thread' attribute, and include the ThreadID in any new messages sent to the room. Use of ThreadIDs is RECOMMENDED because it helps to provide continuity between the one-to-one chat and the multi-user chat.</p>
<example caption='Continuing the Discussion I: User Creates Room'><![CDATA[
<presence
@ -3016,7 +3056,7 @@
</query>
</iq>
]]></example>
<p>The admin MAY then modify the ban list. In order to do so, the admin MUST send the changed items (i.e., only the "delta") back to the service; each item MUST include the 'affiliation' attribute (normally set to a value of "outcast" to ban or "none" to remove ban) 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 the outcast affiliation); in addition, the reason and actor elements are OPTIONAL:</p>
<p>The admin MAY then modify the ban list. In order to do so, the admin MUST send the changed items (i.e., only the "delta") back to the service; each item MUST include the 'affiliation' attribute (normally set to a value of "outcast" to ban or "none" to remove ban) 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 outcast); in addition, the reason and actor elements are OPTIONAL:</p>
<example caption='Admin Sends Modified Ban List to Service'><![CDATA[
<iq from='kinghenryv@shakespeare.lit/throne'
id='ban3'
@ -3210,7 +3250,7 @@
</query>
</iq>
]]></example>
<p>The admin MAY then modify the member 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 'affiliation' attribute (normally set to a value of "member" or "none") and 'jid' attribute but SHOULD NOT include the 'nick' attribute (unless modifying the user's reserved nickname) and MUST NOT include the 'role' attribute (which is used to manage roles such as participant rather than the member affiliation):</p>
<p>The admin MAY then modify the member 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 'affiliation' attribute (normally set to a value of "member" or "none") and 'jid' attribute but SHOULD NOT include the 'nick' attribute (unless modifying the user's reserved nickname) and MUST NOT include the 'role' attribute (which is used to manage roles such as participant rather than affiliations such as member):</p>
<example caption='Admin Sends Modified Member List to Service'><![CDATA[
<iq from='crone1@shakespeare.lit/desktop'
id='member4'
@ -3529,9 +3569,9 @@
</section1>
<section1 topic='Owner Use Cases' anchor='owner'>
<p>Every room MUST have at least one owner, and that owner (or a successor) is a long-lived attribute of the room for as long as the room exists (e.g., the owner does not lose ownership on exiting a persistent room). This document assumes that the (initial) room owner is the individual who creates the room and that only a room owner has the right to change defining room configuration settings such as the room type. Ideally, room owners will be able to specify not only the room types (password-protected, members-only, etc.) but also certain attributes of the room as listed in the <link url='#reqs'>Requirements</link> section of this document. In addition, it would be good if an owner were able to specify the JIDs of other owners, but that shall be determined by the implementation.</p>
<p>In order to provide the necessary flexibility for a wide range of configuration options, Data Forms (<cite>XEP-0004</cite>) shall be used for room configuration, triggered by use of the 'http://jabber.org/protocol/muc' namespace. That is, if an entity does not include the MUC namespace in its room join/create request, then the service shall create the room and not wait for configuration via Data Forms before creating the room (this ensures backwards-compatibility with the old GC protocol); however, if the room join/create request includes the MUC extension, then the service shall require configuration via Data Forms before creating and unlocking the room.</p>
<p>Note: The configuration options shown below address all of the features and room types listed in the requirements section of this document; however, the exact configuration options and form layout shall be determined by the implementation or specific deployment. Also, these are examples only and are not intended to define the only allowed or required configuration options for rooms. A given implementation or deployment MAY choose to provide additional configuration options (profanity filters, setting the default language for a room, message logging, etc.), which is why the use of the 'jabber:x:data' protocol is valuable here.</p>
<p>Every room MUST have at least one owner, and that owner (or a successor) is a long-lived attribute of the room for as long as the room exists (e.g., the owner does not lose ownership on exiting a persistent room). This document assumes that the (initial) room owner is the individual who creates the room and that only a room owner has the right to change defining room configuration settings such as the room type. Room owners can specify not only the room types (password-protected, members-only, etc.) but also certain attributes of the room as listed in the <link url='#reqs'>Requirements</link> section of this document. In addition, an owner can also specify the JIDs of other owners, if supported by the implementation.</p>
<p>In order to provide the necessary flexibility for a wide range of configuration options, Data Forms (<cite>XEP-0004</cite>) are used for room configuration, triggered by use of the 'http://jabber.org/protocol/muc' namespace. If an entity does not include the MUC namespace in its room join/create request, then the service shall create the room and not wait for configuration via Data Forms before creating the room (this ensures backwards-compatibility with the old GC protocol); however, if the room join/create request includes the MUC extension, then the service shall require configuration via Data Forms before creating and unlocking the room.</p>
<p>Note: The configuration options shown below address all of the features and room types listed in the requirements section of this document; however, the exact configuration options and form layout shall be determined by the implementation or specific deployment. Also, these are examples only and are not intended to define the only allowed or required configuration options for rooms. A given implementation or deployment MAY choose to provide additional configuration options (clearance levels, profanity filters, supported languages, message logging, etc.), which is why the use of the 'jabber:x:data' protocol is valuable here.</p>
<section2 topic='Creating a Room' anchor='createroom'>
<section3 topic='General Considerations' anchor='createroom-general'>
<p>The privilege to create rooms MAY be restricted to certain users or MAY be reserved to an administrator of the service. If access is restricted and a user attempts to create a room, the service MUST return a &notallowed; error:</p>
@ -3554,11 +3594,11 @@
</ul>
<p>The workflow for creating and configuring such rooms is as follows:</p>
<ol start='1'>
<li><p>The user MUST send presence to &ROOMJID; and signal his or her support for the Multi-User Chat protocol by including extended presence information in an empty &lt;x/&gt; child element qualified by the 'http://jabber.org/protocol/muc' namespace (note the lack of an '#owner' or '#user' fragment).</p></li>
<li><p>The user sends presence to &ROOMJID; and signal his or her support for the Multi-User Chat protocol by including extended presence information in an empty &lt;x/&gt; child element qualified by the 'http://jabber.org/protocol/muc' namespace (note the lack of an '#owner' or '#user' fragment).</p></li>
<li><p>If this user is allowed to create a room and the room does not yet exist, the service MUST create the room according to some default configuration, assign the requesting user as the initial room owner, and add the owner to the room but not allow anyone else to enter the room (effectively "locking" the room). The initial presence stanza received by the owner from the room MUST include extended presence information indicating the user's status as an owner and acknowledging that the room has been created (via status code 201) and is awaiting configuration.</p></li>
<li><p>If the initial room owner would like to create and configure a reserved room, the room owner MUST then request a configuration form by sending an IQ stanza of type "get" to the room containing an empty &lt;query/&gt; element qualified by the 'http://jabber.org/protocol/muc#owner' namespace, then complete Steps 4 and 5. If the room owner would prefer to create an instant room, the room owner MUST send a query element qualified by the 'http://jabber.org/protocol/muc#owner' namespace and containing an empty &lt;x/&gt; element of type "submit" qualified by the 'jabber:x:data' namespace, then skip to Step 6.</p></li>
<li><p>If the room owner requested a configuration form, the service MUST send an IQ to the room owner containing a configuration form qualified by the 'jabber:x:data' namespace. If there are no configuration options available, the room MUST return an empty query element to the room owner.</p></li>
<li><p>The initial room owner SHOULD provide a starting configuration for the room (or accept the default configuration) by sending an IQ of type "set" containing the completed configuration form. Alternatively, the room owner MAY cancel the configuration process. (An implementation MAY set a timeout for initial configuration, such that if the room owner does not configure the room within the timeout period, the room owner is assumed to have accepted the default configuration or to have cancelled the configuration process.)</p></li>
<li><p>If the room owner requested a configuration form, the service MUST send an IQ result to the room owner containing a configuration form qualified by the 'jabber:x:data' namespace. If there are no configuration options available, the room MUST return an empty query element to the room owner.</p></li>
<li><p>The initial room owner SHOULD provide a starting configuration for the room (or accept the default configuration) by sending an IQ set containing the completed configuration form. Alternatively, the room owner MAY cancel the configuration process. (An implementation MAY set a timeout for initial configuration, such that if the room owner does not configure the room within the timeout period, the room owner is assumed to have accepted the default configuration or to have cancelled the configuration process.)</p></li>
<li><p>Once the service receives the completed configuration form from the initial room owner (or receives a request for an instant room), the service MUST "unlock" the room (i.e., allow other users to enter the room) and send an IQ of type "result" to the room owner. If the service receives a cancellation, it MUST destroy the room.</p></li>
</ol>
<p>The protocol for this workflow is shown in the examples below.</p>
@ -3583,7 +3623,7 @@
</x>
</presence>
]]></example>
<p>After receiving notification that the room has been created, the room owner needs to decide whether to accept the default room configuration (i.e., create an "instant room") or configure the room to have something other than the default room configuration (i.e., create a "reserved room"). The protocol flows for completing those two use cases are shown in the following sections.</p>
<p>After receiving notification that the room has been created, the room owner needs to decide whether to accept the default room configuration (i.e., create an "instant room") or configure the room to use something other than the default room configuration (i.e., create a "reserved room"). The protocol flows for completing those two use cases are shown in the following sections.</p>
<p>Note: If the presence stanza sent to a nonexistent room does not include an &X; element qualified by the 'http://jabber.org/protocol/muc' namespace as shown above, the service SHOULD create a default room without delay (i.e., it MUST assume that the client supports GC rather than MUC and therefore it MUST NOT lock the room while waiting for the room creator to either accept an instant room or configure a reserved room).</p>
</section3>
@ -3777,7 +3817,7 @@
<field type='fixed'>
<value>
You may specify additional people who have
administrative privileges in the room. Please
admin status in the room. Please
provide one Jabber ID per line.
</value>
</field>
@ -3900,47 +3940,13 @@
</iq>
]]></example>
<p>If the room owner cancels the initial configuration, the service SHOULD destroy the room, making sure to send unavailable presence to the room owner (see the "Destroying a Room" use case for protocol details).</p>
<p>If the room owner becomes unavailable for any reason before submitting the form (e.g., a lost connection), the service will receive a presence stanza of type "unavailable" from the owner to the owner's &ROOMJID; or to &ROOM; (or both). The service MUST then destroy the room, sending a presence stanza of type "unavailable" from the room to the owner including a &lt;destroy/&gt; element and reason (if provided) as defined in the <link url='#destroyroom'>Destroying a Room</link> section of this document.</p>
</section3>
<section3 topic='Requesting a Unique Room Name' anchor='createroom-unique'>
<p>In some situations (e.g., when <link url='#continue'>Converting a One-to-One Chat Into a Conference</link>), the room creator might want to request a unique room name before attempting to create the room (e.g., to avoid the possibility of a room conflict). In order to facilitate this, a service MAY support the feature described in this section. (If a service does support this feature, it MUST return a feature of "http://jabber.org/protocol/muc#unique" in its response to service discovery information requests.)</p>
<p>The room creator requests a unique room name by sending an IQ-get to the service itself, containing an empty &lt;unique/&gt; element qualified by the 'http://jabber.org/protocol/muc#unique' namespace:</p>
<example caption='Entity Requests Unique Room Name'><![CDATA[
<iq from='crone1@shakespeare.lit/desktop'
id='unique1'
to='chat.shakespeare.lit'
type='get'>
<unique xmlns='http://jabber.org/protocol/muc#unique'/>
</iq>
]]></example>
<p>If the service supports this feature, it SHOULD return a unique room name as the XML character data of the &lt;unique/&gt; element (but not create the room):</p>
<example caption='Service Returns Unique Room Name'><![CDATA[
<iq from='chat.shakespeare.lit'
id='unique1'
to='crone1@shakespeare.lit/desktop'
type='result'>
<unique xmlns='http://jabber.org/protocol/muc#unique'>
6d9423a55f499b29ad20bf7b2bdea4f4b885ead1
</unique>
</iq>
]]></example>
<p>The service MAY refuse to return a unique room name to entities that are not entitled to create rooms, entities that have sent an excessive number of requests for unique room names, etc.</p>
<p>The service MAY use any algorithm that ensures the creation of a room name that will be permanently unique in the context of the service (e.g., a SHA-1 hash of the requesting JID, datetime, and random salt).</p>
<p>The room creator would then use the XML character data of the &lt;unique/&gt; element as the node identifier portion of the room JID it requests:</p>
<example caption='Owner Creates Room With Unique Name'><![CDATA[
<presence
from='crone1@shakespeare.lit/desktop'
to='6d9423a55f499b29ad20bf7b2bdea4f4b885ead1@chat.shakespeare.lit/firstwitch'>
<x xmlns='http://jabber.org/protocol/muc'/>
</presence>
]]></example>
<p>If the room owner becomes unavailable for any reason before submitting the form (e.g., a lost connection), the service will receive a presence stanza of type "unavailable" from the owner to the owner's &ROOMJID;. The service MUST then destroy the room, sending a presence stanza of type "unavailable" from the room to the owner including a &lt;destroy/&gt; element and reason (if provided) as defined in the <link url='#destroyroom'>Destroying a Room</link> section of this document.</p>
</section3>
</section2>
<section2 topic='Subsequent Room Configuration' anchor='roomconfig'>
<p>At any time after specifying the initial configuration of the room, a room owner might want to change the configuration. In order to initiate this process, a room owner MUST request a new configuration form from the room by sending an IQ to &ROOM; containing an empty &lt;query/&gt; element qualified by the 'http://jabber.org/protocol/muc#owner' namespace.</p>
<p>At any time after specifying the initial configuration of the room, a room owner might want to change the configuration. In order to initiate this process, a room owner requests a new configuration form from the room by sending an IQ get to &ROOM; containing an empty &lt;query/&gt; element qualified by the 'http://jabber.org/protocol/muc#owner' namespace.</p>
<example caption='Owner Requests Configuration Form'><![CDATA[
<iq from='crone1@shakespeare.lit/desktop'
id='config1'
@ -3971,8 +3977,8 @@
<x xmlns='jabber:x:data' type='form'>
<title>Configuration for "coven" Room</title>
<instructions>
Complete this form to make changes to
the configuration of your room.
Complete this form to modify the
configuration of your room.
</instructions>
<field
type='hidden'
@ -4118,7 +4124,7 @@
<field type='fixed'>
<value>
You may specify additional people who have
administrative privileges in the room. Please
admin status in the room. Please
provide one Jabber ID per line.
</value>
</field>
@ -4144,7 +4150,7 @@
</iq>
]]></example>
<p>If there are no configuration options available, the service MUST return an empty query element to the room owner as shown in the previous use case.</p>
<p>The room owner SHOULD then submit the form with updated configuration information.</p>
<p>The room owner then submits the form with updated configuration information. (Example not shown.)</p>
<p>Alternatively, the room owner MAY cancel the configuration process:</p>
<example caption='Owner Cancels Subsequent Configuration'><![CDATA[
<iq from='crone1@shakespeare.lit/desktop'
@ -4157,7 +4163,7 @@
</iq>
]]></example>
<p>If the room owner cancels the subsequent configuration, the service MUST leave the configuration of the room as it was before the room owner initiated the subsequent configuration process.</p>
<p>If as a result of a change in the room configuration a room admin loses administrative privileges while the admin is in the room, the room MUST send updated presence for that individual to all occupants, denoting the change in status by including an &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an &lt;item/&gt; child with the 'affiliation' attribute set to a value of "member" and the 'role' attribute set to a value of "participant" or "visitor" as appropriate for the affiliation level and the room type:</p>
<p>If as a result of a change in the room configuration a room admin loses admin status while in the room, the room MUST send updated presence for that individual to all occupants, denoting the change in status by including an &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an &lt;item/&gt; child with the 'affiliation' attribute set to a value of "member" or "non" and the 'role' attribute set to a value of "participant" or "visitor" as appropriate for the affiliation level and the room type:</p>
<example caption="Service Notes Loss of Admin Affiliation"><![CDATA[
<presence
from='coven@chat.shakespeare.lit/secondwitch'
@ -4171,7 +4177,7 @@
[ ... ]
]]></example>
<p>If as a result of a change in the room configuration a user gains administrative privileges while the user is in the room, the room MUST send updated presence for that individual to all occupants, denoting the change in status by including an &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an &lt;item/&gt; child with the 'affiliation' attribute set to a value of "admin" and the 'role' attribute set to a value of "admin":</p>
<p>If as a result of a change in the room configuration a user gains admin status while in the room, the room MUST send updated presence for that individual to all occupants, denoting the change in status by including an &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an &lt;item/&gt; child with the 'affiliation' attribute set to a value of "admin" and the 'role' attribute set to a value of "moderator":</p>
<example caption="Service Notes Gain of Admin Affiliation to All Users"><![CDATA[
<presence
from='coven@chat.shakespeare.lit/secondwitch'
@ -4185,7 +4191,7 @@
[ ... ]
]]></example>
<p>If as a result of a change in the room configuration a room owner loses owner privileges while that owner is in the room, the room MUST send updated presence for that individual to all occupants, denoting the change in status by including an &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an &lt;item/&gt; child with the 'affiliation' attribute set to a value of "admin" and the 'role' attribute set to an appropriate value given the affiliation and room type ("moderator" is recommended).</p>
<p>If as a result of a change in the room configuration a room owner loses owner status while that owner is in the room, the room MUST send updated presence for that individual to all occupants, denoting the change in status by including an &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an &lt;item/&gt; child with the 'affiliation' attribute set to a value of "admin" and the 'role' attribute set to an appropriate value given the affiliation and room type ("moderator" is recommended).</p>
<example caption="Service Notes Loss of Owner Affiliation"><![CDATA[
<presence
from='coven@chat.shakespeare.lit/secondwitch'
@ -4199,8 +4205,8 @@
[ ... ]
]]></example>
<p>A service MUST NOT allow an owner to revoke his or her own ownership privileges if there are no other owners; if an owner attempts to do this, the service MUST return a &conflict; error to the owner. However, a service SHOULD allow an owner to revoke his or her own ownership privileges if there are other owners.</p>
<p>If as a result of a change in the room configuration a user gains ownership privileges while the user is in the room, the room MUST send updated presence for that individual to all occupants, denoting the change in status by including an &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an &lt;item/&gt; child with the 'affiliation' attribute set to a value of "owner" and the 'role' attribute set to an appropriate value given the affiliation and room type ("moderator" is recommended).</p>
<p>A service MUST NOT allow an owner to revoke his or her own owner status if there are no other owners; if an owner attempts to do this, the service MUST return a &conflict; error to the owner. However, a service SHOULD allow an owner to revoke his or her own owner status if there are other owners.</p>
<p>If as a result of a change in the room configuration a user gains owner status while in the room, the room MUST send updated presence for that individual to all occupants, denoting the change in status by including an &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an &lt;item/&gt; child with the 'affiliation' attribute set to a value of "owner" and the 'role' attribute set to an appropriate value given the affiliation and room type ("moderator" is recommended).</p>
<example caption="Service Notes Gain of Owner Affiliation to All Users"><![CDATA[
<presence
from='coven@chat.shakespeare.lit/secondwitch'
@ -4240,9 +4246,9 @@
</section2>
<section2 topic='Granting Ownership Privileges' anchor='grantowner'>
<p>If allowed by an implementation, an owner MAY grant ownership privileges to another user; this is done by changing the user's affiliation to "owner":</p>
<example caption='Owner Grants Ownership Privileges'><![CDATA[
<section2 topic='Granting Owner Status' anchor='grantowner'>
<p>If allowed by an implementation, an owner MAY grant owner status to another user; this is done by changing the user's affiliation to "owner":</p>
<example caption='Owner Grants Owner Status'><![CDATA[
<iq from='crone1@shakespeare.lit/desktop'
id='owner1'
to='coven@chat.shakespeare.lit'
@ -4254,7 +4260,7 @@
</iq>
]]></example>
<p>The &lt;reason/&gt; element is OPTIONAL.</p>
<example caption='Owner Grants Ownership Privileges (With a Reason)'><![CDATA[
<example caption='Owner Grants Owner Status (With a Reason)'><![CDATA[
<iq from='crone1@shakespeare.lit/desktop'
id='owner1'
to='coven@chat.shakespeare.lit'
@ -4274,8 +4280,8 @@
to='crone1@shakespeare.lit/desktop'
type='result'/>
]]></example>
<p>If the user is in the room, the service MUST then send updated presence from this individual to all occupants, indicating the granting of ownership privileges by including an &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an &lt;item/&gt; child with the 'affiliation' attribute set to a value of "owner" and the 'role' attribute set to an appropriate value given the affiliation and room type ("moderator" is recommended).</p>
<example caption="Service Sends Notice of Ownership Privileges to All Occupants"><![CDATA[
<p>If the user is in the room, the service MUST then send updated presence from this individual to all occupants, indicating the granting of owner status by including an &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an &lt;item/&gt; child with the 'affiliation' attribute set to a value of "owner" and the 'role' attribute set to an appropriate value given the affiliation and room type ("moderator" is recommended).</p>
<example caption="Service Sends Notice of Owner Status to All Occupants"><![CDATA[
<presence
from='coven@chat.shakespeare.lit/hecate'
to='crone1@shakespeare.lit/desktop'>
@ -4288,8 +4294,8 @@
[ ... ]
]]></example>
<p>If the user is not in the room, the service MAY send a message from the room itself to the room occupants, indicating the granting of ownership privileges by including an &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an &lt;item/&gt; child with the 'affiliation' attribute set to a value of "owner".</p>
<example caption="Service Sends Notice of Ownership Privileges to All Occupants"><![CDATA[
<p>If the user is not in the room, the service MAY send a message from the room itself to the room occupants, indicating the granting of owner status by including an &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an &lt;item/&gt; child with the 'affiliation' attribute set to a value of "owner".</p>
<example caption="Service Sends Notice of Owner Status to All Occupants"><![CDATA[
<message
from='chat.shakespeare.lit'
id='22B0F570-526A-4F22-BDE3-52EC3BB18371'
@ -4305,9 +4311,9 @@
]]></example>
</section2>
<section2 topic='Revoking Ownership Privileges' anchor='revokeowner'>
<p>An implementation MAY allow an owner to revoke another user's ownership privileges; this is done by changing the user's affiliation to something other than "owner":</p>
<example caption='Owner Revokes Ownership Privileges'><![CDATA[
<section2 topic='Revoking Owner Status' anchor='revokeowner'>
<p>An implementation MAY allow an owner to revoke another user's owner status; this is done by changing the user's affiliation to something other than "owner":</p>
<example caption='Owner Revokes Owner Status'><![CDATA[
<iq from='crone1@shakespeare.lit/desktop'
id='owner2'
to='coven@chat.shakespeare.lit'
@ -4319,7 +4325,7 @@
</iq>
]]></example>
<p>The &lt;reason/&gt; element is OPTIONAL.</p>
<example caption='Owner Revokes Ownership Privileges (With a Reason)'><![CDATA[
<example caption='Owner Revokes Owner Status (With a Reason)'><![CDATA[
<iq from='crone1@shakespeare.lit/desktop'
id='owner2'
to='coven@chat.shakespeare.lit'
@ -4332,9 +4338,9 @@
</query>
</iq>
]]></example>
<p>A service MUST NOT allow an owner to revoke his or her own ownership privileges if there are no other owners; if an owner attempts to do this, the service MUST return a &conflict; error to the owner. However, a service SHOULD allow an owner to revoke his or her own ownership privileges if there are other owners.</p>
<p>If an implementation does not allow one owner to revoke another user's ownership privileges, the implementation MUST return a &notauthorized; error to the owner who made the request.</p>
<p>Note: Allowing an owner to remove another user's ownership privileges can compromise the control model for room management; therefore this feature is OPTIONAL, and implementations are encouraged to support owner removal through an interface that is open only to individuals with service-wide administrative privileges.</p>
<p>A service MUST NOT allow an owner to revoke his or her own owner status if there are no other owners; if an owner attempts to do this, the service MUST return a &conflict; error to the owner. However, a service SHOULD allow an owner to revoke his or her own owner status if there are other owners.</p>
<p>If an implementation does not allow one owner to revoke another user's owner status, the implementation MUST return a &notauthorized; error to the owner who made the request.</p>
<p>Note: Allowing an owner to remove another user's owner status can compromise the control model for room management; therefore this feature is OPTIONAL, and implementations are encouraged to support owner removal through an interface that is open only to individuals with service-wide admin status.</p>
<p>In all other cases, the service MUST remove the user from the owner list and then inform the owner of success:</p>
<example caption='Service Informs Owner of Success'><![CDATA[
<iq from='coven@chat.shakespeare.lit'
@ -4342,7 +4348,7 @@
to='crone1@shakespeare.lit/desktop'
type='result'/>
]]></example>
<p>If the user is in the room, the service MUST then send updated presence from this individual to all occupants, indicating the loss of ownership privileges by sending a presence element that contains an &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an &lt;item/&gt; child with the 'affiliation' attribute set to a value other than "owner" and the 'role' attribute set to an appropriate value:</p>
<p>If the user is in the room, the service MUST then send updated presence from this individual to all occupants, indicating the loss of owner status by sending a presence element that contains an &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an &lt;item/&gt; child with the 'affiliation' attribute set to a value other than "owner" and the 'role' attribute set to an appropriate value:</p>
<example caption="Service Notes Loss of Owner Affiliation"><![CDATA[
<presence
from='coven@chat.shakespeare.lit/secondwitch'
@ -4356,7 +4362,7 @@
[ ... ]
]]></example>
<p>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 ownership privileges by including an &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an &lt;item/&gt; child with the 'affiliation' attribute set to a value other than "owner".</p>
<p>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 &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an &lt;item/&gt; child with the 'affiliation' attribute set to a value other than "owner".</p>
<example caption="Service Notes Loss of Owner Affiliation"><![CDATA[
<message
from='chat.shakespeare.lit'
@ -4398,7 +4404,7 @@
</query>
</iq>
]]></example>
<p>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; <note>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.</note> 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 the owner affiliation):</p>
<p>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; <note>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.</note> 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):</p>
<example caption='Owner Sends Modified Owner List to Service'><![CDATA[
<iq from='bard@shakespeare.lit/globe'
id='owner4'
@ -4416,16 +4422,12 @@
id='ownertest'
to='hag66@shakespeare.lit/pda'
type='error'>
<query xmlns='http://jabber.org/protocol/muc#admin'>
<item affiliation='owner'
jid='hecate@shakespeare.lit'/>
</query>
<error type='auth'>
<forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
]]></example>
<p>A service MUST NOT allow an owner to revoke his or her own ownership privileges if there are no other owners; if an owner attempts to do this, the service MUST return a &conflict; error to the owner. However, a service SHOULD allow an owner to revoke his or her own ownership privileges if there are other owners.</p>
<p>A service MUST NOT allow an owner to revoke his or her own owner status if there are no other owners; if an owner attempts to do this, the service MUST return a &conflict; error to the owner. However, a service SHOULD allow an owner to revoke his or her own owner status if there are other owners.</p>
<p>In all other cases, the service MUST modify owner list and then inform the owner of success:</p>
<example caption='Service Informs Owner of Success'><![CDATA[
<iq from='coven@chat.shakespeare.lit'
@ -4436,8 +4438,8 @@
<p>The service MUST also send presence notifications related to any affiliation changes that result from modifying the owner list as previously described.</p>
</section2>
<section2 topic='Granting Administrative Privileges' anchor='grantadmin'>
<p>An owner can grant administrative privileges to a member or unaffiliated user; this is done by changing the user's affiliation to "admin":</p>
<section2 topic='Granting Admin Status' anchor='grantadmin'>
<p>An owner can grant admin status to a member or an unaffiliated user; this is done by changing the user's affiliation to "admin":</p>
<example caption='Owner Grants Admin Privileges'><![CDATA[
<iq from='crone1@shakespeare.lit/desktop'
id='admin1'
@ -4470,8 +4472,8 @@
to='crone1@shakespeare.lit/desktop'
type='result'/>
]]></example>
<p>If the user is in the room, the service MUST then send updated presence from this individual to all occupants, indicating the granting of administrative privileges by including an &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an &lt;item/&gt; child with the 'affiliation' attribute set to a value of "admin" and the 'role' attribute set to an appropriate value given the affiliation and room type.</p>
<example caption="Service Sends Notice of Administrative Privileges to All Occupants"><![CDATA[
<p>If the user is in the room, the service MUST then send updated presence from this individual to all occupants, indicating the granting of admin status by including an &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an &lt;item/&gt; child with the 'affiliation' attribute set to a value of "admin" and the 'role' attribute set to an appropriate value given the affiliation and room type (typically "moderator").</p>
<example caption="Service Sends Notice of Admin Status to All Occupants"><![CDATA[
<presence
from='coven@chat.shakespeare.lit/secondwitch'
to='crone1@shakespeare.lit/desktop'>
@ -4484,8 +4486,8 @@
[ ... ]
]]></example>
<p>If the user is not in the room, the service MAY send a message from the room itself to the room occupants, indicating the granting of administrative privileges by including an &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an &lt;item/&gt; child with the 'affiliation' attribute set to a value of "admin".</p>
<example caption="Service Sends Notice of Administrative Privileges to All Occupants"><![CDATA[
<p>If the user is not in the room, the service MAY send a message from the room itself to the room occupants, indicating the granting of admin status by including an &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an &lt;item/&gt; child with the 'affiliation' attribute set to a value of "admin".</p>
<example caption="Service Sends Notice of Admin Status to All Occupants"><![CDATA[
<message
from='chat.shakespeare.lit'
id='C75B919A-30B3-4233-AE89-6E9834E26929'
@ -4501,9 +4503,9 @@
]]></example>
</section2>
<section2 topic='Revoking Administrative Privileges' anchor='revokeadmin'>
<p>An owner might want to revoke a user's administrative privileges; this is done by changing the user's affiliation to something other than "admin" or "owner":</p>
<example caption='Owner Revokes Administrative Privileges'><![CDATA[
<section2 topic='Revoking Admin Status' anchor='revokeadmin'>
<p>An owner might want to revoke a user's admin status; this is done by changing the user's affiliation to something other than "admin" or "owner".</p>
<example caption='Owner Revokes Admin Status'><![CDATA[
<iq from='crone1@shakespeare.lit/desktop'
id='admin2'
to='coven@chat.shakespeare.lit'
@ -4515,7 +4517,7 @@
</iq>
]]></example>
<p>The &lt;reason/&gt; element is OPTIONAL.</p>
<example caption='Owner Revokes Administrative Privileges (With a Reason)'><![CDATA[
<example caption='Owner Revokes Admin Status (With a Reason)'><![CDATA[
<iq from='crone1@shakespeare.lit/desktop'
id='admin2'
to='coven@chat.shakespeare.lit'
@ -4535,7 +4537,7 @@
to='crone1@shakespeare.lit/desktop'
type='result'/>
]]></example>
<p>If the user is in the room, the service MUST then send updated presence from this individual to all occupants, indicating the loss of administrative privileges by sending a presence element that contains an &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an &lt;item/&gt; child with the 'affiliation' attribute set to a value other than "admin" or "owner" and the 'role' attribute set to an appropriate value given the affiliation level and the room type:</p>
<p>If the user is in the room, the service MUST then send updated presence from this individual to all occupants, indicating the loss of admin status by sending a presence element that contains an &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an &lt;item/&gt; child with the 'affiliation' attribute set to a value other than "admin" or "owner" and the 'role' attribute set to an appropriate value given the affiliation level and the room type (typically "participant").</p>
<example caption="Service Notes Loss of Admin Affiliation"><![CDATA[
<presence
from='coven@chat.shakespeare.lit/secondwitch'
@ -4549,7 +4551,7 @@
[ ... ]
]]></example>
<p>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 administrative privileges by including an &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an &lt;item/&gt; child with the 'affiliation' attribute set to a value other than "admin".</p>
<p>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 admin status by including an &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an &lt;item/&gt; child with the 'affiliation' attribute set to a value other than "admin".</p>
<example caption="Service Notes Loss of Admin Affiliation"><![CDATA[
<message
from='chat.shakespeare.lit'
@ -4594,7 +4596,7 @@
</query>
</iq>
]]></example>
<p>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; <note>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.</note> 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 the admin affiliation):</p>
<p>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; <note>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.</note> 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).</p>
<example caption='Owner Sends Modified Admin List to Service'><![CDATA[
<iq from='bard@shakespeare.lit/globe'
id='admin4'
@ -4610,16 +4612,12 @@
</query>
</iq>
]]></example>
<p>Only owners shall be allowed to modify the admin list. If a non-owner attempts to view or modify the admin list, the service MUST deny the request and return a &forbidden; error to the sender:</p>
<p>Only owners shall be allowed to modify the admin list. If a non-owner attempts to view or modify the admin list, the service MUST deny the request and return a &forbidden; error to the sender.</p>
<example caption='Service Returns Error on Attempt by Non-Owner to Modify Admin List'><![CDATA[
<iq from='coven@chat.shakespeare.lit'
id='admintest'
to='hag66@shakespeare.lit/pda'
type='error'>
<query xmlns='http://jabber.org/protocol/muc#admin'>
<item affiliation='admin'
jid='hecate@shakespeare.lit'/>
</query>
<error type='auth'>
<forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
@ -4638,7 +4636,7 @@
<section2 topic='Destroying a Room' anchor='destroyroom'>
<p>A room owner MUST be able to destroy a room, especially if the room is persistent. The workflow is as follows:</p>
<ol start='1'>
<li><p>The room owner requests that the room be destroyed, specifying a reason and an alternate venue if desired.</p></li>
<li><p>The room owner requests that the room be destroyed, optionally specifying a reason and an alternate venue.</p></li>
<li><p>The room removes all users from the room (including appropriate information about the alternate location and the reason for being removed) and destroys the room, even if it was defined as persistent.</p></li>
</ol>
<p>Other than the foregoing, this document does not specify what (if anything) a MUC service implementation shall do as a result of a room destruction request. For example, if the room was defined as persistent, an implementation MAY choose to lock the room ID so that it cannot be re-used, redirect enter requests to the alternate venue, or invite the current participants to the new room; however, such behavior is OPTIONAL.</p>
@ -4720,102 +4718,31 @@
</section1>
<section1 topic='Error and Status Codes' anchor='errorstatus'>
<section2 topic='Error Codes' anchor='errorcodes'>
<p>The error codes associated with the 'http://jabber.org/protocol/muc#user' namespace are fairly straightforward, as summarized in the following table. For detailed information about mapping legacy error codes to XMPP-style error types and conditions, refer to &xep0086;; implementations SHOULD support both legacy and XMPP error handling.</p>
<table caption='Error Codes for http://jabber.org/protocol/muc#user Namespace'>
<tr>
<th>Code</th>
<th>Type</th>
<th>Element</th>
<th>Context</th>
<th>Purpose</th>
</tr>
<tr>
<td>401</td>
<td>Error</td>
<td>Presence</td>
<td>Entering a room</td>
<td>Inform user that a password is required</td>
</tr>
<tr>
<td>403</td>
<td>Error</td>
<td>Presence</td>
<td>Entering a room</td>
<td>Inform user that he or she is banned from the room</td>
</tr>
<tr>
<td>404</td>
<td>Error</td>
<td>Presence</td>
<td>Entering a room</td>
<td>Inform user that the room does not exist</td>
</tr>
<tr>
<td>405</td>
<td>Error</td>
<td>Presence</td>
<td>Entering a room</td>
<td>Inform user that room creation is restricted</td>
</tr>
<tr>
<td>406</td>
<td>Error</td>
<td>Presence</td>
<td>Entering a room</td>
<td>Inform user that the reserved roomnick must be used</td>
</tr>
<tr>
<td>407</td>
<td>Error</td>
<td>Presence</td>
<td>Entering a room</td>
<td>Inform user that he or she is not on the member list</td>
</tr>
<tr>
<td>409</td>
<td>Error</td>
<td>Presence</td>
<td>Entering a room</td>
<td>Inform user that his or her desired room nickname is in use or registered by another user</td>
</tr>
<tr>
<td>503</td>
<td>Error</td>
<td>Presence</td>
<td>Entering a room</td>
<td>Inform user that the maximum number of users has been reached</td>
</tr>
</table>
<p>This document does not stipulate text strings (i.e., values of the XMPP &lt;text/&gt; element) associated with the foregoing error conditions.</p>
</section2>
<section2 topic='Status Codes' anchor='statuscodes'>
<section1 topic='Status Codes' anchor='statuscodes'>
<p>Multi-User Chat uses a &lt;status/&gt; element (specifically, the 'code' attribute of the &lt;status/&gt; element) to communicate information about a user's status in a room. Over time, the number of status codes has grown quite large, and new status codes continue to be requested of the author. Therefore, these codes are now documented in a registry maintained by the XMPP Registrar. For details, refer to the <link url='#registrar-statuscodes'>Status Codes Registry</link> section of this document.</p>
<p>Note: In general, MUC status codes tend to follow the "philosophy" of status codes that is implicit in &rfc2616; and &rfc1893; (1xx codes are informational, 2xx codes specify that it is fine to continue, 3xx codes specify redirects such as being kicked or banned, x3x codes refer to system status, x7x codes refer to security or policy matters, etc.).</p>
<p>Note: If the MUC protocol were being designed today, it would specify a more flexible, XML-friendly approach rather than hardcoded status numbers; however, at this point the pain of changing the status reporting system would be greater than the benefit of doing so, which is why the status code numbers remain in use. A future version of this document may define a more XMPP-like approach to status conditions, retaining the code numbers but supplementing them with more descriptive child elements as is done in <cite>RFC 6120</cite>.</p>
</section2>
</section1>
<section1 topic='Internationalization Considerations' anchor='i18n'>
<p>As specified in <cite>RFC 6120</cite>, XMPP entities (including MUC rooms and MUC services) SHOULD respect the value of the 'xml:lang' attribute provided with any given stanza. However, simultaneous translation of groupchat messages is out of scope for this document.</p>
<p>As specified in <cite>RFC 6120</cite>, XMPP entities (including MUC rooms and MUC services) SHOULD respect the value of the 'xml:lang' attribute provided with any given stanza. However, simultaneous translation of groupchat messages is out of scope for this document (see &xep0171;).</p>
<p>The status and error codes defined herein enable a client implementation to present a localized interface; however, definition of the localized text strings for any given language community is out of scope for this document.</p>
<p>Although the labels for various data form fields are shown here in English, MUC clients SHOULD present localized text for these fields rather than the English text.</p>
<p>Nicknames can contain virtually any Unicode character introduces the possibility of nick spoofing; see &rfc6122; for a description of related security considerations.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<section2 topic='User Authentication and Authorization' anchor='security-auth'>
<p>No room entrance authentication or authorization method more secure than cleartext passwords is defined or required by this document. However, the risks involved can mitigated by the use of channel encryption and strong authentication via TLS and SASL as described in <cite>RFC 6120</cite>.</p>
<p>No room entrance authentication or authorization method more secure than cleartext passwords is defined or required by this document. Although the risks involved can mitigated somewhat by the use of channel encryption and strong authentication via TLS and SASL as described in <cite>RFC 6120</cite>, an entity that joins a room has no way of knowing if its complete communication channel to the room is encrypted (thereby protecting the plaintext password). A future specification might define an XMPP profile of SASL for use with MUC, but currently there is no such specification.</p>
</section2>
<section2 topic='End-to-End Encryption' anchor='security-e2e'>
<p>No end-to-end message or session encryption method is specified herein. Users SHOULD NOT trust a service to keep secret any text sent through a room.</p>
<p>No end-to-end message or session encryption method is specified herein. Users SHOULD NOT trust a service to keep secret any text sent through a room. A future specification might define a method for end-to-end encryption of MUC traffic, but currently there is no such specification.</p>
</section2>
<section2 topic='Privacy' anchor='security-privacy'>
<p>Depending on room configuration, a room may publicly log all discussions held in the room. A service MUST warn the user that the room is publicly logged by returning a status code of "170" with the user's initial presence, and the user's client MUST so warn the user if the room discussion is logged (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 the room is logged). A client MUST also warn the user if the room's configuration is subsequently modified to allow room logging (which the client will discover when the room sends status code 170). Note: In-room history is different from public room logging, and naturally a room cannot effectively prevent occupants from separately maintaining their own room logs, which may become public; users SHOULD exercise due caution and consider any room discussions to be effectively public.</p>
<p>Depending on room configuration, a room might publicly log all discussions held in the room. A service MUST warn the user that the room is publicly logged by returning a status code of "170" with the user's initial presence, and the user's client MUST warn the user if the room discussion is logged (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 the room is logged). A client MUST also warn the user if the room's configuration is subsequently modified to allow room logging (which the client will discover when the room sends status code 170).</p>
<p>Note: In-room history is different from public room logging, and naturally a room cannot effectively prevent occupants from separately maintaining their own room logs, which may become public; users SHOULD exercise due caution and consider any room discussions to be effectively public.</p>
</section2>
<section2 topic='Information Leaks' anchor='security-leaks'>
@ -4824,7 +4751,7 @@
</section2>
<section2 topic='Anonymity' anchor='security-anon'>
<p>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).</p>
<p>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 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 modified from semi-anonymous to non-anonymous (which the client will discover when the room sends status code 172).</p>
</section2>
<section2 topic='Denial of Service' anchor='security-dos'>
@ -4838,7 +4765,7 @@
<li>Registering multiple nicknames across a service and therefore denying the use of those nicknames.</li>
<li>Mimicking another occupant's roomnick (e.g., by adding a space at the end or substituting visually similar characters), then sending messages from that roomnick in an effort to confuse the occupants.</li>
</ol>
<p>These attacks can be mitigated but not completely prevented through the liberal use of administrative actions such as banning, the presence of automated room bots with administrative privileges, implementation of intelligent content filtering, checking the IP addresses of connected users (not always possible in a distributed system), applying voice rules to presence as well as messaging, matching room nicks using more stringent rules than the Resourceprep profile of stringprep, etc. However, experience has shown that it is impossible to fully prevent attacks of this kind.</p>
<p>These attacks can be mitigated but not completely prevented through the liberal use of administrative actions such as banning, the presence of automated room bots with admin status, implementation of intelligent content filtering, checking the IP addresses of connected users (not always possible in a distributed system), applying voice rules to presence as well as messaging, matching room nicks using more stringent rules than the Resourceprep profile of stringprep, etc. However, experience has shown that it is impossible to fully prevent attacks of this kind.</p>
</section2>
<section2 topic='Other Considerations' anchor='security-other'>
@ -4960,7 +4887,7 @@
</section2>
<section2 topic='Field Standardization' anchor='registrar-formtype'>
<p>&xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular namespace. Within MUC, there are four uses of such forms: room registration (the "muc#register" FORM_TYPE), requesting voice and approving voice requests ("muc#request"), room configuration ("muc#roomconfig"), and service discovery extensions for room information ("muc#roominfo"). The reserved fields are defined below.</p>
<p>&xep0068; defines a process for standardizing the fields used within Data Forms qualified by a particular FORM_TYPE. Within MUC, there are four uses of such forms: room registration (the "muc#register" FORM_TYPE), requesting voice and approving voice requests ("muc#request"), room configuration ("muc#roomconfig"), and service discovery extensions for room information ("muc#roominfo"). The reserved fields are defined below.</p>
<section3 topic='muc#register FORM_TYPE' anchor='registrar-formtype-register'>
<code caption='Registry Submission'><![CDATA[
<form_type>
@ -4998,7 +4925,7 @@
<field
var='muc#register_url'
type='text-single'
label='Your URL'/>
label='A Web Page'/>
</form_type>
]]></code>
</section3>
@ -5017,7 +4944,7 @@
type='text-single'
label='Requested role'/>
<field var='muc#jid'
type='text-single'
type='jid-single'
label='User ID'/>
<field var='muc#roomnick'
type='text-single'
@ -5073,7 +5000,7 @@
<field
var='muc#roomconfig_membersonly'
type='boolean'
label='Whether an Make Room Members-Only'/>
label='Whether to Make Room Members-Only'/>
<field
var='muc#roomconfig_moderatedroom'
type='boolean'
@ -5112,7 +5039,7 @@
label='Full List of Room Owners'/>
<field
var='muc#roomconfig_roomsecret'
type='text-private'
type='text-single'
label='The Room Password'/>
<field
var='muc#roomconfig_whois'
@ -5227,7 +5154,7 @@
<number>110</number>
<stanza>presence</stanza>
<context>Any room presence</context>
<purpose>Inform user that presence refers to one of its own room occupants</purpose>
<purpose>Inform user that presence refers to itself</purpose>
</statuscode>
<statuscode>
<number>170</number>
@ -5309,7 +5236,7 @@
<stanza>presence</stanza>
<context>Removal from room</context>
<purpose>Inform user that he or she is being removed from the room
because of a system shutdown</purpose>
because the MUC service is being shut down</purpose>
</statuscode>
]]></code>
</section3>
@ -5350,7 +5277,7 @@ xmpp:coven@chat.shakespeare.lit?join;password=cauldronburn
<keys>
<key>
<name>password</name>
<desc>the password required to enter a multi-user chat room</desc>
<desc>the password required to enter the room</desc>
</key>
</keys>
</querytype>
@ -5374,7 +5301,7 @@ xmpp:coven@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit
</x>
</message>
]]></example>
<p>The URI may include multiple invitees:</p>
<p>The URI can include multiple invitees:</p>
<example caption='Invite Action With Multiple Invitees: IRI/URI'><![CDATA[
xmpp:coven@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;jid=bard@shakespeare.lit
]]></example>
@ -5386,11 +5313,10 @@ xmpp:coven@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;jid=bard@shake
</x>
</message>
]]></example>
<p>The URI may also include a password:</p>
<p>The URI can also include a password:</p>
<example caption='Invite Action With Password: IRI/URI'><![CDATA[
xmpp:coven@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=cauldronburn
]]></example>
<p>If the joining user is not yet in the room, the application MUST send two stanzas: the first to join the room and the second to invite the other individual. If the joining user is in the room already, the application shall send only the invitation stanza.</p>
<example caption='Invite Action With Password: Resulting Stanza(s)'><![CDATA[
<presence to='coven@chat.shakespeare.lit/thirdwitch'>
<x xmlns='http://jabber.org/protocol/muc'/>
@ -5440,20 +5366,20 @@ xmpp:coven@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=cauld
<li><p>If a MUC service receives a message directed to the room or to a single occupant from a user who has a role of "none", the service MUST NOT deliver the message and SHOULD return the message to the sender with a &forbidden; error.</p></li>
<li><p>If a MUC service receives a message directed to a room that does not exist or is not yet unlocked, the service SHOULD return the message to the sender with an &notfound; error.</p></li>
<li><p>A MUC service SHOULD pass extended information (e.g., an XHTML version of the message body) through to occupants unchanged; however, a MUC service MAY disallow message specific extensions (see the <link url='#impl-service-traffic'>Allowable Traffic</link> section of this document).</p></li>
<li><p>A MUC client MAY generate extensions that conform to the &xep0022; or &xep0085; specification; however, a MUC service MAY disallow these extensions (see the <link url='#impl-service-traffic'>Allowable Traffic</link> section of this document).</p></li>
<li><p>A MUC client MAY generate extensions that conform to &xep0085; specification; however, a MUC service MAY disallow these extensions (see the <link url='#impl-service-traffic'>Allowable Traffic</link> section of this document).</p></li>
</ol>
</section2>
<section2 topic='Presence' anchor='bizrules-presence'>
<ol start='1'>
<li><p>A room MUST silently ignore unavailable presence received from a user who has a role of "none".</p></li>
<li><p>Only the MUC service itself SHOULD generate extended presence information about roles, affiliations, full JIDs, or status codes qualified by the 'http://jabber.org/protocol/muc#user' namespace (based on information the service knows about occupants, e.g., roles, or as a result of actions taken by a moderator or room administrator). A client SHOULD NOT presume to generate such information. If a MUC service receives such extended presence information from an occupant, it MUST NOT reflect it to other occupants. (A client MAY generate extended presence information qualified by the 'http://jabber.org/protocol/muc#user' namespace in order to supply a password, but naturally this is not reflected to other occupants.)</p></li>
<li><p>Only the MUC service itself SHOULD generate data about roles, affiliations, full JIDs, or status codes qualified by the 'http://jabber.org/protocol/muc#user' namespace (based on information the service knows about occupants, e.g., roles, or as a result of actions taken by a moderator or room administrator). A client SHOULD NOT presume to generate such information. If a MUC service receives such extended presence information from an occupant, it MUST NOT reflect it to other occupants. (A client MAY generate extended presence information qualified by the 'http://jabber.org/protocol/muc#user' namespace in order to supply a password, but naturally this is not reflected to other occupants.)</p></li>
<li><p>A MUC service SHOULD allow all other presence information to pass through, although it MAY choose to block extended presence information; see the <link url='#impl-service-traffic'>Allowable Traffic</link> section of this document.</p></li>
<li><p>In order to appropriately inform occupants of room roles and affiliations, and to make it easier for clients to track the current state of all users in the room, MUC service implementations MUST provide extended presence information about roles and affiliations in all presence stanzas, including presence stanzas of type "unavailable" sent when a user exits the room for any reason.</p></li>
<li><p>If a privilege is revoked, the service MUST note that by sending an &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an &lt;item/&gt; child element with the 'role' and/or 'affiliation' attributes set to a value that indicates the loss of the relevant privilege. All future presence stanzas for the occupant MUST include the updated role and affiliation, until and unless they change again.</p></li>
<li><p>A MUC service MUST send extended presence to a client even if the client did not send an empty &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc' namespace on entering the room; naturally, a client MUST ignore such information if it does not understand it (in accordance with <cite>RFC 6120</cite>).</p></li>
<li><p>Extended presence about roles and affiliations sent in the muc#user namespace MUST include the full JID (not the bare JID) as the value of the 'jid' attribute.</p></li>
<li><p>A client MAY send a custom exit message if desired (as is often done in IRC channels) by including a &lt;status/&gt; element in the presence stanza of type "unavailable" sent when exiting a room.</p></li>
<li><p>In order to inform occupants of room roles and affiliations, and to make it easier for clients to track the current state of all users in the room, MUC service implementations MUST provide role and affiliation data (and, if allowed by the room configuration, full JID) in all presence stanzas, including presence stanzas of type "unavailable" sent when a user exits the room for any reason.</p></li>
<li><p>If a role or affiliation is revoked, the service MUST note that fact by sending an &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an &lt;item/&gt; child element with the 'role' and/or 'affiliation' attributes set to a value that indicates the loss of the relevant status. All future presence stanzas for the occupant MUST include the updated role and affiliation, until and unless they change again.</p></li>
<li><p>A MUC service MUST include the MUC extensions even if the client did not send an empty &lt;x/&gt; element qualified by the 'http://jabber.org/protocol/muc' namespace on entering the room; naturally, a client MUST ignore such information if it does not understand it (in accordance with <cite>RFC 6120</cite>).</p></li>
<li><p>If the service includes an occupant's JabberID in the MUC presence extension, the value of hte 'jid' attribute MUST be the full JID (not the bare JID).</p></li>
<li><p>A client MAY send a custom exit message if desired (as is often done in IRC channels) by including a &lt;status/&gt; element in the presence stanza of type "unavailable" sent when <link url='#exit'>exiting a room</link>.</p></li>
</ol>
</section2>
@ -5461,8 +5387,8 @@ xmpp:coven@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=cauld
<ol start='1'>
<li><p>MUC is designed for sharing of messages and presence, not IQs. An IQ sent to the JID of the room itself is handled by the room and is not reflected to all of the room occupants.</p></li>
<li><p>If an occupant wants to send an IQ stanza to another user in a non-anonymous room, the sender SHOULD send the request directly to the recipient's bare JID or full JID, rather than attempting to send the request through the room (i.e., via the recipient's room JID).</p></li>
<li><p>If an occupant wants to send an IQ stanza to another user in a semi-anonymous room, the sender can direct the stanza to the recipient's room JID and the service MAY forward the stanza to the recipient's real JID. However, a MUC service MUST NOT reveal the sender's real JID to the recipient at any time, nor reveal the recipient's real JID to the sender.</p></li>
<li><p>A MUC client MUST send only the 'affiliation' attribute or the 'role' attribute in the &lt;item/&gt; element contained within an IQ set qualified by the 'http://jabber.org/protocol/muc#admin' namespace; if a moderator, admin, or owner attempts to modify both the affiliation and role of the same item in the same IQ set, the service MUST return a &badrequest; error to the sender. However, a MUC service MAY modify a role based on a change to an affiliation and thus MAY send presence updates that include both a modified role and a modified affiliation.</p></li>
<li><p>If an occupant wants to send an IQ stanza to another user in a semi-anonymous room, the sender can direct the stanza to the recipient's room JID and the service SHOULD forward the stanza to the recipient's real JID. However, the MUC service MUST NOT reveal the sender's real JID to the recipient at any time, nor reveal the recipient's real JID to the sender.</p></li>
<li><p>A MUC client MUST send only the 'affiliation' attribute or the 'role' attribute in the &lt;item/&gt; element contained within an IQ set qualified by the 'http://jabber.org/protocol/muc#admin' namespace; if a moderator, admin, or owner attempts to modify both the affiliation and role of the same item in the same IQ set, the service MUST return a &badrequest; error to the sender. However, the MUC service MAY modify a role based on a change to an affiliation and thus MAY send presence updates that include both a modified role and a modified affiliation.</p></li>
<li><p>In IQ sets regarding roles, a MUC client MUST include the 'nick' attribute only; in IQ results regarding roles, a MUC service MUST include the 'nick', 'role', 'affiliation', and 'jid' attributes (with the value of the latter set to the user's full JID).</p></li>
<li><p>In IQ sets regarding affiliations, a MUC client MUST include the 'jid' attribute only (with the value set to the bare JID); in IQ results regarding affiliations, a MUC service MUST NOT include the 'role' attribute, MUST include the 'affiliation' attribute and the 'jid' attribute (with the value set to the bare JID), and SHOULD include the 'nick' attribute (except if the affiliation is "outcast", since outcasts SHOULD NOT have reserved nicknames).</p></li>
</ol>
@ -5471,23 +5397,21 @@ xmpp:coven@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=cauld
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<p>The following guidelines may assist client and component developers in creating MUC implementations.</p>
<p>The following guidelines are intended to assist client and component developers in creating MUC implementations.</p>
<section2 topic='Services' anchor='impl-service'>
<ol start='1'>
<li><p>In handling messages sent by visitors in a moderated room, a MUC service MAY queue each message for approval by a moderator and MAY inform the sender that the message is being held for approval; however, such behavior is OPTIONAL, and definition of a message approval protocol (e.g., using Data Forms as defined in <cite>XEP-0004</cite>) is out of scope for this document.</p></li>
<li><p>It is common for MUC services to provide in-room messages when certain events occur, such as when the subject changes, when an occupant enters or exits, or when a room is destroyed. Such messages are entirely OPTIONAL and are left up to the implementation or deployment, but if used MUST be messages of type "groupchat" sent from the room JID itself (&ROOM;) rather than a specific occupant (&ROOMJID;). However, in general it is preferable for the receiving client to generate such messages based on events in the room (e.g., user entrances and exits) as well as specific status codes provided in MUC; this will help ensure correct localization of such messages.</p></li>
<li><p>Out of courtesy, a MUC service MAY send an out-of-room &lt;message/&gt; to an occupant who is kicked or banned, and MAY broadcast an in-room &lt;message/&gt; to all remaining occupants informing them that the occupant has been kicked or banned from the room. However, such messages are OPTIONAL, and indeed are unnecessary since the information required for a receiving client to generate such messages is communicated in the presence stanzas (specifically the status codes) sent by a MUC service.</p></li>
<li><p>Out of courtesy, a MUC service MAY send an out-of-room &lt;message/&gt; if a user's affiliation changes while the user is not in the room; the message SHOULD be sent from the room to the user's bare JID, MAY contain a &lt;body/&gt; element describing the affiliation change, and MUST contain a status code of 101.</p></li>
<li><p>There is no requirement that a MUC service shall provide special treatment for users of the older GC protocol, such as messages that contain equivalents to the extended presence information that is qualified by the 'http://jabber.org/protocol/muc#user' namespace.</p></li>
<li><p>Room types MAY be configured in any combination. A MUC service MAY support or allow any desired room types or combinations thereof.</p></li>
<li><p>Room types MAY be configured in any combination. A MUC service MAY support or allow any desired room types or combinations thereof. There is no guarantee that any such combination is sensible.</p></li>
<li><p>A MUC service MAY limit the number of configuration options presented to an owner after initial configuration has been completed, e.g. because certain options cannot take effect without restarting the service.</p></li>
<li><p>A MUC service MAY provide an interface to room creation and configuration (e.g., in the form of a special XMPP entity or a Web page), so that the ostensible room owner is actually the application instead of a human user.</p></li>
<li><p>A MUC service MAY choose to make available a special in-room resource that provides an interface to administrative functionality (e.g., a "user" named "ChatBot"), which occupants could interact with directly, thus enabling admins to type <tt>'/command parameter'</tt> in a private message to that "user". Obviously this kind of implementation would require the service to add a 'ChatBot' user to the room when it is created, and to prevent any occupant from having the nickname 'ChatBot' in the room. This might be difficult to ensure in some implementations or deployments. In any case, any such interface is OPTIONAL.</p></li>
<li><p>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; the delivery-related errors are &gone;, &notfound;, &recipient;, &redirect;, &remoteserver;, and &timeout;.</p></li>
<li><p>A MUC service MAY choose to discard extended presence information that is attached to a &PRESENCE; stanza before reflecting the presence change to the occupants of a room. That is, an implementation MAY choose to reflect only the &lt;show/&gt;, &lt;status/&gt;, and &lt;priority/&gt; child elements of the presence element as specified in the XML schema for the 'jabber:client' namespace, with the result that presence "changes" in extended namespaces (e.g., gabber:x:music:info) are not passed through to occupants. If a service prohibits certain extended namespaces, it SHOULD provide a description of allowable traffic at the well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic' as described in the <link url='#impl-service-traffic'>Allowable Traffic</link> section of this document.</p></li>
<li><p>A MUC service MAY choose to discard extended information attached to &MESSAGE; stanzas before reflecting the message to the occupants of a room. An example of such extended information is the lightweight text markup specified by &xep0071;. If a service prohibits certain extended namespaces, it SHOULD provide a description of allowable traffic at the well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic' as described in the <link url='#impl-service-traffic'>Allowable Traffic</link> section of this document.</p></li>
<li><p>A MUC service MAY choose to "lock down" room nicknames (e.g., hardcoding the room nickname to the bare JID of the occupant). If so, the service MUST treat the locked down nickname as a reserved room nickname and MUST support the protocol specified in the <link url='#reservednick'>Discovering Reserved Room Nickname</link> section of this document.</p></li>
<li><p>A MUC service MAY choose to discard extended information attached to a &MESSAGE; stanza before reflecting the message to the occupants of a room. An example of such extended information is the lightweight text markup specified by &xep0071;. If a service prohibits certain extended namespaces, it SHOULD provide a description of allowable traffic at the well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic' as described in the <link url='#impl-service-traffic'>Allowable Traffic</link> section of this document.</p></li>
<li><p>A MUC service MAY choose to "lock down" room nicknames (e.g., hardcoding the room nickname to the bare JID of the occupant). If so, the service MUST treat the locked nickname as a reserved room nickname and MUST support the protocol specified in the <link url='#reservednick'>Discovering Reserved Room Nickname</link> section of this document.</p></li>
</ol>
<section3 topic='Allowable Traffic' anchor='impl-service-traffic'>
<p>As noted, a service (more precisely, a properly-configured room) MAY discard some or all extended namespaces attached to &MESSAGE; and &PRESENCE; stanzas that are intended for reflection from the sender through the room to all of the room occupants. If the room does so, it SHOULD enable senders to discover the list of allowable extensions by sending a disco#info query to the well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic', returning one &lt;feature/&gt; element for each namespace supported in the result. If the room does not allow any extended namespaces, it MUST return an empty query as specified in <cite>XEP-0030</cite>. If the room does not support the "#traffic" node, it MUST return a &feature; error in response to queries sent to the 'http://jabber.org/protocol/muc#traffic' node.</p>
<p>The following example shows a room that allows the 'http://jabber.org/protocol/xhtml-im' and 'http://jabber.org/protocol/rosterx' namespaces only, but no other extended namespaces.</p>
@ -5512,14 +5436,12 @@ xmpp:coven@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=cauld
</query>
</iq>
]]></example>
<p>If a service does not discard any namespaces or does not implement this feature, it MUST return a &unavailable; error:</p>
<p>If a service does not discard any namespaces, it MUST return a &unavailable; error:</p>
<example caption='Service Returns Service Unavailable'><![CDATA[
<iq from='heath@chat.shakespeare.lit'
to='wiccarocks@shakespeare.lit/laptop'
id='allow1'
type='error'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://jabber.org/protocol/muc#traffic'/>
<error type='cancel'>
<service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
@ -5527,6 +5449,10 @@ xmpp:coven@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=cauld
]]></example>
</section3>
<section3 topic='Ghost Users' anchor='impl-service-ghosts'>
<p>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;, &notfound;, &recipient;, &redirect;, &remoteserver;, and &timeout;). A MUC service MAY also use &xep0199; to periodically check the availability of room occupants.</p>
</section3>
</section2>
<section2 topic='Clients' anchor='impl-client'>
@ -5637,6 +5563,10 @@ xmpp:coven@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=cauld
<p>Note: Many XMPP clients also implement a '/me ' command as described in &xep0245;. This command does not result in any MUC or IRC protocol action and is therefore not shown in the foregoing table.</p>
</section3>
<section3 topic='Presence Subscriptions' anchor='impl-client-presence'>
<p>In XMPP, presence subscriptions are used to share network availability information between end users (see &rfc6121;). In XMPP groupchat, the presence employed is of a special type: directed presence rather than presence subscriptions. However, an IM user can also subscribe to the presence of a chatroom, which introduces the useful property that the user will be notified when a room comes back online after a crash or other outage, thus facilitating the feature of automatically re-joining the room. Although MUC clients and servers have not traditionally implemented presence subscriptions, developers are encouraged to consider adding such support.</p>
</section3>
</section2>
</section1>
@ -5754,8 +5684,8 @@ xmpp:coven@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=cauld
<xs:complexType>
<xs:sequence>
<xs:element ref='actor' minOccurs='0'/>
<xs:element ref='reason' minOccurs='0'/>
<xs:element ref='continue' minOccurs='0'/>
<xs:element ref='reason' minOccurs='0'/>
</xs:sequence>
<xs:attribute name='affiliation' use='optional'>
<xs:simpleType>
@ -5955,29 +5885,6 @@ xmpp:coven@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=cauld
</xs:restriction>
</xs:simpleType>
</xs:schema>
]]></code>
</section2>
<section2 topic='http://jabber.org/protocol/muc#unique' anchor='schemas-unique'>
<code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://jabber.org/protocol/muc#unique'
xmlns='http://jabber.org/protocol/muc#unique'
elementFormDefault='qualified'>
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
XEP-0045: http://www.xmpp.org/extensions/xep-0045.html
</xs:documentation>
</xs:annotation>
<xs:element name='unique' type='xs:string'/>
</xs:schema>
]]></code>
</section2>
@ -5985,7 +5892,7 @@ xmpp:coven@chat.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password=cauld
</section1>
<section1 topic='Acknowledgements' anchor='ack'>
<p>The author would like to especially recognize the following individuals for their many helpful comments on various drafts of this proposal: Gaston Dombiak, Joe Hildebrand, Craig Kaes, Jacek Konieczny, Peter Millard, Jean-Louis Seguineau, Alexey Shchepin, David Sutton, and David Waite. Thanks also to members of the XSF Technical Review Team for their edits and suggestions, in particular Peter Mount and Luca Tagliaferri. In addition, more people than the author can count have have provided feedback in the jdev@conference.jabber.org conference room and on the standards@xmpp.org and muc@xmpp.org mailing lists.</p>
<p>The author would like to especially recognize the following individuals for their many helpful comments on various drafts of this proposal: Gaston Dombiak, Joe Hildebrand, Craig Kaes, Jacek Konieczny, Peter Millard, Jean-Louis Seguineau, Alexey Shchepin, David Sutton, and David Waite. Thanks also to members of the XSF Technical Review Team for their edits and suggestions, in particular Peter Mount and Luca Tagliaferri. In addition, more people than the author can count have have provided feedback in the jdev@conference.jabber.org chat room and on the standards@xmpp.org and muc@xmpp.org mailing lists.</p>
</section1>
</xep>