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

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.

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.

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