On Wed, Dec 22, 2010 at 11:45 PM, Emmanuel Lecharny <[email protected]> wrote: > Hi, > > I think I already sent a mail a few weeks ago about this matter. > > The RFC-3671 stipulates that for collectiveAttributes we have to add the > collectiveAttributeSubentries AT in the entry to indicate the subentries > which have been leveraged to add some collectiv attributes in the entry. > Here is the LDAP syntax for this AT : > attributetype ( 2.5.18.12 > NAME 'collectiveAttributeSubentries' > EQUALITY distinguishedNameMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 > NO-USER-MODIFICATION > USAGE directoryOperation > ) > > The RFC 4512 defines the subschemaSubentry AT as a way to define the > subentry containing the schema this entry will use. Its syntax is : > > attributetype( 2.5.18.10 NAME 'subschemaSubentry' > EQUALITY distinguishedNameMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 > SINGLE-VALUE NO-USER-MODIFICATION > USAGE directoryOperation ) > > > We have also defined two other ATs, the accessControlSubentries and > triggerExecutionSubentries which contains a reference to the subentries the > entry is selected by. > > So if a subentry subtree specification selects an entry, then this entry > will have a reference to the subentry. Those values must be returned to the > user if requested (as they are Operational Attributes). > > The problem is that those AT are DNs, which means that moving a subentry > implies we have to modify all the entries pointing to this subentry, a > costly operation. > > I suggested to replace those DN references by the subentry UUID, which won't > change. > > For that, we must create 4 more ATs, having an UUID syntax (1.3.6.1.1.16.1, > it has no associated alias), one per type of subentry. > > We will replace the UUID by a DN when returning the entries. > +1 makes sense to me
thanks Emmanuel -- Kiran Ayyagari
