On 5/3/07, Ersin Er <email@example.com> wrote:
On 5/3/07, Alex Karasulu <firstname.lastname@example.org> wrote:
> On 5/2/07, Ersin Er <email@example.com> wrote:
> > Alex,
> > Bringing this mail again to your attention. Please let me know is
> > there is any pb.
> OK more in line ...
> > So, now, regarding to subtreeSpecification related components in ACIs.
> So these are the subterms in the perscriptiveACI attribute syntax and not
> the subtreeSpecification attribute in the ACI subentry. This I think is
> the confusion lies.
> What I am saying is the subtreeSpecification attribute in the ACI subentry
> supports refinements using the full LDAP filter which you extended. However
> the inner elements for classes and subtree inside the prescriptiveACI do
> This is what I would like to clarify.
> > They have not been effected by this change because they cannot be and
> > we did not want also.
> Can you explain why we should not do this?
Well, here is what X.501 says:
SubtreeSpecification does not allow subtree refinement because a
refinement might require a DSA
to use a distributed operation in order to determine if a given user
is in a particular user class. Basic Access
Control is designed to avoid remote operations in the course of making
an access control decision.
Ahhhh yes yes this is important ... it would seriously make ACI calculations slow down the server.
in a subtree whose definition includes only base and chop can be
evaluated locally, whereas membership in a
subtree definition using specificationFilter can only be evaluated by
obtaining information from the user's entry
which is potentially in another DSA.
I am not totally sure if this applies to ApacheDS but by trusting the
completeness of the spec we did never tried to extend the 'subtree'
user class to include specification filter.
Ok np it is now clear to me. Thanks for being such a good student of X.500
> > There are two components that may come to mind
> > about this change. First is the "classes" protected item and the
> > second one is "subtree" user class. The "classes" protected item has
> > the refinement syntax and it is really used for specifying a boolean
> > combination of object classes. It can never include regular attributes
> > other than object class values.
> I know X.500 syntax does not allow it but what prevents us from extending
> it as well to use the full LDAP filter instead? Just curious btw and not
> that we do it.
"classes" is really used for what refinements are intended to be used.
We can still allow regular LDAP filters here but it will just relax
the grammar, it won't provide any more power. Because "classes" is
only used for specifying a logical combination of objectClass values.
Right it would be senseless to do so.