Re: LDAP_DEPRECATED in OPENLDAP_REL_ENG_2_2

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Kurt D. Zeilenga writes:
>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.

I'll retract that a a bit.  The name is perfectly fine for
a SASL bind which can do a bit else on the side.  It's the choice
of a function with that name for Simple bind which is poor.

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

Irrelevant in this context.  ldap_simple_bind() is named well
enough, and that's the one which was deprecated.

> ldap_simple_bind(3) is problematic because it takes char*.
> Aside from the fact that zero octets are allowed in password,

OK, that's a problem - at least in theory, since I've never heard
anyone complain that they can't use zero octets in passwords.
But I still don't think sufficient reason to deprecate it.
It's useful in most cases, and when it is useful, it works fine.

> 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.

I'm not sure I agree that char* means UTF-8 for LDAP, but anyway,
if you mean SASLprep like the new LDAP protocol spec will say
(http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-protocol-19.txt),
then that also assumes the password is UTF-8.

Until we add SASLprep, it doesn't matter whether the password is
considered UTF-8 or not, so that's no reason to deprecate it yet.
When we do add SASLprep, I imagine ldap_simple_bind(), if we keep it,
would do SASLprep too?

> 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.

What's the difference?

> (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.)

Doesn't seem very relevant to me.  I believe ldap_bind is deprecated
because of its 'authmethod' argument, which ldap_simple_bind doesn't
have.

-- 
Hallvard