Re: CLDAP comments

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

At 09:26 AM 2/28/01 +0100, Leif Johansson wrote:
>The "focus" on operating system limitations is just one sencence which
>can easily be removed wo impact on the argument.
>
>You are right that the mechanism of combining results in a single PDU
>was concieved for the express purpouse of overcoming UDP problems but
>I still claim that the following is true:
>
>1. Combining results in a single PDU is be a useful mechanism over
>any transport (UDP or TCP).

For UDP, this is, basically, CLDAP.

>2. Although CLDAP is very simple it is limited in that it does not
>allow extensions or controls.

But CLDAP could be easily expanded to support such.  It would
remain simple.

>My feeling is that if LDAP/UDP is to have any chance of success it
>needs to be folded into the framework of LDAPv3 even at the cost of
>creating an admittedly non-compatible break with RFC1789.

I'm not too concerned about compatibility with RFC1789.  I note
that an RFC 1789 expanded to support LDAPv3'ims would like
non-compatible as well.

However, I am concerned that LDAP/UDP might become too complicated
to be useful.

>I am not sure that I understand your problems with message id reuse.

I believe that message id reuse will complicate mechanisms
providing a means for the client to determine it has obtained
the complete, in-order response set (which I believe is a key
requirement).  How these problems manifest themselves will
depend on what mechanisms are used to provide this basic capability.

One simple mechanism to determine a client has a complete answer
would be for the server to provide a "counter" control with
each response PDU (within the requested set).  That is,
        c: search request { msgid=n, ... }
        s: search entry { msgid=n, ... } counter=1
        s: search reference { msgid=n, ... } counter=0 [out of order]
        s: search entry { msgid=n, ... } counter=2
        s: search entry { msgid=n, ... } counter=2 [duplicate]
        s: search result { msgid=n, ... } counter=3

(where n is some valid message id)

The client can detect there are no missing responses, can
eliminate duplicates, and can reorder responses (if desired).
If anything was missing, the client would retry.

However, if messages ids where reused, you'd then have the
problem with duplicates of the first request would be
indistinguishable from responses to the second request.  The
client could use a 'cookie' control to distinguish each request...
but isn't that exactly the purpose of the message id?

>Please note that I do not claim that this mechanism is the
>solution to all problems!

Yes.  I claim that message id reuse mechanism will make it
harder to solve other problems.