Re: CLDAP issues

Alan Young <Alan.Young@calibre.ch> Mon, 13 December 1993 06:06 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18849; 13 Dec 93 1:06 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18841; 13 Dec 93 1:06 EST
Received: from haig.cs.ucl.ac.uk by CNRI.Reston.VA.US id ab05839; 13 Dec 93 1:06 EST
Received: from bells.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id <g.01675-0@haig.cs.ucl.ac.uk>; Sun, 12 Dec 1993 10:39:09 +0000
Received: from calibre.switch.ch by bells.cs.ucl.ac.uk with Internet SMTP id <g.16441-0@bells.cs.ucl.ac.uk>; Sun, 12 Dec 1993 10:38:55 +0000
Received: from calibre.ch by calibre.switch.ch with SMTP (PP) id <06436-0@calibre.switch.ch>; Sun, 12 Dec 1993 11:38:15 +0100
To: Simon E Spero <ses@tipper.oit.unc.edu>
cc: ldap@umich.edu, osi-ds@cs.ucl.ac.uk
Subject: Re: CLDAP issues
Phone: +41 1 312 1648
In-reply-to: Your message of Sat, 11 Dec 93 13:37:00 -0500. <9312111837.AA00386@tipper.oit.unc.edu>
Date: Sun, 12 Dec 93 11:38:12 +0100
Message-ID: <6434.755692692@calibre.ch>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Alan Young <Alan.Young@calibre.ch>

> The reason for wanting to be able to authenticate individual messages is 
> that I'm working towards an architecture where there is no separate DSA;
> thus the binding is being made to the LDAP server not to the DSA. 

Is this another way of saying a DSA that supports (C)LDAP directly?

> As for the multiple search responses in one UDP datagram; this solution will
> work iff the protocol forbids search responses to be send in different 
> datagrams.

This looks like you want the CLDAP spec only to allow the grouped
response rather than it being a server implementation decision.  There
are two cases where this may be sub-optimal, both related to the size
limitation of UDP packets (but I guess that it would be less of an issue
over OSI CLTS): (a) when a Search returns multiple matches, the sum of
which would not fit in a single packet; (b) when a single Search match
only just fits in a single packet and where the added Search result
would blow the limit. 

You could also argue that the client needs added complexity to deal with
the reassembly. But it needs most of this complexity to deal with timeout
issues in any case. And the risk of loosing just a part of a complete
response still exists when IP is doing the reassembly, although I admit
that this risk is reduced.

For these reasons I prefer grouped responses to be a server
implementation (or runtime) decision. 

Alan.