Resolution of CLDAP issues.

[[e-mail]]

Two issues have been raised in the past few weeks concerning the
current draft CLDAP specification. They both related to multiple
messages in a single transport-level packet.

1. All the response messages for a Search (each match response plus the
final search response) should go in a single packet. This is so that
erroneous conclusions are not drawn if some packets of a sequence are
received out of order or are lost. I accept this and will change the
wording in sections 5.1 and 5.2 accordingly (basically 'may' -> 'must').

2. It may be desirable to group multiple requests in a single packet.
The primary motivation for this is so that authentication information
(from Bind) can be included and so that, consequently, operations that
require an authenticated user can be performed.

The primary motivation behind CLDAP is to provide a DNS-like service
using the Directory. It is not intended to be (yet) another mechanism
for using the full Directory Abstract Service. The current draft
explicitly forbids the use of Bind with CLDAP.  The problem I see with
including it is if the CLDAP server is implemented separately from the
DSA (likely to be the predominant implementation, particularly in the
near term) then each request including bind information will require a
new DAP association with all the associated overhead, in particular
latency. This increases the complexity required for the server and this
is my primary argument against it.

Servers should be small and simple such that one can deploy many of
them, in the same way and for the same reason that cacheing-only DNS
servers are common.

One suggestion was to make the handling of grouped requests optional in
the server but Tim and Steve have both suggested that it is not a good
idea to allow optional functionality in a server. I am not fully
convinced by this as there are plenty of other protocols that distribute
different aspects of functional complexity between client and server
elements.

My view is that adding grouped requests, or otherwise adding Bind
functionality, will unnecessarily complicate server implementations.
So far Simon E Spero <[e-mail]> seems to be the only
person arguing for this functionality. I do not propose to add it to
current draft and solicit other views on this subject.

I will send and updated draft in the next message with the changes to
section 5.

Alan.