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

1.25rc8

This commit is contained in:
stpeter 2011-11-08 12:23:01 -07:00
parent 52b77f5bc4
commit f4cc8b96a1
1 changed files with 56 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

72
xep-0045.xml
View File

@ -47,8 +47,8 @@
<registry/>
&stpeter;
<revision>
<version>1.25rc7</version>
<date>in progress, last updated 2011-09-30</date>
<version>1.25rc8</version>
<date>in progress, last updated 2011-11-08</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>Added "muc#maxhistoryfetch" form field.</li>
<li>Loosened handling of room joins when nicks are locked down, so that the service should modify the roomnick instead of returning an error.</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>
@ -986,7 +987,30 @@
<section1 topic='Entity Use Cases' anchor='entity'>
<p>A MUC implementation MUST support &xep0030; ("disco"). Any entity can complete the following disco-related use cases.</p>
<section2 topic='Discovering Component Support for MUC' anchor='disco-component'>
<section2 topic='Discovering a MUC Component' anchor='disco-component'>
<p>An entity often discovers a MUC component by sending a service discovery items ("disco#items") request to its own server.</p>
<example caption='Entity Queries Server for Associated Services'><![CDATA[
<iq from='hag66@shakespeare.lit/pda'
id='h7ns81g'
to='shakespeare.lit'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>
]]></example>
<p>The server then returns the services that are associated with it.</p>
<example caption='Server Returns Disco Items Result'><![CDATA[
<iq from='shakespeare.lit'
id='h7ns81g'
to='hag66@shakespeare.lit/pda'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<item jid='chat.shakespeare.lit'
name='Chatroom Service'/>
</query>
</iq>
]]></example>
</section2>
<section2 topic='Discovering the Features Supported by a MUC Component' anchor='disco-component-features'>
<p>An entity may wish to discover if a service implements the Multi-User Chat protocol; in order to do so, it sends a service discovery information ("disco#info") query to the component's JID.</p>
<example caption='Entity Queries Chat Service for MUC Support via Disco'><![CDATA[
<iq from='hag66@shakespeare.lit/pda'
@ -997,7 +1021,7 @@
</iq>
]]></example>
<p>The service MUST return its identity and the features it supports.</p>
<example caption='Service Returns Disco Info Results'><![CDATA[
<example caption='Service Returns Disco Info Result'><![CDATA[
<iq from='chat.shakespeare.lit'
id='lx09df27'
to='hag66@shakespeare.lit/pda'
@ -1024,7 +1048,7 @@
</iq>
]]></example>
<p>The service SHOULD return a full list of the public rooms it hosts (i.e., not return any rooms that are hidden).</p>
<example caption='Service Returns Disco Item Results'><![CDATA[
<example caption='Service Returns Disco Items Result'><![CDATA[
<iq from='chat.shakespeare.lit'
id='zb8q41f4'
to='hag66@shakespeare.lit/pda'
@ -1042,7 +1066,7 @@
</iq>
]]></example>
<p>If the full list of rooms is large (see <cite>XEP-0030</cite> for details), the service MAY return only a partial list of rooms. If it does so, it SHOULD include a &lt;set/&gt; element qualified by the 'http://jabber.org/protocol/rsm' namespace (as defined in &xep0059;) to indicate that the list is not the full result set.</p>
<example caption='Service Returns Limited List of Disco Item Results'><![CDATA[
<example caption='Service Returns Limited List of Disco Items Result'><![CDATA[
<iq from='chat.shakespeare.lit'
id='hx51v49s'
to='hag66@shakespeare.lit/pda'
@ -1079,7 +1103,7 @@
</iq>
]]></example>
<p>The room MUST return its identity and SHOULD return the features it supports:</p>
<example caption='Room Returns Disco Info Results'><![CDATA[
<example caption='Room Returns Disco Info Result'><![CDATA[
<iq from='coven@chat.shakespeare.lit'
id='ik3vs715'
to='hag66@shakespeare.lit/pda'
@ -1101,7 +1125,7 @@
]]></example>
<p>Note: The room SHOULD return the materially-relevant features it supports, such as password protection and room moderation (these are listed fully in the feature registry maintained by the XMPP Registrar; see also the <link url='#registrar'>XMPP Registrar</link> section of this document).</p>
<p>A chatroom MAY return more detailed information in its disco#info response using &xep0128;, identified by inclusion of a hidden FORM_TYPE field whose value is "http://jabber.org/protocol/muc#roominfo". Such information might include a more verbose description of the room, the current room subject, and the current number of occupants in the room:</p>
<example caption='Room Returns Extended Disco Info Results'><![CDATA[
<example caption='Room Returns Extended Disco Info Result'><![CDATA[
<iq from='coven@chat.shakespeare.lit'
id='ik3vs715'
to='hag66@shakespeare.lit/pda'
@ -1185,7 +1209,7 @@
</iq>
]]></example>
<p>An implementation MAY return a list of existing occupants if that information is publicly available, or return no list at all if this information is kept private. Implementations and deployments are advised to turn off such information sharing by default.</p>
<example caption='Room Returns Disco Item Results (Items are Public)'><![CDATA[
<example caption='Room Returns Disco Items Result (Items are Public)'><![CDATA[
<iq from='coven@chat.shakespeare.lit'
id='kl2fax27'
to='hag66@shakespeare.lit/pda'
@ -1198,7 +1222,7 @@
]]></example>
<p>Note: These &lt;item/&gt; elements are qualified by the disco#items namespace, not the muc namespace; this means that they cannot possess 'affiliation' or 'role' attributes, for example.</p>
<p>If the list of occupants is private, the room MUST return an empty &QUERY; element, in accordance with <cite>XEP-0030</cite>.</p>
<example caption='Room Returns Empty Disco Item Results (Items are Private)'><![CDATA[
<example caption='Room Returns Empty Disco Items Result (Items are Private)'><![CDATA[
<iq from='coven@chat.shakespeare.lit'
id='kl2fax27'
to='hag66@shakespeare.lit/pda'
@ -1223,7 +1247,7 @@
</iq>
]]></example>
<p>The client SHOULD return its identity and the features it supports.</p>
<example caption='Contact Returns Disco Info Results'><![CDATA[
<example caption='Contact Returns Disco Info Result'><![CDATA[
<iq from='wiccarocks@shakespeare.lit/laptop'
id='yh2fs843'
to='hag66@shakespeare.lit/pda'
@ -1248,7 +1272,7 @@
node='http://jabber.org/protocol/muc#rooms'/>
</iq>
]]></example>
<example caption='Contact Returns Room Query Results'><![CDATA[
<example caption='Contact Returns Room Query Result'><![CDATA[
<iq from='wiccarocks@shakespeare.lit/laptop'
id='gp7w61v3'
to='hag66@shakespeare.lit/pda'
@ -1297,7 +1321,7 @@
<example caption='User Seeks to Enter a Room (groupchat 1.0)'><![CDATA[
<presence
from='hag66@shakespeare.lit/pda'
id='ng91xs69''
id='ng91xs69'
to='coven@chat.shakespeare.lit/thirdwitch'/>
]]></example>
<p>In this example, a user with a full JID of "hag66@shakespeare.lit/pda" has requested to enter the room "coven" on the "chat.shakespeare.lit" chat service with a room nickname of "thirdwitch".</p>
@ -1383,7 +1407,22 @@
]]></example>
<p>In this example, initial room presence is being sent from the new occupant (thirdwitch) to all occupants, including the new occupant.</p>
<p>As shown in the last stanza, the "self-presence" sent by the room to the new user MUST include a status code of 110 so that the user knows this presence refers to itself as an occupant. This self-presence MUST NOT be sent to the new occupant until the room has sent the presence of all other occupants to the new occupant; this enables the new occupant to know when it has finished receiving the room roster.</p>
<p>The service MAY rewrite the new occupant's roomnick (e.g., if roomnicks are locked down). If the service does not accept the new occupant's requested roomnick but instead assigns a new roomnick, it MUST include a status code of "210" in the presence broadcast that it sends to the new occupant.</p>
<p>The service MAY rewrite the new occupant's roomnick (e.g., if roomnicks are locked down or based on some other policy).</p>
<p>In particular, if roomnicks are locked down then the service MUST do one of the following.</p>
<p>If the user has connected using a "groupchat 1.0" client (as indicated on joining the room by the lack of the MUC extension), then the service SHOULD deny the nickname change request and return a presence stanza of type "error" with a &notacceptable; error condition:</p>
<example caption='Service Denies Room Join Because Roomnicks Are Locked Down'><![CDATA[
<presence
from='coven@chat.shakespeare.lit/thirdwitch'
id='ng91xs69'
to='hag66@shakespeare.lit/pda'
type='error'>
<x xmlns='http://jabber.org/protocol/muc'/>
<error by='coven@chat.shakespeare.lit' type='cancel'>
<not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</presence>
]]></example>
<p>If the user has connected using a MUC client (as indicated on joining the room by inclusino of the MUC extension), then the service MUST include a status code of "210" in the presence broadcast that it sends to the new occupant.</p>
<example caption="Service Sends New Occupant's Presence to New Occupant"><![CDATA[
<presence
from='coven@chat.shakespeare.lit/thirdwitch'
@ -1981,7 +2020,7 @@
</presence>
]]></example>
<p>However, if the bare JID &LOCALBARE; of the present occupant matches the bare JID of the user seeking to change his or her nickname, then the service MAY allow the nickname change. See the <link url='#enter-conflict'>Nickname Conflict</link> section of this document for details.</p>
<p>If the user attempts to change his or her room nickname but room nicknames are "locked down", the service MUST deny the nickname change request and return a presence stanza of type "error" specifying a &notacceptable; error condition:</p>
<p>If the user attempts to change their room nickname but nicknames are "locked down", the service MUST either deny the nickname change request and return a presence stanza of type "error" with a &notacceptable; error condition:</p>
<example caption='Service Denies Nickname Change Because Roomnicks Are Locked Down'><![CDATA[
<presence
from='coven@chat.shakespeare.lit/thirdwitch'
@ -2459,7 +2498,7 @@
[ ... ]
]]></example>
<p>If the user's nickname is modified by the service as a result of registration and the user is in the room, the service SHOULD include status code "210" in the updated presence notification that it sends to all users.</p>
<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>
<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 modify the user's nickname to be the registered nickname (instead of returning a &notacceptable; error) 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>
<section2 topic='Getting the Member List' anchor='getmemberlist'>
@ -4807,6 +4846,7 @@
<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 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>
<p>Public MUC services also can be subject to attacks, such as creating a large number of rooms on a service, leaving rooms in an unconfigured state, etc. Such service-level attacks can be mitigated by limiting the number of rooms that any given non-adminstrative user can own, deleting rooms if they remain in the unconfigured state for too long, etc.</p>
</section2>
<section2 topic='Other Considerations' anchor='security-other'>