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

Re: LDAP subentry alignment with X.500 subentry



At 08:10 AM 7/7/00 -0700, Mark C Smith wrote:
>"Kurt D. Zeilenga" wrote:
>> 
>> 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.
>
>The X.500 subtree specifier is rich and therefore fairly complex to
>implement.  That doesn't mean we shouldn't adopt it, but it does mean we
>should consider the impact.

We should consider the impact of implementing something different.
LDAP is an access protocol to an X.500 directory.  Each divergence from
the X.500 information/service models makes increasing difficult to
implement servers which supports both LDAP and DAP
and gateways between LDAP and DAP.

>> 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.
>
>But controls are of course more costly for clients and servers to
>implement.

I disagree.  A control is actually quite simple to implement and rather
cheap (as demonstrated by ManageDsaIT).  Interpeting filter side effects
in complex and often leads to inconsistent implementations due to
ambiguity in the specification of these side effects (as demonstrated
by matched-00).

The advantage of a control is it provides an unambiguous mechanism to
enable the behavior.

> What problem are you trying to solve?

In terms of the filter comment: ambiguity of specification, consistency
of implementation.

In terms of subentry v. entry comment: unnecessary incompatible divergence
from X.500.

>As currently defined,
>clients that have knowledge of LDAPsubentries can retrieve them and
>those that do not won't.

Does the filter above have the side effect of making subentries visible
or not? 

>> 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.
>
>Interesting.  Before we throw out the simple LDAPsubentry that Ed has
>defined, I think someone should list the additional requirements that
>are needed for the access control effort to successfully use subentries.

To turn the tables a bit, before we through out X.500 subentry, I think
someone should list LDUP (or other) requirements which the X.500
subentry mechanism is inadequate.