From 33ee4a99b214e41f63cab764a1d5f47f0992a3ef Mon Sep 17 00:00:00 2001 From: Guus der Kinderen Date: Tue, 9 Jul 2024 18:28:26 +0200 Subject: [PATCH] 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). --- xep-0045.xml | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/xep-0045.xml b/xep-0045.xml index 07f91955e..cec0c06fd 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -46,6 +46,12 @@ &stpeter; + + 1.34.7 + 2024-07-09 + gk +

Remove references to using resourceparts when banning users.

 + 1.34.6 2024-05-01 @@ -3326,12 +3332,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.