[Standards] Possible contradiction in defining MUC affiliations

anders conbere aconbere at gmail.com
Sat Apr 19 18:03:33 UTC 2008


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.

~ Anders



More information about the Standards mailing list