[Standards] Possible contradiction in defining MUC affiliations

Peter Saint-Andre stpeter at stpeter.im
Fri May 23 03:21:01 UTC 2008


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 <stpeter at stpeter.im> 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. <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).
> 
> 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='kinghenryv at shakespeare.lit/throne'
>     id='ban1'
>     to='southampton at henryv.shakespeare.lit'
>     type='set'>
>   <query xmlns='http://jabber.org/protocol/muc#admin'>
>     <item affiliation='outcast'
>           jid='earlofcambridge at shakespeare.lit'>
>       <reason>Treason</reason>
>     </item>
>   </query>
> </iq>
> 
> Where 9.2 implies that bans can also look of the form
> 
> <<<
> <iq from='kinghenryv at shakespeare.lit/throne'
>     id="2160"
>     to="southampton at henryv.shakespeare.lit"
>     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/

-------------- 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/20080522/06c0d26c/attachment.bin>


More information about the Standards mailing list