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 ( 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.
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.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com