Sorry for the delayed reply, I got behind on email. Comments at end. On 04/23/2008 7:47 AM, anders conbere wrote: > On Tue, Apr 22, 2008 at 8:24 PM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: >> 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. <[EMAIL PROTECTED]/resource> (only that resource matches) >> > 2. <[EMAIL PROTECTED]> (any resource matches) >> > 3. <domain/resource> (only that resource matches) >> > 4. <domain> (the domain itself matches, as does any [EMAIL PROTECTED], >> > 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). > > I believe this would fix the contradiction yet leave the confusion. > What I take away from 9.1 is that bans should be done on bare JIDs aka > with stanzas like > > <<< > <iq from='[EMAIL PROTECTED]/throne' > id='ban1' > to='[EMAIL PROTECTED]' > type='set'> > <query xmlns='http://jabber.org/protocol/muc#admin'> > <item affiliation='outcast' > jid='[EMAIL PROTECTED]'> > <reason>Treason</reason> > </item> > </query> > </iq> > > Where 9.2 implies that bans can also look of the form > > <<< > <iq from='[EMAIL PROTECTED]/throne' > id="2160" > to="[EMAIL PROTECTED]" > type="set"> > > <query xmlns="http://jabber.org/protocol/muc#admin";> > <item affiliation="outcast" > jid="cambridge.lit"> > <reason>Treason</reason> > </item> > </query> > </iq> > > Where instead of a jid, one can specify a domain, a domain + resource, > a bare jid, or a bare jid + resource. (in my testing this is how both > Gajim and EjabberD interpret the spec) Even with the should in 9.1, it > still feels like 9.2 turns around and contradicts that.
We have most definitely banned entire domains from chatrooms on conference.jabber.org, and let me tell you I would not want to remove that feature. :) > I suspect that > the rules of pattern matching should be moved up to 9.1 and removed > from 9.2 9.1 talks about banning someone who is in the room right now, whereas 9.2 talks about the ban list in general (e.g., you can ban an entire domain). However, I will work to harmonize the two or at least make the difference clearer. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
