[xmppwg] privacy list cleanup

Lisa Dusseault lisa at xythos.com
Wed Feb 19 15:00:03 CST 2003


When permissions have both accept and deny, servers must be consistent
in how they order or parse them.   This problem is well known in file
system access control models that have both allow and deny.  Some
existing parse models are:
 (1) Handle all 'deny' before any 'grant'. If a match is found, you can
stop looking. That means that if I deny access to 'xmpp-friends' but
allow access to 'peter-st-andre', the deny is found first, and Peter is
forbidden access.
 (2) A specific grant overrides a deny. Must check all items. That means
if I deny access to 'xmpp-friends' but allow access to 'peter-st-andre',
the individual is more specific than the group, and Peter is allowed
access.

The first model is easier but may not match users expectations as well
as the second.  The second is harder because it's not always trivial to
see what is more "specific".  The server may be able to tell, but the
client should also be able to duplicate the server's logic in order to
tell the user what ought to happen and present a helpful GUI.

I looked in draft-ietf-xmpp-im-02.txt but couldn't see information on
how to parse, so I expect this needs to be added to section 7.  Sorry if
I missed this.

Lisa

> -----Original Message-----
> From: xmppwg-admin at jabber.org 
> [mailto:xmppwg-admin at jabber.org] On Behalf Of Robert Norris
> Sent: Sunday, February 16, 2003 5:03 PM
> To: xmppwg at jabber.org
> Subject: Re: [xmppwg] privacy list cleanup
> 
> 
> > So I propose the following structure:
> > 
> > <item
> >   filter='[group|jid|subscription]'
> >   value='foo'
> >   action='[accept|deny]'/>
> > 
> > This way you could specify only one of the following as the 
> filter type:
> > roster group, user JID, or subscription type. Then the 
> value would be the
> > group name, the bare or full JID, or the subscription type. 
> For any of
> > those, the action can be either accept (whitelist) or deny 
> (blacklist).
> 
> I prefer this. Its easier to implement, and easier to extend in the
> future (we just add new filter types).
> 
> Rob.
> 
> -- 
> Robert Norris                                       GPG: 
> 1024D/FC18E6C2
> Email+Jabber: rob at cataclysm.cx                Web: 
http://cataclysm.cx/





More information about the xmppwg mailing list