The LDAP 'list' debate

[Colin Robbins <[e-mail]>]

In the last few weeks there have been a number of messages discussing
LDAP, one thread inparticular discussed whether LDAP should support the
X.500 "list" operation.  I don't wish to restart the debate, but do
think the real issue has been lost in a functionality discussion.

From my perspective, the real issue is to make sure the OSI Directory is
capable of providing a usable and useful service to the end user.  Given
the current DSA technology I question whether LDAP without "list" can do
this. 

DUAs such as the PARADISE DE, and infact many ISODE and UFN based DUAs,
rely upon being able to perform a search operation at the high levels of
the DIT.   Irrespective of the reasons why, it is a fact that not all
DSA implementations are capable of doing this (I will refer to these as
non-QUIPU DSAs).  This means that if one of the ISODE based DUA connects
to a non-QUIPU DSA it is unable to perform correctly.  From a users
perspective this is unacceptable.

There are a number of possible ways to proceed.  One is to persuade the
implementors of the non-QUIPU DSAs to make search at these high levels
work.  This is an unreasonable requirement and we are unlikely to 
suceed - they implement the standard fully and meet the various profiles
that exist. QUIPU only works because it makes a simplifying assumption.

Another, more practical solution, is to build "implementation" knowledge
of the situation into the DUAs.  The PARADISE DE interface (full stack
version) does just this.  When looking below a part of the DIT held by a
non-QUIPU DSA, it reverts to a "first generation" algorithm and uses
the list operation.  This then provides a useful service to the end user
in a multi-implementation universe. 

When porting DE to use LDAP, I understand this functionality has had to
be droped as LDAP does not support list.  I argue that this is a major
omission. 

Another possible solution (and perhaps somebody who has read the spec
closer than me can comment if it is possible) is for the LDAP server to
have this "implementation" knowledge built in, and map the LDAP search
onto list and reads for the relevant part of the DIT (you can work out
which parts of the DIT are affected algorithmicaly).

Steve is correct in saying second generation DUAs don't use list, but
these DUAs have to recognise that some DSAs cannot provide the 
level of service required, and downgrade their service appropriately.
Simply not working is not be acceptable to users, we need to ensure LDAP
is capable of delivering a solution.

Parting thought.  This and similar problems will increasingly become
an issue as the number of non-QUIPU implementations in the DIT increase.
DUA implementors have to make sure they provide an interface that will
work across DSA implementation boundaries, otherwise X.500 is not going
to deliver the level of service required, and will loose out to some
other technology.  Perhaps, the interoperability service provided by the 
PARADISE project may be able to help DUA implementors here.


Colin