[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] Summary of group discussion
Pete Rowley wrote, On 09/28/2007 12:17 AM:
> Jaimon Jose wrote:
>> Pete Rowley wrote, On 09/27/2007 02:43 AM:
>>
>>> I think the memberOf (or isMemberOf) attribute should be regarded as
>>> authoritative as to membership - that is, if the server recognizes a
>>> particular class as a group then it should should include the DNs of
>>> those entries it considers to be the set of members in the value set -
>>> this is so that clients can free themselves from deep knowledge of
>>> grouping mechanics. For group types that can be nested this would also
>>> include derived membership, but I believe that is a matter between the
>>> group types specification document and the implementation.
>>>
>>
>> I think there should be a way to read direct membership and membership
>> through nested group hierarchy.
> What purpose would this have in a member entry?
This is from an administrative perspective. Our experience in
implementing dynamic groups and nested groups (yet to be released
eDirectory 8.8.2) in eDirectory is that, Administrators always wanted to
know how an entry becomes member of a group. They also wanted to know
the direct(static) members of a group and members through nested or
dynamic relationship. This is because, the hierarchy can be pretty
complex in a deeply nested scenario and administrators will not know who
gets rights when they make a group as a trustee of an object.
>> There is already a proposal to have a
>> control or extension to achieve this. This functionality will be
>> required for management consoles to efficiently display member DNs
>> (non-group) and member groups.
> Management consoles would deal directly with groups entries since they
> do need to understand grouping mechanics.
Right. So, they should be able to read groups entries and non-group
entries.
>> At the same time, having a separate
>> attribute to hold member groups will be more convenient to implement
>> from both client and server perspective.
>>
> I don't think it is more convenient for general clients, I think it is
> actually less value due to the requirement to merge the two value sets
> in order to get the group list. The vast majority of clients really
> don't care why an entry is a member of a group, they just want to know
> that it is.
Clients need not know about this when they just read "member" attribute.
The server implementation should be such that, unless the request
accompany a control or extension, the result set should contain direct
members and members of the groupMember (member DN of type group - nested
or dynamic) .
--jaimon
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext