directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: Referencing subentries in entries
Date Thu, 23 Dec 2010 10:10:37 GMT
On 12/23/10 3:42 AM, Antoine Levy Lambert wrote:
> On 12/22/10 1:15 PM, Emmanuel Lecharny 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 (
>>     NAME 'collectiveAttributeSubentries'
>>     EQUALITY distinguishedNameMatch
>>     SYNTAX
>>     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( NAME 'subschemaSubentry'
>>         EQUALITY distinguishedNameMatch
>>         SYNTAX
>>         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 
>> (, it has no associated alias), one per type of subentry.
>> We will replace the UUID by a DN when returning the entries.
> I like better the DNs for clarity. That's just me though. 
When querying entries from the server, you'll get the DN, not the UUID. 
Using the UUID will spare us the modification of all the entries 
associated with a moved AP (moving an AP will not impact the underlying 
subentries, except if the AP is an IAP). If we had a reference to a DN 
instead of an UUID, that would forces us to update all the entries...

> Is it possible also that in some cases the subentry defines its scope 
> (subtreespecification ?) as the containing entry of the subentry ?
It's not something define in the specification, but we can provide an 
extended operation to compute such information.

> Would in this case a move of the subentry not automatically trigger a 
> recalculation because the scope of the subentry changes when the move 
> happens ?
When the subentry is moved, the subtree will change anyway, leading to 
the definition of a new set of impacted entries.

Emmanuel L├ęcharny

View raw message