Re: new control for filtering dn attribute values based upon theirobject class

[Bruce Greenblatt <bgreenblatt@directory-applications.com>]

At 01:32 PM 5/23/2001 -0400, you wrote:
> 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).

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.


> What is the most important problem you are trying to address from the
> 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
> 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.

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

> -Mark Smith
>  Netscape
>
>
> Bruce Greenblatt wrote:
> >
> > 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