Re: Empty rights list in draft-ietf-ldapext-acl-model-04.txt

[David Ward <DSWARD@novell.com>]

I'm a bit confused.  There is already a way to express explicit denial and it doesn't require support for an empty rights list.  An example would be:
 
 aci: 1.2.3.4#subtree#deny;r,w,s,c;[all]#group#cn=Dept XYZ, c=US
 aci: 1.2.3.4#subtree#deny;a,d,e;[entry]#group#cn=Dept XYZ, c=US

Or I guess you could do the revervse and grant nothing:

 aci: 1.2.3.4#subtree#grant;;[all]#group#cn=Dept XYZ, c=US
 aci: 1.2.3.4#subtree#grant;;[entry]#group#cn=Dept XYZ, c=US

I am not sure what you mean by " explicit denial where it is server dependent on exactly how that server stores it"?  Section 2, second paragraph from the bottom, states "No mechanisms are defined ... for storage of access control information at the server; this is vendor dependent".  If I understand this correctly, the storage method is already server dependent.  

David

>>> Ellen Stokes <stokes@austin.ibm.com> 10/19/99 4:21:21 AM >>>
It was a mistake to say that the interpretation of an empty rights ACI is
server
dependent.  We need to be able to express a way of stating 'explicit
denial' where
it is server dependent on exactly how that server stores it.  So an empty
rights
field is permissible and means 'deny all rights to that subject'.  I'll fix
the draft
to correctly reflect this.
Ellen

At 04:45 PM 10/12/1999 -0600, David Ward wrote:
>The BNF in section 6.1 defines rights as:
>
>          < rights > ::= [  ]   |   [ < right > + [ '$'
>                         + <right> ] * ]
>
>This allows the rights part of the acl entry syntax to be empty and
section 6.3 gives an example of an empty rights ACI:
>
>             aci: 1.2.3.4#subtree##group#cn=Dept XYZ, c=US
>
>It goes on to say the interpretation of an empty rights ACI is server
dependent.  What is the purpose and/or value of allowing this type of ACI?
If the interpretation of grant or deny is server dependent, it surely can't
promote interoperability between ldap server vendors.  
>
>David
>
>