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

RE: new control for filtering dn attribute values based upon their object class

Hi Bruce,

Thanks for the reply.  One question and one comment in-line:

Bob Joslin
Hewlett-Packard

> -----Original Message-----
> From: Bruce Greenblatt [mailto:bgreenblatt@directory-applications.com]
> Sent: Wednesday, May 23, 2001 12:25 PM
> To: bobj@cup.hp.com; ietf-ldapext@netscape.com
> Subject: RE: new control for filtering dn attribute values based upon
> their object class
>
>
> At 03:22 PM 5/22/2001 -0700, Bob Joslin wrote:
> >Hi Bruce,
> >
> >Looks like a useful control (we have applications that may need
> to deal with
> >DNs based membership.)  But I thought I'd throw in a curve ball...
>
> Thanks for the review.
>
>
> >It seems that the purpose of the control is so that the client
> application
> >can quickly filter through the DNs and examine only the ones that it is
> >interested in.
>
> That is a main requirement.  It will also help to eliminate some of the
> values that are even returned, which may speed up the data transfer
> somewhat as well.
>
> >So, instead of returning a list of objectclass values in the
> >search results, would it make sense instead to pass in an ldap
> filter in the
> >control.
>
> I had considered that.  The reason that I used the object class only is
> that I thought that would be easier for the server vendors to implement,
> and that it still meets many requirements for the ldap application
> developers.  In some server implementations, entries are either indexed
> based on object class, or otherwise categorized in such a way that it is
> relatively easy to determine the object class of an entry.  While your
> proposal is certainly a more general approach, other attribute types are
> not normally so easy to categorize.  Additionally, there might be a
> substantial performance penalty in using attribute types other than the
> object class.  Due to this, I thought that LDAP server vendors might be
> more receptive to my simpler proposal.  I would support either my current
> proposed mechanism or the more general mechanism if there were sufficient
> interest by the LDAP server folks.  In either case, I can guarantee that
> there would be sufficient interest by LDAP application developers in the
> use of the resulting new feature.

I am most certainly not an expert when it comes to indexed database
technologies.  But from what I think I understand, I'm not sure I understand
why having an index on the objectclass would really help.

Since the LDAP server already knows the DN of the entry in question, why
would it use an objectclass index to determine what objectclasses that entry
belongs to?  I suppose that would work ok, if if the LDAP client were
interested in only one or perhaps two particular objectclasses for that DN.
In that specific case, the server could scan the list(s) of DNs for
that/those partcular objectclass value(s).  But that's could be an expensive
operation if there are many entries of that particular objectclass value.
But it seems that if you were interested in serveral or all the objectclass
values for a particular entry, that the search would be very expensive using
the objectclass index.

It seems to me that once you have the DN, the best way to discover the
objectclasses for a particular entry is to examine the entry itself.

>
> >The control then causes the server to only return the DNs that
> >pass that filter?
>
> The control also provides a way for the client to learn the
> object classes
> of the DNs that are returned, in addition to actually filtering
> out some of
> the uninteresting DNs from being returned at all.

Agreed.  Although, sadly, some implementations of LDAP don't record
auxillary objectclasses.

BTW, self-servingly speaking as a client, I think what I'd like to see is a
combination of the two ideas.  - a filter would be used to filter out the
selected DN based members of a group, and an optional list of attributes
could be returned (objectclass, cn, uid, etc...) for those particular
entries.  (I sense cringing by several vendors.)  :-)

> >So to follow your example, the filter would be
> >"(objectclass=strongAuthenticationUser)".  And only those DNs that are of
> >that OC would be returned.
> >
> >Food for thought.
> >
> >Bob Joslin
> >Hewlett-Packard Company.
> >
> > > -----Original Message-----
> > > From: Bruce Greenblatt [mailto:bgreenblatt@directory-applications.com]
> > > Sent: Tuesday, May 22, 2001 10:45 AM
> > > To: ietf-ldapext@netscape.com
> > > Subject: new control for filtering dn attribute values based
> upon their
> > > object class
> > >
> > >
> > > I've defined a new control which is the result of helping several
> > > customers
> > > with their ldap enabled applications.  They often end up with
> > > entries that
> > > have attributes that have long lists of distinguished names as their
> > > values.  Groups and mailing lists are object classes that
> unfortunately
> > > often end up this way.  Independent of my views on whether it
> is a good
> > > idea to have a zillion values in a single attribute,
> customers' DITs have
> > > them, and they are reluctant to change the DIT.  There are
> many problems
> > > that result from this scenario.  This draft defines a control
> that solves
> > > one of them.  The problem in question arises when the dns in the
> > > attribute
> > > values refer to entries of several different object classes.
> > >
> > > http://search.ietf.org/internet-drafts/draft-greenblatt-dn-type-00.txt
> > >
> > > One good example of how this control would be used is for the
> > > retrieval of
> > > only those dn values which refer to an entry that has a
> certificate (i.e.
> > > has the strongAuthenticationUser object class).  Additionally,
> > > this control
> > > also allows the client to request that the ldap server "tag" each
> > > returned
> > > dn attribute value with the object class(es) of the entry to which it
> > > refers.  Comments welcome.
> > >
> > > Bruce
> > >
> > >
> > > ==============================================
> > > Bruce Greenblatt, Ph. D.
> > > Directory Tools and Application Services, Inc.
> > > http://www.directory-applications.com
> > >
>
> ==============================================
> Bruce Greenblatt, Ph. D.
> Directory Tools and Application Services, Inc.
> http://www.directory-applications.com
>