Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XEP-0045 Remove references to using resourceparts when banning users. #1360

Merged
merged 2 commits into from
Aug 23, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 9 additions & 6 deletions xep-0045.xml
Original file line number Diff line number Diff line change
Expand Up @@ -50,7 +50,12 @@
<version>1.34.7</version>
<date>2024-07-09</date>
<initials>gk</initials>
<remark><p>Explicitly disallow Ban List modifications that clash with 'Banning a User' conditions.</p></remark>
<remark>
<ul>
<li>Remove references to using resourceparts when banning users.</li>
<li>Explicitly disallow Ban List modifications that clash with 'Banning a User' conditions.</li>
</ul>
</remark>
</revision>
<revision>
<version>1.34.6</version>
Expand Down Expand Up @@ -3332,12 +3337,10 @@
type='result'/>
]]></example>
<p>The service MUST then remove the affected occupants (if they are in the room) and send updated presence (including the appropriate status code) from them to all the remaining occupants as described in the "Banning a User" use case. (The service MUST also remove each banned user's reserved nickname from the list of reserved roomnicks, if appropriate.)</p>
<p>When an entity is banned from a room, an implementation SHOULD match JIDs in the following order (these matching rules are the same as those defined for privacy lists in &xep0016;):</p>
<p>When an entity is banned from a room, an implementation SHOULD match JIDs in the following order:</p>
<ol start='1'>
<li>&lt;user@domain/resource&gt; (only that resource matches)</li>
<li>&lt;user@domain&gt; (any resource matches)</li>
<li>&lt;domain/resource&gt; (only that resource matches)</li>
<li>&lt;domain&gt; (the domain itself matches, as does any user@domain or domain/resource)</li>
<li>&lt;user@domain&gt;</li>
<li>&lt;domain&gt; (the domain itself matches, as does any user@domain)</li>
</ol>
<p>Some administrators might wish to ban all users associated with a specific domain from all rooms hosted by a MUC service. Such functionality is a service-level feature and is therefore out of scope for this document; see <cite>XEP-0133</cite>.</p>
<p>As specified in <link url='#ban'>Banning a User</link>, users cannot be banned under certain conditions. For example: admins and owners cannot ban themselves, and a user cannot be banned by an admin with a lower affiliation. When a request to modify the ban list includes one or more modifications that is prohibited by the definitions in <link url='#ban'>Banning a User</link>, then the service SHOULD NOT apply any of the requested changes and MUST deny the request using an error which SHOULD be either &conflict; or &notallowed;.</p>
Expand Down