[Standards] Possible contradiction in defining MUC affiliations

anders conbere aconbere at gmail.com
Wed Apr 23 13:47:41 UTC 2008


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. I suspect that
the rules of pattern matching should be moved up to 9.1 and removed
from 9.2

~ Anders

>
>  Peter
>
>  --
>  Peter Saint-Andre
>  https://stpeter.im/
>
>



More information about the Standards mailing list