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

From: Bruce Greenblatt <[email-masked]>
Date: Tue, 22 May 2001 10:44:34 -0700

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

---

From: "Bob Joslin" <[email-masked]>
Date: Tue, 22 May 2001 15:22:56 -0700

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...

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.  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.  The control then causes the server to only return the DNs that
pass that filter?  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:[email-masked]]
> Sent: Tuesday, May 22, 2001 10:45 AM
> To: [email-masked]
> Subject: new control for filtering dn attribute values based upon their
> object class
>
>

---

From: Ming Lang <[email-masked]>
Date: Wed, 23 May 2001 09:51:39 -0700

Hi All,

I did not follow the whole discussion.
However, Bob's idea can be done cleanly by "Filtered Role", a
iDS5.0 feature.

Ming

---

From: [email-masked] (Mark C Smith)
Date: Wed, 23 May 2001 13:32:26 -0400

My initial reaction is that this would be quite useful to authors of
LDAP client applications.  But it would be challenging for a server
implementation to quickly return the information contained in the
DNObjectClassResponse control (there will be additional overhead for
these kinds of search requests or additional overhead for adds,
modifies, and deletes).

What is the most important problem you are trying to address from the
client perspective?  If it is that you need a way to determine if a
member within a groupOfNames object is another groupOfNames vs. a
different kind of entry (e.g., a person), a simpler solution would be to
define a new grouping mechanism that does not mix together nested group
DNs with other DNs.  This is in fact what iPlanet has done in their iDS
5.0 product with our new roles feature.

-Mark Smith
 Netscape

---

From: Ming Lang <[email-masked]>
Date: Wed, 23 May 2001 14:50:20 -0700

Sorry folks,

Please ignore my comments. I thought this was
a little discussion in our project.
Sorry for the confusion :-}

---

From: Bruce Greenblatt <[email-masked]>
Date: Wed, 23 May 2001 12:25:04 -0700

>DNs based membership.)  But I thought I'd throw in a curve ball...

Thanks for the review.

>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
>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

---

From: Bruce Greenblatt <[email-masked]>
Date: Wed, 23 May 2001 18:14:08 -0700

>these kinds of search requests or additional overhead for adds,

I agree that it would be useful, and that it may be difficult for some 
servers to implement it effectively.  However, it would be more burdensome 
on both the client and the server if the client were to retrieve every 
entry in the list of DNs to check its object class values.

>client perspective?

Sifting through numerous values of dn attribute types is the primary 
problem.  There are several scenarios in which this is used.  The mailing 
list example that I mentioned in the original message is one.  Another is 
the scenario in which groups are used to hold application based access 
control information.  I have seen a couple of other examples in 
applications that some of my consulting clients are building.  I believe 
that it has wide applicability.  Mr. Joslin's suggested alternation would 
have even wider applicability, but would be more difficult to implement.

>If it is that you need a way to determine if a

This sounds useful.  I'll look forward to seeing the draft on it!

---

From: "Bob Joslin" <[email-masked]>
Date: Thu, 24 May 2001 13:12:19 -0700

Hi Bruce,

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

Bob Joslin
Hewlett-Packard

> Sent: Wednesday, May 23, 2001 12:25 PM
> To: [email-masked]; [email-masked]
> Subject: RE: new control for filtering dn attribute values based upon
> their object class
>
>

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 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.)  :-)

---

From: Bruce Greenblatt <[email-masked]>
Date: Tue, 29 May 2001 20:33:01 -0700

At 01:12 PM 5/24/01 -0700, Bob Joslin wrote:
>belongs to?

I was thinking that if you were filtering based on object classes, then the 
object class index could be used.  But, you may be right.

>I suppose that would work ok, if if the LDAP client were

It would really depend upon the implementation.  Do you apply the control 
after the search has been implemented, and then filter out the unwanted 
entries, and then create the object class tags in the control response.  Or 
do you implement the control as part of the search process?  I was thinking 
the latter.  But, if you are doing it after the main search processing, 
there are likely to be different considerations.  At one time earlier in my 
career, I prototyped a CIP Tagged Index Object Server that also responded 
to LDAP queries.  In that implementation, it would have been 
straightforward to implement the object class filtering as part of the 
search process.  But, different servers would have different constraints 
that they have to obey.

>entries.  (I sense cringing by several vendors.)  :-)

I agree that this would be useful.  I will create a revision of this draft 
to include other attributes in the "tagging" area.  Would any server 
vendors be interested in stepping up to the plate and taking a swing at 
this one?

Bruce