[Standards] Possible contradiction in defining MUC affiliations

Peter Saint-Andre stpeter at stpeter.im
Wed Apr 23 03:24:07 UTC 2008

anders conbere wrote:
> There appears to be a contradiction in how to specify ban lists, first
> in section 9.1 it tells us how to ban a user. Specifying that the ban
> MUST be preformed based on the users bare JID.
> <<<
> 9.1 Banning a User
> An admin or owner can ban one or more users from a room. The ban MUST
> be performed based on the occupant's bare JID. In order to ban a user,
> an admin MUST change the user's affiliation to "outcast".
> Then in section 9.2 we see that language used again, stating that "The
> ban list is always based on a user's bare JID".
> <<<
> 9.2 Modifying the Ban List
> A room admin may want to modify the ban list. Note: The ban list is
> always based on a user's bare JID, although a nick (perhaps the last
> room nickname associated with that JID) MAY be included for
> convenience. To modify the list of banned JIDs, the admin first
> requests the ban list by querying the room for all users with an
> affiliation of 'outcast'.
> But at the bottom of 9.2, we have this bit about matching JID's and
> banning users associated with a domain. In practice it seems that most
> clients and servers break the spec at 9.1 and 9.2 by allowing the
> client to specify a ban based on domain/resource and domain, instead
> adhering to the spirit of the below portion.
> <<<
> 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 RFC 3921):
>    1. <user at domain/resource> (only that resource matches)
>    2. <user at domain> (any resource matches)
>    3. <domain/resource> (only that resource matches)
>    4. <domain> (the domain itself matches, as does any user at domain,
> domain/resource, or address containing a subdomain)
> Some administrators may 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 (but see Service Administration [18]).
> I don't think this is a big deal, but it caused some confusion today
> when trying to figure out the proper way for a service to behave.

A ban is an affiliation change (to outcast). All affiliation matching
should be done based on the rules in Section 9.2 (which are the same
rules used in privacy lists and message archiving). So this is not
specific to bans.

For consistency, I think section 9.1 should be adjusted (at the least,
to change the MUST to SHOULD).


Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080422/294a9fcb/attachment.bin>

More information about the Standards mailing list