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: > > 1) it lets you use StartTLS with applications without the application > author having to add code (and an option, probably) to do so > > 2) 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.
