[Date Prev][Date Next]
Re: LDAP_DEPRECATED in OPENLDAP_REL_ENG_2_2
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?
>>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
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