You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2010/12/22 19:15:57 UTC
Referencing subentries in entries
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.
thoughts ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Referencing subentries in entries
Posted by Emmanuel Lecharny <el...@gmail.com>.
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
Re: Referencing subentries in entries
Posted by Antoine Levy Lambert <an...@gmx.de>.
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. Is it possible
also that in some cases the subentry defines its scope
(subtreespecification ?) as the containing entry of the subentry ? 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 ?
>
> thoughts ?
>
Regards,
Antoine
Re: Referencing subentries in entries
Posted by Kiran Ayyagari <ka...@apache.org>.
On Wed, Dec 22, 2010 at 11:45 PM, Emmanuel Lecharny <el...@gmail.com> 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