Pete Rowley wrote, On 09/27/2007 02:43 AM:What purpose would this have in a member entry?
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.
Management consoles would deal directly with groups entries since they do need to understand grouping mechanics.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.
At the same time, having a separateI 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.
attribute to hold member groups will be more convenient to implement
from both client and server perspective.
While I agree that loop detection while evaluating nested groups is aHmm, are you thinking I was referring to the group proposal? I was confining my comment to the memberof attribute.
server implementation detail, how about, duplicate value elimination.
Should the standard say anything about this?
-- Pete
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ldapext mailing list Ldapext@ietf.org https://www1.ietf.org/mailman/listinfo/ldapext