[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: LDAP subentry alignment with X.500 subentry



Kurt - I disagree with your proposal to replace LDAPsubentry with
X.500 subentry, mainly for reasons already expressed on the list:

1) the subtree specifier is omitted because:

   a) it introduces what seems to be a lot of complexity to determining
       which entries a subentry would refer to, 
   b) it introduces what seems to be a lot of complexity to determining
       which subentries apply to a particular entry,
   c) it introduces what seems to be a lot of complex thinking for
       administrators who want to understand how to tell their system
       to do something, and to understand what their system is trying
       to do
   d) the author (me) has not been exposed to many (any) real-world
       problems solved by the subtree specifier which are not or can
       not be as well handled in some other fashion.

2) As Steven Legg pointed out, X.500 vendors who wish to use the
same mechanism to implement subentry and LDAPsubentry may treat
LDAPsubentry as a limited subset (for the most part, see below) of
the X.500 subentry, with an implicit subtree specification.  The
one place I'm aware of that the LDAP subentry is not a proper
subset of the X.500 subentry is that the LDAPsubentry MAY be
nested, whereas the X.500 subentry may not - but that's really
just a structure rule variation, isn't it?

Of those reasons, the first three of 1 are the qualitative reasons.  As for the
fourth - informal conversations I've had with vendors who HAVE implemented
the subentry suggest that it IS complex to implement, it IS hard to
use correctly in operational environments (because of a, b, and c) and
it's NOT widely used.

I've no objection to extending LDAPsubentry at somepoint in the future
to have full X.500 semantic subentry behavior - but I'd rather let those
of you who think it's worth while do the expansion and let the market
place of real-world operations provide the compelling reason the make
that the standard, rather than try to force it on lots of folks who don't
see the need, today.  Or put another way, I have no problem watching
LDAPsubentry attrophy from lack of use if the X.500 subentry is over=
whelmingly adopted by the LDAP community at large.

Ed



=================
Ed Reed
Reed-Matthews, Inc.
+1 801 796 7065
http://www.Reed-Matthews.COM

>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 07/03/00 10:25AM >>>
I believe 'LDAPsubentry' should be replaced with with 'subentry' and
defined such that it closely modelled after X.500.

1) subentries should have a subtree specifier such that they are more
useful for specification of ACI subentries.

2) subentries should be visible based upon presence of a subentries control,
not a filter components.  For example:
  (|(&(objectclass=LDAPsubentry)(!(cn=*))(objectclass=*))

Should the subentry be visible or not?   There are reasonable arguments
for both yes and no.

I primarily make these suggestions because I believe these changes would
make subentries within LDAP more usable, in particular, when used in
support of the access control model.

Kurt