moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

1.25rc6

This commit is contained in:
stpeter 2011-09-19 14:31:49 -06:00
parent 78d729222a
commit de29f8aad7
1 changed files with 22 additions and 31 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

53
xep-0045.xml
View File

@ -47,8 +47,8 @@
<registry/>
&stpeter;
<revision>
<version>1.25rc5</version>
<date>in progress, last updated 2011-08-16</date>
<version>1.25rc6</version>
<date>in progress, last updated 2011-09-19</date>
<initials>psa</initials>
<remark>
<ul>
@ -62,6 +62,7 @@
<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>Removed any mention of fully-anonymous rooms, which are not supported by this specification.</li>
<li>Clarified many small points in the text and examples.</li>
</ul>
</remark>
@ -531,16 +532,15 @@
<section2 topic='Room Types' anchor='terms-rooms'>
<dl>
<di><dt>Fully-Anonymous Room</dt><dd>A room in which the full JIDs or bare JIDs of occupants cannot be discovered by anyone, including room admins and room owners; such rooms are NOT RECOMMENDED or explicitly supported by MUC, but are possible using this protocol if a service implementation offers the appropriate configuration options; contrast with Non-Anonymous Room and Semi-Anonymous Room.</dd></di>
<di><dt>Hidden Room</dt><dd>A room that cannot be found by any user through normal means such as searching and service discovery; antonym: Public Room.</dd></di>
<di><dt>Members-Only Room</dt><dd>A room that a user cannot enter without being on the member list; antonym: Open Room.</dd></di>
<di><dt>Moderated Room</dt><dd>A room in which only those with "voice" are allowed to send messages to all occupants; antonym: Unmoderated Room.</dd></di>
<di><dt>Non-Anonymous Room</dt><dd>A room in which an occupant's full JID is exposed to all other occupants, although the occupant can choose any desired room nickname; contrast with Semi-Anonymous Room and Fully-Anonymous Room.</dd></di>
<di><dt>Non-Anonymous Room</dt><dd>A room in which an occupant's full JID is exposed to all other occupants, although the occupant can choose any desired room nickname; contrast with Semi-Anonymous Room.</dd></di>
<di><dt>Open Room</dt><dd>A room that anyone is allowed to enter without being on the member list; antonym: Members-Only Room.</dd></di>
<di><dt>Password-Protected Room</dt><dd>A room that a user cannot enter without first providing the correct password; antonym: Unsecured Room.</dd></di>
<di><dt>Persistent Room</dt><dd>A room that is not destroyed if the last occupant exits; antonym: Temporary Room.</dd></di>
<di><dt>Public Room</dt><dd>A room that can be found by any user through normal means such as searching and service discovery; antonym: Hidden Room.</dd></di>
<di><dt>Semi-Anonymous Room</dt><dd>A room in which an occupant's full JID can be discovered by room admins only; contrast with Fully-Anonymous Room and Non-Anonymous Room.</dd></di>
<di><dt>Semi-Anonymous Room</dt><dd>A room in which an occupant's full JID can be discovered by room admins only; contrast with Non-Anonymous Room.</dd></di>
<di><dt>Temporary Room</dt><dd>A room that is destroyed if the last occupant exits; antonym: Persistent Room.</dd></di>
<di><dt>Unmoderated Room</dt><dd>A room in which any occupant is allowed to send messages to all occupants; antonym: Moderated Room.</dd></di>
<di><dt>Unsecured Room</dt><dd>A room that anyone is allowed to enter without first providing the correct password; antonym: Password-Protected Room.</dd></di>
@ -2489,7 +2489,7 @@
</x>
</message>
]]></example>
<p>The service then SHOULD forward the request to the room moderator(s) as described in the <link url='#voiceapprove'>Approving Voice Requests</link> section of this document.</p>
<p>The service then proceeds as described in the <link url='#voiceapprove'>Approving Voice Requests</link> section of this document.</p>
</section2>
<section2 topic='Exiting a Room' anchor='exit'>
@ -2634,7 +2634,7 @@
<example caption='Moderator Kicks Occupant'><![CDATA[
<iq from='fluellen@shakespeare.lit/pda'
id='kick1'
to='harfleur@henryv.shakespeare.lit'
to='harfleur@chat.shakespeare.lit'
type='set'>
<query xmlns='http://jabber.org/protocol/muc#admin'>
<item nick='pistol' role='none'>
@ -2646,7 +2646,7 @@
<p>The service MUST remove the kicked occupant by sending a presence stanza of type "unavailable" to each kicked occupant, including status code 307 in the extended presence information, optionally along with the reason (if provided) and the bare JID of the user who initiated the kick.</p>
<example caption='Service Removes Kicked Occupant'><![CDATA[
<presence
from='harfleur@henryv.shakespeare.lit/pistol'
from='harfleur@chat.shakespeare.lit/pistol'
to='pistol@shakespeare.lit/harfleur'
type='unavailable'>
<x xmlns='http://jabber.org/protocol/muc#user'>
@ -2661,7 +2661,7 @@
<p>The inclusion of the status code assists clients in presenting their own notification messages (e.g., information appropriate to the user's locality). The optional inclusion of the reason and actor enable the kicked user to understand why he or she was kicked, and by whom if the kicked occupant would like to discuss the matter. <note>Some commentors have complained that this opens room owners and administrators up to potential abuse; unfortunately, with great power comes great responsibility.</note></p>
<p>After removing the kicked occupant(s), the service MUST then inform the moderator of success:</p>
<example caption='Service Informs Moderator of Success'><![CDATA[
<iq from='harfleur@henryv.shakespeare.lit'
<iq from='harfleur@chat.shakespeare.lit'
id='kick1'
to='fluellen@shakespeare.lit/pda'
type='result'/>
@ -2669,7 +2669,7 @@
<p>After informing the moderator, the service MUST then inform all of the remaining occupants that the kicked occupant is no longer in the room by sending presence stanzas of type "unavailable" from the individual's roomnick (&ROOMJID;) to all the remaining occupants (just as it does when occupants exit the room of their own volition), including the status code and optionally the reason and actor.</p>
<example caption='Service Informs Remaining Occupants'><![CDATA[
<presence
from='harfleur@henryv.shakespeare.lit/pistol'
from='harfleur@chat.shakespeare.lit/pistol'
to='gower@shakespeare.lit/cell'
type='unavailable'>
<x xmlns='http://jabber.org/protocol/muc#user'>
@ -2883,7 +2883,7 @@
</section2>
<section2 topic='Approving Voice Requests' anchor='voiceapprove'>
<p>As noted in the <link url='#requestvoice'>Requesting Voice</link> section of this document, when a service receives a request for voice from an occupant it SHOULD forward that request to the room moderator(s). To do so, the service sends a &MESSAGE; stanza to the room moderator(s), where the &MESSAGE; stanza contains a data form asking for approval or denial of the request, as shown below.</p>
<p>As noted in the <link url='#requestvoice'>Requesting Voice</link> section of this document, an occupant requests voice by sending a voice request data form to the service. The service then SHOULD use that voice request data form as the basis for a voice approval data form that it generates and sends to the room moderator(s). The voice approval data form is contained in a &MESSAGE; stanza, as shown below.</p>
<example caption='Voice Request Approval Form'><![CDATA[
<message from='coven@chat.shakespeare.lit'
id='approve'
@ -2967,7 +2967,7 @@
<example caption='Admin Bans User'><![CDATA[
<iq from='kinghenryv@shakespeare.lit/throne'
id='ban1'
to='southampton@henryv.shakespeare.lit'
to='southampton@chat.shakespeare.lit'
type='set'>
<query xmlns='http://jabber.org/protocol/muc#admin'>
<item affiliation='outcast'
@ -2979,7 +2979,7 @@
<example caption='Admin Bans User (With a Reason)'><![CDATA[
<iq from='kinghenryv@shakespeare.lit/throne'
id='ban1'
to='southampton@henryv.shakespeare.lit'
to='southampton@chat.shakespeare.lit'
type='set'>
<query xmlns='http://jabber.org/protocol/muc#admin'>
<item affiliation='outcast'
@ -2991,7 +2991,7 @@
]]></example>
<p>The service MUST add that bare JID to the ban list, MUST remove the outcast's nickname from the list of registered nicknames, and MUST inform the admin or owner of success:</p>
<example caption='Service Informs Admin or Owner of Success'><![CDATA[
<iq from='southampton@henryv.shakespeare.lit'
<iq from='southampton@chat.shakespeare.lit'
id='ban1'
to='kinghenryv@shakespeare.lit/throne'
type='result'/>
@ -2999,7 +2999,7 @@
<p>The service MUST also remove any banned users who are in the room by sending a presence stanza of type "unavailable" to each banned occupant, including status code 301 in the extended presence information, optionally along with the reason (if provided) and the bare JID of the user who initiated the ban.</p>
<example caption='Service Removes Banned User'><![CDATA[
<presence
from='southampton@henryv.shakespeare.lit/cambridge'
from='southampton@chat.shakespeare.lit/cambridge'
to='earlofcambridge@shakespeare.lit/stabber'
type='unavailable'>
<x xmlns='http://jabber.org/protocol/muc#user'>
@ -3016,7 +3016,7 @@
<example caption='Service Informs Remaining Occupants'><![CDATA[
<presence
type='unavailable'
from='southampton@henryv.shakespeare.lit/cambridge'
from='southampton@chat.shakespeare.lit/cambridge'
to='exeter@shakespeare.lit/pda'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='outcast'
@ -3032,7 +3032,7 @@
<example caption='Service Returns Error on Attempt to Ban User With Higher Affiliation'><![CDATA[
<iq from='kinghenryv@shakespeare.lit/throne'
id='ban1'
to='southampton@henryv.shakespeare.lit'
to='southampton@chat.shakespeare.lit'
type='set'>
<error type='cancel'>
<not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
@ -3047,7 +3047,7 @@
<example caption='Admin Requests Ban List'><![CDATA[
<iq from='kinghenryv@shakespeare.lit/throne'
id='ban2'
to='southampton@henryv.shakespeare.lit'
to='southampton@chat.shakespeare.lit'
type='get'>
<query xmlns='http://jabber.org/protocol/muc#admin'>
<item affiliation='outcast'/>
@ -3056,7 +3056,7 @@
]]></example>
<p>The service MUST then return the list of banned users to the admin; each item MUST include the 'affiliation' and 'jid' attributes but SHOULD NOT include the 'nick' and 'role' attributes:</p>
<example caption='Service Sends Ban List to Admin'><![CDATA[
<iq from='southampton@henryv.shakespeare.lit'
<iq from='southampton@chat.shakespeare.lit'
id='ban2'
to='kinghenryv@shakespeare.lit/throne'
type='result'>
@ -3072,7 +3072,7 @@
<example caption='Admin Sends Modified Ban List to Service'><![CDATA[
<iq from='kinghenryv@shakespeare.lit/throne'
id='ban3'
to='southampton@henryv.shakespeare.lit'
to='southampton@chat.shakespeare.lit'
type='set'>
<query xmlns='http://jabber.org/protocol/muc#admin'>
<item affiliation='outcast'>
@ -3088,7 +3088,7 @@
]]></example>
<p>After updating the ban list, the service MUST inform the admin of success:</p>
<example caption='Service Informs Admin of Success'><![CDATA[
<iq from='southampton@henryv.shakespeare.lit'
<iq from='southampton@chat.shakespeare.lit'
id='ban3'
to='kinghenryv@shakespeare.lit/throne'
type='result'/>
@ -3235,7 +3235,7 @@
<section2 topic='Modifying the Member List' anchor='modifymember'>
<p>In the context of a members-only room, the member list is essentially a "whitelist" of people who are allowed to enter the room. Anyone who is not a member is effectively banned from entering the room, even if their affiliation is not "outcast".</p>
<p>In the context of an open room, the member list is simply a list of users (bare JID and reserved nick) who are registered with the room. Such users cacan appear in a room roster, have their room nickname reserved, be returned in search results or FAQ queries, and the like.</p>
<p>In the context of an open room, the member list is simply a list of users (bare JID and reserved nick) who are registered with the room. Such users can appear in a room roster, have their room nickname reserved, be returned in search results or FAQ queries, and the like.</p>
<p>It is RECOMMENDED that only room admins have the privilege to modify the member list in members-only rooms. To do so, the admin first requests the member list by querying the room for all users with an affiliation of "member":</p>
<example caption='Admin Requests Member List'><![CDATA[
<iq from='crone1@shakespeare.lit/desktop'
@ -4251,7 +4251,6 @@
<li>If room logging is now disabled, status code 171.</li>
<li>If the room is now non-anonymous, status code 172.</li>
<li>If the room is now semi-anonymous, status code 173.</li>
<li>If the room is now fully-anonymous, status code 174.</li>
</ul>
<p>For any other configuration change, the room SHOULD send status code 104 so that interested occupants can retrieve the updated room configuration if desired.</p>
</section3>
@ -5207,14 +5206,6 @@
Inform occupants that the room is now semi-anonymous
</purpose>
</statuscode>
<statuscode>
<number>174</number>
<stanza>message</stanza>
<context>Configuration change</context>
<purpose>
Inform occupants that the room is now fully-anonymous (unused)
</purpose>
</statuscode>
<statuscode>
<number>201</number>
<stanza>presence</stanza>