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.Andrew, I didn't have a chance to follow the complete discussion thread. So, I'm taking the liberty to comment on the items that you mentioned in this summary.
Andrew Findlay wrote, On 09/25/2007 01:13 AM:
Most people who joined the discussion on ldapext@ietf.org were broadly
in support of allowing empty groups, though some thought that any
changes away from the status quo were doomed to fail.
I'm in agreement as well. We already support empty group though its against the standard.
Luke Howard suggested that the behaviour of nested groups should be
defined. I was initially against an explicit definition, but was soon
persuaded that there could be significant performance and security
problems with ad-hoc nesting. At this point the discussion moved
almost entirely to the consideration of nesting issues.
Good suggestion. This is very much needed for interoperability as more and more vendors supporting nested groups.
Pete Rowley wanted an interface to be used by read-only clients to find
out what groups a particular entry is a member of without caring about
how the groups are defined. He suggested a memberOf attribute (presumably
server-maintained) for this purpose. Michael Liben also liked this
approach.
This can even be a virtual attribute for which the implementation can be left to the vendor. Should this include all sort of membership? For eg. static groups, member status through group nesting, dynamic groups...
-- Pete
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext