diff --git a/xep-0045.xml b/xep-0045.xml index 697f81b3b..d289f40ae 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -50,7 +50,12 @@ 1.34.7 2024-07-09 gk -

Explicitly disallow Ban List modifications that clash with 'Banning a User' conditions.

 + + + 1.34.6 @@ -3332,12 +3337,10 @@ type='result'/> ]]>

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.)

-

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;):

+

When an entity is banned from a room, an implementation SHOULD match JIDs in the following order:

    -
  1. <user@domain/resource> (only that resource matches)
    2. -
  2. <user@domain> (any resource matches)
    3. -
  3. <domain/resource> (only that resource matches)
    4. -
  4. <domain> (the domain itself matches, as does any user@domain or domain/resource)
    5. +
  5. <user@domain>
    6. +
  6. <domain> (the domain itself matches, as does any user@domain)

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 XEP-0133.

As specified in Banning a User, 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 Banning a User, 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 ¬allowed;.