search

cyrusimap / cyrus-sasl

Other
146 stars 154 forks source link

cyrus sasl uses ldap_initialize #209

Closed brong closed 14 years ago

brong commented 21 years ago

From: Seth Hettich Bugzilla-Id: 2367 Version: 2.1.x Owner: Ken Murchison

brong commented 21 years ago

From: Seth Hettich

ldap_initialize() is not in RFC 1823, and some (many?) implementations do not support it (like solaris). Until it's part of the standard (I think it's even marken experimental in openldap) you should test to see if it's there, and then only try to use it if available (work around not having it if it's not).

brong commented 21 years ago

From: Igor Brezac

openldap recommends ldap_initialize() over ldap_init (according to openldap man pages ldap(3)). ldap_initialize() is extensively used in the openldap tools and other helper programs.

saslauthd man pages and LDAP_SASLAUTHD note the openldap dependency.

saslauthd configure script does test for ldap_initialize(), if not available ldap support is not compiled in.

Do you need non-openldap api support?

Did you have problems building sasl?

brong commented 21 years ago

From: Seth Hettich

Yes. I would like to be able to build saslauthd w/ LDAP using any ldap implementation that conforms to RFC 1823 (Solaris, Novel, etc)

brong commented 21 years ago

From: Igor Brezac

I personally am against this effort. RFC 1823 is very old and it does not cover any V3 features, most notably STARTTLS and SASL. If anything, ldap-c-api draft should be followed (Solaris and Novell (I think) comply with ldap-c-api- draft)

If you have a patch for rfc 1823 compliance, please feel free to contribute.

brong commented 21 years ago

From: Seth Hettich

ldap-c-api-draft would be fine, just something. Does ldap-c-api-draft include ldap_initialize()?

brong commented 21 years ago

From: Igor Brezac

No.

Is openldap api not an option for you?

sasl will certainly be a problem here.

brong commented 21 years ago

From: Seth Hettich

Well, openldap is what we are doing, but from a cross-platform/standards point of view it would be good if you would build without experimental extensions. It's not a big deal tho.

brong commented 21 years ago

From: Rob Siemborski

Supporting more than one implementation only increases the number of ways things can break or be misdetected by autoconf.

I'd rather not see us going out of our way to support lots of different implementations unless there is a very compelling reason to.

brong commented 20 years ago

From: Derrick

As no compelling reason was forthcoming, closing as WONTFIX.