moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-24 18:22:24 -05:00
Code Issues Releases Wiki Activity

1.23pre3

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1302 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-10-18 23:25:00 +00:00
parent ea7d5986de
commit 0745255690
1 changed files with 144 additions and 81 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

225
xep-0045.xml
View File

@ -50,10 +50,10 @@
<registry/>
&stpeter;
<revision>
<version>1.23pre2</version>
<date>in progress, updated 2007-09-10</date>
<version>1.23pre3</version>
<date>in progress, updated 2007-10-18</date>
<initials>psa</initials>
<remark><p>Added outsider role, including outsider use cases and admin management of outsider role; defined "getmemberlist" room configuration option; added direct invitation protoocol; corrected logic regarding admission of room owner/admin when room is full.</p></remark>
<remark><p>Added outsider role, including outsider use cases and admin management of outsider role; defined getmemberlist room configuration option; added direct invitation protoocol; corrected logic regarding admission of room owner/admin when room is full; defined service discovery extension field for associated LDAP group; specified that room config fields can be listed in extended room information; specified message format for affiliation change notifications if user is not in the room.</p></remark>
</revision>
<revision>
<version>1.22</version>
@ -1009,9 +1009,15 @@
<field var='muc#roominfo_subject' label='Subject'>
<value>Spells</value>
</field>
<field var='muc#roomconfig_changesubject' label='Subject can be modified'>
<value>true</value>
</field>
<field var='muc#roominfo_occupants' label='Number of occupants'>
<value>3</value>
</field>
<field var='muc#roominfo_ldapgroup' label='Associated LDAP Group'>
<value>Witches</value>
</field>
<field var='muc#roominfo_lang' label='Language of discussion'>
<value>en</value>
</field>
@ -1025,7 +1031,7 @@
</query>
</iq>
]]></example>
<p>Some extended room information may be dynamically generated (e.g., the URL for discussion logs, which may be based on service-wide configuration) whereas other information may be based on the room configuration.</p>
<p>Some extended room information may be dynamically generated (e.g., the URL for discussion logs, which may be based on service-wide configuration). Other information may be based on the room configuration, which is why any field defined for the <link url='#registrar-formtype-owner'>muc#roomconfig FORM_TYPE</link> can be included in the extended service discovery fields (as shown above for the muc#roomconfig_changesubject field).</p>
<p>Note: The foregoing extended service discovery fields for the 'http://jabber.org/protocol/muc#roominfo' FORM_TYPE may be supplemented in the future via the mechanisms described in the <link url="#registrar-formtype">Field Standardization</link> section of this document.</p>
</section2>
<section2 topic='Querying for Room Items' anchor='disco-roomitems'>
@ -1424,9 +1430,8 @@
role='participant'/>
</x>
</presence>
.
.
.
[ ... ]
]]></example>
<p>If the user is entering a room that is non-anonymous (i.e., which informs all occupants of each occupant's full JID as shown above), the service SHOULD allow the user to enter the room but MUST also warn the user that the room is not anonymous. This SHOULD be done by including a status code of "100" in the initial presence that the room sends to the new occupant:</p>
<example caption="Service Sends New Occupant's Presence to New Occupant"><![CDATA[
@ -1456,7 +1461,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).</p>
</section3>
<section3 topic='Semi-Anonymous Rooms' anchor='enter-semianon'>
<p>If the room is semi-anonymous, the service MUST send the new occupant's full JID in the format shown above only to those occupants with a role of "moderator".</p>
<p>If the room is semi-anonymous, the service MUST send presence from the new occupant to all occupants as specified above, but MUST include the new occupant's full JID only in the presence notifications it sends to occupants with a role of "moderator" and not to non-moderator occupants.</p>
<p>(Note: All subsequent examples include the 'jid' attribute for each &lt;item/&gt; element, even though this information is not sent to non-moderators in semi-anonymous rooms.)</p>
</section3>
<section3 topic='Password-Protected Rooms' anchor='enter-pw'>
@ -1521,6 +1526,7 @@
</presence>
]]></example>
<p>However, if the bare JID (&BAREJID;) of the present occupant matches the bare JID of the user seeking to enter the room, then the service SHOULD allow entry to the user, so that the user has two (or more) in-room "sessions" with the same roomnick, one for each resource. If a service allows more than one occupant with the same bare JID and the same room nickname, it SHOULD route in-room messages to all of the user's resources and allow all of the user's resources to send messages to the room; it is up to the implementation to determine how to appropriately handle presence from the user's resources and how to route private messages to all or only one resource (based on presence priority or some other algorithm).</p>
<p>How nickname conflicts are determined is up to the implementation (e.g., whether the service applies a case folding routine, a stringprep profile such as Resourceprep or Nodeprep, etc.).</p>
</section3>
<section3 topic='Max Users' anchor='enter-maxusers'>
<p>If the room has reached its maximum number of occupants, the service SHOULD deny access to the room and inform the user of the restriction; this is done by returning a presence stanza of type "error" specifying a &unavailable; error condition:</p>
@ -1854,9 +1860,8 @@
role='moderator'/>
</x>
</presence>
.
.
.
[ ... ]
]]></example>
</section2>
<section2 topic='Inviting Another User to a Room' anchor='invite'>
@ -2299,9 +2304,8 @@
role='participant'/>
</x>
</presence>
.
.
.
[ ... ]
]]></example>
<p>If a user has registered with a room, the room MAY choose to restrict the user to use of the registered nickname only in that room. If it does so, it SHOULD return a &notacceptable; error to the user if the user attempts to join the room with a roomnick other than the user's registered roomnick (this enables a room to "lock down" roomnicks for consistent identification of occupants).</p>
</section2>
@ -2386,9 +2390,8 @@
type='groupchat'>
<subject>Fire Burn and Cauldron Bubble!</subject>
</message>
.
.
.
[ ... ]
]]></example>
<p>In addition, the room SHOULD include the last subject change in the discussion history sent when a new occupant joins the room.</p>
<p>A MUC client that receives such a message MAY choose to display an in-room message, such as the following:</p>
@ -2456,9 +2459,8 @@
<status code='307'/>
</x>
</presence>
.
.
.
[ ... ]
]]></example>
<p>A user cannot be kicked by a moderator with a lower affiliation. Therefore, if a moderator who is a participant attempts to kick an admin or a moderator who is a participant or admin attempts to kick an owner, the service MUST deny the request and return a &notallowed; error to the sender:</p>
<example caption='Service Returns Error on Attempt to Kick User With Higher Affiliation'><![CDATA[
@ -2513,9 +2515,8 @@
</item>
</x>
</presence>
.
.
.
[ ... ]
]]></example>
</section2>
<section2 topic='Revoking Voice from a Participant' anchor='revokevoice'>
@ -2549,9 +2550,8 @@
role='visitor'/>
</x>
</presence>
.
.
.
[ ... ]
]]></example>
<p>A moderator MUST NOT be able to revoke voice from a user whose affiliation is at or above the moderator's level. In addition, a service MUST NOT allow the voice privileges of an admin or owner to be removed by anyone. If a moderator attempts to revoke voice privileges from such a user, the service MUST deny the request and return a &notallowed; error to the sender along with the offending item(s):</p>
<example caption='Service Returns Error on Attempt to Revoke Voice from an Admin, Owner, or User with a Higher Affiliation'><![CDATA[
@ -2776,9 +2776,8 @@
<status code='301'/>
</x>
</presence>
.
.
.
[ ... ]
]]></example>
<p>As with <link url='#kick'>Kicking an Occupant</link>, a user cannot be banned by an admin with a lower affiliation. Therefore, if an admin attempts to ban an owner, the service MUST deny the request and return a &notallowed; error to the sender:</p>
<example caption='Service Returns Error on Attempt to Ban User With Higher Affiliation'><![CDATA[
@ -2895,9 +2894,22 @@
role='participant'/>
</x>
</presence>
.
.
.
[ ... ]
]]></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 membership 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".</p>
<example caption="Service Sends Notice of Membership to All Occupants"><![CDATA[
<message
from='macbeth.shakespeare.lit'
to='crone1@shakespeare.lit/desktop'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='member'
jid='hag66@shakespeare.lit'
role='none'/>
</x>
</message>
[ ... ]
]]></example>
</section2>
<section2 topic='Revoking Membership' anchor='revokemember'>
@ -2931,9 +2943,8 @@
role='participant'/>
</x>
</presence>
.
.
.
[ ... ]
]]></example>
<p>If the room is members-only, the service MUST remove the user from the room, including a status code of 321 to indicate that the user was removed because of an affiliation change, and inform all remaining occupants:</p>
<example caption='Service Removes Non-Member'><![CDATA[
@ -2958,9 +2969,8 @@
<status code='321'/>
</x>
</presence>
.
.
.
[ ... ]
]]></example>
</section2>
<section2 topic='Modifying the Member List' anchor='modifymember'>
@ -3026,9 +3036,8 @@
role='participant'/>
</x>
</presence>
.
.
.
[ ... ]
]]></example>
<p>In addition, the service SHOULD send an invitation to any user who has been added to the member list of a members-only room if the user is not currently affiliated with the room, for example as an admin or owner (such a user would by definition not be in the room; note also that this example includes a password but not a reason -- both child elements are OPTIONAL):</p>
<example caption='Room Sends Invitation to New Member'><![CDATA[
@ -3071,9 +3080,8 @@
role='participant'/>
</x>
</presence>
.
.
.
[ ... ]
]]></example>
</section2>
<section2 topic='Granting Moderator Privileges' anchor='grantmod'>
@ -3107,9 +3115,8 @@
role='moderator'/>
</x>
</presence>
.
.
.
[ ... ]
]]></example>
</section2>
<section2 topic='Revoking Moderator Privileges' anchor='revokemod'>
@ -3143,9 +3150,8 @@
role='participant'/>
</x>
</presence>
.
.
.
[ ... ]
]]></example>
<p>As noted, an admin MUST NOT be allowed to revoke moderator privileges from a user whose affiliation is "owner" or "admin". If an admin attempts to revoke moderator privileges from such a user, the service MUST deny the request and return a &notallowed; error to the sender:</p>
<example caption='Service Returns Error on Attempt to Revoke Moderator Privileges from an Admin or Owner'><![CDATA[
@ -3732,7 +3738,7 @@
<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:</p>
<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='macbeth.shakespeare.lit'
id='unique1'
@ -3968,9 +3974,8 @@
role='participant'/>
</x>
</presence>
.
.
.
[ ... ]
]]></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>
<example caption="Service Notes Gain of Admin Affiliation to All Users"><![CDATA[
@ -3983,9 +3988,8 @@
role='moderator'/>
</x>
</presence>
.
.
.
[ ... ]
]]></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>
<example caption="Service Notes Loss of Owner Affiliation"><![CDATA[
@ -3998,9 +4002,8 @@
role='moderator'/>
</x>
</presence>
.
.
.
[ ... ]
]]></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>
@ -4014,9 +4017,8 @@
role='moderator'/>
</x>
</presence>
.
.
.
[ ... ]
]]></example>
<p>If as a result of a change in the room configuration the room type is changed to members-only but there are non-members in the room, the service MUST remove any non-members from the room and include a status code of 322 in the presence unavailable stanzas sent to those users as well as any remaining occupants.</p>
<section3 topic='Notification of Configuration Changes' anchor='roomconfig-notify'>
@ -4068,13 +4070,26 @@
to='crone1@shakespeare.lit/desktop'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='owner'
jid='hecate@shakespeare.lit/broom'
jid='hecate@shakespeare.lit'
role='moderator'/>
</x>
</presence>
.
.
.
[ ... ]
]]></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[
<message
from='macbeth.shakespeare.lit'
to='crone1@shakespeare.lit/desktop'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='member'
jid='hecate@shakespeare.lit'
role='none'/>
</x>
</message>
[ ... ]
]]></example>
</section2>
<section2 topic='Revoking Ownership Privileges' anchor='revokeowner'>
@ -4092,6 +4107,7 @@
]]></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>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='darkcave@macbeth.shakespeare.lit'
@ -4106,15 +4122,27 @@
to='crone1@shakespeare.lit/desktop'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='admin'
jid='hecate@shakespeare.lit/broom'
jid='hecate@shakespeare.lit'
role='moderator'/>
</x>
</presence>
.
.
.
[ ... ]
]]></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>
<example caption="Service Notes Loss of Owner Affiliation"><![CDATA[
<message
from='macbeth.shakespeare.lit'
to='crone1@shakespeare.lit/desktop'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='admin'
jid='hecate@shakespeare.lit'
role='none'/>
</x>
</message>
[ ... ]
]]></example>
<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>
</section2>
<section2 topic='Modifying the Owner List' anchor='modifyowner'>
<p>If allowed by an implementation, a room owner may want to modify the owner list. To do so, the owner first requests the owner list by querying the room for all users with an affiliation of 'owner'.</p>
@ -4205,13 +4233,26 @@
to='crone1@shakespeare.lit/desktop'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='admin'
jid='wiccarocks@shakespeare.lit/laptop'
jid='wiccarocks@shakespeare.lit'
role='moderator'/>
</x>
</presence>
.
.
.
[ ... ]
]]></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[
<message
from='macbeth.shakespeare.lit'
to='crone1@shakespeare.lit/desktop'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='admin'
jid='wiccarocks@shakespeare.lit'
role='none'/>
</x>
</message>
[ ... ]
]]></example>
</section2>
<section2 topic='Revoking Administrative Privileges' anchor='revokeadmin'>
@ -4234,20 +4275,33 @@
to='crone1@shakespeare.lit/desktop'
type='result'/>
]]></example>
<p>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 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>
<example caption="Service Notes Loss of Admin Affiliation"><![CDATA[
<presence
from='darkcave@macbeth.shakespeare.lit/secondwitch'
to='crone1@shakespeare.lit/desktop'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='member'
jid='wiccarocks@shakespeare.lit/laptop'
jid='wiccarocks@shakespeare.lit'
role='participant'/>
</x>
</presence>
.
.
.
[ ... ]
]]></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>
<example caption="Service Notes Loss of Admin Affiliation"><![CDATA[
<message
from='macbeth.shakespeare.lit'
to='crone1@shakespeare.lit/desktop'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='member'
jid='wiccarocks@shakespeare.lit'
role='none'/>
</x>
</message>
[ ... ]
]]></example>
</section2>
<section2 topic='Modifying the Admin List' anchor='modifyadmin'>
@ -4781,6 +4835,10 @@
var='muc#roominfo_lang'
type='text-single'
label='Natural Language for Room Discussions'/>
<field
var='muc#roominfo_ldapgroup'
type='text-single'
label='An associated LDAP group that defines room membership'/>
<field
var='muc#roominfo_logs'
type='text-single'
@ -4793,6 +4851,10 @@
var='muc#roominfo_subject'
type='text-single'
label='Current Subject or Discussion Topic in Room'/>
<field
var='muc#roominfo_subjectmod'
type='boolean'
label='The room subject can be modified by participants'/>
</form_type>
]]></code>
</section3>
@ -5050,6 +5112,7 @@ xmpp:darkcave@macbeth.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password
<section1 topic='Business Rules' anchor='bizrules'>
<section2 topic='Addresses' anchor='bizrules-jids'>
<p>In order to provide consistency regarding the addresses captured in room JIDs, Room IDs MUST match the Nodeprep profile of Stringprep and Room Nicknames MUST match the Resourceprep profile of Stringprep (both of these are defined in <cite>RFC 3920</cite>). Although not explicitly stated in <cite>RFC 3920</cite>, both the Room ID (node) and Room Nickname (resource) portions of a Room JID MUST be of non-zero length. In addition, a MUC service MUST NOT allow empty or invisible Room Nicknames (i.e., Room Nicknames that consist only of one or more space characters).</p>
<p>It is up to the service implementation whether it will further restrict roomnicks (e.g., by applying case folding routines, the Nodeprep profile of stringprep, or other restrictions).</p>
</section2>
<section2 topic='Message' anchor='bizrules-message'>
<ol start='1'>