Philip Guenther wrote:
On Mon, 6 Oct 2008, Michael Ströder wrote:
Pierangelo Masarati wrote:
Michael Ströder wrote:
Yes I also find it useful. Not sure whether it should be within ldap_initialize() or just in the client apps though.
In ldap_initialize(), please. IMO, the proposal solves two problems:
it lets you use StartTLS with applications without the application author having to add code (and an option, probably) to do so
it lets you naturally request StartTLS on a per-URI basis
The former is only obtained if this is done from the library.
I can see the advantages, especially since I have somthing like this in web2ldap's LDAP URL handling.
The first could be problematic if client applications just read the LDAP URI from some configuration file and pass it as is to ldap_initialize() and after that call ldap_start_tls() a second time based on different configuration parameters.
Seem, like a non-problem to me: if the app has an "ldap-tls" option, you would document that the user should not turn that option on if using the starttls URI extension or vice versa.
(All of Sendmail's products that use LDAP have such an option, plus logic to only use ldap_start_tls_s() on plain ldap:// URIs and not ldaps:// or ldapi:// URIs, but I think putting this in the URI is the Right Thing and see no long-term problems with supporting this.)
It's slightly different: From my understanding up to now ldap_initialize() itself did not send out a LDAP PDU. So the error handling of applications might not be prepared for ldap_initialize() causing a real error. This is an incompatible API change.
Such apps have a problem already, as they have to exclude ldaps:// URIs from that. This is just like an ldaps URI, except instead of starting with "ldaps", it ends with "starttlsOIDgoop".
It's not the same since calling ldap_start_tls() sends out the first LDAP PDU which might lead to another error.
Ciao, Michael.