Re: LDAPv2 -> LDAPv3 in slapd and client API

[Stephan Siano <stephan.siano@suse.de>]

On Wednesday, 9. January 2002 18:34, Kurt D. Zeilenga wrote:
> At 02:30 AM 2002-01-09, Stephan Siano wrote:
> >Hi,
> >
> >in the devel version the slapd refuses LDAPv2 binds (if not configured
> >differently in slapd.conf).
>
> Yes.  For two reasons:
>         a) slapd doesn't really implement LDAPv2 as specified
>            (nobody really does)
>         b) applications developers using HEAD who don't set the
>            API version will realize they aren't using LDAPv3 and
>            hopefully update their code to use LDAPv3.

Well, I don't question that part... :-)

> >At the same time the default value for the
> >protocol version is set to LDAP_VERSION2 in ldap_init (actually in
> >ldap_int_initialize_global_options). Is there a reason for this behaviour?
> >Shouldn't the default better be set to LDAP_VERSION3?
>
> The IETF draft specification says:
>   For compatibility with existing applications, implementations of
>   this API will by default use version 2 of the LDAP protocol.
>
> Personally, I think the I-D should be changed.  But until the
> I-D does change, I think we should follow the I-D as best we can.

Ok, I see why it is as it is, but for what reason the draft is not changed? 
(I mean it's a draft, so it might actually be changed.) All major LDAP 
implementation should allow LDAPv3 binds by now, so it doesn't really make 
sense if the API doesn't do it by default.

> >I know that I can set the protocol version from my application program,
> > but I would guess that might lead to problems with third party
> > applications which just use the OpenLDAP-API and don't care about
> > protocol versions.
>
> Applications which don't care about protocol versions are broken,
> LDAPv2 and LDAPv3 are dramatically different protocols. See
> <http://www.watersprings.org/pub/id/draft-zeilenga-ldapbis-vd-02.txt>
> for just some of the differences.

Well applications don't care about the protocol at all (that's implemented in 
the API) and the difference from the API side is mainly the character 
encoding (which is actually the same for ASCII characters) and the support of 
extended operations (but no application developer is actually forced to use 
these). I already hear the application developers complaining ("It did work 
with the old version and if I can't connect to your server whith the default 
setting of the API you gave me, it is broken...").

However as the draft is as it is, the API is correct and the server settings 
make sense, so I guess we'll have to live with that for now...

Yours,
Stephan Siano

-- 
Stephan Siano                           Mail:  Stephan.Siano@suse.de
SuSE Linux Solutions AG                 Phone: 06196 50951 31
Mergenthalerallee 45-47			Fax:   06196 409607
D-65760 Eschborn