[standards-jig] JEP-0045 Suggestions

Richard Dobson richard at dobson-i.net
Mon Sep 16 12:16:49 CDT 2002


> Hi!
>
> First of all, we have to make clear what we're talking about. As I
> mentioned earlier, I'm writing a moderation component working as proxy
> in front of the original conference component filtering incoming and
> outgoing traffic. This is not for fun but experience shows (*) that we
> need some abilities to moderate the chat rooms. Among other things (+)
> we need the ability to kick, mute, gag or ban a user.
>
> If somebody wants to make trouble it's not very efficient just to ban
> him/her by nick in this single room. You maybe have to ban the jid on
> the entire conference server. You might say the conference component
> knows the mapping between nick and jid and that is enough. To support
> reasonable administration features you have to work with jids at the
> client side user interface. But Richard is right. To preserve the
> privacy we must not reveal the jid to every user in the chat room but to
> some privileged administrators. This is the point where user roles and
> capabilities are getting important.

Why exactly is it not enough to keep the real jid handling inside the
server, the only real problem i see is that it will stop your proxy
component from working effectively if it doesnt know the real jid, when this
is part of the official protocol and this is being handled by the
conferencing server there is no need for your component and thus no real
problem. But if necessary then what about a querying protocol for people
with admin access to find out the real jid of someone within a room, rather
than embedding it into this particular part of the protocol when most of the
time it is probably not even needed and complicates things because you have
to handle the broadcast to admin users differently to the rest of the users.

so what about:

<iq type="get" to="room at gc.server.com/user" from="admin at sdsadsa.com">
    <query xmlns="jabber:iq:gcrealjid"/>
</iq>

<iq type="result" to="admin at sdsadsa.com" from="room at gc.server.com/user">
    <query xmlns="jabber:iq:gcrealjid">
        <user jid="realjid at serevs.com"/>
    </query>
</iq>

> It's no real limitation if you say one user has exactly one role. You
> just have to introduce a new role if you don't already have one with the
> needed set of capabilities. But I think it's not a good protocol design
> if you restrict yourself to the single role paradigm by choosing a
> mapping to the xml supporting only one role. Extensibility...

Well if we want the flexibility to possibly have more than one in the future
then what about this, and also have a note that says at the moment, only one
role is supported and having many more than one is highly discoraged.

<presence to="user at sdsds.com" from="room at gc.server.com/user">
    <x xmlns="jabber:x:gcuser">
        <role>admin</role>
    </x>
</presence>




More information about the Standards-JIG mailing list