LDUP ACLMechanismOID and InheritedACI attributes and where they belong

[Ed Reed <ED_REED@novell.com>]

Bob, et al -

As I'm working on the LDUP schema, and getting to know the subentry class a little better, I'm starting to have second thoughts about explicitly putting an attributed to hold inherited access control information on the nameContext auxiliary class (which is used to indicate the beginning of a new naming context in the LDAP namespace).  Rather, I'd like to suggest that for those ACL policy mechanisms which need them, that they be stored on a subentry immediately subordinate in the namespace to the nameContext entry to which they apply.

Granted, it's awkward to have ACI information which may apply to an entry be located on an entry subordinate to that entry (the nameContext entry, in this case), but is that so much different from treating it as an attributed ON the nameContext entry to which it applies?  I expect we need to discuss this at some length on the list...and invite others to comment on this thread.

For others, the subentry class is derived from TOP, defined as structural in X.500, though I'd be happy delaring it to be abstract, myself, and it's sole purpose in life is to indicate to servers and clients that they can ignore entries derived from the class for the purposes of supporting user operations...they're used to hold operational and policy information relevant to the namespace and/or DSA with which they're associated (usually via subordination in the namespace).  Thus, a user search or list operation would normally not see them, unless they're explicitly asked for, say, by including the class name in a search filter to indicate you want to include them in the search.

They serve the same purpose for object classes that operational attributes do for attributes.  They're great little beasties for holding policy and management relevant information in the directory.  So it would appear.

Thanks,
Ed

----------------------
Ed Reed, Technologist
Novell, Inc.
+1 801 861-3320