[Date Prev][Date Next] [Chronological] [Thread] [Top]

ldapACI: collection and attribute list

At 05:30 PM 3/15/00 -0800, Kurt D. Zeilenga wrote:
At 12:51 AM 3/16/00 -0000, David Chadwick wrote:
>Date forwarded: Wed, 15 Mar 2000 08:16:23 -0800 (PST)
>Date sent: Wed, 15 Mar 2000 10:15:28 -0600
>To: d.w.chadwick@salford.ac.uk, ietf-ldapext@netscape.com
>From: Ellen Stokes <stokes@austin.ibm.com>
>Subject: Re: please publish (draft-ietf-ldapext-acl-model-05.txt)
>Copies to: djbyrne@us.ibm.com, blakley@dascom.com
>Forwarded by: ietf-ldapext@netscape.com
>
>> >vi) Why can an acl entry only confer multiple rights on a single
>> >attribute name. I would have expected <attr> to allow multiple
>> >attribute names within it. (Version 4 allowed this.) Your later
>> >example shows the ldapACI being repeated in order to give SysAdmins
>> >access to attr2 and attr3. Why was the restriction introduced?
>>
>> (EJS) Several people complained that the syntax was too complicated
>> and hence the restriction. We can certainly remove the restriction so
>> attribute: can have one or more attributes. So you can then specify a
>> grouping of attributes by collection: <collectionname> or by
>> attribute: <attr>*. Comments? What's the consensus here?
>
>Again this seems to be the best way forward, lets get some opinions.
>I would argue for allowing multiple attribute types, rather than
>inventing a new collectionname that is only locally known and has to
>be broadcase to applications for them to understand it.

I think a list of attributes should be allowed and that collections
concept dropped.

(EJS) I'll add back the list of attributes (e.g. attribute: <attr>*). However,
collection is still a valuable ease of administration concept. I understand
that a new collection name that might only be known locally could be a
concern, but implementation could code around it to say that if it's not
understood, then it's not supported. I'd like to retain this construct. Any
other opinions?