Re: LDAP (V3)
27 Aug 96 17:53:12 (+0000)

>> Currently the X500 LIST function has not been implemented and I note with
>> disdain that it is not currently proposed to implement this function in V3
>> it is argued that a workaround can be acheived via SEARCH. Has anyone tried
>> implementing LIST and actually measured the time differences between these 2
>> mechanisms ?? The answer is YES I have and I believe that the differences are
>> such that in my view it is essential to implement LIST ASAP.

>Is it not possible to recognise the special case of SEARCH and
>process it efficiently within the server? If it is, LIST is not
>required in the protocol and the problem becomes a local optimisation
>in the server, not a standardisation one.

There will always be the case however, where someone will want
to perform a search of one level for objectClass=* and pull back
all the attributes in the entries. I don't know what you propose
as the special case (filter:objectclass=*, scope=onelevel would
prevent the above request from working) but isn't your solution
trying to hack a way around a restriction of the standard?

I don't like having to use the search operation for SEARCH, LIST
and READ - I'd prefer to have the three separated where
each one is optimised. Most LDAP servers convert the LDAP
request to a DAP request anyway, so adding LIST and READ would
not be that much work, probably the most work would be involved
with handling the protocol.

For cases where a 93 DSA is connected to the LDAP server and
93 access control is in place, isn't a SEARCH going to be
significantly more inefficent than a humble LIST?

Give me XDS anyday ;-)