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

Elsewhere, the specifications dictate that the banlist is based on bare JIDs. Matching resourceparts contradicts this (and is removed by this commit). Co-authored-by: Daniel Gultsch <[email protected]>
xsf · Aug 23, 2024 · 4677fc1 · 4677fc1
1 parent 49c4a15
commit 4677fc1
Showing 1 changed file with 9 additions and 6 deletions.
diff --git a/xep-0045.xml b/xep-0045.xml
@@ -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>
@@ -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>