[Date Prev][Date Next] [Chronological] [Thread] [Top]


At 06:33 AM 12/18/2003, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>>At 12:03 AM 12/18/2003, Michael Ströder wrote:
>>>Hallvard B Furuseth wrote:
>>>> When you talked about LDAP_DEPRECATED some days ago, I
>>>> thought you meant ldap_perror(), ldap_bind() & a few others.
>>>> _That_ sounded good.
>>> Which function should be used for simple binds today?
>> ldap_sasl_bind().
>If so, the function is misnamed.

Lot's of functions could be better named.  I didn't deprecate
anything simply because it was poorly named.

ldap_simple_bind(3) is problematic because it takes char*.
Aside from the fact that zero octets are allowed in password,
being char * it is generally assumed the caller is using this
for UTF-8 encoded Unicode passwords, then it would be reasonable
for the caller to expect ldap_simple_bind(3) provide appropriate
normalization such that equivalent UTF-8 sequences all generate
the same OCTET STRING input to ldap_sasl_bind(3).  It, of course,
does not (yet) do that.

String preparation routines are coming soon to the LDAP C API.
I expect both new standard alone preparation routines as well
as simple bind convenience routine.  That routine likely will be
called ldap_simple_bind_ext() (and support controls).  The question
will then become whether ldap_simple_bind() should be short hand for
ldap_simple_bind_ext() or ldap_sasl_bind().  I'm thinking the
latter would be more appropriate.

(Another reason to deprecated ldap_simple_bind is that it can be
viewed as a short hand for ldap_bind (not ldap_sasl_bind). ldap_bind
is deprecated.)