Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
Re: legacy ldap?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Howard Chu via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 3 Dec 2025 18:53:10 +0000
Patrick Monnerat via curl-library wrote:
>
> On 12/3/25 10:55 AM, Daniel Stenberg wrote:
>> On Tue, 2 Dec 2025, Patrick Monnerat via curl-library wrote:
>>
>>>> If so, I'm curious to learn more on why and on what system(s).
>>>
>>> Yes: on OS/400 ILE. I do not have any knowledge of an OpenLDAP port to this platform.
>>
>> Do you actually use it on that platform or are you just building for it? We build it in CI as well it turns out.
> I don't really use it, since I'm not in the iSeries business anymore. However I regularly test it manually with db.debian.org
>>
>>> I don't use Windows myself for about 9 years, but at this time there was an OS-native support for LDAP that was usable with this code.
>>
>> WinLDAP exists and that code builds to use it. But I don't know of anyone that *uses* it.
>>
>>> BTW: I don't think it's a "legacy" LDAP. I rather take it as an alternative, just like we have more than a single ssh library support.
>>
>> I use the term legacy for this because this is the old, ancient even, way to do LDAP. There's virtually no public documentation to be found online how this
>> API is supposed to work and the API is "lacking". It feels like yet another one of those forgotten corners of the world that maybe we rather not stir up too
>> much...
>>
> I'm not a specialist of ldap, but I think the API base should be very well defined in some standard doc, as all implementations have a large common part (should
> be verified, but I've no time for it).
All of them are derived from the original LDAP releases from University of Michigan in 1996. That
API was for LDAPv2, that's what RFC1823 specifies.
> However each of the latter have some "dialectic" peculiarities. I.e.: ldap_url_parse() availability.
>
> The original curl ldap code supported all of them with conditionals, or at least tried to. Then the OpenLDAP main maintainer brought the openldap.c module that
> is specific This cannot be used on alternate implementations with adding conditionals and/or wrappers and I think the openldap.c motivation was to get rid of them.
>
> Removal of ldap.c would mean: "use openldap or be 100% compatible or die".
Leading up to the standardization of LDAPv3, there were Netscape, Sun, Novell, and Microsoft implementations in the wild,
besides OpenLDAP. Novell was just using a modified OpenLDAP anyway (just as Apple still does). Sun is gone, Netscape
is gone, and projects that used to use the Netscape LDAP SDK (like RedhatDS/389DS) now just use OpenLDAP. So that really
only leaves Microsoft and OpenLDAP still maintained and in use today, and Microsoft apps tend to use their ADSI instead
of vanilla LDAP anyway.
Date: Wed, 3 Dec 2025 18:53:10 +0000
Patrick Monnerat via curl-library wrote:
>
> On 12/3/25 10:55 AM, Daniel Stenberg wrote:
>> On Tue, 2 Dec 2025, Patrick Monnerat via curl-library wrote:
>>
>>>> If so, I'm curious to learn more on why and on what system(s).
>>>
>>> Yes: on OS/400 ILE. I do not have any knowledge of an OpenLDAP port to this platform.
>>
>> Do you actually use it on that platform or are you just building for it? We build it in CI as well it turns out.
> I don't really use it, since I'm not in the iSeries business anymore. However I regularly test it manually with db.debian.org
>>
>>> I don't use Windows myself for about 9 years, but at this time there was an OS-native support for LDAP that was usable with this code.
>>
>> WinLDAP exists and that code builds to use it. But I don't know of anyone that *uses* it.
>>
>>> BTW: I don't think it's a "legacy" LDAP. I rather take it as an alternative, just like we have more than a single ssh library support.
>>
>> I use the term legacy for this because this is the old, ancient even, way to do LDAP. There's virtually no public documentation to be found online how this
>> API is supposed to work and the API is "lacking". It feels like yet another one of those forgotten corners of the world that maybe we rather not stir up too
>> much...
>>
> I'm not a specialist of ldap, but I think the API base should be very well defined in some standard doc, as all implementations have a large common part (should
> be verified, but I've no time for it).
All of them are derived from the original LDAP releases from University of Michigan in 1996. That
API was for LDAPv2, that's what RFC1823 specifies.
> However each of the latter have some "dialectic" peculiarities. I.e.: ldap_url_parse() availability.
>
> The original curl ldap code supported all of them with conditionals, or at least tried to. Then the OpenLDAP main maintainer brought the openldap.c module that
> is specific This cannot be used on alternate implementations with adding conditionals and/or wrappers and I think the openldap.c motivation was to get rid of them.
>
> Removal of ldap.c would mean: "use openldap or be 100% compatible or die".
Leading up to the standardization of LDAPv3, there were Netscape, Sun, Novell, and Microsoft implementations in the wild,
besides OpenLDAP. Novell was just using a modified OpenLDAP anyway (just as Apple still does). Sun is gone, Netscape
is gone, and projects that used to use the Netscape LDAP SDK (like RedhatDS/389DS) now just use OpenLDAP. So that really
only leaves Microsoft and OpenLDAP still maintained and in use today, and Microsoft apps tend to use their ADSI instead
of vanilla LDAP anyway.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2025-12-03