CLDAP comments

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

It seems the one rational for CLDAP is to overcome certain
host operating limitations.  I don't find this a compelling
rational for undertaking this work.  These limitations are
not that of LDAP, but of the host operating system.  There
are OS-specific methods for working around these limitations.

The key rational is to reduce the transport overhead of issuing
small sets of operations upon a server.  I believe CLDAP is
generally only applicable if the size of the set of operations
is near 1 (per session) and the number of response pdu's per
request is near 2 (entry + result).  In other cases, the overhead
of adding basic reliability (client got the complete answer
for the question asked) to UDP is far greater than the overhead
of TCP.

Hence, I believe the approach used in RFC1798 is actually quite
sound for the limited applicability of connection-less LDAP.

In RFC1798 CLDAP, a client either got "all" or "nothing".  That
is, it sent a request and either got back a response (or
duplicates) and got nothing.  Hence, a client could time-out
waiting for the response and reissue if it got "nothing".
Duplicate responses could be ignored.  Simple but effective.

In the I-D, the client waits for result.  Assuming the
client receives at least one result PDU for the request,
upon receipt of this PDU, the client has no mechanism to
determine whether the subset of responses (ignoring duplicates)
is complete or not.

I believe there needs to some mechanism which the client can
use to determine that it has received all responses.  Without
this, the usefulness of the protocol is, IMO, severely limited.

I note that as RFC 1798 is a Proposed Standard and details
a service with default listener on udp/389 and the I-D
suggested protocol is not compatible with RFC 1798, a
different port should be used.

Kurt