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.
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.)
Moreover, ldap_initialize can record that StartTLS was already requested because of the extension, and avoid requesting it twice.
What does "avoid requesting it twice" mean? Return an error code or simply ignore it? Note that a client might wanna take note of whether ldap_start_tls() was successfully called by itself or not.
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".
Philip Guenther