diff --git a/CHANGES b/CHANGES
index eb23eca630a4f8510efd9f7784ef7d8050700739..dd26f9406d4e59bf51663d06ec28264a97da08df 100644
--- a/CHANGES
+++ b/CHANGES
@@ -1,5 +1,5 @@
OpenLDAP 2.4 Change Log
-OpenLDAP 2.4.2alpha Release
+OpenLDAP 2.4.3alpha Engineering
Changes not tracked
diff --git a/build/main.dsw b/build/main.dsw
deleted file mode 100644
index 6df38c1722d431bf74884b437f391049fece50be..0000000000000000000000000000000000000000
--- a/build/main.dsw
+++ /dev/null
@@ -1,746 +0,0 @@
-Microsoft Developer Studio Workspace File, Format Version 5.00
-# WARNING: DO NOT EDIT OR DELETE THIS WORKSPACE FILE!
-
-###############################################################################
-
-Project: "apitest"=..\libraries\libldap\apitest.dsp - Package Owner=<4>
-
-Package=<5>
-{{{
-}}}
-
-Package=<4>
-{{{
- Begin Project Dependency
- Project_Dep_Name libldap
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name liblber
- End Project Dependency
-}}}
-
-###############################################################################
-
-Project: "apitest_r"=..\libraries\libldap_r\apitest_r.dsp - Package Owner=<4>
-
-Package=<5>
-{{{
-}}}
-
-Package=<4>
-{{{
- Begin Project Dependency
- Project_Dep_Name libldap_r
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name liblber
- End Project Dependency
-}}}
-
-###############################################################################
-
-Project: "backbdb"="..\servers\slapd\back-bdb\backbdb.dsp" - Package Owner=<4>
-
-Package=<5>
-{{{
-}}}
-
-Package=<4>
-{{{
- Begin Project Dependency
- Project_Dep_Name setup
- End Project Dependency
-}}}
-
-###############################################################################
-
-Project: "backldbm"="..\servers\slapd\back-ldbm\backldbm.dsp" - Package Owner=<4>
-
-Package=<5>
-{{{
-}}}
-
-Package=<4>
-{{{
- Begin Project Dependency
- Project_Dep_Name setup
- End Project Dependency
-}}}
-
-###############################################################################
-
-Project: "backmon"="..\servers\slapd\back-monitor\backmon.dsp" - Package Owner=<4>
-
-Package=<5>
-{{{
-}}}
-
-Package=<4>
-{{{
-}}}
-
-###############################################################################
-
-Project: "build"=.\build.dsp - Package Owner=<4>
-
-Package=<5>
-{{{
-}}}
-
-Package=<4>
-{{{
- Begin Project Dependency
- Project_Dep_Name apitest
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name apitest_r
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name dtest
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name etest
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name ldapdelete
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name ldapmodify
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name ldapmodrdn
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name ldappasswd
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name ldapsearch
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name ldif
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name testavl
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name slapcat
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name slapadd
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name slapindex
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name slapd
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name ltest
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name ltest_r
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name passwd
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name ucgendat
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name dntest
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name ftest
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name ldapwhoami
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name ldapcompare
- End Project Dependency
-}}}
-
-###############################################################################
-
-Project: "dntest"=..\libraries\libldap\dntest.dsp - Package Owner=<4>
-
-Package=<5>
-{{{
-}}}
-
-Package=<4>
-{{{
- Begin Project Dependency
- Project_Dep_Name liblber
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name libldap
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name liblutil
- End Project Dependency
-}}}
-
-###############################################################################
-
-Project: "dtest"=..\libraries\liblber\dtest.dsp - Package Owner=<4>
-
-Package=<5>
-{{{
-}}}
-
-Package=<4>
-{{{
- Begin Project Dependency
- Project_Dep_Name liblber
- End Project Dependency
-}}}
-
-###############################################################################
-
-Project: "etest"=..\libraries\liblber\etest.dsp - Package Owner=<4>
-
-Package=<5>
-{{{
-}}}
-
-Package=<4>
-{{{
- Begin Project Dependency
- Project_Dep_Name liblber
- End Project Dependency
-}}}
-
-###############################################################################
-
-Project: "ftest"=..\libraries\libldap\ftest.dsp - Package Owner=<4>
-
-Package=<5>
-{{{
-}}}
-
-Package=<4>
-{{{
- Begin Project Dependency
- Project_Dep_Name liblber
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name libldap
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name liblutil
- End Project Dependency
-}}}
-
-###############################################################################
-
-Project: "ldapcompare"=..\clients\tools\ldapcompare.dsp - Package Owner=<4>
-
-Package=<5>
-{{{
-}}}
-
-Package=<4>
-{{{
- Begin Project Dependency
- Project_Dep_Name liblber
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name libldap
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name liblutil
- End Project Dependency
-}}}
-
-###############################################################################
-
-Project: "ldapdelete"=..\clients\tools\ldapdelete.dsp - Package Owner=<4>
-
-Package=<5>
-{{{
-}}}
-
-Package=<4>
-{{{
- Begin Project Dependency
- Project_Dep_Name libldap
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name liblutil
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name liblber
- End Project Dependency
-}}}
-
-###############################################################################
-
-Project: "ldapmodify"=..\clients\tools\ldapmodify.dsp - Package Owner=<4>
-
-Package=<5>
-{{{
-}}}
-
-Package=<4>
-{{{
- Begin Project Dependency
- Project_Dep_Name libldap
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name liblutil
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name liblber
- End Project Dependency
-}}}
-
-###############################################################################
-
-Project: "ldapmodrdn"=..\clients\tools\ldapmodrdn.dsp - Package Owner=<4>
-
-Package=<5>
-{{{
-}}}
-
-Package=<4>
-{{{
- Begin Project Dependency
- Project_Dep_Name libldap
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name liblutil
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name liblber
- End Project Dependency
-}}}
-
-###############################################################################
-
-Project: "ldappasswd"=..\clients\tools\ldappasswd.dsp - Package Owner=<4>
-
-Package=<5>
-{{{
-}}}
-
-Package=<4>
-{{{
- Begin Project Dependency
- Project_Dep_Name libldap
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name liblutil
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name liblber
- End Project Dependency
-}}}
-
-###############################################################################
-
-Project: "ldapsearch"=..\clients\tools\ldapsearch.dsp - Package Owner=<4>
-
-Package=<5>
-{{{
-}}}
-
-Package=<4>
-{{{
- Begin Project Dependency
- Project_Dep_Name libldap
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name liblutil
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name liblber
- End Project Dependency
-}}}
-
-###############################################################################
-
-Project: "ldapwhoami"=..\clients\tools\ldapwhoami.dsp - Package Owner=<4>
-
-Package=<5>
-{{{
-}}}
-
-Package=<4>
-{{{
- Begin Project Dependency
- Project_Dep_Name liblber
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name libldap
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name liblutil
- End Project Dependency
-}}}
-
-###############################################################################
-
-Project: "liblber"=..\libraries\liblber\liblber.dsp - Package Owner=<4>
-
-Package=<5>
-{{{
-}}}
-
-Package=<4>
-{{{
- Begin Project Dependency
- Project_Dep_Name setup
- End Project Dependency
-}}}
-
-###############################################################################
-
-Project: "libldap"=..\libraries\libldap\libldap.dsp - Package Owner=<4>
-
-Package=<5>
-{{{
-}}}
-
-Package=<4>
-{{{
- Begin Project Dependency
- Project_Dep_Name setup
- End Project Dependency
-}}}
-
-###############################################################################
-
-Project: "libldap_r"=..\libraries\libldap_r\libldap_r.dsp - Package Owner=<4>
-
-Package=<5>
-{{{
-}}}
-
-Package=<4>
-{{{
- Begin Project Dependency
- Project_Dep_Name setup
- End Project Dependency
-}}}
-
-###############################################################################
-
-Project: "liblunicode"=..\libraries\liblunicode\liblunicode.dsp - Package Owner=<4>
-
-Package=<5>
-{{{
-}}}
-
-Package=<4>
-{{{
- Begin Project Dependency
- Project_Dep_Name setup
- End Project Dependency
-}}}
-
-###############################################################################
-
-Project: "liblutil"=..\libraries\liblutil\liblutil.dsp - Package Owner=<4>
-
-Package=<5>
-{{{
-}}}
-
-Package=<4>
-{{{
- Begin Project Dependency
- Project_Dep_Name setup
- End Project Dependency
-}}}
-
-###############################################################################
-
-Project: "libslapd"=..\servers\slapd\libslapd.dsp - Package Owner=<4>
-
-Package=<5>
-{{{
-}}}
-
-Package=<4>
-{{{
- Begin Project Dependency
- Project_Dep_Name setup
- End Project Dependency
-}}}
-
-###############################################################################
-
-Project: "ltest"=..\libraries\libldap\ltest.dsp - Package Owner=<4>
-
-Package=<5>
-{{{
-}}}
-
-Package=<4>
-{{{
- Begin Project Dependency
- Project_Dep_Name libldap
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name liblutil
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name liblber
- End Project Dependency
-}}}
-
-###############################################################################
-
-Project: "ltest_r"=..\libraries\libldap_r\ltest_r.dsp - Package Owner=<4>
-
-Package=<5>
-{{{
-}}}
-
-Package=<4>
-{{{
- Begin Project Dependency
- Project_Dep_Name libldap_r
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name liblutil
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name liblber
- End Project Dependency
-}}}
-
-###############################################################################
-
-Project: "passwd"=..\libraries\liblutil\passwd.dsp - Package Owner=<4>
-
-Package=<5>
-{{{
-}}}
-
-Package=<4>
-{{{
- Begin Project Dependency
- Project_Dep_Name liblber
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name liblutil
- End Project Dependency
-}}}
-
-###############################################################################
-
-Project: "setup"=..\include\setup.dsp - Package Owner=<4>
-
-Package=<5>
-{{{
-}}}
-
-Package=<4>
-{{{
-}}}
-
-###############################################################################
-
-Project: "slapadd"=..\servers\slapd\tools\slapadd.dsp - Package Owner=<4>
-
-Package=<5>
-{{{
-}}}
-
-Package=<4>
-{{{
- Begin Project Dependency
- Project_Dep_Name backldbm
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name liblber
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name libldap_r
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name liblutil
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name libslapd
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name liblunicode
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name backbdb
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name backmon
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name backldbm
- End Project Dependency
-}}}
-
-###############################################################################
-
-Project: "slapcat"=..\servers\slapd\tools\slapcat.dsp - Package Owner=<4>
-
-Package=<5>
-{{{
-}}}
-
-Package=<4>
-{{{
- Begin Project Dependency
- Project_Dep_Name liblber
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name libldap_r
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name liblutil
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name libslapd
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name backldbm
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name liblunicode
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name backbdb
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name backmon
- End Project Dependency
-}}}
-
-###############################################################################
-
-Project: "slapd"=..\servers\slapd\slapd.dsp - Package Owner=<4>
-
-Package=<5>
-{{{
-}}}
-
-Package=<4>
-{{{
- Begin Project Dependency
- Project_Dep_Name backldbm
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name libldap_r
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name liblutil
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name setup
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name liblber
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name libslapd
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name liblunicode
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name backbdb
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name backmon
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name backldbm
- End Project Dependency
-}}}
-
-###############################################################################
-
-Project: "slapindex"=..\servers\slapd\tools\slapindex.dsp - Package Owner=<4>
-
-Package=<5>
-{{{
-}}}
-
-Package=<4>
-{{{
- Begin Project Dependency
- Project_Dep_Name backldbm
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name liblber
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name libldap_r
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name liblutil
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name libslapd
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name liblunicode
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name backbdb
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name backmon
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name badldbm
- End Project Dependency
-}}}
-
-###############################################################################
-
-Project: "testavl"=..\libraries\liblutil\testavl.dsp - Package Owner=<4>
-
-Package=<5>
-{{{
-}}}
-
-Package=<4>
-{{{
- Begin Project Dependency
- Project_Dep_Name liblber
- End Project Dependency
- Begin Project Dependency
- Project_Dep_Name liblutil
- End Project Dependency
-}}}
-
-###############################################################################
-
-Project: "ucgendat"=..\libraries\liblunicode\ucgendat.dsp - Package Owner=<4>
-
-Package=<5>
-{{{
-}}}
-
-Package=<4>
-{{{
- Begin Project Dependency
- Project_Dep_Name setup
- End Project Dependency
-}}}
-
-###############################################################################
-
-Global:
-
-Package=<5>
-{{{
-}}}
-
-Package=<3>
-{{{
-}}}
-
-###############################################################################
-
diff --git a/build/version.var b/build/version.var
index c34d625022b3fdddd49ec5843cb38b7d23c7b742..5a6a77d5ccee84579b50bbb5a922d7ff5f042c2f 100644
--- a/build/version.var
+++ b/build/version.var
@@ -15,7 +15,7 @@
ol_package=OpenLDAP
ol_major=2
ol_minor=4
-ol_patch=2alpha
+ol_patch=X
ol_api_inc=20402
ol_api_current=1
ol_api_revision=1
diff --git a/clients/tools/common.c b/clients/tools/common.c
index 0369e3dcb74281cce7fde5d227bfac26ae94cb1b..271a1338693b6b45f55619290bdfbcd1c273734f 100644
--- a/clients/tools/common.c
+++ b/clients/tools/common.c
@@ -187,12 +187,12 @@ N_(" -C chase referrals (anonymously)\n"),
N_(" -d level set LDAP debugging level to `level'\n"),
N_(" -D binddn bind DN\n"),
N_(" -e [!]<ext>[=<extparam>] general extensions (! indicates criticality)\n")
-N_(" [!]assert=<filter> (an RFC 2254 Filter)\n")
+N_(" [!]assert=<filter> (a RFC 4515 Filter string)\n")
N_(" [!]authzid=<authzid> (\"dn:<dn>\" or \"u:<user>\")\n")
#ifdef LDAP_CONTROL_OBSOLETE_PROXY_AUTHZ
#if 0
/* non-advertized support for proxyDN */
-N_(" [!]proxydn=<dn> (an RFC 2253 DN)\n")
+N_(" [!]proxydn=<dn> (a RFC 4514 DN string)\n")
#endif
#endif
#ifdef LDAP_CONTROL_X_CHAINING_BEHAVIOR
@@ -1079,8 +1079,7 @@ tool_bind( LDAP *ld )
{
/* simple bind */
rc = ldap_sasl_bind( ld, binddn, LDAP_SASL_SIMPLE, &passwd,
- sctrlsp,
- NULL, &msgid );
+ sctrlsp, NULL, &msgid );
if ( msgid == -1 ) {
tool_perror( "ldap_sasl_bind(SIMPLE)", rc,
NULL, NULL, NULL, NULL );
diff --git a/clients/tools/ldappasswd.c b/clients/tools/ldappasswd.c
index 4390caaba264cd729d56af36bd0a27910885b775..b8ce5e899a6862e58097077686ff8f86ca857132 100644
--- a/clients/tools/ldappasswd.c
+++ b/clients/tools/ldappasswd.c
@@ -265,7 +265,7 @@ main( int argc, char *argv[] )
}
if( user != NULL || oldpw.bv_val != NULL || newpw.bv_val != NULL ) {
- /* build change password control */
+ /* build the password modify request data */
ber = ber_alloc_t( LBER_USE_DER );
if( ber == NULL ) {
diff --git a/clients/tools/ldapsearch.c b/clients/tools/ldapsearch.c
index 04840c421881d098d885c54ea045f6f710238aa3..e02ba915c89a97644c0fed1f7e5c53c1bca868e8 100644
--- a/clients/tools/ldapsearch.c
+++ b/clients/tools/ldapsearch.c
@@ -109,7 +109,7 @@ void
usage( void )
{
fprintf( stderr, _("usage: %s [options] [filter [attributes...]]\nwhere:\n"), prog);
- fprintf( stderr, _(" filter\tRFC-2254 compliant LDAP search filter\n"));
+ fprintf( stderr, _(" filter\tRFC 4515 compliant LDAP search filter\n"));
fprintf( stderr, _(" attributes\twhitespace-separated list of attribute descriptions\n"));
fprintf( stderr, _(" which may include:\n"));
fprintf( stderr, _(" 1.1 no attributes\n"));
diff --git a/configure b/configure
index 8f4964e5c038d78b52f83a442b821646fd2e1360..00f8fbf4b985116d51afe4005be75c0d0f0d7626 100755
--- a/configure
+++ b/configure
@@ -1,5 +1,5 @@
#! /bin/sh
-# From configure.in OpenLDAP: pkg/ldap/configure.in,v 1.633 2006/04/29 08:09:31 hyc Exp .
+# From configure.in OpenLDAP: pkg/ldap/configure.in,v 1.631.2.2 2006/05/15 17:04:37 kurt Exp .
# Guess values for system-dependent variables and create Makefiles.
# Generated by GNU Autoconf 2.59.
#
@@ -13887,8 +13887,6 @@ fi
-
-
@@ -13937,8 +13935,6 @@ for ac_header in \
termios.h \
unistd.h \
utime.h \
- winsock.h \
- winsock2.h \
do
as_ac_Header=`echo "ac_cv_header_$ac_header" | $as_tr_sh`
@@ -14089,6 +14085,160 @@ fi
done
+if test "$ac_cv_mingw32" = yes ; then
+
+
+for ac_header in winsock.h winsock2.h
+do
+as_ac_Header=`echo "ac_cv_header_$ac_header" | $as_tr_sh`
+if eval "test \"\${$as_ac_Header+set}\" = set"; then
+ echo "$as_me:$LINENO: checking for $ac_header" >&5
+echo $ECHO_N "checking for $ac_header... $ECHO_C" >&6
+if eval "test \"\${$as_ac_Header+set}\" = set"; then
+ echo $ECHO_N "(cached) $ECHO_C" >&6
+fi
+echo "$as_me:$LINENO: result: `eval echo '${'$as_ac_Header'}'`" >&5
+echo "${ECHO_T}`eval echo '${'$as_ac_Header'}'`" >&6
+else
+ # Is the header compilable?
+echo "$as_me:$LINENO: checking $ac_header usability" >&5
+echo $ECHO_N "checking $ac_header usability... $ECHO_C" >&6
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h. */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h. */
+$ac_includes_default
+#include <$ac_header>
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+ (eval $ac_compile) 2>conftest.er1
+ ac_status=$?
+ grep -v '^ *+' conftest.er1 >conftest.err
+ rm -f conftest.er1
+ cat conftest.err >&5
+ echo "$as_me:$LINENO: \$? = $ac_status" >&5
+ (exit $ac_status); } &&
+ { ac_try='test -z "$ac_c_werror_flag"
+ || test ! -s conftest.err'
+ { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+ (eval $ac_try) 2>&5
+ ac_status=$?
+ echo "$as_me:$LINENO: \$? = $ac_status" >&5
+ (exit $ac_status); }; } &&
+ { ac_try='test -s conftest.$ac_objext'
+ { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+ (eval $ac_try) 2>&5
+ ac_status=$?
+ echo "$as_me:$LINENO: \$? = $ac_status" >&5
+ (exit $ac_status); }; }; then
+ ac_header_compiler=yes
+else
+ echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ac_header_compiler=no
+fi
+rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
+echo "$as_me:$LINENO: result: $ac_header_compiler" >&5
+echo "${ECHO_T}$ac_header_compiler" >&6
+
+# Is the header present?
+echo "$as_me:$LINENO: checking $ac_header presence" >&5
+echo $ECHO_N "checking $ac_header presence... $ECHO_C" >&6
+cat >conftest.$ac_ext <<_ACEOF
+/* confdefs.h. */
+_ACEOF
+cat confdefs.h >>conftest.$ac_ext
+cat >>conftest.$ac_ext <<_ACEOF
+/* end confdefs.h. */
+#include <$ac_header>
+_ACEOF
+if { (eval echo "$as_me:$LINENO: \"$ac_cpp conftest.$ac_ext\"") >&5
+ (eval $ac_cpp conftest.$ac_ext) 2>conftest.er1
+ ac_status=$?
+ grep -v '^ *+' conftest.er1 >conftest.err
+ rm -f conftest.er1
+ cat conftest.err >&5
+ echo "$as_me:$LINENO: \$? = $ac_status" >&5
+ (exit $ac_status); } >/dev/null; then
+ if test -s conftest.err; then
+ ac_cpp_err=$ac_c_preproc_warn_flag
+ ac_cpp_err=$ac_cpp_err$ac_c_werror_flag
+ else
+ ac_cpp_err=
+ fi
+else
+ ac_cpp_err=yes
+fi
+if test -z "$ac_cpp_err"; then
+ ac_header_preproc=yes
+else
+ echo "$as_me: failed program was:" >&5
+sed 's/^/| /' conftest.$ac_ext >&5
+
+ ac_header_preproc=no
+fi
+rm -f conftest.err conftest.$ac_ext
+echo "$as_me:$LINENO: result: $ac_header_preproc" >&5
+echo "${ECHO_T}$ac_header_preproc" >&6
+
+# So? What about this header?
+case $ac_header_compiler:$ac_header_preproc:$ac_c_preproc_warn_flag in
+ yes:no: )
+ { echo "$as_me:$LINENO: WARNING: $ac_header: accepted by the compiler, rejected by the preprocessor!" >&5
+echo "$as_me: WARNING: $ac_header: accepted by the compiler, rejected by the preprocessor!" >&2;}
+ { echo "$as_me:$LINENO: WARNING: $ac_header: proceeding with the compiler's result" >&5
+echo "$as_me: WARNING: $ac_header: proceeding with the compiler's result" >&2;}
+ ac_header_preproc=yes
+ ;;
+ no:yes:* )
+ { echo "$as_me:$LINENO: WARNING: $ac_header: present but cannot be compiled" >&5
+echo "$as_me: WARNING: $ac_header: present but cannot be compiled" >&2;}
+ { echo "$as_me:$LINENO: WARNING: $ac_header: check for missing prerequisite headers?" >&5
+echo "$as_me: WARNING: $ac_header: check for missing prerequisite headers?" >&2;}
+ { echo "$as_me:$LINENO: WARNING: $ac_header: see the Autoconf documentation" >&5
+echo "$as_me: WARNING: $ac_header: see the Autoconf documentation" >&2;}
+ { echo "$as_me:$LINENO: WARNING: $ac_header: section \"Present But Cannot Be Compiled\"" >&5
+echo "$as_me: WARNING: $ac_header: section \"Present But Cannot Be Compiled\"" >&2;}
+ { echo "$as_me:$LINENO: WARNING: $ac_header: proceeding with the preprocessor's result" >&5
+echo "$as_me: WARNING: $ac_header: proceeding with the preprocessor's result" >&2;}
+ { echo "$as_me:$LINENO: WARNING: $ac_header: in the future, the compiler will take precedence" >&5
+echo "$as_me: WARNING: $ac_header: in the future, the compiler will take precedence" >&2;}
+ (
+ cat <<\_ASBOX
+## --------------------------------------------- ##
+## Report this to <http://www.openldap.org/its/> ##
+## --------------------------------------------- ##
+_ASBOX
+ ) |
+ sed "s/^/$as_me: WARNING: /" >&2
+ ;;
+esac
+echo "$as_me:$LINENO: checking for $ac_header" >&5
+echo $ECHO_N "checking for $ac_header... $ECHO_C" >&6
+if eval "test \"\${$as_ac_Header+set}\" = set"; then
+ echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+ eval "$as_ac_Header=\$ac_header_preproc"
+fi
+echo "$as_me:$LINENO: result: `eval echo '${'$as_ac_Header'}'`" >&5
+echo "${ECHO_T}`eval echo '${'$as_ac_Header'}'`" >&6
+
+fi
+if test `eval echo '${'$as_ac_Header'}'` = yes; then
+ cat >>confdefs.h <<_ACEOF
+#define `echo "HAVE_$ac_header" | $as_tr_cpp` 1
+_ACEOF
+
+fi
+
+done
+
+fi
+
for ac_header in resolv.h
do
@@ -14465,7 +14615,7 @@ fi
fi
-if test "$ac_cv_cygwin" != yes && test "$ac_cv_header_winsock_h" = yes; then
+if test "$ac_cv_header_winsock_h" = yes; then
echo "$as_me:$LINENO: checking for winsock" >&5
echo $ECHO_N "checking for winsock... $ECHO_C" >&6
if test "${ol_cv_winsock+set}" = set; then
@@ -37912,7 +38062,7 @@ _ACEOF
fi
- if test $ac_cv_header_gmp_h = yes && test $ac_cv_lib_gmp = yes ; then
+ if test $ac_cv_header_gmp_h = yes && test $ac_cv_lib_gmp___gmpz_add_ui = yes ; then
cat >>confdefs.h <<\_ACEOF
#define USE_MP_GMP 1
diff --git a/configure.in b/configure.in
index 425c8e52b6e931b5e601f1868821b7b0af62d4ad..692d8d3384e695bfbc5d30e08905a173ded78854 100644
--- a/configure.in
+++ b/configure.in
@@ -852,10 +852,13 @@ AC_CHECK_HEADERS( \
termios.h \
unistd.h \
utime.h \
- winsock.h \
- winsock2.h \
)
+dnl Only check Winsock on MinGW
+if test "$ac_cv_mingw32" = yes ; then
+ AC_CHECK_HEADERS( winsock.h winsock2.h )
+fi
+
AC_CHECK_HEADERS( resolv.h, [], [],
[$ac_includes_default
#include <netinet/in.h>
@@ -887,9 +890,7 @@ fi
dnl The following is INTENTIONALLY scripted out because shell does not
dnl support variable names with the '@' character, which is what
dnl autoconf would try to generate if one merely used AC_SEARCH_LIBS
-dnl
-dnl Skip Winsock tests on Cygwin
-if test "$ac_cv_cygwin" != yes && test "$ac_cv_header_winsock_h" = yes; then
+if test "$ac_cv_header_winsock_h" = yes; then
AC_CACHE_CHECK([for winsock], [ol_cv_winsock],
save_LIBS="$LIBS"
for curlib in ws2_32 wsock32; do
@@ -2333,7 +2334,7 @@ fi
if test $ol_with_mp = gmp || test $ol_with_mp = auto ; then
AC_CHECK_HEADERS(gmp.h)
AC_CHECK_LIB(gmp, __gmpz_add_ui)
- if test $ac_cv_header_gmp_h = yes && test $ac_cv_lib_gmp = yes ; then
+ if test $ac_cv_header_gmp_h = yes && test $ac_cv_lib_gmp___gmpz_add_ui = yes ; then
AC_DEFINE(USE_MP_GMP,1,[define to use GMP for MP])
ol_with_mp=gmp
elif test $ol_with_mp = gmp ; then
diff --git a/contrib/ldapc++/Makefile.in b/contrib/ldapc++/Makefile.in
index 1df2f44239e18bd34f132512062d2d100e8c6fe4..11c0df223a8ab2710c7462d2710ba22c4f6b9fe6 100644
--- a/contrib/ldapc++/Makefile.in
+++ b/contrib/ldapc++/Makefile.in
@@ -40,8 +40,7 @@ build_triplet = @build@
host_triplet = @host@
DIST_COMMON = README $(am__configure_deps) $(srcdir)/Makefile.am \
$(srcdir)/Makefile.in $(top_srcdir)/configure AUTHORS TODO \
- acconfig.h config.guess config.sub depcomp install-sh \
- ltmain.sh missing mkinstalldirs
+ config.guess config.sub depcomp install-sh ltmain.sh missing
subdir = .
ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
am__aclocal_m4_deps = $(top_srcdir)/configure.in
@@ -49,7 +48,7 @@ am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
$(ACLOCAL_M4)
am__CONFIG_DISTCLEAN_FILES = config.status config.cache config.log \
configure.lineno configure.status.lineno
-mkinstalldirs = $(SHELL) $(top_srcdir)/mkinstalldirs
+mkinstalldirs = $(install_sh) -d
CONFIG_HEADER = $(top_builddir)/src/config.h
CONFIG_CLEAN_FILES =
SOURCES =
diff --git a/contrib/ldapc++/acconfig.h b/contrib/ldapc++/acconfig.h
deleted file mode 100644
index 01f4957f51f5281f7be3c7b0da8aab0d26ef95d6..0000000000000000000000000000000000000000
--- a/contrib/ldapc++/acconfig.h
+++ /dev/null
@@ -1,2 +0,0 @@
-#undef WITH_DEBUG
-
diff --git a/contrib/ldapc++/aclocal.m4 b/contrib/ldapc++/aclocal.m4
index 3e4595203849ba74f9847e831e767e39f237788a..094df7b92f1f599b28004cdf6ccbc77d4f53e6b2 100644
--- a/contrib/ldapc++/aclocal.m4
+++ b/contrib/ldapc++/aclocal.m4
@@ -13,7 +13,7 @@
# libtool.m4 - Configure libtool for the host system. -*-Autoconf-*-
-# serial 47 AC_PROG_LIBTOOL
+# serial 48 AC_PROG_LIBTOOL
# AC_PROVIDE_IFELSE(MACRO-NAME, IF-PROVIDED, IF-NOT-PROVIDED)
@@ -143,7 +143,7 @@ rm="rm -f"
default_ofile=libtool
can_build_shared=yes
-# All known linkers require a `.a' archive for static linking (except M$VC,
+# All known linkers require a `.a' archive for static linking (except MSVC,
# which needs '.lib').
libext=a
ltmain="$ac_aux_dir/ltmain.sh"
@@ -163,6 +163,7 @@ test -z "$AR_FLAGS" && AR_FLAGS=cru
test -z "$AS" && AS=as
test -z "$CC" && CC=cc
test -z "$LTCC" && LTCC=$CC
+test -z "$LTCFLAGS" && LTCFLAGS=$CFLAGS
test -z "$DLLTOOL" && DLLTOOL=dlltool
test -z "$LD" && LD=ld
test -z "$LN_S" && LN_S="ln -s"
@@ -182,10 +183,10 @@ old_postuninstall_cmds=
if test -n "$RANLIB"; then
case $host_os in
openbsd*)
- old_postinstall_cmds="\$RANLIB -t \$oldlib~$old_postinstall_cmds"
+ old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB -t \$oldlib"
;;
*)
- old_postinstall_cmds="\$RANLIB \$oldlib~$old_postinstall_cmds"
+ old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB \$oldlib"
;;
esac
old_archive_cmds="$old_archive_cmds~\$RANLIB \$oldlib"
@@ -233,6 +234,9 @@ AC_DEFUN([_LT_AC_SYS_COMPILER],
# If no C compiler was specified, use CC.
LTCC=${LTCC-"$CC"}
+# If no C compiler flags were specified, use CFLAGS.
+LTCFLAGS=${LTCFLAGS-"$CFLAGS"}
+
# Allow CC to be a program name with arguments.
compiler=$CC
])# _LT_AC_SYS_COMPILER
@@ -261,7 +265,7 @@ cc_basename=`$echo "X$cc_temp" | $Xsed -e 's%.*/%%' -e "s%^$host_alias-%%"`
AC_DEFUN([_LT_COMPILER_BOILERPLATE],
[ac_outfile=conftest.$ac_objext
printf "$lt_simple_compile_test_code" >conftest.$ac_ext
-eval "$ac_compile" 2>&1 >/dev/null | $SED '/^$/d' >conftest.err
+eval "$ac_compile" 2>&1 >/dev/null | $SED '/^$/d; /^ *+/d' >conftest.err
_lt_compiler_boilerplate=`cat conftest.err`
$rm conftest*
])# _LT_COMPILER_BOILERPLATE
@@ -274,7 +278,7 @@ $rm conftest*
AC_DEFUN([_LT_LINKER_BOILERPLATE],
[ac_outfile=conftest.$ac_objext
printf "$lt_simple_link_test_code" >conftest.$ac_ext
-eval "$ac_link" 2>&1 >/dev/null | $SED '/^$/d' >conftest.err
+eval "$ac_link" 2>&1 >/dev/null | $SED '/^$/d; /^ *+/d' >conftest.err
_lt_linker_boilerplate=`cat conftest.err`
$rm conftest*
])# _LT_LINKER_BOILERPLATE
@@ -359,8 +363,8 @@ if test "X${echo_test_string+set}" != Xset; then
# find a string as large as possible, as long as the shell can cope with it
for cmd in 'sed 50q "[$]0"' 'sed 20q "[$]0"' 'sed 10q "[$]0"' 'sed 2q "[$]0"' 'echo test'; do
# expected sizes: less than 2Kb, 1Kb, 512 bytes, 16 bytes, ...
- if (echo_test_string="`eval $cmd`") 2>/dev/null &&
- echo_test_string="`eval $cmd`" &&
+ if (echo_test_string=`eval $cmd`) 2>/dev/null &&
+ echo_test_string=`eval $cmd` &&
(test "X$echo_test_string" = "X$echo_test_string") 2>/dev/null
then
break
@@ -529,7 +533,7 @@ x86_64-*linux*|ppc*-*linux*|powerpc*-*linux*|s390*-*linux*|sparc*-*linux*)
# Find out which ABI we are using.
echo 'int i;' > conftest.$ac_ext
if AC_TRY_EVAL(ac_compile); then
- case "`/usr/bin/file conftest.o`" in
+ case `/usr/bin/file conftest.o` in
*32-bit*)
case $host in
x86_64-*linux*)
@@ -580,6 +584,22 @@ x86_64-*linux*|ppc*-*linux*|powerpc*-*linux*|s390*-*linux*|sparc*-*linux*)
CFLAGS="$SAVE_CFLAGS"
fi
;;
+sparc*-*solaris*)
+ # Find out which ABI we are using.
+ echo 'int i;' > conftest.$ac_ext
+ if AC_TRY_EVAL(ac_compile); then
+ case `/usr/bin/file conftest.o` in
+ *64-bit*)
+ case $lt_cv_prog_gnu_ld in
+ yes*) LD="${LD-ld} -m elf64_sparc" ;;
+ *) LD="${LD-ld} -64" ;;
+ esac
+ ;;
+ esac
+ fi
+ rm -rf conftest*
+ ;;
+
AC_PROVIDE_IFELSE([AC_LIBTOOL_WIN32_DLL],
[*-*-cygwin* | *-*-mingw* | *-*-pw32*)
AC_CHECK_TOOL(DLLTOOL, dlltool, false)
@@ -611,7 +631,7 @@ AC_CACHE_CHECK([$1], [$2],
# with a dollar sign (not a hyphen), so the echo should work correctly.
# The option is referenced via a variable to avoid confusing sed.
lt_compile=`echo "$ac_compile" | $SED \
- -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
+ -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
-e 's: [[^ ]]*conftest\.: $lt_compiler_flag&:; t' \
-e 's:$: $lt_compiler_flag:'`
(eval echo "\"\$as_me:__oline__: $lt_compile\"" >&AS_MESSAGE_LOG_FD)
@@ -622,9 +642,9 @@ AC_CACHE_CHECK([$1], [$2],
if (exit $ac_status) && test -s "$ac_outfile"; then
# The compiler can only warn and ignore the option if not recognized
# So say no if there are warnings other than the usual output.
- $echo "X$_lt_compiler_boilerplate" | $Xsed >conftest.exp
- $SED '/^$/d' conftest.err >conftest.er2
- if test ! -s conftest.err || diff conftest.exp conftest.er2 >/dev/null; then
+ $echo "X$_lt_compiler_boilerplate" | $Xsed -e '/^$/d' >conftest.exp
+ $SED '/^$/d; /^ *+/d' conftest.err >conftest.er2
+ if test ! -s conftest.er2 || diff conftest.exp conftest.er2 >/dev/null; then
$2=yes
fi
fi
@@ -650,13 +670,13 @@ AC_DEFUN([AC_LIBTOOL_LINKER_OPTION],
LDFLAGS="$LDFLAGS $3"
printf "$lt_simple_link_test_code" > conftest.$ac_ext
if (eval $ac_link 2>conftest.err) && test -s conftest$ac_exeext; then
- # The compiler can only warn and ignore the option if not recognized
+ # The linker can only warn and ignore the option if not recognized
# So say no if there are warnings
if test -s conftest.err; then
# Append any errors to the config.log.
cat conftest.err 1>&AS_MESSAGE_LOG_FD
- $echo "X$_lt_linker_boilerplate" | $Xsed > conftest.exp
- $SED '/^$/d' conftest.err >conftest.er2
+ $echo "X$_lt_linker_boilerplate" | $Xsed -e '/^$/d' > conftest.exp
+ $SED '/^$/d; /^ *+/d' conftest.err >conftest.er2
if diff conftest.exp conftest.er2 >/dev/null; then
$2=yes
fi
@@ -725,25 +745,42 @@ AC_CACHE_VAL([lt_cv_sys_max_cmd_len], [dnl
elif test -x /usr/sbin/sysctl; then
lt_cv_sys_max_cmd_len=`/usr/sbin/sysctl -n kern.argmax`
else
- lt_cv_sys_max_cmd_len=65536 # usable default for *BSD
+ lt_cv_sys_max_cmd_len=65536 # usable default for all BSDs
fi
# And add a safety zone
lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \/ 4`
lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \* 3`
;;
+
+ interix*)
+ # We know the value 262144 and hardcode it with a safety zone (like BSD)
+ lt_cv_sys_max_cmd_len=196608
+ ;;
+
osf*)
# Dr. Hans Ekkehard Plesser reports seeing a kernel panic running configure
# due to this test when exec_disable_arg_limit is 1 on Tru64. It is not
# nice to cause kernel panics so lets avoid the loop below.
# First set a reasonable default.
lt_cv_sys_max_cmd_len=16384
- #
+ #
if test -x /sbin/sysconfig; then
case `/sbin/sysconfig -q proc exec_disable_arg_limit` in
*1*) lt_cv_sys_max_cmd_len=-1 ;;
esac
fi
;;
+ sco3.2v5*)
+ lt_cv_sys_max_cmd_len=102400
+ ;;
+ sysv5* | sco5v6* | sysv4.2uw2*)
+ kargmax=`grep ARG_MAX /etc/conf/cf.d/stune 2>/dev/null`
+ if test -n "$kargmax"; then
+ lt_cv_sys_max_cmd_len=`echo $kargmax | sed 's/.*[[ ]]//'`
+ else
+ lt_cv_sys_max_cmd_len=32768
+ fi
+ ;;
*)
# If test is not a shell built-in, we'll probably end up computing a
# maximum length that is only half of the actual maximum length, but
@@ -775,7 +812,7 @@ fi
# _LT_AC_CHECK_DLFCN
-# --------------------
+# ------------------
AC_DEFUN([_LT_AC_CHECK_DLFCN],
[AC_CHECK_HEADERS(dlfcn.h)dnl
])# _LT_AC_CHECK_DLFCN
@@ -783,7 +820,7 @@ AC_DEFUN([_LT_AC_CHECK_DLFCN],
# _LT_AC_TRY_DLOPEN_SELF (ACTION-IF-TRUE, ACTION-IF-TRUE-W-USCORE,
# ACTION-IF-FALSE, ACTION-IF-CROSS-COMPILING)
-# ------------------------------------------------------------------
+# ---------------------------------------------------------------------
AC_DEFUN([_LT_AC_TRY_DLOPEN_SELF],
[AC_REQUIRE([_LT_AC_CHECK_DLFCN])dnl
if test "$cross_compiling" = yes; then :
@@ -849,17 +886,19 @@ int main ()
else if (dlsym( self,"_fnord")) status = $lt_dlneed_uscore;
/* dlclose (self); */
}
+ else
+ puts (dlerror ());
exit (status);
}]
EOF
if AC_TRY_EVAL(ac_link) && test -s conftest${ac_exeext} 2>/dev/null; then
- (./conftest; exit; ) 2>/dev/null
+ (./conftest; exit; ) >&AS_MESSAGE_LOG_FD 2>/dev/null
lt_status=$?
case x$lt_status in
x$lt_dlno_uscore) $1 ;;
x$lt_dlneed_uscore) $2 ;;
- x$lt_unknown|x*) $3 ;;
+ x$lt_dlunknown|x*) $3 ;;
esac
else :
# compilation failed
@@ -871,7 +910,7 @@ rm -fr conftest*
# AC_LIBTOOL_DLOPEN_SELF
-# -------------------
+# ----------------------
AC_DEFUN([AC_LIBTOOL_DLOPEN_SELF],
[AC_REQUIRE([_LT_AC_CHECK_DLFCN])dnl
if test "x$enable_dlopen" != xyes; then
@@ -942,7 +981,7 @@ else
test "x$ac_cv_header_dlfcn_h" = xyes && CPPFLAGS="$CPPFLAGS -DHAVE_DLFCN_H"
save_LDFLAGS="$LDFLAGS"
- eval LDFLAGS=\"\$LDFLAGS $export_dynamic_flag_spec\"
+ wl=$lt_prog_compiler_wl eval LDFLAGS=\"\$LDFLAGS $export_dynamic_flag_spec\"
save_LIBS="$LIBS"
LIBS="$lt_cv_dlopen_libs $LIBS"
@@ -955,7 +994,7 @@ else
])
if test "x$lt_cv_dlopen_self" = xyes; then
- LDFLAGS="$LDFLAGS $link_static_flag"
+ wl=$lt_prog_compiler_wl eval LDFLAGS=\"\$LDFLAGS $lt_prog_compiler_static\"
AC_CACHE_CHECK([whether a statically linked program can dlopen itself],
lt_cv_dlopen_self_static, [dnl
_LT_AC_TRY_DLOPEN_SELF(
@@ -1003,7 +1042,7 @@ AC_CACHE_CHECK([if $compiler supports -c -o file.$ac_objext],
# Note that $ac_compile itself does not contain backslashes and begins
# with a dollar sign (not a hyphen), so the echo should work correctly.
lt_compile=`echo "$ac_compile" | $SED \
- -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
+ -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
-e 's: [[^ ]]*conftest\.: $lt_compiler_flag&:; t' \
-e 's:$: $lt_compiler_flag:'`
(eval echo "\"\$as_me:__oline__: $lt_compile\"" >&AS_MESSAGE_LOG_FD)
@@ -1015,13 +1054,13 @@ AC_CACHE_CHECK([if $compiler supports -c -o file.$ac_objext],
then
# The compiler can only warn and ignore the option if not recognized
# So say no if there are warnings
- $echo "X$_lt_compiler_boilerplate" | $Xsed > out/conftest.exp
- $SED '/^$/d' out/conftest.err >out/conftest.er2
- if test ! -s out/conftest.err || diff out/conftest.exp out/conftest.er2 >/dev/null; then
+ $echo "X$_lt_compiler_boilerplate" | $Xsed -e '/^$/d' > out/conftest.exp
+ $SED '/^$/d; /^ *+/d' out/conftest.err >out/conftest.er2
+ if test ! -s out/conftest.er2 || diff out/conftest.exp out/conftest.er2 >/dev/null; then
_LT_AC_TAGVAR(lt_cv_prog_compiler_c_o, $1)=yes
fi
fi
- chmod u+w .
+ chmod u+w . 2>&AS_MESSAGE_LOG_FD
$rm conftest*
# SGI C++ compiler will create directory out/ii_files/ for
# template instantiation
@@ -1281,7 +1320,8 @@ cygwin* | mingw* | pw32*)
dlpath=`$SHELL 2>&1 -c '\''. $dir/'\''\${base_file}'\''i;echo \$dlname'\''`~
dldir=$destdir/`dirname \$dlpath`~
test -d \$dldir || mkdir -p \$dldir~
- $install_prog $dir/$dlname \$dldir/$dlname'
+ $install_prog $dir/$dlname \$dldir/$dlname~
+ chmod a+x \$dldir/$dlname'
postuninstall_cmds='dldll=`$SHELL 2>&1 -c '\''. $file; echo \$dlname'\''`~
dlpath=$dir/\$dldll~
$rm \$dlpath'
@@ -1334,7 +1374,7 @@ darwin* | rhapsody*)
soname_spec='${libname}${release}${major}$shared_ext'
shlibpath_overrides_runpath=yes
shlibpath_var=DYLD_LIBRARY_PATH
- shrext_cmds='$(test .$module = .yes && echo .so || echo .dylib)'
+ shrext_cmds='`test .$module = .yes && echo .so || echo .dylib`'
# Apple's gcc prints 'gcc -print-search-dirs' doesn't operate the same.
if test "$GCC" = yes; then
sys_lib_search_path_spec=`$CC -print-search-dirs | tr "\n" "$PATH_SEPARATOR" | sed -e 's/libraries:/@libraries:/' | tr "@" "\n" | grep "^libraries:" | sed -e "s/^libraries://" -e "s,=/,/,g" -e "s,$PATH_SEPARATOR, ,g" -e "s,.*,& /lib /usr/lib /usr/local/lib,g"`
@@ -1372,7 +1412,14 @@ kfreebsd*-gnu)
freebsd* | dragonfly*)
# DragonFly does not have aout. When/if they implement a new
# versioning mechanism, adjust this.
- objformat=`test -x /usr/bin/objformat && /usr/bin/objformat || echo aout`
+ if test -x /usr/bin/objformat; then
+ objformat=`/usr/bin/objformat`
+ else
+ case $host_os in
+ freebsd[[123]]*) objformat=aout ;;
+ *) objformat=elf ;;
+ esac
+ fi
version_type=freebsd-$objformat
case $version_type in
freebsd-elf*)
@@ -1394,10 +1441,15 @@ freebsd* | dragonfly*)
shlibpath_overrides_runpath=yes
hardcode_into_libs=yes
;;
- *) # from 3.2 on
+ freebsd3.[[2-9]]* | freebsdelf3.[[2-9]]* | \
+ freebsd4.[[0-5]] | freebsdelf4.[[0-5]] | freebsd4.1.1 | freebsdelf4.1.1)
shlibpath_overrides_runpath=no
hardcode_into_libs=yes
;;
+ freebsd*) # from 4.6 on
+ shlibpath_overrides_runpath=yes
+ hardcode_into_libs=yes
+ ;;
esac
;;
@@ -1417,7 +1469,7 @@ hpux9* | hpux10* | hpux11*)
version_type=sunos
need_lib_prefix=no
need_version=no
- case "$host_cpu" in
+ case $host_cpu in
ia64*)
shrext_cmds='.so'
hardcode_into_libs=yes
@@ -1457,6 +1509,18 @@ hpux9* | hpux10* | hpux11*)
postinstall_cmds='chmod 555 $lib'
;;
+interix3*)
+ version_type=linux
+ need_lib_prefix=no
+ need_version=no
+ library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major ${libname}${shared_ext}'
+ soname_spec='${libname}${release}${shared_ext}$major'
+ dynamic_linker='Interix 3.x ld.so.1 (PE, like ELF)'
+ shlibpath_var=LD_LIBRARY_PATH
+ shlibpath_overrides_runpath=no
+ hardcode_into_libs=yes
+ ;;
+
irix5* | irix6* | nonstopux*)
case $host_os in
nonstopux*) version_type=nonstopux ;;
@@ -1578,6 +1642,7 @@ nto-qnx*)
openbsd*)
version_type=sunos
+ sys_lib_dlsearch_path_spec="/usr/lib"
need_lib_prefix=no
# Some older versions of OpenBSD (3.3 at least) *do* need versioned libs.
case $host_os in
@@ -1621,13 +1686,6 @@ osf3* | osf4* | osf5*)
sys_lib_dlsearch_path_spec="$sys_lib_search_path_spec"
;;
-sco3.2v5*)
- version_type=osf
- soname_spec='${libname}${release}${shared_ext}$major'
- library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
- shlibpath_var=LD_LIBRARY_PATH
- ;;
-
solaris*)
version_type=linux
need_lib_prefix=no
@@ -1653,7 +1711,7 @@ sunos4*)
need_version=yes
;;
-sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
+sysv4 | sysv4.3*)
version_type=linux
library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
soname_spec='${libname}${release}${shared_ext}$major'
@@ -1686,6 +1744,29 @@ sysv4*MP*)
fi
;;
+sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX* | sysv4*uw2*)
+ version_type=freebsd-elf
+ need_lib_prefix=no
+ need_version=no
+ library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext} $libname${shared_ext}'
+ soname_spec='${libname}${release}${shared_ext}$major'
+ shlibpath_var=LD_LIBRARY_PATH
+ hardcode_into_libs=yes
+ if test "$with_gnu_ld" = yes; then
+ sys_lib_search_path_spec='/usr/local/lib /usr/gnu/lib /usr/ccs/lib /usr/lib /lib'
+ shlibpath_overrides_runpath=no
+ else
+ sys_lib_search_path_spec='/usr/ccs/lib /usr/lib'
+ shlibpath_overrides_runpath=yes
+ case $host_os in
+ sco3.2v5*)
+ sys_lib_search_path_spec="$sys_lib_search_path_spec /lib"
+ ;;
+ esac
+ fi
+ sys_lib_dlsearch_path_spec='/usr/lib'
+ ;;
+
uts4*)
version_type=linux
library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
@@ -1699,6 +1780,11 @@ uts4*)
esac
AC_MSG_RESULT([$dynamic_linker])
test "$dynamic_linker" = no && can_build_shared=no
+
+variables_saved_for_relink="PATH $shlibpath_var $runpath_var"
+if test "$GCC" = yes; then
+ variables_saved_for_relink="$variables_saved_for_relink GCC_EXEC_PREFIX COMPILER_PATH LIBRARY_PATH"
+fi
])# AC_LIBTOOL_SYS_DYNAMIC_LINKER
@@ -1723,6 +1809,9 @@ if test -f "$ltmain" && test -n "$tagnames"; then
AC_MSG_WARN([using `LTCC=$LTCC', extracted from `$ofile'])
fi
fi
+ if test -z "$LTCFLAGS"; then
+ eval "`$SHELL ${ofile} --config | grep '^LTCFLAGS='`"
+ fi
# Extract list of available tagged configurations in $ofile.
# Note that this assumes the entire list is on one line.
@@ -1813,7 +1902,7 @@ AC_DEFUN([AC_LIBTOOL_DLOPEN],
# AC_LIBTOOL_WIN32_DLL
# --------------------
-# declare package support for building win32 dll's
+# declare package support for building win32 DLLs
AC_DEFUN([AC_LIBTOOL_WIN32_DLL],
[AC_BEFORE([$0], [AC_LIBTOOL_SETUP])
])# AC_LIBTOOL_WIN32_DLL
@@ -1851,7 +1940,7 @@ AC_ARG_ENABLE([shared],
# AC_DISABLE_SHARED
# -----------------
-#- set the default shared flag to --disable-shared
+# set the default shared flag to --disable-shared
AC_DEFUN([AC_DISABLE_SHARED],
[AC_BEFORE([$0],[AC_LIBTOOL_SETUP])dnl
AC_ENABLE_SHARED(no)
@@ -1987,7 +2076,7 @@ dnl not every word. This closes a longstanding sh security hole.
if test -n "$file_magic_test_file"; then
case $deplibs_check_method in
"file_magic "*)
- file_magic_regex="`expr \"$deplibs_check_method\" : \"file_magic \(.*\)\"`"
+ file_magic_regex=`expr "$deplibs_check_method" : "file_magic \(.*\)"`
MAGIC_CMD="$lt_cv_path_MAGIC_CMD"
if eval $file_magic_cmd \$file_magic_test_file 2> /dev/null |
$EGREP "$file_magic_regex" > /dev/null; then
@@ -2097,7 +2186,7 @@ AC_CACHE_VAL(lt_cv_path_LD,
if test -f "$ac_dir/$ac_prog" || test -f "$ac_dir/$ac_prog$ac_exeext"; then
lt_cv_path_LD="$ac_dir/$ac_prog"
# Check to see if the program is GNU ld. I'd rather use --version,
- # but apparently some GNU ld's only accept -v.
+ # but apparently some variants of GNU ld only accept -v.
# Break only if it was the GNU/non-GNU ld that we prefer.
case `"$lt_cv_path_LD" -v 2>&1 </dev/null` in
*GNU* | *'with BFD'*)
@@ -2129,7 +2218,7 @@ AC_PROG_LD_GNU
AC_DEFUN([AC_PROG_LD_GNU],
[AC_REQUIRE([AC_PROG_EGREP])dnl
AC_CACHE_CHECK([if the linker ($LD) is GNU ld], lt_cv_prog_gnu_ld,
-[# I'd rather use --version here, but apparently some GNU ld's only accept -v.
+[# I'd rather use --version here, but apparently some GNU lds only accept -v.
case `$LD -v 2>&1 </dev/null` in
*GNU* | *'with BFD'*)
lt_cv_prog_gnu_ld=yes
@@ -2159,7 +2248,7 @@ reload_cmds='$LD$reload_flag -o $output$reload_objs'
case $host_os in
darwin*)
if test "$GCC" = yes; then
- reload_cmds='$CC -nostdlib ${wl}-r -o $output$reload_objs'
+ reload_cmds='$LTCC $LTCFLAGS -nostdlib ${wl}-r -o $output$reload_objs'
else
reload_cmds='$LD$reload_flag -o $output$reload_objs'
fi
@@ -2243,7 +2332,7 @@ gnu*)
hpux10.20* | hpux11*)
lt_cv_file_magic_cmd=/usr/bin/file
- case "$host_cpu" in
+ case $host_cpu in
ia64*)
lt_cv_deplibs_check_method='file_magic (s[[0-9]][[0-9]][[0-9]]|ELF-[[0-9]][[0-9]]) shared object file - IA64'
lt_cv_file_magic_test_file=/usr/lib/hpux32/libc.so
@@ -2259,6 +2348,11 @@ hpux10.20* | hpux11*)
esac
;;
+interix3*)
+ # PIC code is broken on Interix 3.x, that's why |\.a not |_pic\.a here
+ lt_cv_deplibs_check_method='match_pattern /lib[[^/]]+(\.so|\.a)$'
+ ;;
+
irix5* | irix6* | nonstopux*)
case $LD in
*-32|*"-32 ") libmagic=32-bit;;
@@ -2304,15 +2398,11 @@ osf3* | osf4* | osf5*)
lt_cv_deplibs_check_method=pass_all
;;
-sco3.2v5*)
- lt_cv_deplibs_check_method=pass_all
- ;;
-
solaris*)
lt_cv_deplibs_check_method=pass_all
;;
-sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
+sysv4 | sysv4.3*)
case $host_vendor in
motorola)
lt_cv_deplibs_check_method='file_magic ELF [[0-9]][[0-9]]*-bit [[ML]]SB (shared object|dynamic lib) M[[0-9]][[0-9]]* Version [[0-9]]'
@@ -2333,10 +2423,13 @@ sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
siemens)
lt_cv_deplibs_check_method=pass_all
;;
+ pc)
+ lt_cv_deplibs_check_method=pass_all
+ ;;
esac
;;
-sysv5OpenUNIX8* | sysv5UnixWare7* | sysv5uw[[78]]* | unixware7* | sysv4*uw2*)
+sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX* | sysv4*uw2*)
lt_cv_deplibs_check_method=pass_all
;;
esac
@@ -2356,36 +2449,43 @@ AC_DEFUN([AC_PROG_NM],
# Let the user override the test.
lt_cv_path_NM="$NM"
else
- lt_save_ifs="$IFS"; IFS=$PATH_SEPARATOR
- for ac_dir in $PATH /usr/ccs/bin /usr/ucb /bin; do
- IFS="$lt_save_ifs"
- test -z "$ac_dir" && ac_dir=.
- tmp_nm="$ac_dir/${ac_tool_prefix}nm"
- if test -f "$tmp_nm" || test -f "$tmp_nm$ac_exeext" ; then
- # Check to see if the nm accepts a BSD-compat flag.
- # Adding the `sed 1q' prevents false positives on HP-UX, which says:
- # nm: unknown option "B" ignored
- # Tru64's nm complains that /dev/null is an invalid object file
- case `"$tmp_nm" -B /dev/null 2>&1 | sed '1q'` in
- */dev/null* | *'Invalid file or object type'*)
- lt_cv_path_NM="$tmp_nm -B"
- break
- ;;
- *)
- case `"$tmp_nm" -p /dev/null 2>&1 | sed '1q'` in
- */dev/null*)
- lt_cv_path_NM="$tmp_nm -p"
+ lt_nm_to_check="${ac_tool_prefix}nm"
+ if test -n "$ac_tool_prefix" && test "$build" = "$host"; then
+ lt_nm_to_check="$lt_nm_to_check nm"
+ fi
+ for lt_tmp_nm in $lt_nm_to_check; do
+ lt_save_ifs="$IFS"; IFS=$PATH_SEPARATOR
+ for ac_dir in $PATH /usr/ccs/bin/elf /usr/ccs/bin /usr/ucb /bin; do
+ IFS="$lt_save_ifs"
+ test -z "$ac_dir" && ac_dir=.
+ tmp_nm="$ac_dir/$lt_tmp_nm"
+ if test -f "$tmp_nm" || test -f "$tmp_nm$ac_exeext" ; then
+ # Check to see if the nm accepts a BSD-compat flag.
+ # Adding the `sed 1q' prevents false positives on HP-UX, which says:
+ # nm: unknown option "B" ignored
+ # Tru64's nm complains that /dev/null is an invalid object file
+ case `"$tmp_nm" -B /dev/null 2>&1 | sed '1q'` in
+ */dev/null* | *'Invalid file or object type'*)
+ lt_cv_path_NM="$tmp_nm -B"
break
;;
*)
- lt_cv_path_NM=${lt_cv_path_NM="$tmp_nm"} # keep the first match, but
- continue # so that we can try to find one that supports BSD flags
+ case `"$tmp_nm" -p /dev/null 2>&1 | sed '1q'` in
+ */dev/null*)
+ lt_cv_path_NM="$tmp_nm -p"
+ break
+ ;;
+ *)
+ lt_cv_path_NM=${lt_cv_path_NM="$tmp_nm"} # keep the first match, but
+ continue # so that we can try to find one that supports BSD flags
+ ;;
+ esac
;;
esac
- esac
- fi
+ fi
+ done
+ IFS="$lt_save_ifs"
done
- IFS="$lt_save_ifs"
test -z "$lt_cv_path_NM" && lt_cv_path_NM=nm
fi])
NM="$lt_cv_path_NM"
@@ -2417,13 +2517,13 @@ esac
# -----------------------------------
# sets LIBLTDL to the link flags for the libltdl convenience library and
# LTDLINCL to the include flags for the libltdl header and adds
-# --enable-ltdl-convenience to the configure arguments. Note that LIBLTDL
-# and LTDLINCL are not AC_SUBSTed, nor is AC_CONFIG_SUBDIRS called. If
-# DIRECTORY is not provided, it is assumed to be `libltdl'. LIBLTDL will
-# be prefixed with '${top_builddir}/' and LTDLINCL will be prefixed with
-# '${top_srcdir}/' (note the single quotes!). If your package is not
-# flat and you're not using automake, define top_builddir and
-# top_srcdir appropriately in the Makefiles.
+# --enable-ltdl-convenience to the configure arguments. Note that
+# AC_CONFIG_SUBDIRS is not called here. If DIRECTORY is not provided,
+# it is assumed to be `libltdl'. LIBLTDL will be prefixed with
+# '${top_builddir}/' and LTDLINCL will be prefixed with '${top_srcdir}/'
+# (note the single quotes!). If your package is not flat and you're not
+# using automake, define top_builddir and top_srcdir appropriately in
+# the Makefiles.
AC_DEFUN([AC_LIBLTDL_CONVENIENCE],
[AC_BEFORE([$0],[AC_LIBTOOL_SETUP])dnl
case $enable_ltdl_convenience in
@@ -2442,13 +2542,13 @@ AC_DEFUN([AC_LIBLTDL_CONVENIENCE],
# -----------------------------------
# sets LIBLTDL to the link flags for the libltdl installable library and
# LTDLINCL to the include flags for the libltdl header and adds
-# --enable-ltdl-install to the configure arguments. Note that LIBLTDL
-# and LTDLINCL are not AC_SUBSTed, nor is AC_CONFIG_SUBDIRS called. If
-# DIRECTORY is not provided and an installed libltdl is not found, it is
-# assumed to be `libltdl'. LIBLTDL will be prefixed with '${top_builddir}/'
-# and LTDLINCL will be prefixed with '${top_srcdir}/' (note the single
-# quotes!). If your package is not flat and you're not using automake,
-# define top_builddir and top_srcdir appropriately in the Makefiles.
+# --enable-ltdl-install to the configure arguments. Note that
+# AC_CONFIG_SUBDIRS is not called here. If DIRECTORY is not provided,
+# and an installed libltdl is not found, it is assumed to be `libltdl'.
+# LIBLTDL will be prefixed with '${top_builddir}/'# and LTDLINCL with
+# '${top_srcdir}/' (note the single quotes!). If your package is not
+# flat and you're not using automake, define top_builddir and top_srcdir
+# appropriately in the Makefiles.
# In the future, this macro may have to be called after AC_PROG_LIBTOOL.
AC_DEFUN([AC_LIBLTDL_INSTALLABLE],
[AC_BEFORE([$0],[AC_LIBTOOL_SETUP])dnl
@@ -2491,7 +2591,7 @@ _LT_AC_SHELL_INIT([tagnames=${tagnames+${tagnames},}CXX])
])# _LT_AC_LANG_CXX
# _LT_AC_PROG_CXXCPP
-# ---------------
+# ------------------
AC_DEFUN([_LT_AC_PROG_CXXCPP],
[
AC_REQUIRE([AC_PROG_CXX])
@@ -2540,7 +2640,7 @@ _LT_AC_SHELL_INIT([tagnames=${tagnames+${tagnames},}GCJ])
# AC_LIBTOOL_RC
-# --------------
+# -------------
# enable support for Windows resource files
AC_DEFUN([AC_LIBTOOL_RC],
[AC_REQUIRE([LT_AC_PROG_RC])
@@ -2577,37 +2677,6 @@ _LT_AC_SYS_COMPILER
_LT_COMPILER_BOILERPLATE
_LT_LINKER_BOILERPLATE
-#
-# Check for any special shared library compilation flags.
-#
-_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)=
-if test "$GCC" = no; then
- case $host_os in
- sco3.2v5*)
- _LT_AC_TAGVAR(lt_prog_cc_shlib, $1)='-belf'
- ;;
- esac
-fi
-if test -n "$_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)"; then
- AC_MSG_WARN([`$CC' requires `$_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)' to build shared libraries])
- if echo "$old_CC $old_CFLAGS " | grep "[[ ]]$_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)[[ ]]" >/dev/null; then :
- else
- AC_MSG_WARN([add `$_LT_AC_TAGVAR(lt_prog_cc_shlib, $1)' to the CC or CFLAGS env variable and reconfigure])
- _LT_AC_TAGVAR(lt_cv_prog_cc_can_build_shared, $1)=no
- fi
-fi
-
-
-#
-# Check to make sure the static flag actually works.
-#
-AC_LIBTOOL_LINKER_OPTION([if $compiler static flag $_LT_AC_TAGVAR(lt_prog_compiler_static, $1) works],
- _LT_AC_TAGVAR(lt_prog_compiler_static_works, $1),
- $_LT_AC_TAGVAR(lt_prog_compiler_static, $1),
- [],
- [_LT_AC_TAGVAR(lt_prog_compiler_static, $1)=])
-
-
AC_LIBTOOL_PROG_COMPILER_NO_RTTI($1)
AC_LIBTOOL_PROG_COMPILER_PIC($1)
AC_LIBTOOL_PROG_CC_C_O($1)
@@ -2616,9 +2685,9 @@ AC_LIBTOOL_PROG_LD_SHLIBS($1)
AC_LIBTOOL_SYS_DYNAMIC_LINKER($1)
AC_LIBTOOL_PROG_LD_HARDCODE_LIBPATH($1)
AC_LIBTOOL_SYS_LIB_STRIP
-AC_LIBTOOL_DLOPEN_SELF($1)
+AC_LIBTOOL_DLOPEN_SELF
-# Report which librarie types wil actually be built
+# Report which library types will actually be built
AC_MSG_CHECKING([if libtool supports shared libraries])
AC_MSG_RESULT([$can_build_shared])
@@ -2627,7 +2696,7 @@ test "$can_build_shared" = "no" && enable_shared=no
# On AIX, shared libraries and static libraries use the same namespace, and
# are all built from PIC.
-case "$host_os" in
+case $host_os in
aix3*)
test "$enable_shared" = yes && enable_static=no
if test -n "$RANLIB"; then
@@ -2677,6 +2746,7 @@ _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)=
_LT_AC_TAGVAR(hardcode_libdir_flag_spec_ld, $1)=
_LT_AC_TAGVAR(hardcode_libdir_separator, $1)=
_LT_AC_TAGVAR(hardcode_minus_L, $1)=no
+_LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=unsupported
_LT_AC_TAGVAR(hardcode_automatic, $1)=no
_LT_AC_TAGVAR(module_cmds, $1)=
_LT_AC_TAGVAR(module_expsym_cmds, $1)=
@@ -2694,7 +2764,7 @@ _LT_AC_TAGVAR(postdeps, $1)=
_LT_AC_TAGVAR(compiler_lib_search_path, $1)=
# Source file extension for C++ test sources.
-ac_ext=cc
+ac_ext=cpp
# Object file extension for compiled C++ test sources.
objext=o
@@ -2704,7 +2774,7 @@ _LT_AC_TAGVAR(objext, $1)=$objext
lt_simple_compile_test_code="int some_variable = 0;\n"
# Code to be used in simple link tests
-lt_simple_link_test_code='int main(int, char *[]) { return(0); }\n'
+lt_simple_link_test_code='int main(int, char *[[]]) { return(0); }\n'
# ltmain only uses $CC for tagged configurations so make sure $CC is set.
_LT_AC_SYS_COMPILER
@@ -2723,12 +2793,12 @@ lt_save_path_LD=$lt_cv_path_LD
if test -n "${lt_cv_prog_gnu_ldcxx+set}"; then
lt_cv_prog_gnu_ld=$lt_cv_prog_gnu_ldcxx
else
- unset lt_cv_prog_gnu_ld
+ $as_unset lt_cv_prog_gnu_ld
fi
if test -n "${lt_cv_path_LDCXX+set}"; then
lt_cv_path_LD=$lt_cv_path_LDCXX
else
- unset lt_cv_path_LD
+ $as_unset lt_cv_path_LD
fi
test -z "${LDCXX+set}" || LD=$LDCXX
CC=${CXX-"c++"}
@@ -2823,6 +2893,7 @@ case $host_os in
;;
esac
done
+ ;;
esac
exp_sym_flag='-bexport'
@@ -2860,6 +2931,7 @@ case $host_os in
_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
_LT_AC_TAGVAR(hardcode_libdir_separator, $1)=
fi
+ ;;
esac
shared_flag='-shared'
if test "$aix_use_runtimelinking" = yes; then
@@ -2891,12 +2963,12 @@ case $host_os in
_LT_AC_SYS_LIBPATH_AIX
_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-blibpath:$libdir:'"$aix_libpath"
- _LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC"' -o $output_objdir/$soname $libobjs $deplibs $compiler_flags `if test "x${allow_undefined_flag}" != "x"; then echo "${wl}${allow_undefined_flag}"; else :; fi` '"\${wl}$no_entry_flag \${wl}$exp_sym_flag:\$export_symbols $shared_flag"
+ _LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC"' -o $output_objdir/$soname $libobjs $deplibs '"\${wl}$no_entry_flag"' $compiler_flags `if test "x${allow_undefined_flag}" != "x"; then echo "${wl}${allow_undefined_flag}"; else :; fi` '"\${wl}$exp_sym_flag:\$export_symbols $shared_flag"
else
if test "$host_cpu" = ia64; then
_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-R $libdir:/usr/lib:/lib'
_LT_AC_TAGVAR(allow_undefined_flag, $1)="-z nodefs"
- _LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs $compiler_flags ${wl}${allow_undefined_flag} '"\${wl}$no_entry_flag \${wl}$exp_sym_flag:\$export_symbols"
+ _LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs '"\${wl}$no_entry_flag"' $compiler_flags ${wl}${allow_undefined_flag} '"\${wl}$exp_sym_flag:\$export_symbols"
else
# Determine the default libpath from the value encoded in an empty executable.
_LT_AC_SYS_LIBPATH_AIX
@@ -2905,16 +2977,26 @@ case $host_os in
# -berok will link without error, but may produce a broken library.
_LT_AC_TAGVAR(no_undefined_flag, $1)=' ${wl}-bernotok'
_LT_AC_TAGVAR(allow_undefined_flag, $1)=' ${wl}-berok'
- # -bexpall does not export symbols beginning with underscore (_)
- _LT_AC_TAGVAR(always_export_symbols, $1)=yes
# Exported symbols can be pulled into shared objects from archives
- _LT_AC_TAGVAR(whole_archive_flag_spec, $1)=' '
+ _LT_AC_TAGVAR(whole_archive_flag_spec, $1)='$convenience'
_LT_AC_TAGVAR(archive_cmds_need_lc, $1)=yes
- # This is similar to how AIX traditionally builds it's shared libraries.
- _LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs $compiler_flags ${wl}-bE:$export_symbols ${wl}-bnoentry${allow_undefined_flag}~$AR $AR_FLAGS $output_objdir/$libname$release.a $output_objdir/$soname'
+ # This is similar to how AIX traditionally builds its shared libraries.
+ _LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs ${wl}-bnoentry $compiler_flags ${wl}-bE:$export_symbols${allow_undefined_flag}~$AR $AR_FLAGS $output_objdir/$libname$release.a $output_objdir/$soname'
fi
fi
;;
+
+ beos*)
+ if $LD --help 2>&1 | grep ': supported targets:.* elf' > /dev/null; then
+ _LT_AC_TAGVAR(allow_undefined_flag, $1)=unsupported
+ # Joseph Beckenbach <jrb3@best.com> says some releases of gcc
+ # support --undefined. This deserves some investigation. FIXME
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -nostart $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib'
+ else
+ _LT_AC_TAGVAR(ld_shlibs, $1)=no
+ fi
+ ;;
+
chorus*)
case $cc_basename in
*)
@@ -2924,7 +3006,6 @@ case $host_os in
esac
;;
-
cygwin* | mingw* | pw32*)
# _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1) is actually meaningless,
# as there is no search path for DLLs.
@@ -2934,7 +3015,7 @@ case $host_os in
_LT_AC_TAGVAR(enable_shared_with_static_runtimes, $1)=yes
if $LD --help 2>&1 | grep 'auto-import' > /dev/null; then
- _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -o $output_objdir/$soname ${wl}--image-base=0x10000000 ${wl}--out-implib,$lib'
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -o $output_objdir/$soname ${wl}--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib'
# If the export-symbols file already is a .def file (1st line
# is EXPORTS), use it as is; otherwise, prepend...
_LT_AC_TAGVAR(archive_expsym_cmds, $1)='if test "x`$SED 1q $export_symbols`" = xEXPORTS; then
@@ -2943,13 +3024,13 @@ case $host_os in
echo EXPORTS > $output_objdir/$soname.def;
cat $export_symbols >> $output_objdir/$soname.def;
fi~
- $CC -shared -nostdlib $output_objdir/$soname.def $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -o $output_objdir/$soname ${wl}--image-base=0x10000000 ${wl}--out-implib,$lib'
+ $CC -shared -nostdlib $output_objdir/$soname.def $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -o $output_objdir/$soname ${wl}--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib'
else
_LT_AC_TAGVAR(ld_shlibs, $1)=no
fi
;;
darwin* | rhapsody*)
- case "$host_os" in
+ case $host_os in
rhapsody* | darwin1.[[012]])
_LT_AC_TAGVAR(allow_undefined_flag, $1)='${wl}-undefined ${wl}suppress'
;;
@@ -2987,7 +3068,7 @@ case $host_os in
_LT_AC_TAGVAR(archive_cmds, $1)='$CC -r -keep_private_externs -nostdlib -o ${lib}-master.o $libobjs~$CC -dynamiclib $allow_undefined_flag -o $lib ${lib}-master.o $deplibs $compiler_flags -install_name $rpath/$soname $verstring'
fi
_LT_AC_TAGVAR(module_cmds, $1)='$CC $allow_undefined_flag -o $lib -bundle $libobjs $deplibs$compiler_flags'
- # Don't fix this by using the ld -exported_symbols_list flag, it doesn't exist in older darwin ld's
+ # Don't fix this by using the ld -exported_symbols_list flag, it doesn't exist in older darwin lds
if test "X$lt_int_apple_cc_single_mod" = Xyes ; then
_LT_AC_TAGVAR(archive_expsym_cmds, $1)='sed -e "s,#.*,," -e "s,^[ ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC -dynamiclib -single_module $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags -install_name $rpath/$soname $verstring~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
else
@@ -3000,7 +3081,7 @@ case $host_os in
output_verbose_link_cmd='echo'
_LT_AC_TAGVAR(archive_cmds, $1)='$CC -qmkshrobj ${wl}-single_module $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags ${wl}-install_name ${wl}`echo $rpath/$soname` $verstring'
_LT_AC_TAGVAR(module_cmds, $1)='$CC $allow_undefined_flag -o $lib -bundle $libobjs $deplibs$compiler_flags'
- # Don't fix this by using the ld -exported_symbols_list flag, it doesn't exist in older darwin ld's
+ # Don't fix this by using the ld -exported_symbols_list flag, it doesn't exist in older darwin lds
_LT_AC_TAGVAR(archive_expsym_cmds, $1)='sed -e "s,#.*,," -e "s,^[ ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC -qmkshrobj ${wl}-single_module $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags ${wl}-install_name ${wl}$rpath/$soname $verstring~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
_LT_AC_TAGVAR(module_expsym_cmds, $1)='sed -e "s,#.*,," -e "s,^[ ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC $allow_undefined_flag -o $lib -bundle $libobjs $deplibs$compiler_flags~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
;;
@@ -3080,33 +3161,22 @@ case $host_os in
;;
hpux10*|hpux11*)
if test $with_gnu_ld = no; then
- case "$host_cpu" in
- hppa*64*)
- _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
+ _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
+ _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
+
+ case $host_cpu in
+ hppa*64*|ia64*)
_LT_AC_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir'
- _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
- ;;
- ia64*)
- _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
;;
*)
- _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
- _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
;;
esac
fi
- case "$host_cpu" in
- hppa*64*)
- _LT_AC_TAGVAR(hardcode_direct, $1)=no
- _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
- ;;
- ia64*)
+ case $host_cpu in
+ hppa*64*|ia64*)
_LT_AC_TAGVAR(hardcode_direct, $1)=no
_LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
- _LT_AC_TAGVAR(hardcode_minus_L, $1)=yes # Not in the search PATH,
- # but as the default
- # location of the library.
;;
*)
_LT_AC_TAGVAR(hardcode_direct, $1)=yes
@@ -3122,9 +3192,12 @@ case $host_os in
_LT_AC_TAGVAR(ld_shlibs, $1)=no
;;
aCC*)
- case "$host_cpu" in
- hppa*64*|ia64*)
- _LT_AC_TAGVAR(archive_cmds, $1)='$LD -b +h $soname -o $lib $linker_flags $libobjs $deplibs'
+ case $host_cpu in
+ hppa*64*)
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
+ ;;
+ ia64*)
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname ${wl}+nodefaultrpath -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
;;
*)
_LT_AC_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
@@ -3143,9 +3216,12 @@ case $host_os in
*)
if test "$GXX" = yes; then
if test $with_gnu_ld = no; then
- case "$host_cpu" in
- ia64*|hppa*64*)
- _LT_AC_TAGVAR(archive_cmds, $1)='$LD -b +h $soname -o $lib $linker_flags $libobjs $deplibs'
+ case $host_cpu in
+ hppa*64*)
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib -fPIC ${wl}+h ${wl}$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
+ ;;
+ ia64*)
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib -fPIC ${wl}+h ${wl}$soname ${wl}+nodefaultrpath -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
;;
*)
_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib -fPIC ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
@@ -3159,6 +3235,20 @@ case $host_os in
;;
esac
;;
+ interix3*)
+ _LT_AC_TAGVAR(hardcode_direct, $1)=no
+ _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
+ _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
+ _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
+ # Hack: On Interix 3.x, we cannot compile PIC because of a broken gcc.
+ # Instead, shared libraries are loaded at an image base (0x10000000 by
+ # default) and relocated if they conflict, which is a slow very memory
+ # consuming and fragmenting process. To avoid this, we pick a random,
+ # 256 KiB-aligned image base between 0x50000000 and 0x6FFC0000 at link
+ # time. Moving up from 0x10000000 also allows more sbrk(2) space.
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag $libobjs $deplibs $compiler_flags ${wl}-h,$soname ${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
+ _LT_AC_TAGVAR(archive_expsym_cmds, $1)='sed "s,^,_," $export_symbols >$output_objdir/$soname.expsym~$CC -shared $pic_flag $libobjs $deplibs $compiler_flags ${wl}-h,$soname ${wl}--retain-symbols-file,$output_objdir/$soname.expsym ${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
+ ;;
irix5* | irix6*)
case $cc_basename in
CC*)
@@ -3244,7 +3334,7 @@ case $host_os in
_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}--rpath ${wl}$libdir'
_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}--export-dynamic'
- _LT_AC_TAGVAR(whole_archive_flag_spec, $1)='${wl}--whole-archive,`for conv in $convenience\"\"; do test -n \"$conv\" && new_convenience=\"$new_convenience,$conv\"; done; $echo \"$new_convenience\"` ${wl}--no-whole-archive'
+ _LT_AC_TAGVAR(whole_archive_flag_spec, $1)='${wl}--whole-archive`for conv in $convenience\"\"; do test -n \"$conv\" && new_convenience=\"$new_convenience,$conv\"; done; $echo \"$new_convenience\"` ${wl}--no-whole-archive'
;;
cxx*)
# Compaq C++
@@ -3441,19 +3531,6 @@ case $host_os in
# FIXME: insert proper C++ library support
_LT_AC_TAGVAR(ld_shlibs, $1)=no
;;
- sco*)
- _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
- case $cc_basename in
- CC*)
- # FIXME: insert proper C++ library support
- _LT_AC_TAGVAR(ld_shlibs, $1)=no
- ;;
- *)
- # FIXME: insert proper C++ library support
- _LT_AC_TAGVAR(ld_shlibs, $1)=no
- ;;
- esac
- ;;
sunos4*)
case $cc_basename in
CC*)
@@ -3476,10 +3553,11 @@ case $host_os in
case $cc_basename in
CC*)
# Sun C++ 4.2, 5.x and Centerline C++
+ _LT_AC_TAGVAR(archive_cmds_need_lc,$1)=yes
_LT_AC_TAGVAR(no_undefined_flag, $1)=' -zdefs'
- _LT_AC_TAGVAR(archive_cmds, $1)='$CC -G${allow_undefined_flag} -nolib -h$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -G${allow_undefined_flag} -h$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$echo "{ global:" > $lib.exp~cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >> $lib.exp~$echo "local: *; };" >> $lib.exp~
- $CC -G${allow_undefined_flag} -nolib ${wl}-M ${wl}$lib.exp -h$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~$rm $lib.exp'
+ $CC -G${allow_undefined_flag} ${wl}-M ${wl}$lib.exp -h$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~$rm $lib.exp'
_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-R$libdir'
_LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
@@ -3499,15 +3577,7 @@ case $host_os in
esac
_LT_AC_TAGVAR(link_all_deplibs, $1)=yes
- # Commands to make compiler produce verbose output that lists
- # what "hidden" libraries, object files and flags are used when
- # linking a shared library.
- #
- # There doesn't appear to be a way to prevent this compiler from
- # explicitly linking system object files so we need to strip them
- # from the output so that they don't get included in the library
- # dependencies.
- output_verbose_link_cmd='templist=`$CC -G $CFLAGS -v conftest.$objext 2>&1 | grep "\-[[LR]]"`; list=""; for z in $templist; do case $z in conftest.$objext) list="$list $z";; *.$objext);; *) list="$list $z";;esac; done; echo $list'
+ output_verbose_link_cmd='echo'
# Archives containing C++ object files must be created using
# "CC -xar", where "CC" is the Sun C++ compiler. This is
@@ -3553,8 +3623,59 @@ case $host_os in
;;
esac
;;
- sysv5OpenUNIX8* | sysv5UnixWare7* | sysv5uw[[78]]* | unixware7*)
+ sysv4*uw2* | sysv5OpenUNIX* | sysv5UnixWare7.[[01]].[[10]]* | unixware7* | sco3.2v5.0.[[024]]*)
+ _LT_AC_TAGVAR(no_undefined_flag, $1)='${wl}-z,text'
_LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
+ _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
+ runpath_var='LD_RUN_PATH'
+
+ case $cc_basename in
+ CC*)
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -G ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
+ _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -G ${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
+ ;;
+ *)
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
+ _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared ${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
+ ;;
+ esac
+ ;;
+ sysv5* | sco3.2v5* | sco5v6*)
+ # Note: We can NOT use -z defs as we might desire, because we do not
+ # link with -lc, and that would cause any symbols used from libc to
+ # always be unresolved, which means just about no library would
+ # ever link correctly. If we're not using GNU ld we use -z text
+ # though, which does catch some bad symbols but isn't as heavy-handed
+ # as -z defs.
+ # For security reasons, it is highly recommended that you always
+ # use absolute paths for naming shared libraries, and exclude the
+ # DT_RUNPATH tag from executables and libraries. But doing so
+ # requires that you compile everything twice, which is a pain.
+ # So that behaviour is only enabled if SCOABSPATH is set to a
+ # non-empty value in the environment. Most likely only useful for
+ # creating official distributions of packages.
+ # This is a hack until libtool officially supports absolute path
+ # names for shared libraries.
+ _LT_AC_TAGVAR(no_undefined_flag, $1)='${wl}-z,text'
+ _LT_AC_TAGVAR(allow_undefined_flag, $1)='${wl}-z,nodefs'
+ _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
+ _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
+ _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='`test -z "$SCOABSPATH" && echo ${wl}-R,$libdir`'
+ _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=':'
+ _LT_AC_TAGVAR(link_all_deplibs, $1)=yes
+ _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-Bexport'
+ runpath_var='LD_RUN_PATH'
+
+ case $cc_basename in
+ CC*)
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -G ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+ _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -G ${wl}-Bexport:$export_symbols ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+ ;;
+ *)
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+ _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared ${wl}-Bexport:$export_symbols ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+ ;;
+ esac
;;
tandem*)
case $cc_basename in
@@ -3591,8 +3712,6 @@ AC_LIBTOOL_SYS_HARD_LINK_LOCKS($1)
AC_LIBTOOL_PROG_LD_SHLIBS($1)
AC_LIBTOOL_SYS_DYNAMIC_LINKER($1)
AC_LIBTOOL_PROG_LD_HARDCODE_LIBPATH($1)
-AC_LIBTOOL_SYS_LIB_STRIP
-AC_LIBTOOL_DLOPEN_SELF($1)
AC_LIBTOOL_CONFIG($1)
@@ -3610,7 +3729,7 @@ lt_cv_prog_gnu_ld=$lt_save_with_gnu_ld
])# AC_LIBTOOL_LANG_CXX_CONFIG
# AC_LIBTOOL_POSTDEP_PREDEP([TAGNAME])
-# ------------------------
+# ------------------------------------
# Figure out "hidden" library dependencies from verbose
# compiler output when linking a shared library.
# Parse the compiler output and extract the necessary
@@ -3664,7 +3783,7 @@ if AC_TRY_EVAL(ac_compile); then
# The `*' in the case matches for architectures that use `case' in
# $output_verbose_cmd can trigger glob expansion during the loop
# eval without this substitution.
- output_verbose_link_cmd="`$echo \"X$output_verbose_link_cmd\" | $Xsed -e \"$no_glob_subst\"`"
+ output_verbose_link_cmd=`$echo "X$output_verbose_link_cmd" | $Xsed -e "$no_glob_subst"`
for p in `eval $output_verbose_link_cmd`; do
case $p in
@@ -3740,13 +3859,37 @@ fi
$rm -f confest.$objext
+# PORTME: override above test on systems where it is broken
+ifelse([$1],[CXX],
+[case $host_os in
+interix3*)
+ # Interix 3.5 installs completely hosed .la files for C++, so rather than
+ # hack all around it, let's just trust "g++" to DTRT.
+ _LT_AC_TAGVAR(predep_objects,$1)=
+ _LT_AC_TAGVAR(postdep_objects,$1)=
+ _LT_AC_TAGVAR(postdeps,$1)=
+ ;;
+
+solaris*)
+ case $cc_basename in
+ CC*)
+ # Adding this requires a known-good setup of shared libraries for
+ # Sun compiler versions before 5.6, else PIC objects from an old
+ # archive will be linked into the output, leading to subtle bugs.
+ _LT_AC_TAGVAR(postdeps,$1)='-lCstd -lCrun'
+ ;;
+ esac
+ ;;
+esac
+])
+
case " $_LT_AC_TAGVAR(postdeps, $1) " in
*" -lc "*) _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no ;;
esac
])# AC_LIBTOOL_POSTDEP_PREDEP
# AC_LIBTOOL_LANG_F77_CONFIG
-# ------------------------
+# --------------------------
# Ensure that the configuration vars for the C compiler are
# suitably defined. Those variables are subsequently used by
# AC_LIBTOOL_CONFIG to write the compiler configuration to `libtool'.
@@ -3809,7 +3952,7 @@ test "$can_build_shared" = "no" && enable_shared=no
# On AIX, shared libraries and static libraries use the same namespace, and
# are all built from PIC.
-case "$host_os" in
+case $host_os in
aix3*)
test "$enable_shared" = yes && enable_static=no
if test -n "$RANLIB"; then
@@ -3830,8 +3973,6 @@ AC_MSG_CHECKING([whether to build static libraries])
test "$enable_shared" = yes || enable_static=yes
AC_MSG_RESULT([$enable_static])
-test "$_LT_AC_TAGVAR(ld_shlibs, $1)" = no && can_build_shared=no
-
_LT_AC_TAGVAR(GCC, $1)="$G77"
_LT_AC_TAGVAR(LD, $1)="$LD"
@@ -3841,8 +3982,6 @@ AC_LIBTOOL_SYS_HARD_LINK_LOCKS($1)
AC_LIBTOOL_PROG_LD_SHLIBS($1)
AC_LIBTOOL_SYS_DYNAMIC_LINKER($1)
AC_LIBTOOL_PROG_LD_HARDCODE_LIBPATH($1)
-AC_LIBTOOL_SYS_LIB_STRIP
-
AC_LIBTOOL_CONFIG($1)
@@ -3899,8 +4038,6 @@ AC_LIBTOOL_SYS_HARD_LINK_LOCKS($1)
AC_LIBTOOL_PROG_LD_SHLIBS($1)
AC_LIBTOOL_SYS_DYNAMIC_LINKER($1)
AC_LIBTOOL_PROG_LD_HARDCODE_LIBPATH($1)
-AC_LIBTOOL_SYS_LIB_STRIP
-AC_LIBTOOL_DLOPEN_SELF($1)
AC_LIBTOOL_CONFIG($1)
@@ -3910,7 +4047,7 @@ CC="$lt_save_CC"
# AC_LIBTOOL_LANG_RC_CONFIG
-# --------------------------
+# -------------------------
# Ensure that the configuration vars for the Windows resource compiler are
# suitably defined. Those variables are subsequently used by
# AC_LIBTOOL_CONFIG to write the compiler configuration to `libtool'.
@@ -3973,7 +4110,7 @@ if test -f "$ltmain"; then
# Now quote all the things that may contain metacharacters while being
# careful not to overquote the AC_SUBSTed values. We take copies of the
# variables and quote the copies for generation of the libtool script.
- for var in echo old_CC old_CFLAGS AR AR_FLAGS EGREP RANLIB LN_S LTCC NM \
+ for var in echo old_CC old_CFLAGS AR AR_FLAGS EGREP RANLIB LN_S LTCC LTCFLAGS NM \
SED SHELL STRIP \
libname_spec library_names_spec soname_spec extract_expsyms_cmds \
old_striplib striplib file_magic_cmd finish_cmds finish_eval \
@@ -4142,6 +4279,9 @@ AR_FLAGS=$lt_AR_FLAGS
# A C compiler.
LTCC=$lt_LTCC
+# LTCC compiler flags.
+LTCFLAGS=$lt_LTCFLAGS
+
# A language-specific compiler.
CC=$lt_[]_LT_AC_TAGVAR(compiler, $1)
@@ -4515,9 +4655,18 @@ irix* | nonstopux*)
osf*)
symcode='[[BCDEGQRST]]'
;;
-solaris* | sysv5*)
+solaris*)
symcode='[[BDRT]]'
;;
+sco3.2v5*)
+ symcode='[[DT]]'
+ ;;
+sysv4.2uw2*)
+ symcode='[[DT]]'
+ ;;
+sysv5* | sco5v6* | unixware* | OpenUNIX*)
+ symcode='[[ABDT]]'
+ ;;
sysv4)
symcode='[[DFNSTU]]'
;;
@@ -4700,6 +4849,10 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
# DJGPP does not support shared libraries at all
_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)=
;;
+ interix3*)
+ # Interix 3.x gcc -fpic/-fPIC options generate broken code.
+ # Instead, we relocate shared libraries at runtime.
+ ;;
sysv4*MP*)
if test -d /usr/nec; then
_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)=-Kconform_pic
@@ -4708,7 +4861,7 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
hpux*)
# PIC is the default for IA64 HP-UX and 64-bit HP-UX, but
# not for PA HP-UX.
- case "$host_cpu" in
+ case $host_cpu in
hppa*64*|ia64*)
;;
*)
@@ -4769,15 +4922,15 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
case $cc_basename in
CC*)
_LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
- _LT_AC_TAGVAR(lt_prog_compiler_static, $1)="${ac_cv_prog_cc_wl}-a ${ac_cv_prog_cc_wl}archive"
+ _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='${wl}-a ${wl}archive'
if test "$host_cpu" != ia64; then
_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='+Z'
fi
;;
aCC*)
_LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
- _LT_AC_TAGVAR(lt_prog_compiler_static, $1)="${ac_cv_prog_cc_wl}-a ${ac_cv_prog_cc_wl}archive"
- case "$host_cpu" in
+ _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='${wl}-a ${wl}archive'
+ case $host_cpu in
hppa*64*|ia64*)
# +Z the default
;;
@@ -4790,6 +4943,10 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
;;
esac
;;
+ interix*)
+ # This is c89, which is MS Visual C++ (no shared libs)
+ # Anyone wants to do a port?
+ ;;
irix5* | irix6* | nonstopux*)
case $cc_basename in
CC*)
@@ -4818,7 +4975,7 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
# Portland Group C++ compiler.
_LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-fpic'
- _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-static'
+ _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
;;
cxx*)
# Compaq C++
@@ -4869,15 +5026,6 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
;;
psos*)
;;
- sco*)
- case $cc_basename in
- CC*)
- _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC'
- ;;
- *)
- ;;
- esac
- ;;
solaris*)
case $cc_basename in
CC*)
@@ -4919,7 +5067,14 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
;;
esac
;;
- unixware*)
+ sysv5* | unixware* | sco3.2v5* | sco5v6* | OpenUNIX*)
+ case $cc_basename in
+ CC*)
+ _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
+ _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
+ _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
+ ;;
+ esac
;;
vxworks*)
;;
@@ -4966,6 +5121,11 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-fno-common'
;;
+ interix3*)
+ # Interix 3.x gcc -fpic/-fPIC options generate broken code.
+ # Instead, we relocate shared libraries at runtime.
+ ;;
+
msdosdjgpp*)
# Just because we use GCC doesn't mean we suddenly get shared libraries
# on systems that don't support them.
@@ -4982,7 +5142,7 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
hpux*)
# PIC is the default for IA64 HP-UX and 64-bit HP-UX, but
# not for PA HP-UX.
- case "$host_cpu" in
+ case $host_cpu in
hppa*64*|ia64*)
# +Z the default
;;
@@ -5029,7 +5189,7 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
_LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
# PIC is the default for IA64 HP-UX and 64-bit HP-UX, but
# not for PA HP-UX.
- case "$host_cpu" in
+ case $host_cpu in
hppa*64*|ia64*)
# +Z the default
;;
@@ -5059,12 +5219,12 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
_LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-static'
;;
- pgcc* | pgf77* | pgf90*)
+ pgcc* | pgf77* | pgf90* | pgf95*)
# Portland Group compilers (*not* the Pentium gcc compiler,
# which looks to be a dead project)
_LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-fpic'
- _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-static'
+ _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
;;
ccc*)
_LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
@@ -5080,11 +5240,6 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
_LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-non_shared'
;;
- sco3.2v5*)
- _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-Kpic'
- _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-dn'
- ;;
-
solaris*)
_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
_LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
@@ -5102,7 +5257,7 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
_LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
;;
- sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
+ sysv4 | sysv4.2uw2* | sysv4.3*)
_LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
_LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
@@ -5115,6 +5270,12 @@ AC_MSG_CHECKING([for $compiler option to produce PIC])
fi
;;
+ sysv5* | unixware* | sco3.2v5* | sco5v6* | OpenUNIX*)
+ _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
+ _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-KPIC'
+ _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='-Bstatic'
+ ;;
+
unicos*)
_LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
_LT_AC_TAGVAR(lt_prog_compiler_can_build_shared, $1)=no
@@ -5147,7 +5308,7 @@ if test -n "$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)"; then
[_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)=
_LT_AC_TAGVAR(lt_prog_compiler_can_build_shared, $1)=no])
fi
-case "$host_os" in
+case $host_os in
# For platforms which do not support PIC, -DPIC is meaningless:
*djgpp*)
_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)=
@@ -5156,6 +5317,16 @@ case "$host_os" in
_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)="$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)ifelse([$1],[],[ -DPIC],[ifelse([$1],[CXX],[ -DPIC],[])])"
;;
esac
+
+#
+# Check to make sure the static flag actually works.
+#
+wl=$_LT_AC_TAGVAR(lt_prog_compiler_wl, $1) eval lt_tmp_static_flag=\"$_LT_AC_TAGVAR(lt_prog_compiler_static, $1)\"
+AC_LIBTOOL_LINKER_OPTION([if $compiler static flag $lt_tmp_static_flag works],
+ _LT_AC_TAGVAR(lt_prog_compiler_static_works, $1),
+ $lt_tmp_static_flag,
+ [],
+ [_LT_AC_TAGVAR(lt_prog_compiler_static, $1)=])
])
@@ -5234,6 +5405,10 @@ ifelse([$1],[CXX],[
with_gnu_ld=no
fi
;;
+ interix*)
+ # we just hope/assume this is gcc and not c89 (= MSVC++)
+ with_gnu_ld=yes
+ ;;
openbsd*)
with_gnu_ld=no
;;
@@ -5243,7 +5418,7 @@ ifelse([$1],[CXX],[
if test "$with_gnu_ld" = yes; then
# If archive_cmds runs LD, not CC, wlarc should be empty
wlarc='${wl}'
-
+
# Set some defaults for GNU ld with shared library support. These
# are reset later if shared libraries are not supported. Putting them
# here allows them to be overridden if necessary.
@@ -5264,7 +5439,7 @@ ifelse([$1],[CXX],[
*\ 2.11.*) ;; # other 2.11 versions
*) supports_anon_versioning=yes ;;
esac
-
+
# See if GNU ld supports shared libraries.
case $host_os in
aix3* | aix4* | aix5*)
@@ -5318,7 +5493,7 @@ EOF
_LT_AC_TAGVAR(export_symbols_cmds, $1)='$NM $libobjs $convenience | $global_symbol_pipe | $SED -e '\''/^[[BCDGRS]] /s/.* \([[^ ]]*\)/\1 DATA/'\'' | $SED -e '\''/^[[AITW]] /s/.* //'\'' | sort | uniq > $export_symbols'
if $LD --help 2>&1 | grep 'auto-import' > /dev/null; then
- _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags -o $output_objdir/$soname ${wl}--image-base=0x10000000 ${wl}--out-implib,$lib'
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags -o $output_objdir/$soname ${wl}--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib'
# If the export-symbols file already is a .def file (1st line
# is EXPORTS), use it as is; otherwise, prepend...
_LT_AC_TAGVAR(archive_expsym_cmds, $1)='if test "x`$SED 1q $export_symbols`" = xEXPORTS; then
@@ -5327,22 +5502,37 @@ EOF
echo EXPORTS > $output_objdir/$soname.def;
cat $export_symbols >> $output_objdir/$soname.def;
fi~
- $CC -shared $output_objdir/$soname.def $libobjs $deplibs $compiler_flags -o $output_objdir/$soname ${wl}--image-base=0x10000000 ${wl}--out-implib,$lib'
+ $CC -shared $output_objdir/$soname.def $libobjs $deplibs $compiler_flags -o $output_objdir/$soname ${wl}--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib'
else
_LT_AC_TAGVAR(ld_shlibs, $1)=no
fi
;;
+ interix3*)
+ _LT_AC_TAGVAR(hardcode_direct, $1)=no
+ _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
+ _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath,$libdir'
+ _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
+ # Hack: On Interix 3.x, we cannot compile PIC because of a broken gcc.
+ # Instead, shared libraries are loaded at an image base (0x10000000 by
+ # default) and relocated if they conflict, which is a slow very memory
+ # consuming and fragmenting process. To avoid this, we pick a random,
+ # 256 KiB-aligned image base between 0x50000000 and 0x6FFC0000 at link
+ # time. Moving up from 0x10000000 also allows more sbrk(2) space.
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag $libobjs $deplibs $compiler_flags ${wl}-h,$soname ${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
+ _LT_AC_TAGVAR(archive_expsym_cmds, $1)='sed "s,^,_," $export_symbols >$output_objdir/$soname.expsym~$CC -shared $pic_flag $libobjs $deplibs $compiler_flags ${wl}-h,$soname ${wl}--retain-symbols-file,$output_objdir/$soname.expsym ${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
+ ;;
+
linux*)
if $LD --help 2>&1 | grep ': supported targets:.* elf' > /dev/null; then
tmp_addflag=
case $cc_basename,$host_cpu in
pgcc*) # Portland Group C compiler
- _LT_AC_TAGVAR(whole_archive_flag_spec, $1)='${wl}--whole-archive,`for conv in $convenience\"\"; do test -n \"$conv\" && new_convenience=\"$new_convenience,$conv\"; done; $echo \"$new_convenience\"` ${wl}--no-whole-archive'
+ _LT_AC_TAGVAR(whole_archive_flag_spec, $1)='${wl}--whole-archive`for conv in $convenience\"\"; do test -n \"$conv\" && new_convenience=\"$new_convenience,$conv\"; done; $echo \"$new_convenience\"` ${wl}--no-whole-archive'
tmp_addflag=' $pic_flag'
;;
- pgf77* | pgf90* ) # Portland Group f77 and f90 compilers
- _LT_AC_TAGVAR(whole_archive_flag_spec, $1)='${wl}--whole-archive,`for conv in $convenience\"\"; do test -n \"$conv\" && new_convenience=\"$new_convenience,$conv\"; done; $echo \"$new_convenience\"` ${wl}--no-whole-archive'
+ pgf77* | pgf90* | pgf95*) # Portland Group f77 and f90 compilers
+ _LT_AC_TAGVAR(whole_archive_flag_spec, $1)='${wl}--whole-archive`for conv in $convenience\"\"; do test -n \"$conv\" && new_convenience=\"$new_convenience,$conv\"; done; $echo \"$new_convenience\"` ${wl}--no-whole-archive'
tmp_addflag=' $pic_flag -Mnomain' ;;
ecc*,ia64* | icc*,ia64*) # Intel C compiler on ia64
tmp_addflag=' -i_dynamic' ;;
@@ -5374,7 +5564,7 @@ EOF
fi
;;
- solaris* | sysv5*)
+ solaris*)
if $LD -v 2>&1 | grep 'BFD 2\.8' > /dev/null; then
_LT_AC_TAGVAR(ld_shlibs, $1)=no
cat <<EOF 1>&2
@@ -5395,6 +5585,33 @@ EOF
fi
;;
+ sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX*)
+ case `$LD -v 2>&1` in
+ *\ [[01]].* | *\ 2.[[0-9]].* | *\ 2.1[[0-5]].*)
+ _LT_AC_TAGVAR(ld_shlibs, $1)=no
+ cat <<_LT_EOF 1>&2
+
+*** Warning: Releases of the GNU linker prior to 2.16.91.0.3 can not
+*** reliably create shared libraries on SCO systems. Therefore, libtool
+*** is disabling shared libraries support. We urge you to upgrade GNU
+*** binutils to release 2.16.91.0.3 or newer. Another option is to modify
+*** your PATH or compiler configuration so that the native linker is
+*** used, and then restart.
+
+_LT_EOF
+ ;;
+ *)
+ if $LD --help 2>&1 | grep ': supported targets:.* elf' > /dev/null; then
+ _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='`test -z "$SCOABSPATH" && echo ${wl}-rpath,$libdir`'
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib'
+ _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname,\${SCOABSPATH:+${install_libdir}/}$soname,-retain-symbols-file,$export_symbols -o $lib'
+ else
+ _LT_AC_TAGVAR(ld_shlibs, $1)=no
+ fi
+ ;;
+ esac
+ ;;
+
sunos4*)
_LT_AC_TAGVAR(archive_cmds, $1)='$LD -assert pure-text -Bshareable -o $lib $libobjs $deplibs $linker_flags'
wlarc=
@@ -5428,7 +5645,7 @@ EOF
# Note: this linker hardcodes the directories in LIBPATH if there
# are no directories specified by -L.
_LT_AC_TAGVAR(hardcode_minus_L, $1)=yes
- if test "$GCC" = yes && test -z "$link_static_flag"; then
+ if test "$GCC" = yes && test -z "$lt_prog_compiler_static"; then
# Neither direct hardcoding nor static linking is supported with a
# broken collect2.
_LT_AC_TAGVAR(hardcode_direct, $1)=unsupported
@@ -5462,6 +5679,7 @@ EOF
break
fi
done
+ ;;
esac
exp_sym_flag='-bexport'
@@ -5499,6 +5717,7 @@ EOF
_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
_LT_AC_TAGVAR(hardcode_libdir_separator, $1)=
fi
+ ;;
esac
shared_flag='-shared'
if test "$aix_use_runtimelinking" = yes; then
@@ -5511,11 +5730,11 @@ EOF
# chokes on -Wl,-G. The following line is correct:
shared_flag='-G'
else
- if test "$aix_use_runtimelinking" = yes; then
+ if test "$aix_use_runtimelinking" = yes; then
shared_flag='${wl}-G'
else
shared_flag='${wl}-bM:SRE'
- fi
+ fi
fi
fi
@@ -5529,12 +5748,12 @@ EOF
# Determine the default libpath from the value encoded in an empty executable.
_LT_AC_SYS_LIBPATH_AIX
_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-blibpath:$libdir:'"$aix_libpath"
- _LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC"' -o $output_objdir/$soname $libobjs $deplibs $compiler_flags `if test "x${allow_undefined_flag}" != "x"; then echo "${wl}${allow_undefined_flag}"; else :; fi` '"\${wl}$no_entry_flag \${wl}$exp_sym_flag:\$export_symbols $shared_flag"
+ _LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC"' -o $output_objdir/$soname $libobjs $deplibs '"\${wl}$no_entry_flag"' $compiler_flags `if test "x${allow_undefined_flag}" != "x"; then echo "${wl}${allow_undefined_flag}"; else :; fi` '"\${wl}$exp_sym_flag:\$export_symbols $shared_flag"
else
if test "$host_cpu" = ia64; then
_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-R $libdir:/usr/lib:/lib'
_LT_AC_TAGVAR(allow_undefined_flag, $1)="-z nodefs"
- _LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs $compiler_flags ${wl}${allow_undefined_flag} '"\${wl}$no_entry_flag \${wl}$exp_sym_flag:\$export_symbols"
+ _LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs '"\${wl}$no_entry_flag"' $compiler_flags ${wl}${allow_undefined_flag} '"\${wl}$exp_sym_flag:\$export_symbols"
else
# Determine the default libpath from the value encoded in an empty executable.
_LT_AC_SYS_LIBPATH_AIX
@@ -5543,13 +5762,11 @@ EOF
# -berok will link without error, but may produce a broken library.
_LT_AC_TAGVAR(no_undefined_flag, $1)=' ${wl}-bernotok'
_LT_AC_TAGVAR(allow_undefined_flag, $1)=' ${wl}-berok'
- # -bexpall does not export symbols beginning with underscore (_)
- _LT_AC_TAGVAR(always_export_symbols, $1)=yes
# Exported symbols can be pulled into shared objects from archives
- _LT_AC_TAGVAR(whole_archive_flag_spec, $1)=' '
+ _LT_AC_TAGVAR(whole_archive_flag_spec, $1)='$convenience'
_LT_AC_TAGVAR(archive_cmds_need_lc, $1)=yes
- # This is similar to how AIX traditionally builds it's shared libraries.
- _LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs $compiler_flags ${wl}-bE:$export_symbols ${wl}-bnoentry${allow_undefined_flag}~$AR $AR_FLAGS $output_objdir/$libname$release.a $output_objdir/$soname'
+ # This is similar to how AIX traditionally builds its shared libraries.
+ _LT_AC_TAGVAR(archive_expsym_cmds, $1)="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs ${wl}-bnoentry $compiler_flags ${wl}-bE:$export_symbols${allow_undefined_flag}~$AR $AR_FLAGS $output_objdir/$libname$release.a $output_objdir/$soname'
fi
fi
;;
@@ -5588,7 +5805,7 @@ EOF
;;
darwin* | rhapsody*)
- case "$host_os" in
+ case $host_os in
rhapsody* | darwin1.[[012]])
_LT_AC_TAGVAR(allow_undefined_flag, $1)='${wl}-undefined ${wl}suppress'
;;
@@ -5617,7 +5834,7 @@ EOF
output_verbose_link_cmd='echo'
_LT_AC_TAGVAR(archive_cmds, $1)='$CC -dynamiclib $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags -install_name $rpath/$soname $verstring'
_LT_AC_TAGVAR(module_cmds, $1)='$CC $allow_undefined_flag -o $lib -bundle $libobjs $deplibs$compiler_flags'
- # Don't fix this by using the ld -exported_symbols_list flag, it doesn't exist in older darwin ld's
+ # Don't fix this by using the ld -exported_symbols_list flag, it doesn't exist in older darwin lds
_LT_AC_TAGVAR(archive_expsym_cmds, $1)='sed -e "s,#.*,," -e "s,^[ ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC -dynamiclib $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags -install_name $rpath/$soname $verstring~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
_LT_AC_TAGVAR(module_expsym_cmds, $1)='sed -e "s,#.*,," -e "s,^[ ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC $allow_undefined_flag -o $lib -bundle $libobjs $deplibs$compiler_flags~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
else
@@ -5626,7 +5843,7 @@ EOF
output_verbose_link_cmd='echo'
_LT_AC_TAGVAR(archive_cmds, $1)='$CC -qmkshrobj $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags ${wl}-install_name ${wl}`echo $rpath/$soname` $verstring'
_LT_AC_TAGVAR(module_cmds, $1)='$CC $allow_undefined_flag -o $lib -bundle $libobjs $deplibs$compiler_flags'
- # Don't fix this by using the ld -exported_symbols_list flag, it doesn't exist in older darwin ld's
+ # Don't fix this by using the ld -exported_symbols_list flag, it doesn't exist in older darwin lds
_LT_AC_TAGVAR(archive_expsym_cmds, $1)='sed -e "s,#.*,," -e "s,^[ ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC -qmkshrobj $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags ${wl}-install_name ${wl}$rpath/$soname $verstring~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
_LT_AC_TAGVAR(module_expsym_cmds, $1)='sed -e "s,#.*,," -e "s,^[ ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC $allow_undefined_flag -o $lib -bundle $libobjs $deplibs$compiler_flags~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
;;
@@ -5690,47 +5907,62 @@ EOF
_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
;;
- hpux10* | hpux11*)
+ hpux10*)
if test "$GCC" = yes -a "$with_gnu_ld" = no; then
- case "$host_cpu" in
- hppa*64*|ia64*)
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
+ else
+ _LT_AC_TAGVAR(archive_cmds, $1)='$LD -b +h $soname +b $install_libdir -o $lib $libobjs $deplibs $linker_flags'
+ fi
+ if test "$with_gnu_ld" = no; then
+ _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
+ _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
+
+ _LT_AC_TAGVAR(hardcode_direct, $1)=yes
+ _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
+
+ # hardcode_minus_L: Not really in the search PATH,
+ # but as the default location of the library.
+ _LT_AC_TAGVAR(hardcode_minus_L, $1)=yes
+ fi
+ ;;
+
+ hpux11*)
+ if test "$GCC" = yes -a "$with_gnu_ld" = no; then
+ case $host_cpu in
+ hppa*64*)
_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}+h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
;;
+ ia64*)
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}+h ${wl}$soname ${wl}+nodefaultrpath -o $lib $libobjs $deplibs $compiler_flags'
+ ;;
*)
_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
;;
esac
else
- case "$host_cpu" in
- hppa*64*|ia64*)
- _LT_AC_TAGVAR(archive_cmds, $1)='$LD -b +h $soname -o $lib $libobjs $deplibs $linker_flags'
+ case $host_cpu in
+ hppa*64*)
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
+ ;;
+ ia64*)
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname ${wl}+nodefaultrpath -o $lib $libobjs $deplibs $compiler_flags'
;;
*)
- _LT_AC_TAGVAR(archive_cmds, $1)='$LD -b +h $soname +b $install_libdir -o $lib $libobjs $deplibs $linker_flags'
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
;;
esac
fi
if test "$with_gnu_ld" = no; then
- case "$host_cpu" in
- hppa*64*)
- _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
+ _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
+ _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
+
+ case $host_cpu in
+ hppa*64*|ia64*)
_LT_AC_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir'
- _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
_LT_AC_TAGVAR(hardcode_direct, $1)=no
_LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
;;
- ia64*)
- _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
- _LT_AC_TAGVAR(hardcode_direct, $1)=no
- _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
-
- # hardcode_minus_L: Not really in the search PATH,
- # but as the default location of the library.
- _LT_AC_TAGVAR(hardcode_minus_L, $1)=yes
- ;;
*)
- _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
- _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
_LT_AC_TAGVAR(hardcode_direct, $1)=yes
_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
@@ -5832,14 +6064,6 @@ EOF
_LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
;;
- sco3.2v5*)
- _LT_AC_TAGVAR(archive_cmds, $1)='$LD -G -h $soname -o $lib $libobjs $deplibs $linker_flags'
- _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
- _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-Bexport'
- runpath_var=LD_RUN_PATH
- hardcode_runpath_var=yes
- ;;
-
solaris*)
_LT_AC_TAGVAR(no_undefined_flag, $1)=' -z text'
if test "$GCC" = yes; then
@@ -5925,36 +6149,45 @@ EOF
fi
;;
- sysv4.2uw2*)
- _LT_AC_TAGVAR(archive_cmds, $1)='$LD -G -o $lib $libobjs $deplibs $linker_flags'
- _LT_AC_TAGVAR(hardcode_direct, $1)=yes
- _LT_AC_TAGVAR(hardcode_minus_L, $1)=no
+ sysv4*uw2* | sysv5OpenUNIX* | sysv5UnixWare7.[[01]].[[10]]* | unixware7*)
+ _LT_AC_TAGVAR(no_undefined_flag, $1)='${wl}-z,text'
+ _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
_LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
- hardcode_runpath_var=yes
- runpath_var=LD_RUN_PATH
- ;;
+ runpath_var='LD_RUN_PATH'
- sysv5OpenUNIX8* | sysv5UnixWare7* | sysv5uw[[78]]* | unixware7*)
- _LT_AC_TAGVAR(no_undefined_flag, $1)='${wl}-z ${wl}text'
if test "$GCC" = yes; then
- _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}-h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
+ _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared ${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
else
- _LT_AC_TAGVAR(archive_cmds, $1)='$CC -G ${wl}-h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -G ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
+ _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -G ${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
fi
- runpath_var='LD_RUN_PATH'
- _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
;;
- sysv5*)
- _LT_AC_TAGVAR(no_undefined_flag, $1)=' -z text'
- # $CC -shared without GNU ld will not create a library from C++
- # object files and a static libstdc++, better avoid it by now
- _LT_AC_TAGVAR(archive_cmds, $1)='$LD -G${allow_undefined_flag} -h $soname -o $lib $libobjs $deplibs $linker_flags'
- _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$echo "{ global:" > $lib.exp~cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >> $lib.exp~$echo "local: *; };" >> $lib.exp~
- $LD -G${allow_undefined_flag} -M $lib.exp -h $soname -o $lib $libobjs $deplibs $linker_flags~$rm $lib.exp'
- _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)=
+ sysv5* | sco3.2v5* | sco5v6*)
+ # Note: We can NOT use -z defs as we might desire, because we do not
+ # link with -lc, and that would cause any symbols used from libc to
+ # always be unresolved, which means just about no library would
+ # ever link correctly. If we're not using GNU ld we use -z text
+ # though, which does catch some bad symbols but isn't as heavy-handed
+ # as -z defs.
+ _LT_AC_TAGVAR(no_undefined_flag, $1)='${wl}-z,text'
+ _LT_AC_TAGVAR(allow_undefined_flag, $1)='${wl}-z,nodefs'
+ _LT_AC_TAGVAR(archive_cmds_need_lc, $1)=no
_LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
+ _LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='`test -z "$SCOABSPATH" && echo ${wl}-R,$libdir`'
+ _LT_AC_TAGVAR(hardcode_libdir_separator, $1)=':'
+ _LT_AC_TAGVAR(link_all_deplibs, $1)=yes
+ _LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-Bexport'
runpath_var='LD_RUN_PATH'
+
+ if test "$GCC" = yes; then
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+ _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared ${wl}-Bexport:$export_symbols ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+ else
+ _LT_AC_TAGVAR(archive_cmds, $1)='$CC -G ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+ _LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -G ${wl}-Bexport:$export_symbols ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+ fi
;;
uts4*)
@@ -5972,11 +6205,6 @@ EOF
AC_MSG_RESULT([$_LT_AC_TAGVAR(ld_shlibs, $1)])
test "$_LT_AC_TAGVAR(ld_shlibs, $1)" = no && can_build_shared=no
-variables_saved_for_relink="PATH $shlibpath_var $runpath_var"
-if test "$GCC" = yes; then
- variables_saved_for_relink="$variables_saved_for_relink GCC_EXEC_PREFIX COMPILER_PATH LIBRARY_PATH"
-fi
-
#
# Do we need to explicitly link libc?
#
@@ -6004,6 +6232,7 @@ x|xyes)
libobjs=conftest.$ac_objext
deplibs=
wl=$_LT_AC_TAGVAR(lt_prog_compiler_wl, $1)
+ pic_flag=$_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)
compiler_flags=-v
linker_flags=-v
verstring=
diff --git a/contrib/ldapc++/configure b/contrib/ldapc++/configure
index 578b6a3f50b280a2080429c9b31f3b60c4875ea8..90e28dc1ed9882f2f24a7689972a73d7a1ce4d1e 100755
--- a/contrib/ldapc++/configure
+++ b/contrib/ldapc++/configure
@@ -285,8 +285,8 @@ if test "X${echo_test_string+set}" != Xset; then
# find a string as large as possible, as long as the shell can cope with it
for cmd in 'sed 50q "$0"' 'sed 20q "$0"' 'sed 10q "$0"' 'sed 2q "$0"' 'echo test'; do
# expected sizes: less than 2Kb, 1Kb, 512 bytes, 16 bytes, ...
- if (echo_test_string="`eval $cmd`") 2>/dev/null &&
- echo_test_string="`eval $cmd`" &&
+ if (echo_test_string=`eval $cmd`) 2>/dev/null &&
+ echo_test_string=`eval $cmd` &&
(test "X$echo_test_string" = "X$echo_test_string") 2>/dev/null
then
break
@@ -3841,7 +3841,7 @@ else
if test -f "$ac_dir/$ac_prog" || test -f "$ac_dir/$ac_prog$ac_exeext"; then
lt_cv_path_LD="$ac_dir/$ac_prog"
# Check to see if the program is GNU ld. I'd rather use --version,
- # but apparently some GNU ld's only accept -v.
+ # but apparently some variants of GNU ld only accept -v.
# Break only if it was the GNU/non-GNU ld that we prefer.
case `"$lt_cv_path_LD" -v 2>&1 </dev/null` in
*GNU* | *'with BFD'*)
@@ -3875,7 +3875,7 @@ echo $ECHO_N "checking if the linker ($LD) is GNU ld... $ECHO_C" >&6
if test "${lt_cv_prog_gnu_ld+set}" = set; then
echo $ECHO_N "(cached) $ECHO_C" >&6
else
- # I'd rather use --version here, but apparently some GNU ld's only accept -v.
+ # I'd rather use --version here, but apparently some GNU lds only accept -v.
case `$LD -v 2>&1 </dev/null` in
*GNU* | *'with BFD'*)
lt_cv_prog_gnu_ld=yes
@@ -3908,7 +3908,7 @@ reload_cmds='$LD$reload_flag -o $output$reload_objs'
case $host_os in
darwin*)
if test "$GCC" = yes; then
- reload_cmds='$CC -nostdlib ${wl}-r -o $output$reload_objs'
+ reload_cmds='$LTCC $LTCFLAGS -nostdlib ${wl}-r -o $output$reload_objs'
else
reload_cmds='$LD$reload_flag -o $output$reload_objs'
fi
@@ -3924,36 +3924,43 @@ else
# Let the user override the test.
lt_cv_path_NM="$NM"
else
- lt_save_ifs="$IFS"; IFS=$PATH_SEPARATOR
- for ac_dir in $PATH /usr/ccs/bin /usr/ucb /bin; do
- IFS="$lt_save_ifs"
- test -z "$ac_dir" && ac_dir=.
- tmp_nm="$ac_dir/${ac_tool_prefix}nm"
- if test -f "$tmp_nm" || test -f "$tmp_nm$ac_exeext" ; then
- # Check to see if the nm accepts a BSD-compat flag.
- # Adding the `sed 1q' prevents false positives on HP-UX, which says:
- # nm: unknown option "B" ignored
- # Tru64's nm complains that /dev/null is an invalid object file
- case `"$tmp_nm" -B /dev/null 2>&1 | sed '1q'` in
- */dev/null* | *'Invalid file or object type'*)
- lt_cv_path_NM="$tmp_nm -B"
- break
- ;;
- *)
- case `"$tmp_nm" -p /dev/null 2>&1 | sed '1q'` in
- */dev/null*)
- lt_cv_path_NM="$tmp_nm -p"
+ lt_nm_to_check="${ac_tool_prefix}nm"
+ if test -n "$ac_tool_prefix" && test "$build" = "$host"; then
+ lt_nm_to_check="$lt_nm_to_check nm"
+ fi
+ for lt_tmp_nm in $lt_nm_to_check; do
+ lt_save_ifs="$IFS"; IFS=$PATH_SEPARATOR
+ for ac_dir in $PATH /usr/ccs/bin/elf /usr/ccs/bin /usr/ucb /bin; do
+ IFS="$lt_save_ifs"
+ test -z "$ac_dir" && ac_dir=.
+ tmp_nm="$ac_dir/$lt_tmp_nm"
+ if test -f "$tmp_nm" || test -f "$tmp_nm$ac_exeext" ; then
+ # Check to see if the nm accepts a BSD-compat flag.
+ # Adding the `sed 1q' prevents false positives on HP-UX, which says:
+ # nm: unknown option "B" ignored
+ # Tru64's nm complains that /dev/null is an invalid object file
+ case `"$tmp_nm" -B /dev/null 2>&1 | sed '1q'` in
+ */dev/null* | *'Invalid file or object type'*)
+ lt_cv_path_NM="$tmp_nm -B"
break
;;
*)
- lt_cv_path_NM=${lt_cv_path_NM="$tmp_nm"} # keep the first match, but
- continue # so that we can try to find one that supports BSD flags
+ case `"$tmp_nm" -p /dev/null 2>&1 | sed '1q'` in
+ */dev/null*)
+ lt_cv_path_NM="$tmp_nm -p"
+ break
+ ;;
+ *)
+ lt_cv_path_NM=${lt_cv_path_NM="$tmp_nm"} # keep the first match, but
+ continue # so that we can try to find one that supports BSD flags
+ ;;
+ esac
;;
esac
- esac
- fi
+ fi
+ done
+ IFS="$lt_save_ifs"
done
- IFS="$lt_save_ifs"
test -z "$lt_cv_path_NM" && lt_cv_path_NM=nm
fi
fi
@@ -4045,7 +4052,7 @@ gnu*)
hpux10.20* | hpux11*)
lt_cv_file_magic_cmd=/usr/bin/file
- case "$host_cpu" in
+ case $host_cpu in
ia64*)
lt_cv_deplibs_check_method='file_magic (s[0-9][0-9][0-9]|ELF-[0-9][0-9]) shared object file - IA64'
lt_cv_file_magic_test_file=/usr/lib/hpux32/libc.so
@@ -4061,6 +4068,11 @@ hpux10.20* | hpux11*)
esac
;;
+interix3*)
+ # PIC code is broken on Interix 3.x, that's why |\.a not |_pic\.a here
+ lt_cv_deplibs_check_method='match_pattern /lib[^/]+(\.so|\.a)$'
+ ;;
+
irix5* | irix6* | nonstopux*)
case $LD in
*-32|*"-32 ") libmagic=32-bit;;
@@ -4106,15 +4118,11 @@ osf3* | osf4* | osf5*)
lt_cv_deplibs_check_method=pass_all
;;
-sco3.2v5*)
- lt_cv_deplibs_check_method=pass_all
- ;;
-
solaris*)
lt_cv_deplibs_check_method=pass_all
;;
-sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
+sysv4 | sysv4.3*)
case $host_vendor in
motorola)
lt_cv_deplibs_check_method='file_magic ELF [0-9][0-9]*-bit [ML]SB (shared object|dynamic lib) M[0-9][0-9]* Version [0-9]'
@@ -4135,10 +4143,13 @@ sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
siemens)
lt_cv_deplibs_check_method=pass_all
;;
+ pc)
+ lt_cv_deplibs_check_method=pass_all
+ ;;
esac
;;
-sysv5OpenUNIX8* | sysv5UnixWare7* | sysv5uw[78]* | unixware7* | sysv4*uw2*)
+sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX* | sysv4*uw2*)
lt_cv_deplibs_check_method=pass_all
;;
esac
@@ -4156,6 +4167,9 @@ test -z "$deplibs_check_method" && deplibs_check_method=unknown
# If no C compiler was specified, use CC.
LTCC=${LTCC-"$CC"}
+# If no C compiler flags were specified, use CFLAGS.
+LTCFLAGS=${LTCFLAGS-"$CFLAGS"}
+
# Allow CC to be a program name with arguments.
compiler=$CC
@@ -4191,7 +4205,7 @@ ia64-*-hpux*)
;;
*-*-irix6*)
# Find out which ABI we are using.
- echo '#line 4194 "configure"' > conftest.$ac_ext
+ echo '#line 4208 "configure"' > conftest.$ac_ext
if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
(eval $ac_compile) 2>&5
ac_status=$?
@@ -4234,7 +4248,7 @@ x86_64-*linux*|ppc*-*linux*|powerpc*-*linux*|s390*-*linux*|sparc*-*linux*)
ac_status=$?
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); }; then
- case "`/usr/bin/file conftest.o`" in
+ case `/usr/bin/file conftest.o` in
*32-bit*)
case $host in
x86_64-*linux*)
@@ -4347,6 +4361,26 @@ echo "${ECHO_T}$lt_cv_cc_needs_belf" >&6
CFLAGS="$SAVE_CFLAGS"
fi
;;
+sparc*-*solaris*)
+ # Find out which ABI we are using.
+ echo 'int i;' > conftest.$ac_ext
+ if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+ (eval $ac_compile) 2>&5
+ ac_status=$?
+ echo "$as_me:$LINENO: \$? = $ac_status" >&5
+ (exit $ac_status); }; then
+ case `/usr/bin/file conftest.o` in
+ *64-bit*)
+ case $lt_cv_prog_gnu_ld in
+ yes*) LD="${LD-ld} -m elf64_sparc" ;;
+ *) LD="${LD-ld} -64" ;;
+ esac
+ ;;
+ esac
+ fi
+ rm -rf conftest*
+ ;;
+
esac
@@ -5306,7 +5340,7 @@ fi
# Provide some information about the compiler.
-echo "$as_me:5309:" \
+echo "$as_me:5343:" \
"checking for Fortran 77 compiler version" >&5
ac_compiler=`set X $ac_compile; echo $2`
{ (eval echo "$as_me:$LINENO: \"$ac_compiler --version </dev/null >&5\"") >&5
@@ -5503,12 +5537,18 @@ else
elif test -x /usr/sbin/sysctl; then
lt_cv_sys_max_cmd_len=`/usr/sbin/sysctl -n kern.argmax`
else
- lt_cv_sys_max_cmd_len=65536 # usable default for *BSD
+ lt_cv_sys_max_cmd_len=65536 # usable default for all BSDs
fi
# And add a safety zone
lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \/ 4`
lt_cv_sys_max_cmd_len=`expr $lt_cv_sys_max_cmd_len \* 3`
;;
+
+ interix*)
+ # We know the value 262144 and hardcode it with a safety zone (like BSD)
+ lt_cv_sys_max_cmd_len=196608
+ ;;
+
osf*)
# Dr. Hans Ekkehard Plesser reports seeing a kernel panic running configure
# due to this test when exec_disable_arg_limit is 1 on Tru64. It is not
@@ -5522,6 +5562,17 @@ else
esac
fi
;;
+ sco3.2v5*)
+ lt_cv_sys_max_cmd_len=102400
+ ;;
+ sysv5* | sco5v6* | sysv4.2uw2*)
+ kargmax=`grep ARG_MAX /etc/conf/cf.d/stune 2>/dev/null`
+ if test -n "$kargmax"; then
+ lt_cv_sys_max_cmd_len=`echo $kargmax | sed 's/.*[ ]//'`
+ else
+ lt_cv_sys_max_cmd_len=32768
+ fi
+ ;;
*)
# If test is not a shell built-in, we'll probably end up computing a
# maximum length that is only half of the actual maximum length, but
@@ -5607,9 +5658,18 @@ irix* | nonstopux*)
osf*)
symcode='[BCDEGQRST]'
;;
-solaris* | sysv5*)
+solaris*)
symcode='[BDRT]'
;;
+sco3.2v5*)
+ symcode='[DT]'
+ ;;
+sysv4.2uw2*)
+ symcode='[DT]'
+ ;;
+sysv5* | sco5v6* | unixware* | OpenUNIX*)
+ symcode='[ABDT]'
+ ;;
sysv4)
symcode='[DFNSTU]'
;;
@@ -5818,7 +5878,7 @@ rm="rm -f"
default_ofile=libtool
can_build_shared=yes
-# All known linkers require a `.a' archive for static linking (except M$VC,
+# All known linkers require a `.a' archive for static linking (except MSVC,
# which needs '.lib').
libext=a
ltmain="$ac_aux_dir/ltmain.sh"
@@ -6075,6 +6135,7 @@ test -z "$AR_FLAGS" && AR_FLAGS=cru
test -z "$AS" && AS=as
test -z "$CC" && CC=cc
test -z "$LTCC" && LTCC=$CC
+test -z "$LTCFLAGS" && LTCFLAGS=$CFLAGS
test -z "$DLLTOOL" && DLLTOOL=dlltool
test -z "$LD" && LD=ld
test -z "$LN_S" && LN_S="ln -s"
@@ -6094,10 +6155,10 @@ old_postuninstall_cmds=
if test -n "$RANLIB"; then
case $host_os in
openbsd*)
- old_postinstall_cmds="\$RANLIB -t \$oldlib~$old_postinstall_cmds"
+ old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB -t \$oldlib"
;;
*)
- old_postinstall_cmds="\$RANLIB \$oldlib~$old_postinstall_cmds"
+ old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB \$oldlib"
;;
esac
old_archive_cmds="$old_archive_cmds~\$RANLIB \$oldlib"
@@ -6139,7 +6200,7 @@ else
if test -n "$file_magic_test_file"; then
case $deplibs_check_method in
"file_magic "*)
- file_magic_regex="`expr \"$deplibs_check_method\" : \"file_magic \(.*\)\"`"
+ file_magic_regex=`expr "$deplibs_check_method" : "file_magic \(.*\)"`
MAGIC_CMD="$lt_cv_path_MAGIC_CMD"
if eval $file_magic_cmd \$file_magic_test_file 2> /dev/null |
$EGREP "$file_magic_regex" > /dev/null; then
@@ -6201,7 +6262,7 @@ else
if test -n "$file_magic_test_file"; then
case $deplibs_check_method in
"file_magic "*)
- file_magic_regex="`expr \"$deplibs_check_method\" : \"file_magic \(.*\)\"`"
+ file_magic_regex=`expr "$deplibs_check_method" : "file_magic \(.*\)"`
MAGIC_CMD="$lt_cv_path_MAGIC_CMD"
if eval $file_magic_cmd \$file_magic_test_file 2> /dev/null |
$EGREP "$file_magic_regex" > /dev/null; then
@@ -6296,6 +6357,9 @@ lt_simple_link_test_code='int main(){return(0);}\n'
# If no C compiler was specified, use CC.
LTCC=${LTCC-"$CC"}
+# If no C compiler flags were specified, use CFLAGS.
+LTCFLAGS=${LTCFLAGS-"$CFLAGS"}
+
# Allow CC to be a program name with arguments.
compiler=$CC
@@ -6303,82 +6367,17 @@ compiler=$CC
# save warnings/boilerplate of simple test code
ac_outfile=conftest.$ac_objext
printf "$lt_simple_compile_test_code" >conftest.$ac_ext
-eval "$ac_compile" 2>&1 >/dev/null | $SED '/^$/d' >conftest.err
+eval "$ac_compile" 2>&1 >/dev/null | $SED '/^$/d; /^ *+/d' >conftest.err
_lt_compiler_boilerplate=`cat conftest.err`
$rm conftest*
ac_outfile=conftest.$ac_objext
printf "$lt_simple_link_test_code" >conftest.$ac_ext
-eval "$ac_link" 2>&1 >/dev/null | $SED '/^$/d' >conftest.err
+eval "$ac_link" 2>&1 >/dev/null | $SED '/^$/d; /^ *+/d' >conftest.err
_lt_linker_boilerplate=`cat conftest.err`
$rm conftest*
-#
-# Check for any special shared library compilation flags.
-#
-lt_prog_cc_shlib=
-if test "$GCC" = no; then
- case $host_os in
- sco3.2v5*)
- lt_prog_cc_shlib='-belf'
- ;;
- esac
-fi
-if test -n "$lt_prog_cc_shlib"; then
- { echo "$as_me:$LINENO: WARNING: \`$CC' requires \`$lt_prog_cc_shlib' to build shared libraries" >&5
-echo "$as_me: WARNING: \`$CC' requires \`$lt_prog_cc_shlib' to build shared libraries" >&2;}
- if echo "$old_CC $old_CFLAGS " | grep "[ ]$lt_prog_cc_shlib[ ]" >/dev/null; then :
- else
- { echo "$as_me:$LINENO: WARNING: add \`$lt_prog_cc_shlib' to the CC or CFLAGS env variable and reconfigure" >&5
-echo "$as_me: WARNING: add \`$lt_prog_cc_shlib' to the CC or CFLAGS env variable and reconfigure" >&2;}
- lt_cv_prog_cc_can_build_shared=no
- fi
-fi
-
-
-#
-# Check to make sure the static flag actually works.
-#
-echo "$as_me:$LINENO: checking if $compiler static flag $lt_prog_compiler_static works" >&5
-echo $ECHO_N "checking if $compiler static flag $lt_prog_compiler_static works... $ECHO_C" >&6
-if test "${lt_prog_compiler_static_works+set}" = set; then
- echo $ECHO_N "(cached) $ECHO_C" >&6
-else
- lt_prog_compiler_static_works=no
- save_LDFLAGS="$LDFLAGS"
- LDFLAGS="$LDFLAGS $lt_prog_compiler_static"
- printf "$lt_simple_link_test_code" > conftest.$ac_ext
- if (eval $ac_link 2>conftest.err) && test -s conftest$ac_exeext; then
- # The compiler can only warn and ignore the option if not recognized
- # So say no if there are warnings
- if test -s conftest.err; then
- # Append any errors to the config.log.
- cat conftest.err 1>&5
- $echo "X$_lt_linker_boilerplate" | $Xsed > conftest.exp
- $SED '/^$/d' conftest.err >conftest.er2
- if diff conftest.exp conftest.er2 >/dev/null; then
- lt_prog_compiler_static_works=yes
- fi
- else
- lt_prog_compiler_static_works=yes
- fi
- fi
- $rm conftest*
- LDFLAGS="$save_LDFLAGS"
-
-fi
-echo "$as_me:$LINENO: result: $lt_prog_compiler_static_works" >&5
-echo "${ECHO_T}$lt_prog_compiler_static_works" >&6
-
-if test x"$lt_prog_compiler_static_works" = xyes; then
- :
-else
- lt_prog_compiler_static=
-fi
-
-
-
lt_prog_compiler_no_builtin_flag=
@@ -6401,20 +6400,20 @@ else
# with a dollar sign (not a hyphen), so the echo should work correctly.
# The option is referenced via a variable to avoid confusing sed.
lt_compile=`echo "$ac_compile" | $SED \
- -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
+ -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
-e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
-e 's:$: $lt_compiler_flag:'`
- (eval echo "\"\$as_me:6407: $lt_compile\"" >&5)
+ (eval echo "\"\$as_me:6406: $lt_compile\"" >&5)
(eval "$lt_compile" 2>conftest.err)
ac_status=$?
cat conftest.err >&5
- echo "$as_me:6411: \$? = $ac_status" >&5
+ echo "$as_me:6410: \$? = $ac_status" >&5
if (exit $ac_status) && test -s "$ac_outfile"; then
# The compiler can only warn and ignore the option if not recognized
# So say no if there are warnings other than the usual output.
- $echo "X$_lt_compiler_boilerplate" | $Xsed >conftest.exp
- $SED '/^$/d' conftest.err >conftest.er2
- if test ! -s conftest.err || diff conftest.exp conftest.er2 >/dev/null; then
+ $echo "X$_lt_compiler_boilerplate" | $Xsed -e '/^$/d' >conftest.exp
+ $SED '/^$/d; /^ *+/d' conftest.err >conftest.er2
+ if test ! -s conftest.er2 || diff conftest.exp conftest.er2 >/dev/null; then
lt_cv_prog_compiler_rtti_exceptions=yes
fi
fi
@@ -6475,6 +6474,11 @@ echo $ECHO_N "checking for $compiler option to produce PIC... $ECHO_C" >&6
lt_prog_compiler_pic='-fno-common'
;;
+ interix3*)
+ # Interix 3.x gcc -fpic/-fPIC options generate broken code.
+ # Instead, we relocate shared libraries at runtime.
+ ;;
+
msdosdjgpp*)
# Just because we use GCC doesn't mean we suddenly get shared libraries
# on systems that don't support them.
@@ -6491,7 +6495,7 @@ echo $ECHO_N "checking for $compiler option to produce PIC... $ECHO_C" >&6
hpux*)
# PIC is the default for IA64 HP-UX and 64-bit HP-UX, but
# not for PA HP-UX.
- case "$host_cpu" in
+ case $host_cpu in
hppa*64*|ia64*)
# +Z the default
;;
@@ -6538,7 +6542,7 @@ echo $ECHO_N "checking for $compiler option to produce PIC... $ECHO_C" >&6
lt_prog_compiler_wl='-Wl,'
# PIC is the default for IA64 HP-UX and 64-bit HP-UX, but
# not for PA HP-UX.
- case "$host_cpu" in
+ case $host_cpu in
hppa*64*|ia64*)
# +Z the default
;;
@@ -6568,12 +6572,12 @@ echo $ECHO_N "checking for $compiler option to produce PIC... $ECHO_C" >&6
lt_prog_compiler_pic='-KPIC'
lt_prog_compiler_static='-static'
;;
- pgcc* | pgf77* | pgf90*)
+ pgcc* | pgf77* | pgf90* | pgf95*)
# Portland Group compilers (*not* the Pentium gcc compiler,
# which looks to be a dead project)
lt_prog_compiler_wl='-Wl,'
lt_prog_compiler_pic='-fpic'
- lt_prog_compiler_static='-static'
+ lt_prog_compiler_static='-Bstatic'
;;
ccc*)
lt_prog_compiler_wl='-Wl,'
@@ -6589,11 +6593,6 @@ echo $ECHO_N "checking for $compiler option to produce PIC... $ECHO_C" >&6
lt_prog_compiler_static='-non_shared'
;;
- sco3.2v5*)
- lt_prog_compiler_pic='-Kpic'
- lt_prog_compiler_static='-dn'
- ;;
-
solaris*)
lt_prog_compiler_pic='-KPIC'
lt_prog_compiler_static='-Bstatic'
@@ -6611,7 +6610,7 @@ echo $ECHO_N "checking for $compiler option to produce PIC... $ECHO_C" >&6
lt_prog_compiler_static='-Bstatic'
;;
- sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
+ sysv4 | sysv4.2uw2* | sysv4.3*)
lt_prog_compiler_wl='-Wl,'
lt_prog_compiler_pic='-KPIC'
lt_prog_compiler_static='-Bstatic'
@@ -6624,6 +6623,12 @@ echo $ECHO_N "checking for $compiler option to produce PIC... $ECHO_C" >&6
fi
;;
+ sysv5* | unixware* | sco3.2v5* | sco5v6* | OpenUNIX*)
+ lt_prog_compiler_wl='-Wl,'
+ lt_prog_compiler_pic='-KPIC'
+ lt_prog_compiler_static='-Bstatic'
+ ;;
+
unicos*)
lt_prog_compiler_wl='-Wl,'
lt_prog_compiler_can_build_shared=no
@@ -6663,20 +6668,20 @@ else
# with a dollar sign (not a hyphen), so the echo should work correctly.
# The option is referenced via a variable to avoid confusing sed.
lt_compile=`echo "$ac_compile" | $SED \
- -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
+ -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
-e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
-e 's:$: $lt_compiler_flag:'`
- (eval echo "\"\$as_me:6669: $lt_compile\"" >&5)
+ (eval echo "\"\$as_me:6674: $lt_compile\"" >&5)
(eval "$lt_compile" 2>conftest.err)
ac_status=$?
cat conftest.err >&5
- echo "$as_me:6673: \$? = $ac_status" >&5
+ echo "$as_me:6678: \$? = $ac_status" >&5
if (exit $ac_status) && test -s "$ac_outfile"; then
# The compiler can only warn and ignore the option if not recognized
# So say no if there are warnings other than the usual output.
- $echo "X$_lt_compiler_boilerplate" | $Xsed >conftest.exp
- $SED '/^$/d' conftest.err >conftest.er2
- if test ! -s conftest.err || diff conftest.exp conftest.er2 >/dev/null; then
+ $echo "X$_lt_compiler_boilerplate" | $Xsed -e '/^$/d' >conftest.exp
+ $SED '/^$/d; /^ *+/d' conftest.err >conftest.er2
+ if test ! -s conftest.er2 || diff conftest.exp conftest.er2 >/dev/null; then
lt_prog_compiler_pic_works=yes
fi
fi
@@ -6697,7 +6702,7 @@ else
fi
fi
-case "$host_os" in
+case $host_os in
# For platforms which do not support PIC, -DPIC is meaningless:
*djgpp*)
lt_prog_compiler_pic=
@@ -6707,6 +6712,48 @@ case "$host_os" in
;;
esac
+#
+# Check to make sure the static flag actually works.
+#
+wl=$lt_prog_compiler_wl eval lt_tmp_static_flag=\"$lt_prog_compiler_static\"
+echo "$as_me:$LINENO: checking if $compiler static flag $lt_tmp_static_flag works" >&5
+echo $ECHO_N "checking if $compiler static flag $lt_tmp_static_flag works... $ECHO_C" >&6
+if test "${lt_prog_compiler_static_works+set}" = set; then
+ echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+ lt_prog_compiler_static_works=no
+ save_LDFLAGS="$LDFLAGS"
+ LDFLAGS="$LDFLAGS $lt_tmp_static_flag"
+ printf "$lt_simple_link_test_code" > conftest.$ac_ext
+ if (eval $ac_link 2>conftest.err) && test -s conftest$ac_exeext; then
+ # The linker can only warn and ignore the option if not recognized
+ # So say no if there are warnings
+ if test -s conftest.err; then
+ # Append any errors to the config.log.
+ cat conftest.err 1>&5
+ $echo "X$_lt_linker_boilerplate" | $Xsed -e '/^$/d' > conftest.exp
+ $SED '/^$/d; /^ *+/d' conftest.err >conftest.er2
+ if diff conftest.exp conftest.er2 >/dev/null; then
+ lt_prog_compiler_static_works=yes
+ fi
+ else
+ lt_prog_compiler_static_works=yes
+ fi
+ fi
+ $rm conftest*
+ LDFLAGS="$save_LDFLAGS"
+
+fi
+echo "$as_me:$LINENO: result: $lt_prog_compiler_static_works" >&5
+echo "${ECHO_T}$lt_prog_compiler_static_works" >&6
+
+if test x"$lt_prog_compiler_static_works" = xyes; then
+ :
+else
+ lt_prog_compiler_static=
+fi
+
+
echo "$as_me:$LINENO: checking if $compiler supports -c -o file.$ac_objext" >&5
echo $ECHO_N "checking if $compiler supports -c -o file.$ac_objext... $ECHO_C" >&6
if test "${lt_cv_prog_compiler_c_o+set}" = set; then
@@ -6725,25 +6772,25 @@ else
# Note that $ac_compile itself does not contain backslashes and begins
# with a dollar sign (not a hyphen), so the echo should work correctly.
lt_compile=`echo "$ac_compile" | $SED \
- -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
+ -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
-e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
-e 's:$: $lt_compiler_flag:'`
- (eval echo "\"\$as_me:6731: $lt_compile\"" >&5)
+ (eval echo "\"\$as_me:6778: $lt_compile\"" >&5)
(eval "$lt_compile" 2>out/conftest.err)
ac_status=$?
cat out/conftest.err >&5
- echo "$as_me:6735: \$? = $ac_status" >&5
+ echo "$as_me:6782: \$? = $ac_status" >&5
if (exit $ac_status) && test -s out/conftest2.$ac_objext
then
# The compiler can only warn and ignore the option if not recognized
# So say no if there are warnings
- $echo "X$_lt_compiler_boilerplate" | $Xsed > out/conftest.exp
- $SED '/^$/d' out/conftest.err >out/conftest.er2
- if test ! -s out/conftest.err || diff out/conftest.exp out/conftest.er2 >/dev/null; then
+ $echo "X$_lt_compiler_boilerplate" | $Xsed -e '/^$/d' > out/conftest.exp
+ $SED '/^$/d; /^ *+/d' out/conftest.err >out/conftest.er2
+ if test ! -s out/conftest.er2 || diff out/conftest.exp out/conftest.er2 >/dev/null; then
lt_cv_prog_compiler_c_o=yes
fi
fi
- chmod u+w .
+ chmod u+w . 2>&5
$rm conftest*
# SGI C++ compiler will create directory out/ii_files/ for
# template instantiation
@@ -6839,6 +6886,10 @@ cc_basename=`$echo "X$cc_temp" | $Xsed -e 's%.*/%%' -e "s%^$host_alias-%%"`
with_gnu_ld=no
fi
;;
+ interix*)
+ # we just hope/assume this is gcc and not c89 (= MSVC++)
+ with_gnu_ld=yes
+ ;;
openbsd*)
with_gnu_ld=no
;;
@@ -6923,7 +6974,7 @@ EOF
export_symbols_cmds='$NM $libobjs $convenience | $global_symbol_pipe | $SED -e '\''/^[BCDGRS] /s/.* \([^ ]*\)/\1 DATA/'\'' | $SED -e '\''/^[AITW] /s/.* //'\'' | sort | uniq > $export_symbols'
if $LD --help 2>&1 | grep 'auto-import' > /dev/null; then
- archive_cmds='$CC -shared $libobjs $deplibs $compiler_flags -o $output_objdir/$soname ${wl}--image-base=0x10000000 ${wl}--out-implib,$lib'
+ archive_cmds='$CC -shared $libobjs $deplibs $compiler_flags -o $output_objdir/$soname ${wl}--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib'
# If the export-symbols file already is a .def file (1st line
# is EXPORTS), use it as is; otherwise, prepend...
archive_expsym_cmds='if test "x`$SED 1q $export_symbols`" = xEXPORTS; then
@@ -6932,22 +6983,37 @@ EOF
echo EXPORTS > $output_objdir/$soname.def;
cat $export_symbols >> $output_objdir/$soname.def;
fi~
- $CC -shared $output_objdir/$soname.def $libobjs $deplibs $compiler_flags -o $output_objdir/$soname ${wl}--image-base=0x10000000 ${wl}--out-implib,$lib'
+ $CC -shared $output_objdir/$soname.def $libobjs $deplibs $compiler_flags -o $output_objdir/$soname ${wl}--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib'
else
ld_shlibs=no
fi
;;
+ interix3*)
+ hardcode_direct=no
+ hardcode_shlibpath_var=no
+ hardcode_libdir_flag_spec='${wl}-rpath,$libdir'
+ export_dynamic_flag_spec='${wl}-E'
+ # Hack: On Interix 3.x, we cannot compile PIC because of a broken gcc.
+ # Instead, shared libraries are loaded at an image base (0x10000000 by
+ # default) and relocated if they conflict, which is a slow very memory
+ # consuming and fragmenting process. To avoid this, we pick a random,
+ # 256 KiB-aligned image base between 0x50000000 and 0x6FFC0000 at link
+ # time. Moving up from 0x10000000 also allows more sbrk(2) space.
+ archive_cmds='$CC -shared $pic_flag $libobjs $deplibs $compiler_flags ${wl}-h,$soname ${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
+ archive_expsym_cmds='sed "s,^,_," $export_symbols >$output_objdir/$soname.expsym~$CC -shared $pic_flag $libobjs $deplibs $compiler_flags ${wl}-h,$soname ${wl}--retain-symbols-file,$output_objdir/$soname.expsym ${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
+ ;;
+
linux*)
if $LD --help 2>&1 | grep ': supported targets:.* elf' > /dev/null; then
tmp_addflag=
case $cc_basename,$host_cpu in
pgcc*) # Portland Group C compiler
- whole_archive_flag_spec='${wl}--whole-archive,`for conv in $convenience\"\"; do test -n \"$conv\" && new_convenience=\"$new_convenience,$conv\"; done; $echo \"$new_convenience\"` ${wl}--no-whole-archive'
+ whole_archive_flag_spec='${wl}--whole-archive`for conv in $convenience\"\"; do test -n \"$conv\" && new_convenience=\"$new_convenience,$conv\"; done; $echo \"$new_convenience\"` ${wl}--no-whole-archive'
tmp_addflag=' $pic_flag'
;;
- pgf77* | pgf90* ) # Portland Group f77 and f90 compilers
- whole_archive_flag_spec='${wl}--whole-archive,`for conv in $convenience\"\"; do test -n \"$conv\" && new_convenience=\"$new_convenience,$conv\"; done; $echo \"$new_convenience\"` ${wl}--no-whole-archive'
+ pgf77* | pgf90* | pgf95*) # Portland Group f77 and f90 compilers
+ whole_archive_flag_spec='${wl}--whole-archive`for conv in $convenience\"\"; do test -n \"$conv\" && new_convenience=\"$new_convenience,$conv\"; done; $echo \"$new_convenience\"` ${wl}--no-whole-archive'
tmp_addflag=' $pic_flag -Mnomain' ;;
ecc*,ia64* | icc*,ia64*) # Intel C compiler on ia64
tmp_addflag=' -i_dynamic' ;;
@@ -6979,7 +7045,7 @@ EOF
fi
;;
- solaris* | sysv5*)
+ solaris*)
if $LD -v 2>&1 | grep 'BFD 2\.8' > /dev/null; then
ld_shlibs=no
cat <<EOF 1>&2
@@ -7000,6 +7066,33 @@ EOF
fi
;;
+ sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX*)
+ case `$LD -v 2>&1` in
+ *\ [01].* | *\ 2.[0-9].* | *\ 2.1[0-5].*)
+ ld_shlibs=no
+ cat <<_LT_EOF 1>&2
+
+*** Warning: Releases of the GNU linker prior to 2.16.91.0.3 can not
+*** reliably create shared libraries on SCO systems. Therefore, libtool
+*** is disabling shared libraries support. We urge you to upgrade GNU
+*** binutils to release 2.16.91.0.3 or newer. Another option is to modify
+*** your PATH or compiler configuration so that the native linker is
+*** used, and then restart.
+
+_LT_EOF
+ ;;
+ *)
+ if $LD --help 2>&1 | grep ': supported targets:.* elf' > /dev/null; then
+ hardcode_libdir_flag_spec='`test -z "$SCOABSPATH" && echo ${wl}-rpath,$libdir`'
+ archive_cmds='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib'
+ archive_expsym_cmds='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname,\${SCOABSPATH:+${install_libdir}/}$soname,-retain-symbols-file,$export_symbols -o $lib'
+ else
+ ld_shlibs=no
+ fi
+ ;;
+ esac
+ ;;
+
sunos4*)
archive_cmds='$LD -assert pure-text -Bshareable -o $lib $libobjs $deplibs $linker_flags'
wlarc=
@@ -7033,7 +7126,7 @@ EOF
# Note: this linker hardcodes the directories in LIBPATH if there
# are no directories specified by -L.
hardcode_minus_L=yes
- if test "$GCC" = yes && test -z "$link_static_flag"; then
+ if test "$GCC" = yes && test -z "$lt_prog_compiler_static"; then
# Neither direct hardcoding nor static linking is supported with a
# broken collect2.
hardcode_direct=unsupported
@@ -7067,6 +7160,7 @@ EOF
break
fi
done
+ ;;
esac
exp_sym_flag='-bexport'
@@ -7104,6 +7198,7 @@ EOF
hardcode_libdir_flag_spec='-L$libdir'
hardcode_libdir_separator=
fi
+ ;;
esac
shared_flag='-shared'
if test "$aix_use_runtimelinking" = yes; then
@@ -7116,11 +7211,11 @@ EOF
# chokes on -Wl,-G. The following line is correct:
shared_flag='-G'
else
- if test "$aix_use_runtimelinking" = yes; then
+ if test "$aix_use_runtimelinking" = yes; then
shared_flag='${wl}-G'
else
shared_flag='${wl}-bM:SRE'
- fi
+ fi
fi
fi
@@ -7185,12 +7280,12 @@ rm -f conftest.err conftest.$ac_objext \
if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
hardcode_libdir_flag_spec='${wl}-blibpath:$libdir:'"$aix_libpath"
- archive_expsym_cmds="\$CC"' -o $output_objdir/$soname $libobjs $deplibs $compiler_flags `if test "x${allow_undefined_flag}" != "x"; then echo "${wl}${allow_undefined_flag}"; else :; fi` '"\${wl}$no_entry_flag \${wl}$exp_sym_flag:\$export_symbols $shared_flag"
+ archive_expsym_cmds="\$CC"' -o $output_objdir/$soname $libobjs $deplibs '"\${wl}$no_entry_flag"' $compiler_flags `if test "x${allow_undefined_flag}" != "x"; then echo "${wl}${allow_undefined_flag}"; else :; fi` '"\${wl}$exp_sym_flag:\$export_symbols $shared_flag"
else
if test "$host_cpu" = ia64; then
hardcode_libdir_flag_spec='${wl}-R $libdir:/usr/lib:/lib'
allow_undefined_flag="-z nodefs"
- archive_expsym_cmds="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs $compiler_flags ${wl}${allow_undefined_flag} '"\${wl}$no_entry_flag \${wl}$exp_sym_flag:\$export_symbols"
+ archive_expsym_cmds="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs '"\${wl}$no_entry_flag"' $compiler_flags ${wl}${allow_undefined_flag} '"\${wl}$exp_sym_flag:\$export_symbols"
else
# Determine the default libpath from the value encoded in an empty executable.
cat >conftest.$ac_ext <<_ACEOF
@@ -7250,13 +7345,11 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
# -berok will link without error, but may produce a broken library.
no_undefined_flag=' ${wl}-bernotok'
allow_undefined_flag=' ${wl}-berok'
- # -bexpall does not export symbols beginning with underscore (_)
- always_export_symbols=yes
# Exported symbols can be pulled into shared objects from archives
- whole_archive_flag_spec=' '
+ whole_archive_flag_spec='$convenience'
archive_cmds_need_lc=yes
- # This is similar to how AIX traditionally builds it's shared libraries.
- archive_expsym_cmds="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs $compiler_flags ${wl}-bE:$export_symbols ${wl}-bnoentry${allow_undefined_flag}~$AR $AR_FLAGS $output_objdir/$libname$release.a $output_objdir/$soname'
+ # This is similar to how AIX traditionally builds its shared libraries.
+ archive_expsym_cmds="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs ${wl}-bnoentry $compiler_flags ${wl}-bE:$export_symbols${allow_undefined_flag}~$AR $AR_FLAGS $output_objdir/$libname$release.a $output_objdir/$soname'
fi
fi
;;
@@ -7295,7 +7388,7 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
;;
darwin* | rhapsody*)
- case "$host_os" in
+ case $host_os in
rhapsody* | darwin1.[012])
allow_undefined_flag='${wl}-undefined ${wl}suppress'
;;
@@ -7324,7 +7417,7 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
output_verbose_link_cmd='echo'
archive_cmds='$CC -dynamiclib $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags -install_name $rpath/$soname $verstring'
module_cmds='$CC $allow_undefined_flag -o $lib -bundle $libobjs $deplibs$compiler_flags'
- # Don't fix this by using the ld -exported_symbols_list flag, it doesn't exist in older darwin ld's
+ # Don't fix this by using the ld -exported_symbols_list flag, it doesn't exist in older darwin lds
archive_expsym_cmds='sed -e "s,#.*,," -e "s,^[ ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC -dynamiclib $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags -install_name $rpath/$soname $verstring~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
module_expsym_cmds='sed -e "s,#.*,," -e "s,^[ ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC $allow_undefined_flag -o $lib -bundle $libobjs $deplibs$compiler_flags~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
else
@@ -7333,7 +7426,7 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
output_verbose_link_cmd='echo'
archive_cmds='$CC -qmkshrobj $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags ${wl}-install_name ${wl}`echo $rpath/$soname` $verstring'
module_cmds='$CC $allow_undefined_flag -o $lib -bundle $libobjs $deplibs$compiler_flags'
- # Don't fix this by using the ld -exported_symbols_list flag, it doesn't exist in older darwin ld's
+ # Don't fix this by using the ld -exported_symbols_list flag, it doesn't exist in older darwin lds
archive_expsym_cmds='sed -e "s,#.*,," -e "s,^[ ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC -qmkshrobj $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags ${wl}-install_name ${wl}$rpath/$soname $verstring~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
module_expsym_cmds='sed -e "s,#.*,," -e "s,^[ ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC $allow_undefined_flag -o $lib -bundle $libobjs $deplibs$compiler_flags~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
;;
@@ -7397,47 +7490,62 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
export_dynamic_flag_spec='${wl}-E'
;;
- hpux10* | hpux11*)
+ hpux10*)
if test "$GCC" = yes -a "$with_gnu_ld" = no; then
- case "$host_cpu" in
- hppa*64*|ia64*)
+ archive_cmds='$CC -shared -fPIC ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
+ else
+ archive_cmds='$LD -b +h $soname +b $install_libdir -o $lib $libobjs $deplibs $linker_flags'
+ fi
+ if test "$with_gnu_ld" = no; then
+ hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir'
+ hardcode_libdir_separator=:
+
+ hardcode_direct=yes
+ export_dynamic_flag_spec='${wl}-E'
+
+ # hardcode_minus_L: Not really in the search PATH,
+ # but as the default location of the library.
+ hardcode_minus_L=yes
+ fi
+ ;;
+
+ hpux11*)
+ if test "$GCC" = yes -a "$with_gnu_ld" = no; then
+ case $host_cpu in
+ hppa*64*)
archive_cmds='$CC -shared ${wl}+h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
;;
+ ia64*)
+ archive_cmds='$CC -shared ${wl}+h ${wl}$soname ${wl}+nodefaultrpath -o $lib $libobjs $deplibs $compiler_flags'
+ ;;
*)
archive_cmds='$CC -shared -fPIC ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
;;
esac
else
- case "$host_cpu" in
- hppa*64*|ia64*)
- archive_cmds='$LD -b +h $soname -o $lib $libobjs $deplibs $linker_flags'
+ case $host_cpu in
+ hppa*64*)
+ archive_cmds='$CC -b ${wl}+h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
+ ;;
+ ia64*)
+ archive_cmds='$CC -b ${wl}+h ${wl}$soname ${wl}+nodefaultrpath -o $lib $libobjs $deplibs $compiler_flags'
;;
*)
- archive_cmds='$LD -b +h $soname +b $install_libdir -o $lib $libobjs $deplibs $linker_flags'
+ archive_cmds='$CC -b ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
;;
esac
fi
if test "$with_gnu_ld" = no; then
- case "$host_cpu" in
- hppa*64*)
- hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir'
+ hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir'
+ hardcode_libdir_separator=:
+
+ case $host_cpu in
+ hppa*64*|ia64*)
hardcode_libdir_flag_spec_ld='+b $libdir'
- hardcode_libdir_separator=:
- hardcode_direct=no
- hardcode_shlibpath_var=no
- ;;
- ia64*)
- hardcode_libdir_flag_spec='-L$libdir'
hardcode_direct=no
hardcode_shlibpath_var=no
-
- # hardcode_minus_L: Not really in the search PATH,
- # but as the default location of the library.
- hardcode_minus_L=yes
;;
*)
- hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir'
- hardcode_libdir_separator=:
hardcode_direct=yes
export_dynamic_flag_spec='${wl}-E'
@@ -7539,14 +7647,6 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
hardcode_libdir_separator=:
;;
- sco3.2v5*)
- archive_cmds='$LD -G -h $soname -o $lib $libobjs $deplibs $linker_flags'
- hardcode_shlibpath_var=no
- export_dynamic_flag_spec='${wl}-Bexport'
- runpath_var=LD_RUN_PATH
- hardcode_runpath_var=yes
- ;;
-
solaris*)
no_undefined_flag=' -z text'
if test "$GCC" = yes; then
@@ -7632,36 +7732,45 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
fi
;;
- sysv4.2uw2*)
- archive_cmds='$LD -G -o $lib $libobjs $deplibs $linker_flags'
- hardcode_direct=yes
- hardcode_minus_L=no
+ sysv4*uw2* | sysv5OpenUNIX* | sysv5UnixWare7.[01].[10]* | unixware7*)
+ no_undefined_flag='${wl}-z,text'
+ archive_cmds_need_lc=no
hardcode_shlibpath_var=no
- hardcode_runpath_var=yes
- runpath_var=LD_RUN_PATH
- ;;
+ runpath_var='LD_RUN_PATH'
- sysv5OpenUNIX8* | sysv5UnixWare7* | sysv5uw[78]* | unixware7*)
- no_undefined_flag='${wl}-z ${wl}text'
if test "$GCC" = yes; then
- archive_cmds='$CC -shared ${wl}-h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
+ archive_cmds='$CC -shared ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
+ archive_expsym_cmds='$CC -shared ${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
else
- archive_cmds='$CC -G ${wl}-h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
+ archive_cmds='$CC -G ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
+ archive_expsym_cmds='$CC -G ${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
fi
- runpath_var='LD_RUN_PATH'
- hardcode_shlibpath_var=no
;;
- sysv5*)
- no_undefined_flag=' -z text'
- # $CC -shared without GNU ld will not create a library from C++
- # object files and a static libstdc++, better avoid it by now
- archive_cmds='$LD -G${allow_undefined_flag} -h $soname -o $lib $libobjs $deplibs $linker_flags'
- archive_expsym_cmds='$echo "{ global:" > $lib.exp~cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >> $lib.exp~$echo "local: *; };" >> $lib.exp~
- $LD -G${allow_undefined_flag} -M $lib.exp -h $soname -o $lib $libobjs $deplibs $linker_flags~$rm $lib.exp'
- hardcode_libdir_flag_spec=
+ sysv5* | sco3.2v5* | sco5v6*)
+ # Note: We can NOT use -z defs as we might desire, because we do not
+ # link with -lc, and that would cause any symbols used from libc to
+ # always be unresolved, which means just about no library would
+ # ever link correctly. If we're not using GNU ld we use -z text
+ # though, which does catch some bad symbols but isn't as heavy-handed
+ # as -z defs.
+ no_undefined_flag='${wl}-z,text'
+ allow_undefined_flag='${wl}-z,nodefs'
+ archive_cmds_need_lc=no
hardcode_shlibpath_var=no
+ hardcode_libdir_flag_spec='`test -z "$SCOABSPATH" && echo ${wl}-R,$libdir`'
+ hardcode_libdir_separator=':'
+ link_all_deplibs=yes
+ export_dynamic_flag_spec='${wl}-Bexport'
runpath_var='LD_RUN_PATH'
+
+ if test "$GCC" = yes; then
+ archive_cmds='$CC -shared ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+ archive_expsym_cmds='$CC -shared ${wl}-Bexport:$export_symbols ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+ else
+ archive_cmds='$CC -G ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+ archive_expsym_cmds='$CC -G ${wl}-Bexport:$export_symbols ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+ fi
;;
uts4*)
@@ -7680,11 +7789,6 @@ echo "$as_me:$LINENO: result: $ld_shlibs" >&5
echo "${ECHO_T}$ld_shlibs" >&6
test "$ld_shlibs" = no && can_build_shared=no
-variables_saved_for_relink="PATH $shlibpath_var $runpath_var"
-if test "$GCC" = yes; then
- variables_saved_for_relink="$variables_saved_for_relink GCC_EXEC_PREFIX COMPILER_PATH LIBRARY_PATH"
-fi
-
#
# Do we need to explicitly link libc?
#
@@ -7717,6 +7821,7 @@ echo $ECHO_N "checking whether -lc should be explicitly linked in... $ECHO_C" >&
libobjs=conftest.$ac_objext
deplibs=
wl=$lt_prog_compiler_wl
+ pic_flag=$lt_prog_compiler_pic
compiler_flags=-v
linker_flags=-v
verstring=
@@ -7877,7 +7982,8 @@ cygwin* | mingw* | pw32*)
dlpath=`$SHELL 2>&1 -c '\''. $dir/'\''\${base_file}'\''i;echo \$dlname'\''`~
dldir=$destdir/`dirname \$dlpath`~
test -d \$dldir || mkdir -p \$dldir~
- $install_prog $dir/$dlname \$dldir/$dlname'
+ $install_prog $dir/$dlname \$dldir/$dlname~
+ chmod a+x \$dldir/$dlname'
postuninstall_cmds='dldll=`$SHELL 2>&1 -c '\''. $file; echo \$dlname'\''`~
dlpath=$dir/\$dldll~
$rm \$dlpath'
@@ -7930,7 +8036,7 @@ darwin* | rhapsody*)
soname_spec='${libname}${release}${major}$shared_ext'
shlibpath_overrides_runpath=yes
shlibpath_var=DYLD_LIBRARY_PATH
- shrext_cmds='$(test .$module = .yes && echo .so || echo .dylib)'
+ shrext_cmds='`test .$module = .yes && echo .so || echo .dylib`'
# Apple's gcc prints 'gcc -print-search-dirs' doesn't operate the same.
if test "$GCC" = yes; then
sys_lib_search_path_spec=`$CC -print-search-dirs | tr "\n" "$PATH_SEPARATOR" | sed -e 's/libraries:/@libraries:/' | tr "@" "\n" | grep "^libraries:" | sed -e "s/^libraries://" -e "s,=/,/,g" -e "s,$PATH_SEPARATOR, ,g" -e "s,.*,& /lib /usr/lib /usr/local/lib,g"`
@@ -7968,7 +8074,14 @@ kfreebsd*-gnu)
freebsd* | dragonfly*)
# DragonFly does not have aout. When/if they implement a new
# versioning mechanism, adjust this.
- objformat=`test -x /usr/bin/objformat && /usr/bin/objformat || echo aout`
+ if test -x /usr/bin/objformat; then
+ objformat=`/usr/bin/objformat`
+ else
+ case $host_os in
+ freebsd[123]*) objformat=aout ;;
+ *) objformat=elf ;;
+ esac
+ fi
version_type=freebsd-$objformat
case $version_type in
freebsd-elf*)
@@ -7990,10 +8103,15 @@ freebsd* | dragonfly*)
shlibpath_overrides_runpath=yes
hardcode_into_libs=yes
;;
- *) # from 3.2 on
+ freebsd3.[2-9]* | freebsdelf3.[2-9]* | \
+ freebsd4.[0-5] | freebsdelf4.[0-5] | freebsd4.1.1 | freebsdelf4.1.1)
shlibpath_overrides_runpath=no
hardcode_into_libs=yes
;;
+ freebsd*) # from 4.6 on
+ shlibpath_overrides_runpath=yes
+ hardcode_into_libs=yes
+ ;;
esac
;;
@@ -8013,7 +8131,7 @@ hpux9* | hpux10* | hpux11*)
version_type=sunos
need_lib_prefix=no
need_version=no
- case "$host_cpu" in
+ case $host_cpu in
ia64*)
shrext_cmds='.so'
hardcode_into_libs=yes
@@ -8053,6 +8171,18 @@ hpux9* | hpux10* | hpux11*)
postinstall_cmds='chmod 555 $lib'
;;
+interix3*)
+ version_type=linux
+ need_lib_prefix=no
+ need_version=no
+ library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major ${libname}${shared_ext}'
+ soname_spec='${libname}${release}${shared_ext}$major'
+ dynamic_linker='Interix 3.x ld.so.1 (PE, like ELF)'
+ shlibpath_var=LD_LIBRARY_PATH
+ shlibpath_overrides_runpath=no
+ hardcode_into_libs=yes
+ ;;
+
irix5* | irix6* | nonstopux*)
case $host_os in
nonstopux*) version_type=nonstopux ;;
@@ -8174,6 +8304,7 @@ nto-qnx*)
openbsd*)
version_type=sunos
+ sys_lib_dlsearch_path_spec="/usr/lib"
need_lib_prefix=no
# Some older versions of OpenBSD (3.3 at least) *do* need versioned libs.
case $host_os in
@@ -8217,13 +8348,6 @@ osf3* | osf4* | osf5*)
sys_lib_dlsearch_path_spec="$sys_lib_search_path_spec"
;;
-sco3.2v5*)
- version_type=osf
- soname_spec='${libname}${release}${shared_ext}$major'
- library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
- shlibpath_var=LD_LIBRARY_PATH
- ;;
-
solaris*)
version_type=linux
need_lib_prefix=no
@@ -8249,7 +8373,7 @@ sunos4*)
need_version=yes
;;
-sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
+sysv4 | sysv4.3*)
version_type=linux
library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
soname_spec='${libname}${release}${shared_ext}$major'
@@ -8282,6 +8406,29 @@ sysv4*MP*)
fi
;;
+sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX* | sysv4*uw2*)
+ version_type=freebsd-elf
+ need_lib_prefix=no
+ need_version=no
+ library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext} $libname${shared_ext}'
+ soname_spec='${libname}${release}${shared_ext}$major'
+ shlibpath_var=LD_LIBRARY_PATH
+ hardcode_into_libs=yes
+ if test "$with_gnu_ld" = yes; then
+ sys_lib_search_path_spec='/usr/local/lib /usr/gnu/lib /usr/ccs/lib /usr/lib /lib'
+ shlibpath_overrides_runpath=no
+ else
+ sys_lib_search_path_spec='/usr/ccs/lib /usr/lib'
+ shlibpath_overrides_runpath=yes
+ case $host_os in
+ sco3.2v5*)
+ sys_lib_search_path_spec="$sys_lib_search_path_spec /lib"
+ ;;
+ esac
+ fi
+ sys_lib_dlsearch_path_spec='/usr/lib'
+ ;;
+
uts4*)
version_type=linux
library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
@@ -8297,6 +8444,11 @@ echo "$as_me:$LINENO: result: $dynamic_linker" >&5
echo "${ECHO_T}$dynamic_linker" >&6
test "$dynamic_linker" = no && can_build_shared=no
+variables_saved_for_relink="PATH $shlibpath_var $runpath_var"
+if test "$GCC" = yes; then
+ variables_saved_for_relink="$variables_saved_for_relink GCC_EXEC_PREFIX COMPILER_PATH LIBRARY_PATH"
+fi
+
echo "$as_me:$LINENO: checking how to hardcode library paths into programs" >&5
echo $ECHO_N "checking how to hardcode library paths into programs... $ECHO_C" >&6
hardcode_action=
@@ -8952,7 +9104,7 @@ fi
test "x$ac_cv_header_dlfcn_h" = xyes && CPPFLAGS="$CPPFLAGS -DHAVE_DLFCN_H"
save_LDFLAGS="$LDFLAGS"
- eval LDFLAGS=\"\$LDFLAGS $export_dynamic_flag_spec\"
+ wl=$lt_prog_compiler_wl eval LDFLAGS=\"\$LDFLAGS $export_dynamic_flag_spec\"
save_LIBS="$LIBS"
LIBS="$lt_cv_dlopen_libs $LIBS"
@@ -8968,7 +9120,7 @@ else
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat > conftest.$ac_ext <<EOF
-#line 8971 "configure"
+#line 9123 "configure"
#include "confdefs.h"
#if HAVE_DLFCN_H
@@ -9025,6 +9177,8 @@ int main ()
else if (dlsym( self,"_fnord")) status = $lt_dlneed_uscore;
/* dlclose (self); */
}
+ else
+ puts (dlerror ());
exit (status);
}
@@ -9034,12 +9188,12 @@ EOF
ac_status=$?
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } && test -s conftest${ac_exeext} 2>/dev/null; then
- (./conftest; exit; ) 2>/dev/null
+ (./conftest; exit; ) >&5 2>/dev/null
lt_status=$?
case x$lt_status in
x$lt_dlno_uscore) lt_cv_dlopen_self=yes ;;
x$lt_dlneed_uscore) lt_cv_dlopen_self=yes ;;
- x$lt_unknown|x*) lt_cv_dlopen_self=no ;;
+ x$lt_dlunknown|x*) lt_cv_dlopen_self=no ;;
esac
else :
# compilation failed
@@ -9054,7 +9208,7 @@ echo "$as_me:$LINENO: result: $lt_cv_dlopen_self" >&5
echo "${ECHO_T}$lt_cv_dlopen_self" >&6
if test "x$lt_cv_dlopen_self" = xyes; then
- LDFLAGS="$LDFLAGS $link_static_flag"
+ wl=$lt_prog_compiler_wl eval LDFLAGS=\"\$LDFLAGS $lt_prog_compiler_static\"
echo "$as_me:$LINENO: checking whether a statically linked program can dlopen itself" >&5
echo $ECHO_N "checking whether a statically linked program can dlopen itself... $ECHO_C" >&6
if test "${lt_cv_dlopen_self_static+set}" = set; then
@@ -9066,7 +9220,7 @@ else
lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
lt_status=$lt_dlunknown
cat > conftest.$ac_ext <<EOF
-#line 9069 "configure"
+#line 9223 "configure"
#include "confdefs.h"
#if HAVE_DLFCN_H
@@ -9123,6 +9277,8 @@ int main ()
else if (dlsym( self,"_fnord")) status = $lt_dlneed_uscore;
/* dlclose (self); */
}
+ else
+ puts (dlerror ());
exit (status);
}
@@ -9132,12 +9288,12 @@ EOF
ac_status=$?
echo "$as_me:$LINENO: \$? = $ac_status" >&5
(exit $ac_status); } && test -s conftest${ac_exeext} 2>/dev/null; then
- (./conftest; exit; ) 2>/dev/null
+ (./conftest; exit; ) >&5 2>/dev/null
lt_status=$?
case x$lt_status in
x$lt_dlno_uscore) lt_cv_dlopen_self_static=yes ;;
x$lt_dlneed_uscore) lt_cv_dlopen_self_static=yes ;;
- x$lt_unknown|x*) lt_cv_dlopen_self_static=no ;;
+ x$lt_dlunknown|x*) lt_cv_dlopen_self_static=no ;;
esac
else :
# compilation failed
@@ -9170,7 +9326,7 @@ echo "${ECHO_T}$lt_cv_dlopen_self_static" >&6
fi
-# Report which librarie types wil actually be built
+# Report which library types will actually be built
echo "$as_me:$LINENO: checking if libtool supports shared libraries" >&5
echo $ECHO_N "checking if libtool supports shared libraries... $ECHO_C" >&6
echo "$as_me:$LINENO: result: $can_build_shared" >&5
@@ -9182,7 +9338,7 @@ test "$can_build_shared" = "no" && enable_shared=no
# On AIX, shared libraries and static libraries use the same namespace, and
# are all built from PIC.
-case "$host_os" in
+case $host_os in
aix3*)
test "$enable_shared" = yes && enable_static=no
if test -n "$RANLIB"; then
@@ -9220,7 +9376,7 @@ if test -f "$ltmain"; then
# Now quote all the things that may contain metacharacters while being
# careful not to overquote the AC_SUBSTed values. We take copies of the
# variables and quote the copies for generation of the libtool script.
- for var in echo old_CC old_CFLAGS AR AR_FLAGS EGREP RANLIB LN_S LTCC NM \
+ for var in echo old_CC old_CFLAGS AR AR_FLAGS EGREP RANLIB LN_S LTCC LTCFLAGS NM \
SED SHELL STRIP \
libname_spec library_names_spec soname_spec extract_expsyms_cmds \
old_striplib striplib file_magic_cmd finish_cmds finish_eval \
@@ -9386,6 +9542,9 @@ AR_FLAGS=$lt_AR_FLAGS
# A C compiler.
LTCC=$lt_LTCC
+# LTCC compiler flags.
+LTCFLAGS=$lt_LTCFLAGS
+
# A language-specific compiler.
CC=$lt_compiler
@@ -9716,6 +9875,9 @@ echo "$as_me: WARNING: output file \`$ofile' does not look like a libtool script
echo "$as_me: WARNING: using \`LTCC=$LTCC', extracted from \`$ofile'" >&2;}
fi
fi
+ if test -z "$LTCFLAGS"; then
+ eval "`$SHELL ${ofile} --config | grep '^LTCFLAGS='`"
+ fi
# Extract list of available tagged configurations in $ofile.
# Note that this assumes the entire list is on one line.
@@ -9768,6 +9930,7 @@ hardcode_libdir_flag_spec_CXX=
hardcode_libdir_flag_spec_ld_CXX=
hardcode_libdir_separator_CXX=
hardcode_minus_L_CXX=no
+hardcode_shlibpath_var_CXX=unsupported
hardcode_automatic_CXX=no
module_cmds_CXX=
module_expsym_cmds_CXX=
@@ -9785,7 +9948,7 @@ postdeps_CXX=
compiler_lib_search_path_CXX=
# Source file extension for C++ test sources.
-ac_ext=cc
+ac_ext=cpp
# Object file extension for compiled C++ test sources.
objext=o
@@ -9795,13 +9958,16 @@ objext_CXX=$objext
lt_simple_compile_test_code="int some_variable = 0;\n"
# Code to be used in simple link tests
-lt_simple_link_test_code='int main(int, char *) { return(0); }\n'
+lt_simple_link_test_code='int main(int, char *[]) { return(0); }\n'
# ltmain only uses $CC for tagged configurations so make sure $CC is set.
# If no C compiler was specified, use CC.
LTCC=${LTCC-"$CC"}
+# If no C compiler flags were specified, use CFLAGS.
+LTCFLAGS=${LTCFLAGS-"$CFLAGS"}
+
# Allow CC to be a program name with arguments.
compiler=$CC
@@ -9809,13 +9975,13 @@ compiler=$CC
# save warnings/boilerplate of simple test code
ac_outfile=conftest.$ac_objext
printf "$lt_simple_compile_test_code" >conftest.$ac_ext
-eval "$ac_compile" 2>&1 >/dev/null | $SED '/^$/d' >conftest.err
+eval "$ac_compile" 2>&1 >/dev/null | $SED '/^$/d; /^ *+/d' >conftest.err
_lt_compiler_boilerplate=`cat conftest.err`
$rm conftest*
ac_outfile=conftest.$ac_objext
printf "$lt_simple_link_test_code" >conftest.$ac_ext
-eval "$ac_link" 2>&1 >/dev/null | $SED '/^$/d' >conftest.err
+eval "$ac_link" 2>&1 >/dev/null | $SED '/^$/d; /^ *+/d' >conftest.err
_lt_linker_boilerplate=`cat conftest.err`
$rm conftest*
@@ -9830,12 +9996,12 @@ lt_save_path_LD=$lt_cv_path_LD
if test -n "${lt_cv_prog_gnu_ldcxx+set}"; then
lt_cv_prog_gnu_ld=$lt_cv_prog_gnu_ldcxx
else
- unset lt_cv_prog_gnu_ld
+ $as_unset lt_cv_prog_gnu_ld
fi
if test -n "${lt_cv_path_LDCXX+set}"; then
lt_cv_path_LD=$lt_cv_path_LDCXX
else
- unset lt_cv_path_LD
+ $as_unset lt_cv_path_LD
fi
test -z "${LDCXX+set}" || LD=$LDCXX
CC=${CXX-"c++"}
@@ -9921,7 +10087,7 @@ else
if test -f "$ac_dir/$ac_prog" || test -f "$ac_dir/$ac_prog$ac_exeext"; then
lt_cv_path_LD="$ac_dir/$ac_prog"
# Check to see if the program is GNU ld. I'd rather use --version,
- # but apparently some GNU ld's only accept -v.
+ # but apparently some variants of GNU ld only accept -v.
# Break only if it was the GNU/non-GNU ld that we prefer.
case `"$lt_cv_path_LD" -v 2>&1 </dev/null` in
*GNU* | *'with BFD'*)
@@ -9955,7 +10121,7 @@ echo $ECHO_N "checking if the linker ($LD) is GNU ld... $ECHO_C" >&6
if test "${lt_cv_prog_gnu_ld+set}" = set; then
echo $ECHO_N "(cached) $ECHO_C" >&6
else
- # I'd rather use --version here, but apparently some GNU ld's only accept -v.
+ # I'd rather use --version here, but apparently some GNU lds only accept -v.
case `$LD -v 2>&1 </dev/null` in
*GNU* | *'with BFD'*)
lt_cv_prog_gnu_ld=yes
@@ -10046,6 +10212,7 @@ case $host_os in
;;
esac
done
+ ;;
esac
exp_sym_flag='-bexport'
@@ -10083,6 +10250,7 @@ case $host_os in
hardcode_libdir_flag_spec_CXX='-L$libdir'
hardcode_libdir_separator_CXX=
fi
+ ;;
esac
shared_flag='-shared'
if test "$aix_use_runtimelinking" = yes; then
@@ -10165,12 +10333,12 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
hardcode_libdir_flag_spec_CXX='${wl}-blibpath:$libdir:'"$aix_libpath"
- archive_expsym_cmds_CXX="\$CC"' -o $output_objdir/$soname $libobjs $deplibs $compiler_flags `if test "x${allow_undefined_flag}" != "x"; then echo "${wl}${allow_undefined_flag}"; else :; fi` '"\${wl}$no_entry_flag \${wl}$exp_sym_flag:\$export_symbols $shared_flag"
+ archive_expsym_cmds_CXX="\$CC"' -o $output_objdir/$soname $libobjs $deplibs '"\${wl}$no_entry_flag"' $compiler_flags `if test "x${allow_undefined_flag}" != "x"; then echo "${wl}${allow_undefined_flag}"; else :; fi` '"\${wl}$exp_sym_flag:\$export_symbols $shared_flag"
else
if test "$host_cpu" = ia64; then
hardcode_libdir_flag_spec_CXX='${wl}-R $libdir:/usr/lib:/lib'
allow_undefined_flag_CXX="-z nodefs"
- archive_expsym_cmds_CXX="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs $compiler_flags ${wl}${allow_undefined_flag} '"\${wl}$no_entry_flag \${wl}$exp_sym_flag:\$export_symbols"
+ archive_expsym_cmds_CXX="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs '"\${wl}$no_entry_flag"' $compiler_flags ${wl}${allow_undefined_flag} '"\${wl}$exp_sym_flag:\$export_symbols"
else
# Determine the default libpath from the value encoded in an empty executable.
cat >conftest.$ac_ext <<_ACEOF
@@ -10230,16 +10398,26 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
# -berok will link without error, but may produce a broken library.
no_undefined_flag_CXX=' ${wl}-bernotok'
allow_undefined_flag_CXX=' ${wl}-berok'
- # -bexpall does not export symbols beginning with underscore (_)
- always_export_symbols_CXX=yes
# Exported symbols can be pulled into shared objects from archives
- whole_archive_flag_spec_CXX=' '
+ whole_archive_flag_spec_CXX='$convenience'
archive_cmds_need_lc_CXX=yes
- # This is similar to how AIX traditionally builds it's shared libraries.
- archive_expsym_cmds_CXX="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs $compiler_flags ${wl}-bE:$export_symbols ${wl}-bnoentry${allow_undefined_flag}~$AR $AR_FLAGS $output_objdir/$libname$release.a $output_objdir/$soname'
+ # This is similar to how AIX traditionally builds its shared libraries.
+ archive_expsym_cmds_CXX="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs ${wl}-bnoentry $compiler_flags ${wl}-bE:$export_symbols${allow_undefined_flag}~$AR $AR_FLAGS $output_objdir/$libname$release.a $output_objdir/$soname'
fi
fi
;;
+
+ beos*)
+ if $LD --help 2>&1 | grep ': supported targets:.* elf' > /dev/null; then
+ allow_undefined_flag_CXX=unsupported
+ # Joseph Beckenbach <jrb3@best.com> says some releases of gcc
+ # support --undefined. This deserves some investigation. FIXME
+ archive_cmds_CXX='$CC -nostart $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname -o $lib'
+ else
+ ld_shlibs_CXX=no
+ fi
+ ;;
+
chorus*)
case $cc_basename in
*)
@@ -10249,7 +10427,6 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
esac
;;
-
cygwin* | mingw* | pw32*)
# _LT_AC_TAGVAR(hardcode_libdir_flag_spec, CXX) is actually meaningless,
# as there is no search path for DLLs.
@@ -10259,7 +10436,7 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
enable_shared_with_static_runtimes_CXX=yes
if $LD --help 2>&1 | grep 'auto-import' > /dev/null; then
- archive_cmds_CXX='$CC -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -o $output_objdir/$soname ${wl}--image-base=0x10000000 ${wl}--out-implib,$lib'
+ archive_cmds_CXX='$CC -shared -nostdlib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -o $output_objdir/$soname ${wl}--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib'
# If the export-symbols file already is a .def file (1st line
# is EXPORTS), use it as is; otherwise, prepend...
archive_expsym_cmds_CXX='if test "x`$SED 1q $export_symbols`" = xEXPORTS; then
@@ -10268,13 +10445,13 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
echo EXPORTS > $output_objdir/$soname.def;
cat $export_symbols >> $output_objdir/$soname.def;
fi~
- $CC -shared -nostdlib $output_objdir/$soname.def $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -o $output_objdir/$soname ${wl}--image-base=0x10000000 ${wl}--out-implib,$lib'
+ $CC -shared -nostdlib $output_objdir/$soname.def $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -o $output_objdir/$soname ${wl}--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib'
else
ld_shlibs_CXX=no
fi
;;
darwin* | rhapsody*)
- case "$host_os" in
+ case $host_os in
rhapsody* | darwin1.[012])
allow_undefined_flag_CXX='${wl}-undefined ${wl}suppress'
;;
@@ -10312,7 +10489,7 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
archive_cmds_CXX='$CC -r -keep_private_externs -nostdlib -o ${lib}-master.o $libobjs~$CC -dynamiclib $allow_undefined_flag -o $lib ${lib}-master.o $deplibs $compiler_flags -install_name $rpath/$soname $verstring'
fi
module_cmds_CXX='$CC $allow_undefined_flag -o $lib -bundle $libobjs $deplibs$compiler_flags'
- # Don't fix this by using the ld -exported_symbols_list flag, it doesn't exist in older darwin ld's
+ # Don't fix this by using the ld -exported_symbols_list flag, it doesn't exist in older darwin lds
if test "X$lt_int_apple_cc_single_mod" = Xyes ; then
archive_expsym_cmds_CXX='sed -e "s,#.*,," -e "s,^[ ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC -dynamiclib -single_module $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags -install_name $rpath/$soname $verstring~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
else
@@ -10325,7 +10502,7 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
output_verbose_link_cmd='echo'
archive_cmds_CXX='$CC -qmkshrobj ${wl}-single_module $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags ${wl}-install_name ${wl}`echo $rpath/$soname` $verstring'
module_cmds_CXX='$CC $allow_undefined_flag -o $lib -bundle $libobjs $deplibs$compiler_flags'
- # Don't fix this by using the ld -exported_symbols_list flag, it doesn't exist in older darwin ld's
+ # Don't fix this by using the ld -exported_symbols_list flag, it doesn't exist in older darwin lds
archive_expsym_cmds_CXX='sed -e "s,#.*,," -e "s,^[ ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC -qmkshrobj ${wl}-single_module $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags ${wl}-install_name ${wl}$rpath/$soname $verstring~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
module_expsym_cmds_CXX='sed -e "s,#.*,," -e "s,^[ ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC $allow_undefined_flag -o $lib -bundle $libobjs $deplibs$compiler_flags~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
;;
@@ -10405,33 +10582,22 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
;;
hpux10*|hpux11*)
if test $with_gnu_ld = no; then
- case "$host_cpu" in
- hppa*64*)
- hardcode_libdir_flag_spec_CXX='${wl}+b ${wl}$libdir'
+ hardcode_libdir_flag_spec_CXX='${wl}+b ${wl}$libdir'
+ hardcode_libdir_separator_CXX=:
+
+ case $host_cpu in
+ hppa*64*|ia64*)
hardcode_libdir_flag_spec_ld_CXX='+b $libdir'
- hardcode_libdir_separator_CXX=:
- ;;
- ia64*)
- hardcode_libdir_flag_spec_CXX='-L$libdir'
;;
*)
- hardcode_libdir_flag_spec_CXX='${wl}+b ${wl}$libdir'
- hardcode_libdir_separator_CXX=:
export_dynamic_flag_spec_CXX='${wl}-E'
;;
esac
fi
- case "$host_cpu" in
- hppa*64*)
- hardcode_direct_CXX=no
- hardcode_shlibpath_var_CXX=no
- ;;
- ia64*)
+ case $host_cpu in
+ hppa*64*|ia64*)
hardcode_direct_CXX=no
hardcode_shlibpath_var_CXX=no
- hardcode_minus_L_CXX=yes # Not in the search PATH,
- # but as the default
- # location of the library.
;;
*)
hardcode_direct_CXX=yes
@@ -10447,9 +10613,12 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
ld_shlibs_CXX=no
;;
aCC*)
- case "$host_cpu" in
- hppa*64*|ia64*)
- archive_cmds_CXX='$LD -b +h $soname -o $lib $linker_flags $libobjs $deplibs'
+ case $host_cpu in
+ hppa*64*)
+ archive_cmds_CXX='$CC -b ${wl}+h ${wl}$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
+ ;;
+ ia64*)
+ archive_cmds_CXX='$CC -b ${wl}+h ${wl}$soname ${wl}+nodefaultrpath -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
;;
*)
archive_cmds_CXX='$CC -b ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
@@ -10468,9 +10637,12 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
*)
if test "$GXX" = yes; then
if test $with_gnu_ld = no; then
- case "$host_cpu" in
- ia64*|hppa*64*)
- archive_cmds_CXX='$LD -b +h $soname -o $lib $linker_flags $libobjs $deplibs'
+ case $host_cpu in
+ hppa*64*)
+ archive_cmds_CXX='$CC -shared -nostdlib -fPIC ${wl}+h ${wl}$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
+ ;;
+ ia64*)
+ archive_cmds_CXX='$CC -shared -nostdlib -fPIC ${wl}+h ${wl}$soname ${wl}+nodefaultrpath -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
;;
*)
archive_cmds_CXX='$CC -shared -nostdlib -fPIC ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
@@ -10484,6 +10656,20 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
;;
esac
;;
+ interix3*)
+ hardcode_direct_CXX=no
+ hardcode_shlibpath_var_CXX=no
+ hardcode_libdir_flag_spec_CXX='${wl}-rpath,$libdir'
+ export_dynamic_flag_spec_CXX='${wl}-E'
+ # Hack: On Interix 3.x, we cannot compile PIC because of a broken gcc.
+ # Instead, shared libraries are loaded at an image base (0x10000000 by
+ # default) and relocated if they conflict, which is a slow very memory
+ # consuming and fragmenting process. To avoid this, we pick a random,
+ # 256 KiB-aligned image base between 0x50000000 and 0x6FFC0000 at link
+ # time. Moving up from 0x10000000 also allows more sbrk(2) space.
+ archive_cmds_CXX='$CC -shared $pic_flag $libobjs $deplibs $compiler_flags ${wl}-h,$soname ${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
+ archive_expsym_cmds_CXX='sed "s,^,_," $export_symbols >$output_objdir/$soname.expsym~$CC -shared $pic_flag $libobjs $deplibs $compiler_flags ${wl}-h,$soname ${wl}--retain-symbols-file,$output_objdir/$soname.expsym ${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
+ ;;
irix5* | irix6*)
case $cc_basename in
CC*)
@@ -10569,7 +10755,7 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
hardcode_libdir_flag_spec_CXX='${wl}--rpath ${wl}$libdir'
export_dynamic_flag_spec_CXX='${wl}--export-dynamic'
- whole_archive_flag_spec_CXX='${wl}--whole-archive,`for conv in $convenience\"\"; do test -n \"$conv\" && new_convenience=\"$new_convenience,$conv\"; done; $echo \"$new_convenience\"` ${wl}--no-whole-archive'
+ whole_archive_flag_spec_CXX='${wl}--whole-archive`for conv in $convenience\"\"; do test -n \"$conv\" && new_convenience=\"$new_convenience,$conv\"; done; $echo \"$new_convenience\"` ${wl}--no-whole-archive'
;;
cxx*)
# Compaq C++
@@ -10766,19 +10952,6 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
# FIXME: insert proper C++ library support
ld_shlibs_CXX=no
;;
- sco*)
- archive_cmds_need_lc_CXX=no
- case $cc_basename in
- CC*)
- # FIXME: insert proper C++ library support
- ld_shlibs_CXX=no
- ;;
- *)
- # FIXME: insert proper C++ library support
- ld_shlibs_CXX=no
- ;;
- esac
- ;;
sunos4*)
case $cc_basename in
CC*)
@@ -10801,10 +10974,11 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
case $cc_basename in
CC*)
# Sun C++ 4.2, 5.x and Centerline C++
+ archive_cmds_need_lc_CXX=yes
no_undefined_flag_CXX=' -zdefs'
- archive_cmds_CXX='$CC -G${allow_undefined_flag} -nolib -h$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
+ archive_cmds_CXX='$CC -G${allow_undefined_flag} -h$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
archive_expsym_cmds_CXX='$echo "{ global:" > $lib.exp~cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >> $lib.exp~$echo "local: *; };" >> $lib.exp~
- $CC -G${allow_undefined_flag} -nolib ${wl}-M ${wl}$lib.exp -h$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~$rm $lib.exp'
+ $CC -G${allow_undefined_flag} ${wl}-M ${wl}$lib.exp -h$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~$rm $lib.exp'
hardcode_libdir_flag_spec_CXX='-R$libdir'
hardcode_shlibpath_var_CXX=no
@@ -10824,15 +10998,7 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
esac
link_all_deplibs_CXX=yes
- # Commands to make compiler produce verbose output that lists
- # what "hidden" libraries, object files and flags are used when
- # linking a shared library.
- #
- # There doesn't appear to be a way to prevent this compiler from
- # explicitly linking system object files so we need to strip them
- # from the output so that they don't get included in the library
- # dependencies.
- output_verbose_link_cmd='templist=`$CC -G $CFLAGS -v conftest.$objext 2>&1 | grep "\-[LR]"`; list=""; for z in $templist; do case $z in conftest.$objext) list="$list $z";; *.$objext);; *) list="$list $z";;esac; done; echo $list'
+ output_verbose_link_cmd='echo'
# Archives containing C++ object files must be created using
# "CC -xar", where "CC" is the Sun C++ compiler. This is
@@ -10878,8 +11044,59 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
;;
esac
;;
- sysv5OpenUNIX8* | sysv5UnixWare7* | sysv5uw[78]* | unixware7*)
+ sysv4*uw2* | sysv5OpenUNIX* | sysv5UnixWare7.[01].[10]* | unixware7* | sco3.2v5.0.[024]*)
+ no_undefined_flag_CXX='${wl}-z,text'
+ archive_cmds_need_lc_CXX=no
+ hardcode_shlibpath_var_CXX=no
+ runpath_var='LD_RUN_PATH'
+
+ case $cc_basename in
+ CC*)
+ archive_cmds_CXX='$CC -G ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
+ archive_expsym_cmds_CXX='$CC -G ${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
+ ;;
+ *)
+ archive_cmds_CXX='$CC -shared ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
+ archive_expsym_cmds_CXX='$CC -shared ${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
+ ;;
+ esac
+ ;;
+ sysv5* | sco3.2v5* | sco5v6*)
+ # Note: We can NOT use -z defs as we might desire, because we do not
+ # link with -lc, and that would cause any symbols used from libc to
+ # always be unresolved, which means just about no library would
+ # ever link correctly. If we're not using GNU ld we use -z text
+ # though, which does catch some bad symbols but isn't as heavy-handed
+ # as -z defs.
+ # For security reasons, it is highly recommended that you always
+ # use absolute paths for naming shared libraries, and exclude the
+ # DT_RUNPATH tag from executables and libraries. But doing so
+ # requires that you compile everything twice, which is a pain.
+ # So that behaviour is only enabled if SCOABSPATH is set to a
+ # non-empty value in the environment. Most likely only useful for
+ # creating official distributions of packages.
+ # This is a hack until libtool officially supports absolute path
+ # names for shared libraries.
+ no_undefined_flag_CXX='${wl}-z,text'
+ allow_undefined_flag_CXX='${wl}-z,nodefs'
archive_cmds_need_lc_CXX=no
+ hardcode_shlibpath_var_CXX=no
+ hardcode_libdir_flag_spec_CXX='`test -z "$SCOABSPATH" && echo ${wl}-R,$libdir`'
+ hardcode_libdir_separator_CXX=':'
+ link_all_deplibs_CXX=yes
+ export_dynamic_flag_spec_CXX='${wl}-Bexport'
+ runpath_var='LD_RUN_PATH'
+
+ case $cc_basename in
+ CC*)
+ archive_cmds_CXX='$CC -G ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+ archive_expsym_cmds_CXX='$CC -G ${wl}-Bexport:$export_symbols ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+ ;;
+ *)
+ archive_cmds_CXX='$CC -shared ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+ archive_expsym_cmds_CXX='$CC -shared ${wl}-Bexport:$export_symbols ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+ ;;
+ esac
;;
tandem*)
case $cc_basename in
@@ -10936,7 +11153,7 @@ if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
# The `*' in the case matches for architectures that use `case' in
# $output_verbose_cmd can trigger glob expansion during the loop
# eval without this substitution.
- output_verbose_link_cmd="`$echo \"X$output_verbose_link_cmd\" | $Xsed -e \"$no_glob_subst\"`"
+ output_verbose_link_cmd=`$echo "X$output_verbose_link_cmd" | $Xsed -e "$no_glob_subst"`
for p in `eval $output_verbose_link_cmd`; do
case $p in
@@ -11012,6 +11229,29 @@ fi
$rm -f confest.$objext
+# PORTME: override above test on systems where it is broken
+case $host_os in
+interix3*)
+ # Interix 3.5 installs completely hosed .la files for C++, so rather than
+ # hack all around it, let's just trust "g++" to DTRT.
+ predep_objects_CXX=
+ postdep_objects_CXX=
+ postdeps_CXX=
+ ;;
+
+solaris*)
+ case $cc_basename in
+ CC*)
+ # Adding this requires a known-good setup of shared libraries for
+ # Sun compiler versions before 5.6, else PIC objects from an old
+ # archive will be linked into the output, leading to subtle bugs.
+ postdeps_CXX='-lCstd -lCrun'
+ ;;
+ esac
+ ;;
+esac
+
+
case " $postdeps_CXX " in
*" -lc "*) archive_cmds_need_lc_CXX=no ;;
esac
@@ -11059,6 +11299,10 @@ echo $ECHO_N "checking for $compiler option to produce PIC... $ECHO_C" >&6
# DJGPP does not support shared libraries at all
lt_prog_compiler_pic_CXX=
;;
+ interix3*)
+ # Interix 3.x gcc -fpic/-fPIC options generate broken code.
+ # Instead, we relocate shared libraries at runtime.
+ ;;
sysv4*MP*)
if test -d /usr/nec; then
lt_prog_compiler_pic_CXX=-Kconform_pic
@@ -11067,7 +11311,7 @@ echo $ECHO_N "checking for $compiler option to produce PIC... $ECHO_C" >&6
hpux*)
# PIC is the default for IA64 HP-UX and 64-bit HP-UX, but
# not for PA HP-UX.
- case "$host_cpu" in
+ case $host_cpu in
hppa*64*|ia64*)
;;
*)
@@ -11128,15 +11372,15 @@ echo $ECHO_N "checking for $compiler option to produce PIC... $ECHO_C" >&6
case $cc_basename in
CC*)
lt_prog_compiler_wl_CXX='-Wl,'
- lt_prog_compiler_static_CXX="${ac_cv_prog_cc_wl}-a ${ac_cv_prog_cc_wl}archive"
+ lt_prog_compiler_static_CXX='${wl}-a ${wl}archive'
if test "$host_cpu" != ia64; then
lt_prog_compiler_pic_CXX='+Z'
fi
;;
aCC*)
lt_prog_compiler_wl_CXX='-Wl,'
- lt_prog_compiler_static_CXX="${ac_cv_prog_cc_wl}-a ${ac_cv_prog_cc_wl}archive"
- case "$host_cpu" in
+ lt_prog_compiler_static_CXX='${wl}-a ${wl}archive'
+ case $host_cpu in
hppa*64*|ia64*)
# +Z the default
;;
@@ -11149,6 +11393,10 @@ echo $ECHO_N "checking for $compiler option to produce PIC... $ECHO_C" >&6
;;
esac
;;
+ interix*)
+ # This is c89, which is MS Visual C++ (no shared libs)
+ # Anyone wants to do a port?
+ ;;
irix5* | irix6* | nonstopux*)
case $cc_basename in
CC*)
@@ -11177,7 +11425,7 @@ echo $ECHO_N "checking for $compiler option to produce PIC... $ECHO_C" >&6
# Portland Group C++ compiler.
lt_prog_compiler_wl_CXX='-Wl,'
lt_prog_compiler_pic_CXX='-fpic'
- lt_prog_compiler_static_CXX='-static'
+ lt_prog_compiler_static_CXX='-Bstatic'
;;
cxx*)
# Compaq C++
@@ -11228,15 +11476,6 @@ echo $ECHO_N "checking for $compiler option to produce PIC... $ECHO_C" >&6
;;
psos*)
;;
- sco*)
- case $cc_basename in
- CC*)
- lt_prog_compiler_pic_CXX='-fPIC'
- ;;
- *)
- ;;
- esac
- ;;
solaris*)
case $cc_basename in
CC*)
@@ -11278,7 +11517,14 @@ echo $ECHO_N "checking for $compiler option to produce PIC... $ECHO_C" >&6
;;
esac
;;
- unixware*)
+ sysv5* | unixware* | sco3.2v5* | sco5v6* | OpenUNIX*)
+ case $cc_basename in
+ CC*)
+ lt_prog_compiler_wl_CXX='-Wl,'
+ lt_prog_compiler_pic_CXX='-KPIC'
+ lt_prog_compiler_static_CXX='-Bstatic'
+ ;;
+ esac
;;
vxworks*)
;;
@@ -11311,20 +11557,20 @@ else
# with a dollar sign (not a hyphen), so the echo should work correctly.
# The option is referenced via a variable to avoid confusing sed.
lt_compile=`echo "$ac_compile" | $SED \
- -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
+ -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
-e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
-e 's:$: $lt_compiler_flag:'`
- (eval echo "\"\$as_me:11317: $lt_compile\"" >&5)
+ (eval echo "\"\$as_me:11563: $lt_compile\"" >&5)
(eval "$lt_compile" 2>conftest.err)
ac_status=$?
cat conftest.err >&5
- echo "$as_me:11321: \$? = $ac_status" >&5
+ echo "$as_me:11567: \$? = $ac_status" >&5
if (exit $ac_status) && test -s "$ac_outfile"; then
# The compiler can only warn and ignore the option if not recognized
# So say no if there are warnings other than the usual output.
- $echo "X$_lt_compiler_boilerplate" | $Xsed >conftest.exp
- $SED '/^$/d' conftest.err >conftest.er2
- if test ! -s conftest.err || diff conftest.exp conftest.er2 >/dev/null; then
+ $echo "X$_lt_compiler_boilerplate" | $Xsed -e '/^$/d' >conftest.exp
+ $SED '/^$/d; /^ *+/d' conftest.err >conftest.er2
+ if test ! -s conftest.er2 || diff conftest.exp conftest.er2 >/dev/null; then
lt_prog_compiler_pic_works_CXX=yes
fi
fi
@@ -11345,7 +11591,7 @@ else
fi
fi
-case "$host_os" in
+case $host_os in
# For platforms which do not support PIC, -DPIC is meaningless:
*djgpp*)
lt_prog_compiler_pic_CXX=
@@ -11355,6 +11601,48 @@ case "$host_os" in
;;
esac
+#
+# Check to make sure the static flag actually works.
+#
+wl=$lt_prog_compiler_wl_CXX eval lt_tmp_static_flag=\"$lt_prog_compiler_static_CXX\"
+echo "$as_me:$LINENO: checking if $compiler static flag $lt_tmp_static_flag works" >&5
+echo $ECHO_N "checking if $compiler static flag $lt_tmp_static_flag works... $ECHO_C" >&6
+if test "${lt_prog_compiler_static_works_CXX+set}" = set; then
+ echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+ lt_prog_compiler_static_works_CXX=no
+ save_LDFLAGS="$LDFLAGS"
+ LDFLAGS="$LDFLAGS $lt_tmp_static_flag"
+ printf "$lt_simple_link_test_code" > conftest.$ac_ext
+ if (eval $ac_link 2>conftest.err) && test -s conftest$ac_exeext; then
+ # The linker can only warn and ignore the option if not recognized
+ # So say no if there are warnings
+ if test -s conftest.err; then
+ # Append any errors to the config.log.
+ cat conftest.err 1>&5
+ $echo "X$_lt_linker_boilerplate" | $Xsed -e '/^$/d' > conftest.exp
+ $SED '/^$/d; /^ *+/d' conftest.err >conftest.er2
+ if diff conftest.exp conftest.er2 >/dev/null; then
+ lt_prog_compiler_static_works_CXX=yes
+ fi
+ else
+ lt_prog_compiler_static_works_CXX=yes
+ fi
+ fi
+ $rm conftest*
+ LDFLAGS="$save_LDFLAGS"
+
+fi
+echo "$as_me:$LINENO: result: $lt_prog_compiler_static_works_CXX" >&5
+echo "${ECHO_T}$lt_prog_compiler_static_works_CXX" >&6
+
+if test x"$lt_prog_compiler_static_works_CXX" = xyes; then
+ :
+else
+ lt_prog_compiler_static_CXX=
+fi
+
+
echo "$as_me:$LINENO: checking if $compiler supports -c -o file.$ac_objext" >&5
echo $ECHO_N "checking if $compiler supports -c -o file.$ac_objext... $ECHO_C" >&6
if test "${lt_cv_prog_compiler_c_o_CXX+set}" = set; then
@@ -11373,25 +11661,25 @@ else
# Note that $ac_compile itself does not contain backslashes and begins
# with a dollar sign (not a hyphen), so the echo should work correctly.
lt_compile=`echo "$ac_compile" | $SED \
- -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
+ -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
-e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
-e 's:$: $lt_compiler_flag:'`
- (eval echo "\"\$as_me:11379: $lt_compile\"" >&5)
+ (eval echo "\"\$as_me:11667: $lt_compile\"" >&5)
(eval "$lt_compile" 2>out/conftest.err)
ac_status=$?
cat out/conftest.err >&5
- echo "$as_me:11383: \$? = $ac_status" >&5
+ echo "$as_me:11671: \$? = $ac_status" >&5
if (exit $ac_status) && test -s out/conftest2.$ac_objext
then
# The compiler can only warn and ignore the option if not recognized
# So say no if there are warnings
- $echo "X$_lt_compiler_boilerplate" | $Xsed > out/conftest.exp
- $SED '/^$/d' out/conftest.err >out/conftest.er2
- if test ! -s out/conftest.err || diff out/conftest.exp out/conftest.er2 >/dev/null; then
+ $echo "X$_lt_compiler_boilerplate" | $Xsed -e '/^$/d' > out/conftest.exp
+ $SED '/^$/d; /^ *+/d' out/conftest.err >out/conftest.er2
+ if test ! -s out/conftest.er2 || diff out/conftest.exp out/conftest.er2 >/dev/null; then
lt_cv_prog_compiler_c_o_CXX=yes
fi
fi
- chmod u+w .
+ chmod u+w . 2>&5
$rm conftest*
# SGI C++ compiler will create directory out/ii_files/ for
# template instantiation
@@ -11457,11 +11745,6 @@ echo "$as_me:$LINENO: result: $ld_shlibs_CXX" >&5
echo "${ECHO_T}$ld_shlibs_CXX" >&6
test "$ld_shlibs_CXX" = no && can_build_shared=no
-variables_saved_for_relink="PATH $shlibpath_var $runpath_var"
-if test "$GCC" = yes; then
- variables_saved_for_relink="$variables_saved_for_relink GCC_EXEC_PREFIX COMPILER_PATH LIBRARY_PATH"
-fi
-
#
# Do we need to explicitly link libc?
#
@@ -11494,6 +11777,7 @@ echo $ECHO_N "checking whether -lc should be explicitly linked in... $ECHO_C" >&
libobjs=conftest.$ac_objext
deplibs=
wl=$lt_prog_compiler_wl_CXX
+ pic_flag=$lt_prog_compiler_pic_CXX
compiler_flags=-v
linker_flags=-v
verstring=
@@ -11654,7 +11938,8 @@ cygwin* | mingw* | pw32*)
dlpath=`$SHELL 2>&1 -c '\''. $dir/'\''\${base_file}'\''i;echo \$dlname'\''`~
dldir=$destdir/`dirname \$dlpath`~
test -d \$dldir || mkdir -p \$dldir~
- $install_prog $dir/$dlname \$dldir/$dlname'
+ $install_prog $dir/$dlname \$dldir/$dlname~
+ chmod a+x \$dldir/$dlname'
postuninstall_cmds='dldll=`$SHELL 2>&1 -c '\''. $file; echo \$dlname'\''`~
dlpath=$dir/\$dldll~
$rm \$dlpath'
@@ -11707,7 +11992,7 @@ darwin* | rhapsody*)
soname_spec='${libname}${release}${major}$shared_ext'
shlibpath_overrides_runpath=yes
shlibpath_var=DYLD_LIBRARY_PATH
- shrext_cmds='$(test .$module = .yes && echo .so || echo .dylib)'
+ shrext_cmds='`test .$module = .yes && echo .so || echo .dylib`'
# Apple's gcc prints 'gcc -print-search-dirs' doesn't operate the same.
if test "$GCC" = yes; then
sys_lib_search_path_spec=`$CC -print-search-dirs | tr "\n" "$PATH_SEPARATOR" | sed -e 's/libraries:/@libraries:/' | tr "@" "\n" | grep "^libraries:" | sed -e "s/^libraries://" -e "s,=/,/,g" -e "s,$PATH_SEPARATOR, ,g" -e "s,.*,& /lib /usr/lib /usr/local/lib,g"`
@@ -11745,7 +12030,14 @@ kfreebsd*-gnu)
freebsd* | dragonfly*)
# DragonFly does not have aout. When/if they implement a new
# versioning mechanism, adjust this.
- objformat=`test -x /usr/bin/objformat && /usr/bin/objformat || echo aout`
+ if test -x /usr/bin/objformat; then
+ objformat=`/usr/bin/objformat`
+ else
+ case $host_os in
+ freebsd[123]*) objformat=aout ;;
+ *) objformat=elf ;;
+ esac
+ fi
version_type=freebsd-$objformat
case $version_type in
freebsd-elf*)
@@ -11767,10 +12059,15 @@ freebsd* | dragonfly*)
shlibpath_overrides_runpath=yes
hardcode_into_libs=yes
;;
- *) # from 3.2 on
+ freebsd3.[2-9]* | freebsdelf3.[2-9]* | \
+ freebsd4.[0-5] | freebsdelf4.[0-5] | freebsd4.1.1 | freebsdelf4.1.1)
shlibpath_overrides_runpath=no
hardcode_into_libs=yes
;;
+ freebsd*) # from 4.6 on
+ shlibpath_overrides_runpath=yes
+ hardcode_into_libs=yes
+ ;;
esac
;;
@@ -11790,7 +12087,7 @@ hpux9* | hpux10* | hpux11*)
version_type=sunos
need_lib_prefix=no
need_version=no
- case "$host_cpu" in
+ case $host_cpu in
ia64*)
shrext_cmds='.so'
hardcode_into_libs=yes
@@ -11830,6 +12127,18 @@ hpux9* | hpux10* | hpux11*)
postinstall_cmds='chmod 555 $lib'
;;
+interix3*)
+ version_type=linux
+ need_lib_prefix=no
+ need_version=no
+ library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major ${libname}${shared_ext}'
+ soname_spec='${libname}${release}${shared_ext}$major'
+ dynamic_linker='Interix 3.x ld.so.1 (PE, like ELF)'
+ shlibpath_var=LD_LIBRARY_PATH
+ shlibpath_overrides_runpath=no
+ hardcode_into_libs=yes
+ ;;
+
irix5* | irix6* | nonstopux*)
case $host_os in
nonstopux*) version_type=nonstopux ;;
@@ -11951,6 +12260,7 @@ nto-qnx*)
openbsd*)
version_type=sunos
+ sys_lib_dlsearch_path_spec="/usr/lib"
need_lib_prefix=no
# Some older versions of OpenBSD (3.3 at least) *do* need versioned libs.
case $host_os in
@@ -11994,13 +12304,6 @@ osf3* | osf4* | osf5*)
sys_lib_dlsearch_path_spec="$sys_lib_search_path_spec"
;;
-sco3.2v5*)
- version_type=osf
- soname_spec='${libname}${release}${shared_ext}$major'
- library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
- shlibpath_var=LD_LIBRARY_PATH
- ;;
-
solaris*)
version_type=linux
need_lib_prefix=no
@@ -12026,7 +12329,7 @@ sunos4*)
need_version=yes
;;
-sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
+sysv4 | sysv4.3*)
version_type=linux
library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
soname_spec='${libname}${release}${shared_ext}$major'
@@ -12059,6 +12362,29 @@ sysv4*MP*)
fi
;;
+sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX* | sysv4*uw2*)
+ version_type=freebsd-elf
+ need_lib_prefix=no
+ need_version=no
+ library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext} $libname${shared_ext}'
+ soname_spec='${libname}${release}${shared_ext}$major'
+ shlibpath_var=LD_LIBRARY_PATH
+ hardcode_into_libs=yes
+ if test "$with_gnu_ld" = yes; then
+ sys_lib_search_path_spec='/usr/local/lib /usr/gnu/lib /usr/ccs/lib /usr/lib /lib'
+ shlibpath_overrides_runpath=no
+ else
+ sys_lib_search_path_spec='/usr/ccs/lib /usr/lib'
+ shlibpath_overrides_runpath=yes
+ case $host_os in
+ sco3.2v5*)
+ sys_lib_search_path_spec="$sys_lib_search_path_spec /lib"
+ ;;
+ esac
+ fi
+ sys_lib_dlsearch_path_spec='/usr/lib'
+ ;;
+
uts4*)
version_type=linux
library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
@@ -12074,6 +12400,11 @@ echo "$as_me:$LINENO: result: $dynamic_linker" >&5
echo "${ECHO_T}$dynamic_linker" >&6
test "$dynamic_linker" = no && can_build_shared=no
+variables_saved_for_relink="PATH $shlibpath_var $runpath_var"
+if test "$GCC" = yes; then
+ variables_saved_for_relink="$variables_saved_for_relink GCC_EXEC_PREFIX COMPILER_PATH LIBRARY_PATH"
+fi
+
echo "$as_me:$LINENO: checking how to hardcode library paths into programs" >&5
echo $ECHO_N "checking how to hardcode library paths into programs... $ECHO_C" >&6
hardcode_action_CXX=
@@ -12111,1147 +12442,315 @@ elif test "$shlibpath_overrides_runpath" = yes ||
enable_fast_install=needless
fi
-striplib=
-old_striplib=
-echo "$as_me:$LINENO: checking whether stripping libraries is possible" >&5
-echo $ECHO_N "checking whether stripping libraries is possible... $ECHO_C" >&6
-if test -n "$STRIP" && $STRIP -V 2>&1 | grep "GNU strip" >/dev/null; then
- test -z "$old_striplib" && old_striplib="$STRIP --strip-debug"
- test -z "$striplib" && striplib="$STRIP --strip-unneeded"
- echo "$as_me:$LINENO: result: yes" >&5
-echo "${ECHO_T}yes" >&6
-else
-# FIXME - insert some real tests, host_os isn't really good enough
- case $host_os in
- darwin*)
- if test -n "$STRIP" ; then
- striplib="$STRIP -x"
- echo "$as_me:$LINENO: result: yes" >&5
-echo "${ECHO_T}yes" >&6
- else
- echo "$as_me:$LINENO: result: no" >&5
-echo "${ECHO_T}no" >&6
-fi
- ;;
- *)
- echo "$as_me:$LINENO: result: no" >&5
-echo "${ECHO_T}no" >&6
- ;;
- esac
-fi
-
-if test "x$enable_dlopen" != xyes; then
- enable_dlopen=unknown
- enable_dlopen_self=unknown
- enable_dlopen_self_static=unknown
-else
- lt_cv_dlopen=no
- lt_cv_dlopen_libs=
-
- case $host_os in
- beos*)
- lt_cv_dlopen="load_add_on"
- lt_cv_dlopen_libs=
- lt_cv_dlopen_self=yes
- ;;
-
- mingw* | pw32*)
- lt_cv_dlopen="LoadLibrary"
- lt_cv_dlopen_libs=
- ;;
- cygwin*)
- lt_cv_dlopen="dlopen"
- lt_cv_dlopen_libs=
- ;;
+# The else clause should only fire when bootstrapping the
+# libtool distribution, otherwise you forgot to ship ltmain.sh
+# with your package, and you will get complaints that there are
+# no rules to generate ltmain.sh.
+if test -f "$ltmain"; then
+ # See if we are running on zsh, and set the options which allow our commands through
+ # without removal of \ escapes.
+ if test -n "${ZSH_VERSION+set}" ; then
+ setopt NO_GLOB_SUBST
+ fi
+ # Now quote all the things that may contain metacharacters while being
+ # careful not to overquote the AC_SUBSTed values. We take copies of the
+ # variables and quote the copies for generation of the libtool script.
+ for var in echo old_CC old_CFLAGS AR AR_FLAGS EGREP RANLIB LN_S LTCC LTCFLAGS NM \
+ SED SHELL STRIP \
+ libname_spec library_names_spec soname_spec extract_expsyms_cmds \
+ old_striplib striplib file_magic_cmd finish_cmds finish_eval \
+ deplibs_check_method reload_flag reload_cmds need_locks \
+ lt_cv_sys_global_symbol_pipe lt_cv_sys_global_symbol_to_cdecl \
+ lt_cv_sys_global_symbol_to_c_name_address \
+ sys_lib_search_path_spec sys_lib_dlsearch_path_spec \
+ old_postinstall_cmds old_postuninstall_cmds \
+ compiler_CXX \
+ CC_CXX \
+ LD_CXX \
+ lt_prog_compiler_wl_CXX \
+ lt_prog_compiler_pic_CXX \
+ lt_prog_compiler_static_CXX \
+ lt_prog_compiler_no_builtin_flag_CXX \
+ export_dynamic_flag_spec_CXX \
+ thread_safe_flag_spec_CXX \
+ whole_archive_flag_spec_CXX \
+ enable_shared_with_static_runtimes_CXX \
+ old_archive_cmds_CXX \
+ old_archive_from_new_cmds_CXX \
+ predep_objects_CXX \
+ postdep_objects_CXX \
+ predeps_CXX \
+ postdeps_CXX \
+ compiler_lib_search_path_CXX \
+ archive_cmds_CXX \
+ archive_expsym_cmds_CXX \
+ postinstall_cmds_CXX \
+ postuninstall_cmds_CXX \
+ old_archive_from_expsyms_cmds_CXX \
+ allow_undefined_flag_CXX \
+ no_undefined_flag_CXX \
+ export_symbols_cmds_CXX \
+ hardcode_libdir_flag_spec_CXX \
+ hardcode_libdir_flag_spec_ld_CXX \
+ hardcode_libdir_separator_CXX \
+ hardcode_automatic_CXX \
+ module_cmds_CXX \
+ module_expsym_cmds_CXX \
+ lt_cv_prog_compiler_c_o_CXX \
+ exclude_expsyms_CXX \
+ include_expsyms_CXX; do
- darwin*)
- # if libdl is installed we need to link against it
- echo "$as_me:$LINENO: checking for dlopen in -ldl" >&5
-echo $ECHO_N "checking for dlopen in -ldl... $ECHO_C" >&6
-if test "${ac_cv_lib_dl_dlopen+set}" = set; then
- echo $ECHO_N "(cached) $ECHO_C" >&6
-else
- ac_check_lib_save_LIBS=$LIBS
-LIBS="-ldl $LIBS"
-cat >conftest.$ac_ext <<_ACEOF
-/* confdefs.h. */
-_ACEOF
-cat confdefs.h >>conftest.$ac_ext
-cat >>conftest.$ac_ext <<_ACEOF
-/* end confdefs.h. */
+ case $var in
+ old_archive_cmds_CXX | \
+ old_archive_from_new_cmds_CXX | \
+ archive_cmds_CXX | \
+ archive_expsym_cmds_CXX | \
+ module_cmds_CXX | \
+ module_expsym_cmds_CXX | \
+ old_archive_from_expsyms_cmds_CXX | \
+ export_symbols_cmds_CXX | \
+ extract_expsyms_cmds | reload_cmds | finish_cmds | \
+ postinstall_cmds | postuninstall_cmds | \
+ old_postinstall_cmds | old_postuninstall_cmds | \
+ sys_lib_search_path_spec | sys_lib_dlsearch_path_spec)
+ # Double-quote double-evaled strings.
+ eval "lt_$var=\\\"\`\$echo \"X\$$var\" | \$Xsed -e \"\$double_quote_subst\" -e \"\$sed_quote_subst\" -e \"\$delay_variable_subst\"\`\\\""
+ ;;
+ *)
+ eval "lt_$var=\\\"\`\$echo \"X\$$var\" | \$Xsed -e \"\$sed_quote_subst\"\`\\\""
+ ;;
+ esac
+ done
-/* Override any gcc2 internal prototype to avoid an error. */
-#ifdef __cplusplus
-extern "C"
-#endif
-/* We use char because int might match the return type of a gcc2
- builtin and then its argument prototype would still apply. */
-char dlopen ();
-int
-main ()
-{
-dlopen ();
- ;
- return 0;
-}
-_ACEOF
-rm -f conftest.$ac_objext conftest$ac_exeext
-if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
- (eval $ac_link) 2>conftest.er1
- ac_status=$?
- grep -v '^ *+' conftest.er1 >conftest.err
- rm -f conftest.er1
- cat conftest.err >&5
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); } &&
- { ac_try='test -z "$ac_cxx_werror_flag"
- || test ! -s conftest.err'
- { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); }; } &&
- { ac_try='test -s conftest$ac_exeext'
- { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); }; }; then
- ac_cv_lib_dl_dlopen=yes
-else
- echo "$as_me: failed program was:" >&5
-sed 's/^/| /' conftest.$ac_ext >&5
+ case $lt_echo in
+ *'\$0 --fallback-echo"')
+ lt_echo=`$echo "X$lt_echo" | $Xsed -e 's/\\\\\\\$0 --fallback-echo"$/$0 --fallback-echo"/'`
+ ;;
+ esac
-ac_cv_lib_dl_dlopen=no
-fi
-rm -f conftest.err conftest.$ac_objext \
- conftest$ac_exeext conftest.$ac_ext
-LIBS=$ac_check_lib_save_LIBS
-fi
-echo "$as_me:$LINENO: result: $ac_cv_lib_dl_dlopen" >&5
-echo "${ECHO_T}$ac_cv_lib_dl_dlopen" >&6
-if test $ac_cv_lib_dl_dlopen = yes; then
- lt_cv_dlopen="dlopen" lt_cv_dlopen_libs="-ldl"
-else
+cfgfile="$ofile"
- lt_cv_dlopen="dyld"
- lt_cv_dlopen_libs=
- lt_cv_dlopen_self=yes
+ cat <<__EOF__ >> "$cfgfile"
+# ### BEGIN LIBTOOL TAG CONFIG: $tagname
-fi
+# Libtool was configured on host `(hostname || uname -n) 2>/dev/null | sed 1q`:
- ;;
+# Shell to use when invoking shell scripts.
+SHELL=$lt_SHELL
- *)
- echo "$as_me:$LINENO: checking for shl_load" >&5
-echo $ECHO_N "checking for shl_load... $ECHO_C" >&6
-if test "${ac_cv_func_shl_load+set}" = set; then
- echo $ECHO_N "(cached) $ECHO_C" >&6
-else
- cat >conftest.$ac_ext <<_ACEOF
-/* confdefs.h. */
-_ACEOF
-cat confdefs.h >>conftest.$ac_ext
-cat >>conftest.$ac_ext <<_ACEOF
-/* end confdefs.h. */
-/* Define shl_load to an innocuous variant, in case <limits.h> declares shl_load.
- For example, HP-UX 11i <limits.h> declares gettimeofday. */
-#define shl_load innocuous_shl_load
+# Whether or not to build shared libraries.
+build_libtool_libs=$enable_shared
-/* System header to define __stub macros and hopefully few prototypes,
- which can conflict with char shl_load (); below.
- Prefer <limits.h> to <assert.h> if __STDC__ is defined, since
- <limits.h> exists even on freestanding compilers. */
+# Whether or not to build static libraries.
+build_old_libs=$enable_static
-#ifdef __STDC__
-# include <limits.h>
-#else
-# include <assert.h>
-#endif
+# Whether or not to add -lc for building shared libraries.
+build_libtool_need_lc=$archive_cmds_need_lc_CXX
-#undef shl_load
+# Whether or not to disallow shared libs when runtime libs are static
+allow_libtool_libs_with_static_runtimes=$enable_shared_with_static_runtimes_CXX
-/* Override any gcc2 internal prototype to avoid an error. */
-#ifdef __cplusplus
-extern "C"
-{
-#endif
-/* We use char because int might match the return type of a gcc2
- builtin and then its argument prototype would still apply. */
-char shl_load ();
-/* The GNU C library defines this for functions which it implements
- to always fail with ENOSYS. Some functions are actually named
- something starting with __ and the normal name is an alias. */
-#if defined (__stub_shl_load) || defined (__stub___shl_load)
-choke me
-#else
-char (*f) () = shl_load;
-#endif
-#ifdef __cplusplus
-}
-#endif
+# Whether or not to optimize for fast installation.
+fast_install=$enable_fast_install
-int
-main ()
-{
-return f != shl_load;
- ;
- return 0;
-}
-_ACEOF
-rm -f conftest.$ac_objext conftest$ac_exeext
-if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
- (eval $ac_link) 2>conftest.er1
- ac_status=$?
- grep -v '^ *+' conftest.er1 >conftest.err
- rm -f conftest.er1
- cat conftest.err >&5
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); } &&
- { ac_try='test -z "$ac_cxx_werror_flag"
- || test ! -s conftest.err'
- { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); }; } &&
- { ac_try='test -s conftest$ac_exeext'
- { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); }; }; then
- ac_cv_func_shl_load=yes
-else
- echo "$as_me: failed program was:" >&5
-sed 's/^/| /' conftest.$ac_ext >&5
+# The host system.
+host_alias=$host_alias
+host=$host
+host_os=$host_os
-ac_cv_func_shl_load=no
-fi
-rm -f conftest.err conftest.$ac_objext \
- conftest$ac_exeext conftest.$ac_ext
-fi
-echo "$as_me:$LINENO: result: $ac_cv_func_shl_load" >&5
-echo "${ECHO_T}$ac_cv_func_shl_load" >&6
-if test $ac_cv_func_shl_load = yes; then
- lt_cv_dlopen="shl_load"
-else
- echo "$as_me:$LINENO: checking for shl_load in -ldld" >&5
-echo $ECHO_N "checking for shl_load in -ldld... $ECHO_C" >&6
-if test "${ac_cv_lib_dld_shl_load+set}" = set; then
- echo $ECHO_N "(cached) $ECHO_C" >&6
-else
- ac_check_lib_save_LIBS=$LIBS
-LIBS="-ldld $LIBS"
-cat >conftest.$ac_ext <<_ACEOF
-/* confdefs.h. */
-_ACEOF
-cat confdefs.h >>conftest.$ac_ext
-cat >>conftest.$ac_ext <<_ACEOF
-/* end confdefs.h. */
+# The build system.
+build_alias=$build_alias
+build=$build
+build_os=$build_os
-/* Override any gcc2 internal prototype to avoid an error. */
-#ifdef __cplusplus
-extern "C"
-#endif
-/* We use char because int might match the return type of a gcc2
- builtin and then its argument prototype would still apply. */
-char shl_load ();
-int
-main ()
-{
-shl_load ();
- ;
- return 0;
-}
-_ACEOF
-rm -f conftest.$ac_objext conftest$ac_exeext
-if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
- (eval $ac_link) 2>conftest.er1
- ac_status=$?
- grep -v '^ *+' conftest.er1 >conftest.err
- rm -f conftest.er1
- cat conftest.err >&5
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); } &&
- { ac_try='test -z "$ac_cxx_werror_flag"
- || test ! -s conftest.err'
- { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); }; } &&
- { ac_try='test -s conftest$ac_exeext'
- { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); }; }; then
- ac_cv_lib_dld_shl_load=yes
-else
- echo "$as_me: failed program was:" >&5
-sed 's/^/| /' conftest.$ac_ext >&5
+# An echo program that does not interpret backslashes.
+echo=$lt_echo
-ac_cv_lib_dld_shl_load=no
-fi
-rm -f conftest.err conftest.$ac_objext \
- conftest$ac_exeext conftest.$ac_ext
-LIBS=$ac_check_lib_save_LIBS
-fi
-echo "$as_me:$LINENO: result: $ac_cv_lib_dld_shl_load" >&5
-echo "${ECHO_T}$ac_cv_lib_dld_shl_load" >&6
-if test $ac_cv_lib_dld_shl_load = yes; then
- lt_cv_dlopen="shl_load" lt_cv_dlopen_libs="-dld"
-else
- echo "$as_me:$LINENO: checking for dlopen" >&5
-echo $ECHO_N "checking for dlopen... $ECHO_C" >&6
-if test "${ac_cv_func_dlopen+set}" = set; then
- echo $ECHO_N "(cached) $ECHO_C" >&6
-else
- cat >conftest.$ac_ext <<_ACEOF
-/* confdefs.h. */
-_ACEOF
-cat confdefs.h >>conftest.$ac_ext
-cat >>conftest.$ac_ext <<_ACEOF
-/* end confdefs.h. */
-/* Define dlopen to an innocuous variant, in case <limits.h> declares dlopen.
- For example, HP-UX 11i <limits.h> declares gettimeofday. */
-#define dlopen innocuous_dlopen
+# The archiver.
+AR=$lt_AR
+AR_FLAGS=$lt_AR_FLAGS
-/* System header to define __stub macros and hopefully few prototypes,
- which can conflict with char dlopen (); below.
- Prefer <limits.h> to <assert.h> if __STDC__ is defined, since
- <limits.h> exists even on freestanding compilers. */
+# A C compiler.
+LTCC=$lt_LTCC
-#ifdef __STDC__
-# include <limits.h>
-#else
-# include <assert.h>
-#endif
+# LTCC compiler flags.
+LTCFLAGS=$lt_LTCFLAGS
-#undef dlopen
+# A language-specific compiler.
+CC=$lt_compiler_CXX
-/* Override any gcc2 internal prototype to avoid an error. */
-#ifdef __cplusplus
-extern "C"
-{
-#endif
-/* We use char because int might match the return type of a gcc2
- builtin and then its argument prototype would still apply. */
-char dlopen ();
-/* The GNU C library defines this for functions which it implements
- to always fail with ENOSYS. Some functions are actually named
- something starting with __ and the normal name is an alias. */
-#if defined (__stub_dlopen) || defined (__stub___dlopen)
-choke me
-#else
-char (*f) () = dlopen;
-#endif
-#ifdef __cplusplus
-}
-#endif
+# Is the compiler the GNU C compiler?
+with_gcc=$GCC_CXX
-int
-main ()
-{
-return f != dlopen;
- ;
- return 0;
-}
-_ACEOF
-rm -f conftest.$ac_objext conftest$ac_exeext
-if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
- (eval $ac_link) 2>conftest.er1
- ac_status=$?
- grep -v '^ *+' conftest.er1 >conftest.err
- rm -f conftest.er1
- cat conftest.err >&5
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); } &&
- { ac_try='test -z "$ac_cxx_werror_flag"
- || test ! -s conftest.err'
- { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); }; } &&
- { ac_try='test -s conftest$ac_exeext'
- { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); }; }; then
- ac_cv_func_dlopen=yes
-else
- echo "$as_me: failed program was:" >&5
-sed 's/^/| /' conftest.$ac_ext >&5
+# An ERE matcher.
+EGREP=$lt_EGREP
-ac_cv_func_dlopen=no
-fi
-rm -f conftest.err conftest.$ac_objext \
- conftest$ac_exeext conftest.$ac_ext
-fi
-echo "$as_me:$LINENO: result: $ac_cv_func_dlopen" >&5
-echo "${ECHO_T}$ac_cv_func_dlopen" >&6
-if test $ac_cv_func_dlopen = yes; then
- lt_cv_dlopen="dlopen"
-else
- echo "$as_me:$LINENO: checking for dlopen in -ldl" >&5
-echo $ECHO_N "checking for dlopen in -ldl... $ECHO_C" >&6
-if test "${ac_cv_lib_dl_dlopen+set}" = set; then
- echo $ECHO_N "(cached) $ECHO_C" >&6
-else
- ac_check_lib_save_LIBS=$LIBS
-LIBS="-ldl $LIBS"
-cat >conftest.$ac_ext <<_ACEOF
-/* confdefs.h. */
-_ACEOF
-cat confdefs.h >>conftest.$ac_ext
-cat >>conftest.$ac_ext <<_ACEOF
-/* end confdefs.h. */
+# The linker used to build libraries.
+LD=$lt_LD_CXX
-/* Override any gcc2 internal prototype to avoid an error. */
-#ifdef __cplusplus
-extern "C"
-#endif
-/* We use char because int might match the return type of a gcc2
- builtin and then its argument prototype would still apply. */
-char dlopen ();
-int
-main ()
-{
-dlopen ();
- ;
- return 0;
-}
-_ACEOF
-rm -f conftest.$ac_objext conftest$ac_exeext
-if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
- (eval $ac_link) 2>conftest.er1
- ac_status=$?
- grep -v '^ *+' conftest.er1 >conftest.err
- rm -f conftest.er1
- cat conftest.err >&5
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); } &&
- { ac_try='test -z "$ac_cxx_werror_flag"
- || test ! -s conftest.err'
- { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); }; } &&
- { ac_try='test -s conftest$ac_exeext'
- { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); }; }; then
- ac_cv_lib_dl_dlopen=yes
-else
- echo "$as_me: failed program was:" >&5
-sed 's/^/| /' conftest.$ac_ext >&5
+# Whether we need hard or soft links.
+LN_S=$lt_LN_S
-ac_cv_lib_dl_dlopen=no
-fi
-rm -f conftest.err conftest.$ac_objext \
- conftest$ac_exeext conftest.$ac_ext
-LIBS=$ac_check_lib_save_LIBS
-fi
-echo "$as_me:$LINENO: result: $ac_cv_lib_dl_dlopen" >&5
-echo "${ECHO_T}$ac_cv_lib_dl_dlopen" >&6
-if test $ac_cv_lib_dl_dlopen = yes; then
- lt_cv_dlopen="dlopen" lt_cv_dlopen_libs="-ldl"
-else
- echo "$as_me:$LINENO: checking for dlopen in -lsvld" >&5
-echo $ECHO_N "checking for dlopen in -lsvld... $ECHO_C" >&6
-if test "${ac_cv_lib_svld_dlopen+set}" = set; then
- echo $ECHO_N "(cached) $ECHO_C" >&6
-else
- ac_check_lib_save_LIBS=$LIBS
-LIBS="-lsvld $LIBS"
-cat >conftest.$ac_ext <<_ACEOF
-/* confdefs.h. */
-_ACEOF
-cat confdefs.h >>conftest.$ac_ext
-cat >>conftest.$ac_ext <<_ACEOF
-/* end confdefs.h. */
+# A BSD-compatible nm program.
+NM=$lt_NM
-/* Override any gcc2 internal prototype to avoid an error. */
-#ifdef __cplusplus
-extern "C"
-#endif
-/* We use char because int might match the return type of a gcc2
- builtin and then its argument prototype would still apply. */
-char dlopen ();
-int
-main ()
-{
-dlopen ();
- ;
- return 0;
-}
-_ACEOF
-rm -f conftest.$ac_objext conftest$ac_exeext
-if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
- (eval $ac_link) 2>conftest.er1
- ac_status=$?
- grep -v '^ *+' conftest.er1 >conftest.err
- rm -f conftest.er1
- cat conftest.err >&5
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); } &&
- { ac_try='test -z "$ac_cxx_werror_flag"
- || test ! -s conftest.err'
- { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); }; } &&
- { ac_try='test -s conftest$ac_exeext'
- { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); }; }; then
- ac_cv_lib_svld_dlopen=yes
-else
- echo "$as_me: failed program was:" >&5
-sed 's/^/| /' conftest.$ac_ext >&5
+# A symbol stripping program
+STRIP=$lt_STRIP
-ac_cv_lib_svld_dlopen=no
-fi
-rm -f conftest.err conftest.$ac_objext \
- conftest$ac_exeext conftest.$ac_ext
-LIBS=$ac_check_lib_save_LIBS
-fi
-echo "$as_me:$LINENO: result: $ac_cv_lib_svld_dlopen" >&5
-echo "${ECHO_T}$ac_cv_lib_svld_dlopen" >&6
-if test $ac_cv_lib_svld_dlopen = yes; then
- lt_cv_dlopen="dlopen" lt_cv_dlopen_libs="-lsvld"
-else
- echo "$as_me:$LINENO: checking for dld_link in -ldld" >&5
-echo $ECHO_N "checking for dld_link in -ldld... $ECHO_C" >&6
-if test "${ac_cv_lib_dld_dld_link+set}" = set; then
- echo $ECHO_N "(cached) $ECHO_C" >&6
-else
- ac_check_lib_save_LIBS=$LIBS
-LIBS="-ldld $LIBS"
-cat >conftest.$ac_ext <<_ACEOF
-/* confdefs.h. */
-_ACEOF
-cat confdefs.h >>conftest.$ac_ext
-cat >>conftest.$ac_ext <<_ACEOF
-/* end confdefs.h. */
+# Used to examine libraries when file_magic_cmd begins "file"
+MAGIC_CMD=$MAGIC_CMD
-/* Override any gcc2 internal prototype to avoid an error. */
-#ifdef __cplusplus
-extern "C"
-#endif
-/* We use char because int might match the return type of a gcc2
- builtin and then its argument prototype would still apply. */
-char dld_link ();
-int
-main ()
-{
-dld_link ();
- ;
- return 0;
-}
-_ACEOF
-rm -f conftest.$ac_objext conftest$ac_exeext
-if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
- (eval $ac_link) 2>conftest.er1
- ac_status=$?
- grep -v '^ *+' conftest.er1 >conftest.err
- rm -f conftest.er1
- cat conftest.err >&5
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); } &&
- { ac_try='test -z "$ac_cxx_werror_flag"
- || test ! -s conftest.err'
- { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); }; } &&
- { ac_try='test -s conftest$ac_exeext'
- { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); }; }; then
- ac_cv_lib_dld_dld_link=yes
-else
- echo "$as_me: failed program was:" >&5
-sed 's/^/| /' conftest.$ac_ext >&5
+# Used on cygwin: DLL creation program.
+DLLTOOL="$DLLTOOL"
-ac_cv_lib_dld_dld_link=no
-fi
-rm -f conftest.err conftest.$ac_objext \
- conftest$ac_exeext conftest.$ac_ext
-LIBS=$ac_check_lib_save_LIBS
-fi
-echo "$as_me:$LINENO: result: $ac_cv_lib_dld_dld_link" >&5
-echo "${ECHO_T}$ac_cv_lib_dld_dld_link" >&6
-if test $ac_cv_lib_dld_dld_link = yes; then
- lt_cv_dlopen="dld_link" lt_cv_dlopen_libs="-dld"
-fi
+# Used on cygwin: object dumper.
+OBJDUMP="$OBJDUMP"
+# Used on cygwin: assembler.
+AS="$AS"
-fi
+# The name of the directory that contains temporary libtool files.
+objdir=$objdir
+# How to create reloadable object files.
+reload_flag=$lt_reload_flag
+reload_cmds=$lt_reload_cmds
-fi
+# How to pass a linker flag through the compiler.
+wl=$lt_lt_prog_compiler_wl_CXX
+# Object file suffix (normally "o").
+objext="$ac_objext"
-fi
+# Old archive suffix (normally "a").
+libext="$libext"
+# Shared library suffix (normally ".so").
+shrext_cmds='$shrext_cmds'
-fi
+# Executable file suffix (normally "").
+exeext="$exeext"
+# Additional compiler flags for building library objects.
+pic_flag=$lt_lt_prog_compiler_pic_CXX
+pic_mode=$pic_mode
-fi
+# What is the maximum length of a command?
+max_cmd_len=$lt_cv_sys_max_cmd_len
- ;;
- esac
+# Does compiler simultaneously support -c and -o options?
+compiler_c_o=$lt_lt_cv_prog_compiler_c_o_CXX
- if test "x$lt_cv_dlopen" != xno; then
- enable_dlopen=yes
- else
- enable_dlopen=no
- fi
+# Must we lock files when doing compilation?
+need_locks=$lt_need_locks
- case $lt_cv_dlopen in
- dlopen)
- save_CPPFLAGS="$CPPFLAGS"
- test "x$ac_cv_header_dlfcn_h" = xyes && CPPFLAGS="$CPPFLAGS -DHAVE_DLFCN_H"
+# Do we need the lib prefix for modules?
+need_lib_prefix=$need_lib_prefix
- save_LDFLAGS="$LDFLAGS"
- eval LDFLAGS=\"\$LDFLAGS $export_dynamic_flag_spec\"
+# Do we need a version for libraries?
+need_version=$need_version
- save_LIBS="$LIBS"
- LIBS="$lt_cv_dlopen_libs $LIBS"
+# Whether dlopen is supported.
+dlopen_support=$enable_dlopen
- echo "$as_me:$LINENO: checking whether a program can dlopen itself" >&5
-echo $ECHO_N "checking whether a program can dlopen itself... $ECHO_C" >&6
-if test "${lt_cv_dlopen_self+set}" = set; then
- echo $ECHO_N "(cached) $ECHO_C" >&6
-else
- if test "$cross_compiling" = yes; then :
- lt_cv_dlopen_self=cross
-else
- lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
- lt_status=$lt_dlunknown
- cat > conftest.$ac_ext <<EOF
-#line 12748 "configure"
-#include "confdefs.h"
+# Whether dlopen of programs is supported.
+dlopen_self=$enable_dlopen_self
-#if HAVE_DLFCN_H
-#include <dlfcn.h>
-#endif
+# Whether dlopen of statically linked programs is supported.
+dlopen_self_static=$enable_dlopen_self_static
-#include <stdio.h>
+# Compiler flag to prevent dynamic linking.
+link_static_flag=$lt_lt_prog_compiler_static_CXX
-#ifdef RTLD_GLOBAL
-# define LT_DLGLOBAL RTLD_GLOBAL
-#else
-# ifdef DL_GLOBAL
-# define LT_DLGLOBAL DL_GLOBAL
-# else
-# define LT_DLGLOBAL 0
-# endif
-#endif
+# Compiler flag to turn off builtin functions.
+no_builtin_flag=$lt_lt_prog_compiler_no_builtin_flag_CXX
-/* We may have to define LT_DLLAZY_OR_NOW in the command line if we
- find out it does not work in some platform. */
-#ifndef LT_DLLAZY_OR_NOW
-# ifdef RTLD_LAZY
-# define LT_DLLAZY_OR_NOW RTLD_LAZY
-# else
-# ifdef DL_LAZY
-# define LT_DLLAZY_OR_NOW DL_LAZY
-# else
-# ifdef RTLD_NOW
-# define LT_DLLAZY_OR_NOW RTLD_NOW
-# else
-# ifdef DL_NOW
-# define LT_DLLAZY_OR_NOW DL_NOW
-# else
-# define LT_DLLAZY_OR_NOW 0
-# endif
-# endif
-# endif
-# endif
-#endif
+# Compiler flag to allow reflexive dlopens.
+export_dynamic_flag_spec=$lt_export_dynamic_flag_spec_CXX
-#ifdef __cplusplus
-extern "C" void exit (int);
-#endif
+# Compiler flag to generate shared objects directly from archives.
+whole_archive_flag_spec=$lt_whole_archive_flag_spec_CXX
-void fnord() { int i=42;}
-int main ()
-{
- void *self = dlopen (0, LT_DLGLOBAL|LT_DLLAZY_OR_NOW);
- int status = $lt_dlunknown;
+# Compiler flag to generate thread-safe objects.
+thread_safe_flag_spec=$lt_thread_safe_flag_spec_CXX
- if (self)
- {
- if (dlsym (self,"fnord")) status = $lt_dlno_uscore;
- else if (dlsym( self,"_fnord")) status = $lt_dlneed_uscore;
- /* dlclose (self); */
- }
+# Library versioning type.
+version_type=$version_type
- exit (status);
-}
-EOF
- if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
- (eval $ac_link) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); } && test -s conftest${ac_exeext} 2>/dev/null; then
- (./conftest; exit; ) 2>/dev/null
- lt_status=$?
- case x$lt_status in
- x$lt_dlno_uscore) lt_cv_dlopen_self=yes ;;
- x$lt_dlneed_uscore) lt_cv_dlopen_self=yes ;;
- x$lt_unknown|x*) lt_cv_dlopen_self=no ;;
- esac
- else :
- # compilation failed
- lt_cv_dlopen_self=no
- fi
-fi
-rm -fr conftest*
+# Format of library name prefix.
+libname_spec=$lt_libname_spec
+# List of archive names. First name is the real one, the rest are links.
+# The last name is the one that the linker finds with -lNAME.
+library_names_spec=$lt_library_names_spec
-fi
-echo "$as_me:$LINENO: result: $lt_cv_dlopen_self" >&5
-echo "${ECHO_T}$lt_cv_dlopen_self" >&6
+# The coded name of the library, if different from the real name.
+soname_spec=$lt_soname_spec
- if test "x$lt_cv_dlopen_self" = xyes; then
- LDFLAGS="$LDFLAGS $link_static_flag"
- echo "$as_me:$LINENO: checking whether a statically linked program can dlopen itself" >&5
-echo $ECHO_N "checking whether a statically linked program can dlopen itself... $ECHO_C" >&6
-if test "${lt_cv_dlopen_self_static+set}" = set; then
- echo $ECHO_N "(cached) $ECHO_C" >&6
-else
- if test "$cross_compiling" = yes; then :
- lt_cv_dlopen_self_static=cross
-else
- lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
- lt_status=$lt_dlunknown
- cat > conftest.$ac_ext <<EOF
-#line 12846 "configure"
-#include "confdefs.h"
+# Commands used to build and install an old-style archive.
+RANLIB=$lt_RANLIB
+old_archive_cmds=$lt_old_archive_cmds_CXX
+old_postinstall_cmds=$lt_old_postinstall_cmds
+old_postuninstall_cmds=$lt_old_postuninstall_cmds
-#if HAVE_DLFCN_H
-#include <dlfcn.h>
-#endif
+# Create an old-style archive from a shared archive.
+old_archive_from_new_cmds=$lt_old_archive_from_new_cmds_CXX
-#include <stdio.h>
+# Create a temporary old-style archive to link instead of a shared archive.
+old_archive_from_expsyms_cmds=$lt_old_archive_from_expsyms_cmds_CXX
-#ifdef RTLD_GLOBAL
-# define LT_DLGLOBAL RTLD_GLOBAL
-#else
-# ifdef DL_GLOBAL
-# define LT_DLGLOBAL DL_GLOBAL
-# else
-# define LT_DLGLOBAL 0
-# endif
-#endif
+# Commands used to build and install a shared archive.
+archive_cmds=$lt_archive_cmds_CXX
+archive_expsym_cmds=$lt_archive_expsym_cmds_CXX
+postinstall_cmds=$lt_postinstall_cmds
+postuninstall_cmds=$lt_postuninstall_cmds
-/* We may have to define LT_DLLAZY_OR_NOW in the command line if we
- find out it does not work in some platform. */
-#ifndef LT_DLLAZY_OR_NOW
-# ifdef RTLD_LAZY
-# define LT_DLLAZY_OR_NOW RTLD_LAZY
-# else
-# ifdef DL_LAZY
-# define LT_DLLAZY_OR_NOW DL_LAZY
-# else
-# ifdef RTLD_NOW
-# define LT_DLLAZY_OR_NOW RTLD_NOW
-# else
-# ifdef DL_NOW
-# define LT_DLLAZY_OR_NOW DL_NOW
-# else
-# define LT_DLLAZY_OR_NOW 0
-# endif
-# endif
-# endif
-# endif
-#endif
+# Commands used to build a loadable module (assumed same as above if empty)
+module_cmds=$lt_module_cmds_CXX
+module_expsym_cmds=$lt_module_expsym_cmds_CXX
-#ifdef __cplusplus
-extern "C" void exit (int);
-#endif
+# Commands to strip libraries.
+old_striplib=$lt_old_striplib
+striplib=$lt_striplib
-void fnord() { int i=42;}
-int main ()
-{
- void *self = dlopen (0, LT_DLGLOBAL|LT_DLLAZY_OR_NOW);
- int status = $lt_dlunknown;
+# Dependencies to place before the objects being linked to create a
+# shared library.
+predep_objects=$lt_predep_objects_CXX
- if (self)
- {
- if (dlsym (self,"fnord")) status = $lt_dlno_uscore;
- else if (dlsym( self,"_fnord")) status = $lt_dlneed_uscore;
- /* dlclose (self); */
- }
+# Dependencies to place after the objects being linked to create a
+# shared library.
+postdep_objects=$lt_postdep_objects_CXX
- exit (status);
-}
-EOF
- if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
- (eval $ac_link) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); } && test -s conftest${ac_exeext} 2>/dev/null; then
- (./conftest; exit; ) 2>/dev/null
- lt_status=$?
- case x$lt_status in
- x$lt_dlno_uscore) lt_cv_dlopen_self_static=yes ;;
- x$lt_dlneed_uscore) lt_cv_dlopen_self_static=yes ;;
- x$lt_unknown|x*) lt_cv_dlopen_self_static=no ;;
- esac
- else :
- # compilation failed
- lt_cv_dlopen_self_static=no
- fi
-fi
-rm -fr conftest*
+# Dependencies to place before the objects being linked to create a
+# shared library.
+predeps=$lt_predeps_CXX
+# Dependencies to place after the objects being linked to create a
+# shared library.
+postdeps=$lt_postdeps_CXX
-fi
-echo "$as_me:$LINENO: result: $lt_cv_dlopen_self_static" >&5
-echo "${ECHO_T}$lt_cv_dlopen_self_static" >&6
- fi
+# The library search path used internally by the compiler when linking
+# a shared library.
+compiler_lib_search_path=$lt_compiler_lib_search_path_CXX
- CPPFLAGS="$save_CPPFLAGS"
- LDFLAGS="$save_LDFLAGS"
- LIBS="$save_LIBS"
- ;;
- esac
+# Method to check whether dependent libraries are shared objects.
+deplibs_check_method=$lt_deplibs_check_method
- case $lt_cv_dlopen_self in
- yes|no) enable_dlopen_self=$lt_cv_dlopen_self ;;
- *) enable_dlopen_self=unknown ;;
- esac
+# Command to use when deplibs_check_method == file_magic.
+file_magic_cmd=$lt_file_magic_cmd
- case $lt_cv_dlopen_self_static in
- yes|no) enable_dlopen_self_static=$lt_cv_dlopen_self_static ;;
- *) enable_dlopen_self_static=unknown ;;
- esac
-fi
+# Flag that allows shared libraries with undefined symbols to be built.
+allow_undefined_flag=$lt_allow_undefined_flag_CXX
+# Flag that forces no undefined symbols.
+no_undefined_flag=$lt_no_undefined_flag_CXX
-# The else clause should only fire when bootstrapping the
-# libtool distribution, otherwise you forgot to ship ltmain.sh
-# with your package, and you will get complaints that there are
-# no rules to generate ltmain.sh.
-if test -f "$ltmain"; then
- # See if we are running on zsh, and set the options which allow our commands through
- # without removal of \ escapes.
- if test -n "${ZSH_VERSION+set}" ; then
- setopt NO_GLOB_SUBST
- fi
- # Now quote all the things that may contain metacharacters while being
- # careful not to overquote the AC_SUBSTed values. We take copies of the
- # variables and quote the copies for generation of the libtool script.
- for var in echo old_CC old_CFLAGS AR AR_FLAGS EGREP RANLIB LN_S LTCC NM \
- SED SHELL STRIP \
- libname_spec library_names_spec soname_spec extract_expsyms_cmds \
- old_striplib striplib file_magic_cmd finish_cmds finish_eval \
- deplibs_check_method reload_flag reload_cmds need_locks \
- lt_cv_sys_global_symbol_pipe lt_cv_sys_global_symbol_to_cdecl \
- lt_cv_sys_global_symbol_to_c_name_address \
- sys_lib_search_path_spec sys_lib_dlsearch_path_spec \
- old_postinstall_cmds old_postuninstall_cmds \
- compiler_CXX \
- CC_CXX \
- LD_CXX \
- lt_prog_compiler_wl_CXX \
- lt_prog_compiler_pic_CXX \
- lt_prog_compiler_static_CXX \
- lt_prog_compiler_no_builtin_flag_CXX \
- export_dynamic_flag_spec_CXX \
- thread_safe_flag_spec_CXX \
- whole_archive_flag_spec_CXX \
- enable_shared_with_static_runtimes_CXX \
- old_archive_cmds_CXX \
- old_archive_from_new_cmds_CXX \
- predep_objects_CXX \
- postdep_objects_CXX \
- predeps_CXX \
- postdeps_CXX \
- compiler_lib_search_path_CXX \
- archive_cmds_CXX \
- archive_expsym_cmds_CXX \
- postinstall_cmds_CXX \
- postuninstall_cmds_CXX \
- old_archive_from_expsyms_cmds_CXX \
- allow_undefined_flag_CXX \
- no_undefined_flag_CXX \
- export_symbols_cmds_CXX \
- hardcode_libdir_flag_spec_CXX \
- hardcode_libdir_flag_spec_ld_CXX \
- hardcode_libdir_separator_CXX \
- hardcode_automatic_CXX \
- module_cmds_CXX \
- module_expsym_cmds_CXX \
- lt_cv_prog_compiler_c_o_CXX \
- exclude_expsyms_CXX \
- include_expsyms_CXX; do
+# Commands used to finish a libtool library installation in a directory.
+finish_cmds=$lt_finish_cmds
- case $var in
- old_archive_cmds_CXX | \
- old_archive_from_new_cmds_CXX | \
- archive_cmds_CXX | \
- archive_expsym_cmds_CXX | \
- module_cmds_CXX | \
- module_expsym_cmds_CXX | \
- old_archive_from_expsyms_cmds_CXX | \
- export_symbols_cmds_CXX | \
- extract_expsyms_cmds | reload_cmds | finish_cmds | \
- postinstall_cmds | postuninstall_cmds | \
- old_postinstall_cmds | old_postuninstall_cmds | \
- sys_lib_search_path_spec | sys_lib_dlsearch_path_spec)
- # Double-quote double-evaled strings.
- eval "lt_$var=\\\"\`\$echo \"X\$$var\" | \$Xsed -e \"\$double_quote_subst\" -e \"\$sed_quote_subst\" -e \"\$delay_variable_subst\"\`\\\""
- ;;
- *)
- eval "lt_$var=\\\"\`\$echo \"X\$$var\" | \$Xsed -e \"\$sed_quote_subst\"\`\\\""
- ;;
- esac
- done
-
- case $lt_echo in
- *'\$0 --fallback-echo"')
- lt_echo=`$echo "X$lt_echo" | $Xsed -e 's/\\\\\\\$0 --fallback-echo"$/$0 --fallback-echo"/'`
- ;;
- esac
-
-cfgfile="$ofile"
-
- cat <<__EOF__ >> "$cfgfile"
-# ### BEGIN LIBTOOL TAG CONFIG: $tagname
-
-# Libtool was configured on host `(hostname || uname -n) 2>/dev/null | sed 1q`:
-
-# Shell to use when invoking shell scripts.
-SHELL=$lt_SHELL
-
-# Whether or not to build shared libraries.
-build_libtool_libs=$enable_shared
-
-# Whether or not to build static libraries.
-build_old_libs=$enable_static
-
-# Whether or not to add -lc for building shared libraries.
-build_libtool_need_lc=$archive_cmds_need_lc_CXX
-
-# Whether or not to disallow shared libs when runtime libs are static
-allow_libtool_libs_with_static_runtimes=$enable_shared_with_static_runtimes_CXX
-
-# Whether or not to optimize for fast installation.
-fast_install=$enable_fast_install
-
-# The host system.
-host_alias=$host_alias
-host=$host
-host_os=$host_os
-
-# The build system.
-build_alias=$build_alias
-build=$build
-build_os=$build_os
-
-# An echo program that does not interpret backslashes.
-echo=$lt_echo
-
-# The archiver.
-AR=$lt_AR
-AR_FLAGS=$lt_AR_FLAGS
-
-# A C compiler.
-LTCC=$lt_LTCC
-
-# A language-specific compiler.
-CC=$lt_compiler_CXX
-
-# Is the compiler the GNU C compiler?
-with_gcc=$GCC_CXX
-
-# An ERE matcher.
-EGREP=$lt_EGREP
-
-# The linker used to build libraries.
-LD=$lt_LD_CXX
-
-# Whether we need hard or soft links.
-LN_S=$lt_LN_S
-
-# A BSD-compatible nm program.
-NM=$lt_NM
-
-# A symbol stripping program
-STRIP=$lt_STRIP
-
-# Used to examine libraries when file_magic_cmd begins "file"
-MAGIC_CMD=$MAGIC_CMD
-
-# Used on cygwin: DLL creation program.
-DLLTOOL="$DLLTOOL"
-
-# Used on cygwin: object dumper.
-OBJDUMP="$OBJDUMP"
-
-# Used on cygwin: assembler.
-AS="$AS"
-
-# The name of the directory that contains temporary libtool files.
-objdir=$objdir
-
-# How to create reloadable object files.
-reload_flag=$lt_reload_flag
-reload_cmds=$lt_reload_cmds
-
-# How to pass a linker flag through the compiler.
-wl=$lt_lt_prog_compiler_wl_CXX
-
-# Object file suffix (normally "o").
-objext="$ac_objext"
-
-# Old archive suffix (normally "a").
-libext="$libext"
-
-# Shared library suffix (normally ".so").
-shrext_cmds='$shrext_cmds'
-
-# Executable file suffix (normally "").
-exeext="$exeext"
-
-# Additional compiler flags for building library objects.
-pic_flag=$lt_lt_prog_compiler_pic_CXX
-pic_mode=$pic_mode
-
-# What is the maximum length of a command?
-max_cmd_len=$lt_cv_sys_max_cmd_len
-
-# Does compiler simultaneously support -c and -o options?
-compiler_c_o=$lt_lt_cv_prog_compiler_c_o_CXX
-
-# Must we lock files when doing compilation?
-need_locks=$lt_need_locks
-
-# Do we need the lib prefix for modules?
-need_lib_prefix=$need_lib_prefix
-
-# Do we need a version for libraries?
-need_version=$need_version
-
-# Whether dlopen is supported.
-dlopen_support=$enable_dlopen
-
-# Whether dlopen of programs is supported.
-dlopen_self=$enable_dlopen_self
-
-# Whether dlopen of statically linked programs is supported.
-dlopen_self_static=$enable_dlopen_self_static
-
-# Compiler flag to prevent dynamic linking.
-link_static_flag=$lt_lt_prog_compiler_static_CXX
-
-# Compiler flag to turn off builtin functions.
-no_builtin_flag=$lt_lt_prog_compiler_no_builtin_flag_CXX
-
-# Compiler flag to allow reflexive dlopens.
-export_dynamic_flag_spec=$lt_export_dynamic_flag_spec_CXX
-
-# Compiler flag to generate shared objects directly from archives.
-whole_archive_flag_spec=$lt_whole_archive_flag_spec_CXX
-
-# Compiler flag to generate thread-safe objects.
-thread_safe_flag_spec=$lt_thread_safe_flag_spec_CXX
-
-# Library versioning type.
-version_type=$version_type
-
-# Format of library name prefix.
-libname_spec=$lt_libname_spec
-
-# List of archive names. First name is the real one, the rest are links.
-# The last name is the one that the linker finds with -lNAME.
-library_names_spec=$lt_library_names_spec
-
-# The coded name of the library, if different from the real name.
-soname_spec=$lt_soname_spec
-
-# Commands used to build and install an old-style archive.
-RANLIB=$lt_RANLIB
-old_archive_cmds=$lt_old_archive_cmds_CXX
-old_postinstall_cmds=$lt_old_postinstall_cmds
-old_postuninstall_cmds=$lt_old_postuninstall_cmds
-
-# Create an old-style archive from a shared archive.
-old_archive_from_new_cmds=$lt_old_archive_from_new_cmds_CXX
-
-# Create a temporary old-style archive to link instead of a shared archive.
-old_archive_from_expsyms_cmds=$lt_old_archive_from_expsyms_cmds_CXX
-
-# Commands used to build and install a shared archive.
-archive_cmds=$lt_archive_cmds_CXX
-archive_expsym_cmds=$lt_archive_expsym_cmds_CXX
-postinstall_cmds=$lt_postinstall_cmds
-postuninstall_cmds=$lt_postuninstall_cmds
-
-# Commands used to build a loadable module (assumed same as above if empty)
-module_cmds=$lt_module_cmds_CXX
-module_expsym_cmds=$lt_module_expsym_cmds_CXX
-
-# Commands to strip libraries.
-old_striplib=$lt_old_striplib
-striplib=$lt_striplib
-
-# Dependencies to place before the objects being linked to create a
-# shared library.
-predep_objects=$lt_predep_objects_CXX
-
-# Dependencies to place after the objects being linked to create a
-# shared library.
-postdep_objects=$lt_postdep_objects_CXX
-
-# Dependencies to place before the objects being linked to create a
-# shared library.
-predeps=$lt_predeps_CXX
-
-# Dependencies to place after the objects being linked to create a
-# shared library.
-postdeps=$lt_postdeps_CXX
-
-# The library search path used internally by the compiler when linking
-# a shared library.
-compiler_lib_search_path=$lt_compiler_lib_search_path_CXX
-
-# Method to check whether dependent libraries are shared objects.
-deplibs_check_method=$lt_deplibs_check_method
-
-# Command to use when deplibs_check_method == file_magic.
-file_magic_cmd=$lt_file_magic_cmd
-
-# Flag that allows shared libraries with undefined symbols to be built.
-allow_undefined_flag=$lt_allow_undefined_flag_CXX
-
-# Flag that forces no undefined symbols.
-no_undefined_flag=$lt_no_undefined_flag_CXX
-
-# Commands used to finish a libtool library installation in a directory.
-finish_cmds=$lt_finish_cmds
-
-# Same as above, but a single script fragment to be evaled but not shown.
-finish_eval=$lt_finish_eval
+# Same as above, but a single script fragment to be evaled but not shown.
+finish_eval=$lt_finish_eval
# Take the output of nm and produce a listing of raw symbols and C names.
global_symbol_pipe=$lt_lt_cv_sys_global_symbol_pipe
@@ -13420,6 +12919,9 @@ lt_simple_link_test_code=" program t\n end\n"
# If no C compiler was specified, use CC.
LTCC=${LTCC-"$CC"}
+# If no C compiler flags were specified, use CFLAGS.
+LTCFLAGS=${LTCFLAGS-"$CFLAGS"}
+
# Allow CC to be a program name with arguments.
compiler=$CC
@@ -13427,13 +12929,13 @@ compiler=$CC
# save warnings/boilerplate of simple test code
ac_outfile=conftest.$ac_objext
printf "$lt_simple_compile_test_code" >conftest.$ac_ext
-eval "$ac_compile" 2>&1 >/dev/null | $SED '/^$/d' >conftest.err
+eval "$ac_compile" 2>&1 >/dev/null | $SED '/^$/d; /^ *+/d' >conftest.err
_lt_compiler_boilerplate=`cat conftest.err`
$rm conftest*
ac_outfile=conftest.$ac_objext
printf "$lt_simple_link_test_code" >conftest.$ac_ext
-eval "$ac_link" 2>&1 >/dev/null | $SED '/^$/d' >conftest.err
+eval "$ac_link" 2>&1 >/dev/null | $SED '/^$/d; /^ *+/d' >conftest.err
_lt_linker_boilerplate=`cat conftest.err`
$rm conftest*
@@ -13465,7 +12967,7 @@ test "$can_build_shared" = "no" && enable_shared=no
# On AIX, shared libraries and static libraries use the same namespace, and
# are all built from PIC.
-case "$host_os" in
+case $host_os in
aix3*)
test "$enable_shared" = yes && enable_static=no
if test -n "$RANLIB"; then
@@ -13489,8 +12991,6 @@ test "$enable_shared" = yes || enable_static=yes
echo "$as_me:$LINENO: result: $enable_static" >&5
echo "${ECHO_T}$enable_static" >&6
-test "$ld_shlibs_F77" = no && can_build_shared=no
-
GCC_F77="$G77"
LD_F77="$LD"
@@ -13537,6 +13037,11 @@ echo $ECHO_N "checking for $compiler option to produce PIC... $ECHO_C" >&6
lt_prog_compiler_pic_F77='-fno-common'
;;
+ interix3*)
+ # Interix 3.x gcc -fpic/-fPIC options generate broken code.
+ # Instead, we relocate shared libraries at runtime.
+ ;;
+
msdosdjgpp*)
# Just because we use GCC doesn't mean we suddenly get shared libraries
# on systems that don't support them.
@@ -13553,7 +13058,7 @@ echo $ECHO_N "checking for $compiler option to produce PIC... $ECHO_C" >&6
hpux*)
# PIC is the default for IA64 HP-UX and 64-bit HP-UX, but
# not for PA HP-UX.
- case "$host_cpu" in
+ case $host_cpu in
hppa*64*|ia64*)
# +Z the default
;;
@@ -13600,7 +13105,7 @@ echo $ECHO_N "checking for $compiler option to produce PIC... $ECHO_C" >&6
lt_prog_compiler_wl_F77='-Wl,'
# PIC is the default for IA64 HP-UX and 64-bit HP-UX, but
# not for PA HP-UX.
- case "$host_cpu" in
+ case $host_cpu in
hppa*64*|ia64*)
# +Z the default
;;
@@ -13630,12 +13135,12 @@ echo $ECHO_N "checking for $compiler option to produce PIC... $ECHO_C" >&6
lt_prog_compiler_pic_F77='-KPIC'
lt_prog_compiler_static_F77='-static'
;;
- pgcc* | pgf77* | pgf90*)
+ pgcc* | pgf77* | pgf90* | pgf95*)
# Portland Group compilers (*not* the Pentium gcc compiler,
# which looks to be a dead project)
lt_prog_compiler_wl_F77='-Wl,'
lt_prog_compiler_pic_F77='-fpic'
- lt_prog_compiler_static_F77='-static'
+ lt_prog_compiler_static_F77='-Bstatic'
;;
ccc*)
lt_prog_compiler_wl_F77='-Wl,'
@@ -13651,11 +13156,6 @@ echo $ECHO_N "checking for $compiler option to produce PIC... $ECHO_C" >&6
lt_prog_compiler_static_F77='-non_shared'
;;
- sco3.2v5*)
- lt_prog_compiler_pic_F77='-Kpic'
- lt_prog_compiler_static_F77='-dn'
- ;;
-
solaris*)
lt_prog_compiler_pic_F77='-KPIC'
lt_prog_compiler_static_F77='-Bstatic'
@@ -13673,7 +13173,7 @@ echo $ECHO_N "checking for $compiler option to produce PIC... $ECHO_C" >&6
lt_prog_compiler_static_F77='-Bstatic'
;;
- sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
+ sysv4 | sysv4.2uw2* | sysv4.3*)
lt_prog_compiler_wl_F77='-Wl,'
lt_prog_compiler_pic_F77='-KPIC'
lt_prog_compiler_static_F77='-Bstatic'
@@ -13686,6 +13186,12 @@ echo $ECHO_N "checking for $compiler option to produce PIC... $ECHO_C" >&6
fi
;;
+ sysv5* | unixware* | sco3.2v5* | sco5v6* | OpenUNIX*)
+ lt_prog_compiler_wl_F77='-Wl,'
+ lt_prog_compiler_pic_F77='-KPIC'
+ lt_prog_compiler_static_F77='-Bstatic'
+ ;;
+
unicos*)
lt_prog_compiler_wl_F77='-Wl,'
lt_prog_compiler_can_build_shared_F77=no
@@ -13725,20 +13231,20 @@ else
# with a dollar sign (not a hyphen), so the echo should work correctly.
# The option is referenced via a variable to avoid confusing sed.
lt_compile=`echo "$ac_compile" | $SED \
- -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
+ -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
-e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
-e 's:$: $lt_compiler_flag:'`
- (eval echo "\"\$as_me:13731: $lt_compile\"" >&5)
+ (eval echo "\"\$as_me:13237: $lt_compile\"" >&5)
(eval "$lt_compile" 2>conftest.err)
ac_status=$?
cat conftest.err >&5
- echo "$as_me:13735: \$? = $ac_status" >&5
+ echo "$as_me:13241: \$? = $ac_status" >&5
if (exit $ac_status) && test -s "$ac_outfile"; then
# The compiler can only warn and ignore the option if not recognized
# So say no if there are warnings other than the usual output.
- $echo "X$_lt_compiler_boilerplate" | $Xsed >conftest.exp
- $SED '/^$/d' conftest.err >conftest.er2
- if test ! -s conftest.err || diff conftest.exp conftest.er2 >/dev/null; then
+ $echo "X$_lt_compiler_boilerplate" | $Xsed -e '/^$/d' >conftest.exp
+ $SED '/^$/d; /^ *+/d' conftest.err >conftest.er2
+ if test ! -s conftest.er2 || diff conftest.exp conftest.er2 >/dev/null; then
lt_prog_compiler_pic_works_F77=yes
fi
fi
@@ -13759,7 +13265,7 @@ else
fi
fi
-case "$host_os" in
+case $host_os in
# For platforms which do not support PIC, -DPIC is meaningless:
*djgpp*)
lt_prog_compiler_pic_F77=
@@ -13769,43 +13275,85 @@ case "$host_os" in
;;
esac
-echo "$as_me:$LINENO: checking if $compiler supports -c -o file.$ac_objext" >&5
-echo $ECHO_N "checking if $compiler supports -c -o file.$ac_objext... $ECHO_C" >&6
-if test "${lt_cv_prog_compiler_c_o_F77+set}" = set; then
+#
+# Check to make sure the static flag actually works.
+#
+wl=$lt_prog_compiler_wl_F77 eval lt_tmp_static_flag=\"$lt_prog_compiler_static_F77\"
+echo "$as_me:$LINENO: checking if $compiler static flag $lt_tmp_static_flag works" >&5
+echo $ECHO_N "checking if $compiler static flag $lt_tmp_static_flag works... $ECHO_C" >&6
+if test "${lt_prog_compiler_static_works_F77+set}" = set; then
echo $ECHO_N "(cached) $ECHO_C" >&6
else
- lt_cv_prog_compiler_c_o_F77=no
- $rm -r conftest 2>/dev/null
- mkdir conftest
- cd conftest
- mkdir out
- printf "$lt_simple_compile_test_code" > conftest.$ac_ext
-
- lt_compiler_flag="-o out/conftest2.$ac_objext"
- # Insert the option either (1) after the last *FLAGS variable, or
- # (2) before a word containing "conftest.", or (3) at the end.
+ lt_prog_compiler_static_works_F77=no
+ save_LDFLAGS="$LDFLAGS"
+ LDFLAGS="$LDFLAGS $lt_tmp_static_flag"
+ printf "$lt_simple_link_test_code" > conftest.$ac_ext
+ if (eval $ac_link 2>conftest.err) && test -s conftest$ac_exeext; then
+ # The linker can only warn and ignore the option if not recognized
+ # So say no if there are warnings
+ if test -s conftest.err; then
+ # Append any errors to the config.log.
+ cat conftest.err 1>&5
+ $echo "X$_lt_linker_boilerplate" | $Xsed -e '/^$/d' > conftest.exp
+ $SED '/^$/d; /^ *+/d' conftest.err >conftest.er2
+ if diff conftest.exp conftest.er2 >/dev/null; then
+ lt_prog_compiler_static_works_F77=yes
+ fi
+ else
+ lt_prog_compiler_static_works_F77=yes
+ fi
+ fi
+ $rm conftest*
+ LDFLAGS="$save_LDFLAGS"
+
+fi
+echo "$as_me:$LINENO: result: $lt_prog_compiler_static_works_F77" >&5
+echo "${ECHO_T}$lt_prog_compiler_static_works_F77" >&6
+
+if test x"$lt_prog_compiler_static_works_F77" = xyes; then
+ :
+else
+ lt_prog_compiler_static_F77=
+fi
+
+
+echo "$as_me:$LINENO: checking if $compiler supports -c -o file.$ac_objext" >&5
+echo $ECHO_N "checking if $compiler supports -c -o file.$ac_objext... $ECHO_C" >&6
+if test "${lt_cv_prog_compiler_c_o_F77+set}" = set; then
+ echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+ lt_cv_prog_compiler_c_o_F77=no
+ $rm -r conftest 2>/dev/null
+ mkdir conftest
+ cd conftest
+ mkdir out
+ printf "$lt_simple_compile_test_code" > conftest.$ac_ext
+
+ lt_compiler_flag="-o out/conftest2.$ac_objext"
+ # Insert the option either (1) after the last *FLAGS variable, or
+ # (2) before a word containing "conftest.", or (3) at the end.
# Note that $ac_compile itself does not contain backslashes and begins
# with a dollar sign (not a hyphen), so the echo should work correctly.
lt_compile=`echo "$ac_compile" | $SED \
- -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
+ -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
-e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
-e 's:$: $lt_compiler_flag:'`
- (eval echo "\"\$as_me:13793: $lt_compile\"" >&5)
+ (eval echo "\"\$as_me:13341: $lt_compile\"" >&5)
(eval "$lt_compile" 2>out/conftest.err)
ac_status=$?
cat out/conftest.err >&5
- echo "$as_me:13797: \$? = $ac_status" >&5
+ echo "$as_me:13345: \$? = $ac_status" >&5
if (exit $ac_status) && test -s out/conftest2.$ac_objext
then
# The compiler can only warn and ignore the option if not recognized
# So say no if there are warnings
- $echo "X$_lt_compiler_boilerplate" | $Xsed > out/conftest.exp
- $SED '/^$/d' out/conftest.err >out/conftest.er2
- if test ! -s out/conftest.err || diff out/conftest.exp out/conftest.er2 >/dev/null; then
+ $echo "X$_lt_compiler_boilerplate" | $Xsed -e '/^$/d' > out/conftest.exp
+ $SED '/^$/d; /^ *+/d' out/conftest.err >out/conftest.er2
+ if test ! -s out/conftest.er2 || diff out/conftest.exp out/conftest.er2 >/dev/null; then
lt_cv_prog_compiler_c_o_F77=yes
fi
fi
- chmod u+w .
+ chmod u+w . 2>&5
$rm conftest*
# SGI C++ compiler will create directory out/ii_files/ for
# template instantiation
@@ -13901,6 +13449,10 @@ cc_basename=`$echo "X$cc_temp" | $Xsed -e 's%.*/%%' -e "s%^$host_alias-%%"`
with_gnu_ld=no
fi
;;
+ interix*)
+ # we just hope/assume this is gcc and not c89 (= MSVC++)
+ with_gnu_ld=yes
+ ;;
openbsd*)
with_gnu_ld=no
;;
@@ -13985,7 +13537,7 @@ EOF
export_symbols_cmds_F77='$NM $libobjs $convenience | $global_symbol_pipe | $SED -e '\''/^[BCDGRS] /s/.* \([^ ]*\)/\1 DATA/'\'' | $SED -e '\''/^[AITW] /s/.* //'\'' | sort | uniq > $export_symbols'
if $LD --help 2>&1 | grep 'auto-import' > /dev/null; then
- archive_cmds_F77='$CC -shared $libobjs $deplibs $compiler_flags -o $output_objdir/$soname ${wl}--image-base=0x10000000 ${wl}--out-implib,$lib'
+ archive_cmds_F77='$CC -shared $libobjs $deplibs $compiler_flags -o $output_objdir/$soname ${wl}--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib'
# If the export-symbols file already is a .def file (1st line
# is EXPORTS), use it as is; otherwise, prepend...
archive_expsym_cmds_F77='if test "x`$SED 1q $export_symbols`" = xEXPORTS; then
@@ -13994,22 +13546,37 @@ EOF
echo EXPORTS > $output_objdir/$soname.def;
cat $export_symbols >> $output_objdir/$soname.def;
fi~
- $CC -shared $output_objdir/$soname.def $libobjs $deplibs $compiler_flags -o $output_objdir/$soname ${wl}--image-base=0x10000000 ${wl}--out-implib,$lib'
+ $CC -shared $output_objdir/$soname.def $libobjs $deplibs $compiler_flags -o $output_objdir/$soname ${wl}--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib'
else
ld_shlibs_F77=no
fi
;;
+ interix3*)
+ hardcode_direct_F77=no
+ hardcode_shlibpath_var_F77=no
+ hardcode_libdir_flag_spec_F77='${wl}-rpath,$libdir'
+ export_dynamic_flag_spec_F77='${wl}-E'
+ # Hack: On Interix 3.x, we cannot compile PIC because of a broken gcc.
+ # Instead, shared libraries are loaded at an image base (0x10000000 by
+ # default) and relocated if they conflict, which is a slow very memory
+ # consuming and fragmenting process. To avoid this, we pick a random,
+ # 256 KiB-aligned image base between 0x50000000 and 0x6FFC0000 at link
+ # time. Moving up from 0x10000000 also allows more sbrk(2) space.
+ archive_cmds_F77='$CC -shared $pic_flag $libobjs $deplibs $compiler_flags ${wl}-h,$soname ${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
+ archive_expsym_cmds_F77='sed "s,^,_," $export_symbols >$output_objdir/$soname.expsym~$CC -shared $pic_flag $libobjs $deplibs $compiler_flags ${wl}-h,$soname ${wl}--retain-symbols-file,$output_objdir/$soname.expsym ${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
+ ;;
+
linux*)
if $LD --help 2>&1 | grep ': supported targets:.* elf' > /dev/null; then
tmp_addflag=
case $cc_basename,$host_cpu in
pgcc*) # Portland Group C compiler
- whole_archive_flag_spec_F77='${wl}--whole-archive,`for conv in $convenience\"\"; do test -n \"$conv\" && new_convenience=\"$new_convenience,$conv\"; done; $echo \"$new_convenience\"` ${wl}--no-whole-archive'
+ whole_archive_flag_spec_F77='${wl}--whole-archive`for conv in $convenience\"\"; do test -n \"$conv\" && new_convenience=\"$new_convenience,$conv\"; done; $echo \"$new_convenience\"` ${wl}--no-whole-archive'
tmp_addflag=' $pic_flag'
;;
- pgf77* | pgf90* ) # Portland Group f77 and f90 compilers
- whole_archive_flag_spec_F77='${wl}--whole-archive,`for conv in $convenience\"\"; do test -n \"$conv\" && new_convenience=\"$new_convenience,$conv\"; done; $echo \"$new_convenience\"` ${wl}--no-whole-archive'
+ pgf77* | pgf90* | pgf95*) # Portland Group f77 and f90 compilers
+ whole_archive_flag_spec_F77='${wl}--whole-archive`for conv in $convenience\"\"; do test -n \"$conv\" && new_convenience=\"$new_convenience,$conv\"; done; $echo \"$new_convenience\"` ${wl}--no-whole-archive'
tmp_addflag=' $pic_flag -Mnomain' ;;
ecc*,ia64* | icc*,ia64*) # Intel C compiler on ia64
tmp_addflag=' -i_dynamic' ;;
@@ -14041,7 +13608,7 @@ EOF
fi
;;
- solaris* | sysv5*)
+ solaris*)
if $LD -v 2>&1 | grep 'BFD 2\.8' > /dev/null; then
ld_shlibs_F77=no
cat <<EOF 1>&2
@@ -14062,6 +13629,33 @@ EOF
fi
;;
+ sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX*)
+ case `$LD -v 2>&1` in
+ *\ [01].* | *\ 2.[0-9].* | *\ 2.1[0-5].*)
+ ld_shlibs_F77=no
+ cat <<_LT_EOF 1>&2
+
+*** Warning: Releases of the GNU linker prior to 2.16.91.0.3 can not
+*** reliably create shared libraries on SCO systems. Therefore, libtool
+*** is disabling shared libraries support. We urge you to upgrade GNU
+*** binutils to release 2.16.91.0.3 or newer. Another option is to modify
+*** your PATH or compiler configuration so that the native linker is
+*** used, and then restart.
+
+_LT_EOF
+ ;;
+ *)
+ if $LD --help 2>&1 | grep ': supported targets:.* elf' > /dev/null; then
+ hardcode_libdir_flag_spec_F77='`test -z "$SCOABSPATH" && echo ${wl}-rpath,$libdir`'
+ archive_cmds_F77='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib'
+ archive_expsym_cmds_F77='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname,\${SCOABSPATH:+${install_libdir}/}$soname,-retain-symbols-file,$export_symbols -o $lib'
+ else
+ ld_shlibs_F77=no
+ fi
+ ;;
+ esac
+ ;;
+
sunos4*)
archive_cmds_F77='$LD -assert pure-text -Bshareable -o $lib $libobjs $deplibs $linker_flags'
wlarc=
@@ -14095,7 +13689,7 @@ EOF
# Note: this linker hardcodes the directories in LIBPATH if there
# are no directories specified by -L.
hardcode_minus_L_F77=yes
- if test "$GCC" = yes && test -z "$link_static_flag"; then
+ if test "$GCC" = yes && test -z "$lt_prog_compiler_static"; then
# Neither direct hardcoding nor static linking is supported with a
# broken collect2.
hardcode_direct_F77=unsupported
@@ -14129,6 +13723,7 @@ EOF
break
fi
done
+ ;;
esac
exp_sym_flag='-bexport'
@@ -14166,6 +13761,7 @@ EOF
hardcode_libdir_flag_spec_F77='-L$libdir'
hardcode_libdir_separator_F77=
fi
+ ;;
esac
shared_flag='-shared'
if test "$aix_use_runtimelinking" = yes; then
@@ -14178,11 +13774,11 @@ EOF
# chokes on -Wl,-G. The following line is correct:
shared_flag='-G'
else
- if test "$aix_use_runtimelinking" = yes; then
+ if test "$aix_use_runtimelinking" = yes; then
shared_flag='${wl}-G'
else
shared_flag='${wl}-bM:SRE'
- fi
+ fi
fi
fi
@@ -14237,12 +13833,12 @@ rm -f conftest.err conftest.$ac_objext \
if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
hardcode_libdir_flag_spec_F77='${wl}-blibpath:$libdir:'"$aix_libpath"
- archive_expsym_cmds_F77="\$CC"' -o $output_objdir/$soname $libobjs $deplibs $compiler_flags `if test "x${allow_undefined_flag}" != "x"; then echo "${wl}${allow_undefined_flag}"; else :; fi` '"\${wl}$no_entry_flag \${wl}$exp_sym_flag:\$export_symbols $shared_flag"
+ archive_expsym_cmds_F77="\$CC"' -o $output_objdir/$soname $libobjs $deplibs '"\${wl}$no_entry_flag"' $compiler_flags `if test "x${allow_undefined_flag}" != "x"; then echo "${wl}${allow_undefined_flag}"; else :; fi` '"\${wl}$exp_sym_flag:\$export_symbols $shared_flag"
else
if test "$host_cpu" = ia64; then
hardcode_libdir_flag_spec_F77='${wl}-R $libdir:/usr/lib:/lib'
allow_undefined_flag_F77="-z nodefs"
- archive_expsym_cmds_F77="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs $compiler_flags ${wl}${allow_undefined_flag} '"\${wl}$no_entry_flag \${wl}$exp_sym_flag:\$export_symbols"
+ archive_expsym_cmds_F77="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs '"\${wl}$no_entry_flag"' $compiler_flags ${wl}${allow_undefined_flag} '"\${wl}$exp_sym_flag:\$export_symbols"
else
# Determine the default libpath from the value encoded in an empty executable.
cat >conftest.$ac_ext <<_ACEOF
@@ -14292,13 +13888,11 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
# -berok will link without error, but may produce a broken library.
no_undefined_flag_F77=' ${wl}-bernotok'
allow_undefined_flag_F77=' ${wl}-berok'
- # -bexpall does not export symbols beginning with underscore (_)
- always_export_symbols_F77=yes
# Exported symbols can be pulled into shared objects from archives
- whole_archive_flag_spec_F77=' '
+ whole_archive_flag_spec_F77='$convenience'
archive_cmds_need_lc_F77=yes
- # This is similar to how AIX traditionally builds it's shared libraries.
- archive_expsym_cmds_F77="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs $compiler_flags ${wl}-bE:$export_symbols ${wl}-bnoentry${allow_undefined_flag}~$AR $AR_FLAGS $output_objdir/$libname$release.a $output_objdir/$soname'
+ # This is similar to how AIX traditionally builds its shared libraries.
+ archive_expsym_cmds_F77="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs ${wl}-bnoentry $compiler_flags ${wl}-bE:$export_symbols${allow_undefined_flag}~$AR $AR_FLAGS $output_objdir/$libname$release.a $output_objdir/$soname'
fi
fi
;;
@@ -14337,7 +13931,7 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
;;
darwin* | rhapsody*)
- case "$host_os" in
+ case $host_os in
rhapsody* | darwin1.[012])
allow_undefined_flag_F77='${wl}-undefined ${wl}suppress'
;;
@@ -14366,7 +13960,7 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
output_verbose_link_cmd='echo'
archive_cmds_F77='$CC -dynamiclib $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags -install_name $rpath/$soname $verstring'
module_cmds_F77='$CC $allow_undefined_flag -o $lib -bundle $libobjs $deplibs$compiler_flags'
- # Don't fix this by using the ld -exported_symbols_list flag, it doesn't exist in older darwin ld's
+ # Don't fix this by using the ld -exported_symbols_list flag, it doesn't exist in older darwin lds
archive_expsym_cmds_F77='sed -e "s,#.*,," -e "s,^[ ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC -dynamiclib $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags -install_name $rpath/$soname $verstring~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
module_expsym_cmds_F77='sed -e "s,#.*,," -e "s,^[ ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC $allow_undefined_flag -o $lib -bundle $libobjs $deplibs$compiler_flags~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
else
@@ -14375,7 +13969,7 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
output_verbose_link_cmd='echo'
archive_cmds_F77='$CC -qmkshrobj $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags ${wl}-install_name ${wl}`echo $rpath/$soname` $verstring'
module_cmds_F77='$CC $allow_undefined_flag -o $lib -bundle $libobjs $deplibs$compiler_flags'
- # Don't fix this by using the ld -exported_symbols_list flag, it doesn't exist in older darwin ld's
+ # Don't fix this by using the ld -exported_symbols_list flag, it doesn't exist in older darwin lds
archive_expsym_cmds_F77='sed -e "s,#.*,," -e "s,^[ ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC -qmkshrobj $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags ${wl}-install_name ${wl}$rpath/$soname $verstring~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
module_expsym_cmds_F77='sed -e "s,#.*,," -e "s,^[ ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC $allow_undefined_flag -o $lib -bundle $libobjs $deplibs$compiler_flags~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
;;
@@ -14439,47 +14033,62 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
export_dynamic_flag_spec_F77='${wl}-E'
;;
- hpux10* | hpux11*)
+ hpux10*)
if test "$GCC" = yes -a "$with_gnu_ld" = no; then
- case "$host_cpu" in
- hppa*64*|ia64*)
+ archive_cmds_F77='$CC -shared -fPIC ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
+ else
+ archive_cmds_F77='$LD -b +h $soname +b $install_libdir -o $lib $libobjs $deplibs $linker_flags'
+ fi
+ if test "$with_gnu_ld" = no; then
+ hardcode_libdir_flag_spec_F77='${wl}+b ${wl}$libdir'
+ hardcode_libdir_separator_F77=:
+
+ hardcode_direct_F77=yes
+ export_dynamic_flag_spec_F77='${wl}-E'
+
+ # hardcode_minus_L: Not really in the search PATH,
+ # but as the default location of the library.
+ hardcode_minus_L_F77=yes
+ fi
+ ;;
+
+ hpux11*)
+ if test "$GCC" = yes -a "$with_gnu_ld" = no; then
+ case $host_cpu in
+ hppa*64*)
archive_cmds_F77='$CC -shared ${wl}+h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
;;
+ ia64*)
+ archive_cmds_F77='$CC -shared ${wl}+h ${wl}$soname ${wl}+nodefaultrpath -o $lib $libobjs $deplibs $compiler_flags'
+ ;;
*)
archive_cmds_F77='$CC -shared -fPIC ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
;;
esac
else
- case "$host_cpu" in
- hppa*64*|ia64*)
- archive_cmds_F77='$LD -b +h $soname -o $lib $libobjs $deplibs $linker_flags'
+ case $host_cpu in
+ hppa*64*)
+ archive_cmds_F77='$CC -b ${wl}+h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
+ ;;
+ ia64*)
+ archive_cmds_F77='$CC -b ${wl}+h ${wl}$soname ${wl}+nodefaultrpath -o $lib $libobjs $deplibs $compiler_flags'
;;
*)
- archive_cmds_F77='$LD -b +h $soname +b $install_libdir -o $lib $libobjs $deplibs $linker_flags'
+ archive_cmds_F77='$CC -b ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
;;
esac
fi
if test "$with_gnu_ld" = no; then
- case "$host_cpu" in
- hppa*64*)
- hardcode_libdir_flag_spec_F77='${wl}+b ${wl}$libdir'
+ hardcode_libdir_flag_spec_F77='${wl}+b ${wl}$libdir'
+ hardcode_libdir_separator_F77=:
+
+ case $host_cpu in
+ hppa*64*|ia64*)
hardcode_libdir_flag_spec_ld_F77='+b $libdir'
- hardcode_libdir_separator_F77=:
- hardcode_direct_F77=no
- hardcode_shlibpath_var_F77=no
- ;;
- ia64*)
- hardcode_libdir_flag_spec_F77='-L$libdir'
hardcode_direct_F77=no
hardcode_shlibpath_var_F77=no
-
- # hardcode_minus_L: Not really in the search PATH,
- # but as the default location of the library.
- hardcode_minus_L_F77=yes
;;
*)
- hardcode_libdir_flag_spec_F77='${wl}+b ${wl}$libdir'
- hardcode_libdir_separator_F77=:
hardcode_direct_F77=yes
export_dynamic_flag_spec_F77='${wl}-E'
@@ -14581,14 +14190,6 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
hardcode_libdir_separator_F77=:
;;
- sco3.2v5*)
- archive_cmds_F77='$LD -G -h $soname -o $lib $libobjs $deplibs $linker_flags'
- hardcode_shlibpath_var_F77=no
- export_dynamic_flag_spec_F77='${wl}-Bexport'
- runpath_var=LD_RUN_PATH
- hardcode_runpath_var=yes
- ;;
-
solaris*)
no_undefined_flag_F77=' -z text'
if test "$GCC" = yes; then
@@ -14674,36 +14275,45 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
fi
;;
- sysv4.2uw2*)
- archive_cmds_F77='$LD -G -o $lib $libobjs $deplibs $linker_flags'
- hardcode_direct_F77=yes
- hardcode_minus_L_F77=no
+ sysv4*uw2* | sysv5OpenUNIX* | sysv5UnixWare7.[01].[10]* | unixware7*)
+ no_undefined_flag_F77='${wl}-z,text'
+ archive_cmds_need_lc_F77=no
hardcode_shlibpath_var_F77=no
- hardcode_runpath_var=yes
- runpath_var=LD_RUN_PATH
- ;;
+ runpath_var='LD_RUN_PATH'
- sysv5OpenUNIX8* | sysv5UnixWare7* | sysv5uw[78]* | unixware7*)
- no_undefined_flag_F77='${wl}-z ${wl}text'
if test "$GCC" = yes; then
- archive_cmds_F77='$CC -shared ${wl}-h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
+ archive_cmds_F77='$CC -shared ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
+ archive_expsym_cmds_F77='$CC -shared ${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
else
- archive_cmds_F77='$CC -G ${wl}-h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
+ archive_cmds_F77='$CC -G ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
+ archive_expsym_cmds_F77='$CC -G ${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
fi
- runpath_var='LD_RUN_PATH'
- hardcode_shlibpath_var_F77=no
;;
- sysv5*)
- no_undefined_flag_F77=' -z text'
- # $CC -shared without GNU ld will not create a library from C++
- # object files and a static libstdc++, better avoid it by now
- archive_cmds_F77='$LD -G${allow_undefined_flag} -h $soname -o $lib $libobjs $deplibs $linker_flags'
- archive_expsym_cmds_F77='$echo "{ global:" > $lib.exp~cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >> $lib.exp~$echo "local: *; };" >> $lib.exp~
- $LD -G${allow_undefined_flag} -M $lib.exp -h $soname -o $lib $libobjs $deplibs $linker_flags~$rm $lib.exp'
- hardcode_libdir_flag_spec_F77=
+ sysv5* | sco3.2v5* | sco5v6*)
+ # Note: We can NOT use -z defs as we might desire, because we do not
+ # link with -lc, and that would cause any symbols used from libc to
+ # always be unresolved, which means just about no library would
+ # ever link correctly. If we're not using GNU ld we use -z text
+ # though, which does catch some bad symbols but isn't as heavy-handed
+ # as -z defs.
+ no_undefined_flag_F77='${wl}-z,text'
+ allow_undefined_flag_F77='${wl}-z,nodefs'
+ archive_cmds_need_lc_F77=no
hardcode_shlibpath_var_F77=no
+ hardcode_libdir_flag_spec_F77='`test -z "$SCOABSPATH" && echo ${wl}-R,$libdir`'
+ hardcode_libdir_separator_F77=':'
+ link_all_deplibs_F77=yes
+ export_dynamic_flag_spec_F77='${wl}-Bexport'
runpath_var='LD_RUN_PATH'
+
+ if test "$GCC" = yes; then
+ archive_cmds_F77='$CC -shared ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+ archive_expsym_cmds_F77='$CC -shared ${wl}-Bexport:$export_symbols ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+ else
+ archive_cmds_F77='$CC -G ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+ archive_expsym_cmds_F77='$CC -G ${wl}-Bexport:$export_symbols ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+ fi
;;
uts4*)
@@ -14722,11 +14332,6 @@ echo "$as_me:$LINENO: result: $ld_shlibs_F77" >&5
echo "${ECHO_T}$ld_shlibs_F77" >&6
test "$ld_shlibs_F77" = no && can_build_shared=no
-variables_saved_for_relink="PATH $shlibpath_var $runpath_var"
-if test "$GCC" = yes; then
- variables_saved_for_relink="$variables_saved_for_relink GCC_EXEC_PREFIX COMPILER_PATH LIBRARY_PATH"
-fi
-
#
# Do we need to explicitly link libc?
#
@@ -14759,6 +14364,7 @@ echo $ECHO_N "checking whether -lc should be explicitly linked in... $ECHO_C" >&
libobjs=conftest.$ac_objext
deplibs=
wl=$lt_prog_compiler_wl_F77
+ pic_flag=$lt_prog_compiler_pic_F77
compiler_flags=-v
linker_flags=-v
verstring=
@@ -14919,7 +14525,8 @@ cygwin* | mingw* | pw32*)
dlpath=`$SHELL 2>&1 -c '\''. $dir/'\''\${base_file}'\''i;echo \$dlname'\''`~
dldir=$destdir/`dirname \$dlpath`~
test -d \$dldir || mkdir -p \$dldir~
- $install_prog $dir/$dlname \$dldir/$dlname'
+ $install_prog $dir/$dlname \$dldir/$dlname~
+ chmod a+x \$dldir/$dlname'
postuninstall_cmds='dldll=`$SHELL 2>&1 -c '\''. $file; echo \$dlname'\''`~
dlpath=$dir/\$dldll~
$rm \$dlpath'
@@ -14972,7 +14579,7 @@ darwin* | rhapsody*)
soname_spec='${libname}${release}${major}$shared_ext'
shlibpath_overrides_runpath=yes
shlibpath_var=DYLD_LIBRARY_PATH
- shrext_cmds='$(test .$module = .yes && echo .so || echo .dylib)'
+ shrext_cmds='`test .$module = .yes && echo .so || echo .dylib`'
# Apple's gcc prints 'gcc -print-search-dirs' doesn't operate the same.
if test "$GCC" = yes; then
sys_lib_search_path_spec=`$CC -print-search-dirs | tr "\n" "$PATH_SEPARATOR" | sed -e 's/libraries:/@libraries:/' | tr "@" "\n" | grep "^libraries:" | sed -e "s/^libraries://" -e "s,=/,/,g" -e "s,$PATH_SEPARATOR, ,g" -e "s,.*,& /lib /usr/lib /usr/local/lib,g"`
@@ -15010,7 +14617,14 @@ kfreebsd*-gnu)
freebsd* | dragonfly*)
# DragonFly does not have aout. When/if they implement a new
# versioning mechanism, adjust this.
- objformat=`test -x /usr/bin/objformat && /usr/bin/objformat || echo aout`
+ if test -x /usr/bin/objformat; then
+ objformat=`/usr/bin/objformat`
+ else
+ case $host_os in
+ freebsd[123]*) objformat=aout ;;
+ *) objformat=elf ;;
+ esac
+ fi
version_type=freebsd-$objformat
case $version_type in
freebsd-elf*)
@@ -15032,10 +14646,15 @@ freebsd* | dragonfly*)
shlibpath_overrides_runpath=yes
hardcode_into_libs=yes
;;
- *) # from 3.2 on
+ freebsd3.[2-9]* | freebsdelf3.[2-9]* | \
+ freebsd4.[0-5] | freebsdelf4.[0-5] | freebsd4.1.1 | freebsdelf4.1.1)
shlibpath_overrides_runpath=no
hardcode_into_libs=yes
;;
+ freebsd*) # from 4.6 on
+ shlibpath_overrides_runpath=yes
+ hardcode_into_libs=yes
+ ;;
esac
;;
@@ -15055,7 +14674,7 @@ hpux9* | hpux10* | hpux11*)
version_type=sunos
need_lib_prefix=no
need_version=no
- case "$host_cpu" in
+ case $host_cpu in
ia64*)
shrext_cmds='.so'
hardcode_into_libs=yes
@@ -15095,6 +14714,18 @@ hpux9* | hpux10* | hpux11*)
postinstall_cmds='chmod 555 $lib'
;;
+interix3*)
+ version_type=linux
+ need_lib_prefix=no
+ need_version=no
+ library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major ${libname}${shared_ext}'
+ soname_spec='${libname}${release}${shared_ext}$major'
+ dynamic_linker='Interix 3.x ld.so.1 (PE, like ELF)'
+ shlibpath_var=LD_LIBRARY_PATH
+ shlibpath_overrides_runpath=no
+ hardcode_into_libs=yes
+ ;;
+
irix5* | irix6* | nonstopux*)
case $host_os in
nonstopux*) version_type=nonstopux ;;
@@ -15216,6 +14847,7 @@ nto-qnx*)
openbsd*)
version_type=sunos
+ sys_lib_dlsearch_path_spec="/usr/lib"
need_lib_prefix=no
# Some older versions of OpenBSD (3.3 at least) *do* need versioned libs.
case $host_os in
@@ -15259,13 +14891,6 @@ osf3* | osf4* | osf5*)
sys_lib_dlsearch_path_spec="$sys_lib_search_path_spec"
;;
-sco3.2v5*)
- version_type=osf
- soname_spec='${libname}${release}${shared_ext}$major'
- library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
- shlibpath_var=LD_LIBRARY_PATH
- ;;
-
solaris*)
version_type=linux
need_lib_prefix=no
@@ -15291,7 +14916,7 @@ sunos4*)
need_version=yes
;;
-sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
+sysv4 | sysv4.3*)
version_type=linux
library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
soname_spec='${libname}${release}${shared_ext}$major'
@@ -15324,6 +14949,29 @@ sysv4*MP*)
fi
;;
+sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX* | sysv4*uw2*)
+ version_type=freebsd-elf
+ need_lib_prefix=no
+ need_version=no
+ library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext} $libname${shared_ext}'
+ soname_spec='${libname}${release}${shared_ext}$major'
+ shlibpath_var=LD_LIBRARY_PATH
+ hardcode_into_libs=yes
+ if test "$with_gnu_ld" = yes; then
+ sys_lib_search_path_spec='/usr/local/lib /usr/gnu/lib /usr/ccs/lib /usr/lib /lib'
+ shlibpath_overrides_runpath=no
+ else
+ sys_lib_search_path_spec='/usr/ccs/lib /usr/lib'
+ shlibpath_overrides_runpath=yes
+ case $host_os in
+ sco3.2v5*)
+ sys_lib_search_path_spec="$sys_lib_search_path_spec /lib"
+ ;;
+ esac
+ fi
+ sys_lib_dlsearch_path_spec='/usr/lib'
+ ;;
+
uts4*)
version_type=linux
library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
@@ -15339,6 +14987,11 @@ echo "$as_me:$LINENO: result: $dynamic_linker" >&5
echo "${ECHO_T}$dynamic_linker" >&6
test "$dynamic_linker" = no && can_build_shared=no
+variables_saved_for_relink="PATH $shlibpath_var $runpath_var"
+if test "$GCC" = yes; then
+ variables_saved_for_relink="$variables_saved_for_relink GCC_EXEC_PREFIX COMPILER_PATH LIBRARY_PATH"
+fi
+
echo "$as_me:$LINENO: checking how to hardcode library paths into programs" >&5
echo $ECHO_N "checking how to hardcode library paths into programs... $ECHO_C" >&6
hardcode_action_F77=
@@ -15376,36 +15029,6 @@ elif test "$shlibpath_overrides_runpath" = yes ||
enable_fast_install=needless
fi
-striplib=
-old_striplib=
-echo "$as_me:$LINENO: checking whether stripping libraries is possible" >&5
-echo $ECHO_N "checking whether stripping libraries is possible... $ECHO_C" >&6
-if test -n "$STRIP" && $STRIP -V 2>&1 | grep "GNU strip" >/dev/null; then
- test -z "$old_striplib" && old_striplib="$STRIP --strip-debug"
- test -z "$striplib" && striplib="$STRIP --strip-unneeded"
- echo "$as_me:$LINENO: result: yes" >&5
-echo "${ECHO_T}yes" >&6
-else
-# FIXME - insert some real tests, host_os isn't really good enough
- case $host_os in
- darwin*)
- if test -n "$STRIP" ; then
- striplib="$STRIP -x"
- echo "$as_me:$LINENO: result: yes" >&5
-echo "${ECHO_T}yes" >&6
- else
- echo "$as_me:$LINENO: result: no" >&5
-echo "${ECHO_T}no" >&6
-fi
- ;;
- *)
- echo "$as_me:$LINENO: result: no" >&5
-echo "${ECHO_T}no" >&6
- ;;
- esac
-fi
-
-
# The else clause should only fire when bootstrapping the
# libtool distribution, otherwise you forgot to ship ltmain.sh
@@ -15420,7 +15043,7 @@ if test -f "$ltmain"; then
# Now quote all the things that may contain metacharacters while being
# careful not to overquote the AC_SUBSTed values. We take copies of the
# variables and quote the copies for generation of the libtool script.
- for var in echo old_CC old_CFLAGS AR AR_FLAGS EGREP RANLIB LN_S LTCC NM \
+ for var in echo old_CC old_CFLAGS AR AR_FLAGS EGREP RANLIB LN_S LTCC LTCFLAGS NM \
SED SHELL STRIP \
libname_spec library_names_spec soname_spec extract_expsyms_cmds \
old_striplib striplib file_magic_cmd finish_cmds finish_eval \
@@ -15538,6 +15161,9 @@ AR_FLAGS=$lt_AR_FLAGS
# A C compiler.
LTCC=$lt_LTCC
+# LTCC compiler flags.
+LTCFLAGS=$lt_LTCFLAGS
+
# A language-specific compiler.
CC=$lt_compiler_F77
@@ -15848,6 +15474,9 @@ lt_simple_link_test_code='public class conftest { public static void main(String
# If no C compiler was specified, use CC.
LTCC=${LTCC-"$CC"}
+# If no C compiler flags were specified, use CFLAGS.
+LTCFLAGS=${LTCFLAGS-"$CFLAGS"}
+
# Allow CC to be a program name with arguments.
compiler=$CC
@@ -15855,13 +15484,13 @@ compiler=$CC
# save warnings/boilerplate of simple test code
ac_outfile=conftest.$ac_objext
printf "$lt_simple_compile_test_code" >conftest.$ac_ext
-eval "$ac_compile" 2>&1 >/dev/null | $SED '/^$/d' >conftest.err
+eval "$ac_compile" 2>&1 >/dev/null | $SED '/^$/d; /^ *+/d' >conftest.err
_lt_compiler_boilerplate=`cat conftest.err`
$rm conftest*
ac_outfile=conftest.$ac_objext
printf "$lt_simple_link_test_code" >conftest.$ac_ext
-eval "$ac_link" 2>&1 >/dev/null | $SED '/^$/d' >conftest.err
+eval "$ac_link" 2>&1 >/dev/null | $SED '/^$/d; /^ *+/d' >conftest.err
_lt_linker_boilerplate=`cat conftest.err`
$rm conftest*
@@ -15909,20 +15538,20 @@ else
# with a dollar sign (not a hyphen), so the echo should work correctly.
# The option is referenced via a variable to avoid confusing sed.
lt_compile=`echo "$ac_compile" | $SED \
- -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
+ -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
-e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
-e 's:$: $lt_compiler_flag:'`
- (eval echo "\"\$as_me:15915: $lt_compile\"" >&5)
+ (eval echo "\"\$as_me:15544: $lt_compile\"" >&5)
(eval "$lt_compile" 2>conftest.err)
ac_status=$?
cat conftest.err >&5
- echo "$as_me:15919: \$? = $ac_status" >&5
+ echo "$as_me:15548: \$? = $ac_status" >&5
if (exit $ac_status) && test -s "$ac_outfile"; then
# The compiler can only warn and ignore the option if not recognized
# So say no if there are warnings other than the usual output.
- $echo "X$_lt_compiler_boilerplate" | $Xsed >conftest.exp
- $SED '/^$/d' conftest.err >conftest.er2
- if test ! -s conftest.err || diff conftest.exp conftest.er2 >/dev/null; then
+ $echo "X$_lt_compiler_boilerplate" | $Xsed -e '/^$/d' >conftest.exp
+ $SED '/^$/d; /^ *+/d' conftest.err >conftest.er2
+ if test ! -s conftest.er2 || diff conftest.exp conftest.er2 >/dev/null; then
lt_cv_prog_compiler_rtti_exceptions=yes
fi
fi
@@ -15983,6 +15612,11 @@ echo $ECHO_N "checking for $compiler option to produce PIC... $ECHO_C" >&6
lt_prog_compiler_pic_GCJ='-fno-common'
;;
+ interix3*)
+ # Interix 3.x gcc -fpic/-fPIC options generate broken code.
+ # Instead, we relocate shared libraries at runtime.
+ ;;
+
msdosdjgpp*)
# Just because we use GCC doesn't mean we suddenly get shared libraries
# on systems that don't support them.
@@ -15999,7 +15633,7 @@ echo $ECHO_N "checking for $compiler option to produce PIC... $ECHO_C" >&6
hpux*)
# PIC is the default for IA64 HP-UX and 64-bit HP-UX, but
# not for PA HP-UX.
- case "$host_cpu" in
+ case $host_cpu in
hppa*64*|ia64*)
# +Z the default
;;
@@ -16046,7 +15680,7 @@ echo $ECHO_N "checking for $compiler option to produce PIC... $ECHO_C" >&6
lt_prog_compiler_wl_GCJ='-Wl,'
# PIC is the default for IA64 HP-UX and 64-bit HP-UX, but
# not for PA HP-UX.
- case "$host_cpu" in
+ case $host_cpu in
hppa*64*|ia64*)
# +Z the default
;;
@@ -16076,12 +15710,12 @@ echo $ECHO_N "checking for $compiler option to produce PIC... $ECHO_C" >&6
lt_prog_compiler_pic_GCJ='-KPIC'
lt_prog_compiler_static_GCJ='-static'
;;
- pgcc* | pgf77* | pgf90*)
+ pgcc* | pgf77* | pgf90* | pgf95*)
# Portland Group compilers (*not* the Pentium gcc compiler,
# which looks to be a dead project)
lt_prog_compiler_wl_GCJ='-Wl,'
lt_prog_compiler_pic_GCJ='-fpic'
- lt_prog_compiler_static_GCJ='-static'
+ lt_prog_compiler_static_GCJ='-Bstatic'
;;
ccc*)
lt_prog_compiler_wl_GCJ='-Wl,'
@@ -16097,11 +15731,6 @@ echo $ECHO_N "checking for $compiler option to produce PIC... $ECHO_C" >&6
lt_prog_compiler_static_GCJ='-non_shared'
;;
- sco3.2v5*)
- lt_prog_compiler_pic_GCJ='-Kpic'
- lt_prog_compiler_static_GCJ='-dn'
- ;;
-
solaris*)
lt_prog_compiler_pic_GCJ='-KPIC'
lt_prog_compiler_static_GCJ='-Bstatic'
@@ -16119,7 +15748,7 @@ echo $ECHO_N "checking for $compiler option to produce PIC... $ECHO_C" >&6
lt_prog_compiler_static_GCJ='-Bstatic'
;;
- sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
+ sysv4 | sysv4.2uw2* | sysv4.3*)
lt_prog_compiler_wl_GCJ='-Wl,'
lt_prog_compiler_pic_GCJ='-KPIC'
lt_prog_compiler_static_GCJ='-Bstatic'
@@ -16132,6 +15761,12 @@ echo $ECHO_N "checking for $compiler option to produce PIC... $ECHO_C" >&6
fi
;;
+ sysv5* | unixware* | sco3.2v5* | sco5v6* | OpenUNIX*)
+ lt_prog_compiler_wl_GCJ='-Wl,'
+ lt_prog_compiler_pic_GCJ='-KPIC'
+ lt_prog_compiler_static_GCJ='-Bstatic'
+ ;;
+
unicos*)
lt_prog_compiler_wl_GCJ='-Wl,'
lt_prog_compiler_can_build_shared_GCJ=no
@@ -16171,20 +15806,20 @@ else
# with a dollar sign (not a hyphen), so the echo should work correctly.
# The option is referenced via a variable to avoid confusing sed.
lt_compile=`echo "$ac_compile" | $SED \
- -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
+ -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
-e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
-e 's:$: $lt_compiler_flag:'`
- (eval echo "\"\$as_me:16177: $lt_compile\"" >&5)
+ (eval echo "\"\$as_me:15812: $lt_compile\"" >&5)
(eval "$lt_compile" 2>conftest.err)
ac_status=$?
cat conftest.err >&5
- echo "$as_me:16181: \$? = $ac_status" >&5
+ echo "$as_me:15816: \$? = $ac_status" >&5
if (exit $ac_status) && test -s "$ac_outfile"; then
# The compiler can only warn and ignore the option if not recognized
# So say no if there are warnings other than the usual output.
- $echo "X$_lt_compiler_boilerplate" | $Xsed >conftest.exp
- $SED '/^$/d' conftest.err >conftest.er2
- if test ! -s conftest.err || diff conftest.exp conftest.er2 >/dev/null; then
+ $echo "X$_lt_compiler_boilerplate" | $Xsed -e '/^$/d' >conftest.exp
+ $SED '/^$/d; /^ *+/d' conftest.err >conftest.er2
+ if test ! -s conftest.er2 || diff conftest.exp conftest.er2 >/dev/null; then
lt_prog_compiler_pic_works_GCJ=yes
fi
fi
@@ -16205,7 +15840,7 @@ else
fi
fi
-case "$host_os" in
+case $host_os in
# For platforms which do not support PIC, -DPIC is meaningless:
*djgpp*)
lt_prog_compiler_pic_GCJ=
@@ -16215,6 +15850,48 @@ case "$host_os" in
;;
esac
+#
+# Check to make sure the static flag actually works.
+#
+wl=$lt_prog_compiler_wl_GCJ eval lt_tmp_static_flag=\"$lt_prog_compiler_static_GCJ\"
+echo "$as_me:$LINENO: checking if $compiler static flag $lt_tmp_static_flag works" >&5
+echo $ECHO_N "checking if $compiler static flag $lt_tmp_static_flag works... $ECHO_C" >&6
+if test "${lt_prog_compiler_static_works_GCJ+set}" = set; then
+ echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+ lt_prog_compiler_static_works_GCJ=no
+ save_LDFLAGS="$LDFLAGS"
+ LDFLAGS="$LDFLAGS $lt_tmp_static_flag"
+ printf "$lt_simple_link_test_code" > conftest.$ac_ext
+ if (eval $ac_link 2>conftest.err) && test -s conftest$ac_exeext; then
+ # The linker can only warn and ignore the option if not recognized
+ # So say no if there are warnings
+ if test -s conftest.err; then
+ # Append any errors to the config.log.
+ cat conftest.err 1>&5
+ $echo "X$_lt_linker_boilerplate" | $Xsed -e '/^$/d' > conftest.exp
+ $SED '/^$/d; /^ *+/d' conftest.err >conftest.er2
+ if diff conftest.exp conftest.er2 >/dev/null; then
+ lt_prog_compiler_static_works_GCJ=yes
+ fi
+ else
+ lt_prog_compiler_static_works_GCJ=yes
+ fi
+ fi
+ $rm conftest*
+ LDFLAGS="$save_LDFLAGS"
+
+fi
+echo "$as_me:$LINENO: result: $lt_prog_compiler_static_works_GCJ" >&5
+echo "${ECHO_T}$lt_prog_compiler_static_works_GCJ" >&6
+
+if test x"$lt_prog_compiler_static_works_GCJ" = xyes; then
+ :
+else
+ lt_prog_compiler_static_GCJ=
+fi
+
+
echo "$as_me:$LINENO: checking if $compiler supports -c -o file.$ac_objext" >&5
echo $ECHO_N "checking if $compiler supports -c -o file.$ac_objext... $ECHO_C" >&6
if test "${lt_cv_prog_compiler_c_o_GCJ+set}" = set; then
@@ -16233,25 +15910,25 @@ else
# Note that $ac_compile itself does not contain backslashes and begins
# with a dollar sign (not a hyphen), so the echo should work correctly.
lt_compile=`echo "$ac_compile" | $SED \
- -e 's:.*FLAGS}? :&$lt_compiler_flag :; t' \
+ -e 's:.*FLAGS}\{0,1\} :&$lt_compiler_flag :; t' \
-e 's: [^ ]*conftest\.: $lt_compiler_flag&:; t' \
-e 's:$: $lt_compiler_flag:'`
- (eval echo "\"\$as_me:16239: $lt_compile\"" >&5)
+ (eval echo "\"\$as_me:15916: $lt_compile\"" >&5)
(eval "$lt_compile" 2>out/conftest.err)
ac_status=$?
cat out/conftest.err >&5
- echo "$as_me:16243: \$? = $ac_status" >&5
+ echo "$as_me:15920: \$? = $ac_status" >&5
if (exit $ac_status) && test -s out/conftest2.$ac_objext
then
# The compiler can only warn and ignore the option if not recognized
# So say no if there are warnings
- $echo "X$_lt_compiler_boilerplate" | $Xsed > out/conftest.exp
- $SED '/^$/d' out/conftest.err >out/conftest.er2
- if test ! -s out/conftest.err || diff out/conftest.exp out/conftest.er2 >/dev/null; then
+ $echo "X$_lt_compiler_boilerplate" | $Xsed -e '/^$/d' > out/conftest.exp
+ $SED '/^$/d; /^ *+/d' out/conftest.err >out/conftest.er2
+ if test ! -s out/conftest.er2 || diff out/conftest.exp out/conftest.er2 >/dev/null; then
lt_cv_prog_compiler_c_o_GCJ=yes
fi
fi
- chmod u+w .
+ chmod u+w . 2>&5
$rm conftest*
# SGI C++ compiler will create directory out/ii_files/ for
# template instantiation
@@ -16347,6 +16024,10 @@ cc_basename=`$echo "X$cc_temp" | $Xsed -e 's%.*/%%' -e "s%^$host_alias-%%"`
with_gnu_ld=no
fi
;;
+ interix*)
+ # we just hope/assume this is gcc and not c89 (= MSVC++)
+ with_gnu_ld=yes
+ ;;
openbsd*)
with_gnu_ld=no
;;
@@ -16431,7 +16112,7 @@ EOF
export_symbols_cmds_GCJ='$NM $libobjs $convenience | $global_symbol_pipe | $SED -e '\''/^[BCDGRS] /s/.* \([^ ]*\)/\1 DATA/'\'' | $SED -e '\''/^[AITW] /s/.* //'\'' | sort | uniq > $export_symbols'
if $LD --help 2>&1 | grep 'auto-import' > /dev/null; then
- archive_cmds_GCJ='$CC -shared $libobjs $deplibs $compiler_flags -o $output_objdir/$soname ${wl}--image-base=0x10000000 ${wl}--out-implib,$lib'
+ archive_cmds_GCJ='$CC -shared $libobjs $deplibs $compiler_flags -o $output_objdir/$soname ${wl}--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib'
# If the export-symbols file already is a .def file (1st line
# is EXPORTS), use it as is; otherwise, prepend...
archive_expsym_cmds_GCJ='if test "x`$SED 1q $export_symbols`" = xEXPORTS; then
@@ -16440,22 +16121,37 @@ EOF
echo EXPORTS > $output_objdir/$soname.def;
cat $export_symbols >> $output_objdir/$soname.def;
fi~
- $CC -shared $output_objdir/$soname.def $libobjs $deplibs $compiler_flags -o $output_objdir/$soname ${wl}--image-base=0x10000000 ${wl}--out-implib,$lib'
+ $CC -shared $output_objdir/$soname.def $libobjs $deplibs $compiler_flags -o $output_objdir/$soname ${wl}--enable-auto-image-base -Xlinker --out-implib -Xlinker $lib'
else
ld_shlibs_GCJ=no
fi
;;
+ interix3*)
+ hardcode_direct_GCJ=no
+ hardcode_shlibpath_var_GCJ=no
+ hardcode_libdir_flag_spec_GCJ='${wl}-rpath,$libdir'
+ export_dynamic_flag_spec_GCJ='${wl}-E'
+ # Hack: On Interix 3.x, we cannot compile PIC because of a broken gcc.
+ # Instead, shared libraries are loaded at an image base (0x10000000 by
+ # default) and relocated if they conflict, which is a slow very memory
+ # consuming and fragmenting process. To avoid this, we pick a random,
+ # 256 KiB-aligned image base between 0x50000000 and 0x6FFC0000 at link
+ # time. Moving up from 0x10000000 also allows more sbrk(2) space.
+ archive_cmds_GCJ='$CC -shared $pic_flag $libobjs $deplibs $compiler_flags ${wl}-h,$soname ${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
+ archive_expsym_cmds_GCJ='sed "s,^,_," $export_symbols >$output_objdir/$soname.expsym~$CC -shared $pic_flag $libobjs $deplibs $compiler_flags ${wl}-h,$soname ${wl}--retain-symbols-file,$output_objdir/$soname.expsym ${wl}--image-base,`expr ${RANDOM-$$} % 4096 / 2 \* 262144 + 1342177280` -o $lib'
+ ;;
+
linux*)
if $LD --help 2>&1 | grep ': supported targets:.* elf' > /dev/null; then
tmp_addflag=
case $cc_basename,$host_cpu in
pgcc*) # Portland Group C compiler
- whole_archive_flag_spec_GCJ='${wl}--whole-archive,`for conv in $convenience\"\"; do test -n \"$conv\" && new_convenience=\"$new_convenience,$conv\"; done; $echo \"$new_convenience\"` ${wl}--no-whole-archive'
+ whole_archive_flag_spec_GCJ='${wl}--whole-archive`for conv in $convenience\"\"; do test -n \"$conv\" && new_convenience=\"$new_convenience,$conv\"; done; $echo \"$new_convenience\"` ${wl}--no-whole-archive'
tmp_addflag=' $pic_flag'
;;
- pgf77* | pgf90* ) # Portland Group f77 and f90 compilers
- whole_archive_flag_spec_GCJ='${wl}--whole-archive,`for conv in $convenience\"\"; do test -n \"$conv\" && new_convenience=\"$new_convenience,$conv\"; done; $echo \"$new_convenience\"` ${wl}--no-whole-archive'
+ pgf77* | pgf90* | pgf95*) # Portland Group f77 and f90 compilers
+ whole_archive_flag_spec_GCJ='${wl}--whole-archive`for conv in $convenience\"\"; do test -n \"$conv\" && new_convenience=\"$new_convenience,$conv\"; done; $echo \"$new_convenience\"` ${wl}--no-whole-archive'
tmp_addflag=' $pic_flag -Mnomain' ;;
ecc*,ia64* | icc*,ia64*) # Intel C compiler on ia64
tmp_addflag=' -i_dynamic' ;;
@@ -16487,7 +16183,7 @@ EOF
fi
;;
- solaris* | sysv5*)
+ solaris*)
if $LD -v 2>&1 | grep 'BFD 2\.8' > /dev/null; then
ld_shlibs_GCJ=no
cat <<EOF 1>&2
@@ -16508,6 +16204,33 @@ EOF
fi
;;
+ sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX*)
+ case `$LD -v 2>&1` in
+ *\ [01].* | *\ 2.[0-9].* | *\ 2.1[0-5].*)
+ ld_shlibs_GCJ=no
+ cat <<_LT_EOF 1>&2
+
+*** Warning: Releases of the GNU linker prior to 2.16.91.0.3 can not
+*** reliably create shared libraries on SCO systems. Therefore, libtool
+*** is disabling shared libraries support. We urge you to upgrade GNU
+*** binutils to release 2.16.91.0.3 or newer. Another option is to modify
+*** your PATH or compiler configuration so that the native linker is
+*** used, and then restart.
+
+_LT_EOF
+ ;;
+ *)
+ if $LD --help 2>&1 | grep ': supported targets:.* elf' > /dev/null; then
+ hardcode_libdir_flag_spec_GCJ='`test -z "$SCOABSPATH" && echo ${wl}-rpath,$libdir`'
+ archive_cmds_GCJ='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib'
+ archive_expsym_cmds_GCJ='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname,\${SCOABSPATH:+${install_libdir}/}$soname,-retain-symbols-file,$export_symbols -o $lib'
+ else
+ ld_shlibs_GCJ=no
+ fi
+ ;;
+ esac
+ ;;
+
sunos4*)
archive_cmds_GCJ='$LD -assert pure-text -Bshareable -o $lib $libobjs $deplibs $linker_flags'
wlarc=
@@ -16541,7 +16264,7 @@ EOF
# Note: this linker hardcodes the directories in LIBPATH if there
# are no directories specified by -L.
hardcode_minus_L_GCJ=yes
- if test "$GCC" = yes && test -z "$link_static_flag"; then
+ if test "$GCC" = yes && test -z "$lt_prog_compiler_static"; then
# Neither direct hardcoding nor static linking is supported with a
# broken collect2.
hardcode_direct_GCJ=unsupported
@@ -16575,6 +16298,7 @@ EOF
break
fi
done
+ ;;
esac
exp_sym_flag='-bexport'
@@ -16612,6 +16336,7 @@ EOF
hardcode_libdir_flag_spec_GCJ='-L$libdir'
hardcode_libdir_separator_GCJ=
fi
+ ;;
esac
shared_flag='-shared'
if test "$aix_use_runtimelinking" = yes; then
@@ -16624,11 +16349,11 @@ EOF
# chokes on -Wl,-G. The following line is correct:
shared_flag='-G'
else
- if test "$aix_use_runtimelinking" = yes; then
+ if test "$aix_use_runtimelinking" = yes; then
shared_flag='${wl}-G'
else
shared_flag='${wl}-bM:SRE'
- fi
+ fi
fi
fi
@@ -16693,12 +16418,12 @@ rm -f conftest.err conftest.$ac_objext \
if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
hardcode_libdir_flag_spec_GCJ='${wl}-blibpath:$libdir:'"$aix_libpath"
- archive_expsym_cmds_GCJ="\$CC"' -o $output_objdir/$soname $libobjs $deplibs $compiler_flags `if test "x${allow_undefined_flag}" != "x"; then echo "${wl}${allow_undefined_flag}"; else :; fi` '"\${wl}$no_entry_flag \${wl}$exp_sym_flag:\$export_symbols $shared_flag"
+ archive_expsym_cmds_GCJ="\$CC"' -o $output_objdir/$soname $libobjs $deplibs '"\${wl}$no_entry_flag"' $compiler_flags `if test "x${allow_undefined_flag}" != "x"; then echo "${wl}${allow_undefined_flag}"; else :; fi` '"\${wl}$exp_sym_flag:\$export_symbols $shared_flag"
else
if test "$host_cpu" = ia64; then
hardcode_libdir_flag_spec_GCJ='${wl}-R $libdir:/usr/lib:/lib'
allow_undefined_flag_GCJ="-z nodefs"
- archive_expsym_cmds_GCJ="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs $compiler_flags ${wl}${allow_undefined_flag} '"\${wl}$no_entry_flag \${wl}$exp_sym_flag:\$export_symbols"
+ archive_expsym_cmds_GCJ="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs '"\${wl}$no_entry_flag"' $compiler_flags ${wl}${allow_undefined_flag} '"\${wl}$exp_sym_flag:\$export_symbols"
else
# Determine the default libpath from the value encoded in an empty executable.
cat >conftest.$ac_ext <<_ACEOF
@@ -16758,13 +16483,11 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
# -berok will link without error, but may produce a broken library.
no_undefined_flag_GCJ=' ${wl}-bernotok'
allow_undefined_flag_GCJ=' ${wl}-berok'
- # -bexpall does not export symbols beginning with underscore (_)
- always_export_symbols_GCJ=yes
# Exported symbols can be pulled into shared objects from archives
- whole_archive_flag_spec_GCJ=' '
+ whole_archive_flag_spec_GCJ='$convenience'
archive_cmds_need_lc_GCJ=yes
- # This is similar to how AIX traditionally builds it's shared libraries.
- archive_expsym_cmds_GCJ="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs $compiler_flags ${wl}-bE:$export_symbols ${wl}-bnoentry${allow_undefined_flag}~$AR $AR_FLAGS $output_objdir/$libname$release.a $output_objdir/$soname'
+ # This is similar to how AIX traditionally builds its shared libraries.
+ archive_expsym_cmds_GCJ="\$CC $shared_flag"' -o $output_objdir/$soname $libobjs $deplibs ${wl}-bnoentry $compiler_flags ${wl}-bE:$export_symbols${allow_undefined_flag}~$AR $AR_FLAGS $output_objdir/$libname$release.a $output_objdir/$soname'
fi
fi
;;
@@ -16803,7 +16526,7 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
;;
darwin* | rhapsody*)
- case "$host_os" in
+ case $host_os in
rhapsody* | darwin1.[012])
allow_undefined_flag_GCJ='${wl}-undefined ${wl}suppress'
;;
@@ -16832,7 +16555,7 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
output_verbose_link_cmd='echo'
archive_cmds_GCJ='$CC -dynamiclib $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags -install_name $rpath/$soname $verstring'
module_cmds_GCJ='$CC $allow_undefined_flag -o $lib -bundle $libobjs $deplibs$compiler_flags'
- # Don't fix this by using the ld -exported_symbols_list flag, it doesn't exist in older darwin ld's
+ # Don't fix this by using the ld -exported_symbols_list flag, it doesn't exist in older darwin lds
archive_expsym_cmds_GCJ='sed -e "s,#.*,," -e "s,^[ ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC -dynamiclib $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags -install_name $rpath/$soname $verstring~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
module_expsym_cmds_GCJ='sed -e "s,#.*,," -e "s,^[ ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC $allow_undefined_flag -o $lib -bundle $libobjs $deplibs$compiler_flags~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
else
@@ -16841,7 +16564,7 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
output_verbose_link_cmd='echo'
archive_cmds_GCJ='$CC -qmkshrobj $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags ${wl}-install_name ${wl}`echo $rpath/$soname` $verstring'
module_cmds_GCJ='$CC $allow_undefined_flag -o $lib -bundle $libobjs $deplibs$compiler_flags'
- # Don't fix this by using the ld -exported_symbols_list flag, it doesn't exist in older darwin ld's
+ # Don't fix this by using the ld -exported_symbols_list flag, it doesn't exist in older darwin lds
archive_expsym_cmds_GCJ='sed -e "s,#.*,," -e "s,^[ ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC -qmkshrobj $allow_undefined_flag -o $lib $libobjs $deplibs $compiler_flags ${wl}-install_name ${wl}$rpath/$soname $verstring~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
module_expsym_cmds_GCJ='sed -e "s,#.*,," -e "s,^[ ]*,," -e "s,^\(..*\),_&," < $export_symbols > $output_objdir/${libname}-symbols.expsym~$CC $allow_undefined_flag -o $lib -bundle $libobjs $deplibs$compiler_flags~nmedit -s $output_objdir/${libname}-symbols.expsym ${lib}'
;;
@@ -16905,47 +16628,62 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
export_dynamic_flag_spec_GCJ='${wl}-E'
;;
- hpux10* | hpux11*)
+ hpux10*)
if test "$GCC" = yes -a "$with_gnu_ld" = no; then
- case "$host_cpu" in
- hppa*64*|ia64*)
+ archive_cmds_GCJ='$CC -shared -fPIC ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
+ else
+ archive_cmds_GCJ='$LD -b +h $soname +b $install_libdir -o $lib $libobjs $deplibs $linker_flags'
+ fi
+ if test "$with_gnu_ld" = no; then
+ hardcode_libdir_flag_spec_GCJ='${wl}+b ${wl}$libdir'
+ hardcode_libdir_separator_GCJ=:
+
+ hardcode_direct_GCJ=yes
+ export_dynamic_flag_spec_GCJ='${wl}-E'
+
+ # hardcode_minus_L: Not really in the search PATH,
+ # but as the default location of the library.
+ hardcode_minus_L_GCJ=yes
+ fi
+ ;;
+
+ hpux11*)
+ if test "$GCC" = yes -a "$with_gnu_ld" = no; then
+ case $host_cpu in
+ hppa*64*)
archive_cmds_GCJ='$CC -shared ${wl}+h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
;;
+ ia64*)
+ archive_cmds_GCJ='$CC -shared ${wl}+h ${wl}$soname ${wl}+nodefaultrpath -o $lib $libobjs $deplibs $compiler_flags'
+ ;;
*)
archive_cmds_GCJ='$CC -shared -fPIC ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
;;
esac
else
- case "$host_cpu" in
- hppa*64*|ia64*)
- archive_cmds_GCJ='$LD -b +h $soname -o $lib $libobjs $deplibs $linker_flags'
+ case $host_cpu in
+ hppa*64*)
+ archive_cmds_GCJ='$CC -b ${wl}+h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
+ ;;
+ ia64*)
+ archive_cmds_GCJ='$CC -b ${wl}+h ${wl}$soname ${wl}+nodefaultrpath -o $lib $libobjs $deplibs $compiler_flags'
;;
*)
- archive_cmds_GCJ='$LD -b +h $soname +b $install_libdir -o $lib $libobjs $deplibs $linker_flags'
+ archive_cmds_GCJ='$CC -b ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
;;
esac
fi
if test "$with_gnu_ld" = no; then
- case "$host_cpu" in
- hppa*64*)
- hardcode_libdir_flag_spec_GCJ='${wl}+b ${wl}$libdir'
+ hardcode_libdir_flag_spec_GCJ='${wl}+b ${wl}$libdir'
+ hardcode_libdir_separator_GCJ=:
+
+ case $host_cpu in
+ hppa*64*|ia64*)
hardcode_libdir_flag_spec_ld_GCJ='+b $libdir'
- hardcode_libdir_separator_GCJ=:
- hardcode_direct_GCJ=no
- hardcode_shlibpath_var_GCJ=no
- ;;
- ia64*)
- hardcode_libdir_flag_spec_GCJ='-L$libdir'
hardcode_direct_GCJ=no
hardcode_shlibpath_var_GCJ=no
-
- # hardcode_minus_L: Not really in the search PATH,
- # but as the default location of the library.
- hardcode_minus_L_GCJ=yes
;;
*)
- hardcode_libdir_flag_spec_GCJ='${wl}+b ${wl}$libdir'
- hardcode_libdir_separator_GCJ=:
hardcode_direct_GCJ=yes
export_dynamic_flag_spec_GCJ='${wl}-E'
@@ -17047,14 +16785,6 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
hardcode_libdir_separator_GCJ=:
;;
- sco3.2v5*)
- archive_cmds_GCJ='$LD -G -h $soname -o $lib $libobjs $deplibs $linker_flags'
- hardcode_shlibpath_var_GCJ=no
- export_dynamic_flag_spec_GCJ='${wl}-Bexport'
- runpath_var=LD_RUN_PATH
- hardcode_runpath_var=yes
- ;;
-
solaris*)
no_undefined_flag_GCJ=' -z text'
if test "$GCC" = yes; then
@@ -17140,36 +16870,45 @@ if test -z "$aix_libpath"; then aix_libpath="/usr/lib:/lib"; fi
fi
;;
- sysv4.2uw2*)
- archive_cmds_GCJ='$LD -G -o $lib $libobjs $deplibs $linker_flags'
- hardcode_direct_GCJ=yes
- hardcode_minus_L_GCJ=no
+ sysv4*uw2* | sysv5OpenUNIX* | sysv5UnixWare7.[01].[10]* | unixware7*)
+ no_undefined_flag_GCJ='${wl}-z,text'
+ archive_cmds_need_lc_GCJ=no
hardcode_shlibpath_var_GCJ=no
- hardcode_runpath_var=yes
- runpath_var=LD_RUN_PATH
- ;;
+ runpath_var='LD_RUN_PATH'
- sysv5OpenUNIX8* | sysv5UnixWare7* | sysv5uw[78]* | unixware7*)
- no_undefined_flag_GCJ='${wl}-z ${wl}text'
if test "$GCC" = yes; then
- archive_cmds_GCJ='$CC -shared ${wl}-h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
+ archive_cmds_GCJ='$CC -shared ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
+ archive_expsym_cmds_GCJ='$CC -shared ${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
else
- archive_cmds_GCJ='$CC -G ${wl}-h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
+ archive_cmds_GCJ='$CC -G ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
+ archive_expsym_cmds_GCJ='$CC -G ${wl}-Bexport:$export_symbols ${wl}-h,$soname -o $lib $libobjs $deplibs $compiler_flags'
fi
- runpath_var='LD_RUN_PATH'
- hardcode_shlibpath_var_GCJ=no
;;
- sysv5*)
- no_undefined_flag_GCJ=' -z text'
- # $CC -shared without GNU ld will not create a library from C++
- # object files and a static libstdc++, better avoid it by now
- archive_cmds_GCJ='$LD -G${allow_undefined_flag} -h $soname -o $lib $libobjs $deplibs $linker_flags'
- archive_expsym_cmds_GCJ='$echo "{ global:" > $lib.exp~cat $export_symbols | $SED -e "s/\(.*\)/\1;/" >> $lib.exp~$echo "local: *; };" >> $lib.exp~
- $LD -G${allow_undefined_flag} -M $lib.exp -h $soname -o $lib $libobjs $deplibs $linker_flags~$rm $lib.exp'
- hardcode_libdir_flag_spec_GCJ=
+ sysv5* | sco3.2v5* | sco5v6*)
+ # Note: We can NOT use -z defs as we might desire, because we do not
+ # link with -lc, and that would cause any symbols used from libc to
+ # always be unresolved, which means just about no library would
+ # ever link correctly. If we're not using GNU ld we use -z text
+ # though, which does catch some bad symbols but isn't as heavy-handed
+ # as -z defs.
+ no_undefined_flag_GCJ='${wl}-z,text'
+ allow_undefined_flag_GCJ='${wl}-z,nodefs'
+ archive_cmds_need_lc_GCJ=no
hardcode_shlibpath_var_GCJ=no
+ hardcode_libdir_flag_spec_GCJ='`test -z "$SCOABSPATH" && echo ${wl}-R,$libdir`'
+ hardcode_libdir_separator_GCJ=':'
+ link_all_deplibs_GCJ=yes
+ export_dynamic_flag_spec_GCJ='${wl}-Bexport'
runpath_var='LD_RUN_PATH'
+
+ if test "$GCC" = yes; then
+ archive_cmds_GCJ='$CC -shared ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+ archive_expsym_cmds_GCJ='$CC -shared ${wl}-Bexport:$export_symbols ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+ else
+ archive_cmds_GCJ='$CC -G ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+ archive_expsym_cmds_GCJ='$CC -G ${wl}-Bexport:$export_symbols ${wl}-h,\${SCOABSPATH:+${install_libdir}/}$soname -o $lib $libobjs $deplibs $compiler_flags'
+ fi
;;
uts4*)
@@ -17188,11 +16927,6 @@ echo "$as_me:$LINENO: result: $ld_shlibs_GCJ" >&5
echo "${ECHO_T}$ld_shlibs_GCJ" >&6
test "$ld_shlibs_GCJ" = no && can_build_shared=no
-variables_saved_for_relink="PATH $shlibpath_var $runpath_var"
-if test "$GCC" = yes; then
- variables_saved_for_relink="$variables_saved_for_relink GCC_EXEC_PREFIX COMPILER_PATH LIBRARY_PATH"
-fi
-
#
# Do we need to explicitly link libc?
#
@@ -17225,6 +16959,7 @@ echo $ECHO_N "checking whether -lc should be explicitly linked in... $ECHO_C" >&
libobjs=conftest.$ac_objext
deplibs=
wl=$lt_prog_compiler_wl_GCJ
+ pic_flag=$lt_prog_compiler_pic_GCJ
compiler_flags=-v
linker_flags=-v
verstring=
@@ -17334,1347 +17069,559 @@ aix4* | aix5*)
# If using run time linking (on AIX 4.2 or later) use lib<name>.so
# instead of lib<name>.a to let people know that these are not
# typical AIX shared libraries.
- library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
- else
- # We preserve .a as extension for shared libraries through AIX4.2
- # and later when we are not doing run time linking.
- library_names_spec='${libname}${release}.a $libname.a'
- soname_spec='${libname}${release}${shared_ext}$major'
- fi
- shlibpath_var=LIBPATH
- fi
- ;;
-
-amigaos*)
- library_names_spec='$libname.ixlibrary $libname.a'
- # Create ${libname}_ixlibrary.a entries in /sys/libs.
- finish_eval='for lib in `ls $libdir/*.ixlibrary 2>/dev/null`; do libname=`$echo "X$lib" | $Xsed -e '\''s%^.*/\([^/]*\)\.ixlibrary$%\1%'\''`; test $rm /sys/libs/${libname}_ixlibrary.a; $show "cd /sys/libs && $LN_S $lib ${libname}_ixlibrary.a"; cd /sys/libs && $LN_S $lib ${libname}_ixlibrary.a || exit 1; done'
- ;;
-
-beos*)
- library_names_spec='${libname}${shared_ext}'
- dynamic_linker="$host_os ld.so"
- shlibpath_var=LIBRARY_PATH
- ;;
-
-bsdi[45]*)
- version_type=linux
- need_version=no
- library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
- soname_spec='${libname}${release}${shared_ext}$major'
- finish_cmds='PATH="\$PATH:/sbin" ldconfig $libdir'
- shlibpath_var=LD_LIBRARY_PATH
- sys_lib_search_path_spec="/shlib /usr/lib /usr/X11/lib /usr/contrib/lib /lib /usr/local/lib"
- sys_lib_dlsearch_path_spec="/shlib /usr/lib /usr/local/lib"
- # the default ld.so.conf also contains /usr/contrib/lib and
- # /usr/X11R6/lib (/usr/X11 is a link to /usr/X11R6), but let us allow
- # libtool to hard-code these into programs
- ;;
-
-cygwin* | mingw* | pw32*)
- version_type=windows
- shrext_cmds=".dll"
- need_version=no
- need_lib_prefix=no
-
- case $GCC,$host_os in
- yes,cygwin* | yes,mingw* | yes,pw32*)
- library_names_spec='$libname.dll.a'
- # DLL is installed to $(libdir)/../bin by postinstall_cmds
- postinstall_cmds='base_file=`basename \${file}`~
- dlpath=`$SHELL 2>&1 -c '\''. $dir/'\''\${base_file}'\''i;echo \$dlname'\''`~
- dldir=$destdir/`dirname \$dlpath`~
- test -d \$dldir || mkdir -p \$dldir~
- $install_prog $dir/$dlname \$dldir/$dlname'
- postuninstall_cmds='dldll=`$SHELL 2>&1 -c '\''. $file; echo \$dlname'\''`~
- dlpath=$dir/\$dldll~
- $rm \$dlpath'
- shlibpath_overrides_runpath=yes
-
- case $host_os in
- cygwin*)
- # Cygwin DLLs use 'cyg' prefix rather than 'lib'
- soname_spec='`echo ${libname} | sed -e 's/^lib/cyg/'``echo ${release} | $SED -e 's/[.]/-/g'`${versuffix}${shared_ext}'
- sys_lib_search_path_spec="/usr/lib /lib/w32api /lib /usr/local/lib"
- ;;
- mingw*)
- # MinGW DLLs use traditional 'lib' prefix
- soname_spec='${libname}`echo ${release} | $SED -e 's/[.]/-/g'`${versuffix}${shared_ext}'
- sys_lib_search_path_spec=`$CC -print-search-dirs | grep "^libraries:" | $SED -e "s/^libraries://" -e "s,=/,/,g"`
- if echo "$sys_lib_search_path_spec" | grep ';[c-zC-Z]:/' >/dev/null; then
- # It is most probably a Windows format PATH printed by
- # mingw gcc, but we are running on Cygwin. Gcc prints its search
- # path with ; separators, and with drive letters. We can handle the
- # drive letters (cygwin fileutils understands them), so leave them,
- # especially as we might pass files found there to a mingw objdump,
- # which wouldn't understand a cygwinified path. Ahh.
- sys_lib_search_path_spec=`echo "$sys_lib_search_path_spec" | $SED -e 's/;/ /g'`
- else
- sys_lib_search_path_spec=`echo "$sys_lib_search_path_spec" | $SED -e "s/$PATH_SEPARATOR/ /g"`
- fi
- ;;
- pw32*)
- # pw32 DLLs use 'pw' prefix rather than 'lib'
- library_names_spec='`echo ${libname} | sed -e 's/^lib/pw/'``echo ${release} | $SED -e 's/[.]/-/g'`${versuffix}${shared_ext}'
- ;;
- esac
- ;;
-
- *)
- library_names_spec='${libname}`echo ${release} | $SED -e 's/[.]/-/g'`${versuffix}${shared_ext} $libname.lib'
- ;;
- esac
- dynamic_linker='Win32 ld.exe'
- # FIXME: first we should search . and the directory the executable is in
- shlibpath_var=PATH
- ;;
-
-darwin* | rhapsody*)
- dynamic_linker="$host_os dyld"
- version_type=darwin
- need_lib_prefix=no
- need_version=no
- library_names_spec='${libname}${release}${versuffix}$shared_ext ${libname}${release}${major}$shared_ext ${libname}$shared_ext'
- soname_spec='${libname}${release}${major}$shared_ext'
- shlibpath_overrides_runpath=yes
- shlibpath_var=DYLD_LIBRARY_PATH
- shrext_cmds='$(test .$module = .yes && echo .so || echo .dylib)'
- # Apple's gcc prints 'gcc -print-search-dirs' doesn't operate the same.
- if test "$GCC" = yes; then
- sys_lib_search_path_spec=`$CC -print-search-dirs | tr "\n" "$PATH_SEPARATOR" | sed -e 's/libraries:/@libraries:/' | tr "@" "\n" | grep "^libraries:" | sed -e "s/^libraries://" -e "s,=/,/,g" -e "s,$PATH_SEPARATOR, ,g" -e "s,.*,& /lib /usr/lib /usr/local/lib,g"`
- else
- sys_lib_search_path_spec='/lib /usr/lib /usr/local/lib'
- fi
- sys_lib_dlsearch_path_spec='/usr/local/lib /lib /usr/lib'
- ;;
-
-dgux*)
- version_type=linux
- need_lib_prefix=no
- need_version=no
- library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname$shared_ext'
- soname_spec='${libname}${release}${shared_ext}$major'
- shlibpath_var=LD_LIBRARY_PATH
- ;;
-
-freebsd1*)
- dynamic_linker=no
- ;;
-
-kfreebsd*-gnu)
- version_type=linux
- need_lib_prefix=no
- need_version=no
- library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major ${libname}${shared_ext}'
- soname_spec='${libname}${release}${shared_ext}$major'
- shlibpath_var=LD_LIBRARY_PATH
- shlibpath_overrides_runpath=no
- hardcode_into_libs=yes
- dynamic_linker='GNU ld.so'
- ;;
-
-freebsd* | dragonfly*)
- # DragonFly does not have aout. When/if they implement a new
- # versioning mechanism, adjust this.
- objformat=`test -x /usr/bin/objformat && /usr/bin/objformat || echo aout`
- version_type=freebsd-$objformat
- case $version_type in
- freebsd-elf*)
- library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext} $libname${shared_ext}'
- need_version=no
- need_lib_prefix=no
- ;;
- freebsd-*)
- library_names_spec='${libname}${release}${shared_ext}$versuffix $libname${shared_ext}$versuffix'
- need_version=yes
- ;;
- esac
- shlibpath_var=LD_LIBRARY_PATH
- case $host_os in
- freebsd2*)
- shlibpath_overrides_runpath=yes
- ;;
- freebsd3.[01]* | freebsdelf3.[01]*)
- shlibpath_overrides_runpath=yes
- hardcode_into_libs=yes
- ;;
- *) # from 3.2 on
- shlibpath_overrides_runpath=no
- hardcode_into_libs=yes
- ;;
- esac
- ;;
-
-gnu*)
- version_type=linux
- need_lib_prefix=no
- need_version=no
- library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}${major} ${libname}${shared_ext}'
- soname_spec='${libname}${release}${shared_ext}$major'
- shlibpath_var=LD_LIBRARY_PATH
- hardcode_into_libs=yes
- ;;
-
-hpux9* | hpux10* | hpux11*)
- # Give a soname corresponding to the major version so that dld.sl refuses to
- # link against other versions.
- version_type=sunos
- need_lib_prefix=no
- need_version=no
- case "$host_cpu" in
- ia64*)
- shrext_cmds='.so'
- hardcode_into_libs=yes
- dynamic_linker="$host_os dld.so"
- shlibpath_var=LD_LIBRARY_PATH
- shlibpath_overrides_runpath=yes # Unless +noenvvar is specified.
- library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
- soname_spec='${libname}${release}${shared_ext}$major'
- if test "X$HPUX_IA64_MODE" = X32; then
- sys_lib_search_path_spec="/usr/lib/hpux32 /usr/local/lib/hpux32 /usr/local/lib"
- else
- sys_lib_search_path_spec="/usr/lib/hpux64 /usr/local/lib/hpux64"
- fi
- sys_lib_dlsearch_path_spec=$sys_lib_search_path_spec
- ;;
- hppa*64*)
- shrext_cmds='.sl'
- hardcode_into_libs=yes
- dynamic_linker="$host_os dld.sl"
- shlibpath_var=LD_LIBRARY_PATH # How should we handle SHLIB_PATH
- shlibpath_overrides_runpath=yes # Unless +noenvvar is specified.
- library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
- soname_spec='${libname}${release}${shared_ext}$major'
- sys_lib_search_path_spec="/usr/lib/pa20_64 /usr/ccs/lib/pa20_64"
- sys_lib_dlsearch_path_spec=$sys_lib_search_path_spec
- ;;
- *)
- shrext_cmds='.sl'
- dynamic_linker="$host_os dld.sl"
- shlibpath_var=SHLIB_PATH
- shlibpath_overrides_runpath=no # +s is required to enable SHLIB_PATH
- library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
- soname_spec='${libname}${release}${shared_ext}$major'
- ;;
- esac
- # HP-UX runs *really* slowly unless shared libraries are mode 555.
- postinstall_cmds='chmod 555 $lib'
- ;;
-
-irix5* | irix6* | nonstopux*)
- case $host_os in
- nonstopux*) version_type=nonstopux ;;
- *)
- if test "$lt_cv_prog_gnu_ld" = yes; then
- version_type=linux
- else
- version_type=irix
- fi ;;
- esac
- need_lib_prefix=no
- need_version=no
- soname_spec='${libname}${release}${shared_ext}$major'
- library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major ${libname}${release}${shared_ext} $libname${shared_ext}'
- case $host_os in
- irix5* | nonstopux*)
- libsuff= shlibsuff=
- ;;
- *)
- case $LD in # libtool.m4 will add one of these switches to LD
- *-32|*"-32 "|*-melf32bsmip|*"-melf32bsmip ")
- libsuff= shlibsuff= libmagic=32-bit;;
- *-n32|*"-n32 "|*-melf32bmipn32|*"-melf32bmipn32 ")
- libsuff=32 shlibsuff=N32 libmagic=N32;;
- *-64|*"-64 "|*-melf64bmip|*"-melf64bmip ")
- libsuff=64 shlibsuff=64 libmagic=64-bit;;
- *) libsuff= shlibsuff= libmagic=never-match;;
- esac
- ;;
- esac
- shlibpath_var=LD_LIBRARY${shlibsuff}_PATH
- shlibpath_overrides_runpath=no
- sys_lib_search_path_spec="/usr/lib${libsuff} /lib${libsuff} /usr/local/lib${libsuff}"
- sys_lib_dlsearch_path_spec="/usr/lib${libsuff} /lib${libsuff}"
- hardcode_into_libs=yes
- ;;
-
-# No shared lib support for Linux oldld, aout, or coff.
-linux*oldld* | linux*aout* | linux*coff*)
- dynamic_linker=no
- ;;
-
-# This must be Linux ELF.
-linux*)
- version_type=linux
- need_lib_prefix=no
- need_version=no
- library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
- soname_spec='${libname}${release}${shared_ext}$major'
- finish_cmds='PATH="\$PATH:/sbin" ldconfig -n $libdir'
- shlibpath_var=LD_LIBRARY_PATH
- shlibpath_overrides_runpath=no
- # This implies no fast_install, which is unacceptable.
- # Some rework will be needed to allow for fast_install
- # before this can be enabled.
- hardcode_into_libs=yes
-
- # Append ld.so.conf contents to the search path
- if test -f /etc/ld.so.conf; then
- lt_ld_extra=`awk '/^include / { system(sprintf("cd /etc; cat %s", \$2)); skip = 1; } { if (!skip) print \$0; skip = 0; }' < /etc/ld.so.conf | $SED -e 's/#.*//;s/[:, ]/ /g;s/=[^=]*$//;s/=[^= ]* / /g;/^$/d' | tr '\n' ' '`
- sys_lib_dlsearch_path_spec="/lib /usr/lib $lt_ld_extra"
- fi
-
- # We used to test for /lib/ld.so.1 and disable shared libraries on
- # powerpc, because MkLinux only supported shared libraries with the
- # GNU dynamic linker. Since this was broken with cross compilers,
- # most powerpc-linux boxes support dynamic linking these days and
- # people can always --disable-shared, the test was removed, and we
- # assume the GNU/Linux dynamic linker is in use.
- dynamic_linker='GNU/Linux ld.so'
- ;;
-
-knetbsd*-gnu)
- version_type=linux
- need_lib_prefix=no
- need_version=no
- library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major ${libname}${shared_ext}'
- soname_spec='${libname}${release}${shared_ext}$major'
- shlibpath_var=LD_LIBRARY_PATH
- shlibpath_overrides_runpath=no
- hardcode_into_libs=yes
- dynamic_linker='GNU ld.so'
- ;;
-
-netbsd*)
- version_type=sunos
- need_lib_prefix=no
- need_version=no
- if echo __ELF__ | $CC -E - | grep __ELF__ >/dev/null; then
- library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${shared_ext}$versuffix'
- finish_cmds='PATH="\$PATH:/sbin" ldconfig -m $libdir'
- dynamic_linker='NetBSD (a.out) ld.so'
- else
- library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major ${libname}${shared_ext}'
- soname_spec='${libname}${release}${shared_ext}$major'
- dynamic_linker='NetBSD ld.elf_so'
- fi
- shlibpath_var=LD_LIBRARY_PATH
- shlibpath_overrides_runpath=yes
- hardcode_into_libs=yes
- ;;
-
-newsos6)
- version_type=linux
- library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
- shlibpath_var=LD_LIBRARY_PATH
- shlibpath_overrides_runpath=yes
- ;;
-
-nto-qnx*)
- version_type=linux
- need_lib_prefix=no
- need_version=no
- library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
- soname_spec='${libname}${release}${shared_ext}$major'
- shlibpath_var=LD_LIBRARY_PATH
- shlibpath_overrides_runpath=yes
- ;;
-
-openbsd*)
- version_type=sunos
- need_lib_prefix=no
- # Some older versions of OpenBSD (3.3 at least) *do* need versioned libs.
- case $host_os in
- openbsd3.3 | openbsd3.3.*) need_version=yes ;;
- *) need_version=no ;;
- esac
- library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${shared_ext}$versuffix'
- finish_cmds='PATH="\$PATH:/sbin" ldconfig -m $libdir'
- shlibpath_var=LD_LIBRARY_PATH
- if test -z "`echo __ELF__ | $CC -E - | grep __ELF__`" || test "$host_os-$host_cpu" = "openbsd2.8-powerpc"; then
- case $host_os in
- openbsd2.[89] | openbsd2.[89].*)
- shlibpath_overrides_runpath=no
- ;;
- *)
- shlibpath_overrides_runpath=yes
- ;;
- esac
- else
- shlibpath_overrides_runpath=yes
- fi
- ;;
-
-os2*)
- libname_spec='$name'
- shrext_cmds=".dll"
- need_lib_prefix=no
- library_names_spec='$libname${shared_ext} $libname.a'
- dynamic_linker='OS/2 ld.exe'
- shlibpath_var=LIBPATH
- ;;
-
-osf3* | osf4* | osf5*)
- version_type=osf
- need_lib_prefix=no
- need_version=no
- soname_spec='${libname}${release}${shared_ext}$major'
- library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
- shlibpath_var=LD_LIBRARY_PATH
- sys_lib_search_path_spec="/usr/shlib /usr/ccs/lib /usr/lib/cmplrs/cc /usr/lib /usr/local/lib /var/shlib"
- sys_lib_dlsearch_path_spec="$sys_lib_search_path_spec"
- ;;
-
-sco3.2v5*)
- version_type=osf
- soname_spec='${libname}${release}${shared_ext}$major'
- library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
- shlibpath_var=LD_LIBRARY_PATH
- ;;
-
-solaris*)
- version_type=linux
- need_lib_prefix=no
- need_version=no
- library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
- soname_spec='${libname}${release}${shared_ext}$major'
- shlibpath_var=LD_LIBRARY_PATH
- shlibpath_overrides_runpath=yes
- hardcode_into_libs=yes
- # ldd complains unless libraries are executable
- postinstall_cmds='chmod +x $lib'
- ;;
-
-sunos4*)
- version_type=sunos
- library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${shared_ext}$versuffix'
- finish_cmds='PATH="\$PATH:/usr/etc" ldconfig $libdir'
- shlibpath_var=LD_LIBRARY_PATH
- shlibpath_overrides_runpath=yes
- if test "$with_gnu_ld" = yes; then
- need_lib_prefix=no
- fi
- need_version=yes
- ;;
-
-sysv4 | sysv4.2uw2* | sysv4.3* | sysv5*)
- version_type=linux
- library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
- soname_spec='${libname}${release}${shared_ext}$major'
- shlibpath_var=LD_LIBRARY_PATH
- case $host_vendor in
- sni)
- shlibpath_overrides_runpath=no
- need_lib_prefix=no
- export_dynamic_flag_spec='${wl}-Blargedynsym'
- runpath_var=LD_RUN_PATH
- ;;
- siemens)
- need_lib_prefix=no
- ;;
- motorola)
- need_lib_prefix=no
- need_version=no
- shlibpath_overrides_runpath=no
- sys_lib_search_path_spec='/lib /usr/lib /usr/ccs/lib'
- ;;
- esac
- ;;
-
-sysv4*MP*)
- if test -d /usr/nec ;then
- version_type=linux
- library_names_spec='$libname${shared_ext}.$versuffix $libname${shared_ext}.$major $libname${shared_ext}'
- soname_spec='$libname${shared_ext}.$major'
- shlibpath_var=LD_LIBRARY_PATH
- fi
- ;;
-
-uts4*)
- version_type=linux
- library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
- soname_spec='${libname}${release}${shared_ext}$major'
- shlibpath_var=LD_LIBRARY_PATH
- ;;
-
-*)
- dynamic_linker=no
- ;;
-esac
-echo "$as_me:$LINENO: result: $dynamic_linker" >&5
-echo "${ECHO_T}$dynamic_linker" >&6
-test "$dynamic_linker" = no && can_build_shared=no
-
-echo "$as_me:$LINENO: checking how to hardcode library paths into programs" >&5
-echo $ECHO_N "checking how to hardcode library paths into programs... $ECHO_C" >&6
-hardcode_action_GCJ=
-if test -n "$hardcode_libdir_flag_spec_GCJ" || \
- test -n "$runpath_var_GCJ" || \
- test "X$hardcode_automatic_GCJ" = "Xyes" ; then
-
- # We can hardcode non-existant directories.
- if test "$hardcode_direct_GCJ" != no &&
- # If the only mechanism to avoid hardcoding is shlibpath_var, we
- # have to relink, otherwise we might link with an installed library
- # when we should be linking with a yet-to-be-installed one
- ## test "$_LT_AC_TAGVAR(hardcode_shlibpath_var, GCJ)" != no &&
- test "$hardcode_minus_L_GCJ" != no; then
- # Linking always hardcodes the temporary library directory.
- hardcode_action_GCJ=relink
- else
- # We can link without hardcoding, and we can hardcode nonexisting dirs.
- hardcode_action_GCJ=immediate
- fi
-else
- # We cannot hardcode anything, or else we can only hardcode existing
- # directories.
- hardcode_action_GCJ=unsupported
-fi
-echo "$as_me:$LINENO: result: $hardcode_action_GCJ" >&5
-echo "${ECHO_T}$hardcode_action_GCJ" >&6
-
-if test "$hardcode_action_GCJ" = relink; then
- # Fast installation is not supported
- enable_fast_install=no
-elif test "$shlibpath_overrides_runpath" = yes ||
- test "$enable_shared" = no; then
- # Fast installation is not necessary
- enable_fast_install=needless
-fi
-
-striplib=
-old_striplib=
-echo "$as_me:$LINENO: checking whether stripping libraries is possible" >&5
-echo $ECHO_N "checking whether stripping libraries is possible... $ECHO_C" >&6
-if test -n "$STRIP" && $STRIP -V 2>&1 | grep "GNU strip" >/dev/null; then
- test -z "$old_striplib" && old_striplib="$STRIP --strip-debug"
- test -z "$striplib" && striplib="$STRIP --strip-unneeded"
- echo "$as_me:$LINENO: result: yes" >&5
-echo "${ECHO_T}yes" >&6
-else
-# FIXME - insert some real tests, host_os isn't really good enough
- case $host_os in
- darwin*)
- if test -n "$STRIP" ; then
- striplib="$STRIP -x"
- echo "$as_me:$LINENO: result: yes" >&5
-echo "${ECHO_T}yes" >&6
- else
- echo "$as_me:$LINENO: result: no" >&5
-echo "${ECHO_T}no" >&6
-fi
- ;;
- *)
- echo "$as_me:$LINENO: result: no" >&5
-echo "${ECHO_T}no" >&6
- ;;
- esac
-fi
-
-if test "x$enable_dlopen" != xyes; then
- enable_dlopen=unknown
- enable_dlopen_self=unknown
- enable_dlopen_self_static=unknown
-else
- lt_cv_dlopen=no
- lt_cv_dlopen_libs=
-
- case $host_os in
- beos*)
- lt_cv_dlopen="load_add_on"
- lt_cv_dlopen_libs=
- lt_cv_dlopen_self=yes
- ;;
-
- mingw* | pw32*)
- lt_cv_dlopen="LoadLibrary"
- lt_cv_dlopen_libs=
- ;;
-
- cygwin*)
- lt_cv_dlopen="dlopen"
- lt_cv_dlopen_libs=
- ;;
-
- darwin*)
- # if libdl is installed we need to link against it
- echo "$as_me:$LINENO: checking for dlopen in -ldl" >&5
-echo $ECHO_N "checking for dlopen in -ldl... $ECHO_C" >&6
-if test "${ac_cv_lib_dl_dlopen+set}" = set; then
- echo $ECHO_N "(cached) $ECHO_C" >&6
-else
- ac_check_lib_save_LIBS=$LIBS
-LIBS="-ldl $LIBS"
-cat >conftest.$ac_ext <<_ACEOF
-/* confdefs.h. */
-_ACEOF
-cat confdefs.h >>conftest.$ac_ext
-cat >>conftest.$ac_ext <<_ACEOF
-/* end confdefs.h. */
-
-/* Override any gcc2 internal prototype to avoid an error. */
-#ifdef __cplusplus
-extern "C"
-#endif
-/* We use char because int might match the return type of a gcc2
- builtin and then its argument prototype would still apply. */
-char dlopen ();
-int
-main ()
-{
-dlopen ();
- ;
- return 0;
-}
-_ACEOF
-rm -f conftest.$ac_objext conftest$ac_exeext
-if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
- (eval $ac_link) 2>conftest.er1
- ac_status=$?
- grep -v '^ *+' conftest.er1 >conftest.err
- rm -f conftest.er1
- cat conftest.err >&5
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag"
- || test ! -s conftest.err'
- { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); }; } &&
- { ac_try='test -s conftest$ac_exeext'
- { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); }; }; then
- ac_cv_lib_dl_dlopen=yes
-else
- echo "$as_me: failed program was:" >&5
-sed 's/^/| /' conftest.$ac_ext >&5
-
-ac_cv_lib_dl_dlopen=no
-fi
-rm -f conftest.err conftest.$ac_objext \
- conftest$ac_exeext conftest.$ac_ext
-LIBS=$ac_check_lib_save_LIBS
-fi
-echo "$as_me:$LINENO: result: $ac_cv_lib_dl_dlopen" >&5
-echo "${ECHO_T}$ac_cv_lib_dl_dlopen" >&6
-if test $ac_cv_lib_dl_dlopen = yes; then
- lt_cv_dlopen="dlopen" lt_cv_dlopen_libs="-ldl"
-else
-
- lt_cv_dlopen="dyld"
- lt_cv_dlopen_libs=
- lt_cv_dlopen_self=yes
-
-fi
-
- ;;
-
- *)
- echo "$as_me:$LINENO: checking for shl_load" >&5
-echo $ECHO_N "checking for shl_load... $ECHO_C" >&6
-if test "${ac_cv_func_shl_load+set}" = set; then
- echo $ECHO_N "(cached) $ECHO_C" >&6
-else
- cat >conftest.$ac_ext <<_ACEOF
-/* confdefs.h. */
-_ACEOF
-cat confdefs.h >>conftest.$ac_ext
-cat >>conftest.$ac_ext <<_ACEOF
-/* end confdefs.h. */
-/* Define shl_load to an innocuous variant, in case <limits.h> declares shl_load.
- For example, HP-UX 11i <limits.h> declares gettimeofday. */
-#define shl_load innocuous_shl_load
-
-/* System header to define __stub macros and hopefully few prototypes,
- which can conflict with char shl_load (); below.
- Prefer <limits.h> to <assert.h> if __STDC__ is defined, since
- <limits.h> exists even on freestanding compilers. */
-
-#ifdef __STDC__
-# include <limits.h>
-#else
-# include <assert.h>
-#endif
-
-#undef shl_load
-
-/* Override any gcc2 internal prototype to avoid an error. */
-#ifdef __cplusplus
-extern "C"
-{
-#endif
-/* We use char because int might match the return type of a gcc2
- builtin and then its argument prototype would still apply. */
-char shl_load ();
-/* The GNU C library defines this for functions which it implements
- to always fail with ENOSYS. Some functions are actually named
- something starting with __ and the normal name is an alias. */
-#if defined (__stub_shl_load) || defined (__stub___shl_load)
-choke me
-#else
-char (*f) () = shl_load;
-#endif
-#ifdef __cplusplus
-}
-#endif
-
-int
-main ()
-{
-return f != shl_load;
- ;
- return 0;
-}
-_ACEOF
-rm -f conftest.$ac_objext conftest$ac_exeext
-if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
- (eval $ac_link) 2>conftest.er1
- ac_status=$?
- grep -v '^ *+' conftest.er1 >conftest.err
- rm -f conftest.er1
- cat conftest.err >&5
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag"
- || test ! -s conftest.err'
- { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); }; } &&
- { ac_try='test -s conftest$ac_exeext'
- { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); }; }; then
- ac_cv_func_shl_load=yes
-else
- echo "$as_me: failed program was:" >&5
-sed 's/^/| /' conftest.$ac_ext >&5
-
-ac_cv_func_shl_load=no
-fi
-rm -f conftest.err conftest.$ac_objext \
- conftest$ac_exeext conftest.$ac_ext
-fi
-echo "$as_me:$LINENO: result: $ac_cv_func_shl_load" >&5
-echo "${ECHO_T}$ac_cv_func_shl_load" >&6
-if test $ac_cv_func_shl_load = yes; then
- lt_cv_dlopen="shl_load"
-else
- echo "$as_me:$LINENO: checking for shl_load in -ldld" >&5
-echo $ECHO_N "checking for shl_load in -ldld... $ECHO_C" >&6
-if test "${ac_cv_lib_dld_shl_load+set}" = set; then
- echo $ECHO_N "(cached) $ECHO_C" >&6
-else
- ac_check_lib_save_LIBS=$LIBS
-LIBS="-ldld $LIBS"
-cat >conftest.$ac_ext <<_ACEOF
-/* confdefs.h. */
-_ACEOF
-cat confdefs.h >>conftest.$ac_ext
-cat >>conftest.$ac_ext <<_ACEOF
-/* end confdefs.h. */
-
-/* Override any gcc2 internal prototype to avoid an error. */
-#ifdef __cplusplus
-extern "C"
-#endif
-/* We use char because int might match the return type of a gcc2
- builtin and then its argument prototype would still apply. */
-char shl_load ();
-int
-main ()
-{
-shl_load ();
- ;
- return 0;
-}
-_ACEOF
-rm -f conftest.$ac_objext conftest$ac_exeext
-if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
- (eval $ac_link) 2>conftest.er1
- ac_status=$?
- grep -v '^ *+' conftest.er1 >conftest.err
- rm -f conftest.er1
- cat conftest.err >&5
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag"
- || test ! -s conftest.err'
- { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); }; } &&
- { ac_try='test -s conftest$ac_exeext'
- { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); }; }; then
- ac_cv_lib_dld_shl_load=yes
-else
- echo "$as_me: failed program was:" >&5
-sed 's/^/| /' conftest.$ac_ext >&5
-
-ac_cv_lib_dld_shl_load=no
-fi
-rm -f conftest.err conftest.$ac_objext \
- conftest$ac_exeext conftest.$ac_ext
-LIBS=$ac_check_lib_save_LIBS
-fi
-echo "$as_me:$LINENO: result: $ac_cv_lib_dld_shl_load" >&5
-echo "${ECHO_T}$ac_cv_lib_dld_shl_load" >&6
-if test $ac_cv_lib_dld_shl_load = yes; then
- lt_cv_dlopen="shl_load" lt_cv_dlopen_libs="-dld"
-else
- echo "$as_me:$LINENO: checking for dlopen" >&5
-echo $ECHO_N "checking for dlopen... $ECHO_C" >&6
-if test "${ac_cv_func_dlopen+set}" = set; then
- echo $ECHO_N "(cached) $ECHO_C" >&6
-else
- cat >conftest.$ac_ext <<_ACEOF
-/* confdefs.h. */
-_ACEOF
-cat confdefs.h >>conftest.$ac_ext
-cat >>conftest.$ac_ext <<_ACEOF
-/* end confdefs.h. */
-/* Define dlopen to an innocuous variant, in case <limits.h> declares dlopen.
- For example, HP-UX 11i <limits.h> declares gettimeofday. */
-#define dlopen innocuous_dlopen
-
-/* System header to define __stub macros and hopefully few prototypes,
- which can conflict with char dlopen (); below.
- Prefer <limits.h> to <assert.h> if __STDC__ is defined, since
- <limits.h> exists even on freestanding compilers. */
-
-#ifdef __STDC__
-# include <limits.h>
-#else
-# include <assert.h>
-#endif
-
-#undef dlopen
-
-/* Override any gcc2 internal prototype to avoid an error. */
-#ifdef __cplusplus
-extern "C"
-{
-#endif
-/* We use char because int might match the return type of a gcc2
- builtin and then its argument prototype would still apply. */
-char dlopen ();
-/* The GNU C library defines this for functions which it implements
- to always fail with ENOSYS. Some functions are actually named
- something starting with __ and the normal name is an alias. */
-#if defined (__stub_dlopen) || defined (__stub___dlopen)
-choke me
-#else
-char (*f) () = dlopen;
-#endif
-#ifdef __cplusplus
-}
-#endif
-
-int
-main ()
-{
-return f != dlopen;
- ;
- return 0;
-}
-_ACEOF
-rm -f conftest.$ac_objext conftest$ac_exeext
-if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
- (eval $ac_link) 2>conftest.er1
- ac_status=$?
- grep -v '^ *+' conftest.er1 >conftest.err
- rm -f conftest.er1
- cat conftest.err >&5
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag"
- || test ! -s conftest.err'
- { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); }; } &&
- { ac_try='test -s conftest$ac_exeext'
- { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); }; }; then
- ac_cv_func_dlopen=yes
-else
- echo "$as_me: failed program was:" >&5
-sed 's/^/| /' conftest.$ac_ext >&5
-
-ac_cv_func_dlopen=no
-fi
-rm -f conftest.err conftest.$ac_objext \
- conftest$ac_exeext conftest.$ac_ext
-fi
-echo "$as_me:$LINENO: result: $ac_cv_func_dlopen" >&5
-echo "${ECHO_T}$ac_cv_func_dlopen" >&6
-if test $ac_cv_func_dlopen = yes; then
- lt_cv_dlopen="dlopen"
-else
- echo "$as_me:$LINENO: checking for dlopen in -ldl" >&5
-echo $ECHO_N "checking for dlopen in -ldl... $ECHO_C" >&6
-if test "${ac_cv_lib_dl_dlopen+set}" = set; then
- echo $ECHO_N "(cached) $ECHO_C" >&6
-else
- ac_check_lib_save_LIBS=$LIBS
-LIBS="-ldl $LIBS"
-cat >conftest.$ac_ext <<_ACEOF
-/* confdefs.h. */
-_ACEOF
-cat confdefs.h >>conftest.$ac_ext
-cat >>conftest.$ac_ext <<_ACEOF
-/* end confdefs.h. */
-
-/* Override any gcc2 internal prototype to avoid an error. */
-#ifdef __cplusplus
-extern "C"
-#endif
-/* We use char because int might match the return type of a gcc2
- builtin and then its argument prototype would still apply. */
-char dlopen ();
-int
-main ()
-{
-dlopen ();
- ;
- return 0;
-}
-_ACEOF
-rm -f conftest.$ac_objext conftest$ac_exeext
-if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
- (eval $ac_link) 2>conftest.er1
- ac_status=$?
- grep -v '^ *+' conftest.er1 >conftest.err
- rm -f conftest.er1
- cat conftest.err >&5
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag"
- || test ! -s conftest.err'
- { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); }; } &&
- { ac_try='test -s conftest$ac_exeext'
- { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); }; }; then
- ac_cv_lib_dl_dlopen=yes
-else
- echo "$as_me: failed program was:" >&5
-sed 's/^/| /' conftest.$ac_ext >&5
-
-ac_cv_lib_dl_dlopen=no
-fi
-rm -f conftest.err conftest.$ac_objext \
- conftest$ac_exeext conftest.$ac_ext
-LIBS=$ac_check_lib_save_LIBS
-fi
-echo "$as_me:$LINENO: result: $ac_cv_lib_dl_dlopen" >&5
-echo "${ECHO_T}$ac_cv_lib_dl_dlopen" >&6
-if test $ac_cv_lib_dl_dlopen = yes; then
- lt_cv_dlopen="dlopen" lt_cv_dlopen_libs="-ldl"
-else
- echo "$as_me:$LINENO: checking for dlopen in -lsvld" >&5
-echo $ECHO_N "checking for dlopen in -lsvld... $ECHO_C" >&6
-if test "${ac_cv_lib_svld_dlopen+set}" = set; then
- echo $ECHO_N "(cached) $ECHO_C" >&6
-else
- ac_check_lib_save_LIBS=$LIBS
-LIBS="-lsvld $LIBS"
-cat >conftest.$ac_ext <<_ACEOF
-/* confdefs.h. */
-_ACEOF
-cat confdefs.h >>conftest.$ac_ext
-cat >>conftest.$ac_ext <<_ACEOF
-/* end confdefs.h. */
-
-/* Override any gcc2 internal prototype to avoid an error. */
-#ifdef __cplusplus
-extern "C"
-#endif
-/* We use char because int might match the return type of a gcc2
- builtin and then its argument prototype would still apply. */
-char dlopen ();
-int
-main ()
-{
-dlopen ();
- ;
- return 0;
-}
-_ACEOF
-rm -f conftest.$ac_objext conftest$ac_exeext
-if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
- (eval $ac_link) 2>conftest.er1
- ac_status=$?
- grep -v '^ *+' conftest.er1 >conftest.err
- rm -f conftest.er1
- cat conftest.err >&5
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag"
- || test ! -s conftest.err'
- { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); }; } &&
- { ac_try='test -s conftest$ac_exeext'
- { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); }; }; then
- ac_cv_lib_svld_dlopen=yes
-else
- echo "$as_me: failed program was:" >&5
-sed 's/^/| /' conftest.$ac_ext >&5
+ library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
+ else
+ # We preserve .a as extension for shared libraries through AIX4.2
+ # and later when we are not doing run time linking.
+ library_names_spec='${libname}${release}.a $libname.a'
+ soname_spec='${libname}${release}${shared_ext}$major'
+ fi
+ shlibpath_var=LIBPATH
+ fi
+ ;;
-ac_cv_lib_svld_dlopen=no
-fi
-rm -f conftest.err conftest.$ac_objext \
- conftest$ac_exeext conftest.$ac_ext
-LIBS=$ac_check_lib_save_LIBS
-fi
-echo "$as_me:$LINENO: result: $ac_cv_lib_svld_dlopen" >&5
-echo "${ECHO_T}$ac_cv_lib_svld_dlopen" >&6
-if test $ac_cv_lib_svld_dlopen = yes; then
- lt_cv_dlopen="dlopen" lt_cv_dlopen_libs="-lsvld"
-else
- echo "$as_me:$LINENO: checking for dld_link in -ldld" >&5
-echo $ECHO_N "checking for dld_link in -ldld... $ECHO_C" >&6
-if test "${ac_cv_lib_dld_dld_link+set}" = set; then
- echo $ECHO_N "(cached) $ECHO_C" >&6
-else
- ac_check_lib_save_LIBS=$LIBS
-LIBS="-ldld $LIBS"
-cat >conftest.$ac_ext <<_ACEOF
-/* confdefs.h. */
-_ACEOF
-cat confdefs.h >>conftest.$ac_ext
-cat >>conftest.$ac_ext <<_ACEOF
-/* end confdefs.h. */
+amigaos*)
+ library_names_spec='$libname.ixlibrary $libname.a'
+ # Create ${libname}_ixlibrary.a entries in /sys/libs.
+ finish_eval='for lib in `ls $libdir/*.ixlibrary 2>/dev/null`; do libname=`$echo "X$lib" | $Xsed -e '\''s%^.*/\([^/]*\)\.ixlibrary$%\1%'\''`; test $rm /sys/libs/${libname}_ixlibrary.a; $show "cd /sys/libs && $LN_S $lib ${libname}_ixlibrary.a"; cd /sys/libs && $LN_S $lib ${libname}_ixlibrary.a || exit 1; done'
+ ;;
-/* Override any gcc2 internal prototype to avoid an error. */
-#ifdef __cplusplus
-extern "C"
-#endif
-/* We use char because int might match the return type of a gcc2
- builtin and then its argument prototype would still apply. */
-char dld_link ();
-int
-main ()
-{
-dld_link ();
- ;
- return 0;
-}
-_ACEOF
-rm -f conftest.$ac_objext conftest$ac_exeext
-if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
- (eval $ac_link) 2>conftest.er1
- ac_status=$?
- grep -v '^ *+' conftest.er1 >conftest.err
- rm -f conftest.er1
- cat conftest.err >&5
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); } &&
- { ac_try='test -z "$ac_c_werror_flag"
- || test ! -s conftest.err'
- { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); }; } &&
- { ac_try='test -s conftest$ac_exeext'
- { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
- (eval $ac_try) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); }; }; then
- ac_cv_lib_dld_dld_link=yes
-else
- echo "$as_me: failed program was:" >&5
-sed 's/^/| /' conftest.$ac_ext >&5
+beos*)
+ library_names_spec='${libname}${shared_ext}'
+ dynamic_linker="$host_os ld.so"
+ shlibpath_var=LIBRARY_PATH
+ ;;
-ac_cv_lib_dld_dld_link=no
-fi
-rm -f conftest.err conftest.$ac_objext \
- conftest$ac_exeext conftest.$ac_ext
-LIBS=$ac_check_lib_save_LIBS
-fi
-echo "$as_me:$LINENO: result: $ac_cv_lib_dld_dld_link" >&5
-echo "${ECHO_T}$ac_cv_lib_dld_dld_link" >&6
-if test $ac_cv_lib_dld_dld_link = yes; then
- lt_cv_dlopen="dld_link" lt_cv_dlopen_libs="-dld"
-fi
+bsdi[45]*)
+ version_type=linux
+ need_version=no
+ library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
+ soname_spec='${libname}${release}${shared_ext}$major'
+ finish_cmds='PATH="\$PATH:/sbin" ldconfig $libdir'
+ shlibpath_var=LD_LIBRARY_PATH
+ sys_lib_search_path_spec="/shlib /usr/lib /usr/X11/lib /usr/contrib/lib /lib /usr/local/lib"
+ sys_lib_dlsearch_path_spec="/shlib /usr/lib /usr/local/lib"
+ # the default ld.so.conf also contains /usr/contrib/lib and
+ # /usr/X11R6/lib (/usr/X11 is a link to /usr/X11R6), but let us allow
+ # libtool to hard-code these into programs
+ ;;
+cygwin* | mingw* | pw32*)
+ version_type=windows
+ shrext_cmds=".dll"
+ need_version=no
+ need_lib_prefix=no
-fi
+ case $GCC,$host_os in
+ yes,cygwin* | yes,mingw* | yes,pw32*)
+ library_names_spec='$libname.dll.a'
+ # DLL is installed to $(libdir)/../bin by postinstall_cmds
+ postinstall_cmds='base_file=`basename \${file}`~
+ dlpath=`$SHELL 2>&1 -c '\''. $dir/'\''\${base_file}'\''i;echo \$dlname'\''`~
+ dldir=$destdir/`dirname \$dlpath`~
+ test -d \$dldir || mkdir -p \$dldir~
+ $install_prog $dir/$dlname \$dldir/$dlname~
+ chmod a+x \$dldir/$dlname'
+ postuninstall_cmds='dldll=`$SHELL 2>&1 -c '\''. $file; echo \$dlname'\''`~
+ dlpath=$dir/\$dldll~
+ $rm \$dlpath'
+ shlibpath_overrides_runpath=yes
+ case $host_os in
+ cygwin*)
+ # Cygwin DLLs use 'cyg' prefix rather than 'lib'
+ soname_spec='`echo ${libname} | sed -e 's/^lib/cyg/'``echo ${release} | $SED -e 's/[.]/-/g'`${versuffix}${shared_ext}'
+ sys_lib_search_path_spec="/usr/lib /lib/w32api /lib /usr/local/lib"
+ ;;
+ mingw*)
+ # MinGW DLLs use traditional 'lib' prefix
+ soname_spec='${libname}`echo ${release} | $SED -e 's/[.]/-/g'`${versuffix}${shared_ext}'
+ sys_lib_search_path_spec=`$CC -print-search-dirs | grep "^libraries:" | $SED -e "s/^libraries://" -e "s,=/,/,g"`
+ if echo "$sys_lib_search_path_spec" | grep ';[c-zC-Z]:/' >/dev/null; then
+ # It is most probably a Windows format PATH printed by
+ # mingw gcc, but we are running on Cygwin. Gcc prints its search
+ # path with ; separators, and with drive letters. We can handle the
+ # drive letters (cygwin fileutils understands them), so leave them,
+ # especially as we might pass files found there to a mingw objdump,
+ # which wouldn't understand a cygwinified path. Ahh.
+ sys_lib_search_path_spec=`echo "$sys_lib_search_path_spec" | $SED -e 's/;/ /g'`
+ else
+ sys_lib_search_path_spec=`echo "$sys_lib_search_path_spec" | $SED -e "s/$PATH_SEPARATOR/ /g"`
+ fi
+ ;;
+ pw32*)
+ # pw32 DLLs use 'pw' prefix rather than 'lib'
+ library_names_spec='`echo ${libname} | sed -e 's/^lib/pw/'``echo ${release} | $SED -e 's/[.]/-/g'`${versuffix}${shared_ext}'
+ ;;
+ esac
+ ;;
-fi
+ *)
+ library_names_spec='${libname}`echo ${release} | $SED -e 's/[.]/-/g'`${versuffix}${shared_ext} $libname.lib'
+ ;;
+ esac
+ dynamic_linker='Win32 ld.exe'
+ # FIXME: first we should search . and the directory the executable is in
+ shlibpath_var=PATH
+ ;;
+darwin* | rhapsody*)
+ dynamic_linker="$host_os dyld"
+ version_type=darwin
+ need_lib_prefix=no
+ need_version=no
+ library_names_spec='${libname}${release}${versuffix}$shared_ext ${libname}${release}${major}$shared_ext ${libname}$shared_ext'
+ soname_spec='${libname}${release}${major}$shared_ext'
+ shlibpath_overrides_runpath=yes
+ shlibpath_var=DYLD_LIBRARY_PATH
+ shrext_cmds='`test .$module = .yes && echo .so || echo .dylib`'
+ # Apple's gcc prints 'gcc -print-search-dirs' doesn't operate the same.
+ if test "$GCC" = yes; then
+ sys_lib_search_path_spec=`$CC -print-search-dirs | tr "\n" "$PATH_SEPARATOR" | sed -e 's/libraries:/@libraries:/' | tr "@" "\n" | grep "^libraries:" | sed -e "s/^libraries://" -e "s,=/,/,g" -e "s,$PATH_SEPARATOR, ,g" -e "s,.*,& /lib /usr/lib /usr/local/lib,g"`
+ else
+ sys_lib_search_path_spec='/lib /usr/lib /usr/local/lib'
+ fi
+ sys_lib_dlsearch_path_spec='/usr/local/lib /lib /usr/lib'
+ ;;
-fi
+dgux*)
+ version_type=linux
+ need_lib_prefix=no
+ need_version=no
+ library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname$shared_ext'
+ soname_spec='${libname}${release}${shared_ext}$major'
+ shlibpath_var=LD_LIBRARY_PATH
+ ;;
+freebsd1*)
+ dynamic_linker=no
+ ;;
-fi
+kfreebsd*-gnu)
+ version_type=linux
+ need_lib_prefix=no
+ need_version=no
+ library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major ${libname}${shared_ext}'
+ soname_spec='${libname}${release}${shared_ext}$major'
+ shlibpath_var=LD_LIBRARY_PATH
+ shlibpath_overrides_runpath=no
+ hardcode_into_libs=yes
+ dynamic_linker='GNU ld.so'
+ ;;
+freebsd* | dragonfly*)
+ # DragonFly does not have aout. When/if they implement a new
+ # versioning mechanism, adjust this.
+ if test -x /usr/bin/objformat; then
+ objformat=`/usr/bin/objformat`
+ else
+ case $host_os in
+ freebsd[123]*) objformat=aout ;;
+ *) objformat=elf ;;
+ esac
+ fi
+ version_type=freebsd-$objformat
+ case $version_type in
+ freebsd-elf*)
+ library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext} $libname${shared_ext}'
+ need_version=no
+ need_lib_prefix=no
+ ;;
+ freebsd-*)
+ library_names_spec='${libname}${release}${shared_ext}$versuffix $libname${shared_ext}$versuffix'
+ need_version=yes
+ ;;
+ esac
+ shlibpath_var=LD_LIBRARY_PATH
+ case $host_os in
+ freebsd2*)
+ shlibpath_overrides_runpath=yes
+ ;;
+ freebsd3.[01]* | freebsdelf3.[01]*)
+ shlibpath_overrides_runpath=yes
+ hardcode_into_libs=yes
+ ;;
+ freebsd3.[2-9]* | freebsdelf3.[2-9]* | \
+ freebsd4.[0-5] | freebsdelf4.[0-5] | freebsd4.1.1 | freebsdelf4.1.1)
+ shlibpath_overrides_runpath=no
+ hardcode_into_libs=yes
+ ;;
+ freebsd*) # from 4.6 on
+ shlibpath_overrides_runpath=yes
+ hardcode_into_libs=yes
+ ;;
+ esac
+ ;;
-fi
+gnu*)
+ version_type=linux
+ need_lib_prefix=no
+ need_version=no
+ library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}${major} ${libname}${shared_ext}'
+ soname_spec='${libname}${release}${shared_ext}$major'
+ shlibpath_var=LD_LIBRARY_PATH
+ hardcode_into_libs=yes
+ ;;
+hpux9* | hpux10* | hpux11*)
+ # Give a soname corresponding to the major version so that dld.sl refuses to
+ # link against other versions.
+ version_type=sunos
+ need_lib_prefix=no
+ need_version=no
+ case $host_cpu in
+ ia64*)
+ shrext_cmds='.so'
+ hardcode_into_libs=yes
+ dynamic_linker="$host_os dld.so"
+ shlibpath_var=LD_LIBRARY_PATH
+ shlibpath_overrides_runpath=yes # Unless +noenvvar is specified.
+ library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
+ soname_spec='${libname}${release}${shared_ext}$major'
+ if test "X$HPUX_IA64_MODE" = X32; then
+ sys_lib_search_path_spec="/usr/lib/hpux32 /usr/local/lib/hpux32 /usr/local/lib"
+ else
+ sys_lib_search_path_spec="/usr/lib/hpux64 /usr/local/lib/hpux64"
+ fi
+ sys_lib_dlsearch_path_spec=$sys_lib_search_path_spec
+ ;;
+ hppa*64*)
+ shrext_cmds='.sl'
+ hardcode_into_libs=yes
+ dynamic_linker="$host_os dld.sl"
+ shlibpath_var=LD_LIBRARY_PATH # How should we handle SHLIB_PATH
+ shlibpath_overrides_runpath=yes # Unless +noenvvar is specified.
+ library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
+ soname_spec='${libname}${release}${shared_ext}$major'
+ sys_lib_search_path_spec="/usr/lib/pa20_64 /usr/ccs/lib/pa20_64"
+ sys_lib_dlsearch_path_spec=$sys_lib_search_path_spec
+ ;;
+ *)
+ shrext_cmds='.sl'
+ dynamic_linker="$host_os dld.sl"
+ shlibpath_var=SHLIB_PATH
+ shlibpath_overrides_runpath=no # +s is required to enable SHLIB_PATH
+ library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
+ soname_spec='${libname}${release}${shared_ext}$major'
;;
esac
+ # HP-UX runs *really* slowly unless shared libraries are mode 555.
+ postinstall_cmds='chmod 555 $lib'
+ ;;
- if test "x$lt_cv_dlopen" != xno; then
- enable_dlopen=yes
- else
- enable_dlopen=no
- fi
-
- case $lt_cv_dlopen in
- dlopen)
- save_CPPFLAGS="$CPPFLAGS"
- test "x$ac_cv_header_dlfcn_h" = xyes && CPPFLAGS="$CPPFLAGS -DHAVE_DLFCN_H"
-
- save_LDFLAGS="$LDFLAGS"
- eval LDFLAGS=\"\$LDFLAGS $export_dynamic_flag_spec\"
-
- save_LIBS="$LIBS"
- LIBS="$lt_cv_dlopen_libs $LIBS"
-
- echo "$as_me:$LINENO: checking whether a program can dlopen itself" >&5
-echo $ECHO_N "checking whether a program can dlopen itself... $ECHO_C" >&6
-if test "${lt_cv_dlopen_self+set}" = set; then
- echo $ECHO_N "(cached) $ECHO_C" >&6
-else
- if test "$cross_compiling" = yes; then :
- lt_cv_dlopen_self=cross
-else
- lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
- lt_status=$lt_dlunknown
- cat > conftest.$ac_ext <<EOF
-#line 18479 "configure"
-#include "confdefs.h"
-
-#if HAVE_DLFCN_H
-#include <dlfcn.h>
-#endif
+interix3*)
+ version_type=linux
+ need_lib_prefix=no
+ need_version=no
+ library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major ${libname}${shared_ext}'
+ soname_spec='${libname}${release}${shared_ext}$major'
+ dynamic_linker='Interix 3.x ld.so.1 (PE, like ELF)'
+ shlibpath_var=LD_LIBRARY_PATH
+ shlibpath_overrides_runpath=no
+ hardcode_into_libs=yes
+ ;;
-#include <stdio.h>
+irix5* | irix6* | nonstopux*)
+ case $host_os in
+ nonstopux*) version_type=nonstopux ;;
+ *)
+ if test "$lt_cv_prog_gnu_ld" = yes; then
+ version_type=linux
+ else
+ version_type=irix
+ fi ;;
+ esac
+ need_lib_prefix=no
+ need_version=no
+ soname_spec='${libname}${release}${shared_ext}$major'
+ library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major ${libname}${release}${shared_ext} $libname${shared_ext}'
+ case $host_os in
+ irix5* | nonstopux*)
+ libsuff= shlibsuff=
+ ;;
+ *)
+ case $LD in # libtool.m4 will add one of these switches to LD
+ *-32|*"-32 "|*-melf32bsmip|*"-melf32bsmip ")
+ libsuff= shlibsuff= libmagic=32-bit;;
+ *-n32|*"-n32 "|*-melf32bmipn32|*"-melf32bmipn32 ")
+ libsuff=32 shlibsuff=N32 libmagic=N32;;
+ *-64|*"-64 "|*-melf64bmip|*"-melf64bmip ")
+ libsuff=64 shlibsuff=64 libmagic=64-bit;;
+ *) libsuff= shlibsuff= libmagic=never-match;;
+ esac
+ ;;
+ esac
+ shlibpath_var=LD_LIBRARY${shlibsuff}_PATH
+ shlibpath_overrides_runpath=no
+ sys_lib_search_path_spec="/usr/lib${libsuff} /lib${libsuff} /usr/local/lib${libsuff}"
+ sys_lib_dlsearch_path_spec="/usr/lib${libsuff} /lib${libsuff}"
+ hardcode_into_libs=yes
+ ;;
-#ifdef RTLD_GLOBAL
-# define LT_DLGLOBAL RTLD_GLOBAL
-#else
-# ifdef DL_GLOBAL
-# define LT_DLGLOBAL DL_GLOBAL
-# else
-# define LT_DLGLOBAL 0
-# endif
-#endif
+# No shared lib support for Linux oldld, aout, or coff.
+linux*oldld* | linux*aout* | linux*coff*)
+ dynamic_linker=no
+ ;;
-/* We may have to define LT_DLLAZY_OR_NOW in the command line if we
- find out it does not work in some platform. */
-#ifndef LT_DLLAZY_OR_NOW
-# ifdef RTLD_LAZY
-# define LT_DLLAZY_OR_NOW RTLD_LAZY
-# else
-# ifdef DL_LAZY
-# define LT_DLLAZY_OR_NOW DL_LAZY
-# else
-# ifdef RTLD_NOW
-# define LT_DLLAZY_OR_NOW RTLD_NOW
-# else
-# ifdef DL_NOW
-# define LT_DLLAZY_OR_NOW DL_NOW
-# else
-# define LT_DLLAZY_OR_NOW 0
-# endif
-# endif
-# endif
-# endif
-#endif
+# This must be Linux ELF.
+linux*)
+ version_type=linux
+ need_lib_prefix=no
+ need_version=no
+ library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
+ soname_spec='${libname}${release}${shared_ext}$major'
+ finish_cmds='PATH="\$PATH:/sbin" ldconfig -n $libdir'
+ shlibpath_var=LD_LIBRARY_PATH
+ shlibpath_overrides_runpath=no
+ # This implies no fast_install, which is unacceptable.
+ # Some rework will be needed to allow for fast_install
+ # before this can be enabled.
+ hardcode_into_libs=yes
-#ifdef __cplusplus
-extern "C" void exit (int);
-#endif
+ # Append ld.so.conf contents to the search path
+ if test -f /etc/ld.so.conf; then
+ lt_ld_extra=`awk '/^include / { system(sprintf("cd /etc; cat %s", \$2)); skip = 1; } { if (!skip) print \$0; skip = 0; }' < /etc/ld.so.conf | $SED -e 's/#.*//;s/[:, ]/ /g;s/=[^=]*$//;s/=[^= ]* / /g;/^$/d' | tr '\n' ' '`
+ sys_lib_dlsearch_path_spec="/lib /usr/lib $lt_ld_extra"
+ fi
-void fnord() { int i=42;}
-int main ()
-{
- void *self = dlopen (0, LT_DLGLOBAL|LT_DLLAZY_OR_NOW);
- int status = $lt_dlunknown;
+ # We used to test for /lib/ld.so.1 and disable shared libraries on
+ # powerpc, because MkLinux only supported shared libraries with the
+ # GNU dynamic linker. Since this was broken with cross compilers,
+ # most powerpc-linux boxes support dynamic linking these days and
+ # people can always --disable-shared, the test was removed, and we
+ # assume the GNU/Linux dynamic linker is in use.
+ dynamic_linker='GNU/Linux ld.so'
+ ;;
- if (self)
- {
- if (dlsym (self,"fnord")) status = $lt_dlno_uscore;
- else if (dlsym( self,"_fnord")) status = $lt_dlneed_uscore;
- /* dlclose (self); */
- }
+knetbsd*-gnu)
+ version_type=linux
+ need_lib_prefix=no
+ need_version=no
+ library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major ${libname}${shared_ext}'
+ soname_spec='${libname}${release}${shared_ext}$major'
+ shlibpath_var=LD_LIBRARY_PATH
+ shlibpath_overrides_runpath=no
+ hardcode_into_libs=yes
+ dynamic_linker='GNU ld.so'
+ ;;
- exit (status);
-}
-EOF
- if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
- (eval $ac_link) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); } && test -s conftest${ac_exeext} 2>/dev/null; then
- (./conftest; exit; ) 2>/dev/null
- lt_status=$?
- case x$lt_status in
- x$lt_dlno_uscore) lt_cv_dlopen_self=yes ;;
- x$lt_dlneed_uscore) lt_cv_dlopen_self=yes ;;
- x$lt_unknown|x*) lt_cv_dlopen_self=no ;;
- esac
- else :
- # compilation failed
- lt_cv_dlopen_self=no
+netbsd*)
+ version_type=sunos
+ need_lib_prefix=no
+ need_version=no
+ if echo __ELF__ | $CC -E - | grep __ELF__ >/dev/null; then
+ library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${shared_ext}$versuffix'
+ finish_cmds='PATH="\$PATH:/sbin" ldconfig -m $libdir'
+ dynamic_linker='NetBSD (a.out) ld.so'
+ else
+ library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major ${libname}${shared_ext}'
+ soname_spec='${libname}${release}${shared_ext}$major'
+ dynamic_linker='NetBSD ld.elf_so'
fi
-fi
-rm -fr conftest*
-
-
-fi
-echo "$as_me:$LINENO: result: $lt_cv_dlopen_self" >&5
-echo "${ECHO_T}$lt_cv_dlopen_self" >&6
+ shlibpath_var=LD_LIBRARY_PATH
+ shlibpath_overrides_runpath=yes
+ hardcode_into_libs=yes
+ ;;
- if test "x$lt_cv_dlopen_self" = xyes; then
- LDFLAGS="$LDFLAGS $link_static_flag"
- echo "$as_me:$LINENO: checking whether a statically linked program can dlopen itself" >&5
-echo $ECHO_N "checking whether a statically linked program can dlopen itself... $ECHO_C" >&6
-if test "${lt_cv_dlopen_self_static+set}" = set; then
- echo $ECHO_N "(cached) $ECHO_C" >&6
-else
- if test "$cross_compiling" = yes; then :
- lt_cv_dlopen_self_static=cross
-else
- lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2
- lt_status=$lt_dlunknown
- cat > conftest.$ac_ext <<EOF
-#line 18577 "configure"
-#include "confdefs.h"
+newsos6)
+ version_type=linux
+ library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
+ shlibpath_var=LD_LIBRARY_PATH
+ shlibpath_overrides_runpath=yes
+ ;;
-#if HAVE_DLFCN_H
-#include <dlfcn.h>
-#endif
+nto-qnx*)
+ version_type=linux
+ need_lib_prefix=no
+ need_version=no
+ library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
+ soname_spec='${libname}${release}${shared_ext}$major'
+ shlibpath_var=LD_LIBRARY_PATH
+ shlibpath_overrides_runpath=yes
+ ;;
-#include <stdio.h>
+openbsd*)
+ version_type=sunos
+ sys_lib_dlsearch_path_spec="/usr/lib"
+ need_lib_prefix=no
+ # Some older versions of OpenBSD (3.3 at least) *do* need versioned libs.
+ case $host_os in
+ openbsd3.3 | openbsd3.3.*) need_version=yes ;;
+ *) need_version=no ;;
+ esac
+ library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${shared_ext}$versuffix'
+ finish_cmds='PATH="\$PATH:/sbin" ldconfig -m $libdir'
+ shlibpath_var=LD_LIBRARY_PATH
+ if test -z "`echo __ELF__ | $CC -E - | grep __ELF__`" || test "$host_os-$host_cpu" = "openbsd2.8-powerpc"; then
+ case $host_os in
+ openbsd2.[89] | openbsd2.[89].*)
+ shlibpath_overrides_runpath=no
+ ;;
+ *)
+ shlibpath_overrides_runpath=yes
+ ;;
+ esac
+ else
+ shlibpath_overrides_runpath=yes
+ fi
+ ;;
-#ifdef RTLD_GLOBAL
-# define LT_DLGLOBAL RTLD_GLOBAL
-#else
-# ifdef DL_GLOBAL
-# define LT_DLGLOBAL DL_GLOBAL
-# else
-# define LT_DLGLOBAL 0
-# endif
-#endif
+os2*)
+ libname_spec='$name'
+ shrext_cmds=".dll"
+ need_lib_prefix=no
+ library_names_spec='$libname${shared_ext} $libname.a'
+ dynamic_linker='OS/2 ld.exe'
+ shlibpath_var=LIBPATH
+ ;;
-/* We may have to define LT_DLLAZY_OR_NOW in the command line if we
- find out it does not work in some platform. */
-#ifndef LT_DLLAZY_OR_NOW
-# ifdef RTLD_LAZY
-# define LT_DLLAZY_OR_NOW RTLD_LAZY
-# else
-# ifdef DL_LAZY
-# define LT_DLLAZY_OR_NOW DL_LAZY
-# else
-# ifdef RTLD_NOW
-# define LT_DLLAZY_OR_NOW RTLD_NOW
-# else
-# ifdef DL_NOW
-# define LT_DLLAZY_OR_NOW DL_NOW
-# else
-# define LT_DLLAZY_OR_NOW 0
-# endif
-# endif
-# endif
-# endif
-#endif
+osf3* | osf4* | osf5*)
+ version_type=osf
+ need_lib_prefix=no
+ need_version=no
+ soname_spec='${libname}${release}${shared_ext}$major'
+ library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
+ shlibpath_var=LD_LIBRARY_PATH
+ sys_lib_search_path_spec="/usr/shlib /usr/ccs/lib /usr/lib/cmplrs/cc /usr/lib /usr/local/lib /var/shlib"
+ sys_lib_dlsearch_path_spec="$sys_lib_search_path_spec"
+ ;;
-#ifdef __cplusplus
-extern "C" void exit (int);
-#endif
+solaris*)
+ version_type=linux
+ need_lib_prefix=no
+ need_version=no
+ library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
+ soname_spec='${libname}${release}${shared_ext}$major'
+ shlibpath_var=LD_LIBRARY_PATH
+ shlibpath_overrides_runpath=yes
+ hardcode_into_libs=yes
+ # ldd complains unless libraries are executable
+ postinstall_cmds='chmod +x $lib'
+ ;;
-void fnord() { int i=42;}
-int main ()
-{
- void *self = dlopen (0, LT_DLGLOBAL|LT_DLLAZY_OR_NOW);
- int status = $lt_dlunknown;
+sunos4*)
+ version_type=sunos
+ library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${shared_ext}$versuffix'
+ finish_cmds='PATH="\$PATH:/usr/etc" ldconfig $libdir'
+ shlibpath_var=LD_LIBRARY_PATH
+ shlibpath_overrides_runpath=yes
+ if test "$with_gnu_ld" = yes; then
+ need_lib_prefix=no
+ fi
+ need_version=yes
+ ;;
- if (self)
- {
- if (dlsym (self,"fnord")) status = $lt_dlno_uscore;
- else if (dlsym( self,"_fnord")) status = $lt_dlneed_uscore;
- /* dlclose (self); */
- }
+sysv4 | sysv4.3*)
+ version_type=linux
+ library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
+ soname_spec='${libname}${release}${shared_ext}$major'
+ shlibpath_var=LD_LIBRARY_PATH
+ case $host_vendor in
+ sni)
+ shlibpath_overrides_runpath=no
+ need_lib_prefix=no
+ export_dynamic_flag_spec='${wl}-Blargedynsym'
+ runpath_var=LD_RUN_PATH
+ ;;
+ siemens)
+ need_lib_prefix=no
+ ;;
+ motorola)
+ need_lib_prefix=no
+ need_version=no
+ shlibpath_overrides_runpath=no
+ sys_lib_search_path_spec='/lib /usr/lib /usr/ccs/lib'
+ ;;
+ esac
+ ;;
- exit (status);
-}
-EOF
- if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5
- (eval $ac_link) 2>&5
- ac_status=$?
- echo "$as_me:$LINENO: \$? = $ac_status" >&5
- (exit $ac_status); } && test -s conftest${ac_exeext} 2>/dev/null; then
- (./conftest; exit; ) 2>/dev/null
- lt_status=$?
- case x$lt_status in
- x$lt_dlno_uscore) lt_cv_dlopen_self_static=yes ;;
- x$lt_dlneed_uscore) lt_cv_dlopen_self_static=yes ;;
- x$lt_unknown|x*) lt_cv_dlopen_self_static=no ;;
+sysv4*MP*)
+ if test -d /usr/nec ;then
+ version_type=linux
+ library_names_spec='$libname${shared_ext}.$versuffix $libname${shared_ext}.$major $libname${shared_ext}'
+ soname_spec='$libname${shared_ext}.$major'
+ shlibpath_var=LD_LIBRARY_PATH
+ fi
+ ;;
+
+sysv5* | sco3.2v5* | sco5v6* | unixware* | OpenUNIX* | sysv4*uw2*)
+ version_type=freebsd-elf
+ need_lib_prefix=no
+ need_version=no
+ library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext} $libname${shared_ext}'
+ soname_spec='${libname}${release}${shared_ext}$major'
+ shlibpath_var=LD_LIBRARY_PATH
+ hardcode_into_libs=yes
+ if test "$with_gnu_ld" = yes; then
+ sys_lib_search_path_spec='/usr/local/lib /usr/gnu/lib /usr/ccs/lib /usr/lib /lib'
+ shlibpath_overrides_runpath=no
+ else
+ sys_lib_search_path_spec='/usr/ccs/lib /usr/lib'
+ shlibpath_overrides_runpath=yes
+ case $host_os in
+ sco3.2v5*)
+ sys_lib_search_path_spec="$sys_lib_search_path_spec /lib"
+ ;;
esac
- else :
- # compilation failed
- lt_cv_dlopen_self_static=no
fi
-fi
-rm -fr conftest*
+ sys_lib_dlsearch_path_spec='/usr/lib'
+ ;;
+
+uts4*)
+ version_type=linux
+ library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
+ soname_spec='${libname}${release}${shared_ext}$major'
+ shlibpath_var=LD_LIBRARY_PATH
+ ;;
+*)
+ dynamic_linker=no
+ ;;
+esac
+echo "$as_me:$LINENO: result: $dynamic_linker" >&5
+echo "${ECHO_T}$dynamic_linker" >&6
+test "$dynamic_linker" = no && can_build_shared=no
+variables_saved_for_relink="PATH $shlibpath_var $runpath_var"
+if test "$GCC" = yes; then
+ variables_saved_for_relink="$variables_saved_for_relink GCC_EXEC_PREFIX COMPILER_PATH LIBRARY_PATH"
fi
-echo "$as_me:$LINENO: result: $lt_cv_dlopen_self_static" >&5
-echo "${ECHO_T}$lt_cv_dlopen_self_static" >&6
- fi
- CPPFLAGS="$save_CPPFLAGS"
- LDFLAGS="$save_LDFLAGS"
- LIBS="$save_LIBS"
- ;;
- esac
+echo "$as_me:$LINENO: checking how to hardcode library paths into programs" >&5
+echo $ECHO_N "checking how to hardcode library paths into programs... $ECHO_C" >&6
+hardcode_action_GCJ=
+if test -n "$hardcode_libdir_flag_spec_GCJ" || \
+ test -n "$runpath_var_GCJ" || \
+ test "X$hardcode_automatic_GCJ" = "Xyes" ; then
- case $lt_cv_dlopen_self in
- yes|no) enable_dlopen_self=$lt_cv_dlopen_self ;;
- *) enable_dlopen_self=unknown ;;
- esac
+ # We can hardcode non-existant directories.
+ if test "$hardcode_direct_GCJ" != no &&
+ # If the only mechanism to avoid hardcoding is shlibpath_var, we
+ # have to relink, otherwise we might link with an installed library
+ # when we should be linking with a yet-to-be-installed one
+ ## test "$_LT_AC_TAGVAR(hardcode_shlibpath_var, GCJ)" != no &&
+ test "$hardcode_minus_L_GCJ" != no; then
+ # Linking always hardcodes the temporary library directory.
+ hardcode_action_GCJ=relink
+ else
+ # We can link without hardcoding, and we can hardcode nonexisting dirs.
+ hardcode_action_GCJ=immediate
+ fi
+else
+ # We cannot hardcode anything, or else we can only hardcode existing
+ # directories.
+ hardcode_action_GCJ=unsupported
+fi
+echo "$as_me:$LINENO: result: $hardcode_action_GCJ" >&5
+echo "${ECHO_T}$hardcode_action_GCJ" >&6
- case $lt_cv_dlopen_self_static in
- yes|no) enable_dlopen_self_static=$lt_cv_dlopen_self_static ;;
- *) enable_dlopen_self_static=unknown ;;
- esac
+if test "$hardcode_action_GCJ" = relink; then
+ # Fast installation is not supported
+ enable_fast_install=no
+elif test "$shlibpath_overrides_runpath" = yes ||
+ test "$enable_shared" = no; then
+ # Fast installation is not necessary
+ enable_fast_install=needless
fi
@@ -18691,7 +17638,7 @@ if test -f "$ltmain"; then
# Now quote all the things that may contain metacharacters while being
# careful not to overquote the AC_SUBSTed values. We take copies of the
# variables and quote the copies for generation of the libtool script.
- for var in echo old_CC old_CFLAGS AR AR_FLAGS EGREP RANLIB LN_S LTCC NM \
+ for var in echo old_CC old_CFLAGS AR AR_FLAGS EGREP RANLIB LN_S LTCC LTCFLAGS NM \
SED SHELL STRIP \
libname_spec library_names_spec soname_spec extract_expsyms_cmds \
old_striplib striplib file_magic_cmd finish_cmds finish_eval \
@@ -18809,6 +17756,9 @@ AR_FLAGS=$lt_AR_FLAGS
# A C compiler.
LTCC=$lt_LTCC
+# LTCC compiler flags.
+LTCFLAGS=$lt_LTCFLAGS
+
# A language-specific compiler.
CC=$lt_compiler_GCJ
@@ -19118,6 +18068,9 @@ lt_simple_link_test_code="$lt_simple_compile_test_code"
# If no C compiler was specified, use CC.
LTCC=${LTCC-"$CC"}
+# If no C compiler flags were specified, use CFLAGS.
+LTCFLAGS=${LTCFLAGS-"$CFLAGS"}
+
# Allow CC to be a program name with arguments.
compiler=$CC
@@ -19125,13 +18078,13 @@ compiler=$CC
# save warnings/boilerplate of simple test code
ac_outfile=conftest.$ac_objext
printf "$lt_simple_compile_test_code" >conftest.$ac_ext
-eval "$ac_compile" 2>&1 >/dev/null | $SED '/^$/d' >conftest.err
+eval "$ac_compile" 2>&1 >/dev/null | $SED '/^$/d; /^ *+/d' >conftest.err
_lt_compiler_boilerplate=`cat conftest.err`
$rm conftest*
ac_outfile=conftest.$ac_objext
printf "$lt_simple_link_test_code" >conftest.$ac_ext
-eval "$ac_link" 2>&1 >/dev/null | $SED '/^$/d' >conftest.err
+eval "$ac_link" 2>&1 >/dev/null | $SED '/^$/d; /^ *+/d' >conftest.err
_lt_linker_boilerplate=`cat conftest.err`
$rm conftest*
@@ -19166,7 +18119,7 @@ if test -f "$ltmain"; then
# Now quote all the things that may contain metacharacters while being
# careful not to overquote the AC_SUBSTed values. We take copies of the
# variables and quote the copies for generation of the libtool script.
- for var in echo old_CC old_CFLAGS AR AR_FLAGS EGREP RANLIB LN_S LTCC NM \
+ for var in echo old_CC old_CFLAGS AR AR_FLAGS EGREP RANLIB LN_S LTCC LTCFLAGS NM \
SED SHELL STRIP \
libname_spec library_names_spec soname_spec extract_expsyms_cmds \
old_striplib striplib file_magic_cmd finish_cmds finish_eval \
@@ -19284,6 +18237,9 @@ AR_FLAGS=$lt_AR_FLAGS
# A C compiler.
LTCC=$lt_LTCC
+# LTCC compiler flags.
+LTCFLAGS=$lt_LTCFLAGS
+
# A language-specific compiler.
CC=$lt_compiler_RC
@@ -19629,8 +18585,9 @@ if test "${enable_debug+set}" = set; then
enableval="$enable_debug"
CXXFLAGS="-g -O0 -Wall"
- cat >>confdefs.h <<\_ACEOF
-#define WITH_DEBUG 1
+
+cat >>confdefs.h <<\_ACEOF
+#define WITH_DEBUG
_ACEOF
diff --git a/contrib/ldapc++/configure.in b/contrib/ldapc++/configure.in
index 29405b74bd396456056c83d57adf81df2e877196..a22bd502e838b0e0bebe855baf4c50c097fd5d57 100644
--- a/contrib/ldapc++/configure.in
+++ b/contrib/ldapc++/configure.in
@@ -23,7 +23,7 @@ AC_PROG_LIBTOOL
dnl AC_PROG_MAKE_SET
AC_ARG_ENABLE(debug,[ --enable-debug],[
CXXFLAGS="-g -O0 -Wall"
- AC_DEFINE(WITH_DEBUG)
+ AC_DEFINE(WITH_DEBUG,[],[Define to 1 ot enable debug logging])
],[
CXXFLAGS="-O0"
]
diff --git a/contrib/ldapc++/depcomp b/contrib/ldapc++/depcomp
index 807b991f4a895431dfc232112e77b0ae7e3d5017..04701da536f33a7c39d7bb01b87a70ae3a776df5 100755
--- a/contrib/ldapc++/depcomp
+++ b/contrib/ldapc++/depcomp
@@ -1,7 +1,9 @@
#! /bin/sh
-
# depcomp - compile a program generating dependencies as side-effects
-# Copyright 1999, 2000 Free Software Foundation, Inc.
+
+scriptversion=2005-07-09.11
+
+# Copyright (C) 1999, 2000, 2003, 2004, 2005 Free Software Foundation, Inc.
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@@ -15,8 +17,8 @@
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
-# 02111-1307, USA.
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+# 02110-1301, USA.
# As a special exception to the GNU General Public License, if you
# distribute this file as part of a program that contains a
@@ -25,22 +27,45 @@
# Originally written by Alexandre Oliva <oliva@dcc.unicamp.br>.
+case $1 in
+ '')
+ echo "$0: No command. Try \`$0 --help' for more information." 1>&2
+ exit 1;
+ ;;
+ -h | --h*)
+ cat <<\EOF
+Usage: depcomp [--help] [--version] PROGRAM [ARGS]
+
+Run PROGRAMS ARGS to compile a file, generating dependencies
+as side-effects.
+
+Environment variables:
+ depmode Dependency tracking mode.
+ source Source file read by `PROGRAMS ARGS'.
+ object Object file output by `PROGRAMS ARGS'.
+ DEPDIR directory where to store dependencies.
+ depfile Dependency file to output.
+ tmpdepfile Temporary file to use when outputing dependencies.
+ libtool Whether libtool is used (yes/no).
+
+Report bugs to <bug-automake@gnu.org>.
+EOF
+ exit $?
+ ;;
+ -v | --v*)
+ echo "depcomp $scriptversion"
+ exit $?
+ ;;
+esac
+
if test -z "$depmode" || test -z "$source" || test -z "$object"; then
echo "depcomp: Variables source, object and depmode must be set" 1>&2
exit 1
fi
-# `libtool' can also be set to `yes' or `no'.
-
-if test -z "$depfile"; then
- base=`echo "$object" | sed -e 's,^.*/,,' -e 's,\.\([^.]*\)$,.P\1,'`
- dir=`echo "$object" | sed 's,/.*$,/,'`
- if test "$dir" = "$object"; then
- dir=
- fi
- # FIXME: should be _deps on DOS.
- depfile="$dir.deps/$base"
-fi
+# Dependencies for sub/bar.o or sub/bar.obj go into sub/.deps/bar.Po.
+depfile=${depfile-`echo "$object" |
+ sed 's|[^\\/]*$|'${DEPDIR-.deps}'/&|;s|\.\([^.]*\)$|.P\1|;s|Pobj$|Po|'`}
tmpdepfile=${tmpdepfile-`echo "$depfile" | sed 's/\.\([^.]*\)$/.T\1/'`}
rm -f "$tmpdepfile"
@@ -172,19 +197,25 @@ sgi)
aix)
# The C for AIX Compiler uses -M and outputs the dependencies
- # in a .u file. This file always lives in the current directory.
- # Also, the AIX compiler puts `$object:' at the start of each line;
- # $object doesn't have directory information.
- stripped=`echo "$object" | sed -e 's,^.*/,,' -e 's/\(.*\)\..*$/\1/'`
+ # in a .u file. In older versions, this file always lives in the
+ # current directory. Also, the AIX compiler puts `$object:' at the
+ # start of each line; $object doesn't have directory information.
+ # Version 6 uses the directory in both cases.
+ stripped=`echo "$object" | sed 's/\(.*\)\..*$/\1/'`
tmpdepfile="$stripped.u"
- outname="$stripped.o"
if test "$libtool" = yes; then
"$@" -Wc,-M
else
"$@" -M
fi
-
stat=$?
+
+ if test -f "$tmpdepfile"; then :
+ else
+ stripped=`echo "$stripped" | sed 's,^.*/,,'`
+ tmpdepfile="$stripped.u"
+ fi
+
if test $stat -eq 0; then :
else
rm -f "$tmpdepfile"
@@ -192,6 +223,7 @@ aix)
fi
if test -f "$tmpdepfile"; then
+ outname="$stripped.o"
# Each line is of the form `foo.o: dependent.h'.
# Do two passes, one to just change these to
# `$object: dependent.h' and one to simply `dependent.h:'.
@@ -206,6 +238,44 @@ aix)
rm -f "$tmpdepfile"
;;
+icc)
+ # Intel's C compiler understands `-MD -MF file'. However on
+ # icc -MD -MF foo.d -c -o sub/foo.o sub/foo.c
+ # ICC 7.0 will fill foo.d with something like
+ # foo.o: sub/foo.c
+ # foo.o: sub/foo.h
+ # which is wrong. We want:
+ # sub/foo.o: sub/foo.c
+ # sub/foo.o: sub/foo.h
+ # sub/foo.c:
+ # sub/foo.h:
+ # ICC 7.1 will output
+ # foo.o: sub/foo.c sub/foo.h
+ # and will wrap long lines using \ :
+ # foo.o: sub/foo.c ... \
+ # sub/foo.h ... \
+ # ...
+
+ "$@" -MD -MF "$tmpdepfile"
+ stat=$?
+ if test $stat -eq 0; then :
+ else
+ rm -f "$tmpdepfile"
+ exit $stat
+ fi
+ rm -f "$depfile"
+ # Each line is of the form `foo.o: dependent.h',
+ # or `foo.o: dep1.h dep2.h \', or ` dep3.h dep4.h \'.
+ # Do two passes, one to just change these to
+ # `$object: dependent.h' and one to simply `dependent.h:'.
+ sed "s,^[^:]*:,$object :," < "$tmpdepfile" > "$depfile"
+ # Some versions of the HPUX 10.20 sed can't process this invocation
+ # correctly. Breaking it into two sed invocations is a workaround.
+ sed 's,^[^:]*: \(.*\)$,\1,;s/^\\$//;/^$/d;/:$/d' < "$tmpdepfile" |
+ sed -e 's/$/ :/' >> "$depfile"
+ rm -f "$tmpdepfile"
+ ;;
+
tru64)
# The Tru64 compiler uses -MD to generate dependencies as a side
# effect. `cc -MD -o foo.o ...' puts the dependencies into `foo.o.d'.
@@ -217,31 +287,47 @@ tru64)
base=`echo "$object" | sed -e 's|^.*/||' -e 's/\.o$//' -e 's/\.lo$//'`
if test "$libtool" = yes; then
- tmpdepfile1="$dir.libs/$base.lo.d"
- tmpdepfile2="$dir.libs/$base.d"
+ # With Tru64 cc, shared objects can also be used to make a
+ # static library. This mecanism is used in libtool 1.4 series to
+ # handle both shared and static libraries in a single compilation.
+ # With libtool 1.4, dependencies were output in $dir.libs/$base.lo.d.
+ #
+ # With libtool 1.5 this exception was removed, and libtool now
+ # generates 2 separate objects for the 2 libraries. These two
+ # compilations output dependencies in in $dir.libs/$base.o.d and
+ # in $dir$base.o.d. We have to check for both files, because
+ # one of the two compilations can be disabled. We should prefer
+ # $dir$base.o.d over $dir.libs/$base.o.d because the latter is
+ # automatically cleaned when .libs/ is deleted, while ignoring
+ # the former would cause a distcleancheck panic.
+ tmpdepfile1=$dir.libs/$base.lo.d # libtool 1.4
+ tmpdepfile2=$dir$base.o.d # libtool 1.5
+ tmpdepfile3=$dir.libs/$base.o.d # libtool 1.5
+ tmpdepfile4=$dir.libs/$base.d # Compaq CCC V6.2-504
"$@" -Wc,-MD
else
- tmpdepfile1="$dir$base.o.d"
- tmpdepfile2="$dir$base.d"
+ tmpdepfile1=$dir$base.o.d
+ tmpdepfile2=$dir$base.d
+ tmpdepfile3=$dir$base.d
+ tmpdepfile4=$dir$base.d
"$@" -MD
fi
stat=$?
if test $stat -eq 0; then :
else
- rm -f "$tmpdepfile1" "$tmpdepfile2"
+ rm -f "$tmpdepfile1" "$tmpdepfile2" "$tmpdepfile3" "$tmpdepfile4"
exit $stat
fi
- if test -f "$tmpdepfile1"; then
- tmpdepfile="$tmpdepfile1"
- else
- tmpdepfile="$tmpdepfile2"
- fi
+ for tmpdepfile in "$tmpdepfile1" "$tmpdepfile2" "$tmpdepfile3" "$tmpdepfile4"
+ do
+ test -f "$tmpdepfile" && break
+ done
if test -f "$tmpdepfile"; then
sed -e "s,^.*\.[a-z]*:,$object:," < "$tmpdepfile" > "$depfile"
- # That's a space and a tab in the [].
- sed -e 's,^.*\.[a-z]*:[ ]*,,' -e 's,$,:,' < "$tmpdepfile" >> "$depfile"
+ # That's a tab and a space in the [].
+ sed -e 's,^.*\.[a-z]*:[ ]*,,' -e 's,$,:,' < "$tmpdepfile" >> "$depfile"
else
echo "#dummy" > "$depfile"
fi
@@ -254,7 +340,7 @@ tru64)
dashmstdout)
# Important note: in order to support this mode, a compiler *must*
- # always write the proprocessed file to stdout, regardless of -o.
+ # always write the preprocessed file to stdout, regardless of -o.
"$@" || exit $?
# Remove the call to Libtool.
@@ -265,9 +351,7 @@ dashmstdout)
shift
fi
- # Remove `-o $object'. We will use -o /dev/null later,
- # however we can't do the remplacement now because
- # `-o $object' might simply not be used
+ # Remove `-o $object'.
IFS=" "
for arg
do
@@ -287,7 +371,11 @@ dashmstdout)
done
test -z "$dashmflag" && dashmflag=-M
- "$@" -o /dev/null $dashmflag | sed 's:^[^:]*\:[ ]*:'"$object"'\: :' > "$tmpdepfile"
+ # Require at least two characters before searching for `:'
+ # in the target name. This is to cope with DOS-style filenames:
+ # a dependency such as `c:/foo/bar' could be seen as target `c' otherwise.
+ "$@" $dashmflag |
+ sed 's:^[ ]*[^: ][^:][^:]*\:[ ]*:'"$object"'\: :' > "$tmpdepfile"
rm -f "$depfile"
cat < "$tmpdepfile" > "$depfile"
tr ' ' '
@@ -306,6 +394,13 @@ dashXmstdout)
makedepend)
"$@" || exit $?
+ # Remove any Libtool call
+ if test "$libtool" = yes; then
+ while test $1 != '--mode=compile'; do
+ shift
+ done
+ shift
+ fi
# X makedepend
shift
cleared=no
@@ -318,7 +413,9 @@ makedepend)
case "$arg" in
-D*|-I*)
set fnord "$@" "$arg"; shift ;;
- -*)
+ # Strip any option that makedepend may not understand. Remove
+ # the object too, otherwise makedepend will parse it as a source file.
+ -*|$object)
;;
*)
set fnord "$@" "$arg"; shift ;;
@@ -339,7 +436,7 @@ makedepend)
cpp)
# Important note: in order to support this mode, a compiler *must*
- # always write the proprocessed file to stdout.
+ # always write the preprocessed file to stdout.
"$@" || exit $?
# Remove the call to Libtool.
@@ -370,7 +467,8 @@ cpp)
done
"$@" -E |
- sed -n '/^# [0-9][0-9]* "\([^"]*\)".*/ s:: \1 \\:p' |
+ sed -n -e '/^# [0-9][0-9]* "\([^"]*\)".*/ s:: \1 \\:p' \
+ -e '/^#line [0-9][0-9]* "\([^"]*\)".*/ s:: \1 \\:p' |
sed '$ s: \\$::' > "$tmpdepfile"
rm -f "$depfile"
echo "$object : \\" > "$depfile"
@@ -381,7 +479,7 @@ cpp)
msvisualcpp)
# Important note: in order to support this mode, a compiler *must*
- # always write the proprocessed file to stdout, regardless of -o,
+ # always write the preprocessed file to stdout, regardless of -o,
# because we must use -o when running libtool.
"$@" || exit $?
IFS=" "
@@ -421,3 +519,12 @@ none)
esac
exit 0
+
+# Local Variables:
+# mode: shell-script
+# sh-indentation: 2
+# eval: (add-hook 'write-file-hooks 'time-stamp)
+# time-stamp-start: "scriptversion="
+# time-stamp-format: "%:y-%02m-%02d.%02H"
+# time-stamp-end: "$"
+# End:
diff --git a/contrib/ldapc++/examples/Makefile.am b/contrib/ldapc++/examples/Makefile.am
index 3ce279893522cc582a88732d14e318875c9f24dd..bf461942258d5ea217a222302e0f963b7b9a11f1 100644
--- a/contrib/ldapc++/examples/Makefile.am
+++ b/contrib/ldapc++/examples/Makefile.am
@@ -2,10 +2,13 @@
# Copyright 2003, OpenLDAP Foundation, All Rights Reserved.
# COPYING RESTRICTIONS APPLY, see COPYRIGHT file
##
-noinst_PROGRAMS = main readSchema
+noinst_PROGRAMS = main readSchema urlTest
main_SOURCES = main.cpp
main_LDADD = ../src/libldapcpp.la
readSchema_SOURCES = readSchema.cpp
readSchema_LDADD = ../src/libldapcpp.la
+
+urlTest_SOURCES = urlTest.cpp
+urlTest_LDADD = ../src/libldapcpp.la
diff --git a/contrib/ldapc++/examples/Makefile.in b/contrib/ldapc++/examples/Makefile.in
index 73672ca1e1f5d63146e9bd3b5f40c16f64fbb36f..8685a813673bfb29d93161cf7efb197397258e7e 100644
--- a/contrib/ldapc++/examples/Makefile.in
+++ b/contrib/ldapc++/examples/Makefile.in
@@ -36,14 +36,14 @@ PRE_UNINSTALL = :
POST_UNINSTALL = :
build_triplet = @build@
host_triplet = @host@
-noinst_PROGRAMS = main$(EXEEXT) readSchema$(EXEEXT)
+noinst_PROGRAMS = main$(EXEEXT) readSchema$(EXEEXT) urlTest$(EXEEXT)
subdir = examples
DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in
ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
am__aclocal_m4_deps = $(top_srcdir)/configure.in
am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
$(ACLOCAL_M4)
-mkinstalldirs = $(SHELL) $(top_srcdir)/mkinstalldirs
+mkinstalldirs = $(install_sh) -d
CONFIG_HEADER = $(top_builddir)/src/config.h
CONFIG_CLEAN_FILES =
PROGRAMS = $(noinst_PROGRAMS)
@@ -53,6 +53,9 @@ main_DEPENDENCIES = ../src/libldapcpp.la
am_readSchema_OBJECTS = readSchema.$(OBJEXT)
readSchema_OBJECTS = $(am_readSchema_OBJECTS)
readSchema_DEPENDENCIES = ../src/libldapcpp.la
+am_urlTest_OBJECTS = urlTest.$(OBJEXT)
+urlTest_OBJECTS = $(am_urlTest_OBJECTS)
+urlTest_DEPENDENCIES = ../src/libldapcpp.la
DEFAULT_INCLUDES = -I. -I$(srcdir) -I$(top_builddir)/src
depcomp = $(SHELL) $(top_srcdir)/depcomp
am__depfiles_maybe = depfiles
@@ -64,8 +67,9 @@ LTCXXCOMPILE = $(LIBTOOL) --tag=CXX --mode=compile $(CXX) $(DEFS) \
CXXLD = $(CXX)
CXXLINK = $(LIBTOOL) --tag=CXX --mode=link $(CXXLD) $(AM_CXXFLAGS) \
$(CXXFLAGS) $(AM_LDFLAGS) $(LDFLAGS) -o $@
-SOURCES = $(main_SOURCES) $(readSchema_SOURCES)
-DIST_SOURCES = $(main_SOURCES) $(readSchema_SOURCES)
+SOURCES = $(main_SOURCES) $(readSchema_SOURCES) $(urlTest_SOURCES)
+DIST_SOURCES = $(main_SOURCES) $(readSchema_SOURCES) \
+ $(urlTest_SOURCES)
ETAGS = etags
CTAGS = ctags
DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
@@ -169,6 +173,8 @@ main_SOURCES = main.cpp
main_LDADD = ../src/libldapcpp.la
readSchema_SOURCES = readSchema.cpp
readSchema_LDADD = ../src/libldapcpp.la
+urlTest_SOURCES = urlTest.cpp
+urlTest_LDADD = ../src/libldapcpp.la
all: all-am
.SUFFIXES:
@@ -215,6 +221,9 @@ main$(EXEEXT): $(main_OBJECTS) $(main_DEPENDENCIES)
readSchema$(EXEEXT): $(readSchema_OBJECTS) $(readSchema_DEPENDENCIES)
@rm -f readSchema$(EXEEXT)
$(CXXLINK) $(readSchema_LDFLAGS) $(readSchema_OBJECTS) $(readSchema_LDADD) $(LIBS)
+urlTest$(EXEEXT): $(urlTest_OBJECTS) $(urlTest_DEPENDENCIES)
+ @rm -f urlTest$(EXEEXT)
+ $(CXXLINK) $(urlTest_LDFLAGS) $(urlTest_OBJECTS) $(urlTest_LDADD) $(LIBS)
mostlyclean-compile:
-rm -f *.$(OBJEXT)
@@ -224,6 +233,7 @@ distclean-compile:
@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/main.Po@am__quote@
@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/readSchema.Po@am__quote@
+@AMDEP_TRUE@@am__include@ @am__quote@./$(DEPDIR)/urlTest.Po@am__quote@
.cpp.o:
@am__fastdepCXX_TRUE@ if $(CXXCOMPILE) -MT $@ -MD -MP -MF "$(DEPDIR)/$*.Tpo" -c -o $@ $<; \
diff --git a/contrib/ldapc++/examples/urlTest.cpp b/contrib/ldapc++/examples/urlTest.cpp
new file mode 100644
index 0000000000000000000000000000000000000000..e1ab2a0dae0014fcbb3d75cbefd3342db229050b
--- /dev/null
+++ b/contrib/ldapc++/examples/urlTest.cpp
@@ -0,0 +1,34 @@
+#include <LDAPUrl.h>
+#include <LDAPException.h>
+#include <iostream>
+
+int main(int argc, char *argv[]) {
+ if ( argc != 2 ) {
+ std::cout << argc << std::endl;
+ std::cout << "urlTest <ldap-URI>" << std::endl;
+ exit(1);
+ }
+ std::string uristr = argv[1];
+ try {
+ LDAPUrl url(uristr);
+ std::cout << "Host: " << url.getHost() << std::endl;
+ std::cout << "Port: " << url.getPort() << std::endl;
+ std::cout << "BaseDN: " << url.getDN() << std::endl;
+ std::cout << "Scope: " << url.getScope() << std::endl;
+ StringList attrs = url.getAttrs();
+ std::cout << "Attrs: " << std::endl;
+ StringList::const_iterator i = attrs.begin();
+ for( ; i != attrs.end(); i++ ) {
+ std::cout << " " << *i << std::endl;
+ }
+ std::cout << "Filter: " << url.getFilter() << std::endl;
+ std::cout << "Setting new BaseDN" << std::endl;
+ url.setDN("o=Beispiel, c=DE");
+ std::cout << "Url: " << url.getURLString() << std::endl;
+ } catch (LDAPUrlException e) {
+ std::cout << e.getCode() << std::endl;
+ std::cout << e.getErrorMessage() << std::endl;
+ std::cout << e.getAdditionalInfo() << std::endl;
+ }
+
+}
diff --git a/contrib/ldapc++/install-sh b/contrib/ldapc++/install-sh
index e9de23842dcd44d2953129c866b1ad25f7e1f1d9..4d4a9519eaf88b18fb157dfe5fae59c1c5d005c7 100755
--- a/contrib/ldapc++/install-sh
+++ b/contrib/ldapc++/install-sh
@@ -1,19 +1,38 @@
#!/bin/sh
-#
# install - install a program, script, or datafile
-# This comes from X11R5 (mit/util/scripts/install.sh).
+
+scriptversion=2005-05-14.22
+
+# This originates from X11R5 (mit/util/scripts/install.sh), which was
+# later released in X11R6 (xc/config/util/install.sh) with the
+# following copyright and license.
+#
+# Copyright (C) 1994 X Consortium
+#
+# Permission is hereby granted, free of charge, to any person obtaining a copy
+# of this software and associated documentation files (the "Software"), to
+# deal in the Software without restriction, including without limitation the
+# rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+# sell copies of the Software, and to permit persons to whom the Software is
+# furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice shall be included in
+# all copies or substantial portions of the Software.
#
-# Copyright 1991 by the Massachusetts Institute of Technology
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+# X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
+# AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNEC-
+# TION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
#
-# Permission to use, copy, modify, distribute, and sell this software and its
-# documentation for any purpose is hereby granted without fee, provided that
-# the above copyright notice appear in all copies and that both that
-# copyright notice and this permission notice appear in supporting
-# documentation, and that the name of M.I.T. not be used in advertising or
-# publicity pertaining to distribution of the software without specific,
-# written prior permission. M.I.T. makes no representations about the
-# suitability of this software for any purpose. It is provided "as is"
-# without express or implied warranty.
+# Except as contained in this notice, the name of the X Consortium shall not
+# be used in advertising or otherwise to promote the sale, use or other deal-
+# ings in this Software without prior written authorization from the X Consor-
+# tium.
+#
+#
+# FSF changes to this file are in the public domain.
#
# Calling this script install-sh is preferred over install.sh, to prevent
# `make' implicit rules from creating a file called install from it
@@ -23,13 +42,11 @@
# from scratch. It can only install one file at a time, a restriction
# shared with many OS's install programs.
-
# set DOITPROG to echo to test this script
# Don't use :- since 4.3BSD and earlier shells don't like it.
doit="${DOITPROG-}"
-
# put in absolute paths if you don't have them in your path; or use env. vars.
mvprog="${MVPROG-mv}"
@@ -41,211 +58,266 @@ stripprog="${STRIPPROG-strip}"
rmprog="${RMPROG-rm}"
mkdirprog="${MKDIRPROG-mkdir}"
-transformbasename=""
-transform_arg=""
-instcmd="$mvprog"
chmodcmd="$chmodprog 0755"
-chowncmd=""
-chgrpcmd=""
-stripcmd=""
+chowncmd=
+chgrpcmd=
+stripcmd=
rmcmd="$rmprog -f"
mvcmd="$mvprog"
-src=""
-dst=""
-dir_arg=""
-
-while [ x"$1" != x ]; do
- case $1 in
- -c) instcmd="$cpprog"
- shift
- continue;;
-
- -d) dir_arg=true
- shift
- continue;;
-
- -m) chmodcmd="$chmodprog $2"
- shift
- shift
- continue;;
-
- -o) chowncmd="$chownprog $2"
- shift
- shift
- continue;;
-
- -g) chgrpcmd="$chgrpprog $2"
- shift
- shift
- continue;;
-
- -s) stripcmd="$stripprog"
- shift
- continue;;
-
- -t=*) transformarg=`echo $1 | sed 's/-t=//'`
- shift
- continue;;
-
- -b=*) transformbasename=`echo $1 | sed 's/-b=//'`
- shift
- continue;;
-
- *) if [ x"$src" = x ]
- then
- src=$1
- else
- # this colon is to work around a 386BSD /bin/sh bug
- :
- dst=$1
- fi
- shift
- continue;;
- esac
-done
-
-if [ x"$src" = x ]
-then
- echo "install: no input file specified"
- exit 1
-else
- true
-fi
-
-if [ x"$dir_arg" != x ]; then
- dst=$src
- src=""
-
- if [ -d $dst ]; then
- instcmd=:
- chmodcmd=""
- else
- instcmd=mkdir
- fi
-else
-
-# Waiting for this to be detected by the "$instcmd $src $dsttmp" command
-# might cause directories to be created, which would be especially bad
-# if $src (and thus $dsttmp) contains '*'.
-
- if [ -f $src -o -d $src ]
- then
- true
- else
- echo "install: $src does not exist"
- exit 1
- fi
-
- if [ x"$dst" = x ]
- then
- echo "install: no destination specified"
- exit 1
- else
- true
- fi
-
-# If destination is a directory, append the input filename; if your system
-# does not like double slashes in filenames, you may need to add some logic
-
- if [ -d $dst ]
- then
- dst="$dst"/`basename $src`
- else
- true
- fi
-fi
-
-## this sed command emulates the dirname command
-dstdir=`echo $dst | sed -e 's,[^/]*$,,;s,/$,,;s,^$,.,'`
-
-# Make sure that the destination directory exists.
-# this part is taken from Noah Friedman's mkinstalldirs script
-
-# Skip lots of stat calls in the usual case.
-if [ ! -d "$dstdir" ]; then
-defaultIFS='
-'
-IFS="${IFS-${defaultIFS}}"
-
-oIFS="${IFS}"
-# Some sh's can't handle IFS=/ for some reason.
-IFS='%'
-set - `echo ${dstdir} | sed -e 's@/@%@g' -e 's@^%@/@'`
-IFS="${oIFS}"
-
-pathcomp=''
-
-while [ $# -ne 0 ] ; do
- pathcomp="${pathcomp}${1}"
+src=
+dst=
+dir_arg=
+dstarg=
+no_target_directory=
+
+usage="Usage: $0 [OPTION]... [-T] SRCFILE DSTFILE
+ or: $0 [OPTION]... SRCFILES... DIRECTORY
+ or: $0 [OPTION]... -t DIRECTORY SRCFILES...
+ or: $0 [OPTION]... -d DIRECTORIES...
+
+In the 1st form, copy SRCFILE to DSTFILE.
+In the 2nd and 3rd, copy all SRCFILES to DIRECTORY.
+In the 4th, create DIRECTORIES.
+
+Options:
+-c (ignored)
+-d create directories instead of installing files.
+-g GROUP $chgrpprog installed files to GROUP.
+-m MODE $chmodprog installed files to MODE.
+-o USER $chownprog installed files to USER.
+-s $stripprog installed files.
+-t DIRECTORY install into DIRECTORY.
+-T report an error if DSTFILE is a directory.
+--help display this help and exit.
+--version display version info and exit.
+
+Environment variables override the default commands:
+ CHGRPPROG CHMODPROG CHOWNPROG CPPROG MKDIRPROG MVPROG RMPROG STRIPPROG
+"
+
+while test -n "$1"; do
+ case $1 in
+ -c) shift
+ continue;;
+
+ -d) dir_arg=true
+ shift
+ continue;;
+
+ -g) chgrpcmd="$chgrpprog $2"
+ shift
+ shift
+ continue;;
+
+ --help) echo "$usage"; exit $?;;
+
+ -m) chmodcmd="$chmodprog $2"
+ shift
+ shift
+ continue;;
+
+ -o) chowncmd="$chownprog $2"
+ shift
+ shift
+ continue;;
+
+ -s) stripcmd=$stripprog
+ shift
+ continue;;
+
+ -t) dstarg=$2
shift
+ shift
+ continue;;
- if [ ! -d "${pathcomp}" ] ;
- then
- $mkdirprog "${pathcomp}"
- else
- true
- fi
-
- pathcomp="${pathcomp}/"
+ -T) no_target_directory=true
+ shift
+ continue;;
+
+ --version) echo "$0 $scriptversion"; exit $?;;
+
+ *) # When -d is used, all remaining arguments are directories to create.
+ # When -t is used, the destination is already specified.
+ test -n "$dir_arg$dstarg" && break
+ # Otherwise, the last argument is the destination. Remove it from $@.
+ for arg
+ do
+ if test -n "$dstarg"; then
+ # $@ is not empty: it contains at least $arg.
+ set fnord "$@" "$dstarg"
+ shift # fnord
+ fi
+ shift # arg
+ dstarg=$arg
+ done
+ break;;
+ esac
done
-fi
-
-if [ x"$dir_arg" != x ]
-then
- $doit $instcmd $dst &&
-
- if [ x"$chowncmd" != x ]; then $doit $chowncmd $dst; else true ; fi &&
- if [ x"$chgrpcmd" != x ]; then $doit $chgrpcmd $dst; else true ; fi &&
- if [ x"$stripcmd" != x ]; then $doit $stripcmd $dst; else true ; fi &&
- if [ x"$chmodcmd" != x ]; then $doit $chmodcmd $dst; else true ; fi
-else
-
-# If we're going to rename the final executable, determine the name now.
-
- if [ x"$transformarg" = x ]
- then
- dstfile=`basename $dst`
- else
- dstfile=`basename $dst $transformbasename |
- sed $transformarg`$transformbasename
- fi
-
-# don't allow the sed command to completely eliminate the filename
-
- if [ x"$dstfile" = x ]
- then
- dstfile=`basename $dst`
- else
- true
- fi
-
-# Make a temp file name in the proper directory.
-
- dsttmp=$dstdir/#inst.$$#
-# Move or copy the file name to the temp name
-
- $doit $instcmd $src $dsttmp &&
-
- trap "rm -f ${dsttmp}" 0 &&
-
-# and set any options; do chmod last to preserve setuid bits
-
-# If any of these fail, we abort the whole thing. If we want to
-# ignore errors from any of these, just make sure not to ignore
-# errors from the above "$doit $instcmd $src $dsttmp" command.
-
- if [ x"$chowncmd" != x ]; then $doit $chowncmd $dsttmp; else true;fi &&
- if [ x"$chgrpcmd" != x ]; then $doit $chgrpcmd $dsttmp; else true;fi &&
- if [ x"$stripcmd" != x ]; then $doit $stripcmd $dsttmp; else true;fi &&
- if [ x"$chmodcmd" != x ]; then $doit $chmodcmd $dsttmp; else true;fi &&
-
-# Now rename the file to the real destination.
-
- $doit $rmcmd -f $dstdir/$dstfile &&
- $doit $mvcmd $dsttmp $dstdir/$dstfile
+if test -z "$1"; then
+ if test -z "$dir_arg"; then
+ echo "$0: no input file specified." >&2
+ exit 1
+ fi
+ # It's OK to call `install-sh -d' without argument.
+ # This can happen when creating conditional directories.
+ exit 0
+fi
-fi &&
+for src
+do
+ # Protect names starting with `-'.
+ case $src in
+ -*) src=./$src ;;
+ esac
+
+ if test -n "$dir_arg"; then
+ dst=$src
+ src=
+
+ if test -d "$dst"; then
+ mkdircmd=:
+ chmodcmd=
+ else
+ mkdircmd=$mkdirprog
+ fi
+ else
+ # Waiting for this to be detected by the "$cpprog $src $dsttmp" command
+ # might cause directories to be created, which would be especially bad
+ # if $src (and thus $dsttmp) contains '*'.
+ if test ! -f "$src" && test ! -d "$src"; then
+ echo "$0: $src does not exist." >&2
+ exit 1
+ fi
+
+ if test -z "$dstarg"; then
+ echo "$0: no destination specified." >&2
+ exit 1
+ fi
+
+ dst=$dstarg
+ # Protect names starting with `-'.
+ case $dst in
+ -*) dst=./$dst ;;
+ esac
+ # If destination is a directory, append the input filename; won't work
+ # if double slashes aren't ignored.
+ if test -d "$dst"; then
+ if test -n "$no_target_directory"; then
+ echo "$0: $dstarg: Is a directory" >&2
+ exit 1
+ fi
+ dst=$dst/`basename "$src"`
+ fi
+ fi
+
+ # This sed command emulates the dirname command.
+ dstdir=`echo "$dst" | sed -e 's,/*$,,;s,[^/]*$,,;s,/*$,,;s,^$,.,'`
+
+ # Make sure that the destination directory exists.
+
+ # Skip lots of stat calls in the usual case.
+ if test ! -d "$dstdir"; then
+ defaultIFS='
+ '
+ IFS="${IFS-$defaultIFS}"
+
+ oIFS=$IFS
+ # Some sh's can't handle IFS=/ for some reason.
+ IFS='%'
+ set x `echo "$dstdir" | sed -e 's@/@%@g' -e 's@^%@/@'`
+ shift
+ IFS=$oIFS
+
+ pathcomp=
+
+ while test $# -ne 0 ; do
+ pathcomp=$pathcomp$1
+ shift
+ if test ! -d "$pathcomp"; then
+ $mkdirprog "$pathcomp"
+ # mkdir can fail with a `File exist' error in case several
+ # install-sh are creating the directory concurrently. This
+ # is OK.
+ test -d "$pathcomp" || exit
+ fi
+ pathcomp=$pathcomp/
+ done
+ fi
+
+ if test -n "$dir_arg"; then
+ $doit $mkdircmd "$dst" \
+ && { test -z "$chowncmd" || $doit $chowncmd "$dst"; } \
+ && { test -z "$chgrpcmd" || $doit $chgrpcmd "$dst"; } \
+ && { test -z "$stripcmd" || $doit $stripcmd "$dst"; } \
+ && { test -z "$chmodcmd" || $doit $chmodcmd "$dst"; }
+
+ else
+ dstfile=`basename "$dst"`
+
+ # Make a couple of temp file names in the proper directory.
+ dsttmp=$dstdir/_inst.$$_
+ rmtmp=$dstdir/_rm.$$_
+
+ # Trap to clean up those temp files at exit.
+ trap 'ret=$?; rm -f "$dsttmp" "$rmtmp" && exit $ret' 0
+ trap '(exit $?); exit' 1 2 13 15
+
+ # Copy the file name to the temp name.
+ $doit $cpprog "$src" "$dsttmp" &&
+
+ # and set any options; do chmod last to preserve setuid bits.
+ #
+ # If any of these fail, we abort the whole thing. If we want to
+ # ignore errors from any of these, just make sure not to ignore
+ # errors from the above "$doit $cpprog $src $dsttmp" command.
+ #
+ { test -z "$chowncmd" || $doit $chowncmd "$dsttmp"; } \
+ && { test -z "$chgrpcmd" || $doit $chgrpcmd "$dsttmp"; } \
+ && { test -z "$stripcmd" || $doit $stripcmd "$dsttmp"; } \
+ && { test -z "$chmodcmd" || $doit $chmodcmd "$dsttmp"; } &&
+
+ # Now rename the file to the real destination.
+ { $doit $mvcmd -f "$dsttmp" "$dstdir/$dstfile" 2>/dev/null \
+ || {
+ # The rename failed, perhaps because mv can't rename something else
+ # to itself, or perhaps because mv is so ancient that it does not
+ # support -f.
+
+ # Now remove or move aside any old file at destination location.
+ # We try this two ways since rm can't unlink itself on some
+ # systems and the destination file might be busy for other
+ # reasons. In this case, the final cleanup might fail but the new
+ # file should still install successfully.
+ {
+ if test -f "$dstdir/$dstfile"; then
+ $doit $rmcmd -f "$dstdir/$dstfile" 2>/dev/null \
+ || $doit $mvcmd -f "$dstdir/$dstfile" "$rmtmp" 2>/dev/null \
+ || {
+ echo "$0: cannot unlink or rename $dstdir/$dstfile" >&2
+ (exit 1); exit 1
+ }
+ else
+ :
+ fi
+ } &&
+
+ # Now rename the file to the real destination.
+ $doit $mvcmd "$dsttmp" "$dstdir/$dstfile"
+ }
+ }
+ fi || { (exit 1); exit 1; }
+done
-exit 0
+# The final little trick to "correctly" pass the exit status to the exit trap.
+{
+ (exit 0); exit 0
+}
+
+# Local variables:
+# eval: (add-hook 'write-file-hooks 'time-stamp)
+# time-stamp-start: "scriptversion="
+# time-stamp-format: "%:y-%02m-%02d.%02H"
+# time-stamp-end: "$"
+# End:
diff --git a/contrib/ldapc++/ltmain.sh b/contrib/ldapc++/ltmain.sh
index eecedf23e43e65471b04172b7b9e74850db37891..06823e057a578f95dabd0f233875dcf0553173c7 100644
--- a/contrib/ldapc++/ltmain.sh
+++ b/contrib/ldapc++/ltmain.sh
@@ -43,8 +43,8 @@ EXIT_FAILURE=1
PROGRAM=ltmain.sh
PACKAGE=libtool
-VERSION=1.5.18
-TIMESTAMP=" (1.1220.2.245 2005/05/16 08:55:27)"
+VERSION=1.5.22
+TIMESTAMP=" (1.1220.2.365 2005/12/18 22:14:06)"
# See if we are running on zsh, and set the options which allow our
# commands through without removal of \ escapes.
@@ -88,14 +88,15 @@ rm="rm -f"
Xsed="${SED}"' -e 1s/^X//'
sed_quote_subst='s/\([\\`\\"$\\\\]\)/\\\1/g'
# test EBCDIC or ASCII
-case `echo A|tr A '\301'` in
- A) # EBCDIC based system
- SP2NL="tr '\100' '\n'"
- NL2SP="tr '\r\n' '\100\100'"
+case `echo X|tr X '\101'` in
+ A) # ASCII based system
+ # \n is not interpreted correctly by Solaris 8 /usr/ucb/tr
+ SP2NL='tr \040 \012'
+ NL2SP='tr \015\012 \040\040'
;;
- *) # Assume ASCII based system
- SP2NL="tr '\040' '\012'"
- NL2SP="tr '\015\012' '\040\040'"
+ *) # EBCDIC based system
+ SP2NL='tr \100 \n'
+ NL2SP='tr \r\n \100\100'
;;
esac
@@ -131,14 +132,52 @@ run=
show="$echo"
show_help=
execute_dlfiles=
+duplicate_deps=no
+preserve_args=
lo2o="s/\\.lo\$/.${objext}/"
o2lo="s/\\.${objext}\$/.lo/"
-quote_scanset='[[~#^*{};<>?'"'"' ]'
#####################################
# Shell function definitions:
# This seems to be the best place for them
+# func_mktempdir [string]
+# Make a temporary directory that won't clash with other running
+# libtool processes, and avoids race conditions if possible. If
+# given, STRING is the basename for that directory.
+func_mktempdir ()
+{
+ my_template="${TMPDIR-/tmp}/${1-$progname}"
+
+ if test "$run" = ":"; then
+ # Return a directory name, but don't create it in dry-run mode
+ my_tmpdir="${my_template}-$$"
+ else
+
+ # If mktemp works, use that first and foremost
+ my_tmpdir=`mktemp -d "${my_template}-XXXXXXXX" 2>/dev/null`
+
+ if test ! -d "$my_tmpdir"; then
+ # Failing that, at least try and use $RANDOM to avoid a race
+ my_tmpdir="${my_template}-${RANDOM-0}$$"
+
+ save_mktempdir_umask=`umask`
+ umask 0077
+ $mkdir "$my_tmpdir"
+ umask $save_mktempdir_umask
+ fi
+
+ # If we're not in dry-run mode, bomb out on failure
+ test -d "$my_tmpdir" || {
+ $echo "cannot create temporary directory \`$my_tmpdir'" 1>&2
+ exit $EXIT_FAILURE
+ }
+ fi
+
+ $echo "X$my_tmpdir" | $Xsed
+}
+
+
# func_win32_libid arg
# return the library type of file 'arg'
#
@@ -157,12 +196,11 @@ func_win32_libid ()
if eval $OBJDUMP -f $1 | $SED -e '10q' 2>/dev/null | \
$EGREP -e 'file format pe-i386(.*architecture: i386)?' >/dev/null ; then
win32_nmres=`eval $NM -f posix -A $1 | \
- sed -n -e '1,100{/ I /{x;/import/!{s/^/import/;h;p;};x;};}'`
- if test "X$win32_nmres" = "Ximport" ; then
- win32_libid_type="x86 archive import"
- else
- win32_libid_type="x86 archive static"
- fi
+ $SED -n -e '1,100{/ I /{s,.*,import,;p;q;};}'`
+ case $win32_nmres in
+ import*) win32_libid_type="x86 archive import";;
+ *) win32_libid_type="x86 archive static";;
+ esac
fi
;;
*DLL*)
@@ -192,7 +230,7 @@ func_infer_tag ()
CC_quoted=
for arg in $CC; do
case $arg in
- *$quote_scanset* | *]* | *\|* | *\&* | *\(* | *\)* | "")
+ *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \ ]*|*]*|"")
arg="\"$arg\""
;;
esac
@@ -213,7 +251,7 @@ func_infer_tag ()
for arg in $CC; do
# Double-quote args containing other shell metacharacters.
case $arg in
- *$quote_scanset* | *]* | *\|* | *\&* | *\(* | *\)* | "")
+ *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \ ]*|*]*|"")
arg="\"$arg\""
;;
esac
@@ -295,9 +333,9 @@ func_extract_archives ()
$run ${rm}r "$my_xdir"
$show "$mkdir $my_xdir"
$run $mkdir "$my_xdir"
- status=$?
- if test "$status" -ne 0 && test ! -d "$my_xdir"; then
- exit $status
+ exit_status=$?
+ if test "$exit_status" -ne 0 && test ! -d "$my_xdir"; then
+ exit $exit_status
fi
case $host in
*-darwin*)
@@ -337,7 +375,7 @@ func_extract_archives ()
func_extract_an_archive "$my_xdir" "$my_xabs"
fi # $darwin_arches
fi # $run
- ;;
+ ;;
*)
func_extract_an_archive "$my_xdir" "$my_xabs"
;;
@@ -352,6 +390,8 @@ func_extract_archives ()
# Darwin sucks
eval std_shrext=\"$shrext_cmds\"
+disable_libs=no
+
# Parse our command line options once, thoroughly.
while test "$#" -gt 0
do
@@ -468,7 +508,11 @@ do
preserve_args="$preserve_args $arg"
;;
- --tag) prevopt="--tag" prev=tag ;;
+ --tag)
+ prevopt="--tag"
+ prev=tag
+ preserve_args="$preserve_args --tag"
+ ;;
--tag=*)
set tag "$optarg" ${1+"$@"}
shift
@@ -500,6 +544,18 @@ if test -n "$prevopt"; then
exit $EXIT_FAILURE
fi
+case $disable_libs in
+no)
+ ;;
+shared)
+ build_libtool_libs=no
+ build_old_libs=yes
+ ;;
+static)
+ build_old_libs=`case $build_libtool_libs in yes) echo no;; *) echo yes;; esac`
+ ;;
+esac
+
# If this variable is set in any of the actions, the command in it
# will be execed at the end. This prevents here-documents from being
# left over by shells.
@@ -576,7 +632,7 @@ if test -z "$show_help"; then
for arg
do
- case "$arg_mode" in
+ case $arg_mode in
arg )
# do not "continue". Instead, add this to base_compile
lastarg="$arg"
@@ -627,7 +683,7 @@ if test -z "$show_help"; then
# Many Bourne shells cannot handle close brackets correctly
# in scan sets, so we specify it separately.
case $arg in
- *$quote_scanset* | *]* | *\|* | *\&* | *\(* | *\)* | "")
+ *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \ ]*|*]*|"")
arg="\"$arg\""
;;
esac
@@ -662,7 +718,7 @@ if test -z "$show_help"; then
# in scan sets (worked around with variable expansion),
# and furthermore cannot handle '|' '&' '(' ')' in scan sets
# at all, so we specify them separately.
- *$quote_scanset* | *]* | *\|* | *\&* | *\(* | *\)* | "")
+ *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \ ]*|*]*|"")
lastarg="\"$lastarg\""
;;
esac
@@ -737,13 +793,12 @@ if test -z "$show_help"; then
qlibobj=`$echo "X$libobj" | $Xsed -e "$sed_quote_subst"`
case $qlibobj in
- *$quote_scanset* | *]* | *\|* | *\&* | *\(* | *\)* | "")
+ *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \ ]*|*]*|"")
qlibobj="\"$qlibobj\"" ;;
esac
- if test "X$libobj" != "X$qlibobj"; then
- $echo "$modename: libobj name \`$libobj' may not contain shell special characters."
- exit $EXIT_FAILURE
- fi
+ test "X$libobj" != "X$qlibobj" \
+ && $echo "X$libobj" | grep '[]~#^*{};<>?"'"'"' &()|`$[]' \
+ && $echo "$modename: libobj name \`$libobj' may not contain shell special characters."
objname=`$echo "X$obj" | $Xsed -e 's%^.*/%%'`
xdir=`$echo "X$obj" | $Xsed -e 's%/[^/]*$%%'`
if test "X$xdir" = "X$obj"; then
@@ -824,7 +879,7 @@ compiler."
fi
qsrcfile=`$echo "X$srcfile" | $Xsed -e "$sed_quote_subst"`
case $qsrcfile in
- *$quote_scanset* | *]* | *\|* | *\&* | *\(* | *\)* | "")
+ *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \ ]*|*]*|"")
qsrcfile="\"$qsrcfile\"" ;;
esac
@@ -857,9 +912,9 @@ EOF
if test ! -d "${xdir}$objdir"; then
$show "$mkdir ${xdir}$objdir"
$run $mkdir ${xdir}$objdir
- status=$?
- if test "$status" -ne 0 && test ! -d "${xdir}$objdir"; then
- exit $status
+ exit_status=$?
+ if test "$exit_status" -ne 0 && test ! -d "${xdir}$objdir"; then
+ exit $exit_status
fi
fi
@@ -1062,6 +1117,7 @@ EOF
no_install=no
objs=
non_pic_objects=
+ notinst_path= # paths that contain not-installed libtool libraries
precious_files_regex=
prefer_static_libs=no
preload=no
@@ -1090,14 +1146,15 @@ EOF
if test -n "$link_static_flag"; then
dlopen_self=$dlopen_self_static
fi
+ prefer_static_libs=yes
else
if test -z "$pic_flag" && test -n "$link_static_flag"; then
dlopen_self=$dlopen_self_static
fi
+ prefer_static_libs=built
fi
build_libtool_libs=no
build_old_libs=yes
- prefer_static_libs=yes
break
;;
esac
@@ -1111,7 +1168,7 @@ EOF
arg="$1"
shift
case $arg in
- *$quote_scanset* | *]* | *\|* | *\&* | *\(* | *\)* | "")
+ *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \ ]*|*]*|"")
qarg=\"`$echo "X$arg" | $Xsed -e "$sed_quote_subst"`\" ### testsuite: skip nested quoting test
;;
*) qarg=$arg ;;
@@ -1272,6 +1329,11 @@ EOF
if test -z "$pic_object" || test "$pic_object" = none ; then
arg="$non_pic_object"
fi
+ else
+ # If the PIC object exists, use it instead.
+ # $xdir was prepended to $pic_object above.
+ non_pic_object="$pic_object"
+ non_pic_objects="$non_pic_objects $non_pic_object"
fi
else
# Only an error if not doing a dry-run.
@@ -1355,8 +1417,8 @@ EOF
prev=
continue
;;
- darwin_framework)
- compiler_flags="$compiler_flags $arg"
+ darwin_framework|darwin_framework_skip)
+ test "$prev" = "darwin_framework" && compiler_flags="$compiler_flags $arg"
compile_command="$compile_command $arg"
finalize_command="$finalize_command $arg"
prev=
@@ -1420,13 +1482,17 @@ EOF
continue
;;
- -framework)
- prev=darwin_framework
- compiler_flags="$compiler_flags $arg"
+ -framework|-arch|-isysroot)
+ case " $CC " in
+ *" ${arg} ${1} "* | *" ${arg} ${1} "*)
+ prev=darwin_framework_skip ;;
+ *) compiler_flags="$compiler_flags $arg"
+ prev=darwin_framework ;;
+ esac
compile_command="$compile_command $arg"
finalize_command="$finalize_command $arg"
- continue
- ;;
+ continue
+ ;;
-inst-prefix-dir)
prev=inst_prefix
@@ -1454,7 +1520,8 @@ EOF
absdir=`cd "$dir" && pwd`
if test -z "$absdir"; then
$echo "$modename: cannot determine absolute directory name of \`$dir'" 1>&2
- exit $EXIT_FAILURE
+ absdir="$dir"
+ notinst_path="$notinst_path $dir"
fi
dir="$absdir"
;;
@@ -1468,10 +1535,15 @@ EOF
esac
case $host in
*-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-os2*)
+ testbindir=`$echo "X$dir" | $Xsed -e 's*/lib$*/bin*'`
case :$dllsearchpath: in
*":$dir:"*) ;;
*) dllsearchpath="$dllsearchpath:$dir";;
esac
+ case :$dllsearchpath: in
+ *":$testbindir:"*) ;;
+ *) dllsearchpath="$dllsearchpath:$testbindir";;
+ esac
;;
esac
continue
@@ -1480,11 +1552,11 @@ EOF
-l*)
if test "X$arg" = "X-lc" || test "X$arg" = "X-lm"; then
case $host in
- *-*-cygwin* | *-*-pw32* | *-*-beos*)
+ *-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-beos*)
# These systems don't actually have a C or math library (as such)
continue
;;
- *-*-mingw* | *-*-os2*)
+ *-*-os2*)
# These systems don't actually have a C library (as such)
test "X$arg" = "X-lc" && continue
;;
@@ -1496,6 +1568,15 @@ EOF
# Rhapsody C and math libraries are in the System framework
deplibs="$deplibs -framework System"
continue
+ ;;
+ *-*-sco3.2v5* | *-*-sco5v6*)
+ # Causes problems with __ctype
+ test "X$arg" = "X-lc" && continue
+ ;;
+ *-*-sysv4.2uw2* | *-*-sysv5* | *-*-unixware* | *-*-OpenUNIX*)
+ # Compiler inserts libc in the correct place for threads to work
+ test "X$arg" = "X-lc" && continue
+ ;;
esac
elif test "X$arg" = "X-lc_r"; then
case $host in
@@ -1537,21 +1618,24 @@ EOF
# +DA*, +DD* enable 64-bit mode on the HP compiler
# -q* pass through compiler args for the IBM compiler
# -m* pass through architecture-specific compiler args for GCC
- -64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*)
+ # -m*, -t[45]*, -txscale* pass through architecture-specific
+ # compiler args for GCC
+ # -pg pass through profiling flag for GCC
+ # @file GCC response files
+ -64|-mips[0-9]|-r[0-9][0-9]*|-xarch=*|-xtarget=*|+DA*|+DD*|-q*|-m*|-pg| \
+ -t[45]*|-txscale*|@*)
# Unknown arguments in both finalize_command and compile_command need
# to be aesthetically quoted because they are evaled later.
arg=`$echo "X$arg" | $Xsed -e "$sed_quote_subst"`
case $arg in
- *$quote_scanset* | *]* | *\|* | *\&* | *\(* | *\)* | "")
+ *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \ ]*|*]*|"")
arg="\"$arg\""
;;
esac
compile_command="$compile_command $arg"
finalize_command="$finalize_command $arg"
- if test "$with_gcc" = "yes" ; then
- compiler_flags="$compiler_flags $arg"
- fi
+ compiler_flags="$compiler_flags $arg"
continue
;;
@@ -1659,7 +1743,7 @@ EOF
for flag in $args; do
IFS="$save_ifs"
case $flag in
- *$quote_scanset* | *]* | *\|* | *\&* | *\(* | *\)* | "")
+ *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \ ]*|*]*|"")
flag="\"$flag\""
;;
esac
@@ -1677,7 +1761,7 @@ EOF
for flag in $args; do
IFS="$save_ifs"
case $flag in
- *$quote_scanset* | *]* | *\|* | *\&* | *\(* | *\)* | "")
+ *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \ ]*|*]*|"")
flag="\"$flag\""
;;
esac
@@ -1710,7 +1794,7 @@ EOF
# to be aesthetically quoted because they are evaled later.
arg=`$echo "X$arg" | $Xsed -e "$sed_quote_subst"`
case $arg in
- *$quote_scanset* | *]* | *\|* | *\&* | *\(* | *\)* | "")
+ *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \ ]*|*]*|"")
arg="\"$arg\""
;;
esac
@@ -1789,6 +1873,11 @@ EOF
if test -z "$pic_object" || test "$pic_object" = none ; then
arg="$non_pic_object"
fi
+ else
+ # If the PIC object exists, use it instead.
+ # $xdir was prepended to $pic_object above.
+ non_pic_object="$pic_object"
+ non_pic_objects="$non_pic_objects $non_pic_object"
fi
else
# Only an error if not doing a dry-run.
@@ -1844,7 +1933,7 @@ EOF
# to be aesthetically quoted because they are evaled later.
arg=`$echo "X$arg" | $Xsed -e "$sed_quote_subst"`
case $arg in
- *$quote_scanset* | *]* | *\|* | *\&* | *\(* | *\)* | "")
+ *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \ ]*|*]*|"")
arg="\"$arg\""
;;
esac
@@ -1894,9 +1983,9 @@ EOF
if test ! -d "$output_objdir"; then
$show "$mkdir $output_objdir"
$run $mkdir $output_objdir
- status=$?
- if test "$status" -ne 0 && test ! -d "$output_objdir"; then
- exit $status
+ exit_status=$?
+ if test "$exit_status" -ne 0 && test ! -d "$output_objdir"; then
+ exit $exit_status
fi
fi
@@ -1959,7 +2048,6 @@ EOF
newlib_search_path=
need_relink=no # whether we're linking any uninstalled libtool libraries
notinst_deplibs= # not-installed libtool libraries
- notinst_path= # paths that contain not-installed libtool libraries
case $linkmode in
lib)
passes="conv link"
@@ -2195,7 +2283,7 @@ EOF
esac # case $deplib
if test "$found" = yes || test -f "$lib"; then :
else
- $echo "$modename: cannot find the library \`$lib'" 1>&2
+ $echo "$modename: cannot find the library \`$lib' or unhandled argument \`$deplib'" 1>&2
exit $EXIT_FAILURE
fi
@@ -2409,7 +2497,7 @@ EOF
case "$temp_rpath " in
*" $dir "*) ;;
*" $absdir "*) ;;
- *) temp_rpath="$temp_rpath $dir" ;;
+ *) temp_rpath="$temp_rpath $absdir" ;;
esac
fi
@@ -2446,8 +2534,12 @@ EOF
fi
link_static=no # Whether the deplib will be linked statically
+ use_static_libs=$prefer_static_libs
+ if test "$use_static_libs" = built && test "$installed" = yes ; then
+ use_static_libs=no
+ fi
if test -n "$library_names" &&
- { test "$prefer_static_libs" = no || test -z "$old_library"; }; then
+ { test "$use_static_libs" = no || test -z "$old_library"; }; then
if test "$installed" = no; then
notinst_deplibs="$notinst_deplibs $lib"
need_relink=yes
@@ -2560,11 +2652,15 @@ EOF
if test "$hardcode_direct" = no; then
add="$dir/$linklib"
case $host in
- *-*-sco3.2v5* ) add_dir="-L$dir" ;;
+ *-*-sco3.2v5.0.[024]*) add_dir="-L$dir" ;;
+ *-*-sysv4*uw2*) add_dir="-L$dir" ;;
+ *-*-sysv5OpenUNIX* | *-*-sysv5UnixWare7.[01].[10]* | \
+ *-*-unixware7*) add_dir="-L$dir" ;;
*-*-darwin* )
# if the lib is a module then we can not link against
# it, someone is ignoring the new warnings I added
- if /usr/bin/file -L $add 2> /dev/null | $EGREP "bundle" >/dev/null ; then
+ if /usr/bin/file -L $add 2> /dev/null |
+ $EGREP ": [^:]* bundle" >/dev/null ; then
$echo "** Warning, lib $linklib is a module, not a shared library"
if test -z "$old_library" ; then
$echo
@@ -2595,7 +2691,7 @@ EOF
add_dir="-L$dir"
# Try looking first in the location we're being installed to.
if test -n "$inst_prefix_dir"; then
- case "$libdir" in
+ case $libdir in
[\\/]*)
add_dir="$add_dir -L$inst_prefix_dir$libdir"
;;
@@ -2668,7 +2764,7 @@ EOF
add_dir="-L$libdir"
# Try looking first in the location we're being installed to.
if test -n "$inst_prefix_dir"; then
- case "$libdir" in
+ case $libdir in
[\\/]*)
add_dir="$add_dir -L$inst_prefix_dir$libdir"
;;
@@ -2729,8 +2825,6 @@ EOF
fi
fi
else
- convenience="$convenience $dir/$old_library"
- old_convenience="$old_convenience $dir/$old_library"
deplibs="$dir/$old_library $deplibs"
link_static=yes
fi
@@ -3317,9 +3411,9 @@ EOF
# Eliminate all temporary directories.
for path in $notinst_path; do
- lib_search_path=`$echo "$lib_search_path " | ${SED} -e 's% $path % %g'`
- deplibs=`$echo "$deplibs " | ${SED} -e 's% -L$path % %g'`
- dependency_libs=`$echo "$dependency_libs " | ${SED} -e 's% -L$path % %g'`
+ lib_search_path=`$echo "$lib_search_path " | ${SED} -e "s% $path % %g"`
+ deplibs=`$echo "$deplibs " | ${SED} -e "s% -L$path % %g"`
+ dependency_libs=`$echo "$dependency_libs " | ${SED} -e "s% -L$path % %g"`
done
if test -n "$xrpath"; then
@@ -3372,7 +3466,12 @@ EOF
;;
*-*-openbsd* | *-*-freebsd* | *-*-dragonfly*)
# Do not include libc due to us having libc/libc_r.
- test "X$arg" = "X-lc" && continue
+ ;;
+ *-*-sco3.2v5* | *-*-sco5v6*)
+ # Causes problems with __ctype
+ ;;
+ *-*-sysv4.2uw2* | *-*-sysv5* | *-*-unixware* | *-*-OpenUNIX*)
+ # Compiler inserts libc in the correct place for threads to work
;;
*)
# Add libc to deplibs on all other systems if necessary.
@@ -3416,11 +3515,11 @@ EOF
int main() { return 0; }
EOF
$rm conftest
- $LTCC -o conftest conftest.c $deplibs
+ $LTCC $LTCFLAGS -o conftest conftest.c $deplibs
if test "$?" -eq 0 ; then
ldd_output=`ldd conftest`
for i in $deplibs; do
- name="`expr $i : '-l\(.*\)'`"
+ name=`expr $i : '-l\(.*\)'`
# If $name is empty we are operating on a -L argument.
if test "$name" != "" && test "$name" -ne "0"; then
if test "X$allow_libtool_libs_with_static_runtimes" = "Xyes" ; then
@@ -3457,11 +3556,11 @@ EOF
# Error occurred in the first compile. Let's try to salvage
# the situation: Compile a separate program for each library.
for i in $deplibs; do
- name="`expr $i : '-l\(.*\)'`"
+ name=`expr $i : '-l\(.*\)'`
# If $name is empty we are operating on a -L argument.
if test "$name" != "" && test "$name" != "0"; then
$rm conftest
- $LTCC -o conftest conftest.c $i
+ $LTCC $LTCFLAGS -o conftest conftest.c $i
# Did it work?
if test "$?" -eq 0 ; then
ldd_output=`ldd conftest`
@@ -3509,7 +3608,7 @@ EOF
set dummy $deplibs_check_method
file_magic_regex=`expr "$deplibs_check_method" : "$2 \(.*\)"`
for a_deplib in $deplibs; do
- name="`expr $a_deplib : '-l\(.*\)'`"
+ name=`expr $a_deplib : '-l\(.*\)'`
# If $name is empty we are operating on a -L argument.
if test "$name" != "" && test "$name" != "0"; then
if test "X$allow_libtool_libs_with_static_runtimes" = "Xyes" ; then
@@ -3578,7 +3677,7 @@ EOF
set dummy $deplibs_check_method
match_pattern_regex=`expr "$deplibs_check_method" : "$2 \(.*\)"`
for a_deplib in $deplibs; do
- name="`expr $a_deplib : '-l\(.*\)'`"
+ name=`expr $a_deplib : '-l\(.*\)'`
# If $name is empty we are operating on a -L argument.
if test -n "$name" && test "$name" != "0"; then
if test "X$allow_libtool_libs_with_static_runtimes" = "Xyes" ; then
@@ -3708,6 +3807,35 @@ EOF
deplibs=$newdeplibs
fi
+
+ # move library search paths that coincide with paths to not yet
+ # installed libraries to the beginning of the library search list
+ new_libs=
+ for path in $notinst_path; do
+ case " $new_libs " in
+ *" -L$path/$objdir "*) ;;
+ *)
+ case " $deplibs " in
+ *" -L$path/$objdir "*)
+ new_libs="$new_libs -L$path/$objdir" ;;
+ esac
+ ;;
+ esac
+ done
+ for deplib in $deplibs; do
+ case $deplib in
+ -L*)
+ case " $new_libs " in
+ *" $deplib "*) ;;
+ *) new_libs="$new_libs $deplib" ;;
+ esac
+ ;;
+ *) new_libs="$new_libs $deplib" ;;
+ esac
+ done
+ deplibs="$new_libs"
+
+
# All the library-specific variables (install_libdir is set above).
library_names=
old_library=
@@ -3791,6 +3919,7 @@ EOF
fi
lib="$output_objdir/$realname"
+ linknames=
for link
do
linknames="$linknames $link"
@@ -3819,6 +3948,9 @@ EOF
# The command line is too long to execute in one step.
$show "using reloadable object file for export list..."
skipped_export=:
+ # Break out early, otherwise skipped_export may be
+ # set to false by a later but shorter cmd.
+ break
fi
done
IFS="$save_ifs"
@@ -3888,7 +4020,8 @@ EOF
fi
fi
- if test "X$skipped_export" != "X:" && len=`expr "X$test_cmds" : ".*"` &&
+ if test "X$skipped_export" != "X:" &&
+ len=`expr "X$test_cmds" : ".*" 2>/dev/null` &&
test "$len" -le "$max_cmd_len" || test "$max_cmd_len" -le -1; then
:
else
@@ -3923,7 +4056,7 @@ EOF
do
eval test_cmds=\"$reload_cmds $objlist $last_robj\"
if test "X$objlist" = X ||
- { len=`expr "X$test_cmds" : ".*"` &&
+ { len=`expr "X$test_cmds" : ".*" 2>/dev/null` &&
test "$len" -le "$max_cmd_len"; }; then
objlist="$objlist $obj"
else
@@ -4013,13 +4146,30 @@ EOF
IFS="$save_ifs"
eval cmd=\"$cmd\"
$show "$cmd"
- $run eval "$cmd" || exit $?
+ $run eval "$cmd" || {
+ lt_exit=$?
+
+ # Restore the uninstalled library and exit
+ if test "$mode" = relink; then
+ $run eval '(cd $output_objdir && $rm ${realname}T && $mv ${realname}U $realname)'
+ fi
+
+ exit $lt_exit
+ }
done
IFS="$save_ifs"
# Restore the uninstalled library and exit
if test "$mode" = relink; then
$run eval '(cd $output_objdir && $rm ${realname}T && $mv $realname ${realname}T && $mv "$realname"U $realname)' || exit $?
+
+ if test -n "$convenience"; then
+ if test -z "$whole_archive_flag_spec"; then
+ $show "${rm}r $gentop"
+ $run ${rm}r "$gentop"
+ fi
+ fi
+
exit $EXIT_SUCCESS
fi
@@ -4201,6 +4351,35 @@ EOF
;;
esac
+
+ # move library search paths that coincide with paths to not yet
+ # installed libraries to the beginning of the library search list
+ new_libs=
+ for path in $notinst_path; do
+ case " $new_libs " in
+ *" -L$path/$objdir "*) ;;
+ *)
+ case " $compile_deplibs " in
+ *" -L$path/$objdir "*)
+ new_libs="$new_libs -L$path/$objdir" ;;
+ esac
+ ;;
+ esac
+ done
+ for deplib in $compile_deplibs; do
+ case $deplib in
+ -L*)
+ case " $new_libs " in
+ *" $deplib "*) ;;
+ *) new_libs="$new_libs $deplib" ;;
+ esac
+ ;;
+ *) new_libs="$new_libs $deplib" ;;
+ esac
+ done
+ compile_deplibs="$new_libs"
+
+
compile_command="$compile_command $compile_deplibs"
finalize_command="$finalize_command $finalize_deplibs"
@@ -4245,10 +4424,15 @@ EOF
fi
case $host in
*-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-os2*)
+ testbindir=`$echo "X$libdir" | $Xsed -e 's*/lib$*/bin*'`
case :$dllsearchpath: in
*":$libdir:"*) ;;
*) dllsearchpath="$dllsearchpath:$libdir";;
esac
+ case :$dllsearchpath: in
+ *":$testbindir:"*) ;;
+ *) dllsearchpath="$dllsearchpath:$testbindir";;
+ esac
;;
esac
done
@@ -4364,11 +4548,23 @@ extern \"C\" {
if test -z "$export_symbols"; then
export_symbols="$output_objdir/$outputname.exp"
$run $rm $export_symbols
- $run eval "${SED} -n -e '/^: @PROGRAM@$/d' -e 's/^.* \(.*\)$/\1/p' "'< "$nlist" > "$export_symbols"'
+ $run eval "${SED} -n -e '/^: @PROGRAM@ $/d' -e 's/^.* \(.*\)$/\1/p' "'< "$nlist" > "$export_symbols"'
+ case $host in
+ *cygwin* | *mingw* )
+ $run eval "echo EXPORTS "'> "$output_objdir/$outputname.def"'
+ $run eval 'cat "$export_symbols" >> "$output_objdir/$outputname.def"'
+ ;;
+ esac
else
- $run eval "${SED} -e 's/\([ ][.*^$]\)/\\\1/g' -e 's/^/ /' -e 's/$/$/'"' < "$export_symbols" > "$output_objdir/$outputname.exp"'
+ $run eval "${SED} -e 's/\([].[*^$]\)/\\\\\1/g' -e 's/^/ /' -e 's/$/$/'"' < "$export_symbols" > "$output_objdir/$outputname.exp"'
$run eval 'grep -f "$output_objdir/$outputname.exp" < "$nlist" > "$nlist"T'
$run eval 'mv "$nlist"T "$nlist"'
+ case $host in
+ *cygwin* | *mingw* )
+ $run eval "echo EXPORTS "'> "$output_objdir/$outputname.def"'
+ $run eval 'cat "$nlist" >> "$output_objdir/$outputname.def"'
+ ;;
+ esac
fi
fi
@@ -4485,16 +4681,29 @@ static const void *lt_preloaded_setup() {
esac
# Now compile the dynamic symbol file.
- $show "(cd $output_objdir && $LTCC -c$no_builtin_flag$pic_flag_for_symtable \"$dlsyms\")"
- $run eval '(cd $output_objdir && $LTCC -c$no_builtin_flag$pic_flag_for_symtable "$dlsyms")' || exit $?
+ $show "(cd $output_objdir && $LTCC $LTCFLAGS -c$no_builtin_flag$pic_flag_for_symtable \"$dlsyms\")"
+ $run eval '(cd $output_objdir && $LTCC $LTCFLAGS -c$no_builtin_flag$pic_flag_for_symtable "$dlsyms")' || exit $?
# Clean up the generated files.
$show "$rm $output_objdir/$dlsyms $nlist ${nlist}S ${nlist}T"
$run $rm "$output_objdir/$dlsyms" "$nlist" "${nlist}S" "${nlist}T"
# Transform the symbol file into the correct name.
- compile_command=`$echo "X$compile_command" | $Xsed -e "s%@SYMFILE@%$output_objdir/${outputname}S.${objext}%"`
- finalize_command=`$echo "X$finalize_command" | $Xsed -e "s%@SYMFILE@%$output_objdir/${outputname}S.${objext}%"`
+ case $host in
+ *cygwin* | *mingw* )
+ if test -f "$output_objdir/${outputname}.def" ; then
+ compile_command=`$echo "X$compile_command" | $Xsed -e "s%@SYMFILE@%$output_objdir/${outputname}.def $output_objdir/${outputname}S.${objext}%"`
+ finalize_command=`$echo "X$finalize_command" | $Xsed -e "s%@SYMFILE@%$output_objdir/${outputname}.def $output_objdir/${outputname}S.${objext}%"`
+ else
+ compile_command=`$echo "X$compile_command" | $Xsed -e "s%@SYMFILE@%$output_objdir/${outputname}S.${objext}%"`
+ finalize_command=`$echo "X$finalize_command" | $Xsed -e "s%@SYMFILE@%$output_objdir/${outputname}S.${objext}%"`
+ fi
+ ;;
+ * )
+ compile_command=`$echo "X$compile_command" | $Xsed -e "s%@SYMFILE@%$output_objdir/${outputname}S.${objext}%"`
+ finalize_command=`$echo "X$finalize_command" | $Xsed -e "s%@SYMFILE@%$output_objdir/${outputname}S.${objext}%"`
+ ;;
+ esac
;;
*)
$echo "$modename: unknown suffix for \`$dlsyms'" 1>&2
@@ -4519,7 +4728,7 @@ static const void *lt_preloaded_setup() {
# We have no uninstalled library dependencies, so finalize right now.
$show "$link_command"
$run eval "$link_command"
- status=$?
+ exit_status=$?
# Delete the generated files.
if test -n "$dlsyms"; then
@@ -4527,7 +4736,7 @@ static const void *lt_preloaded_setup() {
$run $rm "$output_objdir/${outputname}S.${objext}"
fi
- exit $status
+ exit $exit_status
fi
if test -n "$shlibpath_var"; then
@@ -4667,10 +4876,12 @@ static const void *lt_preloaded_setup() {
esac
case $host in
*cygwin* | *mingw* )
- cwrappersource=`$echo ${objdir}/lt-${outputname}.c`
- cwrapper=`$echo ${output}.exe`
- $rm $cwrappersource $cwrapper
- trap "$rm $cwrappersource $cwrapper; exit $EXIT_FAILURE" 1 2 15
+ output_name=`basename $output`
+ output_path=`dirname $output`
+ cwrappersource="$output_path/$objdir/lt-$output_name.c"
+ cwrapper="$output_path/$output_name.exe"
+ $rm $cwrappersource $cwrapper
+ trap "$rm $cwrappersource $cwrapper; exit $EXIT_FAILURE" 1 2 15
cat > $cwrappersource <<EOF
@@ -4695,6 +4906,9 @@ EOF
#include <malloc.h>
#include <stdarg.h>
#include <assert.h>
+#include <string.h>
+#include <ctype.h>
+#include <sys/stat.h>
#if defined(PATH_MAX)
# define LT_PATHMAX PATH_MAX
@@ -4705,15 +4919,19 @@ EOF
#endif
#ifndef DIR_SEPARATOR
-#define DIR_SEPARATOR '/'
+# define DIR_SEPARATOR '/'
+# define PATH_SEPARATOR ':'
#endif
#if defined (_WIN32) || defined (__MSDOS__) || defined (__DJGPP__) || \
defined (__OS2__)
-#define HAVE_DOS_BASED_FILE_SYSTEM
-#ifndef DIR_SEPARATOR_2
-#define DIR_SEPARATOR_2 '\\'
-#endif
+# define HAVE_DOS_BASED_FILE_SYSTEM
+# ifndef DIR_SEPARATOR_2
+# define DIR_SEPARATOR_2 '\\'
+# endif
+# ifndef PATH_SEPARATOR_2
+# define PATH_SEPARATOR_2 ';'
+# endif
#endif
#ifndef DIR_SEPARATOR_2
@@ -4723,17 +4941,32 @@ EOF
(((ch) == DIR_SEPARATOR) || ((ch) == DIR_SEPARATOR_2))
#endif /* DIR_SEPARATOR_2 */
+#ifndef PATH_SEPARATOR_2
+# define IS_PATH_SEPARATOR(ch) ((ch) == PATH_SEPARATOR)
+#else /* PATH_SEPARATOR_2 */
+# define IS_PATH_SEPARATOR(ch) ((ch) == PATH_SEPARATOR_2)
+#endif /* PATH_SEPARATOR_2 */
+
#define XMALLOC(type, num) ((type *) xmalloc ((num) * sizeof(type)))
#define XFREE(stale) do { \
if (stale) { free ((void *) stale); stale = 0; } \
} while (0)
+/* -DDEBUG is fairly common in CFLAGS. */
+#undef DEBUG
+#if defined DEBUGWRAPPER
+# define DEBUG(format, ...) fprintf(stderr, format, __VA_ARGS__)
+#else
+# define DEBUG(format, ...)
+#endif
+
const char *program_name = NULL;
void * xmalloc (size_t num);
char * xstrdup (const char *string);
-char * basename (const char *name);
-char * fnqualify(const char *path);
+const char * base_name (const char *name);
+char * find_executable(const char *wrapper);
+int check_executable(const char *path);
char * strendzap(char *str, const char *pat);
void lt_fatal (const char *message, ...);
@@ -4743,29 +4976,51 @@ main (int argc, char *argv[])
char **newargz;
int i;
- program_name = (char *) xstrdup ((char *) basename (argv[0]));
+ program_name = (char *) xstrdup (base_name (argv[0]));
+ DEBUG("(main) argv[0] : %s\n",argv[0]);
+ DEBUG("(main) program_name : %s\n",program_name);
newargz = XMALLOC(char *, argc+2);
EOF
- cat >> $cwrappersource <<EOF
- newargz[0] = "$SHELL";
+ cat >> $cwrappersource <<EOF
+ newargz[0] = (char *) xstrdup("$SHELL");
EOF
- cat >> $cwrappersource <<"EOF"
- newargz[1] = fnqualify(argv[0]);
+ cat >> $cwrappersource <<"EOF"
+ newargz[1] = find_executable(argv[0]);
+ if (newargz[1] == NULL)
+ lt_fatal("Couldn't find %s", argv[0]);
+ DEBUG("(main) found exe at : %s\n",newargz[1]);
/* we know the script has the same name, without the .exe */
/* so make sure newargz[1] doesn't end in .exe */
strendzap(newargz[1],".exe");
for (i = 1; i < argc; i++)
newargz[i+1] = xstrdup(argv[i]);
newargz[argc+1] = NULL;
+
+ for (i=0; i<argc+1; i++)
+ {
+ DEBUG("(main) newargz[%d] : %s\n",i,newargz[i]);
+ ;
+ }
+
EOF
- cat >> $cwrappersource <<EOF
+ case $host_os in
+ mingw*)
+ cat >> $cwrappersource <<EOF
+ execv("$SHELL",(char const **)newargz);
+EOF
+ ;;
+ *)
+ cat >> $cwrappersource <<EOF
execv("$SHELL",newargz);
EOF
+ ;;
+ esac
- cat >> $cwrappersource <<"EOF"
+ cat >> $cwrappersource <<"EOF"
+ return 127;
}
void *
@@ -4785,48 +5040,148 @@ xstrdup (const char *string)
;
}
-char *
-basename (const char *name)
+const char *
+base_name (const char *name)
{
const char *base;
#if defined (HAVE_DOS_BASED_FILE_SYSTEM)
/* Skip over the disk name in MSDOS pathnames. */
- if (isalpha (name[0]) && name[1] == ':')
+ if (isalpha ((unsigned char)name[0]) && name[1] == ':')
name += 2;
#endif
for (base = name; *name; name++)
if (IS_DIR_SEPARATOR (*name))
base = name + 1;
- return (char *) base;
+ return base;
}
+int
+check_executable(const char * path)
+{
+ struct stat st;
+
+ DEBUG("(check_executable) : %s\n", path ? (*path ? path : "EMPTY!") : "NULL!");
+ if ((!path) || (!*path))
+ return 0;
+
+ if ((stat (path, &st) >= 0) &&
+ (
+ /* MinGW & native WIN32 do not support S_IXOTH or S_IXGRP */
+#if defined (S_IXOTH)
+ ((st.st_mode & S_IXOTH) == S_IXOTH) ||
+#endif
+#if defined (S_IXGRP)
+ ((st.st_mode & S_IXGRP) == S_IXGRP) ||
+#endif
+ ((st.st_mode & S_IXUSR) == S_IXUSR))
+ )
+ return 1;
+ else
+ return 0;
+}
+
+/* Searches for the full path of the wrapper. Returns
+ newly allocated full path name if found, NULL otherwise */
char *
-fnqualify(const char *path)
+find_executable (const char* wrapper)
{
- size_t size;
- char *p;
+ int has_slash = 0;
+ const char* p;
+ const char* p_next;
+ /* static buffer for getcwd */
char tmp[LT_PATHMAX + 1];
+ int tmp_len;
+ char* concat_name;
+
+ DEBUG("(find_executable) : %s\n", wrapper ? (*wrapper ? wrapper : "EMPTY!") : "NULL!");
- assert(path != NULL);
+ if ((wrapper == NULL) || (*wrapper == '\0'))
+ return NULL;
- /* Is it qualified already? */
+ /* Absolute path? */
+#if defined (HAVE_DOS_BASED_FILE_SYSTEM)
+ if (isalpha ((unsigned char)wrapper[0]) && wrapper[1] == ':')
+ {
+ concat_name = xstrdup (wrapper);
+ if (check_executable(concat_name))
+ return concat_name;
+ XFREE(concat_name);
+ }
+ else
+ {
+#endif
+ if (IS_DIR_SEPARATOR (wrapper[0]))
+ {
+ concat_name = xstrdup (wrapper);
+ if (check_executable(concat_name))
+ return concat_name;
+ XFREE(concat_name);
+ }
#if defined (HAVE_DOS_BASED_FILE_SYSTEM)
- if (isalpha (path[0]) && path[1] == ':')
- return xstrdup (path);
+ }
#endif
- if (IS_DIR_SEPARATOR (path[0]))
- return xstrdup (path);
- /* prepend the current directory */
- /* doesn't handle '~' */
+ for (p = wrapper; *p; p++)
+ if (*p == '/')
+ {
+ has_slash = 1;
+ break;
+ }
+ if (!has_slash)
+ {
+ /* no slashes; search PATH */
+ const char* path = getenv ("PATH");
+ if (path != NULL)
+ {
+ for (p = path; *p; p = p_next)
+ {
+ const char* q;
+ size_t p_len;
+ for (q = p; *q; q++)
+ if (IS_PATH_SEPARATOR(*q))
+ break;
+ p_len = q - p;
+ p_next = (*q == '\0' ? q : q + 1);
+ if (p_len == 0)
+ {
+ /* empty path: current directory */
+ if (getcwd (tmp, LT_PATHMAX) == NULL)
+ lt_fatal ("getcwd failed");
+ tmp_len = strlen(tmp);
+ concat_name = XMALLOC(char, tmp_len + 1 + strlen(wrapper) + 1);
+ memcpy (concat_name, tmp, tmp_len);
+ concat_name[tmp_len] = '/';
+ strcpy (concat_name + tmp_len + 1, wrapper);
+ }
+ else
+ {
+ concat_name = XMALLOC(char, p_len + 1 + strlen(wrapper) + 1);
+ memcpy (concat_name, p, p_len);
+ concat_name[p_len] = '/';
+ strcpy (concat_name + p_len + 1, wrapper);
+ }
+ if (check_executable(concat_name))
+ return concat_name;
+ XFREE(concat_name);
+ }
+ }
+ /* not found in PATH; assume curdir */
+ }
+ /* Relative path | not found in path: prepend cwd */
if (getcwd (tmp, LT_PATHMAX) == NULL)
lt_fatal ("getcwd failed");
- size = strlen(tmp) + 1 + strlen(path) + 1; /* +2 for '/' and '\0' */
- p = XMALLOC(char, size);
- sprintf(p, "%s%c%s", tmp, DIR_SEPARATOR, path);
- return p;
+ tmp_len = strlen(tmp);
+ concat_name = XMALLOC(char, tmp_len + 1 + strlen(wrapper) + 1);
+ memcpy (concat_name, tmp, tmp_len);
+ concat_name[tmp_len] = '/';
+ strcpy (concat_name + tmp_len + 1, wrapper);
+
+ if (check_executable(concat_name))
+ return concat_name;
+ XFREE(concat_name);
+ return NULL;
}
char *
@@ -4870,16 +5225,16 @@ lt_fatal (const char *message, ...)
va_end (ap);
}
EOF
- # we should really use a build-platform specific compiler
- # here, but OTOH, the wrappers (shell script and this C one)
- # are only useful if you want to execute the "real" binary.
- # Since the "real" binary is built for $host, then this
- # wrapper might as well be built for $host, too.
- $run $LTCC -s -o $cwrapper $cwrappersource
- ;;
- esac
- $rm $output
- trap "$rm $output; exit $EXIT_FAILURE" 1 2 15
+ # we should really use a build-platform specific compiler
+ # here, but OTOH, the wrappers (shell script and this C one)
+ # are only useful if you want to execute the "real" binary.
+ # Since the "real" binary is built for $host, then this
+ # wrapper might as well be built for $host, too.
+ $run $LTCC $LTCFLAGS -s -o $cwrapper $cwrappersource
+ ;;
+ esac
+ $rm $output
+ trap "$rm $output; exit $EXIT_FAILURE" 1 2 15
$echo > $output "\
#! $SHELL
@@ -5029,13 +5384,13 @@ else
# Backslashes separate directories on plain windows
*-*-mingw | *-*-os2*)
$echo >> $output "\
- exec \$progdir\\\\\$program \${1+\"\$@\"}
+ exec \"\$progdir\\\\\$program\" \${1+\"\$@\"}
"
;;
*)
$echo >> $output "\
- exec \$progdir/\$program \${1+\"\$@\"}
+ exec \"\$progdir/\$program\" \${1+\"\$@\"}
"
;;
esac
@@ -5045,7 +5400,7 @@ else
fi
else
# The program doesn't exist.
- \$echo \"\$0: error: \$progdir/\$program does not exist\" 1>&2
+ \$echo \"\$0: error: \\\`\$progdir/\$program' does not exist\" 1>&2
\$echo \"This script is just a wrapper for \$program.\" 1>&2
$echo \"See the $PACKAGE documentation for more information.\" 1>&2
exit $EXIT_FAILURE
@@ -5109,9 +5464,9 @@ fi\
$run ${rm}r "$gentop"
$show "$mkdir $gentop"
$run $mkdir "$gentop"
- status=$?
- if test "$status" -ne 0 && test ! -d "$gentop"; then
- exit $status
+ exit_status=$?
+ if test "$exit_status" -ne 0 && test ! -d "$gentop"; then
+ exit $exit_status
fi
fi
@@ -5168,7 +5523,7 @@ fi\
oldobjs="$objlist $obj"
objlist="$objlist $obj"
eval test_cmds=\"$old_archive_cmds\"
- if len=`expr "X$test_cmds" : ".*"` &&
+ if len=`expr "X$test_cmds" : ".*" 2>/dev/null` &&
test "$len" -le "$max_cmd_len"; then
:
else
@@ -5365,11 +5720,11 @@ relink_command=\"$relink_command\""
# install_prog (especially on Windows NT).
if test "$nonopt" = "$SHELL" || test "$nonopt" = /bin/sh ||
# Allow the use of GNU shtool's install command.
- $echo "X$nonopt" | $Xsed | grep shtool > /dev/null; then
+ $echo "X$nonopt" | grep shtool > /dev/null; then
# Aesthetically quote it.
arg=`$echo "X$nonopt" | $Xsed -e "$sed_quote_subst"`
case $arg in
- *$quote_scanset* | *]* | *\|* | *\&* | *\(* | *\)* | "")
+ *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \ ]*|*]*|"")
arg="\"$arg\""
;;
esac
@@ -5378,14 +5733,14 @@ relink_command=\"$relink_command\""
shift
else
install_prog=
- arg="$nonopt"
+ arg=$nonopt
fi
# The real first argument should be the name of the installation program.
# Aesthetically quote it.
arg=`$echo "X$arg" | $Xsed -e "$sed_quote_subst"`
case $arg in
- *$quote_scanset* | *]* | *\|* | *\&* | *\(* | *\)* | "")
+ *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \ ]*|*]*|"")
arg="\"$arg\""
;;
esac
@@ -5403,28 +5758,31 @@ relink_command=\"$relink_command\""
do
if test -n "$dest"; then
files="$files $dest"
- dest="$arg"
+ dest=$arg
continue
fi
case $arg in
-d) isdir=yes ;;
- -f) prev="-f" ;;
- -g) prev="-g" ;;
- -m) prev="-m" ;;
- -o) prev="-o" ;;
+ -f)
+ case " $install_prog " in
+ *[\\\ /]cp\ *) ;;
+ *) prev=$arg ;;
+ esac
+ ;;
+ -g | -m | -o) prev=$arg ;;
-s)
stripme=" -s"
continue
;;
- -*) ;;
-
+ -*)
+ ;;
*)
# If the previous option needed an argument, then skip it.
if test -n "$prev"; then
prev=
else
- dest="$arg"
+ dest=$arg
continue
fi
;;
@@ -5433,7 +5791,7 @@ relink_command=\"$relink_command\""
# Aesthetically quote the argument.
arg=`$echo "X$arg" | $Xsed -e "$sed_quote_subst"`
case $arg in
- *$quote_scanset* | *]* | *\|* | *\&* | *\(* | *\)* | "")
+ *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \ ]*|*]*|"")
arg="\"$arg\""
;;
esac
@@ -5602,11 +5960,14 @@ relink_command=\"$relink_command\""
if test "$#" -gt 0; then
# Delete the old symlinks, and create new ones.
+ # Try `ln -sf' first, because the `ln' binary might depend on
+ # the symlink we replace! Solaris /bin/ln does not understand -f,
+ # so we also need to try rm && ln -s.
for linkname
do
if test "$linkname" != "$realname"; then
- $show "(cd $destdir && $rm $linkname && $LN_S $realname $linkname)"
- $run eval "(cd $destdir && $rm $linkname && $LN_S $realname $linkname)"
+ $show "(cd $destdir && { $LN_S -f $realname $linkname || { $rm $linkname && $LN_S $realname $linkname; }; })"
+ $run eval "(cd $destdir && { $LN_S -f $realname $linkname || { $rm $linkname && $LN_S $realname $linkname; }; })"
fi
done
fi
@@ -5619,7 +5980,16 @@ relink_command=\"$relink_command\""
IFS="$save_ifs"
eval cmd=\"$cmd\"
$show "$cmd"
- $run eval "$cmd" || exit $?
+ $run eval "$cmd" || {
+ lt_exit=$?
+
+ # Restore the uninstalled library and exit
+ if test "$mode" = relink; then
+ $run eval '(cd $output_objdir && $rm ${realname}T && $mv ${realname}U $realname)'
+ fi
+
+ exit $lt_exit
+ }
done
IFS="$save_ifs"
fi
@@ -5713,17 +6083,15 @@ relink_command=\"$relink_command\""
notinst_deplibs=
relink_command=
- # To insure that "foo" is sourced, and not "foo.exe",
- # finese the cygwin/MSYS system by explicitly sourcing "foo."
- # which disallows the automatic-append-.exe behavior.
- case $build in
- *cygwin* | *mingw*) wrapperdot=${wrapper}. ;;
- *) wrapperdot=${wrapper} ;;
- esac
+ # Note that it is not necessary on cygwin/mingw to append a dot to
+ # foo even if both foo and FILE.exe exist: automatic-append-.exe
+ # behavior happens only for exec(3), not for open(2)! Also, sourcing
+ # `FILE.' does not work on cygwin managed mounts.
+ #
# If there is no directory component, then add one.
- case $file in
- */* | *\\*) . ${wrapperdot} ;;
- *) . ./${wrapperdot} ;;
+ case $wrapper in
+ */* | *\\*) . ${wrapper} ;;
+ *) . ./${wrapper} ;;
esac
# Check the variables that should have been set.
@@ -5751,34 +6119,21 @@ relink_command=\"$relink_command\""
done
relink_command=
- # To insure that "foo" is sourced, and not "foo.exe",
- # finese the cygwin/MSYS system by explicitly sourcing "foo."
- # which disallows the automatic-append-.exe behavior.
- case $build in
- *cygwin* | *mingw*) wrapperdot=${wrapper}. ;;
- *) wrapperdot=${wrapper} ;;
- esac
+ # Note that it is not necessary on cygwin/mingw to append a dot to
+ # foo even if both foo and FILE.exe exist: automatic-append-.exe
+ # behavior happens only for exec(3), not for open(2)! Also, sourcing
+ # `FILE.' does not work on cygwin managed mounts.
+ #
# If there is no directory component, then add one.
- case $file in
- */* | *\\*) . ${wrapperdot} ;;
- *) . ./${wrapperdot} ;;
+ case $wrapper in
+ */* | *\\*) . ${wrapper} ;;
+ *) . ./${wrapper} ;;
esac
outputname=
if test "$fast_install" = no && test -n "$relink_command"; then
if test "$finalize" = yes && test -z "$run"; then
- tmpdir="/tmp"
- test -n "$TMPDIR" && tmpdir="$TMPDIR"
- tmpdir="$tmpdir/libtool-$$"
- save_umask=`umask`
- umask 0077
- if $mkdir "$tmpdir"; then
- umask $save_umask
- else
- umask $save_umask
- $echo "$modename: error: cannot create temporary directory \`$tmpdir'" 1>&2
- continue
- fi
+ tmpdir=`func_mktempdir`
file=`$echo "X$file$stripped_ext" | $Xsed -e 's%^.*/%%'`
outputname="$tmpdir/$file"
# Replace the output file specification.
@@ -5802,7 +6157,7 @@ relink_command=\"$relink_command\""
fi
# remove .exe since cygwin /usr/bin/install will append another
- # one anyways
+ # one anyway
case $install_prog,$host in
*/usr/bin/install*,*cygwin*)
case $file:$destfile in
@@ -5902,7 +6257,7 @@ relink_command=\"$relink_command\""
# Exit here if they wanted silent mode.
test "$show" = : && exit $EXIT_SUCCESS
- $echo "----------------------------------------------------------------------"
+ $echo "X----------------------------------------------------------------------" | $Xsed
$echo "Libraries have been installed in:"
for libdir in $libdirs; do
$echo " $libdir"
@@ -5935,7 +6290,7 @@ relink_command=\"$relink_command\""
$echo
$echo "See any operating system documentation about shared libraries for"
$echo "more information, such as the ld(1) and ld.so(8) manual pages."
- $echo "----------------------------------------------------------------------"
+ $echo "X----------------------------------------------------------------------" | $Xsed
exit $EXIT_SUCCESS
;;
@@ -6152,9 +6507,17 @@ relink_command=\"$relink_command\""
rmfiles="$rmfiles $objdir/$n"
done
test -n "$old_library" && rmfiles="$rmfiles $objdir/$old_library"
- test "$mode" = clean && rmfiles="$rmfiles $objdir/$name $objdir/${name}i"
- if test "$mode" = uninstall; then
+ case "$mode" in
+ clean)
+ case " $library_names " in
+ # " " in the beginning catches empty $dlname
+ *" $dlname "*) ;;
+ *) rmfiles="$rmfiles $objdir/$dlname" ;;
+ esac
+ test -n "$libdir" && rmfiles="$rmfiles $objdir/$name $objdir/${name}i"
+ ;;
+ uninstall)
if test -n "$library_names"; then
# Do each command in the postuninstall commands.
cmds=$postuninstall_cmds
@@ -6187,7 +6550,8 @@ relink_command=\"$relink_command\""
IFS="$save_ifs"
fi
# FIXME: should reinstall the best remaining shared library.
- fi
+ ;;
+ esac
fi
;;
@@ -6486,12 +6850,11 @@ exit $?
# configuration. But we'll never go from static-only to shared-only.
# ### BEGIN LIBTOOL TAG CONFIG: disable-shared
-build_libtool_libs=no
-build_old_libs=yes
+disable_libs=shared
# ### END LIBTOOL TAG CONFIG: disable-shared
# ### BEGIN LIBTOOL TAG CONFIG: disable-static
-build_old_libs=`case $build_libtool_libs in yes) $echo no;; *) $echo yes;; esac`
+disable_libs=static
# ### END LIBTOOL TAG CONFIG: disable-static
# Local Variables:
diff --git a/contrib/ldapc++/missing b/contrib/ldapc++/missing
index 7789652e877fbc83c770377691249820eebea1f2..894e786e16c1d0d94dfc08d6b475270fe1418d6a 100755
--- a/contrib/ldapc++/missing
+++ b/contrib/ldapc++/missing
@@ -1,7 +1,11 @@
#! /bin/sh
# Common stub for a few missing GNU programs while installing.
-# Copyright (C) 1996, 1997 Free Software Foundation, Inc.
-# Franc,ois Pinard <pinard@iro.umontreal.ca>, 1996.
+
+scriptversion=2005-06-08.21
+
+# Copyright (C) 1996, 1997, 1999, 2000, 2002, 2003, 2004, 2005
+# Free Software Foundation, Inc.
+# Originally by Fran,cois Pinard <pinard@iro.umontreal.ca>, 1996.
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@@ -15,15 +19,47 @@
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA
-# 02111-1307, USA.
+# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+# 02110-1301, USA.
+
+# As a special exception to the GNU General Public License, if you
+# distribute this file as part of a program that contains a
+# configuration script generated by Autoconf, you may include it under
+# the same distribution terms that you use for the rest of that program.
if test $# -eq 0; then
echo 1>&2 "Try \`$0 --help' for more information"
exit 1
fi
+run=:
+
+# In the cases where this matters, `missing' is being run in the
+# srcdir already.
+if test -f configure.ac; then
+ configure_ac=configure.ac
+else
+ configure_ac=configure.in
+fi
+
+msg="missing on your system"
+
case "$1" in
+--run)
+ # Try to run requested program, and just exit if it succeeds.
+ run=
+ shift
+ "$@" && exit 0
+ # Exit code 63 means version mismatch. This often happens
+ # when the user try to use an ancient version of a tool on
+ # a file that requires a minimum version. In this case we
+ # we should proceed has if the program had been absent, or
+ # if --run hadn't been passed.
+ if test $? = 63; then
+ run=:
+ msg="probably too old"
+ fi
+ ;;
-h|--h|--he|--hel|--help)
echo "\
@@ -35,6 +71,7 @@ error status if there is no known handling for PROGRAM.
Options:
-h, --help display this help and exit
-v, --version output version information and exit
+ --run try to run the given command, and emulate it if it fails
Supported PROGRAM values:
aclocal touch file \`aclocal.m4'
@@ -43,13 +80,19 @@ Supported PROGRAM values:
automake touch all \`Makefile.in' files
bison create \`y.tab.[ch]', if possible, from existing .[ch]
flex create \`lex.yy.c', if possible, from existing .c
+ help2man touch the output file
lex create \`lex.yy.c', if possible, from existing .c
makeinfo touch the output file
- yacc create \`y.tab.[ch]', if possible, from existing .[ch]"
+ tar try tar, gnutar, gtar, then tar without non-portable flags
+ yacc create \`y.tab.[ch]', if possible, from existing .[ch]
+
+Send bug reports to <bug-automake@gnu.org>."
+ exit $?
;;
-v|--v|--ve|--ver|--vers|--versi|--versio|--version)
- echo "missing - GNU libit 0.0"
+ echo "missing $scriptversion (GNU Automake)"
+ exit $?
;;
-*)
@@ -58,10 +101,45 @@ Supported PROGRAM values:
exit 1
;;
- aclocal)
+esac
+
+# Now exit if we have it, but it failed. Also exit now if we
+# don't have it and --version was passed (most likely to detect
+# the program).
+case "$1" in
+ lex|yacc)
+ # Not GNU programs, they don't have --version.
+ ;;
+
+ tar)
+ if test -n "$run"; then
+ echo 1>&2 "ERROR: \`tar' requires --run"
+ exit 1
+ elif test "x$2" = "x--version" || test "x$2" = "x--help"; then
+ exit 1
+ fi
+ ;;
+
+ *)
+ if test -z "$run" && ($1 --version) > /dev/null 2>&1; then
+ # We have it, but it failed.
+ exit 1
+ elif test "x$2" = "x--version" || test "x$2" = "x--help"; then
+ # Could not run --version or --help. This is probably someone
+ # running `$TOOL --version' or `$TOOL --help' to check whether
+ # $TOOL exists and not knowing $TOOL uses missing.
+ exit 1
+ fi
+ ;;
+esac
+
+# If it does not exist, or fails to run (possibly an outdated version),
+# try to emulate it.
+case "$1" in
+ aclocal*)
echo 1>&2 "\
-WARNING: \`$1' is missing on your system. You should only need it if
- you modified \`acinclude.m4' or \`configure.in'. You might want
+WARNING: \`$1' is $msg. You should only need it if
+ you modified \`acinclude.m4' or \`${configure_ac}'. You might want
to install the \`Automake' and \`Perl' packages. Grab them from
any GNU archive site."
touch aclocal.m4
@@ -69,8 +147,8 @@ WARNING: \`$1' is missing on your system. You should only need it if
autoconf)
echo 1>&2 "\
-WARNING: \`$1' is missing on your system. You should only need it if
- you modified \`configure.in'. You might want to install the
+WARNING: \`$1' is $msg. You should only need it if
+ you modified \`${configure_ac}'. You might want to install the
\`Autoconf' and \`GNU m4' packages. Grab them from any GNU
archive site."
touch configure
@@ -78,11 +156,11 @@ WARNING: \`$1' is missing on your system. You should only need it if
autoheader)
echo 1>&2 "\
-WARNING: \`$1' is missing on your system. You should only need it if
- you modified \`acconfig.h' or \`configure.in'. You might want
+WARNING: \`$1' is $msg. You should only need it if
+ you modified \`acconfig.h' or \`${configure_ac}'. You might want
to install the \`Autoconf' and \`GNU m4' packages. Grab them
from any GNU archive site."
- files=`sed -n 's/^[ ]*A[CM]_CONFIG_HEADER(\([^)]*\)).*/\1/p' configure.in`
+ files=`sed -n 's/^[ ]*A[CM]_CONFIG_HEADER(\([^)]*\)).*/\1/p' ${configure_ac}`
test -z "$files" && files="config.h"
touch_files=
for f in $files; do
@@ -95,10 +173,10 @@ WARNING: \`$1' is missing on your system. You should only need it if
touch $touch_files
;;
- automake)
+ automake*)
echo 1>&2 "\
-WARNING: \`$1' is missing on your system. You should only need it if
- you modified \`Makefile.am', \`acinclude.m4' or \`configure.in'.
+WARNING: \`$1' is $msg. You should only need it if
+ you modified \`Makefile.am', \`acinclude.m4' or \`${configure_ac}'.
You might want to install the \`Automake' and \`Perl' packages.
Grab them from any GNU archive site."
find . -type f -name Makefile.am -print |
@@ -106,9 +184,32 @@ WARNING: \`$1' is missing on your system. You should only need it if
while read f; do touch "$f"; done
;;
+ autom4te)
+ echo 1>&2 "\
+WARNING: \`$1' is needed, but is $msg.
+ You might have modified some files without having the
+ proper tools for further handling them.
+ You can get \`$1' as part of \`Autoconf' from any GNU
+ archive site."
+
+ file=`echo "$*" | sed -n 's/.*--output[ =]*\([^ ]*\).*/\1/p'`
+ test -z "$file" && file=`echo "$*" | sed -n 's/.*-o[ ]*\([^ ]*\).*/\1/p'`
+ if test -f "$file"; then
+ touch $file
+ else
+ test -z "$file" || exec >$file
+ echo "#! /bin/sh"
+ echo "# Created by GNU Automake missing as a replacement of"
+ echo "# $ $@"
+ echo "exit 0"
+ chmod +x $file
+ exit 1
+ fi
+ ;;
+
bison|yacc)
echo 1>&2 "\
-WARNING: \`$1' is missing on your system. You should only need it if
+WARNING: \`$1' $msg. You should only need it if
you modified a \`.y' file. You may need the \`Bison' package
in order for those modifications to take effect. You can get
\`Bison' from any GNU archive site."
@@ -138,7 +239,7 @@ WARNING: \`$1' is missing on your system. You should only need it if
lex|flex)
echo 1>&2 "\
-WARNING: \`$1' is missing on your system. You should only need it if
+WARNING: \`$1' is $msg. You should only need it if
you modified a \`.l' file. You may need the \`Flex' package
in order for those modifications to take effect. You can get
\`Flex' from any GNU archive site."
@@ -159,28 +260,90 @@ WARNING: \`$1' is missing on your system. You should only need it if
fi
;;
+ help2man)
+ echo 1>&2 "\
+WARNING: \`$1' is $msg. You should only need it if
+ you modified a dependency of a manual page. You may need the
+ \`Help2man' package in order for those modifications to take
+ effect. You can get \`Help2man' from any GNU archive site."
+
+ file=`echo "$*" | sed -n 's/.*-o \([^ ]*\).*/\1/p'`
+ if test -z "$file"; then
+ file=`echo "$*" | sed -n 's/.*--output=\([^ ]*\).*/\1/p'`
+ fi
+ if [ -f "$file" ]; then
+ touch $file
+ else
+ test -z "$file" || exec >$file
+ echo ".ab help2man is required to generate this page"
+ exit 1
+ fi
+ ;;
+
makeinfo)
echo 1>&2 "\
-WARNING: \`$1' is missing on your system. You should only need it if
+WARNING: \`$1' is $msg. You should only need it if
you modified a \`.texi' or \`.texinfo' file, or any other file
indirectly affecting the aspect of the manual. The spurious
call might also be the consequence of using a buggy \`make' (AIX,
DU, IRIX). You might want to install the \`Texinfo' package or
the \`GNU make' package. Grab either from any GNU archive site."
+ # The file to touch is that specified with -o ...
file=`echo "$*" | sed -n 's/.*-o \([^ ]*\).*/\1/p'`
if test -z "$file"; then
- file=`echo "$*" | sed 's/.* \([^ ]*\) *$/\1/'`
- file=`sed -n '/^@setfilename/ { s/.* \([^ ]*\) *$/\1/; p; q; }' $file`
+ # ... or it is the one specified with @setfilename ...
+ infile=`echo "$*" | sed 's/.* \([^ ]*\) *$/\1/'`
+ file=`sed -n '/^@setfilename/ { s/.* \([^ ]*\) *$/\1/; p; q; }' $infile`
+ # ... or it is derived from the source name (dir/f.texi becomes f.info)
+ test -z "$file" && file=`echo "$infile" | sed 's,.*/,,;s,.[^.]*$,,'`.info
fi
+ # If the file does not exist, the user really needs makeinfo;
+ # let's fail without touching anything.
+ test -f $file || exit 1
touch $file
;;
+ tar)
+ shift
+
+ # We have already tried tar in the generic part.
+ # Look for gnutar/gtar before invocation to avoid ugly error
+ # messages.
+ if (gnutar --version > /dev/null 2>&1); then
+ gnutar "$@" && exit 0
+ fi
+ if (gtar --version > /dev/null 2>&1); then
+ gtar "$@" && exit 0
+ fi
+ firstarg="$1"
+ if shift; then
+ case "$firstarg" in
+ *o*)
+ firstarg=`echo "$firstarg" | sed s/o//`
+ tar "$firstarg" "$@" && exit 0
+ ;;
+ esac
+ case "$firstarg" in
+ *h*)
+ firstarg=`echo "$firstarg" | sed s/h//`
+ tar "$firstarg" "$@" && exit 0
+ ;;
+ esac
+ fi
+
+ echo 1>&2 "\
+WARNING: I can't seem to be able to run \`tar' with the given arguments.
+ You may want to install GNU tar or Free paxutils, or check the
+ command line arguments."
+ exit 1
+ ;;
+
*)
echo 1>&2 "\
-WARNING: \`$1' is needed, and you do not seem to have it handy on your
- system. You might have modified some files without having the
+WARNING: \`$1' is needed, and is $msg.
+ You might have modified some files without having the
proper tools for further handling them. Check the \`README' file,
- it often tells you about the needed prerequirements for installing
+ it often tells you about the needed prerequisites for installing
this package. You may also peek at any GNU archive site, in case
some other package would contain this missing \`$1' program."
exit 1
@@ -188,3 +351,10 @@ WARNING: \`$1' is needed, and you do not seem to have it handy on your
esac
exit 0
+
+# Local variables:
+# eval: (add-hook 'write-file-hooks 'time-stamp)
+# time-stamp-start: "scriptversion="
+# time-stamp-format: "%:y-%02m-%02d.%02H"
+# time-stamp-end: "$"
+# End:
diff --git a/contrib/ldapc++/mkinstalldirs b/contrib/ldapc++/mkinstalldirs
deleted file mode 100755
index 732d62e1cbe4f24b1137860e9f5e5f366ac37d5e..0000000000000000000000000000000000000000
--- a/contrib/ldapc++/mkinstalldirs
+++ /dev/null
@@ -1,39 +0,0 @@
-#! /bin/sh
-# mkinstalldirs --- make directory hierarchy
-# Author: Noah Friedman <friedman@prep.ai.mit.edu>
-# Created: 1993-05-16
-# Public domain
-
-
-errstatus=0
-
-for file
-do
- set fnord `echo ":$file" | sed -ne 's/^:\//#/;s/^://;s/\// /g;s/^#/\//;p'`
- shift
-
- pathcomp=
- for d
- do
- pathcomp="$pathcomp$d"
- case "$pathcomp" in
- -* ) pathcomp=./$pathcomp ;;
- esac
-
- if test ! -d "$pathcomp"; then
- echo "mkdir $pathcomp"
-
- mkdir "$pathcomp" || lasterr=$?
-
- if test ! -d "$pathcomp"; then
- errstatus=$lasterr
- fi
- fi
-
- pathcomp="$pathcomp/"
- done
-done
-
-exit $errstatus
-
-# mkinstalldirs ends here
diff --git a/contrib/ldapc++/src/LDAPAsynConnection.cpp b/contrib/ldapc++/src/LDAPAsynConnection.cpp
index 6ffb5af4c3a4c6af85f2932f898f5b30a67601c8..4b2eb53601c11f68a6dffdfd89eff5b666253f8b 100644
--- a/contrib/ldapc++/src/LDAPAsynConnection.cpp
+++ b/contrib/ldapc++/src/LDAPAsynConnection.cpp
@@ -72,7 +72,6 @@ void LDAPAsynConnection::init(const string& hostname, int port){
}
void LDAPAsynConnection::start_tls(){
- int resCode;
if( ldap_start_tls_s( cur_session, NULL, NULL ) != LDAP_SUCCESS ) {
throw LDAPException(this);
}
diff --git a/contrib/ldapc++/src/LDAPException.h b/contrib/ldapc++/src/LDAPException.h
index 09d94f4ab5633596ba43cb6e0a911e1e44890dc4..63d813dca1478691dbb9c19cab36bb0773727932 100644
--- a/contrib/ldapc++/src/LDAPException.h
+++ b/contrib/ldapc++/src/LDAPException.h
@@ -18,14 +18,15 @@ class LDAPAsynConnection;
*/
class LDAPException{
- public :
+ public :
/**
* Constructs a LDAPException-object from the parameters
* @param res_code A valid LDAP result code.
* @param err_string An addional error message for the error
* that happend (optional)
*/
- LDAPException(int res_code, const std::string& err_string=std::string());
+ LDAPException(int res_code,
+ const std::string& err_string=std::string());
/**
* Constructs a LDAPException-object from the error state of a
@@ -43,14 +44,13 @@ class LDAPException{
/**
* @return The Result code of the object
*/
-
- int getResultCode() const;
+ int getResultCode() const;
/**
* @return The error message that is corresponding to the result
* code .
*/
- const std::string& getResultMsg() const;
+ const std::string& getResultMsg() const;
/**
* @return The addional error message of the error (if it was set)
@@ -61,11 +61,11 @@ class LDAPException{
* This method can be used to dump the data of a LDAPResult-Object.
* It is only useful for debugging purposes at the moment
*/
- friend std::ostream& operator << (std::ostream &s, LDAPException e);
+ friend std::ostream& operator << (std::ostream &s, LDAPException e);
- private :
- int m_res_code;
- std::string m_res_string;
- std::string m_err_string;
+ private :
+ int m_res_code;
+ std::string m_res_string;
+ std::string m_err_string;
};
#endif //LDAP_EXCEPTION_H
diff --git a/contrib/ldapc++/src/LDAPUrl.cpp b/contrib/ldapc++/src/LDAPUrl.cpp
index e7763b4ebbdd52c516f949ff17a70805db3ba750..a960ef6f5cc481aaf91ea67d81fa28b25ecce246 100644
--- a/contrib/ldapc++/src/LDAPUrl.cpp
+++ b/contrib/ldapc++/src/LDAPUrl.cpp
@@ -1,74 +1,495 @@
/*
- * Copyright 2000, OpenLDAP Foundation, All Rights Reserved.
+ * Copyright 2000-2006, OpenLDAP Foundation, All Rights Reserved.
* COPYING RESTRICTIONS APPLY, see COPYRIGHT file
*/
#include "LDAPUrl.h"
-
-#include <ldap.h>
+#include <sstream>
#include "debug.h"
using namespace std;
-LDAPUrl::LDAPUrl(const char *url){
+#define PCT_ENCFLAG_NONE 0x0000U
+#define PCT_ENCFLAG_COMMA 0x0001U
+#define PCT_ENCFLAG_SLASH 0x0002U
+
+#define LDAP_DEFAULT_PORT 389
+#define LDAPS_DEFAULT_PORT 636
+
+LDAPUrl::LDAPUrl(const std::string &url)
+{
DEBUG(LDAP_DEBUG_CONSTRUCT, "LDAPUrl::LDAPUrl()" << endl);
DEBUG(LDAP_DEBUG_CONSTRUCT | LDAP_DEBUG_PARAMETER,
" url:" << url << endl);
- if (ldap_is_ldap_url(url)){
- LDAPURLDesc *urlDesc;
- ldap_url_parse(url, &urlDesc);
- if(urlDesc->lud_host){
- m_Host = string(urlDesc->lud_host);
- }
- m_Port = urlDesc->lud_port;
- if(urlDesc->lud_dn){
- m_DN = string(urlDesc->lud_dn);
- }
- m_Attrs = StringList(urlDesc->lud_attrs);
- m_Scope = urlDesc->lud_scope;
- if(urlDesc->lud_filter){
- m_Filter = string(urlDesc->lud_filter);
- }else{
- m_Filter = "";
- }
- m_urlString= string(url);
- ldap_free_urldesc(urlDesc);
- }else{
- DEBUG(LDAP_DEBUG_TRACE," noUrl:" << url << endl);
+ m_urlString = url;
+ m_Filter = "";
+ m_Scheme = "ldap";
+ m_Scope = 0;
+ m_Port = 0;
+ regenerate = false;
+ if (url != "") {
+ this->parseUrl();
}
}
-LDAPUrl::~LDAPUrl(){
+LDAPUrl::~LDAPUrl()
+{
DEBUG(LDAP_DEBUG_DESTROY, "LDAPUrl::~LDAPUrl()" << endl);
m_Attrs.clear();
}
-int LDAPUrl::getPort() const {
+int LDAPUrl::getPort() const
+{
return m_Port;
}
-int LDAPUrl::getScope() const {
+void LDAPUrl::setPort(int port)
+{
+ m_Port = port;
+ regenerate = true;
+}
+
+int LDAPUrl::getScope() const
+{
return m_Scope;
}
-const string& LDAPUrl::getURLString() const {
+void LDAPUrl::setScope( const std::string &scope )
+{
+ if (scope == "base" || scope == "" ) {
+ m_Scope = 0;
+ } else if (scope == "one" ) {
+ m_Scope = 1;
+ } else if (scope == "sub" ) {
+ m_Scope = 2;
+ } else {
+ throw LDAPUrlException(LDAPUrlException::INVALID_SCOPE,
+ "Scope was:" + scope);
+ }
+ regenerate = true;
+}
+
+const string& LDAPUrl::getURLString()
+{
+ if (regenerate){
+ this->components2Url();
+ regenerate=false;
+ }
return m_urlString;
}
-const string& LDAPUrl::getHost() const {
+void LDAPUrl::setURLString( const std::string &url )
+{
+ m_urlString = url;
+ if (url != "") {
+ this->parseUrl();
+ }
+ regenerate = false;
+}
+
+const string& LDAPUrl::getHost() const
+{
return m_Host;
}
-const string& LDAPUrl::getDN() const {
+void LDAPUrl::setHost( const std::string &host )
+{
+ m_Host = host;
+ regenerate = true;
+}
+
+const string& LDAPUrl::getDN() const
+{
return m_DN;
}
+void LDAPUrl::setDN( const std::string &dn )
+{
+ m_DN = dn;
+ regenerate = true;
+}
-const string& LDAPUrl::getFilter() const {
+const string& LDAPUrl::getFilter() const
+{
return m_Filter;
}
+void LDAPUrl::setFilter( const std::string &filter )
+{
+ m_Filter = filter;
+ regenerate = true;
+}
-const StringList& LDAPUrl::getAttrs() const {
+const StringList& LDAPUrl::getAttrs() const
+{
return m_Attrs;
}
+void LDAPUrl::setAttrs( const StringList &attrs )
+{
+ m_Attrs = attrs;
+ regenerate = true;
+}
+
+const StringList& LDAPUrl::getExtensions() const
+{
+ return m_Extensions;
+}
+
+void LDAPUrl::setExtensions( const StringList &ext )
+{
+ m_Extensions = ext;
+ regenerate = true;
+}
+
+const std::string& LDAPUrl::getScheme() const
+{
+ return m_Scheme;
+}
+
+void LDAPUrl::setScheme( const std::string &scheme )
+{
+ if (scheme == "ldap" || scheme == "ldaps" ||
+ scheme == "ldapi" || scheme == "cldap" )
+ {
+ m_Scheme = scheme;
+ regenerate = true;
+ } else {
+ throw LDAPUrlException(LDAPUrlException::INVALID_SCHEME,
+ "Unknown URL scheme: \"" + scheme + "\"");
+ }
+}
+
+void LDAPUrl::parseUrl()
+{
+ DEBUG(LDAP_DEBUG_TRACE, "LDAPUrl::parseUrl()" << std::endl);
+ // reading Scheme
+ std::string::size_type pos = m_urlString.find(':');
+ std::string::size_type startpos = m_urlString.find(':');
+ if (pos == std::string::npos) {
+ throw LDAPUrlException(LDAPUrlException::INVALID_URL,
+ "No colon found in URL");
+ }
+ std::string scheme = m_urlString.substr(0, pos);
+ DEBUG(LDAP_DEBUG_TRACE, " scheme is <" << scheme << ">" << std::endl);
+
+ if ( scheme == "ldap" ) {
+ m_Scheme = scheme;
+ } else if ( scheme == "ldaps" ) {
+ m_Scheme = scheme;
+ } else if ( scheme == "ldapi" ) {
+ m_Scheme = scheme;
+ } else if ( scheme == "cldap" ) {
+ m_Scheme = scheme;
+ } else {
+ throw LDAPUrlException(LDAPUrlException::INVALID_SCHEME,
+ "Unknown URL Scheme: \"" + scheme + "\"");
+ }
+
+ if ( m_urlString[pos+1] != '/' || m_urlString[pos+2] != '/' ) {
+ throw LDAPUrlException(LDAPUrlException::INVALID_URL);
+ } else {
+ startpos = pos + 3;
+ }
+ if ( m_urlString[startpos] == '/' ) {
+ startpos++;
+ } else {
+ pos = m_urlString.find('/', startpos);
+ std::string hostport = m_urlString.substr(startpos,
+ pos - startpos);
+ DEBUG(LDAP_DEBUG_TRACE, " hostport: <" << hostport << ">"
+ << std::endl);
+ std::string::size_type portstart = m_urlString.find(':', startpos);
+ if (portstart == std::string::npos || portstart > pos ) {
+ percentDecode(hostport, m_Host);
+ if ( m_Scheme == "ldap" || m_Scheme == "cldap" ) {
+ m_Port = LDAP_DEFAULT_PORT;
+ } else if ( m_Scheme == "ldaps" ) {
+ m_Port = LDAPS_DEFAULT_PORT;
+ }
+ } else {
+ std::string tmp = m_urlString.substr(startpos,
+ portstart - startpos);
+ percentDecode(tmp, m_Host);
+ DEBUG(LDAP_DEBUG_TRACE, "Host: <" << m_Host << ">" << std::endl);
+ std::string port = m_urlString.substr(portstart+1,
+ pos-portstart-1);
+ if ( port.length() > 0 ) {
+ std::istringstream i(port);
+ i >> m_Port;
+ if ( i.fail() ){
+ throw LDAPUrlException(LDAPUrlException::INVALID_PORT);
+ }
+ }
+ DEBUG(LDAP_DEBUG_TRACE, " Port: <" << m_Port << ">"
+ << std::endl);
+ }
+ }
+ startpos = pos + 1;
+ int parserMode = base;
+ while ( pos != std::string::npos ) {
+ pos = m_urlString.find('?', startpos);
+ std::string actComponent = m_urlString.substr(startpos,
+ pos - startpos);
+ DEBUG(LDAP_DEBUG_TRACE, " ParserMode:" << parserMode << std::endl);
+ DEBUG(LDAP_DEBUG_TRACE, " ActComponent: <" << actComponent << ">"
+ << std::endl);
+ std::string s_scope = "";
+ std::string s_ext = "";
+ switch(parserMode) {
+ case base :
+ percentDecode(actComponent, m_DN);
+ DEBUG(LDAP_DEBUG_TRACE, " BaseDN:" << m_DN << std::endl);
+ break;
+ case attrs :
+ DEBUG(LDAP_DEBUG_TRACE, " reading Attributes" << std::endl);
+ if (actComponent.length() != 0 ) {
+ string2list(actComponent,m_Attrs, true);
+ }
+ break;
+ case scope :
+ percentDecode(actComponent, s_scope);
+ if (s_scope == "base" || s_scope == "" ) {
+ m_Scope = 0;
+ } else if (s_scope == "one" ) {
+ m_Scope = 1;
+ } else if (s_scope == "sub" ) {
+ m_Scope = 2;
+ } else {
+ throw LDAPUrlException(LDAPUrlException::INVALID_SCOPE);
+ }
+ DEBUG(LDAP_DEBUG_TRACE, " Scope: <" << s_scope << ">"
+ << std::endl);
+ break;
+ case filter :
+ percentDecode(actComponent, m_Filter);
+ DEBUG(LDAP_DEBUG_TRACE, " filter: <" << m_Filter << ">"
+ << std::endl);
+ break;
+ case extensions :
+ DEBUG(LDAP_DEBUG_TRACE, " reading Extensions" << std::endl);
+ string2list(actComponent, m_Extensions, true);
+ break;
+ default :
+ DEBUG(LDAP_DEBUG_TRACE, " unknown state" << std::endl);
+ break;
+ }
+ startpos = pos + 1;
+ parserMode++;
+ }
+}
+
+void LDAPUrl::percentDecode(const std::string& src, std::string &out)
+{
+ DEBUG(LDAP_DEBUG_TRACE, "LDAPUrl::percentDecode()" << std::endl);
+ std::string::size_type pos = 0;
+ std::string::size_type startpos = 0;
+ pos = src.find('%', startpos);
+ while ( pos != std::string::npos ) {
+ out += src.substr(startpos, pos - startpos);
+ std::string istr(src.substr(pos+1, 2));
+ std::istringstream i(istr);
+ i.setf(std::ios::hex, std::ios::basefield);
+ i.unsetf(std::ios::showbase);
+ int hex;
+ i >> hex;
+ if ( i.fail() ){
+ throw LDAPUrlException(LDAPUrlException::URL_DECODING_ERROR,
+ "Invalid percent encoding");
+ }
+ char j = hex;
+ out.push_back(j);
+ startpos = pos+3;
+ pos = src.find('%', startpos);
+ }
+ out += src.substr(startpos, pos - startpos);
+}
+
+void LDAPUrl::string2list(const std::string &src, StringList& sl,
+ bool percentDecode)
+{
+ std::string::size_type comma_startpos = 0;
+ std::string::size_type comma_pos = 0;
+ std::string actItem;
+ while ( comma_pos != std::string::npos ) {
+ comma_pos = src.find(',', comma_startpos);
+ actItem = src.substr(comma_startpos, comma_pos - comma_startpos);
+ if (percentDecode){
+ std::string decoded;
+ this->percentDecode(actItem,decoded);
+ actItem = decoded;
+ }
+ sl.add(actItem);
+ comma_startpos = comma_pos + 1;
+ }
+}
+
+
+void LDAPUrl::components2Url()
+{
+ std::ostringstream url;
+ std::string encoded = "";
+ this->percentEncode(m_Host, encoded, PCT_ENCFLAG_SLASH);
+ url << m_Scheme << "://" << encoded;
+ if ( m_Port != 0 ) {
+ url << ":" << m_Port;
+ }
+
+ url << "/";
+ encoded = "";
+ if ( m_DN != "" ) {
+ this->percentEncode( m_DN, encoded );
+ url << encoded;
+ }
+ string qm = "";
+ if ( ! m_Attrs.empty() ){
+ url << "?";
+ bool first = true;
+ for ( StringList::const_iterator i = m_Attrs.begin();
+ i != m_Attrs.end(); i++)
+ {
+ this->percentEncode( *i, encoded );
+ if ( ! first ) {
+ url << ",";
+ } else {
+ first = false;
+ }
+ url << encoded;
+ }
+ } else {
+ qm.append("?");
+ }
+ if ( m_Scope == 1 ) {
+ url << qm << "?one";
+ qm = "";
+ } else if ( m_Scope == 2 ) {
+ url << qm << "?sub";
+ qm = "";
+ } else {
+ qm.append("?");
+ }
+ if (m_Filter != "" ){
+ this->percentEncode( m_Filter, encoded );
+ url << qm << "?" << encoded;
+ qm = "";
+ } else {
+ qm.append("?");
+ }
+
+ if ( ! m_Extensions.empty() ){
+ url << qm << "?";
+ bool first = true;
+ for ( StringList::const_iterator i = m_Extensions.begin();
+ i != m_Extensions.end(); i++)
+ {
+ this->percentEncode( *i, encoded, 1);
+ if ( ! first ) {
+ url << ",";
+ } else {
+ first = false;
+ }
+ url << encoded;
+ }
+ }
+ m_urlString=url.str();
+}
+
+
+void LDAPUrl::percentEncode( const std::string &src,
+ std::string &dest,
+ int flags)
+{
+ std::ostringstream o;
+ o.setf(std::ios::hex, std::ios::basefield);
+ o.setf(std::ios::uppercase);
+ o.unsetf(std::ios::showbase);
+ bool escape=false;
+ for ( std::string::const_iterator i = src.begin(); i != src.end(); i++ ){
+ switch(*i){
+ /* reserved */
+ case '?' :
+ escape = true;
+ break;
+ case ',' :
+ if ( flags & PCT_ENCFLAG_COMMA ) {
+ escape = true;
+ } else {
+ escape = false;
+ }
+ break;
+ case ':' :
+ case '/' :
+ if ( flags & PCT_ENCFLAG_SLASH ) {
+ escape = true;
+ } else {
+ escape = false;
+ }
+ break;
+ case '#' :
+ case '[' :
+ case ']' :
+ case '@' :
+ case '!' :
+ case '$' :
+ case '&' :
+ case '\'' :
+ case '(' :
+ case ')' :
+ case '*' :
+ case '+' :
+ case ';' :
+ case '=' :
+ /* unreserved */
+ case '-' :
+ case '.' :
+ case '_' :
+ case '~' :
+ escape = false;
+ break;
+ default :
+ if ( std::isalnum(*i) ) {
+ escape = false;
+ } else {
+ escape = true;
+ }
+ break;
+ }
+ if ( escape ) {
+ o << "%" << (int)(unsigned char)*i ;
+ } else {
+ o.put(*i);
+ }
+ }
+ dest = o.str();
+}
+
+const code2string_s LDAPUrlException::code2string[] = {
+ { INVALID_SCHEME, "Invalid URL Scheme" },
+ { INVALID_PORT, "Invalid Port in Url" },
+ { INVALID_SCOPE, "Invalid Search Scope in Url" },
+ { INVALID_URL, "Invalid LDAP Url" },
+ { URL_DECODING_ERROR, "Url-decoding Error" },
+ { 0, 0 }
+};
+LDAPUrlException::LDAPUrlException( int code, const std::string &msg) :
+ m_code(code), m_addMsg(msg) {}
+
+int LDAPUrlException::getCode() const
+{
+ return m_code;
+}
+
+const std::string LDAPUrlException::getAdditionalInfo() const
+{
+ return m_addMsg;
+}
+
+const std::string LDAPUrlException::getErrorMessage() const
+{
+ for ( int i = 0; code2string[i].string != 0; i++ ) {
+ if ( code2string[i].code == m_code ) {
+ return std::string(code2string[i].string);
+ }
+ }
+ return "";
+
+}
diff --git a/contrib/ldapc++/src/LDAPUrl.h b/contrib/ldapc++/src/LDAPUrl.h
index 9314aa09b272343f34484e3c2986dfea562379ad..16e1810e6f55ad82ede4b02ab77248cbe379d1fb 100644
--- a/contrib/ldapc++/src/LDAPUrl.h
+++ b/contrib/ldapc++/src/LDAPUrl.h
@@ -1,5 +1,5 @@
/*
- * Copyright 2000, OpenLDAP Foundation, All Rights Reserved.
+ * Copyright 2000-2006, OpenLDAP Foundation, All Rights Reserved.
* COPYING RESTRICTIONS APPLY, see COPYRIGHT file
*/
@@ -7,9 +7,9 @@
#ifndef LDAP_URL_H
#define LDAP_URL_H
-#include <ldap.h>
#include <StringList.h>
+class LDAPUrlException;
/**
* This class is used to analyze and store LDAP-Urls as returned by a
* LDAP-Server as Referrals and Search References. LDAP-URLs are defined
@@ -22,9 +22,10 @@ class LDAPUrl{
public :
/**
- * Create a new object from a c-string that contains a LDAP-Url
+ * Create a new object from a string that contains a LDAP-Url
+ * @param url The URL String
*/
- LDAPUrl(const char *url);
+ LDAPUrl(const std::string &url="");
/**
* Destructor
@@ -36,47 +37,168 @@ class LDAPUrl{
* port
*/
int getPort() const;
+
+ /**
+ * Set the port value of the URL
+ * @param dn The port value
+ */
+ void setPort(int port);
/**
* @return The scope part of the URL is returned.
*/
int getScope() const;
+ /**
+ * Set the Scope part of the URL
+ * @param scope The new scope
+ */
+ void setScope(const std::string& scope);
+
/**
* @return The complete URL as a string
*/
- const std::string& getURLString() const;
+ const std::string& getURLString();
+
+ /**
+ * Set the URL member attribute
+ * @param url The URL String
+ */
+ void setURLString(const std::string &url);
/**
* @return The hostname or IP-Address of the destination host.
*/
const std::string& getHost() const;
+ /**
+ * Set the Host part of the URL
+ * @param host The new host part
+ */
+ void setHost( const std::string &host);
+
+ /**
+ * @return The Protocol Scheme of the URL.
+ */
+ const std::string& getScheme() const;
+
+ /**
+ * Set the Protocol Scheme of the URL
+ * @param host The Protcol scheme. Allowed values are
+ * ldap,ldapi,ldaps and cldap
+ */
+ void setScheme( const std::string &scheme );
+
/**
* @return The Base-DN part of the URL
*/
const std::string& getDN() const;
+
+ /**
+ * Set the DN part of the URL
+ * @param dn The new DN part
+ */
+ void setDN( const std::string &dn);
/**
* @return The Filter part of the URL
*/
const std::string& getFilter() const;
+
+ /**
+ * Set the Filter part of the URL
+ * @param filter The new Filter
+ */
+ void setFilter( const std::string &filter);
/**
* @return The List of attributes that was in the URL
*/
const StringList& getAttrs() const;
-
+
+ /**
+ * Set the Attributes part of the URL
+ * @param attrs StringList constaining the List of Attributes
+ */
+ void setAttrs( const StringList &attrs);
+ void setExtensions( const StringList &ext);
+ const StringList& getExtensions() const;
+
+ /**
+ * Percent-decode a string
+ * @param src The string that is to be decoded
+ * @param dest The decoded result string
+ */
+ void percentDecode( const std::string& src, std::string& dest );
+
+ /**
+ * Percent-encoded a string
+ * @param src The string that is to be encoded
+ * @param dest The encoded result string
+ * @param flags
+ */
+ void percentEncode( const std::string& src,
+ std::string& dest,
+ int flags=0 );
+
+ protected :
+ /**
+ * Split the url string that is associated with this Object into
+ * it components. The compontens of the URL can be access via the
+ * get...() methods.
+ * (this function is mostly for internal use and gets called
+ * automatically whenever necessary)
+ */
+ void parseUrl();
+
+ /**
+ * Generate an URL string from the components that were set with
+ * the various set...() methods
+ * (this function is mostly for internal use and gets called
+ * automatically whenever necessary)
+ */
+ void components2Url();
+
+ void string2list(const std::string &src, StringList& sl,
+ bool percentDecode=false);
+
protected :
+ bool regenerate;
int m_Port;
int m_Scope;
std::string m_Host;
std::string m_DN;
std::string m_Filter;
StringList m_Attrs;
- LDAPURLDesc *m_urlDesc;
+ StringList m_Extensions;
std::string m_urlString;
+ std::string m_Scheme;
+ enum mode { base, attrs, scope, filter, extensions };
};
+struct code2string_s {
+ int code;
+ const char* string;
+};
+
+class LDAPUrlException {
+ public :
+ LDAPUrlException(int code, const std::string &msg="" );
+
+ int getCode() const;
+ const std::string getErrorMessage() const;
+ const std::string getAdditionalInfo() const;
+
+ static const int INVALID_SCHEME = 1;
+ static const int INVALID_PORT = 2;
+ static const int INVALID_SCOPE = 3;
+ static const int INVALID_URL = 4;
+ static const int URL_DECODING_ERROR = 5;
+ static const code2string_s code2string[];
+
+ private:
+ int m_code;
+ std::string m_addMsg;
+};
#endif //LDAP_URL_H
diff --git a/contrib/ldapc++/src/Makefile.in b/contrib/ldapc++/src/Makefile.in
index 2ec8d804f3b0fef6cf173546a69e62e429d5d281..5e31d057b7fac220f6dfc43e908e241ff1f885e4 100644
--- a/contrib/ldapc++/src/Makefile.in
+++ b/contrib/ldapc++/src/Makefile.in
@@ -48,7 +48,7 @@ ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
am__aclocal_m4_deps = $(top_srcdir)/configure.in
am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
$(ACLOCAL_M4)
-mkinstalldirs = $(SHELL) $(top_srcdir)/mkinstalldirs
+mkinstalldirs = $(install_sh) -d
CONFIG_HEADER = config.h
CONFIG_CLEAN_FILES =
am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
@@ -315,7 +315,7 @@ config.h: stamp-h1
stamp-h1: $(srcdir)/config.h.in $(top_builddir)/config.status
@rm -f stamp-h1
cd $(top_builddir) && $(SHELL) ./config.status src/config.h
-$(srcdir)/config.h.in: $(am__configure_deps) $(top_srcdir)/acconfig.h
+$(srcdir)/config.h.in: $(am__configure_deps)
cd $(top_srcdir) && $(AUTOHEADER)
rm -f stamp-h1
touch $@
diff --git a/contrib/ldapc++/src/config.h.in b/contrib/ldapc++/src/config.h.in
index 7d4dbab085f1e7c3e60a2f43dab1297b58275122..a56e34b48c6cae68ecbf8c49ef791580653cb1f2 100644
--- a/contrib/ldapc++/src/config.h.in
+++ b/contrib/ldapc++/src/config.h.in
@@ -1,6 +1,4 @@
/* src/config.h.in. Generated from configure.in by autoheader. */
-#undef WITH_DEBUG
-
/* Define to 1 if you have the <dlfcn.h> header file. */
#undef HAVE_DLFCN_H
@@ -61,3 +59,6 @@
/* Version number of package */
#undef VERSION
+
+/* Define to 1 ot enable debug logging */
+#undef WITH_DEBUG
diff --git a/contrib/ldapc++/stamp-h.in b/contrib/ldapc++/stamp-h.in
deleted file mode 100644
index 9788f70238c91894045d22366fa941580826c3c1..0000000000000000000000000000000000000000
--- a/contrib/ldapc++/stamp-h.in
+++ /dev/null
@@ -1 +0,0 @@
-timestamp
diff --git a/doc/drafts/draft-ietf-ldapbis-authmeth-xx.txt b/doc/drafts/draft-ietf-ldapbis-authmeth-xx.txt
deleted file mode 100644
index 966dde24fb4911bccddbc36fffa490619a6322a8..0000000000000000000000000000000000000000
--- a/doc/drafts/draft-ietf-ldapbis-authmeth-xx.txt
+++ /dev/null
@@ -1,1937 +0,0 @@
-
-INTERNET-DRAFT Editor: R. Harrison
-draft-ietf-ldapbis-authmeth-19.txt Novell, Inc.
-Obsoletes: 2251, 2829, 2830 February 2006
-Intended Category: Standards Track
-
-
-
-
-
-
-
- LDAP: Authentication Methods
- and
- Security Mechanisms
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor as a Standard Track document.
- Distribution of this memo is unlimited. Technical discussion of
- this document will take place on the IETF LDAP Revision Working
- Group mailing list <ietf-ldapbis@OpenLDAP.org>. Please send
- editorial comments directly to the author
- <roger_harrison@novell.com>.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six
- months and may be updated, replaced, or obsoleted by other documents
- at any time. It is inappropriate to use Internet-Drafts as
- reference material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
-Abstract
-
- This document describes authentication methods and security
- mechanisms of the Lightweight Directory Access Protocol (LDAP).
-
-
-
-Harrison Expires August 2006 [Page 1]
-
-Internet-Draft LDAP Authentication Methods February 2006
-
- This document details establishment of Transport Layer Security
- (TLS) using the StartTLS operation.
-
- This document details the simple Bind authentication method
- including anonymous, unauthenticated, and name/password mechanisms
- and the Simple Authentication and Security Layer (SASL) Bind
- authentication method including the EXTERNAL mechanism.
-
- This document discusses various authentication and authorization
- states through which a session to an LDAP server may pass and the
- actions that trigger these state changes.
-
- This document, together with other documents in the LDAP Technical
- Specification (see section 1 of [Roadmap]), obsoletes RFC 2251, RFC
- 2829 and RFC 2830.
-
-Table of Contents
-
- 1. Introduction.....................................................3
- 1.1. Relationship to Other Documents................................5
- 1.2. Conventions....................................................6
- 2. Implementation Requirements......................................7
- 3. StartTLS Operation...............................................7
- 3.1. TLS Establishment Procedures...................................7
- 3.1.1. StartTLS Request Sequencing..................................8
- 3.1.2. Client Certificate...........................................8
- 3.1.3. Server Identity Check........................................8
- 3.1.3.1. Comparison of DNS Names...................................10
- 3.1.3.2. Comparison of IP Addresses................................10
- 3.1.3.3. Comparison of other subjectName types.....................10
- 3.1.4. Discovery of Resultant Security Level.......................10
- 3.1.5. Refresh of Server Capabilities Information..................11
- 3.2. Effect of TLS on Authorization State..........................11
- 3.3. TLS Ciphersuites..............................................11
- 4. Authorization State.............................................12
- 5. Bind Operation..................................................13
- 5.1. Simple Authentication Method..................................13
- 5.1.1. Anonymous Authentication Mechanism of Simple Bind...........13
- 5.1.2. Unauthenticated Authentication Mechanism of Simple Bind.....13
- 5.1.3. Name/Password Authentication Mechanism of Simple Bind.......14
- 5.2. SASL Authentication Method....................................15
- 5.2.1. SASL Protocol Profile.......................................15
- 5.2.1.1. SASL Service Name for LDAP................................15
- 5.2.1.2. SASL Authentication Initiation and Protocol Exchange......15
- 5.2.1.3. Optional Fields...........................................16
- 5.2.1.4. Octet Where Negotiated Security Layers Take Effect........17
- 5.2.1.5. Determination of Supported SASL Mechanisms................17
- 5.2.1.6. Rules for Using SASL Layers...............................17
- 5.2.1.7. Support for Multiple Authentications......................18
- 5.2.1.8. SASL Authorization Identities.............................18
- 5.2.2. SASL Semantics Within LDAP..................................19
-
-Harrison Expires August 2006 [Page 2]
-
-Internet-Draft LDAP Authentication Methods February 2006
-
- 5.2.3. SASL EXTERNAL Authentication Mechanism......................19
- 5.2.3.1. Implicit Assertion........................................19
- 5.2.3.2. Explicit Assertion........................................20
- 6. Security Considerations.........................................20
- 6.1. General LDAP Security Considerations..........................20
- 6.2. StartTLS Security Considerations..............................21
- 6.3. Bind Operation Security Considerations........................21
- 6.3.1. Unauthenticated Mechanism Security Considerations...........21
- 6.3.2. Name/Password Mechanism Security Considerations.............22
- 6.3.3. Password-related Security Considerations....................22
- 6.3.4. Hashed Password Security Considerations.....................23
- 6.4.SASL Security Considerations...................................23
- 6.5. Related Security Considerations...............................23
- 7. IANA Considerations.............................................24
- 8. Acknowledgments.................................................24
- 9. Normative References............................................24
- 10. Informative References.........................................25
- Author's Address...................................................26
- Appendix A. Authentication and Authorization Concepts..............26
- A.1. Access Control Policy.........................................26
- A.2. Access Control Factors........................................26
- A.3. Authentication, Credentials, Identity.........................27
- A.4. Authorization Identity........................................27
- Appendix B. Summary of Changes.....................................27
- B.1. Changes Made to RFC 2251......................................28
- B.1.1. Section 4.2.1 (Sequencing of the Bind Request)..............28
- B.1.2. Section 4.2.2 (Authentication and Other Security Services)..28
- B.2. Changes Made to RFC 2829......................................28
- B.2.1. Section 4 (Required security mechanisms)....................29
- B.2.2. Section 5.1 (Anonymous authentication procedure)............29
- B.2.3. Section 6 (Password-based authentication)...................29
- B.2.4. Section 6.1 (Digest authentication).........................29
- B.2.5. Section 6.2 ("simple" authentication choice with TLS).......29
- B.2.6. Section 6.3 (Other authentication choices with TLS).........29
- B.2.7. Section 7.1 (Certificate-based authentication with TLS).....30
- B.2.8. Section 8 (Other mechanisms)................................30
- B.2.9. Section 9 (Authorization identity)..........................30
- B.2.10. Section 10 (TLS Ciphersuites)..............................30
- B.3. Changes Made to RFC 2830: ....................................30
- B.3.1. Section 3.6 (Server Identity Check).........................30
- B.3.2. Section 3.7 (Refresh of Server Capabilities Information)....31
- B.3.3. Section 5.2 (Effects of TLS on Authorization Identity)......31
- B.3.4. Section 5.1.1 (TLS Closure Effects).........................31
- Appendix C. Changes for draft-ldapbis-authmeth-19..................31
- Intellectual Property Rights.......................................32
- Full Copyright Statement...........................................33
-
-
-1. Introduction
-
-
-Harrison Expires August 2006 [Page 3]
-
-Internet-Draft LDAP Authentication Methods February 2006
-
- The Lightweight Directory Access Protocol (LDAP) [Roadmap] is a
- powerful protocol for accessing directories. It offers means of
- searching, retrieving and manipulating directory content and ways to
- access a rich set of security functions.
-
- It is vital that these security functions be interoperable among all
- LDAP clients and servers on the Internet; therefore there has to be
- a minimum subset of security functions that is common to all
- implementations that claim LDAP conformance.
-
- Basic threats to an LDAP directory service include (but are not
- limited to):
-
- (1) Unauthorized access to directory data via data-retrieval
- operations.
-
- (2) Unauthorized access to directory data by monitoring access of
- others.
-
- (3) Unauthorized access to reusable client authentication
- information by monitoring access of others.
-
- (4) Unauthorized modification of directory data.
-
- (5) Unauthorized modification of configuration information.
-
- (6) Denial of Service: Use of resources (commonly in excess) in a
- manner intended to deny service to others.
-
- (7) Spoofing: Tricking a user or client into believing that
- information came from the directory when in fact it did not,
- either by modifying data in transit or misdirecting the client's
- transport connection. Tricking a user or client into sending
- privileged information to a hostile entity that appears to be
- the directory server but is not. Tricking a directory server
- into believing that information came from a particular client
- when in fact it came from a hostile entity.
-
- (8) Hijacking: An attacker seizes control of an established protocol
- session.
-
- Threats (1), (4), (5), (6), (7) are (8) are active attacks. Threats
- (2) and (3) are passive attacks.
-
- Threats (1), (4), (5) and (6) are due to hostile clients. Threats
- (2), (3), (7) and (8) are due to hostile agents on the path between
- client and server or hostile agents posing as a server, e.g., IP
- spoofing.
-
- LDAP offers the following security mechanisms:
-
-
-
-
-
-Harrison Expires August 2006 [Page 4]
-
-Internet-Draft LDAP Authentication Methods February 2006
-
- (1) Authentication by means of the Bind operation. The Bind
- operation provides a simple method which supports anonymous,
- unauthenticated, and name/password mechanisms, and the Simple
- Authentication and Security Layer (SASL) method which supports a
- wide variety of authentication mechanisms.
-
- (2) Mechanisms to support vendor-specific access control facilities
- (LDAP does not offer a standard access control facility).
-
- (3) Data integrity service by means of security layers in Transport
- Layer Security (TLS) or SASL mechanisms.
-
- (4) Data confidentiality service by means of security layers in TLS
- or SASL mechanisms.
-
- (5) Server resource usage limitation by means of administrative
- limits configured on the server.
-
- (6) Server authentication by means of the TLS protocol or SASL
- mechanisms.
-
- LDAP may also be protected by means outside the LDAP protocol, e.g.,
- with IP-level security [RFC4301].
-
- Experience has shown that simply allowing implementations to pick
- and choose the security mechanisms that will be implemented is not a
- strategy that leads to interoperability. In the absence of
- mandates, clients will continue to be written that do not support
- any security function supported by the server, or worse, they will
- only support mechanisms that provide inadequate security for most
- circumstances.
-
- It is desirable to allow clients to authenticate using a variety of
- mechanisms including mechanisms where identities are represented as
- distinguished names [X.501][Models] in string form [LDAPDN] or as
- used in different systems (e.g., simple user names [RFC4013]).
- Because some authentication mechanisms transmit credentials in plain
- text form, and/or do not provide data security services and/or are
- subject to passive attacks, it is necessary to ensure secure
- interoperability by identifying a mandatory-to-implement mechanism
- for establishing transport-layer security services.
-
- The set of security mechanisms provided in LDAP and described in
- this document is intended to meet the security needs for a wide
- range of deployment scenarios and still provide a high degree of
- interoperability among various LDAP implementations and deployments.
-
-1.1. Relationship to Other Documents
-
- This document is an integral part of the LDAP Technical
- Specification [Roadmap].
-
-
-
-
-Harrison Expires August 2006 [Page 5]
-
-Internet-Draft LDAP Authentication Methods February 2006
-
- This document, together with [Roadmap], [Protocol], and [Models],
- obsoletes RFC 2251 in its entirety. Sections 4.2.1 (portions), and
- 4.2.2 of RFC 2251 are obsoleted by this document. Appendix B.1
- summarizes the substantive changes made to RFC 2251 by this document.
-
- This document obsoletes RFC 2829 in its entirety. Appendix B.2
- summarizes the substantive changes made to RFC 2829 by this document.
-
- Sections 2 and 4 of RFC 2830 are obsoleted by [Protocol]. The
- remainder of RFC 2830 is obsoleted by this document. Appendix B.3
- summarizes the substantive changes made to RFC 2830 by this document.
-
-
-1.2. Conventions
-
- The key words "MUST", "MUST NOT", "SHALL", "SHOULD", "SHOULD NOT",
- "MAY", and "OPTIONAL" in this document are to be interpreted as
- described in RFC 2119 [RFC2119].
-
- The term "user" represents any human or application entity which is
- accessing the directory using a directory client. A directory
- client (or client) is also known as a directory user agent (DUA).
-
- The term "transport connection" refers to the underlying transport
- services used to carry the protocol exchange, as well as
- associations established by these services.
-
- The term "TLS layer" refers to TLS services used in providing
- security services, as well as associations established by these
- services.
-
- The term "SASL layer" refers to SASL services used in providing
- security services, as well as associations established by these
- services.
-
- The term "LDAP message layer" refers to the LDAP Message (PDU)
- services used in providing directory services, as well as
- associations established by these services.
-
- The term "LDAP session" refers to combined services (transport
- connection, TLS layer, SASL layer, LDAP message layer) and their
- associations.
-
- In general, security terms in this document are used consistently
- with the definitions provided in [RFC2828]. In addition, several
- terms and concepts relating to security, authentication, and
- authorization are presented in Appendix A of this document. While
- the formal definition of these terms and concepts is outside the
- scope of this document, an understanding of them is prerequisite to
- understanding much of the material in this document. Readers who
- are unfamiliar with security-related concepts are encouraged to
- review Appendix A before reading the remainder of this document.
-
-
-
-Harrison Expires August 2006 [Page 6]
-
-Internet-Draft LDAP Authentication Methods February 2006
-
-2. Implementation Requirements
-
- LDAP server implementations MUST support the anonymous
- authentication mechanism of the simple Bind method (section 5.1.1).
-
- LDAP implementations that support any authentication mechanism other
- than the anonymous authentication mechanism of the simple Bind
- method MUST support the name/password authentication mechanism of
- the simple Bind method (section 5.1.3) and MUST be capable of
- protecting this name/password authentication using TLS as
- established by the StartTLS operation (section 3).
-
- Implementations SHOULD disallow the use of the name/password
- authentication mechanism by default when suitable data security
- services are not in place, and MAY provide other suitable data
- security services for use with this authentication mechanism.
-
- Implementations MAY support additional authentication mechanisms.
- Some of these mechanisms are discussed below.
-
- LDAP server implementations SHOULD support client assertion of
- authorization identity via the SASL EXTERNAL mechanism (section
- 5.2.3).
-
- LDAP server implementations that support no authentication mechanism
- other than the anonymous mechanism of the simple bind method SHOULD
- support use of TLS as established by the the StartTLS operation
- (section 3). (Other servers MUST support TLS per the second
- paragraph of this section.)
-
- Implementations supporting TLS MUST support the
- TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite and SHOULD support the
- TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite. Support for the
- latter ciphersuite is recommended to encourage interoperability with
- implementations conforming to earlier LDAP StartTLS specifications.
-
-
-3. StartTLS Operation
-
- The Start Transport Layer Security (StartTLS) operation defined in
- section 4.14 of [Protocol] provides the ability to establish TLS
- [TLS] in an LDAP session.
-
- The goals of using the TLS [TLS] protocol with LDAP are to ensure
- data confidentiality and integrity, and to optionally provide for
- authentication. TLS expressly provides these capabilities, although
- the authentication services of TLS are available to LDAP only in
- combination with the SASL EXTERNAL authentication method (see
- section 5.2.3), and then only if the SASL EXTERNAL implementation
- chooses to make use of the TLS credentials.
-
-
-3.1. TLS Establishment Procedures
-
-
-Harrison Expires August 2006 [Page 7]
-
-Internet-Draft LDAP Authentication Methods February 2006
-
- This section describes the overall procedures clients and servers
- must follow for TLS establishment. These procedures take into
- consideration various aspects of the TLS layer including discovery
- of resultant security level and assertion of the client's
- authorization identity.
-
-
-3.1.1. StartTLS Request Sequencing
-
- A client may send the StartTLS extended request at any time after
- establishing an LDAP session, except:
-
- - when TLS is currently established on the session,
- - when a multi-stage SASL negotiation is in progress on the
- session, or
- - when there are outstanding responses for operation requests
- previously issued on the session.
-
- As described in [Protocol] Section 4.14.1, a (detected) violation of
- any of these requirements results in a return of the operationsError
- resultCode.
-
- Client implementers should ensure that they strictly follow these
- operation sequencing requirements to prevent interoperability
- issues. Operational experience has shown that violating these
- requirements causes interoperability issues because there are race
- conditions that prevent servers from detecting some violations of
- these requirements due to factors such as server hardware speed and
- network latencies.
-
- There is no general requirement that the client have or have not
- already performed a Bind operation (section 5) before sending a
- StartTLS operation request, however where a client intends to
- perform both a Bind operation and a StartTLS operation, it SHOULD
- first perform the StartTLS operation so that the Bind request and
- response messages are protected by the data security services
- established by the StartTLS operation.
-
-
-3.1.2. Client Certificate
-
- If an LDAP server requests or demands that a client provide a user
- certificate during TLS negotiation and the client does not present a
- suitable user certificate (e.g., one that can be validated), the
- server may use a local security policy to determine whether to
- successfully complete TLS negotiation.
-
- If a client that has provided a suitable certificate subsequently
- performs a Bind operation using the SASL EXTERNAL authentication
- mechanism (section 5.2.3), information in the certificate may be
- used by the server to identify and authenticate the client.
-
-
-3.1.3. Server Identity Check
-
-Harrison Expires August 2006 [Page 8]
-
-Internet-Draft LDAP Authentication Methods February 2006
-
-
- In order to prevent man-in-the-middle attacks the client MUST verify
- the server's identity (as presented in the server's Certificate
- message). In this section, the client's understanding of the
- server's identity (typically the identity used to establish the
- transport connection) is called the "reference identity".
-
- The client determines the type (e.g., DNS name or IP address) of the
- reference identity and performs a comparison between the reference
- identity and each subjectAltName value of the corresponding type
- until a match is produced. Once a match is produced, the server's
- identity has been verified and the server identity check is
- complete. Different subjectAltName types are matched in different
- ways. Sections 3.1.3.1 - 3.1.3.3 explain how to compare values of
- various subjectAltName types.
-
- The client may map the reference identity to a different type prior
- to performing a comparison. Mappings may be performed for all
- available subjectAltName types to which the reference identity can
- be mapped, however the reference identity should only be mapped to
- types for which the mapping is either inherently secure (e.g.,
- extracting the DNS name from a URI to compare with a subjectAltName
- of type dNSName) or for which the mapping is performed in a secure
- manner (e.g., using DNSSec, or using user- (or admin-) configured
- host-to-address/address-to-host lookup tables).
-
- The server's identity may also be verified by comparing the
- reference identity to the Common Name (CN) [Schema] value in the
- leaf RDN of the subjectName field of the server's certificate. This
- comparison is performed using the rules for comparison of DNS names
- in section 3.1.3.1 below, with the exception that no wildcard
- matching is allowed. Although the use of the Common Name value is
- existing practice, it is deprecated and Certification Authorities
- are encouraged to provide subjectAltName values instead. Note that
- the TLS implementation may represent DNs in certificates according
- to X.500 or other conventions. For example, some X.500
- implementations order the RDNs in a DN using a left-to-right (most
- significant to least significant) convention instead of LDAP's
- right-to-left convention.
-
- If the server identity check fails, user-oriented clients SHOULD
- either notify the user (clients may give the user the opportunity to
- continue with the LDAP session in this case) or close the transport
- connection and indicate that the server's identity is suspect.
- Automated clients SHOULD close the transport connection and then
- return or log an error indicating that the server's identity is
- suspect or both.
-
- Beyond the server identity check described in this section, clients
- should be prepared to do further checking to ensure that the server
- is authorized to provide the service it is requested to provide.
- The client may need to make use of local policy information in
- making this determination.
-
-
-Harrison Expires August 2006 [Page 9]
-
-Internet-Draft LDAP Authentication Methods February 2006
-
-
-3.1.3.1. Comparison of DNS Names
-
- If the reference identity is an internationalized domain name,
- conforming implementations MUST convert it to the ASCII Compatible
- Encoding (ACE) format as specified in section 4 of RFC 3490
- [RFC3490] before comparison with subjectAltName values of type
- dNSName. Specifically, conforming implementations MUST perform the
- conversion operation specified in section 4 of RFC 3490 as follows:
-
- * in step 1, the domain name SHALL be considered a "stored
- string";
- * in step 3, set the flag called "UseSTD3ASCIIRules";
- * in step 4, process each label with the "ToASCII"
- operation; and
- * in step 5, change all label separators to U+002E (full
- stop).
-
- After performing the "to-ASCII" conversion, the DNS labels and names
- MUST be compared for equality according to the rules specified in
- section 3 of RFC3490.
-
- The '*' (ASCII 42) wildcard character is allowed in subjectAltName
- values of type dNSName and then only as the left-most (least
- significant) DNS label in that value. This wildcard matches any
- left-most DNS label in the server name. That is, the subject
- *.example.com matches the server names a.example.com and
- b.example.com but does not match example.com or a.b.example.com.
-
-
-3.1.3.2. Comparison of IP Addresses
-
- When the reference identity is an IP address, the identity MUST be
- converted to the "network byte order" octet string representation
- [RFC791][RFC2460]. For IP Version 4, as specified in RFC 791, the
- octet string will contain exactly four octets. For IP Version 6, as
- specified in RFC 2460, the octet string will contain exactly sixteen
- octets. This octet string is then compared against subjectAltName
- values of type iPAddress. A match occurs if the reference identity
- octet string and value octet strings are identical.
-
-
-3.1.3.3. Comparison of other subjectName types
-
- Client implementations MAY support matching against subjectAltName
- values of other types as described in other documents.
-
-
-3.1.4. Discovery of Resultant Security Level
-
-
-
-
-
-
-Harrison Expires August 2006 [Page 10]
-
-Internet-Draft LDAP Authentication Methods February 2006
-
- After a TLS layer is established in an LDAP session, both parties
- are to each independently decide whether or not to continue based on
- local policy and the security level achieved. If either party
- decides that the security level is inadequate for it to continue, it
- SHOULD remove the TLS layer immediately after the TLS
- (re)negotiation has completed (see [Protocol] section 4.14.3 and
- section 3.2 below). Implementations may reevaluate the security
- level at any time and, upon finding it inadequate, should remove the
- TLS layer.
-
-
-3.1.5. Refresh of Server Capabilities Information
-
- After a TLS layer is established in an LDAP session, the client
- SHOULD discard or refresh all information about the server it
- obtained prior to the initiation of the TLS negotiation and not
- obtained through secure mechanisms. This protects against man-in-
- the-middle attacks that may have altered any server capabilities
- information retrieved prior to TLS layer installation.
-
- The server may advertise different capabilities after installing a
- TLS layer. In particular, the value of 'supportedSASLMechanisms'
- may be different after a TLS layer has been installed (specifically,
- the EXTERNAL and PLAIN [PLAIN] mechanisms are likely to be listed
- only after a TLS layer has been installed).
-
-
-3.2. Effect of TLS on Authorization State
-
- The establishment, change, and/or closure of TLS may cause the
- authorization state to move to a new state. This is discussed
- further in Section 4.
-
-
-3.3. TLS Ciphersuites
-
- Several issues should be considered when selecting TLS ciphersuites
- that are appropriate for use in a given circumstance. These issues
- include the following:
-
- - The ciphersuite's ability to provide adequate confidentiality
- protection for passwords and other data sent over the transport
- connection. Client and server implementers should recognize
- that some TLS ciphersuites provide no confidentiality protection
- while other ciphersuites that do provide confidentiality
- protection may be vulnerable to being cracked using brute force
- methods, especially in light of ever-increasing CPU speeds that
- reduce the time needed to successfully mount such attacks.
-
- - Client and server implementers should carefully consider the
- value of the password or data being protected versus the level
- of confidentiality protection provided by the ciphersuite to
- ensure that the level of protection afforded by the ciphersuite
- is appropriate.
-
-Harrison Expires August 2006 [Page 11]
-
-Internet-Draft LDAP Authentication Methods February 2006
-
-
- - The ciphersuite's vulnerability (or lack thereof) to man-in-the-
- middle attacks. Ciphersuites vulnerable to man-in-the-middle
- attacks SHOULD NOT be used to protect passwords or sensitive
- data, unless the network configuration is such that the danger
- of a man-in-the-middle attack is negligible.
-
- - After a TLS negotiation (either initial or subsequent) is
- completed, both protocol peers should independently verify that
- the security services provided by the negotiated ciphersuite are
- adequate for the intended use of the LDAP session. If not, the
- TLS layer should be closed.
-
-
-4. Authorization State
-
- Every LDAP session has an associated authorization state. This
- state is comprised of numerous factors such as what (if any)
- authorization state has been established, how it was established,
- and what security services are in place. Some factors may be
- determined and/or affected by protocol events (e.g., Bind, StartTLS,
- or TLS closure), and some factors may be determined by external
- events (e.g., time of day or server load).
-
- While it is often convenient to view authorization state in
- simplistic terms (as we often do in this technical specification)
- such as "an anonymous state", it is noted that authorization systems
- in LDAP implementations commonly involve many factors which
- interrelate in complex manners.
-
- Authorization in LDAP is a local matter. One of the key factors in
- making authorization decisions is authorization identity. The Bind
- operation defined in section 4.2 of [Protocol] and discussed further
- in section 5 below allows information to be exchanged between the
- client and server to establish an authorization identity for the
- LDAP session. The Bind operation may also be used to move the LDAP
- session to an anonymous authorization state (see section 5.1.1).
-
- Upon initial establishment of the LDAP session, the session has an
- anonymous authorization identity. Among other things this implies
- that the client need not send a BindRequest in the first PDU of the
- LDAP message layer. The client may send any operation request prior
- to performing a Bind operation, and the server MUST treat it as if
- it had been performed after an anonymous Bind operation (section
- 5.1.1).
-
- Upon receipt of a Bind request, the server immediately moves the
- session to an anonymous authorization state. If the Bind request is
- successful, the session is moved to the requested authentication
- state with its associated authorization state. Otherwise, the
- session remains in an anonymous state.
-
-
-
-
-Harrison Expires August 2006 [Page 12]
-
-Internet-Draft LDAP Authentication Methods February 2006
-
- It is noted that other events both internal and external to LDAP may
- result in the authentication and authorization states being moved to
- an anonymous one. For instance, the establishment, change or
- closure of data security services may result in a move to an
- anonymous state, or the user's credential information (e.g.,
- certificate) may have expired. The former is an example of an event
- internal to LDAP whereas the latter is an example of an event
- external to LDAP.
-
-
-5. Bind Operation
-
- The Bind operation ([Protocol] section 4.2) allows authentication
- information to be exchanged between the client and server to
- establish a new authorization state.
-
- The Bind request typically specifies the desired authentication
- identity. Some Bind mechanisms also allow the client to specify the
- authorization identity. If the authorization identity is not
- specified, the server derives it from the authentication identity in
- an implementation-specific manner.
-
- If the authorization identity is specified, the server MUST verify
- that the client's authentication identity is permitted to assume
- (e.g., proxy for) the asserted authorization identity. The server
- MUST reject the Bind operation with an invalidCredentials resultCode
- in the Bind response if the client is not so authorized.
-
-
-5.1. Simple Authentication Method
-
- The simple authentication method of the Bind Operation provides
- three authentication mechanisms:
-
- - An anonymous authentication mechanism (section 5.1.1).
-
- - An unauthenticated authentication mechanism (section 5.1.2).
-
- - A name/password authentication mechanism using credentials
- consisting of a name (in the form of an LDAP distinguished name
- [LDAPDN]) and a password (section 5.1.3).
-
-
-5.1.1. Anonymous Authentication Mechanism of Simple Bind
-
- An LDAP client may use the anonymous authentication mechanism of the
- simple Bind method to explicitly establish an anonymous
- authorization state by sending a Bind request with a name value of
- zero length and specifying the simple authentication choice
- containing a password value of zero length.
-
-
-5.1.2. Unauthenticated Authentication Mechanism of Simple Bind
-
-
-Harrison Expires August 2006 [Page 13]
-
-Internet-Draft LDAP Authentication Methods February 2006
-
- An LDAP client may use the unauthenticated authentication mechanism
- of the simple Bind method to establish an anonymous authorization
- state by sending a Bind request with a name value (a distinguished
- name in LDAP string form [LDAPDN] of non-zero length) and specifying
- the simple authentication choice containing a password value of zero
- length.
-
- The distinguished name value provided by the client is intended to
- be used for trace (e.g., logging) purposes only. The value is not
- to be authenticated or otherwise validated (including verification
- that the DN refers to an existing directory object). The value is
- not to be used (directly or indirectly) for authorization purposes.
-
- Unauthenticated Bind operations can have significant security issues
- (see section 6.3.1). In particular, users intending to perform
- Name/Password Authentication may inadvertently provide an empty
- password and thus cause poorly implemented clients to request
- Unauthenticated access. Clients SHOULD be implemented to require
- user selection of the Unauthenticated Authentication Mechanism by
- means other than user input of an empty password. Clients SHOULD
- disallow an empty password input to a Name/Password Authentication
- user interface. Additionally, Servers SHOULD by default fail
- Unauthenticated Bind requests with a resultCode of
- unwillingToPerform.
-
-
-5.1.3. Name/Password Authentication Mechanism of Simple Bind
-
- An LDAP client may use the name/password authentication mechanism of
- the simple Bind method to establish an authenticated authorization
- state by sending a Bind request with a name value (a distinguished
- name in LDAP string form [LDAPDN] of non-zero length) and specifying
- the simple authentication choice containing an OCTET STRING password
- value of non-zero length.
-
- Servers that map the DN sent in the Bind request to a directory
- entry with an associated set of one or more passwords used with this
- mechanism will compare the presented password to that set of
- passwords. The presented password is considered valid if it matches
- any member of this set.
-
- A resultCode of invalidDNSyntax indicates that the DN sent in the
- name value is syntactically invalid. A resultCode of
- invalidCredentials indicates that the DN is syntactically correct
- but not valid for purposes of authentication, or the password is not
- valid for the DN or the server otherwise considers the credentials
- to be invalid. A resultCode of success indicates that the
- credentials are valid and the server is willing to provide service
- to the entity these credentials identify.
-
- Server behavior is undefined for Bind requests specifying the
- name/password authentication mechanism with a zero-length name value
- and a password value of non-zero length.
-
-
-Harrison Expires August 2006 [Page 14]
-
-Internet-Draft LDAP Authentication Methods February 2006
-
- The name/password authentication mechanism of the simple Bind method
- is not suitable for authentication in environments without
- confidentiality protection.
-
-
-5.2. SASL Authentication Method
-
- The sasl authentication method of the Bind Operation provides
- facilities for using any SASL mechanism including authentication
- mechanisms and other services (e.g., data security services).
-
-
-5.2.1. SASL Protocol Profile
-
- LDAP allows authentication via any SASL mechanism [SASL]. As LDAP
- includes native anonymous and name/password (plain text)
- authentication methods, the ANONYMOUS [ANONYMOUS] and PLAIN [PLAIN]
- SASL mechanisms are typically not used with LDAP.
-
- Each protocol that utilizes SASL services is required to supply
- certain information profiling the way they are exposed through the
- protocol ([SASL] section 4). This section explains how each of
- these profiling requirements are met by LDAP.
-
-
-5.2.1.1. SASL Service Name for LDAP
-
- The SASL service name for LDAP is "ldap", which has been registered
- with the IANA as a SASL service name.
-
-
-5.2.1.2. SASL Authentication Initiation and Protocol Exchange
-
- SASL authentication is initiated via a BindRequest message
- ([Protocol] section 4.2) with the following parameters:
-
- - The version is 3.
- - The AuthenticationChoice is sasl.
- - The mechanism element of the SaslCredentials sequence contains
- the value of the desired SASL mechanism.
- - The optional credentials field of the SaslCredentials sequence
- MAY be used to provide an initial client response for
- mechanisms that are defined to have the client send data first
- (see [SASL] sections 3 and 5 ).
-
-
-
-
-
-
-
-
-
-
-
-Harrison Expires August 2006 [Page 15]
-
-Internet-Draft LDAP Authentication Methods February 2006
-
- In general, a SASL authentication protocol exchange consists of a
- series of server challenges and client responses, the contents of
- which are specific to and defined by the SASL mechanism. Thus for
- some SASL authentication mechanisms, it may be necessary for the
- client to respond to one or more server challenges by sending
- BindRequest messages multiple times. A challenge is indicated by
- the server sending a BindResponse message with the resultCode set to
- saslBindInProgress. This indicates that the server requires the
- client to send a new BindRequest message with the same SASL
- mechanism to continue the authentication process.
-
- To the LDAP message layer, these challenges and responses are opaque
- binary tokens of arbitrary length. LDAP servers use the
- serverSaslCreds field (an OCTET STRING) in a BindResponse message to
- transmit each challenge. LDAP clients use the credentials field
- (an OCTET STRING) in the SaslCredentials sequence of a BindRequest
- message to transmit each response. Note that unlike some Internet
- protocols where SASL is used, LDAP is not text based and does not
- Base64-transform these challenge and response values.
-
- Clients sending a BindRequest message with the sasl choice selected
- SHOULD send a zero-length value in the name field. Servers
- receiving a BindRequest message with the sasl choice selected SHALL
- ignore any value in the name field.
-
- A client may abort a SASL Bind negotiation by sending a BindRequest
- message with a different value in the mechanism field of
- SaslCredentials or with an AuthenticationChoice other than sasl.
-
- If the client sends a BindRequest with the sasl mechanism field as
- an empty string, the server MUST return a BindResponse with a
- resultCode of authMethodNotSupported. This will allow the client to
- abort a negotiation if it wishes to try again with the same SASL
- mechanism.
-
- The server indicates completion of the SASL challenge-response
- exchange by responding with a BindResponse in which the resultCode
- value is not saslBindInProgress.
-
- The serverSaslCreds field in the BindResponse can be used to include
- an optional challenge with a success notification for mechanisms
- which are defined to have the server send additional data along with
- the indication of successful completion.
-
-
-5.2.1.3. Optional Fields
-
- As discussed above, LDAP provides an optional field for carrying an
- initial response in the message initiating the SASL exchange and
- provides an optional field for carrying additional data in the
- message indicating outcome of the authentication exchange. As the
- mechanism-specific content in these fields may be zero-length, SASL
- requires protocol specifications to detail how an empty field is
- distinguished from an absent field.
-
-Harrison Expires August 2006 [Page 16]
-
-Internet-Draft LDAP Authentication Methods February 2006
-
-
- Zero-length initial response data is distinguished from no initial
- response data in the initiating message, a BindRequest PDU, by the
- presence of the SaslCredentials.credentials OCTET STRING (of length
- zero) in that PDU. If the client does not intend to send an
- initial response with the BindRequest initiating the SASL exchange,
- it MUST omit the SaslCredentials.credentials OCTET STRING (rather
- than including an zero-length OCTET STRING).
-
- Zero-length additional data is distinguished from no additional
- response data in the outcome message, a BindResponse PDU, by the
- presence of the serverSaslCreds OCTET STRING (of length zero) in
- that PDU. If a server does not intend to send additional data in
- the BindResponse message indicating outcome of the exchange, the
- server SHALL omit the serverSaslCreds OCTET STRING (rather than
- including a zero-length OCTET STRING).
-
-
-5.2.1.4. Octet Where Negotiated Security Layers Take Effect
-
- SASL layers take effect following the transmission by the server and
- reception by the client of the final BindResponse in the SASL
- exchange with a resultCode of success.
-
- Once a SASL layer providing data integrity or confidentiality
- services takes effect, the layer remains in effect until a new layer
- is installed (i.e. at the first octet following the final
- BindResponse of the Bind operation that caused the new layer to take
- effect). Thus, an established SASL layer is not affected by a
- failed or non-SASL Bind.
-
-
-5.2.1.5. Determination of Supported SASL Mechanisms
-
- Clients may determine the SASL mechanisms a server supports by
- reading the 'supportedSASLMechanisms' attribute from the root DSE
- (DSA-Specific Entry) ([Models] section 5.1). The values of this
- attribute, if any, list the mechanisms the server supports in the
- current LDAP session state. LDAP servers SHOULD allow all clients--
- even those with an anonymous authorization--to retrieve the
- 'supportedSASLMechanisms' attribute of the root DSE both before and
- after the SASL authentication exchange. The purpose of the latter
- is to allow the client to detect possible downgrade attacks (see
- section 6.4 and [SASL] section 6.1.2).
-
- Because SASL mechanisms provide critical security functions, clients
- and servers should be configurable to specify what mechanisms are
- acceptable and allow only those mechanisms to be used. Both clients
- and servers must confirm that the negotiated security level meets
- their requirements before proceeding to use the session.
-
-
-5.2.1.6. Rules for Using SASL Layers
-
-
-Harrison Expires August 2006 [Page 17]
-
-Internet-Draft LDAP Authentication Methods February 2006
-
- Upon installing a SASL layer, the client SHOULD discard or refresh
- all information about the server it obtained prior to the initiation
- of the SASL negotiation and not obtained through secure mechanisms.
-
- If a lower level security layer (such as TLS) is installed, any SASL
- layer SHALL be layered on top of such security layers regardless of
- the order of their negotiation. In all other respects, the SASL
- layer and other security layers act independently, e.g., if both a
- TLS layer and a SASL layer are in effect then removing the TLS layer
- does not affect the continuing service of the SASL layer.
-
-
-5.2.1.7. Support for Multiple Authentications
-
- LDAP supports multiple SASL authentications as defined in [SASL]
- section 4.
-
-
-5.2.1.8. SASL Authorization Identities
-
- Some SASL mechanisms allow clients to request a desired
- authorization identity for the LDAP session ([SASL] section 3.4.
- The decision to allow or disallow the current authentication
- identity to have access to the requested authorization identity is a
- matter of local policy. The authorization identity is a string of
- UTF-8 [RFC3629] encoded [Unicode] characters corresponding to the
- following ABNF [RFC2234bis] grammar:
-
- authzId = dnAuthzId / uAuthzId
-
- ; distinguished-name-based authz id
- dnAuthzId = "dn:" distinguishedName
-
- ; unspecified authorization id, UTF-8 encoded
- uAuthzId = "u:" userid
- userid = *UTF8 ; syntax unspecified
-
- where the distinguishedName rule is defined in section 3 of [LDAPDN]
- and the UTF8 rule is defined in section 1.4 of [Models].
-
- The dnAuthzId choice is used to assert authorization identities in
- the form of a distinguished name to be matched in accordance with
- the distinguishedNameMatch matching rule [Syntaxes]. There is no
- requirement that the asserted distinguishedName value be that of an
- entry in the directory.
-
-
-
-
-
-
-
-
-
-
-Harrison Expires August 2006 [Page 18]
-
-Internet-Draft LDAP Authentication Methods February 2006
-
- The uAuthzId choice allows clients to assert an authorization
- identity that is not in distinguished name form. The format of
- userid is defined only as a sequence of UTF-8 [RFC3629] encoded
- [Unicode] characters, and any further interpretation is a local
- matter. For example, the userid could identify a user of a specific
- directory service, be a login name or be an email address. A
- uAuthzId SHOULD NOT be assumed to be globally unique. To compare
- uAuthzID values, each uAuthzID value MUST be prepared as a "query"
- string using [RFC4013] and then the two values are compared octet-
- wise.
-
- The above grammar is extensible. The authzId production may be
- extended to support additional forms of identities. Each form is
- distinguished by its unique prefix (see section 3.12 of [LDAPIANA]
- for registration requirements).
-
-
-5.2.2. SASL Semantics Within LDAP
-
- Implementers must take care to maintain the semantics of SASL
- specifications when handling data that has different semantics in
- the LDAP protocol.
-
- For example, the SASL DIGEST-MD5 authentication mechanism [RFC2829]
- utilizes an authentication identity and a realm which are
- syntactically simple strings and semantically simple username and
- realm values ([DIGEST-MD5] section 2.1). These values are not LDAP
- DNs, and there is no requirement that they be represented or treated
- as such.
-
-
-5.2.3. SASL EXTERNAL Authentication Mechanism
-
- A client can use the SASL EXTERNAL [SASL] mechanism to request the
- LDAP server to authenticate and establish a resulting authorization
- identity using security credentials exchanged by a lower security
- layer (such as by TLS authentication). If the client's
- authentication credentials have not been established at a lower
- security layer, the SASL EXTERNAL Bind MUST fail with a resultCode
- of inappropriateAuthentication. Although this situation has the
- effect of leaving the LDAP session in an anonymous state (section
- 4), the state of any installed security layer is unaffected.
-
- A client may either request that its authorization identity be
- automatically derived from its authentication credentials exchanged
- at a lower security layer or it may explicitly provide a desired
- authorization identity. The former is known as an implicit
- assertion, and the latter as an explicit assertion.
-
-
-5.2.3.1. Implicit Assertion
-
-
-
-
-Harrison Expires August 2006 [Page 19]
-
-Internet-Draft LDAP Authentication Methods February 2006
-
- An implicit authorization identity assertion is performed by
- invoking a Bind request of the SASL form using the EXTERNAL
- mechanism name that does not include the optional credentials field
- (found within the SaslCredentials sequence in the BindRequest). The
- server will derive the client's authorization identity from the
- authentication identity supplied by a security layer (e.g., a public
- key certificate used during TLS layer installation) according to
- local policy. The underlying mechanics of how this is accomplished
- are implementation specific.
-
-
-5.2.3.2. Explicit Assertion
-
- An explicit authorization identity assertion is performed by
- invoking a Bind request of the SASL form using the EXTERNAL
- mechanism name that includes the credentials field (found within the
- SaslCredentials sequence in the BindRequest). The value of the
- credentials field (an OCTET STRING) is the asserted authorization
- identity and MUST be constructed as documented in section 5.2.1.8.
-
-
-6. Security Considerations
-
- Security issues are discussed throughout this document. The
- unsurprising conclusion is that security is an integral and
- necessary part of LDAP. This section discusses a number of LDAP-
- related security considerations.
-
-
-6.1. General LDAP Security Considerations
-
- LDAP itself provides no security or protection from accessing or
- updating the directory by other means than through the LDAP
- protocol, e.g., from inspection of server database files by database
- administrators.
-
- Sensitive data may be carried in almost any LDAP message and its
- disclosure may be subject to privacy laws or other legal regulation
- in many countries. Implementers should take appropriate measures to
- protect sensitive data from disclosure to unauthorized entities.
-
- A session on which the client has not established data integrity and
- privacy services (e.g., via StartTLS, IPsec or a suitable SASL
- mechanism) is subject to man-in-the-middle attacks to view and
- modify information in transit. Client and server implementers
- SHOULD take measures to protect sensitive data in the LDAP session
- from these attacks by using data protection services as discussed in
- this document. Clients and servers should provide the ability to be
- configured to require these protections. A resultCode of
- confidentialityRequired indicates that the server requires
- establishment of (stronger) data confidentiality protection in order
- to perform the requested operation.
-
-
-
-Harrison Expires August 2006 [Page 20]
-
-Internet-Draft LDAP Authentication Methods February 2006
-
- Access control should always be applied when reading sensitive
- information or updating directory information.
-
- Various security factors, including authentication and authorization
- information and data security services may change during the course
- of the LDAP session, or even during the performance of a particular
- operation. Implementations should be robust in the handling of
- changing security factors.
-
-
-6.2. StartTLS Security Considerations
-
- All security gained via use of the StartTLS operation is gained by
- the use of TLS itself. The StartTLS operation, on its own, does not
- provide any additional security.
-
- The level of security provided through the use of TLS depends
- directly on both the quality of the TLS implementation used and the
- style of usage of that implementation. Additionally, a man-in-the-
- middle attacker can remove the StartTLS extended operation from the
- 'supportedExtension' attribute of the root DSE. Both parties SHOULD
- independently ascertain and consent to the security level achieved
- once TLS is established and before beginning use of the TLS-
- protected session. For example, the security level of the TLS layer
- might have been negotiated down to plaintext.
-
- Clients MUST either warn the user when the security level achieved
- does not provide an acceptable level of data confidentiality and/or
- data integrity protection, or be configurable to refuse to proceed
- without an acceptable level of security.
-
- As stated in section 3.1.2, a server may use a local security policy
- to determine whether to successfully complete TLS negotiation.
- Information in the user's certificate that is originated or verified
- by the certification authority should be used by the policy
- administrator when configuring the identification and authorization
- policy.
-
- Server implementers SHOULD allow server administrators to elect
- whether and when data confidentiality and integrity are required, as
- well as elect whether authentication of the client during the TLS
- handshake is required.
-
- Implementers should be aware of and understand TLS security
- considerations as discussed in the TLS specification [TLS].
-
-
-6.3. Bind Operation Security Considerations
-
- This section discusses several security considerations relevant to
- LDAP authentication via the Bind operation.
-
-
-6.3.1. Unauthenticated Mechanism Security Considerations
-
-Harrison Expires August 2006 [Page 21]
-
-Internet-Draft LDAP Authentication Methods February 2006
-
-
- Operational experience shows that clients can (and frequently do)
- misuse the unauthenticated authentication mechanism of the simple
- Bind method (see section 5.1.2). For example, a client program
- might make a decision to grant access to non-directory information
- on the basis of successfully completing a Bind operation. LDAP
- server implementations may return a success response to an
- unauthenticated Bind request. This may erroneously leave the client
- with the impression that the server has successfully authenticated
- the identity represented by the distinguished name when in reality,
- an anonymous authorization state has been established. Clients that
- use the results from a simple Bind operation to make authorization
- decisions should actively detect unauthenticated Bind requests (by
- verifying that the supplied password is not empty) and react
- appropriately.
-
-
-6.3.2. Name/Password Mechanism Security Considerations
-
- The name/password authentication mechanism of the simple Bind method
- discloses the password to the server, which is an inherent security
- risk. There are other mechanisms such as SASL DIGEST-MD5 [RFC2829]
- that do not disclose the password to the server.
-
-
-6.3.3. Password-related Security Considerations
-
- LDAP allows multi-valued password attributes. In systems where
- entries are expected to have one and only one password,
- administrative controls should be provided to enforce this behavior.
-
- The use of clear text passwords and other unprotected authentication
- credentials is strongly discouraged over open networks when the
- underlying transport service cannot guarantee confidentiality. LDAP
- implementations SHOULD NOT by default support authentication methods
- using clear text passwords and other unprotected authentication
- credentials unless the data on the session is protected using TLS or
- other data confidentiality and data integrity protection.
-
- The transmission of passwords in the clear--typically for
- authentication or modification--poses a significant security risk.
- This risk can be avoided by using SASL authentication [SASL]
- mechanisms that do not transmit passwords in the clear or by
- negotiating transport or session layer data confidentiality services
- before transmitting password values.
-
- To mitigate the security risks associated with the transfer of
- passwords, a server implementation that supports any password-based
- authentication mechanism that transmits passwords in the clear MUST
- support a policy mechanism that at the time of authentication or
- password modification, requires:
-
- A TLS layer has been successfully installed.
-
-
-Harrison Expires August 2006 [Page 22]
-
-Internet-Draft LDAP Authentication Methods February 2006
-
- OR
-
- Some other data confidentiality mechanism that protects the
- password value from eavesdropping has been provided.
-
- OR
-
- The server returns a resultCode of confidentialityRequired for
- the operation (i.e. name/password Bind with password value,
- SASL Bind transmitting a password value in the clear, add or
- modify including a userPassword value, etc.), even if the
- password value is correct.
-
- Server implementations may also want to provide policy mechanisms to
- invalidate or otherwise protect accounts in situations where a
- server detects that a password for an account has been transmitted
- in the clear.
-
-
-6.3.4. Hashed Password Security Considerations
-
- Some authentication mechanisms (e.g., DIGEST-MD5) transmit a hash of
- the password value that may be vulnerable to offline dictionary
- attacks. Implementers should take care to protect such hashed
- password values during transmission using TLS or other
- confidentiality mechanisms.
-
-
-6.4.SASL Security Considerations
-
- Until data integrity service is installed on an LDAP session, an
- attacker can modify the transmitted values of the
- 'supportedSASLMechanisms' attribute response and thus downgrade the
- list of available SASL mechanisms to include only the least secure
- mechanism. To detect this type of attack, the client may retrieve
- the SASL mechanisms the server makes available both before and after
- data integrity service is installed on an LDAP session. If the
- client finds that the integrity-protected list (the list obtained
- after data integrity service was installed) contains a stronger
- mechanism than those in the previously obtained list, the client
- should assume the previously obtained list was modified by an
- attacker. In this circumstance it is recommended that the client
- close the underlying transport connection and then reconnect to
- reestablish the session.
-
-
-6.5. Related Security Considerations
-
- Additional security considerations relating to the various
- authentication methods and mechanisms discussed in this document
- apply and can be found in [SASL], [RFC4013], [StringPrep] and
- [RFC3629].
-
-
-
-Harrison Expires August 2006 [Page 23]
-
-Internet-Draft LDAP Authentication Methods February 2006
-
-7. IANA Considerations
-
- It is requested that the IANA update the LDAP Protocol Mechanism
- registry to indicate that this document and [Protocol] provide the
- definitive technical specification for the StartTLS
- (1.3.6.1.4.1.1466.20037) extended operation.
-
-
-8. Acknowledgments
-
- This document combines information originally contained in RFC 2251,
- RFC 2829 and RFC 2830 which are products of the LDAP Extensions
- (LDAPEXT) Working Group.
-
- This document is a product of the IETF LDAP Revision (LDAPBIS)
- working group.
-
-
-9. Normative References
-
- [[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn.]]
-
- [LDAPDN] Zeilenga, Kurt D. (editor), "LDAP: String
- Representation of Distinguished Names", draft-ietf-
- ldapbis-dn-xx.txt, a work in progress.
-
- [LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP", draft-
- ietf-ldapbis-bcp64-xx.txt, (a work in progress).
-
- [Matching] Hoffman, Paul and Steve Hanna, "Matching Text Strings
- in PKIX Certificates", draft-hoffman-pkix-stringmatch-
- xx.txt, a work in progress.
-
- [Models] Zeilenga, Kurt D. (editor), "LDAP: Directory
- Information Models", draft-ietf-ldapbis-models-xx.txt,
- a work in progress.
-
- [Protocol] Sermersheim, J., "LDAP: The Protocol", draft-ietf-
- ldapbis-protocol-xx.txt, a work in progress.
-
- [RFC791] Information Sciences Institute, "INTERNET PROTOCOL
- DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION", RFC
- 791, September 1981.
-
- [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2234bis] Crocker, D., Ed. and P. Overell, "Augmented BNF for
- Syntax Specifications: ABNF", draft-crocker-abnf-
- rfc2234bis-xx, a work in progress.
-
- [RFC2460] Deering, S., R. Hinden, "Internet Protocol, Version 6
- (IPv6)", RFC 2460, December 1998.
-
-Harrison Expires August 2006 [Page 24]
-
-Internet-Draft LDAP Authentication Methods February 2006
-
-
- [RFC3490] Falstrom, P., P. Hoffman, and A. Costello,
- "Internationalizing Domain Names In Applications
- (IDNA)", RFC 3490, March 2003.
-
- [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", RFC 3629, STD 63, November 2003.
-
- [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User
- Names and Passwords", RFC 4013, February 2005.
-
- [Roadmap] K. Zeilenga, "LDAP: Technical Specification Road Map",
- draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
-
- [SASL] Melnikov, A. (editor), "Simple Authentication and
- Security Layer (SASL)", draft-ietf-sasl-rfc2222bis-
- xx.txt, a work in progress.
-
- [Schema] Dally, K. (editor), "LDAP: User Schema", draft-ietf-
- ldapbis-user-schema-xx.txt, a work in progress.
-
- [StringPrep] M. Blanchet, "Preparation of Internationalized Strings
- ('stringprep')", draft-hoffman-rfc3454bis-xx.txt, a
- work in progress.
-
- [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
- draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
-
- [TLS] Dierks, T. and C. Allen. "The TLS Protocol Version
- 1.1", draft-ietf-tls-rfc2246-bis-xx.txt, a work in
- progress.
-
- [Unicode] The Unicode Consortium, "The Unicode Standard, Version
- 3.2.0" is defined by "The Unicode Standard, Version
- 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
- 61633-5), as amended by the "Unicode Standard Annex
- #27: Unicode 3.1"
- (http://www.unicode.org/reports/tr27/) and by the
- "Unicode Standard Annex #28: Unicode 3.2"
- (http://www.unicode.org/reports/tr28/).
-
-
-10. Informative References
-
- [[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn.]]
-
- [ANONYMOUS] Zeilenga, K., "Anonymous SASL Mechanism", draft-
- zeilenga-sasl-anon-xx.txt, a work in progress.
-
- [DIGEST-MD5] Leach, P. C. Newman, and A. Melnikov, "Using Digest
- Authentication as a SASL Mechanism", draft-ietf-sasl-
- rfc2831bis-xx.txt, a work in progress.
-
-
-Harrison Expires August 2006 [Page 25]
-
-Internet-Draft LDAP Authentication Methods February 2006
-
- [PLAIN] Zeilenga, K.,"Plain SASL Mechanism", draft-zeilenga-
- sasl-plain-xx.txt, a work in progress.
-
- [RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828, May
- 2000.
-
- [RFC2829] Wahl, M. et al, "Authentication Methods for LDAP", RFC
- 2829, May 2000.
-
- [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
- Internet Protocol", RFC 4301, December 2005.
-
-Author's Address
-
- Roger Harrison
- Novell, Inc.
- 1800 S. Novell Place
- Provo, UT 84606
- USA
- +1 801 861 2642
- roger_harrison@novell.com
-
-
-Appendix A. Authentication and Authorization Concepts
-
- This appendix is non-normative.
-
- This appendix defines basic terms, concepts, and interrelationships
- regarding authentication, authorization, credentials, and identity.
- These concepts are used in describing how various security
- approaches are utilized in client authentication and authorization.
-
-
-A.1. Access Control Policy
-
- An access control policy is a set of rules defining the protection
- of resources, generally in terms of the capabilities of persons or
- other entities accessing those resources. Security objects and
- mechanisms, such as those described here, enable the expression of
- access control policies and their enforcement.
-
-
-A.2. Access Control Factors
-
- A request, when it is being processed by a server, may be associated
- with a wide variety of security-related factors ([Protocol] section
- 4.2). The server uses these factors to determine whether and how to
- process the request. These are called access control factors
- (ACFs). They might include source IP address, encryption strength,
- the type of operation being requested, time of day, etc.. Some
- factors may be specific to the request itself, others may be
- associated with the transport connection via which the request is
- transmitted, others (e.g., time of day) may be "environmental".
-
-
-Harrison Expires August 2006 [Page 26]
-
-Internet-Draft LDAP Authentication Methods February 2006
-
- Access control policies are expressed in terms of access control
- factors. For example, "a request having ACFs i,j,k can perform
- operation Y on resource Z." The set of ACFs that a server makes
- available for such expressions is implementation-specific.
-
-A.3. Authentication, Credentials, Identity
-
- Authentication credentials are the evidence supplied by one party to
- another, asserting the identity of the supplying party (e.g., a
- user) who is attempting to establish a new authorization state with
- the other party (typically a server). Authentication is the process
- of generating, transmitting, and verifying these credentials and
- thus the identity they assert. An authentication identity is the
- name presented in a credential.
-
- There are many forms of authentication credentials. The form used
- depends upon the particular authentication mechanism negotiated by
- the parties. X.509 certificates, Kerberos tickets, and simple
- identity and password pairs are all examples of authentication
- credential forms. Note that an authentication mechanism may
- constrain the form of authentication identities used with it.
-
-
-A.4. Authorization Identity
-
- An authorization identity is one kind of access control factor. It
- is the name of the user or other entity that requests that
- operations be performed. Access control policies are often
- expressed in terms of authorization identities; for example, "entity
- X can perform operation Y on resource Z."
-
- The authorization identity of an LDAP session is often semantically
- the same as the authentication identity presented by the client, but
- it may be different. SASL allows clients to specify an
- authorization identity distinct from the authentication identity
- asserted by the client's credentials. This permits agents such as
- proxy servers to authenticate using their own credentials, yet
- request the access privileges of the identity for which they are
- proxying [SASL]. Also, the form of authentication identity supplied
- by a service like TLS may not correspond to the authorization
- identities used to express a server's access control policy,
- requiring a server-specific mapping to be done. The method by which
- a server composes and validates an authorization identity from the
- authentication credentials supplied by a client is implementation
- specific.
-
-
-Appendix B. Summary of Changes
-
- This appendix is non-normative.
-
-
-
-
-
-Harrison Expires August 2006 [Page 27]
-
-Internet-Draft LDAP Authentication Methods February 2006
-
- This appendix summarizes substantive changes made to RFC 2251, RFC
- 2829 and RFC 2830. In addition to the specific changes detailed
- below, the reader of this document should be aware that numerous
- general editorial changes have been made to the original content
- from the source documents. These changes include the following:
-
- - The material originally found in RFC 2251 sections 4.2.1 and
- 4.2.2, RFC 2829 (all sections except sections 2 and 4) and RFC
- 2830 was combined into a single document
-
- - The combined material was substantially reorganized and edited
- to group related subjects, improve the document flow and clarify
- intent.
-
- - Changes were made throughout the text to align with definitions
- of LDAP protocol layers and IETF security terminology.
-
- - Substantial updates and additions were made to security
- considerations from both documents based on current operational
- experience.
-
-
-B.1. Changes Made to RFC 2251
-
- This section summarizes the substantive changes made to sections
- 4.2.1 and 4.2.2 of RFC 2251 by this document. Additional
- substantive changes to section 4.2.1 of RFC 2251 are also documented
- in [Protocol].
-
-
-B.1.1. Section 4.2.1 (Sequencing of the Bind Request)
-
- - Paragraph 1: Removed the sentence, "If at any stage the client
- wishes to abort the bind process it MAY unbind and then drop the
- underlying connection." The Unbind operation still permits this
- behavior, but it is not documented explicitly.
-
- - Clarified that the session is moved to an anonymous state upon
- receipt of the BindRequest PDU and that it is only moved to a
- non-anonymous state if and when the Bind request is successful.
-
-
-B.1.2. Section 4.2.2 (Authentication and Other Security Services)
-
- - RFC 2251 states that anonymous authentication MUST be performed
- using the simple bind method. This specification defines the
- anonymous authentication mechanism of the simple bind method and
- requires all conforming implementations to support it. Other
- authentication mechanisms producing anonymous authentication and
- authorization state may also be implemented and used by
- conforming implementations.
-
-
-B.2. Changes Made to RFC 2829
-
-Harrison Expires August 2006 [Page 28]
-
-Internet-Draft LDAP Authentication Methods February 2006
-
-
- This section summarizes the substantive changes made to RFC 2829.
-
-
-B.2.1. Section 4 (Required security mechanisms)
-
- - The name/password authentication mechanism (see section B.2.5
- below) protected by TLS replaces the SASL DIGEST-MD5 mechanism
- as LDAP's mandatory-to-implement password-based authentication
- mechanism. Implementations are encouraged to continue
- supporting SASL DIGEST-MD5 [RFC2829].
-
-
-B.2.2. Section 5.1 (Anonymous authentication procedure)
-
- - Clarified that anonymous authentication involves a name value of
- zero length and a password value of zero length. The
- unauthenticated authentication mechanism was added to handle
- simple Bind requests involving a name value with a non-zero
- length and a password value of zero length.
-
-
-B.2.3. Section 6 (Password-based authentication)
-
- - See section B.2.1.
-
-
-B.2.4. Section 6.1 (Digest authentication)
-
- - As the SASL-DIGEST-MD5 mechanism is no longer mandatory to
- implement, this section is now historical and was not included
- in this document. RFC 2829 section 6.1 continues to document the
- SASL DIGEST-MD5 authentication mechanism.
-
-
-B.2.5. Section 6.2 ("simple" authentication choice with TLS)
-
- - Renamed the "simple" authentication mechanism to the
- name/password authentication mechanism to better describe it.
-
- - The use of TLS was generalized to align with definitions of LDAP
- protocol layers. TLS establishment is now discussed as an
- independent subject and is generalized for use with all
- authentication mechanisms and other security layers.
-
- - Removed the implication that the userPassword attribute is the
- sole location for storage of password values to be used in
- authentication. There is no longer any implied requirement for
- how or where passwords are stored at the server for use in
- authentication.
-
-
-B.2.6. Section 6.3 (Other authentication choices with TLS)
-
-
-Harrison Expires August 2006 [Page 29]
-
-Internet-Draft LDAP Authentication Methods February 2006
-
- - See section B.2.5.
-
-
-B.2.7. Section 7.1 (Certificate-based authentication with TLS)
-
- - See section B.2.5.
-
-
-B.2.8. Section 8 (Other mechanisms)
-
- - All SASL authentication mechanisms are explicitly allowed within
- LDAP. Specifically, this means the SASL ANONYMOUS and SASL PLAIN
- mechanisms are no longer precluded from use within LDAP.
-
-
-B.2.9. Section 9 (Authorization identity)
-
- - Specified matching rules for dnAuthzID and uAuthzID values. In
- particular, the DN value in the dnAuthzID form must be matched
- using DN matching rules and the uAuthzID value MUST be prepared
- using SASLprep rules before being compared octet-wise.
-
- - Clarified that uAuthzID values should not be assumed to be
- globally unique.
-
-
-B.2.10. Section 10 (TLS Ciphersuites)
-
- - TLS Ciphersuite recommendations are no longer included in this
- specification. Implementations must still support the
- TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite.
-
- - Clarified that anonymous authentication involves a name value of
- zero length and a password value of zero length. The
- unauthenticated authentication mechanism was added to handle
- simple Bind requests involving a name value with a non-zero
- length and a password value of zero length.
-
-
-B.3. Changes Made to RFC 2830:
-
- This section summarizes the substantive changes made to sections 3
- and 5 of RFC 2830. Readers should consult [Protocol] for summaries
- of changes to other sections.
-
-
-B.3.1. Section 3.6 (Server Identity Check)
-
-
-
-
-
-
-
-
-Harrison Expires August 2006 [Page 30]
-
-Internet-Draft LDAP Authentication Methods February 2006
-
- - Substantially updated the server identity check algorithm to
- ensure that it is complete and robust. In particular, the use
- of all relevant values in the subjectAltName and the subjectName
- fields are covered by the algorithm and matching rules are
- specified for each type of value. Mapped (derived) forms of the
- server identity may now be used when the mapping is performed in
- a secure fashion.
-
-
-B.3.2. Section 3.7 (Refresh of Server Capabilities Information)
-
- - Clients are no longer required to always refresh information
- about server capabilities following TLS establishment to allow
- for situations where this information was obtained through a
- secure mechanism.
-
-
-B.3.3. Section 5.2 (Effects of TLS on Authorization Identity)
-
- - Establishing a TLS layer on an LDAP session may now cause the
- authorization state of the LDAP session to change.
-
-
-B.3.4. Section 5.1.1 (TLS Closure Effects)
-
- - Closing a TLS layer on an LDAP session changes the
- authentication and authorization state of the LDAP session based
- on local policy. Specifically, this means that implementations
- are not required to to change the authentication and
- authorization states to anonymous upon TLS closure.
-
-
-Appendix C. Changes for draft-ldapbis-authmeth-19
-
- [[Note to RFC Editor: Please remove this appendix upon publication
- of this Internet-Draft as an RFC.]]
-
- This appendix is non-normative.
-
- This appendix summarizes changes made in this revision of the
- document.
-
- General
-
- - This draft has addressed all issues raised for the -18 version.
-
- - Several minor edits for clarity and to remove typos based on
- feedback from WG, IETF and IESG reviews.
-
- Abstract
- - Added statement regarding RFCs obsoleted by this document.
-
- Section 2
-
-
-Harrison Expires August 2006 [Page 31]
-
-Internet-Draft LDAP Authentication Methods February 2006
-
- - Changed mandatory-to-implement TLS ciphersuite from
- TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA to
- TLS_RSA_WITH_3DES_EDE_CBC_SHA based on IESG recommendation and
- WG consensus.
-
- Section 5.2.1.5
- - Clarified that 'supportedSASLMechanisms' should be retrievable
- by all clients both before and after SASL negotiation to allow
- detection of mechanism downgrade attacks.
-
- Section 5.2.1.6
- - Changed wording to reflect the fact that SASL layers cannot be
- uninstalled from the session.
-
- Section 5.2.3
- - Removed reference to IPsec as a source of authorization identity.
-
- Section 6.2
- - When TLS layer does not provide an acceptable level of security
- client MUST warn the user or refuse to proceed. (This was
- changed from SHOULD based on IESG recommendation and WG
- consensus.)
-
- - Added a security consideration regarding the proper usage of
- information found in the client certificate.
-
- Section 6.4
- - Added a new section on SASL security considerations that
- discusses SASL mechanism downgrade attacks.
-
- Section 10
- - Replaced references to RFC 2401 with RFC 4301.
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed
- to pertain to the implementation or use of the technology described
- in this document or the extent to which any license under such
- rights might or might not be available; nor does it represent that
- it has made any independent effort to identify any such rights.
- Information on the procedures with respect to rights in RFC
- documents can be found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use
- of such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository
- at http://www.ietf.org/ipr.
-
-
-
-
-
-Harrison Expires August 2006 [Page 32]
-
-Internet-Draft LDAP Authentication Methods February 2006
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at ietf-
- ipr@ietf.org.
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2006).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on
- an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
- REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
- INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
- IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
- THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Harrison Expires August 2006 [Page 33]
-
\ No newline at end of file
diff --git a/doc/drafts/draft-ietf-ldapbis-bcp64-xx.txt b/doc/drafts/draft-ietf-ldapbis-bcp64-xx.txt
deleted file mode 100644
index cdc8505536941e95688ef6219f10b48f83931555..0000000000000000000000000000000000000000
--- a/doc/drafts/draft-ietf-ldapbis-bcp64-xx.txt
+++ /dev/null
@@ -1,1179 +0,0 @@
-
-
-
-
-
-
-INTERNET-DRAFT Kurt D. Zeilenga
-Intended Category: BCP OpenLDAP Foundation
-Expires in six months 23 January 2006
-Obsoletes: RFC 3383
-
-
- IANA Considerations for LDAP
- <draft-ietf-ldapbis-bcp64-06.txt>
-
-
-
-Status of Memo
-
- This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor as a Best Current Practice
- document. This document is intended to replace RFC 3383.
- Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDAP Revision Working Group
- (LDAPBIS) mailing list <ietf-ldapbis@openldap.org>. Please send
- editorial comments directly to the document editor
- <Kurt@OpenLDAP.org>.
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
- Copyright (C) The Internet Society (2006). All Rights Reserved.
-
- Please see the Full Copyright section near the end of this document
- for more information.
-
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 1]
-
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
-Abstract
-
- This document provides procedures for registering extensible elements
- of Lightweight Directory Access Protocol (LDAP). The document also
- provides guidelines to Internet Assigned Numbers Authority (IANA)
- describing conditions under which new values can be assigned.
-
-
-1. Introduction
-
- The Lightweight Directory Access Protocol [Roadmap] (LDAP) is an
- extensible protocol. LDAP supports:
-
- - addition of new operations,
- - extension of existing operations, and
- - extensible schema.
-
- This document details procedures for registering values of used to
- unambiguously identify extensible elements of the protocol including:
-
- - LDAP message types;
- - LDAP extended operations and controls;
- - LDAP result codes;
- - LDAP authentication methods;
- - LDAP attribute description options; and
- - Object Identifier descriptors.
-
- These registries are maintained by the Internet Assigned Numbers
- Authority (IANA).
-
- In addition, this document provides guidelines to IANA describing the
- conditions under which new values can be assigned.
-
- This document replaces RFC 3383.
-
-
-2. Terminology and Conventions
-
- This section details terms and conventions used in this document.
-
-
-2.1. Policy Terminology
-
- The terms "IESG Approval", "Standards Action", "IETF Consensus",
- "Specification Required", "First Come First Served", "Expert Review",
- and "Private Use" are used as defined in BCP 26 [RFC2434].
-
-
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 2]
-
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
-2.2. Requirement Terminology
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119]. In
- this case, "the specification" as used by BCP 14 refers to the
- processing of protocols being submitted to the IETF standards
- process.
-
-
-2.3. Common ABNF Productions
-
- A number of syntaxes in this document are described using ABNF
- [ABNF]. These syntaxes rely on the following common productions:
-
- ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
- LDIGIT = %x31-39 ; "1"-"9"
- DIGIT = %x30 / LDIGIT ; "0"-"9"
- HYPHEN = %x2D ; "-"
- DOT = %x2E ; "."
- number = DIGIT / ( LDIGIT 1*DIGIT )
- keychar = ALPHA / DIGIT / HYPHEN
- leadkeychar = ALPHA
- keystring = leadkeychar *keychar
-
- A keyword is a case-insensitive string of UTF-8 [RFC3629] encoded
- Unicode [Unicode] restricted to the <keystring> production.
-
-
-3. IANA Considerations for LDAP
-
- This section details each kind of protocol value which can be
- registered and provides IANA guidelines on how to assign new values.
-
- IANA may reject obviously bogus registrations.
-
- LDAP values specified in RFCs MUST be registered. Other LDAP values,
- except those in private-use name spaces, SHOULD be registered. RFCs
- SHOULD NOT reference, use, or otherwise recognize unregistered LDAP
- values.
-
-
-3.1. Object Identifiers
-
- Numerous LDAP schema and protocol elements are identified by Object
- Identifiers (OIDs) [X.680]. Specifications which assign OIDs to
- elements SHOULD state who delegated the OIDs for its use.
-
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 3]
-
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
- For IETF developed elements, specifications SHOULD use OIDs under
- "Internet Directory Numbers" (1.3.6.1.1.x). For elements developed
- by others, any properly delegated OID can be used, including those
- under "Internet Directory Numbers" (1.3.6.1.1.x) or "Internet Private
- Enterprise Numbers" (1.3.6.1.4.1.x).
-
- Internet Directory Numbers (1.3.6.1.1.x) will be assigned upon Expert
- Review with Specification Required. Only one OID per specification
- will be assigned. The specification MAY then assign any number of
- OIDs within this arc without further coordination with IANA.
-
- Internet Private Enterprise Numbers (1.3.6.1.4.1.x) are assigned by
- IANA <http://www.iana.org/cgi-bin/enterprise.pl>. Practices for IANA
- assignment of Internet Private Enterprise Numbers is detailed in RFC
- 2578 [RFC2578].
-
- To avoid interoperability problems between early implementations of a
- "work in progress" and implementations of the published specification
- (e.g., the RFC), experimental OIDs SHOULD be used in "works in
- progress" and early implementations. OIDs under the Internet
- Experimental OID arc (1.3.6.1.3.x) may be used for this purpose.
- Practices for IANA assignment of these Internet Experimental numbers
- is detailed in RFC 2578 [RFC2578]
-
-
-3.2 Protocol Mechanisms
-
- LDAP provides a number of Root DSE attributes for discovery of
- protocol mechanisms identified by OIDs, including the
- supportedControl, supportedExtension, and supportedFeatures
- attributes [Models],
-
- A registry of OIDs used for discover of protocol mechanisms is
- provided to allow implementors and others to locate the technical
- specification for these protocol mechanisms. Future specifications
- of additional Root DSE attributes holding values identifying protocol
- mechanisms MAY extend this registry for their values.
-
- Protocol Mechanisms are registered on a First Come First Served
- basis.
-
-
-3.3 LDAP Syntaxes
-
- This registry provides a listing of LDAP syntaxes [Models]. Each
- LDAP syntax is identified by an object identifier (OID). This
- registry is provided to allow implementors and others to locate the
- technical specification describing a particular LDAP Syntax.
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 4]
-
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
- LDAP Syntaxes are registered on a First Come First Served with
- Specification Required basis.
-
- Note: unlike object classes, attribute types and various other kinds
- of schema elements, descriptors are not used in LDAP to identify LDAP
- Syntaxes.
-
-
-3.4. Object Identifier Descriptors
-
- LDAP allows short descriptive names (or descriptors) to be used
- instead of a numeric Object Identifier to identify select protocol
- extensions [Protocol], schema elements [Models], LDAP URL [LDAPURL]
- extensions, and other objects.
-
- While the protocol allows the same descriptor to refer to different
- object identifiers in certain cases and the registry supports
- multiple registrations of the same descriptor (each indicating a
- different kind of schema element and different object identifier),
- multiple registrations of the same descriptor are to be avoided. All
- such multiple registration requests require Expert Review.
-
- Descriptors are restricted to strings of UTF-8 encoded Unicode
- characters restricted by the following ABNF:
-
- name = keystring
-
- Descriptors are case-insensitive.
-
- Multiple names may be assigned to a given OID. For purposes of
- registration, an OID is to be represented in numeric OID form (e.g.,
- 1.1.0.23.40) conforming to the ABNF:
-
- numericoid = number 1*( DOT number )
-
- While the protocol places no maximum length restriction upon
- descriptors, they should be short. Descriptors longer than 48
- characters may be viewed as too long to register.
-
- A value ending with a hyphen ("-") reserves all descriptors which
- start with that value. For example, the registration of the option
- "descrFamily-" reserves all options which start with "descrFamily-"
- for some related purpose.
-
- Descriptors beginning with "x-" are for Private Use and cannot be
- registered.
-
- Descriptors beginning with "e-" are reserved for experiments and will
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 5]
-
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
- be registered on a First Come First Served basis.
-
- All other descriptors require Expert Review to be registered.
-
- The registrant need not "own" the OID being named.
-
- The OID name space is managed by The ISO/IEC Joint Technical
- Committee 1 - Subcommittee 6.
-
-
-3.5. AttributeDescription Options
-
- An AttributeDescription [Models] can contain zero or more options
- specifying additional semantics. An option SHALL be restricted to a
- string UTF-8 encoded Unicode characters limited by the following
- ABNF:
-
- option = keystring
-
- Options are case-insensitive.
-
- While the protocol places no maximum length restriction upon option
- strings, they should be short. Options longer than 24 characters may
- be viewed as too long to register.
-
- Values ending with a hyphen ("-") reserve all option names which
- start with the name. For example, the registration of the option
- "optionFamily-" reserves all options which start with "optionFamily-"
- for some related purpose.
-
- Options beginning with "x-" are for Private Use and cannot be
- registered.
-
- Options beginning with "e-" are reserved for experiments and will be
- registered on a First Come First Served basis.
-
- All other options require Standards Action or Expert Review with
- Specification Required to be registered.
-
-
-3.6. LDAP Message Types
-
- Each protocol message is encapsulated in an LDAPMessage envelope
- [Protocol]. The protocolOp CHOICE indicates the type of message
- encapsulated. Each message type consists of an ASN.1 identifier in
- the form of a keyword and a non-negative choice number. The choice
- number is combined with the class (APPLICATION) and data type
- (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the message's
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 6]
-
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
- encoding. The choice numbers for existing protocol messages are
- implicit in the protocol's ASN.1 defined in [Protocol].
-
- New values will be registered upon Standards Action.
-
- Note: LDAP provides extensible messages which reduces, but does not
- eliminate, the need to add new message types.
-
-
-3.7. LDAP Authentication Method
-
- The LDAP Bind operation supports multiple authentication methods
- [Protocol]. Each authentication choice consists of an ASN.1
- identifier in the form of a keyword and a non-negative integer.
-
- The registrant SHALL classify the authentication method usage using
- one of the following terms:
-
- COMMON - method is appropriate for common use on the
- Internet,
- LIMITED USE - method is appropriate for limited use,
- OBSOLETE - method has been deprecated or otherwise found to
- be inappropriate for any use.
-
- Methods without publicly available specifications SHALL NOT be
- classified as COMMON. New registrations of class OBSOLETE cannot be
- registered.
-
- New authentication method integers in the range 0-1023 require
- Standards Action to be registered. New authentication method
- integers in the range 1024-4095 require Expert Review with
- Specification Required. New authentication method integers in the
- range 4096-16383 will be registered on a First Come First Served
- basis. Keywords associated with integers in the range 0-4095 SHALL
- NOT start with "e-" or "x-". Keywords associated with integers in
- the range 4096-16383 SHALL start with "e-". Values greater than or
- equal to 16384 and keywords starting with "x-" are for Private Use
- and cannot be registered.
-
- Note: LDAP supports Simple Authentication and Security Layers [SASL]
- as an authentication choice. SASL is an extensible
- authentication framework.
-
-
-3.8. LDAP Result Codes
-
- LDAP result messages carry an resultCode enumerated value to indicate
- the outcome of the operation [Protocol]. Each result code consists
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 7]
-
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
- of a ASN.1 identifier in the form of a keyword and a non-negative
- integer.
-
- New resultCodes integers in the range 0-1023 require Standards Action
- to be registered. New resultCode integers in the range 1024-4095
- require Expert Review with Specification Required. New resultCode
- integers in the range 4096-16383 will be registered on a First Come
- First Served basis. Keywords associated with integers in the range
- 0-4095 SHALL NOT start with "e-" or "x-". Keywords associated with
- integers in the range 4096-16383 SHALL start with "e-". Values
- greater than or equal to 16384 and keywords starting with "x-" are
- for Private Use and cannot be registered.
-
-
-3.9. LDAP Search Scope
-
- LDAP SearchRequest messages carry a scope enumerated value to
- indicate the extend of search within the DIT [Protocol] Each search
- value consists of a ASN.1 identifier in the form of a keyword and a
- non-negative integer.
-
- New scope integers in the range 0-1023 require Standards Action to be
- registered. New scope integers in the range 1024-4095 require Expert
- Review with Specification Required. New scope integers in the range
- 4096-16383 will be registered on a First Come First Served basis.
- Keywords associated with integers in the range 0-4095 SHALL NOT start
- with "e-" or "x-". Keywords associated with integers in the range
- 4096-16383 SHALL start with "e-". Values greater than or equal to
- 16384 and keywords starting with "x-" are for Private Use and cannot
- be registered.
-
-
-3.10. LDAP Filter Choice
-
- LDAP filters are used in making assertions against an object
- represented in the directory [Protocol]. The Filter CHOICE indicates
- a type of assertion. Each Filter CHOICE consists of an ASN.1
- identifier in the form of a keyword and a non-negative choice number.
- The choice number is combined with the class (APPLICATION) and data
- type (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the
- message's encoding.
-
- Note: LDAP provides the extensibleMatching choice which reduces, but
- does not eliminate, the need to add new filter choices.
-
-
-3.11. LDAP ModifyRequest Operation Type
-
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 8]
-
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
- The LDAP ModifyRequest carries a sequence of modification operations
- [Protocol]. Each kind (e.g., add, delete, replace) of operation is
- consists of a ASN.1 identifier in the form of a keyword and a
- non-negative integer.
-
- New operation type integers in the range 0-1023 require Standards
- Action to be registered. New operation type integers in the range
- 1024-4095 require Expert Review with Specification Required. New
- operation type integers in the range 4096-16383 will be registered on
- a First Come First Served basis. Keywords associated with integers
- in the range 0-4095 SHALL NOT start with "e-" or "x-". Keywords
- associated with integers in the range 4096-16383 SHALL start with
- "e-". Values greater than or equal to 16384 and keywords starting
- with "x-" are for Private Use and cannot be registered.
-
-
-3.12. LDAP authzId Prefixes
-
- Authorization Identities in LDAP are strings conforming to the
- <authzId> production [AuthMeth]. This production is extensible.
- Each new specific authorization form is identified by a prefix string
- conforming to the following ABNF:
-
- prefix = keystring COLON
- COLON = %x3A ; COLON (":" U+003A)
-
- Prefixes are case-insensitive.
-
- While the protocol places no maximum length restriction upon prefix
- strings, they should be short. Prefixes longer than 12 characters
- may be viewed as too long to register.
-
- Prefixes beginning with "x-" are for Private Use and cannot be
- registered.
-
- Prefixes beginning with "e-" are reserved for experiments and will be
- registered on a First Come First Served basis.
-
- All other prefixes require Standards Action or Expert Review with
- Specification Required to be registered.
-
-
-3.13. Directory Systems Names
-
- The IANA-maintained "Directory Systems Names" registry [IANADSN] of
- valid keywords for well known attributes was used in the LDAPv2
- string representation of a distinguished name [RFC1779]. LDAPv2 is
- now Historic [RFC3494].
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 9]
-
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
- Directory systems names are not known to be used in any other
- context. LDAPv3 [LDAPDN] uses Object Identifier Descriptors [Section
- 3.2] (which have a different syntax than directory system names).
-
- New Directory System Names will no longer be accepted. For
- historical purposes, the current list of registered names should
- remain publicly available.
-
-
-4. Registration Procedure
-
- The procedure given here MUST be used by anyone who wishes to use a
- new value of a type described in Section 3 of this document.
-
- The first step is for the requester to fill out the appropriate form.
- Templates are provided in Appendix A.
-
- If the policy is Standards Action, the completed form SHOULD be
- provided to the IESG with the request for Standards Action. Upon
- approval of the Standards Action, the IESG SHALL forward the request
- (possibly revised) to IANA. The IESG SHALL be viewed as the owner of
- all values requiring Standards Action.
-
- If the policy is Expert Review, the requester SHALL post the
- completed form to the <directory@apps.ietf.org> mailing list for
- public review. The review period is two (2) weeks. If a revised
- form is later submitted, the review period is restarted. Anyone may
- subscribe to this list by sending a request to
- <directory-request@apps.ietf.org>. During the review, objections may
- be raised by anyone (including the Expert) on the list. After
- completion of the review, the Expert, based upon public comments,
- SHALL either approve the request and forward it to the IANA OR deny
- the request. In either case, the Expert SHALL promptly notify the
- requester of the action. Actions of the Expert may be appealed
- [RFC2026]. The Expert is appointed by Applications Area Director(s).
- The requester is viewed as the owner of values registered under
- Expert Review.
-
- If the policy is First Come First Served, the requester SHALL submit
- the completed form directly to the IANA: <iana@iana.org>. The
- requester is viewed as the owner of values registered under First
- Come First Served.
-
- Neither the Expert nor IANA will take position on the claims of
- copyright or trademarks issues regarding completed forms.
-
- Prior to submission of the Internet Draft (I-D) to the RFC Editor but
- after IESG review and tentative approval, the document editor SHOULD
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 10]
-
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
- revise the I-D to use registered values.
-
-
-5. Registration Maintenance
-
- This section discusses maintenance of registrations.
-
-
-5.1. Lists of Registered Values
-
- IANA makes lists of registered values readily available to the
- Internet community on their web site: <http://www.iana.org/>.
-
-
-5.2. Change Control
-
- The registration owner MAY update the registration subject to the
- same constraints and review as with new registrations. In cases
- where the owner is not unable or unwilling to make necessary updates,
- the IESG MAY assume ownership in order to update the registration.
-
-
-5.3. Comments
-
- For cases where others (anyone other than the owner) have significant
- objections to the claims in a registration and the owner does not
- agree to change the registration, comments MAY be attached to a
- registration upon Expert Review. For registrations owned by the
- IESG, the objections SHOULD be addressed by initiating a request for
- Expert Review.
-
- The form to these requests is ad hoc, but MUST include the specific
- objections to be reviewed and SHOULD contain (directly or by
- reference) materials supporting the objections.
-
-
-6. Security Considerations
-
- The security considerations detailed in BCP 26 [RFC2434] are
- generally applicable to this document. Additional security
- considerations specific to each name space are discussed in Section 3
- where appropriate.
-
- Security considerations for LDAP are discussed in documents
- comprising the technical specification [Roadmap].
-
-
-7. Acknowledgment
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 11]
-
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
- This document is a product of the IETF LDAP Revision (LDAPBIS)
- Working Group (WG). This document is a revision of RFC 3383, also a
- product of the LDAPBIS WG.
-
- This document includes text borrowed from "Guidelines for Writing an
- IANA Considerations Section in RFCs" [RFC2434] by Thomas Narten and
- Harald Alvestrand.
-
-
-8. Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- Email: Kurt@OpenLDAP.org
-
-
-9. References
-
- [[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn where
- possible.]]
-
-
-9.1. Normative References
-
- [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
- 3", BCP 9 (also RFC 2026), October 1996.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
- [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", BCP 26 (also RFC
- 2434), October 1998.
-
- [RFC2578] K. McCloghrie, D. Perkins, J. Schoenwaelder, "Structure
- of Management Information Version 2 (SMIv2)", RFC 2578
- (STD: 58), April 1999.
- [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", RFC 3629 (also STD 63), November 2003.
-
- [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 4234, October 2005.
-
- [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
- Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
- progress.
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 12]
-
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
- [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
- Connection Level Security Mechanisms",
- draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
-
- [Models] Zeilenga, K. (editor), "LDAP: Directory Information
- Models", draft-ietf-ldapbis-models-xx.txt, a work in
- progress.
-
- [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
- draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
-
- [LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
- draft-ietf-ldapbis-url-xx.txt, a work in progress.
-
- [Unicode] The Unicode Consortium, "The Unicode Standard, Version
- 3.2.0" is defined by "The Unicode Standard, Version 3.0"
- (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
- as amended by the "Unicode Standard Annex #27: Unicode
- 3.1" (http://www.unicode.org/reports/tr27/) and by the
- "Unicode Standard Annex #28: Unicode 3.2"
- (http://www.unicode.org/reports/tr28/).
-
- [X.680] International Telecommunication Union -
- Telecommunication Standardization Sector, "Abstract
- Syntax Notation One (ASN.1) - Specification of Basic
- Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
-
-
-9.2. Informative References
-
- [RFC1779] Kille, S., "A String Representation of Distinguished
- Names", RFC 1779, March 1995.
-
- [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol
- version 2 (LDAPv2) to Historic Status", RFC 3494, March
- 2003.
-
- [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
- draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
-
- [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
- Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
- work in progress.
-
- [SASL] Melnikov, A. (Editor), "Simple Authentication and
- Security Layer (SASL)",
- draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress.
-
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 13]
-
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
- [IANADSN] IANA, "Directory Systems Names",
- http://www.iana.org/assignments/directory-system-names.
-
-
-Appendix A. Registration Templates
-
- This appendix provides registration templates for registering new
- LDAP values. Note that more than one value may be requested by
- extending the template by listing multiple values, or through use of
- tables.
-
-
-A.1. LDAP Object Identifier Registration Template
-
- Subject: Request for LDAP OID Registration
-
- Person & email address to contact for further information:
-
- Specification: (I-D)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request)
-
-
-A.2. LDAP Protocol Mechanism Registration Template
-
- Subject: Request for LDAP Protocol Mechanism Registration
-
- Object Identifier:
-
- Description:
-
- Person & email address to contact for further information:
-
- Usage: (One of Control or Extension or Feature or other)
-
- Specification: (RFC, I-D, URI)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request)
-
-
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 14]
-
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
-A.3. LDAP Syntax Registration Template
-
- Subject: Request for LDAP Syntax Registration
-
- Object Identifier:
-
- Description:
-
- Person & email address to contact for further information:
-
- Specification: (RFC, I-D, URI)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request)
-
-
-A.4. LDAP Descriptor Registration Template
-
- Subject: Request for LDAP Descriptor Registration
-
- Descriptor (short name):
-
- Object Identifier:
-
- Person & email address to contact for further information:
-
- Usage: (One of administrative role, attribute type, matching rule,
- name form, object class, URL extension, or other)
-
- Specification: (RFC, I-D, URI)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request)
-
-
-A.5. LDAP Attribute Description Option Registration Template
-
- Subject: Request for LDAP Attribute Description Option Registration
-
- Option Name:
-
- Family of Options: (YES or NO)
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 15]
-
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
- Person & email address to contact for further information:
-
- Specification: (RFC, I-D, URI)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request)
-
-
-A.6. LDAP Message Type Registration Template
-
- Subject: Request for LDAP Message Type Registration
-
- LDAP Message Name:
-
- Person & email address to contact for further information:
-
- Specification: (Approved I-D)
-
- Comments:
-
- (Any comments that the requester deems relevant to the request)
-
-
-A.7. LDAP Authentication Method Registration Template
-
- Subject: Request for LDAP Authentication Method Registration
-
- Authentication Method Name:
-
- Person & email address to contact for further information:
-
- Specification: (RFC, I-D, URI)
-
- Intended Usage: (One of COMMON, LIMITED-USE, OBSOLETE)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request)
-
-
-A.8. LDAP Result Code Registration Template
-
- Subject: Request for LDAP Result Code Registration
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 16]
-
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
- Result Code Name:
-
- Person & email address to contact for further information:
-
- Specification: (RFC, I-D, URI)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request)
-
-
-A.8. LDAP Search Scope Registration Template
-
- Subject: Request for LDAP Search Scope Registration
-
- Search Scope Name:
-
- Filter Scope String:
-
- Person & email address to contact for further information:
-
- Specification: (RFC, I-D, URI)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request)
-
-
-A.9. LDAP Filter Choice Registration Template
-
- Subject: Request for LDAP Filter Choice Registration
-
- Filter Choice Name:
-
- Person & email address to contact for further information:
-
- Specification: (RFC, I-D, URI)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request)
-
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 17]
-
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
-A.10. LDAP ModifyRequest Operation Registration Template
-
- Subject: Request for LDAP ModifyRequest Operation Registration
-
- ModifyRequest Operation Name:
-
- Person & email address to contact for further information:
-
- Specification: (RFC, I-D, URI)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request)
-
-
-Appendix B. Changes since RFC 3383
-
- This informative appendix provides a summary of changes made since RFC
- 3383.
-
- - Object Identifier Descriptors practices were updated to require
- all descriptors defined in RFCs to be registered and
- recommending all other descriptors (excepting those in
- private-use name space) be registered. Additionally, all
- requests for multiple registrations of the same descriptor are
- now subject to Expert Review.
-
- - Protocol Mechanisms practices were updated to include values of
- the 'supportedFeatures' attribute type.
-
- - LDAP Syntax, Search Scope, Filter Choice, ModifyRequest
- operation, and authzId prefixes registries were added.
- [[Initial values provided in Appendix C. This Appendix is to be
- removed by the RFC Editor before publication as an RFC.]]
-
- - References to RFCs comprising the LDAP technical specifications
- have been updated to latest revisions.
-
- - References to ISO 10646 have been replaced with [Unicode].
-
- - The "Assigned Values" appendix providing initial registry values
- was removed.
-
- - Numerous editorial changes were made.
-
-
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 18]
-
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
-Appendix C. Initial Values for new registries
-
- This appendix provides initial values for new registries.
-
-
-C.1. LDAP Syntaxes
-
- Object Identifier Syntax Owner Reference
- ----------------------------- -------------------------- ----- ---
- 1.3.6.1.4.1.1466.115.121.1.3 Attribute Type Description IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.6 Bit String IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.7 Boolean IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.11 Country String IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.12 DN IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.14 Delivery Method IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.15 Directory String IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.16 DIT Content Rule Description IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.17 DIT Structure Rule Description IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.21 Enhanced Guide IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.22 Facsimile Telephone Number IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.23 Fax IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.24 Generalized Time IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.25 Guide IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.26 IA5 String IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.27 Integer IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.28 JPEG IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.30 Matching Rule Description IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.31 Matching Rule Use Description IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.34 Name And Optional UID IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.35 Name Form Description IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.36 Numeric String IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.37 Object Class Description IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.38 OID IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.39 Other Mailbox IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.40 Octet String IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.41 Postal Address IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.44 Printable String IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.50 Telephone Number IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.51 Teletex Terminal Identifier IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.52 Telex Number IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.53 UTC Time IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.54 LDAP Syntax Description IESG [Syntaxes]
- 1.3.6.1.4.1.1466.115.121.1.58 Substring Assertion IESG [Syntaxes]
-
-
-C.2. LDAP Search Scopes
-
- Name URLString Value Owner Reference
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 19]
-
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
- ---------------- --------- ----- ----- -------------------
- baseObject base 0 IESG [Protocol][LDAPURL]
- singleLevel one 1 IESG [Protocol][LDAPURL]
- wholeSubtree sub 2 IESG [Protocol][LDAPURL]
-
-
-C.3. LDAP Filter Choices
-
- Name Value Owner Reference
- ---------------- ----- ----- ---------
- and 0 IESG [Protocol]
- or 1 IESG [Protocol]
- not 2 IESG [Protocol]
- equalityMatch 3 IESG [Protocol]
- substrings 4 IESG [Protocol]
- greaterOrEqual 5 IESG [Protocol]
- lessOrEqual 6 IESG [Protocol]
- present 7 IESG [Protocol]
- approxMatch 8 IESG [Protocol]
- extensibleMatch 9 IESG [Protocol]
-
-
-C.4. LDAP ModifyRequest Operations
-
- Name Value Owner Reference
- ---------------- ----- ----- ---------
- add 0 IESG [Protocol]
- delete 1 IESG [Protocol]
- replace 2 IESG [Protocol]
-
-
-C.5. LDAP authzId prefixes
-
- Name Prefix Owner Reference
- ---------------- ------ ----- ---------
- dnAuthzId dn: IESG [AuthMeth]
- uAuthzId u: IESG [AuthMeth]
-
-
-Full Copyright
-
- Copyright (C) The Internet Society (2006).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 20]
-
-INTERNET-DRAFT draft-ietf-ldapbis-bcp64-06.txt 23 January 2006
-
-
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be found
- in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this specification
- can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga IANA Considerations for LDAP [Page 21]
-
diff --git a/doc/drafts/draft-ietf-ldapbis-dn-xx.txt b/doc/drafts/draft-ietf-ldapbis-dn-xx.txt
deleted file mode 100644
index 458f65eea1988726c868b89de91736eb939f9485..0000000000000000000000000000000000000000
--- a/doc/drafts/draft-ietf-ldapbis-dn-xx.txt
+++ /dev/null
@@ -1,843 +0,0 @@
-
-
-
-
-
-INTERNET-DRAFT Editor: Kurt D. Zeilenga
-Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 10 February 2005
-Obsoletes: RFC 2253
-
-
-
- LDAP: String Representation of Distinguished Names
- <draft-ietf-ldapbis-dn-16.txt>
-
-
-
-Status of Memo
-
- This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor as a Standard Track document
- replacing RFC 2253. Distribution of this memo is unlimited.
- Technical discussion of this document will take place on the IETF LDAP
- Revision (LDAPBIS) Working Group mailing list
- <ietf-ldapbis@openldap.org>. Please send editorial comments directly
- to the document editor <Kurt@OpenLDAP.org>.
-
- By submitting this Internet-Draft, I accept the provisions of Section
- 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
- applicable patent or other IPR claims of which I am aware have been
- disclosed, or will be disclosed, and any of which I become aware will
- be disclosed, in accordance with RFC 3668.
-
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference material
- or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
- Copyright (C) The Internet Society (2005). All Rights Reserved.
-
- Please see the Full Copyright section near the end of this document
- for more information.
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 1]
-
-INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
-
-
-Abstract
-
- The X.500 Directory uses distinguished names (DNs) as primary keys to
- entries in the directory. This document defines the string
- representation used in the Lightweight Directory Access Protocol
- (LDAP) to transfer distinguished names. The string representation is
- designed to give a clean representation of commonly used distinguished
- names, while being able to represent any distinguished name.
-
-
-1. Background and Intended Usage
-
- In X.500-based directory systems [X.500], including those accessed
- using the Lightweight Directory Access Protocol (LDAP) [Roadmap],
- distinguished names (DNs) are used to unambiguously refer to directory
- entries [X.501][Models].
-
- The structure of a DN [X.501] is described in terms of ASN.1 [X.680].
- In the X.500 Directory Access Protocol [X.511] (and other ITU-defined
- directory protocols), DNs are encoded using the Basic Encoding Rules
- (BER) [X.690]. In LDAP, DNs are represented in the string form
- described in this document.
-
- It is important to have a common format to be able to unambiguously
- represent a distinguished name. The primary goal of this
- specification is ease of encoding and decoding. A secondary goal is
- to have names that are human readable. It is not expected that LDAP
- implementations with a human user interface would display these
- strings directly to the user, but would most likely be performing
- translations (such as expressing attribute type names in the local
- national language).
-
- This document defines the string representation of Distinguished Names
- used in LDAP [Protocol][Syntaxes]. Section 2 details the RECOMMENDED
- algorithm for converting a DN from its ASN.1 structured representation
- to a string. Section 3 details how to convert a DN from a string to a
- ASN.1 structured representation.
-
- While other documents may define other algorithms for converting a DN
- from its ASN.1 structured representation to a string, all algorithms
- MUST produce strings which adhere to the requirements of Section 3.
-
- This document does not define a canonical string representation for
- DNs. Comparison of DNs for equality is to be performed in accordance
- with the distinguishedNameMatch matching rule [Syntaxes].
-
- This document is a integral part of the LDAP technical specification
- [Roadmap] which obsoletes the previously defined LDAP technical
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 2]
-
-INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
-
-
- specification, RFC 3377, in its entirety. This document obsoletes RFC
- 2253. Changes since RFC 2253 are summarized in Appendix B.
-
- This specification assumes familiarity with X.500 [X.500] and the
- concept of Distinguished Name [X.501][Models].
-
-
-1.1. Conventions
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119].
-
- Character names in this document use the notation for code points and
- names from the Unicode Standard [Unicode]. For example, the letter
- "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
-
- Note: a glossary of terms used in Unicode can be found in [Glossary].
- Information on the Unicode character encoding model can be found in
- [CharModel].
-
-
-2. Converting DistinguishedName from ASN.1 to a String
-
- X.501 [X.501] defines the ASN.1 [X.680] structure of distinguished
- name. The following is a variant provided for discussion purposes.
-
- DistinguishedName ::= RDNSequence
-
- RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
-
- RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
- AttributeTypeAndValue
-
- AttributeTypeAndValue ::= SEQUENCE {
- type AttributeType,
- value AttributeValue }
-
- This section defines the RECOMMENDED algorithm for converting a
- distinguished name from an ASN.1 structured representation to an UTF-8
- [RFC3629] encoded Unicode [Unicode] character string representation.
- Other documents may describe other algorithms for converting a
- distinguished name to a string, but only strings which conform to the
- grammar defined in Section 3 SHALL be produced by LDAP
- implementations.
-
-
-2.1. Converting the RDNSequence
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 3]
-
-INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
-
-
- If the RDNSequence is an empty sequence, the result is the empty or
- zero length string.
-
- Otherwise, the output consists of the string encodings of each
- RelativeDistinguishedName in the RDNSequence (according to Section
- 2.2), starting with the last element of the sequence and moving
- backwards toward the first.
-
- The encodings of adjoining RelativeDistinguishedNames are separated by
- a comma (',' U+002C) character.
-
-
-2.2. Converting RelativeDistinguishedName
-
- When converting from an ASN.1 RelativeDistinguishedName to a string,
- the output consists of the string encodings of each
- AttributeTypeAndValue (according to Section 2.3), in any order.
-
- Where there is a multi-valued RDN, the outputs from adjoining
- AttributeTypeAndValues are separated by a plus sign ('+' U+002B)
- character.
-
-
-2.3. Converting AttributeTypeAndValue
-
- The AttributeTypeAndValue is encoded as the string representation of
- the AttributeType, followed by an equals sign ('=' U+003D) character,
- followed by the string representation of the AttributeValue. The
- encoding of the AttributeValue is given in Section 2.4.
-
- If the AttributeType is defined to have a short name (descriptor)
- [Models] and that short name is known to be registered
- [REGISTRY][BCP64bis] as identifying the AttributeType, that short
- name, a <descr>, is used. Otherwise the AttributeType is encoded as
- the dotted-decimal encoding, a <numericoid>, of its OBJECT IDENTIFIER.
- The <descr> and <numericoid> is defined in [Models].
-
- Implementations are not expected to dynamically update their knowledge
- of registered short names. However, implementations SHOULD provide a
- mechanism to allow its knowledge of registered short names to be
- updated.
-
-
-2.4. Converting an AttributeValue from ASN.1 to a String
-
- If the AttributeType is of the dotted-decimal form, the AttributeValue
- is represented by an number sign ('#' U+0023) character followed by
- the hexadecimal encoding of each of the octets of the BER encoding of
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 4]
-
-INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
-
-
- the X.500 AttributeValue. This form is also used when the syntax of
- the AttributeValue does not have a LDAP-specific [Syntaxes, Section
- 3.1] string encoding defined for it or the LDAP-specific string
- encoding is not restricted to UTF-8 encoded Unicode characters. This
- form may also be used in other cases, such as when a reversible string
- representation is desired (see Section 5.2).
-
- Otherwise, if the AttributeValue is of a syntax which has a
- LDAP-specific string encoding, the value is converted first to a UTF-8
- encoded Unicode string according to its syntax specification (see
- [Syntaxes, Section 3.3] for examples). If that UTF-8 encoded Unicode
- string does not have any of the following characters which need
- escaping, then that string can be used as the string representation of
- the value.
-
- - a space (' ' U+0020) or number sign ('#' U+0023) occurring at
- the beginning of the string;
-
- - a space (' ' U+0020) character occurring at the end of the
- string;
-
- - one of the characters '"', '+', ',', ';', '<', '>', or '\'
- (U+0022, U+002B, U+002C, U+003B, U+003C, U+003E, or U+005C
- respectively);
-
- - the null (U+0000) character.
-
- Other characters may be escaped.
-
- Each octet of the character to be escaped is replaced by a backslash
- and two hex digits, which form a single octet in the code of the
- character. Alternatively, if and only if the character to be escaped
- is one of
-
- ' ', '"', '#', '+', ',', ';', '<', '=', '>', or '\'
- (U+0020, U+0022, U+0023, U+002B, U+002C, U+003B,
- U+003C, U+003D, U+003E, U+005C respectively)
-
- it can be prefixed by a backslash ('\' U+005C).
-
- Examples of the escaping mechanism are shown in Section 4.
-
-
-3. Parsing a String back to a Distinguished Name
-
- The string representation of Distinguished Names is restricted to
- UTF-8 [RFC3629] encoded Unicode [Unicode] characters. The structure
- of this string representation is specified using the following
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 5]
-
-INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
-
-
- Augmented BNF [RFC2234] grammar:
-
- distinguishedName = [ relativeDistinguishedName
- *( COMMA relativeDistinguishedName ) ]
- relativeDistinguishedName = attributeTypeAndValue
- *( PLUS attributeTypeAndValue )
- attributeTypeAndValue = attributeType EQUALS attributeValue
- attributeType = descr / numericoid
- attributeValue = string / hexstring
-
- ; The following characters are to be escaped when they appear
- ; in the value to be encoded: ESC, one of <escaped>, leading
- ; SHARP or SPACE, trailing SPACE, and NULL.
- string = [ ( leadchar / pair ) [ *( stringchar / pair )
- ( trailchar / pair ) ] ]
-
- leadchar = LUTF1 / UTFMB
- LUTF1 = %x01-1F / %x21 / %x24-2A / %x2D-3A /
- %x3D / %x3F-5B / %x5D-7F
-
- trailchar = TUTF1 / UTFMB
- TUTF1 = %x01-1F / %x21 / %x23-2A / %x2D-3A /
- %x3D / %x3F-5B / %x5D-7F
-
- stringchar = SUTF1 / UTFMB
- SUTF1 = %x01-21 / %x23-2A / %x2D-3A /
- %x3D / %x3F-5B / %x5D-7F
-
- pair = ESC ( ESC / special / hexpair )
- special = escaped / SPACE / SHARP / EQUALS
- escaped = DQUOTE / PLUS / COMMA / SEMI / LANGLE / RANGLE
- hexstring = SHARP 1*hexpair
- hexpair = HEX HEX
-
- where the productions <descr>, <numericoid>, <COMMA>, <DQUOTE>,
- <EQUALS>, <ESC>, <HEX>, <LANGLE>, <NULL>, <PLUS>, <RANGLE>, <SEMI>,
- <SPACE>, <SHARP>, <UTFMB> are defined in [Models].
-
- Each <attributeType>, either a <descr> or a <numericoid>, refers to an
- attribute type of an attribute value assertion (AVA). The
- <attributeType> is followed by a <EQUALS> and an <attributeValue>.
- The <attributeValue> is either in <string> or <hexstring> form.
-
- If in <string> form, a LDAP string representation asserted value can
- be obtained by replacing (left-to-right, non-recursively) each <pair>
- appearing in the <string> as follows:
- replace <ESC><ESC> with <ESC>;
- replace <ESC><special> with <special>;
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 6]
-
-INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
-
-
- replace <ESC><hexpair> with the octet indicated by the <hexpair>.
-
- If in <hexstring> form, a BER representation can be obtained from
- converting each <hexpair> of the <hexstring> to the octet indicated by
- the <hexpair>.
-
- One or more attribute values assertions, separated by <PLUS>, for a
- relative distinguished name.
-
- Zero or more relative distinguished names, separated by <COMMA>, for a
- distinguished name.
-
- Implementations MUST recognize AttributeType name strings
- (descriptors) listed in the following table, but MAY recognize other
- name strings.
-
- String X.500 AttributeType
- ------ --------------------------------------------
- CN commonName (2.5.4.3)
- L localityName (2.5.4.7)
- ST stateOrProvinceName (2.5.4.8)
- O organizationName (2.5.4.10)
- OU organizationalUnitName (2.5.4.11)
- C countryName (2.5.4.6)
- STREET streetAddress (2.5.4.9)
- DC domainComponent (0.9.2342.19200300.100.1.25)
- UID userId (0.9.2342.19200300.100.1.1)
-
- Implementations MAY recognize other DN string representations (such as
- that described in RFC 1779). However, as there is no requirement that
- alternative DN string representations to be recognized (and, if so,
- how), implementations SHOULD only generate DN strings in accordance
- with Section 2 of this document.
-
-
-4. Examples
-
- This notation is designed to be convenient for common forms of name.
- This section gives a few examples of distinguished names written using
- this notation. First is a name containing three relative
- distinguished names (RDNs):
-
- UID=jsmith,DC=example,DC=net
-
- Here is an example name containing three RDNs, in which the first RDN
- is multi-valued:
-
- OU=Sales+CN=J. Smith,DC=example,DC=net
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 7]
-
-INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
-
-
- This example shows the method of escaping of a special characters
- appearing in a common name:
-
- CN=James \"Jim\" Smith\, III,DC=example,DC=net
-
- The following shows the method for encoding a value which contains a
- carriage return character:
-
- CN=Before\0dAfter,DC=example,DC=net
-
- In this RDN example, the type in the RDN is unrecognized, and the
- value is the BER encoding of an OCTET STRING containing two octets
- 0x48 and 0x69.
-
- 1.3.6.1.4.1.1466.0=#04024869
-
- Finally, this example shows an RDN whose commonName value consisting
- of 5 letters:
-
- Unicode Character Code UTF-8 Escaped
- ------------------------------- ------ ------ --------
- LATIN CAPITAL LETTER L U+004C 0x4C L
- LATIN SMALL LETTER U U+0075 0x75 u
- LATIN SMALL LETTER C WITH CARON U+010D 0xC48D \C4\8D
- LATIN SMALL LETTER I U+0069 0x69 i
- LATIN SMALL LETTER C WITH ACUTE U+0107 0xC487 \C4\87
-
- could be encoded in printable ASCII (useful for debugging purposes)
- as:
-
- CN=Lu\C4\8Di\C4\87
-
-
-5. Security Considerations
-
- The following security considerations are specific to the handling of
- distinguished names. LDAP security considerations are discussed in
- [Protocol] and other documents comprising the LDAP Technical
- Specification [Roadmap].
-
-
-5.1. Disclosure
-
- Distinguished Names typically consist of descriptive information about
- the entries they name, which can be people, organizations, devices or
- other real-world objects. This frequently includes some of the
- following kinds of information:
-
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 8]
-
-INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
-
-
- - the common name of the object (i.e. a person's full name)
- - an email or TCP/IP address
- - its physical location (country, locality, city, street address)
- - organizational attributes (such as department name or affiliation)
-
- In some cases, such information can be considered sensitive. In many
- countries, privacy laws exist which prohibit disclosure of certain
- kinds of descriptive information (e.g., email addresses). Hence,
- servers implementors are encouraged to support DIT structural rules
- and name forms [Models] as these provide a mechanism for
- administrators to select appropriate naming attributes for entries.
- Administrators are encouraged to use these mechanisms, access
- controls, and other administrative controls which may be available to
- restrict use of attributes containing sensitive information in naming
- of entries. Additionally, use of authentication and data security
- services in LDAP [AuthMeth][Protocol] should be considered.
-
-
-5.2. Use of Distinguished Names in Security Applications
-
- The transformations of an AttributeValue value from its X.501 form to
- an LDAP string representation are not always reversible back to the
- same BER (Basic Encoding Rules) or DER (Distinguished Encoding rules)
- form. An example of a situation which requires the DER form of a
- distinguished name is the verification of an X.509 certificate.
-
- For example, a distinguished name consisting of one RDN with one AVA,
- in which the type is commonName and the value is of the TeletexString
- choice with the letters 'Sam' would be represented in LDAP as the
- string <CN=Sam>. Another distinguished name in which the value is
- still 'Sam' but of the PrintableString choice would have the same
- representation <CN=Sam>.
-
- Applications which require the reconstruction of the DER form of the
- value SHOULD NOT use the string representation of attribute syntaxes
- when converting a distinguished name to the LDAP format. Instead,
- they SHOULD use the hexadecimal form prefixed by the number sign ('#'
- U+0023) as described in the first paragraph of Section 2.4.
-
-
-6. Acknowledgment
-
- This document is an update to RFC 2253, by Mark Wahl, Tim Howes, and
- Steve Kille. RFC 2253 was a product of the IETF ASID Working Group.
-
- This document is a product of the IETF LDAPBIS Working Group.
-
-
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 9]
-
-INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
-
-
-7. Document Editor's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- Email: Kurt@OpenLDAP.org
-
-
-8. References
-
- [[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn where
- possible.]]
-
-
-8.1. Normative References
-
- [X.501] International Telecommunication Union -
- Telecommunication Standardization Sector, "The Directory
- -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
-
- [X.680] International Telecommunication Union -
- Telecommunication Standardization Sector, "Abstract
- Syntax Notation One (ASN.1) - Specification of Basic
- Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
- [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
-
- [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", RFC 3629 (also STD 63), November 2003.
-
- [Unicode] The Unicode Consortium, "The Unicode Standard, Version
- 3.2.0" is defined by "The Unicode Standard, Version 3.0"
- (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
- as amended by the "Unicode Standard Annex #27: Unicode
- 3.1" (http://www.unicode.org/reports/tr27/) and by the
- "Unicode Standard Annex #28: Unicode 3.2"
- (http://www.unicode.org/reports/tr28/).
-
- [Models] Zeilenga, K. (editor), "LDAP: Directory Information
- Models", draft-ietf-ldapbis-models-xx.txt, a work in
- progress.
-
- [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 10]
-
-INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
-
-
- Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
- progress.
-
- [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
- draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
-
- [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
- draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
-
- [Schema] Dally, K. (editor), "LDAP: User Schema",
- draft-ietf-ldapbis-user-schema-xx.txt, a work in
- progress.
-
- [REGISTRY] IANA, Object Identifier Descriptors Registry,
- <http://www.iana.org/...>.
-
-8.2. Informative References
-
- [ASCII] Coded Character Set--7-bit American Standard Code for
- Information Interchange, ANSI X3.4-1986.
-
- [X.500] International Telecommunication Union -
- Telecommunication Standardization Sector, "The Directory
- -- Overview of concepts, models and services,"
- X.500(1993) (also ISO/IEC 9594-1:1994).
-
- [X.690] International Telecommunication Union -
- Telecommunication Standardization Sector, "Specification
- of ASN.1 encoding rules: Basic Encoding Rules (BER),
- Canonical Encoding Rules (CER), and Distinguished
- Encoding Rules (DER)", X.690(1997) (also ISO/IEC
- 8825-1:1998).
-
- [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) -
- Technical Specification", RFC 2849, June 2000.
-
- [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
- draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
-
- [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report
- #17, Character Encoding Model", UTR17,
- <http://www.unicode.org/unicode/reports/tr17/>, August
- 2000.
-
- [Glossary] The Unicode Consortium, "Unicode Glossary",
- <http://www.unicode.org/glossary/>.
-
-
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 11]
-
-INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
-
-
-Appendix A. Presentation Issues
-
- This appendix is provided for informational purposes only, it is not a
- normative part of this specification.
-
- The string representation described in this document is not intended
- to be presented to humans without translation. However, at times it
- may be desirable to present non-translated DN strings to users. This
- section discusses presentation issues associated with non-translated
- DN strings. Presentation of translated DN strings issues are not
- discussed in this appendix. Transcoding issues are also not discussed
- in this appendix.
-
- This appendix provides guidance for applications presenting DN strings
- to users. This section is not comprehensive, it does not discuss all
- presentation issues which implementors may face.
-
- Not all user interfaces are capable of displaying the full set of
- Unicode characters. Some Unicode characters are not displayable.
-
- It is recommended that human interfaces use the optional hex pair
- escaping mechanism (Section 2.3) to produce a string representation
- suitable for display to the user. For example, an application can
- generate a DN string for display which escapes all non-printable
- characters appearing in the AttributeValue's string representation (as
- demonstrated in the final example of Section 4).
-
- When a DN string is displayed in free form text, it is often necessary
- to distinguish the DN string from surrounding text. While this is
- often done with white space (as demonstrated in Section 4), it is
- noted that DN strings may end with white space. Careful readers of
- Section 3 will note that characters '<' (U+003C) and '>' (U+003E) may
- only appear in the DN string if escaped. These characters are
- intended to be used in free form text to distinguish a DN string from
- surrounding text. For example, <CN=Sam\ > distinguished the string
- representation of the DN comprised of one RDN consisting of the AVA:
- the commonName (CN) value 'Sam ' from the surrounding text. It should
- be noted to the user that the wrapping '<' and '>' characters are not
- part of the DN string.
-
- DN strings can be quite long. It is often desirable to line-wrap
- overly long DN strings in presentations. Line wrapping should be done
- by inserting white space after the RDN separator character or, if
- necessary, after the AVA separator character. It should be noted to
- the user that the inserted white space is not part of the DN string
- and is to be removed before use in LDAP. For example,
-
- The following DN string is long:
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 12]
-
-INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
-
-
- CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores,
- O=OpenLDAP Foundation,ST=California,C=US
- so it has been line-wrapped for readability. The extra white
- space is to be removed before the DN string is used in LDAP.
-
- It is not advised to insert white space otherwise as it may not be
- obvious to the user which white space is part of the DN string and
- which white space was added for readability.
-
- Another alternative is to use the LDAP Data Interchange Format (LDIF)
- [RFC2849]. For example,
-
- # This entry has a long DN...
- dn: CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores,
- O=OpenLDAP Foundation,ST=California,C=US
- CN: Kurt D. Zeilenga
- SN: Zeilenga
- objectClass: person
-
-
-Appendix B. Changes made since RFC 2253
-
- This appendix is provided for informational purposes only, it is not a
- normative part of this specification.
-
- The following substantive changes were made to RFC 2253:
- - Removed IESG Note. The IESG Note has been addressed.
- - Replaced all references to ISO 10646-1 with [Unicode].
- - Clarified (in Section 1) that this document does not define a
- canonical string representation.
- - Clarified that Section 2 describes the RECOMMENDED encoding
- algorithm and that alternative algorithms are allowed. Some
- encoding options described in RFC 2253 are now treated as
- alternative algorithms in this specification.
- - Revised specification (in Section 2) to allow short names of any
- registered attribute type to appear in string representations of
- DNs instead of being restricted to a "published table". Remove
- "as an example" language. Added statement (in Section 3) allowing
- recognition of additional names but require recognization of those
- names in the published table. The table is now published in
- Section 3.
- - Removed specification of additional requirements for LDAPv2
- implementations which also support LDAPv3 (RFC 2253, Section 4) as
- LDAPv2 is now Historic.
- - Allow recognition of alternative string representations.
- - Updated Section 2.4 to allow hex pair escaping of all characters
- and clarified escaping for when multiple octet UTF-8 encodings are
- present. Indicated that null (U+0000) character is to be escaped.
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 13]
-
-INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
-
-
- Indicated that equals sign ('=' U+003D) character may be escaped
- as '\='.
- - Rewrote Section 3 to use ABNF as defined in RFC 2234.
- - Updated the Section 3 ABNF. Changes include:
- + allow AttributeType short names of length 1 (e.g., 'L'),
- + use more restrictive <oid> production in AttributeTypes,
- + do not require escaping of equals sign ('=' U+003D) characters,
- + do not require escaping of non-leading number sign ('#' U+0023)
- characters,
- + allow space (' ' U+0020) to escaped as '\ ',
- + require hex escaping of null (U+0000) characters, and
- + removed LDAPv2-only constructs.
- - Updated Section 3 to describe how to parse elements of the
- grammar.
- - Rewrote examples.
- - Added reference to documentations containing general LDAP security
- considerations.
- - Added discussion of presentation issues (Appendix A).
- - Added this appendix.
-
- In addition, numerous editorial changes were made.
-
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be found
- in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this specification
- can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 14]
-
-INTERNET-DRAFT draft-ietf-ldapbis-dn-16.txt 10 February 2005
-
-
-Full Copyright
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga LDAP: Distinguished Names [Page 15]
-
-
diff --git a/doc/drafts/draft-ietf-ldapbis-models-xx.txt b/doc/drafts/draft-ietf-ldapbis-models-xx.txt
deleted file mode 100644
index 43d85caa0b343bf321b92804ff116831596491c3..0000000000000000000000000000000000000000
--- a/doc/drafts/draft-ietf-ldapbis-models-xx.txt
+++ /dev/null
@@ -1,2857 +0,0 @@
-
-
-
-
-INTERNET-DRAFT Editor: Kurt D. Zeilenga
-Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 21 February 2005
-Obsoletes: RFC 2251, RFC 2252, RFC 2256, RFC 3674
-
-
-
- LDAP: Directory Information Models
- <draft-ietf-ldapbis-models-14.txt>
-
-
-
-Status of this Memo
-
- This document is intended to be published as a Standard Track RFC.
- Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDAP Revision Working Group
- mailing list <ietf-ldapbis@openldap.org>. Please send editorial
- comments directly to the editor <Kurt@OpenLDAP.org>.
-
- By submitting this Internet-Draft, I accept the provisions of Section
- 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
- applicable patent or other IPR claims of which I am aware have been
- disclosed, or will be disclosed, and any of which I become aware will
- be disclosed, in accordance with RFC 3668.
-
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference material
- or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
- Copyright (C) The Internet Society (2005). All Rights Reserved.
-
- Please see the Full Copyright section near the end of this document
- for more information.
-
-
-
-
-
-Zeilenga LDAP Models [Page 1]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
-Abstract
-
- The Lightweight Directory Access Protocol (LDAP) is an Internet
- protocol for accessing distributed directory services which act in
- accordance with X.500 data and service models. This document
- describes the X.500 Directory Information Models, as used in LDAP.
-
-Table of Contents
-
- Status of this Memo 1
- Abstract 2
- Table of Contents
- 1. Introduction 3
- 1.1. Relationship to Other LDAP Specifications
- 1.2. Relationship to X.501 4
- 1.3. Conventions
- 1.4. Common ABNF Productions
- 2. Model of Directory User Information 6
- 2.1. The Directory Information Tree 7
- 2.2. Structure of an Entry
- 2.3. Naming of Entries 8
- 2.4. Object Classes 9
- 2.5. Attribute Descriptions 12
- 2.6. Alias Entries 16
- 3. Directory Administrative and Operational Information 17
- 3.1. Subtrees
- 3.2. Subentries 18
- 3.3. The 'objectClass' attribute
- 3.4. Operational attributes 19
- 4. Directory Schema 22
- 4.1. Schema Definitions 23
- 4.2. Subschema Subentries 32
- 4.3. 'extensibleObject' 35
- 4.4. Subschema Discovery 36
- 5. DSA (Server) Informational Model
- 5.1. Server-specific Data Requirements 37
- 6. Other Considerations 40
- 6.1. Preservation of User Information 41
- 6.2. Short Names
- 6.3. Cache and Shadowing
- 7. Implementation Guidelines 42
- 7.1. Server Guidelines
- 7.2. Client Guidelines
- 8. Security Considerations 43
- 9. IANA Considerations
- 10. Acknowledgments 44
- 11. Editor's Address
- 12. References
-
-
-
-Zeilenga LDAP Models [Page 2]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- 12.1. Normative References 45
- 12.2. Informative References
- Appendix A. Changes
- Intellectual Property Rights 51
- Full Copyright
-
-
-1. Introduction
-
- This document discusses the X.500 Directory Information Models
- [X.501], as used by the Lightweight Directory Access Protocol (LDAP)
- [Roadmap].
-
- The Directory is "a collection of open systems cooperating to provide
- directory services" [X.500]. The information held in the Directory is
- collectively known as the Directory Information Base (DIB). A
- Directory user, which may be a human or other entity, accesses the
- Directory through a client (or Directory User Agent (DUA)). The
- client, on behalf of the directory user, interacts with one or more
- servers (or Directory System Agents (DSA)). A server holds a fragment
- of the DIB.
-
- The DIB contains two classes of information:
-
- 1) user information (e.g., information provided and administrated
- by users). Section 2 describes the Model of User Information.
-
- 2) administrative and operational information (e.g., information
- used to administer and/or operate the directory). Section 3
- describes the model of Directory Administrative and Operational
- Information.
-
- These two models, referred to as the generic Directory Information
- Models, describe how information is represented in the Directory.
- These generic models provide a framework for other information models.
- Section 4 discusses the subschema information model and subschema
- discovery. Section 5 discusses the DSA (Server) Informational Model.
-
- Other X.500 information models, such as access control distribution
- knowledge, and replication knowledge information models, may be
- adapted for use in LDAP. Specification of how these models apply to
- LDAP is left to future documents.
-
-
-1.1. Relationship to Other LDAP Specifications
-
- This document is a integral part of the LDAP technical specification
- [Roadmap] which obsoletes the previously defined LDAP technical
-
-
-
-Zeilenga LDAP Models [Page 3]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- specification, RFC 3377, in its entirety.
-
- This document obsoletes RFC 2251 sections 3.2 and 3.4, as well as
- portions of sections 4 and 6. Appendix A.1 summarizes changes to
- these sections. The remainder of RFC 2251 is obsoleted by the
- [Protocol], [AuthMeth], and [Roadmap] documents.
-
- This document obsoletes RFC 2252 sections 4, 5 and 7. Appendix A.2
- summarizes changes to these sections. The remainder of RFC 2252 is
- obsoleted by [Syntaxes].
-
- This document obsoletes RFC 2256 sections 5.1, 5.2, 7.1 and 7.2.
- Appendix A.3 summarizes changes to these sections. The remainder of
- RFC 2256 is obsoleted by [Schema] and [Syntaxes].
-
- This document obsoletes RFC 3674 in its entirety. Appendix A.4
- summarizes changes since RFC 3674.
-
-
-1.2. Relationship to X.501
-
- This document includes material, with and without adaptation, from
- [X.501] as necessary to describe this protocol. These adaptations
- (and any other differences herein) apply to this protocol, and only
- this protocol.
-
-
-1.3. Conventions
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119].
-
- Schema definitions are provided using LDAP description formats (as
- defined in Section 4.1). Definitions provided here are formatted
- (line wrapped) for readability. Matching rules and LDAP syntaxes
- referenced in these definitions are specified in [Syntaxes].
-
-
-1.4. Common ABNF Productions
-
- A number of syntaxes in this document are described using Augmented
- Backus-Naur Form (ABNF) [RFC2234]. These syntaxes (as well as a
- number of syntaxes defined in other documents) rely on the following
- common productions:
-
- keystring = leadkeychar *keychar
- leadkeychar = ALPHA
-
-
-
-Zeilenga LDAP Models [Page 4]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- keychar = ALPHA / DIGIT / HYPHEN
- number = DIGIT / ( LDIGIT 1*DIGIT )
-
- ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
- DIGIT = %x30 / LDIGIT ; "0"-"9"
- LDIGIT = %x31-39 ; "1"-"9"
- HEX = DIGIT / %x41-46 / %x61-66 ; "0"-"9" / "A"-"F" / "a"-"f"
-
- SP = 1*SPACE ; one or more " "
- WSP = 0*SPACE ; zero or more " "
-
- NULL = %x00 ; null (0)
- SPACE = %x20 ; space (" ")
- DQUOTE = %x22 ; quote (""")
- SHARP = %x23 ; octothorpe (or sharp sign) ("#")
- DOLLAR = %x24 ; dollar sign ("$")
- SQUOTE = %x27 ; single quote ("'")
- LPAREN = %x28 ; left paren ("(")
- RPAREN = %x29 ; right paren (")")
- PLUS = %x2B ; plus sign ("+")
- COMMA = %x2C ; comma (",")
- HYPHEN = %x2D ; hyphen ("-")
- DOT = %x2E ; period (".")
- SEMI = %x3B ; semicolon (";")
- LANGLE = %x3C ; left angle bracket ("<")
- EQUALS = %x3D ; equals sign ("=")
- RANGLE = %x3E ; right angle bracket (">")
- ESC = %x5C ; backslash ("\")
- USCORE = %x5F ; underscore ("_")
- LCURLY = %x7B ; left curly brace "{"
- RCURLY = %x7D ; right curly brace "}"
-
- ; Any UTF-8 [UTF-8] encoded Unicode [Unicode] character
- UTF8 = UTF1 / UTFMB
- UTFMB = UTF2 / UTF3 / UTF4
- UTF0 = %x80-BF
- UTF1 = %x00-7F
- UTF2 = %xC2-DF UTF0
- UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
- %xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
- UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
- %xF4 %x80-8F 2(UTF0)
-
- OCTET = %x00-FF ; Any octet (8-bit data unit)
-
- Object identifiers (OIDs) [X.680] are represented in LDAP using a
- dot-decimal format conforming to the ABNF:
-
-
-
-
-Zeilenga LDAP Models [Page 5]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- numericoid = number 1*( DOT number )
-
- Short names, also known as descriptors, are used as more readable
- aliases for object identifiers. Short names are case insensitive and
- conform to the ABNF:
-
- descr = keystring
-
- Where either an object identifier or a short name may be specified,
- the following production is used:
-
- oid = descr / numericoid
-
- While the <descr> form is generally preferred when the usage is
- restricted to short names referring to object identifiers which
- identify like kinds of objects (e.g., attribute type descriptions,
- matching rule descriptions, object class descriptions), the
- <numericoid> form should be used when the object identifiers may
- identify multiple kinds of objects or when an unambiguous short name
- (descriptor) is not available.
-
- Implementations SHOULD treat short names (descriptors) used in an
- ambiguous manner (as discussed above) as unrecognized.
-
- Short Names (descriptors) are discussed further in Section 6.2.
-
-
-2. Model of Directory User Information
-
- As [X.501] states:
-
- The purpose of the Directory is to hold, and provide access to,
- information about objects of interest (objects) in some 'world'.
- An object can be anything which is identifiable (can be named).
-
- An object class is an identified family of objects, or conceivable
- objects, which share certain characteristics. Every object belongs
- to at least one class. An object class may be a subclass of other
- object classes, in which case the members of the former class, the
- subclass, are also considered to be members of the latter classes,
- the superclasses. There may be subclasses of subclasses, etc., to
- an arbitrary depth.
-
- A directory entry, a named collection of information, is the basic
- unit of information held in the Directory. There are multiple kinds
- of directory entries.
-
- An object entry represents a particular object. An alias entry
-
-
-
-Zeilenga LDAP Models [Page 6]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- provides alternative naming. A subentry holds administrative and/or
- operational information.
-
- The set of entries representing the DIB are organized hierarchically
- in a tree structure known as the Directory Information Tree (DIT).
-
- Section 2.1 describes the Directory Information Tree
- Section 2.2 discusses the structure of entries.
- Section 2.3 discusses naming of entries.
- Section 2.4 discusses object classes.
- Section 2.5 discusses attribute descriptions.
- Section 2.6 discusses alias entries.
-
-
-2.1. The Directory Information Tree
-
- As noted above, the DIB is composed of a set of entries organized
- hierarchically in a tree structure known as the Directory Information
- Tree (DIT). Specifically, a tree where vertices are the entries.
-
- The arcs between vertices define relations between entries. If an arc
- exists from X to Y, then the entry at X is the immediate superior of Y
- and Y is the immediate subordinate of X. An entry's superiors are the
- entry's immediate superior and its superiors. An entry's subordinates
- are all of its immediate subordinates and their subordinates.
-
- Similarly, the superior/subordinate relationship between object
- entries can be used to derive a relation between the objects they
- represent. DIT structure rules can be used to govern relationships
- between objects.
-
- Note: An entry's immediate superior is also known as the entry's
- parent and an entry's immediate subordinate is also known as the
- entry's child. Entries which have the same parent are known as
- siblings.
-
-
-2.2. Structure of an Entry
-
- An entry consists of a set of attributes which hold information about
- the object which the entry represents. Some attributes represent user
- information and are called user attributes. Other attributes
- represent operational and/or administrative information and are called
- operational attributes.
-
- An attribute is an attribute description (a type and zero or more
- options) with one or more associated values. An attribute is often
- referred to by its attribute description. For example, the
-
-
-
-Zeilenga LDAP Models [Page 7]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- 'givenName' attribute is the attribute which consists of the attribute
- description 'givenName' (the 'givenName' attribute type [Schema] and
- zero options) and one or more associated values.
-
- The attribute type governs whether the attribute can have multiple
- values, the syntax and matching rules used to construct and compare
- values of that attribute, and other functions. Options indicate
- subtypes and other functions.
-
- Attribute values conform to the defined syntax of the attribute type.
-
- No two values of an attribute may be equivalent. Two values are
- considered equivalent if and only if they would match according to the
- equality matching rule of the attribute type or, if the attribute type
- is defined with no equality matching rule, two values are equivalent
- if and only if they are identical. (See 2.5.1 for other
- restrictions.)
-
- For example, a 'givenName' attribute can have more than one value,
- they must be Directory Strings, and they are case insensitive. A
- 'givenName' attribute cannot hold both "John" and "JOHN" as these are
- equivalent values per the equality matching rule of the attribute
- type.
-
- Additionally, no attribute is to have a value which is not equivalent
- to itself. For example, the 'givenName' attribute cannot have as a
- value a directory string which includes the REPLACEMENT CHARACTER
- (U+FFFD) code point as matching involving that directory string is
- Undefined per this attribute's equality matching rule.
-
- When an attribute is used for naming of the entry, one and only one
- value of the attribute is used in forming the Relative Distinguished
- Name. This value is known as a distinguished value.
-
-
-2.3. Naming of Entries
-
-2.3.1. Relative Distinguished Names
-
- Each entry is named relative to its immediate superior. This relative
- name, known as its Relative Distinguished Name (RDN) [X.501], is
- composed of an unordered set of one or more attribute value assertions
- (AVA) consisting of an attribute description with zero options and an
- attribute value. These AVAs are chosen to match attribute values
- (each a distinguished value) of the entry.
-
- An entry's relative distinguished name must be unique among all
- immediate subordinates of the entry's immediate superior (i.e., all
-
-
-
-Zeilenga LDAP Models [Page 8]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- siblings).
-
- The following are examples of string representations of RDNs [LDAPDN]:
-
- UID=12345
- OU=Engineering
- CN=Kurt Zeilenga+L=Redwood Shores
-
- The last is an example of a multi-valued RDN. That is, an RDN
- composed of multiple AVAs.
-
-
-2.3.2. Distinguished Names
-
- An entry's fully qualified name, known as its Distinguished Name (DN)
- [X.501], is the concatenation of its RDN and its immediate superior's
- DN. A Distinguished Name unambiguously refers to an entry in the
- tree. The following are examples of string representations of DNs
- [LDAPDN]:
-
- UID=nobody@example.com,DC=example,DC=com
- CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US
-
-
-2.3.3. Alias Names
-
- An alias, or alias name, is "an name for an object, provided by the
- use of alias entries" [X.501]. Alias entries are described in Section
- 2.6.
-
-
-2.4. Object Classes
-
- An object class is "an identified family of objects (or conceivable
- objects) which share certain characteristics" [X.501].
-
- As defined in [X.501]:
-
- Object classes are used in the Directory for a number of purposes:
-
- - describing and categorising objects and the entries that
- correspond to these objects;
-
- - where appropriate, controlling the operation of the Directory;
-
- - regulating, in conjunction with DIT structure rule
- specifications, the position of entries in the DIT;
-
-
-
-
-Zeilenga LDAP Models [Page 9]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- - regulating, in conjunction with DIT content rule
- specifications, the attributes that are contained in entries;
-
- - identifying classes of entry that are to be associated with a
- particular policy by the appropriate administrative authority.
-
- An object class (a subclass) may be derived from an object class
- (its direct superclass) which is itself derived from an even more
- generic object class. For structural object classes, this process
- stops at the most generic object class, 'top' (defined in Section
- 2.4.1). An ordered set of superclasses up to the most superior
- object class of an object class is its superclass chain.
-
- An object class may be derived from two or more direct
- superclasses (superclasses not part of the same superclass chain).
- This feature of subclassing is termed multiple inheritance.
-
- Each object class identifies the set of attributes required to be
- present in entries belonging to the class and the set of attributes
- allowed to be present in entries belonging to the class. As an entry
- of a class must meet the requirements of each class it belongs to, it
- can be said that an object class inherits the sets of allowed and
- required attributes from its superclasses. A subclass can identify an
- attribute allowed by its superclass as being required. If an
- attribute is a member of both sets, it is required to be present.
-
- Each object class is defined to be one of three kinds of object
- classes: Abstract, Structural, or Auxiliary.
-
- Each object class is identified by an object identifier (OID) and,
- optionally, one or more short names (descriptors).
-
-
-2.4.1. Abstract Object Classes
-
- An abstract object class, as the name implies, provides a base of
- characteristics from which other object classes can be defined to
- inherit from. An entry cannot belong to an abstract object class
- unless it belongs to a structural or auxiliary class which inherits
- from that abstract class.
-
- Abstract object classes can not derive from structural nor auxiliary
- object classes.
-
- All structural object classes derive (directly or indirectly) from the
- 'top' abstract object class. Auxiliary object classes do not
- necessarily derive from 'top'.
-
-
-
-
-Zeilenga LDAP Models [Page 10]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- The following is the object class definition (see Section 4.1.1) for
- the 'top' object class:
-
- ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
-
- All entries belong to the 'top' abstract object class.
-
-
-2.4.2. Structural Object Classes
-
- As stated in [X.501]:
-
- An object class defined for use in the structural specification of
- the DIT is termed a structural object class. Structural object
- classes are used in the definition of the structure of the names
- of the objects for compliant entries.
-
- An object or alias entry is characterised by precisely one
- structural object class superclass chain which has a single
- structural object class as the most subordinate object class.
- This structural object class is referred to as the structural
- object class of the entry.
-
- Structural object classes are related to associated entries:
-
- - an entry conforming to a structural object class shall
- represent the real-world object constrained by the object
- class;
-
- - DIT structure rules only refer to structural object classes;
- the structural object class of an entry is used to specify the
- position of the entry in the DIT;
-
- - the structural object class of an entry is used, along with an
- associated DIT content rule, to control the content of an
- entry.
-
- The structural object class of an entry shall not be changed.
-
- Each structural object class is a (direct or indirect) subclass of the
- 'top' abstract object class.
-
- Structural object classes cannot subclass auxiliary object classes.
-
- Each entry is said to belong to its structural object class as well as
- all classes in its structural object class's superclass chain.
-
-
-
-
-
-Zeilenga LDAP Models [Page 11]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
-2.4.3. Auxiliary Object Classes
-
- Auxiliary object classes are used to augment the characteristics of
- entries. They are commonly used to augment the sets of attributes
- required and allowed to be present in an entry. They can be used to
- describe entries or classes of entries.
-
- Auxiliary object classes cannot subclass structural object classes.
-
- An entry can belong to any subset of the set of auxiliary object
- classes allowed by the DIT content rule associated with the structural
- object class of the entry. If no DIT content rule is associated with
- the structural object class of the entry, the entry cannot belong to
- any auxiliary object class.
-
- The set of auxiliary object classes which an entry belongs to can
- change over time.
-
-
-2.5. Attribute Descriptions
-
- An attribute description is composed of an attribute type (see Section
- 2.5.1) and a set of zero or more attribute options (see Section
- 2.5.2).
-
- An attribute description is represented by the ABNF:
-
- attributedescription = attributetype options
- attributetype = oid
- options = *( SEMI option )
- option = 1*keychar
-
- where <attributetype> identifies the attribute type and each <option>
- identifies an attribute option. Both <attributetype> and <option>
- productions are case insensitive. The order in which <option>s appear
- is irrelevant. That is, any two <attributedescription>s which consist
- of the same <attributetype> and same set of <option>s are equivalent.
-
- Examples of valid attribute descriptions:
-
- 2.5.4.0
- cn;lang-de;lang-en
- owner
-
- An attribute description with an unrecognized attribute type is to be
- treated as unrecognized. Servers SHALL treat an attribute description
- with an unrecognized attribute option as unrecognized. Clients MAY
- treat an unrecognized attribute option as a tagging option (see
-
-
-
-Zeilenga LDAP Models [Page 12]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- Section 2.5.2.1).
-
- All attributes of an entry must have distinct attribute descriptions.
-
-
-2.5.1. Attribute Types
-
- An attribute type governs whether the attribute can have multiple
- values, the syntax and matching rules used to construct and compare
- values of that attribute, and other functions.
-
- If no equality matching is specified for the attribute type:
- - the attribute (of the type) cannot be used for naming;
- - when adding the attribute (or replacing all values), no two values
- may be equivalent (see 2.2);
- - individual values of a multi-valued attribute are not to be
- independently added or deleted;
- - attribute value assertions (such as matching in search filters and
- comparisons) using values of such a type cannot be performed.
-
- Otherwise, the specified equality matching rule is to be used for the
- purposes of evaluating attribute value assertions concerning the
- attribute type. The specified equality rule is to be transitive and
- commutative.
-
- The attribute type indicates whether the attribute is a user attribute
- or an operational attribute. If operational, the attribute type
- indicates the operational usage and whether the attribute is
- modifiable by users or not. Operational attributes are discussed in
- Section 3.4.
-
- An attribute type (a subtype) may derive from a more generic attribute
- type (a direct supertype). The following restrictions apply to
- subtyping:
- - a subtype must have the same usage as its direct supertype,
- - a subtype's syntax must be the same, or a refinement of, its
- supertype's syntax, and
- - a subtype must be collective [RFC3671] if its supertype is
- collective.
-
- An attribute description consisting of a subtype and no options is
- said to be the direct description subtype of the attribute description
- consisting of the subtype's direct supertype and no options.
-
- Each attribute type is identified by an object identifier (OID) and,
- optionally, one or more short names (descriptors).
-
-
-
-
-
-Zeilenga LDAP Models [Page 13]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
-2.5.2. Attribute Options
-
- There are multiple kinds of attribute description options. The LDAP
- technical specification details one kind: tagging options.
-
- Not all options can be associated with attributes held in the
- directory. Tagging options can be.
-
- Not all options can be used in conjunction with all attribute types.
- In such cases, the attribute description is to be treated as
- unrecognized.
-
- An attribute description that contains mutually exclusive options
- shall be treated as unrecognized. That is, "cn;x-bar;x-foo", where
- "x-foo" and "x-bar" are mutually exclusive, is to be treated as
- unrecognized.
-
- Other kinds of options may be specified in future documents. These
- documents must detail how new kinds of options they define relate to
- tagging options. In particular, these documents must detail whether
- or not new kinds of options can be associated with attributes held in
- the directory, how new kinds of options affect transfer of attribute
- values, and how new kinds of options are treated in attribute
- description hierarchies.
-
- Options are represented as short case insensitive textual strings
- conforming to the <option> production defined in Section 2.5 of this
- document.
-
- Procedures for registering options are detailed in BCP 64 [BCP64bis].
-
-
-2.5.2.1. Tagging Options
-
- Attributes held in the directory can have attribute descriptions with
- any number of tagging options. Tagging options are never mutually
- exclusive.
-
- An attribute description with N tagging options is a direct
- (description) subtype of all attribute descriptions of the same
- attribute type and all but one of the N options. If the attribute
- type has a supertype, then the attribute description is also a direct
- (description) subtype of the attribute description of the supertype
- and the N tagging options. That is, 'cn;lang-de;lang-en' is a direct
- (description) subtype of 'cn;lang-de', 'cn;lang-en', and
- 'name;lang-de;lang-en' ('cn' is a subtype of 'name', both are defined
- in [Schema]).
-
-
-
-
-Zeilenga LDAP Models [Page 14]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
-2.5.3. Attribute Description Hierarchies
-
- An attribute description can be the direct subtype of zero or more
- other attribute descriptions as indicated by attribute type subtyping
- (as described in Section 2.5.1) or attribute tagging option subtyping
- (as described in Section 2.5.2.1). These subtyping relationships are
- used to form hierarchies of attribute descriptions and attributes.
-
- As adapted from [X.501]:
-
- Attribute hierarchies allow access to the DIB with varying degrees
- of granularity. This is achieved by allowing the value components
- of attributes to be accessed by using either their specific
- attribute description (a direct reference to the attribute) or by
- a more generic attribute description (an indirect reference).
-
- Semantically related attributes may be placed in a hierarchical
- relationship, the more specialized being placed subordinate to the
- more generalized. Searching for, or retrieving attributes and
- their values is made easier by quoting the more generalized
- attribute description; a filter item so specified is evaluated for
- the more specialized descriptions as well as for the quoted
- description.
-
- Where subordinate specialized descriptions are selected to be
- returned as part of a search result these descriptions shall be
- returned if available. Where the more general descriptions are
- selected to be returned as part of a search result both the
- general and the specialized descriptions shall be returned, if
- available. An attribute value shall always be returned as a value
- of its own attribute description.
-
- All of the attribute descriptions in an attribute hierarchy are
- treated as distinct and unrelated descriptions for user
- modification of entry content.
-
- An attribute value stored in an object or alias entry is of
- precisely one attribute description. The description is indicated
- when the value is originally added to the entry.
-
- For the purpose of subschema administration of the entry, a
- specification that an attribute is required is fulfilled if the entry
- contains a value of an attribute description belonging to an attribute
- hierarchy where the attribute type of that description is the same as
- the required attribute's type. That is, a "MUST name" specification
- is fulfilled by 'name' or 'name;x-tag-option', but is not fulfilled by
- 'CN' nor by 'CN;x-tag-option' (even though 'CN' is a subtype of
- 'name'). Likewise, an entry may contain a value of an attribute
-
-
-
-Zeilenga LDAP Models [Page 15]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- description belonging to an attribute hierarchy where the attribute
- type of that description is either explicitly included in the
- definition of an object class to which the entry belongs or allowed by
- the DIT content rule applicable to that entry. That is, 'name' and
- 'name;x-tag-option' are allowed by "MAY name" (or by "MUST name"), but
- 'CN' and 'CN;x-tag-option' are not allowed by "MAY name" (nor by "MUST
- name").
-
- For the purposes of other policy administration, unless stated
- otherwise in the specification of the particular administrative model,
- all of the attribute descriptions in an attribute hierarchy are
- treated as distinct and unrelated descriptions.
-
-
-2.6. Alias Entries
-
- As adapted from [X.501]:
-
- An alias, or an alias name, for an object is an alternative name
- for an object or object entry which is provided by the use of
- alias entries.
-
- Each alias entry contains, within the 'aliasedObjectName'
- attribute (known as the 'aliasedEntryName' attribute in X.500]), a
- name of some object. The distinguished name of the alias entry is
- thus also a name for this object.
-
- NOTE - The name within the 'aliasedObjectName' is said to be
- pointed to by the alias. It does not have to be the
- distinguished name of any entry.
-
- The conversion of an alias name to an object name is termed
- (alias) dereferencing and comprises the systematic replacement of
- alias names, where found within a purported name, by the value of
- the corresponding 'aliasedObjectName' attribute. The process may
- require the examination of more than one alias entry.
-
- Any particular entry in the DIT may have zero or more alias names.
- It therefore follows that several alias entries may point to the
- same entry. An alias entry may point to an entry that is not a
- leaf entry and may point to another alias entry.
-
- An alias entry shall have no subordinates, so that an alias entry
- is always a leaf entry.
-
- Every alias entry shall belong to the 'alias' object class.
-
- An entry with the 'alias' object class must also belong to an object
-
-
-
-Zeilenga LDAP Models [Page 16]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- class (or classes), or be governed by a DIT content rule, which allows
- suitable naming attributes to be present.
-
- Example:
- dn: cn=bar,dc=example,dc=com
- objectClass: top
- objectClass: alias
- objectClass: extensibleObject
- cn: bar
- aliasedObjectName: cn=foo,dc=example,dc=com
-
-
-2.6.1. 'alias' object class
-
- Alias entries belong to the 'alias' object class.
-
- ( 2.5.6.1 NAME 'alias'
- SUP top STRUCTURAL
- MUST aliasedObjectName )
-
-
-2.6.2. 'aliasedObjectName' attribute type
-
- The 'aliasedObjectName' attribute holds the name of the entry an alias
- points to. The 'aliasedObjectName' attribute is known as the
- 'aliasedEntryName' attribute in X.500.
-
- ( 2.5.4.1 NAME 'aliasedObjectName'
- EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
- SINGLE-VALUE )
-
- The 'distinguishedNameMatch' matching rule and the DistinguishedName
- (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
-
-
-3. Directory Administrative and Operational Information
-
- This section discusses select aspects of the X.500 Directory
- Administrative and Operational Information model [X.501]. LDAP
- implementations MAY support other aspects of this model.
-
-
-3.1. Subtrees
-
- As defined in [X.501]:
-
- A subtree is a collection of object and alias entries situated at
-
-
-
-Zeilenga LDAP Models [Page 17]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- the vertices of a tree. Subtrees do not contain subentries. The
- prefix sub, in subtree, emphasizes that the base (or root) vertex
- of this tree is usually subordinate to the root of the DIT.
-
- A subtree begins at some vertex and extends to some identifiable
- lower boundary, possibly extending to leaves. A subtree is always
- defined within a context which implicitly bounds the subtree. For
- example, the vertex and lower boundaries of a subtree defining a
- replicated area are bounded by a naming context.
-
-
-3.2. Subentries
-
- A subentry is a "special sort of entry, known by the Directory, used
- to hold information associated with a subtree or subtree refinement"
- [X.501]. Subentries are used in Directory to hold for administrative
- and operational purposes as defined in [X.501]. Their use in LDAP is
- detailed in [RFC3672].
-
- The term "(sub)entry" in this specification indicates that servers
- implementing X.500(93) models are, in accordance with X.500(93) as
- described in [RFC3672], to use a subentry and that other servers are
- to use an object entry belonging to the appropriate auxiliary class
- normally used with the subentry (e.g., 'subschema' for subschema
- subentries) to mimic the subentry. This object entry's RDN SHALL be
- formed from a value of the 'cn' (commonName) attribute [Schema] (as
- all subentries are named with 'cn').
-
-
-3.3. The 'objectClass' attribute
-
- Each entry in the DIT has an 'objectClass' attribute.
-
- ( 2.5.4.0 NAME 'objectClass'
- EQUALITY objectIdentifierMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
-
- The 'objectIdentifierMatch' matching rule and the OBJECT IDENTIFIER
- (1.3.6.1.4.1.1466.115.121.1.38) syntax are defined in [Syntaxes].
-
- The 'objectClass' attribute specifies the object classes of an entry,
- which (among other things) is used in conjunction with the controlling
- schema to determine the permitted attributes of an entry. Values of
- this attribute can be modified by clients, but the 'objectClass'
- attribute cannot be removed.
-
- Servers which follow X.500(93) models SHALL restrict modifications of
- this attribute to prevent the basic structural class of the entry from
-
-
-
-Zeilenga LDAP Models [Page 18]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- being changed. That is, one cannot change a 'person' into a
- 'country'.
-
- When creating an entry or adding an 'objectClass' value to an entry,
- all superclasses of the named classes SHALL be implicitly added as
- well if not already present. That is, if the auxiliary class 'x-a' is
- a subclass of the class 'x-b', adding 'x-a' to 'objectClass' causes
- 'x-b' to be implicitly added (if is not already present).
-
- Servers SHALL restrict modifications of this attribute to prevent
- superclasses of remaining 'objectClass' values from being deleted.
- That is, if the auxiliary class 'x-a' is a subclass of the auxiliary
- class 'x-b' and the 'objectClass' attribute contains 'x-a' and 'x-b',
- an attempt to delete only 'x-b' from the 'objectClass' attribute is an
- error.
-
-
-3.4. Operational attributes
-
- Some attributes, termed operational attributes, are used or maintained
- by servers for administrative and operational purposes. As stated in
- [X.501]: "There are three varieties of operational attributes:
- Directory operational attributes, DSA-shared operational attributes,
- and DSA-specific operational attributes."
-
- A directory operational attribute is used to represent operational
- and/or administrative information in the Directory Information Model.
- This includes operational attributes maintained by the server (e.g.
- 'createTimestamp') as well as operational attributes which hold values
- administrated by the user (e.g. 'ditContentRules').
-
- A DSA-shared operational attribute is used to represent information of
- the DSA Information Model which is shared between DSAs.
-
- A DSA-specific operational attribute is used to represent information
- of the DSA Information Model which is specific to the DSA (though, in
- some cases, may be derived from information shared between DSAs)
- (e.g., 'namingContexts').
-
- The DSA Information Model operational attributes are detailed in
- [X.501].
-
- Operational attributes are not normally visible. They are not
- returned in search results unless explicitly requested by name.
-
- Not all operational attributes are user modifiable.
-
- Entries may contain, among others, the following operational
-
-
-
-Zeilenga LDAP Models [Page 19]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- attributes:
-
- - creatorsName: the Distinguished Name of the user who added this
- entry to the directory,
-
- - createTimestamp: the time this entry was added to the directory,
-
- - modifiersName: the Distinguished Name of the user who last
- modified this entry, and
-
- - modifyTimestamp: the time this entry was last modified.
-
- Servers SHOULD maintain the 'creatorsName', 'createTimestamp',
- 'modifiersName', and 'modifyTimestamp' attributes for all entries of
- the DIT.
-
-
-3.4.1. 'creatorsName'
-
- This attribute appears in entries which were added using the protocol
- (e.g., using the Add operation). The value is the distinguished name
- of the creator.
-
- ( 2.5.18.3 NAME 'creatorsName'
- EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
- SINGLE-VALUE NO-USER-MODIFICATION
- USAGE directoryOperation )
-
- The 'distinguishedNameMatch' matching rule and the DistinguishedName
- (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
-
-
-3.4.2. 'createTimestamp'
-
- This attribute appears in entries which were added using the protocol
- (e.g., using the Add operation). The value is the time the entry was
- added.
-
- ( 2.5.18.1 NAME 'createTimestamp'
- EQUALITY generalizedTimeMatch
- ORDERING generalizedTimeOrderingMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
- SINGLE-VALUE NO-USER-MODIFICATION
- USAGE directoryOperation )
-
- The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching
- rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax
-
-
-
-Zeilenga LDAP Models [Page 20]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- are defined in [Syntaxes].
-
-
-3.4.3. 'modifiersName'
-
- This attribute appears in entries which have been modified using the
- protocol (e.g., using Modify operation). The value is the
- distinguished name of the last modifier.
-
- ( 2.5.18.4 NAME 'modifiersName'
- EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
- SINGLE-VALUE NO-USER-MODIFICATION
- USAGE directoryOperation )
-
- The 'distinguishedNameMatch' matching rule and the DistinguishedName
- (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
-
-
-3.4.4. 'modifyTimestamp'
-
- This attribute appears in entries which have been modified using the
- protocol (e.g., using the Modify operation). The value is the time
- the entry was last modified.
-
- ( 2.5.18.2 NAME 'modifyTimestamp'
- EQUALITY generalizedTimeMatch
- ORDERING generalizedTimeOrderingMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
- SINGLE-VALUE NO-USER-MODIFICATION
- USAGE directoryOperation )
-
- The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching
- rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax
- are defined in [Syntaxes].
-
-
-3.4.5. 'structuralObjectClass'
-
- This attribute indicates the structural object class of the entry.
-
- ( 2.5.21.9 NAME 'structuralObjectClass'
- EQUALITY objectIdentifierMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
- SINGLE-VALUE NO-USER-MODIFICATION
- USAGE directoryOperation )
-
- The 'objectIdentifierMatch' matching rule and OBJECT IDENTIFIER
-
-
-
-Zeilenga LDAP Models [Page 21]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- (1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [Syntaxes].
-
-
-3.4.6. 'governingStructureRule'
-
- This attribute indicates the structure rule governing the entry.
-
- ( 2.5.21.10 NAME 'governingStructureRule'
- EQUALITY integerMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
- SINGLE-VALUE NO-USER-MODIFICATION
- USAGE directoryOperation )
-
- The 'integerMatch' matching rule and INTEGER
- (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in [Syntaxes].
-
-
-4. Directory Schema
-
- As defined in [X.501]:
-
- The Directory Schema is a set of definitions and constraints
- concerning the structure of the DIT, the possible ways entries are
- named, the information that can be held in an entry, the
- attributes used to represent that information and their
- organization into hierarchies to facilitate search and retrieval
- of the information and the ways in which values of attributes may
- be matched in attribute value and matching rule assertions.
-
- NOTE 1 - The schema enables the Directory system to, for example:
-
- - prevent the creation of subordinate entries of the wrong
- object-class (e.g. a country as a subordinate of a person);
-
- - prevent the addition of attribute-types to an entry
- inappropriate to the object-class (e.g. a serial number to a
- person's entry);
-
- - prevent the addition of an attribute value of a syntax not
- matching that defined for the attribute-type (e.g. a printable
- string to a bit string).
-
- Formally, the Directory Schema comprises a set of:
-
- a) Name Form definitions that define primitive naming relations
- for structural object classes;
-
- b) DIT Structure Rule definitions that define the names that
-
-
-
-Zeilenga LDAP Models [Page 22]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- entries may have and the ways in which the entries may be
- related to one another in the DIT;
-
- c) DIT Content Rule definitions that extend the specification of
- allowable attributes for entries beyond those indicated by the
- structural object classes of the entries;
-
- d) Object Class definitions that define the basic set of mandatory
- and optional attributes that shall be present, and may be
- present, respectively, in an entry of a given class, and which
- indicate the kind of object class that is being defined;
-
- e) Attribute Type definitions that identify the object identifier
- by which an attribute is known, its syntax, associated matching
- rules, whether it is an operational attribute and if so its
- type, whether it is a collective attribute, whether it is
- permitted to have multiple values and whether or not it is
- derived from another attribute type;
-
- f) Matching Rule definitions that define matching rules.
-
- And in LDAP:
-
- g) LDAP Syntax definitions that define encodings used in LDAP.
-
-
-4.1. Schema Definitions
-
- Schema definitions in this section are described using ABNF and rely
- on the common productions specified in Section 1.2 as well as these:
-
- noidlen = numericoid [ LCURLY len RCURLY ]
- len = number
-
- oids = oid / ( LPAREN WSP oidlist WSP RPAREN )
- oidlist = oid *( WSP DOLLAR WSP oid )
-
- extensions = *( SP xstring SP qdstrings )
- xstring = "X" HYPHEN 1*( ALPHA / HYPHEN / USCORE )
-
- qdescrs = qdescr / ( LPAREN WSP qdescrlist WSP RPAREN )
- qdescrlist = [ qdescr *( SP qdescr ) ]
- qdescr = SQUOTE descr SQUOTE
-
- qdstrings = qdstring / ( LPAREN WSP qdstringlist WSP RPAREN )
- qdstringlist = [ qdstring *( SP qdstring ) ]
- qdstring = SQUOTE dstring SQUOTE
- dstring = 1*( QS / QQ / QUTF8 ) ; escaped UTF-8 string
-
-
-
-Zeilenga LDAP Models [Page 23]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- QQ = ESC %x32 %x37 ; "\27"
- QS = ESC %x35 ( %x43 / %x63 ) ; "\5C" / "\5c"
-
- ; Any UTF-8 encoded Unicode character
- ; except %x27 ("'") and %x5C ("\")
- QUTF8 = QUTF1 / UTFMB
-
- ; Any ASCII character except %x27 ("'") and %x5C ("\")
- QUTF1 = %x00-26 / %x28-5B / %x5D-7F
-
- Schema definitions in this section also share a number of common
- terms.
-
- The NAME field provides a set of short names (descriptors) which are
- to be used as aliases for the OID.
-
- The DESC field optionally allows a descriptive string to be provided
- by the directory administrator and/or implementor. While
- specifications may suggest a descriptive string, there is no
- requirement that the suggested (or any) descriptive string be used.
-
- The OBSOLETE field, if present, indicates the element is not active.
-
- Implementors should note that future versions of this document may
- expand these definitions to include additional terms. Terms whose
- identifier begins with "X-" are reserved for private experiments, and
- are followed by <SP> and <qdstrings> tokens.
-
-
-4.1.1. Object Class Definitions
-
- Object Class definitions are written according to the ABNF:
-
- ObjectClassDescription = LPAREN WSP
- numericoid ; object identifier
- [ SP "NAME" SP qdescrs ] ; short names (descriptors)
- [ SP "DESC" SP qdstring ] ; description
- [ SP "OBSOLETE" ] ; not active
- [ SP "SUP" SP oids ] ; superior object classes
- [ SP kind ] ; kind of class
- [ SP "MUST" SP oids ] ; attribute types
- [ SP "MAY" SP oids ] ; attribute types
- extensions WSP RPAREN
-
- kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"
-
- where:
- <numericoid> is object identifier assigned to this object class;
-
-
-
-Zeilenga LDAP Models [Page 24]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- NAME <qdescrs> are short names (descriptors) identifying this object
- class;
- DESC <qdstring> is a short descriptive string;
- OBSOLETE indicates this object class is not active;
- SUP <oids> specifies the direct superclasses of this object class;
- the kind of object class is indicated by one of ABSTRACT,
- STRUCTURAL, or AUXILIARY, default is STRUCTURAL;
- MUST and MAY specify the sets of required and allowed attribute
- types, respectively; and
- <extensions> describe extensions.
-
-
-4.1.2. Attribute Types
-
- Attribute Type definitions are written according to the ABNF:
-
- AttributeTypeDescription = LPAREN WSP
- numericoid ; object identifier
- [ SP "NAME" SP qdescrs ] ; short names (descriptors)
- [ SP "DESC" SP qdstring ] ; description
- [ SP "OBSOLETE" ] ; not active
- [ SP "SUP" SP oid ] ; supertype
- [ SP "EQUALITY" SP oid ] ; equality matching rule
- [ SP "ORDERING" SP oid ] ; ordering matching rule
- [ SP "SUBSTR" SP oid ] ; substrings matching rule
- [ SP "SYNTAX" SP noidlen ] ; value syntax
- [ SP "SINGLE-VALUE" ] ; single-value
- [ SP "COLLECTIVE" ] ; collective
- [ SP "NO-USER-MODIFICATION" ] ; not user modifiable
- [ SP "USAGE" SP usage ] ; usage
- extensions WSP RPAREN ; extensions
-
- usage = "userApplications" / ; user
- "directoryOperation" / ; directory operational
- "distributedOperation" / ; DSA-shared operational
- "dSAOperation" ; DSA-specific operational
-
- where:
- <numericoid> is object identifier assigned to this attribute type;
- NAME <qdescrs> are short names (descriptors) identifying this
- attribute type;
- DESC <qdstring> is a short descriptive string;
- OBSOLETE indicates this attribute type is not active;
- SUP oid specifies the direct supertype of this type;
- EQUALITY, ORDERING, SUBSTR provide the oid of the equality,
- ordering, and substrings matching rules, respectively;
- SYNTAX identifies value syntax by object identifier and may suggest
- a minimum upper bound;
-
-
-
-Zeilenga LDAP Models [Page 25]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- SINGLE-VALUE indicates attributes of this type are restricted to a
- single value;
- COLLECTIVE indicates this attribute type is collective
- [X.501][RFC3671];
- NO-USER-MODIFICATION indicates this attribute type is not user
- modifiable;
- USAGE indicates the application of this attribute type; and
- <extensions> describe extensions.
-
- Each attribute type description must contain at least one of the SUP
- or SYNTAX fields. If no SYNTAX field is provided, the attribute type
- description takes its value from the supertype.
-
- If SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING
- fields, if not specified, take their value from the supertype.
-
- Usage of userApplications, the default, indicates that attributes of
- this type represent user information. That is, they are user
- attributes.
-
- A usage of directoryOperation, distributedOperation, or dSAOperation
- indicates that attributes of this type represent operational and/or
- administrative information. That is, they are operational attributes.
-
- directoryOperation usage indicates that the attribute of this type is
- a directory operational attribute. distributedOperation usage
- indicates that the attribute of this DSA-shared usage operational
- attribute. dSAOperation usage indicates that the attribute of this
- type is a DSA-specific operational attribute.
-
- COLLECTIVE requires usage userApplications. Use of collective
- attribute types in LDAP is discussed in [RFC3671].
-
- NO-USER-MODIFICATION requires an operational usage.
-
- Note that the <AttributeTypeDescription> does not list the matching
- rules which can be used with that attribute type in an extensibleMatch
- search filter [Protocol]. This is done using the 'matchingRuleUse'
- attribute described in Section 4.1.4.
-
- This document refines the schema description of X.501 by requiring
- that the SYNTAX field in an <AttributeTypeDescription> be a string
- representation of an object identifier for the LDAP string syntax
- definition with an optional indication of the suggested minimum bound
- of a value of this attribute.
-
- A suggested minimum upper bound on the number of characters in a value
- with a string-based syntax, or the number of bytes in a value for all
-
-
-
-Zeilenga LDAP Models [Page 26]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- other syntaxes, may be indicated by appending this bound count inside
- of curly braces following the syntax's OBJECT IDENTIFIER in an
- Attribute Type Description. This bound is not part of the syntax name
- itself. For instance, "1.3.6.4.1.1466.0{64}" suggests that server
- implementations should allow a string to be 64 characters long,
- although they may allow longer strings. Note that a single character
- of the Directory String syntax may be encoded in more than one octet
- since UTF-8 [RFC3629] is a variable-length encoding.
-
-
-4.1.3. Matching Rules
-
- Matching rules are used in performance of attribute value assertions,
- such as in performance of a Compare operation. They are also used in
- evaluation of a Search filters, in determining which individual values
- are be added or deleted during performance of a Modify operation, and
- used in comparison of distinguished names.
-
- Each matching rule is identified by an object identifier (OID) and,
- optionally, one or more short names (descriptors).
-
- Matching rule definitions are written according to the ABNF:
-
- MatchingRuleDescription = LPAREN WSP
- numericoid ; object identifier
- [ SP "NAME" SP qdescrs ] ; short names (descriptors)
- [ SP "DESC" SP qdstring ] ; description
- [ SP "OBSOLETE" ] ; not active
- SP "SYNTAX" SP numericoid ; assertion syntax
- extensions WSP RPAREN ; extensions
-
- where:
- <numericoid> is object identifier assigned to this matching rule;
- NAME <qdescrs> are short names (descriptors) identifying this
- matching rule;
- DESC <qdstring> is a short descriptive string;
- OBSOLETE indicates this matching rule is not active;
- SYNTAX identifies the assertion syntax (the syntax of the assertion
- value) by object identifier; and
- <extensions> describe extensions.
-
-
-4.1.4. Matching Rule Uses
-
- A matching rule use lists the attribute types which are suitable for
- use with an extensibleMatch search filter.
-
- Matching rule use descriptions are written according to the following
-
-
-
-Zeilenga LDAP Models [Page 27]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- ABNF:
-
- MatchingRuleUseDescription = LPAREN WSP
- numericoid ; object identifier
- [ SP "NAME" SP qdescrs ] ; short names (descriptors)
- [ SP "DESC" SP qdstring ] ; description
- [ SP "OBSOLETE" ] ; not active
- SP "APPLIES" SP oids ; attribute types
- extensions WSP RPAREN ; extensions
-
- where:
- <numericoid> is the object identifier of the matching rule
- associated with this matching rule use description;
- NAME <qdescrs> are short names (descriptors) identifying this
- matching rule use;
- DESC <qdstring> is a short descriptive string;
- OBSOLETE indicates this matching rule use is not active;
- APPLIES provides a list of attribute types the matching rule applies
- to; and
- <extensions> describe extensions.
-
-
-4.1.5. LDAP Syntaxes
-
- LDAP Syntaxes of (attribute and assertion) values are described in
- terms of ASN.1 [X.680] and, optionally, have an octet string encoding
- known as the LDAP-specific encoding. Commonly, the LDAP-specific
- encoding is constrained to a string of Unicode [Unicode] characters in
- UTF-8 [RFC3629] form.
-
- Each LDAP syntax is identified by an object identifier (OID).
-
- LDAP syntax definitions are written according to the ABNF:
-
- SyntaxDescription = LPAREN WSP
- numericoid ; object identifier
- [ SP "DESC" SP qdstring ] ; description
- extensions WSP RPAREN ; extensions
-
- where:
- <numericoid> is the object identifier assigned to this LDAP syntax;
- DESC <qdstring> is a short descriptive string; and
- <extensions> describe extensions.
-
-
-4.1.6. DIT Content Rules
-
- A DIT content rule is a "rule governing the content of entries of a
-
-
-
-Zeilenga LDAP Models [Page 28]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- particular structural object class" [X.501].
-
- For DIT entries of a particular structural object class, a DIT content
- rule specifies which auxiliary object classes the entries are allowed
- to belong to and which additional attributes (by type) are required,
- allowed or not allowed to appear in the entries.
-
- The list of precluded attributes cannot include any attribute listed
- as mandatory in the rule, the structural object class, or any of the
- allowed auxiliary object classes.
-
- Each content rule is identified by the object identifier, as well as
- any short names (descriptors), of the structural object class it
- applies to.
-
- An entry may only belong to auxiliary object classes listed in the
- governing content rule.
-
- An entry must contain all attributes required by the object classes
- the entry belongs to as well as all attributes required by the
- governing content rule.
-
- An entry may contain any non-precluded attributes allowed by the
- object classes the entry belongs to as well as all attributes allowed
- by the governing content rule.
-
- An entry cannot include any attribute precluded by the governing
- content rule.
-
- An entry is governed by (if present and active in the subschema) the
- DIT content rule which applies to the structural object class of the
- entry (see Section 2.4.2). If no active rule is present for the
- entry's structural object class, the entry's content is governed by
- the structural object class (and possibly other aspects of user and
- system schema). DIT content rules for superclasses of the structural
- object class of an entry are not applicable to that entry.
-
- DIT content rule descriptions are written according to the ABNF:
-
- DITContentRuleDescription = LPAREN WSP
- numericoid ; object identifier
- [ SP "NAME" SP qdescrs ] ; short names (descriptors)
- [ SP "DESC" SP qdstring ] ; description
- [ SP "OBSOLETE" ] ; not active
- [ SP "AUX" SP oids ] ; auxiliary object classes
- [ SP "MUST" SP oids ] ; attribute types
- [ SP "MAY" SP oids ] ; attribute types
- [ SP "NOT" SP oids ] ; attribute types
-
-
-
-Zeilenga LDAP Models [Page 29]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- extensions WSP RPAREN ; extensions
-
- where:
- <numericoid> is the object identifier of the structural object class
- associated with this DIT content rule;
- NAME <qdescrs> are short names (descriptors) identifying this DIT
- content rule;
- DESC <qdstring> is a short descriptive string;
- OBSOLETE indicates this DIT content rule use is not active;
- AUX specifies a list of auxiliary object classes which entries
- subject to this DIT content rule may belong to;
- MUST, MAY, and NOT specify lists of attribute types which are
- required, allowed, or precluded, respectively, from appearing in
- entries subject to this DIT content rule; and
- <extensions> describe extensions.
-
-
-4.1.7. DIT Structure Rules and Name Forms
-
- It is sometimes desirable to regulate where object and alias entries
- can be placed in the DIT and how they can be named based upon their
- structural object class.
-
-
-4.1.7.1. DIT Structure Rules
-
- A DIT structure rule is a "rule governing the structure of the DIT by
- specifying a permitted superior to subordinate entry relationship. A
- structure rule relates a name form, and therefore a structural object
- class, to superior structure rules. This permits entries of the
- structural object class identified by the name form to exist in the
- DIT as subordinates to entries governed by the indicated superior
- structure rules" [X.501].
-
- DIT structure rule descriptions are written according to the ABNF:
-
- DITStructureRuleDescription = LPAREN WSP
- ruleid ; rule identifier
- [ SP "NAME" SP qdescrs ] ; short names (descriptors)
- [ SP "DESC" SP qdstring ] ; description
- [ SP "OBSOLETE" ] ; not active
- SP "FORM" SP oid ; NameForm
- [ SP "SUP" ruleids ] ; superior rules
- extensions WSP RPAREN ; extensions
-
- ruleids = ruleid / ( LPAREN WSP ruleidlist WSP RPAREN )
- ruleidlist = ruleid *( SP ruleid )
- ruleid = number
-
-
-
-Zeilenga LDAP Models [Page 30]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- where:
- <ruleid> is the rule identifier of this DIT structure rule;
- NAME <qdescrs> are short names (descriptors) identifying this DIT
- structure rule;
- DESC <qdstring> is a short descriptive string;
- OBSOLETE indicates this DIT structure rule use is not active;
- FORM is specifies the name form associated with this DIT structure
- rule;
- SUP identifies superior rules (by rule id); and
- <extensions> describe extensions.
-
- If no superior rules are identified, the DIT structure rule applies
- to an autonomous administrative point (e.g. the root vertex of the
- subtree controlled by the subschema) [X.501].
-
-
-4.1.7.2. Name Forms
-
- A name form "specifies a permissible RDN for entries of a particular
- structural object class. A name form identifies a named object
- class and one or more attribute types to be used for naming (i.e.
- for the RDN). Name forms are primitive pieces of specification
- used in the definition of DIT structure rules" [X.501].
-
- Each name form indicates the structural object class to be named,
- a set of required attribute types, and a set of allowed attribute
- types. A particular attribute type cannot be in both sets.
-
- Entries governed by the form must be named using a value from each
- required attribute type and zero or more values from the allowed
- attribute types.
-
- Each name form is identified by an object identifier (OID) and,
- optionally, one or more short names (descriptors).
-
- Name form descriptions are written according to the ABNF:
-
- NameFormDescription = LPAREN WSP
- numericoid ; object identifier
- [ SP "NAME" SP qdescrs ] ; short names (descriptors)
- [ SP "DESC" SP qdstring ] ; description
- [ SP "OBSOLETE" ] ; not active
- SP "OC" SP oid ; structural object class
- SP "MUST" SP oids ; attribute types
- [ SP "MAY" SP oids ] ; attribute types
- extensions WSP RPAREN ; extensions
-
- where:
-
-
-
-Zeilenga LDAP Models [Page 31]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- <numericoid> is object identifier which identifies this name form;
- NAME <qdescrs> are short names (descriptors) identifying this name
- form;
- DESC <qdstring> is a short descriptive string;
- OBSOLETE indicates this name form is not active;
- OC identifies the structural object class this rule applies to,
- MUST and MAY specify the sets of required and allowed, respectively,
- naming attributes for this name form; and
- <extensions> describe extensions.
-
- All attribute types in the required ("MUST") and allowed ("MAY") lists
- shall be different.
-
-
-4.2. Subschema Subentries
-
- Subschema (sub)entries are used for administering information about
- the directory schema. A single subschema (sub)entry contains all
- schema definitions (see Section 4.1) used by entries in a particular
- part of the directory tree.
-
- Servers which follow X.500(93) models SHOULD implement subschema using
- the X.500 subschema mechanisms (as detailed in Section 12 of [X.501]),
- and so these are not ordinary object entries but subentries (see
- Section 3.2). LDAP clients SHOULD NOT assume that servers implement
- any of the other aspects of X.500 subschema.
-
- Servers MAY allow subschema modification. Procedures for subschema
- modification are discussed in Section 14.5 of [X.501].
-
- A server which masters entries and permits clients to modify these
- entries SHALL implement and provide access to these subschema
- (sub)entries including providing a 'subschemaSubentry' attribute in
- each modifiable entry. This is so clients may discover the attributes
- and object classes which are permitted to be present. It is strongly
- RECOMMENDED that all other servers implement this as well.
-
- The value of the 'subschemaSubentry' attribute is the name of the
- subschema (sub)entry holding the subschema controlling the entry.
-
- ( 2.5.18.10 NAME 'subschemaSubentry'
- EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
- NO-USER-MODIFICATION SINGLE-VALUE
- USAGE directoryOperation )
-
- The 'distinguishedNameMatch' matching rule and the DistinguishedName
- (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [Syntaxes].
-
-
-
-Zeilenga LDAP Models [Page 32]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- Subschema is held in (sub)entries belonging to the subschema auxiliary
- object class.
-
- ( 2.5.20.1 NAME 'subschema' AUXILIARY
- MAY ( dITStructureRules $ nameForms $ ditContentRules $
- objectClasses $ attributeTypes $ matchingRules $
- matchingRuleUse ) )
-
- The 'ldapSyntaxes' operational attribute may also be present in
- subschema entries.
-
- Servers MAY provide additional attributes (described in other
- documents) in subschema (sub)entries.
-
- Servers SHOULD provide the attributes 'createTimestamp' and
- 'modifyTimestamp' in subschema (sub)entries, in order to allow clients
- to maintain their caches of schema information.
-
- The following subsections provide attribute type definitions for each
- of schema definition attribute types.
-
-
-4.2.1. 'objectClasses'
-
- This attribute holds definitions of object classes.
-
- ( 2.5.21.6 NAME 'objectClasses'
- EQUALITY objectIdentifierFirstComponentMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.37
- USAGE directoryOperation )
-
- The 'objectIdentifierFirstComponentMatch' matching rule and the
- ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) syntax are
- defined in [Syntaxes].
-
-
-4.2.2. 'attributeTypes'
-
- This attribute holds definitions of attribute types.
-
- ( 2.5.21.5 NAME 'attributeTypes'
- EQUALITY objectIdentifierFirstComponentMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.3
- USAGE directoryOperation )
-
- The 'objectIdentifierFirstComponentMatch' matching rule and the
- AttributeTypeDescription (1.3.6.1.4.1.1466.115.121.1.3) syntax are
- defined in [Syntaxes].
-
-
-
-Zeilenga LDAP Models [Page 33]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
-4.2.3. 'matchingRules'
-
- This attribute holds definitions of matching rules.
-
- ( 2.5.21.4 NAME 'matchingRules'
- EQUALITY objectIdentifierFirstComponentMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.30
- USAGE directoryOperation )
-
- The 'objectIdentifierFirstComponentMatch' matching rule and the
- MatchingRuleDescription (1.3.6.1.4.1.1466.115.121.1.30) syntax are
- defined in [Syntaxes].
-
-
-4.2.4 'matchingRuleUse'
-
- This attribute holds definitions of matching rule uses.
-
- ( 2.5.21.8 NAME 'matchingRuleUse'
- EQUALITY objectIdentifierFirstComponentMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.31
- USAGE directoryOperation )
-
- The 'objectIdentifierFirstComponentMatch' matching rule and the
- MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) syntax are
- defined in [Syntaxes].
-
-
-4.2.5. 'ldapSyntaxes'
-
- This attribute holds definitions of LDAP syntaxes.
-
- ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes'
- EQUALITY objectIdentifierFirstComponentMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.54
- USAGE directoryOperation )
-
- The 'objectIdentifierFirstComponentMatch' matching rule and the
- SyntaxDescription (1.3.6.1.4.1.1466.115.121.1.54) syntax are defined
- in [Syntaxes].
-
-
-4.2.6. 'dITContentRules'
-
- This attribute lists DIT Content Rules which are present in the
- subschema.
-
- ( 2.5.21.2 NAME 'dITContentRules'
-
-
-
-Zeilenga LDAP Models [Page 34]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- EQUALITY objectIdentifierFirstComponentMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.16
- USAGE directoryOperation )
-
- The 'objectIdentifierFirstComponentMatch' matching rule and the
- DITContentRuleDescription (1.3.6.1.4.1.1466.115.121.1.16) syntax are
- defined in [Syntaxes].
-
-
-4.2.7. 'dITStructureRules'
-
- This attribute lists DIT Structure Rules which are present in the
- subschema.
-
- ( 2.5.21.1 NAME 'dITStructureRules'
- EQUALITY integerFirstComponentMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.17
- USAGE directoryOperation )
-
- The 'integerFirstComponentMatch' matching rule and the
- DITStructureRuleDescription (1.3.6.1.4.1.1466.115.121.1.17) syntax are
- defined in [Syntaxes].
-
-
-4.2.8 'nameForms'
-
- This attribute lists Name Forms which are in force.
-
- ( 2.5.21.7 NAME 'nameForms'
- EQUALITY objectIdentifierFirstComponentMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.35
- USAGE directoryOperation )
-
- The 'objectIdentifierFirstComponentMatch' matching rule and the
- NameFormDescription (1.3.6.1.4.1.1466.115.121.1.35) syntax are defined
- in [Syntaxes].
-
-
-4.3. 'extensibleObject' object class
-
- The 'extensibleObject' auxiliary object class allows entries that
- belong to it to hold any user attribute. The set of allowed attribute
- types of this object class is implicitly the set of all attribute
- types of userApplications usage.
-
- ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
- SUP top AUXILIARY )
-
-
-
-
-Zeilenga LDAP Models [Page 35]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- The mandatory attributes of the other object classes of this entry are
- still required to be present and any precluded attributes are still
- not allowed to be present.
-
-
-
-4.4. Subschema Discovery
-
- To discover the DN of the subschema (sub)entry holding the subschema
- controlling a particular entry, a client reads that entry's
- 'subschemaSubentry' operational attribute. To read schema attributes
- from the subschema (sub)entry, clients MUST issue a Search operation
- [Protocol] where baseObject is the DN of the subschema (sub)entry,
- scope is baseObject, filter is "(objectClass=subschema)" [Filters],
- and attributes field lists the names of the desired schema attributes
- (as they are operational). Note: the "(objectClass=subschema)" filter
- allows LDAP servers which gateway to X.500 to detect that subentry
- information is being requested.
-
- Clients SHOULD NOT assume a published subschema is complete nor assume
- the server supports all of the schema elements it publishes nor assume
- the server does not support an unpublished element.
-
-
-5. DSA (Server) Informational Model
-
- The LDAP protocol assumes there are one or more servers which jointly
- provide access to a Directory Information Tree (DIT). The server
- holding the original information is called the "master" (for that
- information). Servers which hold copies of the original information
- are referred to as "shadowing" or "caching" servers.
-
- As defined in [X.501]:
-
- context prefix: The sequence of RDNs leading from the Root of the
- DIT to the initial vertex of a naming context; corresponds to
- the distinguished name of that vertex.
-
- and:
-
- naming context: A subtree of entries held in a single master DSA.
-
- That is, a naming context is the largest collection of entries,
- starting at an entry that is mastered by a particular server, and
- including all its subordinates and their subordinates, down to the
- entries which are mastered by different servers. The context prefix
- is the name of the initial entry.
-
-
-
-
-Zeilenga LDAP Models [Page 36]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- The root of the DIT is a DSA-specific Entry (DSE) and not part of any
- naming context (or any subtree); each server has different attribute
- values in the root DSE.
-
-
-5.1. Server-specific Data Requirements
-
- An LDAP server SHALL provide information about itself and other
- information that is specific to each server. This is represented as a
- group of attributes located in the root DSE, which is named with the
- DN with zero RDNs (whose [LDAPDN] representation is as the zero-length
- string).
-
- These attributes are retrievable, subject to access control and other
- restrictions, if a client performs a Search operation [Protocol] with
- an empty baseObject, scope of baseObject, the filter "(objectClass=*)"
- [Filters], and with the attributes field listing the names of the
- desired attributes. It is noted that root DSE attributes are
- operational, and like other operational attributes, are not returned
- in search requests unless requested by name.
-
- The root DSE SHALL NOT be included if the client performs a subtree
- search starting from the root.
-
- Servers may allow clients to modify attributes of the root DSE where
- appropriate.
-
- The following attributes of the root DSE are defined in [Syntaxes].
- Additional attributes may be defined in other documents.
-
- - altServer: alternative servers;
-
- - namingContexts: naming contexts;
-
- - supportedControl: recognized LDAP controls;
-
- - supportedExtension: recognized LDAP extended operations;
-
- - supportedFeatures: recognized LDAP features;
-
- - supportedLDAPVersion: LDAP versions supported; and
-
- - supportedSASLMechanisms: recognized Simple Authentication and
- Security Layers (SASL) [SASL] mechanisms.
-
- The values provided for these attributes may depend on
- session-specific and other factors. For example, a server supporting
- the SASL EXTERNAL mechanism might only list "EXTERNAL" when the
-
-
-
-Zeilenga LDAP Models [Page 37]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- client's identity has been established by a lower level. See
- [AuthMeth].
-
- The root DSE may also include a 'subschemaSubentry' attribute. If so,
- it refers to the subschema (sub)entry holding the schema controlling
- the root DSE. Clients SHOULD NOT assume that this subschema
- (sub)entry controls other entries held by the server. General
- subschema discovery procedures are provided in Section 4.4.
-
-
-5.1.1. 'altServer'
-
- The 'altServer' attribute lists URIs referring to alternative servers
- which may be contacted when this server becomes unavailable. URIs for
- servers implementing the LDAP are written according to [LDAPURL].
- Other kinds of URIs may be provided. If the server does not know of
- any other servers which could be used this attribute will be absent.
- Clients may cache this information in case their preferred server
- later becomes unavailable.
-
- ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
- USAGE dSAOperation )
-
- The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax is defined in
- [Syntaxes].
-
-
-5.1.2. 'namingContexts'
-
- The 'namingContexts' attribute lists the context prefixes of the
- naming contexts the server masters or shadows (in part or in whole).
- If the server is a first-level DSA [X.501], it should list (in
- addition) an empty string (indicating the root of the DIT). If the
- server does not master or shadow any information (e.g. it is an LDAP
- gateway to a public X.500 directory) this attribute will be absent.
- If the server believes it masters or shadows the entire directory, the
- attribute will have a single value, and that value will be the empty
- string (indicating the root of the DIT).
-
- This attribute may be used, for example, to select a suitable entry
- name for subsequent operations with this server.
-
- ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
- USAGE dSAOperation )
-
- The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax is
-
-
-
-Zeilenga LDAP Models [Page 38]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- defined in [Syntaxes].
-
-
-5.1.3. 'supportedControl'
-
- The 'supportedControl' attribute lists object identifiers identifying
- the request controls [Protocol] the server supports. If the server
- does not support any request controls, this attribute will be absent.
- Object identifiers identifying response controls need not be listed.
-
- Procedures for registering object identifiers used to discovery of
- protocol mechanisms are detailed in BCP 64 [BCP64bis].
-
- ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
- USAGE dSAOperation )
-
- The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
- defined in [Syntaxes].
-
-
-5.1.4. 'supportedExtension'
-
- The 'supportedExtension' attribute lists object identifiers
- identifying the extended operations [Protocol] which the server
- supports. If the server does not support any extended operations,
- this attribute will be absent.
-
- An extended operation generally consists of an extended request and an
- extended response but may also include other protocol data units (such
- as intermediate responses). The object identifier assigned to the
- extended request is used to identify the extended operation. Other
- object identifiers used in the extended operation need not be listed
- as values of this attribute.
-
- Procedures for registering object identifiers used to discovery of
- protocol mechanisms are detailed in BCP 64 [BCP64bis].
-
- ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
- USAGE dSAOperation )
-
- The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
- defined in [Syntaxes].
-
-
-5.1.5. 'supportedFeatures'
-
-
-
-
-Zeilenga LDAP Models [Page 39]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- The 'supportedFeatures' attribute lists object identifiers identifying
- elective features which the server supports. If the server does not
- support any discoverable elective features, this attribute will be
- absent.
-
- ( 1.3.6.1.4.1.4203.1.3.5 NAME 'supportedFeatures'
- EQUALITY objectIdentifierMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
- USAGE dSAOperation )
-
- Procedures for registering object identifiers used to discovery of
- protocol mechanisms are detailed in BCP 64 [BCP64bis].
-
- The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax and
- objectIdentifierMatch matching rule are defined in [Syntaxes].
-
-
-5.1.6. 'supportedLDAPVersion'
-
- The 'supportedLDAPVersion' attribute lists the versions of LDAP which
- the server supports.
-
- ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
- USAGE dSAOperation )
-
- The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax are defined in
- [Syntaxes].
-
-
-5.1.7. 'supportedSASLMechanisms'
-
- The 'supportedSASLMechanisms' attribute lists the SASL mechanisms
- [SASL] which the server recognizes and/or supports [AuthMeth]. The
- contents of this attribute may depend on the current session state.
- If the server does not support any SASL mechanisms this attribute will
- not be present.
-
- ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
- USAGE dSAOperation )
-
- The Directory String (1.3.6.1.4.1.1466.115.121.1.15) syntax is defined
- in [Syntaxes].
-
-
-6. Other Considerations
-
-
-
-
-Zeilenga LDAP Models [Page 40]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
-6.1. Preservation of User Information
-
- Syntaxes may be defined which have specific value and/or value form
- (representation) preservation requirements. For example, a syntax
- containing digitally signed data can mandate the server preserve both
- the value and form of value presented to ensure signature is not
- invalidated.
-
- Where such requirements have not been explicitly stated, servers
- SHOULD preserve the value of user information but MAY return the value
- in a different form. And where a server is unable (or unwilling) to
- preserve the value of user information, the server SHALL ensure that
- an equivalent value (per Section 2.3) is returned.
-
-
-6.2. Short Names
-
- Short names, also known as descriptors, are used as more readable
- aliases for object identifiers and are used to identify various schema
- elements. However, it is not expected that LDAP implementations with
- human user interface would display these short names (nor the object
- identifiers they refer to) to the user, but would most likely be
- performing translations (such as expressing the short name in one of
- the local national languages). For example, the short name "st"
- (stateOrProvinceName) might be displayed to a German-speaking user as
- "Land".
-
- The same short name might have different meaning in different
- subschemas and, within a particular subschema, the same short name
- might refer to different object identifiers each identifying a
- different kind of schema element.
-
- Implementations MUST be prepared that the same short name might be
- used in a subschema to refer to the different kinds of schema
- elements. That is, there might be an object class 'x-fubar' and an
- attribute type 'x-fubar' in a subschema.
-
- Implementations MUST be prepared that the same short name might be
- used in the different subschemas to refer to the different schema
- elements. That is, there might be two matching rules 'x-fubar', each
- in different subschemas.
-
- Procedures for registering short names (descriptors) are detailed in
- BCP 64 [BCP64bis].
-
-
-6.3. Cache and Shadowing
-
-
-
-
-Zeilenga LDAP Models [Page 41]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- Some servers may hold cache or shadow copies of entries, which can be
- used to answer search and comparison queries, but will return
- referrals or contact other servers if modification operations are
- requested. Servers that perform shadowing or caching MUST ensure that
- they do not violate any access control constraints placed on the data
- by the originating server.
-
-
-7. Implementation Guidelines
-
-7.1 Server Guidelines
-
- Servers MUST recognize all names of attribute types and object classes
- defined in this document but, unless stated otherwise, need not
- support the associated functionality. Servers SHOULD recognize all
- the names of attribute types and object classes defined in Section 3
- and 4, respectively, of [Schema].
-
- Servers MUST ensure that entries conform to user and system schema
- rules or other data model constraints.
-
- Servers MAY support DIT Content Rules. Servers MAY support DIT
- Structure Rules and Name Forms.
-
- Servers MAY support alias entries.
-
- Servers MAY support the 'extensibleObject' object class.
-
- Servers MAY support subentries. If so, they MUST do so in accordance
- with [RFC3672]. Servers which do not support subentries SHOULD use
- object entries to mimic subentries as detailed in Section 3.2.
-
- Servers MAY implement additional schema elements. Servers SHOULD
- provide definitions of all schema elements they support in subschema
- (sub)entries.
-
-
-7.2 Client Guidelines
-
- In the absence of prior agreements with servers, clients SHOULD NOT
- assume that servers support any particular schema elements beyond
- those referenced in Section 7.1. The client can retrieve subschema
- information as described in Section 4.4.
-
- Clients MUST NOT display nor attempt to decode as ASN.1, a value if
- its syntax is not known. Clients MUST NOT assume the LDAP-specific
- string encoding is restricted to a UTF-8 encoded string of Unicode
- characters or any particular subset of Unicode (such as a printable
-
-
-
-Zeilenga LDAP Models [Page 42]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- subset) unless such restriction is explicitly stated. Clients SHOULD
- NOT send attribute values in a request that are not valid according to
- the syntax defined for the attributes.
-
-
-8. Security Considerations
-
- Attributes of directory entries are used to provide descriptive
- information about the real-world objects they represent, which can be
- people, organizations or devices. Most countries have privacy laws
- regarding the publication of information about people.
-
- General security considerations for accessing directory information
- with LDAP are discussed in [Protocol] and [AuthMeth].
-
-
-9. IANA Considerations
-
- It is requested that the Internet Assigned Numbers Authority (IANA)
- update the LDAP descriptors registry as indicated in the following
- template:
-
- Subject: Request for LDAP Descriptor Registration Update
- Descriptor (short name): see comment
- Object Identifier: see comment
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Usage: see comment
- Specification: RFC XXXX
- Author/Change Controller: IESG
- Comments:
-
- The following descriptors (short names) should be added to
- the registry.
-
- NAME Type OID
- ------------------------ ---- -----------------
- governingStructureRule A 2.5.21.10
- structuralObjectClass A 2.5.21.9
-
- The following descriptors (short names) should be updated to
- refer to this RFC.
-
- NAME Type OID
- ------------------------ ---- -----------------
- alias O 2.5.6.1
- aliasedObjectName A 2.5.4.1
- altServer A 1.3.6.1.4.1.1466.101.120.6
-
-
-
-Zeilenga LDAP Models [Page 43]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- attributeTypes A 2.5.21.5
- createTimestamp A 2.5.18.1
- creatorsName A 2.5.18.3
- dITContentRules A 2.5.21.2
- dITStructureRules A 2.5.21.1
- extensibleObject O 1.3.6.1.4.1.1466.101.120.111
- ldapSyntaxes A 1.3.6.1.4.1.1466.101.120.16
- matchingRuleUse A 2.5.21.8
- matchingRules A 2.5.21.4
- modifiersName A 2.5.18.4
- modifyTimestamp A 2.5.18.2
- nameForms A 2.5.21.7
- namingContexts A 1.3.6.1.4.1.1466.101.120.5
- objectClass A 2.5.4.0
- objectClasses A 2.5.21.6
- subschema O 2.5.20.1
- subschemaSubentry A 2.5.18.10
- supportedControl A 1.3.6.1.4.1.1466.101.120.13
- supportedExtension A 1.3.6.1.4.1.1466.101.120.7
- supportedFeatures A 1.3.6.1.4.1.4203.1.3.5
- supportedLDAPVersion A 1.3.6.1.4.1.1466.101.120.15
- supportedSASLMechanisms A 1.3.6.1.4.1.1466.101.120.14
- top O 2.5.6.0
-
-
-10. Acknowledgments
-
- This document is based in part on RFC 2251 by M. Wahl, T. Howes, and
- S. Kille; RFC 2252 by M. Wahl, A. Coulbeck, T. Howes, S. Kille; and
- RFC 2556 by M. Wahl, all products of the IETF Access, Searching and
- Indexing of Directories (ASID) Working Group. This document is also
- based in part on "The Directory: Models" [X.501], a product of the
- International Telephone Union (ITU). Additional text was borrowed
- from RFC 2253 by M. Wahl, T. Howes, and S. Kille.
-
- This document is a product of the IETF LDAP Revision (LDAPBIS) Working
- Group.
-
-
-11. Editor's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- Email: Kurt@OpenLDAP.org
-
-
-12. References
-
-
-
-Zeilenga LDAP Models [Page 44]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- [[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn where
- possible.]]
-
-
-12.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
- [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
-
- [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", RFC 3629 (also STD 63), November 2003.
-
- [RFC3671] Zeilenga, K., "Collective Attributes in LDAP", RFC 3671,
- December 2003.
-
- [RFC3672] Zeilenga, K. and S. Legg, "Subentries in LDAP", RFC
- 3672, December 2003.
-
- [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
- draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
-
- [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
- Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
- progress.
-
- [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
- draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
-
- [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
- Connection Level Security Mechanisms",
- draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
-
- [Filters] Smith, M. (editor), LDAPbis WG, "LDAP: String
- Representation of Search Filters",
- draft-ietf-ldapbis-filter-xx.txt, a work in progress.
-
- [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
- Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
- work in progress.
-
- [LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
- draft-ietf-ldapbis-url-xx.txt, a work in progress.
-
- [SASL] Melnikov, A. (Editor), "Simple Authentication and
-
-
-
-Zeilenga LDAP Models [Page 45]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- Security Layer (SASL)",
- draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress.
-
- [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
- draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
-
- [Schema] Dally, K. (editor), "LDAP: User Schema",
- draft-ietf-ldapbis-user-schema-xx.txt, a work in
- progress.
-
- [Unicode] The Unicode Consortium, "The Unicode Standard, Version
- 3.2.0" is defined by "The Unicode Standard, Version 3.0"
- (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
- as amended by the "Unicode Standard Annex #27: Unicode
- 3.1" (http://www.unicode.org/reports/tr27/) and by the
- "Unicode Standard Annex #28: Unicode 3.2"
- (http://www.unicode.org/reports/tr28/).
-
- [X.500] International Telecommunication Union -
- Telecommunication Standardization Sector, "The Directory
- -- Overview of concepts, models and services,"
- X.500(1993) (also ISO/IEC 9594-1:1994).
-
- [X.501] International Telecommunication Union -
- Telecommunication Standardization Sector, "The Directory
- -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
-
- [X.680] International Telecommunication Union -
- Telecommunication Standardization Sector, "Abstract
- Syntax Notation One (ASN.1) - Specification of Basic
- Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
-
-
-12.2. Informative References
-
- None.
-
-
-Appendix A. Changes
-
- This appendix is non-normative.
-
- This document amounts to nearly a complete rewrite of portions of RFC
- 2251, RFC 2252, and RFC 2256. This rewrite was undertaken to improve
- overall clarity of technical specification. This appendix provides a
- summary of substantive changes made to the portions of these documents
- incorporated into this document. Readers should consult [Roadmap],
- [Protocol], [Syntaxes], and [Schema] for summaries of remaining
-
-
-
-Zeilenga LDAP Models [Page 46]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- portions of these documents.
-
-
-A.1 Changes to RFC 2251
-
- This document incorporates from RFC 2251 sections 3.2 and 3.4,
- portions of Section 4 and 6 as summarized below.
-
-
-A.1.1 Section 3.2 of RFC 2251
-
- Section 3.2 of RFC 2251 provided a brief introduction to the X.500
- data model, as used by LDAP. The previous specification relied on
- [X.501] but lacked clarity in how X.500 models are adapted for use by
- LDAP. This document describes the X.500 data models, as used by LDAP
- in greater detail, especially in areas where adaptation is needed.
-
- Section 3.2.1 of RFC 2251 described an attribute as "a type with one
- or more associated values." In LDAP, an attribute is better described
- as an attribute description, a type with zero or more options, and one
- or more associated values.
-
- Section 3.2.2 of RFC 2251 mandated that subschema subentries contain
- objectClasses and attributeTypes attributes, yet X.500(93) treats
- these attributes as optional. While generally all implementations
- that support X.500(93) subschema mechanisms will provide both of these
- attributes, it is not absolutely required for interoperability that
- all servers do. The mandate was removed for consistency with
- X.500(93). The subschema discovery mechanism was also clarified to
- indicate that subschema controlling an entry is obtained by reading
- the (sub)entry referred to by that entry's 'subschemaSubentry'
- attribute.
-
-
-A.1.2 Section 3.4 of RFC 2251
-
- Section 3.4 of RFC 2251 provided "Server-specific Data Requirements".
- This material, with changes, was incorporated in Section 5.1 of this
- document.
-
- Changes:
-
- - Clarify that attributes of the root DSE are subject to "other
- restrictions" in addition to access controls.
-
- - Clarify that only recognized extended requests need to be enumerated
- 'supportedExtension'.
-
-
-
-
-Zeilenga LDAP Models [Page 47]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- - Clarify that only recognized request controls need to be enumerated
- 'supportedControl'.
-
- - Clarify that root DSE attributes are operational and, like other
- operational attributes, will not be returned in search requests
- unless requested by name.
-
- - Clarify that not all root DSE attributes are user modifiable.
-
- - Remove inconsistent text regarding handling of the
- 'subschemaSubentry' attribute within the root DSE. The previous
- specification stated that the 'subschemaSubentry' attribute held in
- the root DSE referred to "subschema entries (or subentries) known by
- this server." This is inconsistent with the attribute intended use
- as well as its formal definition as a single valued attribute
- [X.501]. It is also noted that a simple (possibly incomplete) list
- of subschema (sub)entries is not terrible useful. This document (in
- section 5.1) specifies that the 'subschemaSubentry' attribute of the
- root DSE refers to the subschema controlling the root DSE. It is
- noted that the general subschema discovery mechanism remains
- available (see Section 4.4 of this document).
-
-
-A.1.2 Section 4 of RFC 2251
-
- Portions of Section 4 of RFC 2251 detailing aspects of the information
- model used by LDAP were incorporated in this document, including:
-
- - Restriction of distinguished values to attributes whose descriptions
- have no options (from Section 4.1.3);
-
- - Data model aspects of Attribute Types (from Section 4.1.4),
- Attribute Descriptions (from 4.1.5), Attribute (from 4.1.8),
- Matching Rule Identifier (from 4.1.9); and
-
- - User schema requirements (from Section 4.1.6, 4.5.1, and 4.7).
-
-
-Clarifications to these portions include:
-
- - Subtyping and AttributeDescriptions with options.
-
-
-
-
-
-A.1.3 Section 6 of RFC 2251
-
-
-
-
-Zeilenga LDAP Models [Page 48]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- The Section 6.1 and the second paragraph of Section 6.2 of RFC 2251
- where incorporated into this document.
-
-
-A.2 Changes to RFC 2252
-
- This document incorporates Sections 4, 5 and 7 from RFC 2252.
-
-
-A.2.1 Section 4 of RFC 2252
-
- The specification was updated to use Augmented BNF [RFC2234]. The
- string representation of an OBJECT IDENTIFIER was tighten to
- disallow leading zeros as described in RFC 2252 text.
-
- The <descr> syntax was changed to disallow semicolon (U+003B)
- characters to appear to be consistent its natural language
- specification "descr is the syntactic representation of an object
- descriptor, which consists of letters and digits, starting with a
- letter." In a related change, the statement "an
- AttributeDescription can be used as the value in a NAME part of an
- AttributeTypeDescription" was deleted. RFC 2252 provided no
- specification of the semantics of attribute options appearing in
- NAME fields.
-
- RFC 2252 stated that the <descr> form of <oid> SHOULD be preferred
- over the <numericoid> form. However, <descr> form can be ambiguous.
- To address this issue, the imperative was replaced with a statement
- (in Section 1.4) that while the <descr> form is generally preferred,
- <numericoid> should be used where an unambiguous <descr> is not
- available. Additionally, an expanded discussion of descriptor
- issues is discussed in Section 6.2 (Short Names).
-
- The ABNF for a quoted string (qdstring) was updated to reflect
- support for the escaping mechanism described in 4.3 of RFC 2252.
-
-
-A.2.2 Section 5 of RFC 2252
-
- Definitions of operational attributes provided in Section 5 of RFC
- 2252 where incorporated into this document.
-
- The 'namingContexts' description was clarified. A first-level DSA
- should publish, in addition to other values, "" indicating the root
- of the DIT.
-
- The 'altServer' description was clarified. It may hold any URI.
-
-
-
-
-Zeilenga LDAP Models [Page 49]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
- The 'supportedExtension' description was clarified. A server need
- only list the OBJECT IDENTIFIERs associated with the extended
- requests of the extended operations it recognizes.
-
- The 'supportedControl' description was clarified. A server need
- only list the OBJECT IDENTIFIERs associated with the request
- controls it recognizes.
-
- Descriptions for the 'structuralObjectClass' and
- 'governingStructureRule' operational attribute types were added.
-
-
-A.2.3 Section 7 of RFC 2252
-
- Section 7 of RFC 2252 provides definitions of the 'subschema' and
- 'extensibleObject' object classes. These definitions where
- integrated into Section 4.2 and Section 4.3 of this document,
- respectively. Section 7 of RFC 2252 also contained the object class
- implementation requirement. This was incorporated into Section 7 of
- this document.
-
- The specification of 'extensibleObject' was clarified of how it
- interacts with precluded attributes.
-
-
-A.3 Changes to RFC 2256
-
- This document incorporates Sections 5.1, 5.2, 7.1, and 7.2 of RFC
- 2256.
-
- Section 5.1 of RFC 2256 provided the definition of the 'objectClass'
- attribute type. This was integrated into Section 2.4.1 of this
- document. The statement "One of the values is either 'top' or
- 'alias'" was replaced with statement that one of the values is 'top'
- as entries belonging to 'alias' also belong to 'top'.
-
- Section 5.2 of RFC 2256 provided the definition of the
- 'aliasedObjectName' attribute type. This was integrated into
- Section 2.6.2 of this document.
-
- Section 7.1 of RFC 2256 provided the definition of the 'top' object
- class. This was integrated into Section 2.4.1 of this document.
-
- Section 7.2 of RFC 2256 provided the definition of the 'alias'
- object class. This was integrated into Section 2.6.1 of this
- document.
-
-
-
-
-
-Zeilenga LDAP Models [Page 50]
-
-INTERNET-DRAFT draft-ietf-ldapbis-models-14 21 February 2005
-
-
-A.4 Changes to RFC 3674
-
- This document made no substantive change to the 'supportedFeatures'
- technical specification provided in RFC 3674.
-
-
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be found
- in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this specification
- can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-Full Copyright
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-Zeilenga LDAP Models [Page 51]
-
diff --git a/doc/drafts/draft-ietf-ldapbis-protocol-xx.txt b/doc/drafts/draft-ietf-ldapbis-protocol-xx.txt
deleted file mode 100644
index 575f1dc529a1f87c117ab60a21f04f6fc69b36e7..0000000000000000000000000000000000000000
--- a/doc/drafts/draft-ietf-ldapbis-protocol-xx.txt
+++ /dev/null
@@ -1,3709 +0,0 @@
-
-
-Internet-Draft Editor: J. Sermersheim
-Intended Category: Standard Track Novell, Inc
-Document: draft-ietf-ldapbis-protocol-32.txt Oct 2005
-Obsoletes: RFCs 2251, 2830, 3771
-
-
- LDAP: The Protocol
-
-
-Status of this Memo
-
- By submitting this Internet-Draft, each
- author represents that any applicable patent or other IPR claims of
- which he or she is aware have been or will be disclosed, and any of
- which he or she becomes aware will be disclosed, in accordance with
- Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress".
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire in February 2005.
-
- Technical discussion of this document will take place on the IETF
- LDAP Revision Working Group (LDAPbis) mailing list <ietf-
- ldapbis@openldap.org>. Please send editorial comments directly to the
- editor <jimse@novell.com>.
-
-
-Abstract
-
- This document describes the protocol elements, along with their
- semantics and encodings, of the Lightweight Directory Access Protocol
- (LDAP). LDAP provides access to distributed directory services that
- act in accordance with X.500 data and service models. These protocol
- elements are based on those described in the X.500 Directory Access
- Protocol (DAP).
-
-
-Table of Contents
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 1
- Lightweight Directory Access Protocol Version 3
-
- 1. Introduction....................................................3
- 1.1. Relationship to Other LDAP Specifications.....................3
- 2. Conventions.....................................................3
- 3. Protocol Model..................................................4
- 3.1 Operation and LDAP Message Layer Relationship..................5
- 4. Elements of Protocol............................................5
- 4.1. Common Elements...............................................5
- 4.1.1. Message Envelope............................................5
- 4.1.2. String Types................................................7
- 4.1.3. Distinguished Name and Relative Distinguished Name..........7
- 4.1.4. Attribute Descriptions......................................8
- 4.1.5. Attribute Value.............................................8
- 4.1.6. Attribute Value Assertion...................................8
- 4.1.7. Attribute and PartialAttribute..............................9
- 4.1.8. Matching Rule Identifier....................................9
- 4.1.9. Result Message..............................................9
- 4.1.10. Referral..................................................11
- 4.1.11. Controls..................................................13
- 4.2. Bind Operation...............................................14
- 4.3. Unbind Operation.............................................17
- 4.4. Unsolicited Notification.....................................17
- 4.5. Search Operation.............................................18
- 4.6. Modify Operation.............................................29
- 4.7. Add Operation................................................31
- 4.8. Delete Operation.............................................31
- 4.9. Modify DN Operation..........................................32
- 4.10. Compare Operation...........................................33
- 4.11. Abandon Operation...........................................34
- 4.12. Extended Operation..........................................35
- 4.13. IntermediateResponse Message................................36
- 4.14. StartTLS Operation..........................................37
- 5. Protocol Encoding, Connection, and Transfer....................39
- 5.1. Protocol Encoding............................................39
- 5.2. Transmission Control Protocol (TCP)..........................40
- 5.3. Termination of the LDAP session..............................40
- 6. Security Considerations........................................40
- 7. Acknowledgements...............................................42
- 8. Normative References...........................................42
- 9. Informative References.........................................44
- 10. IANA Considerations...........................................44
- 11. Editor's Address..............................................45
- Appendix A - LDAP Result Codes....................................46
- A.1 Non-Error Result Codes........................................46
- A.2 Result Codes..................................................46
- Appendix B - Complete ASN.1 Definition............................51
- Appendix C - Changes..............................................57
- C.1 Changes made to RFC 2251:.....................................57
- C.2 Changes made to RFC 2830:.....................................62
- C.3 Changes made to RFC 3771:.....................................63
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 2
- Lightweight Directory Access Protocol Version 3
-
-1. Introduction
-
- The Directory is "a collection of open systems cooperating to provide
- directory services" [X.500]. A directory user, which may be a human
- or other entity, accesses the Directory through a client (or
- Directory User Agent (DUA)). The client, on behalf of the directory
- user, interacts with one or more servers (or Directory System Agents
- (DSA)). Clients interact with servers using a directory access
- protocol.
-
- This document details the protocol elements of the Lightweight
- Directory Access Protocol (LDAP), along with their semantics.
- Following the description of protocol elements, it describes the way
- in which the protocol elements are encoded and transferred.
-
-
-1.1. Relationship to Other LDAP Specifications
-
- This document is an integral part of the LDAP Technical Specification
- [Roadmap] which obsoletes the previously defined LDAP technical
- specification, RFC 3377, in its entirety.
-
- This document, together with [Roadmap], [AuthMeth], and [Models],
- obsoletes RFC 2251 in its entirety. Section 3.3 is obsoleted by
- [Roadmap]. Sections 4.2.1 (portions), and 4.2.2 are obsoleted by
- [AuthMeth]. Sections 3.2, 3.4, 4.1.3 (last paragraph), 4.1.4, 4.1.5,
- 4.1.5.1, 4.1.9 (last paragraph), 5.1, 6.1, and 6.2 (last paragraph)
- are obsoleted by [Models]. The remainder of RFC 2251 is obsoleted by
- this document. Appendix C.1 summarizes substantive changes in the
- remainder.
-
- This document obsoletes RFC 2830, Sections 2 and 4. The remainder of
- RFC 2830 is obsoleted by [AuthMeth]. Appendix C.2 summarizes
- substantive changes to the remaining sections.
-
- This document also obsoletes RFC 3771 in entirety.
-
-
-2. Conventions
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
- to be interpreted as described in [Keyword].
-
- Character names in this document use the notation for code points and
- names from the Unicode Standard [Unicode]. For example, the letter
- "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
-
- Note: a glossary of terms used in Unicode can be found in [Glossary].
- Information on the Unicode character encoding model can be found in
- [CharModel].
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 3
- Lightweight Directory Access Protocol Version 3
-
- The term "transport connection" refers to the underlying transport
- services used to carry the protocol exchange, as well as associations
- established by these services.
-
- The term "TLS layer" refers to TLS services used in providing
- security services, as well as associations established by these
- services.
-
- The term "SASL layer" refers to SASL services used in providing
- security services, as well as associations established by these
- services.
-
- The term "LDAP message layer" refers to the LDAP Message Protocol
- Data Unit (PDU) services used in providing directory services, as
- well as associations established by these services.
-
- The term "LDAP session" refers to combined services (transport
- connection, TLS layer, SASL layer, LDAP message layer) and their
- associations.
-
- See the table in Section 5 for an illustration of these four terms.
-
-
-3. Protocol Model
-
- The general model adopted by this protocol is one of clients
- performing protocol operations against servers. In this model, a
- client transmits a protocol request describing the operation to be
- performed to a server. The server is then responsible for performing
- the necessary operation(s) in the Directory. Upon completion of an
- operation, the server typically returns a response containing
- appropriate data to the requesting client.
-
- Protocol operations are generally independent of one another. Each
- operation is processed as an atomic action, leaving the directory in
- a consistent state.
-
- Although servers are required to return responses whenever such
- responses are defined in the protocol, there is no requirement for
- synchronous behavior on the part of either clients or servers.
- Requests and responses for multiple operations generally may be
- exchanged between a client and server in any order. If required,
- synchronous behavior may be controlled by client applications.
-
- The core protocol operations defined in this document can be mapped
- to a subset of the X.500 (1993) Directory Abstract Service [X.511].
- However there is not a one-to-one mapping between LDAP operations and
- X.500 Directory Access Protocol (DAP) operations. Server
- implementations acting as a gateway to X.500 directories may need to
- make multiple DAP requests to service a single LDAP request.
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 4
- Lightweight Directory Access Protocol Version 3
-
-
-3.1. Operation and LDAP Message Layer Relationship
-
- Protocol operations are exchanged at the LDAP message layer. When the
- transport connection is closed, any uncompleted operations at the
- LDAP message layer, when possible, are abandoned, and when not
- possible, are completed without transmission of the response. Also,
- when the transport connection is closed, the client MUST NOT assume
- that any uncompleted update operations have succeeded or failed.
-
-
-4. Elements of Protocol
-
- The protocol is described using Abstract Syntax Notation One
- ([ASN.1]), and is transferred using a subset of ASN.1 Basic Encoding
- Rules ([BER]). Section 5 specifies how the protocol elements are
- encoded and transferred.
-
- In order to support future extensions to this protocol, extensibility
- is implied where it is allowed per ASN.1 (i.e. sequence, set, choice,
- and enumerated types are extensible). In addition, ellipses (...)
- have been supplied in ASN.1 types that are explicitly extensible as
- discussed in [LDAPIANA]. Because of the implied extensibility,
- clients and servers MUST (unless otherwise specified) ignore trailing
- SEQUENCE components whose tags they do not recognize.
-
- Changes to the protocol other than through the extension mechanisms
- described here require a different version number. A client indicates
- the version it is using as part of the BindRequest, described in
- Section 4.2. If a client has not sent a Bind, the server MUST assume
- the client is using version 3 or later.
-
- Clients may attempt to determine the protocol versions a server
- supports by reading the 'supportedLDAPVersion' attribute from the
- root DSE (DSA-Specific Entry) [Models].
-
-
-4.1. Common Elements
-
- This section describes the LDAPMessage envelope Protocol Data Unit
- (PDU) format, as well as data type definitions, which are used in the
- protocol operations.
-
-
-4.1.1. Message Envelope
-
- For the purposes of protocol exchanges, all protocol operations are
- encapsulated in a common envelope, the LDAPMessage, which is defined
- as follows:
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 5
- Lightweight Directory Access Protocol Version 3
-
- LDAPMessage ::= SEQUENCE {
- messageID MessageID,
- protocolOp CHOICE {
- bindRequest BindRequest,
- bindResponse BindResponse,
- unbindRequest UnbindRequest,
- searchRequest SearchRequest,
- searchResEntry SearchResultEntry,
- searchResDone SearchResultDone,
- searchResRef SearchResultReference,
- modifyRequest ModifyRequest,
- modifyResponse ModifyResponse,
- addRequest AddRequest,
- addResponse AddResponse,
- delRequest DelRequest,
- delResponse DelResponse,
- modDNRequest ModifyDNRequest,
- modDNResponse ModifyDNResponse,
- compareRequest CompareRequest,
- compareResponse CompareResponse,
- abandonRequest AbandonRequest,
- extendedReq ExtendedRequest,
- extendedResp ExtendedResponse,
- ...,
- intermediateResponse IntermediateResponse },
- controls [0] Controls OPTIONAL }
-
- MessageID ::= INTEGER (0 .. maxInt)
-
- maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
-
- The ASN.1 type Controls is defined in Section 4.1.11.
-
- The function of the LDAPMessage is to provide an envelope containing
- common fields required in all protocol exchanges. At this time the
- only common fields are the messageID and the controls.
-
- If the server receives an LDAPMessage from the client in which the
- LDAPMessage SEQUENCE tag cannot be recognized, the messageID cannot
- be parsed, the tag of the protocolOp is not recognized as a request,
- or the encoding structures or lengths of data fields are found to be
- incorrect, then the server SHOULD return the Notice of Disconnection
- described in Section 4.4.1, with the resultCode set to protocolError,
- and MUST immediately terminate the LDAP session as described in
- Section 5.3.
-
- In other cases where the client or server cannot parse an LDAP PDU,
- it SHOULD abruptly terminate the LDAP session (Section 5.3) where
- further communication (including providing notice) would be
- pernicious. Otherwise, server implementations MUST return an
- appropriate response to the request, with the resultCode set to
- protocolError.
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 6
- Lightweight Directory Access Protocol Version 3
-
-4.1.1.1. Message ID
-
- All LDAPMessage envelopes encapsulating responses contain the
- messageID value of the corresponding request LDAPMessage.
-
- The message ID of a request MUST have a non-zero value different from
- the messageID of any other request in progress in the same LDAP
- session. The zero value is reserved for the unsolicited notification
- message.
-
- Typical clients increment a counter for each request.
-
- A client MUST NOT send a request with the same message ID as an
- earlier request in the same LDAP session unless it can be determined
- that the server is no longer servicing the earlier request (e.g.
- after the final response is received, or a subsequent Bind
- completes). Otherwise the behavior is undefined. For this purpose,
- note that Abandon and successfully abandoned operations do not send
- responses.
-
-
-4.1.2. String Types
-
- The LDAPString is a notational convenience to indicate that, although
- strings of LDAPString type encode as ASN.1 OCTET STRING types, the
- [ISO10646] character set (a superset of [Unicode]) is used, encoded
- following the [UTF-8] algorithm. Note that Unicode characters U+0000
- through U+007F are the same as ASCII 0 through 127, respectively, and
- have the same single octet UTF-8 encoding. Other Unicode characters
- have a multiple octet UTF-8 encoding.
-
- LDAPString ::= OCTET STRING -- UTF-8 encoded,
- -- [ISO10646] characters
-
- The LDAPOID is a notational convenience to indicate that the
- permitted value of this string is a (UTF-8 encoded) dotted-decimal
- representation of an OBJECT IDENTIFIER. Although an LDAPOID is
- encoded as an OCTET STRING, values are limited to the definition of
- <numericoid> given in Section 1.4 of [Models].
-
- LDAPOID ::= OCTET STRING -- Constrained to <numericoid> [Models]
-
- For example,
-
- 1.3.6.1.4.1.1466.1.2.3
-
-
-4.1.3. Distinguished Name and Relative Distinguished Name
-
- An LDAPDN is defined to be the representation of a Distinguished Name
- (DN) after encoding according to the specification in [LDAPDN].
-
- LDAPDN ::= LDAPString
- -- Constrained to <distinguishedName> [LDAPDN]
-
-Sermersheim Internet-Draft - Expires April 2006 Page 7
- Lightweight Directory Access Protocol Version 3
-
-
- A RelativeLDAPDN is defined to be the representation of a Relative
- Distinguished Name (RDN) after encoding according to the
- specification in [LDAPDN].
-
- RelativeLDAPDN ::= LDAPString
- -- Constrained to <name-component> [LDAPDN]
-
-
-4.1.4. Attribute Descriptions
-
- The definition and encoding rules for attribute descriptions are
- defined in Section 2.5 of [Models]. Briefly, an attribute description
- is an attribute type and zero or more options.
-
- AttributeDescription ::= LDAPString
- -- Constrained to <attributedescription>
- -- [Models]
-
-
-4.1.5. Attribute Value
-
- A field of type AttributeValue is an OCTET STRING containing an
- encoded attribute value. The attribute value is encoded according to
- the LDAP-specific encoding definition of its corresponding syntax.
- The LDAP-specific encoding definitions for different syntaxes and
- attribute types may be found in other documents and in particular
- [Syntaxes].
-
- AttributeValue ::= OCTET STRING
-
- Note that there is no defined limit on the size of this encoding;
- thus protocol values may include multi-megabyte attribute values
- (e.g. photographs).
-
- Attribute values may be defined which have arbitrary and non-
- printable syntax. Implementations MUST NOT display nor attempt to
- decode an attribute value if its syntax is not known. The
- implementation may attempt to discover the subschema of the source
- entry, and retrieve the descriptions of 'attributeTypes' from it
- [Models].
-
- Clients MUST only send attribute values in a request that are valid
- according to the syntax defined for the attributes.
-
-
-4.1.6. Attribute Value Assertion
-
- The AttributeValueAssertion (AVA) type definition is similar to the
- one in the X.500 Directory standards. It contains an attribute
- description and a matching rule ([Models] Section 4.1.3) assertion
- value suitable for that type. Elements of this type are typically
- used to assert that the value in assertionValue matches a value of an
- attribute.
-
-Sermersheim Internet-Draft - Expires April 2006 Page 8
- Lightweight Directory Access Protocol Version 3
-
-
- AttributeValueAssertion ::= SEQUENCE {
- attributeDesc AttributeDescription,
- assertionValue AssertionValue }
-
- AssertionValue ::= OCTET STRING
-
- The syntax of the AssertionValue depends on the context of the LDAP
- operation being performed. For example, the syntax of the EQUALITY
- matching rule for an attribute is used when performing a Compare
- operation. Often this is the same syntax used for values of the
- attribute type, but in some cases the assertion syntax differs from
- the value syntax. See objectIdentiferFirstComponentMatch in
- [Syntaxes] for an example.
-
-
-4.1.7. Attribute and PartialAttribute
-
- Attributes and partial attributes consist of an attribute description
- and attribute values. A PartialAttribute allows zero values, while
- Attribute requires at least one value.
-
- PartialAttribute ::= SEQUENCE {
- type AttributeDescription,
- vals SET OF value AttributeValue }
-
- Attribute ::= PartialAttribute(WITH COMPONENTS {
- ...,
- vals (SIZE(1..MAX))})
-
- No two of the attribute values may be equivalent as described by
- Section 2.3 of [Models]. The set of attribute values is unordered.
- Implementations MUST NOT rely upon the ordering being repeatable.
-
-
-4.1.8. Matching Rule Identifier
-
- Matching rules are defined in Section 4.1.3 of [Models]. A matching
- rule is identified in the protocol by the printable representation of
- either its <numericoid>, or one of its short name descriptors
- [Models], e.g. 'caseIgnoreMatch' or '2.5.13.2'.
-
- MatchingRuleId ::= LDAPString
-
-
-4.1.9. Result Message
-
- The LDAPResult is the construct used in this protocol to return
- success or failure indications from servers to clients. To various
- requests, servers will return responses containing the elements found
- in LDAPResult to indicate the final status of the protocol operation
- request.
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 9
- Lightweight Directory Access Protocol Version 3
-
- LDAPResult ::= SEQUENCE {
- resultCode ENUMERATED {
- success (0),
- operationsError (1),
- protocolError (2),
- timeLimitExceeded (3),
- sizeLimitExceeded (4),
- compareFalse (5),
- compareTrue (6),
- authMethodNotSupported (7),
- strongerAuthRequired (8),
- -- 9 reserved --
- referral (10),
- adminLimitExceeded (11),
- unavailableCriticalExtension (12),
- confidentialityRequired (13),
- saslBindInProgress (14),
- noSuchAttribute (16),
- undefinedAttributeType (17),
- inappropriateMatching (18),
- constraintViolation (19),
- attributeOrValueExists (20),
- invalidAttributeSyntax (21),
- -- 22-31 unused --
- noSuchObject (32),
- aliasProblem (33),
- invalidDNSyntax (34),
- -- 35 reserved for undefined isLeaf --
- aliasDereferencingProblem (36),
- -- 37-47 unused --
- inappropriateAuthentication (48),
- invalidCredentials (49),
- insufficientAccessRights (50),
- busy (51),
- unavailable (52),
- unwillingToPerform (53),
- loopDetect (54),
- -- 55-63 unused --
- namingViolation (64),
- objectClassViolation (65),
- notAllowedOnNonLeaf (66),
- notAllowedOnRDN (67),
- entryAlreadyExists (68),
- objectClassModsProhibited (69),
- -- 70 reserved for CLDAP --
- affectsMultipleDSAs (71),
- -- 72-79 unused --
- other (80),
- ... },
- matchedDN LDAPDN,
- diagnosticMessage LDAPString,
- referral [3] Referral OPTIONAL }
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 10
- Lightweight Directory Access Protocol Version 3
-
- The resultCode enumeration is extensible as defined in Section 3.6 of
- [LDAPIANA]. The meanings of the listed result codes are given in
- Appendix A. If a server detects multiple errors for an operation,
- only one result code is returned. The server should return the result
- code that best indicates the nature of the error encountered. Servers
- may return substituted result codes to prevent unauthorized
- disclosures.
-
- The diagnosticMessage field of this construct may, at the server's
- option, be used to return a string containing a textual, human-
- readable (terminal control and page formatting characters should be
- avoided) diagnostic message. As this diagnostic message is not
- standardized, implementations MUST NOT rely on the values returned.
- Diagnostic messages typically supplement the resultCode with
- additional information. If the server chooses not to return a textual
- diagnostic, the diagnosticMessage field MUST be empty.
-
- For certain result codes (typically, but not restricted to
- noSuchObject, aliasProblem, invalidDNSyntax and
- aliasDereferencingProblem), the matchedDN field is set (subject to
- access controls) to the name of the last entry (object or alias) used
- in finding the target (or base) object. This will be a truncated form
- of the provided name or, if an alias was dereferenced while
- attempting to locate the entry, of the resulting name. Otherwise the
- matchedDN field is empty.
-
-
-4.1.10. Referral
-
- The referral result code indicates that the contacted server cannot
- or will not perform the operation and that one or more other servers
- may be able to. Reasons for this include:
-
- - The target entry of the request is not held locally, but the
- server has knowledge of its possible existence elsewhere.
-
- - The operation is restricted on this server -- perhaps due to a
- read-only copy of an entry to be modified.
-
- The referral field is present in an LDAPResult if the resultCode is
- set to referral, and absent with all other result codes. It contains
- one or more references to one or more servers or services that may be
- accessed via LDAP or other protocols. Referrals can be returned in
- response to any operation request (except Unbind and Abandon which do
- not have responses). At least one URI MUST be present in the
- Referral.
-
- During a Search operation, after the baseObject is located, and
- entries are being evaluated, the referral is not returned. Instead,
- continuation references, described in Section 4.5.3, are returned
- when other servers would need to be contacted to complete the
- operation.
-
- Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
-
-Sermersheim Internet-Draft - Expires April 2006 Page 11
- Lightweight Directory Access Protocol Version 3
-
-
- URI ::= LDAPString -- limited to characters permitted in
- -- URIs
-
- If the client wishes to progress the operation, it contacts one of
- the supported services found in the referral. If multiple URIs are
- present, the client assumes that any supported URI may be used to
- progress the operation.
-
- Clients that follow referrals MUST ensure that they do not loop
- between servers. They MUST NOT repeatedly contact the same server for
- the same request with the same parameters. Some clients use a counter
- that is incremented each time referral handling occurs for an
- operation, and these kinds of clients MUST be able to handle at least
- ten nested referrals while progressing the operation.
-
- A URI for a server implementing LDAP and accessible via [TCP]/[IP]
- (v4 or v6) is written as an LDAP URL according to [LDAPURL].
-
- Referral values which are LDAP URLs follow these rules:
-
- - If an alias was dereferenced, the <dn> part of the LDAP URL MUST
- be present, with the new target object name.
-
- - It is RECOMMENDED that the <dn> part be present to avoid
- ambiguity.
-
- - If the <dn> part is present, the client uses this name in its next
- request to progress the operation, and if it is not present the
- client uses the same name as in the original request.
-
- - Some servers (e.g. participating in distributed indexing) may
- provide a different filter in a URL of a referral for a Search
- operation.
-
- - If the <filter> part of the LDAP URL is present, the client uses
- this filter in its next request to progress this Search, and if it
- is not present the client uses the same filter as it used for that
- Search.
-
- - For Search, it is RECOMMENDED that the <scope> part be present to
- avoid ambiguity.
-
- - If the <scope> part is missing, the scope of the original Search
- is used by the client to progress the operation.
-
- - Other aspects of the new request may be the same as or different
- from the request which generated the referral.
-
- Other kinds of URIs may be returned. The syntax and semantics of such
- URIs is left to future specifications. Clients may ignore URIs that
- they do not support.
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 12
- Lightweight Directory Access Protocol Version 3
-
- UTF-8 encoded characters appearing in the string representation of a
- DN, search filter, or other fields of the referral value may not be
- legal for URIs (e.g. spaces) and MUST be escaped using the % method
- in [URI].
-
-
-4.1.11. Controls
-
- Controls provide a mechanism whereby the semantics and arguments of
- existing LDAP operations may be extended. One or more controls may be
- attached to a single LDAP message. A control only affects the
- semantics of the message it is attached to.
-
- Controls sent by clients are termed 'request controls' and those sent
- by servers are termed 'response controls'.
-
- Controls ::= SEQUENCE OF control Control
-
- Control ::= SEQUENCE {
- controlType LDAPOID,
- criticality BOOLEAN DEFAULT FALSE,
- controlValue OCTET STRING OPTIONAL }
-
- The controlType field is the dotted-decimal representation of an
- OBJECT IDENTIFIER which uniquely identifies the control. This
- provides unambiguous naming of controls. Often, response control(s)
- solicited by a request control share controlType values with the
- request control.
-
- The criticality field only has meaning in controls attached to
- request messages (except UnbindRequest). For controls attached to
- response messages and the UnbindRequest, the criticality field SHOULD
- be FALSE, and MUST be ignored by the receiving protocol peer. A value
- of TRUE indicates that it is unacceptable to perform the operation
- without applying the semantics of the control. Specifically, the
- criticality field is applied as follows:
-
- - If the server does not recognize the control type, determines that
- it is not appropriate for the operation, or is otherwise unwilling
- to perform the operation with the control, and the criticality
- field is TRUE, the server MUST NOT perform the operation, and for
- operations that have a response message, MUST return with the
- resultCode set to unavailableCriticalExtension.
-
- - If the server does not recognize the control type, determines that
- it is not appropriate for the operation, or is otherwise unwilling
- to perform the operation with the control, and the criticality
- field is FALSE, the server MUST ignore the control.
-
- - Regardless of criticality, if a control is applied to an
- operation, it is applied consistently and impartially to the
- entire operation.
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 13
- Lightweight Directory Access Protocol Version 3
-
- The controlValue may contain information associated with the
- controlType. Its format is defined by the specification of the
- control. Implementations MUST be prepared to handle arbitrary
- contents of the controlValue octet string, including zero bytes. It
- is absent only if there is no value information which is associated
- with a control of its type. When a controlValue is defined in terms
- of ASN.1, and BER encoded according to Section 5.1, it also follows
- the extensibility rules in Section 4.
-
- Servers list the controlType of request controls they recognize in
- the 'supportedControl' attribute in the root DSE (Section 5.1 of
- [Models]).
-
- Controls SHOULD NOT be combined unless the semantics of the
- combination has been specified. The semantics of control
- combinations, if specified, are generally found in the control
- specification most recently published. When a combination of controls
- is encountered whose semantics are invalid, not specified (or not
- known), the message is considered to be not well-formed, thus the
- operation fails with protocolError. Controls with a criticality of
- FALSE may be ignored in order to arrive at a valid combination.
- Additionally, unless order-dependent semantics are given in a
- specification, the order of a combination of controls in the SEQUENCE
- is ignored. Where the order is to be ignored but cannot be ignored by
- the server, the message is considered not well-formed and the
- operation fails with protocolError. Again, controls with a
- criticality of FALSE may be ignored in order to arrive at a valid
- combination.
-
- This document does not specify any controls. Controls may be
- specified in other documents. Documents detailing control extensions
- are to provide for each control:
-
- - the OBJECT IDENTIFIER assigned to the control,
-
- - direction as to what value the sender should provide for the
- criticality field (note: the semantics of the criticality field
- are defined above should not be altered by the control's
- specification),
-
- - whether the controlValue field is present, and if so, the format
- of its contents,
-
- - the semantics of the control, and
-
- - optionally, semantics regarding the combination of the control
- with other controls.
-
-
-4.2. Bind Operation
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 14
- Lightweight Directory Access Protocol Version 3
-
- The function of the Bind operation is to allow authentication
- information to be exchanged between the client and server. The Bind
- operation should be thought of as the "authenticate" operation.
- Operational, authentication, and security-related semantics of this
- operation are given in [AuthMeth].
-
- The Bind request is defined as follows:
-
- BindRequest ::= [APPLICATION 0] SEQUENCE {
- version INTEGER (1 .. 127),
- name LDAPDN,
- authentication AuthenticationChoice }
-
- AuthenticationChoice ::= CHOICE {
- simple [0] OCTET STRING,
- -- 1 and 2 reserved
- sasl [3] SaslCredentials,
- ... }
-
- SaslCredentials ::= SEQUENCE {
- mechanism LDAPString,
- credentials OCTET STRING OPTIONAL }
-
- Fields of the BindRequest are:
-
- - version: A version number indicating the version of the protocol
- to be used at the LDAP message layer. This document describes
- version 3 of the protocol. There is no version negotiation. The
- client sets this field to the version it desires. If the server
- does not support the specified version, it MUST respond with a
- BindResponse where the resultCode is set to protocolError.
-
- - name: If not empty, the name of the Directory object that the
- client wishes to bind as. This field may take on a null value (a
- zero length string) for the purposes of anonymous binds
- ([AuthMeth] Section 5.1) or when using Simple Authentication and
- Security Layer [SASL] authentication ([AuthMeth] Section 5.2).
- Where the server attempts to locate the named object, it SHALL NOT
- perform alias dereferencing.
-
- - authentication: information used in authentication. This type is
- extensible as defined in Section 3.7 of [LDAPIANA]. Servers that
- do not support a choice supplied by a client return a BindResponse
- with the resultCode set to authMethodNotSupported.
-
- Textual passwords (consisting of a character sequence with a known
- character set and encoding) transferred to the server using the
- simple AuthenticationChoice SHALL be transferred as [UTF-8]
- encoded [Unicode]. Prior to transfer, clients SHOULD prepare text
- passwords as "query" strings by applying the [SASLprep] profile of
- the [Stringprep] algorithm. Passwords consisting of other data
- (such as random octets) MUST NOT be altered. The determination of
- whether a password is textual is a local client matter.
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 15
- Lightweight Directory Access Protocol Version 3
-
-
-4.2.1. Processing of the Bind Request
-
- Before processing a BindRequest, all uncompleted operations MUST
- either complete or be abandoned. The server may either wait for the
- uncompleted operations to complete, or abandon them. The server then
- proceeds to authenticate the client in either a single-step, or
- multi-step Bind process. Each step requires the server to return a
- BindResponse to indicate the status of authentication.
-
- After sending a BindRequest, clients MUST NOT send further LDAP PDUs
- until receiving the BindResponse. Similarly, servers SHOULD NOT
- process or respond to requests received while processing a
- BindRequest.
-
- If the client did not bind before sending a request and receives an
- operationsError to that request, it may then send a BindRequest. If
- this also fails or the client chooses not to bind on the existing
- LDAP session, it may terminate the LDAP session, re-establish it and
- begin again by first sending a BindRequest. This will aid in
- interoperating with servers implementing other versions of LDAP.
-
- Clients may send multiple Bind requests to change the authentication
- and/or security associations or to complete a multi-stage Bind
- process. Authentication from earlier binds is subsequently ignored.
-
- For some SASL authentication mechanisms, it may be necessary for the
- client to invoke the BindRequest multiple times ([AuthMeth] Section
- 5.2). Clients MUST NOT invoke operations between two Bind requests
- made as part of a multi-stage Bind.
-
- A client may abort a SASL bind negotiation by sending a BindRequest
- with a different value in the mechanism field of SaslCredentials, or
- an AuthenticationChoice other than sasl.
-
- If the client sends a BindRequest with the sasl mechanism field as an
- empty string, the server MUST return a BindResponse with the
- resultCode set to authMethodNotSupported. This will allow clients to
- abort a negotiation if it wishes to try again with the same SASL
- mechanism.
-
-
-4.2.2. Bind Response
-
- The Bind response is defined as follows.
-
- BindResponse ::= [APPLICATION 1] SEQUENCE {
- COMPONENTS OF LDAPResult,
- serverSaslCreds [7] OCTET STRING OPTIONAL }
-
- BindResponse consists simply of an indication from the server of the
- status of the client's request for authentication.
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 16
- Lightweight Directory Access Protocol Version 3
-
- A successful Bind operation is indicated by a BindResponse with a
- resultCode set to success. Otherwise, an appropriate result code is
- set in the BindResponse. For BindResponse, the protocolError result
- code may be used to indicate that the version number supplied by the
- client is unsupported.
-
- If the client receives a BindResponse where the resultCode is set to
- protocolError, it is to assume that the server does not support this
- version of LDAP. While the client may be able proceed with another
- version of this protocol (this may or may not require closing and re-
- establishing the transport connection), how to proceed with another
- version of this protocol is beyond the scope of this document.
- Clients which are unable or unwilling to proceed SHOULD terminate the
- LDAP session.
-
- The serverSaslCreds field is used as part of a SASL-defined bind
- mechanism to allow the client to authenticate the server to which it
- is communicating, or to perform "challenge-response" authentication.
- If the client bound with the simple choice, or the SASL mechanism
- does not require the server to return information to the client, then
- this field SHALL NOT be included in the BindResponse.
-
-
-4.3. Unbind Operation
-
- The function of the Unbind operation is to terminate an LDAP session.
- The Unbind operation is not the antithesis of the Bind operation as
- the name implies. The naming of these operations are historical. The
- Unbind operation should be thought of as the "quit" operation.
-
- The Unbind operation is defined as follows:
-
- UnbindRequest ::= [APPLICATION 2] NULL
-
- The client, upon transmission of the UnbindRequest, and the server,
- upon receipt of the UnbindRequest are to gracefully terminate the
- LDAP session as described in Section 5.3.
-
- Uncompleted operations are handled as specified in Section 3.1.
-
-
-4.4. Unsolicited Notification
-
- An unsolicited notification is an LDAPMessage sent from the server to
- the client which is not in response to any LDAPMessage received by
- the server. It is used to signal an extraordinary condition in the
- server or in the LDAP session between the client and the server. The
- notification is of an advisory nature, and the server will not expect
- any response to be returned from the client.
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 17
- Lightweight Directory Access Protocol Version 3
-
- The unsolicited notification is structured as an LDAPMessage in which
- the messageID is zero and protocolOp is set to the extendedResp
- choice using the ExtendedResponse type (See Section 4.12). The
- responseName field of the ExtendedResponse always contains an LDAPOID
- which is unique for this notification.
-
- One unsolicited notification (Notice of Disconnection) is defined in
- this document. The specification of an unsolicited notification
- consists of:
-
- - the OBJECT IDENTIFIER assigned to the notification (to be
- specified in the responseName,
-
- - the format of the contents of the responseValue (if any),
-
- - the circumstances which will cause the notification to be sent,
- and
-
- - the semantics of the message.
-
-
-4.4.1. Notice of Disconnection
-
- This notification may be used by the server to advise the client that
- the server is about to terminate the LDAP session on its own
- initiative. This notification is intended to assist clients in
- distinguishing between an exceptional server condition and a
- transient network failure. Note that this notification is not a
- response to an Unbind requested by the client. Uncompleted operations
- are handled as specified in Section 3.1.
-
- The responseName is 1.3.6.1.4.1.1466.20036, the responseValue field
- is absent, and the resultCode is used to indicate the reason for the
- disconnection. When the strongerAuthRequired resultCode is returned
- with this message, it indicates that the server has detected that an
- established security association between the client and server has
- unexpectedly failed or been compromised.
-
- Upon transmission of the Notice of Disconnection, the server
- gracefully terminates the LDAP session as described in Section 5.3.
-
-
-4.5. Search Operation
-
- The Search operation is used to request a server to return, subject
- to access controls and other restrictions, a set of entries matching
- a complex search criterion. This can be used to read attributes from
- a single entry, from entries immediately subordinate to a particular
- entry, or a whole subtree of entries.
-
-
-4.5.1. Search Request
-
- The Search request is defined as follows:
-
-Sermersheim Internet-Draft - Expires April 2006 Page 18
- Lightweight Directory Access Protocol Version 3
-
-
- SearchRequest ::= [APPLICATION 3] SEQUENCE {
- baseObject LDAPDN,
- scope ENUMERATED {
- baseObject (0),
- singleLevel (1),
- wholeSubtree (2),
- ... },
- derefAliases ENUMERATED {
- neverDerefAliases (0),
- derefInSearching (1),
- derefFindingBaseObj (2),
- derefAlways (3) },
- sizeLimit INTEGER (0 .. maxInt),
- timeLimit INTEGER (0 .. maxInt),
- typesOnly BOOLEAN,
- filter Filter,
- attributes AttributeSelection }
-
- AttributeSelection ::= SEQUENCE OF selector LDAPString
- -- The LDAPString is constrained to
- -- <attributeSelector> in Section 4.5.1.7
-
- Filter ::= CHOICE {
- and [0] SET SIZE (1..MAX) OF filter Filter,
- or [1] SET SIZE (1..MAX) OF filter Filter,
- not [2] Filter,
- equalityMatch [3] AttributeValueAssertion,
- substrings [4] SubstringFilter,
- greaterOrEqual [5] AttributeValueAssertion,
- lessOrEqual [6] AttributeValueAssertion,
- present [7] AttributeDescription,
- approxMatch [8] AttributeValueAssertion,
- extensibleMatch [9] MatchingRuleAssertion,
- ... }
-
- SubstringFilter ::= SEQUENCE {
- type AttributeDescription,
- substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
- initial [0] AssertionValue, -- can occur at most once
- any [1] AssertionValue,
- final [2] AssertionValue } -- can occur at most once
- }
-
- MatchingRuleAssertion ::= SEQUENCE {
- matchingRule [1] MatchingRuleId OPTIONAL,
- type [2] AttributeDescription OPTIONAL,
- matchValue [3] AssertionValue,
- dnAttributes [4] BOOLEAN DEFAULT FALSE }
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 19
- Lightweight Directory Access Protocol Version 3
-
- Note that an X.500 "list"-like operation can be emulated by the
- client requesting a singleLevel Search operation with a filter
- checking for the presence of the 'objectClass' attribute, and that an
- X.500 "read"-like operation can be emulated by a baseObject Search
- operation with the same filter. A server which provides a gateway to
- X.500 is not required to use the Read or List operations, although it
- may choose to do so, and if it does, it must provide the same
- semantics as the X.500 Search operation.
-
-
-4.5.1.1. SearchRequest.baseObject
-
- The name of the base object entry (or possibly the root) relative to
- which the Search is to be performed.
-
-
-4.5.1.2. SearchRequest.scope
-
- Specifies the scope of the Search to be performed. The semantics (as
- described in [X.511]) of the defined values of this field are:
-
- baseObject: The scope is constrained to the entry named by
- baseObject.
-
- singleLevel: The scope is constrained to the immediate
- subordinates of the entry named by baseObject.
-
- wholeSubtree: the scope is constrained to the entry named by the
- baseObject, and all its subordinates.
-
-
-4.5.1.3. SearchRequest.derefAliases
-
- An indicator as to whether or not alias entries (as defined in
- [Models]) are to be dereferenced during stages of the Search
- operation.
-
- The act of dereferencing an alias includes recursively dereferencing
- aliases which refer to aliases.
-
- Servers MUST detect looping while dereferencing aliases in order to
- prevent denial of service attacks of this nature.
-
- The semantics of the defined values of this field are:
-
- neverDerefAliases: Do not dereference aliases in searching or in
- locating the base object of the Search.
-
-
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 20
- Lightweight Directory Access Protocol Version 3
-
- derefInSearching: While searching subordinates of the base object,
- dereference any alias within the search scope. Dereferenced
- objects become the vertices of further search scopes where the
- Search operation is also applied. If the search scope is
- wholeSubtree, the Search continues in the subtree(s) of any
- dereferenced object. If the search scope is singleLevel, the
- search is applied to any dereferenced objects, and is not applied
- to their subordinates. Servers SHOULD eliminate duplicate entries
- that arise due to alias dereferencing while searching.
-
- derefFindingBaseObj: Dereference aliases in locating the base
- object of the Search, but not when searching subordinates of the
- base object.
-
- derefAlways: Dereference aliases both in searching and in locating
- the base object of the Search.
-
-
-4.5.1.4. SearchRequest.sizeLimit
-
- A size limit that restricts the maximum number of entries to be
- returned as a result of the Search. A value of zero in this field
- indicates that no client-requested size limit restrictions are in
- effect for the Search. Servers may also enforce a maximum number of
- entries to return.
-
-
-4.5.1.5. SearchRequest.timeLimit
-
- A time limit that restricts the maximum time (in seconds) allowed for
- a Search. A value of zero in this field indicates that no client-
- requested time limit restrictions are in effect for the Search.
- Servers may also enforce a maximum time limit for the Search.
-
-
-4.5.1.6. SearchRequest.typesOnly
-
- An indicator as to whether Search results are to contain both
- attribute descriptions and values, or just attribute descriptions.
- Setting this field to TRUE causes only attribute descriptions (no
- values) to be returned. Setting this field to FALSE causes both
- attribute descriptions and values to be returned.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 21
- Lightweight Directory Access Protocol Version 3
-
-4.5.1.7. SearchRequest.filter
-
- A filter that defines the conditions that must be fulfilled in order
- for the Search to match a given entry.
-
- The 'and', 'or' and 'not' choices can be used to form combinations of
- filters. At least one filter element MUST be present in an 'and' or
- 'or' choice. The others match against individual attribute values of
- entries in the scope of the Search. (Implementor's note: the 'not'
- filter is an example of a tagged choice in an implicitly-tagged
- module. In BER this is treated as if the tag was explicit.)
-
- A server MUST evaluate filters according to the three-valued logic of
- [X.511] (1993) Clause 7.8.1. In summary, a filter is evaluated to
- either "TRUE", "FALSE" or "Undefined". If the filter evaluates to
- TRUE for a particular entry, then the attributes of that entry are
- returned as part of the Search result (subject to any applicable
- access control restrictions). If the filter evaluates to FALSE or
- Undefined, then the entry is ignored for the Search.
-
- A filter of the "and" choice is TRUE if all the filters in the SET OF
- evaluate to TRUE, FALSE if at least one filter is FALSE, and
- otherwise Undefined. A filter of the "or" choice is FALSE if all of
- the filters in the SET OF evaluate to FALSE, TRUE if at least one
- filter is TRUE, and Undefined otherwise. A filter of the 'not' choice
- is TRUE if the filter being negated is FALSE, FALSE if it is TRUE,
- and Undefined if it is Undefined.
-
- A filter item evaluates to Undefined when the server would not be
- able to determine whether the assertion value matches an entry.
- Examples include:
-
- - An attribute description in an equalityMatch, substrings,
- greaterOrEqual, lessOrEqual, approxMatch or extensibleMatch
- filter is not recognized by the server.
-
- - The attribute type does not define the appropriate matching
- rule.
-
- - A MatchingRuleId in the extensibleMatch is not recognized by
- the server or is not valid for the attribute type.
-
- - The type of filtering requested is not implemented.
-
- - The assertion value is invalid.
-
- For example, if a server did not recognize the attribute type
- shoeSize, the filters (shoeSize=*), (shoeSize=12), (shoeSize>=12) and
- (shoeSize<=12) would each evaluate to Undefined.
-
- Servers MUST NOT return errors if attribute descriptions or matching
- rule ids are not recognized, assertion values are invalid, or the
- assertion syntax is not supported. More details of filter processing
- are given in Clause 7.8 of [X.511].
-
-Sermersheim Internet-Draft - Expires April 2006 Page 22
- Lightweight Directory Access Protocol Version 3
-
-
-
-4.5.1.7.1. SearchRequest.filter.equalityMatch
-
- The matching rule for an equalityMatch filter is defined by the
- EQUALITY matching rule for the attribute type or subtype. The filter
- is TRUE when the EQUALITY rule returns TRUE as applied to the
- attribute or subtype and the asserted value.
-
-
-4.5.1.7.2. SearchRequest.filter.substrings
-
- There SHALL be at most one 'initial', and at most one 'final' in the
- 'substrings' of a SubstringFilter. If 'initial' is present, it SHALL
- be the first element of 'substrings'. If 'final' is present, it SHALL
- be the last element of 'substrings'.
-
- The matching rule for an AssertionValue in a substrings filter item
- is defined by the SUBSTR matching rule for the attribute type or
- subtype. The filter is TRUE when the SUBSTR rule returns TRUE as
- applied to the attribute or subtype and the asserted value.
-
- Note that the AssertionValue in a substrings filter item conforms to
- the assertion syntax of the EQUALITY matching rule for the attribute
- type rather than the assertion syntax of the SUBSTR matching rule for
- the attribute type. Conceptually, the entire SubstringFilter is
- converted into an assertion value of the substrings matching rule
- prior to applying the rule.
-
-
-4.5.1.7.3. SearchRequest.filter.greaterOrEqual
-
- The matching rule for a greaterOrEqual filter is defined by the
- ORDERING matching rule for the attribute type or subtype. The filter
- is TRUE when the ORDERING rule returns FALSE as applied to the
- attribute or subtype and the asserted value.
-
-
-4.5.1.7.4. SearchRequest.filter.lessOrEqual
-
- The matching rules for a lessOrEqual filter are defined by the
- ORDERING and EQUALITY matching rules for the attribute type or
- subtype. The filter is TRUE when either the ORDERING or EQUALITY rule
- returns TRUE as applied to the attribute or subtype and the asserted
- value.
-
-
-4.5.1.7.5. SearchRequest.filter.present
-
- A present filter is TRUE when there is an attribute or subtype of the
- specified attribute description present in an entry, FALSE when no
- attribute or subtype of the specified attribute description is
- present in an entry, and Undefined otherwise.
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 23
- Lightweight Directory Access Protocol Version 3
-
-
-4.5.1.7.6. SearchRequest.filter.approxMatch
-
- An approxMatch filter is TRUE when there is a value of the attribute
- type or subtype for which some locally-defined approximate matching
- algorithm (e.g. spelling variations, phonetic match, etc.) returns
- TRUE. If a value matches for equality, it also satisfies an
- approximate match. If approximate matching is not supported for the
- attribute, this filter item should be treated as an equalityMatch.
-
-
-4.5.1.7.7. SearchRequest.filter.extensibleMatch
-
- The fields of the extensibleMatch filter item are evaluated as
- follows:
-
- - If the matchingRule field is absent, the type field MUST be
- present, and an equality match is performed for that type.
-
- - If the type field is absent and the matchingRule is present, the
- matchValue is compared against all attributes in an entry which
- support that matchingRule.
-
- - If the type field is present and the matchingRule is present, the
- matchValue is compared against the specified attribute type and
- its subtypes.
-
- - If the dnAttributes field is set to TRUE, the match is
- additionally applied against all the AttributeValueAssertions in
- an entry's distinguished name, and evaluates to TRUE if there is
- at least one attribute or subtype in the distinguished name for
- which the filter item evaluates to TRUE. The dnAttributes field is
- present to alleviate the need for multiple versions of generic
- matching rules (such as word matching), where one applies to
- entries and another applies to entries and DN attributes as well.
-
- The matchingRule used for evaluation determines the syntax for the
- assertion value. Once the matchingRule and attribute(s) have been
- determined, the filter item evaluates to TRUE if it matches at least
- one attribute type or subtype in the entry, FALSE if it does not
- match any attribute type or subtype in the entry, and Undefined if
- the matchingRule is not recognized, the matchingRule is unsuitable
- for use with the specified type, or the assertionValue is invalid.
-
-
-4.5.1.7. SearchRequest.attributes
-
- A selection list of the attributes to be returned from each entry
- which matches the search filter. Attributes which are subtypes of
- listed attributes are implicitly included. LDAPString values of this
- field are constrained to the following Augmented Backus-Naur Form
- ([ABNF]):
-
- attributeSelector = attributedescription / selectorspecial
-
-Sermersheim Internet-Draft - Expires April 2006 Page 24
- Lightweight Directory Access Protocol Version 3
-
-
- selectorspecial = noattrs / alluserattrs
-
- noattrs = %x31.2E.31 ; "1.1"
-
- alluserattrs = %x2A ; asterisk ("*")
-
- The <attributedescription> production is defined in Section 2.5 of
- [Models].
-
- There are three special cases which may appear in the attributes
- selection list:
-
- - an empty list with no attributes,
-
- - a list containing "*" (with zero or more attribute
- descriptions), and
-
- - a list containing only "1.1".
-
- An empty list requests the return of all user attributes.
-
- A list containing "*" requests the return of all user attributes
- in addition to other listed (operational) attributes.
-
- A list containing only the OID "1.1" indicates that no attributes
- are to be returned. If "1.1" is provided with other
- attributeSelector values, the "1.1" attributeSelector is ignored.
- This OID was chosen because it does not (and can not) correspond
- to any attribute in use.
-
- Client implementors should note that even if all user attributes are
- requested, some attributes and/or attribute values of the entry may
- not be included in Search results due to access controls or other
- restrictions. Furthermore, servers will not return operational
- attributes, such as objectClasses or attributeTypes, unless they are
- listed by name. Operational attributes are described in [Models].
-
- Attributes are returned at most once in an entry. If an attribute
- description is named more than once in the list, the subsequent names
- are ignored. If an attribute description in the list is not
- recognized, it is ignored by the server.
-
-
-4.5.2. Search Result
-
- The results of the Search operation are returned as zero or more
- SearchResultEntry and/or SearchResultReference messages, followed by
- a single SearchResultDone message.
-
- SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
- objectName LDAPDN,
- attributes PartialAttributeList }
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 25
- Lightweight Directory Access Protocol Version 3
-
- PartialAttributeList ::= SEQUENCE OF
- partialAttribute PartialAttribute
-
- SearchResultReference ::= [APPLICATION 19] SEQUENCE
- SIZE (1..MAX) OF uri URI
-
- SearchResultDone ::= [APPLICATION 5] LDAPResult
-
- Each SearchResultEntry represents an entry found during the Search.
- Each SearchResultReference represents an area not yet explored during
- the Search. The SearchResultEntry and SearchResultReference messages
- may come in any order. Following all the SearchResultReference and
- SearchResultEntry responses, the server returns a SearchResultDone
- response, which contains an indication of success, or detailing any
- errors that have occurred.
-
- Each entry returned in a SearchResultEntry will contain all
- appropriate attributes as specified in the attributes field of the
- Search Request, subject to access control and other administrative
- policy. Note that the PartialAttributeList may hold zero elements.
- This may happen when none of the attributes of an entry were
- requested, or could be returned. Note also that the partialAttribute
- vals set may hold zero elements. This may happen when typesOnly is
- requested, access controls prevent the return of values, or other
- reasons.
-
- Some attributes may be constructed by the server and appear in a
- SearchResultEntry attribute list, although they are not stored
- attributes of an entry. Clients SHOULD NOT assume that all attributes
- can be modified, even if permitted by access control.
-
- If the server's schema defines short names [Models] for an attribute
- type then the server SHOULD use one of those names in attribute
- descriptions for that attribute type (in preference to using the
- <numericoid> [Models] format of the attribute type's object
- identifier). The server SHOULD NOT use the short name if that name is
- known by the server to be ambiguous, or otherwise likely to cause
- interoperability problems.
-
-
-4.5.3. Continuation References in the Search Result
-
- If the server was able to locate the entry referred to by the
- baseObject but was unable or unwilling to search one or more non-
- local entries, the server may return one or more
- SearchResultReference messages, each containing a reference to
- another set of servers for continuing the operation. A server MUST
- NOT return any SearchResultReference messages if it has not located
- the baseObject and thus has not searched any entries; in this case it
- would return a SearchResultDone containing either a referral or
- noSuchObject result code (depending on the server's knowledge of the
- entry named in the baseObject).
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 26
- Lightweight Directory Access Protocol Version 3
-
- If a server holds a copy or partial copy of the subordinate naming
- context (Section 5 of [Models]), it may use the search filter to
- determine whether or not to return a SearchResultReference response.
- Otherwise SearchResultReference responses are always returned when in
- scope.
-
- The SearchResultReference is of the same data type as the Referral.
-
- If the client wishes to progress the Search, it issues a new Search
- operation for each SearchResultReference that is returned. If
- multiple URIs are present, the client assumes that any supported URI
- may be used to progress the operation.
-
- Clients that follow search continuation references MUST ensure that
- they do not loop between servers. They MUST NOT repeatedly contact
- the same server for the same request with the same parameters. Some
- clients use a counter that is incremented each time search result
- reference handling occurs for an operation, and these kinds of
- clients MUST be able to handle at least ten nested referrals while
- progressing the operation.
-
- Note that the Abandon operation described in Section 4.11 applies
- only to a particular operation sent at the LDAP message layer between
- a client and server. The client must abandon subsequent Search
- operations it wishes to individually.
-
- A URI for a server implementing LDAP and accessible via [TCP]/[IP]
- (v4 or v6) is written as an LDAP URL according to [LDAPURL].
-
- SearchResultReference values which are LDAP URLs follow these rules:
-
- - The <dn> part of the LDAP URL MUST be present, with the new target
- object name. The client uses this name when following the
- reference.
-
- - Some servers (e.g. participating in distributed indexing) may
- provide a different filter in the LDAP URL.
-
- - If the <filter> part of the LDAP URL is present, the client uses
- this filter in its next request to progress this Search, and if it
- is not present the client uses the same filter as it used for that
- Search.
-
- - If the originating search scope was singleLevel, the <scope> part
- of the LDAP URL will be "base".
-
- - It is RECOMMENDED that the <scope> part be present to avoid
- ambiguity. In the absence of a <scope> part, the scope of the
- original Search request is assumed.
-
- - Other aspects of the new Search request may be the same as or
- different from the Search request which generated the
- SearchResultReference.
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 27
- Lightweight Directory Access Protocol Version 3
-
- - The name of an unexplored subtree in a SearchResultReference need
- not be subordinate to the base object.
-
- Other kinds of URIs may be returned. The syntax and semantics of such
- URIs is left to future specifications. Clients may ignore URIs that
- they do not support.
-
- UTF-8 encoded characters appearing in the string representation of a
- DN, search filter, or other fields of the referral value may not be
- legal for URIs (e.g. spaces) and MUST be escaped using the % method
- in [URI].
-
-
-
-4.5.3.1. Examples
-
- For example, suppose the contacted server (hosta) holds the entry
- <DC=Example,DC=NET> and the entry <CN=Manager,DC=Example,DC=NET>. It
- knows that both LDAP servers (hostb) and (hostc) hold
- <OU=People,DC=Example,DC=NET> (one is the master and the other server
- a shadow), and that LDAP-capable server (hostd) holds the subtree
- <OU=Roles,DC=Example,DC=NET>. If a wholeSubtree Search of
- <DC=Example,DC=NET> is requested to the contacted server, it may
- return the following:
-
- SearchResultEntry for DC=Example,DC=NET
- SearchResultEntry for CN=Manager,DC=Example,DC=NET
- SearchResultReference {
- ldap://hostb/OU=People,DC=Example,DC=NET??sub
- ldap://hostc/OU=People,DC=Example,DC=NET??sub }
- SearchResultReference {
- ldap://hostd/OU=Roles,DC=Example,DC=NET??sub }
- SearchResultDone (success)
-
- Client implementors should note that when following a
- SearchResultReference, additional SearchResultReference may be
- generated. Continuing the example, if the client contacted the server
- (hostb) and issued the Search request for the subtree
- <OU=People,DC=Example,DC=NET>, the server might respond as follows:
-
- SearchResultEntry for OU=People,DC=Example,DC=NET
- SearchResultReference {
- ldap://hoste/OU=Managers,OU=People,DC=Example,DC=NET??sub }
- SearchResultReference {
- ldap://hostf/OU=Consultants,OU=People,DC=Example,DC=NET??sub }
- SearchResultDone (success)
-
- Similarly, if a singleLevel Search of <DC=Example,DC=NET> is
- requested to the contacted server, it may return the following:
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 28
- Lightweight Directory Access Protocol Version 3
-
- SearchResultEntry for CN=Manager,DC=Example,DC=NET
- SearchResultReference {
- ldap://hostb/OU=People,DC=Example,DC=NET??base
- ldap://hostc/OU=People,DC=Example,DC=NET??base }
- SearchResultReference {
- ldap://hostd/OU=Roles,DC=Example,DC=NET??base }
- SearchResultDone (success)
-
- If the contacted server does not hold the base object for the Search,
- but has knowledge of its possible location, then it may return a
- referral to the client. In this case, if the client requests a
- subtree Search of <DC=Example,DC=ORG> to hosta, the server returns a
- SearchResultDone containing a referral.
-
- SearchResultDone (referral) {
- ldap://hostg/DC=Example,DC=ORG??sub }
-
-
-4.6. Modify Operation
-
- The Modify operation allows a client to request that a modification
- of an entry be performed on its behalf by a server. The Modify
- Request is defined as follows:
-
- ModifyRequest ::= [APPLICATION 6] SEQUENCE {
- object LDAPDN,
- changes SEQUENCE OF change SEQUENCE {
- operation ENUMERATED {
- add (0),
- delete (1),
- replace (2),
- ... },
- modification PartialAttribute } }
-
- Fields of the Modify Request are:
-
- - object: The value of this field contains the name of the entry to
- be modified. The server SHALL NOT perform any alias dereferencing
- in determining the object to be modified.
-
- - changes: A list of modifications to be performed on the entry. The
- entire list of modifications MUST be performed in the order they
- are listed as a single atomic operation. While individual
- modifications may violate certain aspects of the directory schema
- (such as the object class definition and DIT content rule), the
- resulting entry after the entire list of modifications is
- performed MUST conform to the requirements of the directory model
- and controlling schema [Models].
-
- - operation: Used to specify the type of modification being
- performed. Each operation type acts on the following
- modification. The values of this field have the following
- semantics respectively:
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 29
- Lightweight Directory Access Protocol Version 3
-
- add: add values listed to the modification attribute,
- creating the attribute if necessary;
-
- delete: delete values listed from the modification attribute.
- If no values are listed, or if all current values of the
- attribute are listed, the entire attribute is removed;
-
- replace: replace all existing values of the modification
- attribute with the new values listed, creating the attribute
- if it did not already exist. A replace with no value will
- delete the entire attribute if it exists, and is ignored if
- the attribute does not exist.
-
- - modification: A PartialAttribute (which may have an empty SET
- of vals) used to hold the attribute type or attribute type and
- values being modified.
-
- Upon receipt of a Modify Request, the server attempts to perform the
- necessary modifications to the DIT and returns the result in a Modify
- Response, defined as follows:
-
- ModifyResponse ::= [APPLICATION 7] LDAPResult
-
- The server will return to the client a single Modify Response
- indicating either the successful completion of the DIT modification,
- or the reason that the modification failed. Due to the requirement
- for atomicity in applying the list of modifications in the Modify
- Request, the client may expect that no modifications of the DIT have
- been performed if the Modify Response received indicates any sort of
- error, and that all requested modifications have been performed if
- the Modify Response indicates successful completion of the Modify
- operation. Whether the modification was applied or not cannot be
- determined by the client if the Modify Response was not received
- (e.g. the LDAP session was terminated or the Modify operation was
- abandoned).
-
- Servers MUST ensure that entries conform to user and system schema
- rules or other data model constraints. The Modify operation cannot be
- used to remove from an entry any of its distinguished values, i.e.
- those values which form the entry's relative distinguished name. An
- attempt to do so will result in the server returning the
- notAllowedOnRDN result code. The Modify DN operation described in
- Section 4.9 is used to rename an entry.
-
- For attribute types which specify no equality matching, the rules in
- Section 2.5.1 of [Models] are followed.
-
- Note that due to the simplifications made in LDAP, there is not a
- direct mapping of the changes in an LDAP ModifyRequest onto the
- changes of a DAP ModifyEntry operation, and different implementations
- of LDAP-DAP gateways may use different means of representing the
- change. If successful, the final effect of the operations on the
- entry MUST be identical.
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 30
- Lightweight Directory Access Protocol Version 3
-
-
-4.7. Add Operation
-
- The Add operation allows a client to request the addition of an entry
- into the Directory. The Add Request is defined as follows:
-
- AddRequest ::= [APPLICATION 8] SEQUENCE {
- entry LDAPDN,
- attributes AttributeList }
-
- AttributeList ::= SEQUENCE OF attribute Attribute
-
- Fields of the Add Request are:
-
- - entry: the name of the entry to be added. The server SHALL NOT
- dereference any aliases in locating the entry to be added.
-
- - attributes: the list of attributes that, along with those from the
- RDN, make up the content of the entry being added. Clients MAY or
- MAY NOT include the RDN attribute(s) in this list. Clients MUST
- NOT supply NO-USER-MODIFICATION attributes such as the
- createTimestamp or creatorsName attributes, since the server
- maintains these automatically.
-
- Servers MUST ensure that entries conform to user and system schema
- rules or other data model constraints. For attribute types which
- specify no equality matching, the rules in Section 2.5.1 of [Models]
- are followed (this applies to the naming attribute in addition to any
- multi-valued attributes being added).
-
- The entry named in the entry field of the AddRequest MUST NOT exist
- for the AddRequest to succeed. The immediate superior (parent) of an
- object or alias entry to be added MUST exist. For example, if the
- client attempted to add <CN=JS,DC=Example,DC=NET>, the
- <DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did
- exist, then the server would return the noSuchObject result code with
- the matchedDN field containing <DC=NET>.
-
- Upon receipt of an Add Request, a server will attempt to add the
- requested entry. The result of the Add attempt will be returned to
- the client in the Add Response, defined as follows:
-
- AddResponse ::= [APPLICATION 9] LDAPResult
-
- A response of success indicates that the new entry has been added to
- the Directory.
-
-
-4.8. Delete Operation
-
- The Delete operation allows a client to request the removal of an
- entry from the Directory. The Delete Request is defined as follows:
-
- DelRequest ::= [APPLICATION 10] LDAPDN
-
-Sermersheim Internet-Draft - Expires April 2006 Page 31
- Lightweight Directory Access Protocol Version 3
-
-
- The Delete Request consists of the name of the entry to be deleted.
- The server SHALL NOT dereference aliases while resolving the name of
- the target entry to be removed.
-
- Only leaf entries (those with no subordinate entries) can be deleted
- with this operation.
-
- Upon receipt of a Delete Request, a server will attempt to perform
- the entry removal requested and return the result in the Delete
- Response defined as follows:
-
- DelResponse ::= [APPLICATION 11] LDAPResult
-
-
-4.9. Modify DN Operation
-
- The Modify DN operation allows a client to change the Relative
- Distinguished Name (RDN) of an entry in the Directory, and/or to move
- a subtree of entries to a new location in the Directory. The Modify
- DN Request is defined as follows:
-
- ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
- entry LDAPDN,
- newrdn RelativeLDAPDN,
- deleteoldrdn BOOLEAN,
- newSuperior [0] LDAPDN OPTIONAL }
-
- Fields of the Modify DN Request are:
-
- - entry: the name of the entry to be changed. This entry may or may
- not have subordinate entries.
-
- - newrdn: the new RDN of the entry. The value of the old RDN is
- supplied when moving the entry to a new superior without changing
- its RDN. Attribute values of the new RDN not matching any
- attribute value of the entry are added to the entry and an
- appropriate error is returned if this fails.
-
- - deleteoldrdn: a boolean field that controls whether the old RDN
- attribute values are to be retained as attributes of the entry, or
- deleted from the entry.
-
- - newSuperior: if present, this is the name of an existing object
- entry which becomes the immediate superior (parent) of the
- existing entry.
-
- The server SHALL NOT dereference any aliases in locating the objects
- named in entry or newSuperior.
-
- Upon receipt of a ModifyDNRequest, a server will attempt to perform
- the name change and return the result in the Modify DN Response,
- defined as follows:
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 32
- Lightweight Directory Access Protocol Version 3
-
- ModifyDNResponse ::= [APPLICATION 13] LDAPResult
-
- For example, if the entry named in the entry field was <cn=John
- Smith,c=US>, the newrdn field was <cn=John Cougar Smith>, and the
- newSuperior field was absent, then this operation would attempt to
- rename the entry to be <cn=John Cougar Smith,c=US>. If there was
- already an entry with that name, the operation would fail with the
- entryAlreadyExists result code.
-
- Servers MUST ensure that entries conform to user and system schema
- rules or other data model constraints. For attribute types which
- specify no equality matching, the rules in Section 2.5.1 of [Models]
- are followed (this pertains to newrdn and deleteoldrdn).
-
- The object named in newSuperior MUST exist. For example, if the
- client attempted to add <CN=JS,DC=Example,DC=NET>, the
- <DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did
- exist, then the server would return the noSuchObject result code with
- the matchedDN field containing <DC=NET>.
-
- If the deleteoldrdn field is TRUE, the attribute values forming the
- old RDN but not the new RDN are deleted from the entry. If the
- deleteoldrdn field is FALSE, the attribute values forming the old RDN
- will be retained as non-distinguished attribute values of the entry.
-
- Note that X.500 restricts the ModifyDN operation to only affect
- entries that are contained within a single server. If the LDAP server
- is mapped onto DAP, then this restriction will apply, and the
- affectsMultipleDSAs result code will be returned if this error
- occurred. In general, clients MUST NOT expect to be able to perform
- arbitrary movements of entries and subtrees between servers or
- between naming contexts.
-
-
-4.10. Compare Operation
-
- The Compare operation allows a client to compare an assertion value
- with the values of a particular attribute in a particular entry in
- the Directory. The Compare Request is defined as follows:
-
- CompareRequest ::= [APPLICATION 14] SEQUENCE {
- entry LDAPDN,
- ava AttributeValueAssertion }
-
- Fields of the Compare Request are:
-
- - entry: the name of the entry to be compared. The server SHALL NOT
- dereference any aliases in locating the entry to be compared.
-
- - ava: holds the attribute value assertion to be compared.
-
- Upon receipt of a Compare Request, a server will attempt to perform
- the requested comparison and return the result in the Compare
- Response, defined as follows:
-
-Sermersheim Internet-Draft - Expires April 2006 Page 33
- Lightweight Directory Access Protocol Version 3
-
-
- CompareResponse ::= [APPLICATION 15] LDAPResult
-
- The resultCode is set to compareTrue, compareFalse, or an appropriate
- error. compareTrue indicates that the assertion value in the ava
- field matches a value of the attribute or subtype according to the
- attribute's EQUALITY matching rule. compareFalse indicates that the
- assertion value in the ava field and the values of the attribute or
- subtype did not match. Other result codes indicate either that the
- result of the comparison was Undefined (Section 4.5.1), or that some
- error occurred.
-
- Note that some directory systems may establish access controls which
- permit the values of certain attributes (such as userPassword) to be
- compared but not interrogated by other means.
-
-
-4.11. Abandon Operation
-
- The function of the Abandon operation is to allow a client to request
- that the server abandon an uncompleted operation. The Abandon Request
- is defined as follows:
-
- AbandonRequest ::= [APPLICATION 16] MessageID
-
- The MessageID is that of an operation which was requested earlier at
- this LDAP message layer. The Abandon request itself has its own
- MessageID. This is distinct from the MessageID of the earlier
- operation being abandoned.
-
- There is no response defined in the Abandon operation. Upon receipt
- of an AbandonRequest, the server MAY abandon the operation identified
- by the MessageID. Since the client cannot tell the difference between
- a successfully abandoned operation and an uncompleted operation, the
- application of the Abandon operation is limited to uses where the
- client does not require an indication of its outcome.
-
- Abandon, Bind, Unbind, and StartTLS operations cannot be abandoned.
-
- In the event that a server receives an Abandon Request on a Search
- operation in the midst of transmitting responses to the Search, that
- server MUST cease transmitting entry responses to the abandoned
- request immediately, and MUST NOT send the SearchResultDone. Of
- course, the server MUST ensure that only properly encoded LDAPMessage
- PDUs are transmitted.
-
- The ability to abandon other (particularly update) operations is at
- the discretion of the server.
-
- Clients should not send Abandon requests for the same operation
- multiple times, and MUST also be prepared to receive results from
- operations it has abandoned (since these may have been in transit
- when the Abandon was requested, or are not able to be abandoned).
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 34
- Lightweight Directory Access Protocol Version 3
-
- Servers MUST discard Abandon requests for message IDs they do not
- recognize, for operations which cannot be abandoned, and for
- operations which have already been abandoned.
-
-
-4.12. Extended Operation
-
- The Extended operation allows additional operations to be defined for
- services not already available in the protocol. For example, to Add
- operations to install transport layer security (see Section 4.14).
-
- The Extended operation allows clients to make requests and receive
- responses with predefined syntaxes and semantics. These may be
- defined in RFCs or be private to particular implementations.
-
- Each Extended operation consists of an Extended request and an
- Extended response.
-
- ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
- requestName [0] LDAPOID,
- requestValue [1] OCTET STRING OPTIONAL }
-
- The requestName is a dotted-decimal representation of the unique
- OBJECT IDENTIFIER corresponding to the request. The requestValue is
- information in a form defined by that request, encapsulated inside an
- OCTET STRING.
-
- The server will respond to this with an LDAPMessage containing an
- ExtendedResponse.
-
- ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
- COMPONENTS OF LDAPResult,
- responseName [10] LDAPOID OPTIONAL,
- responseValue [11] OCTET STRING OPTIONAL }
-
- The responseName field, when present, contains an LDAPOID which is
- unique for this extended operation or response. This field is
- optional (even when the extension specification specifies an LDAPOID
- to be returned in the field). The field will be absent whenever the
- server is unable or unwilling to determine the appropriate LDAPOID to
- return, for instance when the requestName cannot be parsed or its
- value is not recognized.
-
- Where the requestName is not recognized, the server returns
- protocolError (The server may return protocolError in other cases).
-
- The requestValue and responseValue fields contain information
- associated with the operation. The format of these fields is defined
- by the specification of the Extended operation. Implementations MUST
- be prepared to handle arbitrary contents of these fields, including
- zero bytes. Values that are defined in terms of ASN.1 and BER encoded
- according to Section 5.1, also follow the extensibility rules in
- Section 4.
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 35
- Lightweight Directory Access Protocol Version 3
-
- Servers list the requestName of Extended Requests they recognize in
- the 'supportedExtension' attribute in the root DSE (Section 5.1 of
- [Models]).
-
- Extended operations may be specified in other documents. The
- specification of an Extended operation consists of:
-
- - the OBJECT IDENTIFIER assigned to the requestName,
-
- - the OBJECT IDENTIFIER (if any) assigned to the responseName (note
- that the same OBJECT IDENTIFIER may be used for both the
- requestName and responseName),
-
- - the format of the contents of the requestValue and responseValue
- (if any), and
-
- - the semantics of the operation.
-
-
-4.13. IntermediateResponse Message
-
- While the Search operation provides a mechanism to return multiple
- response messages for a single Search request, other operations, by
- nature, do not provide for multiple response messages.
-
- The IntermediateResponse message provides a general mechanism for
- defining single-request/multiple-response operations in LDAP. This
- message is intended to be used in conjunction with the Extended
- operation to define new single-request/multiple-response operations
- or in conjunction with a control when extending existing LDAP
- operations in a way that requires them to return Intermediate
- response information.
-
- It is intended that the definitions and descriptions of Extended
- operations and controls that make use of the IntermediateResponse
- message will define the circumstances when an IntermediateResponse
- message can be sent by a server and the associated meaning of an
- IntermediateResponse message sent in a particular circumstance.
-
- IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
- responseName [0] LDAPOID OPTIONAL,
- responseValue [1] OCTET STRING OPTIONAL }
-
- IntermediateResponse messages SHALL NOT be returned to the client
- unless the client issues a request that specifically solicits their
- return. This document defines two forms of solicitation: Extended
- operation and request control. IntermediateResponse messages are
- specified in documents describing the manner in which they are
- solicited (i.e. in the Extended operation or request control
- specification that uses them). These specifications include:
-
- - the OBJECT IDENTIFIER (if any) assigned to the responseName,
-
- - the format of the contents of the responseValue (if any), and
-
-Sermersheim Internet-Draft - Expires April 2006 Page 36
- Lightweight Directory Access Protocol Version 3
-
-
- - the semantics associated with the IntermediateResponse message.
-
- Extensions that allow the return of multiple types of
- IntermediateResponse messages SHALL identify those types using unique
- responseName values (note that one of these may specify no value).
-
- Sections 4.13.1 and 4.13.2 describe additional requirements on the
- inclusion of responseName and responseValue in IntermediateResponse
- messages.
-
-
-4.13.1. Usage with LDAP ExtendedRequest and ExtendedResponse
-
- A single-request/multiple-response operation may be defined using a
- single ExtendedRequest message to solicit zero or more
- IntermediateResponse messages of one or more kinds followed by an
- ExtendedResponse message.
-
-
-4.13.2. Usage with LDAP Request Controls
-
- A control's semantics may include the return of zero or more
- IntermediateResponse messages prior to returning the final result
- code for the operation. One or more kinds of IntermediateResponse
- messages may be sent in response to a request control.
-
- All IntermediateResponse messages associated with request controls
- SHALL include a responseName. This requirement ensures that the
- client can correctly identify the source of IntermediateResponse
- messages when:
-
- - two or more controls using IntermediateResponse messages are
- included in a request for any LDAP operation or
-
- - one or more controls using IntermediateResponse messages are
- included in a request with an LDAP Extended operation that uses
- IntermediateResponse messages.
-
-
-4.14. StartTLS Operation
-
- The Start Transport Layer Security (StartTLS) operation's purpose is
- to initiate installation of a TLS layer. The StartTLS operation is
- defined using the Extended operation mechanism described in Section
- 4.12.
-
-
-
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 37
- Lightweight Directory Access Protocol Version 3
-
-4.14.1. StartTLS Request
-
- A client requests TLS establishment by transmitting a StartTLS
- request message to the server. The StartTLS request is defined in
- terms of an ExtendedRequest. The requestName is
- "1.3.6.1.4.1.1466.20037", and the requestValue field is always
- absent.
-
- The client MUST NOT send any LDAP PDUs at this LDAP message layer
- following this request until it receives a StartTLS Extended response
- and, in the case of a successful response, completes TLS
- negotiations.
-
- Detected sequencing problems (particularly those detailed in Section
- 3.1.1 of [AuthMeth]) result in the resultCode being set to
- operationsError.
-
- If the server does not support TLS (whether by design or by current
- configuration), it returns with the resultCode set to protocolError
- as described in Section 4.12.
-
-
-4.14.2. StartTLS Response
-
- When a StartTLS request is received, servers supporting the operation
- MUST return a StartTLS response message to the requestor. The
- responseName is "1.3.6.1.4.1.1466.20037" when provided (See 4.12).
- The responseValue is always absent.
-
- If the server is willing and able to negotiate TLS, it returns the
- StartTLS response with the resultCode set to success. Upon client
- receipt of a successful StartTLS response, protocol peers may
- commence with TLS negotiation as discussed in Section 3 of
- [AuthMeth].
-
- If the server is otherwise unwilling or unable to perform this
- operation, the server is to return an appropriate result code
- indicating the nature of the problem. For example, if the TLS
- subsystem is not presently available, the server may indicate so by
- returning with the resultCode set to unavailable. In cases where a
- non-success result code is returned, the LDAP session is left without
- a TLS layer.
-
-
-4.14.3. Removal of the TLS Layer
-
- Either the client or server MAY remove the TLS layer and leave the
- LDAP message layer intact by sending and receiving a TLS closure
- alert.
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 38
- Lightweight Directory Access Protocol Version 3
-
- The initiating protocol peer sends the TLS closure alert and MUST
- wait until it receives a TLS closure alert from the other peer before
- sending further LDAP PDUs.
-
- When a protocol peer receives the initial TLS closure alert, it may
- choose to allow the LDAP message layer to remain intact. In this
- case, it MUST immediately transmit a TLS closure alert. Following
- this, it MAY send and receive LDAP PDUs.
-
- Protocol peers MAY terminate the LDAP session after sending or
- receiving a TLS closure alert.
-
-
-5. Protocol Encoding, Connection, and Transfer
-
- This protocol is designed to run over connection-oriented, reliable
- transports, where the data stream is divided into octets (8-bit
- units), with each octet and each bit being significant.
-
- One underlying service, LDAP over TCP, is defined in Section
- 5.2. This service is generally applicable to applications providing
- or consuming X.500-based directory services on the Internet. This
- specification was generally written with the TCP mapping in mind.
- Specifications detailing other mappings may encounter various
- obstacles.
-
- Implementations of LDAP over TCP MUST implement the mapping as
- described in Section 5.2.
-
- This table illustrates the relationship between the different layers
- involved in an exchange between two protocol peers:
-
- +----------------------+
- | LDAP message layer |
- +----------------------+ > LDAP PDUs
- +----------------------+ < data
- | SASL layer |
- +----------------------+ > SASL-protected data
- +----------------------+ < data
- | TLS layer |
- Application +----------------------+ > TLS-protected data
- ------------+----------------------+ < data
- Transport | transport connection |
- +----------------------+
-
-
-5.1. Protocol Encoding
-
- The protocol elements of LDAP SHALL be encoded for exchange using the
- Basic Encoding Rules [BER] of [ASN.1] with the following
- restrictions:
-
- - Only the definite form of length encoding is used.
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 39
- Lightweight Directory Access Protocol Version 3
-
-
- - OCTET STRING values are encoded in the primitive form only.
-
- - If the value of a BOOLEAN type is true, the encoding of the value
- octet is set to hex "FF".
-
- - If a value of a type is its default value, it is absent. Only some
- BOOLEAN and INTEGER types have default values in this protocol
- definition.
-
- These restrictions are meant to ease the overhead of encoding and
- decoding certain elements in BER.
-
- These restrictions do not apply to ASN.1 types encapsulated inside of
- OCTET STRING values, such as attribute values, unless otherwise
- stated.
-
-
-5.2. Transmission Control Protocol (TCP)
-
- The encoded LDAPMessage PDUs are mapped directly onto the [TCP]
- bytestream using the BER-based encoding described in Section 5.1. It
- is recommended that server implementations running over the TCP
- provide a protocol listener on the Internet Assigned Numbers
- Authority (IANA)-assigned LDAP port, 389 [PortReg]. Servers may
- instead provide a listener on a different port number. Clients MUST
- support contacting servers on any valid TCP port.
-
-
-5.3. Termination of the LDAP session
-
- Termination of the LDAP session is typically initiated by the client
- sending an UnbindRequest (Section 4.3), or by the server sending a
- Notice of Disconnection (Section 4.4.1). In these cases each protocol
- peer gracefully terminates the LDAP session by ceasing exchanges at
- the LDAP message layer, tearing down any SASL layer, tearing down any
- TLS layer, and closing the transport connection.
-
- A protocol peer may determine that the continuation of any
- communication would be pernicious, and in this case may abruptly
- terminate the session by ceasing communication and closing the
- transport connection.
-
- In either case, when the LDAP session is terminated, uncompleted
- operations are handled as specified in Section 3.1.
-
-
-6. Security Considerations
-
- This version of the protocol provides facilities for simple
- authentication using a cleartext password, as well as any [SASL]
- mechanism. Installing SASL and/or TLS layers can provide integrity
- and other data security services.
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 40
- Lightweight Directory Access Protocol Version 3
-
- It is also permitted that the server can return its credentials to
- the client, if it chooses to do so.
-
- Use of cleartext password is strongly discouraged where the
- underlying transport service cannot guarantee confidentiality and may
- result in disclosure of the password to unauthorized parties.
-
- Servers are encouraged to prevent directory modifications by clients
- that have authenticated anonymously [AuthMeth].
-
- Security considerations for authentication methods, SASL mechanisms,
- and TLS are described in [AuthMeth].
-
- It should be noted that SASL authentication exchanges do not provide
- data confidentiality nor integrity protection for the version or name
- fields of the BindRequest nor the resultCode, diagnosticMessage, or
- referral fields of the BindResponse nor of any information contained
- in controls attached to Bind requests or responses. Thus information
- contained in these fields SHOULD NOT be relied on unless otherwise
- protected (such as by establishing protections at the transport
- layer).
-
- Implementors should note that various security factors, including
- authentication and authorization information and data security
- services may change during the course of the LDAP session, or even
- during the performance of a particular operation. For instance,
- credentials could expire, authorization identities or access controls
- could change, or the underlying security layer(s) could be replaced
- or terminated. Implementations should be robust in the handling of
- changing security factors.
- In some cases, it may be appropriate to continue the operation even
- in light of security factor changes. For instance, it may be
- appropriate to continue an Abandon operation regardless of the
- change, or to continue an operation when the change upgraded (or
- maintained) the security factor. In other cases, it may be
- appropriate to fail, or alter the processing of the operation. For
- instance, if confidential protections were removed, it would be
- appropriate to either fail a request to return sensitive data, or
- minimally, to exclude the return of sensitive data.
-
- Implementations which cache attributes and entries obtained via LDAP
- MUST ensure that access controls are maintained if that information
- is to be provided to multiple clients, since servers may have access
- control policies which prevent the return of entries or attributes in
- Search results except to particular authenticated clients. For
- example, caches could serve result information only to the client
- whose request caused it to be in the cache.
-
-
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 41
- Lightweight Directory Access Protocol Version 3
-
- Servers may return referrals or Search result references which
- redirect clients to peer servers. It is possible for a rogue
- application to inject such referrals into the data stream in an
- attempt to redirect a client to a rogue server. Clients are advised
- to be aware of this, and possibly reject referrals when
- confidentiality measures are not in place. Clients are advised to
- reject referrals from the StartTLS operation.
-
- The matchedDN and diagnosticMessage fields, as well as some
- resultCode values (e.g., attributeOrValueExists and
- entryAlreadyExists), could disclose the presence or absence of
- specific data in the directory which is subject to access and other
- administrative controls. Server implementations should restrict
- access to protected information equally under both normal and error
- conditions.
-
- Protocol peers MUST be prepared to handle invalid and arbitrary
- length protocol encodings. Invalid protocol encodings include: BER
- encoding exceptions, format string and UTF-8 encoding exceptions,
- overflow exceptions, integer value exceptions, and binary mode on/off
- flag exceptions. The LDAPv3 PROTOS [PROTOS-LDAP] test suite provides
- excellent examples of these exceptions and test cases used to
- discover flaws.
-
- In the event that a protocol peer senses an attack which in its
- nature could cause damage due to further communication at any layer
- in the LDAP session, the protocol peer should abruptly terminate the
- LDAP session as described in Section 5.3.
-
-
-7. Acknowledgements
-
- This document is based on RFC 2251 by Mark Wahl, Tim Howes, and Steve
- Kille. RFC 2251 was a product of the IETF ASID Working Group.
-
- It is also based on RFC 2830 by Jeff Hodges, RL "Bob" Morgan, and
- Mark Wahl. RFC 2830 was a product of the IETF LDAPEXT Working Group.
-
- It is also based on RFC 3771 by Roger Harrison, and Kurt Zeilenga.
- RFC 3771 was an individual submission to the IETF.
-
- This document is a product of the IETF LDAPBIS Working Group.
- Significant contributors of technical review and content include Kurt
- Zeilenga, Steven Legg, and Hallvard Furuseth.
-
-
-8. Normative References
-
- [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", draft-crocker-abnf-rfc2234bis-
- xx.txt, (a work in progress).
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 42
- Lightweight Directory Access Protocol Version 3
-
- [ASN.1] ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824-1:2002
- "Information Technology - Abstract Syntax Notation One
- (ASN.1): Specification of basic notation"
-
- [AuthMeth] Harrison, R., "LDAP: Authentication Methods and Connection
- Level Security Mechanisms", draft-ietf-ldapbis-authmeth-
- xx.txt, (a work in progress).
-
- [BER] ITU-T Rec. X.690 (07/2002) | ISO/IEC 8825-1:2002,
- "Information technology - ASN.1 encoding rules:
- Specification of Basic Encoding Rules (BER), Canonical
- Encoding Rules (CER) and Distinguished Encoding Rules
- (DER)", 2002.
-
- [IP] Postel, J., "Internet Protocol", STD5 and RFC 791,
- September 1981
-
- [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
- Architecture and Basic Multilingual Plane, ISO/IEC 10646-1
- : 1993.
-
- [Keyword] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, March 1997.
-
- [LDAPDN] Zeilenga, K., "LDAP: String Representation of
- Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, (a
- work in progress).
-
- [LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP", draft-ietf-
- ldapbis-bcp64-xx.txt, (a work in progress).
-
- [LDAPURL] Smith, M., "LDAP: Uniform Resource Locator", draft-ietf-
- ldapbis-url-xx.txt, (a work in progress).
-
- [Models] Zeilenga, K., "LDAP: Directory Information Models", draft-
- ietf-ldapbis-models-xx.txt (a work in progress).
-
- [Roadmap] Zeilenga, K., "LDAP: Technical Specification Road Map",
- draft-ietf-ldapbis-roadmap-xx.txt (a work in progress).
-
- [SASL] Melnikov, A., "Simple Authentication and Security Layer",
- draft-ietf-sasl-rfc2222bis-xx.txt (a work in progress).
-
- [SASLPrep] Zeilenga, K., "Stringprep profile for user names and
- passwords", draft-ietf-sasl-saslprep-xx.txt, (a work in
- progress).
-
- [StringPrep] Hoffman P. and M. Blanchet, "Preparation of
- Internationalized Strings ('stringprep')", draft-hoffman-
- rfc3454bis-xx.txt, a work in progress.
-
- [Syntaxes] Legg, S., and K. Dally, "LDAP: Syntaxes and Matching
- Rules", draft-ietf-ldapbis-syntaxes-xx.txt, (a work in
- progress).
-
-Sermersheim Internet-Draft - Expires April 2006 Page 43
- Lightweight Directory Access Protocol Version 3
-
-
- [TCP] Postel, J., "Transmission Control Protocol", STD7 and RFC
- 793, September 1981
-
- [TLS] Dierks, T. and C. Allen. "The TLS Protocol Version 1.1",
- draft-ietf-tls-rfc2246-bis-xx.txt, a work in progress.
-
- [Unicode] The Unicode Consortium, "The Unicode Standard, Version
- 3.2.0" is defined by "The Unicode Standard, Version 3.0"
- (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
- as amended by the "Unicode Standard Annex #27: Unicode
- 3.1" (http://www.unicode.org/reports/tr27/) and by the
- "Unicode Standard Annex #28: Unicode 3.2"
- (http://www.unicode.org/reports/tr28/).
-
- [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
- Resource Identifiers (URI): Generic Syntax", RFC 2396,
- August 1998.
-
- [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", STD63 and RFC3629, November 2003.
-
- [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
- Models and Service", 1993.
-
- [X.501] ITU-T Rec. X.501, "The Directory: Models", 1993.
-
- [X.511] ITU-T Rec. X.511, "The Directory: Abstract Service
- Definition", 1993.
-
-
-9. Informative References
-
- [Glossary] The Unicode Consortium, "Unicode Glossary",
- <http://www.unicode.org/glossary/>.
-
- [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report
- #17, Character Encoding Model", UTR17,
- <http://www.unicode.org/unicode/reports/tr17/>, August
- 2000.
-
- [PROTOS-LDAP] University of Oulu, "PROTOS Test-Suite: c06-ldapv3"
- <http://www.ee.oulu.fi/research/ouspg/protos/testing/c06/l
- dapv3/>
-
- [PortReg] IANA, "Port Numbers",
- http://www.iana.org/assignments/port-numbers
-
-
-10. IANA Considerations
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 44
- Lightweight Directory Access Protocol Version 3
-
- It is requested that the Internet Assigned Numbers Authority (IANA)
- update the LDAP result code registry to indicate that this document
- provides the definitive technical specification for result codes 0-
- 36, 48-54, 64-70, 80-90. It is also noted that one resultCode value
- (strongAuthRequired) has been renamed (to strongerAuthRequired).
-
- It is requested that the IANA update the LDAP Protocol Mechanism
- registry to indicate that this document and [AuthMeth] provides the
- definitive technical specification for the StartTLS
- (1.3.6.1.4.1.1466.20037) Extended operation.
-
- It is requested that the IANA update the occurrence of "RFC XXXX" in
- this section and Appendix B with this RFC number at publication.
-
- It is requested that IANA assign upon Standards Action an LDAP Object
- Identifier [LDAPIANA] to identify the ASN.1 module defined in this
- document.
-
- Subject: Request for LDAP Object Identifier Registration
- Person & email address to contact for further information:
- Jim Sermersheim <jimse@novell.com>
- Specification: RFC XXXX
- Author/Change Controller: IESG
- Comments:
- Identifies the LDAP ASN.1 module
-
- [[Note to RFC Editor: please replace the occurrence of <IANA-
- ASSIGNED-DIRECTORY-NUMBER> in Appendix B with the IANA assigned
- OID.]]
-
-
-11. Editor's Address
-
- Jim Sermersheim
- Novell, Inc.
- 1800 South Novell Place
- Provo, Utah 84606, USA
- jimse@novell.com
- +1 801 861-3088
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 45
- Lightweight Directory Access Protocol Version 3
-
-Appendix A. LDAP Result Codes
-
- This normative appendix details additional considerations regarding
- LDAP result codes and provides a brief, general description of each
- LDAP result code enumerated in Section 4.1.9.
-
- Additional result codes MAY be defined for use with extensions
- [LDAPIANA]. Client implementations SHALL treat any result code which
- they do not recognize as an unknown error condition.
-
- The descriptions provided here do not fully account for result code
- substitutions used to prevent unauthorized disclosures (such as
- substitution of noSuchObject for insufficientAccessRights, or
- invalidCredentials for insufficientAccessRights).
-
-
-A.1. Non-Error Result Codes
-
- These result codes (called "non-error" result codes) do not indicate
- an error condition:
- success (0),
- compareFalse (5),
- compareTrue (6),
- referral (10), and
- saslBindInProgress (14).
-
- The success, compareTrue, and compareFalse result codes indicate
- successful completion (and, hence, are referred to as "successful"
- result codes).
-
- The referral and saslBindInProgress result codes indicate the client
- needs to take additional action to complete the operation.
-
-
-A.2. Result Codes
-
- Existing LDAP result codes are described as follows:
-
- success (0)
- Indicates the successful completion of an operation. Note:
- this code is not used with the Compare operation. See
- compareFalse (5) and compareTrue (6).
-
- operationsError (1)
- Indicates that the operation is not properly sequenced with
- relation to other operations (of same or different type).
-
- For example, this code is returned if the client attempts to
- StartTLS [TLS] while there are other uncompleted operations
- or if a TLS layer was already installed.
-
- protocolError (2)
- Indicates the server received data which is not well-formed.
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 46
- Lightweight Directory Access Protocol Version 3
-
- For Bind operation only, this code is also used to indicate
- that the server does not support the requested protocol
- version.
-
- For Extended operations only, this code is also used to
- indicate that the server does not support (by design or
- configuration) the Extended operation associated with the
- requestName.
-
- For request operations specifying multiple controls, this may
- be used to indicate that the server cannot ignore the order
- of the controls as specified, or that the combination of the
- specified controls is invalid or unspecified.
-
- timeLimitExceeded (3)
- Indicates that the time limit specified by the client was
- exceeded before the operation could be completed.
-
- sizeLimitExceeded (4)
- Indicates that the size limit specified by the client was
- exceeded before the operation could be completed.
-
- compareFalse (5)
- Indicates that the Compare operation has successfully
- completed and the assertion has evaluated to FALSE or
- Undefined.
-
- compareTrue (6)
- Indicates that the Compare operation has successfully
- completed and the assertion has evaluated to TRUE.
-
- authMethodNotSupported (7)
- Indicates that the authentication method or mechanism is not
- supported.
-
- strongerAuthRequired (8)
- Indicates the server requires strong(er) authentication in
- order to complete the operation.
-
- When used with the Notice of Disconnection operation, this
- code indicates that the server has detected that an
- established security association between the client and
- server has unexpectedly failed or been compromised.
-
- referral (10)
- Indicates that a referral needs to be chased to complete the
- operation (see Section 4.1.10).
-
- adminLimitExceeded (11)
- Indicates that an administrative limit has been exceeded.
-
- unavailableCriticalExtension (12)
- Indicates a critical control is unrecognized (see Section
- 4.1.11).
-
-Sermersheim Internet-Draft - Expires April 2006 Page 47
- Lightweight Directory Access Protocol Version 3
-
-
- confidentialityRequired (13)
- Indicates that data confidentiality protections are required.
-
- saslBindInProgress (14)
- Indicates the server requires the client to send a new bind
- request, with the same SASL mechanism, to continue the
- authentication process (see Section 4.2).
-
- noSuchAttribute (16)
- Indicates that the named entry does not contain the specified
- attribute or attribute value.
-
- undefinedAttributeType (17)
- Indicates that a request field contains an unrecognized
- attribute description.
-
- inappropriateMatching (18)
- Indicates that an attempt was made (e.g. in an assertion) to
- use a matching rule not defined for the attribute type
- concerned.
-
- constraintViolation (19)
- Indicates that the client supplied an attribute value which
- does not conform to the constraints placed upon it by the
- data model.
-
- For example, this code is returned when multiple values are
- supplied to an attribute which has a SINGLE-VALUE constraint.
-
- attributeOrValueExists (20)
- Indicates that the client supplied an attribute or value to
- be added to an entry, but the attribute or value already
- exists.
-
- invalidAttributeSyntax (21)
- Indicates that a purported attribute value does not conform
- to the syntax of the attribute.
-
- noSuchObject (32)
- Indicates that the object does not exist in the DIT.
-
- aliasProblem (33)
- Indicates that an alias problem has occurred. For example,
- the code may used to indicate an alias has been dereferenced
- which names no object.
-
- invalidDNSyntax (34)
- Indicates that an LDAPDN or RelativeLDAPDN field (e.g. search
- base, target entry, ModifyDN newrdn, etc.) of a request does
- not conform to the required syntax or contains attribute
- values which do not conform to the syntax of the attribute's
- type.
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 48
- Lightweight Directory Access Protocol Version 3
-
-
- aliasDereferencingProblem (36)
- Indicates that a problem occurred while dereferencing an
- alias. Typically an alias was encountered in a situation
- where it was not allowed or where access was denied.
-
- inappropriateAuthentication (48)
- Indicates the server requires the client which had attempted
- to bind anonymously or without supplying credentials to
- provide some form of credentials.
-
- invalidCredentials (49)
- Indicates that the provided credentials (e.g. the user's name
- and password) are invalid.
-
- insufficientAccessRights (50)
- Indicates that the client does not have sufficient access
- rights to perform the operation.
-
- busy (51)
- Indicates that the server is too busy to service the
- operation.
-
- unavailable (52)
- Indicates that the server is shutting down or a subsystem
- necessary to complete the operation is offline.
-
- unwillingToPerform (53)
- Indicates that the server is unwilling to perform the
- operation.
-
- loopDetect (54)
- Indicates that the server has detected an internal loop (e.g.
- while dereferencing aliases or chaining an operation).
-
- namingViolation (64)
- Indicates that the entry's name violates naming restrictions.
-
- objectClassViolation (65)
- Indicates that the entry violates object class restrictions.
-
- notAllowedOnNonLeaf (66)
- Indicates that the operation is inappropriately acting upon a
- non-leaf entry.
-
- notAllowedOnRDN (67)
- Indicates that the operation is inappropriately attempting to
- remove a value which forms the entry's relative distinguished
- name.
-
- entryAlreadyExists (68)
- Indicates that the request cannot be fulfilled (added, moved,
- or renamed) as the target entry already exists.
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 49
- Lightweight Directory Access Protocol Version 3
-
-
- objectClassModsProhibited (69)
- Indicates that an attempt to modify the object class(es) of
- an entry's 'objectClass' attribute is prohibited.
-
- For example, this code is returned when a client attempts to
- modify the structural object class of an entry.
-
- affectsMultipleDSAs (71)
- Indicates that the operation cannot be performed as it would
- affect multiple servers (DSAs).
-
- other (80)
- Indicates the server has encountered an internal error.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 50
- Lightweight Directory Access Protocol Version 3
-
-Appendix B. Complete ASN.1 Definition
-
- This appendix is normative.
-
- Lightweight-Directory-Access-Protocol-V3 {1 3 6 1 1 <IANA-
- ASSIGNED-DIRECTORY-NUMBER>}
- -- Copyright (C) The Internet Society (2005). This version of
- -- this ASN.1 module is part of RFC XXXX; see the RFC itself
- -- for full legal notices.
- DEFINITIONS
- IMPLICIT TAGS
- EXTENSIBILITY IMPLIED ::=
-
- BEGIN
-
- LDAPMessage ::= SEQUENCE {
- messageID MessageID,
- protocolOp CHOICE {
- bindRequest BindRequest,
- bindResponse BindResponse,
- unbindRequest UnbindRequest,
- searchRequest SearchRequest,
- searchResEntry SearchResultEntry,
- searchResDone SearchResultDone,
- searchResRef SearchResultReference,
- modifyRequest ModifyRequest,
- modifyResponse ModifyResponse,
- addRequest AddRequest,
- addResponse AddResponse,
- delRequest DelRequest,
- delResponse DelResponse,
- modDNRequest ModifyDNRequest,
- modDNResponse ModifyDNResponse,
- compareRequest CompareRequest,
- compareResponse CompareResponse,
- abandonRequest AbandonRequest,
- extendedReq ExtendedRequest,
- extendedResp ExtendedResponse,
- ...,
- intermediateResponse IntermediateResponse },
- controls [0] Controls OPTIONAL }
-
- MessageID ::= INTEGER (0 .. maxInt)
-
- maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
-
- LDAPString ::= OCTET STRING -- UTF-8 encoded,
- -- [ISO10646] characters
-
- LDAPOID ::= OCTET STRING -- Constrained to <numericoid> [Models]
-
- LDAPDN ::= LDAPString -- Constrained to <distinguishedName>
- -- [LDAPDN]
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 51
- Lightweight Directory Access Protocol Version 3
-
- RelativeLDAPDN ::= LDAPString -- Constrained to <name-component>
- -- [LDAPDN]
-
- AttributeDescription ::= LDAPString
- -- Constrained to <attributedescription>
- -- [Models]
-
- AttributeValue ::= OCTET STRING
-
- AttributeValueAssertion ::= SEQUENCE {
- attributeDesc AttributeDescription,
- assertionValue AssertionValue }
-
- AssertionValue ::= OCTET STRING
-
- PartialAttribute ::= SEQUENCE {
- type AttributeDescription,
- vals SET OF value AttributeValue }
-
- Attribute ::= PartialAttribute(WITH COMPONENTS {
- ...,
- vals (SIZE(1..MAX))})
-
- MatchingRuleId ::= LDAPString
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 52
- Lightweight Directory Access Protocol Version 3
-
- LDAPResult ::= SEQUENCE {
- resultCode ENUMERATED {
- success (0),
- operationsError (1),
- protocolError (2),
- timeLimitExceeded (3),
- sizeLimitExceeded (4),
- compareFalse (5),
- compareTrue (6),
- authMethodNotSupported (7),
- strongerAuthRequired (8),
- -- 9 reserved --
- referral (10),
- adminLimitExceeded (11),
- unavailableCriticalExtension (12),
- confidentialityRequired (13),
- saslBindInProgress (14),
- noSuchAttribute (16),
- undefinedAttributeType (17),
- inappropriateMatching (18),
- constraintViolation (19),
- attributeOrValueExists (20),
- invalidAttributeSyntax (21),
- -- 22-31 unused --
- noSuchObject (32),
- aliasProblem (33),
- invalidDNSyntax (34),
- -- 35 reserved for undefined isLeaf --
- aliasDereferencingProblem (36),
- -- 37-47 unused --
- inappropriateAuthentication (48),
- invalidCredentials (49),
- insufficientAccessRights (50),
- busy (51),
- unavailable (52),
- unwillingToPerform (53),
- loopDetect (54),
- -- 55-63 unused --
- namingViolation (64),
- objectClassViolation (65),
- notAllowedOnNonLeaf (66),
- notAllowedOnRDN (67),
- entryAlreadyExists (68),
- objectClassModsProhibited (69),
- -- 70 reserved for CLDAP --
- affectsMultipleDSAs (71),
- -- 72-79 unused --
- other (80),
- ... },
- matchedDN LDAPDN,
- diagnosticMessage LDAPString,
- referral [3] Referral OPTIONAL }
-
- Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
-
-Sermersheim Internet-Draft - Expires April 2006 Page 53
- Lightweight Directory Access Protocol Version 3
-
-
- URI ::= LDAPString -- limited to characters permitted in
- -- URIs
-
- Controls ::= SEQUENCE OF control Control
-
- Control ::= SEQUENCE {
- controlType LDAPOID,
- criticality BOOLEAN DEFAULT FALSE,
- controlValue OCTET STRING OPTIONAL }
-
- BindRequest ::= [APPLICATION 0] SEQUENCE {
- version INTEGER (1 .. 127),
- name LDAPDN,
- authentication AuthenticationChoice }
-
- AuthenticationChoice ::= CHOICE {
- simple [0] OCTET STRING,
- -- 1 and 2 reserved
- sasl [3] SaslCredentials,
- ... }
-
- SaslCredentials ::= SEQUENCE {
- mechanism LDAPString,
- credentials OCTET STRING OPTIONAL }
-
- BindResponse ::= [APPLICATION 1] SEQUENCE {
- COMPONENTS OF LDAPResult,
- serverSaslCreds [7] OCTET STRING OPTIONAL }
-
- UnbindRequest ::= [APPLICATION 2] NULL
-
- SearchRequest ::= [APPLICATION 3] SEQUENCE {
- baseObject LDAPDN,
- scope ENUMERATED {
- baseObject (0),
- singleLevel (1),
- wholeSubtree (2),
- ... },
- derefAliases ENUMERATED {
- neverDerefAliases (0),
- derefInSearching (1),
- derefFindingBaseObj (2),
- derefAlways (3) },
- sizeLimit INTEGER (0 .. maxInt),
- timeLimit INTEGER (0 .. maxInt),
- typesOnly BOOLEAN,
- filter Filter,
- attributes AttributeSelection }
-
- AttributeSelection ::= SEQUENCE OF selector LDAPString
- -- The LDAPString is constrained to
- -- <attributeSelector> in Section 4.5.1.7
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 54
- Lightweight Directory Access Protocol Version 3
-
- Filter ::= CHOICE {
- and [0] SET SIZE (1..MAX) OF filter Filter,
- or [1] SET SIZE (1..MAX) OF filter Filter,
- not [2] Filter,
- equalityMatch [3] AttributeValueAssertion,
- substrings [4] SubstringFilter,
- greaterOrEqual [5] AttributeValueAssertion,
- lessOrEqual [6] AttributeValueAssertion,
- present [7] AttributeDescription,
- approxMatch [8] AttributeValueAssertion,
- extensibleMatch [9] MatchingRuleAssertion,
- ... }
-
- SubstringFilter ::= SEQUENCE {
- type AttributeDescription,
- substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
- initial [0] AssertionValue, -- can occur at most once
- any [1] AssertionValue,
- final [2] AssertionValue } -- can occur at most once
- }
-
- MatchingRuleAssertion ::= SEQUENCE {
- matchingRule [1] MatchingRuleId OPTIONAL,
- type [2] AttributeDescription OPTIONAL,
- matchValue [3] AssertionValue,
- dnAttributes [4] BOOLEAN DEFAULT FALSE }
-
- SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
- objectName LDAPDN,
- attributes PartialAttributeList }
-
- PartialAttributeList ::= SEQUENCE OF
- partialAttribute PartialAttribute
-
- SearchResultReference ::= [APPLICATION 19] SEQUENCE
- SIZE (1..MAX) OF uri URI
-
- SearchResultDone ::= [APPLICATION 5] LDAPResult
-
- ModifyRequest ::= [APPLICATION 6] SEQUENCE {
- object LDAPDN,
- changes SEQUENCE OF change SEQUENCE {
- operation ENUMERATED {
- add (0),
- delete (1),
- replace (2),
- ... },
- modification PartialAttribute } }
-
- ModifyResponse ::= [APPLICATION 7] LDAPResult
-
- AddRequest ::= [APPLICATION 8] SEQUENCE {
- entry LDAPDN,
- attributes AttributeList }
-
-Sermersheim Internet-Draft - Expires April 2006 Page 55
- Lightweight Directory Access Protocol Version 3
-
-
- AttributeList ::= SEQUENCE OF attribute Attribute
-
- AddResponse ::= [APPLICATION 9] LDAPResult
-
- DelRequest ::= [APPLICATION 10] LDAPDN
-
- DelResponse ::= [APPLICATION 11] LDAPResult
-
- ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
- entry LDAPDN,
- newrdn RelativeLDAPDN,
- deleteoldrdn BOOLEAN,
- newSuperior [0] LDAPDN OPTIONAL }
-
- ModifyDNResponse ::= [APPLICATION 13] LDAPResult
-
- CompareRequest ::= [APPLICATION 14] SEQUENCE {
- entry LDAPDN,
- ava AttributeValueAssertion }
-
- CompareResponse ::= [APPLICATION 15] LDAPResult
-
- AbandonRequest ::= [APPLICATION 16] MessageID
-
- ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
- requestName [0] LDAPOID,
- requestValue [1] OCTET STRING OPTIONAL }
-
- ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
- COMPONENTS OF LDAPResult,
- responseName [10] LDAPOID OPTIONAL,
- responseValue [11] OCTET STRING OPTIONAL }
-
- IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
- responseName [0] LDAPOID OPTIONAL,
- responseValue [1] OCTET STRING OPTIONAL }
-
- END
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 56
- Lightweight Directory Access Protocol Version 3
-
-Appendix C. Changes
-
- This appendix is non-normative.
-
- This appendix summarizes substantive changes made to RFC 2251, RFC
- 2830, and RFC 3771.
-
-
-C.1. Changes made to RFC 2251:
-
- This section summarizes the substantive changes made to Sections 1,
- 2, 3.1, and 4 through the remainder of RFC 2251. Readers should
- consult [Models] and [AuthMeth] for summaries of changes to other
- sections.
-
-
-C.1.1. Section 1 (Status of this Memo)
-
- - Removed IESG note. Post publication of RFC 2251, mandatory LDAP
- authentication mechanisms have been standardized which are
- sufficient to remove this note. See [AuthMeth] for authentication
- mechanisms.
-
-
-C.1.2. Section 3.1 (Protocol Model) and others
-
- - Removed notes giving history between LDAP v1, v2 and v3. Instead,
- added sufficient language so that this document can stand on its
- own.
-
-
-C.1.3. Section 4 (Elements of Protocol)
-
- - Clarified where the extensibility features of ASN.1 apply to the
- protocol. This change affected various ASN.1 types by the
- inclusion of ellipses (...) to certain elements.
- - Removed the requirement that servers which implement version 3 or
- later MUST provide the 'supportedLDAPVersion' attribute. This
- statement provided no interoperability advantages.
-
-
-C.1.4. Section 4.1.1 (Message Envelope)
-
- - There was a mandatory requirement for the server to return a
- Notice of Disconnection and drop the transport connection when a
- PDU is malformed in a certain way. This has been updated such that
- the server SHOULD return the Notice of Disconnection, and MUST
- terminate the LDAP Session.
-
-
-C.1.5. Section 4.1.1.1 (Message ID)
-
- - Required that the messageID of requests MUST be non-zero as the
- zero is reserved for Notice of Disconnection.
-
-Sermersheim Internet-Draft - Expires April 2006 Page 57
- Lightweight Directory Access Protocol Version 3
-
- - Specified when it is and isn't appropriate to return an already
- used message id. RFC 2251 accidentally imposed synchronous server
- behavior in its wording of this.
-
-
-C.1.6. Section 4.1.2 (String Types)
-
- - Stated that LDAPOID is constrained to <numericoid> from [Models].
-
-
-C.1.7. Section 4.1.5.1 (Binary Option) and others
-
- - Removed the Binary Option from the specification. There are
- numerous interoperability problems associated with this method of
- alternate attribute type encoding. Work to specify a suitable
- replacement is ongoing.
-
-
-C.1.8. Section 4.1.8 (Attribute)
-
- - Combined the definitions of PartialAttribute and Attribute here,
- and defined Attribute in terms of PartialAttribute.
-
-
-C.1.9. Section 4.1.10 (Result Message)
-
- - Renamed "errorMessage" to "diagnosticMessage" as it is allowed to
- be sent for non-error results.
- - Moved some language into Appendix A, and refer the reader there.
- - Allowed matchedDN to be present for other result codes than those
- listed in RFC 2251.
- - renamed the code "strongAuthRequired" to "strongerAuthRequired" to
- clarify that this code may often be returned to indicate that a
- stronger authentication is needed to perform a given operation.
-
-
-C.1.10. Section 4.1.11 (Referral)
-
- - Defined referrals in terms of URIs rather than URLs.
- - Removed the requirement that all referral URIs MUST be equally
- capable of progressing the operation. The statement was ambiguous
- and provided no instructions on how to carry it out.
- - Added the requirement that clients MUST NOT loop between servers.
- - Clarified the instructions for using LDAPURLs in referrals, and in
- doing so added a recommendation that the scope part be present.
- - Removed imperatives which required clients to use URLs in specific
- ways to progress an operation. These did nothing for
- interoperability.
-
-
-C.1.11. Section 4.1.12 (Controls)
-
- - Specified how control values defined in terms of ASN.1 are to be
- encoded.
-
-Sermersheim Internet-Draft - Expires April 2006 Page 58
- Lightweight Directory Access Protocol Version 3
-
- - Noted that the criticality field is only applied to request
- messages (except UnbindRequest), and must be ignored when present
- on response messages and UnbindRequest.
- - Specified that non-critical controls may be ignored at the
- server's discretion. There was confusion in the original wording
- which led some to believe that recognized controls may not be
- ignored as long as they were associated with a proper request.
- - Added language regarding combinations of controls and the ordering
- of controls on a message.
- - Specified that when the semantics of the combination of controls
- is undefined or unknown, it results in a protocolError.
- - Changed "The server MUST be prepared" to "Implementations MUST be
- prepared" in the eighth paragraph to reflect that both client and
- server implementations must be able to handle this (as both parse
- controls).
-
-
-C.1.12. Section 4.2 (Bind Operation)
-
- - Mandated that servers return protocolError when the version is not
- supported.
- - Disambiguated behavior when the simple authentication is used, the
- name is empty and the password is non-empty.
- - Required servers to not dereference aliases for Bind. This was
- added for consistency with other operations and to help ensure
- data consistency.
- - Required that textual passwords be transferred as UTF-8 encoded
- Unicode, and added recommendations on string preparation. This was
- to help ensure interoperability of passwords being sent from
- different clients.
-
-
-C.1.13. Section 4.2.1 (Sequencing of the Bind Request)
-
- - This section was largely reorganized for readability and language
- was added to clarify the authentication state of failed and
- abandoned Bind operations.
- - Removed: "If a SASL transfer encryption or integrity mechanism has
- been negotiated, that mechanism does not support the changing of
- credentials from one identity to another, then the client MUST
- instead establish a new connection."
- If there are dependencies between multiple negotiations of a
- particular SASL mechanism, the technical specification for that
- SASL mechanism details how applications are to deal with them.
- LDAP should not require any special handling.
- - Dropped MUST imperative in paragraph 3 to align with [Keywords].
- - Mandated that clients not send non-Bind operations while a Bind is
- in progress, and suggested that servers not process them if they
- are received. This is needed to ensure proper sequencing of the
- Bind in relationship to other operations.
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 59
- Lightweight Directory Access Protocol Version 3
-
-C.1.14. Section 4.2.3 (Bind Response)
-
- - Moved most error-related text to Appendix A, and added text
- regarding certain errors used in conjunction with the Bind
- operation.
- - Prohibited the server from specifying serverSaslCreds when not
- appropriate.
-
-
-C.1.15. Section 4.3 (Unbind Operation)
-
- - Specified that both peers are to cease transmission and terminate
- the LDAP session for the Unbind operation.
-
-
-C.1.16. Section 4.4 (Unsolicited Notification)
-
- - Added instructions for future specifications of Unsolicited
- Notifications.
-
-
-C.1.17. Section 4.5.1 (Search Request)
-
- - SearchRequest attributes is now defined as an AttributeSelection
- type rather than AttributeDescriptionList, and an ABNF is
- provided.
- - SearchRequest attributes may contain duplicate attribute
- descriptions. This was previously prohibited. Now servers are
- instructed to ignore subsequent names when they are duplicated.
- This was relaxed in order to allow different short names and also
- OIDs to be requested for an attribute.
- - The present search filter now evaluates to Undefined when the
- specified attribute is not known to the server. It used to
- evaluate to FALSE, which caused behavior inconsistent with what
- most would expect, especially when the not operator was used.
- - The Filter choice SubstringFilter substrings type is now defined
- with a lower bound of 1.
- - The SubstringFilter substrings 'initial, 'any', and 'final' types
- are now AssertionValue rather than LDAPString. Also, added
- imperatives stating that 'initial' (if present) must be listed
- first, and 'final' (if present) must be listed last.
- - Disambiguated the semantics of the derefAliases choices. There was
- question as to whether derefInSearching applied to the base object
- in a wholeSubtree Search.
- - Added instructions for equalityMatch, substrings, greaterOrEqual,
- lessOrEqual, and approxMatch.
-
-
-C.1.18. Section 4.5.2 (Search Result)
-
- - Recommended that servers not use attribute short names when it
- knows they are ambiguous or may cause interoperability problems.
- - Removed all mention of ExtendedResponse due to lack of
- implementation.
-
-Sermersheim Internet-Draft - Expires April 2006 Page 60
- Lightweight Directory Access Protocol Version 3
-
-
-
-C.1.19. Section 4.5.3 (Continuation References in the Search Result)
-
- - Made changes similar to those made to Section 4.1.11.
-
-
-C.1.20. Section 4.5.3.1 (Example)
-
- - Fixed examples to adhere to changes made to Section 4.5.3.
-
-
-C.1.21. Section 4.6 (Modify Operation)
-
- - Replaced AttributeTypeAndValues with Attribute as they are
- equivalent.
- - Specified the types of modification changes which might
- temporarily violate schema. Some readers were under the impression
- that any temporary schema violation was allowed.
-
-
-C.1.22. Section 4.7 (Add Operation)
-
- - Aligned Add operation with X.511 in that the attributes of the RDN
- are used in conjunction with the listed attributes to create the
- entry. Previously, Add required that the distinguished values be
- present in the listed attributes.
- - Removed requirement that the objectClass attribute MUST be
- specified as some DSE types do not require this attribute.
- Instead, generic wording was added, requiring the added entry to
- adhere to the data model.
- - Removed recommendation regarding placement of objects. This is
- covered in the data model document.
-
-
-C.1.23. Section 4.9 (Modify DN Operation)
-
- - Required servers to not dereference aliases for Modify DN. This
- was added for consistency with other operations and to help ensure
- data consistency.
- - Allow Modify DN to fail when moving between naming contexts.
- - Specified what happens when the attributes of the newrdn are not
- present on the entry.
-
-
-C.1.24. Section 4.10 (Compare Operation)
-
- - Specified that compareFalse means that the Compare took place and
- the result is false. There was confusion which lead people to
- believe that an Undefined match resulted in compareFalse.
- - Required servers to not dereference aliases for Compare. This was
- added for consistency with other operations and to help ensure
- data consistency.
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 61
- Lightweight Directory Access Protocol Version 3
-
-
-C.1.25. Section 4.11 (Abandon Operation)
-
- - Explained that since Abandon returns no response, clients should
- not use it if they need to know the outcome.
- - Specified that Abandon and Unbind cannot be abandoned.
-
-
-C.1.26. Section 4.12 (Extended Operation)
-
- - Specified how values of Extended operations defined in terms of
- ASN.1 are to be encoded.
- - Added instructions on what Extended operation specifications
- consist of.
- - Added a recommendation that servers advertise supported Extended
- operations.
-
-
-C.1.27. Section 5.2 (Transfer Protocols)
-
- - Moved referral-specific instructions into referral-related
- sections.
-
-
-C.1.28. Section 7 (Security Considerations)
-
- - Reworded notes regarding SASL not protecting certain aspects of
- the LDAP Bind messages.
- - Noted that Servers are encouraged to prevent directory
- modifications by clients that have authenticated anonymously
- [AuthMeth].
- - Added a note regarding the possibility of changes to security
- factors (authentication, authorization, data confidentiality).
- - Warned against following referrals that may have been injected in
- the data stream.
- - Noted that servers should protect information equally, whether in
- an error condition or not, and mentioned specifically; matchedDN,
- diagnosticMessage, and resultCodes.
- - Added a note regarding malformed and long encodings.
-
-
-C.1.29. Appendix A (Complete ASN.1 Definition)
-
- - Added "EXTENSIBILITY IMPLIED" to ASN.1 definition.
- - Removed AttributeType. It is not used.
-
-
-C.2. Changes made to RFC 2830:
-
- This section summarizes the substantive changes made to Sections of
- RFC 2830. Readers should consult [AuthMeth] for summaries of changes
- to other sections.
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 62
- Lightweight Directory Access Protocol Version 3
-
-C.2.1. Section 2.3 (Response other than "success")
-
- - Removed wording indicating that referrals can be returned from
- StartTLS.
- - Removed requirement that only a narrow set of result codes can be
- returned. Some result codes are required in certain scenarios, but
- any other may be returned if appropriate.
- - Removed requirement that the ExtendedResponse.responseName MUST be
- present. There are circumstances where this is impossible, and
- requiring this is at odds with language in Section 4.12.
-
-
-C.2.1. Section 4 (Closing a TLS Connection)
-
- - Reworded most of this section to align with definitions of the
- LDAP protocol layers.
- - Removed instructions on abrupt closure as this is covered in other
- areas of the document (specifically, Section 5.3)
-
-
-C.3. Changes made to RFC 3771:
-
- - Rewrote to fit into this document. In general, semantics were
- preserved. Supporting and background language seen as redundant
- due to its presence in this document was omitted.
- - Specified that Intermediate responses to a request may be of
- different types, and one of the response types may be specified to
- have no response value.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 63
- Lightweight Directory Access Protocol Version 3
-
-
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at ietf-
- ipr@ietf.org.
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2005).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-Sermersheim Internet-Draft - Expires April 2006 Page 64
diff --git a/doc/drafts/draft-ietf-ldapbis-roadmap-xx.txt b/doc/drafts/draft-ietf-ldapbis-roadmap-xx.txt
deleted file mode 100644
index 70f80425fe15477d35df37f87b124c67808023e2..0000000000000000000000000000000000000000
--- a/doc/drafts/draft-ietf-ldapbis-roadmap-xx.txt
+++ /dev/null
@@ -1,396 +0,0 @@
-
-
-
-
-
-INTERNET-DRAFT Editor: Kurt D. Zeilenga
-Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 10 February 2005
-Obsoletes: RFC 2251-2256, 2829-2830, 3377, 3771
-
-
-
- Lightweight Directory Access Protocol (LDAP):
- Technical Specification Road Map
- <draft-ietf-ldapbis-roadmap-07.txt>
-
-
-
-Status of this Memo
-
- This document is intended to be published as a Standard Track RFC.
- Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDAP Revision Working Group
- mailing list <ietf-ldapbis@openldap.org>. Please send editorial
- comments directly to the author <Kurt@OpenLDAP.org>.
-
- By submitting this Internet-Draft, I accept the provisions of Section
- 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
- applicable patent or other IPR claims of which I am aware have been
- disclosed, or will be disclosed, and any of which I become aware will
- be disclosed, in accordance with RFC 3668.
-
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference material
- or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
- Copyright (C) The Internet Society (2005). All Rights Reserved.
-
- Please see the Full Copyright section near the end of this document
- for more information.
-
-
-
-
-Zeilenga LDAP: TS Road Map [Page 1]
-
-INTERNET-DRAFT draft-ietf-ldapbis-roadmap-07 10 February 2005
-
-
-Abstract
-
- The Lightweight Directory Access Protocol (LDAP) is an Internet
- protocol for accessing distributed directory services which act in
- accordance with X.500 data and service models. This document provides
- a roadmap of the LDAP Technical Specification.
-
-
-Conventions
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119].
-
-
-1. The LDAP Technical Specification
-
- The technical specification detailing version 3 of the Lightweight
- Directory Access Protocol (LDAP), an Internet Protocol, consists of
- this document and the following documents:
-
- LDAP: The Protocol [Protocol],
- LDAP: Directory Information Models [Models],
- LDAP: Authentication Methods and Connection Level Security
- Mechanisms [AuthMeth],
- LDAP: String Representation of Distinguished Names [LDAPDN],
- LDAP: String Representation of Search Filters [Filters],
- LDAP: Uniform Resource Locator [LDAPURL],
- LDAP: Syntaxes and Matching Rules [Syntaxes],
- LDAP: Internationalized String Preparation [LDAPprep], and
- LDAP: User Schema [Schema].
-
- The terms "LDAP" and "LDAPv3" are commonly used to informally refer to
- the protocol specified by this technical specification. The LDAP
- suite, as defined here, should be formally identified in other
- documents by a normative reference to this document.
-
- LDAP is an extensible protocol. Extensions to LDAP may be specified
- in other documents. Nomenclature denoting such combinations of
- LDAP-plus-extension(s) is not defined by this document but may be
- defined in some future document(s). Extensions are expected to be
- truly optional.
-
- IANA (Internet Assigned Numbers Authority) considerations for LDAP
- described in BCP 64 [BCP64bis] apply fully to this revision of the
- LDAP technical specification.
-
-
-
-
-
-Zeilenga LDAP: TS Road Map [Page 2]
-
-INTERNET-DRAFT draft-ietf-ldapbis-roadmap-07 10 February 2005
-
-
-2. Relationship to X.500
-
- This technical specification defines LDAP in terms of [X.500] as an
- X.500 access mechanism. An LDAP server MUST act in accordance with
- X.500(1993) series of International Telecommunication Union - Telecom
- Standardization (ITU-T) Recommendations when providing the service.
- However, it is not required that an LDAP server make use of any X.500
- protocols in providing this service, e.g. LDAP can be mapped onto any
- other directory system so long as the X.500 data and service models
- [X.501][X.511] as used in LDAP is not violated in the LDAP interface.
-
- This technical specification explicitly incorporates portions of
- X.500(93). Later revisions of X.500 do not automatically apply to
- this technical specification.
-
-
-3. Security Considerations
-
- LDAP security considerations are discussed in each document comprising
- the technical specification.
-
-
-4. Relationship to Obsolete Specifications
-
- This technical specification, as defined in Section 1, obsoletes
- entirely the previously defined LDAP technical specification [RFC3377]
- (which consists of RFC 2251-2256, RFC 2829-2830, RFC 3771, and RFC
- 3377 itself). The technical specification was significantly
- reorganized.
-
- This document replaces RFC 3377 as well as Section 3.3 of RFC 2251.
- [Models] replaces portions of RFC 2251, RFC 2252 and RFC 2256.
- [Protocol] replaces the majority RFC 2251, portions of RFC 2252, and
- all of RFC 3771. [AuthMeth] replaces RFC 2829, RFC 2830, and portions
- of RFC 2251. [Syntaxes] replaces the majority of RFC 2252 and
- portions of RFC 2256. [Schema] replaces the majority of RFC 2256.
- [LDAPDN] replaces RFC 2253. [Filters] replaces RFC 2254. [LDAPURL]
- replaces RFC 2255.
-
- [LDAPprep] is new to this revision of the LDAP technical
- specification.
-
- Each document of this specification contains appendices summarizing
- changes to all sections of the specifications they replace. Appendix
- A.1 of this document details changes made to RFC 3377. Appendix A.2
- of this document details changes made to Section 3.3 of RFC 2251.
-
- Additionally, portions of this technical specification update and/or
-
-
-
-Zeilenga LDAP: TS Road Map [Page 3]
-
-INTERNET-DRAFT draft-ietf-ldapbis-roadmap-07 10 February 2005
-
-
- replace a number of other documents not listed above. These
- relationships are discussed in the documents detailings these portions
- of this technical specification.
-
-
-5. Acknowledgments
-
- This document is based largely on RFC 3377 by J. Hodges and R.
- Morgan, a product of the LDAPBIS and LDAPEXT Working Groups. The
- document also borrows from RFC 2251 by M. Wahl, T. Howes, and S.
- Kille, a product of the ASID Working Group.
-
- This document is a product of the IETF LDAPBIS Working Group.
-
-
-6. Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- Email: Kurt@OpenLDAP.org
-
-
-7. References
-
- [[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn where
- possible.]]
-
-
-7.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
- [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
- draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
-
- [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
- draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
-
- [Models] Zeilenga, K. (editor), "LDAP: Directory Information
- Models", draft-ietf-ldapbis-models-xx.txt, a work in
- progress.
-
- [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
- Connection Level Security Mechanisms",
- draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
-
-
-
-Zeilenga LDAP: TS Road Map [Page 4]
-
-INTERNET-DRAFT draft-ietf-ldapbis-roadmap-07 10 February 2005
-
-
- [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
- Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
- work in progress.
-
- [Filters] Smith, M. (editor), LDAPbis WG, "LDAP: String
- Representation of Search Filters",
- draft-ietf-ldapbis-filter-xx.txt, a work in progress.
-
- [LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
- draft-ietf-ldapbis-url-xx.txt, a work in progress.
-
- [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
- draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
-
- [LDAPprep] Zeilenga, K., "LDAP: Internationalized String
- Preparation", draft-ietf-ldapbis-strprep-xx.txt, a work
- in progress.
-
- [Schema] Dally, K. (editor), "LDAP: User Schema",
- draft-ietf-ldapbis-user-schema-xx.txt, a work in
- progress.
-
- [X.500] International Telecommunication Union -
- Telecommunication Standardization Sector, "The Directory
- -- Overview of concepts, models and services,"
- X.500(1993) (also ISO/IEC 9594-1:1994).
-
- [X.501] International Telecommunication Union -
- Telecommunication Standardization Sector, "The Directory
- -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
-
- [X.511] International Telecommunication Union -
- Telecommunication Standardization Sector, "The
- Directory: Abstract Service Definition", X.511(1993)
- (also ISO/IEC 9594-3:1993).
-
-
-7.2. Informative References
-
- None.
-
-
-Appendix A. Changes to Previous Documents
-
- This appendix outlines changes this document makes relative to the
- documents it replaces (in whole or in part).
-
-
-
-
-
-Zeilenga LDAP: TS Road Map [Page 5]
-
-INTERNET-DRAFT draft-ietf-ldapbis-roadmap-07 10 February 2005
-
-
-Appendix A.1. Changes to RFC 3377
-
- This document is nearly a complete rewrite of RFC 3377 as much of the
- material of RFC 3377 is no longer applicable. The changes include
- redefining the terms "LDAP" and "LDAPv3" to refer to this revision of
- the technical specification.
-
-
-Appendix A.2. Changes to Section 3.3 of RFC 2251
-
- The section was modified slightly (the word "document" was replaced
- with "technical specification") to clarify that it applies to the
- entire LDAP technical specification.
-
-
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be found
- in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this specification
- can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-Full Copyright
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-
-
-Zeilenga LDAP: TS Road Map [Page 6]
-
-INTERNET-DRAFT draft-ietf-ldapbis-roadmap-07 10 February 2005
-
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga LDAP: TS Road Map [Page 7]
-
-
-
diff --git a/doc/drafts/draft-ietf-ldapbis-strprep-xx.txt b/doc/drafts/draft-ietf-ldapbis-strprep-xx.txt
deleted file mode 100644
index 7759473caec95502579bce4f92e983e374194e82..0000000000000000000000000000000000000000
--- a/doc/drafts/draft-ietf-ldapbis-strprep-xx.txt
+++ /dev/null
@@ -1,787 +0,0 @@
-
-
-
-
-
-
-Internet-Draft Kurt D. Zeilenga
-Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 23 January 2006
-
-
-
- LDAP: Internationalized String Preparation
- <draft-ietf-ldapbis-strprep-07.txt>
-
-
-
-Status of this Memo
-
- This document is intended to be published as a Standard Track RFC.
- Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDAP Revision Working Group
- mailing list <ietf-ldapbis@openldap.org>. Please send editorial
- comments directly to the editor <Kurt@OpenLDAP.org>.
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware have
- been or will be disclosed, and any of which he or she becomes aware
- will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference material
- or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
- Copyright (C) The Internet Society (2006). All Rights Reserved.
-
- Please see the Full Copyright section near the end of this document
- for more information.
-
-
-
-
-
-
-
-Zeilenga LDAPprep [Page 1]
-
-Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
-
-
-Abstract
-
- The previous Lightweight Directory Access Protocol (LDAP) technical
- specifications did not precisely define how character string matching
- is to be performed. This led to a number of usability and
- interoperability problems. This document defines string preparation
- algorithms for character-based matching rules defined for use in LDAP.
-
-
-Conventions and Terms
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119].
-
- Character names in this document use the notation for code points and
- names from the Unicode Standard [Unicode]. For example, the letter
- "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
- In the lists of mappings and the prohibited characters, the "U+" is
- left off to make the lists easier to read. The comments for character
- ranges are shown in square brackets (such as "[CONTROL CHARACTERS]")
- and do not come from the standard.
-
- Note: a glossary of terms used in Unicode can be found in [Glossary].
- Information on the Unicode character encoding model can be found in
- [CharModel].
-
- The term "combining mark", as used in this specification, refers to
- any Unicode [Unicode] code point which has a mark property (Mn, Mc,
- Me). Appendix A provides a definitive list of combining marks.
-
-
-1. Introduction
-
-1.1. Background
-
- A Lightweight Directory Access Protocol (LDAP) [Roadmap] matching rule
- [Syntaxes] defines an algorithm for determining whether a presented
- value matches an attribute value in accordance with the criteria
- defined for the rule. The proposition may be evaluated to True,
- False, or Undefined.
-
- True - the attribute contains a matching value,
-
- False - the attribute contains no matching value,
-
- Undefined - it cannot be determined whether the attribute contains
- a matching value or not.
-
-
-
-Zeilenga LDAPprep [Page 2]
-
-Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
-
-
- For instance, the caseIgnoreMatch matching rule may be used to compare
- whether the commonName attribute contains a particular value without
- regard for case and insignificant spaces.
-
-
-1.2. X.500 String Matching Rules
-
- "X.520: Selected attribute types" [X.520] provides (amongst other
- things) value syntaxes and matching rules for comparing values
- commonly used in the Directory. These specifications are inadequate
- for strings composed of Unicode [Unicode] characters.
-
- The caseIgnoreMatch matching rule [X.520], for example, is simply
- defined as being a case insensitive comparison where insignificant
- spaces are ignored. For printableString, there is only one space
- character and case mapping is bijective, hence this definition is
- sufficient. However, for Unicode string types such as
- universalString, this is not sufficient. For example, a case
- insensitive matching implementation which folded lower case characters
- to upper case would yield different different results than an
- implementation which used upper case to lower case folding. Or one
- implementation may view space as referring to only SPACE (U+0020), a
- second implementation may view any character with the space separator
- (Zs) property as a space, and another implementation may view any
- character with the whitespace (WS) category as a space.
-
- The lack of precise specification for character string matching has
- led to significant interoperability problems. When used in
- certificate chain validation, security vulnerabilities can arise. To
- address these problems, this document defines precise algorithms for
- preparing character strings for matching.
-
-
-1.3. Relationship to "stringprep"
-
- The character string preparation algorithms described in this document
- are based upon the "stringprep" approach [RFC3454]. In "stringprep",
- presented and stored values are first prepared for comparison and so
- that a character-by-character comparison yields the "correct" result.
-
- The approach used here is a refinement of the "stringprep" [RFC3454]
- approach. Each algorithm involves two additional preparation steps.
-
- a) prior to applying the Unicode string preparation steps outlined in
- "stringprep", the string is transcoded to Unicode;
-
- b) after applying the Unicode string preparation steps outlined in
- "stringprep", the string is modified to appropriately handle
-
-
-
-Zeilenga LDAPprep [Page 3]
-
-Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
-
-
- characters insignificant to the matching rule.
-
- Hence, preparation of character strings for X.500 matching involves
- the following steps:
-
- 1) Transcode
- 2) Map
- 3) Normalize
- 4) Prohibit
- 5) Check Bidi (Bidirectional)
- 6) Insignificant Character Handling
-
- These steps are described in Section 2.
-
- It is noted that while various tables of Unicode characters included
- or referenced by this specification are derived from Unicode [UNICODE]
- data, these tables are to be considered definitive for the purpose of
- implementing this specification.
-
-
-1.4. Relationship to the LDAP Technical Specification
-
- This document is a integral part of the LDAP technical specification
- [Roadmap] which obsoletes the previously defined LDAP technical
- specification [RFC3377] in its entirety.
-
- This document details new LDAP internationalized character string
- preparation algorithms used by [Syntaxes] and possible other technical
- specifications defining LDAP syntaxes and/or matching rules.
-
-
-1.5. Relationship to X.500
-
- LDAP is defined [Roadmap] in X.500 terms as an X.500 access mechanism.
- As such, there is a strong desire for alignment between LDAP and X.500
- syntax and semantics. The character string preparation algorithms
- described in this document are based upon "Internationalized String
- Matching Rules for X.500" [XMATCH] proposal to ITU/ISO Joint Study
- Group 2.
-
-
-2. String Preparation
-
- The following six-step process SHALL be applied to each presented and
- attribute value in preparation for character string matching rule
- evaluation.
-
- 1) Transcode
-
-
-
-Zeilenga LDAPprep [Page 4]
-
-Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
-
-
- 2) Map
- 3) Normalize
- 4) Prohibit
- 5) Check bidi
- 6) Insignificant Character Handling
-
- Failure in any step causes the assertion to evaluate to Undefined.
-
- The character repertoire of this process is Unicode 3.2 [Unicode].
-
- Note that this six-step process specification is intended to described
- expected matching behavior. Implementations are free use alternative
- processes so long as the matching rule evaluation behavior provided is
- consistent with the behavior described by this specification.
-
-
-2.1. Transcode
-
- Each non-Unicode string value is transcoded to Unicode.
-
- PrintableString [X.680] value are transcoded directly to Unicode.
-
- UniversalString, UTF8String, and bmpString [X.680] values need not be
- transcoded as they are Unicode-based strings (in the case of
- bmpString, a subset of Unicode).
-
- TeletexString [X.680] values are transcoded to Unicode. As there is
- no standard for mapping TeletexString values to Unicode, the mapping
- is left a local matter.
-
- For these and other reasons, use of TeletexString is NOT RECOMMENDED.
-
- The output is the transcoded string.
-
-
-2.2. Map
-
- SOFT HYPHEN (U+00AD) and MONGOLIAN TODO SOFT HYPHEN (U+1806) code
- points are mapped to nothing. COMBINING GRAPHEME JOINER (U+034F) and
- VARIATION SELECTORs (U+180B-180D, FF00-FE0F) code points are also
- mapped to nothing. The OBJECT REPLACEMENT CHARACTER (U+FFFC) is
- mapped to nothing.
-
- CHARACTER TABULATION (U+0009), LINE FEED (LF) (U+000A), LINE
- TABULATION (U+000B), FORM FEED (FF) (U+000C), CARRIAGE RETURN (CR)
- (U+000D), and NEXT LINE (NEL) (U+0085) are mapped to SPACE (U+0020).
-
- All other control code (e.g., Cc) points or code points with a control
-
-
-
-Zeilenga LDAPprep [Page 5]
-
-Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
-
-
- function (e.g., Cf) are mapped to nothing. The following is a
- complete list of these code points: U+0000-0008, 000E-001F, 007F-0084,
- 0086-009F, 06DD, 070F, 180E, 200C-200F, 202A-202E, 2060-2063,
- 206A-206F, FEFF, FFF9-FFFB, 1D173-1D17A, E0001, E0020-E007F.
-
- ZERO WIDTH SPACE (U+200B) is mapped to nothing. All other code points
- with Separator (space, line, or paragraph) property (e.g, Zs, Zl, or
- Zp) are mapped to SPACE (U+0020). The following is a complete list of
- these code points: U+0020, 00A0, 1680, 2000-200A, 2028-2029, 202F,
- 205F, 3000.
-
- For case ignore, numeric, and stored prefix string matching rules,
- characters are case folded per B.2 of [RFC3454].
-
- The output is the mapped string.
-
-
-2.3. Normalize
-
- The input string is be normalized to Unicode Form KC (compatibility
- composed) as described in [UAX15]. The output is the normalized
- string.
-
-
-2.4. Prohibit
-
- All Unassigned code points are prohibited. Unassigned code points are
- listed in Table A.1 of [RFC3454].
-
- Characters which, per Section 5.8 of [Stringprep], change display
- properties or are deprecated are prohibited. These characters are are
- listed in Table C.8 of [RFC3454].
-
- Private Use code points are prohibited. These characters are listed
- in Table C.3 of [RFC3454].
-
- All non-character code points are prohibited. These code points are
- listed in Table C.4 of [RFC3454].
-
- Surrogate codes are prohibited. These characters are listed in Table
- C.5 of [RFC3454].
-
- The REPLACEMENT CHARACTER (U+FFFD) code point is prohibited.
-
- The step fails if the input string contains any prohibited code point.
- Otherwise, the output is the input string.
-
-
-
-
-
-Zeilenga LDAPprep [Page 6]
-
-Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
-
-
-2.5. Check bidi
-
- Bidirectional characters are ignored.
-
-
-2.6. Insignificant Character Handling
-
- In this step, the string is modified to ensure proper handling of
- characters insignificant to the matching rule. This modification
- differs from matching rule to matching rule.
-
- Section 2.6.1 applies to case ignore and exact string matching.
- Section 2.6.2 applies to numericString matching.
- Section 2.6.3 applies to telephoneNumber matching.
-
-
-2.6.1. Insignificant Space Handling
-
- For the purposes of this section, a space is defined to be the SPACE
- (U+0020) code point followed by no combining marks.
-
- NOTE - The previous steps ensure that the string cannot contain any
- code points in the separator class, other than SPACE (U+0020).
-
- If the input string contains at least one non-space character, then
- the string is modified such that the string starts with exactly one
- space character, ends with exactly one SPACE character, and that any
- inner (non-empty) sequence of space characters is replaced with
- exactly two SPACE characters. For instance, the input strings
- "foo<SPACE>bar<SPACE><SPACE>", results in the output
- "<SPACE>foo<SPACE><SPACE>bar<SPACE>".
-
- Otherwise, if the string being prepared is an initial, any, or final
- substring, then the output string is exactly one SPACE character, else
- the output string is exactly two SPACEs.
-
- Appendix B discusses the rationale for the behavior.
-
-
-2.6.2. numericString Insignificant Character Handling
-
- For the purposes of this section, a space is defined to be the SPACE
- (U+0020) code point followed by no combining marks.
-
- All spaces are regarded as insignificant and are to be removed.
-
- For example, removal of spaces from the Form KC string:
- "<SPACE><SPACE>123<SPACE><SPACE>456<SPACE><SPACE>"
-
-
-
-Zeilenga LDAPprep [Page 7]
-
-Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
-
-
- would result in the output string:
- "123456"
- and the Form KC string:
- "<SPACE><SPACE><SPACE>"
- would result in the output string:
- "" (an empty string).
-
-
-2.6.3. telephoneNumber Insignificant Character Handling
-
- For the purposes of this section, a hyphen is defined to be
- HYPHEN-MINUS (U+002D), ARMENIAN HYPHEN (U+058A), HYPHEN (U+2010),
- NON-BREAKING HYPHEN (U+2011), MINUS SIGN (U+2212), SMALL HYPHEN-MINUS
- (U+FE63), or FULLWIDTH HYPHEN-MINUS (U+FF0D) code point followed by no
- combining marks and a space is defined to be the SPACE (U+0020) code
- point followed by no combining marks.
-
- All hyphens and spaces are considered insignificant and are to be
- removed.
-
- For example, removal of hyphens and spaces from the Form KC string:
- "<SPACE><HYPHEN>123<SPACE><SPACE>456<SPACE><HYPHEN>"
- would result in the output string:
- "123456"
- and the Form KC string:
- "<HYPHEN><HYPHEN><HYPHEN>"
- would result in the (empty) output string:
- "".
-
-
-3. Security Considerations
-
- "Preparation for International Strings ('stringprep')" [RFC3454]
- security considerations generally apply to the algorithms described
- here.
-
-
-4. Acknowledgments
-
- The approach used in this document is based upon design principles and
- algorithms described in "Preparation of Internationalized Strings
- ('stringprep')" [RFC3454] by Paul Hoffman and Marc Blanchet. Some
- additional guidance was drawn from Unicode Technical Standards,
- Technical Reports, and Notes.
-
- This document is a product of the IETF LDAP Revision (LDAPBIS) Working
- Group.
-
-
-
-
-Zeilenga LDAPprep [Page 8]
-
-Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
-
-
-5. Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- Email: Kurt@OpenLDAP.org
-
-
-6. References
-
- [[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn where
- possible.]]
-
-
-6.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
- [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
- Internationalized Strings ('stringprep')", RFC 3454,
- December 2002.
-
- [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
- Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
- progress.
-
- [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
- draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
-
- [Unicode] The Unicode Consortium, "The Unicode Standard, Version
- 3.2.0" is defined by "The Unicode Standard, Version 3.0"
- (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
- as amended by the "Unicode Standard Annex #27: Unicode
- 3.1" (http://www.unicode.org/reports/tr27/) and by the
- "Unicode Standard Annex #28: Unicode 3.2"
- (http://www.unicode.org/reports/tr28/).
-
- [UAX15] Davis, M. and M. Duerst, "Unicode Standard Annex #15:
- Unicode Normalization Forms, Version 3.2.0".
- <http://www.unicode.org/unicode/reports/tr15/tr15-22.html>,
- March 2002.
-
- [X.680] International Telecommunication Union -
- Telecommunication Standardization Sector, "Abstract
- Syntax Notation One (ASN.1) - Specification of Basic
- Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
-
-
-
-Zeilenga LDAPprep [Page 9]
-
-Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
-
-
-6.2. Informative References
-
- [X.500] International Telecommunication Union -
- Telecommunication Standardization Sector, "The Directory
- -- Overview of concepts, models and services,"
- X.500(1993) (also ISO/IEC 9594-1:1994).
-
- [X.501] International Telecommunication Union -
- Telecommunication Standardization Sector, "The Directory
- -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
-
- [X.520] International Telecommunication Union -
- Telecommunication Standardization Sector, "The
- Directory: Selected Attribute Types", X.520(1993) (also
- ISO/IEC 9594-6:1994).
-
- [Glossary] The Unicode Consortium, "Unicode Glossary",
- <http://www.unicode.org/glossary/>.
-
- [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report
- #17, Character Encoding Model", UTR17,
- <http://www.unicode.org/unicode/reports/tr17/>, August
- 2000.
-
- [Filters] Smith, M. (editor), LDAPbis WG, "LDAP: String
- Representation of Search Filters",
- draft-ietf-ldapbis-filter-xx.txt, a work in progress.
-
- [XMATCH] Zeilenga, K., "Internationalized String Matching Rules
- for X.500", draft-zeilenga-ldapbis-strmatch-xx.txt, a
- work in progress.
-
-
-Appendix A. Combining Marks
-
- This appendix is normative.
-
- This table was derived from Unicode [Unicode] data
- files, it lists all code points with the Mn, Mc, or Me
- properties. This table is to be considered definitive
- for the purposes of implementation of this
- specification.
-
-
- 0300-034F 0360-036F 0483-0486 0488-0489 0591-05A1
- 05A3-05B9 05BB-05BC 05BF 05C1-05C2 05C4 064B-0655 0670
- 06D6-06DC 06DE-06E4 06E7-06E8 06EA-06ED 0711 0730-074A
- 07A6-07B0 0901-0903 093C 093E-094F 0951-0954 0962-0963
-
-
-
-Zeilenga LDAPprep [Page 10]
-
-Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
-
-
- 0981-0983 09BC 09BE-09C4 09C7-09C8 09CB-09CD 09D7
- 09E2-09E3 0A02 0A3C 0A3E-0A42 0A47-0A48 0A4B-0A4D
- 0A70-0A71 0A81-0A83 0ABC 0ABE-0AC5 0AC7-0AC9 0ACB-0ACD
- 0B01-0B03 0B3C 0B3E-0B43 0B47-0B48 0B4B-0B4D 0B56-0B57
- 0B82 0BBE-0BC2 0BC6-0BC8 0BCA-0BCD 0BD7 0C01-0C03
- 0C3E-0C44 0C46-0C48 0C4A-0C4D 0C55-0C56 0C82-0C83
- 0CBE-0CC4 0CC6-0CC8 0CCA-0CCD 0CD5-0CD6 0D02-0D03
- 0D3E-0D43 0D46-0D48 0D4A-0D4D 0D57 0D82-0D83 0DCA
- 0DCF-0DD4 0DD6 0DD8-0DDF 0DF2-0DF3 0E31 0E34-0E3A
- 0E47-0E4E 0EB1 0EB4-0EB9 0EBB-0EBC 0EC8-0ECD 0F18-0F19
- 0F35 0F37 0F39 0F3E-0F3F 0F71-0F84 0F86-0F87 0F90-0F97
- 0F99-0FBC 0FC6 102C-1032 1036-1039 1056-1059 1712-1714
- 1732-1734 1752-1753 1772-1773 17B4-17D3 180B-180D 18A9
- 20D0-20EA 302A-302F 3099-309A FB1E FE00-FE0F FE20-FE23
- 1D165-1D169 1D16D-1D172 1D17B-1D182 1D185-1D18B
- 1D1AA-1D1AD
-
-
-
-Appendix B. Substrings Matching
-
- This appendix is non-normative.
-
- In absence of substrings matching, the insignificant
- space handling for case ignore/exact matching could be
- simplified. Specifically, the handling could be as
- require all sequences of one or more spaces be replaced
- with one space and, if string contains non-space
- characters, removal of all all leading spaces and
- trailing spaces.
-
- In the presence of substrings matching, this simplified
- space handling would lead to unexpected and undesirable
- matching behavior. For instance:
- 1) (CN=foo\20*\20bar) would match the CN value "foobar" but not
- "foo<SPACE>bar" nor "foo<SPACE><SPACE>bar";
- 2) (CN=*\20foobar\20*) would match "foobar", but (CN=*\20*foobar*\20*)
- would not;
- 3) (CN=foo\20*\20bar) would match "foo<SPACE>X<SPACE>bar" but not
- "foo<SPACE><SPACE>bar".
-
- Note to readers not familiar with LDAP substrings matching: the LDAP
- filter [Filters] assertion (CN=A*B*C) says "match any value (of the
- attribute CN) which begins with A, contains B after A, ends with C
- where C is also after B."
-
- The first case illustrates that this simplified space handling would
- cause leading and trailing spaces in substrings of the string to be
-
-
-
-Zeilenga LDAPprep [Page 11]
-
-Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
-
-
- regarded as insignificant. However, only leading and trailing (as
- well as multiple consecutive spaces) of the string (as a whole) are
- insignificant.
-
- The second case illustrates that this simplified space handling would
- cause sub-partitioning failures. That is, if a prepared any substring
- matches a partition of the attribute value, then an assertion
- constructed by subdividing that substring into multiple substrings
- should also match.
-
- The third case illustrates that this simplified space handling causes
- another partitioning failure. Though both the initial or final
- strings match different portions of "foo<SPACE>X<SPACE>bar" with
- neither matching the X portion, they don't match a string consisting
- of the two matched portions less the unmatched X portion.
-
- In designing an appropriate approach for space handling for substrings
- matching, one must study key aspects of X.500 case exact/ignore
- matching. X.520 [X.520] says:
- The [substrings] rule returns TRUE if there is a partitioning of
- the attribute value (into portions) such that:
- - the specified substrings (initial, any, final) match different
- portions of the value in the order of the strings sequence;
- - initial, if present, matches the first portion of the value;
- - final, if present, matches the last portion of the value;
- - any, if present, matches some arbitrary portion of the value.
-
- That is, the substrings assertion (CN=foo\20*\20bar) matches the
- attribute value "foo<SPACE><SPACE>bar" as the value can be partitioned
- into the portions "foo<SPACE>" and "<SPACE>bar" meeting the above
- requirements.
-
- X.520 also says:
- [T]he following spaces are regarded as not significant:
- - leading spaces (i.e. those preceding the first character that is
- not a space);
- - trailing spaces (i.e. those following the last character that is
- not a space);
- - multiple consecutive spaces (these are taken as equivalent to a
- single space character).
-
- This statement applies to the assertion values and attribute values
- as whole strings, and not individually to substrings of an assertion
- value. In particular, the statements should be taken to mean that
- if an assertion value and attribute value match without any
- consideration to insignificant characters, then that assertion value
- should also match any attribute value which differs only by inclusion
- or removal of insignificant characters.
-
-
-
-Zeilenga LDAPprep [Page 12]
-
-Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
-
-
- Hence, the assertion (CN=foo\20*\20bar) matches
- "foo<SPACE><SPACE><SPACE>bar" and "foo<SPACE>bar" as these values
- only differ from "foo<SPACE><SPACE>bar" by the inclusion or removal
- of insignificant spaces.
-
- Astute readers of this text will also note that there are special
- cases where the specified space handling does not ignore spaces
- which could be considered insignificant. For instance, the assertion
- (CN=\20*\20*\20) does not match "<SPACE><SPACE><SPACE>"
- (insignificant spaces present in value) nor " " (insignificant
- spaces not present in value). However, as these cases have no
- practical application that cannot be met by simple assertions, e.g.
- (cn=\20), and this minor anomaly can only be fully addressed by a
- preparation algorithm to be used in conjunction with
- character-by-character partitioning and matching, the anomaly is
- considered acceptable.
-
-
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed
- to pertain to the implementation or use of the technology described
- in this document or the extent to which any license under such
- rights might or might not be available; nor does it represent that
- it has made any independent effort to identify any such rights.
- Information on the procedures with respect to rights in RFC documents
- can be found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use
- of such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository
- at http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-Full Copyright
-
- Copyright (C) The Internet Society (2006).
-
-
-
-Zeilenga LDAPprep [Page 13]
-
-Internet-Draft draft-ietf-ldapbis-strprep-07 23 January 2006
-
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
- REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
- INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
- IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
- THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga LDAPprep [Page 14]
-
diff --git a/doc/drafts/draft-ietf-ldapbis-url-xx.txt b/doc/drafts/draft-ietf-ldapbis-url-xx.txt
deleted file mode 100644
index 96ace5fbd25d9d7ff48c05b314a596741c2c02ef..0000000000000000000000000000000000000000
--- a/doc/drafts/draft-ietf-ldapbis-url-xx.txt
+++ /dev/null
@@ -1,841 +0,0 @@
-
-
-
-Network Working Group Mark Smith, Editor
-Request for Comments: DRAFT Pearl Crescent, LLC
-Obsoletes: RFC 2255 Tim Howes
-Expires: 4 July 2005 Opsware, Inc.
-
- 4 January 2005
-
-
- LDAP: Uniform Resource Locator
- <draft-ietf-ldapbis-url-09.txt>
-
-
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she become
- aware will be disclosed, in accordance with RFC 3668.
-
- This document is intended to be published as a Standards Track RFC,
- replacing RFC 2255. Distribution of this memo is unlimited.
- Technical discussion of this document will take place on the IETF
- LDAP (v3) Revision (ldapbis) Working Group mailing list
- <ietf-ldapbis@openldap.org>. Please send editorial comments directly
- to the editor <mcs@pearlcrescent.com>.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as
- Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than a "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
- Please see the Full Copyright section near the end of this document
- for more information.
-
-
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 1]
-
-INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
-
-
-Abstract
-
- This document describes a format for a Lightweight Directory Access
- Protocol (LDAP) Uniform Resource Locator (URL). An LDAP URL
- describes an LDAP search operation that is used to retrieve
- information from an LDAP directory, or, in the context of an LDAP
- referral or reference, an LDAP URL describes a service where an LDAP
- operation may be progressed.
-
-Table of Contents
-
- Status of this Memo............................................1
- Abstract.......................................................2
- Table of Contents..............................................2
-1. Introduction...................................................2
-2. URL Definition.................................................3
-2.1. Percent-Encoding............................................5
-3. Defaults for Fields of the LDAP URL............................5
-4. Examples.......................................................6
-5. Security Considerations........................................8
-6. IANA Considerations............................................9
-7. Normative References...........................................9
-8. Informative References.........................................10
-9. Acknowledgements...............................................10
-10. Authors' Addresses.............................................11
-11. Appendix A: Changes Since RFC 2255.............................11
-11.1. Technical Changes...........................................11
-11.2. Editorial Changes...........................................12
-12. Appendix B: Changes Since Previous Document Revision...........14
-12.1. Technical Changes...........................................14
-12.2. Editorial Changes...........................................14
- Intellectual Property Rights...................................14
- Full Copyright.................................................15
-
-1. Introduction
-
- LDAP is the Lightweight Directory Access Protocol [Roadmap]. This
- document specifies the LDAP URL format for version 3 of LDAP and
- clarifies how LDAP URLs are resolved. This document also defines an
- extension mechanism for LDAP URLs. This mechanism may be used to
- provide access to new LDAP extensions.
-
- Note that not all of the parameters of the LDAP search operation
- described in [Protocol] can be expressed using the format defined in
- this document. Note also that URLs may be used to represent reference
- knowledge, including for non-search operations.
-
-
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 2]
-
-INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
-
-
- This document is a integral part of the LDAP technical specification
- [Roadmap] which obsoletes the previously defined LDAP technical
- specification, RFC 3377, in its entirety.
-
- This document replaces RFC 2255. See Appendix A for a list of changes
- relative to RFC 2255.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119].
-
-2. URL Definition
-
- An LDAP URL begins with the protocol prefix "ldap" and is defined by
- the following grammar, following the ABNF notation defined in
- [RFC2234].
-
- ldapurl = scheme COLON SLASH SLASH [host [COLON port]]
- [SLASH dn [QUESTION [attributes]
- [QUESTION [scope] [QUESTION [filter]
- [QUESTION extensions]]]]]
- ; <host> and <port> are defined
- ; in Sections 3.2.2 and 3.2.3
- ; of [RFC2396bis].
- ; <filter> is from Section 3 of
- ; [Filters], subject to the
- ; provisions of the
- ; "Percent-Encoding" section
- ; below.
-
- scheme = "ldap"
-
- dn = distinguishedName ; From Section 3 of [LDAPDN],
- ; subject to the provisions of
- ; the "Percent-Encoding"
- ; section below.
-
- attributes = attrdesc *(COMMA attrdesc)
- attrdesc = selector *(COMMA selector)
- selector = attributeSelector ; From Section 4.5.1 of
- ; [Protocol], subject to the
- ; provisions of the
- ; "Percent-Encoding" section
- ; below.
-
- scope = "base" / "one" / "sub"
- extensions = extension *(COMMA extension)
- extension = [EXCLAMATION] extype [EQUALS exvalue]
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 3]
-
-INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
-
-
- extype = oid ; From section 1.4 of [Models].
-
- exvalue = LDAPString ; From section 4.1.2 of
- ; [Protocol], subject to the
- ; provisions of the
- ; "Percent-Encoding" section
- ; below.
-
- EXCLAMATION = %x21 ; exclamation mark ("!")
- SLASH = %x2F ; forward slash ("/")
- COLON = %x3A ; colon (":")
- QUESTION = %x3F ; question mark ("?")
-
-
- The "ldap" prefix indicates an entry or entries accessible from the
- LDAP server running on the given hostname at the given portnumber.
- Note that the <host> may contain literal IPv6 addresses as specified
- in Section 3.2.2 of [RFC2396bis].
-
- The <dn> is an LDAP Distinguished Name using the string format
- described in [LDAPDN]. It identifies the base object of the LDAP
- search or the target of a non-search operation.
-
- The <attributes> construct is used to indicate which attributes
- should be returned from the entry or entries.
-
- The <scope> construct is used to specify the scope of the search to
- perform in the given LDAP server. The allowable scopes are "base"
- for a base object search, "one" for a one-level search, or "sub" for
- a subtree search.
-
- The <filter> is used to specify the search filter to apply to entries
- within the specified scope during the search. It has the format
- specified in [Filters].
-
- The <extensions> construct provides the LDAP URL with an
- extensibility mechanism, allowing the capabilities of the URL to be
- extended in the future. Extensions are a simple comma-separated list
- of type=value pairs, where the =value portion MAY be omitted for
- options not requiring it. Each type=value pair is a separate
- extension. These LDAP URL extensions are not necessarily related to
- any of the LDAP extension mechanisms. Extensions may be supported or
- unsupported by the client resolving the URL. An extension prefixed
- with a '!' character (ASCII 0x21) is critical. An extension not
- prefixed with a '!' character is non-critical.
-
- If an LDAP URL extension is implemented (that is, if the
- implementation understands it and is able to use it), the
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 4]
-
-INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
-
-
- implementation MUST make use of it. If an extension is not
- implemented and is marked critical, the implementation MUST NOT
- process the URL. If an extension is not implemented and it not
- marked critical, the implementation MUST ignore the extension.
-
- The extension type (<extype>) MAY be specified using the numeric OID
- <numericoid> form (e.g., 1.2.3.4) or the descriptor <descr> form
- (e.g., myLDAPURLExtension). Use of the <descr> form SHOULD be
- restricted to registered object identifier descriptive names. See
- [LDAPIANA] for registration details and usage guidelines for
- descriptive names.
-
- No LDAP URL extensions are defined in this document. Other documents
- or a future version of this document MAY define one or more
- extensions.
-
-2.1. Percent-Encoding
-
- A generated LDAP URL MUST consist only of the restricted set of
- characters included in one of the following three productions defined
- in [RFC2396bis]:
-
- <reserved>
- <unreserved>
- <pct-encoded>
-
- Implementations SHOULD accept other valid UTF-8 strings [RFC3629] as
- input. An octet MUST be encoded using the percent-encoding mechanism
- described in section 2.1 of [RFC2396bis] in any of these situations:
-
- The octet is not in the reserved set defined in section 2.2 of
- [RFC2396bis] or in the unreserved set defined in section 2.3 of
- [RFC2396bis].
-
- It is the single Reserved character '?' and occurs inside a <dn>,
- <filter>, or other element of an LDAP URL.
-
- It is a comma character ',' that occurs inside an <exvalue>.
-
- Note that before the percent-encoding mechanism is applied, the
- extensions component of the LDAP URL may contain one or more null
- (zero) bytes. No other component may.
-
-3. Defaults for Fields of the LDAP URL
-
- Some fields of the LDAP URL are optional, as described above. In the
- absence of any other specification, the following general defaults
- SHOULD be used when a field is absent. Note that other documents MAY
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 5]
-
-INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
-
-
- specify different defaulting rules; for example, section 4.1.10 of
- [Protocol] specifies a different rule for determining the correct DN
- to use when it is absent in an LDAP URL that is returned as a
- referral.
-
- <host>
- If no <host> is given, the client must have some apriori knowledge
- of an appropriate LDAP server to contact.
-
- <port>
- The default LDAP port is TCP port 389.
-
- <dn>
- If no <dn> is given, the default is the zero-length DN, "".
-
- <attributes>
- If the <attributes> part is omitted, all user attributes of the
- entry or entries should be requested (e.g., by setting the
- attributes field AttributeDescriptionList in the LDAP search
- request to a NULL list, or by using the special <alluserattrs>
- selector "*").
-
- <scope>
- If <scope> is omitted, a <scope> of "base" is assumed.
-
- <filter>
- If <filter> is omitted, a filter of "(objectClass=*)" is assumed.
-
- <extensions>
- If <extensions> is omitted, no extensions are assumed.
-
-
-4. Examples
-
- The following are some example LDAP URLs using the format defined
- above. The first example is an LDAP URL referring to the University
- of Michigan entry, available from an LDAP server of the client's
- choosing:
-
- ldap:///o=University%20of%20Michigan,c=US
-
- The next example is an LDAP URL referring to the University of
- Michigan entry in a particular ldap server:
-
- ldap://ldap1.example.net/o=University%20of%20Michigan,c=US
-
- Both of these URLs correspond to a base object search of the
- "o=University of Michigan,c=US" entry using a filter of
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 6]
-
-INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
-
-
- "(objectclass=*)", requesting all attributes.
-
- The next example is an LDAP URL referring to only the postalAddress
- attribute of the University of Michigan entry:
-
- ldap://ldap1.example.net/o=University%20of%20Michigan,
- c=US?postalAddress
-
- The corresponding LDAP search operation is the same as in the
- previous example, except that only the postalAddress attribute is
- requested.
-
- The next example is an LDAP URL referring to the set of entries found
- by querying the given LDAP server on port 6666 and doing a subtree
- search of the University of Michigan for any entry with a common name
- of "Babs Jensen", retrieving all attributes:
-
- ldap://ldap1.example.net:6666/o=University%20of%20Michigan,
- c=US??sub?(cn=Babs%20Jensen)
-
- The next example is an LDAP URL referring to all children of the c=GB
- entry:
-
- LDAP://ldap1.example.com/c=GB?objectClass?ONE
-
- The objectClass attribute is requested to be returned along with the
- entries, and the default filter of "(objectclass=*)" is used.
-
- The next example is an LDAP URL to retrieve the mail attribute for
- the LDAP entry named "o=Question?,c=US" is given below, illustrating
- the use of the percent-encoding mechanism on the reserved character
- '?'.
-
- ldap://ldap2.example.com/o=Question%3f,c=US?mail
-
- The next example (which is broken into two lines for readability)
- illustrates the interaction between the LDAP string representation of
- filters quoting mechanism and URL quoting mechanisms.
-
- ldap://ldap3.example.com/o=Babsco,c=US
- ???(four-octet=%5c00%5c00%5c00%5c04)
-
- The filter in this example uses the LDAP escaping mechanism of \ to
- encode three zero or null bytes in the value. In LDAP, the filter
- would be written as (four-octet=\00\00\00\04). Because the \
- character must be escaped in a URL, the \'s are percent-encoded as
- %5c (or %5C) in the URL encoding.
-
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 7]
-
-INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
-
-
- The next example illustrates the interaction between the LDAP string
- representation of DNs quoting mechanism and URL quoting mechanisms.
-
- ldap://ldap.example.com/o=An%20Example%5C2C%20Inc.,c=US
-
- The DN encoded in the above URL is:
-
- o=An Example\2C Inc.,c=US
-
- That is, the left-most RDN value is:
-
- An Example, Inc.
-
- The following three URLs that are equivalent, assuming that the
- defaulting rules specified in section 4 of this document are used:
-
- ldap://ldap.example.net
- ldap://ldap.example.net/
- ldap://ldap.example.net/?
-
- These three URLs all point to the root DSE on the ldap.example.net
- server.
-
-The final two examples show use of a hypothetical, experimental bind
-name extension (the value associated with the extension is an LDAP DN).
-
- ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com
- ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com
-
- The two URLs are the same, except that the second one marks the
- e-bindname extension as critical. Notice the use of the
- percent-encoding mechanism to encode the commas within the
- distinguished name value in the e-bindname extension.
-
-
-5. Security Considerations
-
- General URL security considerations discussed in [RFC2396bis] are
- relevant for LDAP URLs.
-
- The use of security mechanisms when processing LDAP URLs requires
- particular care, since clients may encounter many different servers
- via URLs, and since URLs are likely to be processed automatically,
- without user intervention. A client SHOULD have a user-configurable
- policy that controls which servers the client will establish LDAP
- sessions with using which security mechanisms, and SHOULD NOT
- establish LDAP sessions that are inconsistent with this policy. If a
- client chooses to reuse an existing LDAP session when resolving one
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 8]
-
-INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
-
-
- or more LDAP URLs, it MUST ensure that the session is compatible with
- the URL and that no security policies are violated.
-
- Sending authentication information, no matter the mechanism, may
- violate a user's privacy requirements. In the absence of specific
- policy permitting authentication information to be sent to a server,
- a client should use an anonymous LDAP session. (Note that clients
- conforming to previous LDAP URL specifications, where all LDAP
- sessions are anonymous and unprotected, are consistent with this
- specification; they simply have the default security policy.) Simply
- opening a transport connection to another server may violate some
- users' privacy requirements, so clients should provide the user with
- a way to control URL processing.
-
- Some authentication methods, in particular reusable passwords sent to
- the server, may reveal easily-abused information to the remote server
- or to eavesdroppers in transit, and should not be used in URL
- processing unless explicitly permitted by policy. Confirmation by
- the human user of the use of authentication information is
- appropriate in many circumstances. Use of strong authentication
- methods that do not reveal sensitive information is much preferred.
- If the URL represents a referral for an update operation, strong
- authentication methods SHOULD be used. Please refer to the Security
- Considerations section of [AuthMeth] for more information.
-
- The LDAP URL format allows the specification of an arbitrary LDAP
- search operation to be performed when evaluating the LDAP URL.
- Following an LDAP URL may cause unexpected results, for example, the
- retrieval of large amounts of data, the initiation of a long-lived
- search, etc. The security implications of resolving an LDAP URL are
- the same as those of resolving an LDAP search query.
-
-6. IANA Considerations
-
- This document has no actions for IANA.
-
-7. Normative References
-
-[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods",
- draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. a
- work in progress.
-
-[LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
- Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work
- in progress.
-
-[Filters] Smith, M. and Howes, T., "LDAP: String Representation of
- Search Filters", draft-ietf-ldapbis-filter-xx.txt, a work in
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 9]
-
-INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
-
-
- progress.
-
-[RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
- Requirement Levels," RFC 2119, BCP 14, March 1997.
-
-[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
- draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
-
-[RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
-
-[RFC2396bis]
- Berners-Lee, T., Fielding, R. and Masinter, L., "Uniform
- Resource Identifiers (URI): Generic Syntax",
- draft-fielding-uri-rfc2396bis-xx.txt, a work in progress.
-
-[Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road
- Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
-
-[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
- RFC 3629, November 2003.
-
-8. Informative References
-
-[LDAPIANA] Zeilenga, K., "IANA Considerations for LDAP",
- draft-ietf-ldapbis-bcp64-xx.txt, a work in progress. None.
-
-9. Acknowledgements
-
- The LDAP URL format was originally defined at the University of
- Michigan. This material is based upon work supported by the National
- Science Foundation under Grant No. NCR-9416667. The support of both
- the University of Michigan and the National Science Foundation is
- gratefully acknowledged.
-
- This document is an update to RFC 2255 by Tim Howes and Mark Smith.
- Changes included in this revised specification are based upon
- discussions among the authors, discussions within the LDAP (v3)
- Revision Working Group (ldapbis), and discussions within other IETF
- Working Groups. The contributions of individuals in these working
- groups is gratefully acknowledged. Several people in particular have
- made valuable comments on this document; RL "Bob" Morgan, Mark Wahl,
- Kurt Zeilenga, Jim Sermersheim, and Hallvard Furuseth deserve special
- thanks for their contributions.
-
-
-
-
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 10]
-
-INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
-
-
-10. Authors' Addresses
-
- Mark Smith, Editor
- Pearl Crescent, LLC
- 447 Marlpool Dr.
- Saline, MI 48176
- USA
- +1 734 944-2856
- mcs@pearlcrescent.com
-
- Tim Howes
- Opsware, Inc.
- 599 N. Mathilda Ave.
- Sunnyvale, CA 94085
- USA
- +1 408 744-7509
- howes@opsware.com
-
-11. Appendix A: Changes Since RFC 2255
-
-11.1. Technical Changes
-
- The following technical changes were made to the contents of the "URL
- Definition" section:
-
- Revised all of the ABNF to use common productions from [Models].
-
- Replaced references to [RFC2396] with a reference to [RFC2396bis]
- (this allows literal IPv6 addresses to be used inside the <host>
- portion of the URL, and a note was added to remind the reader of this
- enhancement). Referencing [RFC2396bis] required changes to the ABNF
- and text so that productions that are no longer defined by
- [RFC2396bis] are not used. For example, <hostport> is not defined by
- [RFC2396bis] so it has been replaced with host [COLON port]. Note:
- [RFC2396bis] includes new definitions for the "Reserved" and
- "Unreserved" sets of characters, and the net result is that the
- following two additional characters should be percent-encoded when
- they appear anywhere in the data used to construct an LDAP URL: "["
- and "]" (these two characters were first added to the Reserved set by
- RFC 2732).
-
- Changed the definition of <attrdesc> to refer to <attributeSelector>
- from [Protocol]. This allows use of "*" in the <attrdesc> part of
- the URL. It is believed that existing implementations of RFC 2255
- already support this.
-
- Avoided use of <prose-val> (bracketed-string) productions in the
- <dn>, <host>, <attrdesc>, and <exvalue> rules.
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 11]
-
-INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
-
-
- Changed the ABNF for <ldapurl> to group the <dn> component with the
- preceding <SLASH>.
-
- Changed the <extype> rule to be an <oid> from [Models].
-
- Changed the text about extension types so it references [LDAPIANA].
- Reordered rules to more closely follow the order the elements appear
- in the URL.
-
- "Bindname Extension": removed due to lack of known implementations.
-
-
-11.2. Editorial Changes
-
- Changed document title to include "LDAP:" prefix.
-
- IESG Note: removed note about lack of satisfactory mandatory
- authentication mechanisms.
-
- "Status of this Memo" section: updated boilerplate to match current
- I-D guidelines.
-
- "Abstract" section: separated from introductory material.
-
- "Table of Contents" and "IANA Considerations" sections: added.
-
- "Introduction" section: new section; separated from the Abstract.
- Changed the text indicate that RFC 2255 is replaced by this document
- (instead of RFC 1959). Added text to indicate that LDAP URLs are
- used for references and referrals. Fixed typo (replaced the nonsense
- phrase "to perform to retrieve" with "used to retrieve"). Added a
- note to let the reader know that not all of the parameters of the
- LDAP search operation described in [Protocol] can be expressed using
- this format.
-
- "URL Definition" section: removed second copy of <ldapurl> grammar
- and following two paragraphs (editorial error in RFC 2255). Fixed
- line break within '!' sequence. Reformatted the ABNF to improve
- readability by aligning comments and adding some blank lines.
- Replaced "residing in the LDAP server" with "accessible from the LDAP
- server" in the sentence immediately following the ABNF. Removed the
- sentence "Individual attrdesc names are as defined for
- AttributeDescription in [Protocol]." because [Protocol]'s
- <attributeSelector> is now used directly in the ABNF. Reworded last
- paragraph to clarify which characters must be percent-encoded. Added
- text to indicate that LDAP URLs are used for references and
- referrals. Added text that refers to the ABNF from RFC 2234.
- Clarified and strengthened the requirements with respect to
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 12]
-
-INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
-
-
- processing of URLs that contain implements and not implemented
- extensions (the approach now closely matches that specified in
- [Protocol] for LDAP controls).
-
- "Defaults for Fields of the LDAP URL" section: added; formed by
- moving text about defaults out of the "URL Definition" section.
- Replaced direct reference to the attribute name "*" with a reference
- to the special <alluserattrs> selector "*" defined in [Protocol].
-
- "URL Processing" section: removed.
-
- "Examples" section: Modified examples to use example.com and
- example.net hostnames. Added missing '?' to the LDAP URL example
- whose filter contains three null bytes. Removed space after one
- comma within a DN. Revised the bindname example to use e-bindname.
- Changed the name of an attribute used in one example from "int" to
- "four-octet" to avoid potential confusion. Added an example that
- demonstrates the interaction between DN escaping and URL
- percent-encoding. Added some examples to show URL equivalence with
- respect to the <dn> portion of the URL. Used uppercase in some
- examples to remind the reader that some tokens are case-insensitive.
-
- "Security Considerations" section: Added a note about connection
- reuse. Added a note about using strong authentication methods for
- updates. Added a reference to [AuthMeth]. Added note that simply
- opening a connection may violate some users' privacy requirements.
- Adopted the working group's revised LDAP terminology specification by
- replacing the word "connection" with "LDAP session" or "LDAP
- connection" as appropriate.
-
- "Acknowledgements" section: added statement about this being an
- update to RFC 2255. Added Kurt Zeilenga, Jim Sermersheim, and
- Hallvard Furuseth.
-
- "Normative References" section: renamed from "References" per new RFC
- guidelines. Changed from [1] style to [Protocol] style throughout the
- document. Added references to RFC 2234 and RFC 3629. Updated all
- RFC 1738 references to point to the appropriate sections within
- [RFC2396bis]. Updated the LDAP references to refer to LDAPBis WG
- documents. Removed the reference to the LDAP Attribute Syntaxes
- document and added references to the [AuthMeth], [LDAPIANA], and
- [Roadmap] documents.
-
- "Informative References" section: added.
-
- Header and "Authors' Addresses" sections: added "editor" next to Mark
- Smith's name. Updated affiliation and contact information.
-
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 13]
-
-INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
-
-
- Copyright: updated the year.
-
- Throughout the document: surrounded the names of all ABNF productions
- with "<" and ">" where they are used in descriptive text.
-
-
-
-12. Appendix B: Changes Since Previous Document Revision
-
- This appendix lists all changes relative to the previously published
- revision, draft-ietf-ldapbis-url-08.txt. Note that when appropriate
- these changes are also included in Appendix A, but are also included
- here for the benefit of the people who have already reviewed
- draft-ietf-ldapbis-url-08.txt. This section will be removed before
- this document is published as an RFC.
-
-12.1. Technical Changes
-
- Throughout the document: Replaced references to [RFC2396] and
- [RFC2732] with references to [RFC2396bis]. This required changes to
- the ABNF and text so that productions that are no longer defined by
- [RFC2396bis] are not used. For example, <hostport> is not defined by
- [RFC2396bis] so it has been replaced with host [COLON port]. Note:
- [RFC2396bis] includes new definitions for the "Reserved" and
- "Unreserved" sets of characters, and the net result is that the
- following two additional characters should be percent-encoded when
- they appear anywhere in the data used to construct an LDAP URL: "["
- and "]" (these two characters were first added to the Reserved set by
- RFC 2732).
-
-12.2. Editorial Changes
-
- Throughout the document: Replaced phrases like "Escaping using the %
- method" with "Percent-encoding" to be consistent with the terminology
- used in [RFC2396bis].
-
- "URL Definition" section: For consistency, replaced all occurrences
- of the phrase 'see the "Percent-Encoding" section below' with
- 'subject to the provisions of the "Percent-Encoding" section below.'
-
- Updated the copyright year to 2005.
-
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 14]
-
-INTERNET-DRAFT LDAP: Uniform Resource Locator 4 January 2005
-
-
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-Full Copyright
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-This Internet Draft expires on 4 July 2005.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 15]
-
-
diff --git a/doc/drafts/draft-zeilenga-ldap-adlist-xx.txt b/doc/drafts/draft-zeilenga-ldap-adlist-xx.txt
deleted file mode 100644
index 23e4d93330081eeec6043e12df6f15a7960fa700..0000000000000000000000000000000000000000
--- a/doc/drafts/draft-zeilenga-ldap-adlist-xx.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-INTERNET-DRAFT Kurt D. Zeilenga
-Intended Category: Informational OpenLDAP Foundation
-Expires in six months 18 July 2005
-
-
-
- Requesting Attributes by Object Class in the
- Lightweight Directory Access Protocol
- <draft-zeilenga-ldap-adlist-11.txt>
-
-
-Status of this Memo
-
- This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor as an Informational document.
- Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDAP Extensions mailing list
- <ldapext@ietf.org>. Please send editorial comments directly to the
- author <Kurt@OpenLDAP.org>.
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware have
- been or will be disclosed, and any of which he or she becomes aware
- will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference material
- or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
- Copyright (C) The Internet Society (2005). All Rights Reserved.
-
- Please see the Full Copyright section near the end of this document
- for more information.
-
-
-
-
-
-
-Zeilenga Requesting Attributes by Object Class [Page 1]
-
-INTERNET-DRAFT draft-zeilenga-ldap-adlist-11 18 July 2005
-
-
-Abstract
-
- The Lightweight Directory Access Protocol (LDAP) search operation
- provides mechanisms for clients to request all user application
- attributes, all operational attributes, and/or attributes selected by
- their description. This document extends LDAP to support a mechanism
- that LDAP clients may use to request the return of all attributes of
- an object class.
-
-
-1. Background and Intended Use
-
- In the Lightweight Directory Access Protocol (LDAP) [Roadmap], the
- search operation [Protocol] support requesting the return of a set of
- attributes. This set is determined by a list of attribute
- descriptions. Two special descriptors are defined to request all user
- attributes ("*") [Protocol] and all operational attributes ("+")
- [RFC3673]. However, there is no convenient mechanism for requesting
- pre-defined sets of attributes such as the set of attributes used to
- represent a particular class of object.
-
- This document extends LDAP to allow an object class identifier to be
- specified in attributes lists, such as in Search requests, to request
- the return all attributes belonging to an object class. The
- COMMERCIAL AT ("@", U+0040) character is used to distinguish an object
- class identifier from an attribute descriptions.
-
- For example, the attribute list of "@country" is equivalent to the
- attribute list of 'c', 'searchGuide', 'description', and
- 'objectClass'. This object class is described in [Schema].
-
- This extension is intended primarily to be used where the user is in
- direct control of the parameters of the LDAP search operation, for
- instance when entering a LDAP URL [LDAPURL] into a web browser. For
- example, <ldap:///dc=example,dc=com?@organization?base>.
-
-2. Terminology
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119].
-
- DSA stands for Directory System Agent (or server).
- DSE stands for DSA-specific Entry.
-
-
-3. Return of all Attributes of an Object Class
-
-
-
-
-Zeilenga Requesting Attributes by Object Class [Page 2]
-
-INTERNET-DRAFT draft-zeilenga-ldap-adlist-11 18 July 2005
-
-
- This extension allows object class identifiers is to be provided in
- the attributes field of the LDAP SearchRequest [Protocol] or other
- request values of the AttributeSelection data type (e.g., attributes
- field in pre/post read controls [ReadEntry]) and/or
- <attributeSelector> production (e.g., attributes of an LDAP URL
- [LDAPURL]). For each object class identified in the attributes field,
- the request is to be treated as if each attribute allowed by that
- class (by "MUST" or "MAY", directly or by "SUP"erior) [Models] was
- itself listed.
-
- This extension extends attributeSelector [Protocol] production as
- indicated by the following ABNF [ABNF]:
-
- attributeSelector /= objectclassdescription
- objectclassdescription = ATSIGN oid options
- ATSIGN = %x40 ; COMMERCIAL AT ("@" U+0040)
-
- where <oid> and <options> productions are as defined in [Models].
-
- The <oid> component of an <objectclassdescription> production
- identifies the object class by short name (descr) or object identifier
- (numericoid). If the value of the <oid> component is unrecognized or
- does not refer to an object class, the object class description is be
- treated an an unrecognized attribute description.
-
- The <options> production is included in the grammar for extensibility
- purposes. An object class description with an unrecognized or
- inappropriate option is to be treated as an unrecognized.
-
- While object class description options and attribute description
- options share the same syntax, they are not semantically related.
- This document does not define any object description option.
-
- Servers supporting this feature SHOULD publish the object identifier
- (OID) 1.3.6.1.4.1.4203.1.5.2 as a value of the 'supportedFeatures'
- [Models] attribute in the root DSE. Clients supporting this feature
- SHOULD NOT use the feature unless they have knowledge the server
- supports it.
-
-
-3. Security Considerations
-
- This extension provides a shorthand for requesting all attributes of
- an object class. As these attributes which could have been listed
- individually, introduction of this shorthand is not believed to raise
- additional security considerations.
-
- Implementors of this LDAP extension should be familiar with security
-
-
-
-Zeilenga Requesting Attributes by Object Class [Page 3]
-
-INTERNET-DRAFT draft-zeilenga-ldap-adlist-11 18 July 2005
-
-
- considerations applicable to the LDAP search operation [Protocol], as
- well as general LDAP security considerations [Roadmap].
-
-
-4. IANA Considerations
-
- Registration of the LDAP Protocol Mechanism [BCP64bis] defined in
- document is requested.
-
- Subject: Request for LDAP Protocol Mechanism Registration
- Object Identifier: 1.3.6.1.4.1.4203.1.5.2
- Description: OC AD Lists
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@openldap.org>
- Usage: Feature
- Specification: RFC XXXX
- Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
- Comments: none
-
- This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its
- IANA-assigned private enterprise allocation [PRIVATE], for use in this
- specification.
-
-
-5. Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- Email: Kurt@OpenLDAP.org
-
-
-6. References
-
- [[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn where
- possible.]]
-
-
-6.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
- [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", draft-crocker-abnf-rfc2234bis, a
- work in progress.
-
-
-
-
-Zeilenga Requesting Attributes by Object Class [Page 4]
-
-INTERNET-DRAFT draft-zeilenga-ldap-adlist-11 18 July 2005
-
-
- [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
- Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
- progress.
-
- [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
- draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
-
- [Models] Zeilenga, K. (editor), "LDAP: Directory Information
- Models", draft-ietf-ldapbis-models-xx.txt, a work in
- progress.
-
- [LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
- draft-ietf-ldapbis-url-xx.txt, a work in progress.
-
- [X.680] International Telecommunication Union -
- Telecommunication Standardization Sector, "Abstract
- Syntax Notation One (ASN.1) - Specification of Basic
- Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
-
-
-6.2. Informative References
-
- [RFC3673] Zeilenga, K., "LDAPv3: All Operational Attributes", RFC
- 3673, December 2003.
-
- [Schema] Dally, K. (editor), "LDAP: User Schema",
- draft-ietf-ldapbis-user-schema-xx.txt, a work in
- progress.
-
- [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
- draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
-
- [ReadEntry] Zeilenga, K., "LDAP Read Entry Controls",
- draft-zeilenga-ldap-readentry-xx.txt, a work in
- progress.
-
- [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
- http://www.openldap.org/foundation/oid-delegate.txt.
-
- [PRIVATE] IANA, "Private Enterprise Numbers",
- http://www.iana.org/assignments/enterprise-numbers.
-
-
-
-Full Copyright
-
- Copyright (C) The Internet Society (2005).
-
-
-
-
-Zeilenga Requesting Attributes by Object Class [Page 5]
-
-INTERNET-DRAFT draft-zeilenga-ldap-adlist-11 18 July 2005
-
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be found
- in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this specification
- can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Requesting Attributes by Object Class [Page 6]
-
diff --git a/doc/drafts/draft-zeilenga-ldap-assert-xx.txt b/doc/drafts/draft-zeilenga-ldap-assert-xx.txt
deleted file mode 100644
index a27c289023d75cff5e9bbc77791014299b5f5a46..0000000000000000000000000000000000000000
--- a/doc/drafts/draft-zeilenga-ldap-assert-xx.txt
+++ /dev/null
@@ -1,340 +0,0 @@
-
-
-
-
-
-INTERNET-DRAFT Kurt D. Zeilenga
-Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 10 February 2005
-
-
-
- The LDAP Assertion Control
- <draft-zeilenga-ldap-assert-05.txt>
-
-
-Status of this Memo
-
- This document is intended to be, after appropriate review and
- revision, submitted to the IESG for consideration as a Standard Track
- document. Distribution of this memo is unlimited. Technical
- discussion of this document will take place on the IETF LDAP
- Extensions mailing list <ldapext@ietf.org>. Please send editorial
- comments directly to the author <Kurt@OpenLDAP.org>.
-
- By submitting this Internet-Draft, I accept the provisions of Section
- 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
- applicable patent or other IPR claims of which I am aware have been
- disclosed, or will be disclosed, and any of which I become aware will
- be disclosed, in accordance with RFC 3668.
-
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference material
- or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
- Copyright (C) The Internet Society (2005). All Rights Reserved.
-
- Please see the Full Copyright section near the end of this document
- for more information.
-
-
-
-
-
-
-Zeilenga LDAP Assertion Control [Page 1]
-
-INTERNET-DRAFT draft-zeilenga-ldap-assert-05 10 February 2005
-
-
-Abstract
-
- This document defines the Lightweight Directory Access Protocol (LDAP)
- Assertion Control which allows a client to specify that a directory
- operation should only be processed if an assertion applied to the
- target entry of the operation is true. It can be used to construct
- "test and set" and "test and clear" and other conditional operations.
-
-
-1. Overview
-
- This document defines the Lightweight Directory Access Protocol (LDAP)
- [Roadmap] assertion control. The assertion control allows the client
- to specify a condition which must be true for the operation to be
- processed normally. Otherwise the operation fails. For instance, the
- control can be used with the Modify operation [Protocol] to perform
- atomic "test and set" and "test and clear" operations.
-
- The control may be attached to any update operation to support
- conditional addition, deletion, modification, and renaming of the
- target object. The asserted condition is evaluated as an integral
- part the operation.
-
- The control may also be used with the search operation. Here the
- assertion is applied to the base object of the search before searching
- for objects matching the search scope and filter.
-
- The control may also be used with the compare operation. Here it
- extends the compare operation to allow a more complex assertion.
-
-
-2. Terminology
-
- Protocol elements are described using ASN.1 [X.680] with implicit
- tags. The term "BER-encoded" means the element is to be encoded using
- the Basic Encoding Rules [X.690] under the restrictions detailed in
- Section 5.2 of [Protocol].
-
- DSA stands for Directory System Agent (or server).
- DSE stands for DSA-specific Entry.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119].
-
-
-3. The Assertion Control
-
-
-
-
-Zeilenga LDAP Assertion Control [Page 2]
-
-INTERNET-DRAFT draft-zeilenga-ldap-assert-05 10 February 2005
-
-
- The assertion control is an LDAP Control [Protocol] whose controlType
- is IANA-ASSIGNED-OID and controlValue is a BER-encoded Filter
- [Protocol, Section 4.5.1]. The criticality may be TRUE or FALSE.
- There is no corresponding response control.
-
- The control is appropriate for both LDAP interrogation and update
- operations [Protocol] including Add, Compare, Delete, Modify, ModifyDN
- (rename), and Search. It is inappropriate for Abandon, Bind nor
- Unbind, and Start TLS operations.
-
- When the control is attached to an LDAP request, the processing of the
- request is conditional on the evaluation of the Filter as applied
- against the target of the operation. If the Filter evaluates to TRUE,
- then the request is processed normally. If the Filter evaluates to
- FALSE or Undefined, then assertionFailed (IANA-ASSIGNED-CODE)
- resultCode is returned and no further processing is performed.
-
- For Add, Compare, and ModifyDN the target is indicated by the entry
- field in the request. For Modify, the target is indicated by the
- object field. For Delete, the target is indicated by the DelRequest
- type. For the Compare operation and all update operations, the
- evaluation of the assertion MUST be performed as an integral part of
- the operation. That is, the evaluation of the assertion and the
- normal processing of the operation SHALL be done as one atomic action.
-
- For search operation, the target is indicated by the baseObject field
- and the evaluation is done after "finding" but before "searching"
- [Protocol]. Hence, no entries or continuations references are
- returned if the assertion fails.
-
- Servers implementing this technical specification SHOULD publish the
- object identifier IANA-ASSIGNED-OID as a value of the
- 'supportedControl' attribute [Models] in their root DSE. A server MAY
- choose to advertise this extension only when the client is authorized
- to use it.
-
- Other documents may specify how this control applies to other LDAP
- operations. In doing so, they must state how the target entry is
- determined.
-
-
-4. Security Considerations
-
- The filter may, like other components of the request, contain
- sensitive information. When so, this information should be
- appropriately protected.
-
- As with any general assertion mechanism, the mechanism can be used to
-
-
-
-Zeilenga LDAP Assertion Control [Page 3]
-
-INTERNET-DRAFT draft-zeilenga-ldap-assert-05 10 February 2005
-
-
- determine directory content. Hence, this mechanism SHOULD be subject
- to appropriate access controls.
-
- Some assertions may be very complex, requiring significant time and
- resources to evaluate. Hence, this mechanism SHOULD be subject to
- appropriate administrative controls.
-
- Security considerations for the base operations [Protocol] extended by
- this control, as well as general LDAP security considerations
- [Roadmap], generally apply to implementation and use of this
- extension.
-
-
-5. IANA Considerations
-
-5.1. Object Identifier
-
- It is requested that IANA assign upon Standards Action an LDAP Object
- Identifier [BCP64bis] to identify the LDAP Assertion Control defined
- in this document.
-
- Subject: Request for LDAP Object Identifier Registration
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Specification: RFC XXXX
- Author/Change Controller: IESG
- Comments:
- Identifies the LDAP Assertion Control
-
-5.2 LDAP Protocol Mechanism
-
- Registration of this protocol mechanism [BCP64bis] is requested.
-
- Subject: Request for LDAP Protocol Mechanism Registration
- Object Identifier: IANA-ASSIGNED-OID
- Description: Assertion Control
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@openldap.org>
- Usage: Control
- Specification: RFC XXXX
- Author/Change Controller: IESG
- Comments: none
-
-
-5.3 LDAP Result Code
-
- Assignment of an LDAP Result Code [BCP64bis] called 'assertionFailed'
- is requested.
-
-
-
-Zeilenga LDAP Assertion Control [Page 4]
-
-INTERNET-DRAFT draft-zeilenga-ldap-assert-05 10 February 2005
-
-
- Subject: LDAP Result Code Registration
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Result Code Name: assertionFailed
- Specification: RFC XXXX
- Author/Change Controller: IESG
- Comments: none
-
-
-6. Acknowledgments
-
- The assertion control concept is attributed to Morteza Ansari.
-
-
-7. Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- Email: Kurt@OpenLDAP.org
-
-
-8. References
-
- [[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn where
- possible.]]
-
-
-8.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
- [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
- Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
- progress.
-
- [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
- draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
-
- [Models] Zeilenga, K. (editor), "LDAP: Directory Information
- Models", draft-ietf-ldapbis-models-xx.txt, a work in
- progress.
-
-
-8.2. Informative References
-
-
-
-
-Zeilenga LDAP Assertion Control [Page 5]
-
-INTERNET-DRAFT draft-zeilenga-ldap-assert-05 10 February 2005
-
-
- [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
- draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
-
-
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be found
- in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this specification
- can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-Full Copyright
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-Zeilenga LDAP Assertion Control [Page 6]
-
-
-
diff --git a/doc/drafts/draft-zeilenga-ldap-authzid-xx.txt b/doc/drafts/draft-zeilenga-ldap-authzid-xx.txt
deleted file mode 100644
index a44058762432d01cb32ef96b0a016ff07dff3134..0000000000000000000000000000000000000000
--- a/doc/drafts/draft-zeilenga-ldap-authzid-xx.txt
+++ /dev/null
@@ -1,445 +0,0 @@
-INTERNET-DRAFT Kurt D. Zeilenga
-Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 19 November 2004
-
-
-
- LDAP "Who am I?" Operation
- <draft-zeilenga-ldap-authzid-10.txt>
-
-
-Status of this Memo
-
- This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor as a Standard Track document.
- Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDAP Extensions mailing list
- <ldapext@ietf.org>. Please send editorial comments directly to the
- author <Kurt@OpenLDAP.org>.
-
- By submitting this Internet-Draft, I accept the provisions of Section
- 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
- applicable patent or other IPR claims of which I am aware have been
- disclosed, or will be disclosed, and any of which I become aware will
- be disclosed, in accordance with RFC 3668.
-
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference material
- or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
- Internet-Draft Shadow Directories can be accessed at
- <http://www.ietf.org/shadow.html>.
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
- Please see the Full Copyright section near the end of this document
- for more information.
-
-
-Abstract
-
- This specification provides a mechanism for Lightweight Directory
-
-
-
-Zeilenga LDAP "Who am I?" [Page 1]
-
-INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
-
-
- Access Protocol (LDAP) clients to obtain the authorization identity
- which the server has associated with the user or application entity.
- This mechanism is specified as an LDAP extended operation called the
- LDAP "Who am I?" operation.
-
-
-Conventions
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119].
-
-
-1. Background and Intent of Use
-
- This specification describes a Lightweight Directory Access Protocol
- (LDAP) [RFC3377] operation which clients can use to obtain the primary
- authorization identity in its primary form which the server has
- associated with the user or application entity. The operation is
- called the "Who am I?" operation.
-
- This specification is intended to replace the existing [AUTHRESP]
- mechanism which uses Bind request and response controls to request and
- return the authorization identity. Bind controls are not protected by
- the security layers established by the Bind operation which includes
- them. While it is possible to establish security layers using Start
- TLS [RFC2830] prior to the Bind operation, it is often desirable to
- use security layers established by the Bind operation. An extended
- operation sent after a Bind operation is protected by the security
- layers established by the Bind operation.
-
- There are other cases where it is desirable to request the
- authorization identity which the server associated with the client
- separately from the Bind operation. For example, the "Who am I?"
- operation can be augmented with a Proxied Authorization Control
- [PROXYAUTH] to determine the authorization identity which the server
- associates with the identity asserted in the Proxied Authorization
- Control. The "Who am I?" operation can also be used prior to the Bind
- operation.
-
- Servers often associate multiple authorization identities with the
- client and each authorization identity may be represented by multiple
- authzId [RFC2829] strings. This operation requests and returns the
- authzId the server considers to be primary. In the specification, the
- term "the authorization identity" and "the authzId" are generally to
- be read as "the primary authorization identity" and the "the primary
- authzId", respectively.
-
-
-
-
-Zeilenga LDAP "Who am I?" [Page 2]
-
-INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
-
-
-2. The "Who am I?" Operation
-
- The "Who am I?" operation is defined as an LDAP Extended Operation
- [RFC2251, Section 4.12] identified by the whoamiOID Object Identifier
- (OID). This section details the syntax of the operation's whoami
- request and response messages.
-
- whoamiOID ::= "1.3.6.1.4.1.4203.1.11.3"
-
-
-2.1. The whoami Request
-
- The whoami request is an ExtendedRequest with the requestName field
- containing the whoamiOID OID and an absent requestValue field. For
- example, a whoami request could be encoded as the sequence of octets
- (in hex):
-
- 30 1e 02 01 02 77 19 80 17 31 2e 33 2e 36 2e 31
- 2e 34 2e 31 2e 34 32 30 33 2e 31 2e 31 31 2e 33
-
-
-2.2. The whoami Response
-
- The whoami response is an ExtendedResponse where the responseName
- field is absent and the response field, if present, is empty or an
- authzId [RFC2829]. For example, a whoami response returning the
- authzId "u:xxyyz@EXAMPLE.NET" (in response to the example request)
- would be encoded as the sequence of octets (in hex):
-
- 30 21 02 01 02 78 1c 0a 01 00 04 00 04 00 8b 13
- 75 3a 78 78 79 79 7a 40 45 58 41 4d 50 4c 45 2e
- 4e 45 54
-
-
-3. Operational Semantics
-
- The "Who am I?" operation provides a mechanism, a whoami Request, for
- the client to request that the server returns the authorization
- identity it currently associates with the client and provides a
- mechanism, a whoami Response, for the server to respond to that
- request.
-
- Servers indicate their support for this extended operation by
- providing whoamiOID object identifier as a value of the
- 'supportedExtension' attribute type in their root DSE. Server SHOULD
- advertise this extension only when the client is willing and able to
- perform this operation.
-
-
-
-
-Zeilenga LDAP "Who am I?" [Page 3]
-
-INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
-
-
- If the server is willing and able to provide the authorization
- identity it associates with the client, the server SHALL return a
- whoami Response with a success resultCode. If the server is treating
- the client as an anonymous entity, the response field is present but
- empty. Otherwise the server provides the authzId [RFC2829]
- representing the authorization identity it currently associates with
- the client in the response field.
-
- If the server is unwilling or unable to provide the authorization
- identity it associates with the client, the server SHALL return a
- whoami Response with an appropriate non-success resultCode (such as
- operationsError, protocolError, confidentialityRequired,
- insufficientAccessRights, busy, unavailable, unwillingToPerform, or
- other) and an absent response field.
-
- As described in [RFC2251] and [RFC2829], an LDAP session has an
- "anonymous" association until the client has been successfully
- authenticated using the Bind operation. Clients MUST NOT invoke the
- "Who Am I?" operation while any Bind operation is in progress,
- including between two Bind requests made as part of a multi-stage Bind
- operation. Where a whoami Request is received in violation of this
- absolute prohibition, the server should return a whoami Response with
- an operationsError resultCode.
-
-
-4. Extending the "Who am I?" operation with controls
-
- Future specifications may extend the "Who am I?" operation using the
- control mechanism [RFC2251]. When extended by controls, the "Who am
- I?" operation requests and returns the authorization identity the
- server associates with the client in a particular context indicated by
- the controls.
-
-
-4.1. Proxied Authorization Control
-
- The Proxied Authorization Control [PROXYAUTH] is used by clients to
- request that the operation it is attached to operates under the
- authorization of an assumed identity. The client provides the
- identity to assume in the Proxied Authorization request control. If
- the client is authorized to assume the requested identity, the server
- executes the operation as if the requested identity had issued the
- operation.
-
- As servers often map the asserted authzId to another identity
- [RFC2829], it is desirable to request the server provide the authzId
- it associates with the assumed identity.
-
-
-
-
-Zeilenga LDAP "Who am I?" [Page 4]
-
-INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
-
-
- When a Proxied Authorization Control is be attached to the "Who Am I?"
- operation, the operation requests the return of the authzId the server
- associates with the identity asserted in the Proxied Authorization
- Control. The TBD result code is used to indicate that the server does
- not allow the client to assume the asserted identity. [[Note to RFC
- Editor: TBD is to be replaced with the name/code assigned by IANA for
- [PROXYAUTH] use.]]
-
-
-5. Security Considerations
-
- Identities associated with users may be sensitive information. When
- so, security layers [RFC2829][RFC2830] should be established to
- protect this information. This mechanism is specifically designed to
- allow security layers established by a Bind operation to protect the
- integrity and/or confidentiality of the authorization identity.
-
- Servers may place access control or other restrictions upon the use of
- this operation. As stated in Section 3, the server SHOULD advertise
- this extension when it is willing and able to perform the operation.
-
- As with any other extended operations, general LDAP security
- considerations [RFC3377] apply.
-
-
-6. IANA Considerations
-
- The OID 1.3.6.1.4.1.4203.1.11.3 is used to identify the LDAP "Who Am
- I?" extended operation. This OID was assigned [ASSIGN] by OpenLDAP
- Foundation, under its IANA-assigned private enterprise allocation
- [PRIVATE], for use in this specification.
-
- Registration of this protocol mechanism [RFC3383] is requested.
-
- Subject: Request for LDAP Protocol Mechanism Registration
- Object Identifier: 1.3.6.1.4.1.4203.1.11.3
- Description: Who am I?
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@openldap.org>
- Usage: Extended Operation
- Specification: RFC XXXX
- Author/Change Controller: IESG
- Comments: none
-
-
-7. Acknowledgment
-
- This document borrows from prior work in this area including
-
-
-
-Zeilenga LDAP "Who am I?" [Page 5]
-
-INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
-
-
- "Authentication Response Control" [AUTHRESP] by Rob Weltman, Mark
- Smith and Mark Wahl.
-
- The LDAP "Who am I?" operation takes it name from the UNIX whoami(1)
- command. The whoami(1) command displays the effective user id.
-
-
-8. Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- Email: Kurt@OpenLDAP.org
-
-
-9. References
-
- [[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn where
- possible.]]
-
-
-9.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
- [RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory
- Access Protocol (v3)", RFC 2251, December 1997.
-
- [RFC2829] Wahl, M., H. Alvestrand, and J. Hodges, RL "Bob" Morgan,
- "Authentication Methods for LDAP", RFC 2829, June 2000.
-
- [RFC2830] Hodges, J., R. Morgan, and M. Wahl, "Lightweight
- Directory Access Protocol (v3): Extension for Transport
- Layer Security", RFC 2830, May 2000.
-
- [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
- Protocol (v3): Technical Specification", RFC 3377,
- September 2002.
-
- [PROXYAUTH] Weltman, R., "LDAP Proxy Authentication Control",
- draft-weltman-ldapv3-proxy-xx.txt, a work in progress.
-
-
-9.2. Informative References
-
- [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
-
-
-
-Zeilenga LDAP "Who am I?" [Page 6]
-
-INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
-
-
- (also RFC 3383), September 2002.
-
- [AUTHRESP] Weltman, R., M. Smith and M. Wahl, "LDAP Authorization
- Identity Response and Request Controls",
- draft-weltman-ldapv3-auth-response-xx.txt, a work in
- progress.
-
- [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
- http://www.openldap.org/foundation/oid-delegate.txt.
-
- [PRIVATE] IANA, "Private Enterprise Numbers",
- http://www.iana.org/assignments/enterprise-numbers.
-
-
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be found
- in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this specification
- can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-Full Copyright
-
- Copyright (C) The Internet Society (2004). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
- This document and the information contained herein are provided on an
-
-
-
-Zeilenga LDAP "Who am I?" [Page 7]
-
-INTERNET-DRAFT draft-zeilenga-ldap-authzid-10 19 November 2004
-
-
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga LDAP "Who am I?" [Page 8]
-
diff --git a/doc/drafts/draft-zeilenga-ldap-cosine-xx.txt b/doc/drafts/draft-zeilenga-ldap-cosine-xx.txt
deleted file mode 100644
index eea421204bbb4f832a26bce4ff23047e868d79c2..0000000000000000000000000000000000000000
--- a/doc/drafts/draft-zeilenga-ldap-cosine-xx.txt
+++ /dev/null
@@ -1,1403 +0,0 @@
-
-
-
-
-
-
-INTERNET-DRAFT Editor: Kurt D. Zeilenga
-Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 23 October 2005
-Obsoletes: RFC 1274, RFC 2247
-Updates: RFC 2798
-
-
- COSINE LDAP/X.500 Schema
- <draft-zeilenga-ldap-cosine-01.txt>
-
-
-Status of this Memo
-
- This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor as a Standard Track document.
- Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDAPEXT mailing list
- <ldapext@ietf.org>. Please send editorial comments directly to the
- author <Kurt@OpenLDAP.org>.
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware have
- been or will be disclosed, and any of which he or she becomes aware
- will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference material
- or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
- Copyright (C) The Internet Society (2005). All Rights Reserved.
-
- Please see the Full Copyright section near the end of this document
- for more information.
-
-
-Abstract
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 1]
-
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
- This document provides a collection of schema elements for use with
- the Lightweight Directory Access Protocol (LDAP) from the COSINE and
- Internet X.500 pilot projects.
-
- This document obsoletes RFC 1274 and RFC 2247.
-
-
-Table of Contents
-
- Status of this Memo 1
- Abstract 2
- Table of Contents
- 1. Background and Intended Use 3
- 1.1. Relationship with Other Documents
- 1.2. Terminology and Conventions
- 2. COSINE Attribute Types 4
- 2.1. associatedDomain
- 2.2. associatedName
- 2.3. buildingName
- 2.3. co
- 2.5. documentAuthor
- 2.6. documentIdentifier
- 2.7. documentLocation
- 2.8. documentPublisher
- 2.9. documentTitle
- 2.10. documentVersion
- 2.11. drink
- 2.12. homePhone
- 2.13. homePostalAddress
- 2.14. host
- 2.16. info
- 2.17. mail
- 2.18. manager
- 2.19. mobile
- 2.20. organizationalStatus
- 2.21. pager
- 2.22. personalTitle
- 2.23. roomNumber
- 2.24. secretary
- 2.26. uniqueIdentifier
- 2.27. userClass
- 3. COSINE Object Classes 14
- 3.1. account
- 3.2. document
- 3.3. documentSeries
- 3.4. domain
- 3.5. domainRelatedObject
- 3.6. friendlyCountry
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 2]
-
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
- 3.7. rFC822LocalPart
- 3.8. room
- 3.9. simpleSecurityObject
- 4. Security Considerations 19
- 5. IANA Considerations 20
- 6. Acknowledgments 21
- 7. Editor's Address
- 8. References
- A. Changes Since RFC 1274 23
- Intellectual Property Rights 24
- Full Copyright
-
-
-1. Background and Intended Use
-
- In the late 1980s, X.500 Directory Services were standardised by the
- CCITT (Commite' Consultatif International de Telegraphique et
- Telephonique), now a part of the ITU (International Telephone Union).
- This lead to Directory Service piloting activities in the early 1990s,
- including the COSINE (Co-operation and Open Systems Interconnection in
- Europe) PARADISE Project pilot [COSINEpilot] in Europe. Motivated by
- needs large scale directory pilots, RFC 1274 was published to
- standardize directory schema and naming architecture for use in the
- COSINE and other Internet X.500 pilots [RFC1274].
-
- In the years that followed, X.500 Directory Services have evolved to
- incorporate new capabilities and even new protocols. In particular,
- the Lightweight Directory Access Protocol (LDAP) [Roadmap] was
- introduced in the early 1990s [RFC1487], with Version 3 of LDAP
- introduced in the late 1990s [RFC2251] and subsequently revised in the
- 2005 [Roadmap].
-
- While much of the material in RFC 1274 has been superceed by
- subsequently published ITU-T Recommendations and IETF RFCs, many of
- the schema elements lack standardized schema descriptions for use in
- modern X.500 and LDAP directory services despite the fact that these
- schema elements are in wide use today. As the old schema descriptions
- cannot be used without adaptation, interoperabilty issues may arise
- due to lack of standardized modern schema descriptions.
-
- This document addresses these issues by offering standardized schema
- descriptions, where needed, for widely-used COSINE schema elements.
-
-1.1. Relationship to Other Documents
-
- This document, together with [Schema] and [Syntaxes], obsoletes RFC
- 1274 in its entirety. [Schema] replaces Sections 9.3.1 (Userid) and
- Section 9.3.21 (Domain Component) of RFC 1274. [Syntaxes] replaces
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 3]
-
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
- section 9.4 (Generally useful syntaxes) of RFC 1274.
-
- This document replaces the remainder of RFC 1274. Appendix A.
- discusses changes since RFC 1274, as well as why certain schema
- elements were not brought forward in this revision of the COSINE
- schema. All elements not brought are to be regarded as Historic.
-
- This document, together with [NamingPlan] and [Schema], obsoletes RFC
- 2247 in its entirety. [Schema] replaces Section 4 (Attribute Type
- Definition) and Section 5.1 (The dcObject object class) of RFC 2247.
- This document replaces Section 5.2 (The domain object class) of RFC
- 2247. The remainder of RFC 2247 is replaced by [NamingPlan].
-
- Some of these items were described in RFC 2798 (inetOrgPerson schema).
- This document supersedes these descriptions. This document, together
- with [Schema], replaces section 9.1.3 of RFC 2798.
-
-
-1.2. Terminology and Conventions
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119].
-
- DIT stands for Directory Information Tree.
- DN stands for Distinguished Name.
- DSA stands for Directory System Agent, a server.
- DSE stands for DSA-Specific Entry.
- DUA stands for Directory User Agent, a client.
-
- These terms are discussed in [Models].
-
- Schema definitions are provided using LDAP description formats
- [Models]. Definitions provided here are formatted (line wrapped) for
- readability.
-
-
-2. COSINE Attribute Types
-
- This section details COSINE attribute types for use in LDAP.
-
-
-2.1. associatedDomain
-
- The 'associatedDomain' attribute specifies DNS domains [RFC1034] which
- are associated with an object. For example, the entry in the DIT with
- a DN <DC=example,DC=com> might have an associated domain of
- "example.com".
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 4]
-
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
- ( 0.9.2342.19200300.100.1.37 NAME 'associatedDomain'
- EQUALITY caseIgnoreIA5Match
- SUBSTR caseIgnoreIA5SubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
-
- The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax and the
- 'caseIgnoreIA5Match' and 'caseIgnoreIA5SubstringsMatch' rules are
- described in [Syntaxes].
-
- It is noted that the directory will not ensure that values of this
- attribute conform to the <domain> production [RFC1034]. It is the
- application responsibility to ensure domains it stores in this
- attribute are appropriately represented.
-
- It is also noted that applications supporting Internationalized Domain
- Names SHALL use the ToASCII method [RFC3490] to produce <label>
- components of the <domain> production.
-
-
-2.2. associatedName
-
- The 'associatedName' attribute specifies names of entries in the
- organizational DIT associated with a DNS domain [RFC1034].
-
- ( 0.9.2342.19200300.100.1.38 NAME 'associatedName'
- EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
-
- The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the
- 'distinguishedNameMatch' rule are described in [Syntaxes].
-
-
-2.3. buildingName
-
- The 'buildingName' attribute specifies names of the buildings where an
- organization or organizational unit is based. For example, "The White
- House".
-
- ( 0.9.2342.19200300.100.1.48 NAME 'buildingName'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [Syntaxes].
-
-
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 5]
-
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
-2.3. co
-
- The 'co' (Friendly Country Name) attribute specifies names of
- countries in human-readable format. For example, "Germany" and
- "Federal Republic of Germany". It is commonly used in conjunction
- with the 'c' (Country Name) [Schema] attribute (whose values are
- restricted to the two-letter codes defined in [ISO3166]).
-
- ( 0.9.2342.19200300.100.1.43 NAME 'co'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [Syntaxes].
-
-
-2.5. documentAuthor
-
- The 'documentAuthor' attribute specifies the distinguished name of
- authors (or editors) of a document. For example,
-
- ( 0.9.2342.19200300.100.1.14 NAME 'documentAuthor'
- EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
-
- The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the
- 'distinguishedNameMatch' rule are described in [Syntaxes].
-
-
-2.6. documentIdentifier
-
- The 'documentIdentifier' attribute specifies unique identifiers for a
- document. A document may be identified by more than one unique
- identifier. For example, RFC 3383 and BCP 64 are unique identifers
- which (presently) refer to the same document.
-
- ( 0.9.2342.19200300.100.1.11 NAME 'documentIdentifier'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [Syntaxes].
-
-
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 6]
-
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
-2.7. documentLocation
-
- The 'documentLocation' attribute specifies locations of the document
- original.
-
- ( 0.9.2342.19200300.100.1.15 NAME 'documentLocation'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [Syntaxes].
-
-
-2.8. documentPublisher
-
- The 'documentPublisher' attribute is the persons and/or organizations
- that published the document. Documents which are jointly published
- have one value for each publisher.
-
- ( 0.9.2342.19200300.100.1.56 NAME 'documentPublisher'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [Syntaxes].
-
-
-2.9. documentTitle
-
- The 'documentTitle' attribute specifies the titles of a document.
- Multiple values are allowed to accomadate both long and short titles,
- or other situations where a document has multiple titles. For
- example, "The Lightweight Directory Access Protocol Technical
- Specification" and "The LDAP Technical Specification".
-
- ( 0.9.2342.19200300.100.1.12 NAME 'documentTitle'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [Syntaxes].
-
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 7]
-
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
-2.10. documentVersion
-
- The 'documentVersion' attribute specifies the version information of a
- document.
-
- ( 0.9.2342.19200300.100.1.13 NAME 'documentVersion'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [Syntaxes].
-
-
-2.11. drink
-
- The 'drink' (favoriteDrink) attribute specifies favorite drinks of an
- object (or person). For instance, "cola" and "beer".
-
- ( 0.9.2342.19200300.100.1.5 NAME 'drink'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [Syntaxes].
-
-
-2.12. homePhone
-
- The 'homePhone' (Home Telephone Number) attribute specifies home
- telephone numbers (e.g., "+1 775 555 1234") associated with a person.
-
- ( 0.9.2342.19200300.100.1.20 NAME 'homePhone'
- EQUALITY telephoneNumberMatch
- SUBSTR telephoneNumberSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
-
- The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the
- 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are
- described in [Syntaxes].
-
-
-2.13. homePostalAddress
-
- The 'homePostalAddress' attribute specifies home postal addresses for
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 8]
-
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
- an object. Each value should be limited to up to 6 directory strings
- of 30 characters each. (Note: it is not intended that the directory
- service enforce these limits.)
-
-
- ( 0.9.2342.19200300.100.1.39 NAME 'homePostalAddress'
- EQUALITY caseIgnoreListMatch
- SUBSTR caseIgnoreListSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
-
- The PostalAddress (1.3.6.1.4.1.1466.115.121.1.41) syntax and the
- 'caseIgnoreListMatch' and 'caseIgnoreListSubstringsMatch' rules are
- described in [Syntaxes].
-
-
-2.14. host
-
- The 'host' attribute specifies host computers, generally by their
- primary fully-qualified domain name (e.g., my-host.example.com).
-
- ( 0.9.2342.19200300.100.1.9 NAME 'host'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [Syntaxes].
-
-
-2.16. info
-
- The 'info' attribute specifies any general information pertinent to an
- object. This information is not necessarily descriptive of the
- object.
-
- Applications should not attach specific semantics to values of this
- attribute. The 'description' attribute [Schema] is available for
- specifying descriptive information pertinent to an object.
-
- ( 0.9.2342.19200300.100.1.4 NAME 'info'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{2048} )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [Syntaxes].
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 9]
-
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
-2.17. mail
-
- The 'mail' (rfc822mailbox) attribute type holds Internet mail
- addresses in Mailbox [RFC2821] form (e.g.: user@example.com).
-
- ( 0.9.2342.19200300.100.1.3 NAME 'mail'
- EQUALITY caseIgnoreIA5Match
- SUBSTR caseIgnoreIA5SubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
-
- The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax and the
- 'caseIgnoreIA5Match' and 'caseIgnoreIA5SubstringsMatch' rules are
- described in [Syntaxes].
-
- It is noted that the directory will not ensure that values of this
- attribute conform to the <Mailbox> production [RFC2821]. It is the
- application responsibility to ensure domains it stores in this
- attribute are appropriately represented.
-
- Additionally, the directory will compare values per the matching rules
- named in the above attribute type description. As these rules differ
- from rules which normally apply to <Mailbox> comparisons, operational
- issues may arise. For example, the assertion (mail=joe@example.com)
- will match "JOE@example.com" even though the <local-parts> differ.
- Also, where a user has two <Mailbox>es which whose addresses differ
- only by case of the <local-part>, both cannot be listed as values of
- the user's mail attribute (as they are considered by the
- 'caseIgnoreIA5Match' rule to be equal).
-
- It is also noted that applications supporting internationalized domain
- names SHALL use the ToASCII method [RFC3490] to produce <sub-domain>
- components of the <Mailbox> production.
-
-
-2.18. manager
-
- The 'manager' attribute specifies managers, by distinguished name, of
- the person (or entity).
-
- ( 0.9.2342.19200300.100.1.10 NAME 'manager'
- EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
-
- The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the
- 'distinguishedNameMatch' rule are described in [Syntaxes].
-
-
-2.19. mobile
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 10]
-
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
- The 'mobile' (mobileTelephoneNumber) attribute specifies mobile
- telephone numbers (e.g., "+1 775 555 6789") associated with a person
- (or entity).
-
- ( 0.9.2342.19200300.100.1.41 NAME 'mobile'
- EQUALITY telephoneNumberMatch
- SUBSTR telephoneNumberSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
-
- The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the
- 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are
- described in [Syntaxes].
-
-
-2.20. organizationalStatus
-
- The 'organizationalStatus' attribute specifies categories by which a
- person is often referred to in an organization. Examples of usage in
- academia might include "undergraduate student", "researcher",
- "professor", "staff", etc.. Multiple values are allowed were the
- person is in multiple categories.
-
- Directory administrators and application designers SHOULD consider
- carefully the distinctions between this and the 'title' and
- 'userClass' attributes.
-
- ( 0.9.2342.19200300.100.1.45 NAME 'organizationalStatus'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [Syntaxes].
-
-
-2.21. pager
-
- The 'pager' (pagerTelephoneNumber) attribute specifies pager telephone
- numbers (e.g., "+1 775 555 5555") for an object.
-
- ( 0.9.2342.19200300.100.1.42 NAME 'pager'
- EQUALITY telephoneNumberMatch
- SUBSTR telephoneNumberSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
-
- The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the
- 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 11]
-
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
- described in [Syntaxes].
-
-
-2.22. personalTitle
-
- The 'personalTitle' attribute specifies personal titles for a person.
- Examples of personal titles are "Frau", "Dr.", "Herr", and
- "Professor".
-
- ( 0.9.2342.19200300.100.1.40 NAME 'personalTitle'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [Syntaxes].
-
-
-2.23. roomNumber
-
- The 'roomNumber' attribute specifies the room number of an object.
- During periods of renumbering or in other circumstances where a room
- has multiple valid room numbers associated with it, multiple values
- may be provided. Note that the 'cn' (commonName) attribute type
- SHOULD be used for naming room objects.
-
- ( 0.9.2342.19200300.100.1.6 NAME 'roomNumber'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [Syntaxes].
-
-
-2.24. secretary
-
- The 'secretary' attribute specifies secretaries and/or administrative
- assistants, by distinguish name, of a person.
-
- ( 0.9.2342.19200300.100.1.21 NAME 'secretary'
- EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
-
- The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the
- 'distinguishedNameMatch' rule are described in [Syntaxes].
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 12]
-
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
-2.26. uniqueIdentifier
-
- The 'uniqueIdentifier' attribute specifies a unique identifier for an
- object represented in the Directory. The domain within which the
- identifier is unique, and the exact semantics of the identifier, are
- for local definition. For a person, this might be an institution-wide
- payroll number. For an organizational unit, it might be a department
- code.
-
- ( 0.9.2342.19200300.100.1.44 NAME 'uniqueIdentifier'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [Syntaxes].
-
- Note: X.520 also describes an attribute called 'uniqueIdentifier'
- (2.5.4.45) which is called 'x500UniqueIdentifier' in LDAP
- [Schema]. The attribute detailed here ought not be confused
- with 'x500UniqueIdentifier'.
-
-
-2.27. userClass
-
- The 'userClass' attribute specifies categories of computer or
- application user. The semantics placed on this attribute are for
- local interpretation. Examples of current usage of this attribute in
- academia are "student", "staff", "faculty", etc.. Note that the
- 'organizationalStatus' attribute type is now often be preferred as it
- makes no distinction between persons as opposed to users.
-
- ( 0.9.2342.19200300.100.1.8 NAME 'userClass'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [Syntaxes].
-
-
-3. COSINE Object Classes
-
- This section details COSINE object classes for use in LDAP.
-
-
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 13]
-
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
-3.1. account
-
- The 'account' object class is used to define entries representing
- computer accounts. The 'uid' attribute SHOULD be used for naming
- entries of this object class.
-
- ( 0.9.2342.19200300.100.4.5 NAME 'account'
- SUP top STRUCTURAL
- MUST uid
- MAY ( description $ seeAlso $ l $ o $ ou $ host ) )
-
- The 'top' object class is described in [Models]. The 'description',
- 'seeAlso', 'l', 'o', 'ou', and 'uid' attribute types are described in
- [Schema]. The 'host' attribute type is described in Section 2 of this
- document.
-
- Example:
-
- dn: uid=kdz,cn=Accounts,dc=Example,dc=COM
- objectClass: account
- uid: kdz
- seeAlso: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM
-
-
-3.2. document
-
- The 'document' object class is used to define entries which represent
- documents.
-
- ( 0.9.2342.19200300.100.4.6 NAME 'document'
- SUP top STRUCTURAL
- MUST documentIdentifier
- MAY ( cn $ description $ seeAlso $ l $ o $ ou $
- documentTitle $ documentVersion $ documentAuthor $
- documentLocation $ documentPublisher ) )
-
- The 'top' object class is described in [Models]. The 'cn',
- 'description', 'seeAlso', 'l', 'o', and 'ou' attribute types are
- described in [Schema]. The 'documentIdentifier', 'documentTitle',
- 'documentVersion', 'documentAuthor', 'documentLocation', and
- 'documentPublisher' attribute types are described in Section 2 of this
- document.
-
- Example:
-
- dn: documentIdentifier=RFCXXXX,cn=RFC,dc=Example,dc=COM
- objectClass: document
- documentIdentifier: RFC XXXXX
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 14]
-
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
- documentTitle: COSINE LDAP/X.500 Schema
- documentAuthor: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM
- documentLocation: http://www.rfc-editor.org/rfc/rfcXXXX.txt
- documentPublisher: Internet Engineering Task Force
- description: A collection of schema elements for use in LDAP
- description: Obsoletes RFC 1274
- seeAlso: documentIdentifier=[Roadmap],cn=RFC,dc=Example,dc=COM
- seeAlso: documentIdentifier=RFC 1274,cn=RFC,dc=Example,dc=COM
-
-
-3.3. documentSeries
-
- The documentSeries object class is used to define an entry which
- represents a series of documents (e.g., The Request For Comments
- memos).
-
- ( 0.9.2342.19200300.100.4.9 NAME 'documentSeries'
- SUP top STRUCTURAL
- MUST cn
- MAY ( description $ l $ o $ ou $ seeAlso $
- telephonenumber ) )
-
- The 'top' object class is described in [Models]. The 'description',
- 'l', 'o', 'ou', 'seeAlso', and 'telephoneNumber' attribute types are
- described in [Schema].
-
- Example:
-
- dn: cn=RFC,dc=Example,dc=COM
- objectClass: documentSeries
- cn: Request for Comments
- cn: RFC
- description: a series of memos about the Internet
-
-
-3.4. domain
-
- The 'domain' object class is used to define entries which represent
- DNS domains for objects which are not organizations, organizational
- units, or other kinds of objects more approproiately defined using an
- object class specific to the kind of object being defined (e.g.,
- 'organization', 'organizationUnit', etc.).
-
- The 'dc' attribute should be used for naming entries of 'domain'
- object class.
-
- ( 0.9.2342.19200300.100.4.13 NAME 'domain'
- SUP top STRUCTURAL
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 15]
-
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
- MUST dc
- MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
- x121Address $ registeredAddress $ destinationIndicator $
- preferredDeliveryMethod $ telexNumber $
- teletexTerminalIdentifier $ telephoneNumber $
- internationaliSDNNumber $ facsimileTelephoneNumber $ street $
- postOfficeBox $ postalCode $ postalAddress $
- physicalDeliveryOfficeName $ st $ l $ description $ o $
- associatedName ) )
-
- The 'top' object class and the 'dc', 'userPassword', 'searchGuide
- 'seeAlso', 'businessCategory', 'x121Address', 'registeredAddress
- 'destinationIndicator', 'preferredDeliveryMethod', 'telexNumber',
- 'teletexTerminalIdentifier', 'telephoneNumber',
- 'internationaliSDNNumber', 'facsimileTelephoneNumber', 'street',
- 'postOfficeBox', 'postalCode', 'postalAddress',
- 'physicalDeliveryOfficeName', 'st', 'l', 'description', 'o', types are
- described in [Schema]. The 'associatedName' attribute type is
- described in Section 2 of this document.
-
- Example:
- dn: dc=com
- objectClass: domain
- dc: com
- description: the .COM TLD
-
-
-3.5. domainRelatedObject
-
- The 'domainRelatedObject' object class is used to define entries which
- represent DNS domains which are "equivalent" to an X.500 domain: e.g.,
- an organization or organizational unit.
-
- ( 0.9.2342.19200300.100.4.17 NAME 'domainRelatedObject'
- SUP top AUXILIARY
- MUST associatedDomain )
-
- The 'top' object class is described in [Models]. The
- 'associatedDomain' attribute type is described in Section 2 of this
- document.
-
- Example:
-
- dn: dc=example,dc=com
- objectClass: organization
- objectClass: dcObject
- objectClass: domainRelatedObject
- dc: example
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 16]
-
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
- associatedDomain: example.com
- o: Example Organization
-
- The 'organization' and 'dcObject' object classes and the 'dc' and 'o'
- attribute types are described in [Schema].
-
-
-3.5. friendlyCountry
-
- The 'friendlyCountry' object class is used to define entries
- representing countries in the DIT. The object class is used to allow
- friendlier naming of countries than that allowed by the object class
- 'country' [Schema].
-
- ( 0.9.2342.19200300.100.4.18 NAME 'friendlyCountry'
- SUP country STRUCTURAL
- MUST co )
-
- The 'country' object class is described in [Schema]. The 'co'
- attribute type is described in Section 2 of this document.
-
- Example:
-
- dn: c=DE
- objectClass: country
- objectClass: friendlyCountry
- c: DE
- co: Deutschland
- co: Germany
- co: Federal Republic of Germany
- co: FRG
-
- The 'c' attribute type is described in [Schema].
-
-
-3.6. rFC822LocalPart
-
- The 'rFC822LocalPart' object class is used to define entries which
- represent the local part of Internet mail addresses [RFC2822]. This
- treats the local part of the address as a 'domain' object.
-
- ( 0.9.2342.19200300.100.4.14 NAME 'rFC822localPart'
- SUP domain STRUCTURAL
- MAY ( cn $ description $ destinationIndicator $
- facsimileTelephoneNumber $ internationaliSDNNumber $
- physicalDeliveryOfficeName $ postalAddress $ postalCode $
- postOfficeBox $ preferredDeliveryMethod $ registeredAddress $
- seeAlso $ sn $ street $ telephoneNumber $
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 17]
-
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
- teletexTerminalIdentifier $ telexNumber $ x121Address ) )
-
- The 'domain' object class is described in Section 3.4 of this
- document. The 'cn', 'description', 'destinationIndicator',
- 'facsimileTelephoneNumber', 'internationaliSDNNumber,
- 'physicalDeliveryOfficeName', 'postalAddress', 'postalCode',
- 'postOfficeBox', 'preferredDeliveryMethod', 'registeredAddress',
- 'seeAlso', 'sn, 'street', 'telephoneNumber',
- 'teletexTerminalIdentifier', 'telexNumber' and 'x121Address' attribute
- types are described in [Schema].
-
-
- Example:
-
- dn: dc=kdz,dc=example,dc=com
- objectClass: domain
- objectClass: rFC822LocalPart
- dc: kdz
- associatedName: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM
-
- The 'dc' attribute type is described in [Schema].
-
-
-3.7. room
-
- The 'room' object class is used to define entries representing rooms.
- The 'cn' (commonName) attribute SHOULD be used for naming entries of
- this object class.
-
- ( 0.9.2342.19200300.100.4.7 NAME 'room'
- SUP top STRUCTURAL
- MUST cn
- MAY ( roomNumber $ description $ seeAlso $ telephoneNumber ) )
-
- The 'top' object class is described in [Models]. The 'cn',
- 'description', 'seeAlso' and 'telephoneNumber' attribute types are
- described in [Schema]. The 'roomNumber' attribute type is described
- in Section 2 of this document.
-
- dn: cn=conference room,dc=example,dc=com
- objectClass: room
- cn: conference room
- telephoneNumber: +1 755 555 1111
-
-
-3.8. simpleSecurityObject
-
- The 'simpleSecurityObject' object class is used to require an entry to
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 18]
-
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
- have an 'userPassword' attribute when the entry's structural object
- class does not require (or allow) the 'userPassword attribute'.
-
- ( 0.9.2342.19200300.100.4.19 NAME 'simpleSecurityObject'
- SUP top AUXILIARY
- MUST userPassword )
-
- The 'top' object class is described in [Models]. The 'userPassword'
- attribute type is described in [Schema].
-
- dn: dc=kdz,dc=Example,dc=COM
- objectClass: account
- objectClass: simpleSecurityObject
- uid: kdz
- userPassword: My Password
- seeAlso: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM
-
-
-4. Security Considerations
-
- General LDAP security considerations [Roadmap] is applicable to the
- use of this schema. Additional considerations are noted above where
- appropriate.
-
- Directories administrators should ensure that access to sensitive
- information is restricted to authorized entities, but ensure that
- appropriate data security services, including data integrity and data
- confidentiality, are used to protect against eavesdropping.
-
- Simple authentication (e.g., plain text passwords) mechanisms should
- only be used when adequate data security services are in place. LDAP
- offers reasonable strong authentication and data security services
- [AuthMeth].
-
-
-
-5. IANA Considerations
-
- It is requested that the Internet Assigned Numbers Authority (IANA)
- update upon Standard Action the LDAP descriptors registry [BCP64bis]
- as indicated the following template:
-
- Subject: Request for LDAP Descriptor Registration Update
- Descriptor (short name): see comment
- Object Identifier: see comments
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Usage: see comments
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 19]
-
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
- Specification: RFC XXXX
- Author/Change Controller: IESG
- Comments:
-
- The following descriptors should be updated to refer to RFC XXXX.
-
- NAME Type OID
- ------------------------ ---- --------------------------
- account O 0.9.2342.19200300.100.4.5
- associatedDomain A 0.9.2342.19200300.100.1.37
- associatedName A 0.9.2342.19200300.100.1.38
- buildingName A 0.9.2342.19200300.100.1.48
- co A 0.9.2342.19200300.100.1.43
- document O 0.9.2342.19200300.100.4.6
- documentAuthor A 0.9.2342.19200300.100.1.14
- documentIdentifier A 0.9.2342.19200300.100.1.11
- documentLocation A 0.9.2342.19200300.100.1.15
- documentPublisher A 0.9.2342.19200300.100.1.56
- documentSeries O 0.9.2342.19200300.100.4.8
- documentTitle A 0.9.2342.19200300.100.1.12
- documentVersion A 0.9.2342.19200300.100.1.13
- domain O 0.9.2342.19200300.100.4.13
- domainRelatedObject O 0.9.2342.19200300.100.4.17
- drink A 0.9.2342.19200300.100.1.5
- favouriteDrink A* 0.9.2342.19200300.100.1.5
- friendlyCountry O 0.9.2342.19200300.100.4.18
- friendlyCountryName A* 0.9.2342.19200300.100.1.43
- homePhone A 0.9.2342.19200300.100.1.20
- homePostalAddress A 0.9.2342.19200300.100.1.39
- homeTelephone A* 0.9.2342.19200300.100.1.20
- host A 0.9.2342.19200300.100.1.9
- info A 0.9.2342.19200300.100.1.4
- mail A 0.9.2342.19200300.100.1.3
- manager A 0.9.2342.19200300.100.1.10
- mobile A 0.9.2342.19200300.100.1.41
- mobileTelephoneNumber A* 0.9.2342.19200300.100.1.41
- organizationalStatus A 0.9.2342.19200300.100.1.45
- pager A 0.9.2342.19200300.100.1.42
- pagerTelephoneNumber A* 0.9.2342.19200300.100.1.42
- personalTitle A 0.9.2342.19200300.100.1.40
- rFC822LocalPart O 0.9.2342.19200300.100.4.14
- rfc822Mailbox A* 0.9.2342.19200300.100.1.3
- room O 0.9.2342.19200300.100.4.7
- roomNumber A 0.9.2342.19200300.100.1.6
- secretary A 0.9.2342.19200300.100.1.21
- simpleSecurityObject O 0.9.2342.19200300.100.4.19
- singleLevelQuality A 0.9.2342.19200300.100.1.50
- uniqueIdentifier A 0.9.2342.19200300.100.1.44
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 20]
-
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
- userClass A 0.9.2342.19200300.100.1.8
-
- where Type A is Attribute and Type O is ObjectClass, and *
- indicates the registration is historic in nature.
-
-
-6. Acknowledgments
-
- This document is based upon RFC 1274 by Paul Barker and Steve Kille,
- as well as RFC 2247 by Steve Kill, Mark Wahl, Al Grimstad, Rick Huber,
- and Sri Satulari.
-
-
-7. Editor's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- Email: Kurt@OpenLDAP.org
-
-
-8. References
-
- [[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn where
- possible.]]
-
-8.1. Normative References
-
- [RFC1034] Mockapetris, P., "Domain names - concepts
- and facilities", STD 13 (also RFC 1034), November 1987.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
- [RFC2247] Kille, S., M. Wahl, A. Grimstad, R. Huber and S.
- Sataluri, "Using Domains in LDAP/X.500 Distinguished
- Names", January 1998.
-
- [RFC2821] Klensin, J. (editor), "Simple Mail Transfer Protocol",
- RFC 2822, April 2001.
-
- [RFC3490] Faltstrom, P., P. Hoffman, and A. Costello,
- "Internationalizing Domain Names in Applications
- (INDA)", RFC 3490, March 2003.
-
- [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
- Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 21]
-
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
- progress.
-
- [Models] Zeilenga, K. (editor), "LDAP: Directory Information
- Models", draft-ietf-ldapbis-models-xx.txt, a work in
- progress.
-
- [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
- draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
-
- [Schema] Dally, K. (editor), "LDAP: User Schema",
- draft-ietf-ldapbis-user-schema-xx.txt, a work in
- progress.
-
- [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
- Connection Level Security Mechanisms",
- draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
-
-
-8.2. Informative References
-
- [COSINEpilot]
-
- [NamingPlan] Zeilenga, K., "The Internet Naming Plan for LDAP/X.500
- Directories", draft-zeilenga-ldap-namingplan-xx.txt, a
- work in progress.
-
- [ISO3166] International Organization for Standardization, "Codes
- for the representation of names of countries", ISO 3166.
-
- [RFC1274] Barker, P. and S. Kille, "The COSINE and Internet X.500
- Schema", November 1991.
-
- [RFC2798] Smith, M., "The LDAP inetOrgPerson Object Class", RFC
- 2798, April 2000.
-
- [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
- draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
-
-
-Appendix A. Changes since RFC 1274
-
- This document represents a substantial rewrite of RFC 1274. The
- following sections summarize the substantive changes.
-
-A.1. LDAP Short Names
-
- A number of COSINE attribute types have short names in LDAP.
-
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 22]
-
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
- X.500 Name LDAP Short Name
- ------------- ---------------
- domainComponent dc
- favoriteDrink drink
- friendCountryName co
- homeTelephoneNumber homePhone
- mobileTelephoneNumber mobile
- pagerTelephoneNumber pager
- rfc822Mailbox mail
- userid uid
-
- While the LDAP short names are generally used in LDAP, some
- implementations may (for legacy reasons [Historic]) recognize the
- attribute type by its X.500 name. Hence, the X.500 names have been
- reserved solely for this purpose.
-
- Note: 'uid' and 'dc' are described in [Schema].
-
-
-A.2. pilotObject
-
- The 'pilotObject' object class was not brought forward as its function
- is largely replaced by operational attributes introduced in X.500(93)
- [X.501] and version 3 of LDAP [Models]. For instance, the function
- of the 'lastModifiedBy' and 'lastModifiedTime' attribute types is now
- served by the 'creatorsName', 'createTimestamp', 'modifiersName', and
- 'modifyTimestamp' operational attributes [Models].
-
-
-A.3. pilotPerson
-
- The 'pilotPerson' object class was not brought forward as its function
- is largely replaced by the 'organizationalPerson' [Models] object
- class and its subclasses, such as 'inetOrgPerson' [RFC2798].
-
- Most of the related attribute types (e.g., 'mail', 'manager', etc.)
- were brought forward as they are used in other object classes.
-
-
-A.4. dNSDomain
-
- The 'dNSDomain' object class and related attribute types were not
- brought forward as its use is primarily experimental [RFC1279].
-
-
-A.5. pilotDSA and qualityLabelledData
-
- The 'pilotDSA' and 'qualityLabelledData' object classes, as well as
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 23]
-
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
- related attribute types, were not brought forward as it as its use is
- primarily experimental [QoS].
-
-
-A.6. Attribute syntaxes
-
- RFC 1274 defined and used caseIgnoreIA5StringSyntax attribute syntax.
- This has been replaced with the IA5String syntax and approrpiate
- matching rules in 'mail' and 'associatedDomain'.
-
- RFC 1274 restricted 'mail' to have non-zero length values. This
- restriction is not reflected in the IA5String syntax used in the
- definitions provided in this specification. However, as values are
- to conform to the <Mailbox> production, the 'mail' should not contain
- zero-length values. Unfornuately, the directory service will not
- enforce this restriction.
-
-
-Appendix B. Changes since RFC 2247
-
- The 'domainNameForm' name form was not brought forward as
- specification of name forms used in LDAP is left to a future
- specification.
-
-
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be found
- in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this specification
- can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 24]
-
-INTERNET-DRAFT COSINE Schema 23 October 2005
-
-
- ietf-ipr@ietf.org.
-
-
-
-Full Copyright
-
- Copyright (C) The Internet Society (2005).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga draft-zeilenga-ldap-cosine-01 [Page 25]
-
diff --git a/doc/drafts/draft-zeilenga-ldap-incr.txt b/doc/drafts/draft-zeilenga-ldap-incr.txt
deleted file mode 100644
index e903781d0ad80ea36bb7e41266c4bdd72d9e4192..0000000000000000000000000000000000000000
--- a/doc/drafts/draft-zeilenga-ldap-incr.txt
+++ /dev/null
@@ -1,340 +0,0 @@
-
-
-
-
-
-INTERNET-DRAFT Kurt D. Zeilenga
-Intended Category: Experimental OpenLDAP Foundation
-Expires in six months 10 February 2005
-
-
-
- LDAP Modify-Increment Extension
- <draft-zeilenga-ldap-incr-01.txt>
-
-
-Status of this Memo
-
- This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor as an Experimental document.
- Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDAP Extensions mailing list
- <ldapext@ietf.org>. Please send editorial comments directly to the
- author <Kurt@OpenLDAP.org>.
-
- By submitting this Internet-Draft, I accept the provisions of Section
- 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
- applicable patent or other IPR claims of which I am aware have been
- disclosed, or will be disclosed, and any of which I become aware will
- be disclosed, in accordance with RFC 3668.
-
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference material
- or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
- Copyright (C) The Internet Society (2005). All Rights Reserved.
-
- Please see the Full Copyright section near the end of this document
- for more information.
-
-
-
-
-
-
-Zeilenga LDAP Modify-Increment Extension [Page 1]
-
-INTERNET-DRAFT draft-zeilenga-ldap-incr-01.txt 10 February 2005
-
-
-Abstract
-
- This document describes an extension to the Lightweight Directory
- Access Protocol (LDAP) Modify operation to support an increment
- capability. This extension is useful in provisioning applications,
- especially when combined with the assertion control and/or the
- pre-read or post-read control extension.
-
-
-1. Background and Intended Use
-
- The Lightweight Directory Access Protocol [Roadmap] does not currently
- provide an operation to increment values of an attribute. A client
- must read the values of the attribute, then modify those values to
- increment them by the desired amount. As the values may be updated by
- other clients between this add and modify, the client must be careful
- to construct the modify request so that it fails in this case, and
- upon failure, re-read the values and construct a new modify request.
-
- This document extends the LDAP Modify Operation [Protocol] to support
- an increment values capability. This feature is intended to be used
- with either the LDAP pre-read or post-read control extension
- [ReadEntry]. This feature may also be used with the LDAP assertion
- control [Assertion] to provide test-and-increment functionality.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119].
-
-
-2. The Modify-Increment Extension
-
- This document extends the LDAP Modify request to support a increment
- values capability. Implementations of this extension SHALL support an
- additional ModifyRequest operation enumeration value increment (IANA-
- ASSIGNED-TYPE) as described herein. Implementations not supporting
- this extension will treat this value as they would an unlisted value,
- e.g., as a protocol error.
-
- The increment (IANA-ASSIGNED-TYPE) operation value specifies that an
- increment values modification is requested. All existing values of
- the modification attribute are to be incremented by the listed value.
- The modification attribute must be appropriate for request, e.g., must
- have INTEGER or other increment-able values, and the modification must
- provide one and only value. If the attribute is not appropriate for
- the request, a constraintViolation or other appropriate error is to be
- returned. If multiple values are provided, a protocolError is to be
- returned.
-
-
-
-Zeilenga LDAP Modify-Increment Extension [Page 2]
-
-INTERNET-DRAFT draft-zeilenga-ldap-incr-01.txt 10 February 2005
-
-
- Servers supporting this feature SHOULD publish the object identifier
- (OID) IANA-ASSIGNED-OID as a value of the 'supportedFeatures'
- [RFC3674] attribute in the root DSE. Clients supporting this feature
- SHOULD NOT use the feature unless they have knowledge the server
- supports it.
-
-
- 3. LDIF Support
-
- To represent Modify-Increment requests in LDAP Data Interchange Format
- [RFC2849], the ABNF [RFC2234] production <mod-spec> is extended as
- follows:
-
- mod-spec /= "increment:" FILL AttributeDescription SEP
- attrval-spec "-" SEP
-
- For example,
-
- # Increment uidNumber
- dn: cn=max-assigned uidNumber,dc=example,dc=com
- changetype: modify
- increment: uidNumber
- uidNumber: 1
- -
-
- This LDIF fragment represents a Modify request to increment the
- value(s) of uidNumber by 1.
-
-
-4. Security Considerations
-
- General LDAP security considerations [Roadmap], as well as those
- specific to the LDAP Modify [Protocol], apply to this Modify-Increment
- extension. Beyond these considerations, it is noted that introduction
- of this extension should reduce application complexity (by provide one
- operation what presently requires multiple operation) and, hence, may
- aide in the production of correct and secure implementations.
-
-
-5. IANA Considerations
-
- Registration of the following values [BCP64bis] is requested.
-
-
-5.1. Object Identifier
-
- It is requested that IANA assign an LDAP Object Identifier to identify
- the LDAP Modify-Increment feature as defined in this document.
-
-
-
-Zeilenga LDAP Modify-Increment Extension [Page 3]
-
-INTERNET-DRAFT draft-zeilenga-ldap-incr-01.txt 10 February 2005
-
-
- Subject: Request for LDAP Object Identifier Registration
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Specification: RFC XXXX
- Author/Change Controller: Author
- Comments:
- Identifies the LDAP Modify-Increment feature
-
-
-
-5.2. LDAP Protocol Mechanism
-
- It is requested that the following LDAP Protocol Mechanism be
- registered.
-
- Subject: Request for LDAP Protocol Mechanism Registration
- Object Identifier: IANA-ASSIGNED-OID
- Description: Modify-Increment
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@openldap.org>
- Usage: Feature
- Specification: RFC XXXX
- Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
- Comments: none
-
-
-5.3. LDAP Protocol Mechanism
-
- It is requested that IANA assign an LDAP ModifyRequest Operation Type
- [BCP64bis] for use in this document.
-
- Subject: Request for LDAP Protocol Mechanism Registration
- ModifyRequest Operation Name: increment
- Description: Modify-Increment
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@openldap.org>
- Usage: Feature
- Specification: RFC XXXX
- Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
- Comments: none
-
-
-6. Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
- <Kurt@OpenLDAP.org>
-
-
-
-
-Zeilenga LDAP Modify-Increment Extension [Page 4]
-
-INTERNET-DRAFT draft-zeilenga-ldap-incr-01.txt 10 February 2005
-
-
-7. References
-
- [[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn where
- possible.]]
-
-
-7.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
- [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
-
- [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) -
- Technical Specification", RFC 2849, June 2000.
-
- [Features] Zeilenga, K., "Feature Discovery in LDAP", RFC 3674,
- December 2003.
-
- [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
- Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
- progress.
-
- [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
- draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
-
-
-7.2. Informative References
-
- [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
- draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
-
- [ReadEntry] Zeilenga, K., "LDAP Read Entry Controls",
- draft-zeilenga-ldap-readentry-xx.txt, a work in
- progress.
-
- [Assertion] Zeilenga, K., "LDAP Assertion Control",
- draft-zeilenga-ldap-assert-xx.txt, a work in progress.
-
- [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
- http://www.openldap.org/foundation/oid-delegate.txt.
-
- [PRIVATE] IANA, "Private Enterprise Numbers",
- http://www.iana.org/assignments/enterprise-numbers.
-
-
-
-
-
-Zeilenga LDAP Modify-Increment Extension [Page 5]
-
-INTERNET-DRAFT draft-zeilenga-ldap-incr-01.txt 10 February 2005
-
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be found
- in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this specification
- can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-Full Copyright
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga LDAP Modify-Increment Extension [Page 6]
-
-
-
diff --git a/doc/drafts/draft-zeilenga-ldap-readentry-xx.txt b/doc/drafts/draft-zeilenga-ldap-readentry-xx.txt
deleted file mode 100644
index d299d04bb9e6d593d94b30421583258671f737a8..0000000000000000000000000000000000000000
--- a/doc/drafts/draft-zeilenga-ldap-readentry-xx.txt
+++ /dev/null
@@ -1,452 +0,0 @@
-
-
-
-
-
-INTERNET-DRAFT Kurt D. Zeilenga
-Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 10 February 2005
-
-
-
- LDAP Read Entry Controls
- <draft-zeilenga-ldap-readentry-04.txt>
-
-
-1. Status of this Memo
-
- This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor as a Standard Track document.
- Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDAP Extensions mailing list
- <ldapext@ietf.org>. Please send editorial comments directly to the
- author <Kurt@OpenLDAP.org>.
-
- By submitting this Internet-Draft, I accept the provisions of Section
- 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
- applicable patent or other IPR claims of which I am aware have been
- disclosed, or will be disclosed, and any of which I become aware will
- be disclosed, in accordance with RFC 3668.
-
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference material
- or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
- Copyright (C) The Internet Society (2005). All Rights Reserved.
-
- Please see the Full Copyright section near the end of this document
- for more information.
-
-
-
-
-
-
-Zeilenga LDAP Read Entry Controls [Page 1]
-
-INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
-
-
-Abstract
-
- This document specifies an extension to the Lightweight Directory
- Access Protocol (LDAP) to allow the client to read the target entry of
- an update operation. The client may request to read the entry before
- and/or after the modifications are applied. These reads are done as
- an atomic part of the update operation.
-
-
-1. Background and Intent of Use
-
- This document specifies an extension to the Lightweight Directory
- Access Protocol (LDAP) [Roadmap] to allow the client to read the
- target entry of an update operation (e.g., Add, Delete, Modify,
- ModifyDN). The extension utilizes controls [Protocol] attached to
- update requests to request and return copies of the target entry. One
- request control, called the Pre-Read request control, indicates that a
- copy of the entry before application of update is to be returned.
- Another control, called the Post-Read request control, indicates that
- a copy of the entry after application of the update is to be returned.
- Each request control has a corresponding response control used to
- return the entry.
-
- To ensure proper isolation, the controls are processed as an atomic
- part of the update operation.
-
- The functionality offered by these controls is based upon similar
- functionality in the X.500 Directory Access Protocol (DAP) [X.511].
-
- The Pre-Read controls may be used to obtain replaced or deleted values
- of modified attributes or a copy of the entry being deleted.
-
- The Post-Read controls may be used to obtain values of operational
- attributes, such as the 'entryUUID' [EntryUUID] and 'modifyTimestamp'
- [Models] attributes, updated by the server as part of the update
- operation.
-
-
-2. Terminology
-
- Protocol elements are described using ASN.1 [X.680] with implicit
- tags. The term "BER-encoded" means the element is to be encoded using
- the Basic Encoding Rules [X.690] under the restrictions detailed in
- Section 5.2 of [Protocol].
-
- DN stands for Distinguished Name.
- DSA stands for Directory System Agent (i.e., a directory server).
- DSE stands for DSA-specific Entry.
-
-
-
-Zeilenga LDAP Read Entry Controls [Page 2]
-
-INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
-
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119].
-
-
-3. Read Entry Controls
-
-3.1. The Pre-Read Controls
-
- The Pre-Read request and response controls are identified by the
- IANA-ASSIGNED-OID.1 object identifier. Servers implementing these
- controls SHOULD publish IANA-ASSIGNED-OID.1 as a value of the
- 'supportedControl' [Models] in their root DSE.
-
- The Pre-Read request control is an LDAP Control [Protocol] whose
- controlType is IANA-ASSIGNED-OID.1 and whose controlValue is a
- BER-encoded AttributeSelection [Protocol], as extended by [RFC3673].
- The criticality may be TRUE or FALSE. This control is appropriate for
- the modifyRequest, delRequest, and modDNRequest LDAP messages.
-
- The corresponding response control is a LDAP Control whose controlType
- is IANA-ASSIGNED-OID.1 and whose the controlValue, an OCTET STRING,
- contains a BER-encoded SearchResultEntry. The criticality may be TRUE
- or FALSE. This control is appropriate for the modifyResponse,
- delResponse, and modDNResponse LDAP messages with a resultCode of
- success (0).
-
- When the request control is attached to an appropriate update LDAP
- request, the control requests the return of a copy of target entry
- prior to the application of the update. The AttributeSelection
- indicates, as discussed in [Protocol][RFC3673] which attributes are
- requested to appear in the copy. The server is to return a
- SearchResultEntry containing, subject to access controls and other
- constraints, values of the requested attributes.
-
- The normal processing of the update operation and the processing of
- this control MUST be performed as one atomic action isolated from
- other update operations.
-
- If the update operation fails (in either normal or control
- processing), no response control is provided.
-
-
-3.2. The Post-Read Controls
-
- The Post-Read request and response controls are identified by the
- IANA-ASSIGNED-OID.2 object identifier. Servers implementing these
- controls SHOULD publish IANA-ASSIGNED-OID.2 as a value of the
-
-
-
-Zeilenga LDAP Read Entry Controls [Page 3]
-
-INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
-
-
- 'supportedControl' [Models] in their root DSE.
-
- The Post-Read request control is an LDAP Control [Protocol] whose
- controlType is IANA-ASSIGNED-OID.2 and whose controlValue, an OCTET
- STRING, contains a BER-encoded AttributeSelection [Protocol], as
- extended by [RFC3673]. The criticality may be TRUE or FALSE. This
- control is appropriate for the addRequest, modifyRequest, and
- modDNRequest LDAP messages.
-
- The corresponding response control is a LDAP Control whose controlType
- is IANA-ASSIGNED-OID.2 and whose controlValue is a BER-encoded
- SearchResultEntry. The criticality may be TRUE or FALSE. This
- control is appropriate for the addResponse, modifyResponse, and
- modDNResponse LDAP messages with a resultCode of success (0).
-
- When the request control is attached to an appropriate update LDAP
- request, the control requests the return of a copy of target entry
- after the application of the update. The AttributeSelection
- indicates, as discussed in [Protocol][RFC3673], which attributes are
- requested to appear in the copy. The server is to return a
- SearchResultEntry containing, subject to access controls and other
- constraints, values of the requested attributes.
-
- The normal processing of the update operation and the processing of
- this control MUST be performed as one atomic action isolated from
- other update operations.
-
- If the update operation fails (in either normal or control
- processing), no response control is provided.
-
-
-4. Interaction with other controls
-
- The Pre-Read and Post-Read controls may be combined with each other
- and/or with a variety of other controls. When combined with the
- assertion control [Assertion] and/or the manageDsaIT control
- [RFC3296], the semantics of each control included in the combination
- apply. The Pre-Read and Post-Read controls may be combined with other
- controls as detailed in other technical specifications.
-
-
-5. Security Considerations
-
- The controls defined in this document extend update operations to
- support read capabilities. Servers MUST ensure that the client is
- authorized both for reading of the information provided in this
- control in addition to ensuring the client is authorized to perform
- the requested directory update.
-
-
-
-Zeilenga LDAP Read Entry Controls [Page 4]
-
-INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
-
-
- Security considerations for the update operations [Protocol] extended
- by this control, as well as general LDAP security considerations
- [Roadmap], generally apply to implementation and use of this extension
-
-
-6. IANA Considerations
-
- Registration of the following protocol values [BCP64bis] is requested.
-
-
-6.1. Object Identifier
-
- It is requested that IANA register an LDAP Object Identifier to
- identify LDAP protocol elements defined in this document.
-
- Subject: Request for LDAP Object Identifier Registration
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Specification: RFC XXXX
- Author/Change Controller: IESG
- Comments:
- Identifies the LDAP Read Entry Controls
-
-
-6.2. LDAP Protocol Mechanisms
-
- It is requested that IANA register the LDAP Protocol Mechanism
- described in this document.
-
- Subject: Request for LDAP Protocol Mechanism Registration
- Object Identifier: IANA-ASSIGNED-OID.1
- Description: LDAP Pre-read Control
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@openldap.org>
- Usage: Control
- Specification: RFC XXXX
- Author/Change Controller: IESG
- Comments: none
- in 2
-
- Subject: Request for LDAP Protocol Mechanism Registration
- Object Identifier: IANA-ASSIGNED-OID.2
- Description: LDAP Post-read Control
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@openldap.org>
- Usage: Control
- Specification: RFC XXXX
- Author/Change Controller: IESG
-
-
-
-Zeilenga LDAP Read Entry Controls [Page 5]
-
-INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
-
-
- Comments: none
-
-
-7. Acknowledgment
-
- The LDAP Pre-Read and Post-Read controls are modeled after similar
- capabilities offered in the DAP [X.511].
-
-
-8. References
-
- [[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn where
- possible.]]
-
-
-8.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
- [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
- Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
- progress.
-
- [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
- draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
-
- [Models] Zeilenga, K. (editor), "LDAP: Directory Information
- Models", draft-ietf-ldapbis-models-xx.txt, a work in
- progress.
-
- [RFC3296] Zeilenga, K., "Named Subordinate References in
- Lightweight Directory Access Protocol (LDAP)
- Directories", RFC 3296, July 2002.
-
- [RFC3673] Zeilenga, K., "LDAPv3: All Operational Attributes", RFC
- 3673, December 2003.
-
- [Assertion] Zeilenga, K., "LDAP Assertion Control",
- draft-zeilenga-ldap-assert-xx.txt, a work in progress.
-
- [X.680] International Telecommunication Union -
- Telecommunication Standardization Sector, "Abstract
- Syntax Notation One (ASN.1) - Specification of Basic
- Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
-
- [X.690] International Telecommunication Union -
-
-
-
-Zeilenga LDAP Read Entry Controls [Page 6]
-
-INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
-
-
- Telecommunication Standardization Sector, "Specification
- of ASN.1 encoding rules: Basic Encoding Rules (BER),
- Canonical Encoding Rules (CER), and Distinguished
- Encoding Rules (DER)", X.690(1997) (also ISO/IEC
- 8825-1:1998).
-
-
-8.2. Informative References
-
- [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
- draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
-
- [EntryUUID] Zeilenga, K., "The LDAP EntryUUID Operational
- Attribute", draft-zeilenga-ldap-uuid-xx.txt, a work in
- progress.
-
- [X.511] International Telecommunication Union -
- Telecommunication Standardization Sector, "The
- Directory: Abstract Service Definition", X.511(1993)
- (also ISO/IEC 9594-3:1993).
-
-
-10. Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- Email: Kurt@OpenLDAP.org
-
-
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be found
- in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this specification
- can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
-
-
-Zeilenga LDAP Read Entry Controls [Page 7]
-
-INTERNET-DRAFT draft-zeilenga-ldap-readentry-04 10 February 2005
-
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-Full Copyright
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga LDAP Read Entry Controls [Page 8]
-
-
-
diff --git a/doc/drafts/draft-zeilenga-ldap-t-f-xx.txt b/doc/drafts/draft-zeilenga-ldap-t-f-xx.txt
deleted file mode 100644
index 1d07396b8cb8072620a859fb517cbb3be8839cdc..0000000000000000000000000000000000000000
--- a/doc/drafts/draft-zeilenga-ldap-t-f-xx.txt
+++ /dev/null
@@ -1,340 +0,0 @@
-
-
-
-
-
-INTERNET-DRAFT Kurt D. Zeilenga
-Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 10 February 2005
-
-
-
- LDAP Absolute True and False Filters
- <draft-zeilenga-ldap-t-f-10.txt>
-
-
-Status of this Memo
-
- This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor as a Standard Track document.
- Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDAP Extensions mailing list
- <ldapext@ietf.org>. Please send editorial comments directly to the
- author <Kurt@OpenLDAP.org>.
-
- By submitting this Internet-Draft, I accept the provisions of Section
- 4 of RFC 3667. By submitting this Internet-Draft, I certify that any
- applicable patent or other IPR claims of which I am aware have been
- disclosed, or will be disclosed, and any of which I become aware will
- be disclosed, in accordance with RFC 3668.
-
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference material
- or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
- Copyright (C) The Internet Society (2005). All Rights Reserved.
-
- Please see the Full Copyright section near the end of this document
- for more information.
-
-
-
-
-
-
-Zeilenga LDAP True & False Filters [Page 1]
-
-INTERNET-DRAFT draft-zeilenga-ldap-t-f-10.txt 10 February 2005
-
-
-Abstract
-
- This document extends the Lightweight Directory Access Protocol (LDAP)
- to support absolute True and False filters based upon similar
- capabilities found in X.500 directory systems. The document also
- extends the String Representation of LDAP Search Filters to support
- these filters.
-
-
-1. Background
-
- The X.500 Directory Access Protocol (DAP) [X.511] supports absolute
- True and False assertions. An 'and' filter with zero elements always
- evaluates to True. An 'or' filter with zero elements always evaluates
- to False. These filters are commonly used when requesting DSA-
- specific Entries (DSEs) which do not necessarily have 'objectClass'
- attributes. That is, where "(objectClass=*)" may evaluate to False.
-
- While LDAPv2 [RFC1777][RFC3494] placed no restriction on the number of
- elements in 'and' and 'or' filter sets, the LDAPv2 string
- representation [RFC1960][RFC3494] could not represent empty 'and' and
- 'or' filter sets. Due to this, absolute True or False filters were
- (unfortunately) eliminated from LDAPv3 [Roadmap].
-
- This documents extends LDAPv3 to support absolute True and False
- assertions by allowing empty 'and' and 'or' in Search filters
- [Protocol] and extends the filter string representation [Filters] to
- allow empty filter lists.
-
- It is noted that certain search operations, such as those used to
- retrieve subschema information [Models], require use of particular
- filters. This document does not change these requirements.
-
- This feature is intended to allow a more direct mapping between DAP
- and LDAP (as needed to implement DAP-to-LDAP gateways).
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119].
-
-
-2. Absolute True and False Filters
-
- Implementations of this extension SHALL allow 'and' and 'or' choices
- with zero filter elements.
-
- An 'and' filter consisting of an empty set of filters SHALL evaluate
- to True. This filter is represented by the string "(&)".
-
-
-
-Zeilenga LDAP True & False Filters [Page 2]
-
-INTERNET-DRAFT draft-zeilenga-ldap-t-f-10.txt 10 February 2005
-
-
- An 'or' filter consisting of an empty set of filters SHALL evaluate to
- False. This filter is represented by the string "(|)".
-
- Servers supporting this feature SHOULD publish the Object Identifier
- 1.3.6.1.4.1.4203.1.5.3 as a value of the 'supportedFeatures' [RFC3674]
- attribute in the root DSE.
-
- Clients supporting this feature SHOULD NOT use the feature unless they
- have knowledge the server supports it.
-
-
-3. Security Considerations
-
- The (re)introduction of absolute True and False filters is not
- believed to raise any new security considerations.
-
- Implementors of this (or any) LDAPv3 extension should be familiar with
- general LDAPv3 security considerations [Roadmap].
-
-
-4. IANA Considerations
-
- Registration of this feature is requested [BCP64bis].
-
- Subject: Request for LDAP Protocol Mechanism Registration
- Object Identifier: 1.3.6.1.4.1.4203.1.5.3
- Description: True/False filters
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@openldap.org>
- Usage: Feature
- Specification: RFC XXXX
- Author/Change Controller: IESG
- Comments: none
-
- This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its
- IANA-assigned private enterprise allocation [PRIVATE], for use in this
- specification.
-
-
-5. Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
- <Kurt@OpenLDAP.org>
-
-
-6. References
-
-
-
-
-Zeilenga LDAP True & False Filters [Page 3]
-
-INTERNET-DRAFT draft-zeilenga-ldap-t-f-10.txt 10 February 2005
-
-
- [[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn where
- possible.]]
-
-
-6.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
- [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
- Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
- progress.
-
- [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
- draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
-
- [Models] Zeilenga, K. (editor), "LDAP: Directory Information
- Models", draft-ietf-ldapbis-models-xx.txt, a work in
- progress.
-
- [Filters] Smith, M. (editor), LDAPbis WG, "LDAP: String
- Representation of Search Filters",
- draft-ietf-ldapbis-filter-xx.txt, a work in progress.
-
- [Features] Zeilenga, K., "Feature Discovery in LDAP", RFC 3674,
- December 2003.
-
-
-6.2. Informative References
-
- [RFC1777] Yeong, W., Howes, T., and S. Kille, "Lightweight
- Directory Access Protocol", RFC 1777, March 1995.
-
- [RFC1960] Howes, T., "A String Representation of LDAP Search
- Filters", RFC 1960, June 1996.
-
- [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
- draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
-
- [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol
- version 2 (LDAPv2) to Historic Status", RFC 3494, March
- 2003.
-
- [X.500] International Telecommunication Union -
- Telecommunication Standardization Sector, "The Directory
- -- Overview of concepts, models and services,"
- X.500(1993) (also ISO/IEC 9594-1:1994).
-
-
-
-Zeilenga LDAP True & False Filters [Page 4]
-
-INTERNET-DRAFT draft-zeilenga-ldap-t-f-10.txt 10 February 2005
-
-
- [X.501] International Telecommunication Union -
- Telecommunication Standardization Sector, "The Directory
- -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
-
- [X.511] International Telecommunication Union -
- Telecommunication Standardization Sector, "The
- Directory: Abstract Service Definition", X.511(1993)
- (also ISO/IEC 9594-3:1993).
-
- [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
- http://www.openldap.org/foundation/oid-delegate.txt.
-
- [PRIVATE] IANA, "Private Enterprise Numbers",
- http://www.iana.org/assignments/enterprise-numbers.
-
-
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be found
- in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this specification
- can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-Full Copyright
-
- Copyright (C) The Internet Society (2005). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-
-Zeilenga LDAP True & False Filters [Page 5]
-
-INTERNET-DRAFT draft-zeilenga-ldap-t-f-10.txt 10 February 2005
-
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga LDAP True & False Filters [Page 6]
-
-
-
diff --git a/doc/drafts/draft-zeilenga-ldap-turn-xx.txt b/doc/drafts/draft-zeilenga-ldap-turn-xx.txt
deleted file mode 100644
index 9cb2f302a3db3bdc8d5417eb3f6d4a11ba1f40b1..0000000000000000000000000000000000000000
--- a/doc/drafts/draft-zeilenga-ldap-turn-xx.txt
+++ /dev/null
@@ -1,507 +0,0 @@
-
-
-
-
-
-
-INTERNET-DRAFT Kurt D. Zeilenga
-Intended Category: Experimental OpenLDAP Foundation
-Expires in six months 28 October 2005
-
-
-
- LDAP Turn Operation
- <draft-zeilenga-ldap-turn-03.txt>
-
-
-1. Status of this Memo
-
- This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor for publication as an
- Experimental document. Distribution of this memo is unlimited.
- Technical discussion of this document will take place on the IETF LDAP
- Extensions mailing list <ldapext@ietf.org>. Please send editorial
- comments directly to the author <Kurt@OpenLDAP.org>.
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware have
- been or will be disclosed, and any of which he or she becomes aware
- will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference material
- or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
- Copyright (C) The Internet Society (2005). All Rights Reserved.
-
- Please see the Full Copyright section near the end of this document
- for more information.
-
-
-Abstract
-
-
-
-
-Zeilenga LDAP Turn Op [Page 1]
-
-INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
-
-
- This specification describes a Lightweight Directory Access Protocol
- (LDAP) extended operation to reverse (or "turn") the roles of client
- and server for subsequent protocol exchanges in the session, or to
- enable each peer to act as both client and server with respect to the
- other.
-
-
-1. Background and Intent of Use
-
- The Lightweight Directory Access Protocol (LDAP) [Roadmap][Protocol]
- is a client-server protocol which typically operates over reliable
- octet-stream transports such as the Transport Control Protocol (TCP).
- Generally, the client initiates the stream by connecting to the
- server's listener at some well-known address.
-
- There are cases where it is desirable for the server to initiate the
- stream. While it certainly is possible to write a technical
- specification detailing how to implement server-initiated LDAP
- sessions, this would require the design of new authentication and
- other security mechanisms to support server-initiated LDAP sessions.
-
- Instead, this document introduces an operation, the Turn operation,
- which may be used to reverse the client-servers roles of the protocol
- peers. This allows the initiating protocol peer to become server
- (after the reversal).
-
- As an additional feature, the Turn operation may be used to allow both
- peers to act in both roles. This is useful where both peers are
- directory servers that desire to request, as LDAP clients, operations
- be performed by the other. This may be useful in replicated and/or
- distributed environments.
-
- This operation is intended to be used between protocol peers which
- have established a mutual agreement, by means outside of the protocol,
- which requires reversal of client-server roles, or allows both peers
- to act both as client and server.
-
-
-1.1 Terminology
-
- Protocol elements are described using ASN.1 [X.680] with implicit
- tags. The term "BER-encoded" means the element is to be encoded using
- the Basic Encoding Rules [X.690] under the restrictions detailed in
- Section 5.2 of [Protocol].
-
-
-2. Turn Operation
-
-
-
-
-Zeilenga LDAP Turn Op [Page 2]
-
-INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
-
-
- The Turn operation is defined as a LDAP Extended Operation [Protocol,
- Section 4.12] identified by the IANA-ASSIGNED-OID. The function of
- the Turn Operation is to request that the client-server roles be
- reversed, or, optionally to request that both protocol peers to be
- able to act both as client and server in respect to the other.
-
-
-2.1. Turn Request
-
- The Turn request is an ExtendedRequest with the requestName field
- containing the IANA-ASSIGNED-OID and a requestValue field is a
- BER-encoded turnValue:
-
- turnValue ::= SEQUENCE {
- mutual BOOLEAN DEFAULT FALSE,
- identifier LDAPString
- }
-
- A TRUE mutual field value indicates a request to allow both peers to
- act both as client and server. A FALSE mutual field value indicates a
- request to reserve the client and server roles.
-
- The value of the identifier field is a locally-defined policy
- identifier (typically associated with a mutual agreement for which
- this turn is be executed as part of).
-
-
-2.2. Turn Response
-
- A Turn response is an ExtendedResponse where the responseName and
- responseValue fields are absent. A resultCode of success is returned
- if and only if the responder is willing and able to turn the session
- as requested. Otherwise, a different resultCode is returned.
-
-
-3. Authentication
-
- This extension's authentication model assumes separate authentication
- of the peers in each of their roles. A separate Bind exchange is
- expected between the peers in their new roles to establish identities
- in these roles.
-
- Upon completion of the Turn, the responding peer in its new client
- role has an anonymous association at the initiating peer in its new
- server role. If the turn was mutual, the authentication association
- of the initiating peer in its pre-existing client role is left intact
- at the responding peer in its pre-existing server role. If the turn
- was not mutual, this association is void.
-
-
-
-Zeilenga LDAP Turn Op [Page 3]
-
-INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
-
-
- The responding peer may establish its identity in its client role by
- requesting and successfully completing a Bind operation.
-
- The remainder of this section discuss some authentication scenarios.
- In the protocol exchange illustrations, A refers to the initiating
- peer (the original client) and B refers to the responding peer (the
- original server).
-
-3.1. Use with TLS and Simple Authentication
-
- A->B: StartTLS Request
- B->A: StartTLS(success) Response
- A->B: Bind(Simple(cn=B,dc=example,dc=net,B's secret)) Request
- B->A: Bind(success) Response
- A->B: Turn(TRUE,"XXYYZ") Request
- B->A: Turn(success) Response
- A->B: Bind(Simple(DN/Password)) Request
- B->A: Bind(Simple(cn=A,dc=example,dc=net,A's secret)) Request
- A->B: Bind(success) Response
-
- In this scenario, TLS (Transport Layer Security) [TLS] is started and
- the initiating peer (the original client) establishes its identity
- with the responding peer prior to the Turn using the the DN/password
- mechanism of the Simple method of the Bind operation. After the turn,
- the responding peer in its new client role establishes its identity
- with the initiating peer in its new server role.
-
-
-3.2. Use with TLS and SASL EXTERNAL
-
- A->B: StartTLS Request
- B->A: StartTLS(success) Response
- A->B: Bind(SASL(EXTERNAL)) Request
- B->A: Bind(success) Response
- A->B: Turn(TRUE,"XXYYZ") Request
- B->A: Turn(success) Response
- B->A: Bind(SASL(EXTERNAL)) Request
- A->B: Bind(success) Response
-
- In this scenario, TLS is started prior with each peer providing a
- valid certificate and the initiating peer (the original client)
- establishes its identity through the use of the EXTERNAL mechanism of
- the SASL (Simple Authentication and Security Layer) [SASL] method of
- the Bind operation prior to the Turn. After the turn, the responding
- peer in its new client role establishes its identity with the
- initiating peer in its new server role.
-
-
-
-
-
-Zeilenga LDAP Turn Op [Page 4]
-
-INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
-
-
-3.3. Use of mutual authentication and SASL EXTERNAL
-
- A number of SASL mechanisms, such as GSSAPI [GSSAPI] and DIGEST-MD5
- [DIGEST-MD5], support mutual authentication. The initiating peer, it
- its new server role, may use the identity of the responding peer
- established by a prior authentication exchange, as its source for
- "external" identity in subsequent EXTERNAL exchange.
-
- A->B: Bind(SASL(GSSAPI)) Request
- <intermediate messages>
- B->A: Bind(success) Response
- A->B: Turn(TRUE,"XXYYZ") Request
- B->A: Turn(success) Response
- B->A: Bind(SASL(EXTERNAL)) Request
- A->B: Bind(success) Response
-
- In this scenario, a GSSAPI mutual-authentication exchange is completed
- between the initiating peer (the original client) and the the
- responding server (the original server) prior to the turn. After the
- turn, the responding peer in its new client role requests the
- initiating peer utilize an "external" identity to establish its LDAP
- authorization identity.
-
-
-4. TLS and SASL security layers
-
- As described in [Protocol], LDAP supports both Transport Layer
- Security (TLS) [TLS] and Simple Authentication and Security Layer
- (SASL) [SASL] security frameworks. The following table illustrates
- the relationship between the LDAP message layer, SASL layer, TLS
- layer, and transport connection within an LDAP session.
-
- +----------------------+
- | LDAP message layer |
- +----------------------+ > LDAP PDUs
- +----------------------+ < data
- | SASL layer |
- +----------------------+ > SASL-protected data
- +----------------------+ < data
- | TLS layer |
- Application +----------------------+ > TLS-protected data
- ------------+----------------------+ < data
- Transport | transport connection |
- +----------------------+
-
- This extension does not alter this relationship, nor does it remove
- the general restriction against multiple TLS layers, nor does it
- remove the general restriction against multiple SASL layers.
-
-
-
-Zeilenga LDAP Turn Op [Page 5]
-
-INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
-
-
- As specified in [Protocol], the StartTLS operation is used to initiate
- negotiation of a TLS layer. If a TLS is already installed, the
- StartTLS operation must fail. Upon establishment of the TLS layer,
- regardless of which peer issued the request to start TLS, the peer
- which initiated the LDAP session (the original client) performs the
- "server identity check" as described in Section 3.1.5 of [AuthMeth]
- treating itself as the "client" and its peer as the "server".
-
- As specified in [SASL], newly negotiated SASL security layer replace
- the installed SASL security layer. Though the client/server roles in
- LDAP, and hence SASL, may be reversed in subsequent exchanges, only
- one SASL security layer may be installed at any instance.
-
-
-5. Security Considerations
-
- Implementors should be aware that the reversing of client/server roles
- and/or allowing both peers to act as client and server likely
- introduces security considerations not foreseen by the authors of this
- document. In particular, the security implications of the design
- choices made in the authentication and data security models for this
- extension (discussed in sections 3 and 4, respectively) are not fully
- studied. It is hoped that experimentation with this extension will
- lead to better understanding of the security implications of these
- models and other aspects of this extension, and that appropriate
- considerations will be documented in a future document. The following
- security considerations are apparent at this time.
-
- Implementors should take special care to process LDAP, SASL, TLS, and
- other events the appropriate roles for the peers. It is noted that
- while the Turn reverses the client/server roles with LDAP, and in SASL
- authentication exchanges, it does not reverse the roles within the TLS
- layer or the transport connection.
-
- The responding server (the original server) should restrict use of
- this operation to authorized clients. Client knowledge of a valid
- identifier should not be the sole factor in determining authorization
- to turn.
-
- Where the peers except to establish TLS, TLS should be started prior
- to the Turn and any request to authenticate via the Bind operation.
-
- LDAP security considerations [Protocol][AuthMeth] generally apply to
- this extension.
-
-
-6. IANA Considerations
-
-
-
-
-Zeilenga LDAP Turn Op [Page 6]
-
-INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
-
-
- Registration of the following values [BCP64bis] is requested.
-
-
-6.1. Object Identifier
-
- It is requested that IANA assign an LDAP Object Identifier to identify
- the LDAP Turn Operation as defined in this document.
-
- Subject: Request for LDAP Object Identifier Registration
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Specification: RFC XXXX
- Author/Change Controller: Author
- Comments:
- Identifies the LDAP Turn Operation
-
-
-6.2. LDAP Protocol Mechanism
-
- It is requested that IANA register the LDAP Protocol Mechanism
- described in this document.
-
- Subject: Request for LDAP Protocol Mechanism Registration
- Object Identifier: IANA-ASSIGNED-OID
- Description: LDAP Turn Operation
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@openldap.org>
- Usage: Extended Operation
- Specification: RFC XXXX
- Author/Change Controller: Author
- Comments: none
-
-
-7. Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- Email: Kurt@OpenLDAP.org
-
-
-8. References
-
- [[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn where
- possible.]]
-
-
-
-
-
-Zeilenga LDAP Turn Op [Page 7]
-
-INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
-
-
-8.1. Normative References
-
- [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
- Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
- progress.
-
- [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
- draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
-
- [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
- Connection Level Security Mechanisms",
- draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
-
- [SASL] Melnikov, A. (Editor), "Simple Authentication and
- Security Layer (SASL)",
- draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress.
-
- [TLS] Dierks, T. and, E. Rescorla, "The TLS Protocol Version
- 1.1", draft-ietf-tls-rfc2246-bis-xx.txt, a work in
- progress.
-
- [X.680] International Telecommunication Union -
- Telecommunication Standardization Sector, "Abstract
- Syntax Notation One (ASN.1) - Specification of Basic
- Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
-
- [X.690] International Telecommunication Union -
- Telecommunication Standardization Sector, "Specification
- of ASN.1 encoding rules: Basic Encoding Rules (BER),
- Canonical Encoding Rules (CER), and Distinguished
- Encoding Rules (DER)", X.690(2002) (also ISO/IEC
- 8825-1:2002).
-
-
-8.2. Informative References
-
- [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
- draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
-
- [GSSAPI] Linn, J., "Generic Security Service
- Application Program Interface, Version 2, Update 1", RFC
- 2743, January 2000.
-
- [DIGEST-MD5] Leach, P., C. Newman, and A. Melnikov, "Using Digest
- Authentication as a SASL Mechanism",
- draft-ietf-sasl-rfc2831bis-xx.txt, a work in progress.
-
-
-
-
-
-Zeilenga LDAP Turn Op [Page 8]
-
-INTERNET-DRAFT draft-zeilenga-ldap-turn-03 28 October 2005
-
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be found
- in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this specification
- can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-Full Copyright
-
- Copyright (C) The Internet Society (2005).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-Zeilenga LDAP Turn Op [Page 9]
-
diff --git a/doc/drafts/draft-zeilenga-ldap-uuid-xx.txt b/doc/drafts/draft-zeilenga-ldap-uuid-xx.txt
deleted file mode 100644
index 75a9ab1bd47e6879ba930f9b63158ee91caf3368..0000000000000000000000000000000000000000
--- a/doc/drafts/draft-zeilenga-ldap-uuid-xx.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-INTERNET-DRAFT Kurt D. Zeilenga
-Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 18 July 2005
-
-
-
- The LDAP entryUUID operational attribute
- <draft-zeilenga-ldap-uuid-06.txt>
-
-
-
-Status of this Memo
-
- This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor as an Standard Track document.
- Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDAP Extensions mailing list
- <ldapext@ietf.org>. Please send editorial comments directly to the
- author <Kurt@OpenLDAP.org>.
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware have
- been or will be disclosed, and any of which he or she becomes aware
- will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference material
- or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
- Copyright (C) The Internet Society (2005). All Rights Reserved.
-
- Please see the Full Copyright section near the end of this document
- for more information.
-
-
-Abstract
-
-
-
-Zeilenga draft-zeilenga-ldap-uuid-06 [Page 1]
-
-INTERNET-DRAFT LDAP entryUUID 18 July 2005
-
-
- This document describes the LDAP/X.500 'entryUUID' operational
- attribute and associated matching rules and syntax. The attribute
- holds a server-assigned Universally Unique Identifier (UUID) for the
- object. Directory clients may use this attribute to distinguish
- objects identified by a distinguished name or to locate an object
- after renaming.
-
-
-1. Background and Intended Use
-
- In X.500 Directory Services [X.501], such as those accessible using
- the Lightweight Directory Access Protocol (LDAP) [Roadmap], an object
- is identified by its distinguished name (DN). However, DNs are not
- stable identifiers. That is, a new object may be identified by a DN
- which previously identified another (now renamed or deleted) object.
-
- A Universally Unique Identifier (UUID) is "an identifier unique across
- both space and time, with respect to the space of all UUIDs"
- [UUIDURN]. UUIDs are used in a wide range of systems.
-
- This document describes the 'entryUUID' operational attribute which
- holds the UUID assigned to the object by the server. Clients may use
- this attribute to distinguish objects identified by a particular
- distinguished name or to locate a particular object after renaming.
-
- This document defines the UUID syntax, the 'uuidMatch' and
- 'uuidOrderingMatch' matching rules, and the 'entryUUID' attribute
- type.
-
- Schema definitions are provided using LDAP description formats
- [Models]. Definitions provided here are formatted (line wrapped) for
- readability.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119].
-
-
-2. UUID Schema Elements
-
-2.1 UUID Syntax
-
- A Universally Unique Identifier (UUID) [UUIDURN] is a 16-octet
- (128-bit) value which identifies an object. The ASN.1 [X.680] type
- UUID is defined to represent UUIDs as follows:
-
- UUID ::= OCTET STRING (SIZE(16))
- -- constrained to an UUID [UUIDURN]
-
-
-
-Zeilenga draft-zeilenga-ldap-uuid-06 [Page 2]
-
-INTERNET-DRAFT LDAP entryUUID 18 July 2005
-
-
- In LDAP, UUID values are encoded using the [ASCII] character string
- representation described in [UUIDURN]. For example,
- "597ae2f6-16a6-1027-98f4-d28b5365dc14".
-
- The following is a LDAP syntax description suitable for publication in
- subschema subentries.
-
- ( IANA-ASSIGNED-OID.1 DESC 'UUID' )
-
-
-2.2 'uuidMatch' Matching Rule
-
- The 'uuidMatch' matching rule compares an asserted UUID with a stored
- UUID for equality. Its semantics are same as the 'octetStringMatch'
- [X.520][Syntaxes] matching rule. The rule differs from
- 'octetStringMatch' in that the assertion value is encoded using the
- UUID string representation instead of the normal OCTET STRING string
- representation.
-
- The following is a LDAP matching rule description suitable for
- publication in subschema subentries.
-
- ( IANA-ASSIGNED-OID.2 NAME 'uuidMatch'
- SYNTAX IANA-ASSIGNED-OID.1 )
-
-
-2.3 'uuidOrderingMatch' Matching Rule
-
- The 'uuidOrderingMatch' matching rule compares an asserted UUID
- with a stored UUID for ordering. Its semantics are the same as the
- 'octetStringOrderingMatch' [X.520][Syntaxes] matching rule. The
- rule differs from 'octetStringOrderingMatch' in that the assertion
- value is encoded using the UUID string representation instead of
- the normal OCTET STRING string representation.
-
- The following is a LDAP matching rule description suitable for
- publication in subschema subentries.
-
- ( IANA-ASSIGNED-OID.3 NAME 'uuidOrderingMatch'
- SYNTAX IANA-ASSIGNED-OID.1 )
-
- It is noted that not all UUID variants have a defined ordering and,
- even where so, servers are not obligated to assign UUIDs in any
- particular order. This matching rule is provided for completeness.
-
-
-2.4. 'entryUUID' attribute
-
-
-
-
-Zeilenga draft-zeilenga-ldap-uuid-06 [Page 3]
-
-INTERNET-DRAFT LDAP entryUUID 18 July 2005
-
-
- The 'entryUUID' operational attribute provides the Universally Unique
- Identifier (UUID) assigned to the entry.
-
- The following is a LDAP attribute type description suitable for
- publication in subschema subentries.
-
- ( IANA-ASSIGNED-OID.4 NAME 'entryUUID'
- DESC 'UUID of the entry'
- EQUALITY uuidMatch
- ORDERING uuidOrderingMatch
- SYNTAX IANA-ASSIGNED-OID.1
- SINGLE-VALUE
- NO-USER-MODIFICATION
- USAGE directoryOperation )
-
- Servers SHALL generate and assign a new UUID to each entry upon its
- addition to the directory and provide that UUID as the value of the
- 'entryUUID' operational attribute. An entry's UUID is immutable.
-
- UUID are to be generated in accordance with Section 4 of [UUIDURN].
- In particular, servers MUST ensure that each generated UUID is unique
- in space and time.
-
-
-3. Security Considerations
-
- An entry's relative distinguish name (RDN) is composed from attribute
- values of the entry, values which are commonly descriptive of the
- object the entry represents. While deployers are encouraged to use
- naming attributes whose values are widely disclosable [LDAPDN],
- entries are often named using information which cannot be disclosed to
- all parties. As UUIDs do not contain any descriptive information of
- the object they identify, UUIDs may be used to identify a particular
- entry without disclosure of its contents.
-
- General UUID security considerations [UUIDURN] apply.
-
- General LDAP security considerations [RFC3377] apply.
-
-
-4. IANA Considerations
-
- It is requested that IANA register upon Standards Action the LDAP
- values specified in this document.
-
-
-4.1. Object Identifier Registration
-
-
-
-
-Zeilenga draft-zeilenga-ldap-uuid-06 [Page 4]
-
-INTERNET-DRAFT LDAP entryUUID 18 July 2005
-
-
- Subject: Request for LDAP OID Registration
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Specification: RFC XXXX
- Author/Change Controller: IESG
- Comments:
- Identifies the UUID schema elements
-
-
-4.2. UUID Syntax Registration
-
- Subject: Request for LDAP Syntax Registration
- Object Identifier: IANA-ASSIGNED-OID.1
- Description: UUID
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Specification: RFC XXXX
- Author/Change Controller: IESG
- Comments:
- Identifies the UUID syntax
-
-
-4.3. 'uuidMatch' Descriptor Registration
-
- Subject: Request for LDAP Descriptor Registration
- Descriptor (short name): uuidMatch
- Object Identifier: IANA-ASSIGNED-OID.2
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Usage: Matching Rule
- Specification: RFC XXXX
- Author/Change Controller: IESG
-
-
-4.3. 'uuidOrderingMatch' Descriptor Registration
-
- Subject: Request for LDAP Descriptor Registration
- Descriptor (short name): uuidOrderingMatch
- Object Identifier: IANA-ASSIGNED-OID.3
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Usage: Matching Rule
- Specification: RFC XXXX
- Author/Change Controller: IESG
-
-
-5.4. 'entryUUID' Descriptor Registration
-
-
-
-
-Zeilenga draft-zeilenga-ldap-uuid-06 [Page 5]
-
-INTERNET-DRAFT LDAP entryUUID 18 July 2005
-
-
- It is requested that IANA register upon Standards Action the LDAP
- 'entryUUID' descriptor.
-
- Subject: Request for LDAP Descriptor Registration
- Descriptor (short name): entryUUID
- Object Identifier: IANA-ASSIGNED-OID.4
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Usage: Attribute Type
- Specification: RFC XXXX
- Author/Change Controller: IESG
-
-
-6. Acknowledgments
-
- This document is based upon discussions in the LDAP Update and
- Duplication Protocols (LDUP) WG. Members of the LDAP Directorate
- provided review.
-
-
-7. Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- Email: Kurt@OpenLDAP.org
-
-
-8. References
-
- [[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn where
- possible.]]
-
-
-8.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
- [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
- Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
- progress.
-
- [UUIDURN] Leach, P, M. Mealling, R. Salz, "A UUID URN Namespace",
- a work in progress.
-
- [Models] Zeilenga, K. (editor), "LDAP: Directory Information
-
-
-
-Zeilenga draft-zeilenga-ldap-uuid-06 [Page 6]
-
-INTERNET-DRAFT LDAP entryUUID 18 July 2005
-
-
- Models", draft-ietf-ldapbis-models-xx.txt, a work in
- progress.
-
- [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules",
- draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
-
- [ASCII] Coded Character Set--7-bit American Standard Code for
- Information Interchange, ANSI X3.4-1986.
-
- [X.501] International Telecommunication Union -
- Telecommunication Standardization Sector, "The Directory
- -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
-
- [X.520] International Telecommunication Union -
- Telecommunication Standardization Sector, "The
- Directory: Selected Attribute Types", X.520(1993) (also
- ISO/IEC 9594-6:1994).
-
- [X.680] International Telecommunication Union -
- Telecommunication Standardization Sector, "Abstract
- Syntax Notation One (ASN.1) - Specification of Basic
- Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
-
-
-
-8.2. Informative References
-
- [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
- Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a
- work in progress.
-
- [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
- draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
-
-
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be found
- in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
-
-
-
-Zeilenga draft-zeilenga-ldap-uuid-06 [Page 7]
-
-INTERNET-DRAFT LDAP entryUUID 18 July 2005
-
-
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this specification
- can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-Full Copyright
-
- Copyright (C) The Internet Society (2005).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga draft-zeilenga-ldap-uuid-06 [Page 8]
-
diff --git a/doc/drafts/draft-zeilenga-ldap-x509-xx.txt b/doc/drafts/draft-zeilenga-ldap-x509-xx.txt
deleted file mode 100644
index e5ec986b70f44a18d470db83dc7c3094bcd67911..0000000000000000000000000000000000000000
--- a/doc/drafts/draft-zeilenga-ldap-x509-xx.txt
+++ /dev/null
@@ -1,1403 +0,0 @@
-
-
-
-
-
-
-INTERNET-DRAFT Kurt D. Zeilenga
-Intended Category: Standard Track OpenLDAP Foundation
-Expires in six months 18 July 2005
-Obsoletes: RFC 2252, RFC 2256, RFC 2587
-
-
- Lightweight Directory Access Protocol (LDAP) schema
- definitions for X.509 Certificates
- <draft-zeilenga-ldap-x509-02.txt>
-
-
-Status of this Memo
-
- This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor as an Standard Track document.
- Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDAP Extensions mailing list
- <ldapext@ietf.org>. Please send editorial comments directly to the
- author <Kurt@OpenLDAP.org>.
-
- This document is intended to be published in conjunction to the
- revised LDAP TS [Roadmap]. Together, this document and the revised
- LDAP TS obsoletes RFC 2252 and RFC 2256 in their entirety.
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware have
- been or will be disclosed, and any of which he or she becomes aware
- will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference material
- or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
-
- Copyright (C) The Internet Society (2005). All Rights Reserved.
-
- Please see the Full Copyright section near the end of this document
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 1]
-
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- for more information.
-
-
-Abstract
-
- This document describes schema for representing X.509 certificates,
- X.521 security information, and related elements in directories
- accessible using the Lightweight Directory Access Protocol (LDAP).
- The LDAP definitions for these X.509 and X.521 schema elements
- replaces those provided in RFC 2252 and RFC 2256.
-
-
-1. Background and Intended Use
-
- This document provides LDAP [Roadmap] schema definitions [Models] for
- a subset of elements specified in X.509 [X.509] and X.521 [X.521],
- including attribute types for certificates, cross certificate pairs,
- and certificate revocation lists; matching rules to be used with these
- attribute types; and related object classes. LDAP syntax definitions
- are also provided for associated assertion and attribute values.
-
- As the semantics of these elements are as defined in X.509 and X.521,
- knowledge of X.509 and X.521 is necessary to make use of the LDAP
- schema definitions provided herein.
-
- This document, together with [Roadmap], obsoletes RFC 2252 and RFC
- 2256 in their entirety. The changes (in this document) made since RFC
- 2252 and RFC 2256 include:
- - addition of pkiUser, pkiCA, and deltaCRL classes;
- - update of attribute types to include equality matching rules in
- accordance with their X.500 specifications;
- - addition of certificate, certificate pair, certificate list, and
- algorithm identifer matching rules; and
- - addition of LDAP syntax for assertion syntaxes for these matching
- rules.
-
- This document obsoletes RFC 2587. The X.509 schema descriptions for
- LDAPv2 [RFC1777] are Historic, as is LDAPv2 [RFC3494].
-
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119].
-
- Schema definitions are provided using LDAP description formats
- [Models]. Definitions provided here are formatted (line wrapped) for
- readability.
-
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 2]
-
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
-2. Syntaxes
-
- This section describes various syntaxes used in LDAP to transfer
- certificates and related data types.
-
-
-2.1. Certificate
-
- ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'X.509 Certificate' )
-
- A value of this syntax is an X.509 Certificate [X.509, clause 7].
-
- Due to changes made to the definition of a Certificate made through
- time, no LDAP-specific encoding is defined for this syntax. Values of
- this syntax SHOULD be encoded using Distinguished Encoding Rules (DER)
- [X.690] and MUST only be transferred using the ;binary transfer option
- [Binary]. That is, by requesting and returning values using attribute
- descriptions such as "userCertificate;binary".
-
- As values of this syntax contain digitally-signed data, values of this
- syntax, and the form of the value, MUST be preserved as presented.
-
-
-2.2. CertificateList
-
- ( 1.3.6.1.4.1.1466.115.121.1.9 DESC 'X.509 Certificate List' )
-
- A value of this syntax is an X.509 CertificateList [X.509, clause
- 7.3].
-
- Due to changes made to the definition of a CertificateList made
- through time, no LDAP-specific encoding is defined for this syntax.
- Values of this syntax SHOULD be encoded using DER [X.690] and MUST
- only be transferred using the ;binary transfer option [Binary]. That
- is, by requesting and returning values using attribute descriptions
- such as "certificateRevocationList;binary".
-
- As values of this syntax contain digitally-signed data, values of this
- syntax, and the form of the value, MUST be preserved as presented.
-
-
-2.3. CertificatePair
-
- ( 1.3.6.1.4.1.1466.115.121.1.10 DESC 'X.509 Certificate Pair' )
-
- A value of this syntax is an X.509 CertificatePair [X.509, clause
- 11.2.3].
-
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 3]
-
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- Due to changes made to the definition of an X.509 CertificatePair made
- through time, no LDAP-specific encoding is defined for this syntax.
- Values of this syntax SHOULD be encoded using DER [X.690] and MUST
- only be transferred using the ;binary transfer option [Binary]. That
- is, by requesting and returning values using attribute descriptions
- such as "crossCertificatePair;binary".
-
- As values of this syntax contain digitally-signed data, values of this
- syntax, and the form of the value, MUST be preserved as presented.
-
-2.4 SupportedAlgorithm
-
- ( 1.3.6.1.4.1.1466.115.121.1.49
- DESC 'X.509 Supported Algorithm' )
-
- A value of this syntax is an X.509 SupportedAlgorithm [X.509, clause
- 11.2.7].
-
- Due to changes made to the definition of an X.509 SupportedAlgorithm
- made through time, no LDAP-specific encoding is defined for this
- syntax. Values of this syntax SHOULD be encoded using DER [X.690] and
- MUST only be transferred using the ;binary transfer option [Binary].
- That is, by requesting and returning values using attribute
- descriptions such as "supportedAlgorithms;binary".
-
- As values of this syntax contain digitally-signed data, values of this
- syntax, and the form of the value, MUST be preserved as presented.
-
-
-2.5. CertificateExactAssertion
-
- ( IANA-ASSIGNED-OID.1 DESC 'X.509 Certificate Exact Assertion' )
-
- A value of this syntax is an X.509 CertificateExactAssertion [X.509,
- clause 11.3.1]. Values of this syntax MUST be encoded using the
- Generic String Encoding Rules (GSER) [RFC3641]. Appendix A.1 provides
- an equivalent Augmented Backus-Naur Form (ABNF) [ABNF] grammar for
- this syntax.
-
-
-2.6. CertificateAssertion
-
- ( IANA-ASSIGNED-OID.2 DESC 'X.509 Certificate Assertion' )
-
- A value of this syntax is an X.509 CertificateAssertion [X.509, clause
- 11.3.2]. Values of this syntax MUST be encoded using GSER [RFC3641].
- Appendix A.2 provides an equivalent ABNF [ABNF] grammar for this
- syntax.
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 4]
-
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
-2.7. CertificatePairExactAssertion
-
- ( IANA-ASSIGNED-OID.3
- DESC 'X.509 Certificate Pair Exact Assertion' )
-
- A value of this syntax is an X.509 CertificatePairExactAssertion
- [X.509, clause 11.3.3]. Values of this syntax MUST be encoded using
- GSER [RFC3641]. Appendix A.3 provides an equivalent ABNF [ABNF]
- grammar for this syntax.
-
-
-2.8. CertificatePairAssertion
-
- ( IANA-ASSIGNED-OID.4 DESC 'X.509 Certificate Pair Assertion' )
-
- A value of this syntax is an X.509 CertificatePairAssertion [X.509,
- clause 11.3.4]. Values of this syntax MUST be encoded using GSER
- [RFC3641]. Appendix A.4 provides an equivalent ABNF [ABNF] grammar
- for this syntax.
-
-
-2.9. CertificateListExactAssertion
-
- ( IANA-ASSIGNED-OID.5
- DESC 'X.509 Certificate List Exact Assertion' )
-
- A value of this syntax is an X.509 CertificateListExactAssertion
- [X.509, clause 11.3.5]. Values of this syntax MUST be encoded using
- GSER [RFC3641]. Appendix A.5 provides an equivalent ABNF grammar for
- this syntax.
-
-
-2.10. CertificateListAssertion
-
- ( IANA-ASSIGNED-OID.6 DESC 'X.509 Certificate List Assertion' )
-
- A value of this syntax is an X.509 CertificateListAssertion [X.509,
- clause 11.3.6]. Values of this syntax MUST be encoded using GSER
- [RFC3641]. Appendix A.6 provides an equivalent ABNF [ABNF] grammar
- for this syntax.
-
-
-2.11 AlgorithmIdentifier
-
- ( IANA-ASSIGNED-OID.7 DESC 'X.509 Algorithm Identifier' )
-
- A value of this syntax is an X.509 AlgorithmIdentifier [X.509, Clause
- 7]. Values of this syntax MUST be encoded using GSER [RFC3641].
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 5]
-
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- Appendix A.7 provides an equivalent ABNF [ABNF] grammar for this
- syntax.
-
-
-3. Matching Rules
-
- This section introduces a set of certificate and related matching
- rules for use in LDAP. These rules are intended to act in accordance
- with their X.500 counterparts.
-
-
-3.1. certificateExactMatch
-
- The certificateExactMatch matching rule compares the presented
- certificate exact assertion value with an attribute value of the
- certificate syntax as described in clause 11.3.1 of [X.509].
-
- ( 2.5.13.34 NAME 'certificateExactMatch'
- DESC 'X.509 Certificate Exact Match'
- SYNTAX IANA-ASSIGNED-OID.1 )
-
-
-3.2. certificateMatch
-
- The certificateMatch matching rule compares the presented certificate
- assertion value with an attribute value of the certificate syntax as
- described in clause 11.3.2 of [X.509].
-
- ( 2.5.13.35 NAME 'certificateMatch'
- DESC 'X.509 Certificate Match'
- SYNTAX IANA-ASSIGNED-OID.2 )
-
-
-3.3. certificatePairExactMatch
-
- The certificatePairExactMatch matching rule compares the presented
- certificate pair exact assertion value with an attribute value of the
- certificate pair syntax as described in clause 11.3.3 of [X.509].
-
- ( 2.5.13.36 NAME 'certificatePairExactMatch'
- DESC 'X.509 Certificate Pair Exact Match'
- SYNTAX IANA-ASSIGNED-OID.3 )
-
-
-3.4. certificatePairMatch
-
- The certificatePairMatch matching rule compares the presented
- certificate pair assertion value with an attribute value of the
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 6]
-
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- certificate pair syntax as described in clause 11.3.4 of [X.509].
-
- ( 2.5.13.37 NAME 'certificatePairMatch'
- DESC 'X.509 Certificate Pair Match'
- SYNTAX IANA-ASSIGNED-OID.4 )
-
-
-3.5. certificateListExactMatch
-
- The certificateListExactMatch matching rule compares the presented
- certificate list exact assertion value with an attribute value of the
- certificate pair syntax as described in clause 11.3.5 of [X.509].
-
- ( 2.5.13.38 NAME 'certificateListExactMatch'
- DESC 'X.509 Certificate List Exact Match'
- SYNTAX IANA-ASSIGNED-OID.5 )
-
-
-3.6. certificateListMatch
-
- The certificateListMatch matching rule compares the presented
- certificate list assertion value with an attribute value of the
- certificate pair syntax as described in clause 11.3.6 of [X.509].
-
- ( 2.5.13.39 NAME 'certificateListMatch'
- DESC 'X.509 Certificate List Match'
- SYNTAX IANA-ASSIGNED-OID.6 )
-
-
-3.7. algorithmIdentifierMatch
-
- The algorithmIdentifierMatch mating rule compares a presented
- algorithm identifier with an attribute value of supported algorithm as
- described in clause 11.3.7 of [X.509].
-
- ( 2.5.13.40 NAME 'algorithmIdentifier'
- DESC 'X.509 Algorithm Identifier Match'
- SYNTAX IANA-ASSIGNED-OID.7 )
-
-
-4. Attribute Types
-
- This section details a set of certificate and related attribute types
- for use in LDAP.
-
-
-4.1. userCertificate
-
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 7]
-
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- The userCertificate attribute holds the X.509 certificates issued to
- the user by one or more certificate authorities, as discussed in
- clause 11.2.1 of [X.509].
-
- ( 2.5.4.36 NAME 'userCertificate'
- DESC 'X.509 user certificate'
- EQUALITY certificateExactMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
-
- As required by this attribute type's syntax, values of this attribute
- are requested and transferred using the attribute description
- "userCertificate;binary".
-
-
-4.2. cACertificate
-
- The cACertificate attribute holds the X.509 certificates issued to the
- certificate authority (CA), as discussed in clause 11.2.2 of [X.509].
-
- ( 2.5.4.37 NAME 'cACertificate'
- DESC 'X.509 CA certificate'
- EQUALITY certificateExactMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
-
- As required by this attribute type's syntax, values of this attribute
- are requested and transferred using the attribute description
- "cACertificate;binary".
-
-
-4.3. crossCertificatePair
-
- The crossCertificatePair attribute holds an X.509 certificate pair, as
- discussed in clause 11.2.3 of [X.509].
-
- ( 2.5.4.40 NAME 'crossCertificatePair'
- DESC 'X.509 cross certificate pair'
- EQUALITY certificatePairExactMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.10 )
-
- As required by this attribute type's syntax, values of this attribute
- are requested and transferred using the attribute description
- "crossCertificatePair;binary".
-
-
-4.4. certificateRevocationList
-
- The certificateRevocationList attribute holds certificate lists, as
- discussed in 11.2.4 of [X.509].
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 8]
-
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- ( 2.5.4.39 NAME 'certificateRevocationList'
- DESC 'X.509 certificate revocation list'
- EQUALITY certificateListExactMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
-
- As required by this attribute type's syntax, values of this attribute
- are requested and transferred using the attribute description
- "certificateRevocationList;binary".
-
-
-4.5. authorityRevocationList
-
- The authorityRevocationList attribute holds certificate lists, as
- discussed in 11.2.5 of [X.509].
-
- ( 2.5.4.38 NAME 'authorityRevocationList'
- DESC 'X.509 authority revocation list'
- EQUALITY certificateListExactMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
-
- As required by this attribute type's syntax, values of this attribute
- are requested and transferred using the attribute description
- "authorityRevocationList;binary".
-
-
-4.6. deltaRevocationList
-
- The deltaRevocationList attribute holds certificate lists, as
- discussed in 11.2.6 of [X.509].
-
- ( 2.5.4.53 NAME 'deltaRevocationList'
- DESC 'X.509 delta revocation list'
- EQUALITY certificateListExactMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
-
- As required by this attribute type's syntax, values of this attribute
- MUST be requested and transferred using the attribute description
- "deltaRevocationList;binary".
-
-
-4.7. supportedAlgorithms
-
- The supportedAlgorithms attribute holds supported algorithms, as
- discussed in 11.2.7 of [X.509].
-
- ( 2.5.4.52 NAME 'supportedAlgorithms'
- DESC 'X.509 supported algorithms'
- EQUALITY algorithmIdentifierMatch
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 9]
-
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.49 )
-
- As required by this attribute type's syntax, values of this attribute
- MUST be requested and transferred using the attribute description
- "supportedAlgorithms;binary".
-
-
-5. Object Classes
-
- This section details a set of certificate-related object classes for
- use in LDAP.
-
-
-5.1. pkiUser
-
- This object class is used in augment entries for objects that may be
- subject to certificates, as defined in clause 11.1.1 of [X.509].
-
- ( 2.5.6.21 NAME 'pkiUser'
- DESC 'X.509 PKI User'
- SUP top AUXILIARY
- MAY userCertificate )
-
-
-5.2. pkiCA
-
- This object class is used to augment entries for objects which act as
- certificate authorities, as defined in clause 11.1.2 of [X.509]
-
- ( 2.5.6.22 NAME 'pkiCA'
- DESC 'X.509 PKI Certificate Authority'
- SUP top AUXILIARY
- MAY ( cACertificate $ certificateRevocationList $
- authorityRevocationList $ crossCertificatePair ) )
-
-
-5.3. cRLDistributionPoint
-
- This class is used to represent objects which act as CRL distribution
- points, as discussed in clause 11.1.3 of [X.509].
-
- ( 2.5.6.19 NAME 'cRLDistributionPoint'
- DESC 'X.509 CRL distribution point'
- SUP top STRUCTURAL
- MUST cn
- MAY ( certificateRevocationList $
- authorityRevocationList $ deltaRevocationList ) )
-
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 10]
-
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
-5.4 deltaCRL
-
- The deltaCRL object class is used to augment entries to hold delta
- revocation lists, as discussed in clause 11.1.4 of [X.509].
-
- ( 2.5.6.23 NAME 'deltaCRL'
- DESC 'X.509 delta CRL'
- SUP top AUXILIARY
- MAY deltaRevocationList )
-
-
-5.5. strongAuthenticationUser
-
- This object class is used to augment entries for objects participating
- in certificate-based authentication, as defined in clause 6.15 of
- [X.521]. This object class is deprecated in favor of pkiUser.
-
- ( 2.5.6.15 NAME 'strongAuthenticationUser'
- DESC 'X.521 strong authentication user'
- SUP top AUXILIARY
- MUST userCertificate )
-
-
-5.6. userSecurityInformation
-
- This object class is used to augment entries with needed additional
- associated security information, as defined in clause 6.16 of [X.521].
-
- ( 2.5.6.18 NAME 'userSecurityInformation'
- DESC 'X.521 user security information'
- SUP top AUXILIARY
- MAY ( supportedAlgorithms ) )
-
-
-5.7. certificationAuthority
-
- This object class is used to augment entries for objects which act as
- certificate authorities, as defined in clause 6.17 of [X.521]. This
- object class is deprecated in favor of pkiCA.
-
- ( 2.5.6.16 NAME 'certificationAuthority'
- DESC 'X.509 certificate authority'
- SUP top AUXILIARY
- MUST ( authorityRevocationList $
- certificateRevocationList $ cACertificate )
- MAY crossCertificatePair )
-
-
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 11]
-
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
-5.8. certificationAuthority-V2
-
- This object class is used to augment entries for objects which act as
- certificate authorities, as defined in clause 6.18 of [X.521]. This
- object class is deprecated in favor of pkiCA.
-
- ( 2.5.6.16.2 NAME 'certificationAuthority-V2'
- DESC 'X.509 certificate authority, version 2'
- SUP certificationAuthority AUXILIARY
- MAY deltaRevocationList )
-
-
-6. Security Considerations
-
- General certificate considerations [RFC3280] apply to LDAP-aware
- certificate applications. General LDAP security considerations
- [Roadmap] apply as well.
-
- While elements of certificate information are commonly signed, these
- signatures only protect the integrity of the signed information. In
- the absence of a data integrity protections in LDAP (or lower layer,
- e.g. IPsec), a server is not assured that client certificate request
- (or other request) was unaltered in transit. Likewise, a client
- cannot be assured that the results of the query were unaltered in
- transit. Hence, it is generally recommended implementations make use
- of authentication and data integrity services in LDAP
- [AuthMeth][Protocol].
-
-
-7. IANA Considerations
-
-7.1. Object Identifier Registration
-
- It is requested that IANA register upon Standards Action an LDAP
- Object Identifier for use in this technical specification.
-
- Subject: Request for LDAP OID Registration
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Specification: RFC XXXX
- Author/Change Controller: IESG
- Comments:
- Identifies the LDAP X.509 Certificate schema elements
- introduced in this document.
-
-
-7.2. Registration of the descriptor
-
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 12]
-
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- It is requested that IANA update upon Standards Action the LDAP
- Descriptor registry as indicated below.
-
- Subject: Request for LDAP Descriptor Registration
- Descriptor (short name): see table
- Object Identifier: see table
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Usage: see table
- Specification: RFC XXXX
- Author/Change Controller: IESG
-
- algorithmIdentifierMatch R 2.5.13.40
- authorityRevocationList A 2.5.4.38 *
- cACertificate A 2.5.4.37 *
- cRLDistributionPoint O 2.5.6.19 *
- certificateExactMatch R 2.5.13.34
- certificateListExactMatch R 2.5.13.38
- certificateListMatch R 2.5.13.39
- certificateMatch R 2.5.13.35
- certificatePairExactMatch R 2.5.13.36
- certificatePairMatch R 2.5.13.37
- certificateRevocationList A 2.5.4.39 *
- certificationAuthority O 2.5.6.16 *
- certificationAuthority-V2 O 2.5.6.16.2 *
- crossCertificatePair A 2.5.4.40 *
- deltaCRL O 2.5.6.23 *
- deltaRevocationList A 2.5.4.53 *
- pkiCA O 2.5.6.22 *
- pkiUser O 2.5.6.21 *
- strongAuthenticationUser O 2.5.6.15 *
- supportedAlgorithms A 2.5.4.52 *
- userCertificate A 2.5.4.36 *
- userSecurityInformation O 2.5.6.18 *
-
- * Updates previous registration
-
-
-8. Acknowledgments
-
- This document is based upon X.509, a product of the ITU-T. A number
- of LDAP schema definitions were based on those found in RFC 2252 and
- RFC 2256, both products of the IETF ASID WG. The ABNF productions in
- Appendix A were provided by Steven Legg. Additional material was
- borrowed from prior works by David Chadwick and Steven Legg to refine
- the LDAP X.509 schema.
-
-
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 13]
-
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
-9. Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- Email: Kurt@OpenLDAP.org
-
-
-10. References
-
- [[Note to the RFC Editor: please replace the citation tags used in
- referencing Internet-Drafts with tags of the form RFCnnnn where
- possible.]]
-
-
-10.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
- [RFC3641] Legg, S., "Generic String Encoding Rules for ASN.1
- Types", RFC 3641, October 2003.
-
- [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
- Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
- progress.
-
- [Models] Zeilenga, K. (editor), "LDAP: Directory Information
- Models", draft-ietf-ldapbis-models-xx.txt, a work in
- progress.
-
- [Binary] Legg, S., "Lightweight Directory Access Protocol (LDAP):
- The Binary Encoding Option",
- draft-legg-ldap-binary-xx.txt, a work in progress.
-
- [X.509] International Telecommunication Union -
- Telecommunication Standardization Sector, "The
- Directory: Authentication Framework", X.509(2000).
-
- [X.521] International Telecommunication Union -
- Telecommunication Standardization Sector, "The
- Directory: Selected Object Classes", X.521(2000).
-
- [X.680] International Telecommunication Union -
- Telecommunication Standardization Sector, "Abstract
- Syntax Notation One (ASN.1) - Specification of Basic
- Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
-
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 14]
-
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- [X.690] International Telecommunication Union -
- Telecommunication Standardization Sector, "Specification
- of ASN.1 encoding rules: Basic Encoding Rules (BER),
- Canonical Encoding Rules (CER), and Distinguished
- Encoding Rules (DER)", X.690(2002) (also ISO/IEC
- 8825-1:2002).
-
-
-11.2. Informative References
-
- [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", draft-crocker-abnf-rfc2234bis, a
- work in progress.
-
- [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
- Connection Level Security Mechanisms",
- draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
-
- [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
- draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
-
- [RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay):
- Mapping between X.400 and RFC 822/MIME", RFC 2156,
- January 1998.
-
- [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
- X.509 Public Key Infrastructure Certificate and
- Certificate Revocation List (CRL) Profile", RFC 3280,
- April 2002.
-
- [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
- (also RFC 3383), September 2002.
-
- [RFC3642] Legg, S., "Common Elements of GSER Encodings", RFC 3642,
- October 2003.
-
- [RFC3687] Legg, S., "Lightweight Directory Access Protocol (LDAP)
- and X.500 Component Matching Rules", RFC 3687, February
- 2004.
-
- [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP",
- draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
-
-
-Appendix A.
-
- This appendix is informative.
-
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 15]
-
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- This appendix provides ABNF [ABNF] grammars for GSER-based [RFC3687]
- LDAP-specific encodings specified in this document. These grammars
- where produced using, and relying on, Common Elements for GSER
- Encodings [RFC3342].
-
-
-A.1. CertificateExactAssertion
-
- CertificateExactAssertion = "{" sp cea-serialNumber ","
- sp cea-issuer sp "}"
-
- cea-serialNumber = id-serialNumber msp CertificateSerialNumber
- cea-issuer = id-issuer msp Name
-
- id-serialNumber =
- %x73.65.72.69.61.6C.4E.75.6D.62.65.72 ; 'serialNumber'
- id-issuer = %x69.73.73.75.65.72 ; 'issuer'
-
- Name = id-rdnSequence ":" RDNSequence
- id-rdnSequence = %x72.64.6E.53.65.71.75.65.6E.63.65 ; 'rdnSequence'
-
- CertificateSerialNumber = INTEGER
-
-
-A.2. CertificateAssertion
-
- CertificateAssertion = "{" [ sp ca-serialNumber ]
- [ sep sp ca-issuer ]
- [ sep sp ca-subjectKeyIdentifier ]
- [ sep sp ca-authorityKeyIdentifier ]
- [ sep sp ca-certificateValid ]
- [ sep sp ca-privateKeyValid ]
- [ sep sp ca-subjectPublicKeyAlgID ]
- [ sep sp ca-keyUsage ]
- [ sep sp ca-subjectAltName ]
- [ sep sp ca-policy ]
- [ sep sp ca-pathToName ]
- [ sep sp ca-subject ]
- [ sep sp ca-nameConstraints ] sp "}"
-
- ca-serialNumber = id-serialNumber msp CertificateSerialNumber
- ca-issuer = id-issuer msp Name
- ca-subjectKeyIdentifier = id-subjectKeyIdentifier msp
- SubjectKeyIdentifier
- ca-authorityKeyIdentifier = id-authorityKeyIdentifier msp
- AuthorityKeyIdentifier
- ca-certificateValid = certificateValid msp Time
- ca-privateKeyValid = id-privateKeyValid msp GeneralizedTime
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 16]
-
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- ca-subjectPublicKeyAlgID = id-subjectPublicKeyAlgID msp
- OBJECT-IDENTIFIER
- ca-keyUsage = id-keyUsage msp KeyUsage
- ca-subjectAltName = id-subjectAltName msp AltNameType
- ca-policy = id-policy msp CertPolicySet
- ca-pathToName = id-pathToName msp Name
- ca-subject = id-subject msp Name
- ca-nameConstraints = id-nameConstraints msp NameConstraintsSyntax
-
- id-subjectKeyIdentifier =
- %x73.75.62.6A.65.63.74.4B.65.79.49.64.65.6E.74.69.66.69.65.72
- ; 'subjectKeyIdentifier'
- id-authorityKeyIdentifier =
- %x61.75.74.68.6F.72.69.74.79.4B.65.79.49.64.65.6E.74.69.66.69.65.72
- ; 'authorityKeyIdentifier'
- id-certificateValid = %x63.65.72.74.69.66.69.63.61.74.65.56.61.6C.69.64
- ; 'certificateValid'
- id-privateKeyValid = %x70.72.69.76.61.74.65.4B.65.79.56.61.6C.69.64
- ; 'privateKeyValid'
- id-subjectPublicKeyAlgID =
- %x73.75.62.6A.65.63.74.50.75.62.6C.69.63.4B.65.79.41.6C.67.49.44
- ; 'subjectPublicKeyAlgID'
- id-keyUsage = %x6B.65.79.55.73.61.67.65 ; 'keyUsage'
- id-subjectAltName = %x73.75.62.6A.65.63.74.41.6C.74.4E.61.6D.65
- ; 'subjectAltName'
- id-policy = %x70.6F.6C.69.63.79 ; 'policy'
- id-pathToName = %x70.61.74.68.54.6F.4E.61.6D.65 ; 'pathToName'
- id-subject = %x73.75.62.6A.65.63.74 ; 'subject'
- id-nameConstraints = %x6E.61.6D.65.43.6F.6E.73.74.72.61.69.6E.74.73
- ; 'nameConstraints'
-
- SubjectKeyIdentifier = KeyIdentifier
-
- KeyIdentifier = OCTET-STRING
-
- AuthorityKeyIdentifier = "{" [ sp aki-keyIdentifier ]
- [ sep sp aki-authorityCertIssuer ]
- [ sep sp aki-authorityCertSerialNumber ] sp "}"
-
- aki-keyIdentifier = id-keyIdentifier msp KeyIdentifier
- aki-authorityCertIssuer = id-authorityCertIssuer msp GeneralNames
-
- GeneralNames = "{" sp GeneralName *( "," sp GeneralName ) sp "}"
- GeneralName = gn-otherName
- / gn-rfc822Name
- / gn-dNSName
- / gn-x400Address
- / gn-directoryName
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 17]
-
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- / gn-ediPartyName
- / gn-uniformResourceIdentifier
- / gn-iPAddress
- / gn-registeredID
-
- gn-otherName = id-otherName ":" OtherName
- gn-rfc822Name = id-rfc822Name ":" IA5String
- gn-dNSName = id-dNSName ":" IA5String
- gn-x400Address = id-x400Address ":" ORAddress
- gn-directoryName = id-directoryName ":" Name
- gn-ediPartyName = id-ediPartyName ":" EDIPartyName
- gn-iPAddress = id-iPAddress ":" OCTET-STRING
- gn-registeredID = gn-id-registeredID ":" OBJECT-IDENTIFIER
-
- gn-uniformResourceIdentifier = id-uniformResourceIdentifier
- ":" IA5String
-
- id-otherName = %x6F.74.68.65.72.4E.61.6D.65 ; 'otherName'
- gn-id-registeredID = %x72.65.67.69.73.74.65.72.65.64.49.44
- ; 'registeredID'
-
- OtherName = "{" sp on-type-id "," sp on-value sp "}"
- on-type-id = id-type-id msp OBJECT-IDENTIFIER
- on-value = id-value msp Value
- ;; <Value> as defined in Section 8 of [RFC3786]
-
- id-type-id = %x74.79.70.65.2D.69.64 ; 'type-id'
- id-value = %x76.61.6C.75.65 ; 'value'
-
- ORAddress = dquote *SafeIA5Character dquote
- SafeIA5Character = %x01-21 / %x23-7F / ; ASCII minus dquote
- dquote dquote ; escaped double quote
- dquote = %x22 ; '"' (double quote)
-
- ;; Note: The <ORAddress> rule encodes the x400Address component
- ;; of a GeneralName as a character string between double quotes.
- ;; The character string is first derived according to Section 4.1
- ;; of [RFC2156], and then any embedded double quotes are escaped
- ;; by being repeated. This resulting string is output between
- ;; double quotes.
-
- EDIPartyName = "{" [ sp nameAssigner "," ] sp partyName sp "}"
- nameAssigner = id-nameAssigner msp DirectoryString
- partyName = id-partyName msp DirectoryString
- id-nameAssigner = %x6E.61.6D.65.41.73.73.69.67.6E.65.72
- ; 'nameAssigner'
- id-partyName = %x70.61.72.74.79.4E.61.6D.65 ; 'partyName'
-
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 18]
-
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- aki-authorityCertSerialNumber = id-authorityCertSerialNumber
- msp CertificateSerialNumber
-
- id-keyIdentifier = %x6B.65.79.49.64.65.6E.74.69.66.69.65.72
- ; 'keyIdentifier'
- id-authorityCertIssuer =
- %x61.75.74.68.6F.72.69.74.79.43.65.72.74.49.73.73.75.65.72
- ; 'authorityCertIssuer'
-
- id-authorityCertSerialNumber = %x61.75.74.68.6F.72.69.74.79.43
- %x65.72.74.53.65.72.69.61.6C.4E.75.6D.62.65.72
- ; 'authorityCertSerialNumber'
-
- Time = time-utcTime / time-generalizedTime
- time-utcTime = id-utcTime ":" UTCTime
- time-generalizedTime = id-generalizedTime ":" GeneralizedTime
- id-utcTime = %x75.74.63.54.69.6D.65 ; 'utcTime'
- id-generalizedTime = %x67.65.6E.65.72.61.6C.69.7A.65.64.54.69.6D.65
- ; 'generalizedTime'
-
- KeyUsage = BIT-STRING / key-usage-bit-list
- key-usage-bit-list = "{" [ sp key-usage *( "," sp key-usage ) ] sp "}"
-
- ;; Note: The <key-usage-bit-list> rule encodes the one bits in
- ;; a KeyUsage value as a comma separated list of identifiers.
-
- key-usage = id-digitalSignature
- / id-nonRepudiation
- / id-keyEncipherment
- / id-dataEncipherment
- / id-keyAgreement
- / id-keyCertSign
- / id-cRLSign
- / id-encipherOnly
- / id-decipherOnly
-
- id-digitalSignature = %x64.69.67.69.74.61.6C.53.69.67.6E.61.74
- %x75.72.65 ; 'digitalSignature'
- id-nonRepudiation = %x6E.6F.6E.52.65.70.75.64.69.61.74.69.6F.6E
- ; 'nonRepudiation'
- id-keyEncipherment = %x6B.65.79.45.6E.63.69.70.68.65.72.6D.65.6E.74
- ; 'keyEncipherment'
- id-dataEncipherment = %x64.61.74.61.45.6E.63.69.70.68.65.72.6D.65.6E
- %x74 ; "dataEncipherment'
- id-keyAgreement = %x6B.65.79.41.67.72.65.65.6D.65.6E.74
- ; 'keyAgreement'
- id-keyCertSign = %x6B.65.79.43.65.72.74.53.69.67.6E
- ; 'keyCertSign'
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 19]
-
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- id-cRLSign = %x63.52.4C.53.69.67.6E ; "cRLSign"
- id-encipherOnly = %x65.6E.63.69.70.68.65.72.4F.6E.6C.79
- ; 'encipherOnly'
- id-decipherOnly = %x64.65.63.69.70.68.65.72.4F.6E.6C.79
- ; 'decipherOnly'
-
- AltNameType = ant-builtinNameForm / ant-otherNameForm
-
- ant-builtinNameForm = id-builtinNameForm ":" BuiltinNameForm
- ant-otherNameForm = id-otherNameForm ":" OBJECT-IDENTIFIER
-
- id-builtinNameForm = %x62.75.69.6C.74.69.6E.4E.61.6D.65.46.6F.72.6D
- ; 'builtinNameForm'
- id-otherNameForm = %x6F.74.68.65.72.4E.61.6D.65.46.6F.72.6D
- ; 'otherNameForm'
-
- BuiltinNameForm = id-rfc822Name
- / id-dNSName
- / id-x400Address
- / id-directoryName
- / id-ediPartyName
- / id-uniformResourceIdentifier
- / id-iPAddress
- / id-registeredId
-
- id-rfc822Name = %x72.66.63.38.32.32.4E.61.6D.65 ; 'rfc822Name'
- id-dNSName = %x64.4E.53.4E.61.6D.65 ; 'dNSName'
- id-x400Address = %x78.34.30.30.41.64.64.72.65.73.73 ; 'x400Address'
- id-directoryName = %x64.69.72.65.63.74.6F.72.79.4E.61.6D.65
- ; 'directoryName'
- id-ediPartyName = %x65.64.69.50.61.72.74.79.4E.61.6D.65
- ; 'ediPartyName'
- id-iPAddress = %x69.50.41.64.64.72.65.73.73 ; 'iPAddress'
- id-registeredId = %x72.65.67.69.73.74.65.72.65.64.49.64
- ; 'registeredId'
-
- id-uniformResourceIdentifier = %x75.6E.69.66.6F.72.6D.52.65.73.6F.75
- %x72.63.65.49.64.65.6E.74.69.66.69.65.72
- ; 'uniformResourceIdentifier'
-
- CertPolicySet = "{" sp CertPolicyId *( "," sp CertPolicyId ) sp "}"
- CertPolicyId = OBJECT-IDENTIFIER
-
- NameConstraintsSyntax = "{" [ sp ncs-permittedSubtrees ]
- [ sep sp ncs-excludedSubtrees ] sp "}"
-
- ncs-permittedSubtrees = id-permittedSubtrees msp GeneralSubtrees
- ncs-excludedSubtrees = id-excludedSubtrees msp GeneralSubtrees
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 20]
-
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- id-permittedSubtrees =
- %x70.65.72.6D.69.74.74.65.64.53.75.62.74.72.65.65.73
- ; 'permittedSubtrees'
- id-excludedSubtrees =
- %x65.78.63.6C.75.64.65.64.53.75.62.74.72.65.65.73
- ; 'excludedSubtrees'
-
- GeneralSubtrees = "{" sp GeneralSubtree
- *( "," sp GeneralSubtree ) sp "}"
- GeneralSubtree = "{" sp gs-base
- [ "," sp gs-minimum ]
- [ "," sp gs-maximum ] sp "}"
-
- gs-base = id-base msp GeneralName
- gs-minimum = id-minimum msp BaseDistance
- gs-maximum = id-maximum msp BaseDistance
-
- id-base = %x62.61.73.65 ; 'base'
- id-minimum = %x6D.69.6E.69.6D.75.6D ; 'minimum'
- id-maximum = %x6D.61.78.69.6D.75.6D ; 'maximum'
-
- BaseDistance = INTEGER-0-MAX
-
-
-A.3. CertificatePairExactAssertion
-
- CertificatePairExactAssertion = "{" [ sp cpea-issuedTo ]
- [sep sp cpea-issuedBy ] sp "}"
- ;; At least one of <cpea-issuedTo> or <cpea-issuedBy> MUST be present.
-
- cpea-issuedTo = id-issuedToThisCAAssertion msp
- CertificateExactAssertion
- cpea-issuedBy = id-issuedByThisCAAssertion msp
- CertificateExactAssertion
-
- id-issuedToThisCAAssertion = %x69.73.73.75.65.64.54.6F.54.68.69.73
- %x43.41.41.73.73.65.72.74.69.6F.6E ; 'issuedToThisCAAssertion'
- id-issuedByThisCAAssertion = %x69.73.73.75.65.64.42.79.54.68.69.73
- %x43.41.41.73.73.65.72.74.69.6F.6E ; 'issuedByThisCAAssertion'
-
-
-A.4. CertificatePairAssertion
-
- CertificatePairAssertion = "{" [ sp cpa-issuedTo ]
- [sep sp cpa-issuedBy ] sp "}"
- ;; At least one of <cpa-issuedTo> and <cpa-issuedBy> MUST be present.
-
- cpa-issuedTo = id-issuedToThisCAAssertion msp CertificateAssertion
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 21]
-
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- cpa-issuedBy = id-issuedByThisCAAssertion msp CertificateAssertion
-
-
-A.5. CertificateListExactAssertion
-
- CertificateListExactAssertion = "{" sp clea-issuer ","
- sp clea-thisUpdate
- [ "," sp clea-distributionPoint ] sp "}"
-
- clea-issuer = id-issuer msp Name
- clea-thisUpdate = id-thisUpdate msp Time
- clea-distributionPoint = id-distributionPoint msp
- DistributionPointName
-
- id-thisUpdate = %x74.68.69.73.55.70.64.61.74.65 ; 'thisUpdate'
- id-distributionPoint =
- %x64.69.73.74.72.69.62.75.74.69.6F.6E.50.6F.69.6E.74
- ; 'distributionPoint'
-
- DistributionPointName = dpn-fullName / dpn-nameRelativeToCRLIssuer
-
- dpn-fullName = id-fullName ":" GeneralNames
- dpn-nameRelativeToCRLIssuer = id-nameRelativeToCRLIssuer ":"
- RelativeDistinguishedName
-
- id-fullName = %x66.75.6C.6C.4E.61.6D.65 ; 'fullName'
- id-nameRelativeToCRLIssuer = %x6E.61.6D.65.52.65.6C.61.74.69.76.65
- %x54.6F.43.52.4C.49.73.73.75.65.72 ; 'nameRelativeToCRLIssuer'
-
-
-A.6. CertificateListAssertion
-
- CertificateListAssertion = "{" [ sp cla-issuer ]
- [ sep sp cla-minCRLNumber ]
- [ sep sp cla-maxCRLNumber ]
- [ sep sp cla-reasonFlags ]
- [ sep sp cla-dateAndTime ]
- [ sep sp cla-distributionPoint ]
- [ sep sp cla-authorityKeyIdentifier ] sp "}"
-
- cla-issuer = id-issuer msp Name
- cla-minCRLNumber = id-minCRLNumber msp CRLNumber
- cla-maxCRLNumber = id-maxCRLNumber msp CRLNumber
- cla-reasonFlags = id-reasonFlags msp ReasonFlags
- cla-dateAndTime = id-dateAndTime msp Time
-
- cla-distributionPoint = id-distributionPoint msp
- DistributionPointName
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 22]
-
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- cla-authorityKeyIdentifier = id-authorityKeyIdentifier msp
- AuthorityKeyIdentifier
-
- id-minCRLNumber = %x6D.69.6E.43.52.4C.4E.75.6D.62.65.72
- ; 'minCRLNumber'
- id-maxCRLNumber = %x6D.61.78.43.52.4C.4E.75.6D.62.65.72
- ; 'maxCRLNumber'
- id-reasonFlags = %x72.65.61.73.6F.6E.46.6C.61.67.73 ; 'reasonFlags'
- id-dateAndTime = %x64.61.74.65.41.6E.64.54.69.6D.65 ; 'dateAndTime'
-
- CRLNumber = INTEGER-0-MAX
-
- ReasonFlags = BIT-STRING
- / "{" [ sp reason-flag *( "," sp reason-flag ) ] sp "}"
-
- reason-flag = id-unused
- / id-keyCompromise
- / id-cACompromise
- / id-affiliationChanged
- / id-superseded
- / id-cessationOfOperation
- / id-certificateHold
- / id-privilegeWithdrawn
- / id-aACompromise
-
- id-unused = %x75.6E.75.73.65.64 ; 'unused'
- id-keyCompromise = %x6B.65.79.43.6F.6D.70.72.6F.6D.69.73.65
- ; 'keyCompromise'
- id-cACompromise = %x63.41.43.6F.6D.70.72.6F.6D.69.73.65
- ; 'cACompromise'
- id-affiliationChanged =
- %x61.66.66.69.6C.69.61.74.69.6F.6E.43.68.61.6E.67.65.64
- ; 'affiliationChanged'
- id-superseded = %x73.75.70.65.72.73.65.64.65.64 ; 'superseded'
- id-cessationOfOperation =
- %x63.65.73.73.61.74.69.6F.6E.4F.66.4F.70.65.72.61.74.69.6F.6E
- ; 'cessationOfOperation'
- id-certificateHold = %x63.65.72.74.69.66.69.63.61.74.65.48.6F.6C.64
- ; 'certificateHold'
- id-privilegeWithdrawn =
- %x70.72.69.76.69.6C.65.67.65.57.69.74.68.64.72.61.77.6E
- ; 'privilegeWithdrawn'
- id-aACompromise = %x61.41.43.6F.6D.70.72.6F.6D.69.73.65
- ; 'aACompromise'
-
-
-A.7. AlgorithmIdentifier
-
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 23]
-
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- AlgorithmIdentifier = "{" sp ai-algorithm
- [ "," sp ai-parameters ] sp "}"
-
- ai-algorithm = id-algorithm msp OBJECT-IDENTIFIER
- ai-parameters = id-parameters msp Value
- id-algorithm = %x61.6C.67.6F.72.69.74.68.6D ; 'algorithm'
- id-parameters = %x70.61.72.61.6D.65.74.65.72.73 ; 'parameters'
-
-
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be found
- in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this specification
- can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-
-Full Copyright
-
- Copyright (C) The Internet Society (2005).
-
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 24]
-
-INTERNET-DRAFT LDAP X.509 Schema 18 July 2005
-
-
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga draft-zeilenga-ldap-x509-02 [Page 25]
-
diff --git a/doc/drafts/draft-zeilenga-ldup-sync-xx.txt b/doc/drafts/draft-zeilenga-ldup-sync-xx.txt
deleted file mode 100644
index f8f030855ae9f489b59e1e3a2ebe1ea3e2f0e43e..0000000000000000000000000000000000000000
--- a/doc/drafts/draft-zeilenga-ldup-sync-xx.txt
+++ /dev/null
@@ -1,1792 +0,0 @@
-
-
-INTERNET-DRAFT Kurt D. Zeilenga
-Intended Category: Experimental OpenLDAP Foundation
-Expires in six months Jong Hyuk Choi
- IBM Corporation
-
- 3 February 2004
-
-
-
-
- The LDAP Content Synchronization Operation
- <draft-zeilenga-ldup-sync-05.txt>
-
-
-
-
-Status of this Memo
-
- This document is an Internet-Draft and is in full conformance with all
- provisions of Section 10 of RFC2026.
-
- Distribution of this memo is unlimited. Technical discussion of this
- document will take place on the IETF LDUP Working Group mailing list
- at <ietf-ldup@imc.org>. Please send editorial comments directly to
- the document editor at <Kurt@OpenLDAP.org>.
-
- Internet-Drafts are working documents of the Internet Engineering Task
- Force (IETF), its areas, and its working groups. Note that other
- groups may also distribute working documents as Internet-Drafts.
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as ``work in progress.''
-
- The list of current Internet-Drafts can be accessed at
- <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
- Internet-Draft Shadow Directories can be accessed at
- <http://www.ietf.org/shadow.html>.
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
- Please see the Full Copyright section near the end of this document
- for more information.
-
-
-
-
-
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 1]
-
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
-Abstract
-
- This specification describes the LDAP (Lightweight Directory Access
- Protocol) Content Synchronization Operation. The operation allows a
- client to maintain a copy of a fragment of directory information tree.
- It supports both polling for changes and listening for changes. The
- operation is defined as an extension of the LDAP Search Operation.
-
-
-Table of Contents
-
- Status of this Memo 1
- Abstract 2
- Table of Contents
- 1. Introduction 3
- 1.1. Background
- 1.2. Intended Usage 4
- 1.3. Overview 5
- 1.4. Conventions
- 2. Elements of the Sync Operation 8
- 2.1. Common ASN.1 Elements 9
- 2.2. Sync Request Control
- 2.3. Sync State Control
- 2.4. Sync Done Control 10
- 2.5. Sync Info Message
- 2.6. Sync Result Codes 11
- 3. Content Synchronization
- 3.1. Synchronization Session
- 3.2. Content Determination 12
- 3.3. refreshOnly Mode 13
- 3.4. refreshAndPersist Mode 16
- 3.5. Search Request Parameters 17
- 3.6. objectName Issues 18
- 3.7. Canceling the Sync Operation 19
- 3.8. Refresh Required
- 3.9. Chattiness Considerations 20
- 3.10. Operation Multiplexing 21
- 4. Meta Information Considerations 22
- 4.1. Entry DN
- 4.2. Operational Attributes
- 4.3. Collective Attributes 23
- 4.4. Access and Other Administrative Controls
- 5. Interaction with Other Controls
- 5.1. ManageDsaIT Control 24
- 5.2. Subentries Control
- 6. Shadowing Considerations
- 7. Security Considerations 25
- 8. IANA Considerations
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 2]
-
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- 8.1. Object Identifier 26
- 8.2. LDAP Protocol Mechanism
- 8.3. LDAP Result Codes
- 9. Acknowledgments
- 10. Normative References 27
- 11. Informative References 28
- 12. Authors' Addresses 29
- Appendix A. CSN-based Implementation Considerations
- Intellectual Property Rights 31
- Full Copyright
-
-
-1. Introduction
-
- The Lightweight Directory Access Protocol (LDAP) [RFC3377] provides a
- mechanism, the search operation [RFC2251], which allows a client to
- request directory content matching a complex set of assertions and for
- the server to return this content, subject to access control and other
- restrictions, to the client. However, LDAP does not provide (despite
- the introduction of numerous extensions in this area) an effective and
- efficient mechanism for maintaining synchronized copies of directory
- content. This document introduces a new mechanism specifically
- designed to met the content synchronization requirements of
- sophisticated directory applications.
-
- This document defines the LDAP Content Synchronization Operation, or
- Sync Operation for short, which allows a client to maintain a
- synchronized copy of a fragment of a Directory Information Tree (DIT).
- The Sync Operation is defined as a set of controls and other protocol
- elements which extend the Search Operation.
-
-
-1.1. Background
-
- Over the years, a number of content synchronization approaches have
- been suggested for use in LDAP directory services. These approaches
- are inadequate for one or more of the following reasons:
-
- - fail to ensure a reasonable level of convergence;
- - fail to detect that convergence cannot be achieved (without
- reload);
- - require pre-arranged synchronization agreements;
- - require the server to maintain histories of past changes to DIT
- content and/or meta information;
- - require the server to maintain synchronization state on a per
- client basis; and/or
- - are overly chatty.
-
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 3]
-
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- The Sync Operation provides eventual convergence of synchronized
- content when possible and, when not, notification that a full reload
- is required.
-
- The Sync Operation does not require pre-arranged synchronization
- agreements.
-
- The Sync Operation does not require servers to maintain nor to use any
- history of past changes to the DIT or to meta information. However,
- servers may maintain and use histories (e.g., change logs, tombstones,
- DIT snapshots) to reduce the number of messages generated and to
- reduce their size. As it is not always feasible to maintain and use
- histories, the operation may be implemented using purely (current)
- state-based approaches. The Sync Operation allows use of either the
- state-based approach or the history-based approach in an operation by
- operation basis to balance the size of history and the amount of
- traffic. The Sync Operation also allows the combined use of the
- state-based and the history-based approaches.
-
- The Sync Operation does not require servers to maintain
- synchronization state on a per client basis. However, servers may
- maintain and use per client state information to reduce the number of
- messages generated and the size of such messages.
-
- A synchronization mechanism can be considered overly chatty when
- synchronization traffic is not reasonably bounded. The Sync Operation
- traffic is bounded by the size of updated (or new) entries and the
- number of unchanged entries in the content. The operation is designed
- to avoid full content exchanges even in the case that the history
- information available to the server is insufficient to determine the
- client's state. The operation is also designed to avoid transmission
- of out-of-content history information, as its size is not bounded by
- the content and it is not always feasible to transmit such history
- information due to security reasons.
-
- This document includes a number of non-normative appendices providing
- additional information to server implementors.
-
-
-1.2. Intended Usage
-
- The Sync Operation is intended to be used in applications requiring
- eventually-convergent content synchronization. Upon completion of
- each synchronization stage of the operation, all information to
- construct a synchronized client copy of the content has been provided
- to the client or the client has been notified that a complete content
- reload is necessary. Except for transient inconsistencies due to
- concurrent operation (or other) processing at the server, the client
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 4]
-
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- copy is an accurate reflection of the content held by the server.
- Transient inconsistencies will be resolved by subsequent
- synchronization operations.
-
- Possible uses include:
- - White page service applications may use the Sync Operation to
- maintain current copy of a DIT fragment. For example, a mail user
- agent which uses the sync operation to maintain a local copy of an
- enterprise address book.
-
- - Meta-information engines may use the Sync Operation to maintain a
- copy of a DIT fragment.
-
- - Caching proxy services may use the Sync Operation to maintain a
- coherent content cache.
-
- - Lightweight master-slave replication between heterogeneous
- directory servers. For example, the Sync Operation can be used by
- a slave server to maintain a shadow copy of a DIT fragment.
- (Note: The International Telephone Union (ITU) has defined the
- X.500 Directory [X.500] Information Shadowing Protocol (DISP)
- [X.525] which may be used for master-slave replication between
- directory servers. Other experimental LDAP replication protocols
- also exist.)
-
- This protocol is not intended to be used in applications requiring
- transactional data consistency.
-
- As this protocol transfers all visible values of entries belonging to
- the content upon change instead of change deltas, this protocol is not
- appropriate for bandwidth-challenged applications or deployments.
-
-
-1.3. Overview
-
- This section provides an overview of basic ways the Sync Operation can
- be used to maintain a synchronized client copy of a DIT fragment.
-
- - Polling for Changes: refreshOnly mode
- - Listening for Changes: refreshAndPersist mode
-
-
-1.3.1. Polling for Changes (refreshOnly)
-
- To obtain its initial client copy, the client issues a Sync request: a
- search request with the Sync Request Control with mode set to
- refreshOnly. The server, much like it would with a normal search
- operation, returns (subject to access controls and other restrictions)
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 5]
-
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- the content matching the search criteria (baseObject, scope, filter,
- attributes). Additionally, with each entry returned, the server
- provides a Sync State Control indicating state add. This control
- contains the Universally Unique Identifier (UUID) [UUID] of the entry
- [EntryUUID]. Unlike the Distinguished Name (DN), which may change
- over time, an entry's UUID is stable. The initial content is followed
- by a SearchResultDone with a Sync Done Control. The Sync Done Control
- provides a syncCookie. The syncCookie represents session state.
-
- To poll for updates to the client copy, the client reissues the Sync
- Operation with the syncCookie previously returned. The server, much
- as it would with a normal search operation, determines which content
- would be returned as if the operation was a normal search operation.
- However, using the syncCookie as an indicator of what content the
- client was sent previously, the server sends copies of entries which
- have changed with a Sync State Control indicating state add. For each
- changed entry, all (modified or unmodified) attributes belonging to
- the content are sent.
-
- The server may perform either or both of the two distinct
- synchronization phases which are distinguished by how to synchronize
- entries deleted from the content: the present and the delete phases.
- When the server uses a single phase for the refresh stage, each phase
- is marked as ended by a SearchResultDone with a Sync Done Control. A
- present phase is identified by a FALSE refreshDeletes value in the
- Sync Done Control. A delete phase is identified by a TRUE
- refreshDeletes value. The present phase may be followed by a delete
- phase. The two phases are delimited by a refreshPresent Sync Info
- Message having a FALSE refreshDone value. In the case that both the
- phases are used, the present phase is used to bring the client copy up
- to the state at which the subsequent delete phase can begin.
-
- In the present phase, the server sends an empty entry (i.e., no
- attributes) with a Sync State Control indicating state present for
- each unchanged entry.
-
- The delete phase may be used when the server can reliably determine
- which entries in the prior client copy are no longer present in the
- content and the number of such entries is less than or equal to the
- number of unchanged entries. In the delete mode, the server sends an
- empty entry with a Sync State Control indicating state delete for each
- entry which is no longer in the content, instead of returning an empty
- entry with state present for each present entry.
-
- The server may send syncIdSet Sync Info Messages containing the set of
- UUIDs of either unchanged present entries or deleted entries, instead
- of sending multiple individual messages. If refreshDeletes of
- syncIdSet is set to FALSE, the UUIDs of unchanged present entries are
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 6]
-
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- contained in the syncUUIDs set; if refreshDeletes of syncIdSet is set
- to TRUE, the UUIDs of the entries no longer present in the content are
- contained in the syncUUIDs set. An optional cookie can be included in
- the syncIdSet to represent the state of the content after
- synchronizing the presence or the absence of the entries contained in
- the syncUUIDs set.
-
- The synchronized copy of the DIT fragment is constructed by the
- client.
-
- If refreshDeletes of syncDoneValue is FALSE, the new copy includes all
- changed entries returned by the reissued Sync Operation as well as all
- unchanged entries identified as being present by the reissued Sync
- Operation, but whose content is provided by the previous Sync
- Operation. The unchanged entries not identified as being present are
- deleted from the client content. They had been either deleted, moved,
- or otherwise scoped-out from the content.
-
- If refreshDeletes of syncDoneValue is TRUE, the new copy includes all
- changed entries returned by the reissued Sync Operation as well as all
- other entries of the previous copy except for those which are
- identified as having been deleted from the content.
-
- The client can, at some later time, re-poll for changes to this
- synchronized client copy.
-
-
-1.3.2. Listening for Changes (refreshAndPersist)
-
- Polling for changes can be expensive in terms of server, client, and
- network resources. The refreshAndPersist mode allows for active
- updates of changed entries in the content.
-
- By selecting the refreshAndPersist mode, the client requests the
- server to send updates of entries that are changed after the initial
- refresh content is determined. Instead of sending a SearchResultDone
- Message as in polling, the server sends a Sync Info Message to the
- client indicating that the refresh stage is complete and then enters
- the persist stage. After receipt of this Sync Info Message, the
- client will construct a synchronized copy as described in Section
- 1.3.1.
-
- The server may then send change notifications as the result of the
- original Sync search request which now remains persistent in the
- server. For entries to be added to the returned content, the server
- sends a SearchResultEntry (with attributes) with a Sync State Control
- indicating state add. For entries to be deleted from the content, the
- server sends a SearchResultEntry containing no attributes and a Sync
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 7]
-
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- State Control indicating state delete. For entries to be modified in
- the return content, the server sends a SearchResultEntry (with
- attributes) with a Sync State Control indicating state modify. Upon
- modification of an entry, all (modified or unmodified) attributes
- belonging to the content are sent.
-
- Note that renaming an entry of the DIT may cause an add state change
- where the entry is renamed into the content, a delete state change
- where the entry is renamed out of the content, and a modify state
- change where the entry remains in the content. Also note that a
- modification of an entry of the DIT may cause an add, delete, or
- modify state change to the content.
-
- Upon receipt of a change notification, the client updates its copy of
- the content.
-
- If the server desires to update the syncCookie during the persist
- stage, it may include the syncCookie in any Sync State Control or Sync
- Info Message returned.
-
- The operation persists until canceled [CANCEL] by the client or
- terminated by the server. A Sync Done Control shall be attached to
- SearchResultDone Message to provide a new syncCookie.
-
-
-1.4. Conventions
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119].
-
- Protocol elements are described using ASN.1 [X.680] with implicit
- tags. The term "BER-encoded" means the element is to be encoded using
- the Basic Encoding Rules [X.690] under the restrictions detailed in
- Section 5.1 of [RFC2251].
-
-
-2. Elements of the Sync Operation
-
- The Sync Operation is defined as an extension to the LDAP Search
- Operation [RFC2251] where the directory user agent (DUA or client)
- submits a SearchRequest Message with a Sync Request Control and the
- directory system agent (DSA or server) responses with zero or more
- SearchResultEntry Messages, each with a Sync State Control; zero or
- more SearchResultReference Messages, each with a Sync State Control;
- zero or more Sync Info Intermediate Response Messages; and a
- SearchResultDone Message with a Sync Done Control.
-
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 8]
-
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- To allow clients to discover support for this operation, servers
- implementing this operation SHOULD publish the
- 1.3.6.1.4.1.4203.1.9.1.1 as a value of 'supportedControl' attribute
- [RFC2252] of the root DSA-specific entry (DSE). A server MAY choose
- to advertise this extension only when the client is authorized to use
- it.
-
-
-2.1 Common ASN.1 Elements
-
-2.1.1 syncUUID
-
- The syncUUID data type is an OCTET STRING holding a 128-bit (16-octet)
- Universally Unique Identifier (UUID) [UUID].
-
- syncUUID ::= OCTET STRING (SIZE(16))
- -- constrained to UUID
-
-
-2.1.2 syncCookie
-
- The syncCookie is a notational convenience to indicate that, while the
- syncCookie type is encoded as an OCTET STRING, its value is an opaque
- value containing information about the synchronization session and its
- state. Generally, the session information would include a hash of the
- operation parameters which the server requires not be changed and the
- synchronization state information would include a commit (log)
- sequence number, a change sequence number, or a time stamp. For
- convenience of description, the term no cookie refers either to null
- cookie or to a cookie with pre-initialized synchronization state.
-
- syncCookie ::= OCTET STRING
-
-
-2.2 Sync Request Control
-
- The Sync Request Control is an LDAP Control [RFC2251, Section 4.1.2]
- where the controlType is the object identifier
- 1.3.6.1.4.1.4203.1.9.1.1 and the controlValue, an OCTET STRING,
- contains a BER-encoded syncRequestValue. The criticality field is
- either TRUE or FALSE.
-
- syncRequestValue ::= SEQUENCE {
- mode ENUMERATED {
- -- 0 unused
- refreshOnly (1),
- -- 2 reserved
- refreshAndPersist (3)
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 9]
-
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- },
- cookie syncCookie OPTIONAL,
- reloadHint BOOLEAN DEFAULT FALSE
- }
-
- The Sync Request Control is only applicable to the SearchRequest
- Message.
-
-
-2.3 Sync State Control
-
- The Sync State Control is an LDAP Control [RFC2251, Section 4.1.2]
- where the controlType is the object identifier
- 1.3.6.1.4.1.4203.1.9.1.2 and the controlValue, an OCTET STRING,
- contains a BER-encoded syncStateValue. The criticality is FALSE.
-
- syncStateValue ::= SEQUENCE {
- state ENUMERATED {
- present (0),
- add (1),
- modify (2),
- delete (3)
- },
- entryUUID syncUUID,
- cookie syncCookie OPTIONAL
- }
-
- The Sync State Control is only applicable to SearchResultEntry and
- SearchResultReference Messages.
-
-
-2.4 Sync Done Control
-
- The Sync Done Control is an LDAP Control [RFC2251, Section 4.1.2]
- where the controlType is the object identifier
- 1.3.6.1.4.1.4203.1.9.1.3 and the controlValue contains a BER-encoded
- syncDoneValue. The criticality is FALSE (and hence absent).
-
- syncDoneValue ::= SEQUENCE {
- cookie syncCookie OPTIONAL,
- refreshDeletes BOOLEAN DEFAULT FALSE
- }
-
- The Sync Done Control is only applicable to SearchResultDone Message.
-
-
-2.5 Sync Info Message
-
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 10]
-
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- The Sync Info Message is an LDAP Intermediate Response Message
- [LDAPIRM] where responseName is the object identifier
- 1.3.6.1.4.1.4203.1.9.1.4 and responseValue contains a BER-encoded
- syncInfoValue. The criticality is FALSE (and hence absent).
-
- syncInfoValue ::= CHOICE {
- newcookie [0] syncCookie,
- refreshDelete [1] SEQUENCE {
- cookie syncCookie OPTIONAL,
- refreshDone BOOLEAN DEFAULT TRUE
- },
- refreshPresent [2] SEQUENCE {
- cookie syncCookie OPTIONAL,
- refreshDone BOOLEAN DEFAULT TRUE
- },
- syncIdSet [3] SEQUENCE {
- cookie syncCookie OPTIONAL,
- refreshDeletes BOOLEAN DEFAULT FALSE,
- syncUUIDs SET OF syncUUID
- }
- }
-
-
-2.6 Sync Result Codes
-
- The following LDAP resultCode [RFC2251] is defined:
-
- e-syncRefreshRequired (IANA-ASSIGNED-CODE)
-
-
-3. Content Synchronization
-
- The Sync Operation is invoked by the client sending a SearchRequest
- Message with a Sync Request Control.
-
- The absence of a cookie or an initialized synchronization state in a
- cookie indicates a request for initial content while the presence of a
- cookie representing a state of a client copy indicates a request for
- content update. Synchronization Sessions are discussed in Section
- 3.1. Content Determination is discussed in Section 3.2.
-
- The mode is either refreshOnly or refreshAndPersist. The refreshOnly
- and refreshAndPersist modes are discussed in Section 3.3 and Section
- 3.4, respectively. The refreshOnly mode consists only of a refresh
- stage, while the refreshAndPersist mode consists of a refresh stage
- and a subsequent persist stage.
-
-
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 11]
-
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
-3.1. Synchronization Session
-
- A sequence of Sync Operations where the last cookie returned by the
- server for one operation is provided by the client in the next
- operation are said to belong to the same Synchronization Session.
-
- The client MUST specify the same content controlling parameters (see
- Section 3.5) in each Search Request of the session. The client SHOULD
- also issue each Sync request of a session under the same
- authentication and authorization associations with equivalent
- integrity and protections. If the server does not recognize the
- request cookie or the request is made under different associations or
- non-equivalent protections, the server SHALL return the initial
- content as if no cookie had been provided or return an empty content
- with the e-syncRefreshRequired LDAP result code. The decision between
- the return of the initial content and the return of the empty content
- with the e-syncRefreshRequired result code MAY be based on reloadHint
- in the Sync Request Control from the client. If the server recognizes
- the request cookie as representing empty or initial synchronization
- state of the client copy, the server SHALL return the initial content.
-
- A Synchronization Session may span multiple LDAP sessions between the
- client and the server. The client SHOULD issue each Sync request of a
- session to the same server. (Note: Shadowing considerations are
- discussed in Section 6.)
-
-
-3.2. Content Determination
-
- The content to be provided is determined by parameters of the Search
- Request, as described in [RFC2251], and possibly other controls. The
- same content parameters SHOULD be used in each Sync request of a
- session. If different content is requested and the server is
- unwilling or unable to process the request, the server SHALL return
- the initial content as if no cookie had been provided or return an
- empty content with the e-syncRefreshRequired LDAP result code. The
- decision between the return of the initial content and the return of
- the empty content with the e-syncRefreshRequired result code MAY be
- based on reloadHint in the Sync Request Control from the client.
-
- The content may not necessarily include all entries or references
- which would be returned by a normal search operation nor, for those
- entries included, not all attributes returned by a normal search.
- When the server is unwilling or unable to provide synchronization for
- any attribute for a set of entries, the server MUST treat all filter
- components matching against these attributes as Undefined and MUST NOT
- return these attributes in SearchResultEntry responses.
-
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 12]
-
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- Servers SHOULD support synchronization for all non-collective
- user-application attributes for all entries.
-
- The server may also return continuation references to other servers or
- to itself. The latter is allowed as the server may partition the
- entries it holds into separate synchronization contexts.
-
- The client may chase all or some of these continuations, each as a
- separate content synchronization session.
-
-
-3.3. refreshOnly Mode
-
- A Sync request with mode refreshOnly and with no cookie is a poll for
- initial content. A Sync request with mode refreshOnly and with a
- cookie representing a synchronization state is a poll for content
- update.
-
-
-3.3.1. Initial Content Poll
-
- Upon receipt of the request, the server provides the initial content
- using a set of zero or more SearchResultEntry and
- SearchResultReference Messages followed by a SearchResultDone Message.
-
- Each SearchResultEntry Message SHALL include a Sync State Control of
- state add, entryUUID containing the entry's UUID, and no cookie. Each
- SearchResultReference Message SHALL include a Sync State Control of
- state add, entryUUID containing the UUID associated with the reference
- (normally the UUID of the associated named referral [RFC3296] object),
- and no cookie. The SearchResultDone Message SHALL include a Sync Done
- Control having refreshDeletes set to FALSE.
-
- A resultCode value of success indicates the operation successfully
- completed. Otherwise, the result code indicates the nature of
- failure. The server may return e-syncRefreshRequired result code on
- the initial content poll if it is safe to do so when it is unable to
- perform the operation due to various reasons. reloadHint is set to
- FALSE in the SearchRequest Message requesting the initial content
- poll.
-
- If the operation is successful, a cookie representing the
- synchronization state of the current client copy SHOULD be returned
- for use in subsequent Sync Operations.
-
-
-3.3.2. Content Update Poll
-
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 13]
-
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- Upon receipt of the request the server provides the content refresh
- using a set of zero or more SearchResultEntry and
- SearchResultReference Messages followed by a SearchResultDone Message.
-
- The server is REQUIRED to either:
- a) provide the sequence of messages necessary for eventual
- convergence of the client's copy of the content to the server's
- copy,
-
- b) treat the request as an initial content request (e.g., ignore
- the cookie or the synchronization state represented in the
- cookie),
-
- c) indicate that the incremental convergence is not possible by
- returning e-syncRefreshRequired,
-
- d) return a resultCode other than success or
- e-syncRefreshRequired.
-
- A Sync Operation may consist of a single present phase, a single
- delete phase, or a present phase followed by a delete phase.
-
- In each phase, for each entry or reference which has been added to the
- content or been changed since the previous Sync Operation indicated by
- the cookie, the server returns a SearchResultEntry or
- SearchResultReference Message, respectively, each with a Sync State
- Control consisting of state add, entryUUID containing the UUID of the
- entry or reference, and no cookie. Each SearchResultEntry Message
- represents the current state of a changed entry. Each
- SearchResultReference Message represents the current state of a
- changed reference.
-
- In the present phase, for each entry which has not been changed since
- the previous Sync Operation, an empty SearchResultEntry is returned
- whose objectName reflects the entry's current DN, the attributes field
- is empty, and a Sync State Control consisting of state present,
- entryUUID containing the UUID of the entry, and no cookie. For each
- reference which has not been changed since the previous Sync
- Operation, an empty SearchResultReference containing an empty SEQUENCE
- OF LDAPURL is returned with a Sync State Control consisting of state
- present, entryUUID containing the UUID of the entry, and no cookie.
- No messages are sent for entries or references which are no longer in
- the content.
-
- Multiple empty entries with a Sync State Control of state present
- SHOULD be coalesced into one or more Sync Info Messages of syncIdSet
- value with refreshDeletes set to FALSE. syncUUIDs contain a set of
- UUIDs of the entries and references unchanged since the last Sync
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 14]
-
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- Operation. syncUUIDs may be empty. The Sync Info Message of
- syncIdSet may contain cookie to represent the state of the content
- after performing the synchronization of the entries in the set.
-
- In the delete phase, for each entry no longer in the content, the
- server returns a SearchResultEntry whose objectName reflects a past DN
- of the entry or is empty, the attributes field is empty, and a Sync
- State Control consisting of state delete, entryUUID containing the
- UUID of the deleted entry, and no cookie. For each reference no
- longer in the content, a SearchResultReference containing an empty
- SEQUENCE OF LDAPURL is returned with a Sync State Control consisting
- of state delete, entryUUID containing the UUID of the deleted
- reference, and no cookie.
-
- Multiple empty entries with a Sync State Control of state delete
- SHOULD be coalesced into one or more Sync Info Messages of syncIdSet
- value with refreshDeletes set to TRUE. syncUUIDs contain a set of
- UUIDs of the entries and references which has been deleted from the
- content since the last Sync Operation. syncUUIDs may be empty. The
- Sync Info Message of syncIdSet may contain cookie to represent the
- state of the content after performing the synchronization of the
- entries in the set.
-
- When a present phase is followed by a delete phase, the two phases are
- delimited by a Sync Info Message containing syncInfoValue of
- refreshPresent, which may contain cookie representing the state after
- completing the present phase. The refreshPresent contains refreshDone
- which is always FALSE in the refreshOnly mode of Sync Operation
- because it is followed by a delete phase.
-
- If a Sync Operation consists of a single phase, each phase and hence
- the Sync Operation are marked ended by a SearchResultDone Message with
- Sync Done Control which SHOULD contain cookie representing the state
- of the content after completing the Sync Operation. The Sync Done
- Control contains refreshDeletes which is set to FALSE for the present
- phase and set to TRUE for the delete phase.
-
- If a Sync Operation consists of a present phase followed by a delete
- phase, the Sync Operation are marked ended at the end of the delete
- phase by a SearchResultDone Message with Sync Done Control which
- SHOULD contain cookie representing the state of the content after
- completing the Sync Operation. The Sync Done Control contains
- refreshDeletes which is set to TRUE.
-
- The client can specify whether it prefers to receive an initial
- content by supplying reloadHint of TRUE or to receive a
- e-syncRefreshRequired resultCode by supplying reloadHint of FALSE
- (hence absent), in the case that the server determines that it is
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 15]
-
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- impossible or inefficient to achieve the eventual convergence by
- continuing the current incremental synchronization thread.
-
- A resultCode value of success indicates the operation is successfully
- completed. A resultCode value of e-syncRefreshRequired indicates that
- a full or partial refresh is needed. Otherwise, the result code
- indicates the nature of failure. A cookie is provided in the Sync
- Done Control for use in subsequent Sync Operations for incremental
- synchronization.
-
-
-3.4. refreshAndPersist Mode
-
- A Sync request with mode refreshAndPersist asks for initial content or
- content update (during the refresh stage) followed by change
- notifications (during the persist stage).
-
-
-3.4.1. refresh Stage
-
- The content refresh is provided as described in Section 3.3 excepting
- that the successful completion of content refresh is indicated by
- sending a Sync Info Message of refreshDelete or refreshPresent with a
- refreshDone value set to TRUE instead of a SearchResultDone Message
- with resultCode success. A cookie SHOULD be returned in the Sync Info
- Message to represent the state of the content after finishing the
- refresh stage of the Sync Operation.
-
-
-3.4.2. persist Stage
-
- Change notifications are provided during the persist stage.
-
- As updates are made to the DIT the server notifies the client of
- changes to the content. DIT updates may cause entries and references
- to be added to the content, deleted from the content, or modified
- within the content. DIT updates may also cause references to be
- added, deleted, or modified within the content.
-
- Where DIT updates cause an entry to be added to the content, the
- server provides a SearchResultEntry Message which represents the entry
- as it appears in the content. The message SHALL include a Sync State
- Control with state of add, entryUUID containing the entry's UUID, and
- an optional cookie.
-
- Where DIT updates cause a reference to be added to the content, the
- server provides a SearchResultReference Message which represents the
- reference in the content. The message SHALL include a Sync State
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 16]
-
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- Control with state of add, entryUUID containing the UUID associated
- with the reference, and an optional cookie.
-
- Where DIT updates cause an entry to be modified within the content,
- the server provides a SearchResultEntry Message which represents the
- entry as it appears in the content. The message SHALL include a Sync
- State Control with state of modify, entryUUID containing the entry's
- UUID, and an optional cookie.
-
- Where DIT updates cause a reference to be modified within the content,
- the server provides a SearchResultEntry Message which represents the
- reference in the content. The message SHALL include a Sync State
- Control with state of modify, entryUUID containing the UUID associated
- with the reference, and an optional cookie.
-
- Where DIT updates cause an entry to be deleted from the content, the
- server provides a SearchResultReference Message with an empty SEQUENCE
- OF LDAPURL. The message SHALL include a Sync State Control with state
- of delete, entryUUID containing the UUID associated with the
- reference, and an optional cookie.
-
- Where DIT updates cause a reference to be deleted from the content,
- the server provides a SearchResultEntry Message with no attributes.
- The message SHALL include a Sync State Control with state of delete,
- entryUUID containing the entry's UUID, and an optional cookie.
-
- Multiple empty entries with a Sync State Control of state delete
- SHOULD be coalesced into one or more Sync Info Messages of syncIdSet
- value with refreshDeletes set to TRUE. syncUUIDs contain a set of
- UUIDs of the entries and references which has been deleted from the
- content. The Sync Info Message of syncIdSet may contain cookie to
- represent the state of the content after performing the
- synchronization of the entries in the set.
-
- With each of these messages, the server may provide a new cookie to be
- used in subsequent Sync Operations. Additionally, the server may also
- return Sync Info Messages of choice newCookie to provide a new cookie.
- The client SHOULD use the newest (last) cookie it received from the
- server in subsequent Sync Operations.
-
-
-3.5. Search Request Parameters
-
- As stated in Section 3.1, the client SHOULD specify the same content
- controlling parameters in each Search Request of the session. All
- fields of the SearchRequest Message are considered content controlling
- parameters except for sizeLimit and timeLimit.
-
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 17]
-
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
-3.5.1. baseObject
-
- As with the normal search operation, the refresh and persist stages
- are not isolated from DIT changes. It is possible that the entry
- referred to by the baseObject is deleted, renamed, or moved. It is
- also possible that alias object used in finding the entry referred to
- by the baseObject is changed such that the baseObject refers to a
- different entry.
-
- If the DIT is updated during processing of the Sync Operation in a
- manner that causes the baseObject to no longer refer to any entry or
- in a manner that changes the entry the baseObject refers to, the
- server SHALL return an appropriate non-success result code such as
- noSuchObject, aliasProblem, aliasDereferencingProblem, referral, or
- e-syncRefreshRequired.
-
-
-3.5.2. derefAliases
-
- This operation does not support alias dereferencing during searching.
- The client SHALL specify neverDerefAliases or derefFindingBaseObj for
- the SearchRequest derefAliases parameter. The server SHALL treat
- other values (e.g., derefInSearching, derefAlways) as protocol errors.
-
-
-3.5.3. sizeLimit
-
- The sizeLimit applies only to entries (regardless of their state in
- Sync State Control) returned during the refreshOnly operation or the
- refresh stage of the refreshAndPersist operation.
-
-
-3.5.4. timeLimit
-
- For a refreshOnly Sync Operation, the timeLimit applies to the whole
- operation. For a refreshAndPersist operation, the timeLimit applies
- only to the refresh stage including the generation of the Sync Info
- Message with a refreshDone value of TRUE.
-
-
-3.5.5. filter
-
- The client SHOULD avoid filter assertions which apply to the values of
- the attributes likely to be considered by the server as ones holding
- meta-information. See Section 4.
-
-
-3.6. objectName
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 18]
-
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- The Sync Operation uses entryUUID values provided in the Sync State
- Control as the primary keys to entries. The client MUST use these
- entryUUIDs to correlate synchronization messages.
-
- In some circumstances the DN returned may not reflect the entry's
- current DN. In particular, when the entry is being deleted from the
- content, the server may provide an empty DN if the server does not
- wish to disclose the entry's current DN (or, if deleted from the DIT,
- the entry's last DN).
-
- It should also be noted that the entry's DN may be viewed as meta
- information (see Section 4.1).
-
-
-3.7. Canceling the Sync Operation
-
- Servers MUST implement the LDAP Cancel [CANCEL] Operation and support
- cancellation of outstanding Sync Operations as described here.
-
- To cancel an outstanding Sync Operation, the client issues an LDAP
- Cancel [CANCEL] Operation.
-
- If at any time the server becomes unwilling or unable to continue
- processing a Sync Operation, the server SHALL return a
- SearchResultDone with a non-success resultCode indicating the reason
- for the termination of the operation.
-
- Whether the client or the server initiated the termination, the server
- may provide a cookie in the Sync Done Control for use in subsequent
- Sync Operations.
-
-
-3.8. Refresh Required
-
- In order to achieve the eventually-convergent synchronization, the
- server may terminate the Sync Operation in the refresh or the persist
- stage by returning a e-syncRefreshRequired resultCode to the client.
- If no cookie is provided, a full refresh is needed. If a cookie
- representing a synchronization state is provided in this response, an
- incremental refresh is needed.
-
- To obtain a full refresh, the client then issues a new synchronization
- request with no cookie. To obtain an incremental reload, the client
- issues a new synchronization with the provided cookie.
-
- The server may choose to provide a full copy in the refresh stage
- (e.g., ignore the cookie or the synchronization state represented in
- the cookie) instead of providing an incremental refresh in order to
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 19]
-
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- achieve the eventual convergence.
-
- The decision between the return of the initial content and the return
- of the e-syncRefreshRequired result code may be based on reloadHint in
- the Sync Request Control from the client.
-
- In the case of persist stage Sync, the server returns the resultCode
- of e-syncRefreshRequired to the client to indicate that the client
- needs to issue a new Sync Operation in order to obtain a synchronized
- copy of the content. If no cookie is provided, a full refresh is
- needed. If a cookie representing a synchronization state is provided,
- an incremental refresh is needed.
-
- The server may also return e-syncRefreshRequired if it determines that
- a refresh would be more efficient than sending all the messages
- required for convergence.
-
- It is noted that the client may receive one or more of
- SearchResultEntry, SearchResultReference, and/or Sync Info Messages
- before it receives SearchResultDone Message with the
- e-syncRefreshRequired result code.
-
-
-3.9. Chattiness Considerations
-
- The server MUST ensure that the number of entry messages generated to
- refresh the client content does not exceed the number of entries
- presently in the content. While there is no requirement for servers
- to maintain history information, if the server has sufficient history
- to allow it to reliably determine which entries in the prior client
- copy are no longer present in the content and the number of such
- entries is less than or equal to the number of unchanged entries, the
- server SHOULD generate delete entry messages instead of present entry
- messages (see Section 3.3.2).
-
- When the amount of history information maintained in the server is not
- enough for the clients to perform infrequent refreshOnly Sync
- Operations, it is likely that the server has incomplete history
- information (e.g. due to truncation) by the time those clients connect
- again.
-
- The server SHOULD NOT resort to full reload when the history
- information is not enough to generate delete entry messages. The
- server SHOULD generate either present entry messages only or present
- entry messages followed by delete entry messages to bring the client
- copy to the current state. In the latter case, the present entry
- messages bring the client copy to a state covered by the history
- information maintained in the server.
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 20]
-
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- The server SHOULD maintain enough (current or historical) state
- information (such as a context-wide last modify time stamp) to
- determine if no changes were made in the context since the content
- refresh was provided and, and when no changes were made, generate zero
- delete entry messages instead of present messages.
-
- The server SHOULD NOT use the history information when its use does
- not reduce the synchronization traffic or when its use can expose
- sensitive information not allowed to be received by the client.
-
- The server implementor should also consider chattiness issues which
- span multiple Sync Operations of a session. As noted in Section 3.8,
- the server may return e-syncRefreshRequired if it determines that a
- reload would be more efficient than continuing under the current
- operation. If reloadHint in the Sync Request is TRUE, the server may
- initiate a reload without directing the client to request a reload.
-
- The server SHOULD transfer a new cookie frequently to avoid having to
- transfer information already provided to the client. Even where DIT
- changes do not cause content synchronization changes to be
- transferred, it may be advantageous to provide a new cookie using a
- Sync Info Message. However, the server SHOULD avoid overloading the
- client or network with Sync Info Messages.
-
- During persist mode, the server SHOULD coalesce multiple outstanding
- messages updating the same entry. The server MAY delay generation of
- an entry update in anticipation of subsequent changes to that entry
- which could be coalesced. The length of the delay should be long
- enough to allow coalescing of update requests issued back to back but
- short enough that the transient inconsistency induced by the delay is
- corrected in a timely manner.
-
- The server SHOULD use syncIdSet Sync Info Message when there are
- multiple delete or present messages to reduce the amount of
- synchronization traffic.
-
- It is also noted that there may be many clients interested in a
- particular directory change, and servers attempting to service all of
- these at once may cause congestion on the network. The congestion
- issues are magnified when the change requires a large transfer to each
- interested client. Implementors and deployers of servers should take
- steps to prevent and manage network congestion.
-
-
-3.10. Operation Multiplexing
-
- The LDAP protocol model [RFC2251] allows operations to be multiplexed
- over a single LDAP session. Clients SHOULD NOT maintain multiple LDAP
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 21]
-
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- sessions with the same server. Servers SHOULD ensure that responses
- from concurrently processed operations are interleaved fairly.
-
- Clients SHOULD combine Sync Operations whose result set is largely
- overlapping. This avoids having to return multiple messages, once for
- each overlapping session, for changes to entries in the overlap.
-
- Clients SHOULD NOT combine Sync Operations whose result sets are
- largely non-overlapping with each other. This ensures that an event
- requiring a e-syncRefreshRequired response can be limited to as few
- result sets as possible.
-
-
-4. Meta Information Considerations
-
-4.1. Entry DN
-
- As an entry's DN is constructed from its relative DN (RDN) and the
- entry's parent's DN, it is often viewed as meta information.
-
- While renaming or moving to a new superior causes the entry's DN to
- change, that change SHOULD NOT, by itself, cause synchronization
- messages to be sent for that entry. However, if the renaming or the
- moving could cause the entry to be added or deleted from the content,
- appropriate synchronization messages should be generated to indicate
- this to the client.
-
- When a server treats the entry's DN as meta information, the server
- SHALL either
-
- - evaluate all MatchingRuleAssertions [RFC2251] to TRUE if
- matching a value of an attribute of the entry and otherwise
- Undefined, or
- - evaluate all MatchingRuleAssertion with dnAttributes of TRUE as
- Undefined.
-
- The latter choice is offered for ease of server implementation.
-
-
-4.2. Operational Attributes
-
- Where values of an operational attribute is determined by values not
- held as part of the entry it appears in, the operational attribute
- SHOULD NOT support synchronization of that operational attribute.
-
- For example, in servers which implement X.501 subschema model [X.501],
- servers should not support synchronization of the subschemaSubentry
- attribute as its value is determined by values held and administrated
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 22]
-
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- in subschema subentries.
-
- As a counter example, servers which implement aliases [RFC2256][X.501]
- can support synchronization of the aliasedObjectName attribute as its
- values are held and administrated as part of the alias entries.
-
- Servers SHOULD support synchronization of the following operational
- attributes: createTimestamp, modifyTimestamp, creatorsName,
- modifiersName [RFC2252]. Servers MAY support synchronization of other
- operational attributes.
-
-
-4.3. Collective Attributes
-
- A collective attribute is "a user attribute whose values are the same
- for each member of an entry collection" [X.501]. Use of collective
- attributes in LDAP is discussed in [RFC3371].
-
- Modification of a collective attribute generally affects the content
- of multiple entries, which are the members of the collection. It is
- inefficient to include values of collective attributes visible in
- entries of the collection, as a single modification of a collective
- attribute requires transmission of multiple SearchResultEntry (one for
- each entry of the collection which the modification affected) to be
- transmitted.
-
- Servers SHOULD NOT synchronize collective attributes appearing in
- entries of any collection. Servers MAY support synchronization of
- collective attributes appearing in collective attribute subentries.
-
-
-4.4. Access and Other Administrative Controls
-
- Entries are commonly subject to access and other administrative
- Controls. While portions of the policy information governing a
- particular entry may be held in the entry, policy information is often
- held elsewhere (in superior entries, in subentries, in the root DSE,
- in configuration files etc.). Because of this, changes to policy
- information make it difficult to ensure eventual convergence during
- incremental synchronization.
-
- Where it is impractical or infeasible to generate content changes
- resulting from a change to policy information, servers may opt to
- return e-syncRefreshRequired or treat the Sync Operation as an initial
- content request (e.g., ignore the cookie or the synchronization state
- represented in the cookie).
-
-
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 23]
-
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
-5. Interaction with Other Controls
-
- The Sync Operation may be used with:
-
- - ManageDsaIT Control [RFC3296]
- - Subentries Control [RFC3672]
-
- as described below. The Sync Operation may be used with other LDAP
- extensions as detailed in other documents.
-
-
-5.1. ManageDsaIT Control
-
- The ManageDsaIT Control [RFC3296] indicates that the operation acts
- upon the DSA Information Tree and causes referral and other special
- entries to be treated as object entries with respect to the operation.
-
-
-5.2. Subentries Control
-
- The Subentries Control is used with the search operation "to control
- the visibility of entries and subentries which are within scope"
- [RFC3672]. When used with the Sync Operation, the subentries control
- and other factors (search scope, filter, etc.) are used to determine
- whether an entry or subentry appear in the content or not.
-
-
-6. Shadowing Considerations
-
- As noted in [RFC2251], some servers may hold shadow copies of entries
- which can be used to answer search and comparison queries. Such
- servers may also support content synchronization requests. This
- section discusses considerations for implementors and deployers for
- the implementation and deployment of the Sync operation in shadowed
- directories.
-
- While a client may know of multiple servers which are equally capable
- of being used to obtain particular directory content from, a client
- SHOULD NOT assume that each of these server is equally capable of
- continuing a content synchronization session. As stated in Section
- 3.1, the client SHOULD issue each Sync request of a Sync session to
- the same server.
-
- However, through domain naming or IP address redirection or other
- techniques, multiple physical servers can be made to appear as one
- logical server to a client. Only servers which are equally capable in
- regards to their support for the Sync operation and which hold equally
- complete copies of the entries should be made to appear as one logical
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 24]
-
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- server. In particular, each physical server acting as one logical
- server SHOULD be equally capable of continuing a content
- synchronization based upon cookies provided by any of the other
- physical servers without requiring a full reload. Because there is no
- standard LDAP shadowing mechanism, the specification of how to
- independently implement equally capable servers (as well as the
- precise definition of "equally capable") is left to future documents.
-
- It is noted that it may be difficult for the server to reliably
- determine what content was provided to the client by another server,
- especially in the shadowing environments which allow shadowing events
- to be coalesced. Where so, the use of the delete phase discussed in
- Section 3.3.2 may not be applicable.
-
-
-7. Security Considerations
-
- In order to maintain a synchronized copy of the content, a client is
- to delete information from its copy of the content as described above.
- However, the client may maintain knowledge of information disclosed to
- it by the server separate from its copy of the content used for
- synchronization. Management of this knowledge is beyond the scope of
- this document. Servers should be careful not to disclose information
- for content which the client is not authorized to have knowledge of
- and/or about.
-
- While the information provided by a series of refreshOnly Sync
- Operations is similar to that provided by a series of Search
- Operations, persist stage may disclose additional information. A
- client may be able to discern information about the particular
- sequence of update operations which caused content change.
-
- Implementors should take precautions against malicious cookie content,
- including malformed cookies or valid cookies used with different
- security associations and/or protections in attempt to obtain
- unauthorized access to information. Servers may include a digital
- signature in the cookie to detect tampering.
-
- The operation may be the target of direct denial of service attacks.
- Implementors should provide safeguards to ensure the operation is not
- abused. Servers may place access control or other restrictions upon
- the use of this operation.
-
- It is noted that even small updates to the directory may cause
- significant amount of traffic to be generated to clients using this
- operation. A user could abuse its update privileges to mount an
- indirect denial of service to these clients, other clients, and/or
- portions of the network. Servers should provide safeguards to ensure
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 25]
-
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- update operations are not abused.
-
- Implementors of this (or any) LDAP extension should be familiar with
- general LDAP security considerations [RFC3377].
-
-
-8. IANA Considerations
-
- Registration of the following values is requested.
-
- The OID arc 1.3.6.1.4.1.4203.1.9.1 was assigned [ASSIGN] by OpenLDAP
- Foundation, under its IANA-assigned private enterprise allocation
- [PRIVATE], for use in this specification.
-
-
-8.2. LDAP Protocol Mechanism
-
- It is requested that IANA register the LDAP Protocol Mechanism
- described in this document.
-
- Subject: Request for LDAP Protocol Mechanism Registration
- Object Identifier: 1.3.6.1.4.1.4203.1.9.1.1
- Description: LDAP Content Synchronization Control
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@openldap.org>
- Usage: Control
- Specification: RFC XXXX
- Author/Change Controller: IESG
- Comments: none
-
-
-8.3. LDAP Result Codes
-
- It is requested that IANA register the LDAP Result Code described in
- this document.
-
- Subject: LDAP Result Code Registration
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Result Code Name: e-syncRefreshRequired (IANA-ASSIGNED-CODE)
- Specification: RFC XXXX
- Author/Change Controller: IESG
- Comments: none
-
-
-9. Acknowledgments
-
- This document borrows significantly from the LDAP Client Update
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 26]
-
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- Protocol [LCUP], a product of the IETF LDUP working group. This
- document also benefited from Persistent Search [PSEARCH], Triggered
- Search [TSEARCH], and Directory Synchronization [DIRSYNC] works. This
- document also borrows from "Lightweight Directory Access Protocol
- (v3)" [RFC2251].
-
-
-10. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-
- [RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory
- Access Protocol (v3)", RFC 2251, December 1997.
-
- [RFC2252] Wahl, M., A. Coulbeck, T. Howes, and S. Kille,
- "Lightweight Directory Access Protocol (v3): Attribute
- Syntax Definitions", RFC 2252, December 1997.
-
- [RFC3296] Zeilenga, K., "Named Subordinate References in
- Lightweight Directory Access Protocol (LDAP)
- Directories", RFC 3296, July 2002.
-
- [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
- Protocol (v3): Technical Specification", RFC 3377,
- September 2002.
-
- [RFC3671] Zeilenga, K., "Collective Attributes in LDAP", RFC 3671,
- December 2003.
-
- [RFC3672] Zeilenga, K. and S. Legg, "Subentries in LDAP", RFC
- 3672, December 2003.
-
- [CANCEL] Zeilenga, K., "LDAP Cancel Extended Operation",
- draft-zeilenga-ldap-cancel-xx.txt, a work in progress.
- [EntryUUID] Zeilenga, K., "The LDAP EntryUUID Operational
- Attribute", draft-zeilenga-ldap-uuid-xx.txt, a work in
- progress.
-
- [LDAPIRM] Harrison, R. and Zeilenga, K., "LDAP Intermediate
- Response",
- draft-rharrison-ldap-intermediate-resp-00.txt, a work in
- progress.
-
- [UUID] International Organization for Standardization (ISO),
- "Information technology - Open Systems Interconnection -
- Remote Procedure Call", ISO/IEC 11578:1996
-
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 27]
-
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- [X.680] International Telecommunication Union -
- Telecommunication Standardization Sector, "Abstract
- Syntax Notation One (ASN.1) - Specification of Basic
- Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
-
- [X.690] International Telecommunication Union -
- Telecommunication Standardization Sector, "Specification
- of ASN.1 encoding rules: Basic Encoding Rules (BER),
- Canonical Encoding Rules (CER), and Distinguished
- Encoding Rules (DER)", X.690(1997) (also ISO/IEC
- 8825-1:1998).
-
-
-11. Informative References
-
- [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for
- use with LDAPv3", RFC 2256, December 1997.
-
- [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
- (also RFC 3383), September 2002.
-
- [PRIVATE] IANA, "Private Enterprise Numbers",
- http://www.iana.org/assignments/enterprise-numbers.
-
- [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
- http://www.openldap.org/foundation/oid-delegate.txt.
-
- [X.500] International Telecommunication Union -
- Telecommunication Standardization Sector, "The Directory
- -- Overview of concepts, models and services,"
- X.500(1993) (also ISO/IEC 9594-1:1994).
-
- [X.511] International Telecommunication Union -
- Telecommunication Standardization Sector, "The
- Directory: Abstract Service Definition", X.511(1993).
-
- [X.525] International Telecommunication Union -
- Telecommunication Standardization Sector, "The
- Directory: Replication", X.525(1993).
-
- [UUIDinfo] The Open Group, "Universally Unique Identifier" appendix
- of the CAE Specification "DCE 1.1: Remote Procedure
- Calls", Document Number C706,
- <http://www.opengroup.org/products/publications/
- catalog/c706.htm> (appendix available at:
- <http://www.opengroup.org/onlinepubs/9629399/
- apdxa.htm>), August 1997.
-
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 28]
-
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- [DIRSYNC] Armijo, M., "Microsoft LDAP Control for Directory
- Synchronization", draft-armijo-ldap-dirsync-xx.txt, a
- work in progress.
-
- [LCUP] Megginson, R., et. al., "LDAP Client Update Protocol",
- draft-ietf-ldup-lcup-xx.txt, a work in progress.
-
- [PSEARCH] Smith, M., et. al., "Persistent Search: A Simple LDAP
- Change Notification Mechanism",
- draft-ietf-ldapext-psearch-xx.txt, a work in progress.
-
- [TSEARCH] Wahl, M., "LDAPv3 Triggered Search Control",
- draft-ietf-ldapext-trigger-xx.txt, a work in progress.
-
-
-12. Authors' Addresses
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
- <Kurt@OpenLDAP.org>
-
- Jong Hyuk Choi
- IBM Corporation
- <jongchoi@us.ibm.com>
-
-
-
-Appendix A. CSN-based Implementation Considerations
-
- This appendix is provided for informational purposes only, it is not a
- normative part of the LDAP Content Synchronization Operation's
- technical specification.
-
- This appendix discusses LDAP Content Synchronization Operation server
- implementation considerations associated with a Change Sequence Number
- based approaches.
-
- Change Sequence Number based approaches are targeted for use in
- servers which do not maintain history information (e.g., change logs,
- state snapshots, etc.) about changes made to the Directory and hence,
- must rely on current directory state and minimal synchronization state
- information embedded in Sync Cookie. Servers which maintain history
- information should consider other approaches which exploit the history
- information.
-
- A Change Sequence Number is effectively a time stamp which has
- sufficient granularity to ensure that the precedence relationship in
- time of two updates to the same object can be determined. Change
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 29]
-
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- Sequence Numbers are not to be confused with Commit Sequence Numbers
- or Commit Log Record Numbers. A Commit Sequence Number allows one to
- determine how two commits (to the same object or different objects)
- relate to each other in time. Change Sequence Number associated with
- different entries may be committed out of order. In the remainder of
- this Appendix, the term CSN refers to a Change Sequence Number.
-
- In these approaches, the server not only maintains a CSN for each
- directory entry (the entry CSN), but also maintains a value which we
- will call the context CSN. The context CSN is the greatest committed
- entry CSN which is not greater than any outstanding (uncommitted)
- entry CSNs for all entries in a directory context. The values of
- context CSN are used in syncCookie values as synchronization state
- indicators.
-
- As search operations are not isolated from individual directory update
- operations and individual update operations cannot be assumed to be
- serialized, one cannot assume that the returned content incorporates
- all relevant changes whose change sequence number is less than or
- equal to the greatest entry CSN in the content. The content
- incorporates all the relevant changes whose change sequence number is
- less than or equal to context CSN before search processing. The
- content may also incorporate any subset of the changes whose change
- sequence number is greater than context CSN before search processing
- but less than or equal to the context CSN after search processing.
- The content does not incorporate any of the changes whose CSN is
- greater than the context CSN after search processing.
-
- A simple server implementation could use value of the context CSN
- before search processing to indicate state. Such an implementation
- would embed this value into each SyncCookie returned. We'll call this
- the cookie CSN. When a refresh was requested, the server would simply
- generate "update" messages for all entries in the content whose CSN is
- greater than the supplied cookie CSN and generate "present" messages
- for all other entries in the content. However, if the current context
- CSN is the same as the cookie CSN, the server should instead generate
- zero "updates" and zero "delete" messages, and indicate refreshDeletes
- of TRUE as the directory has not changed.
-
- The implementation should also consider the impact of changes to meta
- information, such as access controls, which affects content
- determination. One approach is for the server to maintain a context
- wide meta information CSN or meta CSN. This meta CSN would be updated
- whenever meta information affecting content determination was changed.
- If the value of the meta CSN is greater than cookie CSN, the server
- should ignore the cookie and treat the request as an initial request
- for content.
-
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 30]
-
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- Additionally, servers may want to consider maintaining some
- per-session history information to reduce the number of messages
- needed to be transferred during incremental refreshes. Specifically,
- a server could record information about entries as they leave the
- scope of a disconnected sync session and later use this information to
- generate delete messages instead of present messages.
-
- When the history information is truncated, the CSN of the latest
- truncated history information entry may be recorded as the truncated
- CSN of the history information. The truncated CSN may be used to
- determine whether a client copy can be covered by the history
- information by comparing it to the synchronization state contained in
- the cookie supplied by the client.
-
- When there are a large number of sessions, it may make sense to
- maintain such history only for the selected clients. Also, servers
- taking this approach need to consider resource consumption issues to
- ensure reasonable server operation and to protect against abuse. It
- may be appropriate to restrict this mode of operation by policy.
-
-
-
-
-Intellectual Property Rights
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property or other rights that might be claimed to pertain
- to the implementation or use of the technology described in this
- document or the extent to which any license under such rights might or
- might not be available; neither does it represent that it has made any
- effort to identify any such rights. Information on the IETF's
- procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication and any assurances of
- licenses to be made available, or the result of an attempt made to
- obtain a general license or permission for the use of such proprietary
- rights by implementors or users of this specification can be obtained
- from the IETF Secretariat.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
-
-Full Copyright
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 31]
-
-INTERNET-DRAFT draft-zeilenga-ldup-sync-05 3 February 2004
-
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published and
- distributed, in whole or in part, without restriction of any kind,
- provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be followed,
- or as required to translate it into languages other than English.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga LDAP Content Sync Operation [Page 32]
-
-
diff --git a/doc/guide/admin/intro.sdf b/doc/guide/admin/intro.sdf
index 26722e1e1409636de5dbb91d3de4aec5c71e9b21..9960d05d5ecb1a7ab0f260b7f76ac0481776a6dc 100644
--- a/doc/guide/admin/intro.sdf
+++ b/doc/guide/admin/intro.sdf
@@ -52,10 +52,11 @@ H2: What is LDAP?
it is a lightweight protocol for accessing directory services,
specifically {{TERM:X.500}}-based directory services. LDAP runs
over {{TERM:TCP}}/{{TERM:IP}} or other connection oriented transfer
-services. The nitty-gritty details of LDAP are defined in
-{{REF:RFC2251}} "The Lightweight Directory Access Protocol (v3)"
-and other documents comprising the technical specification
-{{REF:RFC3377}}. This section gives an overview of LDAP from a
+services. LDAP is an {{ORG:IETF}} Standard Track protocol and is
+specified as detailed in "Lightweight Directory Access Protocol
+(LDAP) Technical Specification Road Map" {{REF:RFC4510}}.
+
+This section gives an overview of LDAP from a
user's perspective.
{{What kind of information can be stored in the directory?}} The
@@ -107,8 +108,8 @@ concatenating the names of its ancestor entries. For example, the
entry for Barbara Jensen in the Internet naming example above has
an RDN of {{EX:uid=babs}} and a DN of
{{EX:uid=babs,ou=People,dc=example,dc=com}}. The full DN format
-is described in {{REF:RFC2253}}, "Lightweight Directory Access
-Protocol (v3): UTF-8 String Representation of Distinguished Names."
+is described in {{REF:RFC4514}}, "LDAP: String Representation of
+Distinguished Names."
{{How is the information accessed?}} LDAP defines operations for
interrogating and updating the directory. Operations are provided
diff --git a/doc/guide/admin/proxycache.sdf b/doc/guide/admin/proxycache.sdf
index d510dd3b75a1ef7cb1eade65494070e22c1cfc84..5fd2b3420fba8e9dc3d5cbc0e7c0c4ff397a929e 100644
--- a/doc/guide/admin/proxycache.sdf
+++ b/doc/guide/admin/proxycache.sdf
@@ -36,7 +36,7 @@ is stored in main memory.
A template is a prototype for generating LDAP search requests.
Templates are described by a prototype search filter and a list of
attributes which are required in queries generated from the template.
-The representation for prototype filter is similar to RFC 2254,
+The representation for prototype filter is similar to {{REF:RFC4515}},
except that the assertion values are missing. Examples of prototype
filters are: (sn=),(&(sn=)(givenname=)) which are instantiated by
search filters (sn=Doe) and (&(sn=Doe)(givenname=John)) respectively.
diff --git a/doc/guide/admin/sasl.sdf b/doc/guide/admin/sasl.sdf
index cdd0cca4b32cc79574f7180626ac6741a087b237..00e2c4739ec5fcef13f0f03fe220b00ef252f4ec 100644
--- a/doc/guide/admin/sasl.sdf
+++ b/doc/guide/admin/sasl.sdf
@@ -5,7 +5,7 @@ H1: Using SASL
OpenLDAP clients and servers are capable of authenticating via the
{{TERM[expand]SASL}} ({{TERM:SASL}}) framework, which is detailed
-in {{REF:RFC2222}}. This chapter describes how to make use of
+in {{REF:RFC4422}}. This chapter describes how to make use of
SASL in OpenLDAP.
There are several industry standard authentication mechanisms that
@@ -483,6 +483,10 @@ Note that the explicitly-named realms are handled first, to avoid
the realm name becoming part of the UID. Also note the use of scope
and filters to limit matching to desirable entries.
+Note as well that {{EX:authz-regexp}} internal search are subject
+to access controls. Specifically, the authentication identity
+must have {{EX:auth}} access.
+
See {{slapd.conf}}(5) for more detailed information.
diff --git a/doc/guide/admin/schema.sdf b/doc/guide/admin/schema.sdf
index a2d519ac785001352a83c6f35d9fb0001f7ad673..6a14fb3e7ed3363ea215b34974305ed09860e03e 100644
--- a/doc/guide/admin/schema.sdf
+++ b/doc/guide/admin/schema.sdf
@@ -96,9 +96,9 @@ OID Assignment
1.1.1 SNMP Elements
1.1.2 LDAP Elements
1.1.2.1 AttributeTypes
-1.1.2.1.1 myAttribute
+1.1.2.1.1 x-my-Attribute
1.1.2.2 ObjectClasses
-1.1.2.2.1 myObjectClass
+1.1.2.2.1 x-my-ObjectClass
!endblock
You are, of course, free to design a hierarchy suitable to your
@@ -130,25 +130,27 @@ Alternatively, OID name space may be available from a national
authority (e.g., {{ORG:ANSI}}, {{ORG:BSI}}).
-H3: Name Prefix
+H3: Naming Elements
In addition to assigning a unique object identifier to each schema
element, you should provide a least one textual name for each
-element. The name should be both descriptive and not likely to
-clash with names of other schema elements. In particular, any name
-you choose should not clash with present or future Standard Track
-names.
+element. Names should be registered with the {{ORG:IANA}} or
+prefixed with "x-" to place in the "private use" name space.
-To reduce (but not eliminate) the potential for name clashes, the
-convention is to prefix names of non-Standard Track with a few
-letters to localize the changes to your organization. The smaller
-the organization, the longer your prefix should be.
+The name should be both descriptive and not likely to clash with
+names of other schema elements. In particular, any name you choose
+should not clash with present or future Standard Track names (this
+is assured if you registered names or use names begining with "x-").
-In the examples below, we have chosen a short prefix '{{EX:my}}'
-(to save space). Such a short prefix would only be suitable for a
-very large, global organization. In general, we recommend something
-like '{{EX:deFirm}}' (German company) or '{{EX:comExample}}' (elements
-associated with organization associated with {{EX:example.com}}).
+It is noted that you can obtain your own registered name
+prefix so as to avoid having to register your names individually.
+See {{REF:RFC4520}} for details.
+
+In the examples below, we have used a short prefix '{{EX:x-my-}}'.
+Such a short prefix would only be suitable for a very large, global
+organization. In general, we recommend something like '{{EX:x-de-Firm-}}'
+(German company) or '{{EX:x-com-Example}}' (elements associated with
+organization associated with {{EX:example.com}}).
H3: Local schema file
@@ -173,10 +175,10 @@ H3: Attribute Type Specification
The {{attributetype}} directive is used to define a new attribute
type. The directive uses the same Attribute Type Description
-(as defined in {{REF:RFC2252}}) used by the attributeTypes
+(as defined in {{REF:RFC4512}}) used by the attributeTypes
attribute found in the subschema subentry, e.g.:
-E: attributetype <{{REF:RFC2252}} Attribute Type Description>
+E: attributetype <{{REF:RFC4512}} Attribute Type Description>
where Attribute Type Description is defined by the following
{{TERM:BNF}}:
@@ -283,7 +285,7 @@ for usage by user applications. Neither is obsolete nor collective.
The following subsections provide a couple of examples.
-H4: myUniqueName
+H4: x-my-UniqueName
Many organizations maintain a single unique name for each user.
Though one could use {{EX:displayName}} ({{REF:RFC2798}}), this
@@ -292,7 +294,7 @@ organization. We could just copy the definition of {{EX:displayName}}
from {{F:inetorgperson.schema}} and replace the OID, name, and
description, e.g:
-> attributetype ( 1.1.2.1.1 NAME 'myUniqueName'
+> attributetype ( 1.1.2.1.1 NAME 'x-my-UniqueName'
> DESC 'unique name with my organization'
> EQUALITY caseIgnoreMatch
> SUBSTR caseIgnoreSubstringsMatch
@@ -303,22 +305,22 @@ However, if we want this name to be included in
{{EX:name}} assertions [e.g. {{EX:(name=*Jane*)}}], the attribute
could alternatively be defined as a subtype of {{EX:name}}, e.g.:
-> attributetype ( 1.1.2.1.1 NAME 'myUniqueName'
+> attributetype ( 1.1.2.1.1 NAME 'x-my-UniqueName'
> DESC 'unique name with my organization'
> SUP name )
-H4: myPhoto
+H4: x-my-Photo
Many organizations maintain a photo of each each user. A
-{{EX:myPhoto}} attribute type could be defined to hold a photo.
+{{EX:x-my-Photo}} attribute type could be defined to hold a photo.
Of course, one could use just use {{EX:jpegPhoto}} ({{REF:RFC2798}})
(or a subtype) to hold the photo. However, you can only do
this if the photo is in {{JPEG File Interchange Format}}.
Alternatively, an attribute type which uses the {{Octet String}}
syntax can be defined, e.g.:
-> attributetype ( 1.1.2.1.2 NAME 'myPhoto'
+> attributetype ( 1.1.2.1.2 NAME 'x-my-Photo'
> DESC 'a photo (application defined format)'
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
> SINGLE-VALUE )
@@ -337,7 +339,7 @@ pointing to the photo. You can model such an attribute after
{{EX:labeledURI}} ({{REF:RFC2079}}) or simply create a subtype,
e.g.:
-> attributetype ( 1.1.2.1.3 NAME 'myPhotoURI'
+> attributetype ( 1.1.2.1.3 NAME 'x-my-PhotoURI'
> DESC 'URI and optional label referring to a photo'
> SUP labeledURI )
@@ -346,10 +348,10 @@ H3: Object Class Specification
The {{objectclasses}} directive is used to define a new object
class. The directive uses the same Object Class Description
-(as defined in {{REF:RFC2252}}) used by the objectClasses
+(as defined in {{REF:RFC4512}}) used by the objectClasses
attribute found in the subschema subentry, e.g.:
-E: objectclass <{{REF:RFC2252}} Object Class Description>
+E: objectclass <{{REF:RFC4512}} Object Class Description>
where Object Class Description is defined by the following
{{TERM:BNF}}:
@@ -371,18 +373,18 @@ OID in numeric form (e.g. {{EX:1.1.0}}), qdescrs is one or more
names, and oids is one or more names and/or OIDs.
-H4: myPhotoObject
+H4: x-my-PhotoObject
To define an {{auxiliary}} object class which allows
-myPhoto to be added to any existing entry.
+x-my-Photo to be added to any existing entry.
-> objectclass ( 1.1.2.2.1 NAME 'myPhotoObject'
-> DESC 'mixin myPhoto'
+> objectclass ( 1.1.2.2.1 NAME 'x-my-PhotoObject'
+> DESC 'mixin x-my-Photo'
> AUXILIARY
-> MAY myPhoto )
+> MAY x-my-Photo )
-H4: myPerson
+H4: x-my-Person
If your organization would like have a private {{structural}}
object class to instantiate users, you can subclass one of
@@ -390,20 +392,20 @@ the existing person classes, such as {{EX:inetOrgPerson}}
({{REF:RFC2798}}), and add any additional attributes which
you desire.
-> objectclass ( 1.1.2.2.2 NAME 'myPerson'
+> objectclass ( 1.1.2.2.2 NAME 'x-my-Person'
> DESC 'my person'
> SUP inetOrgPerson
-> MUST ( myUniqueName $ givenName )
-> MAY myPhoto )
+> MUST ( x-my-UniqueName $ givenName )
+> MAY x-my-Photo )
The object class inherits the required/allowed attribute
-types of {{EX:inetOrgPerson}} but requires {{EX:myUniqueName}}
-and {{EX:givenName}} and allows {{EX:myPhoto}}.
+types of {{EX:inetOrgPerson}} but requires {{EX:x-my-UniqueName}}
+and {{EX:givenName}} and allows {{EX:x-my-Photo}}.
!if 0
H2: Transferring Schema
-Since the {{slapd.conf}}(5) schema directives use {{REF:RFC2252}}
+Since the {{slapd.conf}}(5) schema directives use {{REF:RFC4512}}
format values, you can extract schema elements published by
any LDAPv3 server and easily construct directives for use with
{{slapd}}(8).
@@ -430,12 +432,12 @@ This will return {{TERM:LDIF}} output containing many type/value
pairs. The following is an abbreviated example:
> dn: cn=Subschema
-> objectClasses: ( 1.1.2.2.2 NAME 'myPerson' DESC 'my person' SUP inet
-> OrgPerson MUST ( myUniqueName $ givenName ) MAY myPhoto )
-> attributeTypes: ( 1.1.2.1.1 NAME 'myUniqueName' DESC 'unique name wi
-> th my organization' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubst
-> ringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
-> attributeTypes: ( 1.1.2.1.2 NAME 'myPhoto' DESC 'a photo (applicatio
+> objectClasses: ( 1.1.2.2.2 NAME 'x-my-Person' DESC 'my person' SUP inet
+> OrgPerson MUST ( x-my-UniqueName $ givenName ) MAY x-my-Photo )
+> attributeTypes: ( 1.1.2.1.1 NAME 'x-my-UniqueName' DESC 'unique name wi
+> th my organization' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstrin
+> gsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
+> attributeTypes: ( 1.1.2.1.2 NAME 'x-my-Photo' DESC 'a photo (applicatio
> n defined format)' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
Capture the output of the search in a file and then edit the file:
@@ -451,20 +453,20 @@ Capture the output of the search in a file and then edit the file:
For the three type/value pairs in our example, the edit should
result in a file with contains of:
-> attributetype ( 1.1.2.1.1 NAME 'myUniqueName'
+> attributetype ( 1.1.2.1.1 NAME 'x-my-UniqueName'
> DESC 'unique name with my organization'
> EQUALITY caseIgnoreMatch
> SUBSTR caseIgnoreSubstringsMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
> SINGLE-VALUE )
-> attributeType ( 1.1.2.1.2 NAME 'myPhoto'
+> attributeType ( 1.1.2.1.2 NAME 'x-my-Photo'
> DESC 'a photo (application defined format)'
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
-> objectClass ( 1.1.2.2.2 NAME 'myPerson'
+> objectClass ( 1.1.2.2.2 NAME 'x-my-Person'
> DESC 'my person'
> SUP inetOrgPerson
-> MUST ( myUniqueName $ givenName )
-> MAY myPhoto )
+> MUST ( x-my-UniqueName $ givenName )
+> MAY x-my-Photo )
Save in an appropriately named file (e.g. {{F:local.schema}}).
You may now include this file in your {{slapd.conf}}(5) file.
@@ -489,11 +491,11 @@ and their use in defining schema elements:
> objectIdentifier myLDAP myOID:2
> objectIdentifier myAttributeType myLDAP:1
> objectIdentifier myObjectClass myLDAP:2
-> attributetype ( myAttributeType:3 NAME 'myPhotoURI'
+> attributetype ( myAttributeType:3 NAME 'x-my-PhotoURI'
> DESC 'URI and optional label referring to a photo'
> SUP labeledURI )
-> objectclass ( myObjectClass:1 NAME 'myPhotoObject'
-> DESC 'mixin myPhoto'
+> objectclass ( myObjectClass:1 NAME 'x-my-PhotoObject'
+> DESC 'mixin x-my-Photo'
> AUXILIARY
-> MAY myPhoto )
+> MAY x-my-Photo )
diff --git a/doc/guide/admin/slapdconf2.sdf b/doc/guide/admin/slapdconf2.sdf
index b67916bac610f75fbc4057f721d862c817ea6339..b02f5d28a21fffb464a1a808f9ca7c2c15d83dde 100644
--- a/doc/guide/admin/slapdconf2.sdf
+++ b/doc/guide/admin/slapdconf2.sdf
@@ -323,14 +323,14 @@ in underneath. Schema entries must have the {{EX:olcSchemaConfig}}
objectClass.
-H4: olcAttributeTypes: <{{REF:RFC2252}} Attribute Type Description>
+H4: olcAttributeTypes: <{{REF:RFC4512}} Attribute Type Description>
This directive defines an attribute type.
Please see the {{SECT:Schema Specification}} chapter
for information regarding how to use this directive.
-H4: olcObjectClasses: <{{REF:RFC2252}} Object Class Description>
+H4: olcObjectClasses: <{{REF:RFC4512}} Object Class Description>
This directive defines an object class.
Please see the {{SECT:Schema Specification}} chapter for
@@ -561,8 +561,9 @@ the rootdn (when the rootdn is set to a DN within the database).
> olcRootPW: secret
-It is also permissible to provide a hash of the password in RFC 2307
-form. {{slappasswd}}(8) may be used to generate the password hash.
+It is also permissible to provide a hash of the password in
+{{REF:RFC2307}} form. {{slappasswd}}(8) may be used to generate
+the password hash.
\Example:
@@ -1063,7 +1064,7 @@ the target entry's {{normalized DN}}. (The second form is not
discussed further in this document.) The third form is used to
select entries which are within the requested scope of DN. The
<DN> is a string representation of the Distinguished Name, as
-described in {{REF:RFC2253}}.
+described in {{REF:RFC4514}}.
The scope can be either {{EX:base}}, {{EX:one}}, {{EX:subtree}},
or {{EX:children}}. Where {{EX:base}} matches only the entry with
@@ -1093,7 +1094,7 @@ Entries may also be selected using a filter:
> to filter=<ldap filter>
where <ldap filter> is a string representation of an LDAP
-search filter, as described in {{REF:RFC2254}}. For example:
+search filter, as described in {{REF:RFC4515}}. For example:
> to filter=(objectClass=person)
diff --git a/doc/guide/admin/slapdconfig.sdf b/doc/guide/admin/slapdconfig.sdf
index 091473e4649c2959fb1262cabb92c8b21be11ff3..5302618f4c4d0023ed9ef236e22ed4117e509be9 100644
--- a/doc/guide/admin/slapdconfig.sdf
+++ b/doc/guide/admin/slapdconfig.sdf
@@ -105,7 +105,7 @@ access control policy, {{EX:access to * by * read}}, allows all
both authenticated and anonymous users read access.
-H4: attributetype <{{REF:RFC2252}} Attribute Type Description>
+H4: attributetype <{{REF:RFC4512}} Attribute Type Description>
This directive defines an attribute type.
Please see the {{SECT:Schema Specification}} chapter
@@ -172,7 +172,7 @@ logged.
E: loglevel 256
-H4: objectclass <{{REF:RFC2252}} Object Class Description>
+H4: objectclass <{{REF:RFC4512}} Object Class Description>
This directive defines an object class.
Please see the {{SECT:Schema Specification}} chapter for
@@ -378,7 +378,7 @@ the rootdn (when the rootdn is set to a DN within the database).
> rootpw secret
-It is also permissible to provide hash of the password in RFC 2307
+It is also permissible to provide hash of the password in {{REF:RFC2307}}
form. {{slappasswd}}(8) may be used to generate the password hash.
\Example:
@@ -643,7 +643,7 @@ the target entry's {{normalized DN}}. (The second form is not
discussed further in this document.) The third form is used to
select entries which are within the requested scope of DN. The
<DN> is a string representation of the Distinguished Name, as
-described in {{REF:RFC2253}}.
+described in {{REF:RFC4514}}.
The scope can be either {{EX:base}}, {{EX:one}}, {{EX:subtree}},
or {{EX:children}}. Where {{EX:base}} matches only the entry with
@@ -673,7 +673,7 @@ Entries may also be selected using a filter:
> to filter=<ldap filter>
where <ldap filter> is a string representation of an LDAP
-search filter, as described in {{REF:RFC2254}}. For example:
+search filter, as described in {{REF:RFC4515}}. For example:
> to filter=(objectClass=person)
diff --git a/doc/guide/admin/tls.sdf b/doc/guide/admin/tls.sdf
index ee42e34cf53a343c2c7e4400df1871eff4548267..c0dd8f8dabe407a9982ffece59f9cc560736dcd7 100644
--- a/doc/guide/admin/tls.sdf
+++ b/doc/guide/admin/tls.sdf
@@ -7,6 +7,7 @@ OpenLDAP clients and servers are capable of using the
{{TERM[expand]TLS}} ({{TERM:TLS}}) framework to provide
integrity and confidentiality protections and to support
LDAP authentication using the {{TERM:SASL}} EXTERNAL mechanism.
+TLS is defined in {{REF:RFC4346}}.
H2: TLS Certificates
@@ -23,7 +24,7 @@ The DN of a server certificate must use the CN attribute
to name the server, and the {{EX:CN}} must carry the server's
fully qualified domain name. Additional alias names and wildcards
may be present in the {{EX:subjectAltName}} certificate extension.
-More details on server certificate names are in {{REF:RFC2830}}.
+More details on server certificate names are in {{REF:RFC4513}}.
H3: Client Certificates
diff --git a/doc/guide/preamble.sdf b/doc/guide/preamble.sdf
index cb336774668fb4e153ad1bac79b254007d48357b..01d044cfe6692ed06db46f3e1f8d6f381a813b5c 100644
--- a/doc/guide/preamble.sdf
+++ b/doc/guide/preamble.sdf
@@ -207,24 +207,27 @@ X.509|X.509 Public Key and Attribute Certificate Frameworks
!block references; data
Reference|Status|Document|Jump
RFC2079|PS|Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifers|http://www.rfc-editor.org/rfc/rfc2079.txt
-RFC2222|PS|Simple Authentication and Security Layer|http://www.rfc-editor.org/rfc/rfc2222.txt
-RFC2251|PS|Lightweight Directory Access Protocol (v3)|http://www.rfc-editor.org/rfc/rfc2251.txt
-RFC2252|PS|LDAPv3: Attribute Syntax Definitions|http://www.rfc-editor.org/rfc/rfc2252.txt
-RFC2253|PS|LDAPv3: UTF-8 String Representation of Distinguished Names|http://www.rfc-editor.org/rfc/rfc2253.txt
-RFC2254|PS|The String Representation of LDAP Search Filters|http://www.rfc-editor.org/rfc/rfc2254.txt
-RFC2255|PS|The LDAP URL Format|http://www.rfc-editor.org/rfc/rfc2255.txt
-RFC2256|PS|A Summary of the X.500(96) User Schema for use with LDAPv3|http://www.rfc-editor.org/rfc/rfc2256.txt
RFC2296|PS|Use of Language Codes in LDAP|http://www.rfc-editor.org/rfc/rfc2296.txt
+RFC2307|X|An Approach for Using LDAP as a Network Information Service|http://www.rfc-editor.org/rfc/rfc2307.txt
RFC2798|INFO|Definition of the inetOrgPerson LDAP Object Class|http://www.rfc-editor.org/rfc/rfc2798.txt
-RFC2829|PS|Authentication Methods for LDAP|http://www.rfc-editor.org/rfc/rfc2829.txt
-RFC2830|PS|LDAPv3: Extension for Transport Layer Security|http://www.rfc-editor.org/rfc/rfc2830.txt
RFC2831|PS|Using Digest Authentication as a SASL Mechanism|http://www.rfc-editor.org/rfc/rfc2831.txt
RFC2849|PS|The LDAP Data Interchange Format|http://www.rfc-editor.org/rfc/rfc2849.txt
RFC3088|X|OpenLDAP Root Service|http://www.rfc-editor.org/rfc/rfc3088.txt
RFC3296|PS|Named Subordinate References in LDAP|http://www.rfc-editor.org/rfc/rfc3296.txt
-RFC3377|PS|Lightweight Directory Access Protocol (v3): Technical Specification|http://www.rfc-editor.org/rfc/rfc3377.txt
-RFC3383|BCP|Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)|http://www.rfc-editor.org/rfc/rfc3383.txt
RFC3384|INFO|Lightweight Directory Access Protocol (version 3) Replication Requirements|http://www.rfc-editor.org/rfc/rfc3384.txt
RFC3494|INFO|Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status|http://www.rfc-editor.org/rfc/rfc3494.txt
RFC4013|PS|SASLprep: Stringprep Profile for User Names and Passwords
+RFC4346|PS|The Transport Layer Security (TLS) Protocol, Version 1.1|http://www.rfc-editor.org/rfc/rfc4346.txt
+RFC4422|PS|Simple Authentication and Security Layer (SASL)|http://www.rfc-editor.org/rfc/rfc4422.txt
+RFC4510|PS|Lightweight Directory Access Protocol (LDAP) Technical Specification Roadmap|http://www.rfc-editor.org/rfc/rfc4510.txt
+RFC4511|PS|Lightweight Directory Access Protocol (LDAP): The Protocol|http://www.rfc-editor.org/rfc/rfc4512.txt
+RFC4512|PS|Lightweight Directory Access Protocol (LDAP): Directory Information Models|http://www.rfc-editor.org/rfc/rfc4512.txt
+RFC4513|PS|Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms|http://www.rfc-editor.org/rfc/rfc4513.txt
+RFC4514|PS|Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names|http://www.rfc-editor.org/rfc/rfc4514.txt
+RFC4515|PS|Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters|http://www.rfc-editor.org/rfc/rfc4515.txt
+RFC4516|PS|Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator|http://www.rfc-editor.org/rfc/rfc4516.txt
+RFC4517|PS|Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules|http://www.rfc-editor.org/rfc/rfc4517.txt
+RFC4518|PS|Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation|http://www.rfc-editor.org/rfc/rfc4518.txt
+RFC4519|PS|Lightweight Directory Access Protocol (LDAP): Schema for User Applications|http://www.rfc-editor.org/rfc/rfc4519.txt
+RFC4520|BCP|IANA Considerations for LDAP|http://www.rfc-editor.org/rfc/rfc4520.txt
!endblock
diff --git a/doc/man/Project b/doc/man/Project
new file mode 100644
index 0000000000000000000000000000000000000000..2685f48f3550245057213c47abbd4b0df8cbb55b
--- /dev/null
+++ b/doc/man/Project
@@ -0,0 +1,5 @@
+.\" Shared Project Acknowledgement Text
+.B "OpenLDAP Software"
+is developed and maintained by The OpenLDAP Project <http://www.openldap.org/>.
+.B "OpenLDAP Software"
+is derived from University of Michigan LDAP 3.3 Release.
diff --git a/doc/man/man1/ldapcompare.1 b/doc/man/man1/ldapcompare.1
index 1bf6a6aaa83cff5685f900ab5c8873da67172921..54997589bb597dedfe53c0aa1607cb3602f9a87c 100644
--- a/doc/man/man1/ldapcompare.1
+++ b/doc/man/man1/ldapcompare.1
@@ -56,7 +56,7 @@ ldapcompare \- LDAP compare tool
.SH DESCRIPTION
.I ldapcompare
is a shell-accessible interface to the
-.BR ldap_compare (3)
+.BR ldap_compare_ext (3)
library call.
.LP
.B ldapcompare
@@ -176,11 +176,8 @@ the value from.
.BR ldap.conf (5),
.BR ldif (5),
.BR ldap (3),
-.BR ldap_compare (3)
+.BR ldap_compare_ext (3)
.SH AUTHOR
The OpenLDAP Project <http://www.openldap.org/>
.SH ACKNOWLEDGEMENTS
-.B OpenLDAP
-is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
-.B OpenLDAP
-is derived from University of Michigan LDAP 3.3 Release.
+.so ../Project
diff --git a/doc/man/man1/ldapdelete.1 b/doc/man/man1/ldapdelete.1
index 5a8d7c464946d8186dc947c966700df8cec785c1..aaa42d13b6b61c36bd18fbd9395c4509c8e87838 100644
--- a/doc/man/man1/ldapdelete.1
+++ b/doc/man/man1/ldapdelete.1
@@ -59,14 +59,14 @@ ldapdelete \- LDAP delete entry tool
.SH DESCRIPTION
.I ldapdelete
is a shell-accessible interface to the
-.BR ldap_delete (3)
+.BR ldap_delete_ext (3)
library call.
.LP
.B ldapdelete
opens a connection to an LDAP server, binds, and deletes one or more
entries. If one or more \fIDN\fP arguments are provided, entries with
those Distinguished Names are deleted. Each \fIDN\fP should be provided
-using the LDAPv3 string representation as defined in RFC 2253.
+using the LDAPv3 string representation as defined in RFC 4514.
If no \fIdn\fP arguments
are provided, a list of DNs is read from standard input (or from
\fIfile\fP if the -f flag is used).
@@ -194,11 +194,8 @@ status and a diagnostic message being written to standard error.
.BR ldapmodrdn (1),
.BR ldapsearch (1),
.BR ldap (3),
-.BR ldap_delete (3)
+.BR ldap_delete_ext (3)
.SH AUTHOR
The OpenLDAP Project <http://www.openldap.org/>
.SH ACKNOWLEDGEMENTS
-.B OpenLDAP
-is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
-.B OpenLDAP
-is derived from University of Michigan LDAP 3.3 Release.
+.so ../Project
diff --git a/doc/man/man1/ldapmodify.1 b/doc/man/man1/ldapmodify.1
index 5fbfdf42d5b551d2a9ce9f70a7330a2510819996..c3c812e9697a7ba7b7b2a8fa092b223e3189fdf4 100644
--- a/doc/man/man1/ldapmodify.1
+++ b/doc/man/man1/ldapmodify.1
@@ -107,9 +107,11 @@ ldapmodify, ldapadd \- LDAP modify entry and LDAP add entry tools
.SH DESCRIPTION
.B ldapmodify
is a shell-accessible interface to the
-.BR ldap_modify (3)
+.BR ldap_add_ext (3),
+.BR ldap_modify_ext (3),
+.BR ldap_delete_ext (3)
and
-.BR ldap_add (3)
+.BR ldap_rename (3).
library calls.
.B ldapadd
is implemented as a hard link to the ldapmodify tool. When invoked as
@@ -360,16 +362,13 @@ exit status and a diagnostic message being written to standard error.
.BR ldapsearch (1),
.BR ldap.conf (5),
.BR ldap (3),
-.BR ldap_add (3),
-.BR ldap_delete (3),
-.BR ldap_modify (3),
-.BR ldap_modrdn (3),
+.BR ldap_add_ext (3),
+.BR ldap_delete_ext (3),
+.BR ldap_modify_ext (3),
+.BR ldap_modrdn_ext (3),
.BR ldif (5),
.BR slapd.replog (5)
.SH AUTHOR
The OpenLDAP Project <http://www.openldap.org/>
.SH ACKNOWLEDGEMENTS
-.B OpenLDAP
-is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
-.B OpenLDAP
-is derived from University of Michigan LDAP 3.3 Release.
+.so ../Project
diff --git a/doc/man/man1/ldapmodrdn.1 b/doc/man/man1/ldapmodrdn.1
index cb5e5cd66f9a423b58a7a6b8a5096a98939433d3..b9442e05c5c2ac8ac8725e71fb189fbc04e5f403 100644
--- a/doc/man/man1/ldapmodrdn.1
+++ b/doc/man/man1/ldapmodrdn.1
@@ -59,7 +59,7 @@ ldapmodrdn \- LDAP rename entry tool
.SH DESCRIPTION
.B ldapmodrdn
is a shell-accessible interface to the
-.BR ldap_modrdn2 (3)
+.BR ldap_rename (3)
library call.
.LP
.B ldapmodrdn
@@ -214,11 +214,8 @@ status and a diagnostic message being written to standard error.
.BR ldapsearch (1),
.BR ldap.conf (5),
.BR ldap (3),
-.BR ldap_modrdn2 (3)
+.BR ldap_rename (3)
.SH AUTHOR
The OpenLDAP Project <http://www.openldap.org/>
.SH ACKNOWLEDGEMENTS
-.B OpenLDAP
-is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
-.B OpenLDAP
-is derived from University of Michigan LDAP 3.3 Release.
+.so ../Project
diff --git a/doc/man/man1/ldappasswd.1 b/doc/man/man1/ldappasswd.1
index 3c62b5bc5e9d70af982ad7e814968b1381ac883f..6ae94833ab017a63c639563f444348ec17738499 100644
--- a/doc/man/man1/ldappasswd.1
+++ b/doc/man/man1/ldappasswd.1
@@ -185,7 +185,4 @@ the command will require the operation to be successful
.SH AUTHOR
The OpenLDAP Project <http://www.openldap.org/>
.SH ACKNOWLEDGEMENTS
-.B OpenLDAP
-is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
-.B OpenLDAP
-is derived from University of Michigan LDAP 3.3 Release.
+.so ../Project
diff --git a/doc/man/man1/ldapsearch.1 b/doc/man/man1/ldapsearch.1
index 401535617c71eed01ed175c2b10bfa443066084f..f274fb26e46e867af9d0fb27facbb516de5e17e2 100644
--- a/doc/man/man1/ldapsearch.1
+++ b/doc/man/man1/ldapsearch.1
@@ -84,17 +84,18 @@ ldapsearch \- LDAP search tool
.SH DESCRIPTION
.I ldapsearch
is a shell-accessible interface to the
-.BR ldap_search (3)
+.BR ldap_search_ext (3)
library call.
.LP
.B ldapsearch
opens a connection to an LDAP server, binds, and performs a search
using specified parameters. The \fIfilter\fP should conform to
-the string representation for search filters as defined in RFC 2254.
+the string representation for search filters as defined in RFC 4515.
If not provided, the default filter, (objectClass=*), is used.
.LP
If
-.B ldapsearch finds one or more entries, the attributes specified by
+.B ldapsearch
+finds one or more entries, the attributes specified by
\fIattrs\fP are returned. If * is listed, all user attributes are
returned. If + is listed, all operational attributes are returned.
If no \fIattrs\fP are listed, all user attributes are returned. If only
@@ -239,7 +240,7 @@ Specify general extensions with -e and search extensions with -E.
General extensions:
.nf
- [!]assert=<filter> (an RFC 2254 Filter)
+ [!]assert=<filter> (an RFC 4515 Filter)
[!]authzid=<authzid> ("dn:<dn>" or "u:<user>")
[!]manageDSAit
[!]noop
@@ -443,11 +444,9 @@ a diagnostic message being written to standard error.
.BR ldap.conf (5),
.BR ldif (5),
.BR ldap (3),
-.BR ldap_search (3)
+.BR ldap_search_ext (3),
+.BR ldap_sort (3)
.SH AUTHOR
The OpenLDAP Project <http://www.openldap.org/>
.SH ACKNOWLEDGEMENTS
-.B OpenLDAP
-is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
-.B OpenLDAP
-is derived from University of Michigan LDAP 3.3 Release.
+.so ../Project
diff --git a/doc/man/man1/ldapwhoami.1 b/doc/man/man1/ldapwhoami.1
index f12a0b462fe334b879b3da236e44d83d7cce2174..47ddec130388069ecf385a38eab17f9735e1c4a1 100644
--- a/doc/man/man1/ldapwhoami.1
+++ b/doc/man/man1/ldapwhoami.1
@@ -148,7 +148,4 @@ Issue StartTLS (Transport Layer Security) extended operation. If you use
.SH AUTHOR
The OpenLDAP Project <http://www.openldap.org/>
.SH ACKNOWLEDGEMENTS
-.B OpenLDAP
-is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
-.B OpenLDAP
-is derived from University of Michigan LDAP 3.3 Release.
+.so ../Project
diff --git a/doc/man/man3/Deprecated b/doc/man/man3/Deprecated
new file mode 100644
index 0000000000000000000000000000000000000000..6d850c0368d0350230778e2a3357a954c88c18c6
--- /dev/null
+++ b/doc/man/man3/Deprecated
@@ -0,0 +1,7 @@
+Deprecated interfaces generally remain in the library. The macro
+LDAP_DEPRECATED can be defined to a non-zero value
+(e.g., -DLDAP_DEPRECATED=1) when compiling program designed to use
+deprecated interaces. It is recommended that developers writing new
+programs, or updating old programs, avoid use of deprecated interfaces.
+Over time, it is expected that documentation (and, eventually, support) for
+deprecated interfaces to be eliminated.
diff --git a/doc/man/man3/ldap.3 b/doc/man/man3/ldap.3
index e3a64ab82ce61a68ac3396bb90cd5c57b692ac26..f78b9eaf5725c166d0afee939daa638ede90b5b1 100644
--- a/doc/man/man3/ldap.3
+++ b/doc/man/man3/ldap.3
@@ -14,12 +14,12 @@ OpenLDAP LDAP (libldap, -lldap)
.fi
.SH DESCRIPTION
.LP
-The Lightweight Directory Access Protocol (LDAP) (RFC 3377) provides
+The Lightweight Directory Access Protocol (LDAP) (RFC 4510) provides
access to X.500 directory services. These services may be stand\-alone
or part of a distributed directory service. This client API supports
-LDAP over TCP (RFC2251), LDAP over TLS/SSL, and LDAP over IPC (UNIX
-domain sockets). This API supports SASL (RFC2829) and Start TLS
-(RFC2830) as well as a number of protocol extensions. This API is
+LDAP over TCP (RFC 4511), LDAP over TLS/SSL, and LDAP over IPC (UNIX
+domain sockets). This API supports SASL (RFC 4513) and Start TLS
+(RFC 4513) as well as a number of protocol extensions. This API is
loosely based upon IETF/LDAPEXT C LDAP API draft specification, a (orphaned)
work in progress.
.LP
@@ -65,9 +65,9 @@ Errors can be interpreted by calling
.BR ldap_err2string (3).
.SH LDAP versions
This library supports version 3 of the Lightweight Directory Access
-Protocol (LDAPv3) as defined in RFC 3377. It also supports a variant
+Protocol (LDAPv3) as defined in RFC 4510. It also supports a variant
of version 2 of LDAP as defined by U-Mich LDAP and, to some degree,
-RFC 1777. Version 2 (all variants) should be viewed as obsolete.
+RFC 1777. Version 2 (all variants) are considered obsolete.
Version 3 should be used instead.
.LP
For backwards compatibility reasons, the library defaults to version 2.
@@ -81,15 +81,15 @@ All character string input/output is expected to be/is UTF\-8
encoded Unicode (version 3.2).
.LP
Distinguished names (DN) (and relative distinguished names (RDN) to
-be passed to the LDAP routines should conform to RFC 2253 UTF\-8
+be passed to the LDAP routines should conform to RFC 4514 UTF\-8
string representation.
.LP
Search filters to be passed to the search routines are to be
-constructed by hand and should conform to RFC 2254 UTF\-8
+constructed by hand and should conform to RFC 4515 UTF\-8
string representation.
.LP
LDAP URL are to be passed to routines are expected to conform
-to RFC 2255 syntax. The
+to RFC 4516 format. The
.BR ldap_url (3)
routines can be used to work with LDAP URLs.
.SH DISPLAYING RESULTS
@@ -112,6 +112,10 @@ Also provided are various utility routines. The
.BR ldap_sort (3)
routines are used to sort the entries and values returned via
the ldap search routines.
+.SH DEPRECATED INTERFACES
+A number of interfaces are now considered deprecated. For instance,
+ldap_add(3) is deprecated in favor of ldap_add_ext(3).
+.so Deprecated
.SH BER LIBRARY
Also included in the distribution is a set of lightweight Basic
Encoding Rules routines. These routines are used by the LDAP library
@@ -256,10 +260,7 @@ case insensitive string comparison
.BR slapd (8),
.BR draft-ietf-ldapext-ldap-c-api-xx.txt \ <http://www.ietf.org>
.SH ACKNOWLEDGEMENTS
-.B OpenLDAP
-is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
-.B OpenLDAP
-is derived from University of Michigan LDAP 3.3 Release.
+.so ../Project
.LP
These API manual pages are loosely based upon descriptions provided
in the IETF/LDAPEXT C LDAP API Internet Draft, a (orphaned) work
diff --git a/doc/man/man3/ldap_abandon.3 b/doc/man/man3/ldap_abandon.3
index a2327ea0e006b79010247439662fc16eeeef05cc..011e40ecd53f7b7bcc9c16c95aeda2821e5f9e49 100644
--- a/doc/man/man3/ldap_abandon.3
+++ b/doc/man/man3/ldap_abandon.3
@@ -3,66 +3,67 @@
.\" Copyright 1998-2006 The OpenLDAP Foundation All Rights Reserved.
.\" Copying restrictions apply. See COPYRIGHT/LICENSE.
.SH NAME
-ldap_abandon, ldap_abandon_ext \- Abandon an LDAP operation in progress
+ldap_abandon_ext \- Abandon an LDAP operation in progress
.SH LIBRARY
OpenLDAP LDAP (libldap, -lldap)
.SH SYNOPSIS
.nf
-.B #include <ldap.h>
-.sp
-.BI "int ldap_abandon(LDAP *" ld ", int " msgid ");"
-.sp
-.BI "int ldap_abandon_ext(LDAP *" ld ", int " msgid ","
+.B
+#include <ldap.h>
+.LP
+.ft B
+int ldap_abandon_ext(
.RS
-.BI "LDAPControl *" sctrls "[], LDAPControl *" cctrls "[]);"
+.ft B
+LDAP *\fIld\fB,
+Bint \fImsgid\fB,
+LDAPControl **\fIsctrls\fB,
+LDAPControl **\fIcctrls\fB );
.RE
.fi
.SH DESCRIPTION
The
-.B ldap_abandon()
-routine is used to abandon or cancel an LDAP
+.B ldap_abandon_ext()
+routine is used to send a LDAP Abandon request for an
operation in progress. The \fImsgid\fP passed should be the
-message id of an outstanding LDAP operation, as returned by
-.BR ldap_search (3),
-.BR ldap_modify (3),
-etc.
+message id of an outstanding LDAP operation, such as returned by
+.BR ldap_search_ext (3).
.LP
-.BR ldap_abandon ()
+.BR ldap_abandon_ext ()
checks to see if the result of the operation has already come in. If it
has, it deletes it from the queue of pending messages. If not,
-it sends an LDAP abandon operation to the the LDAP server.
+it sends an LDAP abandon request to the LDAP server.
.LP
The caller can expect that the result of an abandoned operation
will not be returned from a future call to
.BR ldap_result (3).
.LP
.B ldap_abandon_ext()
-is equivalent to
-.B ldap_abandon()
-except that it allows server and client controls to be passed
-in
+allows server and client controls to be passed in via the
.I sctrls
and
-.IR cctrls ,
-respectively.
-.SH ERRORS
-.B ldap_abandon()
-returns 0 if everything goes ok, -1 otherwise,
-setting \fIld_errno\fP with an appropriate LDAP error code.
+.I cctrls
+parameters, respectively.
.LP
.B ldap_abandon_ext()
-directly returns an LDAP error code indicating success or failure of the
-operation.
-.LP
-See
+returns a code indicating success or, in the case of failure, the
+nature of the failure. See
.BR ldap_error (3)
for details.
+.SH DEPRECATED INTERFACES
+The
+.B ldap_abandon()
+routine is deprecated in favor of the
+.B ldap_abandon_ext()
+routine.
+.LP
+.so Deprecated
+
.SH SEE ALSO
.BR ldap (3),
+.BR ldap_error (3),
.BR ldap_result (3),
-.BR ldap_error (3)
+.BR ldap_search_ext (3)
.SH ACKNOWLEDGEMENTS
-.B OpenLDAP
-is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
-.B OpenLDAP
-is derived from University of Michigan LDAP 3.3 Release.
+.so ../Project
+
diff --git a/doc/man/man3/ldap_add.3 b/doc/man/man3/ldap_add.3
index dacf0d80d4e99f12d62dd89c45e5ba767a2dd927..9758442365ea9bebafe05779fb852c742dd102cf 100644
--- a/doc/man/man3/ldap_add.3
+++ b/doc/man/man3/ldap_add.3
@@ -3,88 +3,79 @@
.\" Copyright 1998-2006 The OpenLDAP Foundation All Rights Reserved.
.\" Copying restrictions apply. See COPYRIGHT/LICENSE.
.SH NAME
-ldap_add, ldap_add_s, ldap_add_ext, ldap_add_ext_s \- Perform an LDAP add operation
+ldap_add_ext, ldap_add_ext_s \- Perform an LDAP add operation
.SH LIBRARY
OpenLDAP LDAP (libldap, -lldap)
.SH SYNOPSIS
+.ft B
+#include <ldap.h>
+.LP
+.ft B
.nf
-.B #include <ldap.h>
-.sp
-.BI "int ldap_add(LDAP *" ld ", const char *" dn ", LDAPMod *" attrs "[]);"
-.sp
-.BI "int ldap_add_s(LDAP *" ld ", const char *" dn ", LDAPMod *" attrs "[]);"
-.sp
-.BI "int ldap_add_ext(LDAP *" ld ", const char *" dn ", LDAPMod *" attrs "[],"
+int ldap_add_ext(
.RS
-.BI "LDAPControl *" sctrls "[], LDAPControl *" cctrls "[], int *" msgidp ");"
+.ft B
+LDAP *\fIld,
+const char *\fIdn\fB,
+LDAPMod **\fIattrs\fB,
+LDAPControl **\fIsctrls\fB,
+LDAPControl **\fIcctrls\fB,
+int *\fImsgidp\fB );
.RE
-.sp
-.BI "int ldap_add_ext_s(LDAP *" ld ", const char *" dn ", LDAPMod *" attrs "[],"
+.LP
+.ft B
+.nf
+int ldap_add_ext_s(
.RS
-.BI "LDAPControl *" sctrls "[], LDAPControl *" cctrls "[]);"
+LDAP *\fIld\fB,
+const char *\fIdn\fB,
+LDAPMod **\fIattrs\fB,
+LDAPControl *\fIsctrls\fB,
+LDAPControl *\fIcctrls\fB );
.RE
.fi
.SH DESCRIPTION
The
-.B ldap_add_s()
+.B ldap_add_ext_s()
routine is used to perform an LDAP add operation.
It takes \fIdn\fP, the DN of the entry to add, and \fIattrs\fP, a
null-terminated array of the entry's attributes. The LDAPMod structure
is used to represent attributes, with the \fImod_type\fP and
\fImod_values\fP fields being used as described under
-.BR ldap_modify (3),
+.BR ldap_modify_ext (3),
and the \fIldap_op\fP field being used only if you need to specify
the LDAP_MOD_BVALUES option. Otherwise, it should be set to zero.
.LP
Note that all entries except that
specified by the last component in the given DN must already exist.
-.B ldap_add_s()
-returns an LDAP error code indicating success or failure
-of the operation. See
+.B ldap_add_ext_s()
+returns an code indicating success or, in the case of failure,
+indicating the nature of failure of the operation. See
.BR ldap_error (3)
for more details.
.LP
The
-.B ldap_add()
+.B ldap_add_ext()
routine works just like
-.BR ldap_add_s() ,
+.BR ldap_add_ext_s() ,
but it is asynchronous. It returns the message id of the request it
initiated. The result of this operation can be obtained by calling
.BR ldap_result (3).
-.LP
+.SH DEPRECATED INTERFACES
The
-.B ldap_add_ext()
-routine allows server and client controls to be specified to extend
-the add request. This routine is asynchronous like
-.BR ldap_add() ,
-but its return value is an LDAP error code. It stores the message id
-of the request in the integer pointed to
-by
-.IR msgidp .
-.LP
-The
-.B ldap_add_ext_s()
-routine is the synchronous version of
-.BR ldap_add_ext() .
-It also returns an LDAP error code indicating success or failure
-of the operation.
-.SH ERRORS
-.B ldap_add()
-returns -1 in case of error initiating the request, and
-will set the \fIld_errno\fP field in the \fIld\fP parameter
-to indicate the error.
-.B ldap_add_s()
-will return an LDAP error code
-directly (LDAP_SUCCESS if everything went ok, some error otherwise).
-.B ldap_add_ext()
+.BR ldap_add ()
and
-.B ldap_add_ext_s()
-also directly return LDAP error codes.
+.BR ldap_add_s ()
+routines are deprecated in favor of the
+.BR ldap_add_ext ()
+and
+.BR ldap_add_ext_s ()
+routines, respectively.
+.LP
+.so Deprecated
.SH SEE ALSO
.BR ldap (3),
+.BR ldap_error (3),
.BR ldap_modify (3)
.SH ACKNOWLEDGEMENTS
-.B OpenLDAP
-is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
-.B OpenLDAP
-is derived from University of Michigan LDAP 3.3 Release.
+.so ../Project
diff --git a/doc/man/man3/ldap_bind.3 b/doc/man/man3/ldap_bind.3
index 34b6a23846f520a87105b9499c9180d7df1da8d5..81bfc88e231e641ccbb7e5162a4c20dff92e9216 100644
--- a/doc/man/man3/ldap_bind.3
+++ b/doc/man/man3/ldap_bind.3
@@ -226,8 +226,8 @@ The bind method must be synchronous.
.BR ldap_open (3),
.BR ldap_set_option (3),
.BR ldap_url_parse (3)
-.B RFC 2222
-(http://www.ietf.org),
+.B RFC 4422
+(http://www.rfc-editor.org),
.B Cyrus SASL
(http://asg.web.cmu.edu/sasl/)
.SH ACKNOWLEDGEMENTS
diff --git a/doc/man/man3/ldap_compare.3 b/doc/man/man3/ldap_compare.3
index 500c8faa2412577f76844703986fc38a7fae29bc..fff40d1d533e8d9ca13c6e30295ae3b9bdd720a9 100644
--- a/doc/man/man3/ldap_compare.3
+++ b/doc/man/man3/ldap_compare.3
@@ -12,86 +12,68 @@ OpenLDAP LDAP (libldap, -lldap)
#include <ldap.h>
.LP
.ft B
-int ldap_compare_s(ld, dn, attr, value)
-.ft
-LDAP *ld;
-char *dn, *attr, *value;
-.LP
+int ldap_compare_ext(
+.RS
.ft B
-int ldap_compare(ld, dn, attr, value)
-.ft
-LDAP *ld;
-char *dn, *attr, *value;
+LDAP *\fIld\fB,
+char *\fIdn\fB,
+char *\fIattr\fB,
+const struct berval *\fIbvalue\fB,
+LDAPControl **\fIserverctrls\fB,
+LDAPControl **\fIclientctrls\fB,
+int *\fImsgidp\fB );
+.RE
.LP
.ft B
-int ldap_compare_ext(ld, dn, attr, bvalue, serverctrls, clientctrls, msgidp)
-.ft
-LDAP *ld;
-char *dn, *attr;
-const struct berval *bvalue;
-LDAPControl **serverctrls, **clientctrls;
-int *msgidp;
-.LP
+int ldap_compare_ext_s(
+.RS
.ft B
-int ldap_compare_ext_s(ld, dn, attr, bvalue, serverctrls, clientctrls)
-.ft
-LDAP *ld;
-char *dn, *attr;
-const struct berval *bvalue;
-LDAPControl **serverctrls, **clientctrls;
+LDAP *\fIld\fB,
+char *\fIdn\fB,
+char *\fIattr\fB,
+const struct berval *\fIbvalue\fB,
+LDAPControl **\fIserverctrls\fB,
+LDAPControl **\fIclientctrls\fB );
+.RE
.SH DESCRIPTION
The
-.B ldap_compare_s()
-routine is used to perform an LDAP compare operation
-synchronously. It takes \fIdn\fP, the DN of the entry upon which to perform
-the compare, and \fIattr\fP and \fIvalue\fP, the attribute type and value to
-compare to those found in the entry. It returns an LDAP error code, which
+.B ldap_compare_ext_s()
+routine is used to perform an LDAP compare operation synchronously.
+It takes \fIdn\fP, the DN of the entry upon which to perform the
+compare, and \fIattr\fP and \fIvalue\fP, the attribute description and
+value to compare to those found in the entry. It returns a code, which
will be LDAP_COMPARE_TRUE if the entry contains the attribute value and
-LDAP_COMPARE_FALSE if it does not. Otherwise, some error code is returned.
+LDAP_COMPARE_FALSE if it does not. Otherwise, an error code is
+returned that indicates the nature of the problem. See
+.BR ldap (3)
+for details.
.LP
The
-.B ldap_compare()
+.B ldap_compare_ext()
routine is used to perform an LDAP compare operation
asynchronously. It takes the same parameters as
-.BR ldap_compare_s() ,
-but returns the message id of the request it initiated. The result of
+.BR ldap_compare_ext_s() ,
+but provides the message id of the request it initiated in the
+integer pointed to \fImsgidp\fP. The result of
the compare can be obtained by a subsequent call to
.BR ldap_result (3).
.LP
-The
-.B ldap_compare_ext()
-routine allows server and client controls to be
-specified to extend the compare request. This routine is asynchronous like
-ldap_compare(), but its return value is an LDAP error code. It stores the
-message id of the request in the integer pointed to by msgidp.
-.LP
-The
-.B ldap_compare_ext_s()
-routine is the synchronous version of
-.BR ldap_compare_ext().
-It also returns an LDAP error code indicating success
-or failure of the operation.
-.SH ERRORS
-.B ldap_compare_s()
-returns an LDAP error code which can be interpreted
-by calling one of
-.BR ldap_perror (3)
-and friends. ldap_compare() returns
--1 if something went wrong initiating the request. It returns the
-non-negative message id of the request if things went ok.
-.LP
-.B ldap_compare_ext_s()
+Both routines allow server and client controls to be specified to
+extend the compare request.
+.SH DEPRECATED INTERFACES
+The routines
+.BR ldap_compare ()
and
-.B ldap_compare_ext()
-return some Non-zero value other than 0x05 or 0x06 in case of failure.
-0x05 corresponds to LDAP_COMPARE_FALSE and 0x06 corresponds to LDAP_COMPARE_TRUE.
-.SH BUGS
-There is no way to compare binary values, but there should be.
+.BR ldap_compare_s ()
+are deprecated in favor of
+.BR ldap_compare_ext ()
+and
+.BR ldap_compare_ext_s (),
+respectively.
+.LP
+.so Deprecated
.SH SEE ALSO
.BR ldap (3),
.BR ldap_error (3)
.SH ACKNOWLEDGEMENTS
-.B OpenLDAP
-is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
-.B OpenLDAP
-is derived from University of Michigan LDAP 3.3 Release.
+.so ../Project
diff --git a/doc/man/man3/ldap_error.3 b/doc/man/man3/ldap_error.3
index 4b5ebfc55492f8a0b9bdb5962adfc3f87a63ec43..b3ff7637cbc138329659a9417c66fb4f438ba520 100644
--- a/doc/man/man3/ldap_error.3
+++ b/doc/man/man3/ldap_error.3
@@ -12,18 +12,20 @@ OpenLDAP LDAP (libldap, -lldap)
#include <ldap.h>
.LP
.ft B
-char *ldap_err2string( int err );
-.LP
-.ft B
-void ldap_perror( LDAP *ld, const char *s )
-.LP
-.ft B
-int ldap_result2error( LDAP *ld, LDAPMessage *res, int freeit )
+char *ldap_err2string( int \fIerr\fB );
.SH DESCRIPTION
-These routines provide interpretation of the various error codes
-returned by the LDAP protocol and LDAP library routines or associated
-with an LDAP session. The error code associated with an LDAP session
-is accessible using
+The
+.B ldap_err2string()
+routine provides short description of the various codes returned by
+routines in this library. The returned string is a pointer to a
+static area that should not be modified.
+
+These codes are either negative,
+indicating an API error code; positive, indicating an LDAP resultCode
+other than \'success' (0), or - zero, indicating both successful use
+of the API and the LDAP resultCode \'success' (0).
+
+The code associated with an LDAP session is accessible using
.BR ldap_get_option (3)
and
.BR ldap_set_option (3)
@@ -31,38 +33,15 @@ with the
.B LDAP_OPT_RESULT_CODE
option (previously called
.BR LDAP_OPT_ERROR_NUMBER ).
-.LP
-The
-.B ldap_result2error()
-routine takes \fIres\fP, a result as produced by
-.BR ldap_result (3)
-or
-.BR ldap_search_s (3),
-and returns
-the corresponding error code. Possible error codes are listed
-below. If the \fIfreeit\fP parameter is non zero it indicates that the
-\fIres\fP parameter should be freed by a call to
-.BR ldap_msgfree (3)
-after the error code has been extracted. The
-.B ld_errno
-field in \fIld\fP is set and returned.
-.LP
-The returned value can be passed to
-.B ldap_err2string()
-to get a text description of the message. The string
-returned from
-.B ldap_err2string()
-is a pointer to a static area that
-should not be modified.
-.LP
-The
-.B ldap_perror()
-routine can be called to print an indication of
-the error on standard error, similar to the way
-.BR perror (3)
-works.
-.SH ERRORS
-The possible values for an ldap error code are:
+
+.SH PROTOCOL RESULT CODES
+
+This section provides a partial list of protocol codes recognized
+by the library. As LDAP is extensible, additional values may be
+returned. A complete listing of \fIregistered\fP LDAP result codes
+can be obtained from the \fIInternet Assigned Numbers Authority\fP
+<http://www.iana.org>.
+
.LP
.TP 20
.SM LDAP_SUCCESS
@@ -172,7 +151,17 @@ Object class modifications are not allowed.
.TP
.SM LDAP_OTHER
An unknown error occurred.
-.TP
+
+.SH API ERROR CODES
+
+This section provides a complete list of API error codes recognized
+by the library. Note that LDAP_SUCCESS indicates success of an
+API call in addition to representing the return of the LDAP
+\'success' resultCode.
+
+
+.LP
+.TP 20
.SM LDAP_SERVER_DOWN
The LDAP library can't contact the LDAP server.
.TP
@@ -200,13 +189,36 @@ An ldap routine was called with a bad parameter.
.TP
.SM LDAP_NO_MEMORY
An memory allocation (e.g., malloc(3) or other dynamic memory
-allocator) call failed in an ldap
-library routine.
+allocator) call failed in an ldap library routine.
+.TP
+.SM LDAP_USER_CANCELED
+Indicates the user cancelled the operation.
+.TP
+.SM LDAP_CONNECT_ERROR
+Indicates a connection problem.
+.TP
+.SM LDAP_NOT_SUPPORTED
+Indicates the routine was called in a manner not supported by the library.
+.TP
+.SM LDAP_CONTROL_NOT_FOUND
+Indicates the control provided is unknown to the client library.
+.TP
+.SM LDAP_NO_RESULTS_RETURNED
+Indicates no results returned.
+.TP
+.SM LDAP_MORE_RESULTS_TO_RETURN
+Indicates more results could be returned.
+.TP
+.SM LDAP_CLIENT_LOOP
+Indicates the library has detected a loop in its processing.
+.TP
+.SM LDAP_REFERRAL_LIMIT_EXCEEDED
+Indicates the referral limit has been exceeded.
+
+.SH DEPRECATED
+.so Deprecated
+
.SH SEE ALSO
.BR ldap (3),
-.BR perror (3)
.SH ACKNOWLEDGEMENTS
-.B OpenLDAP
-is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
-.B OpenLDAP
-is derived from University of Michigan LDAP 3.3 Release.
+.so ../Project
diff --git a/doc/man/man3/ldap_extended_operation.3 b/doc/man/man3/ldap_extended_operation.3
index 2c9e31037d98bd0ffb769395bcdf29404261a6fb..2723bfb8a33bc9c7617f3d6e70161a9d9644ebcf 100644
--- a/doc/man/man3/ldap_extended_operation.3
+++ b/doc/man/man3/ldap_extended_operation.3
@@ -12,53 +12,64 @@ OpenLDAP LDAP (libldap, -lldap)
#include <ldap.h>
.LP
.ft B
-int ldap_extended_operation( ld, requestoid, requestdata, sctrls[], cctrls[], msgidp );
-.ft
-LDAP *ld;
-const char *requestoid;
-const struct berval *requestdata;
-LDAPControl *sctrls[], *cctrls[];
-int *msgidp;
+int ldap_extended_operation(
+.RS
+.ft B
+LDAP *\fIld\fB,
+const char *\fIrequestoid\fB,
+const struct berval *\fIrequestdata\fB,
+LDAPControl **\fIsctrls\fB,
+LDAPControl **\fIcctrls\fB,
+int *\fImsgidp\fB );
+.RE
.LP
.ft B
-int ldap_extended_operation_s( ld, requestoid, requestdata, sctrls[], cctrls[], retoidp, retdatap );
-.ft
-LDAP *ld,
-const char *requestoid;
-const struct berval *requestdata;
-LDAPControl *sctrls[], *cctrls[];
-char **retoidp;
-struct berval **retdatap;
+int ldap_extended_operation_s(
+.RS
+.ft B
+LDAP *\fIld\fB,
+const char *\fIrequestoid\fB,
+const struct berval *\fIrequestdata\fB,
+LDAPControl **\fIsctrls\fB,
+LDAPControl **\fIcctrls\fB,
+char **\fIretoidp\fB;
+struct berval **\fIretdatap\fB );
+.RE
.SH DESCRIPTION
The
-.B ldap_extended_operation_s
-method is used to synchronously send an extended operation to the server.
-It takes \fIrequestoid\fP, which points to a dotted OID text string identifying
-the extended operation to perform. \fIrequestdata\fP is the data required for the
-operation, \fIseverctrls\fP is an array of LDAPControl structures to use with this
-extended operation,\fIclientctrls\fP is an array of LDAPControl structures that list
-the client controls to use with this extended operation .The input parameter
-\fIretoidp\fP points to a dotted-OID text string returned by the LDAP server.
-The memory used by the string should be freed with the ldap_memfree function.
-retdatap is an output parameter which points to a pointer to a berval structure
-that contains the returned data. If no data is returned, the server set this
-to NULL. The memory used by this structure should be freed with the ber_bvfree
+.B ldap_extended_operation_s()
+routine is used to synchronously perform an LDAP extended operation.
+It takes \fIrequestoid\fP, which points to a dotted-decimal OID string
+identifying the extended operation to perform. \fIrequestdata\fP is the
+data required for the request, \fIsctrls\fP is an array of LDAPControl
+structures to use with this extended operation, \fIcctrls\fP is an array
+of LDAPControl structures that list the client controls to use with
+this extended operation.
+.LP
+The output parameter \fIretoidp\fP points to a dotted-decimal OID
+string returned by the LDAP server. The memory used by the string
+should be freed with the
+.BR ldap_memfree (3)
+function.
+The output parameter \fIretdatap\fP points to a pointer to a berval
+structure that contains the returned data. If no data is returned
+by the server, the pointer is set this to NULL. The memory used by
+this structure should be freed with the
+.BR ber_bvfree (3)
function.
.LP
The
-.B ldap_extended_operation
-works just like ldap_extended_operation_s, but the operation is asynchornous.
-It returns the message id of the request it initiated.
+.B ldap_extended_operation()
+works just like
+.BR ldap_extended_operation_s() ,
+but the operation is asynchornous. It provides the message id of
+the request it initiated in the integer pointed to be \fImsgidp\fP.
The result of this operation can be obtained by calling
.BR ldap_result(3).
-.SH NOTES
-The LDAP server must support the operation; otherwise an
-LDAP_NOT_SUPPORTED error is returned.
.SH SEE ALSO
-.BR ldap_result (3),
-.BR ldap_parse_extended_result (3)
+.BR ber_bvfree (3),
+.BR ldap_memfree (3),
+.BR ldap_parse_extended_result (3),
+.BR ldap_result (3)
.SH ACKNOWLEDGEMENTS
-.B OpenLDAP
-is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
-.B OpenLDAP
-is derived from University of Michigan LDAP 3.3 Release.
+.so ../Project
diff --git a/doc/man/man3/ldap_get_dn.3 b/doc/man/man3/ldap_get_dn.3
index bb176b5fe1a2948d928698e7a53c2e1a20cadaa4..12f7ae6dce254ba6409e519f61316b75d6261cea 100644
--- a/doc/man/man3/ldap_get_dn.3
+++ b/doc/man/man3/ldap_get_dn.3
@@ -41,8 +41,8 @@ char *ldap_dn2ad_canonical( const char * dn )
These routines allow LDAP entry names (Distinguished Names, or DNs)
to be obtained, parsed, converted to a user-friendly form, and tested.
A DN has the form described in
-RFC 2253 "Lightweight Directory Access Protocol (v3):
-UTF-8 String Representation of Distinguished Names".
+RFC 4414 "Lightweight Directory Access Protocol (LDAP):
+String Representation of Distinguished Names".
.LP
The
.B ldap_get_dn()
@@ -91,7 +91,7 @@ can be either
or
.B LDAP_AVA_BINARY,
the latter meaning that the value is BER/DER encoded and thus must
-be represented as, quoting from RFC 2253, " ... an
+be represented as, quoting from RFC 4514, " ... an
octothorpe character ('#' ASCII 35) followed by the hexadecimal
representation of each of the bytes of the BER encoding of the X.500
AttributeValue."
@@ -107,7 +107,7 @@ can be
LDAP_DN_FORMAT_DCE
.fi
-which defines what DN syntax is expected (according to RFC 2253,
+which defines what DN syntax is expected (according to RFC 4514,
RFC 1779 and DCE, respectively).
The format can be \fIOR\fPed to the flags
.LP
diff --git a/doc/man/man3/ldap_modify.3 b/doc/man/man3/ldap_modify.3
index 17b23f0b9a4f319b8f7c690c5aa333569b4d0fbf..ff4745a08d18b7468fba5d6307eca6f064e8dce5 100644
--- a/doc/man/man3/ldap_modify.3
+++ b/doc/man/man3/ldap_modify.3
@@ -3,7 +3,7 @@
.\" Copyright 1998-2006 The OpenLDAP Foundation All Rights Reserved.
.\" Copying restrictions apply. See COPYRIGHT/LICENSE.
.SH NAME
-ldap_modify, ldap_modify_s \- Perform an LDAP modify operation
+ldap_modify_ext, ldap_modify_ext_s \- Perform an LDAP modify operation
.SH LIBRARY
OpenLDAP LDAP (libldap, -lldap)
.SH SYNOPSIS
@@ -12,30 +12,40 @@ OpenLDAP LDAP (libldap, -lldap)
#include <ldap.h>
.LP
.ft B
-.nf
-int ldap_modify(ld, dn, mods)
-.ft
-LDAP *ld;
-char *dn;
-LDAPMod *mods[];
-.LP
+int ldap_modify_ext(
+.RS
.ft B
-.nf
-int ldap_modify_s(ld, dn, mods)
-.ft
-LDAP *ld;
-char *dn;
-LDAPMod *mods[];
+LDAP *\fIld\fB,
+char *\fIdn\fB,
+LDAPMod *\fImods[]\fB,
+LDAPControl **\fIsctrls\fB,
+LDAPControl **\fIcctrls\fB,
+int **\fImsgidp\fB );
+.RE
.LP
+.nf
+.ft B
+int ldap_modify_ext_s(
+.RS
.ft B
+LDAP *\fIld\fB,
+char *\fIdn\fB,
+LDAPMod *\fImods[]\fB,
+LDAPControl **\fIsctrls\fB,
+LDAPControl **\fIcctrls\fB );
+.RE
+.LP
.nf
-void ldap_mods_free( mods, freemods )
-.ft
-LDAPMod **mods;
-int freemods;
+.ft B
+void ldap_mods_free(
+.RS
+.ft B
+LDAPMod **\fImods\fB,
+int \fIfreemods\fB );
+.RE
.SH DESCRIPTION
The routine
-.B ldap_modify_s()
+.B ldap_modify_ext_s()
is used to perform an LDAP modify operation.
\fIdn\fP is the DN of the entry to modify, and \fImods\fP is a
null-terminated array of modifications to make to the entry. Each element
@@ -43,7 +53,6 @@ of the \fImods\fP array is a pointer to an LDAPMod structure, which is
defined below.
.LP
.nf
-.ft B
typedef struct ldapmod {
int mod_op;
char *mod_type;
@@ -82,41 +91,47 @@ modifications, the attribute will have the listed values after the
modification, having been created if necessary. All modifications are
performed in the order in which they are listed.
.LP
-.B
-ldap_modify_s()
-returns the LDAP error code resulting from the
-modify operation. This code can be interpreted by
-.BR ldap_perror (3)
-and friends.
+.B ldap_mods_free()
+can be used to free each element of a NULL-terminated
+array of mod structures. If \fIfreemods\fP is non-zero, the
+\fImods\fP pointer itself is freed as well.
+.LP
+.B ldap_modify_ext_s()
+returns a code indicating success or, in the case of failure,
+indicating the nature of the failure. See
+.BR ldap_error (3)
+for details
.LP
The
-.B ldap_modify()
+.B ldap_modify_ext()
operation works the same way as
-.BR ldap_modify_s() ,
-except that it is asynchronous, returning the message id of the
-request it initiates, or -1 on error. The result of the operation
-can be obtained by calling
+.BR ldap_modify_ext_s() ,
+except that it is asynchronous. The integer that \fImsgidp\fP points
+to is set to the message id of the modify request. The result of
+the operation can be obtained by calling
.BR ldap_result (3).
.LP
-.B ldap_mods_free()
-can be used to free each element of a NULL-terminated
-array of mod structures. If \fIfreemods\fP is non-zero, the
-\fImods\fP pointer itself is freed as well.
-.SH ERRORS
-.B ldap_modify_s()
-returns an ldap error code, either LDAP_SUCCESS or
-an error if there was trouble.
+Both
+.B ldap_modify_ext()
+and
+.B ldap_modify_ext_s()
+allows server and client controls to be passed in
+via the sctrls and cctrls parameters, respectively.
+.SH DEPRECATED INTERFACES
+The
.B ldap_modify()
-returns -1 in case
-of trouble, setting the
-.B ld_errno
-field of \fIld\fP.
+and
+.B ldap_modify_s()
+routines are deprecated in favor of the
+.B ldap_modify_ext()
+and
+.B ldap_modify_ext_s()
+routines, respectively.
+.LP
+.so Deprecated
.SH SEE ALSO
.BR ldap (3),
.BR ldap_error (3),
-.BR ldap_add (3)
.SH ACKNOWLEDGEMENTS
-.B OpenLDAP
-is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
-.B OpenLDAP
-is derived from University of Michigan LDAP 3.3 Release.
+.so ../Project
+
diff --git a/doc/man/man3/ldap_schema.3 b/doc/man/man3/ldap_schema.3
index 13518a7aa65a28a7478b7a8bc8b24cf36d7c7a5b..d6e5ab49f30fe9733b47708b49c63cd850fb32bc 100644
--- a/doc/man/man3/ldap_schema.3
+++ b/doc/man/man3/ldap_schema.3
@@ -117,13 +117,13 @@ char * ldap_scherr2str(code)
int code;
.SH DESCRIPTION
These routines are used to parse schema definitions in the syntax
-defined in RFC 2252 into structs and handle these structs. These
+defined in RFC 4512 into structs and handle these structs. These
routines handle four kinds of definitions: syntaxes, matching rules,
attribute types and object classes. For each definition kind, four
routines are provided.
.LP
.B ldap_str2xxx()
-takes a definition in RFC 2252 format in argument
+takes a definition in RFC 4512 format in argument
.IR s
as a NUL-terminated string and returns, if possible, a pointer to a
newly allocated struct of the appropriate kind. The caller is
@@ -145,7 +145,7 @@ is a bit mask of parsing options controlling the relaxation of the
syntax recognized. The following values are defined:
.TP
.B LDAP_SCHEMA_ALLOW_NONE
-strict parsing according to RFC 2252.
+strict parsing according to RFC 4512.
.TP
.B LDAP_SCHEMA_ALLOW_NO_OID
permit definitions that do not contain an initial OID.
@@ -278,7 +278,7 @@ return a canonical name for the definition.
.LP
Routines
.B ldap_xxx2str()
-return a string representation in the format described by RFC 2252 of
+return a string representation in the format described by RFC 4512 of
the struct passed in the argument. The string is a newly allocated
string that must be freed by the caller. These routines may return
NULL if no memory can be allocated for the string.
diff --git a/doc/man/man3/ldap_search.3 b/doc/man/man3/ldap_search.3
index 0f398ea66b42532d13fd301b4810517c0434ce1a..abbdc6e6a68f684dd0f1873a76c6ab473298a32b 100644
--- a/doc/man/man3/ldap_search.3
+++ b/doc/man/man3/ldap_search.3
@@ -9,167 +9,100 @@ OpenLDAP LDAP (libldap, -lldap)
.SH SYNOPSIS
.nf
.ft B
-#include <sys/time.h> /* for struct timeval definition */
+#include <sys/types.h>
#include <ldap.h>
.LP
.ft B
-int ldap_search(ld, base, scope, filter, attrs, attrsonly)
-.ft
-LDAP *ld;
-char *base;
-int scope;
-char *filter, *attrs[];
-int attrsonly;
+int ldap_search_ext(
+.RS
+LDAP *\fIld\fB,
+char *\fIbase\fB,
+int \fIscope\fB,
+char *\fIfilter\fB,
+char *\fIattrs\fB[],
+int \fIattrsonly\fB,
+LDAPControl **\fIserverctrls\fB,
+LDAPControl **\fIclientctrls\fB,
+struct timeval *\fItimeout\fB,
+int sizelimit, *\fImsgidp\fB );
+.RE
.LP
.ft B
-int ldap_search_s(ld, base, scope, filter, attrs, attrsonly, res)
-.ft
-LDAP *ld;
-char *base;
-int scope;
-char *filter, *attrs[]
-int attrsonly;
-LDAPMessage **res;
-.LP
-.ft B
-int ldap_search_st(ld, base, scope, filter, attrs, attrsonly, timeout, res)
-.ft
-LDAP *ld;
-char *base;
-int scope;
-char *filter, *attrs[]
-int attrsonly;
-struct timeval *timeout;
-LDAPMessage **res;
-.LP
-.ft B
-int ldap_search_ext(ld, base, scope, filter, attrs, attrsonly, serverctrls,
-.ft
-clientctrls, timeout, sizelimit, msgidp)
-.ft
-LDAP *ld;
-char *base;
-int scope;
-char *filter, *attrs[]
-int attrsonly;
-LDAPControl **serverctrls, **clientctrls;
-struct timeval *timeout;
-int sizelimit, *msgidp;
-.LP
-.ft B
-int ldap_search_ext_s(ld, base, scope, filter, attrs, attrsonly, serverctrls,
-.ft
-clientctrls, timeout, sizelimit, res)
-.ft
-LDAP *ld;
-char *base;
-int scope;
-char *filter, *attrs[]
-int attrsonly;
-LDAPControl **serverctrls, **clientctrls;
-struct timeval *timeout;
-int sizelimit;
-LDAPMessage **res;
+int ldap_search_ext_s(
+.RS
+LDAP *\fIld\fB,
+char *\fIbase\fB,
+int \fIscope\fB,
+char *\fIfilter\fB,
+char *\fIattrs\fB[],
+int \fIattrsonly\fB,
+LDAPControl **\fIserverctrls\fB,
+LDAPControl **\fIclientctrls\fB,
+struct timeval *\fItimeout\fB,
+LDAPMessage **\fIres\fB );
+.RE
.SH DESCRIPTION
These routines are used to perform LDAP search operations.
-.B ldap_search_s()
+The
+.B ldap_search_ext_s()
+routine
does the search synchronously (i.e., not
-returning until the operation completes).
-.B ldap_search_st()
-does
-the same, but allows a \fItimeout\fP to be specified.
-.B ldap_search()
-is the asynchronous version, initiating the search and returning
-the message id of the operation it initiated.
-\fIBase\fP is the DN of the entry at which to start the search.
-\fIScope\fP is the scope of the search and should be one of LDAP_SCOPE_BASE,
-to search the object itself,
-LDAP_SCOPE_ONELEVEL, to search the object's immediate children,
-or LDAP_SCOPE_SUBTREE, to search the object and all its descendants.
+returning until the operation completes), providing a pointer
+to the resulting LDAP messages at the location pointed to by
+the \fIres\fP parameter.
.LP
-\fIFilter\fP is a string
-
-representation of the filter to apply in the search. Simple filters
-can be specified as \fI(attributetype=attributevalue)\fP. More complex
-filters are specified using a prefix notation according to the following
-BNF:
+The
+.B ldap_search_ext()
+routine is the asynchronous version, initiating the search and returning
+the message id of the operation it initiated in the integer
+pointed to by the \fImsgidp\fP parameter.
.LP
-.nf
- <filter> ::= '(' <filtercomp> ')'
- <filtercomp> ::= <and> | <or> | <not> | <simple>
- <and> ::= '&' <filterlist>
- <or> ::= '|' <filterlist>
- <not> ::= '!' <filter>
- <filterlist> ::= <filter> | <filter> <filterlist>
- <simple> ::= <attributetype> <filtertype> <attributevalue>
- <filtertype> ::= '=' | '~=' | '<=' | '>='
-.fi
+The \fIbase\fP parameter is the DN of the entry at which to start the search.
.LP
-The '~=' construct is used to specify approximate matching. The
-representation for <attributetype> and <attributevalue> are as
-described in RFC 2254. In addition, <attributevalue> can be a single *
-to achieve an attribute existence test, or can contain text and *'s
-interspersed to achieve substring matching.
+The \fIscope\fP parameter is the scope of the search and should be one
+of LDAP_SCOPE_BASE, to search the object itself, LDAP_SCOPE_ONELEVEL,
+to search the object's immediate children, LDAP_SCOPE_SUBTREE, to
+search the object and all its descendants, or LDAP_SCOPE_CHILDREN,
+to search all of the descendants. Note that the latter requires
+the server support the LDAP Subordinates Search Scope extension.
.LP
-For example, the filter "(mail=*)" will find any entries that have a mail
-attribute. The filter "(mail=*@terminator.rs.itd.umich.edu)" will find
-any entries that have a mail attribute ending in the specified string.
-To put parentheses in a filter, escape them with a backslash '\\'
-character. See RFC 2254 for a more complete description of allowable
-filters.
+The \fIfilter\fP is a string representation of the filter to
+apply in the search. The string should conform to the format
+specified in RFC 4515 as extended by RFC 4526. For instance,
+"(cn=Jane Doe)". Note that use of the extension requires the
+server to support the LDAP Absolute True/False Filter extension.
+NULL may be specified to indicate the library should send the
+filter (objectClass=*).
.LP
-\fIAttrs\fP is a null-terminated array of attribute types to return
-from entries that match \fIfilter\fP.
+The \fIattrs\fP parameter is a null-terminated array of attribute
+descriptions to return from matching entries.
If NULL is specified, the return of all user attributes is requested.
-The type "*" (LDAP_ALL_USER_ATTRIBUTES) may be used to request
+The description "*" (LDAP_ALL_USER_ATTRIBUTES) may be used to request
all user attributes to be returned.
-The type "+"(LDAP_ALL_OPERATIONAL_ATTRIBUTES) may be used to request
-all operational attributes to be returned.
-To request no attributes, the type "1.1" (LDAP_NO_ATTRS)
+The description "+"(LDAP_ALL_OPERATIONAL_ATTRIBUTES) may be used to
+request all operational attributes to be returned. Note that this
+requires the server to suppor the LDAP All Operational Attribute
+extension.
+To request no attributes, the description "1.1" (LDAP_NO_ATTRS)
should be listed by itself.
.LP
-\fIAttrsonly\fP should be set to 1 if
-only attribute types are wanted. It should be set to 0 if both
-attributes types and attribute values are wanted.
+The \fIattrsonly\fP parameter should be set to a non-zero value
+if only attribute descriptions are wanted. It should be set to zero (0)
+if both attributes descriptions and attribute values are wanted.
.LP
-.B ldap_search_ext()
-routine allows server and client controls to be specified to extend
-the search request. This routine is asynchronous like
-.BR ldap_search() ,
-but its return value is an LDAP error code. It stores the message id
-of the request in the integer pointed to
-by
-.IR msgidp .
+The \fIserverctrls\fP and \fIclientctrls\fP parameters may be used
+to specify server and client controls, respectively.
.LP
The
.B ldap_search_ext_s()
routine is the synchronous version of
.BR ldap_search_ext().
-It also returns an LDAP error code indicating success or failure
-of the operation.
-.SH ERRORS
-.B ldap_search_s()
-and
-.B ldap_search_st()
-will return the LDAP error code resulting from the search operation.
-See
+.LP
+It also returns a code indicating success or, in the
+case of failure, indicating the nature of the failure
+of the operation. See
.BR ldap_error (3)
for details.
-.B ldap_search()
-returns -1 in case of trouble.
-.LP
-.B ldap_search_s(),
-.B ldap_search_ext_s
-and
-.B ldap_search_st()
-will return the LDAP error code resulting from the search operation.
-See
-.BR ldap_error (3)
-for details.
-.B ldap_search()
-and
-.B ldap_search_ext
-returns -1 in case of trouble.
.SH NOTES
Note that both read
and list functionality are subsumed by these routines,
@@ -179,12 +112,23 @@ emulate read) or LDAP_SCOPE_ONELEVEL (to emulate list).
These routines may dynamically allocate memory. The caller is
responsible for freeing such memory using supplied deallocation
routines. Return values are contained in <ldap.h>.
+.SH DEPRECATED INTERFACES
+The
+.B ldap_search()
+routine is deprecated in favor of the
+.B ldap_search_ext()
+routine. The
+.B ldap_search_s()
+and
+.B ldap_search_st()
+routines are deprecated in favor of the
+.B ldap_search_ext_s()
+routine.
+.LP
+.so Deprecated
.SH SEE ALSO
.BR ldap (3),
.BR ldap_result (3),
.BR ldap_error (3)
.SH ACKNOWLEDGEMENTS
-.B OpenLDAP
-is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
-.B OpenLDAP
-is derived from University of Michigan LDAP 3.3 Release.
+.so ../Project
diff --git a/doc/man/man3/ldap_sort.3 b/doc/man/man3/ldap_sort.3
index 63ef8dffd145df83c6cd47210ad856e2318c5bcb..3d13b377f601dc43e00725af8308a1a41582dc91 100644
--- a/doc/man/man3/ldap_sort.3
+++ b/doc/man/man3/ldap_sort.3
@@ -3,114 +3,19 @@
.\" Copyright 1998-2006 The OpenLDAP Foundation All Rights Reserved.
.\" Copying restrictions apply. See COPYRIGHT/LICENSE.
.SH NAME
-ldap_sort_entries, ldap_sort_values, ldap_sort_strcasecmp \- LDAP sorting routines
+LDAP sorting routines (deprecated)
.SH LIBRARY
OpenLDAP LDAP (libldap, -lldap)
-.SH SYNOPSIS
-.nf
-.ft B
-#include <ldap.h>
-.LP
-.ft B
-ldap_sort_entries(ld, chain, attr, cmp)
-.ft
-LDAP *ld;
-LDAPMessage **chain;
-char *attr;
-int (*cmp)();
-.LP
-.ft B
-ldap_sort_values(ld, vals, cmp)
-.ft
-LDAP *ld;
-char **vals;
-int (*cmp)();
-.LP
-.ft B
-ldap_sort_strcasecmp(a, b)
-.ft
-char *a;
-char *b;
.SH DESCRIPTION
-These routines are used to sort lists of entries and values retrieved
-from an LDAP server.
-.B ldap_sort_entries()
-is used to sort a chain
-of entries retrieved from an LDAP search call either by DN or by some
-arbitrary attribute in the entries. It takes \fIld\fP, the LDAP
-structure, which is only used for error reporting, \fIchain\fP, the
-list of entries as returned by
-.BR ldap_search_s (3)
-or
-.BR ldap_result (3).
-\fIattr\fP is the attribute to use as a key in the sort
-or NULL to sort by DN, and \fIcmp\fP is the comparison function to use
-when comparing values (or individual DN components if sorting by DN).
-In this case, \fIcmp\fP should be a function taking two single values
-of the \fIattr\fP to sort by, and returning a value less than zero,
-equal to zero, or greater than zero, depending on whether the first
-argument is less than, equal to, or greater than the second argument.
-The convention is the same as used by
-.BR qsort (3),
-which is called to do the actual sorting.
-.LP
-.B ldap_sort_values()
-is used to sort an array of values from an entry,
-as returned by
-.BR ldap_get_values (3).
-It takes the LDAP connection
-structure \fIld\fP, the array of values
-to sort \fIvals\fP, and \fIcmp\fP, the comparison
-function to use during the sort.
-Note that \fIcmp\fP will be passed a pointer to each element in the
-\fIvals\fP array, so if you pass the normal char ** for this parameter,
-\fIcmp\fP should take two char **'s as arguments (i.e., you cannot
-pass \fIstrcasecmp\fP or its friends for \fIcmp\fP). You can, however,
-pass the function
-.B ldap_sort_strcasecmp()
-for this purpose.
-.LP
-For example:
-.LP
-.nf
-.ft tt
- LDAP *ld;
- LDAPMessage *res;
-
- /*
- * ... call to ldap_search_s(), fill in res,
- * retrieve sn attr ...
- */
-
- /* now sort the entries on surname attribute */
- if ( ldap_sort_entries( ld, &res, "sn",
- ldap_sort_strcasecmp ) != 0 )
- ldap_perror( ld, "ldap_sort_entries" );
-.ft
-.fi
-.SH NOTES
-.LP
The
-.B ldap_sort_entries()
-routine applies the comparison function to
-each value of the attribute in the array as returned by a call to
-.BR ldap_get_values (3),
-until a mismatch is found.
-This works fine for single-valued attributes, but
-may produce unexpected results for multi-valued attributes.
-When sorting by DN, the comparison function is
-applied to an exploded version of the DN, without types.
-The return values for all of these functions are declared in the
-<ldap.h> header file. Some routines may dynamically allocate memory.
-Callers are responsible for freeing such memory using the supplied
-deallocation routines.
+.BR ldap_sort_entries (),
+.BR ldap_sort_values (),
+and
+.BR ldap_sort_strcasecmp ()
+are deprecated.
+.LP
+.so Deprecated
.SH SEE ALSO
-.BR ldap (3),
-.BR ldap_search (3),
-.BR ldap_result (3),
-.BR qsort (3)
+.BR ldap (3)
.SH ACKNOWLEDGEMENTS
-.B OpenLDAP
-is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
-.B OpenLDAP
-is derived from University of Michigan LDAP 3.3 Release.
+.so ../Project
diff --git a/doc/man/man3/ldap_url.3 b/doc/man/man3/ldap_url.3
index 89dfcd4e50b7c5927b3fb0b5c4d5400e76b83fc2..2093116fb52afef487a93afa0ae6fa4c0a04076f 100644
--- a/doc/man/man3/ldap_url.3
+++ b/doc/man/man3/ldap_url.3
@@ -12,7 +12,6 @@ OpenLDAP LDAP (libldap, -lldap)
.nf
.ft B
#include <ldap.h>
-.ft
.LP
.ft B
int ldap_is_ldap_url( const char *url )
@@ -37,7 +36,7 @@ typedef struct ldap_url_desc {
ldap_free_urldesc( LDAPURLDesc *ludp )
.SH DESCRIPTION
These routines support the use of LDAP URLs (Uniform Resource Locators)
-as detailed in RFC 2255. LDAP URLs look like this:
+as detailed in RFC 4516. LDAP URLs look like this:
.nf
\fBldap://\fP\fIhostport\fP\fB/\fP\fIdn\fP[\fB?\fP\fIattrs\fP[\fB?\fP\fIscope\fP[\fB?\fP\fIfilter\fP[\fB?\fP\fIexts\fP]]]]
@@ -57,7 +56,7 @@ Example:
.fi
.LP
URLs that are wrapped in angle-brackets and/or preceded by "URL:" are also
-tolerated. Alternative schemes such as ldaps:// and ldapi:// may be
+tolerated. Alternative LDAP schemes such as ldaps:// and ldapi:// may be
parsed using the below routines as well.
.LP
.B ldap_is_ldap_url()
@@ -78,12 +77,9 @@ should be called to free an LDAP URL description that was obtained from
a call to
.B ldap_url_parse().
.SH SEE ALSO
+.nf
.BR ldap (3)
-.LP
-.B The LDAP URL Format, RFC 2255,
-Tim Howes and Mark Smith, December 1997.
+.BR "RFC 4516" " <http://www.rfc-editor.org/rfc/rfc4516.txt>"
.SH ACKNOWLEDGEMENTS
-.B OpenLDAP
-is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
-.B OpenLDAP
-is derived from University of Michigan LDAP 3.3 Release.
+.fi
+.so ../Project
diff --git a/doc/man/man5/slapd-dnssrv.5 b/doc/man/man5/slapd-dnssrv.5
index 67f9ba1007f7479e50a64e9a0ce67e23c0ee130e..b3989e3af6db8264f70d0365d629ad1422d84060 100644
--- a/doc/man/man5/slapd-dnssrv.5
+++ b/doc/man/man5/slapd-dnssrv.5
@@ -26,7 +26,7 @@ In fact, this backend only implements the
.B search
operation when the
.B manageDSAit
-control (RFC3296) is used, otherwise for every operation a referral,
+control (RFC 3296) is used, otherwise for every operation a referral,
whenever appropriate, or an error is returned.
Currently, there is no means to condition the returning of the referral
by means of ACLs; no access control is implemented, except for
diff --git a/doc/man/man5/slapd-ldap.5 b/doc/man/man5/slapd-ldap.5
index 0011354612c072516061d7c782d9c27ad2534e7e..79eb9349e38ce14fad15ce16d91ebc0705cc74ec 100644
--- a/doc/man/man5/slapd-ldap.5
+++ b/doc/man/man5/slapd-ldap.5
@@ -121,6 +121,36 @@ and
.BR acl-passwd .
.RE
+.TP
+.B cancel {ABANDON|ignore|exop[-discover]}
+Defines how to handle operation cancellation.
+By default,
+.B abandon
+is invoked, so the operation is abandoned immediately.
+If set to
+.BR ignore ,
+no action is taken and any further response is ignored; this may result
+in further response messages to be queued for that connection, so it is
+recommended that long lasting connections are timed out either by
+.I idle-timeout
+or
+.IR conn-ttl ,
+so that resources eventually get released.
+If set to
+.BR exop ,
+a
+.I cancel
+operation (RFC 3909) is issued, resulting in the cancellation
+of the current operation; the
+.I cancel
+operation waits for remote server response, so its use
+may not be recommended.
+If set to
+.BR exop-discover ,
+support of the
+.I cancel
+extended operation is detected by reading the remote server's root DSE.
+
.TP
.B chase-referrals {YES|no}
enable/disable automatic referral chasing, which is delegated to the
@@ -313,10 +343,6 @@ used by the client, otherwise the requested protocol is used.
The proxy returns \fIunwillingToPerform\fP if an operation that is
incompatible with the requested protocol is attempted.
-.TP
-.B single\-conn {NO|yes}
-Discards current cached connection when the client rebinds.
-
.TP
.B proxy\-whoami {NO|yes}
Turns on proxying of the WhoAmI extended operation. If this option is
@@ -326,12 +352,34 @@ request will be forwarded to the remote LDAP server. Other sessions will
be handled by the local slapd, as before. This option is mainly useful
in conjunction with Proxy Authorization.
+.TP
+.B quarantine <interval>,<num>[;<interval>,<num>[...]]
+Turns on quarantine of URIs that returned
+.IR LDAP_UNAVAILABLE ,
+so that an attempt to reconnect only occurs at given intervals instead
+of any time a client requests an operation.
+The pattern is: retry only after at least
+.I interval
+seconds elapsed since last attempt, for exactly
+.I num
+times; then use the next pattern.
+If
+.I num
+for the last pattern is "\fB+\fP", it retries forever; otherwise,
+no more retries occur.
+The process can be restarted by resetting the \fIolcDbQuarantine\fP
+attribute of the database entry in the configuration backend.
+
.TP
.B rebind-as-user {NO|yes}
If this option is given, the client's bind credentials are remembered
for rebinds when chasing referrals. Useful when
\fBchase-referrals\fP is set to \fByes\fP, useless otherwise.
+.TP
+.B single\-conn {NO|yes}
+Discards current cached connection when the client rebinds.
+
.TP
.B t-f-support {NO|yes|discover}
enable if the remote server supports absolute filters
@@ -370,12 +418,6 @@ as a side-effect, some of the traditional directives have been
deprecated and should be no longer used, as they might disappear
in future releases.
-.TP
-.B server <hostname[:port]>
-this directive is no longer supported. Use the
-.B uri
-directive as described above.
-
.TP
.B acl-authcDN "<administrative DN for access control purposes>"
DN which is used to query the target server for acl checking; it
@@ -446,6 +488,12 @@ arg of
.BR idassert-bind ,
and will be dismissed in the future.
+.TP
+.B server <hostname[:port]>
+this directive is no longer supported. Use the
+.B uri
+directive as described above.
+
.TP
.B suffixmassage, map, rewrite*
These directives are no longer supported by back-ldap; their
diff --git a/doc/man/man5/slapd-meta.5 b/doc/man/man5/slapd-meta.5
index 8beab5adff09f1ba83804a2e5224bb6c773a74a4..58d67604391382d490469c6c9835bf25705d9105 100644
--- a/doc/man/man5/slapd-meta.5
+++ b/doc/man/man5/slapd-meta.5
@@ -143,6 +143,24 @@ This directive, when set to
causes the authentication to the remote servers with the pseudo-root
identity to be deferred until actually needed by subsequent operations.
+.TP
+.B quarantine <interval>,<num>[;<interval>,<num>[...]]
+Turns on quarantine of URIs that returned
+.IR LDAP_UNAVAILABLE ,
+so that an attempt to reconnect only occurs at given intervals instead
+of any time a client requests an operation.
+The pattern is: retry only after at least
+.I interval
+seconds elapsed since last attempt, for exactly
+.I num
+times; then use the next pattern.
+If
+.I num
+for the last pattern is "\fB+\fP", it retries forever; otherwise,
+no more retries occur.
+This directive must appear before any target specification;
+it affects all targets with the same pattern.
+
.TP
.B rebind-as-user {NO|yes}
If this option is given, the client's bind credentials are remembered
diff --git a/doc/man/man5/slapd.access.5 b/doc/man/man5/slapd.access.5
index fd3fa6dd864e57b7510216c284c0717cf3db48a9..bf3f7f22ebd75c66ad83c2ba8504dcb4dc6884c2 100644
--- a/doc/man/man5/slapd.access.5
+++ b/doc/man/man5/slapd.access.5
@@ -194,7 +194,7 @@ The regex form of the pattern does not (yet) support UTF\-8.
.LP
The statement
.B filter=<ldapfilter>
-selects the entries based on a valid LDAP filter as described in RFC 2254.
+selects the entries based on a valid LDAP filter as described in RFC 4515.
A filter of
.B (objectClass=*)
is implied if no
@@ -860,11 +860,13 @@ as the first access rule.
As a consequence, unless the operation is performed with the
.B updatedn
identity, control is passed straight to the subsequent rules.
+
.SH OPERATION REQUIREMENTS
Operations require different privileges on different portions of entries.
The following summary applies to primary database backends such as
the BDB and HDB backends. Requirements for other backends may
(and often do) differ.
+
.LP
The
.B add
@@ -877,6 +879,10 @@ of the entry being added, and
privileges on the pseudo-attribute
.B children
of the entry's parent.
+When adding the suffix entry of a database, write access to
+.B children
+of the empty DN ("") is required.
+
.LP
The
.B bind
@@ -884,12 +890,14 @@ operation, when credentials are stored in the directory, requires
.B auth (=x)
privileges on the attribute the credentials are stored in (usually
.BR userPassword ).
+
.LP
The
.B compare
operation requires
.B compare (=c)
privileges on the attribute that is being compared.
+
.LP
The
.B delete
@@ -902,12 +910,14 @@ of the entry being deleted, and
privileges on the
.B children
pseudo-attribute of the entry's parent.
+
.LP
The
.B modify
operation requires
.B write (=w)
privileges on the attributes being modified.
+
.LP
The
.B modrdn
@@ -927,6 +937,7 @@ privileges are also required on the attributes that are present
in the old relative DN if
.B deleteoldrdn
is set to 1.
+
.LP
The
.B search
@@ -959,6 +970,7 @@ access to the attribute holding the referral information
(generally the
.B ref
attribute).
+
.LP
Some internal operations and some
.B controls
diff --git a/doc/man/man5/slapd.conf.5 b/doc/man/man5/slapd.conf.5
index c0b0058dc6156216ce1c63d0d232fcc4d2614a07..99f4154f411a32d274a26854b0fde22e857a763d 100644
--- a/doc/man/man5/slapd.conf.5
+++ b/doc/man/man5/slapd.conf.5
@@ -133,8 +133,8 @@ a trailing `-') matches all options starting with that name, as well
as the option with the range name sans the trailing `-'.
That is, `x-foo-bar-' matches `x-foo-bar' and `x-foo-bar-baz'.
-RFC 2251 reserves options beginning with `x-' for private experiments.
-Other options should be registered with IANA, see RFC 3383 section 3.4.
+RFC 4520 reserves options beginning with `x-' for private experiments.
+Other options should be registered with IANA, see RFC 4520 section 3.5.
OpenLDAP also has the `binary' option built in, but this is a transfer
option, not a tagging option.
.HP
@@ -153,8 +153,8 @@ option, not a tagging option.
[NO\-USER\-MODIFICATION]\
[USAGE\ <attributeUsage>]\ )"
.RS
-Specify an attribute type using the LDAPv3 syntax defined in RFC 2252.
-The slapd parser extends the RFC 2252 definition by allowing string
+Specify an attribute type using the LDAPv3 syntax defined in RFC 4512.
+The slapd parser extends the RFC 4512 definition by allowing string
forms as well as numeric OIDs to be used for the attribute OID and
attribute syntax OID.
(See the
@@ -374,6 +374,8 @@ e.g.
.RE
The protocol portion of the URI must be strictly
.BR ldap .
+Note that this search is subject to access controls. Specifically,
+the authentication identity must have "auth" access in the subject.
Multiple
.B authz-regexp
@@ -432,8 +434,8 @@ disallows the StartTLS operation if authenticated (see also
[MAY\ <oids>]\
[NOT\ <oids>]\ )"
.RS
-Specify an DIT Content Rule using the LDAPv3 syntax defined in RFC 2252.
-The slapd parser extends the RFC 2252 definition by allowing string
+Specify an DIT Content Rule using the LDAPv3 syntax defined in RFC 4512.
+The slapd parser extends the RFC 4512 definition by allowing string
forms as well as numeric OIDs to be used for the attribute OID and
attribute syntax OID.
(See the
@@ -637,8 +639,8 @@ the path is colon-separated but this depends on the operating system.
[{ ABSTRACT | STRUCTURAL | AUXILIARY }]\
[MUST\ <oids>] [MAY\ <oids>] )"
.RS
-Specify an objectclass using the LDAPv3 syntax defined in RFC 2252.
-The slapd parser extends the RFC 2252 definition by allowing string
+Specify an objectclass using the LDAPv3 syntax defined in RFC 4512.
+The slapd parser extends the RFC 4512 definition by allowing string
forms as well as numeric OIDs to be used for the object class OID.
(See the
.B
@@ -754,7 +756,9 @@ instance that handles that replication log.
.B require <conditions>
Specify a set of conditions (separated by white space) to
require (default none).
-The directive may be specified globally and/or per-database.
+The directive may be specified globally and/or per-database;
+databases inherit global conditions, so per-database specifications
+are additive.
.B bind
requires bind operation prior to directory operations.
.B LDAPv3
@@ -768,8 +772,9 @@ requires strong authentication prior to directory operations.
The strong keyword allows protected "simple" authentication
as well as SASL authentication.
.B none
-may be used to require no conditions (useful for clearly globally
-set conditions within a particular database).
+may be used to require no conditions (useful to clear out globally
+set conditions within a particular database); it must occur first
+in the list of conditions.
.TP
.B reverse-lookup on | off
Enable/disable client name unverified reverse lookup (default is
@@ -1091,7 +1096,9 @@ Controls whether
.B slapd
will automatically maintain the
modifiersName, modifyTimestamp, creatorsName, and
-createTimestamp attributes for entries. By default, lastmod is on.
+createTimestamp attributes for entries. It also controls
+the entryCSN and entryUUID attributes, which are needed
+by the syncrepl provider. By default, lastmod is on.
.TP
.B limits <who> <limit> [<limit> [...]]
Specify time and size limits based on who initiated an operation.
diff --git a/doc/man/man5/slapo-accesslog.5 b/doc/man/man5/slapo-accesslog.5
index c27e4834706a9eb782a48c788dfbf97c03d827d9..43bbde319153a61b8798fdb3fe7e573487fccad8 100644
--- a/doc/man/man5/slapo-accesslog.5
+++ b/doc/man/man5/slapo-accesslog.5
@@ -26,9 +26,10 @@ directive.
.B logdb <suffix>
Specify the suffix of a database to be used for storing the log records.
The specified database must have already been configured in a prior section
-of the config file. The suffix entry of the log database will be created
-automatically by this overlay. The log entries will be generated as the
-immediate children of the suffix entry.
+of the config file, and it must have a rootDN configured. The access controls
+on the log database should prevent general write access. The suffix entry
+of the log database will be created automatically by this overlay. The log
+entries will be generated as the immediate children of the suffix entry.
.TP
.B logops <operations>
Specify which types of operations to log. The valid operation types are
diff --git a/doc/man/man5/slapo-chain.5 b/doc/man/man5/slapo-chain.5
index 38f9e130d4a7bd4b283ade0b8556b23e081699f8..6981fe10bdc645f3f529c1aff45fa91d70b2892a 100644
--- a/doc/man/man5/slapo-chain.5
+++ b/doc/man/man5/slapo-chain.5
@@ -53,6 +53,14 @@ feature.
[Note: this may change in the future, as the \fBldap\fP(5) and
\fBmeta\fP(5) backends might no longer chase referrals on their own.]
.TP
+.B chain-cache-uri {FALSE|true}
+This directive instructs the \fIchain\fP overlay to cache
+connections to URIs parsed out of referrals that are not predefined,
+to be reused for later chaining.
+These URIs inherit the properties configured for the underlying
+\fBslapd-ldap\fP(5) before any occurrence of the \fBchain-uri\fP
+directive; in detail, they are essentially chained anonymously.
+.TP
.B chain-chaining [resolve=<r>] [continuation=<c>] [critical]
This directive enables the \fIchaining\fP control
(see \fIdraft-sermersheim-ldap-chaining\fP for details)
@@ -71,13 +79,18 @@ The values \fBr\fP and \fBc\fP can be any of
If the \fBcritical\fP flag affects the control criticality if provided.
[This control is experimental and its support may change in the future.]
.TP
-.B chain-cache-uri {FALSE|true}
-This directive instructs the \fIchain\fP overlay to cache
-connections to URIs parsed out of referrals that are not predefined,
-to be reused for later chaining.
-These URIs inherit the properties configured for the underlying
-\fBslapd-ldap\fP(5) before any occurrence of the \fBchain-uri\fP
-directive; in detail, they are essentially chained anonymously.
+.B chain-max-depth <n>
+In case a referral is returned during referral chasing, further chasing
+occurs at most \fB<n>\fP levels deep. Set to \fB1\fP (the default)
+to disable further referral chasing.
+.TP
+.B chain-return-error {FALSE|true}
+In case referral chasing fails, the real error is returned instead
+of the original referral. In case multiple referral URIs are present,
+only the first error is returned. This behavior may not be always
+appropriate nor desirable, since failures in referral chasing might be
+better resolved by the client (e.g. when caused by distributed
+authentication issues).
.TP
.B chain-uri <ldapuri>
This directive instantiates a new underlying \fIldap\fP database
diff --git a/doc/man/man5/slapo-dds.5 b/doc/man/man5/slapo-dds.5
index 836a9032a5791c74917ecdd3701aa2f6be42af4b..7f05d606824a41cce608fcc6cdd8638058f33b1c 100644
--- a/doc/man/man5/slapo-dds.5
+++ b/doc/man/man5/slapo-dds.5
@@ -97,7 +97,7 @@ is used.
.TP
.B dds\-interval <ttl>
-Specifies the interval between expiration checks; efaults to 1 hour.
+Specifies the interval between expiration checks; defaults to 1 hour.
.TP
.B dds\-tolerance <ttl>
diff --git a/doc/man/man5/slapo-pcache.5 b/doc/man/man5/slapo-pcache.5
index 66891d3de28ebea150c677dd749cb9fb2ba67c15..89ef6424d08faffe1cc2b8d6b1f957a34cfa2e2d 100644
--- a/doc/man/man5/slapo-pcache.5
+++ b/doc/man/man5/slapo-pcache.5
@@ -24,7 +24,7 @@ are saved in the cache for use in future queries.
A template is defined by a filter string and an index identifying a set of
attributes. The \fBtemplate string\fP for a query can be obtained by
-removing assertion values from the RFC 2254 representation of its search
+removing assertion values from the RFC 4515 representation of its search
filter. A query belongs to a template if its template string and set of
projected attributes correspond to a cacheable template.
Examples of template strings are \fB(mail=)\fP, \fB(|(sn=)(cn=))\fP,
diff --git a/doc/man/man5/slapo-ppolicy.5 b/doc/man/man5/slapo-ppolicy.5
index 060446794fe5b7aee23009e6507dede6c5227c43..4f59db302f3ef29220294a46af56450323d67910 100644
--- a/doc/man/man5/slapo-ppolicy.5
+++ b/doc/man/man5/slapo-ppolicy.5
@@ -623,7 +623,7 @@ time "#" syntaxOID "#" length "#" data
time=
.RS 4
-generalizedTimeString as specified in section 6.14 of [RFC2252]
+GeneralizedTime as specified in section 3.3.13 of [RFC4517]
.RE
.P
@@ -631,13 +631,13 @@ syntaxOID = numericoid
.RS 4
This is the string representation of the dotted-decimal OID that
defines the syntax used to store the password. numericoid is
-described in section 4.1 of [RFC2252].
+described in section 1.4 of [RFC4512].
.RE
-length = numericstring
+length = NumericString
.RS 4
-The number of octets in the data. numericstring is described in
-section 4.1 of [RFC2252].
+The number of octets in the data. NumericString is described in
+section 3.3.23 of [RFC4517].
.RE
data =
diff --git a/doc/man/man5/slapo-refint.5 b/doc/man/man5/slapo-refint.5
index 514b9c22c9ca108014486f9984fb11ba6ebb3934..4eebbbe54bb33e1e4c2a67807c4d795b7b76282b 100644
--- a/doc/man/man5/slapo-refint.5
+++ b/doc/man/man5/slapo-refint.5
@@ -18,12 +18,19 @@ or
.B delete
operation. For example, if the integrity attribute were configured as
.BR manager ,
-deletion of the record "uid=robert,ou=people,o=openldap.org" would trigger a
+deletion of the record "uid=robert,ou=people,dc=example,dc=com" would trigger a
search for all other records which have a
.B manager
attribute containing that DN. Entries matching that search would have their
.B manager
attribute removed.
+Or, renaming the same record into "uid=george,ou=people,dc=example,dc=com"
+would trigger a search for all other records which have a
+.B manager
+attribute containing that DN.
+Entries matching that search would have their
+.B manager
+attribute deleted and replaced by the new DN.
.SH CONFIGURATION
These
.B slapd.conf
diff --git a/doc/man/man5/slapo-syncprov.5 b/doc/man/man5/slapo-syncprov.5
index 170cc1594760b248d87a88c84f86c7e4574432e0..c23d4404961f3f6cbca90f8f209def1358d3e642 100644
--- a/doc/man/man5/slapo-syncprov.5
+++ b/doc/man/man5/slapo-syncprov.5
@@ -3,12 +3,13 @@
.\" Copying restrictions apply. See COPYRIGHT/LICENSE.
.\" $OpenLDAP$
.SH NAME
-slapo-syncprov \- Syncrepl Provider overlay
+slapo-syncprov \- Sync Provider overlay
.SH SYNOPSIS
ETCDIR/slapd.conf
.SH DESCRIPTION
-The Syncrepl Provider overlay implements the provider-side support for
-syncrepl replication, including persistent search functionality. The overlay
+The Sync Provider overlay implements the provider-side support for the
+LDAP Content Synchronization (RFC4533) as well as syncrepl replication
+support. The overlay
can be used with any backend that maintains entryCSN and entryUUID
attributes for its entries. It also creates a contextCSN attribute in
the root entry of the database.
@@ -28,7 +29,7 @@ eq index on the entryCSN attribute when using this overlay.
.SH CONFIGURATION
These
.B slapd.conf
-options apply to the Syncrepl Provider overlay.
+options apply to the Sync Provider overlay.
They should appear after the
.B overlay
directive.
@@ -58,12 +59,12 @@ should only be set TRUE for a syncprov instance on top of a log database
The default is FALSE.
.TP
.B syncprov-reloadhint TRUE | FALSE
-Specify that the overlay should honor the reloadHint flag in the Syncrepl
-Control. In OpenLDAP releases 2.3.11 and earlier the Syncrepl consumer did
+Specify that the overlay should honor the reloadHint flag in the Sync
+Control. In OpenLDAP releases 2.3.11 and earlier the syncrepl consumer did
not properly set this flag, so the overlay must ignore it. This option
should be set TRUE when working with newer releases that properly support
this flag. It must be set TRUE when using the accesslog overlay for
-delta-based Syncrepl support. The default is FALSE.
+delta-based syncrepl replication support. The default is FALSE.
.SH FILES
.TP
ETCDIR/slapd.conf
diff --git a/doc/man/man8/slapacl.8 b/doc/man/man8/slapacl.8
index 56797016efea78beed1e8ada25d27100ec7af1a6..c0e94fa68589c6e7d84f8647dfae02efe28d6080 100644
--- a/doc/man/man8/slapacl.8
+++ b/doc/man/man8/slapacl.8
@@ -5,13 +5,14 @@
slapacl \- Check access to a list of attributes.
.SH SYNOPSIS
.B SBINDIR/slapacl
-.B [\-v]
+.B \-b DN
.B [\-d level]
+.B [\-D authcDN | \-U authcID]
.B [\-f slapd.conf]
.B [\-F confdir]
-.B [\-D authcDN | \-U authcID]
-.B \-b DN
+.B [\-o name[=value]
.B [\-u]
+.B [\-v]
.B [\-X authzID | \-o authzDN=DN]
.B [attr[/access][:value]] [...]
.LP
@@ -35,13 +36,25 @@ pseudo-attribute is tested.
.LP
.SH OPTIONS
.TP
-.B \-v
-enable verbose mode.
+.BI \-b " DN"
+specify the
+.B DN
+which access is requested to; the corresponding entry is fetched
+from the database, and thus it must exist.
+The DN is also used to determine what rules apply; thus, it must be
+in the naming context of a configured database. See also
+.BR \-u .
.TP
.BI \-d " level"
enable debugging messages as defined by the specified
.IR level .
.TP
+.BI \-D " authcDN"
+specify a DN to be used as identity through the test session
+when selecting appropriate
+.B <by>
+clauses in access lists.
+.TP
.BI \-f " slapd.conf"
specify an alternative
.BR slapd.conf (5)
@@ -60,62 +73,42 @@ default config directory will be made before trying to use the default
config file. If a valid config directory exists then the
default config file is ignored.
.TP
-.BI \-D " authcDN"
-specify a DN to be used as identity through the test session
-when selecting appropriate
-.B <by>
-clauses in access lists.
-.TP
-.BI \-U " authcID"
-specify an ID to be mapped to a
-.B DN
-as by means of
-.B authz-regexp
-or
-.B authz-rewrite
-rules (see
-.BR slapd.conf (5)
-for details); mutually exclusive with
-.BR \-D .
-.TP
-.BI \-X " authzID"
-specify an authorization ID to be mapped to a
-.B DN
-as by means of
-.B authz-regexp
-or
-.B authz-rewrite
-rules (see
-.BR slapd.conf (5)
-for details); mutually exclusive with \fB\-o\fP \fIauthzDN=DN\fP.
-.TP
.BI \-o " option[=value]"
Specify an
.BR option
with a(n optional)
.BR value .
-Possible options/values are:
+Possible generic options/values are:
.LP
.nf
- sockurl
+ syslog=<subsystems> (see `\-s' in slapd(8))
+ syslog-level=<level> (see `\-S' in slapd(8))
+ syslog-user=<user> (see `\-l' in slapd(8))
+
+.fi
+.RS
+Possible options/values specific to
+.B slapacl
+are:
+.RE
+.nf
+
+ authzDN
domain
peername
+ sasl_ssf
sockname
+ sockurl
ssf
- transport_ssf
tls_ssf
- sasl_ssf
- authzDN
+ transport_ssf
+
.fi
-.TP
-.BI \-b " DN"
-specify the
-.B DN
-which access is requested to; the corresponding entry is fetched
-from the database, and thus it must exist.
-The DN is also used to determine what rules apply; thus, it must be
-in the naming context of a configured database. See also
-.BR \-u .
+.RS
+See the related fields in
+.BR slapd.access (5)
+for details.
+.RE
.TP
.BI \-u
do not fetch the entry from the database.
@@ -131,6 +124,32 @@ option is still used to select what rules apply; thus, it must be
in the naming context of a configured database.
See also
.BR \-b .
+.TP
+.BI \-U " authcID"
+specify an ID to be mapped to a
+.B DN
+as by means of
+.B authz-regexp
+or
+.B authz-rewrite
+rules (see
+.BR slapd.conf (5)
+for details); mutually exclusive with
+.BR \-D .
+.TP
+.B \-v
+enable verbose mode.
+.TP
+.BI \-X " authzID"
+specify an authorization ID to be mapped to a
+.B DN
+as by means of
+.B authz-regexp
+or
+.B authz-rewrite
+rules (see
+.BR slapd.conf (5)
+for details); mutually exclusive with \fB\-o\fP \fIauthzDN=DN\fP.
.SH EXAMPLES
The command
.LP
@@ -159,7 +178,4 @@ level.
.LP
"OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)
.SH ACKNOWLEDGEMENTS
-.B OpenLDAP
-is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
-.B OpenLDAP
-is derived from University of Michigan LDAP 3.3 Release.
+.so ../Project
diff --git a/doc/man/man8/slapadd.8 b/doc/man/man8/slapadd.8
index f8ef62cd7e1f4d9fb82a694cde31d46d222a6adc..134b71cb2a6db81f3709cc8ef6952637ac71bafa 100644
--- a/doc/man/man8/slapadd.8
+++ b/doc/man/man8/slapadd.8
@@ -6,18 +6,20 @@
slapadd \- Add entries to a SLAPD database
.SH SYNOPSIS
.B SBINDIR/slapadd
-.B [\-v]
+.B [\-b suffix]
.B [\-c]
.B [\-g]
-.B [\-u]
-.B [\-q]
-.B [\-w]
.B [\-d level]
-.B [\-b suffix]
-.B [\-n dbnum]
.B [\-f slapd.conf]
.B [\-F confdir]
+.B [\-j lineno]
.B [\-l ldif-file]
+.B [\-n dbnum]
+.B [\-o name[=value]
+.B [\-q]
+.B [\-u]
+.B [\-v]
+.B [\-w]
.SH DESCRIPTION
.LP
.B Slapadd
@@ -43,40 +45,6 @@ schema checks, and does not maintain operational
attributes (such as createTimeStamp and modifiersName).
.SH OPTIONS
.TP
-.B \-v
-enable verbose mode.
-.TP
-.B \-c
-enable continue (ignore errors) mode.
-.TP
-.B \-g
-disable subordinate gluing. Only the specified database will be
-processed, and not its glued subordinates (if any).
-.TP
-.B -s
-disable schema checking. This option is intended to be used when loading
-databases containing special objects, such as fractional objects on a
-partial replica. Loading normal objects which do not conform to
-schema may result in unexpected and ill behavior.
-.TP
-.B \-u
-enable dry-run (don't write to backend) mode.
-.TP
-.B \-q
-enable quick (fewer integrity checks) mode. Does fewer consistency checks
-on the input data, and no consistency checks when writing the database.
-Improves the load time but if any errors or interruptions occur the resulting
-database will be unusable.
-.TP
-.BI \-w
-write syncrepl context information.
-After all entries are added, the contextCSN
-will be updated with the greatest CSN in the database.
-.TP
-.BI \-d " level"
-enable debugging messages as defined by the specified
-.IR level .
-.TP
.BI \-b " suffix"
Use the specified \fIsuffix\fR to determine which database to
add entries to. The \-b cannot be used in conjunction
@@ -84,13 +52,12 @@ with the
.B \-n
option.
.TP
-.BI \-n " dbnum"
-Add entries to the \fIdbnum\fR\-th database listed in the
-configuration file. The
-.B \-n
-cannot be used in conjunction with the
-.B \-b
-option.
+.B \-c
+enable continue (ignore errors) mode.
+.TP
+.BI \-d " level"
+enable debugging messages as defined by the specified
+.IR level .
.TP
.BI \-f " slapd.conf"
specify an alternative
@@ -111,8 +78,62 @@ config file. If a valid config directory exists then the
default config file is ignored. If dryrun mode is also specified,
no conversion will occur.
.TP
+.B \-g
+disable subordinate gluing. Only the specified database will be
+processed, and not its glued subordinates (if any).
+.TP
+.BI \-j " lineno"
+Jump to the specified line number in the LDIF file before processing
+any entries. This allows a load that was aborted due to errors in the
+input LDIF to be resumed after the errors are corrected.
+.TP
.BI \-l " ldif-file"
Read LDIF from the specified file instead of standard input.
+.TP
+.BI \-n " dbnum"
+Add entries to the \fIdbnum\fR\-th database listed in the
+configuration file. The
+.B \-n
+cannot be used in conjunction with the
+.B \-b
+option.
+.TP
+.BI \-o " option[=value]"
+Specify an
+.BR option
+with a(n optional)
+.BR value .
+Possible generic options/values are:
+.LP
+.nf
+ syslog=<subsystems> (see `\-s' in slapd(8))
+ syslog-level=<level> (see `\-S' in slapd(8))
+ syslog-user=<user> (see `\-l' in slapd(8))
+
+.fi
+.TP
+.B \-q
+enable quick (fewer integrity checks) mode. Does fewer consistency checks
+on the input data, and no consistency checks when writing the database.
+Improves the load time but if any errors or interruptions occur the resulting
+database will be unusable.
+.TP
+.B -s
+disable schema checking. This option is intended to be used when loading
+databases containing special objects, such as fractional objects on a
+partial replica. Loading normal objects which do not conform to
+schema may result in unexpected and ill behavior.
+.TP
+.B \-u
+enable dry-run (don't write to backend) mode.
+.TP
+.B \-v
+enable verbose mode.
+.TP
+.BI \-w
+write syncrepl context information.
+After all entries are added, the contextCSN
+will be updated with the greatest CSN in the database.
.SH LIMITATIONS
Your
.BR slapd (8)
@@ -145,7 +166,4 @@ database give the command:
.LP
"OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)
.SH ACKNOWLEDGEMENTS
-.B OpenLDAP
-is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
-.B OpenLDAP
-is derived from University of Michigan LDAP 3.3 Release.
+.so ../Project
diff --git a/doc/man/man8/slapauth.8 b/doc/man/man8/slapauth.8
index 98ec37719f3eef13093a78053cb666ac42cde5ec..6e66afa8bfe7fa981f933197ddfc7e5fa594561b 100644
--- a/doc/man/man8/slapauth.8
+++ b/doc/man/man8/slapauth.8
@@ -5,13 +5,14 @@
slapauth \- Check a list of string-represented IDs for authc/authz.
.SH SYNOPSIS
.B SBINDIR/slapauth
-.B [\-v]
.B [\-d level]
.B [\-f slapd.conf]
.B [\-F confdir]
.B [\-M mech]
+.B [\-o name[=value]
.B [\-R realm]
.B [\-U authcID]
+.B [\-v]
.B [\-X authzID]
.B ID [...]
.LP
@@ -33,9 +34,6 @@ list given on the command-line.
.LP
.SH OPTIONS
.TP
-.B \-v
-enable verbose mode.
-.TP
.BI \-d " level"
enable debugging messages as defined by the specified
.IR level .
@@ -61,6 +59,20 @@ default config file is ignored.
.BI \-M " mech"
specify a mechanism.
.TP
+.BI \-o " option[=value]"
+Specify an
+.BR option
+with a(n optional)
+.BR value .
+Possible generic options/values are:
+.LP
+.nf
+ syslog=<subsystems> (see `\-s' in slapd(8))
+ syslog-level=<level> (see `\-S' in slapd(8))
+ syslog-user=<user> (see `\-l' in slapd(8))
+
+.fi
+.TP
.BI \-R " realm"
specify a realm.
.TP
@@ -86,6 +98,9 @@ If both
and
.I authzID
are given via command line switch, the ID list cannot be present.
+.TP
+.B \-v
+enable verbose mode.
.SH EXAMPLES
The command
.LP
@@ -119,7 +134,4 @@ are defined in
.LP
"OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)
.SH ACKNOWLEDGEMENTS
-.B OpenLDAP
-is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
-.B OpenLDAP
-is derived from University of Michigan LDAP 3.3 Release.
+.so ../Project
diff --git a/doc/man/man8/slapcat.8 b/doc/man/man8/slapcat.8
index 4f80335d6613b9349c38a282dfcd753d5d3cf3ae..9c5f7e09ba58adc7421cd82e3a12b9ae952bfbc2 100644
--- a/doc/man/man8/slapcat.8
+++ b/doc/man/man8/slapcat.8
@@ -6,17 +6,18 @@
slapcat \- SLAPD database to LDIF utility
.SH SYNOPSIS
.B SBINDIR/slapcat
-.B [\-v]
+.B [\-a filter]
+.B [\-b suffix]
.B [\-c]
-.B [\-g]
.B [\-d level]
-.B [\-b suffix]
-.B [\-n dbnum]
-.B [\-a filter]
-.B [\-s subtree-dn]
.B [\-f slapd.conf]
.B [\-F confdir]
+.B [\-g]
.B [\-l ldif-file]
+.B [\-n dbnum]
+.B [\-o name[=value]
+.B [\-s subtree-dn]
+.B [\-v]
.B
.LP
.SH DESCRIPTION
@@ -48,35 +49,6 @@ into superior first order and removing no-user-modification
operational attributes.
.SH OPTIONS
.TP
-.B \-v
-Enable verbose mode.
-.TP
-.B \-c
-Enable continue (ignore errors) mode.
-.TP
-.B \-g
-disable subordinate gluing. Only the specified database will be
-processed, and not its glued subordinates (if any).
-.TP
-.BI \-d " level"
-Enable debugging messages as defined by the specified
-.IR level .
-.TP
-.BI \-b " suffix"
-Use the specified \fIsuffix\fR to determine which database to
-generate output for. The \-b cannot be used in conjunction
-with the
-.B \-n
-option.
-.TP
-.BI \-n " dbnum"
-Generate output for the \fIdbnum\fR\-th database listed in the
-configuration file. The
-.B \-n
-cannot be used in conjunction with the
-.B \-b
-option.
-.TP
.BI \-a " filter"
Only dump entries matching the asserted filter.
For example
@@ -87,13 +59,19 @@ slapcat -a \\
will dump all but the "ou=People,dc=example,dc=com" subtree
of the "dc=example,dc=com" database.
.TP
-.BI \-s " subtree-dn"
-Only dump entries in the subtree specified by this DN.
-Implies `-b subtree-dn' if no
-.B \-b
-or
+.BI \-b " suffix"
+Use the specified \fIsuffix\fR to determine which database to
+generate output for. The \-b cannot be used in conjunction
+with the
.B \-n
-option is given.
+option.
+.TP
+.B \-c
+Enable continue (ignore errors) mode.
+.TP
+.BI \-d " level"
+Enable debugging messages as defined by the specified
+.IR level .
.TP
.BI \-f " slapd.conf"
Specify an alternative
@@ -113,8 +91,45 @@ default config directory will be made before trying to use the default
config file. If a valid config directory exists then the
default config file is ignored.
.TP
+.B \-g
+disable subordinate gluing. Only the specified database will be
+processed, and not its glued subordinates (if any).
+.TP
.BI \-l " ldif-file"
Write LDIF to specified file instead of standard output.
+.TP
+.BI \-n " dbnum"
+Generate output for the \fIdbnum\fR\-th database listed in the
+configuration file. The
+.B \-n
+cannot be used in conjunction with the
+.B \-b
+option.
+.TP
+.BI \-o " option[=value]"
+Specify an
+.BR option
+with a(n optional)
+.BR value .
+Possible generic options/values are:
+.LP
+.nf
+ syslog=<subsystems> (see `\-s' in slapd(8))
+ syslog-level=<level> (see `\-S' in slapd(8))
+ syslog-user=<user> (see `\-l' in slapd(8))
+
+.fi
+.TP
+.BI \-s " subtree-dn"
+Only dump entries in the subtree specified by this DN.
+Implies `-b subtree-dn' if no
+.B \-b
+or
+.B \-n
+option is given.
+.TP
+.B \-v
+Enable verbose mode.
.SH LIMITATIONS
In general, your
.BR slapd (8)
@@ -139,7 +154,4 @@ give the command:
.LP
"OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)
.SH ACKNOWLEDGEMENTS
-.B OpenLDAP
-is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
-.B OpenLDAP
-is derived from University of Michigan LDAP 3.3 Release.
+.so ../Project
diff --git a/doc/man/man8/slapd.8 b/doc/man/man8/slapd.8
index f91a73233fcbc19126a0f8cb9708fede20436900..866a4d5021efb48a563550221053505b155f2bde 100644
--- a/doc/man/man8/slapd.8
+++ b/doc/man/man8/slapd.8
@@ -80,7 +80,7 @@ are not provided or not usable.
.TP
.BI \-d " debug\-level"
Turn on debugging as defined by
-.I debug\-level.
+.IR debug\-level .
If this option is specified, even with a zero argument,
.B slapd
will not fork or disassociate from the invoking terminal. Some general
@@ -310,7 +310,4 @@ To test whether the configuration file is correct or not, type:
.SH BUGS
See http://www.openldap.org/its/
.SH ACKNOWLEDGEMENTS
-.B OpenLDAP
-is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
-.B OpenLDAP
-is derived from University of Michigan LDAP 3.3 Release.
+.so ../Project
diff --git a/doc/man/man8/slapdn.8 b/doc/man/man8/slapdn.8
index 01513f2ee5de538c8e257f373503d98b0b27a02c..01eae62480b24b05141f3995c24216d22133f489 100644
--- a/doc/man/man8/slapdn.8
+++ b/doc/man/man8/slapdn.8
@@ -5,11 +5,12 @@
slapdn \- Check a list of string-represented DNs based on schema syntax.
.SH SYNOPSIS
.B SBINDIR/slapdn
-.B [\-v]
.B [\-d level]
.B [\-f slapd.conf]
.B [\-F confdir]
.B [\-N | \-P]
+.B [\-o name[=value]
+.B [\-v]
.B DN [...]
.LP
.SH DESCRIPTION
@@ -29,9 +30,6 @@ list given on the command-line.
.LP
.SH OPTIONS
.TP
-.B \-v
-enable verbose mode.
-.TP
.BI \-d " level"
enable debugging messages as defined by the specified
.IR level .
@@ -59,10 +57,27 @@ only output a normalized form of the DN, suitable to be used
in a normalization tool; incompatible with
.BR \-P .
.TP
+.BI \-o " option[=value]"
+Specify an
+.BR option
+with a(n optional)
+.BR value .
+Possible generic options/values are:
+.LP
+.nf
+ syslog=<subsystems> (see `\-s' in slapd(8))
+ syslog-level=<level> (see `\-S' in slapd(8))
+ syslog-user=<user> (see `\-l' in slapd(8))
+
+.fi
+.TP
.BI \-P
only output a prettified form of the DN, suitable to be used
in a check and beautification tool; incompatible with
.BR \-N .
+.TP
+.B \-v
+enable verbose mode.
.SH EXAMPLES
To check a
.B DN
@@ -80,7 +95,4 @@ give the command:
.LP
"OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)
.SH ACKNOWLEDGEMENTS
-.B OpenLDAP
-is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
-.B OpenLDAP
-is derived from University of Michigan LDAP 3.3 Release.
+.so ../Project
diff --git a/doc/man/man8/slapindex.8 b/doc/man/man8/slapindex.8
index 2da8317dc29e85b1e507603491655dcb9c386e3f..44ca608f3f7a4058c19a3299027ccd24835f07df 100644
--- a/doc/man/man8/slapindex.8
+++ b/doc/man/man8/slapindex.8
@@ -6,15 +6,16 @@
slapindex \- SLAPD index to LDIF utility
.SH SYNOPSIS
.B SBINDIR/slapindex
-.B [\-v]
+.B [\-b suffix]
.B [\-c]
-.B [\-g]
-.B [\-q]
.B [\-d level]
-.B [\-b suffix]
-.B [\-n dbnum]
.B [\-f slapd.conf]
.B [\-F confdir]
+.B [\-g]
+.B [\-n dbnum]
+.B [\-o name[=value]
+.B [\-q]
+.B [\-v]
.B
.LP
.SH DESCRIPTION
@@ -31,27 +32,6 @@ Databases configured as
of this one are also re-indexed, unless \fB-g\fP is specified.
.SH OPTIONS
.TP
-.B \-v
-enable verbose mode.
-.TP
-.B \-c
-enable continue (ignore errors) mode.
-.TP
-.B \-g
-disable subordinate gluing. Only the specified database will be
-processed, and not its glued subordinates (if any).
-.TP
-.B \-q
-enable quick (fewer integrity checks) mode. Performs no consistency checks
-when writing the database. Improves indexing time,
-.B however
-the database will most likely be unusable if any errors or
-interruptions occur.
-.TP
-.BI \-d " level"
-enable debugging messages as defined by the specified
-.IR level .
-.TP
.BI \-b " suffix"
Use the specified \fIsuffix\fR to determine which database to
generate output for. The \-b cannot be used in conjunction
@@ -59,13 +39,12 @@ with the
.B \-n
option.
.TP
-.BI \-n " dbnum"
-Generate output for the \fIdbnum\fR\-th database listed in the
-configuration file. The
-.B \-n
-cannot be used in conjunction with the
-.B \-b
-option.
+.B \-c
+enable continue (ignore errors) mode.
+.TP
+.BI \-d " level"
+enable debugging messages as defined by the specified
+.IR level .
.TP
.BI \-f " slapd.conf"
specify an alternative
@@ -84,6 +63,42 @@ If neither option is specified, an attempt to read the
default config directory will be made before trying to use the default
config file. If a valid config directory exists then the
default config file is ignored.
+.TP
+.B \-g
+disable subordinate gluing. Only the specified database will be
+processed, and not its glued subordinates (if any).
+.TP
+.BI \-n " dbnum"
+Generate output for the \fIdbnum\fR\-th database listed in the
+configuration file. The
+.B \-n
+cannot be used in conjunction with the
+.B \-b
+option.
+.TP
+.BI \-o " option[=value]"
+Specify an
+.BR option
+with a(n optional)
+.BR value .
+Possible generic options/values are:
+.LP
+.nf
+ syslog=<subsystems> (see `\-s' in slapd(8))
+ syslog-level=<level> (see `\-S' in slapd(8))
+ syslog-user=<user> (see `\-l' in slapd(8))
+
+.fi
+.TP
+.B \-q
+enable quick (fewer integrity checks) mode. Performs no consistency checks
+when writing the database. Improves indexing time,
+.B however
+the database will most likely be unusable if any errors or
+interruptions occur.
+.TP
+.B \-v
+enable verbose mode.
.SH LIMITATIONS
Your
.BR slapd (8)
@@ -109,7 +124,4 @@ To reindex your SLAPD database, give the command:
.LP
"OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)
.SH ACKNOWLEDGEMENTS
-.B OpenLDAP
-is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
-.B OpenLDAP
-is derived from University of Michigan LDAP 3.3 Release.
+.so ../Project
diff --git a/doc/man/man8/slappasswd.8 b/doc/man/man8/slappasswd.8
index 9750da398aa00e0c4b6ddfe27c69ec1db052ae54..0048f7ed3a3079dfb8206f7d3b6fea38376833ff 100644
--- a/doc/man/man8/slappasswd.8
+++ b/doc/man/man8/slappasswd.8
@@ -138,7 +138,7 @@ Omit the trailing newline; useful to pipe the credentials
into a command.
.SH LIMITATIONS
The practice storing hashed passwords in userPassword violates
-Standard Track (RFC 2256) schema specifications and may hinder
+Standard Track (RFC 4519) schema specifications and may hinder
interoperability. A new attribute type, authPassword, to hold
hashed passwords has been defined (RFC 3112), but is not yet
implemented in
@@ -160,11 +160,9 @@ were clear text passwords.
.BR slapd (8)
.BR slapd.conf (5)
.B RFC 2307
-.B RFC 2256
+.B RFC 4519
.B RFC 3112
.LP
"OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)
.SH ACKNOWLEDGEMENTS
-OpenLDAP is developed and maintained by
-The OpenLDAP Project (http://www.openldap.org/).
-OpenLDAP is derived from University of Michigan LDAP 3.3 Release.
+.so ../Project
diff --git a/doc/man/man8/slaptest.8 b/doc/man/man8/slaptest.8
index 3fcd484fbef4ccd7a85c04c7400feecba7afe84f..06748eebd621bc8c5d1883d013e5021295d09e19 100644
--- a/doc/man/man8/slaptest.8
+++ b/doc/man/man8/slaptest.8
@@ -8,6 +8,7 @@ slaptest \- Check the suitability of the slapd.conf file.
.B [\-d level]
.B [\-f slapd.conf]
.B [\-F confdir]
+.B [\-o name[=value]
.B [\-u]
.B [\-v]
.LP
@@ -47,6 +48,20 @@ config file. If a valid config directory exists then the
default config file is ignored. If dryrun mode is also specified,
no conversion will occur.
.TP
+.BI \-o " option[=value]"
+Specify an
+.BR option
+with a(n optional)
+.BR value .
+Possible generic options/values are:
+.LP
+.nf
+ syslog=<subsystems> (see `\-s' in slapd(8))
+ syslog-level=<level> (see `\-S' in slapd(8))
+ syslog-user=<user> (see `\-l' in slapd(8))
+
+.fi
+.TP
.B \-u
enable dryrun mode (i.e. don't fail if databases cannot be opened,
but config is fine).
@@ -70,7 +85,4 @@ give the command:
.LP
"OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)
.SH ACKNOWLEDGEMENTS
-.B OpenLDAP
-is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
-.B OpenLDAP
-is derived from University of Michigan LDAP 3.3 Release.
+.so ../Project
diff --git a/doc/man/man8/slurpd.8 b/doc/man/man8/slurpd.8
index 7c037421e5db64b5f24994b59a051912fefa85ea..009e5855af1855a9b7e99683d5f73b5bcbb43c42 100644
--- a/doc/man/man8/slurpd.8
+++ b/doc/man/man8/slurpd.8
@@ -157,7 +157,4 @@ on voluminous debugging which will be printed on standard error, type:
.LP
"OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)
.SH ACKNOWLEDGEMENTS
-.B OpenLDAP
-is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
-.B OpenLDAP
-is derived from University of Michigan LDAP 3.3 Release.
+.so ../Project
diff --git a/doc/rfc/INDEX b/doc/rfc/INDEX
index 8c1aecd8d26ae292e9e597b278e3cb87fc18b9cd..4420833bff5add2c4d218ddaaff18167df44757b 100644
--- a/doc/rfc/INDEX
+++ b/doc/rfc/INDEX
@@ -1,19 +1,11 @@
This is an index of RFC contained in this directory:
-rfc1274.txt COSINE and Internet X.500 Schema (PS)
rfc2079.txt X.500 Attribute Type and an Object Class to Hold URIs (PS)
rfc2247.txt Using Domains in LDAP DNs (PS)
-rfc2251.txt LDAPv3 Protocol (PS)
-rfc2252.txt LDAPv3 Attribute Types (PS)
-rfc2253.txt LDAPv3 Disinguished Name (PS)
-rfc2254.txt LDAPv3 Search Filters (PS)
-rfc2255.txt LDAPv3 URL Format (PS)
-rfc2256.txt X.500(96) Schema for LDAPv3 (PS)
rfc2293.txt Tables and Subtrees in the X.500 Directory (PS)
rfc2294.txt O/R Address hierarchy in the X.500 DIT (PS)
rfc2307.txt LDAP Network Information Services Schema (E)
rfc2377.txt LDAP Naming Plan (I)
-rfc2587.txt Internet X.509 PKI LDAPv2 Schema (PS)
rfc2589.txt LDAPv3: Dynamic Directory Services Extensions (PS)
rfc2649.txt LDAPv3 Operational Signatures (E)
rfc2696.txt LDAP Simple Paged Result Control (I)
@@ -30,19 +22,15 @@ rfc3062.txt LDAP Password Modify Extended Operation (PS)
rfc3088.txt OpenLDAP Root Service (E)
rfc3112.txt LDAP Authentication Password Schema (I)
rfc3296.txt Named Subordinate References in LDAP (PS)
-rfc3377.txt LDAP(v3): Technical Specification (PS)
-rfc3383.txt IANA Considerations for LDAP (BCP)
rfc3663.txt Domain Administrative Data in LDAP (E)
rfc3671.txt Collective Attributes in LDAP (PS)
rfc3672.txt Subentries in LDAP (PS)
rfc3673.txt LDAPv3: All Operational Attributes (PS)
-rfc3674.txt Feature Discovery in LDAP (PS)
rfc3687.txt LDAP Component Matching Rules (PS)
rfc3698.txt LDAP: Additional Matching Rules (PS)
rfc3703.txt LDAP: Schema for Policy Core (PS)
rfc3712.txt LDAP: Schema for Printer Services (I)
rfc3727.txt ASN.1 Module for LDAP Component Matching Rules (PS)
-rfc3771.txt LDAP: Intermediate Response Message (PS)
rfc3829.txt LDAP Authorization Identity Controls (I)
rfc3866.txt Language Tag and Ranges in LDAP (PS)
rfc3876.txt Returning Matched Values with LDAP (PS)
@@ -52,6 +40,30 @@ rfc4013.txt SASLprep (PS)
rfc4370.txt LDAP Proxied Authorization Control (PS)
rfc4373.txt LBURP (I)
rfc4404.txt LDAP Schema for UDDI (I)
+rfc4510.txt LDAP Technical Specification Roadmap (PS)
+rfc4511.txt LDAP: The Protocol (PS)
+rfc4512.txt LDAP: Directory Information Models (PS)
+rfc4513.txt LDAP: Authentication Methods and Security Mechanisms (PS)
+rfc4514.txt LDAP: DN (PS)
+rfc4515.txt LDAP: Search Filters (PS)
+rfc4516.txt LDAP: URL (PS)
+rfc4517.txt LDAP: Syntaxes and Matching Rules (PS)
+rfc4518.txt LDAP: Internationalized String Preparation (PS)
+rfc4519.txt LDAP: User Applications Schema (PS)
+rfc4520.txt IANA Considerations for LDAP (BCP)
+rfc4521.txt Considerations for LDAP Extensions (BCP)
+rfc4522.txt LDAP: Binary Encoding Option (PS)
+rfc4523.txt LDAP: X.509 Certificate Schema (PS)
+rfc4524.txt LDAP: COSINE Schema (PS)
+rfc4525.txt LDAP: Modify-Increment Extension (I)
+rfc4526.txt LDAP: Absolute True and False Filters (PS)
+rfc4527.txt LDAP: Read Entry Controls (PS)
+rfc4528.txt LDAP: Assertion Control (PS)
+rfc4529.txt LDAP: Requesting Attributes by Object Class
+rfc4530.txt LDAP: entryUUID (PS)
+rfc4531.txt LDAP Turn Operation (E)
+rfc4532.txt LDAP Who am I? Operation (PS)
+rfc4533.txt LDAP Content Sync Operation (E)
Legend:
STD Standard
diff --git a/doc/rfc/rfc1274.txt b/doc/rfc/rfc1274.txt
deleted file mode 100644
index 3ae2709258ca9b14dcee70cd358ac33b45a146df..0000000000000000000000000000000000000000
--- a/doc/rfc/rfc1274.txt
+++ /dev/null
@@ -1,3363 +0,0 @@
-
-
-
-
-
-
-Network Working Group P. Barker
-Request for Comments: 1274 S. Kille
- University College London
- November 1991
-
-
- The COSINE and Internet X.500 Schema
-
-Status of this Memo
-
- This RFC specifies an IAB standards track protocol for the Internet
- community, and requests discussion and suggestions for improvements.
- Please refer to the current edition of the "IAB Official Protocol
- Standards" for the standardization state and status of this protocol.
- Distribution of this memo is unlimited.
-
-Abstract
-
- This document suggests an X.500 Directory Schema, or Naming
- Architecture, for use in the COSINE and Internet X.500 pilots. The
- schema is independent of any specific implementation. As well as
- indicating support for the standard object classes and attributes, a
- large number of generally useful object classes and attributes are
- also defined. An appendix to this document includes a machine
- processable version of the schema.
-
- This document also proposes a mechanism for allowing the schema to
- evolve in line with emerging requirements. Proformas to support this
- process are included.
-
- Corrections and additions to the schema should be sent to na-
- update@cs.ucl.ac.uk list, as described within.
-
-1. Introduction
-
- Directory Services are a fundamental requirement of both human and
- computer communications' systems. Human users need to be able to
- look up various details about other people: for example, telephone
- numbers, facsimile numbers and paper mail addresses. Computing
- systems also need Directory Services for several purposes: for
- example, to support address look-ups for a variety of services, and
- to support user-friendly naming and distribution lists in electronic
- mail systems.
-
- Directory Services have recently been standardised and published as
- the 1988 CCITT X.500 / ISO IS9594 recommendations [1]. The standard
- provides a good basis for the provision of real services, and a
- considerable amount of Directory Service piloting activity is
-
-
-
-Barker & Kille [Page 1]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- currently underway. In the U.S., the PSI White Pages Pilot [4] has
- stimulated use of X.500 on the Internet. In Britain, the U.K.
- Academic Community Directory Pilot [5] is similarly promoting use of
- X.500.
-
-2. Motivation and aims of this document
-
- In a number of areas the X.500 standard only provides a basis for
- services. One such area is the Directory's Schema or Naming
- Architecture. The standard defines a number of useful object
- classes, in X.521, and attribute types, in X.520. These are intended
- to be generally useful across a range of directory applications.
- However, while these standard definitions are a useful starting
- point, they are insufficient as a basis for a large scale pilot
- directory.
-
- While it is possible for directory administrators to define their own
- sets of additional attribute types and object classes, this is
- undesirable for some common attributes and objects. The same objects
- and attribute types would be privately defined many times over. This
- would result in the directory's generality being diminished as remote
- systems would be unable to determine the semantics of these privately
- defined data types.
-
- A number of useful additions to the standard definitions were made in
- this note's forerunner, "The THORN and RARE Naming Architecture" [2].
- These have been heavily used in early X.500 piloting activities.
- Furthermore, both the THORN and Quipu X.500 implementations have made
- use of these definitions.
-
- Since the afore-mentioned note was issued, a number of further
- requirements have come to light as the volume and variety of piloting
- activity has increased. Yet further requirements seem likely as the
- scale of X.500 pilot services increases. Thus, it is argued that it
- is not sufficient to merely reissue an updated version of the
- original note. The schema is a "living document" that needs
- procedures for:
-
- - Allowing submission of requests for new attributes and
- object classes to be added into the schema;
-
- - Allowing groups of object classes and attribute types
- defined elsewhere to be integrated into the schema.
-
- - Checking for the redundancy of any previously defined
- attribute types and object classes.
-
- This document attempts to establish procedures to allow for the
-
-
-
-Barker & Kille [Page 2]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- continual updating of the schema. Two proformas are set out for this
- purpose. In addition, descriptive detail is provided for the
- additional object classes and attribute types defined in the schema.
- These descriptions follow the style used in X.520 and X.521.
- Finally, also following the style adopted in the standards documents,
- appendices will include the entire schema. Plain text versions of
- the document's appendices are intended to be machine processable to
- allow derivation of a system's schema tables. Appendix C lists all
- the schema's object classes and attribute types in their respective
- ASN.1 macro formats.
-
- The scope and intended remit of this coordination activity should be
- clearly understood.
-
- - Esoteric and local, highly experimental requirements should
- continue to be met by private definitions.
-
- - Requirements which have support from more than one site will
- usually be integrated into the schema. Put in other words,
- the tendency will be for the inclusion, as opposed to the
- exclusion, of useful additions to the schema.
-
- - An attempt will be made to avoid duplication of object
- classes and attribute types for essentially similar real
- world objects.
-
-3. What conformance to this schema means
-
- It is not reasonable to require that a DSA which supports this schema
- has specific code to handle each of the defined syntaxes. However,
- the following requirements are made of a system which claims
- conformance to this specification:
-
- 1. A DSA shall be able to store all of the attributes and
- object class values specified. (Note that this implies
- support for all the object classes and attribute types
- required by strong authentication as defined in X.509.)
-
- 2. A DUA shall be able to identify each attribute type and
- object class to the user, with an appropriate representation
- (e.g., a string).
-
- 3. These statement are qualified for large attributes values
- (>1kbyte). A conforming DSA does not have to store such
- attribute values, and a DUA does not have to display such
- values, although it must indicate their presence.
-
- The following are desirable, but not required:
-
-
-
-Barker & Kille [Page 3]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- 1. For a DSA to match correctly on the basis of all attribute
- syntaxes defined
-
- 2. For a DSA to enforce the Object Class schema implied by
- these definitions
-
- 3. For a DUA to correctly display the attribute values
- (syntaxes) defined
-
- 4. For DUAs and DSAs to maintain compatibility with a previous
- version of the schema.
-
-4. Requesting new object classes and attribute types
-
- This section defines procedures for requesting new object classes and
- attribute types to be added to the schema. Proformas for object
- classes and attribute types are specified, and examples given of how
- to use them. A mechanism for making requests for large groups of new
- object classes and attribute types is described in the next section.
-
- As stated earlier, it is anticipated that the schema will evolve
- considerably over time. As X.500 is used to support a widening range
- of applications, there will be requirements for extensions to the
- schema. This document proposes formalising this procedure by
- requiring requests for additions to the schema to be submitted as
- completed proformas. This stipulation will greatly simplify
- subsequent revisions of the schema.
-
- There is one qualification to the above with respect to requests for
- modifications to an existing object class. If a modification to an
- object class merely involves additional, optional attributes, the
- object class will be enhanced as requested. Systems are expected to
- be resilient to such changes to the schema. However, requests to
- modify an object class, such that the mandatory attribute types
- require altering, will not be met. Instead, a new object class will
- be created, and the original object class expired following the
- scheme described in the next main section.
-
- It is anticipated that most requests for modifications to the schema
- will be met without any need for editorial intervention. Sometimes,
- however, some discussion between the submitter of a request and the
- schema's editor may be required. For example, the editor may have to
- judge the relative merits of two very similar requests and, as a
- result, one of the parties may not get quite what they want. In
- cases such as this where the submitter of a request feels aggrieved
- about an editorial decision, the requestor may appeal to a broader
- community by explaining their views to the mailing list osi-
- ds@cs.ucl.ac.uk. Heed will be paid to any consensus that emerges
-
-
-
-Barker & Kille [Page 4]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- from discussions on the schema on this list. If it proves that this
- list is used almost solely for discussions on schema issues, a
- separate discussion list will be created.
-
- To facilitate the production of the afore-mentioned proformas, tools
- are included in Appendix B which will verify that a proforma has been
- correctly formatted.
-
- Completed proformas should be mailed to na-update@cs.ucl.ac.uk
-
-4.1. Object Class proforma
-
- This section gives an example, completed proforma for a new object
- class, alcoholic drink. A proforma for object class specified in BNF
- is included in Appendix A.
-
- Object Class: Alcoholic Drink
-
- Description: The Alcoholic Drink object class is used to define
- entries representing intoxicating beverages.
-
- ASN1OCMacro: alcoholicDrink OBJECT-CLASS
- SUBCLASS OF drink
- MUST CONTAIN {
- percentAlcohol}
- MAY CONTAIN {
- normalServing,
- hue}
-
- An object class description consists of three fields, separated by
- blank lines. The keywords Object Class, Description and ASN1OCMacro,
- and their suffixed colons, must be included exactly as above.
-
- The Object Class field should be used for a textual description of
- the object class. This will be at most three or four words.
-
- The Description field should contain some explanatory text about the
- intended use of the object class. This can run to a number of lines.
-
- The ASN1OCMacro field should follow the definition of the object
- class macro as specified in X.501. The above example shows the main
- features. There are many more examples which can studied in the
- section defining the Pilot Object Classes.
-
-4.2. Attribute type proforma
-
- This section gives an example completed proforma for a new attribute
- type, hue (one of the attribute types in the alcoholic drink object
-
-
-
-Barker & Kille [Page 5]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- class).
-
- Attribute Type: Hue
-
- Description: The Hue attribute type specifies the hue of
- an object. (Note that a description may run to several
- lines.)
-
- OCMust:
-
- OCMay: alcoholicDrink
-
- ASN1ATMacro:hue ATTRIBUTE
- WITH ATTRIBUTE SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-hue))
-
- ub-hue INTEGER ::= 256
-
- An attribute type description consists of five fields, separated by
- blank lines. The keywords Attribute Type, Description, OCMust, OCMay
- and ASN1ATMacro, and their suffixed colons, must be included exactly
- as above.
-
- The Attribute Type field should be used for a textual description of
- the attribute type. This will be at most three or four words.
-
- The Description field should contain some explanatory text about the
- intended use of the attribute type. This can run to a number of
- lines.
-
- The OCMust field should contain a comma-separated list of object
- classes for which this attribute is mandatory.
-
- The OCMay field should contain a comma-separated list of object
- classes for which this attribute is optional.
-
- The ASN1ATMacro field should follow the definition of the attribute
- macro as specified in X.501. The above example shows some of the
- features. In particular, please note the format for specifying size
- constraints.
-
-5. Integrating groups of object classes and attribute types.
-
- This section describes two mechanisms that may be employed to allow
- the integration of a substantial number of new object classes and
- attribute types into the schema.
-
-
-
-
-Barker & Kille [Page 6]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- The first mechanism allows for the transition of groups of related,
- privately defined object classes and attribute types into the schema.
- An example of when such a transition might be appropriate is when
- some experimental use of the Directory is widely adopted within the
- pilot. Such a transition will be made if the following conditions
- hold:
-
- - The definitions are well structured: i.e., they are not
- scattered over a multiplicity of object identifier subtrees.
-
- - The definitions are in use at a number of sites, and having
- to adopt new object identifiers would be unnecessarily
- disruptive.
-
- A second mechanism allows for the allocation of an object subtree for
- a group of new definitions. A pilotGroups object identifier has been
- defined for this purpose. This method will be suitable for an
- experiment requiring a considerable number of new object identifiers
- to be defined. This approach allows for flexibility during
- experimentation and should simplify both the management and the
- coherence of the pilot's object identifiers.
-
- In both cases, the object classes, attribute types and syntaxes
- should be defined and described in an RFC. It is suggested that such
- documents should follow the style used in this document for object
- class and attribute type definitions. A reference will be given in
- this schema to the document containing the definitions.
-
-6. Removing "old" object classes and attribute types.
-
- It is also important that object classes and attribute types which
- are no longer used or useful are removed from the schema. Some
- object classes and attribute types initially defined as pilot
- extensions may be included as standard definitions in future versions
- of the standard. In such a case, it is important that there should
- be a fairly rapid transition to the standard definitions. Another
- possibility is that newer, more specific definitions obviate the
- original definitions.
-
- Two things are essential. First, it is crucial that "old"
- definitions are retired as gracefully as possible. The intention to
- retire a definition will be sent to the osi-ds@cs.ucl.ac.uk mail
- list. In the absence of objections, the definition will be marked
- for expiry with a given expiry date. The definition will remain in
- the schema until the expiry date. Users of the schema should ensure
- that they make the transition to new, alternative definitions in the
- interim.
-
-
-
-
-Barker & Kille [Page 7]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- Second, users of the schema must have the right to argue for the
- retention of definitions which they regard as necessary, there being
- no other definitions which closely meet their requirements. It is
- clearly impossible to lay down hard and fast rules on this point, as
- no two instances will ever be quite the same. It is intended that
- the refereeing on these matters will be sympathetic! As for requests
- for additions, an aggrieved user can "go to arbitration" by
- initiating a discussion on the osi-ds@cs.ucl.ac.uk mail list.
-
-7. Object Identifiers
-
- Some additional object identifiers are defined for this schema.
- These are also reproduced in Appendix C.
-
- data OBJECT IDENTIFIER ::= {ccitt 9}
- pss OBJECT IDENTIFIER ::= {data 2342}
- ucl OBJECT IDENTIFIER ::= {pss 19200300}
- pilot OBJECT IDENTIFIER ::= {ucl 100}
-
- pilotAttributeType OBJECT IDENTIFIER ::= {pilot 1}
- pilotAttributeSyntax OBJECT IDENTIFIER ::= {pilot 3}
- pilotObjectClass OBJECT IDENTIFIER ::= {pilot 4}
- pilotGroups OBJECT IDENTIFIER ::= {pilot 10}
-
- iA5StringSyntax OBJECT IDENTIFIER ::= {pilotAttributeSyntax 4}
- caseIgnoreIA5StringSyntax OBJECT IDENTIFIER ::=
- {pilotAttributeSyntax 5}
-
-8. Object Classes
-
-8.1. X.500 standard object classes
-
- A number of generally useful object classes are defined in X.521, and
- these are supported. Refer to that document for descriptions of the
- suggested usage of these object classes. The ASN.1 for these object
- classes is reproduced for completeness in Appendix C.
-
-8.2. X.400 standard object classes
-
- A number of object classes defined in X.400 are supported. Refer to
- X.402 for descriptions of the usage of these object classes. The
- ASN.1 for these object classes is reproduced for completeness in
- Appendix C.
-
-8.3. COSINE/Internet object classes
-
- This section attempts to fuse together the object classes designed
- for use in the COSINE and Internet pilot activities. Descriptions
-
-
-
-Barker & Kille [Page 8]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- are given of the suggested usage of these object classes. The ASN.1
- for these object classes is also reproduced in Appendix C.
-
-8.3.1. Pilot Object
-
- The PilotObject object class is used as a sub-class to allow some
- common, useful attributes to be assigned to entries of all other
- object classes.
-
- pilotObject OBJECT-CLASS
- SUBCLASS OF top
- MAY CONTAIN {
- info,
- photo,
- manager,
- uniqueIdentifier,
- lastModifiedTime,
- lastModifiedBy,
- dITRedirect,
- audio}
- ::= {pilotObjectClass 3}
-
-8.3.2. Pilot Person
-
- The PilotPerson object class is used as a sub-class of person, to
- allow the use of a number of additional attributes to be assigned to
- entries of object class person.
-
- pilotPerson OBJECT-CLASS
- SUBCLASS OF person
- MAY CONTAIN {
- userid,
- textEncodedORAddress,
- rfc822Mailbox,
- favouriteDrink,
- roomNumber,
- userClass,
- homeTelephoneNumber,
- homePostalAddress,
- secretary,
- personalTitle,
- preferredDeliveryMethod,
- businessCategory,
- janetMailbox,
- otherMailbox,
- mobileTelephoneNumber,
- pagerTelephoneNumber,
- organizationalStatus,
-
-
-
-Barker & Kille [Page 9]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- mailPreferenceOption,
- personalSignature}
- ::= {pilotObjectClass 4}
-
-8.3.3. Account
-
- The Account object class is used to define entries representing
- computer accounts. The userid attribute should be used for naming
- entries of this object class.
-
- account OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- userid}
- MAY CONTAIN {
- description,
- seeAlso,
- localityName,
- organizationName,
- organizationalUnitName,
- host}
- ::= {pilotObjectClass 5}
-
-8.3.4. Document
-
- The Document object class is used to define entries which represent
- documents.
-
- document OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- documentIdentifier}
- MAY CONTAIN {
- commonName,
- description,
- seeAlso,
- localityName,
- organizationName,
- organizationalUnitName,
- documentTitle,
- documentVersion,
- documentAuthor,
- documentLocation,
- documentPublisher}
- ::= {pilotObjectClass 6}
-
-
-
-
-
-
-Barker & Kille [Page 10]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
-8.3.5. Room
-
- The Room object class is used to define entries representing rooms.
- The commonName attribute should be used for naming pentries of this
- object class.
-
- room OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- commonName}
- MAY CONTAIN {
- roomNumber,
- description,
- seeAlso,
- telephoneNumber}
- ::= {pilotObjectClass 7}
-
-8.3.6. Document Series
-
- The Document Series object class is used to define an entry which
- represents a series of documents (e.g., The Request For Comments
- papers).
-
- documentSeries OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- commonName}
- MAY CONTAIN {
- description,
- seeAlso,
- telephoneNumber,
- localityName,
- organizationName,
- organizationalUnitName}
- ::= {pilotObjectClass 9}
-
-8.3.7. Domain
-
- The Domain object class is used to define entries which represent DNS
- or NRS domains. The domainComponent attribute should be used for
- naming entries of this object class. The usage of this object class
- is described in more detail in [3].
-
- domain OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- domainComponent}
- MAY CONTAIN {
-
-
-
-Barker & Kille [Page 11]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- associatedName,
- organizationName,
- organizationalAttributeSet}
- ::= {pilotObjectClass 13}
-
-8.3.8. RFC822 Local Part
-
- The RFC822 Local Part object class is used to define entries which
- represent the local part of RFC822 mail addresses. This treats this
- part of an RFC822 address as a domain. The usage of this object
- class is described in more detail in [3].
-
- rFC822localPart OBJECT-CLASS
- SUBCLASS OF domain
- MAY CONTAIN {
- commonName,
- surname,
- description,
- seeAlso,
- telephoneNumber,
- postalAttributeSet,
- telecommunicationAttributeSet}
- ::= {pilotObjectClass 14}
-
-8.3.9. DNS Domain
-
- The DNS Domain (Domain NameServer) object class is used to define
- entries for DNS domains. The usage of this object class is described
- in more detail in [3].
-
- dNSDomain OBJECT-CLASS
- SUBCLASS OF domain
- MAY CONTAIN {
- ARecord,
- MDRecord,
- MXRecord,
- NSRecord,
- SOARecord,
- CNAMERecord}
- ::= {pilotObjectClass 15}
-
-8.3.10. Domain Related Object
-
- The Domain Related Object object class is used to define entries
- which represent DNS/NRS domains which are "equivalent" to an X.500
- domain: e.g., an organisation or organisational unit. The usage of
- this object class is described in more detail in [3].
-
-
-
-
-Barker & Kille [Page 12]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- domainRelatedObject OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- associatedDomain}
- ::= {pilotObjectClass 17}
-
-8.3.11. Friendly Country
-
- The Friendly Country object class is used to define country entries
- in the DIT. The object class is used to allow friendlier naming of
- countries than that allowed by the object class country. The naming
- attribute of object class country, countryName, has to be a 2 letter
- string defined in ISO 3166.
-
- friendlyCountry OBJECT-CLASS
- SUBCLASS OF country
- MUST CONTAIN {
- friendlyCountryName}
- ::= {pilotObjectClass 18}
-
-8.3.12. Simple Security Object
-
- The Simple Security Object object class is used to allow an entry to
- have a userPassword attribute when an entry's principal object
- classes do not allow userPassword as an attribute type.
-
- simpleSecurityObject OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- userPassword }
- ::= {pilotObjectClass 19}
-
-8.3.13. Pilot Organization
-
- The PilotOrganization object class is used as a sub-class of
- organization and organizationalUnit to allow a number of additional
- attributes to be assigned to entries of object classes organization
- and organizationalUnit.
-
- pilotOrganization OBJECT-CLASS
- SUBCLASS OF organization, organizationalUnit
- MAY CONTAIN {
- buildingName}
- ::= {pilotObjectClass 20}
-
-
-
-
-
-
-
-Barker & Kille [Page 13]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
-8.3.14. Pilot DSA
-
- The PilotDSA object class is used as a sub-class of the dsa object
- class to allow additional attributes to be assigned to entries for
- DSAs.
-
- pilotDSA OBJECT-CLASS
- SUBCLASS OF dsa
- MUST CONTAIN {
- dSAQuality}
- ::= {pilotObjectClass 21}
-
-8.3.15. Quality Labelled Data
-
- The Quality Labelled Data object class is used to allow the
- assignment of the data quality attributes to subtrees in the DIT.
-
- See [8] for more details.
-
- qualityLabelledData OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- dSAQuality}
- MAY CONTAIN {
- subtreeMinimumQuality,
- subtreeMaximumQuality}
- ::= {pilotObjectClass 22}
-
-9. Attribute Types
-
-9.1. X.500 standard attribute types
-
- A number of generally useful attribute types are defined in X.520,
- and these are supported. Refer to that document for descriptions of
- the suggested usage of these attribute types. The ASN.1 for these
- attribute types is reproduced for completeness in Appendix C.
-
-9.2. X.400 standard attribute types
-
- The standard X.400 attribute types are supported. See X.402 for full
- details. The ASN.1 for these attribute types is reproduced in
- Appendix C.
-
-9.3. COSINE/Internet attribute types
-
- This section describes all the attribute types defined for use in the
- COSINE and Internet pilots. Descriptions are given as to the
- suggested usage of these attribute types. The ASN.1 for these
-
-
-
-Barker & Kille [Page 14]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- attribute types is reproduced in Appendix C.
-
-9.3.1. Userid
-
- The Userid attribute type specifies a computer system login name.
-
- userid ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-user-identifier))
- ::= {pilotAttributeType 1}
-
-9.3.2. Text Encoded O/R Address
-
- The Text Encoded O/R Address attribute type specifies a text encoding
- of an X.400 O/R address, as specified in RFC 987. The use of this
- attribute is deprecated as the attribute is intended for interim use
- only. This attribute will be the first candidate for the attribute
- expiry mechanisms!
-
- textEncodedORAddress ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-text-encoded-or-address))
- ::= {pilotAttributeType 2}
-
-9.3.3. RFC 822 Mailbox
-
- The RFC822 Mailbox attribute type specifies an electronic mailbox
- attribute following the syntax specified in RFC 822. Note that this
- attribute should not be used for greybook or other non-Internet order
- mailboxes.
-
- rfc822Mailbox ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreIA5StringSyntax
- (SIZE (1 .. ub-rfc822-mailbox))
- ::= {pilotAttributeType 3}
-
-9.3.4. Information
-
- The Information attribute type specifies any general information
- pertinent to an object. It is recommended that specific usage of
- this attribute type is avoided, and that specific requirements are
- met by other (possibly additional) attribute types.
-
- info ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
-
-
-
-Barker & Kille [Page 15]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-information))
- ::= {pilotAttributeType 4}
-
-9.3.5. Favourite Drink
-
- The Favourite Drink attribute type specifies the favourite drink of
- an object (or person).
-
- favouriteDrink ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-favourite-drink))
- ::= {pilotAttributeType 5}
-
-9.3.6. Room Number
-
- The Room Number attribute type specifies the room number of an
- object. Note that the commonName attribute should be used for naming
- room objects.
-
- roomNumber ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-room-number))
- ::= {pilotAttributeType 6}
-
-9.3.7. Photo
-
- The Photo attribute type specifies a "photograph" for an object.
- This should be encoded in G3 fax as explained in recommendation T.4,
- with an ASN.1 wrapper to make it compatible with an X.400 BodyPart as
- defined in X.420.
-
- IMPORT G3FacsimileBodyPart FROM { mhs-motis ipms modules
- information-objects }
-
- photo ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- CHOICE {
- g3-facsimile [3] G3FacsimileBodyPart
- }
- (SIZE (1 .. ub-photo))
- ::= {pilotAttributeType 7}
-
-
-
-
-
-
-
-Barker & Kille [Page 16]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
-9.3.8. User Class
-
- The User Class attribute type specifies a category of computer user.
- The semantics placed on this attribute are for local interpretation.
- Examples of current usage od this attribute in academia are
- undergraduate student, researcher, lecturer, etc. Note that the
- organizationalStatus attribute may now often be preferred as it makes
- no distinction between computer users and others.
-
- userClass ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-user-class))
- ::= {pilotAttributeType 8}
-
-9.3.9. Host
-
- The Host attribute type specifies a host computer.
-
- host ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-host))
- ::= {pilotAttributeType 9}
-
-9.3.10. Manager
-
- The Manager attribute type specifies the manager of an object
- represented by an entry.
-
- manager ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- distinguishedNameSyntax
- ::= {pilotAttributeType 10}
-
-9.3.11. Document Identifier
-
- The Document Identifier attribute type specifies a unique identifier
- for a document.
-
- documentIdentifier ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-document-identifier))
- ::= {pilotAttributeType 11}
-
-
-
-
-
-
-Barker & Kille [Page 17]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
-9.3.12. Document Title
-
- The Document Title attribute type specifies the title of a document.
-
- documentTitle ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-document-title))
- ::= {pilotAttributeType 12}
-
-9.3.13. Document Version
-
- The Document Version attribute type specifies the version number of a
- document.
-
- documentVersion ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-document-version))
- ::= {pilotAttributeType 13}
-
-9.3.14. Document Author
-
- The Document Author attribute type specifies the distinguished name
- of the author of a document.
-
- documentAuthor ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- distinguishedNameSyntax
- ::= {pilotAttributeType 14}
-
-9.3.15. Document Location
-
- The Document Location attribute type specifies the location of the
- document original.
-
- documentLocation ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-document-location))
- ::= {pilotAttributeType 15}
-
-9.3.16. Home Telephone Number
-
- The Home Telephone Number attribute type specifies a home telephone
- number associated with a person. Attribute values should follow the
- agreed format for international telephone numbers: i.e., "+44 71 123
- 4567".
-
-
-
-Barker & Kille [Page 18]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- homeTelephoneNumber ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- telephoneNumberSyntax
- ::= {pilotAttributeType 20}
-
-9.3.17. Secretary
-
- The Secretary attribute type specifies the secretary of a person.
- The attribute value for Secretary is a distinguished name.
-
- secretary ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- distinguishedNameSyntax
- ::= {pilotAttributeType 21}
-
-9.3.18. Other Mailbox
-
- The Other Mailbox attribute type specifies values for electronic
- mailbox types other than X.400 and rfc822.
-
- otherMailbox ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- SEQUENCE {
- mailboxType PrintableString, -- e.g. Telemail
- mailbox IA5String -- e.g. X378:Joe
- }
- ::= {pilotAttributeType 22}
-
-9.3.19. Last Modified Time
-
- The Last Modified Time attribute type specifies the last time, in UTC
- time, that an entry was modified. Ideally, this attribute should be
- maintained by the DSA.
-
- lastModifiedTime ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- uTCTimeSyntax
- ::= {pilotAttributeType 23}
-
-9.3.20. Last Modified By
-
- The Last Modified By attribute specifies the distinguished name of
- the last user to modify the associated entry. Ideally, this
- attribute should be maintained by the DSA.
-
- lastModifiedBy ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- distinguishedNameSyntax
-
-
-
-Barker & Kille [Page 19]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- ::= {pilotAttributeType 24}
-
-9.3.21. Domain Component
-
- The Domain Component attribute type specifies a DNS/NRS domain. For
- example, "uk" or "ac".
-
- domainComponent ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreIA5StringSyntax
- SINGLE VALUE
- ::= {pilotAttributeType 25}
-
- 9.3.22. DNS ARecord
-
- The A Record attribute type specifies a type A (Address) DNS resource
- record [6] [7].
-
- aRecord ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- DNSRecordSyntax
- ::= {pilotAttributeType 26}
-
-9.3.23. MX Record
-
- The MX Record attribute type specifies a type MX (Mail Exchange) DNS
- resource record [6] [7].
-
- mXRecord ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- DNSRecordSyntax
- ::= {pilotAttributeType 28}
-
-9.3.24. NS Record
-
- The NS Record attribute type specifies an NS (Name Server) DNS
- resource record [6] [7].
-
- nSRecord ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- DNSRecordSyntax
- ::= {pilotAttributeType 29}
-
-9.3.25. SOA Record
-
- The SOA Record attribute type specifies a type SOA (Start of
- Authority) DNS resorce record [6] [7].
-
-
-
-
-Barker & Kille [Page 20]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- sOARecord ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- DNSRecordSyntax
- ::= {pilotAttributeType 30}
-
-9.3.26. CNAME Record
-
- The CNAME Record attribute type specifies a type CNAME (Canonical
- Name) DNS resource record [6] [7].
-
- cNAMERecord ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- iA5StringSyntax
- ::= {pilotAttributeType 31}
-
-9.3.27. Associated Domain
-
- The Associated Domain attribute type specifies a DNS or NRS domain
- which is associated with an object in the DIT. For example, the entry
- in the DIT with a distinguished name "C=GB, O=University College
- London" would have an associated domain of "UCL.AC.UK. Note that all
- domains should be represented in rfc822 order. See [3] for more
- details of usage of this attribute.
-
- associatedDomain ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreIA5StringSyntax
- ::= {pilotAttributeType 37}
-
-9.3.28. Associated Name
-
- The Associated Name attribute type specifies an entry in the
- organisational DIT associated with a DNS/NRS domain. See [3] for
- more details of usage of this attribute.
-
- associatedName ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- distinguishedNameSyntax
- ::= {pilotAttributeType 38}
-
-9.3.29. Home postal address
-
- The Home postal address attribute type specifies a home postal
- address for an object. This should be limited to up to 6 lines of 30
- characters each.
-
- homePostalAddress ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
-
-
-
-Barker & Kille [Page 21]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- postalAddress
- MATCHES FOR EQUALITY
- ::= {pilotAttributeType 39}
-
-9.3.30. Personal Title
-
- The Personal Title attribute type specifies a personal title for a
- person. Examples of personal titles are "Ms", "Dr", "Prof" and "Rev".
-
- personalTitle ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-personal-title))
- ::= {pilotAttributeType 40}
-
-9.3.31. Mobile Telephone Number
-
- The Mobile Telephone Number attribute type specifies a mobile
- telephone number associated with a person. Attribute values should
- follow the agreed format for international telephone numbers: i.e.,
- "+44 71 123 4567".
-
- mobileTelephoneNumber ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- telephoneNumberSyntax
- ::= {pilotAttributeType 41}
-
-9.3.32. Pager Telephone Number
-
- The Pager Telephone Number attribute type specifies a pager telephone
- number for an object. Attribute values should follow the agreed
- format for international telephone numbers: i.e., "+44 71 123 4567".
-
- pagerTelephoneNumber ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- telephoneNumberSyntax
- ::= {pilotAttributeType 42}
-
-9.3.33. Friendly Country Name
-
- The Friendly Country Name attribute type specifies names of countries
- in human readable format. The standard attribute country name must
- be one of the two-letter codes defined in ISO 3166.
-
- friendlyCountryName ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- ::= {pilotAttributeType 43}
-
-
-
-Barker & Kille [Page 22]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
-9.3.34. Unique Identifier
-
- The Unique Identifier attribute type specifies a "unique identifier"
- for an object represented in the Directory. The domain within which
- the identifier is unique, and the exact semantics of the identifier,
- are for local definition. For a person, this might be an
- institution-wide payroll number. For an organisational unit, it
- might be a department code.
-
- uniqueIdentifier ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-unique-identifier))
- ::= {pilotAttributeType 44}
-
-9.3.35. Organisational Status
-
- The Organisational Status attribute type specifies a category by
- which a person is often referred to in an organisation. Examples of
- usage in academia might include undergraduate student, researcher,
- lecturer, etc.
-
- A Directory administrator should probably consider carefully the
- distinctions between this and the title and userClass attributes.
-
- organizationalStatus ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-organizational-status))
- ::= {pilotAttributeType 45}
-
-9.3.36. Janet Mailbox
-
- The Janet Mailbox attribute type specifies an electronic mailbox
- attribute following the syntax specified in the Grey Book of the
- Coloured Book series. This attribute is intended for the convenience
- of U.K users unfamiliar with rfc822 and little-endian mail addresses.
- Entries using this attribute MUST also include an rfc822Mailbox
- attribute.
-
- janetMailbox ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreIA5StringSyntax
- (SIZE (1 .. ub-janet-mailbox))
- ::= {pilotAttributeType 46}
-
-
-
-
-
-
-Barker & Kille [Page 23]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
-9.3.37. Mail Preference Option
-
- An attribute to allow users to indicate a preference for inclusion of
- their names on mailing lists (electronic or physical). The absence
- of such an attribute should be interpreted as if the attribute was
- present with value "no-list-inclusion". This attribute should be
- interpreted by anyone using the directory to derive mailing lists,
- and its value respected.
-
- mailPreferenceOption ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX ENUMERATED {
- no-list-inclusion(0),
- any-list-inclusion(1), -- may be added to any lists
- professional-list-inclusion(2)
- -- may be added to lists
- -- which the list provider
- -- views as related to the
- -- users professional inter-
- -- ests, perhaps evaluated
- -- from the business of the
- -- organisation or keywords
- -- in the entry.
- }
- ::= {pilotAttributeType 47}
-
-9.3.38. Building Name
-
- The Building Name attribute type specifies the name of the building
- where an organisation or organisational unit is based.
-
- buildingName ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-building-name))
- ::= {pilotAttributeType 48}
-
-9.3.39. DSA Quality
-
- The DSA Quality attribute type specifies the purported quality of a
- DSA. It allows a DSA manager to indicate the expected level of
- availability of the DSA. See [8] for details of the syntax.
-
- dSAQuality ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX DSAQualitySyntax
- SINGLE VALUE
- ::= {pilotAttributeType 49}
-
-
-
-
-
-Barker & Kille [Page 24]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
-9.3.40. Single Level Quality
-
- The Single Level Quality attribute type specifies the purported data
- quality at the level immediately below in the DIT. See [8] for
- details of the syntax.
-
- singleLevelQuality ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX DataQualitySyntax
- SINGLE VALUE
- ::= {pilotAttributeType 50}
-
-9.3.41. Subtree Minimum Quality
-
- The Subtree Minimum Quality attribute type specifies the purported
- minimum data quality for a DIT subtree. See [8] for more discussion
- and details of the syntax.
-
- subtreeMinimumQuality ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX DataQualitySyntax
- SINGLE VALUE
- -- Defaults to singleLevelQuality
- ::= {pilotAttributeType 51}
-
-9.3.42. Subtree Maximum Quality
-
- The Subtree Maximum Quality attribute type specifies the purported
- maximum data quality for a DIT subtree. See [8] for more discussion
- and details of the syntax.
-
- subtreeMaximumQuality ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX DataQualitySyntax
- SINGLE VALUE
- -- Defaults to singleLevelQuality
- ::= {pilotAttributeType 52}
-
-9.3.43. Personal Signature
-
- The Personal Signature attribute type allows for a representation of
- a person's signature. This should be encoded in G3 fax as explained
- in recommendation T.4, with an ASN.1 wrapper to make it compatible
- with an X.400 BodyPart as defined in X.420.
-
- IMPORT G3FacsimileBodyPart FROM { mhs-motis ipms modules
- information-objects }
-
- personalSignature ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- CHOICE {
-
-
-
-Barker & Kille [Page 25]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- g3-facsimile [3] G3FacsimileBodyPart
- }
- (SIZE (1 .. ub-personal-signature))
- ::= {pilotAttributeType 53}
-
-9.3.44. DIT Redirect
-
- The DIT Redirect attribute type is used to indicate that the object
- described by one entry now has a newer entry in the DIT. The entry
- containing the redirection attribute should be expired after a
- suitable grace period. This attribute may be used when an individual
- changes his/her place of work, and thus acquires a new organisational
- DN.
-
- dITRedirect ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- distinguishedNameSyntax
- ::= {pilotAttributeType 54}
-
-9.3.45. Audio
-
- The Audio attribute type allows the storing of sounds in the
- Directory. The attribute uses a u-law encoded sound file as used by
- the "play" utility on a Sun 4. This is an interim format.
-
- audio ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- Audio
- (SIZE (1 .. ub-audio))
- ::= {pilotAttributeType 55}
-
-9.3.46. Publisher of Document
-
-
- The Publisher of Document attribute is the person and/or organization
- that published a document.
-
- documentPublisher ATTRIBUTE
- WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax
- ::= {pilotAttributeType 56}
-
-9.4. Generally useful syntaxes
-
- caseIgnoreIA5StringSyntax ATTRIBUTE-SYNTAX
- IA5String
- MATCHES FOR EQUALITY SUBSTRINGS
-
-
-
-
-
-Barker & Kille [Page 26]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- iA5StringSyntax ATTRIBUTE-SYNTAX
- IA5String
- MATCHES FOR EQUALITY SUBSTRINGS
-
-
- -- Syntaxes to support the DNS attributes
-
- DNSRecordSyntax ATTRIBUTE-SYNTAX
- IA5String
- MATCHES FOR EQUALITY
-
-
- NRSInformationSyntax ATTRIBUTE-SYNTAX
- NRSInformation
- MATCHES FOR EQUALITY
-
-
- NRSInformation ::= SET {
- [0] Context,
- [1] Address-space-id,
- routes [2] SEQUENCE OF SEQUENCE {
- Route-cost,
- Addressing-info }
- }
-
-
-9.5. Upper bounds on length of attribute values
-
-
- ub-document-identifier INTEGER ::= 256
-
- ub-document-location INTEGER ::= 256
-
- ub-document-title INTEGER ::= 256
-
- ub-document-version INTEGER ::= 256
-
- ub-favourite-drink INTEGER ::= 256
-
- ub-host INTEGER ::= 256
-
- ub-information INTEGER ::= 2048
-
- ub-unique-identifier INTEGER ::= 256
-
- ub-personal-title INTEGER ::= 256
-
- ub-photo INTEGER ::= 250000
-
-
-
-Barker & Kille [Page 27]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- ub-rfc822-mailbox INTEGER ::= 256
-
- ub-room-number INTEGER ::= 256
-
- ub-text-or-address INTEGER ::= 256
-
- ub-user-class INTEGER ::= 256
-
- ub-user-identifier INTEGER ::= 256
-
- ub-organizational-status INTEGER ::= 256
-
- ub-janet-mailbox INTEGER ::= 256
-
- ub-building-name INTEGER ::= 256
-
- ub-personal-signature ::= 50000
-
- ub-audio INTEGER ::= 250000
-
-References
-
- [1] CCITT/ISO, "X.500, The Directory - overview of concepts,
- models and services, CCITT /ISO IS 9594.
-
- [2] Kille, S., "The THORN and RARE X.500 Naming Architecture, in
- University College London, Department of Computer Science
- Research Note 89/48, May 1989.
-
- [3] Kille, S., "X.500 and Domains", RFC 1279, University College
- London, November 1991.
-
- [4] Rose, M., "PSI/NYSERNet White Pages Pilot Project: Status
- Report", Technical Report 90-09-10-1, published by NYSERNet
- Inc, 1990.
-
- [5] Craigie, J., "UK Academic Community Directory Service Pilot
- Project, pp. 305-310 in Computer Networks and ISDN Systems
- 17 (1989), published by North Holland.
-
- [6] Mockapetris, P., "Domain Names - Concepts and Facilities",
- RFC 1034, USC/Information Sciences Institute, November 1987.
-
- [7] Mockapetris, P., "Domain Names - Implementation and
- Specification, RFC 1035, USC/Information Sciences Institute,
- November 1987.
-
- [8] Kille, S., "Handling QOS (Quality of service) in the
-
-
-
-Barker & Kille [Page 28]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- Directory," publication in process, March 1991.
-
-APPENDIX A - Object Class and Attribute Type proformas
-
- These are specified in BNF. First some useful definitions, common to
- both proformas.
-
- EOL ::= -- the end of line character(s)
-
- BlankLine ::= -- a line consisting solely of an EOL character
-
- String ::= <anychar> | <String> <anychar>
-
- anychar ::= --any character occurring in general text, excluding
- -- the end of line character
-
- lString ::= <lowercase> <otherstring>
-
- lowercase ::= [a-z]
-
- UString ::= <uppercase> <otherstring>
-
- uppercase ::= [A-Z]
-
- otherstring ::= <otherchar> | <otherstring> <otherchar>
-
- otherchar ::= <lowercase> | <uppercase> | <digit>
-
- Integer ::= <digit> | <Integer> <digit>
-
- digit ::= [0-9]
-
-1. Object Class
-
-
- OCProforma ::= <ObjectClassName> <BlankLine> <Description> \
- <BlankLine> <OCMacro>
-
- ObjectClassName ::= "ObjectClass:" <String> <EOL>
-
- Description ::= "Description:" <DescriptiveText> <EOL>
-
- DescriptiveText ::= <String> | <DescriptiveText> <EOL> <String>
-
- OCMacro ::= "ASN1OCMacro:" <ObjectClassMacro>
-
- -- The definition of ObjectClassMacro is adapted from
- -- that given in X.501
-
-
-
-Barker & Kille [Page 29]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- ObjectClassMacro ::= <OCname> "OBJECT-CLASS" <SubclassOf> \
- <MandatoryAttributes> <OptionalAttributes>
-
- OCName ::= <lString>
-
- SubclassOf ::= "SUBCLASS OF" Subclasses | <empty>
-
- Subclasses ::= <Subclass> | <Subclass> "," <Subclasses>
-
- Subclass ::= <OCName>
-
- MandatoryAttributes ::= "MUST CONTAIN {" <Attributes> "}" \
- | <empty>
- OptionalAttributes ::= "MAY CONTAIN {" <Attributes> "}" | <empty>
-
- Attributes ::= <AttributeTerm> | <AttributeTerm> "," <Attributes>
-
- AttributeTerm ::= <Attribute> | <AttributeSet>
-
- Attribute ::= <lString>
-
- AttributeSet ::= <lString>
-
-2. Attribute Type
-
-
- ATProforma ::= <AttributeTypeName> <BlankLine> <Description> \
- <BlankLine> <OCMust> <Blankline> <OCMay> \
- <BlankLine> <ATMacro>
-
- AttributeTypeName ::= "Attribute Type:" <String> <EOL>
-
- Description ::= "Description:" <DescriptiveText> <EOL>
-
- DescriptiveText ::= <String> | <DescriptiveText> <EOL> <String>
-
- OCMust ::= "OCMust:" <OCList> <EOL>
-
- OCList ::= <OCName> | <OCList> "," <OCName> | <empty>
-
- OCMay ::= "OCMay:" <OCList> <EOL>
-
- ATMacro ::= "ASN1ATMacro:" <AttributeTypeMacro>
-
- -- The definition of AttributeTypeMacro is adapted from that
- -- given in X.501
-
- AttributeTypeMacro ::= <ATname> "ATTRIBUTE" <AttributeSyntax> \
-
-
-
-Barker & Kille [Page 30]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- <Multivalued> | <empty>
-
- ATName ::= <lString>
-
- AttributeSyntax ::= "WITH ATTRIBUTE SYNTAX" SyntaxChoice
-
- SyntaxChoice ::= <Syntax> <Constraint> | <ASN1Type> <MatchTypes>
-
- Syntax ::= <lString>
-
- Constraint ::= "(" ConstraintAlternative ")" | <empty>
-
- ConstraintAlternative ::= StringConstraint | IntegerConstraint
-
- StringConstraint ::= "SIZE" "(" SizeConstraint ")"
-
- SizeConstraint ::= SingleValue | Range
-
- SingleValue ::= <Integer>
-
- Range ::= <Integer> ".." <Integer>
-
- IntegerConstraint ::= Range
-
- ASN1Type ::= <UString>
- -- one of ASN.1's base types: e.g. PrintableString,
- -- NumericString, etc.
-
- MatchTypes ::= "MATCHES FOR" Matches | <empty>
-
- Matches ::= Match | Matches Match
-
- Match ::= "EQUALITY" | "SUBSTRINGS" | "ORDERING"
-
- Multivalued ::= "SINGLE VALUE" | "MULTI VALUE" | <empty>
-
-APPENDIX B - Format checking tools
-
- This section includes the source for format checking tools for the
- two proformas. The tools are written as Bourne shell scripts for
- UNIX systems.
-
-1. Object class format checker
-
-
- sed 's/ *: */:/' |
- awk '
- BEGIN {
-
-
-
-Barker & Kille [Page 31]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- state = "initial"
- }
-
- /^$/ {
- next
- }
-
- /^Object Class:/ {
- n = index($0, ":")
- if (state != "initial")
- {
- print "Already got object class " oc
- print "Got another object class " substr($0, n+1)
- state = "notOK"
- exit 1
- }
- oc = substr($0, n+1)
- state = "gotOC"
- next
- }
-
- /^Description:/ {
- n = index($0, ":")
- if (state != "gotOC")
- {
- print "Got Description: " substr($0, n+1)
- for (i = 0; i < 2 && getline > 0; i++)
- print $0
- print "..."
- if (state == "initial")
- print "Expecting Object Class:"
- else
- print "Expecting ASN1OCMacro:"
- state = "notOK"
- exit 1
- }
- while (getline > 0)
- if (length($0) > 0)
- continue
- else
- break
- state = "gotDesc"
- next
- }
-
- /^ASN1OCMacro:/ {
- n = index($0, ":")
- if (state != "gotDesc")
-
-
-
-Barker & Kille [Page 32]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- {
- print "Got ASN1Macro: " substr($0, n+1)
- for (i = 0; i < 2 && getline > 0; i++)
- print $0
- print "..."
- if (state == "initial")
- print "Expecting Object Class:"
- else
- print "Expecting Description:"
- state = "notOK"
- exit 1
- }
- state = "OK"
- exit 0
- }
-
- {
- print "Parsing has got confused on seeing line: " $0
- state = "notOK"
- exit 1
- }
-
- END {
- if (state == "OK")
- print "Input looks OK"
- }
-
-
-2. Attribute Type format checker
-
-
- sed 's/ *: */:/' |
- awk '
- BEGIN {
- state = "initial"
- }
-
- /^$/ {
- next
- }
-
- /^Attribute Type:/ {
- n = index($0, ":")
- if (state != "initial")
- {
- got = "Attribute Type:"
- exit 1
- }
-
-
-
-Barker & Kille [Page 33]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- state = "gotAT"
- next
- }
-
- /^Description:/ {
- n = index($0, ":")
- if (state != "gotAT")
- {
- got = "Description:"
- exit 1
- }
- while (getline > 0)
- if (length($0) > 0)
- continue
- else
- break
- state = "gotDesc"
- next
- }
-
- /^OCMust:/ {
- n = index($0, ":")
- if (state != "gotDesc")
- {
- got = "OCMust:"
- exit 1
- }
- state = "gotOCMust"
- next
- }
-
- /^OCMay:/ {
- n = index($0, ":")
- if (state != "gotOCMust")
- {
- got = "OCMay:"
- exit 1
- }
- state = "gotOCMay"
- next
- }
-
- /^ASN1ATMacro:/ {
- n = index($0, ":")
- if (state != "gotOCMay")
- {
- got = "ASN1ATMacro:"
- exit 1
-
-
-
-Barker & Kille [Page 34]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- }
- state = "OK"
- exit 0
- }
-
- {
- print "Parsing has got confused on seeing line: " $0
- state = "notOK"
- exit 1
- }
-
- END {
- if (state == "initial")
- print "Expecting Attribute Type:"
- else if (state == "gotAT")
- print "Expecting Description:"
- else if (state == "gotDesc")
- print "Expecting OCMust:"
- else if (state == "gotOCMust")
- print "Expecting OCMay:"
- else if (state == "gotOCMay")
- print "Expecting ASN1ATMacro:"
- if (state != "OK")
- print "Got " got
- else
- print "Input looks OK"
- }
-
-
-APPENDIX C - Summary of all Object Classes and Attribute Types
-
- -- Some Important Object Identifiers
-
- data OBJECT IDENTIFIER ::= {ccitt 9}
- pss OBJECT IDENTIFIER ::= {data 2342}
- ucl OBJECT IDENTIFIER ::= {pss 19200300}
- pilot OBJECT IDENTIFIER ::= {ucl 100}
-
- pilotAttributeType OBJECT IDENTIFIER ::= {pilot 1}
- pilotAttributeSyntax OBJECT IDENTIFIER ::= {pilot 3}
- pilotObjectClass OBJECT IDENTIFIER ::= {pilot 4}
- pilotGroups OBJECT IDENTIFIER ::= {pilot 10}
-
- iA5StringSyntax OBJECT IDENTIFIER ::= {pilotAttributeSyntax 4}
- caseIgnoreIA5StringSyntax OBJECT IDENTIFIER ::=
- {pilotAttributeSyntax 5}
-
-
-
-
-
-Barker & Kille [Page 35]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- -- Standard Object Classes
-
- top OBJECT-CLASS
- MUST CONTAIN {
- objectClass}
- ::= {objectClass 0}
-
-
- alias OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- aliasedObjectName}
- ::= {objectClass 1}
-
-
- country OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- countryName}
- MAY CONTAIN {
- description,
- searchGuide}
- ::= {objectClass 2}
-
-
- locality OBJECT-CLASS
- SUBCLASS OF top
- MAY CONTAIN {
- description,
- localityName,
- stateOrProvinceName,
- searchGuide,
- seeAlso,
- streetAddress}
- ::= {objectClass 3}
-
-
- organization OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- organizationName}
- MAY CONTAIN {
- organizationalAttributeSet}
- ::= {objectClass 4}
-
-
-
-
-
-
-
-Barker & Kille [Page 36]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- organizationalUnit OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- organizationalUnitName}
- MAY CONTAIN {
- organizationalAttributeSet}
- ::= {objectClass 5}
-
-
- person OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- commonName,
- surname}
- MAY CONTAIN {
- description,
- seeAlso,
- telephoneNumber,
- userPassword}
- ::= {objectClass 6}
-
-
- organizationalPerson OBJECT-CLASS
- SUBCLASS OF person
- MAY CONTAIN {
- localeAttributeSet,
- organizationalUnitName,
- postalAttributeSet,
- telecommunicationAttributeSet,
- title}
- ::= {objectClass 7}
-
-
- organizationalRole OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- commonName}
- MAY CONTAIN {
- description,
- localeAttributeSet,
- organizationalUnitName,
- postalAttributeSet,
- preferredDeliveryMethod,
- roleOccupant,
- seeAlso,
- telecommunicationAttributeSet}
- ::= {objectClass 8}
-
-
-
-
-Barker & Kille [Page 37]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- groupOfNames OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- commonName,
- member}
- MAY CONTAIN {
- description,
- organizationName,
- organizationalUnitName,
- owner,
- seeAlso,
- businessCategory}
- ::= {objectClass 9}
-
-
- residentialPerson OBJECT-CLASS
- SUBCLASS OF person
- MUST CONTAIN {
- localityName}
- MAY CONTAIN {
- localeAttributeSet,
- postalAttributeSet,
- preferredDeliveryMethod,
- telecommunicationAttributeSet,
- businessCategory}
- ::= {objectClass 10}
-
-
- applicationProcess OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- commonName}
- MAY CONTAIN {
- description,
- localityName,
- organizationalUnitName,
- seeAlso}
- ::= {objectClass 11}
-
-
- applicationEntity OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- commonName,
- presentationAddress}
- MAY CONTAIN {
- description,
- localityName,
-
-
-
-Barker & Kille [Page 38]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- organizationName,
- organizationalUnitName,
- seeAlso,
- supportedApplicationContext}
- ::= {objectClass 12}
-
-
- dSA OBJECT-CLASS
- SUBCLASS OF applicationEntity
- MAY CONTAIN {
- knowledgeInformation}
- ::= {objectClass 13}
-
-
- device OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- commonName}
- MAY CONTAIN {
- description,
- localityName,
- organizationName,
- organizationalUnitName,
- owner,
- seeAlso,
- serialNumber}
- ::= {objectClass 14}
-
-
- strongAuthenticationUser OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- userCertificate}
- ::= {objectClass 15}
-
-
- certificationAuthority OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- cACertificate,
- certificateRevocationList,
- authorityRevocationList}
- MAY CONTAIN {
- crossCertificatePair}
- ::= {objectClass 16}
-
-
-
-
-
-
-Barker & Kille [Page 39]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- -- Standard MHS Object Classes
-
- mhsDistributionList OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- commonName,
- mhsDLSubmitPermissions,
- mhsORAddresses}
- MAY CONTAIN {
- description,
- organizationName,
- organizationalUnitName,
- owner,
- seeAlso,
- mhsDeliverableContentTypes,
- mhsdeliverableEits,
- mhsDLMembers,
- mhsPreferredDeliveryMethods}
- ::= {mhsObjectClass 0}
-
-
- mhsMessageStore OBJECT-CLASS
- SUBCLASS OF applicationEntity
- MAY CONTAIN {
- description,
- owner,
- mhsSupportedOptionalAttributes,
- mhsSupportedAutomaticActions,
- mhsSupportedContentTypes}
- ::= {mhsObjectClass 1}
-
-
- mhsMessageTransferAgent OBJECT-CLASS
- SUBCLASS OF applicationEntity
- MAY CONTAIN {
- description,
- owner,
- mhsDeliverableContentLength}
- ::= {mhsObjectClass 2}
-
-
- mhsOrganizationalUser OBJECT-CLASS
- SUBCLASS OF organizationalPerson
- MUST CONTAIN {
- mhsORAddresses}
- MAY CONTAIN {
- mhsDeliverableContentLength,
- mhsDeliverableContentTypes,
-
-
-
-Barker & Kille [Page 40]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- mhsDeliverableEits,
- mhsMessageStoreName,
- mhsPreferredDeliveryMethods }
- ::= {mhsObjectClass 3}
-
-
- mhsResidentialUser OBJECT-CLASS
- SUBCLASS OF residentialPerson
- MUST CONTAIN {
- mhsORAddresses}
- MAY CONTAIN {
- mhsDeliverableContentLength,
- mhsDeliverableContentTypes,
- mhsDeliverableEits,
- mhsMessageStoreName,
- mhsPreferredDeliveryMethods }
- ::= {mhsObjectClass 4}
-
-
- mhsUserAgent OBJECT-CLASS
- SUBCLASS OF applicationEntity
- MAY CONTAIN {
- mhsDeliverableContentLength,
- mhsDeliverableContentTypes,
- mhsDeliverableEits,
- mhsORAddresses,
- owner}
- ::= {mhsObjectClass 5}
-
-
-
-
- -- Pilot Object Classes
-
- pilotObject OBJECT-CLASS
- SUBCLASS OF top
- MAY CONTAIN {
- info,
- photo,
- manager,
- uniqueIdentifier,
- lastModifiedTime,
- lastModifiedBy,
- dITRedirect,
- audio}
- ::= {pilotObjectClass 3}
-
-
-
-
-
-Barker & Kille [Page 41]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- pilotPerson OBJECT-CLASS
- SUBCLASS OF person
- MAY CONTAIN {
- userid,
- textEncodedORAddress,
- rfc822Mailbox,
- favouriteDrink,
- roomNumber,
- userClass,
- homeTelephoneNumber,
- homePostalAddress,
- secretary,
- personalTitle,
- preferredDeliveryMethod,
- businessCategory,
- janetMailbox,
- otherMailbox,
- mobileTelephoneNumber,
- pagerTelephoneNumber,
- organizationalStatus,
- mailPreferenceOption,
- personalSignature}
- ::= {pilotObjectClass 4}
-
-
- account OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- userid}
- MAY CONTAIN {
- description,
- seeAlso,
- localityName,
- organizationName,
- organizationalUnitName,
- host}
- ::= {pilotObjectClass 5}
-
-
- document OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- documentIdentifier}
- MAY CONTAIN {
- commonName,
- description,
- seeAlso,
- localityName,
-
-
-
-Barker & Kille [Page 42]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- organizationName,
- organizationalUnitName,
- documentTitle,
- documentVersion,
- documentAuthor,
- documentLocation,
- documentPublisher}
- ::= {pilotObjectClass 6}
-
-
- room OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- commonName}
- MAY CONTAIN {
- roomNumber,
- description,
- seeAlso,
- telephoneNumber}
- ::= {pilotObjectClass 7}
-
-
- documentSeries OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- commonName}
- MAY CONTAIN {
- description,
- seeAlso,
- telephoneNumber,
- localityName,
- organizationName,
- organizationalUnitName}
- ::= {pilotObjectClass 9}
-
-
- domain OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- domainComponent}
- MAY CONTAIN {
- associatedName,
- organizationName,
- organizationalAttributeSet}
- ::= {pilotObjectClass 13}
-
-
-
-
-
-
-Barker & Kille [Page 43]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- rFC822localPart OBJECT-CLASS
- SUBCLASS OF domain
- MAY CONTAIN {
- commonName,
- surname,
- description,
- seeAlso,
- telephoneNumber,
- postalAttributeSet,
- telecommunicationAttributeSet}
- ::= {pilotObjectClass 14}
-
-
- dNSDomain OBJECT-CLASS
- SUBCLASS OF domain
- MAY CONTAIN {
- ARecord,
- MDRecord,
- MXRecord,
- NSRecord,
- SOARecord,
- CNAMERecord}
- ::= {pilotObjectClass 15}
-
-
- domainRelatedObject OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- associatedDomain}
- ::= {pilotObjectClass 17}
-
-
- friendlyCountry OBJECT-CLASS
- SUBCLASS OF country
- MUST CONTAIN {
- friendlyCountryName}
- ::= {pilotObjectClass 18}
-
-
- simpleSecurityObject OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- userPassword }
- ::= {pilotObjectClass 19}
-
-
- pilotOrganization OBJECT-CLASS
- SUBCLASS OF organization, organizationalUnit
-
-
-
-Barker & Kille [Page 44]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- MAY CONTAIN {
- buildingName}
- ::= {pilotObjectClass 20}
-
-
- pilotDSA OBJECT-CLASS
- SUBCLASS OF dsa
- MUST CONTAIN {
- dSAQuality}
- ::= {pilotObjectClass 21}
-
-
- qualityLabelledData OBJECT-CLASS
- SUBCLASS OF top
- MUST CONTAIN {
- dSAQuality}
- MAY CONTAIN {
- subtreeMinimumQuality,
- subtreeMaximumQuality}
- ::= {pilotObjectClass 22}
-
-
-
-
- -- Standard Attribute Types
-
- objectClass ObjectClass
- ::= {attributeType 0}
-
-
- aliasedObjectName AliasedObjectName
- ::= {attributeType 1}
-
-
- knowledgeInformation ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX caseIgnoreString
- ::= {attributeType 2}
-
-
- commonName ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
- (SIZE (1..ub-common-name))
- ::= {attributeType 3}
-
-
- surname ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
- (SIZE (1..ub-surname))
-
-
-
-Barker & Kille [Page 45]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- ::= {attributeType 4}
-
-
- serialNumber ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX printableStringSyntax
- (SIZE (1..ub-serial-number))
- ::= {attributeType 5}
-
-
- countryName ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX PrintableString
- (SIZE (1..ub-country-code))
- SINGLE VALUE
- ::= {attributeType 6}
-
-
- localityName ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
- (SIZE (1..ub-locality-name))
- ::= {attributeType 7}
-
-
- stateOrProvinceName ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
- (SIZE (1..ub-state-name))
- ::= {attributeType 8}
-
-
- streetAddress ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
- (SIZE (1..ub-street-address))
- ::= {attributeType 9}
-
-
- organizationName ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
- (SIZE (1..ub-organization-name))
- ::= {attributeType 10}
-
-
- organizationalUnitName ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
- (SIZE (1..ub-organizational-unit-name))
- ::= {attributeType 11}
-
-
- title ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
-
-
-
-Barker & Kille [Page 46]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- (SIZE (1..ub-title))
- ::= {attributeType 12}
-
-
- description ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
- (SIZE (1..ub-description))
- ::= {attributeType 13}
-
-
- searchGuide ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX Guide
- ::= {attributeType 14}
-
-
- businessCategory ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
- (SIZE (1..ub-business-category))
- ::= {attributeType 15}
-
-
- postalAddress ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX PostalAddress
- MATCHES FOR EQUALITY
- ::= {attributeType 16}
-
-
- postalCode ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
- (SIZE (1..ub-postal-code))
- ::= {attributeType 17}
-
-
- postOfficeBox ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
- (SIZE (1..ub-post-office-box))
- ::= {attributeType 18}
-
-
- physicalDeliveryOfficeName ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
- (SIZE (1..ub-physical-office-name))
- ::= {attributeType 19}
-
-
- telephoneNumber ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX telephoneNumberSyntax
- (SIZE (1..ub-telephone-number))
-
-
-
-Barker & Kille [Page 47]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- ::= {attributeType 20}
-
-
- telexNumber ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX TelexNumber
- (SIZE (1..ub-telex))
- ::= {attributeType 21}
-
-
- teletexTerminalIdentifier ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX TeletexTerminalIdentifier
- (SIZE (1..ub-teletex-terminal-id))
- ::= {attributeType 22}
-
-
- facsimileTelephoneNumber ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX FacsimileTelephoneNumber
- ::= {attributeType 23}
-
-
- x121Address ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX NumericString
- (SIZE (1..ub-x121-address))
- ::= {attributeType 24}
-
-
- internationaliSDNNumber ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX NumericString
- (SIZE (1..ub-isdn-address))
- ::= {attributeType 25}
-
-
- registeredAddress ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX PostalAddress
- ::= {attributeType 26}
-
-
- destinationIndicator ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX PrintableString
- (SIZE (1..ub-destination-indicator))
- MATCHES FOR EQUALITY SUBSTRINGS
- ::= {attributeType 27}
-
-
- preferredDeliveryMethod ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX deliveryMethod
- ::= {attributeType 28}
-
-
-
-
-Barker & Kille [Page 48]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- presentationAddress ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX PresentationAddress
- MATCHES FOR EQUALITY
- ::= {attributeType 29}
-
-
- supportedApplicationContext ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX objectIdentifierSyntax
- ::= {attributeType 30}
-
-
- member ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
- ::= {attributeType 31}
-
-
- owner ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
- ::= {attributeType 32}
-
-
- roleOccupant ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
- ::= {attributeType 33}
-
-
- seeAlso ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
- ::= {attributeType 34}
-
-
- userPassword ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX Userpassword
- ::= {attributeType 35}
-
-
- userCertificate ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX UserCertificate
- ::= {attributeType 36}
-
-
- cACertificate ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX cACertificate
- ::= {attributeType 37}
-
-
- authorityRevocationList ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX AuthorityRevocationList
-
-
-
-Barker & Kille [Page 49]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- ::= {attributeType 38}
-
-
- certificateRevocationList ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX CertificateRevocationList
- ::= {attributeType 39}
-
-
- crossCertificatePair ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX CrossCertificatePair
- ::= {attributeType 40}
-
-
-
-
- -- Standard MHS Attribute Types
-
- mhsDeliverableContentLength ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX integer
- ::= {mhsAttributeType 0}
-
-
- mhsDeliverableContentTypes ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX oID
- ::= {mhsAttributeType 1}
-
-
- mhsDeliverableEits ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX oID
- ::= {mhsAttributeType 2}
-
-
- mhsDLMembers ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX oRName
- ::= {mhsAttributeType 3}
-
-
- mhsDLSubmitPermissions ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX dLSubmitPermission
- ::= {mhsAttributeType 4}
-
-
- mhsMessageStoreName ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX dN
- ::= {mhsAttributeType 5}
-
-
-
-
-
-
-Barker & Kille [Page 50]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- mhsORAddresses ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX oRAddress
- ::= {mhsAttributeType 6}
-
-
- mhsPreferredDeliveryMethods ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX deliveryMethod
- ::= {mhsAttributeType 7}
-
-
- mhsSupportedAutomaticActions ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX oID
- ::= {mhsAttributeType 8}
-
-
- mhsSupportedContentTypes ATTRIBUTE
-
- WITH ATTRIBUTE-SYNTAX oID
- ::= {mhsAttributeType 9}
-
-
- mhsSupportedOptionalAttributes ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX oID
- ::= {mhsAttributeType 10}
-
-
-
-
- -- Pilot Attribute Types
-
- userid ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-user-identifier))
- ::= {pilotAttributeType 1}
-
-
- textEncodedORAddress ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-text-encoded-or-address))
- ::= {pilotAttributeType 2}
-
-
- rfc822Mailbox ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreIA5StringSyntax
- (SIZE (1 .. ub-rfc822-mailbox))
-
-
-
-Barker & Kille [Page 51]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- ::= {pilotAttributeType 3}
-
-
- info ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-information))
- ::= {pilotAttributeType 4}
-
-
- favouriteDrink ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-favourite-drink))
- ::= {pilotAttributeType 5}
-
-
- roomNumber ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-room-number))
- ::= {pilotAttributeType 6}
-
-
- photo ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- CHOICE {
- g3-facsimile [3] G3FacsimileBodyPart
- }
- (SIZE (1 .. ub-photo))
- ::= {pilotAttributeType 7}
-
-
- userClass ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-user-class))
- ::= {pilotAttributeType 8}
-
-
- host ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-host))
- ::= {pilotAttributeType 9}
-
-
-
-
-
-
-Barker & Kille [Page 52]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- manager ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- distinguishedNameSyntax
- ::= {pilotAttributeType 10}
-
-
- documentIdentifier ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-document-identifier))
- ::= {pilotAttributeType 11}
-
-
- documentTitle ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-document-title))
- ::= {pilotAttributeType 12}
-
-
- documentVersion ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-document-version))
- ::= {pilotAttributeType 13}
-
-
- documentAuthor ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- distinguishedNameSyntax
- ::= {pilotAttributeType 14}
-
-
- documentLocation ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-document-location))
- ::= {pilotAttributeType 15}
-
-
- homeTelephoneNumber ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- telephoneNumberSyntax
- ::= {pilotAttributeType 20}
-
-
- secretary ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
-
-
-
-Barker & Kille [Page 53]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- distinguishedNameSyntax
- ::= {pilotAttributeType 21}
-
-
- otherMailbox ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- SEQUENCE {
- mailboxType PrintableString, -- e.g. Telemail
- mailbox IA5String -- e.g. X378:Joe
- }
- ::= {pilotAttributeType 22}
-
-
- lastModifiedTime ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- uTCTimeSyntax
- ::= {pilotAttributeType 23}
-
-
- lastModifiedBy ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- distinguishedNameSyntax
- ::= {pilotAttributeType 24}
-
-
- domainComponent ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreIA5StringSyntax
- SINGLE VALUE
- ::= {pilotAttributeType 25}
-
-
- aRecord ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- DNSRecordSyntax
- ::= {pilotAttributeType 26}
-
-
- mXRecord ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- DNSRecordSyntax
- ::= {pilotAttributeType 28}
-
-
- nSRecord ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- DNSRecordSyntax
- ::= {pilotAttributeType 29}
-
-
-
-Barker & Kille [Page 54]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- sOARecord ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- DNSRecordSyntax
- ::= {pilotAttributeType 30}
-
-
- cNAMERecord ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- iA5StringSyntax
- ::= {pilotAttributeType 31}
-
-
- associatedDomain ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreIA5StringSyntax
- ::= {pilotAttributeType 37}
-
-
- associatedName ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- distinguishedNameSyntax
- ::= {pilotAttributeType 38}
-
-
- homePostalAddress ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- postalAddress
- MATCHES FOR EQUALITY
- ::= {pilotAttributeType 39}
-
-
- personalTitle ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-personal-title))
- ::= {pilotAttributeType 40}
-
-
- mobileTelephoneNumber ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- telephoneNumberSyntax
- ::= {pilotAttributeType 41}
-
-
- pagerTelephoneNumber ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- telephoneNumberSyntax
- ::= {pilotAttributeType 42}
-
-
-
-Barker & Kille [Page 55]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- friendlyCountryName ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- ::= {pilotAttributeType 43}
-
-
- uniqueIdentifier ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-unique-identifier))
- ::= {pilotAttributeType 44}
-
-
- organizationalStatus ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-organizational-status))
- ::= {pilotAttributeType 45}
-
-
- janetMailbox ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreIA5StringSyntax
- (SIZE (1 .. ub-janet-mailbox))
- ::= {pilotAttributeType 46}
-
-
- mailPreferenceOption ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX ENUMERATED {
- no-list-inclusion(0),
- any-list-inclusion(1), -- may be added to any lists
- professional-list-inclusion(2)
- -- may be added to lists
- -- which the list provider
- -- views as related to the
- -- users professional inter-
- -- ests, perhaps evaluated
- -- from the business of the
- -- organisation or keywords
- -- in the entry.
- }
- ::= {pilotAttributeType 47}
-
-
- buildingName ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- caseIgnoreStringSyntax
- (SIZE (1 .. ub-building-name))
-
-
-
-Barker & Kille [Page 56]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- ::= {pilotAttributeType 48}
-
-
- dSAQuality ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX DSAQualitySyntax
- SINGLE VALUE
- ::= {pilotAttributeType 49}
-
-
- singleLevelQuality ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX DataQualitySyntax
- SINGLE VALUE
-
-
- subtreeMinimumQuality ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX DataQualitySyntax
- SINGLE VALUE
- -- Defaults to singleLevelQuality
- ::= {pilotAttributeType 51}
-
-
- subtreeMaximumQuality ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX DataQualitySyntax
- SINGLE VALUE
- -- Defaults to singleLevelQuality
- ::= {pilotAttributeType 52}
-
-
- personalSignature ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- CHOICE {
- g3-facsimile [3] G3FacsimileBodyPart
- }
- (SIZE (1 .. ub-personal-signature))
- ::= {pilotAttributeType 53}
-
-
- dITRedirect ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- distinguishedNameSyntax
- ::= {pilotAttributeType 54}
-
-
- audio ATTRIBUTE
- WITH ATTRIBUTE-SYNTAX
- Audio
- (SIZE (1 .. ub-audio))
- ::= {pilotAttributeType 55}
-
-
-
-Barker & Kille [Page 57]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- documentPublisher ATTRIBUTE
- WITH ATTRIBUTE SYNTAX caseIgnoreStringSyntax
- ::= {pilotAttributeType 56}
-
-
-
- -- Generally useful syntaxes
-
-
- caseIgnoreIA5StringSyntax ATTRIBUTE-SYNTAX
- IA5String
- MATCHES FOR EQUALITY SUBSTRINGS
-
-
- iA5StringSyntax ATTRIBUTE-SYNTAX
- IA5String
- MATCHES FOR EQUALITY SUBSTRINGS
-
-
- -- Syntaxes to support the DNS attributes
-
- DNSRecordSyntax ATTRIBUTE-SYNTAX
- IA5String
- MATCHES FOR EQUALITY
-
-
- NRSInformationSyntax ATTRIBUTE-SYNTAX
- NRSInformation
- MATCHES FOR EQUALITY
-
-
- NRSInformation ::= SET {
- [0] Context,
- [1] Address-space-id,
- routes [2] SEQUENCE OF SEQUENCE {
- Route-cost,
- Addressing-info }
- }
-
-
-
-
-
-
-
-
-
-
-
-
-
-Barker & Kille [Page 58]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
- -- Upper bounds on length of attribute values
-
-
- ub-document-identifier INTEGER ::= 256
-
- ub-document-location INTEGER ::= 256
-
- ub-document-title INTEGER ::= 256
-
- ub-document-version INTEGER ::= 256
-
- ub-favourite-drink INTEGER ::= 256
-
- ub-host INTEGER ::= 256
-
- ub-information INTEGER ::= 2048
-
- ub-unique-identifier INTEGER ::= 256
-
- ub-personal-title INTEGER ::= 256
-
- ub-photo INTEGER ::= 250000
-
- ub-rfc822-mailbox INTEGER ::= 256
-
- ub-room-number INTEGER ::= 256
-
- ub-text-or-address INTEGER ::= 256
-
- ub-user-class INTEGER ::= 256
-
- ub-user-identifier INTEGER ::= 256
-
- ub-organizational-status INTEGER ::= 256
-
- ub-janet-mailbox INTEGER ::= 256
-
- ub-building-name INTEGER ::= 256
-
- ub-personal-signature ::= 50000
-
- ub-audio INTEGER ::= 250000
-
-
-
-
-
-
-
-
-
-Barker & Kille [Page 59]
-
-RFC 1274 COSINE and Internet X.500 Schema November 1991
-
-
-Security Considerations
-
- Security issues are not discussed in this memo.
-
-10. Authors' Addresses
-
- Paul Barker
- Department of Computer Science
- University College London
- Gower Street
- London WC1E 6BT
- England
-
- Phone: +44 71-380-7366
- EMail: P.Barker@cs.ucl.ac.uk
-
-
- Steve Kille
- Department of Computer Science
- University College London
- Gower Street
- London WC1E 6BT
- England
-
- Phone: +44 71-380-7294
- EMail: S.Kille@cs.ucl.ac.uk
-
- Or send comments to the discussion group: <osi-ds@cs.ucl.ac.uk>.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Barker & Kille [Page 60]
-
\ No newline at end of file
diff --git a/doc/rfc/rfc2251.txt b/doc/rfc/rfc2251.txt
deleted file mode 100644
index 88844cbf38b791515ec5a60658f4c3033d942827..0000000000000000000000000000000000000000
--- a/doc/rfc/rfc2251.txt
+++ /dev/null
@@ -1,2803 +0,0 @@
-
-
-
-
-
-
-Network Working Group M. Wahl
-Request for Comments: 2251 Critical Angle Inc.
-Category: Standards Track T. Howes
- Netscape Communications Corp.
- S. Kille
- Isode Limited
- December 1997
-
-
- Lightweight Directory Access Protocol (v3)
-
-1. Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (1997). All Rights Reserved.
-
-IESG Note
-
- This document describes a directory access protocol that provides
- both read and update access. Update access requires secure
- authentication, but this document does not mandate implementation of
- any satisfactory authentication mechanisms.
-
- In accordance with RFC 2026, section 4.4.1, this specification is
- being approved by IESG as a Proposed Standard despite this
- limitation, for the following reasons:
-
- a. to encourage implementation and interoperability testing of
- these protocols (with or without update access) before they
- are deployed, and
-
- b. to encourage deployment and use of these protocols in read-only
- applications. (e.g. applications where LDAPv3 is used as
- a query language for directories which are updated by some
- secure mechanism other than LDAP), and
-
- c. to avoid delaying the advancement and deployment of other Internet
- standards-track protocols which require the ability to query, but
- not update, LDAPv3 directory servers.
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 1]
-
-RFC 2251 LDAPv3 December 1997
-
-
- Readers are hereby warned that until mandatory authentication
- mechanisms are standardized, clients and servers written according to
- this specification which make use of update functionality are
- UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
- IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
-
- Implementors are hereby discouraged from deploying LDAPv3 clients or
- servers which implement the update functionality, until a Proposed
- Standard for mandatory authentication in LDAPv3 has been approved and
- published as an RFC.
-
-Table of Contents
-
- 1. Status of this Memo .................................... 1
- Copyright Notice ....................................... 1
- IESG Note .............................................. 1
- 2. Abstract ............................................... 3
- 3. Models ................................................. 4
- 3.1. Protocol Model ........................................ 4
- 3.2. Data Model ............................................ 5
- 3.2.1. Attributes of Entries ............................... 5
- 3.2.2. Subschema Entries and Subentries .................... 7
- 3.3. Relationship to X.500 ................................. 8
- 3.4. Server-specific Data Requirements ..................... 8
- 4. Elements of Protocol ................................... 9
- 4.1. Common Elements ....................................... 9
- 4.1.1. Message Envelope .................................... 9
- 4.1.1.1. Message ID ........................................ 11
- 4.1.2. String Types ........................................ 11
- 4.1.3. Distinguished Name and Relative Distinguished Name .. 11
- 4.1.4. Attribute Type ...................................... 12
- 4.1.5. Attribute Description ............................... 13
- 4.1.5.1. Binary Option ..................................... 14
- 4.1.6. Attribute Value ..................................... 14
- 4.1.7. Attribute Value Assertion ........................... 15
- 4.1.8. Attribute ........................................... 15
- 4.1.9. Matching Rule Identifier ............................ 15
- 4.1.10. Result Message ..................................... 16
- 4.1.11. Referral ........................................... 18
- 4.1.12. Controls ........................................... 19
- 4.2. Bind Operation ........................................ 20
- 4.2.1. Sequencing of the Bind Request ...................... 21
- 4.2.2. Authentication and Other Security Services .......... 22
- 4.2.3. Bind Response ....................................... 23
- 4.3. Unbind Operation ...................................... 24
- 4.4. Unsolicited Notification .............................. 24
- 4.4.1. Notice of Disconnection ............................. 24
- 4.5. Search Operation ...................................... 25
-
-
-
-Wahl, et. al. Standards Track [Page 2]
-
-RFC 2251 LDAPv3 December 1997
-
-
- 4.5.1. Search Request ...................................... 25
- 4.5.2. Search Result ....................................... 29
- 4.5.3. Continuation References in the Search Result ........ 31
- 4.5.3.1. Example ........................................... 31
- 4.6. Modify Operation ...................................... 32
- 4.7. Add Operation ......................................... 34
- 4.8. Delete Operation ...................................... 35
- 4.9. Modify DN Operation ................................... 36
- 4.10. Compare Operation .................................... 37
- 4.11. Abandon Operation .................................... 38
- 4.12. Extended Operation ................................... 38
- 5. Protocol Element Encodings and Transfer ................ 39
- 5.1. Mapping Onto BER-based Transport Services ............. 39
- 5.2. Transfer Protocols .................................... 40
- 5.2.1. Transmission Control Protocol (TCP) ................. 40
- 6. Implementation Guidelines .............................. 40
- 6.1. Server Implementations ................................ 40
- 6.2. Client Implementations ................................ 40
- 7. Security Considerations ................................ 41
- 8. Acknowledgements ....................................... 41
- 9. Bibliography ........................................... 41
- 10. Authors' Addresses ..................................... 42
- Appendix A - Complete ASN.1 Definition ..................... 44
- Full Copyright Statement ................................... 50
-
-2. Abstract
-
- The protocol described in this document is designed to provide access
- to directories supporting the X.500 models, while not incurring the
- resource requirements of the X.500 Directory Access Protocol (DAP).
- This protocol is specifically targeted at management applications and
- browser applications that provide read/write interactive access to
- directories. When used with a directory supporting the X.500
- protocols, it is intended to be a complement to the X.500 DAP.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document
- are to be interpreted as described in RFC 2119 [10].
-
- Key aspects of this version of LDAP are:
-
- - All protocol elements of LDAPv2 (RFC 1777) are supported. The
- protocol is carried directly over TCP or other transport, bypassing
- much of the session/presentation overhead of X.500 DAP.
-
- - Most protocol data elements can be encoded as ordinary strings
- (e.g., Distinguished Names).
-
-
-
-
-Wahl, et. al. Standards Track [Page 3]
-
-RFC 2251 LDAPv3 December 1997
-
-
- - Referrals to other servers may be returned.
-
- - SASL mechanisms may be used with LDAP to provide association
- security services.
-
- - Attribute values and Distinguished Names have been
- internationalized through the use of the ISO 10646 character set.
-
- - The protocol can be extended to support new operations, and
- controls may be used to extend existing operations.
-
- - Schema is published in the directory for use by clients.
-
-3. Models
-
- Interest in X.500 [1] directory technologies in the Internet has led
- to efforts to reduce the high cost of entry associated with use of
- these technologies. This document continues the efforts to define
- directory protocol alternatives, updating the LDAP [2] protocol
- specification.
-
-3.1. Protocol Model
-
- The general model adopted by this protocol is one of clients
- performing protocol operations against servers. In this model, a
- client transmits a protocol request describing the operation to be
- performed to a server. The server is then responsible for performing
- the necessary operation(s) in the directory. Upon completion of the
- operation(s), the server returns a response containing any results or
- errors to the requesting client.
-
- In keeping with the goal of easing the costs associated with use of
- the directory, it is an objective of this protocol to minimize the
- complexity of clients so as to facilitate widespread deployment of
- applications capable of using the directory.
-
- Note that although servers are required to return responses whenever
- such responses are defined in the protocol, there is no requirement
- for synchronous behavior on the part of either clients or servers.
- Requests and responses for multiple operations may be exchanged
- between a client and server in any order, provided the client
- eventually receives a response for every request that requires one.
-
- In LDAP versions 1 and 2, no provision was made for protocol servers
- returning referrals to clients. However, for improved performance
- and distribution this version of the protocol permits servers to
- return to clients referrals to other servers. This allows servers to
- offload the work of contacting other servers to progress operations.
-
-
-
-Wahl, et. al. Standards Track [Page 4]
-
-RFC 2251 LDAPv3 December 1997
-
-
- Note that the core protocol operations defined in this document can
- be mapped to a strict subset of the X.500(1997) directory abstract
- service, so it can be cleanly provided by the DAP. However there is
- not a one-to-one mapping between LDAP protocol operations and DAP
- operations: server implementations acting as a gateway to X.500
- directories may need to make multiple DAP requests.
-
-3.2. Data Model
-
- This section provides a brief introduction to the X.500 data model,
- as used by LDAP.
-
- The LDAP protocol assumes there are one or more servers which jointly
- provide access to a Directory Information Tree (DIT). The tree is
- made up of entries. Entries have names: one or more attribute values
- from the entry form its relative distinguished name (RDN), which MUST
- be unique among all its siblings. The concatenation of the relative
- distinguished names of the sequence of entries from a particular
- entry to an immediate subordinate of the root of the tree forms that
- entry's Distinguished Name (DN), which is unique in the tree. An
- example of a Distinguished Name is
-
- CN=Steve Kille, O=Isode Limited, C=GB
-
- Some servers may hold cache or shadow copies of entries, which can be
- used to answer search and comparison queries, but will return
- referrals or contact other servers if modification operations are
- requested.
-
- Servers which perform caching or shadowing MUST ensure that they do
- not violate any access control constraints placed on the data by the
- originating server.
-
- The largest collection of entries, starting at an entry that is
- mastered by a particular server, and including all its subordinates
- and their subordinates, down to the entries which are mastered by
- different servers, is termed a naming context. The root of the DIT
- is a DSA-specific Entry (DSE) and not part of any naming context:
- each server has different attribute values in the root DSE. (DSA is
- an X.500 term for the directory server).
-
-3.2.1. Attributes of Entries
-
- Entries consist of a set of attributes. An attribute is a type with
- one or more associated values. The attribute type is identified by a
- short descriptive name and an OID (object identifier). The attribute
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 5]
-
-RFC 2251 LDAPv3 December 1997
-
-
- type governs whether there can be more than one value of an attribute
- of that type in an entry, the syntax to which the values must
- conform, the kinds of matching which can be performed on values of
- that attribute, and other functions.
-
- An example of an attribute is "mail". There may be one or more values
- of this attribute, they must be IA5 (ASCII) strings, and they are
- case insensitive (e.g. "foo@bar.com" will match "FOO@BAR.COM").
-
- Schema is the collection of attribute type definitions, object class
- definitions and other information which a server uses to determine
- how to match a filter or attribute value assertion (in a compare
- operation) against the attributes of an entry, and whether to permit
- add and modify operations. The definition of schema for use with
- LDAP is given in [5] and [6]. Additional schema elements may be
- defined in other documents.
-
- Each entry MUST have an objectClass attribute. The objectClass
- attribute specifies the object classes of an entry, which along with
- the system and user schema determine the permitted attributes of an
- entry. Values of this attribute may be modified by clients, but the
- objectClass attribute cannot be removed. Servers may restrict the
- modifications of this attribute to prevent the basic structural class
- of the entry from being changed (e.g. one cannot change a person into
- a country). When creating an entry or adding an objectClass value to
- an entry, all superclasses of the named classes are implicitly added
- as well if not already present, and the client must supply values for
- any mandatory attributes of new superclasses.
-
- Some attributes, termed operational attributes, are used by servers
- for administering the directory system itself. They are not returned
- in search results unless explicitly requested by name. Attributes
- which are not operational, such as "mail", will have their schema and
- syntax constraints enforced by servers, but servers will generally
- not make use of their values.
-
- Servers MUST NOT permit clients to add attributes to an entry unless
- those attributes are permitted by the object class definitions, the
- schema controlling that entry (specified in the subschema - see
- below), or are operational attributes known to that server and used
- for administrative purposes. Note that there is a particular
- objectClass 'extensibleObject' defined in [5] which permits all user
- attributes to be present in an entry.
-
- Entries MAY contain, among others, the following operational
- attributes, defined in [5]. These attributes are maintained
- automatically by the server and are not modifiable by clients:
-
-
-
-
-Wahl, et. al. Standards Track [Page 6]
-
-RFC 2251 LDAPv3 December 1997
-
-
- - creatorsName: the Distinguished Name of the user who added this
- entry to the directory.
-
- - createTimestamp: the time this entry was added to the directory.
-
- - modifiersName: the Distinguished Name of the user who last modified
- this entry.
-
- - modifyTimestamp: the time this entry was last modified.
-
- - subschemaSubentry: the Distinguished Name of the subschema entry
- (or subentry) which controls the schema for this entry.
-
-3.2.2. Subschema Entries and Subentries
-
- Subschema entries are used for administering information about the
- directory schema, in particular the object classes and attribute
- types supported by directory servers. A single subschema entry
- contains all schema definitions used by entries in a particular part
- of the directory tree.
-
- Servers which follow X.500(93) models SHOULD implement subschema
- using the X.500 subschema mechanisms, and so these subschemas are not
- ordinary entries. LDAP clients SHOULD NOT assume that servers
- implement any of the other aspects of X.500 subschema. A server
- which masters entries and permits clients to modify these entries
- MUST implement and provide access to these subschema entries, so that
- its clients may discover the attributes and object classes which are
- permitted to be present. It is strongly recommended that all other
- servers implement this as well.
-
- The following four attributes MUST be present in all subschema
- entries:
-
- - cn: this attribute MUST be used to form the RDN of the subschema
- entry.
-
- - objectClass: the attribute MUST have at least the values "top" and
- "subschema".
-
- - objectClasses: each value of this attribute specifies an object
- class known to the server.
-
- - attributeTypes: each value of this attribute specifies an attribute
- type known to the server.
-
- These are defined in [5]. Other attributes MAY be present in
- subschema entries, to reflect additional supported capabilities.
-
-
-
-Wahl, et. al. Standards Track [Page 7]
-
-RFC 2251 LDAPv3 December 1997
-
-
- These include matchingRules, matchingRuleUse, dITStructureRules,
- dITContentRules, nameForms and ldapSyntaxes.
-
- Servers SHOULD provide the attributes createTimestamp and
- modifyTimestamp in subschema entries, in order to allow clients to
- maintain their caches of schema information.
-
- Clients MUST only retrieve attributes from a subschema entry by
- requesting a base object search of the entry, where the search filter
- is "(objectClass=subschema)". (This will allow LDAPv3 servers which
- gateway to X.500(93) to detect that subentry information is being
- requested.)
-
-3.3. Relationship to X.500
-
- This document defines LDAP in terms of X.500 as an X.500 access
- mechanism. An LDAP server MUST act in accordance with the
- X.500(1993) series of ITU recommendations when providing the service.
- However, it is not required that an LDAP server make use of any X.500
- protocols in providing this service, e.g. LDAP can be mapped onto any
- other directory system so long as the X.500 data and service model as
- used in LDAP is not violated in the LDAP interface.
-
-3.4. Server-specific Data Requirements
-
- An LDAP server MUST provide information about itself and other
- information that is specific to each server. This is represented as
- a group of attributes located in the root DSE (DSA-Specific Entry),
- which is named with the zero-length LDAPDN. These attributes are
- retrievable if a client performs a base object search of the root
- with filter "(objectClass=*)", however they are subject to access
- control restrictions. The root DSE MUST NOT be included if the
- client performs a subtree search starting from the root.
-
- Servers may allow clients to modify these attributes.
-
- The following attributes of the root DSE are defined in section 5 of
- [5]. Additional attributes may be defined in other documents.
-
- - namingContexts: naming contexts held in the server. Naming contexts
- are defined in section 17 of X.501 [6].
-
- - subschemaSubentry: subschema entries (or subentries) known by this
- server.
-
- - altServer: alternative servers in case this one is later
- unavailable.
-
-
-
-
-Wahl, et. al. Standards Track [Page 8]
-
-RFC 2251 LDAPv3 December 1997
-
-
- - supportedExtension: list of supported extended operations.
-
- - supportedControl: list of supported controls.
-
- - supportedSASLMechanisms: list of supported SASL security features.
-
- - supportedLDAPVersion: LDAP versions implemented by the server.
-
- If the server does not master entries and does not know the locations
- of schema information, the subschemaSubentry attribute is not present
- in the root DSE. If the server masters directory entries under one
- or more schema rules, there may be any number of values of the
- subschemaSubentry attribute in the root DSE.
-
-4. Elements of Protocol
-
- The LDAP protocol is described using Abstract Syntax Notation 1
- (ASN.1) [3], and is typically transferred using a subset of ASN.1
- Basic Encoding Rules [11]. In order to support future extensions to
- this protocol, clients and servers MUST ignore elements of SEQUENCE
- encodings whose tags they do not recognize.
-
- Note that unlike X.500, each change to the LDAP protocol other than
- through the extension mechanisms will have a different version
- number. A client will indicate the version it supports as part of
- the bind request, described in section 4.2. If a client has not sent
- a bind, the server MUST assume that version 3 is supported in the
- client (since version 2 required that the client bind first).
-
- Clients may determine the protocol version a server supports by
- reading the supportedLDAPVersion attribute from the root DSE. Servers
- which implement version 3 or later versions MUST provide this
- attribute. Servers which only implement version 2 may not provide
- this attribute.
-
-4.1. Common Elements
-
- This section describes the LDAPMessage envelope PDU (Protocol Data
- Unit) format, as well as data type definitions which are used in the
- protocol operations.
-
-4.1.1. Message Envelope
-
- For the purposes of protocol exchanges, all protocol operations are
- encapsulated in a common envelope, the LDAPMessage, which is defined
- as follows:
-
- LDAPMessage ::= SEQUENCE {
-
-
-
-Wahl, et. al. Standards Track [Page 9]
-
-RFC 2251 LDAPv3 December 1997
-
-
- messageID MessageID,
- protocolOp CHOICE {
- bindRequest BindRequest,
- bindResponse BindResponse,
- unbindRequest UnbindRequest,
- searchRequest SearchRequest,
- searchResEntry SearchResultEntry,
- searchResDone SearchResultDone,
- searchResRef SearchResultReference,
- modifyRequest ModifyRequest,
- modifyResponse ModifyResponse,
- addRequest AddRequest,
- addResponse AddResponse,
- delRequest DelRequest,
- delResponse DelResponse,
- modDNRequest ModifyDNRequest,
- modDNResponse ModifyDNResponse,
- compareRequest CompareRequest,
- compareResponse CompareResponse,
- abandonRequest AbandonRequest,
- extendedReq ExtendedRequest,
- extendedResp ExtendedResponse },
- controls [0] Controls OPTIONAL }
-
- MessageID ::= INTEGER (0 .. maxInt)
-
- maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
-
- The function of the LDAPMessage is to provide an envelope containing
- common fields required in all protocol exchanges. At this time the
- only common fields are the message ID and the controls.
-
- If the server receives a PDU from the client in which the LDAPMessage
- SEQUENCE tag cannot be recognized, the messageID cannot be parsed,
- the tag of the protocolOp is not recognized as a request, or the
- encoding structures or lengths of data fields are found to be
- incorrect, then the server MUST return the notice of disconnection
- described in section 4.4.1, with resultCode protocolError, and
- immediately close the connection. In other cases that the server
- cannot parse the request received by the client, the server MUST
- return an appropriate response to the request, with the resultCode
- set to protocolError.
-
- If the client receives a PDU from the server which cannot be parsed,
- the client may discard the PDU, or may abruptly close the connection.
-
- The ASN.1 type Controls is defined in section 4.1.12.
-
-
-
-
-Wahl, et. al. Standards Track [Page 10]
-
-RFC 2251 LDAPv3 December 1997
-
-
-4.1.1.1. Message ID
-
- All LDAPMessage envelopes encapsulating responses contain the
- messageID value of the corresponding request LDAPMessage.
-
- The message ID of a request MUST have a value different from the
- values of any other requests outstanding in the LDAP session of which
- this message is a part.
-
- A client MUST NOT send a second request with the same message ID as
- an earlier request on the same connection if the client has not
- received the final response from the earlier request. Otherwise the
- behavior is undefined. Typical clients increment a counter for each
- request.
-
- A client MUST NOT reuse the message id of an abandonRequest or of the
- abandoned operation until it has received a response from the server
- for another request invoked subsequent to the abandonRequest, as the
- abandonRequest itself does not have a response.
-
-4.1.2. String Types
-
- The LDAPString is a notational convenience to indicate that, although
- strings of LDAPString type encode as OCTET STRING types, the ISO
- 10646 [13] character set (a superset of Unicode) is used, encoded
- following the UTF-8 algorithm [14]. Note that in the UTF-8 algorithm
- characters which are the same as ASCII (0x0000 through 0x007F) are
- represented as that same ASCII character in a single byte. The other
- byte values are used to form a variable-length encoding of an
- arbitrary character.
-
- LDAPString ::= OCTET STRING
-
- The LDAPOID is a notational convenience to indicate that the
- permitted value of this string is a (UTF-8 encoded) dotted-decimal
- representation of an OBJECT IDENTIFIER.
-
- LDAPOID ::= OCTET STRING
-
- For example,
-
- 1.3.6.1.4.1.1466.1.2.3
-
-4.1.3. Distinguished Name and Relative Distinguished Name
-
- An LDAPDN and a RelativeLDAPDN are respectively defined to be the
- representation of a Distinguished Name and a Relative Distinguished
- Name after encoding according to the specification in [4], such that
-
-
-
-Wahl, et. al. Standards Track [Page 11]
-
-RFC 2251 LDAPv3 December 1997
-
-
- <distinguished-name> ::= <name>
-
- <relative-distinguished-name> ::= <name-component>
-
- where <name> and <name-component> are as defined in [4].
-
- LDAPDN ::= LDAPString
-
- RelativeLDAPDN ::= LDAPString
-
- Only Attribute Types can be present in a relative distinguished name
- component; the options of Attribute Descriptions (next section) MUST
- NOT be used in specifying distinguished names.
-
-4.1.4. Attribute Type
-
- An AttributeType takes on as its value the textual string associated
- with that AttributeType in its specification.
-
- AttributeType ::= LDAPString
-
- Each attribute type has a unique OBJECT IDENTIFIER which has been
- assigned to it. This identifier may be written as decimal digits
- with components separated by periods, e.g. "2.5.4.10".
-
- A specification may also assign one or more textual names for an
- attribute type. These names MUST begin with a letter, and only
- contain ASCII letters, digit characters and hyphens. They are case
- insensitive. (These ASCII characters are identical to ISO 10646
- characters whose UTF-8 encoding is a single byte between 0x00 and
- 0x7F.)
-
- If the server has a textual name for an attribute type, it MUST use a
- textual name for attributes returned in search results. The dotted-
- decimal OBJECT IDENTIFIER is only used if there is no textual name
- for an attribute type.
-
- Attribute type textual names are non-unique, as two different
- specifications (neither in standards track RFCs) may choose the same
- name.
-
- A server which masters or shadows entries SHOULD list all the
- attribute types it supports in the subschema entries, using the
- attributeTypes attribute. Servers which support an open-ended set of
- attributes SHOULD include at least the attributeTypes value for the
- 'objectClass' attribute. Clients MAY retrieve the attributeTypes
- value from subschema entries in order to obtain the OBJECT IDENTIFIER
- and other information associated with attribute types.
-
-
-
-Wahl, et. al. Standards Track [Page 12]
-
-RFC 2251 LDAPv3 December 1997
-
-
- Some attribute type names which are used in this version of LDAP are
- described in [5]. Servers may implement additional attribute types.
-
-4.1.5. Attribute Description
-
- An AttributeDescription is a superset of the definition of the
- AttributeType. It has the same ASN.1 definition, but allows
- additional options to be specified. They are also case insensitive.
-
- AttributeDescription ::= LDAPString
-
- A value of AttributeDescription is based on the following BNF:
-
- <AttributeDescription> ::= <AttributeType> [ ";" <options> ]
-
- <options> ::= <option> | <option> ";" <options>
-
- <option> ::= <opt-char> <opt-char>*
-
- <opt-char> ::= ASCII-equivalent letters, numbers and hyphen
-
- Examples of valid AttributeDescription:
-
- cn
- userCertificate;binary
-
- One option, "binary", is defined in this document. Additional
- options may be defined in IETF standards-track and experimental RFCs.
- Options beginning with "x-" are reserved for private experiments.
- Any option could be associated with any AttributeType, although not
- all combinations may be supported by a server.
-
- An AttributeDescription with one or more options is treated as a
- subtype of the attribute type without any options. Options present
- in an AttributeDescription are never mutually exclusive.
- Implementations MUST generate the <options> list sorted in ascending
- order, and servers MUST treat any two AttributeDescription with the
- same AttributeType and options as equivalent. A server will treat an
- AttributeDescription with any options it does not implement as an
- unrecognized attribute type.
-
- The data type "AttributeDescriptionList" describes a list of 0 or
- more attribute types. (A list of zero elements has special
- significance in the Search request.)
-
- AttributeDescriptionList ::= SEQUENCE OF
- AttributeDescription
-
-
-
-
-Wahl, et. al. Standards Track [Page 13]
-
-RFC 2251 LDAPv3 December 1997
-
-
-4.1.5.1. Binary Option
-
- If the "binary" option is present in an AttributeDescription, it
- overrides any string-based encoding representation defined for that
- attribute in [5]. Instead the attribute is to be transferred as a
- binary value encoded using the Basic Encoding Rules [11]. The syntax
- of the binary value is an ASN.1 data type definition which is
- referenced by the "SYNTAX" part of the attribute type definition.
-
- The presence or absence of the "binary" option only affects the
- transfer of attribute values in protocol; servers store any
- particular attribute in a single format. If a client requests that a
- server return an attribute in the binary format, but the server
- cannot generate that format, the server MUST treat this attribute
- type as an unrecognized attribute type. Similarly, clients MUST NOT
- expect servers to return an attribute in binary format if the client
- requested that attribute by name without the binary option.
-
- This option is intended to be used with attributes whose syntax is a
- complex ASN.1 data type, and the structure of values of that type is
- needed by clients. Examples of this kind of syntax are "Certificate"
- and "CertificateList".
-
-4.1.6. Attribute Value
-
- A field of type AttributeValue takes on as its value either a string
- encoding of a AttributeValue data type, or an OCTET STRING containing
- an encoded binary value, depending on whether the "binary" option is
- present in the companion AttributeDescription to this AttributeValue.
-
- The definition of string encodings for different syntaxes and types
- may be found in other documents, and in particular [5].
-
- AttributeValue ::= OCTET STRING
-
- Note that there is no defined limit on the size of this encoding;
- thus protocol values may include multi-megabyte attributes (e.g.
- photographs).
-
- Attributes may be defined which have arbitrary and non-printable
- syntax. Implementations MUST NEITHER simply display nor attempt to
- decode as ASN.1 a value if its syntax is not known. The
- implementation may attempt to discover the subschema of the source
- entry, and retrieve the values of attributeTypes from it.
-
- Clients MUST NOT send attribute values in a request which are not
- valid according to the syntax defined for the attributes.
-
-
-
-
-Wahl, et. al. Standards Track [Page 14]
-
-RFC 2251 LDAPv3 December 1997
-
-
-4.1.7. Attribute Value Assertion
-
- The AttributeValueAssertion type definition is similar to the one in
- the X.500 directory standards. It contains an attribute description
- and a matching rule assertion value suitable for that type.
-
- AttributeValueAssertion ::= SEQUENCE {
- attributeDesc AttributeDescription,
- assertionValue AssertionValue }
-
- AssertionValue ::= OCTET STRING
-
- If the "binary" option is present in attributeDesc, this signals to
- the server that the assertionValue is a binary encoding of the
- assertion value.
-
- For all the string-valued user attributes described in [5], the
- assertion value syntax is the same as the value syntax. Clients may
- use attribute values as assertion values in compare requests and
- search filters.
-
- Note however that the assertion syntax may be different from the
- value syntax for other attributes or for non-equality matching rules.
- These may have an assertion syntax which contains only part of the
- value. See section 20.2.1.8 of X.501 [6] for examples.
-
-4.1.8. Attribute
-
- An attribute consists of a type and one or more values of that type.
- (Though attributes MUST have at least one value when stored, due to
- access control restrictions the set may be empty when transferred in
- protocol. This is described in section 4.5.2, concerning the
- PartialAttributeList type.)
-
- Attribute ::= SEQUENCE {
- type AttributeDescription,
- vals SET OF AttributeValue }
-
- Each attribute value is distinct in the set (no duplicates). The
- order of attribute values within the vals set is undefined and
- implementation-dependent, and MUST NOT be relied upon.
-
-4.1.9. Matching Rule Identifier
-
- A matching rule is a means of expressing how a server should compare
- an AssertionValue received in a search filter with an abstract data
- value. The matching rule defines the syntax of the assertion value
- and the process to be performed in the server.
-
-
-
-Wahl, et. al. Standards Track [Page 15]
-
-RFC 2251 LDAPv3 December 1997
-
-
- An X.501(1993) Matching Rule is identified in the LDAP protocol by
- the printable representation of its OBJECT IDENTIFIER, either as one
- of the strings given in [5], or as decimal digits with components
- separated by periods, e.g. "caseIgnoreIA5Match" or
- "1.3.6.1.4.1.453.33.33".
-
- MatchingRuleId ::= LDAPString
-
- Servers which support matching rules for use in the extensibleMatch
- search filter MUST list the matching rules they implement in
- subschema entries, using the matchingRules attributes. The server
- SHOULD also list there, using the matchingRuleUse attribute, the
- attribute types with which each matching rule can be used. More
- information is given in section 4.4 of [5].
-
-4.1.10. Result Message
-
- The LDAPResult is the construct used in this protocol to return
- success or failure indications from servers to clients. In response
- to various requests servers will return responses containing fields
- of type LDAPResult to indicate the final status of a protocol
- operation request.
-
- LDAPResult ::= SEQUENCE {
- resultCode ENUMERATED {
- success (0),
- operationsError (1),
- protocolError (2),
- timeLimitExceeded (3),
- sizeLimitExceeded (4),
- compareFalse (5),
- compareTrue (6),
-
- authMethodNotSupported (7),
- strongAuthRequired (8),
- -- 9 reserved --
- referral (10), -- new
- adminLimitExceeded (11), -- new
- unavailableCriticalExtension (12), -- new
- confidentialityRequired (13), -- new
- saslBindInProgress (14), -- new
- noSuchAttribute (16),
- undefinedAttributeType (17),
- inappropriateMatching (18),
- constraintViolation (19),
- attributeOrValueExists (20),
- invalidAttributeSyntax (21),
- -- 22-31 unused --
-
-
-
-Wahl, et. al. Standards Track [Page 16]
-
-RFC 2251 LDAPv3 December 1997
-
-
- noSuchObject (32),
- aliasProblem (33),
- invalidDNSyntax (34),
- -- 35 reserved for undefined isLeaf --
- aliasDereferencingProblem (36),
- -- 37-47 unused --
- inappropriateAuthentication (48),
- invalidCredentials (49),
- insufficientAccessRights (50),
- busy (51),
- unavailable (52),
- unwillingToPerform (53),
- loopDetect (54),
- -- 55-63 unused --
- namingViolation (64),
- objectClassViolation (65),
- notAllowedOnNonLeaf (66),
- notAllowedOnRDN (67),
- entryAlreadyExists (68),
- objectClassModsProhibited (69),
- -- 70 reserved for CLDAP --
- affectsMultipleDSAs (71), -- new
- -- 72-79 unused --
- other (80) },
- -- 81-90 reserved for APIs --
- matchedDN LDAPDN,
- errorMessage LDAPString,
- referral [3] Referral OPTIONAL }
-
- All the result codes with the exception of success, compareFalse and
- compareTrue are to be treated as meaning the operation could not be
- completed in its entirety.
-
- Most of the result codes are based on problem indications from X.511
- error data types. Result codes from 16 to 21 indicate an
- AttributeProblem, codes 32, 33, 34 and 36 indicate a NameProblem,
- codes 48, 49 and 50 indicate a SecurityProblem, codes 51 to 54
- indicate a ServiceProblem, and codes 64 to 69 and 71 indicates an
- UpdateProblem.
-
- If a client receives a result code which is not listed above, it is
- to be treated as an unknown error condition.
-
- The errorMessage field of this construct may, at the server's option,
- be used to return a string containing a textual, human-readable
- (terminal control and page formatting characters should be avoided)
- error diagnostic. As this error diagnostic is not standardized,
-
-
-
-
-Wahl, et. al. Standards Track [Page 17]
-
-RFC 2251 LDAPv3 December 1997
-
-
- implementations MUST NOT rely on the values returned. If the server
- chooses not to return a textual diagnostic, the errorMessage field of
- the LDAPResult type MUST contain a zero length string.
-
- For result codes of noSuchObject, aliasProblem, invalidDNSyntax and
- aliasDereferencingProblem, the matchedDN field is set to the name of
- the lowest entry (object or alias) in the directory that was matched.
- If no aliases were dereferenced while attempting to locate the entry,
- this will be a truncated form of the name provided, or if aliases
- were dereferenced, of the resulting name, as defined in section 12.5
- of X.511 [8]. The matchedDN field is to be set to a zero length
- string with all other result codes.
-
-4.1.11. Referral
-
- The referral error indicates that the contacted server does not hold
- the target entry of the request. The referral field is present in an
- LDAPResult if the LDAPResult.resultCode field value is referral, and
- absent with all other result codes. It contains a reference to
- another server (or set of servers) which may be accessed via LDAP or
- other protocols. Referrals can be returned in response to any
- operation request (except unbind and abandon which do not have
- responses). At least one URL MUST be present in the Referral.
-
- The referral is not returned for a singleLevel or wholeSubtree search
- in which the search scope spans multiple naming contexts, and several
- different servers would need to be contacted to complete the
- operation. Instead, continuation references, described in section
- 4.5.3, are returned.
-
- Referral ::= SEQUENCE OF LDAPURL -- one or more
-
- LDAPURL ::= LDAPString -- limited to characters permitted in URLs
-
- If the client wishes to progress the operation, it MUST follow the
- referral by contacting any one of servers. All the URLs MUST be
- equally capable of being used to progress the operation. (The
- mechanisms for how this is achieved by multiple servers are outside
- the scope of this document.)
-
- URLs for servers implementing the LDAP protocol are written according
- to [9]. If an alias was dereferenced, the <dn> part of the URL MUST
- be present, with the new target object name. If the <dn> part is
- present, the client MUST use this name in its next request to
- progress the operation, and if it is not present the client will use
- the same name as in the original request. Some servers (e.g.
- participating in distributed indexing) may provide a different filter
- in a referral for a search operation. If the filter part of the URL
-
-
-
-Wahl, et. al. Standards Track [Page 18]
-
-RFC 2251 LDAPv3 December 1997
-
-
- is present in an LDAPURL, the client MUST use this filter in its next
- request to progress this search, and if it is not present the client
- MUST use the same filter as it used for that search. Other aspects
- of the new request may be the same or different as the request which
- generated the referral.
-
- Note that UTF-8 characters appearing in a DN or search filter may not
- be legal for URLs (e.g. spaces) and MUST be escaped using the %
- method in RFC 1738 [7].
-
- Other kinds of URLs may be returned, so long as the operation could
- be performed using that protocol.
-
-4.1.12. Controls
-
- A control is a way to specify extension information. Controls which
- are sent as part of a request apply only to that request and are not
- saved.
-
- Controls ::= SEQUENCE OF Control
-
- Control ::= SEQUENCE {
- controlType LDAPOID,
- criticality BOOLEAN DEFAULT FALSE,
- controlValue OCTET STRING OPTIONAL }
-
- The controlType field MUST be a UTF-8 encoded dotted-decimal
- representation of an OBJECT IDENTIFIER which uniquely identifies the
- control. This prevents conflicts between control names.
-
- The criticality field is either TRUE or FALSE.
-
- If the server recognizes the control type and it is appropriate for
- the operation, the server will make use of the control when
- performing the operation.
-
- If the server does not recognize the control type and the criticality
- field is TRUE, the server MUST NOT perform the operation, and MUST
- instead return the resultCode unsupportedCriticalExtension.
-
- If the control is not appropriate for the operation and criticality
- field is TRUE, the server MUST NOT perform the operation, and MUST
- instead return the resultCode unsupportedCriticalExtension.
-
- If the control is unrecognized or inappropriate but the criticality
- field is FALSE, the server MUST ignore the control.
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 19]
-
-RFC 2251 LDAPv3 December 1997
-
-
- The controlValue contains any information associated with the
- control, and its format is defined for the control. The server MUST
- be prepared to handle arbitrary contents of the controlValue octet
- string, including zero bytes. It is absent only if there is no value
- information which is associated with a control of its type.
-
- This document does not define any controls. Controls may be defined
- in other documents. The definition of a control consists of:
-
- - the OBJECT IDENTIFIER assigned to the control,
-
- - whether the control is always noncritical, always critical, or
- critical at the client's option,
-
- - the format of the controlValue contents of the control.
-
- Servers list the controls which they recognize in the
- supportedControl attribute in the root DSE.
-
-4.2. Bind Operation
-
- The function of the Bind Operation is to allow authentication
- information to be exchanged between the client and server.
-
- The Bind Request is defined as follows:
-
- BindRequest ::= [APPLICATION 0] SEQUENCE {
- version INTEGER (1 .. 127),
- name LDAPDN,
- authentication AuthenticationChoice }
-
- AuthenticationChoice ::= CHOICE {
- simple [0] OCTET STRING,
- -- 1 and 2 reserved
- sasl [3] SaslCredentials }
-
- SaslCredentials ::= SEQUENCE {
- mechanism LDAPString,
- credentials OCTET STRING OPTIONAL }
-
- Parameters of the Bind Request are:
-
- - version: A version number indicating the version of the protocol to
- be used in this protocol session. This document describes version
- 3 of the LDAP protocol. Note that there is no version negotiation,
- and the client just sets this parameter to the version it desires.
- If the client requests protocol version 2, a server that supports
- the version 2 protocol as described in [2] will not return any v3-
-
-
-
-Wahl, et. al. Standards Track [Page 20]
-
-RFC 2251 LDAPv3 December 1997
-
-
- specific protocol fields. (Note that not all LDAP servers will
- support protocol version 2, since they may be unable to generate
- the attribute syntaxes associated with version 2.)
-
- - name: The name of the directory object that the client wishes to
- bind as. This field may take on a null value (a zero length
- string) for the purposes of anonymous binds, when authentication
- has been performed at a lower layer, or when using SASL credentials
- with a mechanism that includes the LDAPDN in the credentials.
-
- - authentication: information used to authenticate the name, if any,
- provided in the Bind Request.
-
- Upon receipt of a Bind Request, a protocol server will authenticate
- the requesting client, if necessary. The server will then return a
- Bind Response to the client indicating the status of the
- authentication.
-
- Authorization is the use of this authentication information when
- performing operations. Authorization MAY be affected by factors
- outside of the LDAP Bind request, such as lower layer security
- services.
-
-4.2.1. Sequencing of the Bind Request
-
- For some SASL authentication mechanisms, it may be necessary for the
- client to invoke the BindRequest multiple times. If at any stage the
- client wishes to abort the bind process it MAY unbind and then drop
- the underlying connection. Clients MUST NOT invoke operations
- between two Bind requests made as part of a multi-stage bind.
-
- A client may abort a SASL bind negotiation by sending a BindRequest
- with a different value in the mechanism field of SaslCredentials, or
- an AuthenticationChoice other than sasl.
-
- If the client sends a BindRequest with the sasl mechanism field as an
- empty string, the server MUST return a BindResponse with
- authMethodNotSupported as the resultCode. This will allow clients to
- abort a negotiation if it wishes to try again with the same SASL
- mechanism.
-
- Unlike LDAP v2, the client need not send a Bind Request in the first
- PDU of the connection. The client may request any operations and the
- server MUST treat these as unauthenticated. If the server requires
- that the client bind before browsing or modifying the directory, the
- server MAY reject a request other than binding, unbinding or an
- extended request with the "operationsError" result.
-
-
-
-
-Wahl, et. al. Standards Track [Page 21]
-
-RFC 2251 LDAPv3 December 1997
-
-
- If the client did not bind before sending a request and receives an
- operationsError, it may then send a Bind Request. If this also fails
- or the client chooses not to bind on the existing connection, it will
- close the connection, reopen it and begin again by first sending a
- PDU with a Bind Request. This will aid in interoperating with
- servers implementing other versions of LDAP.
-
- Clients MAY send multiple bind requests on a connection to change
- their credentials. A subsequent bind process has the effect of
- abandoning all operations outstanding on the connection. (This
- simplifies server implementation.) Authentication from earlier binds
- are subsequently ignored, and so if the bind fails, the connection
- will be treated as anonymous. If a SASL transfer encryption or
- integrity mechanism has been negotiated, and that mechanism does not
- support the changing of credentials from one identity to another,
- then the client MUST instead establish a new connection.
-
-4.2.2. Authentication and Other Security Services
-
- The simple authentication option provides minimal authentication
- facilities, with the contents of the authentication field consisting
- only of a cleartext password. Note that the use of cleartext
- passwords is not recommended over open networks when there is no
- authentication or encryption being performed by a lower layer; see
- the "Security Considerations" section.
-
- If no authentication is to be performed, then the simple
- authentication option MUST be chosen, and the password be of zero
- length. (This is often done by LDAPv2 clients.) Typically the DN is
- also of zero length.
-
- The sasl choice allows for any mechanism defined for use with SASL
- [12]. The mechanism field contains the name of the mechanism. The
- credentials field contains the arbitrary data used for
- authentication, inside an OCTET STRING wrapper. Note that unlike
- some Internet application protocols where SASL is used, LDAP is not
- text-based, thus no base64 transformations are performed on the
- credentials.
-
- If any SASL-based integrity or confidentiality services are enabled,
- they take effect following the transmission by the server and
- reception by the client of the final BindResponse with resultCode
- success.
-
- The client can request that the server use authentication information
- from a lower layer protocol by using the SASL EXTERNAL mechanism.
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 22]
-
-RFC 2251 LDAPv3 December 1997
-
-
-4.2.3. Bind Response
-
- The Bind Response is defined as follows.
-
- BindResponse ::= [APPLICATION 1] SEQUENCE {
- COMPONENTS OF LDAPResult,
- serverSaslCreds [7] OCTET STRING OPTIONAL }
-
- BindResponse consists simply of an indication from the server of he
- status of the client's request for authentication.
-
- f the bind was successful, the resultCode will be success, therwise
- it will be one of:
-
- - operationsError: server encountered an internal error,
-
- - protocolError: unrecognized version number or incorrect PDU
- structure,
-
- - authMethodNotSupported: unrecognized SASL mechanism name,
-
- - strongAuthRequired: the server requires authentication be
- performed with a SASL mechanism,
-
- - referral: this server cannot accept this bind and the client
- should try another,
-
- - saslBindInProgress: the server requires the client to send a
- new bind request, with the same sasl mechanism, to continue the
- authentication process,
-
- - inappropriateAuthentication: the server requires the client
- which had attempted to bind anonymously or without supplying
- credentials to provide some form of credentials,
-
- - invalidCredentials: the wrong password was supplied or the SASL
- credentials could not be processed,
-
- - unavailable: the server is shutting down.
-
- If the server does not support the client's requested protocol
- version, it MUST set the resultCode to protocolError.
-
- If the client receives a BindResponse response where the resultCode
- was protocolError, it MUST close the connection as the server will be
- unwilling to accept further operations. (This is for compatibility
- with earlier versions of LDAP, in which the bind was always the first
- operation, and there was no negotiation.)
-
-
-
-Wahl, et. al. Standards Track [Page 23]
-
-RFC 2251 LDAPv3 December 1997
-
-
- The serverSaslCreds are used as part of a SASL-defined bind mechanism
- to allow the client to authenticate the server to which it is
- communicating, or to perform "challenge-response" authentication. If
- the client bound with the password choice, or the SASL mechanism does
- not require the server to return information to the client, then this
- field is not to be included in the result.
-
-4.3. Unbind Operation
-
- The function of the Unbind Operation is to terminate a protocol
- session. The Unbind Operation is defined as follows:
-
- UnbindRequest ::= [APPLICATION 2] NULL
-
- The Unbind Operation has no response defined. Upon transmission of an
- UnbindRequest, a protocol client may assume that the protocol session
- is terminated. Upon receipt of an UnbindRequest, a protocol server
- may assume that the requesting client has terminated the session and
- that all outstanding requests may be discarded, and may close the
- connection.
-
-4.4. Unsolicited Notification
-
- An unsolicited notification is an LDAPMessage sent from the server to
- the client which is not in response to any LDAPMessage received by
- the server. It is used to signal an extraordinary condition in the
- server or in the connection between the client and the server. The
- notification is of an advisory nature, and the server will not expect
- any response to be returned from the client.
-
- The unsolicited notification is structured as an LDAPMessage in which
- the messageID is 0 and protocolOp is of the extendedResp form. The
- responseName field of the ExtendedResponse is present. The LDAPOID
- value MUST be unique for this notification, and not be used in any
- other situation.
-
- One unsolicited notification is defined in this document.
-
-4.4.1. Notice of Disconnection
-
- This notification may be used by the server to advise the client that
- the server is about to close the connection due to an error
- condition. Note that this notification is NOT a response to an
- unbind requested by the client: the server MUST follow the procedures
- of section 4.3. This notification is intended to assist clients in
- distinguishing between an error condition and a transient network
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 24]
-
-RFC 2251 LDAPv3 December 1997
-
-
- failure. As with a connection close due to network failure, the
- client MUST NOT assume that any outstanding requests which modified
- the directory have succeeded or failed.
-
- The responseName is 1.3.6.1.4.1.1466.20036, the response field is
- absent, and the resultCode is used to indicate the reason for the
- disconnection.
-
- The following resultCode values are to be used in this notification:
-
- - protocolError: The server has received data from the client in
- which
- the LDAPMessage structure could not be parsed.
-
- - strongAuthRequired: The server has detected that an established
- underlying security association protecting communication between
- the client and server has unexpectedly failed or been compromised.
-
- - unavailable: This server will stop accepting new connections and
- operations on all existing connections, and be unavailable for an
- extended period of time. The client may make use of an alternative
- server.
-
- After sending this notice, the server MUST close the connection.
- After receiving this notice, the client MUST NOT transmit any further
- on the connection, and may abruptly close the connection.
-
-4.5. Search Operation
-
- The Search Operation allows a client to request that a search be
- performed on its behalf by a server. This can be used to read
- attributes from a single entry, from entries immediately below a
- particular entry, or a whole subtree of entries.
-
-4.5.1. Search Request
-
- The Search Request is defined as follows:
-
- SearchRequest ::= [APPLICATION 3] SEQUENCE {
- baseObject LDAPDN,
- scope ENUMERATED {
- baseObject (0),
- singleLevel (1),
- wholeSubtree (2) },
- derefAliases ENUMERATED {
- neverDerefAliases (0),
- derefInSearching (1),
- derefFindingBaseObj (2),
-
-
-
-Wahl, et. al. Standards Track [Page 25]
-
-RFC 2251 LDAPv3 December 1997
-
-
- derefAlways (3) },
- sizeLimit INTEGER (0 .. maxInt),
- timeLimit INTEGER (0 .. maxInt),
- typesOnly BOOLEAN,
- filter Filter,
- attributes AttributeDescriptionList }
-
- Filter ::= CHOICE {
- and [0] SET OF Filter,
- or [1] SET OF Filter,
- not [2] Filter,
- equalityMatch [3] AttributeValueAssertion,
- substrings [4] SubstringFilter,
- greaterOrEqual [5] AttributeValueAssertion,
- lessOrEqual [6] AttributeValueAssertion,
- present [7] AttributeDescription,
- approxMatch [8] AttributeValueAssertion,
- extensibleMatch [9] MatchingRuleAssertion }
-
- SubstringFilter ::= SEQUENCE {
- type AttributeDescription,
- -- at least one must be present
- substrings SEQUENCE OF CHOICE {
- initial [0] LDAPString,
- any [1] LDAPString,
- final [2] LDAPString } }
-
- MatchingRuleAssertion ::= SEQUENCE {
- matchingRule [1] MatchingRuleId OPTIONAL,
- type [2] AttributeDescription OPTIONAL,
- matchValue [3] AssertionValue,
- dnAttributes [4] BOOLEAN DEFAULT FALSE }
-
- Parameters of the Search Request are:
-
- - baseObject: An LDAPDN that is the base object entry relative to
- which the search is to be performed.
-
- - scope: An indicator of the scope of the search to be performed. The
- semantics of the possible values of this field are identical to the
- semantics of the scope field in the X.511 Search Operation.
-
- - derefAliases: An indicator as to how alias objects (as defined in
- X.501) are to be handled in searching. The semantics of the
- possible values of this field are:
-
- neverDerefAliases: do not dereference aliases in searching
- or in locating the base object of the search;
-
-
-
-Wahl, et. al. Standards Track [Page 26]
-
-RFC 2251 LDAPv3 December 1997
-
-
- derefInSearching: dereference aliases in subordinates of
- the base object in searching, but not in locating the
- base object of the search;
-
- derefFindingBaseObj: dereference aliases in locating
- the base object of the search, but not when searching
- subordinates of the base object;
-
- derefAlways: dereference aliases both in searching and in
- locating the base object of the search.
-
- - sizelimit: A sizelimit that restricts the maximum number of entries
- to be returned as a result of the search. A value of 0 in this
- field indicates that no client-requested sizelimit restrictions are
- in effect for the search. Servers may enforce a maximum number of
- entries to return.
-
- - timelimit: A timelimit that restricts the maximum time (in seconds)
- allowed for a search. A value of 0 in this field indicates that no
- client-requested timelimit restrictions are in effect for the
- search.
-
- - typesOnly: An indicator as to whether search results will contain
- both attribute types and values, or just attribute types. Setting
- this field to TRUE causes only attribute types (no values) to be
- returned. Setting this field to FALSE causes both attribute types
- and values to be returned.
-
- - filter: A filter that defines the conditions that must be fulfilled
- in order for the search to match a given entry.
-
- The 'and', 'or' and 'not' choices can be used to form combinations of
- filters. At least one filter element MUST be present in an 'and' or
- 'or' choice. The others match against individual attribute values of
- entries in the scope of the search. (Implementor's note: the 'not'
- filter is an example of a tagged choice in an implicitly-tagged
- module. In BER this is treated as if the tag was explicit.)
-
- A server MUST evaluate filters according to the three-valued logic
- of X.511(93) section 7.8.1. In summary, a filter is evaluated to
- either "TRUE", "FALSE" or "Undefined". If the filter evaluates
- to TRUE for a particular entry, then the attributes of that entry
- are returned as part of the search result (subject to any applicable
- access control restrictions). If the filter evaluates to FALSE or
- Undefined, then the entry is ignored for the search.
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 27]
-
-RFC 2251 LDAPv3 December 1997
-
-
- A filter of the "and" choice is TRUE if all the filters in the SET
- OF evaluate to TRUE, FALSE if at least one filter is FALSE, and
- otherwise Undefined. A filter of the "or" choice is FALSE if all
- of the filters in the SET OF evaluate to FALSE, TRUE if at least
- one filter is TRUE, and Undefined otherwise. A filter of the "not"
- choice is TRUE if the filter being negated is FALSE, FALSE if it is
- TRUE, and Undefined if it is Undefined.
-
- The present match evaluates to TRUE where there is an attribute or
- subtype of the specified attribute description present in an entry,
- and FALSE otherwise (including a presence test with an unrecognized
- attribute description.)
-
- The extensibleMatch is new in this version of LDAP. If the
- matchingRule field is absent, the type field MUST be present, and
- the equality match is performed for that type. If the type field is
- absent and matchingRule is present, the matchValue is compared
- against all attributes in an entry which support that matchingRule,
- and the matchingRule determines the syntax for the assertion value
- (the filter item evaluates to TRUE if it matches with at least
- one attribute in the entry, FALSE if it does not match any attribute
- in the entry, and Undefined if the matchingRule is not recognized
- or the assertionValue cannot be parsed.) If the type field is
- present and matchingRule is present, the matchingRule MUST be one
- permitted for use with that type, otherwise the filter item is
- undefined. If the dnAttributes field is set to TRUE, the match is
- applied against all the attributes in an entry's distinguished name
- as well, and also evaluates to TRUE if there is at least one
- attribute in the distinguished name for which the filter item
- evaluates to TRUE. (Editors note: The dnAttributes field is present
- so that there does not need to be multiple versions of generic
- matching rules such as for word matching, one to apply to entries
- and another to apply to entries and dn attributes as well).
-
- A filter item evaluates to Undefined when the server would not
- be able to determine whether the assertion value matches an
- entry. If an attribute description in an equalityMatch, substrings,
- greaterOrEqual, lessOrEqual, approxMatch or extensibleMatch
- filter is not recognized by the server, a matching rule id in the
- extensibleMatch is not recognized by the server, the assertion
- value cannot be parsed, or the type of filtering requested is not
- implemented, then the filter is Undefined. Thus for example if a
- server did not recognize the attribute type shoeSize, a filter of
- (shoeSize=*) would evaluate to FALSE, and the filters (shoeSize=12),
- (shoeSize>=12) and (shoeSize<=12) would evaluate to Undefined.
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 28]
-
-RFC 2251 LDAPv3 December 1997
-
-
- Servers MUST NOT return errors if attribute descriptions or matching
- rule ids are not recognized, or assertion values cannot be parsed.
- More details of filter processing are given in section 7.8 of X.511
- [8].
-
- - attributes: A list of the attributes to be returned from each entry
- which matches the search filter. There are two special values which
- may be used: an empty list with no attributes, and the attribute
- description string "*". Both of these signify that all user
- attributes are to be returned. (The "*" allows the client to
- request all user attributes in addition to specific operational
- attributes).
-
- Attributes MUST be named at most once in the list, and are returned
- at most once in an entry. If there are attribute descriptions in
- the list which are not recognized, they are ignored by the server.
-
- If the client does not want any attributes returned, it can specify
- a list containing only the attribute with OID "1.1". This OID was
- chosen arbitrarily and does not correspond to any attribute in use.
-
- Client implementors should note that even if all user attributes are
- requested, some attributes of the entry may not be included in
- search results due to access control or other restrictions.
- Furthermore, servers will not return operational attributes, such
- as objectClasses or attributeTypes, unless they are listed by name,
- since there may be extremely large number of values for certain
- operational attributes. (A list of operational attributes for use
- in LDAP is given in [5].)
-
- Note that an X.500 "list"-like operation can be emulated by the client
- requesting a one-level LDAP search operation with a filter checking
- for the existence of the objectClass attribute, and that an X.500
- "read"-like operation can be emulated by a base object LDAP search
- operation with the same filter. A server which provides a gateway to
- X.500 is not required to use the Read or List operations, although it
- may choose to do so, and if it does must provide the same semantics
- as the X.500 search operation.
-
-4.5.2. Search Result
-
- The results of the search attempted by the server upon receipt of a
- Search Request are returned in Search Responses, which are LDAP
- messages containing either SearchResultEntry, SearchResultReference,
- ExtendedResponse or SearchResultDone data types.
-
- SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
- objectName LDAPDN,
-
-
-
-Wahl, et. al. Standards Track [Page 29]
-
-RFC 2251 LDAPv3 December 1997
-
-
- attributes PartialAttributeList }
-
- PartialAttributeList ::= SEQUENCE OF SEQUENCE {
- type AttributeDescription,
- vals SET OF AttributeValue }
- -- implementors should note that the PartialAttributeList may
- -- have zero elements (if none of the attributes of that entry
- -- were requested, or could be returned), and that the vals set
- -- may also have zero elements (if types only was requested, or
- -- all values were excluded from the result.)
-
- SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL
- -- at least one LDAPURL element must be present
-
- SearchResultDone ::= [APPLICATION 5] LDAPResult
-
- Upon receipt of a Search Request, a server will perform the necessary
- search of the DIT.
-
- If the LDAP session is operating over a connection-oriented transport
- such as TCP, the server will return to the client a sequence of
- responses in separate LDAP messages. There may be zero or more
- responses containing SearchResultEntry, one for each entry found
- during the search. There may also be zero or more responses
- containing SearchResultReference, one for each area not explored by
- this server during the search. The SearchResultEntry and
- SearchResultReference PDUs may come in any order. Following all the
- SearchResultReference responses and all SearchResultEntry responses
- to be returned by the server, the server will return a response
- containing the SearchResultDone, which contains an indication of
- success, or detailing any errors that have occurred.
-
- Each entry returned in a SearchResultEntry will contain all
- attributes, complete with associated values if necessary, as
- specified in the attributes field of the Search Request. Return of
- attributes is subject to access control and other administrative
- policy. Some attributes may be returned in binary format (indicated
- by the AttributeDescription in the response having the binary option
- present).
-
- Some attributes may be constructed by the server and appear in a
- SearchResultEntry attribute list, although they are not stored
- attributes of an entry. Clients MUST NOT assume that all attributes
- can be modified, even if permitted by access control.
-
- LDAPMessage responses of the ExtendedResponse form are reserved for
- returning information associated with a control requested by the
- client. These may be defined in future versions of this document.
-
-
-
-Wahl, et. al. Standards Track [Page 30]
-
-RFC 2251 LDAPv3 December 1997
-
-
-4.5.3. Continuation References in the Search Result
-
- If the server was able to locate the entry referred to by the
- baseObject but was unable to search all the entries in the scope at
- and under the baseObject, the server may return one or more
- SearchResultReference, each containing a reference to another set of
- servers for continuing the operation. A server MUST NOT return any
- SearchResultReference if it has not located the baseObject and
- thus has not searched any entries; in this case it would return a
- SearchResultDone containing a referral resultCode.
-
- In the absence of indexing information provided to a server from
- servers holding subordinate naming contexts, SearchResultReference
- responses are not affected by search filters and are always returned
- when in scope.
-
- The SearchResultReference is of the same data type as the Referral.
- URLs for servers implementing the LDAP protocol are written according
- to [9]. The <dn> part MUST be present in the URL, with the new target
- object name. The client MUST use this name in its next request.
- Some servers (e.g. part of a distributed index exchange system) may
- provide a different filter in the URLs of the SearchResultReference.
- If the filter part of the URL is present in an LDAP URL, the client
- MUST use the new filter in its next request to progress the search,
- and if the filter part is absent the client will use again the same
- filter. Other aspects of the new search request may be the same or
- different as the search which generated the continuation references.
-
- Other kinds of URLs may be returned so long as the operation could be
- performed using that protocol.
-
- The name of an unexplored subtree in a SearchResultReference need not
- be subordinate to the base object.
-
- In order to complete the search, the client MUST issue a new search
- operation for each SearchResultReference that is returned. Note that
- the abandon operation described in section 4.11 applies only to a
- particular operation sent on a connection between a client and server,
- and if the client has multiple outstanding search operations to
- different servers, it MUST abandon each operation individually.
-
-4.5.3.1. Example
-
- For example, suppose the contacted server (hosta) holds the entry
- "O=MNN,C=WW" and the entry "CN=Manager,O=MNN,C=WW". It knows that
- either LDAP-capable servers (hostb) or (hostc) hold
- "OU=People,O=MNN,C=WW" (one is the master and the other server a
-
-
-
-
-Wahl, et. al. Standards Track [Page 31]
-
-RFC 2251 LDAPv3 December 1997
-
-
- shadow), and that LDAP-capable server (hostd) holds the subtree
- "OU=Roles,O=MNN,C=WW". If a subtree search of "O=MNN,C=WW" is
- requested to the contacted server, it may return the following:
-
- SearchResultEntry for O=MNN,C=WW
- SearchResultEntry for CN=Manager,O=MNN,C=WW
- SearchResultReference {
- ldap://hostb/OU=People,O=MNN,C=WW
- ldap://hostc/OU=People,O=MNN,C=WW
- }
- SearchResultReference {
- ldap://hostd/OU=Roles,O=MNN,C=WW
- }
- SearchResultDone (success)
-
- Client implementors should note that when following a
- SearchResultReference, additional SearchResultReference may be
- generated. Continuing the example, if the client contacted the
- server (hostb) and issued the search for the subtree
- "OU=People,O=MNN,C=WW", the server might respond as follows:
-
- SearchResultEntry for OU=People,O=MNN,C=WW
- SearchResultReference {
- ldap://hoste/OU=Managers,OU=People,O=MNN,C=WW
- }
- SearchResultReference {
- ldap://hostf/OU=Consultants,OU=People,O=MNN,C=WW
- }
- SearchResultDone (success)
-
- If the contacted server does not hold the base object for the search,
- then it will return a referral to the client. For example, if the
- client requests a subtree search of "O=XYZ,C=US" to hosta, the server
- may return only a SearchResultDone containing a referral.
-
- SearchResultDone (referral) {
- ldap://hostg/
- }
-
-4.6. Modify Operation
-
- The Modify Operation allows a client to request that a modification
- of an entry be performed on its behalf by a server. The Modify
- Request is defined as follows:
-
- ModifyRequest ::= [APPLICATION 6] SEQUENCE {
- object LDAPDN,
- modification SEQUENCE OF SEQUENCE {
-
-
-
-Wahl, et. al. Standards Track [Page 32]
-
-RFC 2251 LDAPv3 December 1997
-
-
- operation ENUMERATED {
- add (0),
- delete (1),
- replace (2) },
- modification AttributeTypeAndValues } }
-
- AttributeTypeAndValues ::= SEQUENCE {
- type AttributeDescription,
- vals SET OF AttributeValue }
-
- Parameters of the Modify Request are:
-
- - object: The object to be modified. The value of this field contains
- the DN of the entry to be modified. The server will not perform
- any alias dereferencing in determining the object to be modified.
-
- - modification: A list of modifications to be performed on the entry.
- The entire list of entry modifications MUST be performed
- in the order they are listed, as a single atomic operation. While
- individual modifications may violate the directory schema, the
- resulting entry after the entire list of modifications is performed
- MUST conform to the requirements of the directory schema. The
- values that may be taken on by the 'operation' field in each
- modification construct have the following semantics respectively:
-
- add: add values listed to the given attribute, creating
- the attribute if necessary;
-
- delete: delete values listed from the given attribute,
- removing the entire attribute if no values are listed, or
- if all current values of the attribute are listed for
- deletion;
-
- replace: replace all existing values of the given attribute
- with the new values listed, creating the attribute if it
- did not already exist. A replace with no value will delete
- the entire attribute if it exists, and is ignored if the
- attribute does not exist.
-
- The result of the modify attempted by the server upon receipt of a
- Modify Request is returned in a Modify Response, defined as follows:
-
- ModifyResponse ::= [APPLICATION 7] LDAPResult
-
- Upon receipt of a Modify Request, a server will perform the necessary
- modifications to the DIT.
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 33]
-
-RFC 2251 LDAPv3 December 1997
-
-
- The server will return to the client a single Modify Response
- indicating either the successful completion of the DIT modification,
- or the reason that the modification failed. Note that due to the
- requirement for atomicity in applying the list of modifications in
- the Modify Request, the client may expect that no modifications of
- the DIT have been performed if the Modify Response received indicates
- any sort of error, and that all requested modifications have been
- performed if the Modify Response indicates successful completion of
- the Modify Operation. If the connection fails, whether the
- modification occurred or not is indeterminate.
-
- The Modify Operation cannot be used to remove from an entry any of
- its distinguished values, those values which form the entry's
- relative distinguished name. An attempt to do so will result in the
- server returning the error notAllowedOnRDN. The Modify DN Operation
- described in section 4.9 is used to rename an entry.
-
- If an equality match filter has not been defined for an attribute type,
- clients MUST NOT attempt to delete individual values of that attribute
- from an entry using the "delete" form of a modification, and MUST
- instead use the "replace" form.
-
- Note that due to the simplifications made in LDAP, there is not a
- direct mapping of the modifications in an LDAP ModifyRequest onto the
- EntryModifications of a DAP ModifyEntry operation, and different
- implementations of LDAP-DAP gateways may use different means of
- representing the change. If successful, the final effect of the
- operations on the entry MUST be identical.
-
-4.7. Add Operation
-
- The Add Operation allows a client to request the addition of an entry
- into the directory. The Add Request is defined as follows:
-
- AddRequest ::= [APPLICATION 8] SEQUENCE {
- entry LDAPDN,
- attributes AttributeList }
-
- AttributeList ::= SEQUENCE OF SEQUENCE {
- type AttributeDescription,
- vals SET OF AttributeValue }
-
- Parameters of the Add Request are:
-
- - entry: the Distinguished Name of the entry to be added. Note that
- the server will not dereference any aliases in locating the entry
- to be added.
-
-
-
-
-Wahl, et. al. Standards Track [Page 34]
-
-RFC 2251 LDAPv3 December 1997
-
-
- - attributes: the list of attributes that make up the content of the
- entry being added. Clients MUST include distinguished values
- (those forming the entry's own RDN) in this list, the objectClass
- attribute, and values of any mandatory attributes of the listed
- object classes. Clients MUST NOT supply the createTimestamp or
- creatorsName attributes, since these will be generated
- automatically by the server.
-
- The entry named in the entry field of the AddRequest MUST NOT exist
- for the AddRequest to succeed. The parent of the entry to be added
- MUST exist. For example, if the client attempted to add
- "CN=JS,O=Foo,C=US", the "O=Foo,C=US" entry did not exist, and the
- "C=US" entry did exist, then the server would return the error
- noSuchObject with the matchedDN field containing "C=US". If the
- parent entry exists but is not in a naming context held by the
- server, the server SHOULD return a referral to the server holding the
- parent entry.
-
- Servers implementations SHOULD NOT restrict where entries can be
- located in the directory. Some servers MAY allow the administrator
- to restrict the classes of entries which can be added to the
- directory.
-
- Upon receipt of an Add Request, a server will attempt to perform the
- add requested. The result of the add attempt will be returned to the
- client in the Add Response, defined as follows:
-
- AddResponse ::= [APPLICATION 9] LDAPResult
-
- A response of success indicates that the new entry is present in the
- directory.
-
-4.8. Delete Operation
-
- The Delete Operation allows a client to request the removal of an
- entry from the directory. The Delete Request is defined as follows:
-
- DelRequest ::= [APPLICATION 10] LDAPDN
-
- The Delete Request consists of the Distinguished Name of the entry to
- be deleted. Note that the server will not dereference aliases while
- resolving the name of the target entry to be removed, and that only
- leaf entries (those with no subordinate entries) can be deleted with
- this operation.
-
- The result of the delete attempted by the server upon receipt of a
- Delete Request is returned in the Delete Response, defined as
- follows:
-
-
-
-Wahl, et. al. Standards Track [Page 35]
-
-RFC 2251 LDAPv3 December 1997
-
-
- DelResponse ::= [APPLICATION 11] LDAPResult
-
- Upon receipt of a Delete Request, a server will attempt to perform
- the entry removal requested. The result of the delete attempt will be
- returned to the client in the Delete Response.
-
-4.9. Modify DN Operation
-
- The Modify DN Operation allows a client to change the leftmost (least
- significant) component of the name of an entry in the directory, or
- to move a subtree of entries to a new location in the directory. The
- Modify DN Request is defined as follows:
-
- ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
- entry LDAPDN,
- newrdn RelativeLDAPDN,
- deleteoldrdn BOOLEAN,
- newSuperior [0] LDAPDN OPTIONAL }
-
- Parameters of the Modify DN Request are:
-
- - entry: the Distinguished Name of the entry to be changed. This
- entry may or may not have subordinate entries.
-
- - newrdn: the RDN that will form the leftmost component of the new
- name of the entry.
-
- - deleteoldrdn: a boolean parameter that controls whether the old RDN
- attribute values are to be retained as attributes of the entry, or
- deleted from the entry.
-
- - newSuperior: if present, this is the Distinguished Name of the entry
- which becomes the immediate superior of the existing entry.
-
- The result of the name change attempted by the server upon receipt of
- a Modify DN Request is returned in the Modify DN Response, defined
- as follows:
-
- ModifyDNResponse ::= [APPLICATION 13] LDAPResult
-
- Upon receipt of a ModifyDNRequest, a server will attempt to
- perform the name change. The result of the name change attempt will
- be returned to the client in the Modify DN Response.
-
- For example, if the entry named in the "entry" parameter was
- "cn=John Smith,c=US", the newrdn parameter was "cn=John Cougar Smith",
- and the newSuperior parameter was absent, then this operation would
-
-
-
-
-Wahl, et. al. Standards Track [Page 36]
-
-RFC 2251 LDAPv3 December 1997
-
-
- attempt to rename the entry to be "cn=John Cougar Smith,c=US". If
- there was already an entry with that name, the operation would fail
- with error code entryAlreadyExists.
-
- If the deleteoldrdn parameter is TRUE, the values forming the old
- RDN are deleted from the entry. If the deleteoldrdn parameter is
- FALSE, the values forming the old RDN will be retained as
- non-distinguished attribute values of the entry. The server may
- not perform the operation and return an error code if the setting of
- the deleteoldrdn parameter would cause a schema inconsistency in the
- entry.
-
- Note that X.500 restricts the ModifyDN operation to only affect
- entries that are contained within a single server. If the LDAP
- server is mapped onto DAP, then this restriction will apply, and the
- resultCode affectsMultipleDSAs will be returned if this error
- occurred. In general clients MUST NOT expect to be able to perform
- arbitrary movements of entries and subtrees between servers.
-
-4.10. Compare Operation
-
- The Compare Operation allows a client to compare an assertion
- provided with an entry in the directory. The Compare Request is
- defined as follows:
-
- CompareRequest ::= [APPLICATION 14] SEQUENCE {
- entry LDAPDN,
- ava AttributeValueAssertion }
-
- Parameters of the Compare Request are:
-
- - entry: the name of the entry to be compared with.
-
- - ava: the assertion with which an attribute in the entry is to be
- compared.
-
- The result of the compare attempted by the server upon receipt of a
- Compare Request is returned in the Compare Response, defined as
- follows:
-
- CompareResponse ::= [APPLICATION 15] LDAPResult
-
- Upon receipt of a Compare Request, a server will attempt to perform
- the requested comparison. The result of the comparison will be
- returned to the client in the Compare Response. Note that errors and
- the result of comparison are all returned in the same construct.
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 37]
-
-RFC 2251 LDAPv3 December 1997
-
-
- Note that some directory systems may establish access controls which
- permit the values of certain attributes (such as userPassword) to be
- compared but not read. In a search result, it may be that an
- attribute of that type would be returned, but with an empty set of
- values.
-
-4.11. Abandon Operation
-
- The function of the Abandon Operation is to allow a client to request
- that the server abandon an outstanding operation. The Abandon
- Request is defined as follows:
-
- AbandonRequest ::= [APPLICATION 16] MessageID
-
- The MessageID MUST be that of a an operation which was requested
- earlier in this connection.
-
- (The abandon request itself has its own message id. This is distinct
- from the id of the earlier operation being abandoned.)
-
- There is no response defined in the Abandon Operation. Upon
- transmission of an Abandon Operation, a client may expect that the
- operation identified by the Message ID in the Abandon Request has
- been abandoned. In the event that a server receives an Abandon
- Request on a Search Operation in the midst of transmitting responses
- to the search, that server MUST cease transmitting entry responses to
- the abandoned request immediately, and MUST NOT send the
- SearchResponseDone. Of course, the server MUST ensure that only
- properly encoded LDAPMessage PDUs are transmitted.
-
- Clients MUST NOT send abandon requests for the same operation
- multiple times, and MUST also be prepared to receive results from
- operations it has abandoned (since these may have been in transit
- when the abandon was requested).
-
- Servers MUST discard abandon requests for message IDs they do not
- recognize, for operations which cannot be abandoned, and for
- operations which have already been abandoned.
-
-4.12. Extended Operation
-
- An extension mechanism has been added in this version of LDAP, in
- order to allow additional operations to be defined for services not
- available elsewhere in this protocol, for instance digitally signed
- operations and results.
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 38]
-
-RFC 2251 LDAPv3 December 1997
-
-
- The extended operation allows clients to make requests and receive
- responses with predefined syntaxes and semantics. These may be
- defined in RFCs or be private to particular implementations. Each
- request MUST have a unique OBJECT IDENTIFIER assigned to it.
-
- ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
- requestName [0] LDAPOID,
- requestValue [1] OCTET STRING OPTIONAL }
-
- The requestName is a dotted-decimal representation of the OBJECT
- IDENTIFIER corresponding to the request. The requestValue is
- information in a form defined by that request, encapsulated inside an
- OCTET STRING.
-
- The server will respond to this with an LDAPMessage containing the
- ExtendedResponse.
-
- ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
- COMPONENTS OF LDAPResult,
- responseName [10] LDAPOID OPTIONAL,
- response [11] OCTET STRING OPTIONAL }
-
- If the server does not recognize the request name, it MUST return
- only the response fields from LDAPResult, containing the
- protocolError result code.
-
-5. Protocol Element Encodings and Transfer
-
- One underlying service is defined here. Clients and servers SHOULD
- implement the mapping of LDAP over TCP described in 5.2.1.
-
-5.1. Mapping Onto BER-based Transport Services
-
- The protocol elements of LDAP are encoded for exchange using the
- Basic Encoding Rules (BER) [11] of ASN.1 [3]. However, due to the
- high overhead involved in using certain elements of the BER, the
- following additional restrictions are placed on BER-encodings of LDAP
- protocol elements:
-
- (1) Only the definite form of length encoding will be used.
-
- (2) OCTET STRING values will be encoded in the primitive form only.
-
- (3) If the value of a BOOLEAN type is true, the encoding MUST have
- its contents octets set to hex "FF".
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 39]
-
-RFC 2251 LDAPv3 December 1997
-
-
- (4) If a value of a type is its default value, it MUST be absent.
- Only some BOOLEAN and INTEGER types have default values in this
- protocol definition.
-
- These restrictions do not apply to ASN.1 types encapsulated inside of
- OCTET STRING values, such as attribute values, unless otherwise
- noted.
-
-5.2. Transfer Protocols
-
- This protocol is designed to run over connection-oriented, reliable
- transports, with all 8 bits in an octet being significant in the data
- stream.
-
-5.2.1. Transmission Control Protocol (TCP)
-
- The LDAPMessage PDUs are mapped directly onto the TCP bytestream. It
- is recommended that server implementations running over the TCP MAY
- provide a protocol listener on the assigned port, 389. Servers may
- instead provide a listener on a different port number. Clients MUST
- support contacting servers on any valid TCP port.
-
-6. Implementation Guidelines
-
- This document describes an Internet protocol.
-
-6.1. Server Implementations
-
- The server MUST be capable of recognizing all the mandatory attribute
- type names and implement the syntaxes specified in [5]. Servers MAY
- also recognize additional attribute type names.
-
-6.2. Client Implementations
-
- Clients which request referrals MUST ensure that they do not loop
- between servers. They MUST NOT repeatedly contact the same server for
- the same request with the same target entry name, scope and filter.
- Some clients may be using a counter that is incremented each time
- referral handling occurs for an operation, and these kinds of clients
- MUST be able to handle a DIT with at least ten layers of naming
- contexts between the root and a leaf entry.
-
- In the absence of prior agreements with servers, clients SHOULD NOT
- assume that servers support any particular schemas beyond those
- referenced in section 6.1. Different schemas can have different
- attribute types with the same names. The client can retrieve the
- subschema entries referenced by the subschemaSubentry attribute in
- the server's root DSE or in entries held by the server.
-
-
-
-Wahl, et. al. Standards Track [Page 40]
-
-RFC 2251 LDAPv3 December 1997
-
-
-7. Security Considerations
-
- When used with a connection-oriented transport, this version of the
- protocol provides facilities for the LDAP v2 authentication
- mechanism, simple authentication using a cleartext password, as well
- as any SASL mechanism [12]. SASL allows for integrity and privacy
- services to be negotiated.
-
- It is also permitted that the server can return its credentials to
- the client, if it chooses to do so.
-
- Use of cleartext password is strongly discouraged where the
- underlying transport service cannot guarantee confidentiality and may
- result in disclosure of the password to unauthorized parties.
-
- When used with SASL, it should be noted that the name field of the
- BindRequest is not protected against modification. Thus if the
- distinguished name of the client (an LDAPDN) is agreed through the
- negotiation of the credentials, it takes precedence over any value in
- the unprotected name field.
-
- Implementations which cache attributes and entries obtained via LDAP
- MUST ensure that access controls are maintained if that information
- is to be provided to multiple clients, since servers may have access
- control policies which prevent the return of entries or attributes in
- search results except to particular authenticated clients. For
- example, caches could serve result information only to the client
- whose request caused it to be cache.
-
-8. Acknowledgements
-
- This document is an update to RFC 1777, by Wengyik Yeong, Tim Howes,
- and Steve Kille. Design ideas included in this document are based on
- those discussed in ASID and other IETF Working Groups. The
- contributions of individuals in these working groups is gratefully
- acknowledged.
-
-9. Bibliography
-
- [1] ITU-T Rec. X.500, "The Directory: Overview of Concepts, Models
- and Service", 1993.
-
- [2] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access
- Protocol", RFC 1777, March 1995.
-
- [3] ITU-T Rec. X.680, "Abstract Syntax Notation One (ASN.1) -
- Specification of Basic Notation", 1994.
-
-
-
-
-Wahl, et. al. Standards Track [Page 41]
-
-RFC 2251 LDAPv3 December 1997
-
-
- [4] Kille, S., Wahl, M., and T. Howes, "Lightweight Directory Access
- Protocol (v3): UTF-8 String Representation of Distinguished
- Names", RFC 2253, December 1997.
-
- [5] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight
- Directory Access Protocol (v3): Attribute Syntax Definitions",
- RFC 2252, December 1997.
-
- [6] ITU-T Rec. X.501, "The Directory: Models", 1993.
-
- [7] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
- Resource Locators (URL)", RFC 1738, December 1994.
-
- [8] ITU-T Rec. X.511, "The Directory: Abstract Service Definition",
- 1993.
-
- [9] Howes, T., and M. Smith, "The LDAP URL Format", RFC 2255,
- December 1997.
-
- [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", RFC 2119, March 1997.
-
- [11] ITU-T Rec. X.690, "Specification of ASN.1 encoding rules: Basic,
- Canonical, and Distinguished Encoding Rules", 1994.
-
- [12] Meyers, J., "Simple Authentication and Security Layer",
- RFC 2222, October 1997.
-
- [13] Universal Multiple-Octet Coded Character Set (UCS) -
- Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 :
- 1993.
-
- [14] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
- 10646", RFC 2044, October 1996.
-
-10. Authors' Addresses
-
- Mark Wahl
- Critical Angle Inc.
- 4815 W Braker Lane #502-385
- Austin, TX 78759
- USA
-
- Phone: +1 512 372-3160
- EMail: M.Wahl@critical-angle.com
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 42]
-
-RFC 2251 LDAPv3 December 1997
-
-
- Tim Howes
- Netscape Communications Corp.
- 501 E. Middlefield Rd., MS MV068
- Mountain View, CA 94043
- USA
-
- Phone: +1 650 937-3419
- EMail: howes@netscape.com
-
- Steve Kille
- Isode Limited
- The Dome, The Square
- Richmond
- TW9 1DT
- UK
-
- Phone: +44-181-332-9091
- EMail: S.Kille@isode.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 43]
-
-RFC 2251 LDAPv3 December 1997
-
-
-Appendix A - Complete ASN.1 Definition
-
- Lightweight-Directory-Access-Protocol-V3 DEFINITIONS
- IMPLICIT TAGS ::=
-
- BEGIN
-
- LDAPMessage ::= SEQUENCE {
- messageID MessageID,
- protocolOp CHOICE {
- bindRequest BindRequest,
- bindResponse BindResponse,
- unbindRequest UnbindRequest,
- searchRequest SearchRequest,
- searchResEntry SearchResultEntry,
- searchResDone SearchResultDone,
- searchResRef SearchResultReference,
- modifyRequest ModifyRequest,
- modifyResponse ModifyResponse,
- addRequest AddRequest,
- addResponse AddResponse,
- delRequest DelRequest,
- delResponse DelResponse,
- modDNRequest ModifyDNRequest,
- modDNResponse ModifyDNResponse,
- compareRequest CompareRequest,
- compareResponse CompareResponse,
- abandonRequest AbandonRequest,
- extendedReq ExtendedRequest,
- extendedResp ExtendedResponse },
- controls [0] Controls OPTIONAL }
-
- MessageID ::= INTEGER (0 .. maxInt)
-
- maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
-
- LDAPString ::= OCTET STRING
-
- LDAPOID ::= OCTET STRING
-
- LDAPDN ::= LDAPString
-
- RelativeLDAPDN ::= LDAPString
-
- AttributeType ::= LDAPString
-
- AttributeDescription ::= LDAPString
-
-
-
-
-Wahl, et. al. Standards Track [Page 44]
-
-RFC 2251 LDAPv3 December 1997
-
-
- AttributeDescriptionList ::= SEQUENCE OF
- AttributeDescription
-
- AttributeValue ::= OCTET STRING
-
- AttributeValueAssertion ::= SEQUENCE {
- attributeDesc AttributeDescription,
- assertionValue AssertionValue }
-
- AssertionValue ::= OCTET STRING
-
- Attribute ::= SEQUENCE {
- type AttributeDescription,
- vals SET OF AttributeValue }
-
- MatchingRuleId ::= LDAPString
-
- LDAPResult ::= SEQUENCE {
- resultCode ENUMERATED {
- success (0),
- operationsError (1),
- protocolError (2),
- timeLimitExceeded (3),
- sizeLimitExceeded (4),
- compareFalse (5),
- compareTrue (6),
- authMethodNotSupported (7),
- strongAuthRequired (8),
- -- 9 reserved --
- referral (10), -- new
- adminLimitExceeded (11), -- new
- unavailableCriticalExtension (12), -- new
- confidentialityRequired (13), -- new
- saslBindInProgress (14), -- new
- noSuchAttribute (16),
- undefinedAttributeType (17),
- inappropriateMatching (18),
- constraintViolation (19),
- attributeOrValueExists (20),
- invalidAttributeSyntax (21),
- -- 22-31 unused --
- noSuchObject (32),
- aliasProblem (33),
- invalidDNSyntax (34),
- -- 35 reserved for undefined isLeaf --
- aliasDereferencingProblem (36),
- -- 37-47 unused --
- inappropriateAuthentication (48),
-
-
-
-Wahl, et. al. Standards Track [Page 45]
-
-RFC 2251 LDAPv3 December 1997
-
-
- invalidCredentials (49),
- insufficientAccessRights (50),
- busy (51),
- unavailable (52),
- unwillingToPerform (53),
- loopDetect (54),
- -- 55-63 unused --
- namingViolation (64),
- objectClassViolation (65),
- notAllowedOnNonLeaf (66),
- notAllowedOnRDN (67),
- entryAlreadyExists (68),
- objectClassModsProhibited (69),
- -- 70 reserved for CLDAP --
- affectsMultipleDSAs (71), -- new
- -- 72-79 unused --
- other (80) },
- -- 81-90 reserved for APIs --
- matchedDN LDAPDN,
- errorMessage LDAPString,
- referral [3] Referral OPTIONAL }
-
- Referral ::= SEQUENCE OF LDAPURL
-
- LDAPURL ::= LDAPString -- limited to characters permitted in URLs
-
- Controls ::= SEQUENCE OF Control
-
- Control ::= SEQUENCE {
- controlType LDAPOID,
- criticality BOOLEAN DEFAULT FALSE,
- controlValue OCTET STRING OPTIONAL }
-
- BindRequest ::= [APPLICATION 0] SEQUENCE {
- version INTEGER (1 .. 127),
- name LDAPDN,
- authentication AuthenticationChoice }
-
- AuthenticationChoice ::= CHOICE {
- simple [0] OCTET STRING,
- -- 1 and 2 reserved
- sasl [3] SaslCredentials }
-
- SaslCredentials ::= SEQUENCE {
- mechanism LDAPString,
- credentials OCTET STRING OPTIONAL }
-
- BindResponse ::= [APPLICATION 1] SEQUENCE {
-
-
-
-Wahl, et. al. Standards Track [Page 46]
-
-RFC 2251 LDAPv3 December 1997
-
-
- COMPONENTS OF LDAPResult,
- serverSaslCreds [7] OCTET STRING OPTIONAL }
-
- UnbindRequest ::= [APPLICATION 2] NULL
-
- SearchRequest ::= [APPLICATION 3] SEQUENCE {
- baseObject LDAPDN,
- scope ENUMERATED {
- baseObject (0),
- singleLevel (1),
- wholeSubtree (2) },
- derefAliases ENUMERATED {
- neverDerefAliases (0),
- derefInSearching (1),
- derefFindingBaseObj (2),
- derefAlways (3) },
- sizeLimit INTEGER (0 .. maxInt),
- timeLimit INTEGER (0 .. maxInt),
- typesOnly BOOLEAN,
- filter Filter,
- attributes AttributeDescriptionList }
-
- Filter ::= CHOICE {
- and [0] SET OF Filter,
- or [1] SET OF Filter,
- not [2] Filter,
- equalityMatch [3] AttributeValueAssertion,
- substrings [4] SubstringFilter,
- greaterOrEqual [5] AttributeValueAssertion,
- lessOrEqual [6] AttributeValueAssertion,
- present [7] AttributeDescription,
- approxMatch [8] AttributeValueAssertion,
- extensibleMatch [9] MatchingRuleAssertion }
-
- SubstringFilter ::= SEQUENCE {
- type AttributeDescription,
- -- at least one must be present
- substrings SEQUENCE OF CHOICE {
- initial [0] LDAPString,
- any [1] LDAPString,
- final [2] LDAPString } }
-
- MatchingRuleAssertion ::= SEQUENCE {
- matchingRule [1] MatchingRuleId OPTIONAL,
- type [2] AttributeDescription OPTIONAL,
- matchValue [3] AssertionValue,
- dnAttributes [4] BOOLEAN DEFAULT FALSE }
-
-
-
-
-Wahl, et. al. Standards Track [Page 47]
-
-RFC 2251 LDAPv3 December 1997
-
-
- SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
- objectName LDAPDN,
- attributes PartialAttributeList }
-
- PartialAttributeList ::= SEQUENCE OF SEQUENCE {
- type AttributeDescription,
- vals SET OF AttributeValue }
-
- SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL
-
- SearchResultDone ::= [APPLICATION 5] LDAPResult
-
- ModifyRequest ::= [APPLICATION 6] SEQUENCE {
- object LDAPDN,
- modification SEQUENCE OF SEQUENCE {
- operation ENUMERATED {
- add (0),
- delete (1),
- replace (2) },
- modification AttributeTypeAndValues } }
-
- AttributeTypeAndValues ::= SEQUENCE {
- type AttributeDescription,
- vals SET OF AttributeValue }
-
- ModifyResponse ::= [APPLICATION 7] LDAPResult
-
- AddRequest ::= [APPLICATION 8] SEQUENCE {
- entry LDAPDN,
- attributes AttributeList }
-
- AttributeList ::= SEQUENCE OF SEQUENCE {
- type AttributeDescription,
- vals SET OF AttributeValue }
-
- AddResponse ::= [APPLICATION 9] LDAPResult
-
- DelRequest ::= [APPLICATION 10] LDAPDN
-
- DelResponse ::= [APPLICATION 11] LDAPResult
-
- ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
- entry LDAPDN,
- newrdn RelativeLDAPDN,
- deleteoldrdn BOOLEAN,
- newSuperior [0] LDAPDN OPTIONAL }
-
- ModifyDNResponse ::= [APPLICATION 13] LDAPResult
-
-
-
-Wahl, et. al. Standards Track [Page 48]
-
-RFC 2251 LDAPv3 December 1997
-
-
- CompareRequest ::= [APPLICATION 14] SEQUENCE {
- entry LDAPDN,
- ava AttributeValueAssertion }
-
- CompareResponse ::= [APPLICATION 15] LDAPResult
-
- AbandonRequest ::= [APPLICATION 16] MessageID
-
- ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
- requestName [0] LDAPOID,
- requestValue [1] OCTET STRING OPTIONAL }
-
- ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
- COMPONENTS OF LDAPResult,
- responseName [10] LDAPOID OPTIONAL,
- response [11] OCTET STRING OPTIONAL }
-
- END
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 49]
-
-RFC 2251 LDAPv3 December 1997
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (1997). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 50]
-
diff --git a/doc/rfc/rfc2252.txt b/doc/rfc/rfc2252.txt
deleted file mode 100644
index 5597ee1c326cb43bfb913e32e3f404e337dbb658..0000000000000000000000000000000000000000
--- a/doc/rfc/rfc2252.txt
+++ /dev/null
@@ -1,1795 +0,0 @@
-
-
-
-
-
-
-Network Working Group M. Wahl
-Request for Comments: 2252 Critical Angle Inc.
-Category: Standards Track A. Coulbeck
- Isode Inc.
- T. Howes
- Netscape Communications Corp.
- S. Kille
- Isode Limited
- December 1997
-
-
- Lightweight Directory Access Protocol (v3):
- Attribute Syntax Definitions
-
-1. Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (1997). All Rights Reserved.
-
-IESG Note
-
- This document describes a directory access protocol that provides
- both read and update access. Update access requires secure
- authentication, but this document does not mandate implementation of
- any satisfactory authentication mechanisms.
-
- In accordance with RFC 2026, section 4.4.1, this specification is
- being approved by IESG as a Proposed Standard despite this
- limitation, for the following reasons:
-
- a. to encourage implementation and interoperability testing of
- these protocols (with or without update access) before they
- are deployed, and
-
- b. to encourage deployment and use of these protocols in read-only
- applications. (e.g. applications where LDAPv3 is used as
- a query language for directories which are updated by some
- secure mechanism other than LDAP), and
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 1]
-
-RFC 2252 LADPv3 Attributes December 1997
-
-
- c. to avoid delaying the advancement and deployment of other Internet
- standards-track protocols which require the ability to query, but
- not update, LDAPv3 directory servers.
-
- Readers are hereby warned that until mandatory authentication
- mechanisms are standardized, clients and servers written according to
- this specification which make use of update functionality are
- UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
- IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
-
- Implementors are hereby discouraged from deploying LDAPv3 clients or
- servers which implement the update functionality, until a Proposed
- Standard for mandatory authentication in LDAPv3 has been approved and
- published as an RFC.
-
-2. Abstract
-
- The Lightweight Directory Access Protocol (LDAP) [1] requires that
- the contents of AttributeValue fields in protocol elements be octet
- strings. This document defines a set of syntaxes for LDAPv3, and the
- rules by which attribute values of these syntaxes are represented as
- octet strings for transmission in the LDAP protocol. The syntaxes
- defined in this document are referenced by this and other documents
- that define attribute types. This document also defines the set of
- attribute types which LDAP servers should support.
-
-3. Overview
-
- This document defines the framework for developing schemas for
- directories accessible via the Lightweight Directory Access Protocol.
-
- Schema is the collection of attribute type definitions, object class
- definitions and other information which a server uses to determine
- how to match a filter or attribute value assertion (in a compare
- operation) against the attributes of an entry, and whether to permit
- add and modify operations.
-
- Section 4 states the general requirements and notations for attribute
- types, object classes, syntax and matching rule definitions.
-
- Section 5 lists attributes, section 6 syntaxes and section 7 object
- classes.
-
- Additional documents define schemas for representing real-world
- objects as directory entries.
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 2]
-
-RFC 2252 LADPv3 Attributes December 1997
-
-
-4. General Issues
-
- This document describes encodings used in an Internet protocol.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [4].
-
- Attribute Type and Object Class definitions are written in a string
- representation of the AttributeTypeDescription and
- ObjectClassDescription data types defined in X.501(93) [3].
- Implementors are strongly advised to first read the description of
- how schema is represented in X.500 before reading the rest of this
- document.
-
-4.1. Common Encoding Aspects
-
- For the purposes of defining the encoding rules for attribute
- syntaxes, the following BNF definitions will be used. They are based
- on the BNF styles of RFC 822 [13].
-
- a = "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" /
- "j" / "k" / "l" / "m" / "n" / "o" / "p" / "q" / "r" /
- "s" / "t" / "u" / "v" / "w" / "x" / "y" / "z" / "A" /
- "B" / "C" / "D" / "E" / "F" / "G" / "H" / "I" / "J" /
- "K" / "L" / "M" / "N" / "O" / "P" / "Q" / "R" / "S" /
- "T" / "U" / "V" / "W" / "X" / "Y" / "Z"
-
- d = "0" / "1" / "2" / "3" / "4" /
- "5" / "6" / "7" / "8" / "9"
-
- hex-digit = d / "a" / "b" / "c" / "d" / "e" / "f" /
- "A" / "B" / "C" / "D" / "E" / "F"
-
- k = a / d / "-" / ";"
-
- p = a / d / """ / "(" / ")" / "+" / "," /
- "-" / "." / "/" / ":" / "?" / " "
-
- letterstring = 1*a
-
- numericstring = 1*d
-
- anhstring = 1*k
-
- keystring = a [ anhstring ]
-
- printablestring = 1*p
-
-
-
-Wahl, et. al. Standards Track [Page 3]
-
-RFC 2252 LADPv3 Attributes December 1997
-
-
- space = 1*" "
-
- whsp = [ space ]
-
- utf8 = <any sequence of octets formed from the UTF-8 [9]
- transformation of a character from ISO10646 [10]>
-
- dstring = 1*utf8
-
- qdstring = whsp "'" dstring "'" whsp
-
- qdstringlist = [ qdstring *( qdstring ) ]
-
- qdstrings = qdstring / ( whsp "(" qdstringlist ")" whsp )
-
- In the following BNF for the string representation of OBJECT
- IDENTIFIERs, descr is the syntactic representation of an object
- descriptor, which consists of letters and digits, starting with a
- letter. An OBJECT IDENTIFIER in the numericoid format should not
- have leading zeroes (e.g. "0.9.3" is permitted but "0.09.3" should
- not be generated).
-
- When encoding 'oid' elements in a value, the descr encoding option
- SHOULD be used in preference to the numericoid. An object descriptor
- is a more readable alias for a number OBJECT IDENTIFIER, and these
- (where assigned and known by the implementation) SHOULD be used in
- preference to numeric oids to the greatest extent possible. Examples
- of object descriptors in LDAP are attribute type, object class and
- matching rule names.
-
- oid = descr / numericoid
-
- descr = keystring
-
- numericoid = numericstring *( "." numericstring )
-
- woid = whsp oid whsp
-
- ; set of oids of either form
- oids = woid / ( "(" oidlist ")" )
-
- oidlist = woid *( "$" woid )
-
- ; object descriptors used as schema element names
- qdescrs = qdescr / ( whsp "(" qdescrlist ")" whsp )
-
- qdescrlist = [ qdescr *( qdescr ) ]
-
-
-
-
-Wahl, et. al. Standards Track [Page 4]
-
-RFC 2252 LADPv3 Attributes December 1997
-
-
- qdescr = whsp "'" descr "'" whsp
-
-4.2. Attribute Types
-
- The attribute types are described by sample values for the subschema
- "attributeTypes" attribute, which is written in the
- AttributeTypeDescription syntax. While lines have been folded for
- readability, the values transferred in protocol would not contain
- newlines.
-
- The AttributeTypeDescription is encoded according to the following
- BNF, and the productions for oid, qdescrs and qdstring are given in
- section 4.1. Implementors should note that future versions of this
- document may have expanded this BNF to include additional terms.
- Terms which begin with the characters "X-" are reserved for private
- experiments, and MUST be followed by a <qdstrings>.
-
- AttributeTypeDescription = "(" whsp
- numericoid whsp ; AttributeType identifier
- [ "NAME" qdescrs ] ; name used in AttributeType
- [ "DESC" qdstring ] ; description
- [ "OBSOLETE" whsp ]
- [ "SUP" woid ] ; derived from this other
- ; AttributeType
- [ "EQUALITY" woid ; Matching Rule name
- [ "ORDERING" woid ; Matching Rule name
- [ "SUBSTR" woid ] ; Matching Rule name
- [ "SYNTAX" whsp noidlen whsp ] ; see section 4.3
- [ "SINGLE-VALUE" whsp ] ; default multi-valued
- [ "COLLECTIVE" whsp ] ; default not collective
- [ "NO-USER-MODIFICATION" whsp ]; default user modifiable
- [ "USAGE" whsp AttributeUsage ]; default userApplications
- whsp ")"
-
- AttributeUsage =
- "userApplications" /
- "directoryOperation" /
- "distributedOperation" / ; DSA-shared
- "dSAOperation" ; DSA-specific, value depends on server
-
- Servers are not required to provide the same or any text in the
- description part of the subschema values they maintain. Servers
- SHOULD provide at least one of the "SUP" and "SYNTAX" fields for each
- AttributeTypeDescription.
-
- Servers MUST implement all the attribute types referenced in sections
- 5.1, 5.2 and 5.3.
-
-
-
-
-Wahl, et. al. Standards Track [Page 5]
-
-RFC 2252 LADPv3 Attributes December 1997
-
-
- Servers MAY recognize additional names and attributes not listed in
- this document, and if they do so, MUST publish the definitions of the
- types in the attributeTypes attribute of their subschema entries.
-
- Schema developers MUST NOT create attribute definitions whose names
- conflict with attributes defined for use with LDAP in existing
- standards-track RFCs.
-
- An AttributeDescription can be used as the value in a NAME part of an
- AttributeTypeDescription. Note that these are case insensitive.
-
- Note that the AttributeTypeDescription does not list the matching
- rules which can can be used with that attribute type in an
- extensibleMatch search filter. This is done using the
- matchingRuleUse attribute described in section 4.5.
-
- This document refines the schema description of X.501 by requiring
- that the syntax field in an AttributeTypeDescription be a string
- representation of an OBJECT IDENTIFIER for the LDAP string syntax
- definition, and an optional indication of the maximum length of a
- value of this attribute (defined in section 4.3.2).
-
-4.3. Syntaxes
-
- This section defines general requirements for LDAP attribute value
- syntax encodings. All documents defining attribute syntax encodings
- for use with LDAP are expected to conform to these requirements.
-
- The encoding rules defined for a given attribute syntax must produce
- octet strings. To the greatest extent possible, encoded octet
- strings should be usable in their native encoded form for display
- purposes. In particular, encoding rules for attribute syntaxes
- defining non-binary values should produce strings that can be
- displayed with little or no translation by clients implementing LDAP.
- There are a few cases (e.g. audio) however, when it is not sensible
- to produce a printable representation, and clients MUST NOT assume
- that an unrecognized syntax is a string representation.
-
- In encodings where an arbitrary string, not a Distinguished Name, is
- used as part of a larger production, and other than as part of a
- Distinguished Name, a backslash quoting mechanism is used to escape
- the following separator symbol character (such as "'", "$" or "#") if
- it should occur in that string. The backslash is followed by a pair
- of hexadecimal digits representing the next character. A backslash
- itself in the string which forms part of a larger syntax is always
- transmitted as '\5C' or '\5c'. An example is given in section 6.27.
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 6]
-
-RFC 2252 LADPv3 Attributes December 1997
-
-
- Syntaxes are also defined for matching rules whose assertion value
- syntax is different from the attribute value syntax.
-
-4.3.1 Binary Transfer of Values
-
- This encoding format is used if the binary encoding is requested by
- the client for an attribute, or if the attribute syntax name is
- "1.3.6.1.4.1.1466.115.121.1.5". The contents of the LDAP
- AttributeValue or AssertionValue field is a BER-encoded instance of
- the attribute value or a matching rule assertion value ASN.1 data
- type as defined for use with X.500. (The first byte inside the OCTET
- STRING wrapper is a tag octet. However, the OCTET STRING is still
- encoded in primitive form.)
-
- All servers MUST implement this form for both generating attribute
- values in search responses, and parsing attribute values in add,
- compare and modify requests, if the attribute type is recognized and
- the attribute syntax name is that of Binary. Clients which request
- that all attributes be returned from entries MUST be prepared to
- receive values in binary (e.g. userCertificate;binary), and SHOULD
- NOT simply display binary or unrecognized values to users.
-
-4.3.2. Syntax Object Identifiers
-
- Syntaxes for use with LDAP are named by OBJECT IDENTIFIERs, which are
- dotted-decimal strings. These are not intended to be displayed to
- users.
-
- noidlen = numericoid [ "{" len "}" ]
-
- len = numericstring
-
- The following table lists some of the syntaxes that have been defined
- for LDAP thus far. The H-R column suggests whether a value in that
- syntax would likely be a human readable string. Clients and servers
- need not implement all the syntaxes listed here, and MAY implement
- other syntaxes.
-
- Other documents may define additional syntaxes. However, the
- definition of additional arbitrary syntaxes is strongly deprecated
- since it will hinder interoperability: today's client and server
- implementations generally do not have the ability to dynamically
- recognize new syntaxes. In most cases attributes will be defined
- with the syntax for directory strings.
-
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 7]
-
-RFC 2252 LADPv3 Attributes December 1997
-
-
- Value being represented H-R OBJECT IDENTIFIER
- =================================================================
- ACI Item N 1.3.6.1.4.1.1466.115.121.1.1
- Access Point Y 1.3.6.1.4.1.1466.115.121.1.2
- Attribute Type Description Y 1.3.6.1.4.1.1466.115.121.1.3
- Audio N 1.3.6.1.4.1.1466.115.121.1.4
- Binary N 1.3.6.1.4.1.1466.115.121.1.5
- Bit String Y 1.3.6.1.4.1.1466.115.121.1.6
- Boolean Y 1.3.6.1.4.1.1466.115.121.1.7
- Certificate N 1.3.6.1.4.1.1466.115.121.1.8
- Certificate List N 1.3.6.1.4.1.1466.115.121.1.9
- Certificate Pair N 1.3.6.1.4.1.1466.115.121.1.10
- Country String Y 1.3.6.1.4.1.1466.115.121.1.11
- DN Y 1.3.6.1.4.1.1466.115.121.1.12
- Data Quality Syntax Y 1.3.6.1.4.1.1466.115.121.1.13
- Delivery Method Y 1.3.6.1.4.1.1466.115.121.1.14
- Directory String Y 1.3.6.1.4.1.1466.115.121.1.15
- DIT Content Rule Description Y 1.3.6.1.4.1.1466.115.121.1.16
- DIT Structure Rule Description Y 1.3.6.1.4.1.1466.115.121.1.17
- DL Submit Permission Y 1.3.6.1.4.1.1466.115.121.1.18
- DSA Quality Syntax Y 1.3.6.1.4.1.1466.115.121.1.19
- DSE Type Y 1.3.6.1.4.1.1466.115.121.1.20
- Enhanced Guide Y 1.3.6.1.4.1.1466.115.121.1.21
- Facsimile Telephone Number Y 1.3.6.1.4.1.1466.115.121.1.22
- Fax N 1.3.6.1.4.1.1466.115.121.1.23
- Generalized Time Y 1.3.6.1.4.1.1466.115.121.1.24
- Guide Y 1.3.6.1.4.1.1466.115.121.1.25
- IA5 String Y 1.3.6.1.4.1.1466.115.121.1.26
- INTEGER Y 1.3.6.1.4.1.1466.115.121.1.27
- JPEG N 1.3.6.1.4.1.1466.115.121.1.28
- LDAP Syntax Description Y 1.3.6.1.4.1.1466.115.121.1.54
- LDAP Schema Definition Y 1.3.6.1.4.1.1466.115.121.1.56
- LDAP Schema Description Y 1.3.6.1.4.1.1466.115.121.1.57
- Master And Shadow Access Points Y 1.3.6.1.4.1.1466.115.121.1.29
- Matching Rule Description Y 1.3.6.1.4.1.1466.115.121.1.30
- Matching Rule Use Description Y 1.3.6.1.4.1.1466.115.121.1.31
- Mail Preference Y 1.3.6.1.4.1.1466.115.121.1.32
- MHS OR Address Y 1.3.6.1.4.1.1466.115.121.1.33
- Modify Rights Y 1.3.6.1.4.1.1466.115.121.1.55
- Name And Optional UID Y 1.3.6.1.4.1.1466.115.121.1.34
- Name Form Description Y 1.3.6.1.4.1.1466.115.121.1.35
- Numeric String Y 1.3.6.1.4.1.1466.115.121.1.36
- Object Class Description Y 1.3.6.1.4.1.1466.115.121.1.37
- Octet String Y 1.3.6.1.4.1.1466.115.121.1.40
- OID Y 1.3.6.1.4.1.1466.115.121.1.38
- Other Mailbox Y 1.3.6.1.4.1.1466.115.121.1.39
- Postal Address Y 1.3.6.1.4.1.1466.115.121.1.41
- Protocol Information Y 1.3.6.1.4.1.1466.115.121.1.42
-
-
-
-Wahl, et. al. Standards Track [Page 8]
-
-RFC 2252 LADPv3 Attributes December 1997
-
-
- Presentation Address Y 1.3.6.1.4.1.1466.115.121.1.43
- Printable String Y 1.3.6.1.4.1.1466.115.121.1.44
- Substring Assertion Y 1.3.6.1.4.1.1466.115.121.1.58
- Subtree Specification Y 1.3.6.1.4.1.1466.115.121.1.45
- Supplier Information Y 1.3.6.1.4.1.1466.115.121.1.46
- Supplier Or Consumer Y 1.3.6.1.4.1.1466.115.121.1.47
- Supplier And Consumer Y 1.3.6.1.4.1.1466.115.121.1.48
- Supported Algorithm N 1.3.6.1.4.1.1466.115.121.1.49
- Telephone Number Y 1.3.6.1.4.1.1466.115.121.1.50
- Teletex Terminal Identifier Y 1.3.6.1.4.1.1466.115.121.1.51
- Telex Number Y 1.3.6.1.4.1.1466.115.121.1.52
- UTC Time Y 1.3.6.1.4.1.1466.115.121.1.53
-
- A suggested minimum upper bound on the number of characters in value
- with a string-based syntax, or the number of bytes in a value for all
- other syntaxes, may be indicated by appending this bound count inside
- of curly braces following the syntax name's OBJECT IDENTIFIER in an
- Attribute Type Description. This bound is not part of the syntax
- name itself. For instance, "1.3.6.4.1.1466.0{64}" suggests that
- server implementations should allow a string to be 64 characters
- long, although they may allow longer strings. Note that a single
- character of the Directory String syntax may be encoded in more than
- one byte since UTF-8 is a variable-length encoding.
-
-4.3.3. Syntax Description
-
- The following BNF may be used to associate a short description with a
- syntax OBJECT IDENTIFIER. Implementors should note that future
- versions of this document may expand this definition to include
- additional terms. Terms whose identifier begins with "X-" are
- reserved for private experiments, and MUST be followed by a
- <qdstrings>.
-
- SyntaxDescription = "(" whsp
- numericoid whsp
- [ "DESC" qdstring ]
- whsp ")"
-
-4.4. Object Classes
-
- The format for representation of object classes is defined in X.501
- [3]. In general every entry will contain an abstract class ("top" or
- "alias"), at least one structural object class, and zero or more
- auxiliary object classes. Whether an object class is abstract,
- structural or auxiliary is defined when the object class identifier
- is assigned. An object class definition should not be changed
- without having a new identifier assigned to it.
-
-
-
-
-Wahl, et. al. Standards Track [Page 9]
-
-RFC 2252 LADPv3 Attributes December 1997
-
-
- Object class descriptions are written according to the following BNF.
- Implementors should note that future versions of this document may
- expand this definition to include additional terms. Terms whose
- identifier begins with "X-" are reserved for private experiments, and
- MUST be followed by a <qdstrings> encoding.
-
- ObjectClassDescription = "(" whsp
- numericoid whsp ; ObjectClass identifier
- [ "NAME" qdescrs ]
- [ "DESC" qdstring ]
- [ "OBSOLETE" whsp ]
- [ "SUP" oids ] ; Superior ObjectClasses
- [ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ]
- ; default structural
- [ "MUST" oids ] ; AttributeTypes
- [ "MAY" oids ] ; AttributeTypes
- whsp ")"
-
- These are described as sample values for the subschema
- "objectClasses" attribute for a server which implements the LDAP
- schema. While lines have been folded for readability, the values
- transferred in protocol would not contain newlines.
-
- Servers SHOULD implement all the object classes referenced in section
- 7, except for extensibleObject, which is optional. Servers MAY
- implement additional object classes not listed in this document, and
- if they do so, MUST publish the definitions of the classes in the
- objectClasses attribute of their subschema entries.
-
- Schema developers MUST NOT create object class definitions whose
- names conflict with attributes defined for use with LDAP in existing
- standards-track RFCs.
-
-4.5. Matching Rules
-
- Matching rules are used by servers to compare attribute values
- against assertion values when performing Search and Compare
- operations. They are also used to identify the value to be added or
- deleted when modifying entries, and are used when comparing a
- purported distinguished name with the name of an entry.
-
- Most of the attributes given in this document will have an equality
- matching rule defined.
-
- Matching rule descriptions are written according to the following
- BNF. Implementors should note that future versions of this document
- may have expanded this BNF to include additional terms. Terms whose
- identifier begins with "X-" are reserved for private experiments, and
-
-
-
-Wahl, et. al. Standards Track [Page 10]
-
-RFC 2252 LADPv3 Attributes December 1997
-
-
- MUST be followed by a <qdstrings> encoding.
-
- MatchingRuleDescription = "(" whsp
- numericoid whsp ; MatchingRule identifier
- [ "NAME" qdescrs ]
- [ "DESC" qdstring ]
- [ "OBSOLETE" whsp ]
- "SYNTAX" numericoid
- whsp ")"
-
- Values of the matchingRuleUse list the attributes which are suitable
- for use with an extensible matching rule.
-
- MatchingRuleUseDescription = "(" whsp
- numericoid whsp ; MatchingRule identifier
- [ "NAME" qdescrs ]
- [ "DESC" qdstring ]
- [ "OBSOLETE" ]
- "APPLIES" oids ; AttributeType identifiers
- whsp ")"
-
- Servers which support matching rules and the extensibleMatch SHOULD
- implement all the matching rules in section 8.
-
- Servers MAY implement additional matching rules not listed in this
- document, and if they do so, MUST publish the definitions of the
- matching rules in the matchingRules attribute of their subschema
- entries. If the server supports the extensibleMatch, then the server
- MUST publish the relationship between the matching rules and
- attributes in the matchingRuleUse attribute.
-
- For example, a server which implements a privately-defined matching
- rule for performing sound-alike matches on Directory String-valued
- attributes would include the following in the subschema entry
- (1.2.3.4.5 is an example, the OID of an actual matching rule would be
- different):
-
- matchingRule: ( 1.2.3.4.5 NAME 'soundAlikeMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- If this matching rule could be used with the attributes 2.5.4.41 and
- 2.5.4.15, the following would also be present:
-
- matchingRuleUse: ( 1.2.3.4.5 APPLIES (2.5.4.41 $ 2.5.4.15) )
-
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 11]
-
-RFC 2252 LADPv3 Attributes December 1997
-
-
- A client could then make use of this matching rule by sending a
- search operation in which the filter is of the extensibleMatch
- choice, the matchingRule field is "soundAlikeMatch", and the type
- field is "2.5.4.41" or "2.5.4.15".
-
-5. Attribute Types
-
- All LDAP server implementations MUST recognize the attribute types
- defined in this section.
-
- Servers SHOULD also recognize all the attributes from section 5 of
- [12].
-
-5.1. Standard Operational Attributes
-
- Servers MUST maintain values of these attributes in accordance with
- the definitions in X.501(93).
-
-5.1.1. createTimestamp
-
- This attribute SHOULD appear in entries which were created using the
- Add operation.
-
- ( 2.5.18.1 NAME 'createTimestamp' EQUALITY generalizedTimeMatch
- ORDERING generalizedTimeOrderingMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
- SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
-
-5.1.2. modifyTimestamp
-
- This attribute SHOULD appear in entries which have been modified
- using the Modify operation.
-
- ( 2.5.18.2 NAME 'modifyTimestamp' EQUALITY generalizedTimeMatch
- ORDERING generalizedTimeOrderingMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
- SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
-
-5.1.3. creatorsName
-
- This attribute SHOULD appear in entries which were created using the
- Add operation.
-
- ( 2.5.18.3 NAME 'creatorsName' EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
- SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 12]
-
-RFC 2252 LADPv3 Attributes December 1997
-
-
-5.1.4. modifiersName
-
- This attribute SHOULD appear in entries which have been modified
- using the Modify operation.
-
- ( 2.5.18.4 NAME 'modifiersName' EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
- SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
-
-5.1.5. subschemaSubentry
-
- The value of this attribute is the name of a subschema entry (or
- subentry if the server is based on X.500(93)) in which the server
- makes available attributes specifying the schema.
-
- ( 2.5.18.10 NAME 'subschemaSubentry'
- EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATION
- SINGLE-VALUE USAGE directoryOperation )
-
-5.1.6. attributeTypes
-
- This attribute is typically located in the subschema entry.
-
- ( 2.5.21.5 NAME 'attributeTypes'
- EQUALITY objectIdentifierFirstComponentMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.3 USAGE directoryOperation )
-
-5.1.7. objectClasses
-
- This attribute is typically located in the subschema entry.
-
- ( 2.5.21.6 NAME 'objectClasses'
- EQUALITY objectIdentifierFirstComponentMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.37 USAGE directoryOperation )
-
-5.1.8. matchingRules
-
- This attribute is typically located in the subschema entry.
-
- ( 2.5.21.4 NAME 'matchingRules'
- EQUALITY objectIdentifierFirstComponentMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.30 USAGE directoryOperation )
-
-
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 13]
-
-RFC 2252 LADPv3 Attributes December 1997
-
-
-5.1.9. matchingRuleUse
-
- This attribute is typically located in the subschema entry.
-
- ( 2.5.21.8 NAME 'matchingRuleUse'
- EQUALITY objectIdentifierFirstComponentMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.31 USAGE directoryOperation )
-
-5.2. LDAP Operational Attributes
-
- These attributes are only present in the root DSE (see [1] and [3]).
-
- Servers MUST recognize these attribute names, but it is not required
- that a server provide values for these attributes, when the attribute
- corresponds to a feature which the server does not implement.
-
-5.2.1. namingContexts
-
- The values of this attribute correspond to naming contexts which this
- server masters or shadows. If the server does not master any
- information (e.g. it is an LDAP gateway to a public X.500 directory)
- this attribute will be absent. If the server believes it contains
- the entire directory, the attribute will have a single value, and
- that value will be the empty string (indicating the null DN of the
- root). This attribute will allow a client to choose suitable base
- objects for searching when it has contacted a server.
-
- ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 USAGE dSAOperation )
-
-5.2.2. altServer
-
- The values of this attribute are URLs of other servers which may be
- contacted when this server becomes unavailable. If the server does
- not know of any other servers which could be used this attribute will
- be absent. Clients may cache this information in case their preferred
- LDAP server later becomes unavailable.
-
- ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 USAGE dSAOperation )
-
-5.2.3. supportedExtension
-
- The values of this attribute are OBJECT IDENTIFIERs identifying the
- supported extended operations which the server supports.
-
- If the server does not support any extensions this attribute will be
- absent.
-
-
-
-Wahl, et. al. Standards Track [Page 14]
-
-RFC 2252 LADPv3 Attributes December 1997
-
-
- ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation )
-
-5.2.4. supportedControl
-
- The values of this attribute are the OBJECT IDENTIFIERs identifying
- controls which the server supports. If the server does not support
- any controls, this attribute will be absent.
-
- ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation )
-
-5.2.5. supportedSASLMechanisms
-
- The values of this attribute are the names of supported SASL
- mechanisms which the server supports. If the server does not support
- any mechanisms this attribute will be absent.
-
- ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE dSAOperation )
-
-5.2.6. supportedLDAPVersion
-
- The values of this attribute are the versions of the LDAP protocol
- which the server implements.
-
- ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 USAGE dSAOperation )
-
-5.3. LDAP Subschema Attribute
-
- This attribute is typically located in the subschema entry.
-
-5.3.1. ldapSyntaxes
-
- Servers MAY use this attribute to list the syntaxes which are
- implemented. Each value corresponds to one syntax.
-
- ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes'
- EQUALITY objectIdentifierFirstComponentMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.54 USAGE directoryOperation )
-
-5.4. X.500 Subschema attributes
-
- These attributes are located in the subschema entry. All servers
- SHOULD recognize their name, although typically only X.500 servers
- will implement their functionality.
-
-
-
-
-Wahl, et. al. Standards Track [Page 15]
-
-RFC 2252 LADPv3 Attributes December 1997
-
-
-5.4.1. dITStructureRules
-
- ( 2.5.21.1 NAME 'dITStructureRules' EQUALITY integerFirstComponentMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.17 USAGE directoryOperation )
-
-5.4.2. nameForms
-
- ( 2.5.21.7 NAME 'nameForms'
- EQUALITY objectIdentifierFirstComponentMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.35 USAGE directoryOperation )
-
-5.4.3. ditContentRules
-
- ( 2.5.21.2 NAME 'dITContentRules'
- EQUALITY objectIdentifierFirstComponentMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.16 USAGE directoryOperation )
-
-6. Syntaxes
-
- Servers SHOULD recognize all the syntaxes described in this section.
-
-6.1. Attribute Type Description
-
- ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' )
-
- Values in this syntax are encoded according to the BNF given at the
- start of section 4.2. For example,
-
- ( 2.5.4.0 NAME 'objectClass'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
-
-6.2. Binary
-
- ( 1.3.6.1.4.1.1466.115.121.1.5 DESC 'Binary' )
-
- Values in this syntax are encoded as described in section 4.3.1.
-
-6.3. Bit String
-
- ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' )
-
- Values in this syntax are encoded according to the following BNF:
-
- bitstring = "'" *binary-digit "'B"
-
- binary-digit = "0" / "1"
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 16]
-
-RFC 2252 LADPv3 Attributes December 1997
-
-
- Example:
-
- '0101111101'B
-
-6.4. Boolean
-
- ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )
-
- Values in this syntax are encoded according to the following BNF:
-
- boolean = "TRUE" / "FALSE"
-
- Boolean values have an encoding of "TRUE" if they are logically true,
- and have an encoding of "FALSE" otherwise.
-
-6.5. Certificate
-
- ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' )
-
- Because of the changes from X.509(1988) and X.509(1993) and
- additional changes to the ASN.1 definition to support certificate
- extensions, no string representation is defined, and values in this
- syntax MUST only be transferred using the binary encoding, by
- requesting or returning the attributes with descriptions
- "userCertificate;binary" or "caCertificate;binary". The BNF notation
- in RFC 1778 for "User Certificate" is not recommended to be used.
-
-6.6. Certificate List
-
- ( 1.3.6.1.4.1.1466.115.121.1.9 DESC 'Certificate List' )
-
- Because of the incompatibility of the X.509(1988) and X.509(1993)
- definitions of revocation lists, values in this syntax MUST only be
- transferred using a binary encoding, by requesting or returning the
- attributes with descriptions "certificateRevocationList;binary" or
- "authorityRevocationList;binary". The BNF notation in RFC 1778 for
- "Authority Revocation List" is not recommended to be used.
-
-6.7. Certificate Pair
-
- ( 1.3.6.1.4.1.1466.115.121.1.10 DESC 'Certificate Pair' )
-
- Because the Certificate is being carried in binary, values in this
- syntax MUST only be transferred using a binary encoding, by
- requesting or returning the attribute description
- "crossCertificatePair;binary". The BNF notation in RFC 1778 for
- "Certificate Pair" is not recommended to be used.
-
-
-
-
-Wahl, et. al. Standards Track [Page 17]
-
-RFC 2252 LADPv3 Attributes December 1997
-
-
-6.8. Country String
-
- ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' )
-
- A value in this syntax is encoded the same as a value of Directory
- String syntax. Note that this syntax is limited to values of exactly
- two printable string characters, as listed in ISO 3166 [14].
-
- CountryString = p p
-
- Example:
- US
-
-6.9. DN
-
- ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )
-
- Values in the Distinguished Name syntax are encoded to have the
- representation defined in [5]. Note that this representation is not
- reversible to an ASN.1 encoding used in X.500 for Distinguished
- Names, as the CHOICE of any DirectoryString element in an RDN is no
- longer known.
-
- Examples (from [5]):
- CN=Steve Kille,O=Isode Limited,C=GB
- OU=Sales+CN=J. Smith,O=Widget Inc.,C=US
- CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB
- CN=Before\0DAfter,O=Test,C=GB
- 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB
- SN=Lu\C4\8Di\C4\87
-
-6.10. Directory String
-
- ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )
-
- A string in this syntax is encoded in the UTF-8 form of ISO 10646 (a
- superset of Unicode). Servers and clients MUST be prepared to
- receive encodings of arbitrary Unicode characters, including
- characters not presently assigned to any character set.
-
- For characters in the PrintableString form, the value is encoded as
- the string value itself.
-
- If it is of the TeletexString form, then the characters are
- transliterated to their equivalents in UniversalString, and encoded
- in UTF-8 [9].
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 18]
-
-RFC 2252 LADPv3 Attributes December 1997
-
-
- If it is of the UniversalString or BMPString forms [10], UTF-8 is
- used to encode them.
-
- Note: the form of DirectoryString is not indicated in protocol unless
- the attribute value is carried in binary. Servers which convert to
- DAP MUST choose an appropriate form. Servers MUST NOT reject values
- merely because they contain legal Unicode characters outside of the
- range of printable ASCII.
-
- Example:
-
- This is a string of DirectoryString containing #!%#@
-
-6.11. DIT Content Rule Description
-
-
- ues in this syntax are encoded according to the following BNF.
- lementors should note that future versions of this document
- have expanded this BNF to include additional terms.
-
- 0
-
- DITContentRuleDescription = "("
- numericoid ; Structural ObjectClass identifier
- [ "NAME" qdescrs ]
- [ "DESC" qdstring ]
- [ "OBSOLETE" ]
- [ "AUX" oids ] ; Auxiliary ObjectClasses
- [ "MUST" oids ] ; AttributeType identifiers
- [ "MAY" oids ] ; AttributeType identifiers
- [ "NOT" oids ] ; AttributeType identifiers
- ")"
-
- 0 2. Facsimile Telephone Number
-
- 3
-
- ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number' )
-
- Values in this syntax are encoded according to the following BNF:
-
- fax-number = printablestring [ "$" faxparameters ]
-
- faxparameters = faxparm / ( faxparm "$" faxparameters )
-
- faxparm = "twoDimensional" / "fineResolution" /
- "unlimitedLength" /
- "b4Length" / "a3Width" / "b4Width" / "uncompressed"
-
-
-
-Wahl, et. al. Standards Track [Page 19]
-
-RFC 2252 LADPv3 Attributes December 1997
-
-
- In the above, the first printablestring is the telephone number,
- based on E.123 [15], and the faxparm tokens represent fax parameters.
-
-6.13. Fax
-
- ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' )
-
- Values in this syntax are encoded as if they were octet strings
- containing Group 3 Fax images as defined in [7].
-
-6.14. Generalized Time
-
- ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' )
-
- Values in this syntax are encoded as printable strings, represented
- as specified in X.208. Note that the time zone must be specified.
- It is strongly recommended that GMT time be used. For example,
-
- 199412161032Z
-
-6.15. IA5 String
-
- ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )
-
- The encoding of a value in this syntax is the string value itself.
-
-6.16. INTEGER
-
- ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' )
-
- Values in this syntax are encoded as the decimal representation of
- their values, with each decimal digit represented by the its
- character equivalent. So the number 1321 is represented by the
- character string "1321".
-
-6.17. JPEG
-
- ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )
-
- Values in this syntax are encoded as strings containing JPEG images
- in the JPEG File Interchange Format (JFIF), as described in [8].
-
-6.18. Matching Rule Description
-
- ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' )
-
- Values of type matchingRules are encoded as strings according to the
- BNF given in section 4.5.
-
-
-
-Wahl, et. al. Standards Track [Page 20]
-
-RFC 2252 LADPv3 Attributes December 1997
-
-
-6.19. Matching Rule Use Description
-
- ( 1.3.6.1.4.1.1466.115.121.1.31 DESC 'Matching Rule Use Description'
- )
-
- Values of type matchingRuleUse are encoded as strings according to
- the BNF given in section 4.5.
-
-6.20. MHS OR Address
-
- ( 1.3.6.1.4.1.1466.115.121.1.33 DESC 'MHS OR Address' )
-
- Values in this syntax are encoded as strings, according to the format
- defined in [11].
-
-6.21. Name And Optional UID
-
- ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' )
-
- Values in this syntax are encoded according to the following BNF:
-
- NameAndOptionalUID = DistinguishedName [ "#" bitstring ]
-
- Although the '#' character may occur in a string representation of a
- distinguished name, no additional special quoting is done. This
- syntax has been added subsequent to RFC 1778.
-
- Example:
-
- 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B
-
-6.22. Name Form Description
-
- ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' )
-
- Values in this syntax are encoded according to the following BNF.
- Implementors should note that future versions of this document may
- have expanded this BNF to include additional terms.
-
- NameFormDescription = "(" whsp
- numericoid whsp ; NameForm identifier
- [ "NAME" qdescrs ]
- [ "DESC" qdstring ]
- [ "OBSOLETE" whsp ]
- "OC" woid ; Structural ObjectClass
- "MUST" oids ; AttributeTypes
- [ "MAY" oids ] ; AttributeTypes
- whsp ")"
-
-
-
-Wahl, et. al. Standards Track [Page 21]
-
-RFC 2252 LADPv3 Attributes December 1997
-
-
-6.23. Numeric String
-
- ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' )
-
- The encoding of a string in this syntax is the string value itself.
- Example:
-
- 1997
-
-6.24. Object Class Description
-
- ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' )
-
- Values in this syntax are encoded according to the BNF in section
- 4.4.
-
-6.25. OID
-
- ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' )
-
- Values in the Object Identifier syntax are encoded according to
- the BNF in section 4.1 for "oid".
-
- Example:
-
- 1.2.3.4
- cn
-
-6.26. Other Mailbox
-
- ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' )
-
- Values in this syntax are encoded according to the following BNF:
-
- otherMailbox = mailbox-type "$" mailbox
-
- mailbox-type = printablestring
-
- mailbox = <an encoded IA5 String>
-
- In the above, mailbox-type represents the type of mail system in
- which the mailbox resides, for example "MCIMail"; and mailbox is the
- actual mailbox in the mail system defined by mailbox-type.
-
-6.27. Postal Address
-
- ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' )
-
-
-
-
-Wahl, et. al. Standards Track [Page 22]
-
-RFC 2252 LADPv3 Attributes December 1997
-
-
- Values in this syntax are encoded according to the following BNF:
-
- postal-address = dstring *( "$" dstring )
-
- In the above, each dstring component of a postal address value is
- encoded as a value of type Directory String syntax. Backslashes and
- dollar characters, if they occur in the component, are quoted as
- described in section 4.3. Many servers limit the postal address to
- six lines of up to thirty characters.
-
- Example:
-
- 1234 Main St.$Anytown, CA 12345$USA
- \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA
-
-6.28. Presentation Address
-
- ( 1.3.6.1.4.1.1466.115.121.1.43 DESC 'Presentation Address' )
-
- Values in this syntax are encoded with the representation described
- in RFC 1278 [6].
-
-6.29. Printable String
-
- ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )
-
- The encoding of a value in this syntax is the string value itself.
- PrintableString is limited to the characters in production p of
- section 4.1.
-
- Example:
-
- This is a PrintableString
-
-6.30. Telephone Number
-
- ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )
-
- Values in this syntax are encoded as if they were Printable String
- types. Telephone numbers are recommended in X.520 to be in
- international form, as described in E.123 [15].
-
- Example:
-
- +1 512 305 0280
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 23]
-
-RFC 2252 LADPv3 Attributes December 1997
-
-
-6.31. UTC Time
-
- ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' )
-
- Values in this syntax are encoded as if they were printable strings
- with the strings containing a UTCTime value. This is historical; new
- attribute definitions SHOULD use GeneralizedTime instead.
-
-6.32. LDAP Syntax Description
-
- ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' )
-
- Values in this syntax are encoded according to the BNF in section
- 4.3.3.
-
-6.33. DIT Structure Rule Description
-
- ( 1.3.6.1.4.1.1466.115.121.1.17 DESC 'DIT Structure Rule Description'
- )
-
- Values with this syntax are encoded according to the following BNF:
-
- DITStructureRuleDescription = "(" whsp
- ruleidentifier whsp ; DITStructureRule identifier
- [ "NAME" qdescrs ]
- [ "DESC" qdstring ]
- [ "OBSOLETE" whsp ]
- "FORM" woid whsp ; NameForm
- [ "SUP" ruleidentifiers whsp ] ; superior DITStructureRules
- ")"
-
- ruleidentifier = integer
-
- ruleidentifiers = ruleidentifier |
- "(" whsp ruleidentifierlist whsp ")"
-
- ruleidentifierlist = [ ruleidentifier *( ruleidentifier ) ]
-
-7. Object Classes
-
- Servers SHOULD recognize all the names of standard classes from
- section 7 of [12].
-
-7.1. Extensible Object Class
-
- The extensibleObject object class, if present in an entry, permits
- that entry to optionally hold any attribute. The MAY attribute list
- of this class is implicitly the set of all attributes.
-
-
-
-Wahl, et. al. Standards Track [Page 24]
-
-RFC 2252 LADPv3 Attributes December 1997
-
-
- ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
- SUP top AUXILIARY )
-
- The mandatory attributes of the other object classes of this entry
- are still required to be present.
-
- Note that not all servers will implement this object class, and those
- which do not will reject requests to add entries which contain this
- object class, or modify an entry to add this object class.
-
-7.2. subschema
-
- This object class is used in the subschema entry.
-
- ( 2.5.20.1 NAME 'subschema' AUXILIARY
- MAY ( dITStructureRules $ nameForms $ ditContentRules $
- objectClasses $ attributeTypes $ matchingRules $
- matchingRuleUse ) )
-
- The ldapSyntaxes operational attribute may also be present in
- subschema entries.
-
-8. Matching Rules
-
- Servers which implement the extensibleMatch filter SHOULD allow all
- the matching rules listed in this section to be used in the
- extensibleMatch. In general these servers SHOULD allow matching
- rules to be used with all attribute types known to the server, when
- the assertion syntax of the matching rule is the same as the value
- syntax of the attribute.
-
- Servers MAY implement additional matching rules.
-
-8.1. Matching Rules used in Equality Filters
-
- Servers SHOULD be capable of performing the following matching rules.
-
- For all these rules, the assertion syntax is the same as the value
- syntax.
-
- ( 2.5.13.0 NAME 'objectIdentifierMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
-
- If the client supplies a filter using an objectIdentifierMatch whose
- matchValue oid is in the "descr" form, and the oid is not recognized
- by the server, then the filter is Undefined.
-
- ( 2.5.13.1 NAME 'distinguishedNameMatch'
-
-
-
-Wahl, et. al. Standards Track [Page 25]
-
-RFC 2252 LADPv3 Attributes December 1997
-
-
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
-
- ( 2.5.13.2 NAME 'caseIgnoreMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- ( 2.5.13.8 NAME 'numericStringMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
-
- ( 2.5.13.11 NAME 'caseIgnoreListMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
-
- ( 2.5.13.14 NAME 'integerMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
-
- ( 2.5.13.16 NAME 'bitStringMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
-
- ( 2.5.13.20 NAME 'telephoneNumberMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
-
- ( 2.5.13.22 NAME 'presentationAddressMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.43 )
-
- ( 2.5.13.23 NAME 'uniqueMemberMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
-
- ( 2.5.13.24 NAME 'protocolInformationMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.42 )
-
- ( 2.5.13.27 NAME 'generalizedTimeMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
-
- ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
-
- ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
-
- When performing the caseIgnoreMatch, caseIgnoreListMatch,
- telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
- multiple adjoining whitespace characters are treated the same as an
- individual space, and leading and trailing whitespace is ignored.
-
- Clients MUST NOT assume that servers are capable of transliteration
- of Unicode values.
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 26]
-
-RFC 2252 LADPv3 Attributes December 1997
-
-
-8.2. Matching Rules used in Inequality Filters
-
- Servers SHOULD be capable of performing the following matching rules,
- which are used in greaterOrEqual and lessOrEqual filters.
-
- ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
-
- ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- The sort ordering for a caseIgnoreOrderingMatch is implementation-
- dependent.
-
-8.3. Syntax and Matching Rules used in Substring Filters
-
- The Substring Assertion syntax is used only as the syntax of
- assertion values in the extensible match. It is not used as the
- syntax of attributes, or in the substring filter.
-
- ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' )
-
- The Substring Assertion is encoded according to the following BNF:
-
- substring = [initial] any [final]
- initial = value
- any = "*" *(value "*")
- final = value
-
- The <value> production is UTF-8 encoded string. Should the backslash
- or asterix characters be present in a production of <value>, they are
- quoted as described in section 4.3.
-
- Servers SHOULD be capable of performing the following matching rules,
- which are used in substring filters.
-
- ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
-
- ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
-
- ( 2.5.13.10 NAME 'numericStringSubstringsMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
-
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 27]
-
-RFC 2252 LADPv3 Attributes December 1997
-
-
-8.4. Matching Rules for Subschema Attributes
-
- Servers which allow subschema entries to be modified by clients MUST
- support the following matching rules, as they are the equality
- matching rules for several of the subschema attributes.
-
- ( 2.5.13.29 NAME 'integerFirstComponentMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
-
- ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
-
- Implementors should note that the assertion syntax of these matching
- rules, an INTEGER or OID, is different from the value syntax of
- attributes for which this is the equality matching rule.
-
- If the client supplies an extensible filter using an
- objectIdentifierFirstComponentMatch whose matchValue is in the
- "descr" form, and the OID is not recognized by the server, then the
- filter is Undefined.
-
-9. Security Considerations
-
-9.1. Disclosure
-
- Attributes of directory entries are used to provide descriptive
- information about the real-world objects they represent, which can be
- people, organizations or devices. Most countries have privacy laws
- regarding the publication of information about people.
-
-9.2. Use of Attribute Values in Security Applications
-
- The transformations of an AttributeValue value from its X.501 form to
- an LDAP string representation are not always reversible back to the
- same BER or DER form. An example of a situation which requires the
- DER form of a distinguished name is the verification of an X.509
- certificate.
-
- For example, a distinguished name consisting of one RDN with one AVA,
- in which the type is commonName and the value is of the TeletexString
- choice with the letters 'Sam' would be represented in LDAP as the
- string CN=Sam. Another distinguished name in which the value is
- still 'Sam' but of the PrintableString choice would have the same
- representation CN=Sam.
-
- Applications which require the reconstruction of the DER form of the
- value SHOULD NOT use the string representation of attribute syntaxes
- when converting a value to LDAP format. Instead it SHOULD use the
-
-
-
-Wahl, et. al. Standards Track [Page 28]
-
-RFC 2252 LADPv3 Attributes December 1997
-
-
- Binary syntax.
-
-10. Acknowledgements
-
- This document is based substantially on RFC 1778, written by Tim
- Howes, Steve Kille, Wengyik Yeong and Colin Robbins.
-
- Many of the attribute syntax encodings defined in this and related
- documents are adapted from those used in the QUIPU and the IC R3
- X.500 implementations. The contributions of the authors of both these
- implementations in the specification of syntaxes are gratefully
- acknowledged.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 29]
-
-RFC 2252 LADPv3 Attributes December 1997
-
-
-11. Authors' Addresses
-
- Mark Wahl
- Critical Angle Inc.
- 4815 West Braker Lane #502-385
- Austin, TX 78759
- USA
-
- Phone: +1 512 372-3160
- EMail: M.Wahl@critical-angle.com
-
- Andy Coulbeck
- Isode Inc.
- 9390 Research Blvd Suite 305
- Austin, TX 78759
- USA
-
- Phone: +1 512 231-8993
- EMail: A.Coulbeck@isode.com
-
- Tim Howes
- Netscape Communications Corp.
- 501 E. Middlefield Rd, MS MV068
- Mountain View, CA 94043
- USA
-
- Phone: +1 650 937-3419
- EMail: howes@netscape.com
-
- Steve Kille
- Isode Limited
- The Dome, The Square
- Richmond
- TW9 1DT
- UK
-
- Phone: +44-181-332-9091
- EMail: S.Kille@isode.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 30]
-
-RFC 2252 LADPv3 Attributes December 1997
-
-
-12. Bibliography
-
- [1] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access
- Protocol (v3)", RFC 2251, December 1997.
-
- [2] The Directory: Selected Attribute Types. ITU-T Recommendation
- X.520, 1993.
-
- [3] The Directory: Models. ITU-T Recommendation X.501, 1993.
-
- [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", RFC 2119, March 1997.
-
- [5] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Access
- Protocol (v3): UTF-8 String Representation of
- Distinguished Names", RFC 2253, December 1997.
-
- [6] Kille, S., "A String Representation for Presentation Addresses",
- RFC 1278, November 1991.
-
- [7] Terminal Equipment and Protocols for Telematic Services -
- Standardization of Group 3 facsimile apparatus for document
- transmission. CCITT, Recommendation T.4.
-
- [8] JPEG File Interchange Format (Version 1.02). Eric Hamilton,
- C-Cube Microsystems, Milpitas, CA, September 1, 1992.
-
- [9] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
- 10646", RFC 2044, October 1996.
-
- [10] Universal Multiple-Octet Coded Character Set (UCS) -
- Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 :
- 1993 (With amendments).
-
- [11] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021
- and RFC 822", RFC 1327, May 1992.
-
- [12] Wahl, M., "A Summary of the X.500(96) User Schema for use
- with LDAPv3", RFC 2256, December 1997.
-
- [13] Crocker, D., "Standard of the Format of ARPA-Internet Text
- Messages", STD 11, RFC 822, August 1982.
-
- [14] ISO 3166, "Codes for the representation of names of countries".
-
- [15] ITU-T Rec. E.123, Notation for national and international
- telephone numbers, 1988.
-
-
-
-
-Wahl, et. al. Standards Track [Page 31]
-
-RFC 2252 LADPv3 Attributes December 1997
-
-
-13. Full Copyright Statement
-
- Copyright (C) The Internet Society (1997). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wahl, et. al. Standards Track [Page 32]
-
diff --git a/doc/rfc/rfc2253.txt b/doc/rfc/rfc2253.txt
deleted file mode 100644
index a7439eed776d3e3ff3038eefb85ea54241169d34..0000000000000000000000000000000000000000
--- a/doc/rfc/rfc2253.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group M. Wahl
-Request for Comments: 2253 Critical Angle Inc.
-Obsoletes: 1779 S. Kille
-Category: Standards Track Isode Ltd.
- T. Howes
- Netscape Communications Corp.
- December 1997
-
-
- Lightweight Directory Access Protocol (v3):
- UTF-8 String Representation of Distinguished Names
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (1997). All Rights Reserved.
-
-IESG Note
-
- This document describes a directory access protocol that provides
- both read and update access. Update access requires secure
- authentication, but this document does not mandate implementation of
- any satisfactory authentication mechanisms.
-
- In accordance with RFC 2026, section 4.4.1, this specification is
- being approved by IESG as a Proposed Standard despite this
- limitation, for the following reasons:
-
- a. to encourage implementation and interoperability testing of
- these protocols (with or without update access) before they
- are deployed, and
-
- b. to encourage deployment and use of these protocols in read-only
- applications. (e.g. applications where LDAPv3 is used as
- a query language for directories which are updated by some
- secure mechanism other than LDAP), and
-
- c. to avoid delaying the advancement and deployment of other Internet
- standards-track protocols which require the ability to query, but
- not update, LDAPv3 directory servers.
-
-
-
-
-Wahl, et. al. Proposed Standard [Page 1]
-
-RFC 2253 LADPv3 Distinguished Names December 1997
-
-
- Readers are hereby warned that until mandatory authentication
- mechanisms are standardized, clients and servers written according to
- this specification which make use of update functionality are
- UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
- IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
-
- Implementors are hereby discouraged from deploying LDAPv3 clients or
- servers which implement the update functionality, until a Proposed
- Standard for mandatory authentication in LDAPv3 has been approved and
- published as an RFC.
-
-Abstract
-
- The X.500 Directory uses distinguished names as the primary keys to
- entries in the directory. Distinguished Names are encoded in ASN.1
- in the X.500 Directory protocols. In the Lightweight Directory
- Access Protocol, a string representation of distinguished names is
- transferred. This specification defines the string format for
- representing names, which is designed to give a clean representation
- of commonly used distinguished names, while being able to represent
- any distinguished name.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [6].
-
-1. Background
-
- This specification assumes familiarity with X.500 [1], and the
- concept of Distinguished Name. It is important to have a common
- format to be able to unambiguously represent a distinguished name.
- The primary goal of this specification is ease of encoding and
- decoding. A secondary goal is to have names that are human readable.
- It is not expected that LDAP clients with a human user interface
- would display these strings directly to the user, but would most
- likely be performing translations (such as expressing attribute type
- names in one of the local national languages).
-
-2. Converting DistinguishedName from ASN.1 to a String
-
- In X.501 [2] the ASN.1 structure of distinguished name is defined as:
-
- DistinguishedName ::= RDNSequence
-
- RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
-
-
-
-
-
-
-Wahl, et. al. Proposed Standard [Page 2]
-
-RFC 2253 LADPv3 Distinguished Names December 1997
-
-
- RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
- AttributeTypeAndValue
-
- AttributeTypeAndValue ::= SEQUENCE {
- type AttributeType,
- value AttributeValue }
-
- The following sections define the algorithm for converting from an
- ASN.1 structured representation to a UTF-8 string representation.
-
-2.1. Converting the RDNSequence
-
- If the RDNSequence is an empty sequence, the result is the empty or
- zero length string.
-
- Otherwise, the output consists of the string encodings of each
- RelativeDistinguishedName in the RDNSequence (according to 2.2),
- starting with the last element of the sequence and moving backwards
- toward the first.
-
- The encodings of adjoining RelativeDistinguishedNames are separated
- by a comma character (',' ASCII 44).
-
-2.2. Converting RelativeDistinguishedName
-
- When converting from an ASN.1 RelativeDistinguishedName to a string,
- the output consists of the string encodings of each
- AttributeTypeAndValue (according to 2.3), in any order.
-
- Where there is a multi-valued RDN, the outputs from adjoining
- AttributeTypeAndValues are separated by a plus ('+' ASCII 43)
- character.
-
-2.3. Converting AttributeTypeAndValue
-
- The AttributeTypeAndValue is encoded as the string representation of
- the AttributeType, followed by an equals character ('=' ASCII 61),
- followed by the string representation of the AttributeValue. The
- encoding of the AttributeValue is given in section 2.4.
-
- If the AttributeType is in a published table of attribute types
- associated with LDAP [4], then the type name string from that table
- is used, otherwise it is encoded as the dotted-decimal encoding of
- the AttributeType's OBJECT IDENTIFIER. The dotted-decimal notation is
- described in [3]. As an example, strings for a few of the attribute
- types frequently seen in RDNs include:
-
-
-
-
-
-Wahl, et. al. Proposed Standard [Page 3]
-
-RFC 2253 LADPv3 Distinguished Names December 1997
-
-
- String X.500 AttributeType
- ------------------------------
- CN commonName
- L localityName
- ST stateOrProvinceName
- O organizationName
- OU organizationalUnitName
- C countryName
- STREET streetAddress
- DC domainComponent
- UID userid
-
-2.4. Converting an AttributeValue from ASN.1 to a String
-
- If the AttributeValue is of a type which does not have a string
- representation defined for it, then it is simply encoded as an
- octothorpe character ('#' ASCII 35) followed by the hexadecimal
- representation of each of the bytes of the BER encoding of the X.500
- AttributeValue. This form SHOULD be used if the AttributeType is of
- the dotted-decimal form.
-
- Otherwise, if the AttributeValue is of a type which has a string
- representation, the value is converted first to a UTF-8 string
- according to its syntax specification (see for example section 6 of
- [4]).
-
- If the UTF-8 string does not have any of the following characters
- which need escaping, then that string can be used as the string
- representation of the value.
-
- o a space or "#" character occurring at the beginning of the
- string
-
- o a space character occurring at the end of the string
-
- o one of the characters ",", "+", """, "\", "<", ">" or ";"
-
- Implementations MAY escape other characters.
-
- If a character to be escaped is one of the list shown above, then it
- is prefixed by a backslash ('\' ASCII 92).
-
- Otherwise the character to be escaped is replaced by a backslash and
- two hex digits, which form a single byte in the code of the
- character.
-
- Examples of the escaping mechanism are shown in section 5.
-
-
-
-
-Wahl, et. al. Proposed Standard [Page 4]
-
-RFC 2253 LADPv3 Distinguished Names December 1997
-
-
-3. Parsing a String back to a Distinguished Name
-
- The structure of the string is specified in a BNF grammar, based on
- the grammar defined in RFC 822 [5]. Server implementations parsing a
- DN string generated by an LDAPv2 client MUST also accept (and ignore)
- the variants given in section 4 of this document.
-
-distinguishedName = [name] ; may be empty string
-
-name = name-component *("," name-component)
-
-name-component = attributeTypeAndValue *("+" attributeTypeAndValue)
-
-attributeTypeAndValue = attributeType "=" attributeValue
-
-attributeType = (ALPHA 1*keychar) / oid
-keychar = ALPHA / DIGIT / "-"
-
-oid = 1*DIGIT *("." 1*DIGIT)
-
-attributeValue = string
-
-string = *( stringchar / pair )
- / "#" hexstring
- / QUOTATION *( quotechar / pair ) QUOTATION ; only from v2
-
-quotechar = <any character except "\" or QUOTATION >
-
-special = "," / "=" / "+" / "<" / ">" / "#" / ";"
-
-pair = "\" ( special / "\" / QUOTATION / hexpair )
-stringchar = <any character except one of special, "\" or QUOTATION >
-
-hexstring = 1*hexpair
-hexpair = hexchar hexchar
-
-hexchar = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
- / "a" / "b" / "c" / "d" / "e" / "f"
-
-ALPHA = <any ASCII alphabetic character>
- ; (decimal 65-90 and 97-122)
-DIGIT = <any ASCII decimal digit> ; (decimal 48-57)
-QUOTATION = <the ASCII double quotation mark character '"' decimal 34>
-
-
-
-
-
-
-
-
-Wahl, et. al. Proposed Standard [Page 5]
-
-RFC 2253 LADPv3 Distinguished Names December 1997
-
-
-4. Relationship with RFC 1779 and LDAPv2
-
- The syntax given in this document is more restrictive than the syntax
- in RFC 1779. Implementations parsing a string generated by an LDAPv2
- client MUST accept the syntax of RFC 1779. Implementations MUST NOT,
- however, generate any of the RFC 1779 encodings which are not
- described above in section 2.
-
- Implementations MUST allow a semicolon character to be used instead
- of a comma to separate RDNs in a distinguished name, and MUST also
- allow whitespace characters to be present on either side of the comma
- or semicolon. The whitespace characters are ignored, and the
- semicolon replaced with a comma.
-
- Implementations MUST allow an oid in the attribute type to be
- prefixed by one of the character strings "oid." or "OID.".
-
- Implementations MUST allow for space (' ' ASCII 32) characters to be
- present between name-component and ',', between attributeTypeAndValue
- and '+', between attributeType and '=', and between '=' and
- attributeValue. These space characters are ignored when parsing.
-
- Implementations MUST allow a value to be surrounded by quote ('"'
- ASCII 34) characters, which are not part of the value. Inside the
- quoted value, the following characters can occur without any
- escaping:
-
- ",", "=", "+", "<", ">", "#" and ";"
-
-5. Examples
-
- This notation is designed to be convenient for common forms of name.
- This section gives a few examples of distinguished names written
- using this notation. First is a name containing three relative
- distinguished names (RDNs):
-
- CN=Steve Kille,O=Isode Limited,C=GB
-
- Here is an example name containing three RDNs, in which the first RDN
- is multi-valued:
-
- OU=Sales+CN=J. Smith,O=Widget Inc.,C=US
-
- This example shows the method of quoting of a comma in an
- organization name:
-
- CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB
-
-
-
-
-Wahl, et. al. Proposed Standard [Page 6]
-
-RFC 2253 LADPv3 Distinguished Names December 1997
-
-
- An example name in which a value contains a carriage return
- character:
-
- CN=Before\0DAfter,O=Test,C=GB
-
- An example name in which an RDN was of an unrecognized type. The
- value is the BER encoding of an OCTET STRING containing two bytes
- 0x48 and 0x69.
-
- 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB
-
- Finally, an example of an RDN surname value consisting of 5 letters:
-
- Unicode Letter Description 10646 code UTF-8 Quoted
- =============================== ========== ====== =======
- LATIN CAPITAL LETTER L U0000004C 0x4C L
- LATIN SMALL LETTER U U00000075 0x75 u
- LATIN SMALL LETTER C WITH CARON U0000010D 0xC48D \C4\8D
- LATIN SMALL LETTER I U00000069 0x69 i
- LATIN SMALL LETTER C WITH ACUTE U00000107 0xC487 \C4\87
-
- Could be written in printable ASCII (useful for debugging purposes):
-
- SN=Lu\C4\8Di\C4\87
-
-6. References
-
- [1] The Directory -- overview of concepts, models and services.
- ITU-T Rec. X.500(1993).
-
- [2] The Directory -- Models. ITU-T Rec. X.501(1993).
-
- [3] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
- Access Protocol (v3)", RFC 2251, December 1997.
-
- [4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
- Directory Access Protocol (v3): Attribute Syntax Definitions",
- RFC 2252, December 1997.
-
- [5] Crocker, D., "Standard of the Format of ARPA-Internet Text
- Messages", STD 11, RFC 822, August 1982.
-
- [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", RFC 2119.
-
-
-
-
-
-
-
-Wahl, et. al. Proposed Standard [Page 7]
-
-RFC 2253 LADPv3 Distinguished Names December 1997
-
-
-7. Security Considerations
-
-7.1. Disclosure
-
- Distinguished Names typically consist of descriptive information
- about the entries they name, which can be people, organizations,
- devices or other real-world objects. This frequently includes some
- of the following kinds of information:
-
- - the common name of the object (i.e. a person's full name)
- - an email or TCP/IP address
- - its physical location (country, locality, city, street address)
- - organizational attributes (such as department name or affiliation)
-
- Most countries have privacy laws regarding the publication of
- information about people.
-
-7.2. Use of Distinguished Names in Security Applications
-
- The transformations of an AttributeValue value from its X.501 form to
- an LDAP string representation are not always reversible back to the
- same BER or DER form. An example of a situation which requires the
- DER form of a distinguished name is the verification of an X.509
- certificate.
-
- For example, a distinguished name consisting of one RDN with one AVA,
- in which the type is commonName and the value is of the TeletexString
- choice with the letters 'Sam' would be represented in LDAP as the
- string CN=Sam. Another distinguished name in which the value is
- still 'Sam' but of the PrintableString choice would have the same
- representation CN=Sam.
-
- Applications which require the reconstruction of the DER form of the
- value SHOULD NOT use the string representation of attribute syntaxes
- when converting a distinguished name to the LDAP format. Instead,
- they SHOULD use the hexadecimal form prefixed by the octothorpe ('#')
- as described in the first paragraph of section 2.4.
-
-8. Authors' Addresses
-
- Mark Wahl
- Critical Angle Inc.
- 4815 W. Braker Lane #502-385
- Austin, TX 78759
- USA
-
- EMail: M.Wahl@critical-angle.com
-
-
-
-
-Wahl, et. al. Proposed Standard [Page 8]
-
-RFC 2253 LADPv3 Distinguished Names December 1997
-
-
- Steve Kille
- Isode Ltd.
- The Dome
- The Square
- Richmond, Surrey
- TW9 1DT
- England
-
- Phone: +44-181-332-9091
- EMail: S.Kille@ISODE.COM
-
-
- Tim Howes
- Netscape Communications Corp.
- 501 E. Middlefield Rd, MS MV068
- Mountain View, CA 94043
- USA
-
- Phone: +1 650 937-3419
- EMail: howes@netscape.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wahl, et. al. Proposed Standard [Page 9]
-
-RFC 2253 LADPv3 Distinguished Names December 1997
-
-
-9. Full Copyright Statement
-
- Copyright (C) The Internet Society (1997). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wahl, et. al. Proposed Standard [Page 10]
-
diff --git a/doc/rfc/rfc2254.txt b/doc/rfc/rfc2254.txt
deleted file mode 100644
index 323fdb00b7c5baf83757892505c307fc472dd1ee..0000000000000000000000000000000000000000
--- a/doc/rfc/rfc2254.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group T. Howes
-Request for Comments: 2254 Netscape Communications Corp.
-Category: Standards Track December 1997
-
-
- The String Representation of LDAP Search Filters
-
-1. Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (1997). All Rights Reserved.
-
-IESG Note
-
- This document describes a directory access protocol that provides
- both read and update access. Update access requires secure
- authentication, but this document does not mandate implementation of
- any satisfactory authentication mechanisms.
-
- In accordance with RFC 2026, section 4.4.1, this specification is
- being approved by IESG as a Proposed Standard despite this
- limitation, for the following reasons:
-
- a. to encourage implementation and interoperability testing of
- these protocols (with or without update access) before they
- are deployed, and
-
- b. to encourage deployment and use of these protocols in read-only
- applications. (e.g. applications where LDAPv3 is used as
- a query language for directories which are updated by some
- secure mechanism other than LDAP), and
-
- c. to avoid delaying the advancement and deployment of other Internet
- standards-track protocols which require the ability to query, but
- not update, LDAPv3 directory servers.
-
-
-
-
-
-
-
-
-
-Howes Standards Track [Page 1]
-
-RFC 2254 String Representation of LDAP December 1997
-
-
- Readers are hereby warned that until mandatory authentication
- mechanisms are standardized, clients and servers written according to
- this specification which make use of update functionality are
- UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
- IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
-
- Implementors are hereby discouraged from deploying LDAPv3 clients or
- servers which implement the update functionality, until a Proposed
- Standard for mandatory authentication in LDAPv3 has been approved and
- published as an RFC.
-
-2. Abstract
-
- The Lightweight Directory Access Protocol (LDAP) [1] defines a
- network representation of a search filter transmitted to an LDAP
- server. Some applications may find it useful to have a common way of
- representing these search filters in a human-readable form. This
- document defines a human-readable string format for representing LDAP
- search filters.
-
- This document replaces RFC 1960, extending the string LDAP filter
- definition to include support for LDAP version 3 extended match
- filters, and including support for representing the full range of
- possible LDAP search filters.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Howes Standards Track [Page 2]
-
-RFC 2254 String Representation of LDAP December 1997
-
-
-3. LDAP Search Filter Definition
-
- An LDAPv3 search filter is defined in Section 4.5.1 of [1] as
- follows:
-
- Filter ::= CHOICE {
- and [0] SET OF Filter,
- or [1] SET OF Filter,
- not [2] Filter,
- equalityMatch [3] AttributeValueAssertion,
- substrings [4] SubstringFilter,
- greaterOrEqual [5] AttributeValueAssertion,
- lessOrEqual [6] AttributeValueAssertion,
- present [7] AttributeDescription,
- approxMatch [8] AttributeValueAssertion,
- extensibleMatch [9] MatchingRuleAssertion
- }
-
- SubstringFilter ::= SEQUENCE {
- type AttributeDescription,
- SEQUENCE OF CHOICE {
- initial [0] LDAPString,
- any [1] LDAPString,
- final [2] LDAPString
- }
- }
-
- AttributeValueAssertion ::= SEQUENCE {
- attributeDesc AttributeDescription,
- attributeValue AttributeValue
- }
-
- MatchingRuleAssertion ::= SEQUENCE {
- matchingRule [1] MatchingRuleID OPTIONAL,
- type [2] AttributeDescription OPTIONAL,
- matchValue [3] AssertionValue,
- dnAttributes [4] BOOLEAN DEFAULT FALSE
- }
-
- AttributeDescription ::= LDAPString
-
- AttributeValue ::= OCTET STRING
-
- MatchingRuleID ::= LDAPString
-
- AssertionValue ::= OCTET STRING
-
- LDAPString ::= OCTET STRING
-
-
-
-Howes Standards Track [Page 3]
-
-RFC 2254 String Representation of LDAP December 1997
-
-
- where the LDAPString above is limited to the UTF-8 encoding of the
- ISO 10646 character set [4]. The AttributeDescription is a string
- representation of the attribute description and is defined in [1].
- The AttributeValue and AssertionValue OCTET STRING have the form
- defined in [2]. The Filter is encoded for transmission over a
- network using the Basic Encoding Rules defined in [3], with
- simplifications described in [1].
-
-4. String Search Filter Definition
-
- The string representation of an LDAP search filter is defined by the
- following grammar, following the ABNF notation defined in [5]. The
- filter format uses a prefix notation.
-
- filter = "(" filtercomp ")"
- filtercomp = and / or / not / item
- and = "&" filterlist
- or = "|" filterlist
- not = "!" filter
- filterlist = 1*filter
- item = simple / present / substring / extensible
- simple = attr filtertype value
- filtertype = equal / approx / greater / less
- equal = "="
- approx = "~="
- greater = ">="
- less = "<="
- extensible = attr [":dn"] [":" matchingrule] ":=" value
- / [":dn"] ":" matchingrule ":=" value
- present = attr "=*"
- substring = attr "=" [initial] any [final]
- initial = value
- any = "*" *(value "*")
- final = value
- attr = AttributeDescription from Section 4.1.5 of [1]
- matchingrule = MatchingRuleId from Section 4.1.9 of [1]
- value = AttributeValue from Section 4.1.6 of [1]
-
- The attr, matchingrule, and value constructs are as described in the
- corresponding section of [1] given above.
-
-
-
-
-
-
-
-
-
-
-
-Howes Standards Track [Page 4]
-
-RFC 2254 String Representation of LDAP December 1997
-
-
- If a value should contain any of the following characters
-
- Character ASCII value
- ---------------------------
- * 0x2a
- ( 0x28
- ) 0x29
- \ 0x5c
- NUL 0x00
-
- the character must be encoded as the backslash '\' character (ASCII
- 0x5c) followed by the two hexadecimal digits representing the ASCII
- value of the encoded character. The case of the two hexadecimal
- digits is not significant.
-
- This simple escaping mechanism eliminates filter-parsing ambiguities
- and allows any filter that can be represented in LDAP to be
- represented as a NUL-terminated string. Other characters besides the
- ones listed above may be escaped using this mechanism, for example,
- non-printing characters.
-
- For example, the filter checking whether the "cn" attribute contained
- a value with the character "*" anywhere in it would be represented as
- "(cn=*\2a*)".
-
- Note that although both the substring and present productions in the
- grammar above can produce the "attr=*" construct, this construct is
- used only to denote a presence filter.
-
-5. Examples
-
- This section gives a few examples of search filters written using
- this notation.
-
- (cn=Babs Jensen)
- (!(cn=Tim Howes))
- (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))
- (o=univ*of*mich*)
-
- The following examples illustrate the use of extensible matching.
-
- (cn:1.2.3.4.5:=Fred Flintstone)
- (sn:dn:2.4.6.8.10:=Barney Rubble)
- (o:dn:=Ace Industry)
- (:dn:2.4.6.8.10:=Dino)
-
-
-
-
-
-
-Howes Standards Track [Page 5]
-
-RFC 2254 String Representation of LDAP December 1997
-
-
- The second example illustrates the use of the ":dn" notation to
- indicate that matching rule "2.4.6.8.10" should be used when making
- comparisons, and that the attributes of an entry's distinguished name
- should be considered part of the entry when evaluating the match.
-
- The third example denotes an equality match, except that DN
- components should be considered part of the entry when doing the
- match.
-
- The fourth example is a filter that should be applied to any
- attribute supporting the matching rule given (since the attr has been
- left off). Attributes supporting the matching rule contained in the
- DN should also be considered.
-
- The following examples illustrate the use of the escaping mechanism.
-
- (o=Parens R Us \28for all your parenthetical needs\29)
- (cn=*\2A*)
- (filename=C:\5cMyFile)
- (bin=\00\00\00\04)
- (sn=Lu\c4\8di\c4\87)
-
- The first example shows the use of the escaping mechanism to
- represent parenthesis characters. The second shows how to represent a
- "*" in a value, preventing it from being interpreted as a substring
- indicator. The third illustrates the escaping of the backslash
- character.
-
- The fourth example shows a filter searching for the four-byte value
- 0x00000004, illustrating the use of the escaping mechanism to
- represent arbitrary data, including NUL characters.
-
- The final example illustrates the use of the escaping mechanism to
- represent various non-ASCII UTF-8 characters.
-
-6. Security Considerations
-
- This memo describes a string representation of LDAP search filters.
- While the representation itself has no known security implications,
- LDAP search filters do. They are interpreted by LDAP servers to
- select entries from which data is retrieved. LDAP servers should
- take care to protect the data they maintain from unauthorized access.
-
-
-
-
-
-
-
-
-
-Howes Standards Track [Page 6]
-
-RFC 2254 String Representation of LDAP December 1997
-
-
-7. References
-
- [1] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access
- Protocol (v3)", RFC 2251, December 1997.
-
- [2] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight
- Directory Access Protocol (v3): Attribute Syntax Definitions", RFC
- 2252, December 1997.
-
- [3] Specification of ASN.1 encoding rules: Basic, Canonical, and
- Distinguished Encoding Rules, ITU-T Recommendation X.690, 1994.
-
- [4] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
- 10646", RFC 2044, October 1996.
-
- [5] Crocker, D., "Standard for the Format of ARPA Internet Text
- Messages", STD 11, RFC 822, August 1982.
-
-8. Author's Address
-
- Tim Howes
- Netscape Communications Corp.
- 501 E. Middlefield Road
- Mountain View, CA 94043
- USA
-
- Phone: +1 415 937-3419
- EMail: howes@netscape.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Howes Standards Track [Page 7]
-
-RFC 2254 String Representation of LDAP December 1997
-
-
-9. Full Copyright Statement
-
- Copyright (C) The Internet Society (1997). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Howes Standards Track [Page 8]
-
diff --git a/doc/rfc/rfc2255.txt b/doc/rfc/rfc2255.txt
deleted file mode 100644
index a03567154e5c5f6cbc4e40ac7d2ef494dc822bd8..0000000000000000000000000000000000000000
--- a/doc/rfc/rfc2255.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-Network Working Group T. Howes
-Request for Comments: 2255 M. Smith
-Category: Standards Track Netscape Communications Corp.
- December 1997
-
-
- The LDAP URL Format
-
-1. Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (1997). All Rights Reserved.
-
-IESG NOTE
-
- This document describes a directory access protocol that provides
- both read and update access. Update access requires secure
- authentication, but this document does not mandate implementation of
- any satisfactory authentication mechanisms.
-
- In accordance with RFC 2026, section 4.4.1, this specification is
- being approved by IESG as a Proposed Standard despite this
- limitation, for the following reasons:
-
- a. to encourage implementation and interoperability testing of
- these protocols (with or without update access) before they
- are deployed, and
-
- b. to encourage deployment and use of these protocols in read-only
- applications. (e.g. applications where LDAPv3 is used as
- a query language for directories which are updated by some
- secure mechanism other than LDAP), and
-
- c. to avoid delaying the advancement and deployment of other Internet
- standards-track protocols which require the ability to query, but
- not update, LDAPv3 directory servers.
-
-
-
-
-
-
-
-
-Howes & Smith Standards Track [Page 1]
-
-RFC 2255 LDAP URL Format December 1997
-
-
- Readers are hereby warned that until mandatory authentication
- mechanisms are standardized, clients and servers written according to
- this specification which make use of update functionality are
- UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
- IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
-
- Implementors are hereby discouraged from deploying LDAPv3 clients or
- servers which implement the update functionality, until a Proposed
- Standard for mandatory authentication in LDAPv3 has been approved and
- published as an RFC.
-
-2. Abstract
-
- LDAP is the Lightweight Directory Access Protocol, defined in [1],
- [2] and [3]. This document describes a format for an LDAP Uniform
- Resource Locator. The format describes an LDAP search operation to
- perform to retrieve information from an LDAP directory. This document
- replaces RFC 1959. It updates the LDAP URL format for version 3 of
- LDAP and clarifies how LDAP URLs are resolved. This document also
- defines an extension mechanism for LDAP URLs, so that future
- documents can extend their functionality, for example, to provide
- access to new LDAPv3 extensions as they are defined.
-
- The key words "MUST", "MAY", and "SHOULD" used in this document are
- to be interpreted as described in [6].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Howes & Smith Standards Track [Page 2]
-
-RFC 2255 LDAP URL Format December 1997
-
-
-3. URL Definition
-
- An LDAP URL begins with the protocol prefix "ldap" and is defined by
- the following grammar.
-
- ldapurl = scheme "://" [hostport] ["/"
- [dn ["?" [attributes] ["?" [scope]
- ["?" [filter] ["?" extensions]]]]]]
- scheme = "ldap"
- attributes = attrdesc *("," attrdesc)
- scope = "base" / "one" / "sub"
- dn = distinguishedName from Section 3 of [1]
- hostport = hostport from Section 5 of RFC 1738 [5]
- attrdesc = AttributeDescription from Section 4.1.5 of [2]
- filter = filter from Section 4 of [4]
- extensions = extension *("," extension)
- extension = ["!"] extype ["=" exvalue]
- extype = token / xtoken
- exvalue = LDAPString from section 4.1.2 of [2]
- token = oid from section 4.1 of [3]
- xtoken = ("X-" / "x-") token
-
- The "ldap" prefix indicates an entry or entries residing in the LDAP
- server running on the given hostname at the given portnumber. The
- default LDAP port is TCP port 389. If no hostport is given, the
- client must have some apriori knowledge of an appropriate LDAP server
- to contact.
-
- The dn is an LDAP Distinguished Name using the string format
- described in [1]. It identifies the base object of the LDAP search.
-
- ldapurl = scheme "://" [hostport] ["/"
- [dn ["?" [attributes] ["?" [scope]
- ["?" [filter] ["?" extensions]]]]]]
- scheme = "ldap"
- attributes = attrdesc *("," attrdesc)
- scope = "base" / "one" / "sub"
- dn = distinguishedName from Section 3 of [1]
- hostport = hostport from Section 5 of RFC 1738 [5]
- attrdesc = AttributeDescription from Section 4.1.5 of [2]
- filter = filter from Section 4 of [4]
- extensions = extension *("," extension)
- extension = ["!"] extype ["=" exvalue]
- extype = token / xtoken
- exvalue = LDAPString from section 4.1.2 of [2]
- token = oid from section 4.1 of [3]
- xtoken = ("X-" / "x-") token
-
-
-
-
-Howes & Smith Standards Track [Page 3]
-
-RFC 2255 LDAP URL Format December 1997
-
-
- The "ldap" prefix indicates an entry or entries residing in the LDAP
- server running on the given hostname at the given portnumber. The
- default LDAP port is TCP port 389. If no hostport is given, the
- client must have some apriori knowledge of an appropriate LDAP server
- to contact.
-
- The dn is an LDAP Distinguished Name using the string format
- described in [1]. It identifies the base object of the LDAP search.
-
- The attributes construct is used to indicate which attributes should
- be returned from the entry or entries. Individual attrdesc names are
- as defined for AttributeDescription in [2]. If the attributes part
- is omitted, all user attributes of the entry or entries should be
- requested (e.g., by setting the attributes field
- AttributeDescriptionList in the LDAP search request to a NULL list,
- or (in LDAPv3) by requesting the special attribute name "*").
-
- The scope construct is used to specify the scope of the search to
- perform in the given LDAP server. The allowable scopes are "base"
- for a base object search, "one" for a one-level search, or "sub" for
- a subtree search. If scope is omitted, a scope of "base" is assumed.
-
- The filter is used to specify the search filter to apply to entries
- within the specified scope during the search. It has the format
- specified in [4]. If filter is omitted, a filter of
- "(objectClass=*)" is assumed.
-
- The extensions construct provides the LDAP URL with an extensibility
- mechanism, allowing the capabilities of the URL to be extended in the
- future. Extensions are a simple comma-separated list of type=value
- pairs, where the =value portion MAY be omitted for options not
- requiring it. Each type=value pair is a separate extension. These
- LDAP URL extensions are not necessarily related to any of the LDAPv3
- extension mechanisms. Extensions may be supported or unsupported by
- the client resolving the URL. An extension prefixed with a '!'
- character (ASCII 33) is critical. An extension not prefixed with a '
- !' character is non-critical.
-
- If an extension is supported by the client, the client MUST obey the
- extension if the extension is critical. The client SHOULD obey
- supported extensions that are non-critical.
-
- If an extension is unsupported by the client, the client MUST NOT
- process the URL if the extension is critical. If an unsupported
- extension is non-critical, the client MUST ignore the extension.
-
-
-
-
-
-
-Howes & Smith Standards Track [Page 4]
-
-RFC 2255 LDAP URL Format December 1997
-
-
- If a critical extension cannot be processed successfully by the
- client, the client MUST NOT process the URL. If a non-critical
- extension cannot be processed successfully by the client, the client
- SHOULD ignore the extension.
-
- Extension types prefixed by "X-" or "x-" are reserved for use in
- bilateral agreements between communicating parties. Other extension
- types MUST be defined in this document, or in other standards-track
- documents.
-
- One LDAP URL extension is defined in this document in the next
- section. Other documents or a future version of this document MAY
- define other extensions.
-
- Note that any URL-illegal characters (e.g., spaces), URL special
- characters (as defined in section 2.2 of RFC 1738) and the reserved
- character '?' (ASCII 63) occurring inside a dn, filter, or other
- element of an LDAP URL MUST be escaped using the % method described
- in RFC 1738 [5]. If a comma character ',' occurs inside an extension
- value, the character MUST also be escaped using the % method.
-
-4. The Bindname Extension
-
- This section defines an LDAP URL extension for representing the
- distinguished name for a client to use when authenticating to an LDAP
- directory during resolution of an LDAP URL. Clients MAY implement
- this extension.
-
- The extension type is "bindname". The extension value is the
- distinguished name of the directory entry to authenticate as, in the
- same form as described for dn in the grammar above. The dn may be the
- NULL string to specify unauthenticated access. The extension may be
- either critical (prefixed with a '!' character) or non-critical (not
- prefixed with a '!' character).
-
- If the bindname extension is critical, the client resolving the URL
- MUST authenticate to the directory using the given distinguished name
- and an appropriate authentication method. Note that for a NULL
- distinguished name, no bind MAY be required to obtain anonymous
- access to the directory. If the extension is non-critical, the client
- MAY bind to the directory using the given distinguished name.
-
-5. URL Processing
-
- This section describes how an LDAP URL SHOULD be resolved by a
- client.
-
-
-
-
-
-Howes & Smith Standards Track [Page 5]
-
-RFC 2255 LDAP URL Format December 1997
-
-
- First, the client obtains a connection to the LDAP server referenced
- in the URL, or an LDAP server of the client's choice if no LDAP
- server is explicitly referenced. This connection MAY be opened
- specifically for the purpose of resolving the URL or the client MAY
- reuse an already open connection. The connection MAY provide
- confidentiality, integrity, or other services, e.g., using TLS. Use
- of security services is at the client's discretion if not specified
- in the URL.
-
- Next, the client authenticates itself to the LDAP server. This step
- is optional, unless the URL contains a critical bindname extension
- with a non-NULL value. If a bindname extension is given, the client
- proceeds according to the section above.
-
- If a bindname extension is not specified, the client MAY bind to the
- directory using a appropriate dn and authentication method of its own
- choosing (including NULL authentication).
-
- Next, the client performs the LDAP search operation specified in the
- URL. Additional fields in the LDAP protocol search request, such as
- sizelimit, timelimit, deref, and anything else not specified or
- defaulted in the URL specification, MAY be set at the client's
- discretion.
-
- Once the search has completed, the client MAY close the connection to
- the LDAP server, or the client MAY keep the connection open for
- future use.
-
-6. Examples
-
- The following are some example LDAP URLs using the format defined
- above. The first example is an LDAP URL referring to the University
- of Michigan entry, available from an LDAP server of the client's
- choosing:
-
- ldap:///o=University%20of%20Michigan,c=US
-
- The next example is an LDAP URL referring to the University of
- Michigan entry in a particular ldap server:
-
- ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US
-
- Both of these URLs correspond to a base object search of the
- "o=University of Michigan, c=US" entry using a filter of
- "(objectclass=*)", requesting all attributes.
-
- The next example is an LDAP URL referring to only the postalAddress
- attribute of the University of Michigan entry:
-
-
-
-Howes & Smith Standards Track [Page 6]
-
-RFC 2255 LDAP URL Format December 1997
-
-
- ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,
- c=US?postalAddress
-
- The corresponding LDAP search operation is the same as in the
- previous example, except that only the postalAddress attribute is
- requested.
-
- The next example is an LDAP URL referring to the set of entries found
- by querying the given LDAP server on port 6666 and doing a subtree
- search of the University of Michigan for any entry with a common name
- of "Babs Jensen", retrieving all attributes:
-
- ldap://host.com:6666/o=University%20of%20Michigan,
- c=US??sub?(cn=Babs%20Jensen)
-
- The next example is an LDAP URL referring to all children of the c=GB
- entry:
-
- ldap://ldap.itd.umich.edu/c=GB?objectClass?one
-
- The objectClass attribute is requested to be returned along with the
- entries, and the default filter of "(objectclass=*)" is used.
-
- The next example is an LDAP URL to retrieve the mail attribute for
- the LDAP entry named "o=Question?,c=US" is given below, illustrating
- the use of the escaping mechanism on the reserved character '?'.
-
- ldap://ldap.question.com/o=Question%3f,c=US?mail
-
- The next example illustrates the interaction between LDAP and URL
- quoting mechanisms.
-
- ldap://ldap.netscape.com/o=Babsco,c=US??(int=%5c00%5c00%5c00%5c04)
-
- The filter in this example uses the LDAP escaping mechanism of \ to
- encode three zero or null bytes in the value. In LDAP, the filter
- would be written as (int=\00\00\00\04). Because the \ character must
- be escaped in a URL, the \'s are escaped as %5c in the URL encoding.
-
- The final example shows the use of the bindname extension to specify
- the dn a client should use for authentication when resolving the URL.
-
- ldap:///??sub??bindname=cn=Manager%2co=Foo
- ldap:///??sub??!bindname=cn=Manager%2co=Foo
-
- The two URLs are the same, except that the second one marks the
- bindname extension as critical. Notice the use of the % encoding
- method to encode the comma in the distinguished name value in the
-
-
-
-Howes & Smith Standards Track [Page 7]
-
-RFC 2255 LDAP URL Format December 1997
-
-
- bindname extension.
-
-7. Security Considerations
-
- General URL security considerations discussed in [5] are relevant for
- LDAP URLs.
-
- The use of security mechanisms when processing LDAP URLs requires
- particular care, since clients may encounter many different servers
- via URLs, and since URLs are likely to be processed automatically,
- without user intervention. A client SHOULD have a user-configurable
- policy about which servers to connect to using which security
- mechanisms, and SHOULD NOT make connections that are inconsistent
- with this policy.
-
- Sending authentication information, no matter the mechanism, may
- violate a user's privacy requirements. In the absence of specific
- policy permitting authentication information to be sent to a server,
- a client should use an anonymous connection. (Note that clients
- conforming to previous LDAP URL specifications, where all connections
- are anonymous and unprotected, are consistent with this
- specification; they simply have the default security policy.)
-
- Some authentication methods, in particular reusable passwords sent to
- the server, may reveal easily-abused information to the remote server
- or to eavesdroppers in transit, and should not be used in URL
- processing unless explicitly permitted by policy. Confirmation by
- the human user of the use of authentication information is
- appropriate in many circumstances. Use of strong authentication
- methods that do not reveal sensitive information is much preferred.
-
- The LDAP URL format allows the specification of an arbitrary LDAP
- search operation to be performed when evaluating the LDAP URL.
- Following an LDAP URL may cause unexpected results, for example, the
- retrieval of large amounts of data, the initiation of a long-lived
- search, etc. The security implications of resolving an LDAP URL are
- the same as those of resolving an LDAP search query.
-
-8. Acknowledgements
-
- The LDAP URL format was originally defined at the University of
- Michigan. This material is based upon work supported by the National
- Science Foundation under Grant No. NCR-9416667. The support of both
- the University of Michigan and the National Science Foundation is
- gratefully acknowledged.
-
-
-
-
-
-
-Howes & Smith Standards Track [Page 8]
-
-RFC 2255 LDAP URL Format December 1997
-
-
- Several people have made valuable comments on this document. In
- particular RL "Bob" Morgan and Mark Wahl deserve special thanks for
- their contributions.
-
-9. References
-
- [1] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Access
- Protocol (v3): UTF-8 String Representation of Distinguished Names",
- RFC 2253, December 1997.
-
- [2] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access
- Protocol (v3)", RFC 2251, December 1997.
-
- [3] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
- Directory Access Protocol (v3): Attribute Syntax Definitions", RFC
- 2252, December 1997.
-
- [4] Howes, T., "A String Representation of LDAP Search Filters", RFC
- 2254, December 1997.
-
- [5] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource
- Locators (URL)," RFC 1738, December 1994.
-
- [6] Bradner, S., "Key Words for use in RFCs to Indicate Requirement
- Levels," RFC 2119, March 1997.
-
-Authors' Addresses
-
- Tim Howes
- Netscape Communications Corp.
- 501 E. Middlefield Rd.
- Mountain View, CA 94043
- USA
-
- Phone: +1 415 937-3419
- EMail: howes@netscape.com
-
-
- Mark Smith
- Netscape Communications Corp.
- 501 E. Middlefield Rd.
- Mountain View, CA 94043
- USA
-
- Phone: +1 415 937-3477
- EMail: mcs@netscape.com
-
-
-
-
-
-Howes & Smith Standards Track [Page 9]
-
-RFC 2255 LDAP URL Format December 1997
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (1997). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Howes & Smith Standards Track [Page 10]
-
diff --git a/doc/rfc/rfc2256.txt b/doc/rfc/rfc2256.txt
deleted file mode 100644
index 69706f65a690d2b8963d3686ec6ad7d846739090..0000000000000000000000000000000000000000
--- a/doc/rfc/rfc2256.txt
+++ /dev/null
@@ -1,1123 +0,0 @@
-
-
-
-
-
-
-Network Working Group M. Wahl
-Request for Comments: 2256 Critical Angle Inc.
-Category: Standards Track December 1997
-
-
- A Summary of the X.500(96) User Schema for use with LDAPv3
-
-1. Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (1997). All Rights Reserved.
-
-IESG Note
-
- This document describes a directory access protocol that provides
- both read and update access. Update access requires secure
- authentication, but this document does not mandate implementation of
- any satisfactory authentication mechanisms.
-
- In accordance with RFC 2026, section 4.4.1, this specification is
- being approved by IESG as a Proposed Standard despite this
- limitation, for the following reasons:
-
- a. to encourage implementation and interoperability testing of
- these protocols (with or without update access) before they
- are deployed, and
-
- b. to encourage deployment and use of these protocols in read-only
- applications. (e.g. applications where LDAPv3 is used as
- a query language for directories which are updated by some
- secure mechanism other than LDAP), and
-
- c. to avoid delaying the advancement and deployment of other Internet
- standards-track protocols which require the ability to query, but
- not update, LDAPv3 directory servers.
-
- Readers are hereby warned that until mandatory authentication
- mechanisms are standardized, clients and servers written according to
- this specification which make use of update functionality are
- UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
- IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
-
-
-
-Wahl Standards Track [Page 1]
-
-RFC 2256 LDAPv3 Schema December 1997
-
-
- Implementors are hereby discouraged from deploying LDAPv3 clients or
- servers which implement the update functionality, until a Proposed
- Standard for mandatory authentication in LDAPv3 has been approved and
- published as an RFC.
-
-2. Abstract
-
- This document provides an overview of the attribute types and object
- classes defined by the ISO and ITU-T committees in the X.500
- documents, in particular those intended for use by directory clients.
- This is the most widely used schema for LDAP/X.500 directories, and
- many other schema definitions for white pages objects use it as a
- basis. This document does not cover attributes used for the
- administration of X.500 directory servers, nor does it include
- attributes defined by other ISO/ITU-T documents.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [6].
-
-3. General Issues
-
- This document references syntaxes given in section 6 of this document
- and section 6 of [1]. Matching rules are listed in section 8 of this
- document and section 8 of [1].
-
- The attribute type and object class definitions are written using the
- BNF form of AttributeTypeDescription and ObjectClassDescription given
- in [1]. Lines have been folded for readability.
-
-4. Source
-
- The schema definitions in this document are based on those found in
- X.500 [2],[3],[4],[5], and updates to these documents, specifically:
-
- Sections Source
- ============ ============
- 5.1 - 5.2 X.501(93)
- 5.3 - 5.36 X.520(88)
- 5.37 - 5.41 X.509(93)
- 5.42 - 5.52 X.520(93)
- 5.53 - 5.54 X.509(96)
- 5.55 X.520(96)
- 6.1 RFC 1274
- 6.2 (new syntax)
- 6.3 - 6.6 RFC 1274
- 7.1 - 7.2 X.501(93)
- 7.3 - 7.18 X.521(93)
-
-
-
-Wahl Standards Track [Page 2]
-
-RFC 2256 LDAPv3 Schema December 1997
-
-
- 7.19 - 7.21 X.509(96)
- 7.22 X.521(96)
-
- Some attribute names are different from those found in X.520(93).
-
- Three new attributes supportedAlgorithms, deltaRevocationList and
- dmdName, and the objectClass dmd, are defined in the X.500(96)
- documents.
-
-5. Attribute Types
-
- An LDAP server implementation SHOULD recognize the attribute types
- described in this section.
-
-5.1. objectClass
-
- The values of the objectClass attribute describe the kind of object
- which an entry represents. The objectClass attribute is present in
- every entry, with at least two values. One of the values is either
- "top" or "alias".
-
- ( 2.5.4.0 NAME 'objectClass' EQUALITY objectIdentifierMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
-
-5.2. aliasedObjectName
-
- The aliasedObjectName attribute is used by the directory service if
- the entry containing this attribute is an alias.
-
- ( 2.5.4.1 NAME 'aliasedObjectName' EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )
-
-5.3. knowledgeInformation
-
- This attribute is no longer used.
-
- ( 2.5.4.2 NAME 'knowledgeInformation' EQUALITY caseIgnoreMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
-
-5.4. cn
-
- This is the X.500 commonName attribute, which contains a name of an
- object. If the object corresponds to a person, it is typically the
- person's full name.
-
- ( 2.5.4.3 NAME 'cn' SUP name )
-
-
-
-
-
-Wahl Standards Track [Page 3]
-
-RFC 2256 LDAPv3 Schema December 1997
-
-
-5.5. sn
-
- This is the X.500 surname attribute, which contains the family name
- of a person.
-
- ( 2.5.4.4 NAME 'sn' SUP name )
-
-5.6. serialNumber
-
- This attribute contains the serial number of a device.
-
- ( 2.5.4.5 NAME 'serialNumber' EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{64} )
-
-5.7. c
-
- This attribute contains a two-letter ISO 3166 country code
- (countryName).
-
- ( 2.5.4.6 NAME 'c' SUP name SINGLE-VALUE )
-
-5.8. l
-
- This attribute contains the name of a locality, such as a city,
- county or other geographic region (localityName).
-
- ( 2.5.4.7 NAME 'l' SUP name )
-
-5.9. st
-
- This attribute contains the full name of a state or province
- (stateOrProvinceName).
-
- ( 2.5.4.8 NAME 'st' SUP name )
-
-5.10. street
-
- This attribute contains the physical address of the object to which
- the entry corresponds, such as an address for package delivery
- (streetAddress).
-
- ( 2.5.4.9 NAME 'street' EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
-
-
-
-
-
-
-Wahl Standards Track [Page 4]
-
-RFC 2256 LDAPv3 Schema December 1997
-
-
-5.11. o
-
- This attribute contains the name of an organization
- (organizationName).
-
- ( 2.5.4.10 NAME 'o' SUP name )
-
-5.12. ou
-
- This attribute contains the name of an organizational unit
- (organizationalUnitName).
-
- ( 2.5.4.11 NAME 'ou' SUP name )
-
-5.13. title
-
- This attribute contains the title, such as "Vice President", of a
- person in their organizational context. The "personalTitle"
- attribute would be used for a person's title independent of their job
- function.
-
- ( 2.5.4.12 NAME 'title' SUP name )
-
-5.14. description
-
- This attribute contains a human-readable description of the object.
-
- ( 2.5.4.13 NAME 'description' EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} )
-
-5.15. searchGuide
-
- This attribute is for use by X.500 clients in constructing search
- filters. It is obsoleted by enhancedSearchGuide, described below in
- 5.48.
-
- ( 2.5.4.14 NAME 'searchGuide'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 )
-
-5.16. businessCategory
-
- This attribute describes the kind of business performed by an
- organization.
-
- ( 2.5.4.15 NAME 'businessCategory' EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
-
-
-
-Wahl Standards Track [Page 5]
-
-RFC 2256 LDAPv3 Schema December 1997
-
-
-5.17. postalAddress
-
- ( 2.5.4.16 NAME 'postalAddress' EQUALITY caseIgnoreListMatch
- SUBSTR caseIgnoreListSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
-
-5.18. postalCode
-
- ( 2.5.4.17 NAME 'postalCode' EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} )
-
-5.19. postOfficeBox
-
- ( 2.5.4.18 NAME 'postOfficeBox' EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{40} )
-
-5.20. physicalDeliveryOfficeName
-
- ( 2.5.4.19 NAME 'physicalDeliveryOfficeName' EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
-
-5.21. telephoneNumber
-
- ( 2.5.4.20 NAME 'telephoneNumber' EQUALITY telephoneNumberMatch
- SUBSTR telephoneNumberSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.50{32} )
-
-5.22. telexNumber
-
- ( 2.5.4.21 NAME 'telexNumber'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 )
-
-5.23. teletexTerminalIdentifier
-
- ( 2.5.4.22 NAME 'teletexTerminalIdentifier'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 )
-
-5.24. facsimileTelephoneNumber
-
- ( 2.5.4.23 NAME 'facsimileTelephoneNumber'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )
-
-
-
-
-
-
-
-Wahl Standards Track [Page 6]
-
-RFC 2256 LDAPv3 Schema December 1997
-
-
-5.25. x121Address
-
- ( 2.5.4.24 NAME 'x121Address' EQUALITY numericStringMatch
- SUBSTR numericStringSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{15} )
-
-5.26. internationaliSDNNumber
-
- ( 2.5.4.25 NAME 'internationaliSDNNumber' EQUALITY numericStringMatch
- SUBSTR numericStringSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{16} )
-
-5.27. registeredAddress
-
- This attribute holds a postal address suitable for reception of
- telegrams or expedited documents, where it is necessary to have the
- recipient accept delivery.
-
- ( 2.5.4.26 NAME 'registeredAddress' SUP postalAddress
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
-
-5.28. destinationIndicator
-
- This attribute is used for the telegram service.
-
- ( 2.5.4.27 NAME 'destinationIndicator' EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{128} )
-
-5.29. preferredDeliveryMethod
-
- ( 2.5.4.28 NAME 'preferredDeliveryMethod'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.14
- SINGLE-VALUE )
-
-5.30. presentationAddress
-
- This attribute contains an OSI presentation address.
-
- ( 2.5.4.29 NAME 'presentationAddress'
- EQUALITY presentationAddressMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.43
- SINGLE-VALUE )
-
-
-
-
-
-
-
-
-Wahl Standards Track [Page 7]
-
-RFC 2256 LDAPv3 Schema December 1997
-
-
-5.31. supportedApplicationContext
-
- This attribute contains the identifiers of OSI application contexts.
-
- ( 2.5.4.30 NAME 'supportedApplicationContext'
- EQUALITY objectIdentifierMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
-
-5.32. member
-
- ( 2.5.4.31 NAME 'member' SUP distinguishedName )
-
-5.33. owner
-
- ( 2.5.4.32 NAME 'owner' SUP distinguishedName )
-
-5.34. roleOccupant
-
- ( 2.5.4.33 NAME 'roleOccupant' SUP distinguishedName )
-
-5.35. seeAlso
-
- ( 2.5.4.34 NAME 'seeAlso' SUP distinguishedName )
-
-5.36. userPassword
-
- ( 2.5.4.35 NAME 'userPassword' EQUALITY octetStringMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
-
- Passwords are stored using an Octet String syntax and are not
- encrypted. Transfer of cleartext passwords are strongly discouraged
- where the underlying transport service cannot guarantee
- confidentiality and may result in disclosure of the password to
- unauthorized parties.
-
-5.37. userCertificate
-
- This attribute is to be stored and requested in the binary form, as
- 'userCertificate;binary'.
-
- ( 2.5.4.36 NAME 'userCertificate'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
-
-5.38. cACertificate
-
- This attribute is to be stored and requested in the binary form, as
- 'cACertificate;binary'.
-
-
-
-
-Wahl Standards Track [Page 8]
-
-RFC 2256 LDAPv3 Schema December 1997
-
-
- ( 2.5.4.37 NAME 'cACertificate'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
-
-5.39. authorityRevocationList
-
- This attribute is to be stored and requested in the binary form, as
- 'authorityRevocationList;binary'.
-
- ( 2.5.4.38 NAME 'authorityRevocationList'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
-
-5.40. certificateRevocationList
-
- This attribute is to be stored and requested in the binary form, as
- 'certificateRevocationList;binary'.
-
- ( 2.5.4.39 NAME 'certificateRevocationList'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
-
-5.41. crossCertificatePair
-
- This attribute is to be stored and requested in the binary form, as
- 'crossCertificatePair;binary'.
-
- ( 2.5.4.40 NAME 'crossCertificatePair'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.10 )
-
-5.42. name
-
- The name attribute type is the attribute supertype from which string
- attribute types typically used for naming may be formed. It is
- unlikely that values of this type itself will occur in an entry. LDAP
- server implementations which do not support attribute subtyping need
- not recognize this attribute in requests. Client implementations
- MUST NOT assume that LDAP servers are capable of performing attribute
- subtyping.
-
- ( 2.5.4.41 NAME 'name' EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
-
-5.43. givenName
-
- The givenName attribute is used to hold the part of a person's name
- which is not their surname nor middle name.
-
- ( 2.5.4.42 NAME 'givenName' SUP name )
-
-
-
-
-Wahl Standards Track [Page 9]
-
-RFC 2256 LDAPv3 Schema December 1997
-
-
-5.44. initials
-
- The initials attribute contains the initials of some or all of an
- individuals names, but not the surname(s).
-
- ( 2.5.4.43 NAME 'initials' SUP name )
-
-5.45. generationQualifier
-
- The generationQualifier attribute contains the part of the name which
- typically is the suffix, as in "IIIrd".
-
- ( 2.5.4.44 NAME 'generationQualifier' SUP name )
-
-5.46. x500UniqueIdentifier
-
- The x500UniqueIdentifier attribute is used to distinguish between
- objects when a distinguished name has been reused. This is a
- different attribute type from both the "uid" and "uniqueIdentifier"
- types.
-
- ( 2.5.4.45 NAME 'x500UniqueIdentifier' EQUALITY bitStringMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
-
-5.47. dnQualifier
-
- The dnQualifier attribute type specifies disambiguating information
- to add to the relative distinguished name of an entry. It is
- intended for use when merging data from multiple sources in order to
- prevent conflicts between entries which would otherwise have the same
- name. It is recommended that the value of the dnQualifier attribute
- be the same for all entries from a particular source.
-
- ( 2.5.4.46 NAME 'dnQualifier' EQUALITY caseIgnoreMatch
- ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
-
-5.48. enhancedSearchGuide
-
- This attribute is for use by X.500 clients in constructing search
- filters.
-
- ( 2.5.4.47 NAME 'enhancedSearchGuide'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 )
-
-
-
-
-
-
-
-Wahl Standards Track [Page 10]
-
-RFC 2256 LDAPv3 Schema December 1997
-
-
-5.49. protocolInformation
-
- This attribute is used in conjunction with the presentationAddress
- attribute, to provide additional information to the OSI network
- service.
-
- ( 2.5.4.48 NAME 'protocolInformation'
- EQUALITY protocolInformationMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.42 )
-
-5.50. distinguishedName
-
- This attribute type is not used as the name of the object itself, but
- it is instead a base type from which attributes with DN syntax
- inherit.
-
- It is unlikely that values of this type itself will occur in an
- entry. LDAP server implementations which do not support attribute
- subtyping need not recognize this attribute in requests. Client
- implementations MUST NOT assume that LDAP servers are capable of
- performing attribute subtyping.
-
- ( 2.5.4.49 NAME 'distinguishedName' EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
-
-5.51. uniqueMember
-
- ( 2.5.4.50 NAME 'uniqueMember' EQUALITY uniqueMemberMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
-
-5.52. houseIdentifier
-
- This attribute is used to identify a building within a location.
-
- ( 2.5.4.51 NAME 'houseIdentifier' EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
-
-5.53. supportedAlgorithms
-
- This attribute is to be stored and requested in the binary form, as
- 'supportedAlgorithms;binary'.
-
- ( 2.5.4.52 NAME 'supportedAlgorithms'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.49 )
-
-
-
-
-
-
-Wahl Standards Track [Page 11]
-
-RFC 2256 LDAPv3 Schema December 1997
-
-
-5.54. deltaRevocationList
-
- This attribute is to be stored and requested in the binary form, as
- 'deltaRevocationList;binary'.
-
- ( 2.5.4.53 NAME 'deltaRevocationList'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
-
-5.55. dmdName
-
- The value of this attribute specifies a directory management domain
- (DMD), the administrative authority which operates the directory
- server.
-
- ( 2.5.4.54 NAME 'dmdName' SUP name )
-
-6. Syntaxes
-
- Servers SHOULD recognize the syntaxes defined in this section. Each
- syntax begins with a sample value of the ldapSyntaxes attribute which
- defines the OBJECT IDENTIFIER of the syntax. The descriptions of
- syntax names are not carried in protocol, and are not guaranteed to
- be unique.
-
-6.1. Delivery Method
-
- ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' )
-
- Values in this syntax are encoded according to the following BNF:
-
- delivery-value = pdm / ( pdm whsp "$" whsp delivery-value )
-
- pdm = "any" / "mhs" / "physical" / "telex" / "teletex" /
- "g3fax" / "g4fax" / "ia5" / "videotex" / "telephone"
-
- Example:
-
- telephone
-
-6.2. Enhanced Guide
-
- ( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' )
-
- Values in this syntax are encoded according to the following BNF:
-
- EnhancedGuide = woid whsp "#" whsp criteria whsp "#" whsp subset
-
- subset = "baseobject" / "oneLevel" / "wholeSubtree"
-
-
-
-Wahl Standards Track [Page 12]
-
-RFC 2256 LDAPv3 Schema December 1997
-
-
- The criteria production is defined in the Guide syntax below. This
- syntax has been added subsequent to RFC 1778.
-
- Example:
-
- person#(sn)#oneLevel
-
-6.3. Guide
-
- ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' )
-
- Values in this syntax are encoded according to the following BNF:
-
- guide-value = [ object-class "#" ] criteria
-
- object-class = woid
-
- criteria = criteria-item / criteria-set / ( "!" criteria )
-
- criteria-set = ( [ "(" ] criteria "&" criteria-set [ ")" ] ) /
- ( [ "(" ] criteria "|" criteria-set [ ")" ] )
-
- criteria-item = [ "(" ] attributetype "$" match-type [ ")" ]
-
- match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX"
-
- This syntax should not be used for defining new attributes.
-
-6.4. Octet String
-
- ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' )
-
- Values in this syntax are encoded as octet strings.
-
-
- Example:
-
- secret
-
-6.5. Teletex Terminal Identifier
-
- ( 1.3.6.1.4.1.1466.115.121.1.51 DESC 'Teletex Terminal Identifier' )
-
- Values in this syntax are encoded according to the following BNF:
-
- teletex-id = ttx-term 0*("$" ttx-param)
-
- ttx-term = printablestring
-
-
-
-Wahl Standards Track [Page 13]
-
-RFC 2256 LDAPv3 Schema December 1997
-
-
- ttx-param = ttx-key ":" ttx-value
-
- ttx-key = "graphic" / "control" / "misc" / "page" / "private"
-
- ttx-value = octetstring
-
- In the above, the first printablestring is the encoding of the first
- portion of the teletex terminal identifier to be encoded, and the
- subsequent 0 or more octetstrings are subsequent portions of the
- teletex terminal identifier.
-
-6.6. Telex Number
-
- ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' )
-
- Values in this syntax are encoded according to the following BNF:
-
- telex-number = actual-number "$" country "$" answerback
-
- actual-number = printablestring
-
- country = printablestring
-
- answerback = printablestring
-
- In the above, actual-number is the syntactic representation of the
- number portion of the TELEX number being encoded, country is the
- TELEX country code, and answerback is the answerback code of a TELEX
- terminal.
-
-6.7. Supported Algorithm
-
- ( 1.3.6.1.4.1.1466.115.121.1.49 DESC 'Supported Algorithm' )
-
- No printable representation of values of the supportedAlgorithms
- attribute is defined in this document. Clients which wish to store
- and retrieve this attribute MUST use "supportedAlgorithms;binary", in
- which the value is transferred as a binary encoding.
-
-7. Object Classes
-
- LDAP servers MUST recognize the object classes "top" and "subschema".
- LDAP servers SHOULD recognize all the other object classes listed
- here as values of the objectClass attribute.
-
-7.1. top
-
- ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
-
-
-
-Wahl Standards Track [Page 14]
-
-RFC 2256 LDAPv3 Schema December 1997
-
-
-7.2. alias
-
- ( 2.5.6.1 NAME 'alias' SUP top STRUCTURAL MUST aliasedObjectName )
-
-7.3. country
-
- ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c
- MAY ( searchGuide $ description ) )
-
-7.4. locality
-
- ( 2.5.6.3 NAME 'locality' SUP top STRUCTURAL
- MAY ( street $ seeAlso $ searchGuide $ st $ l $ description ) )
-
-7.5. organization
-
- ( 2.5.6.4 NAME 'organization' SUP top STRUCTURAL MUST o
- MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
- x121Address $ registeredAddress $ destinationIndicator $
- preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
- telephoneNumber $ internationaliSDNNumber $
- facsimileTelephoneNumber $
- street $ postOfficeBox $ postalCode $ postalAddress $
- physicalDeliveryOfficeName $ st $ l $ description ) )
-
-7.6. organizationalUnit
-
- ( 2.5.6.5 NAME 'organizationalUnit' SUP top STRUCTURAL MUST ou
- MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
- x121Address $ registeredAddress $ destinationIndicator $
- preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
- telephoneNumber $ internationaliSDNNumber $
- facsimileTelephoneNumber $
- street $ postOfficeBox $ postalCode $ postalAddress $
- physicalDeliveryOfficeName $ st $ l $ description ) )
-
-7.7. person
-
- ( 2.5.6.6 NAME 'person' SUP top STRUCTURAL MUST ( sn $ cn )
- MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
-
-7.8. organizationalPerson
-
- ( 2.5.6.7 NAME 'organizationalPerson' SUP person STRUCTURAL
- MAY ( title $ x121Address $ registeredAddress $
- destinationIndicator $
- preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
- telephoneNumber $ internationaliSDNNumber $
-
-
-
-Wahl Standards Track [Page 15]
-
-RFC 2256 LDAPv3 Schema December 1997
-
-
- facsimileTelephoneNumber $
- street $ postOfficeBox $ postalCode $ postalAddress $
- physicalDeliveryOfficeName $ ou $ st $ l ) )
-
-7.9. organizationalRole
-
- ( 2.5.6.8 NAME 'organizationalRole' SUP top STRUCTURAL MUST cn
- MAY ( x121Address $ registeredAddress $ destinationIndicator $
- preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
- telephoneNumber $ internationaliSDNNumber $
- facsimileTelephoneNumber $
- seeAlso $ roleOccupant $ preferredDeliveryMethod $ street $
- postOfficeBox $ postalCode $ postalAddress $
- physicalDeliveryOfficeName $ ou $ st $ l $ description ) )
-
-7.10. groupOfNames
-
- ( 2.5.6.9 NAME 'groupOfNames' SUP top STRUCTURAL MUST ( member $ cn )
- MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )
-
-7.11. residentialPerson
-
- ( 2.5.6.10 NAME 'residentialPerson' SUP person STRUCTURAL MUST l
- MAY ( businessCategory $ x121Address $ registeredAddress $
- destinationIndicator $ preferredDeliveryMethod $ telexNumber $
- teletexTerminalIdentifier $ telephoneNumber $
- internationaliSDNNumber $
- facsimileTelephoneNumber $ preferredDeliveryMethod $ street $
- postOfficeBox $ postalCode $ postalAddress $
- physicalDeliveryOfficeName $ st $ l ) )
-
-7.12. applicationProcess
-
- ( 2.5.6.11 NAME 'applicationProcess' SUP top STRUCTURAL MUST cn
- MAY ( seeAlso $ ou $ l $ description ) )
-
-7.13. applicationEntity
-
- ( 2.5.6.12 NAME 'applicationEntity' SUP top STRUCTURAL
- MUST ( presentationAddress $ cn )
- MAY ( supportedApplicationContext $ seeAlso $ ou $ o $ l $
- description ) )
-
-7.14. dSA
-
- ( 2.5.6.13 NAME 'dSA' SUP applicationEntity STRUCTURAL
- MAY knowledgeInformation )
-
-
-
-
-Wahl Standards Track [Page 16]
-
-RFC 2256 LDAPv3 Schema December 1997
-
-
-7.15. device
-
- ( 2.5.6.14 NAME 'device' SUP top STRUCTURAL MUST cn
- MAY ( serialNumber $ seeAlso $ owner $ ou $ o $ l $ description ) )
-
-7.16. strongAuthenticationUser
-
- ( 2.5.6.15 NAME 'strongAuthenticationUser' SUP top AUXILIARY
- MUST userCertificate )
-
-7.17. certificationAuthority
-
- ( 2.5.6.16 NAME 'certificationAuthority' SUP top AUXILIARY
- MUST ( authorityRevocationList $ certificateRevocationList $
- cACertificate ) MAY crossCertificatePair )
-
-7.18. groupOfUniqueNames
-
- ( 2.5.6.17 NAME 'groupOfUniqueNames' SUP top STRUCTURAL
- MUST ( uniqueMember $ cn )
- MAY ( businessCategory $ seeAlso $ owner $ ou $ o $ description ) )
-
-7.19. userSecurityInformation
-
- ( 2.5.6.18 NAME 'userSecurityInformation' SUP top AUXILIARY
- MAY ( supportedAlgorithms ) )
-
-7.20. certificationAuthority-V2
-
- ( 2.5.6.16.2 NAME 'certificationAuthority-V2' SUP
- certificationAuthority
- AUXILIARY MAY ( deltaRevocationList ) )
-
-7.21. cRLDistributionPoint
-
- ( 2.5.6.19 NAME 'cRLDistributionPoint' SUP top STRUCTURAL
- MUST ( cn ) MAY ( certificateRevocationList $
- authorityRevocationList $
- deltaRevocationList ) )
-
-7.22. dmd
-
- ( 2.5.6.20 NAME 'dmd' SUP top STRUCTURAL MUST ( dmdName )
- MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
- x121Address $ registeredAddress $ destinationIndicator $
- preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
- telephoneNumber $ internationaliSDNNumber $
- facsimileTelephoneNumber $
-
-
-
-Wahl Standards Track [Page 17]
-
-RFC 2256 LDAPv3 Schema December 1997
-
-
- street $ postOfficeBox $ postalCode $ postalAddress $
- physicalDeliveryOfficeName $ st $ l $ description ) )
-
-8. Matching Rules
-
- Servers MAY implement additional matching rules.
-
-8.1. octetStringMatch
-
- Servers which implement the extensibleMatch filter SHOULD allow the
- matching rule listed in this section to be used in the
- extensibleMatch. In general these servers SHOULD allow matching
- rules to be used with all attribute types known to the server, when
- the assertion syntax of the matching rule is the same as the value
- syntax of the attribute.
-
- ( 2.5.13.17 NAME 'octetStringMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
-
-9. Security Considerations
-
- Attributes of directory entries are used to provide descriptive
- information about the real-world objects they represent, which can be
- people, organizations or devices. Most countries have privacy laws
- regarding the publication of information about people.
-
- Transfer of cleartext passwords are strongly discouraged where the
- underlying transport service cannot guarantee confidentiality and may
- result in disclosure of the password to unauthorized parties.
-
-10. Acknowledgements
-
- The definitions on which this document have been developed by
- committees for telecommunications and international standards. No
- new attribute definitions have been added. The syntax definitions
- are based on the ISODE "QUIPU" implementation of X.500.
-
-11. Bibliography
-
- [1] Wahl, M., Coulbeck, A., Howes, T., and S. Kille,
- "Lightweight X.500 Directory Access Protocol (v3): Attribute
- Syntax Definitions", RFC 2252, December 1997.
-
- [2] The Directory: Models. ITU-T Recommendation X.501, 1996.
-
- [3] The Directory: Authentication Framework. ITU-T Recommendation
- X.509, 1996.
-
-
-
-
-Wahl Standards Track [Page 18]
-
-RFC 2256 LDAPv3 Schema December 1997
-
-
- [4] The Directory: Selected Attribute Types. ITU-T Recommendation
- X.520, 1996.
-
- [5] The Directory: Selected Object Classes. ITU-T Recommendation
- X.521, 1996.
-
- [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", RFC 2119, March 1997.
-
-12. Author's Address
-
- Mark Wahl
- Critical Angle Inc.
- 4815 West Braker Lane #502-385
- Austin, TX 78759
- USA
-
- Phone: +1 512 372 3160
- EMail: M.Wahl@critical-angle.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wahl Standards Track [Page 19]
-
-RFC 2256 LDAPv3 Schema December 1997
-
-
-13. Full Copyright Statement
-
- Copyright (C) The Internet Society (1997). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wahl Standards Track [Page 20]
-
diff --git a/doc/rfc/rfc2587.txt b/doc/rfc/rfc2587.txt
deleted file mode 100644
index a5c18a68cddb6269dcf4ddfbc22137cf2965a5fa..0000000000000000000000000000000000000000
--- a/doc/rfc/rfc2587.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group S. Boeyen
-Request for Comments: 2587 Entrust
-Category: Standards Track T. Howes
- Netscape
- P. Richard
- Xcert
- June 1999
-
-
-
- Internet X.509 Public Key Infrastructure
- LDAPv2 Schema
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
-1. Abstract
-
- The schema defined in this document is a minimal schema to support
- PKIX in an LDAPv2 environment, as defined in RFC 2559. Only PKIX-
- specific components are specified here. LDAP servers, acting as PKIX
- repositories should support the auxiliary object classes defined in
- this specification and integrate this schema specification with the
- generic and other application-specific schemas as appropriate,
- depending on the services to be supplied by that server.
-
- The key words 'MUST', 'SHALL', 'REQUIRED', 'SHOULD', 'RECOMMENDED',
- and 'MAY' in this document are to be interpreted as described in RFC
- 2119.
-
-2. Introduction
-
- This specification is part of a multi-part standard for development
- of a Public Key Infrastructure (PKI) for the Internet. LDAPv2 is one
- mechanism defined for access to a PKI repository. Other mechanisms,
- such as http, are also defined. If an LDAP server, accessed by LDAPv2
- is used to provide a repository, the minimum requirement is that the
- repository support the addition of X.509 certificates to directory
-
-
-
-
-Boeyen, et al. Standards Track [Page 1]
-
-RFC 2587 PKIX LDAPv2 Schema June 1999
-
-
- entries. Certificate Revocation List (CRL)is one mechanism for
- publishing revocation information in a repository. Other mechanisms,
- such as http, are also defined.
-
- This specification defines the attributes and object classes to be
- used by LDAP servers acting as PKIX repositories and to be understood
- by LDAP clients communicating with such repositories to query, add,
- modify and delete PKI information. Some object classes and attributes
- defined in X.509 are duplicated here for completeness. For end
- entities and Certification Authorities (CA), the earlier X.509
- defined object classes mandated inclusion of attributes which are
- optional for PKIX. Also, because of the mandatory attribute
- specification, this would have required dynamic modification of the
- object class attribute should the attributes not always be present in
- entries. For these reasons, alternative object classes are defined in
- this document for use by LDAP servers acting as PKIX repositories.
-
-3. PKIX Repository Objects
-
- The primary PKIX objects to be represented in a repository are:
-
- - End Entities
- - Certification Authorities (CA)
-
- These objects are defined in RFC 2459.
-
-3.1. End Entities
-
- For purposes of PKIX schema definition, the role of end entities as
- subjects of certificates is the major aspect relevant to this
- specification. End entities may be human users, or other types of
- entities to which certificates may be issued. In some cases, the
- entry for the end entity may already exist and the PKI-specific
- information is added to the existing entry. In other cases the entry
- may not exist prior to the issuance of a certificate, in which case
- the entity adding the certificate may also need to create the entry.
- Schema elements used to represent the non PKIX aspects of an entry,
- such as the structural object class used to represent organizational
- persons, may vary, depending on the particular environment and set of
- applications served and are outside the scope of this specification.
-
- The following auxiliary object class MAY be used to represent
- certificate subjects:
-
-
-
-
-
-
-
-
-Boeyen, et al. Standards Track [Page 2]
-
-RFC 2587 PKIX LDAPv2 Schema June 1999
-
-
-pkiUser OBJECT-CLASS ::= {
- SUBCLASS OF { top}
- KIND auxiliary
- MAY CONTAIN {userCertificate}
- ID joint-iso-ccitt(2) ds(5) objectClass(6) pkiUser(21)}
-
-userCertificate ATTRIBUTE ::= {
- WITH SYNTAX Certificate
- EQUALITY MATCHING RULE certificateExactMatch
- ID joint-iso-ccitt(2) ds(5) attributeType(4) userCertificate(36) }
-
- An end entity may obtain one or more certificates from one or more
- Certification Authorities. The userCertificate attribute MUST be
- used to represent these certificates in the directory entry
- representing that user.
-
-3.2. Certification Authorities
-
- As with end entities, Certification Authorities are typically
- represented in directories as auxiliary components of entries
- representing a more generic object, such as organizations,
- organizational units etc. The non PKIX-specific schema elements for
- these entries, such as the structural object class of the object, are
- outside the scope of this specification.
-
- The following auxiliary object class MAY be used to represent
- Certification Authorities:
-
-pkiCA OBJECT-CLASS ::= {
- SUBCLASS OF { top}
- KIND auxiliary
- MAY CONTAIN {cACertificate |
- certificateRevocationList |
- authorityRevocationList |
- crossCertificatePair }
- ID joint-iso-ccitt(2) ds(5) objectClass(6) pkiCA(22)}
-
-cACertificate ATTRIBUTE ::= {
- WITH SYNTAX Certificate
- EQUALITY MATCHING RULE certificateExactMatch
- ID joint-iso-ccitt(2) ds(5) attributeType(4) cACertificate(37) }
-
-crossCertificatePairATTRIBUTE::={
- WITH SYNTAX CertificatePair
- EQUALITY MATCHING RULE certificatePairExactMatch
- ID joint-iso-ccitt(2) ds(5) attributeType(4) crossCertificatePair(40)}
-
-
-
-
-
-Boeyen, et al. Standards Track [Page 3]
-
-RFC 2587 PKIX LDAPv2 Schema June 1999
-
-
- The cACertificate attribute of a CA's directory entry shall be used
- to store self-issued certificates (if any) and certificates issued to
- this CA by CAs in the same realm as this CA.
-
- The forward elements of the crossCertificatePair attribute of a CA's
- directory entry shall be used to store all, except self-issued
- certificates issued to this CA. Optionally, the reverse elements of
- the crossCertificatePair attribute, of a CA's directory entry may
- contain a subset of certificates issued by this CA to other CAs.
- When both the forward and the reverse elements are present in a
- single attribute value, issuer name in one certificate shall match
- the subject name in the other and vice versa, and the subject public
- key in one certificate shall be capable of verifying the digital
- signature on the other certificate and vice versa.
-
- When a reverse element is present, the forward element value and the
- reverse element value need not be stored in the same attribute value;
- in other words, they can be stored in either a single attribute value
- or two attribute values.
-
- In the case of V3 certificates, none of the above CA certificates
- shall include a basicConstraints extension with the cA value set to
- FALSE.
-
- The definition of realm is purely a matter of local policy.
-
- certificateRevocationListATTRIBUTE::={
- WITH SYNTAX CertificateList
- EQUALITY MATCHING RULE certificateListExactMatch
- ID joint-iso-ccitt(2) ds(5) attributeType(4)
- certificateRevocationList(39)}
-
- The certificateRevocationList attribute, if present in a particular
- CA's entry, contains CRL(s) as defined in RFC 2459.
-
- authorityRevocationListATTRIBUTE::={
- WITH SYNTAX CertificateList
- EQUALITY MATCHING RULE certificateListExactMatch
- ID joint-iso-ccitt(2) ds(5) attributeType(4)
- authorityRevocationList(38)}
-
- The authorityRevocationList attribute, if present in a particular
- CA's entry, includes revocation information regarding certificates
- issued to other CAs.
-
-
-
-
-
-
-
-Boeyen, et al. Standards Track [Page 4]
-
-RFC 2587 PKIX LDAPv2 Schema June 1999
-
-
-3.2.1. CRL distribution points
-
- CRL distribution points are an optional mechanism, specified in RFC
- 2459, which MAY be used to distribute revocation information.
-
- A patent statement regarding CRL distribution points can be found at
- the end of this document.
-
- If a CA elects to use CRL distribution points, the following object
- class is used to represent these.
-
- cRLDistributionPoint OBJECT-CLASS::= {
- SUBCLASS OF { top }
- KIND structural
- MUST CONTAIN { commonName }
- MAY CONTAIN { certificateRevocationList |
- authorityRevocationList |
- deltaRevocationList }
- ID joint-iso-ccitt(2) ds(5) objectClass(6) cRLDistributionPoint(19) }
-
- The certificateRevocationList and authorityRevocationList attributes
- are as defined above.
-
- The commonName attribute and deltaRevocationList attributes, defined
- in X.509, are duplicated below.
-
- commonName ATTRIBUTE::={
- SUBTYPE OF name
- WITH SYNTAX DirectoryString
- ID joint-iso-ccitt(2) ds(5) attributeType(4) commonName(3) }
-
- deltaRevocationList ATTRIBUTE ::= {
- WITH SYNTAX CertificateList
- EQUALITY MATCHING RULE certificateListExactMatch
- ID joint-iso-ccitt(2) ds(5) attributeType(4)
- deltaRevocationList(53) }
-
-3.2.2. Delta CRLs
-
- Delta CRLs are an optional mechanism, specified in RFC 2459, which
- MAY be used to enhance the distribution of revocation information.
-
- If a CA elects to use delta CRLs, the following object class is used
- to represent these.
-
-
-
-
-
-
-
-Boeyen, et al. Standards Track [Page 5]
-
-RFC 2587 PKIX LDAPv2 Schema June 1999
-
-
- deltaCRL OBJECT-CLASS::= {
- SUBCLASS OF { top }
- KIND auxiliary
- MAY CONTAIN { deltaRevocationList }
- ID joint-iso-ccitt(2) ds(5) objectClass(6) deltaCRL(23) }
-
-4. Security Considerations
-
- Since the elements of information which are key to the PKI service
- (certificates and CRLs) are both digitally signed pieces of
- information, no additional integrity service is REQUIRED.
-
- Security considerations with respect to retrieval, addition,
- deletion, and modification of the information supported by this
- schema definition are addressed in RFC 2559.
-
-5. References
-
- [1] Yeong, Y., Howes, T. and S. Kille, "Lightweight Directory Access
- Protocol", RFC 1777, March 1995.
-
- [2] Bradner, S., "Key Words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
-6 Intellectual Property Rights
-
- The IETF has been notified of intellectual property rights claimed in
- regard to some or all of the specification contained in this
- document. For more information consult the online list of claimed
- rights.
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication and any assurances of
- licenses to be made available, or the result of an attempt made to
- obtain a general license or permission for the use of such
- proprietary rights by implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
-
-
-
-
-
-
-Boeyen, et al. Standards Track [Page 6]
-
-RFC 2587 PKIX LDAPv2 Schema June 1999
-
-
-7. Authors' Addresses
-
- Sharon Boeyen
- Entrust Technologies Limited
- 750 Heron Road
- Ottawa, Ontario
- Canada K1V 1A7
-
- EMail: sharon.boeyen@entrust.com
-
-
- Tim Howes
- Netscape Communications Corp.
- 501 E. Middlefield Rd.
- Mountain View, CA 94043
- USA
-
- EMail: howes@netscape.com
-
-
- Patrick Richard
- Xcert Software Inc.
- Suite 1001, 701 W. Georgia Street
- P.O. Box 10145
- Pacific Centre
- Vancouver, B.C.
- Canada V7Y 1C6
-
- EMail: patr@xcert.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Boeyen, et al. Standards Track [Page 7]
-
-RFC 2587 PKIX LDAPv2 Schema June 1999
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Boeyen, et al. Standards Track [Page 8]
-
diff --git a/doc/rfc/rfc2829.txt b/doc/rfc/rfc2829.txt
deleted file mode 100644
index 343e153c8e3315475b74e0b2b2b66f2da7706791..0000000000000000000000000000000000000000
--- a/doc/rfc/rfc2829.txt
+++ /dev/null
@@ -1,899 +0,0 @@
-
-
-
-
-
-
-Network Working Group M. Wahl
-Request for Comments: 2829 Sun Microsystems, Inc.
-Category: Standards Track H. Alvestrand
- EDB Maxware
- J. Hodges
- Oblix, Inc.
- R. Morgan
- University of Washington
- May 2000
-
-
- Authentication Methods for LDAP
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
-Abstract
-
- This document specifies particular combinations of security
- mechanisms which are required and recommended in LDAP [1]
- implementations.
-
-1. Introduction
-
- LDAP version 3 is a powerful access protocol for directories.
-
- It offers means of searching, fetching and manipulating directory
- content, and ways to access a rich set of security functions.
-
- In order to function for the best of the Internet, it is vital that
- these security functions be interoperable; therefore there has to be
- a minimum subset of security functions that is common to all
- implementations that claim LDAPv3 conformance.
-
- Basic threats to an LDAP directory service include:
-
- (1) Unauthorized access to data via data-fetching operations,
-
-
-
-
-
-Wahl, et al. Standards Track [Page 1]
-
-RFC 2829 Authentication Methods for LDAP May 2000
-
-
- (2) Unauthorized access to reusable client authentication
- information by monitoring others' access,
-
- (3) Unauthorized access to data by monitoring others' access,
-
- (4) Unauthorized modification of data,
-
- (5) Unauthorized modification of configuration,
-
- (6) Unauthorized or excessive use of resources (denial of
- service), and
-
- (7) Spoofing of directory: Tricking a client into believing that
- information came from the directory when in fact it did not,
- either by modifying data in transit or misdirecting the
- client's connection.
-
- Threats (1), (4), (5) and (6) are due to hostile clients. Threats
- (2), (3) and (7) are due to hostile agents on the path between client
- and server, or posing as a server.
-
- The LDAP protocol suite can be protected with the following security
- mechanisms:
-
- (1) Client authentication by means of the SASL [2] mechanism
- set, possibly backed by the TLS credentials exchange
- mechanism,
-
- (2) Client authorization by means of access control based on the
- requestor's authenticated identity,
-
- (3) Data integrity protection by means of the TLS protocol or
- data-integrity SASL mechanisms,
-
- (4) Protection against snooping by means of the TLS protocol or
- data-encrypting SASL mechanisms,
-
- (5) Resource limitation by means of administrative limits on
- service controls, and
-
- (6) Server authentication by means of the TLS protocol or SASL
- mechanism.
-
- At the moment, imposition of access controls is done by means outside
- the scope of the LDAP protocol.
-
- In this document, the term "user" represents any application which is
- an LDAP client using the directory to retrieve or store information.
-
-
-
-Wahl, et al. Standards Track [Page 2]
-
-RFC 2829 Authentication Methods for LDAP May 2000
-
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in RFC 2119 [3].
-
-2. Example deployment scenarios
-
- The following scenarios are typical for LDAP directories on the
- Internet, and have different security requirements. (In the
- following, "sensitive" means data that will cause real damage to the
- owner if revealed; there may be data that is protected but not
- sensitive). This is not intended to be a comprehensive list, other
- scenarios are possible, especially on physically protected networks.
-
- (1) A read-only directory, containing no sensitive data,
- accessible to "anyone", and TCP connection hijacking or IP
- spoofing is not a problem. This directory requires no
- security functions except administrative service limits.
-
- (2) A read-only directory containing no sensitive data; read
- access is granted based on identity. TCP connection
- hijacking is not currently a problem. This scenario requires
- a secure authentication function.
-
- (3) A read-only directory containing no sensitive data; and the
- client needs to ensure that the directory data is
- authenticated by the server and not modified while being
- returned from the server.
-
- (4) A read-write directory, containing no sensitive data; read
- access is available to "anyone", update access to properly
- authorized persons. TCP connection hijacking is not
- currently a problem. This scenario requires a secure
- authentication function.
-
- (5) A directory containing sensitive data. This scenario
- requires session confidentiality protection AND secure
- authentication.
-
-3. Authentication and Authorization: Definitions and Concepts
-
- This section defines basic terms, concepts, and interrelationships
- regarding authentication, authorization, credentials, and identity.
- These concepts are used in describing how various security approaches
- are utilized in client authentication and authorization.
-
-
-
-
-
-
-
-Wahl, et al. Standards Track [Page 3]
-
-RFC 2829 Authentication Methods for LDAP May 2000
-
-
-3.1. Access Control Policy
-
- An access control policy is a set of rules defining the protection of
- resources, generally in terms of the capabilities of persons or other
- entities accessing those resources. A common expression of an access
- control policy is an access control list. Security objects and
- mechanisms, such as those described here, enable the expression of
- access control policies and their enforcement. Access control
- policies are typically expressed in terms of access control
- attributes as described below.
-
-3.2. Access Control Factors
-
- A request, when it is being processed by a server, may be associated
- with a wide variety of security-related factors (section 4.2 of [1]).
- The server uses these factors to determine whether and how to process
- the request. These are called access control factors (ACFs). They
- might include source IP address, encryption strength, the type of
- operation being requested, time of day, etc. Some factors may be
- specific to the request itself, others may be associated with the
- connection via which the request is transmitted, others (e.g. time of
- day) may be "environmental".
-
- Access control policies are expressed in terms of access control
- factors. E.g., a request having ACFs i,j,k can perform operation Y
- on resource Z. The set of ACFs that a server makes available for such
- expressions is implementation-specific.
-
-3.3. Authentication, Credentials, Identity
-
- Authentication credentials are the evidence supplied by one party to
- another, asserting the identity of the supplying party (e.g. a user)
- who is attempting to establish an association with the other party
- (typically a server). Authentication is the process of generating,
- transmitting, and verifying these credentials and thus the identity
- they assert. An authentication identity is the name presented in a
- credential.
-
- There are many forms of authentication credentials -- the form used
- depends upon the particular authentication mechanism negotiated by
- the parties. For example: X.509 certificates, Kerberos tickets,
- simple identity and password pairs. Note that an authentication
- mechanism may constrain the form of authentication identities used
- with it.
-
-
-
-
-
-
-
-Wahl, et al. Standards Track [Page 4]
-
-RFC 2829 Authentication Methods for LDAP May 2000
-
-
-3.4. Authorization Identity
-
- An authorization identity is one kind of access control factor. It
- is the name of the user or other entity that requests that operations
- be performed. Access control policies are often expressed in terms
- of authorization identities; e.g., entity X can perform operation Y
- on resource Z.
-
- The authorization identity bound to an association is often exactly
- the same as the authentication identity presented by the client, but
- it may be different. SASL allows clients to specify an authorization
- identity distinct from the authentication identity asserted by the
- client's credentials. This permits agents such as proxy servers to
- authenticate using their own credentials, yet request the access
- privileges of the identity for which they are proxying [2]. Also,
- the form of authentication identity supplied by a service like TLS
- may not correspond to the authorization identities used to express a
- server's access control policy, requiring a server-specific mapping
- to be done. The method by which a server composes and validates an
- authorization identity from the authentication credentials supplied
- by a client is implementation-specific.
-
-4. Required security mechanisms
-
- It is clear that allowing any implementation, faced with the above
- requirements, to pick and choose among the possible alternatives is
- not a strategy that is likely to lead to interoperability. In the
- absence of mandates, clients will be written that do not support any
- security function supported by the server, or worse, support only
- mechanisms like cleartext passwords that provide clearly inadequate
- security.
-
- Active intermediary attacks are the most difficult for an attacker to
- perform, and for an implementation to protect against. Methods that
- protect only against hostile client and passive eavesdropping attacks
- are useful in situations where the cost of protection against active
- intermediary attacks is not justified based on the perceived risk of
- active intermediary attacks.
-
- Given the presence of the Directory, there is a strong desire to see
- mechanisms where identities take the form of a Distinguished Name and
- authentication data can be stored in the directory; this means that
- either this data is useless for faking authentication (like the Unix
- "/etc/passwd" file format used to be), or its content is never passed
- across the wire unprotected - that is, it's either updated outside
- the protocol or it is only updated in sessions well protected against
- snooping. It is also desirable to allow authentication methods to
-
-
-
-
-Wahl, et al. Standards Track [Page 5]
-
-RFC 2829 Authentication Methods for LDAP May 2000
-
-
- carry authorization identities based on existing forms of user
- identities for backwards compatibility with non-LDAP-based
- authentication services.
-
- Therefore, the following implementation conformance requirements are
- in place:
-
- (1) For a read-only, public directory, anonymous authentication,
- described in section 5, can be used.
-
- (2) Implementations providing password-based authenticated
- access MUST support authentication using the DIGEST-MD5 SASL
- mechanism [4], as described in section 6.1. This provides
- client authentication with protection against passive
- eavesdropping attacks, but does not provide protection
- against active intermediary attacks.
-
- (3) For a directory needing session protection and
- authentication, the Start TLS extended operation [5], and
- either the simple authentication choice or the SASL EXTERNAL
- mechanism, are to be used together. Implementations SHOULD
- support authentication with a password as described in
- section 6.2, and SHOULD support authentication with a
- certificate as described in section 7.1. Together, these
- can provide integrity and disclosure protection of
- transmitted data, and authentication of client and server,
- including protection against active intermediary attacks.
-
- If TLS is negotiated, the client MUST discard all information about
- the server fetched prior to the TLS negotiation. In particular, the
- value of supportedSASLMechanisms MAY be different after TLS has been
- negotiated (specifically, the EXTERNAL mechanism or the proposed
- PLAIN mechanism are likely to only be listed after a TLS negotiation
- has been performed).
-
- If a SASL security layer is negotiated, the client MUST discard all
- information about the server fetched prior to SASL. In particular,
- if the client is configured to support multiple SASL mechanisms, it
- SHOULD fetch supportedSASLMechanisms both before and after the SASL
- security layer is negotiated and verify that the value has not
- changed after the SASL security layer was negotiated. This detects
- active attacks which remove supported SASL mechanisms from the
- supportedSASLMechanisms list, and allows the client to ensure that it
- is using the best mechanism supported by both client and server
- (additionally, this is a SHOULD to allow for environments where the
- supported SASL mechanisms list is provided to the client through a
- different trusted source, e.g. as part of a digitally signed object).
-
-
-
-
-Wahl, et al. Standards Track [Page 6]
-
-RFC 2829 Authentication Methods for LDAP May 2000
-
-
-5. Anonymous authentication
-
- Directory operations which modify entries or access protected
- attributes or entries generally require client authentication.
- Clients which do not intend to perform any of these operations
- typically use anonymous authentication.
-
- LDAP implementations MUST support anonymous authentication, as
- defined in section 5.1.
-
- LDAP implementations MAY support anonymous authentication with TLS,
- as defined in section 5.2.
-
- While there MAY be access control restrictions to prevent access to
- directory entries, an LDAP server SHOULD allow an anonymously-bound
- client to retrieve the supportedSASLMechanisms attribute of the root
- DSE.
-
- An LDAP server MAY use other information about the client provided by
- the lower layers or external means to grant or deny access even to
- anonymously authenticated clients.
-
-5.1. Anonymous authentication procedure
-
- An LDAP client which has not successfully completed a bind operation
- on a connection is anonymously authenticated.
-
- An LDAP client MAY also specify anonymous authentication in a bind
- request by using a zero-length OCTET STRING with the simple
- authentication choice.
-
-5.2. Anonymous authentication and TLS
-
- An LDAP client MAY use the Start TLS operation [5] to negotiate the
- use of TLS security [6]. If the client has not bound beforehand,
- then until the client uses the EXTERNAL SASL mechanism to negotiate
- the recognition of the client's certificate, the client is
- anonymously authenticated.
-
- Recommendations on TLS ciphersuites are given in section 10.
-
- An LDAP server which requests that clients provide their certificate
- during TLS negotiation MAY use a local security policy to determine
- whether to successfully complete TLS negotiation if the client did
- not present a certificate which could be validated.
-
-
-
-
-
-
-Wahl, et al. Standards Track [Page 7]
-
-RFC 2829 Authentication Methods for LDAP May 2000
-
-
-6. Password-based authentication
-
- LDAP implementations MUST support authentication with a password
- using the DIGEST-MD5 SASL mechanism for password protection, as
- defined in section 6.1.
-
- LDAP implementations SHOULD support authentication with the "simple"
- password choice when the connection is protected against
- eavesdropping using TLS, as defined in section 6.2.
-
-6.1. Digest authentication
-
- An LDAP client MAY determine whether the server supports this
- mechanism by performing a search request on the root DSE, requesting
- the supportedSASLMechanisms attribute, and checking whether the
- string "DIGEST-MD5" is present as a value of this attribute.
-
- In the first stage of authentication, when the client is performing
- an "initial authentication" as defined in section 2.1 of [4], the
- client sends a bind request in which the version number is 3, the
- authentication choice is sasl, the sasl mechanism name is "DIGEST-
- MD5", and the credentials are absent. The client then waits for a
- response from the server to this request.
-
- The server will respond with a bind response in which the resultCode
- is saslBindInProgress, and the serverSaslCreds field is present. The
- contents of this field is a string defined by "digest-challenge" in
- section 2.1.1 of [4]. The server SHOULD include a realm indication
- and MUST indicate support for UTF-8.
-
- The client will send a bind request with a distinct message id, in
- which the version number is 3, the authentication choice is sasl, the
- sasl mechanism name is "DIGEST-MD5", and the credentials contain the
- string defined by "digest-response" in section 2.1.2 of [4]. The
- serv-type is "ldap".
-
- The server will respond with a bind response in which the resultCode
- is either success, or an error indication. If the authentication is
- successful and the server does not support subsequent authentication,
- then the credentials field is absent. If the authentication is
- successful and the server supports subsequent authentication, then
- the credentials field contains the string defined by "response-auth"
- in section 2.1.3 of [4]. Support for subsequent authentication is
- OPTIONAL in clients and servers.
-
-
-
-
-
-
-
-Wahl, et al. Standards Track [Page 8]
-
-RFC 2829 Authentication Methods for LDAP May 2000
-
-
-6.2. "simple" authentication choice under TLS encryption
-
- A user who has a directory entry containing a userPassword attribute
- MAY authenticate to the directory by performing a simple password
- bind sequence following the negotiation of a TLS ciphersuite
- providing connection confidentiality [6].
-
- The client will use the Start TLS operation [5] to negotiate the use
- of TLS security [6] on the connection to the LDAP server. The client
- need not have bound to the directory beforehand.
-
- For this authentication procedure to be successful, the client and
- server MUST negotiate a ciphersuite which contains a bulk encryption
- algorithm of appropriate strength. Recommendations on cipher suites
- are given in section 10.
-
- Following the successful completion of TLS negotiation, the client
- MUST send an LDAP bind request with the version number of 3, the name
- field containing the name of the user's entry, and the "simple"
- authentication choice, containing a password.
-
- The server will, for each value of the userPassword attribute in the
- named user's entry, compare these for case-sensitive equality with
- the client's presented password. If there is a match, then the
- server will respond with resultCode success, otherwise the server
- will respond with resultCode invalidCredentials.
-
-6.3. Other authentication choices with TLS
-
- It is also possible, following the negotiation of TLS, to perform a
- SASL authentication which does not involve the exchange of plaintext
- reusable passwords. In this case the client and server need not
- negotiate a ciphersuite which provides confidentiality if the only
- service required is data integrity.
-
-7. Certificate-based authentication
-
- LDAP implementations SHOULD support authentication via a client
- certificate in TLS, as defined in section 7.1.
-
-7.1. Certificate-based authentication with TLS
-
- A user who has a public/private key pair in which the public key has
- been signed by a Certification Authority may use this key pair to
- authenticate to the directory server if the user's certificate is
- requested by the server. The user's certificate subject field SHOULD
- be the name of the user's directory entry, and the Certification
- Authority must be sufficiently trusted by the directory server to
-
-
-
-Wahl, et al. Standards Track [Page 9]
-
-RFC 2829 Authentication Methods for LDAP May 2000
-
-
- have issued the certificate in order that the server can process the
- certificate. The means by which servers validate certificate paths
- is outside the scope of this document.
-
- A server MAY support mappings for certificates in which the subject
- field name is different from the name of the user's directory entry.
- A server which supports mappings of names MUST be capable of being
- configured to support certificates for which no mapping is required.
-
- The client will use the Start TLS operation [5] to negotiate the use
- of TLS security [6] on the connection to the LDAP server. The client
- need not have bound to the directory beforehand.
-
- In the TLS negotiation, the server MUST request a certificate. The
- client will provide its certificate to the server, and MUST perform a
- private key-based encryption, proving it has the private key
- associated with the certificate.
-
- As deployments will require protection of sensitive data in transit,
- the client and server MUST negotiate a ciphersuite which contains a
- bulk encryption algorithm of appropriate strength. Recommendations
- of cipher suites are given in section 10.
-
- The server MUST verify that the client's certificate is valid. The
- server will normally check that the certificate is issued by a known
- CA, and that none of the certificates on the client's certificate
- chain are invalid or revoked. There are several procedures by which
- the server can perform these checks.
-
- Following the successful completion of TLS negotiation, the client
- will send an LDAP bind request with the SASL "EXTERNAL" mechanism.
-
-8. Other mechanisms
-
- The LDAP "simple" authentication choice is not suitable for
- authentication on the Internet where there is no network or transport
- layer confidentiality.
-
- As LDAP includes native anonymous and plaintext authentication
- methods, the "ANONYMOUS" and "PLAIN" SASL mechanisms are not used
- with LDAP. If an authorization identity of a form different from a
- DN is requested by the client, a mechanism that protects the password
- in transit SHOULD be used.
-
- The following SASL-based mechanisms are not considered in this
- document: KERBEROS_V4, GSSAPI and SKEY.
-
-
-
-
-
-Wahl, et al. Standards Track [Page 10]
-
-RFC 2829 Authentication Methods for LDAP May 2000
-
-
- The "EXTERNAL" SASL mechanism can be used to request the LDAP server
- make use of security credentials exchanged by a lower layer. If a TLS
- session has not been established between the client and server prior
- to making the SASL EXTERNAL Bind request and there is no other
- external source of authentication credentials (e.g. IP-level
- security [8]), or if, during the process of establishing the TLS
- session, the server did not request the client's authentication
- credentials, the SASL EXTERNAL bind MUST fail with a result code of
- inappropriateAuthentication. Any client authentication and
- authorization state of the LDAP association is lost, so the LDAP
- association is in an anonymous state after the failure.
-
-9. Authorization Identity
-
- The authorization identity is carried as part of the SASL credentials
- field in the LDAP Bind request and response.
-
- When the "EXTERNAL" mechanism is being negotiated, if the credentials
- field is present, it contains an authorization identity of the
- authzId form described below.
-
- Other mechanisms define the location of the authorization identity in
- the credentials field.
-
- The authorization identity is a string in the UTF-8 character set,
- corresponding to the following ABNF [7]:
-
- ; Specific predefined authorization (authz) id schemes are
- ; defined below -- new schemes may be defined in the future.
-
- authzId = dnAuthzId / uAuthzId
-
- ; distinguished-name-based authz id.
- dnAuthzId = "dn:" dn
- dn = utf8string ; with syntax defined in RFC 2253
-
- ; unspecified userid, UTF-8 encoded.
- uAuthzId = "u:" userid
- userid = utf8string ; syntax unspecified
-
- A utf8string is defined to be the UTF-8 encoding of one or more ISO
- 10646 characters.
-
- All servers which support the storage of authentication credentials,
- such as passwords or certificates, in the directory MUST support the
- dnAuthzId choice.
-
-
-
-
-
-Wahl, et al. Standards Track [Page 11]
-
-RFC 2829 Authentication Methods for LDAP May 2000
-
-
- The uAuthzId choice allows for compatibility with client applications
- which wish to authenticate to a local directory but do not know their
- own Distinguished Name or have a directory entry. The format of the
- string is defined as only a sequence of UTF-8 encoded ISO 10646
- characters, and further interpretation is subject to prior agreement
- between the client and server.
-
- For example, the userid could identify a user of a specific directory
- service, or be a login name or the local-part of an RFC 822 email
- address. In general a uAuthzId MUST NOT be assumed to be globally
- unique.
-
- Additional authorization identity schemes MAY be defined in future
- versions of this document.
-
-10. TLS Ciphersuites
-
- The following ciphersuites defined in [6] MUST NOT be used for
- confidentiality protection of passwords or data:
-
- TLS_NULL_WITH_NULL_NULL
- TLS_RSA_WITH_NULL_MD5
- TLS_RSA_WITH_NULL_SHA
-
- The following ciphersuites defined in [6] can be cracked easily (less
- than a week of CPU time on a standard CPU in 1997). The client and
- server SHOULD carefully consider the value of the password or data
- being protected before using these ciphersuites:
-
- TLS_RSA_EXPORT_WITH_RC4_40_MD5
- TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
- TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
- TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
- TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
- TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
- TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
- TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
- TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
-
- The following ciphersuites are vulnerable to man-in-the-middle
- attacks, and SHOULD NOT be used to protect passwords or sensitive
- data, unless the network configuration is such that the danger of a
- man-in-the-middle attack is tolerable:
-
-
-
-
-
-
-
-
-Wahl, et al. Standards Track [Page 12]
-
-RFC 2829 Authentication Methods for LDAP May 2000
-
-
- TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
- TLS_DH_anon_WITH_RC4_128_MD5
- TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
- TLS_DH_anon_WITH_DES_CBC_SHA
- TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
-
- A client or server that supports TLS MUST support at least
- TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.
-
-11. SASL service name for LDAP
-
- For use with SASL [2], a protocol must specify a service name to be
- used with various SASL mechanisms, such as GSSAPI. For LDAP, the
- service name is "ldap", which has been registered with the IANA as a
- GSSAPI service name.
-
-12. Security Considerations
-
- Security issues are discussed throughout this memo; the
- (unsurprising) conclusion is that mandatory security is important,
- and that session encryption is required when snooping is a problem.
-
- Servers are encouraged to prevent modifications by anonymous users.
- Servers may also wish to minimize denial of service attacks by timing
- out idle connections, and returning the unwillingToPerform result
- code rather than performing computationally expensive operations
- requested by unauthorized clients.
-
- A connection on which the client has not performed the Start TLS
- operation or negotiated a suitable SASL mechanism for connection
- integrity and encryption services is subject to man-in-the-middle
- attacks to view and modify information in transit.
-
- Additional security considerations relating to the EXTERNAL mechanism
- to negotiate TLS can be found in [2], [5] and [6].
-
-13. Acknowledgements
-
- This document is a product of the LDAPEXT Working Group of the IETF.
- The contributions of its members is greatly appreciated.
-
-
-
-
-
-
-
-
-
-
-
-Wahl, et al. Standards Track [Page 13]
-
-RFC 2829 Authentication Methods for LDAP May 2000
-
-
-14. Bibliography
-
- [1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
- Protocol (v3)", RFC 2251, December 1997.
-
- [2] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC
- 2222, October 1997.
-
- [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March 1997.
-
- [4] Leach, P. and C. Newman, "Using Digest Authentication as a SASL
- Mechanism", RFC 2831, May 2000.
-
- [5] Hodges, J., Morgan, R. and M. Wahl, "Lightweight Directory Access
- Protocol (v3): Extension for Transport Layer Security", RFC 2830,
- May 2000.
-
- [6] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
- 2246, January 1999.
-
- [7] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
-
- [8] Kent, S. and R. Atkinson, "Security Architecture for the Internet
- Protocol", RFC 2401, November 1998.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wahl, et al. Standards Track [Page 14]
-
-RFC 2829 Authentication Methods for LDAP May 2000
-
-
-15. Authors' Addresses
-
- Mark Wahl
- Sun Microsystems, Inc.
- 8911 Capital of Texas Hwy #4140
- Austin TX 78759
- USA
-
- EMail: M.Wahl@innosoft.com
-
-
- Harald Tveit Alvestrand
- EDB Maxware
- Pirsenteret
- N-7462 Trondheim, Norway
-
- Phone: +47 73 54 57 97
- EMail: Harald@Alvestrand.no
-
-
- Jeff Hodges
- Oblix, Inc.
- 18922 Forge Drive
- Cupertino, CA 95014
- USA
-
- Phone: +1-408-861-6656
- EMail: JHodges@oblix.com
-
-
- RL "Bob" Morgan
- Computing and Communications
- University of Washington
- Seattle, WA 98105
- USA
-
- Phone: +1-206-221-3307
- EMail: rlmorgan@washington.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wahl, et al. Standards Track [Page 15]
-
-RFC 2829 Authentication Methods for LDAP May 2000
-
-
-16. Full Copyright Statement
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Wahl, et al. Standards Track [Page 16]
-
diff --git a/doc/rfc/rfc2830.txt b/doc/rfc/rfc2830.txt
deleted file mode 100644
index 7801c7d5b99ffa49d99cdc8444661a045d1323b1..0000000000000000000000000000000000000000
--- a/doc/rfc/rfc2830.txt
+++ /dev/null
@@ -1,675 +0,0 @@
-
-
-
-
-
-
-Network Working Group J. Hodges
-Request for Comments: 2830 Oblix Inc.
-Category: Standards Track R. Morgan
- Univ of Washington
- M. Wahl
- Sun Microsystems, Inc.
- May 2000
-
-
- Lightweight Directory Access Protocol (v3):
- Extension for Transport Layer Security
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
-Abstract
-
- This document defines the "Start Transport Layer Security (TLS)
- Operation" for LDAP [LDAPv3, TLS]. This operation provides for TLS
- establishment in an LDAP association and is defined in terms of an
- LDAP extended request.
-
-1. Conventions Used in this Document
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [ReqsKeywords].
-
-2. The Start TLS Request
-
- This section describes the Start TLS extended request and extended
- response themselves: how to form the request, the form of the
- response, and enumerates the various result codes the client MUST be
- prepared to handle.
-
- The section following this one then describes how to sequence an
- overall Start TLS Operation.
-
-
-
-
-
-Hodges, et al. Standards Track [Page 1]
-
-RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
-
-
-2.1. Requesting TLS Establishment
-
- A client may perform a Start TLS operation by transmitting an LDAP
- PDU containing an ExtendedRequest [LDAPv3] specifying the OID for the
- Start TLS operation:
-
- 1.3.6.1.4.1.1466.20037
-
- An LDAP ExtendedRequest is defined as follows:
-
- ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
- requestName [0] LDAPOID,
- requestValue [1] OCTET STRING OPTIONAL }
-
- A Start TLS extended request is formed by setting the requestName
- field to the OID string given above. The requestValue field is
- absent. The client MUST NOT send any PDUs on this connection
- following this request until it receives a Start TLS extended
- response.
-
- When a Start TLS extended request is made, the server MUST return an
- LDAP PDU containing a Start TLS extended response. An LDAP
- ExtendedResponse is defined as follows:
-
- ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
- COMPONENTS OF LDAPResult,
- responseName [10] LDAPOID OPTIONAL,
- response [11] OCTET STRING OPTIONAL }
-
- A Start TLS extended response MUST contain a responseName field which
- MUST be set to the same string as that in the responseName field
- present in the Start TLS extended request. The response field is
- absent. The server MUST set the resultCode field to either success or
- one of the other values outlined in section 2.3.
-
-2.2. "Success" Response
-
- If the ExtendedResponse contains a resultCode of success, this
- indicates that the server is willing and able to negotiate TLS. Refer
- to section 3, below, for details.
-
-2.3. Response other than "success"
-
- If the ExtendedResponse contains a resultCode other than success,
- this indicates that the server is unwilling or unable to negotiate
- TLS.
-
-
-
-
-
-Hodges, et al. Standards Track [Page 2]
-
-RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
-
-
- If the Start TLS extended request was not successful, the resultCode
- will be one of:
-
- operationsError (operations sequencing incorrect; e.g. TLS already
- established)
-
- protocolError (TLS not supported or incorrect PDU structure)
-
- referral (this server doesn't do TLS, try this one)
-
- unavailable (e.g. some major problem with TLS, or server is
- shutting down)
-
- The server MUST return operationsError if the client violates any of
- the Start TLS extended operation sequencing requirements described in
- section 3, below.
-
- If the server does not support TLS (whether by design or by current
- configuration), it MUST set the resultCode to protocolError (see
- section 4.1.1 of [LDAPv3]), or to referral. The server MUST include
- an actual referral value in the LDAP Result if it returns a
- resultCode of referral. The client's current session is unaffected if
- the server does not support TLS. The client MAY proceed with any LDAP
- operation, or it MAY close the connection.
-
- The server MUST return unavailable if it supports TLS but cannot
- establish a TLS connection for some reason, e.g. the certificate
- server not responding, it cannot contact its TLS implementation, or
- if the server is in process of shutting down. The client MAY retry
- the StartTLS operation, or it MAY proceed with any other LDAP
- operation, or it MAY close the connection.
-
-3. Sequencing of the Start TLS Operation
-
- This section describes the overall procedures clients and servers
- MUST follow for TLS establishment. These procedures take into
- consideration various aspects of the overall security of the LDAP
- association including discovery of resultant security level and
- assertion of the client's authorization identity.
-
- Note that the precise effects, on a client's authorization identity,
- of establishing TLS on an LDAP association are described in detail in
- section 5.
-
-
-
-
-
-
-
-
-Hodges, et al. Standards Track [Page 3]
-
-RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
-
-
-3.1. Requesting to Start TLS on an LDAP Association
-
- The client MAY send the Start TLS extended request at any time after
- establishing an LDAP association, except that in the following cases
- the client MUST NOT send a Start TLS extended request:
-
- - if TLS is currently established on the connection, or
- - during a multi-stage SASL negotiation, or
- - if there are any LDAP operations outstanding on the connection.
-
- The result of violating any of these requirements is a resultCode of
- operationsError, as described above in section 2.3.
-
- The client MAY have already performed a Bind operation when it sends
- a Start TLS request, or the client might have not yet bound.
-
- If the client did not establish a TLS connection before sending any
- other requests, and the server requires the client to establish a TLS
- connection before performing a particular request, the server MUST
- reject that request with a confidentialityRequired or
- strongAuthRequired result. The client MAY send a Start TLS extended
- request, or it MAY choose to close the connection.
-
-3.2. Starting TLS
-
- The server will return an extended response with the resultCode of
- success if it is willing and able to negotiate TLS. It will return
- other resultCodes, documented above, if it is unable.
-
- In the successful case, the client, which has ceased to transfer LDAP
- requests on the connection, MUST either begin a TLS negotiation or
- close the connection. The client will send PDUs in the TLS Record
- Protocol directly over the underlying transport connection to the
- server to initiate TLS negotiation [TLS].
-
-3.3. TLS Version Negotiation
-
- Negotiating the version of TLS or SSL to be used is a part of the TLS
- Handshake Protocol, as documented in [TLS]. Please refer to that
- document for details.
-
-3.4. Discovery of Resultant Security Level
-
- After a TLS connection is established on an LDAP association, both
- parties MUST individually decide whether or not to continue based on
- the privacy level achieved. Ascertaining the TLS connection's privacy
- level is implementation dependent, and accomplished by communicating
- with one's respective local TLS implementation.
-
-
-
-Hodges, et al. Standards Track [Page 4]
-
-RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
-
-
- If the client or server decides that the level of authentication or
- privacy is not high enough for it to continue, it SHOULD gracefully
- close the TLS connection immediately after the TLS negotiation has
- completed (see sections 4.1 and 5.2, below).
-
- The client MAY attempt to Start TLS again, or MAY send an unbind
- request, or send any other LDAP request.
-
-3.5. Assertion of Client's Authorization Identity
-
- The client MAY, upon receipt of a Start TLS extended response
- indicating success, assert that a specific authorization identity be
- utilized in determining the client's authorization status. The client
- accomplishes this via an LDAP Bind request specifying a SASL
- mechanism of "EXTERNAL" [SASL]. See section 5.1.2, below.
-
-3.6. Server Identity Check
-
- The client MUST check its understanding of the server's hostname
- against the server's identity as presented in the server's
- Certificate message, in order to prevent man-in-the-middle attacks.
-
- Matching is performed according to these rules:
-
- - The client MUST use the server hostname it used to open the LDAP
- connection as the value to compare against the server name as
- expressed in the server's certificate. The client MUST NOT use the
- server's canonical DNS name or any other derived form of name.
-
- - If a subjectAltName extension of type dNSName is present in the
- certificate, it SHOULD be used as the source of the server's
- identity.
-
- - Matching is case-insensitive.
-
- - The "*" wildcard character is allowed. If present, it applies only
- to the left-most name component.
-
- E.g. *.bar.com would match a.bar.com, b.bar.com, etc. but not
- bar.com. If more than one identity of a given type is present in the
- certificate (e.g. more than one dNSName name), a match in any one of
- the set is considered acceptable.
-
- If the hostname does not match the dNSName-based identity in the
- certificate per the above check, user-oriented clients SHOULD either
- notify the user (clients MAY give the user the opportunity to
-
-
-
-
-
-Hodges, et al. Standards Track [Page 5]
-
-RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
-
-
- continue with the connection in any case) or terminate the connection
- and indicate that the server's identity is suspect. Automated clients
- SHOULD close the connection, returning and/or logging an error
- indicating that the server's identity is suspect.
-
- Beyond the server identity checks described in this section, clients
- SHOULD be prepared to do further checking to ensure that the server
- is authorized to provide the service it is observed to provide. The
- client MAY need to make use of local policy information.
-
-3.7. Refresh of Server Capabilities Information
-
- The client MUST refresh any cached server capabilities information
- (e.g. from the server's root DSE; see section 3.4 of [LDAPv3]) upon
- TLS session establishment. This is necessary to protect against
- active-intermediary attacks which may have altered any server
- capabilities information retrieved prior to TLS establishment. The
- server MAY advertise different capabilities after TLS establishment.
-
-4. Closing a TLS Connection
-
-4.1. Graceful Closure
-
- Either the client or server MAY terminate the TLS connection on an
- LDAP association by sending a TLS closure alert. This will leave the
- LDAP association intact.
-
- Before closing a TLS connection, the client MUST either wait for any
- outstanding LDAP operations to complete, or explicitly abandon them
- [LDAPv3].
-
- After the initiator of a close has sent a closure alert, it MUST
- discard any TLS messages until it has received an alert from the
- other party. It will cease to send TLS Record Protocol PDUs, and
- following the receipt of the alert, MAY send and receive LDAP PDUs.
-
- The other party, if it receives a closure alert, MUST immediately
- transmit a TLS closure alert. It will subsequently cease to send TLS
- Record Protocol PDUs, and MAY send and receive LDAP PDUs.
-
-4.2. Abrupt Closure
-
- Either the client or server MAY abruptly close the entire LDAP
- association and any TLS connection established on it by dropping the
- underlying TCP connection. A server MAY beforehand send the client a
- Notice of Disconnection [LDAPv3] in this case.
-
-
-
-
-
-Hodges, et al. Standards Track [Page 6]
-
-RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
-
-
-5. Effects of TLS on a Client's Authorization Identity
-
- This section describes the effects on a client's authorization
- identity brought about by establishing TLS on an LDAP association.
- The default effects are described first, and next the facilities for
- client assertion of authorization identity are discussed including
- error conditions. Lastly, the effects of closing the TLS connection
- are described.
-
- Authorization identities and related concepts are defined in
- [AuthMeth].
-
-5.1. TLS Connection Establishment Effects
-
-5.1.1. Default Effects
-
- Upon establishment of the TLS connection onto the LDAP association,
- any previously established authentication and authorization
- identities MUST remain in force, including anonymous state. This
- holds even in the case where the server requests client
- authentication via TLS -- e.g. requests the client to supply its
- certificate during TLS negotiation (see [TLS]).
-
-5.1.2. Client Assertion of Authorization Identity
-
- A client MAY either implicitly request that its LDAP authorization
- identity be derived from its authenticated TLS credentials or it MAY
- explicitly provide an authorization identity and assert that it be
- used in combination with its authenticated TLS credentials. The
- former is known as an implicit assertion, and the latter as an
- explicit assertion.
-
-5.1.2.1. Implicit Assertion
-
- An implicit authorization identity assertion is accomplished after
- TLS establishment by invoking a Bind request of the SASL form using
- the "EXTERNAL" mechanism name [SASL, LDAPv3] that SHALL NOT include
- the optional credentials octet string (found within the
- SaslCredentials sequence in the Bind Request). The server will derive
- the client's authorization identity from the authentication identity
- supplied in the client's TLS credentials (typically a public key
- certificate) according to local policy. The underlying mechanics of
- how this is accomplished are implementation specific.
-
-
-
-
-
-
-
-
-Hodges, et al. Standards Track [Page 7]
-
-RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
-
-
-5.1.2.2. Explicit Assertion
-
- An explicit authorization identity assertion is accomplished after
- TLS establishment by invoking a Bind request of the SASL form using
- the "EXTERNAL" mechanism name [SASL, LDAPv3] that SHALL include the
- credentials octet string. This string MUST be constructed as
- documented in section 9 of [AuthMeth].
-
-5.1.2.3. Error Conditions
-
- For either form of assertion, the server MUST verify that the
- client's authentication identity as supplied in its TLS credentials
- is permitted to be mapped to the asserted authorization identity. The
- server MUST reject the Bind operation with an invalidCredentials
- resultCode in the Bind response if the client is not so authorized.
-
- Additionally, with either form of assertion, if a TLS session has not
- been established between the client and server prior to making the
- SASL EXTERNAL Bind request and there is no other external source of
- authentication credentials (e.g. IP-level security [IPSEC]), or if,
- during the process of establishing the TLS session, the server did
- not request the client's authentication credentials, the SASL
- EXTERNAL bind MUST fail with a result code of
- inappropriateAuthentication.
-
- After the above Bind operation failures, any client authentication
- and authorization state of the LDAP association is lost, so the LDAP
- association is in an anonymous state after the failure. TLS
- connection state is unaffected, though a server MAY end the TLS
- connection, via a TLS close_notify message, based on the Bind failure
- (as it MAY at any time).
-
-5.2. TLS Connection Closure Effects
-
- Closure of the TLS connection MUST cause the LDAP association to move
- to an anonymous authentication and authorization state regardless of
- the state established over TLS and regardless of the authentication
- and authorization state prior to TLS connection establishment.
-
-6. Security Considerations
-
- The goals of using the TLS protocol with LDAP are to ensure
- connection confidentiality and integrity, and to optionally provide
- for authentication. TLS expressly provides these capabilities, as
- described in [TLS].
-
-
-
-
-
-
-Hodges, et al. Standards Track [Page 8]
-
-RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
-
-
- All security gained via use of the Start TLS operation is gained by
- the use of TLS itself. The Start TLS operation, on its own, does not
- provide any additional security.
-
- The use of TLS does not provide or ensure for confidentiality and/or
- non-repudiation of the data housed by an LDAP-based directory server.
- Nor does it secure the data from inspection by the server
- administrators. Once established, TLS only provides for and ensures
- confidentiality and integrity of the operations and data in transit
- over the LDAP association, and only if the implementations on the
- client and server support and negotiate it.
-
- The level of security provided though the use of TLS depends directly
- on both the quality of the TLS implementation used and the style of
- usage of that implementation. Additionally, an active-intermediary
- attacker can remove the Start TLS extended operation from the
- supportedExtension attribute of the root DSE. Therefore, both parties
- SHOULD independently ascertain and consent to the security level
- achieved once TLS is established and before beginning use of the TLS
- connection. For example, the security level of the TLS connection
- might have been negotiated down to plaintext.
-
- Clients SHOULD either warn the user when the security level achieved
- does not provide confidentiality and/or integrity protection, or be
- configurable to refuse to proceed without an acceptable level of
- security.
-
- Client and server implementors SHOULD take measures to ensure proper
- protection of credentials and other confidential data where such
- measures are not otherwise provided by the TLS implementation.
-
- Server implementors SHOULD allow for server administrators to elect
- whether and when connection confidentiality and/or integrity is
- required, as well as elect whether and when client authentication via
- TLS is required.
-
-7. Acknowledgements
-
- The authors thank Tim Howes, Paul Hoffman, John Kristian, Shirish
- Rai, Jonathan Trostle, Harald Alvestrand, and Marcus Leech for their
- contributions to this document.
-
-
-
-
-
-
-
-
-
-
-Hodges, et al. Standards Track [Page 9]
-
-RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
-
-
-8. References
-
- [AuthMeth] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan,
- "Authentication Methods for LDAP", RFC 2829, May 2000.
-
- [IPSEC] Kent, S. and R. Atkinson, "Security Architecture for
- the Internet Protocol", RFC 2401, November 1998.
-
- [LDAPv3] Wahl, M., Kille S. and T. Howes, "Lightweight
- Directory Access Protocol (v3)", RFC 2251, December
- 1997.
-
- [ReqsKeywords] Bradner, S., "Key Words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [SASL] Myers, J., "Simple Authentication and Security Layer
- (SASL)", RFC 2222, October 1997.
-
- [TLS] Dierks, T. and C. Allen. "The TLS Protocol Version
- 1.0", RFC 2246, January 1999.
-
-9. Authors' Addresses
-
- Jeff Hodges
- Oblix, Inc.
- 18922 Forge Drive
- Cupertino, CA 95014
- USA
-
- Phone: +1-408-861-6656
- EMail: JHodges@oblix.com
-
- RL "Bob" Morgan
- Computing and Communications
- University of Washington
- Seattle, WA
- USA
-
- Phone: +1-206-221-3307
- EMail: rlmorgan@washington.edu
-
- Mark Wahl
- Sun Microsystems, Inc.
- 8911 Capital of Texas Hwy #4140
- Austin TX 78759
- USA
-
- EMail: M.Wahl@innosoft.com
-
-
-
-Hodges, et al. Standards Track [Page 10]
-
-RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
-
-
-10. Intellectual Property Rights Notices
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication and any assurances of
- licenses to be made available, or the result of an attempt made to
- obtain a general license or permission for the use of such
- proprietary rights by implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hodges, et al. Standards Track [Page 11]
-
-RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
-
-
-11. Full Copyright Statement
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hodges, et al. Standards Track [Page 12]
-
diff --git a/doc/rfc/rfc3377.txt b/doc/rfc/rfc3377.txt
deleted file mode 100644
index 2aa26d5f104f6530cc1a5d4d3a917618befe32a4..0000000000000000000000000000000000000000
--- a/doc/rfc/rfc3377.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group J. Hodges
-Request for Comments: 3377 Sun Microsystems Inc.
-Category: Standards Track R. Morgan
- University of Washington
- September 2002
-
-
- Lightweight Directory Access Protocol (v3):
- Technical Specification
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
-Abstract
-
- This document specifies the set of RFCs comprising the Lightweight
- Directory Access Protocol Version 3 (LDAPv3), and addresses the "IESG
- Note" attached to RFCs 2251 through 2256.
-
-1. Background and Motivation
-
- The specification for the Lightweight Directory Access Protocol
- version 3 (LDAPv3) nominally comprises eight RFCs which were issued
- in two distinct subsets at separate times -- RFCs 2251 through 2256
- first, then RFCs 2829 and 2830 following later.
-
- RFC 2251 through 2256 do not mandate the implementation of any
- satisfactory authentication mechanisms and hence were published with
- an "IESG Note" discouraging implementation and deployment of LDAPv3
- clients or servers implementing update functionality until a Proposed
- Standard for mandatory authentication in LDAPv3 is published.
-
- RFC 2829 was subsequently published in answer to the IESG Note.
-
- The purpose of this document is to explicitly specify the set of RFCs
- comprising LDAPv3, and formally address the IESG Note through
- explicit inclusion of RFC 2829.
-
-
-
-
-
-Hodges & Morgan Standards Track [Page 1]
-
-RFC 3377 LDAPv3: Technical Specification September 2002
-
-
-2. Specification of LDAPv3
-
- The Lightweight Directory Access Protocol version 3 (LDAPv3) is
- specified by this set of nine RFCs:
-
- [RFC2251] Lightweight Directory Access Protocol (v3) [the
- specification of the LDAP on-the-wire protocol]
-
- [RFC2252] Lightweight Directory Access Protocol (v3): Attribute
- Syntax Definitions
-
- [RFC2253] Lightweight Directory Access Protocol (v3): UTF-8
- String Representation of Distinguished Names
-
- [RFC2254] The String Representation of LDAP Search Filters
-
- [RFC2255] The LDAP URL Format
-
- [RFC2256] A Summary of the X.500(96) User Schema for use with
- LDAPv3
-
- [RFC2829] Authentication Methods for LDAP
-
- [RFC2830] Lightweight Directory Access Protocol (v3): Extension
- for Transport Layer Security
-
- And, this document (RFC3377).
-
- The term "LDAPv3" is often used informally to refer to the protocol
- specified by the above set of RFCs, or subsets thereof. However, the
- LDAPv3 protocol suite, as defined here, should be formally identified
- in other documents by a normative reference to this document.
-
-3. Addressing the "IESG Note" in RFCs 2251 through 2256
-
- The IESG approved publishing RFCs 2251 through 2256 with an attendant
- IESG Note included in each document. The Note begins with:
-
- This document describes a directory access protocol that provides
- both read and update access. Update access requires secure
- authentication, but this document does not mandate implementation
- of any satisfactory authentication mechanisms.
-
-
-
-
-
-
-
-
-
-Hodges & Morgan Standards Track [Page 2]
-
-RFC 3377 LDAPv3: Technical Specification September 2002
-
-
- The Note ends with this statement:
-
- Implementors are hereby discouraged from deploying LDAPv3 clients
- or servers which implement the update functionality, until a
- Proposed Standard for mandatory authentication in LDAPv3 has been
- approved and published as an RFC.
-
- [RFC2829] is expressly the "Proposed Standard for mandatory
- authentication in LDAPv3" called for in the Note. Thus, the IESG
- Note in [RFC2251], [RFC2252], [RFC2253], [RFC2254], [RFC2255], and
- [RFC2256] is addressed.
-
-4. Security Considerations
-
- This document does not directly discuss security, although the
- context of the aforementioned IESG Note is security related, as is
- the manner in which it is addressed.
-
- Please refer to the referenced documents, especially [RFC2829],
- [RFC2251], and [RFC2830], for further information concerning LDAPv3
- security.
-
-5. Acknowledgements
-
- The authors thank Patrik Faltstrom, Leslie Daigle, Thomas Narten, and
- Kurt Zeilenga for their contributions to this document.
-
-6. References
-
- [RFC2251] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory
- Access Protocol (v3)", RFC 2251, December 1997.
-
- [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
- "Lightweight Directory Access Protocol (v3): Attribute
- Syntax Definitions", RFC 2252, December 1997.
-
- [RFC2253] Kille, S., Wahl, M. and T. Howes, "Lightweight Directory
- Access Protocol (v3): UTF-8 String Representation of
- Distinguished Names", RFC 2253, December 1997.
-
- [RFC2254] Howes, T., "The String Representation of LDAP Search
- Filters", RFC 2254, December 1997.
-
- [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
- December 1997.
-
- [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
- with LDAPv3", RFC 2256, December 1997.
-
-
-
-Hodges & Morgan Standards Track [Page 3]
-
-RFC 3377 LDAPv3: Technical Specification September 2002
-
-
- [RFC2829] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan,
- "Authentication Methods for LDAP", RFC 2829, May 2000.
-
- [RFC2830] Hodges, J., Morgan, R. and M. Wahl, "Lightweight Directory
- Access Protocol (v3): Extension for Transport Layer
- Security", RFC 2830, May 2000.
-
-7. Intellectual Property Rights Notices
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication and any assurances of
- licenses to be made available, or the result of an attempt made to
- obtain a general license or permission for the use of such
- proprietary rights by implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hodges & Morgan Standards Track [Page 4]
-
-RFC 3377 LDAPv3: Technical Specification September 2002
-
-
-8. Authors' Addresses
-
- Jeff Hodges
- Sun Microsystems, Inc.
- 901 San Antonio Road, USCA22-212
- Palo Alto, CA 94303
- USA
-
- Phone: +1-408-276-5467
- EMail: Jeff.Hodges@sun.com
-
-
- RL "Bob" Morgan
- Computing and Communications
- University of Washington
- Seattle, WA
- USA
-
- Phone: +1-206-221-3307
- EMail: rlmorgan@washington.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hodges & Morgan Standards Track [Page 5]
-
-RFC 3377 LDAPv3: Technical Specification September 2002
-
-
-9. Full Copyright Statement
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hodges & Morgan Standards Track [Page 6]
-
diff --git a/doc/rfc/rfc3383.txt b/doc/rfc/rfc3383.txt
deleted file mode 100644
index a0545cc9cd1258b7c68a721e6bdb51b38cd15d8e..0000000000000000000000000000000000000000
--- a/doc/rfc/rfc3383.txt
+++ /dev/null
@@ -1,1291 +0,0 @@
-
-
-
-
-
-
-Network Working Group K. Zeilenga
-Request for Comments: 3383 OpenLDAP Foundation
-BCP: 64 September 2002
-Category: Best Current Practice
-
-
- Internet Assigned Numbers Authority (IANA) Considerations
- for the Lightweight Directory Access Protocol (LDAP)
-
-Status of this Memo
-
- This document specifies an Internet Best Current Practices for the
- Internet Community, and requests discussion and suggestions for
- improvements. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
-Abstract
-
- This document provides procedures for registering extensible elements
- of the Lightweight Directory Access Protocol (LDAP). This document
- also provides guidelines to the Internet Assigned Numbers Authority
- (IANA) describing conditions under which new values can be assigned.
-
-1. Introduction
-
- The Lightweight Directory Access Protocol (LDAP) [RFC3377] is an
- extensible protocol. LDAP supports:
-
- - addition of new operations,
- - extension of existing operations, and
- - extensible schema.
-
- This document details procedures for registering values of used to
- unambiguously identify extensible elements of the protocol including:
-
- - LDAP message types;
- - LDAP extended operations and controls;
- - LDAP result codes;
- - LDAP authentication methods;
- - LDAP attribute description options; and
- - Object Identifier descriptors.
-
- These registries are maintained by the Internet Assigned Numbers
- Authority (IANA).
-
-
-
-
-Zeilenga Best Current Practice [Page 1]
-
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
- In addition, this document provides guidelines to IANA describing the
- conditions under which new values can be assigned.
-
-2. Terminology and Conventions
-
- This section details terms and conventions used in this document.
-
-2.1. Policy Terminology
-
- The terms "IESG Approval", "Standards Action", "IETF Consensus",
- "Specification Required", "First Come First Served", "Expert Review",
- and "Private Use" are used as defined in BCP 26 [RFC2434].
-
-2.2. Requirement Terminology
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119]. In
- this case, "the specification" as used by BCP 14 refers to the
- processing of protocols being submitted to the IETF standards
- process.
-
-2.3. Common ABNF Productions
-
- A number of syntaxes in this document are described using ABNF
- [RFC2234]. These syntaxes rely on the following common productions:
-
- ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
-
- LDIGIT = %x31-39 ; 1-9
-
- DIGIT = %x30 / LDIGIT ; 0-9
-
- HYPHEN = %x2D ; "-"
-
- DOT = %x2E ; "."
-
- number = DIGIT / ( LDIGIT 1*DIGIT )
-
- keychar = ALPHA / DIGIT / HYPHEN
-
- leadkeychar = ALPHA
-
- keystring = leadkeychar *keychar
-
- A keyword is a case-insensitive string of UTF-8 [RFC2279] encoded
- characters from the Universal Character Set (UCS) [ISO10646]
- restricted to the <keystring> production.
-
-
-
-Zeilenga Best Current Practice [Page 2]
-
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
-3. IANA Considerations for LDAP
-
- This section details each kind of protocol value which can be
- registered and provides IANA guidelines on how to assign new values.
-
- IANA may reject obviously bogus registration requests.
-
-3.1. Object Identifiers
-
- Numerous LDAP schema and protocol elements are identified by Object
- Identifiers. Specifications which assign OIDs to elements SHOULD
- state who delegated the OIDs for its use.
-
- For IETF developed elements, specifications SHOULD use OIDs under
- "Internet Directory Numbers" (1.3.6.1.1.x). Numbers under this OID
- arc will be assigned upon Expert Review with Specification Required.
- Only one OID per specification will be assigned. The specification
- MAY then assign any number of OIDs within this arc without further
- coordination with IANA.
-
- For elements developed by others, any properly delegated OID can
- be used, including those under "Internet Private Enterprise
- Numbers" (1.3.6.1.4.1.x) assigned by IANA
- <http://www.iana.org/cgi-bin/enterprise.pl>.
-
- To avoid interoperability problems between early implementations of
- "works in progress" and implementations of the published
- specification (e.g., the RFC), experimental OIDs SHOULD be used in
- "works in progress" and early implementations. OIDs under the
- Internet Experimental OID arc (1.3.6.1.3.x) may be used for this
- purpose.
-
- Experimental OIDs are not to used in published specifications (e.g.,
- RFCs).
-
- Practices for IANA assignment of Internet Enterprise and Experimental
- OIDs are detailed in STD 16 [RFC1155].
-
-3.2 Protocol Mechanisms
-
- LDAP provides a number of Root DSE attributes for discovery of
- protocol mechanisms identified by OIDs, including:
-
- - supportedControl [RFC2252] and
- - supportedExtension [RFC2252].
-
-
-
-
-
-
-Zeilenga Best Current Practice [Page 3]
-
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
- A registry of OIDs used for discover of protocol mechanisms is
- provided to allow implementors and others to locate the technical
- specification for these protocol mechanisms. Future specifications
- of additional Root DSE attributes holding values identifying protocol
- mechanisms MAY extend this registry for their values.
-
- OIDs associated with discoverable protocol mechanisms SHOULD be
- registered. These are be considered on a First Come First Served
- with Specification Required basis.
-
- OIDs associated with Standard Track mechanisms MUST be registered and
- require Standards Action.
-
-3.3. Object Identifier Descriptors
-
- LDAP allows short descriptive names (or descriptors) to be used
- instead of a numeric Object Identifier to identify protocol
- extensions [RFC2251], schema elements [RFC2252], LDAP URL [RFC2255]
- extensions, and other objects. Descriptors are restricted to strings
- of UTF-8 encoded UCS characters restricted by the following ABNF:
-
- name = keystring
-
- Descriptors are case-insensitive.
-
- Multiple names may be assigned to a given OID. For purposes of
- registration, an OID is to be represented in numeric OID form
- conforming to the ABNF:
-
- numericoid = number *( DOT number ) ; e.g., 1.1.0.23.40
-
- While the protocol places no maximum length restriction upon
- descriptors, they should be short. Descriptors longer than 48
- characters may be viewed as too long to register.
-
- A values ending with a hyphen ("-") reserve all descriptors which
- start with the value. For example, the registration of the option
- "descrFamily-" reserves all options which start with "descrFamily-"
- for some related purpose.
-
- Descriptors beginning with "x-" are for Private Use and cannot be
- registered.
-
- Descriptors beginning with "e-" are reserved for experiments and will
- be registered on a First Come First Served basis.
-
- All other descriptors require Expert Review to be registered.
-
-
-
-
-Zeilenga Best Current Practice [Page 4]
-
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
- The registrant need not "own" the OID being named.
-
- The OID namespace is managed by The ISO/IEC Joint Technical Committee
- 1 - Subcommittee 6.
-
-3.4. AttributeDescription Options
-
- An AttributeDescription [RFC2251, Section 4.1.5] can contain zero or
- more options specifying additional semantics. An option SHALL be
- restricted to a string UTF-8 encoded UCS characters limited by the
- following ABNF:
-
- option = keystring
-
- Options are case-insensitive.
-
- While the protocol places no maximum length restriction upon option
- strings, they should be short. Options longer than 24 characters may
- be viewed as too long to register.
-
- Values ending with a hyphen ("-") reserve all option names which
- start with the name. For example, the registration of the option
- "optionFamily-" reserves all options which start with "optionFamily-"
- for some related purpose.
-
- Options beginning with "x-" are for Private Use and cannot be
- registered.
-
- Options beginning with "e-" are reserved for experiments and will be
- registered on a First Come First Served basis.
-
- All other options require Standards Action or Expert Review with
- Specification Required to be registered.
-
-3.5. LDAP Message Types
-
- Each protocol message is encapsulated in an LDAPMessage envelope
- [RFC2251, Section 4.1.1]. The protocolOp CHOICE indicates the type
- of message encapsulated. Each message type consists of a keyword and
- a non-negative choice number is combined with the class (APPLICATION)
- and data type (CONSTRUCTED or PRIMITIVE) to construct the BER tag in
- the message's encoding. The choice numbers for existing protocol
- messages are implicit in the protocol's ASN.1 defined in [RFC2251].
-
- New values will be registered upon Standards Action.
-
- Note: LDAP provides extensible messages which reduces, but does not
- eliminate, the need to add new message types.
-
-
-
-Zeilenga Best Current Practice [Page 5]
-
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
-3.6. LDAP Result Codes
-
- LDAP result messages carry an resultCode enumerated value to indicate
- the outcome of the operation [RFC2251, Section 4.1.10]. Each result
- code consists of a keyword and a non-negative integer.
-
- New resultCodes integers in the range 0-1023 require Standards Action
- to be registered. New resultCode integers in the range 1024-4095
- require Expert Review with Specification Required. New resultCode
- integers in the range 4096-16383 will be registered on a First Come
- First Served basis. Keywords associated with integers in the range
- 0-4095 SHALL NOT start with "e-" or "x-". Keywords associated with
- integers in the range 4096-16383 SHALL start with "e-". Values
- greater than or equal to 16384 and keywords starting with "x-" are
- for Private Use and cannot be registered.
-
-3.7. LDAP Authentication Method
-
- The LDAP Bind operation supports multiple authentication methods
- [RFC2251, Section 4.2]. Each authentication choice consists of a
- keyword and a non-negative integer.
-
- The registrant SHALL classify the authentication method usage using
- one of the following terms:
-
- COMMON - method is appropriate for common use on the
- Internet,
- LIMITED USE - method is appropriate for limited use,
- OBSOLETE - method has been deprecated or otherwise found to be
- inappropriate for any use.
-
- Methods without publicly available specifications SHALL NOT be
- classified as COMMON. New registrations of class OBSOLETE cannot be
- registered.
-
- New authentication method integers in the range 0-1023 require
- Standards Action to be registered. New authentication method
- integers in the range 1024-4095 require Expert Review with
- Specification Required. New authentication method integers in the
- range 4096-16383 will be registered on a First Come First Served
- basis. Keywords associated with integers in the range 0-4095 SHALL
- NOT start with "e-" or "x-". Keywords associated with integers in
- the range 4096-16383 SHALL start with "e-". Values greater than or
- equal to 16384 and keywords starting with "x-" are for Private Use
- and cannot be registered.
-
- Note: LDAP supports SASL [RFC2222] as an Authentication CHOICE.
- SASL is an extensible LDAP authentication method.
-
-
-
-Zeilenga Best Current Practice [Page 6]
-
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
-3.8. Directory Systems Names
-
- The IANA-maintained "Directory Systems Names" registry [IANADSN] of
- valid keywords for well known attributes used in the LDAPv2 string
- representation of a distinguished name [RFC1779]. RFC 1779 was
- obsoleted by RFC 2253.
-
- Directory systems names are not known to be used in any other
- context. LDAPv3 uses Object Identifier Descriptors [Section 3.2]
- (which have a different syntax than directory system names).
-
- New Directory System Names will no longer be accepted. For
- historical purposes, the current list of registered names should
- remain publicly available.
-
-4. Registration Procedure
-
- The procedure given here MUST be used by anyone who wishes to use a
- new value of a type described in Section 3 of this document.
-
- The first step is for the requester to fill out the appropriate form.
- Templates are provided in Appendix A.
-
- If the policy is Standards Action, the completed form SHOULD be
- provided to the IESG with the request for Standards Action. Upon
- approval of the Standards Action, the IESG SHALL forward the request
- (possibly revised) to IANA. The IESG SHALL be viewed as the owner of
- all values requiring Standards Action.
-
- If the policy is Expert Review, the requester SHALL post the
- completed form to the <directory@apps.ietf.org> mailing list for
- public review. The review period is two (2) weeks. If a revised
- form is later submitted, the review period is restarted. Anyone
- may subscribe to this list by sending a request to
- <directory-request@apps.ietf.org>. During the review, objections
- may be raised by anyone (including the Expert) on the list. After
- completion of the review, the Expert, based upon public comments,
- SHALL either approve the request and forward it to the IESG OR deny
- the request. In either case, the Expert SHALL promptly notify the
- requester of the action. Actions of the Expert may be appealed
- [RFC2026]. The Expert is appointed by Applications Area Director(s).
- The requester is viewed as the owner of values registered under
- Expert Review.
-
- If the policy is First Come First Served, the requester SHALL submit
- the completed form directly to the IANA: <iana@iana.org>. The
- requester is viewed as the owner of values registered under First
- Come First Served.
-
-
-
-Zeilenga Best Current Practice [Page 7]
-
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
- Neither the Expert nor IANA will take position on the claims of
- copyright or trademarks issues regarding completed forms.
-
- Prior to submission of the Internet Draft (I-D) to the RFC Editor but
- after IESG review and tentative approval, the document editor SHOULD
- revise the I-D to use registered values.
-
-5. Registration Maintenance
-
- This section discusses maintenance of registrations.
-
-5.1. Lists of Registered Values
-
- IANA makes lists of registered values readily available to the
- Internet community on their web site: <http://www.iana.org/>.
-
-5.2. Change Control
-
- The registration owner MAY update the registration subject to the
- same constraints and review as with new registrations. In cases
- where the owner is not unable or unwilling to make necessary updates,
- the IESG MAY assert ownership in order to update the registration.
-
-5.3. Comments
-
- For cases where others (anyone other than the owner) have significant
- objections to the claims in a registration and the owner does not
- agree to change the registration, comments MAY be attached to a
- registration upon Expert Review. For registrations owned by the
- IESG, the objections SHOULD be addressed by initiating a request for
- Expert Review.
-
- The form of these requests is ad hoc, but MUST include the specific
- objections to be reviewed and SHOULD contain (directly or by
- reference) materials supporting the objections.
-
-6. Security Considerations
-
- The security considerations detailed in [RFC2434] are generally
- applicable to this document. Additional security considerations
- specific to each namespace are discussed in Section 3 where
- appropriate.
-
- Security considerations for LDAP are discussed in documents
- comprising the technical specification [RFC3377].
-
-
-
-
-
-
-Zeilenga Best Current Practice [Page 8]
-
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
-7. Acknowledgment
-
- This document is a product of the IETF LDAP Revision (LDAPbis)
- Working Group. Some text was borrowed from "Guidelines for Writing
- an IANA Considerations Section in RFCs" [RFC2434] by Thomas Narten
- and Harald Alvestrand.
-
-8. Normative References
-
- [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification
- of Management Information for TCP/IP-based Internets", STD
- 16, RFC 1155, May 1990.
-
- [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
- 3", BCP 9, RFC 2026, October 1996.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
-
- [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
- Access Protocol (v3)", RFC 2251, December 1997.
-
- [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
- "Lightweight Directory Access Protocol (v3): Attribute
- Syntax Definitions", RFC 2252, December 1997.
-
- [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
- December, 1997.
-
- [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
- with LDAPv3", RFC 2256, December 1997.
-
- [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", RFC 2279, January 1998.
-
- [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", BCP 26, RFC 2434,
- October 1998.
-
- [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
- Protocol (v3): Technical Specification", RFC 3377,
- September 2002.
-
- [IANADSN] IANA, "Directory Systems Names",
- http://www.iana.org/assignments/directory-system-names
-
-
-
-Zeilenga Best Current Practice [Page 9]
-
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
- [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
- Architecture and Basic Multilingual Plane, ISO/IEC
- 10646-1: 1993.
-
-10. Informative References
-
- [RFC1779] Kille, S., "A String Representation of Distinguished
- Names", RFC 1779, March 1995.
-
- [RFC2222] Myers, J., "Simple Authentication and Security Layer
- (SASL)", RFC 2222, October 1997.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Best Current Practice [Page 10]
-
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
-Appendix A. Registration Templates
-
- This appendix provides registration templates for registering new
- LDAP values.
-
-A.1. LDAP Object Identifier Registration Template
-
- Subject: Request for LDAP OID Registration
-
- Person & email address to contact for further information:
-
- Specification: (I-D)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request)
-
-A.2. LDAP Protocol Mechanism Registration Template
-
- Subject: Request for LDAP Protocol Mechanism Registration
-
- Object Identifier:
-
- Description:
-
- Person & email address to contact for further information:
-
- Usage: (One of Control or Extension)
-
- Specification: (I-D)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request)
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Best Current Practice [Page 11]
-
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
-A.3. LDAP Descriptor Registration Template
-
- Subject: Request for LDAP Descriptor Registration
-
- Descriptor (short name):
-
- Object Identifier:
-
- Person & email address to contact for further information:
-
- Usage: (One of attribute type, URL extension,
- object class, or other)
-
- Specification: (RFC, I-D, URI)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request)
-
-A.4. LDAP Attribute Description Option Registration Template
-
- Subject: Request for LDAP Attribute Description Option Registration
-
- Option Name:
-
- Family of Options: (YES or NO)
-
- Person & email address to contact for further information:
-
- Specification: (RFC, I-D, URI)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request)
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Best Current Practice [Page 12]
-
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
-A.5. LDAP Message Type Registration Template
-
- Subject: Request for LDAP Message Type Registration
-
- LDAP Message Name:
-
- Person & email address to contact for further information:
-
- Specification: (Approved I-D)
-
- Comments:
-
- (Any comments that the requester deems relevant to the request)
-
-A.6. LDAP Result Code Registration Template
-
- Subject: Request for LDAP Result Code Registration
-
- Result Code Name:
-
- Person & email address to contact for further information:
-
- Specification: (RFC, I-D, URI)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request)
-
-A.7. LDAP Authentication Method Registration Template
-
- Subject: Request for LDAP Authentication Method Registration
-
- Authentication Method Name:
-
- Person & email address to contact for further information:
-
- Specification: (RFC, I-D, URI)
-
- Intended Usage: (One of COMMON, LIMITED-USE, OBSOLETE)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request)
-
-
-
-
-Zeilenga Best Current Practice [Page 13]
-
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
-Appendix B. Assigned Values
-
- The following values are currently assigned.
-
-B.1. Object Identifiers
-
- Currently registered "Internet Private Enterprise Numbers" can be
- found at <http://www.iana.org/assignments/enterprise-numbers>.
-
- Currently registered "Internet Directory Numbers" can be found at
- <http://www.iana.org/assignments/smi-numbers>.
-
-B.2. Protocol Mechanisms
-
-Object Identifier Type Description Reference
--------------------------- ---- -------------- ---------
-1.2.840.113556.1.4.473 C Sort Request [RFC2891]
-1.2.840.113556.1.4.474 C Sort Response [RFC2891]
-1.3.6.1.4.1.1466.101.119.1 E Dynamic Refresh [RFC2589]
-1.3.6.1.4.1.1466.20037 E Start TLS [RFC2830]
-1.3.6.1.4.1.4203.1.11.1 E Modify Password [RFC3062]
-2.16.840.1.113730.3.4.2 C ManageDsaIT [RFC3296]
-
-Legend
-------------------------
-C => supportedControl
-E => supportedExtension
-
-B.3. Object Identifier Descriptors
-
-NAME Type OID [REF]
------------------------- ---- -----------------
-account O 0.9.2342.19200300.100.4.5 [RFC1274]
-alias O 2.5.6.1 [RFC2256]
-aliasedEntryName A 2.5.4.1 [X.501]
-aliasedObjectName A 2.5.4.1 [RFC2256]
-altServer A 1.3.6.1.4.1.1466.101.120.6 [RFC2252]
-applicationEntity O 2.5.6.12 [RFC2256]
-applicationProcess O 2.5.6.11 [RFC2256]
-aRecord A 0.9.2342.19200300.100.1.26 [RFC1274]
-associatedDomain A 0.9.2342.19200300.100.1.37 [RFC1274]
-associatedInternetGateway A 1.3.6.1.4.1.453.7.2.8 [RFC2164]
-associatedName A 0.9.2342.19200300.100.1.38 [RFC1274]
-associatedORAddress A 1.3.6.1.4.1.453.7.2.6 [RFC2164]
-associatedX400Gateway A 1.3.6.1.4.1.453.7.2.3 [RFC2164]
-attributeTypes A 2.5.21.5 [RFC2252]
-audio A 0.9.2342.19200300.100.1.55 [RFC1274]
-authorityRevocationList A 2.5.4.38 [RFC2256]
-
-
-
-Zeilenga Best Current Practice [Page 14]
-
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
-bitStringMatch M 2.5.13.16 [RFC2252]
-buildingName A 0.9.2342.19200300.100.1.48 [RFC1274]
-businessCategory A 2.5.4.15 [RFC2256]
-C A 2.5.4.6 [RFC2256]
-cACertificate A 2.5.4.37 [RFC2256]
-calCalAdrURI A 1.2.840.113556.1.4.481 [RFC2739]
-calCalURI A 1.2.840.113556.1.4.478 [RFC2739]
-calCAPURI A 1.2.840.113556.1.4.480 [RFC2739]
-calEntry O 1.2.840.113556.1.5.87 [RFC2739]
-calFBURL A 1.2.840.113556.1.4.479 [RFC2739]
-calOtherCalAdrURIs A 1.2.840.113556.1.4.485 [RFC2739]
-calOtherCalURIs A 1.2.840.113556.1.4.482 [RFC2739]
-calOtherCAPURIs A 1.2.840.113556.1.4.484 [RFC2739]
-calOtherFBURLs A 1.2.840.113556.1.4.483 [RFC2739]
-caseExactIA5Match M 1.3.6.1.4.1.1466.109.114.1 [RFC2252]
-caseIgnoreIA5Match M 1.3.6.1.4.1.1466.109.114.2 [RFC2252]
-caseIgnoreListMatch M 2.5.13.11 [RFC2252]
-caseIgnoreMatch M 2.5.13.2 [RFC2252]
-caseIgnoreOrderingMatch M 2.5.13.3 [RFC2252]
-caseIgnoreSubstringsMatch M 2.5.13.4 [RFC2252]
-certificateRevocationList A 2.5.4.39 [RFC2256]
-certificationAuthority O 2.5.6.16 [RFC2256]
-certificationAuthority-V2 O 2.5.6.16.2 [RFC2256]
-CN A 2.5.4.3 [RFC2256]
-cNAMERecord A 0.9.2342.19200300.100.1.31 [RFC1274]
-co A 0.9.2342.19200300.100.1.43 [RFC1274]
-commonName A 2.5.4.3 [RFC2256]
-country O 2.5.6.2 [RFC2256]
-countryName A 2.5.4.6 [RFC2256]
-createTimestamp A 2.5.18.1 [RFC2252]
-creatorsName A 2.5.18.3 [RFC2252]
-cRLDistributionPoint O 2.5.6.19 [RFC2256]
-crossCertificatePair A 2.5.4.40 [RFC2256]
-DC A 0.9.2342.19200300.100.1.25 [RFC2247]
-dcObject O 1.3.6.1.4.1.1466.344 [RFC2247]
-deltaCRL O 2.5.6.23 [RFC2587]
-deltaRevocationList A 2.5.4.53 [RFC2256]
-description A 2.5.4.13 [RFC2256]
-destinationIndicator A 2.5.4.27 [RFC2256]
-device O 2.5.6.14 [RFC2256]
-distinguishedName A 2.5.4.49 [RFC2256]
-distinguishedNameMatch M 2.5.13.1 [RFC2252]
-distinguishedNameTableEntry O 1.3.6.1.4.1.453.7.1.5 [RFC2293]
-distinguishedNameTableKey A 1.3.6.1.4.1.453.7.2.3 [RFC2293]
-dITContentRules A 2.5.21.2 [RFC2252]
-dITRedirect A 0.9.2342.19200300.100.1.54 [RFC1274]
-dITStructureRules A 2.5.21.1 [RFC2252]
-dmd O 2.5.6.20 [RFC2256]
-
-
-
-Zeilenga Best Current Practice [Page 15]
-
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
-dmdName A 2.5.4.54 [RFC2256]
-dnQualifier A 2.5.4.46 [RFC2256]
-dNSDomain O 0.9.2342.19200300.100.4.15 [RFC1274]
-document O 0.9.2342.19200300.100.4.6 [RFC1274]
-documentAuthor A 0.9.2342.19200300.100.1.14 [RFC1274]
-documentIdentifier A 0.9.2342.19200300.100.1.11 [RFC1274]
-documentLocation A 0.9.2342.19200300.100.1.15 [RFC1274]
-documentPublisher A 0.9.2342.19200300.100.1.56 [RFC1274]
-documentSeries O 0.9.2342.19200300.100.4.8 [RFC1274]
-documentTitle A 0.9.2342.19200300.100.1.12 [RFC1274]
-documentVersion A 0.9.2342.19200300.100.1.13 [RFC1274]
-domain O 0.9.2342.19200300.100.4.13 [RFC2247]
-domainComponent A 0.9.2342.19200300.100.1.25 [RFC2247]
-domainNameForm N 1.3.6.1.4.1.1466.345 [RFC2247]
-domainRelatedObject O 0.9.2342.19200300.100.4.17 [RFC1274]
-drink A 0.9.2342.19200300.100.1.5 [RFC1274]
-dSA O 2.5.6.13 [RFC2256]
-dSAQuality A 0.9.2342.19200300.100.1.49 [RFC1274]
-dynamicObject O 1.3.6.1.4.1.1466.101.119.2 [RFC2589]
-dynamicSubtrees A 1.3.6.1.4.1.1466.101.119.4 [RFC2589]
-enhancedSearchGuide A 2.5.4.47 [RFC2256]
-entryTtl A 1.3.6.1.4.1.1466.101.119.3 [RFC2589]
-extensibleObject O 1.3.6.1.4.1.1466.101.120.111 [RFC2252]
-facsimileTelephoneNumber A 2.5.4.23 [RFC2256]
-favouriteDrink A 0.9.2342.19200300.100.1.5 [RFC1274]
-friendlyCountry O 0.9.2342.19200300.100.4.18 [RFC1274]
-friendlyCountryName A 0.9.2342.19200300.100.1.43 [RFC1274]
-generalizedTimeMatch M 2.5.13.27 [RFC2252]
-generalizedTimeOrderingMatch M 2.5.13.28 [RFC2252]
-generationQualifier A 2.5.4.44 [RFC2256]
-givenName A 2.5.4.42 [RFC2256]
-GN A 2.5.4.42 [RFC2256]
-groupOfNames O 2.5.6.9 [RFC2256]
-groupOfUniqueNames O 2.5.6.17 [RFC2256]
-homePhone A 0.9.2342.19200300.100.1.20 [RFC1274]
-homePostalAddress A 0.9.2342.19200300.100.1.39 [RFC1274]
-homeTelephone A 0.9.2342.19200300.100.1.20 [RFC1274]
-host A 0.9.2342.19200300.100.1.9 [RFC1274]
-houseIdentifier A 2.5.4.51 [RFC2256]
-info A 0.9.2342.19200300.100.1.4 [RFC1274]
-initials A 2.5.4.43 [RFC2256]
-integerFirstComponentMatch M 2.5.13.29 [RFC2252]
-integerMatch M 2.5.13.14 [RFC2252]
-internationaliSDNNumber A 2.5.4.25 [RFC2256]
-janetMailbox A 0.9.2342.19200300.100.1.46 [RFC1274]
-jpegPhoto A 0.9.2342.19200300.100.1.60 [RFC1488]
-knowledgeInformation A 2.5.4.2 [RFC2256]
-L A 2.5.4.7 [RFC2256]
-
-
-
-Zeilenga Best Current Practice [Page 16]
-
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
-labeledURI A 1.3.6.1.4.1.250.1.57 [RFC2079]
-labeledURIObject A 1.3.6.1.4.1.250.3.15 [RFC2079]
-lastModifiedBy A 0.9.2342.19200300.100.1.24 [RFC1274]
-lastModifiedTime A 0.9.2342.19200300.100.1.23 [RFC1274]
-ldapSyntaxes A 1.3.6.1.4.1.1466.101.120.16 [RFC2252]
-locality O 2.5.6.3 [RFC2256]
-localityName A 2.5.4.7 [RFC2256]
-mail A 0.9.2342.19200300.100.1.3 [RFC2798]
-mailPreferenceOption A 0.9.2342.19200300.100.1.47 [RFC1274]
-manager A 0.9.2342.19200300.100.1.10 [RFC1274]
-matchingRules A 2.5.21.4 [RFC2252]
-matchingRuleUse A 2.5.21.8 [RFC2252]
-mcgamTables A 1.3.6.1.4.1.453.7.2.9 [RFC2164]
-mDRecord A 0.9.2342.19200300.100.1.27 [RFC1274]
-member A 2.5.4.31 [RFC2256]
-mixerGateway O 1.3.6.1.4.1.453.7.1.4 [RFC2164]
-mobile A 0.9.2342.19200300.100.1.41 [RFC1274]
-mobileTelephoneNumber A 0.9.2342.19200300.100.1.41 [RFC1274]
-modifiersName A 2.5.18.4 [RFC2252]
-modifyTimestamp A 2.5.18.2 [RFC2252]
-mXRecord A 0.9.2342.19200300.100.1.28 [RFC1274]
-name A 2.5.4.41 [RFC2256]
-nameForms A 2.5.21.7 [RFC2252]
-namingContexts A 1.3.6.1.4.1.1466.101.120.5 [RFC2252]
-nSRecord A 0.9.2342.19200300.100.1.29 [RFC1274]
-numericStringMatch M 2.5.13.8 [RFC2252]
-numericStringSubstringsMatch M 2.5.13.10 [RFC2252]
-O A 2.5.4.10 [RFC2256]
-objectClass A 2.5.4.0 [RFC2256]
-objectClasses A 2.5.21.6 [RFC2252]
-objectIdentifierFirstComponentMatch M 2.5.13.30 [RFC2252]
-objectIdentifiersMatch M 2.5.13.0 [RFC2252]
-octetStringMatch M 2.5.13.17 [RFC2252]
-omittedORAddressComponent O 1.3.6.1.4.1.453.7.1.3 [RFC2164]
-oRAddressComponentType A 1.3.6.1.4.1.453.7.2.7 [RFC2164]
-organization O 2.5.6.4 [RFC2256]
-organizationalPerson O 2.5.6.7 [RFC2256]
-organizationalRole O 2.5.6.8 [RFC2256]
-organizationalStatus A 0.9.2342.19200300.100.1.45 [RFC1274]
-organizationalUnit O 2.5.6.5 [RFC2256]
-organizationalUnitName A 2.5.4.11 [RFC2256]
-organizationName A 2.5.4.10 [RFC2256]
-otherMailbox A 0.9.2342.19200300.100.1.22 [RFC1274]
-OU A 2.5.4.11 [RFC2256]
-owner A 2.5.4.32 [RFC2256]
-pager A 0.9.2342.19200300.100.1.42 [RFC1274]
-pagerTelephoneNumber A 0.9.2342.19200300.100.1.42 [RFC1274]
-person O 2.5.6.6 [RFC2256]
-
-
-
-Zeilenga Best Current Practice [Page 17]
-
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
-personalSignature A 0.9.2342.19200300.100.1.53 [RFC1274]
-personalTitle A 0.9.2342.19200300.100.1.40 [RFC1274]
-photo A 0.9.2342.19200300.100.1.7 [RFC1274]
-physicalDeliveryOfficeName A 2.5.4.19 [RFC2256]
-pilotDSA O 0.9.2342.19200300.100.4.21 [RFC1274]
-pilotObject O 0.9.2342.19200300.100.4.3 [RFC1274]
-pilotOrganization O 0.9.2342.19200300.100.4.20 [RFC1274]
-pilotPerson O 0.9.2342.19200300.100.4.4 [RFC1274]
-pkiCA O 2.5.6.22 [RFC2587]
-pkiUser O 2.5.6.21 [RFC2587]
-postalAddress A 2.5.4.16 [RFC2256]
-postalCode A 2.5.4.17 [RFC2256]
-postOfficeBox A 2.5.4.18 [RFC2256]
-preferredDeliveryMethod A 2.5.4.28 [RFC2256]
-presentationAddress A 2.5.4.29 [RFC2256]
-presentationAddressMatch M 2.5.13.22 [RFC2252]
-protocolInformation A 2.5.4.48 [RFC2256]
-protocolInformationMatch M 2.5.13.24 [RFC2252]
-qualityLabelledData O 0.9.2342.19200300.100.4.22 [RFC1274]
-ref A 2.16.840.1.113730.3.1.34 [RFC3296]
-referral 0 2.16.840.1.113730.3.2.6 [RFC3296]
-registeredAddress A 2.5.4.26 [RFC2256]
-residentialPerson O 2.5.6.10 [RFC2256]
-RFC822LocalPart O 0.9.2342.19200300.100.4.14 [RFC1274]
-RFC822Mailbox A 0.9.2342.19200300.100.1.3 [RFC1274]
-rFC822ToX400Mapping O 1.3.6.1.4.1.453.7.1.1 [RFC2164]
-roleOccupant A 2.5.4.33 [RFC2256]
-room O 0.9.2342.19200300.100.4.7 [RFC1274]
-roomNumber A 0.9.2342.19200300.100.1.6 [RFC1274]
-searchGuide A 2.5.4.14 [RFC2256]
-secretary A 0.9.2342.19200300.100.1.21 [RFC1274]
-seeAlso A 2.5.4.34 [RFC2256]
-serialNumber A 2.5.4.5 [RFC2256]
-simpleSecurityObject O 0.9.2342.19200300.100.4.19 [RFC1274]
-singleLevelQuality A 0.9.2342.19200300.100.1.50 [RFC1274]
-SN A 2.5.4.4 [RFC2256]
-sOARecord A 0.9.2342.19200300.100.1.30 [RFC1274]
-ST A 2.5.4.8 [RFC2256]
-stateOrProvinceName A 2.5.4.8 [RFC2256]
-street A 2.5.4.9 [RFC2256]
-streetAddress A 2.5.4.9 [RFC2256]
-strongAuthenticationUser O 2.5.6.15 [RFC2256]
-subschema O 2.5.20.1 [RFC2252]
-subschemaSubentry A 2.5.18.10 [RFC2252]
-subtree O 1.3.6.1.4.1.453.7.1.1 [RFC2293]
-subtreeMaximumQuality A 0.9.2342.19200300.100.1.52 [RFC1274]
-subtreeMinimumQuality A 0.9.2342.19200300.100.1.51 [RFC1274]
-supportedAlgorithms A 2.5.4.52 [RFC2256]
-
-
-
-Zeilenga Best Current Practice [Page 18]
-
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
-supportedApplicationContext A 2.5.4.30 [RFC2256]
-supportedControl A 1.3.6.1.4.1.1466.101.120.13 [RFC2252]
-supportedExtension A 1.3.6.1.4.1.1466.101.120.7 [RFC2252]
-supportedLDAPVersion A 1.3.6.1.4.1.1466.101.120.15 [RFC2252]
-supportedSASLMechanisms A 1.3.6.1.4.1.1466.101.120.14 [RFC2252]
-surname A 2.5.4.4 [RFC2256]
-table O 1.3.6.1.4.1.453.7.1.2 [RFC2293]
-tableEntry O 1.3.6.1.4.1.453.7.1.3 [RFC2293]
-telephoneNumber A 2.5.4.20 [RFC2256]
-telephoneNumberMatch M 2.5.13.20 [RFC2252]
-telephoneNumberSubstringsMatch M 2.5.13.21 [RFC2252]
-teletexTerminalIdentifier A 2.5.4.22 [RFC2256]
-telexNumber A 2.5.4.21 [RFC2256]
-textEncodedORAddress A 0.9.2342.19200300.100.1.2 [RFC1274]
-textTableEntry O 1.3.6.1.4.1.453.7.1.4 [RFC2293]
-textTableKey A 1.3.6.1.4.1.453.7.2.1 [RFC2293]
-textTableValue A 1.3.6.1.4.1.453.7.2.2 [RFC2293]
-title A 2.5.4.12 [RFC2256]
-top O 2.5.6.0 [RFC2256]
-uid A 0.9.2342.19200300.100.1.1 [RFC2253]
-uniqueIdentifier A 0.9.2342.19200300.100.1.44 [RFC1274]
-uniqueMember A 2.5.4.50 [RFC2256]
-uniqueMemberMatch M 2.5.13.23 [RFC2252]
-userCertificate A 2.5.4.36 [RFC2256]
-userClass A 0.9.2342.19200300.100.1.8 [RFC1274]
-userId A 0.9.2342.19200300.100.1.1 [RFC1274]
-userPassword A 2.5.4.35 [RFC2256]
-userSecurityInformation O 2.5.6.18 [RFC2256]
-x121Address A 2.5.4.24 [RFC2256]
-x400ToRFC822Mapping O 1.3.6.1.4.1.453.7.1.2 [RFC2164]
-x500UniqueIdentifier A 2.5.4.45 [RFC2256]
-
-Legend
-------------------------
-A => Attribute Type
-C => DIT Content Rule
-E => LDAP URL Extension
-M => Matching Rule
-N => Name Form
-O => Object Class
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Best Current Practice [Page 19]
-
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
-B.4. Attribute Description Options
-
-Option Owner Reference
----------------- ----- ---------
-binary IESG [RFC2251]
-lang-* IESG [RFC2596]
-
-* family of options
-
-B.5. LDAPMessage types
-
-Name Code Owner Reference
---------------------------- ---- ----- ---------
-bindRequest 0 IESG [RFC2251]
-bindResponse 1 IESG [RFC2251]
-unbindRequest 2 IESG [RFC2251]
-searchRequest 3 IESG [RFC2251]
-searchResEntry 4 IESG [RFC2251]
-searchResDone 5 IESG [RFC2251]
-modifyRequest 6 IESG [RFC2251]
-modifyResponse 7 IESG [RFC2251]
-addRequest 8 IESG [RFC2251]
-addResponse 9 IESG [RFC2251]
-delRequest 10 IESG [RFC2251]
-delResponse 11 IESG [RFC2251]
-modDNRequest 12 IESG [RFC2251]
-modDNResponse 13 IESG [RFC2251]
-compareRequest 14 IESG [RFC2251]
-compareResponse 15 IESG [RFC2251]
-abandonRequest 16 IESG [RFC2251]
-reserved 17-18 IESG
-searchResRef 19 IESG [RFC2251]
-reserved 20-22 IESG
-extendedReq 23 IESG [RFC2251]
-extendedResp 24 IESG [RFC2251]
-
-B.6. resultCode values
-
-Name Code Owner Reference
---------------------------- ---- ----- ---------
-success 0 IESG [RFC2251]
-operationsError 1 IESG [RFC2251]
-protocolError 2 IESG [RFC2251]
-timeLimitExceeded 3 IESG [RFC2251]
-sizeLimitExceeded 4 IESG [RFC2251]
-compareFalse 5 IESG [RFC2251]
-compareTrue 6 IESG [RFC2251]
-authMethodNotSupported 7 IESG [RFC2251]
-
-
-
-Zeilenga Best Current Practice [Page 20]
-
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
-strongAuthRequired 8 IESG [RFC2251]
-reserved (partialResults) 9 IESG [RFC2251]
-referral 10 IESG [RFC2251]
-adminLimitExceeded 11 IESG [RFC2251]
-unavailableCriticalExtension 12 IESG [RFC2251]
-confidentialityRequired 13 IESG [RFC2251]
-saslBindInProgress 14 IESG [RFC2251]
-noSuchAttribute 16 IESG [RFC2251]
-undefinedAttributeType 17 IESG [RFC2251]
-inappropriateMatching 18 IESG [RFC2251]
-constraintViolation 19 IESG [RFC2251]
-attributeOrValueExists 20 IESG [RFC2251]
-invalidAttributeSyntax 21 IESG [RFC2251]
-noSuchObject 32 IESG [RFC2251]
-aliasProblem 33 IESG [RFC2251]
-invalidDNSyntax 34 IESG [RFC2251]
-reserved (isLeaf) 35 IESG [RFC2251]
-aliasDereferencingProblem 36 IESG [RFC2251]
-reserved 37-47 IESG
-inappropriateAuthentication 48 IESG [RFC2251]
-invalidCredentials 49 IESG [RFC2251]
-insufficientAccessRights 50 IESG [RFC2251]
-busy 51 IESG [RFC2251]
-unavailable 52 IESG [RFC2251]
-unwillingToPerform 53 IESG [RFC2251]
-loopDetect 54 IESG [RFC2251]
-reserved 55-63 IESG
-namingViolation 64 IESG [RFC2251]
-objectClassViolation 65 IESG [RFC2251]
-notAllowedOnNonLeaf 66 IESG [RFC2251]
-notAllowedOnRDN 67 IESG [RFC2251]
-entryAlreadyExists 68 IESG [RFC2251]
-objectClassModsProhibited 69 IESG [RFC2251]
-reserved (resultsTooLarge) 70 IESG [RFC2251]
-reserved 71-79 IESG
-other 80 IESG [RFC2251]
-reserved (APIs) 81-90 IESG [RFC2251]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Best Current Practice [Page 21]
-
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
-B.7. Bind Authentication Method
-
-Method Value Owner Usage Reference
------- ----- ----- ----------- -----------------
-simple 0 IESG LIMITED USE [RFC2251,RFC2829]
-krbv42LDAP 1 IESG OBSOLETE* [RFC1777]
-krbv42DSA 2 IESG OBSOLETE* [RFC1777]
-sasl 3 IESG COMMON [RFC2251,RFC2829]
-
-* These LDAPv2-only mechanisms were deprecated in favor of the
-LDAPv3 SASL authentication method, specifically the GSSAPI mechanism.
-
-Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- EMail: Kurt@OpenLDAP.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Best Current Practice [Page 22]
-
-RFC 3383 IANA Considerations for LDAP September 2002
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2002). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Best Current Practice [Page 23]
-
diff --git a/doc/rfc/rfc3674.txt b/doc/rfc/rfc3674.txt
deleted file mode 100644
index 396bb010bc2d38b7c6f2b34c23e051d495223ed6..0000000000000000000000000000000000000000
--- a/doc/rfc/rfc3674.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-
-
-
-
-
-
-Network Working Group K. Zeilenga
-Request for Comments: 3674 OpenLDAP Foundation
-Category: Standards Track December 2003
-
-
- Feature Discovery in Lightweight Directory Access Protocol (LDAP)
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-Abstract
-
- The Lightweight Directory Access Protocol (LDAP) is an extensible
- protocol with numerous elective features. This document introduces a
- general mechanism for discovery of elective features and extensions
- which cannot be discovered using existing mechanisms.
-
-1. Background and Intended Use
-
- The Lightweight Directory Access Protocol (LDAP) [RFC3377] is an
- extensible protocol with numerous elective features. LDAP provides
- mechanisms for a client to discover supported protocol versions,
- controls, extended operations, Simple Authentication and Security
- Layer (SASL) mechanisms, and subschema information. However, these
- mechanisms are not designed to support general feature discovery.
-
- This document describes a simple, general-purpose mechanism which
- clients may use to discover the set of elective features supported by
- a server. For example, this mechanism could be used by a client to
- discover whether or not the server supports requests for all
- operational attributes, e.g., "+" [RFC3673]. As another example,
- this mechanism could be used to discover absolute true, e.g., "(&)"
- and false, e.g., "(|)", search filters [T-F] support.
-
- This document extends the LDAP Protocol Mechanism registry [RFC3383]
- to support registration of values of the supportedFeatures attribute.
- This registry is managed by the Internet Assigned Numbers Authority
- (IANA).
-
-
-
-
-Zeilenga Standards Track [Page 1]
-
-RFC 3674 Feature Discovery in LDAP December 2003
-
-
- Schema definitions are provided using LDAP description formats
- [RFC2252]. Definitions provided here are formatted (line wrapped)
- for readability.
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14 [RFC2119].
-
-2. Discovery of supported features
-
- Each elective feature whose support may be discovered SHALL be
- identified by an Object Identifier (OID). A server advertises its
- support for a given feature by providing the OID associated with the
- feature as a value of the 'supportedFeatures' attribute held in the
- root DSE. A client may examine the values of this attribute to
- determine if a particular feature is supported by the server. A
- client MUST ignore values it doesn't recognize as they refer to
- elective features it doesn't implement.
-
- Features associated with Standard Track protocol mechanisms MUST be
- registered. Features associated with other protocol mechanisms
- SHOULD be registered. Procedures for registering protocol mechanisms
- are described in BCP 64 [RFC3383]. The word "Feature" should be
- placed in the usage field of the submitted LDAP Protocol Mechanism
- template.
-
- The 'supportedFeatures' attribute type is described as follows:
-
- ( 1.3.6.1.4.1.4203.1.3.5
- NAME 'supportedFeatures'
- DESC 'features supported by the server'
- EQUALITY objectIdentifierMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
- USAGE dSAOperation )
-
- Servers MUST be capable of recognizing this attribute type by the
- name 'supportedFeatures'. Servers MAY recognize the attribute type
- by other names.
-
-3. Security Considerations
-
- As rogue clients can discover features of a server by other means
- (such as by trial and error), this feature discovery mechanism is not
- believed to introduce any new security risk to LDAP.
-
-
-
-
-
-
-
-Zeilenga Standards Track [Page 2]
-
-RFC 3674 Feature Discovery in LDAP December 2003
-
-
-4. IANA Considerations
-
-4.1. Registration of Features as Protocol Mechanisms
-
- Future specifications detailing LDAP features are to register each
- feature as a LDAP Protocol Mechanism per guidance given in BCP 64
- [RFC3383]. A usage of "Feature" in a Protocol Mechanism registration
- template indicates that the value to be registered is associated with
- an LDAP feature.
-
-4.2. Registration of the supportedFeatures descriptor
-
- The IANA has registered the LDAP 'supportedFeatures' descriptor. The
- following registration template is suggested:
-
- Subject: Request for LDAP Descriptor Registration
- Descriptor (short name): supportedFeatures
- Object Identifier: 1.3.6.1.4.1.4203.1.3.5
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt@OpenLDAP.org>
- Usage: Attribute Type
- Specification: RFC 3674
- Author/Change Controller: IESG
-
- This OID was assigned [ASSIGN] by OpenLDAP Foundation under its IANA
- assigned private enterprise allocation [PRIVATE] for use in this
- specification.
-
-5. Acknowledgment
-
- This document is based upon input from the IETF LDAPEXT working
- group.
-
-6. Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication and any assurances of
- licenses to be made available, or the result of an attempt made to
- obtain a general license or permission for the use of such
- proprietary rights by implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
-
-
-Zeilenga Standards Track [Page 3]
-
-RFC 3674 Feature Discovery in LDAP December 2003
-
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-7. References
-
-7.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
- "Lightweight Directory Access Protocol (v3): Attribute
- Syntax Definitions", RFC 2252, December 1997.
-
- [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
- Protocol (v3): Technical Specification", RFC 3377,
- September 2002.
-
- [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority
- (IANA) Considerations for Lightweight Directory Access
- Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
-
-7.2. Informative References
-
- [RFC3673] Zeilenga, K., "Lightweight Directory Access Protocol
- version 3 (LDAPv3): All Operational Attributes", RFC
- 3673, December 2003.
-
- [T-F] Zeilenga, K., "LDAP True/False Filters", Work in
- Progress.
-
- [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
- http://www.openldap.org/foundation/oid-delegate.txt.
-
- [PRIVATE] IANA, "Private Enterprise Numbers",
- http://www.iana.org/assignments/enterprise-numbers.
-
-8. Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- EMail: Kurt@OpenLDAP.org
-
-
-
-
-
-Zeilenga Standards Track [Page 4]
-
-RFC 3674 Feature Discovery in LDAP December 2003
-
-
-9. Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assignees.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Standards Track [Page 5]
-
diff --git a/doc/rfc/rfc3771.txt b/doc/rfc/rfc3771.txt
deleted file mode 100644
index 52fecc4c9e07adff833353db89e126c3371d8630..0000000000000000000000000000000000000000
--- a/doc/rfc/rfc3771.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group R. Harrison
-Request for Comments: 3771 Novell, Inc.
-Updates: 2251 K. Zeilenga
-Category: Standards Track OpenLDAP Foundation
- April 2004
-
-
- The Lightweight Directory Access Protocol (LDAP)
- Intermediate Response Message
-
-Status of this Memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2004). All Rights Reserved.
-
-Abstract
-
- This document defines and describes the IntermediateResponse message,
- a general mechanism for defining single-request/multiple-response
- operations in Lightweight Directory Access Protocol (LDAP). The
- IntermediateResponse message is defined in such a way that the
- protocol behavior of existing LDAP operations is maintained. This
- message is intended to be used in conjunction with the LDAP
- ExtendedRequest and ExtendedResponse to define new single-
- request/multiple-response operations or in conjunction with a control
- when extending existing LDAP operations in a way that requires them
- to return intermediate response information.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Harrison & Zeilenga Standards Track [Page 1]
-
-RFC 3771 LDAP Intermediate Response April 2004
-
-
-1. Introduction
-
- The Lightweight Directory Access Protocol (LDAP), version 3 [RFC3377]
- is an extensible protocol. Extended operations ([RFC2251] Section
- 4.12) are defined to allow for the addition of operations to LDAP,
- without requiring revisions of the protocol. Similarly, controls
- ([RFC2251] Section 4.1.12) are defined to extend or modify the
- behavior of existing LDAP operations.
-
- LDAP is a client-request/server-response based protocol. With the
- exception of the search operation, the entire response to an
- operation request is returned in a single protocol data unit (i.e.,
- LDAP message). While this single-request/single-response paradigm is
- sufficient for many operations (including all but one of those
- currently defined by [RFC3377]), both intuition and practical
- experience validate the notion that it is insufficient for others.
-
- For example, the LDAP delete operation could be extended via a
- subtree control to mean that an entire subtree is to be deleted. A
- subtree delete operation needs to return continuation references
- based upon subordinate knowledge information contained in the server
- so that the client can complete the operation. Returning references
- as they are found, instead of with the final result, allows the
- client to perform the operation more efficiently because it does not
- have to wait for the final result to get this continuation reference
- information.
-
- Similarly, an engineer might choose to design the subtree delete
- operation as an extended operation of its own rather than using a
- subtree control in conjunction with the delete operation. Once
- again, the same continuation reference information is needed by the
- client to complete the operation, and sending the continuation
- references as they are found would allow the client to perform the
- operation more efficiently.
-
- Operations that are completed in stages or that progress through
- various states as they are completed might want to send intermediate
- responses to the client, thereby informing it of the status of the
- operation. For example, an LDAP implementation might define an
- extended operation to create a new replica of an administrative area
- on a server, and the operation is completed in three stages: (1)
- begin creation of replica, (2) send replica data to server, (3)
- replica creation complete. Intermediate messages might be sent from
- the server to the client at the beginning of each stage with the
- final response for the extended operation being sent after stage (3)
- is complete.
-
-
-
-
-
-Harrison & Zeilenga Standards Track [Page 2]
-
-RFC 3771 LDAP Intermediate Response April 2004
-
-
- As LDAP [RFC3377] is currently defined, there is no general LDAP
- message type that can be used to return intermediate results. A
- single, reusable LDAP message for carrying intermediate response
- information is desired to avoid repeated modification of the
- protocol. Although the ExtendedResponse message is defined in LDAP,
- it is defined to be the one and only response message to an
- ExtendedRequest message ([RFC2251] Section 4.12), for unsolicited
- notifications ([RFC2251] Section 4.4), and to return intermediate
- responses for the search operation ([RFC3377] Section 4.5.2, also see
- Section 5 below). The adaptation of ExtendedResponse as a general
- intermediate response mechanism would be problematic. In particular,
- existing APIs would likely have to be redesigned. It is believed
- (based upon operational experience) that the addition of a new
- message to carry intermediate result information is easier to
- implement and is less likely to cause interoperability problems with
- existing deployed implementations.
-
- This document defines and describes the LDAP IntermediateResponse
- message. This message is intended to be used in conjunction with
- ExtendedRequest and ExtendedResponse to define new single-
- request/multiple-response operations or in conjunction with a control
- when extending existing LDAP operations in a way that requires them
- to return intermediate response information.
-
- It is intended that the definitions and descriptions of extended
- operations and controls using the IntermediateResponse message will
- define the circumstances in which an IntermediateResponse message can
- be sent by a server and the associated meaning of the
- IntermediateResponse message sent in a particular circumstance.
- Similarly, it is intended that clients will explicitly solicit
- IntermediateResponse messages by issuing operations that specifically
- call for their return.
-
- The LDAP Content Sync Operation [ZEILENGA] demonstrates one use of
- LDAP Intermediate Response messages.
-
-2. Conventions used in this document
-
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in [RFC2119].
-
- The term "request control" is used to describe a control that is
- included in an LDAP request message sent from an LDAP client to an
- LDAP server.
-
-
-
-
-
-
-Harrison & Zeilenga Standards Track [Page 3]
-
-RFC 3771 LDAP Intermediate Response April 2004
-
-
-3. The IntermediateResponse Message
-
- This document extends the protocolOp CHOICE of LDAPMessage ([RFC2251]
- Section 4.1.1) to include the field:
-
- intermediateResponse IntermediateResponse
-
- where IntermediateResponse is defined as:
-
- IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
- responseName [0] LDAPOID OPTIONAL,
- responseValue [1] OCTET STRING OPTIONAL }
-
- IntermediateResponse messages SHALL NOT be returned to the client
- unless the client issues a request that specifically solicits their
- return. This document defines two forms of solicitation: extended
- operation and request control.
-
- Although the responseName and responseValue are optional in some
- circumstances, IntermediateResponse messages usually have a
- predefined responseName and a responseValue. The value of the
- responseName (if present), the syntax of the responseValue (if
- present) and the semantics associated with a particular
- IntermediateResponse message MUST be specified in documents
- describing the extended operation or request control that uses them.
- Sections 3.1 and 3.2 describe additional requirements for the
- inclusion of responseName and responseValue in IntermediateResponse
- messages.
-
-3.1. Usage with LDAP ExtendedRequest and ExtendedResponse
-
- A single-request/multiple-response operation may be defined using a
- single ExtendedRequest message to solicit zero or more
- IntermediateResponse messages, of one or more kinds, followed by an
- ExtendedResponse message.
-
- An extended operation that defines the return of multiple kinds of
- IntermediateResponse messages MUST provide and document a mechanism
- for the client to distinguish the kind of IntermediateResponse
- message being sent. This SHALL be accomplished by using different
- responseName values for each type of IntermediateResponse message
- associated with the extended operation or by including identifying
- information in the responseValue of each type of IntermediateResponse
- message associated with the extended operation.
-
-
-
-
-
-
-
-Harrison & Zeilenga Standards Track [Page 4]
-
-RFC 3771 LDAP Intermediate Response April 2004
-
-
-3.2. Usage with LDAP Request Controls
-
- Any LDAP operation may be extended by the addition of one or more
- controls ([RFC2251] Section 4.1.12). A control's semantics may
- include the return of zero or more IntermediateResponse messages
- prior to returning the final result code for the operation. One or
- more kinds of IntermediateResponse messages may be sent in response
- to a request control.
-
- All IntermediateResponse messages associated with request controls
- SHALL include a responseName. This requirement ensures that the
- client can correctly identify the source of IntermediateResponse
- messages when:
-
- a) two or more controls using IntermediateResponse messages are
- included in a request for any LDAP operation or
-
- b) one or more controls using IntermediateResponse messages are
- included in a request with an LDAP extended operation that uses
- IntermediateResponse messages.
-
- A request control that defines the return of multiple kinds of
- IntermediateResponse messages MUST provide and document a mechanism
- for the client to distinguish the kind of IntermediateResponse
- message being sent. This SHALL be accomplished by using different
- responseName values for each type of IntermediateResponse message
- associated with the request control or by including identifying
- information in the responseValue of each type of IntermediateResponse
- message associated with the request control.
-
-4. Advertising Support for IntermediateResponse Messages
-
- Because IntermediateResponse messages are associated with extended
- operations or controls and LDAP provides a means for advertising the
- extended operations and controls supported by a server (using the
- supportedExtension ([RFC2252] Section 5.2.3) and supportedControl
- ([RFC2252] Section 5.2.4) attributes of the root DSE), there is no
- need for a separate means of advertising support for intermediate
- response messages.
-
-5. Use of IntermediateResponse and ExtendedResponse with Search
-
- It is noted that ExtendedResponse messages may be sent in response to
- LDAP search operations with controls ([RFC2251] Section 4.5.2). This
- use of ExtendedResponse messages SHOULD be viewed as deprecated, in
- favor of use of the IntermediateResponse messages.
-
-
-
-
-
-Harrison & Zeilenga Standards Track [Page 5]
-
-RFC 3771 LDAP Intermediate Response April 2004
-
-
-6. Security Considerations
-
- This document describes an enhancement to LDAP. All security
- considerations of [RFC3377] apply to this document; however, it does
- not introduce any new security considerations to LDAP.
-
- Security considerations specific to each extension using this
- protocol mechanism shall be discussed in the technical specification
- detailing the extension.
-
-7. IANA Considerations
-
- Registration of the following value has been completed [RFC3383].
-
-7.1. LDAP Message Type
-
- The IANA has registered an LDAP Message Type (25) to identify the
- LDAP IntermediateResponse message as defined in section 3 of this
- document.
-
- The following registration template is suggested:
-
- Subject: Request for LDAP Message Type Registration
- Person & email address to contact for further information:
- Roger Harrison <roger_harrison@novell.com>
- Specification: RFC3771
- Author/Change Controller: IESG
- Comments: Identifies the LDAP IntermediateResponse Message
-
-8. Acknowledgments
-
- The authors would like to acknowledge the members of the IETF LDAP
- Extensions (ldapext) working group mail list who responded to the
- suggestion that a multiple-response paradigm might be useful for LDAP
- extended requests. Special thanks to two individuals: David Wilbur
- who first introduced the idea on the working group list, and Thomas
- Salter, who succinctly summarized the group's discussion.
-
-9. References
-
-9.1. Normative References
-
- [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
- Access Protocol (v3)", RFC 2251, December 1997.
-
-
-
-
-Harrison & Zeilenga Standards Track [Page 6]
-
-RFC 3771 LDAP Intermediate Response April 2004
-
-
- [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
- "Lightweight Directory Access Protocol (v3): Attribute
- Syntax Definitions", RFC 2252, December 1997.
-
- [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
- Protocol (v3): Technical Specification", RFC 3377,
- September 2002.
-
- [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
- Considerations for the Lightweight Directory Access
- Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
-
-9.2. Informative References
-
- [ZEILENGA] Zeilenga, K., "LDAP Content Synchronization Operation",
- Work in Progress, February 2004.
-
-10. Authors' Addresses
-
- Roger Harrison
- Novell, Inc.
- 1800 S. Novell Place
- Provo, UT 84606
-
- Phone: +1 801 861 2642
- EMail: roger_harrison@novell.com
-
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- EMail: Kurt@OpenLDAP.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Harrison & Zeilenga Standards Track [Page 7]
-
-RFC 3771 LDAP Intermediate Response April 2004
-
-
-11. Full Copyright Statement
-
- Copyright (C) The Internet Society (2004). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-Intellectual Property
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at ietf-
- ipr@ietf.org.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-Harrison & Zeilenga Standards Track [Page 8]
-
diff --git a/doc/rfc/rfc4510.txt b/doc/rfc/rfc4510.txt
new file mode 100644
index 0000000000000000000000000000000000000000..8ba41d1d932d12c42c50b50d40303304ad0a18a5
--- /dev/null
+++ b/doc/rfc/rfc4510.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group K. Zeilenga, Ed.
+Request for Comments: 4510 OpenLDAP Foundation
+Obsoletes: 2251, 2252, 2253, 2254, 2255, June 2006
+ 2256, 2829, 2830, 3377, 3771
+Category: Standards Track
+
+
+ Lightweight Directory Access Protocol (LDAP):
+ Technical Specification Road Map
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ The Lightweight Directory Access Protocol (LDAP) is an Internet
+ protocol for accessing distributed directory services that act in
+ accordance with X.500 data and service models. This document
+ provides a road map of the LDAP Technical Specification.
+
+1. The LDAP Technical Specification
+
+ The technical specification detailing version 3 of the Lightweight
+ Directory Access Protocol (LDAP), an Internet Protocol, consists of
+ this document and the following documents:
+
+ LDAP: The Protocol [RFC4511]
+ LDAP: Directory Information Models [RFC4512]
+ LDAP: Authentication Methods and Security Mechanisms [RFC4513]
+ LDAP: String Representation of Distinguished Names [RFC4514]
+ LDAP: String Representation of Search Filters [RFC4515]
+ LDAP: Uniform Resource Locator [RFC4516]
+ LDAP: Syntaxes and Matching Rules [RFC4517]
+ LDAP: Internationalized String Preparation [RFC4518]
+ LDAP: Schema for User Applications [RFC4519]
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 1]
+
+RFC 4510 LDAP: TS Road Map June 2006
+
+
+ The terms "LDAP" and "LDAPv3" are commonly used to refer informally
+ to the protocol specified by this technical specification. The LDAP
+ suite, as defined here, should be formally identified in other
+ documents by a normative reference to this document.
+
+ LDAP is an extensible protocol. Extensions to LDAP may be specified
+ in other documents. Nomenclature denoting such combinations of
+ LDAP-plus-extensions is not defined by this document but may be
+ defined in some future document(s). Extensions are expected to be
+ truly optional. Considerations for the LDAP extensions described in
+ BCP 118, RFC 4521 [RFC4521] fully apply to this revision of the LDAP
+ Technical Specification.
+
+ IANA (Internet Assigned Numbers Authority) considerations for LDAP
+ described in BCP 64, RFC 4520 [RFC4520] apply fully to this revision
+ of the LDAP technical specification.
+
+1.1. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+2. Relationship to X.500
+
+ This technical specification defines LDAP in terms of [X.500] as an
+ X.500 access mechanism. An LDAP server MUST act in accordance with
+ the X.500 (1993) series of International Telecommunication Union -
+ Telecommunication Standardization (ITU-T) Recommendations when
+ providing the service. However, it is not required that an LDAP
+ server make use of any X.500 protocols in providing this service.
+ For example, LDAP can be mapped onto any other directory system so
+ long as the X.500 data and service models [X.501][X.511], as used in
+ LDAP, are not violated in the LDAP interface.
+
+ This technical specification explicitly incorporates portions of
+ X.500(93). Later revisions of X.500 do not automatically apply to
+ this technical specification.
+
+3. Relationship to Obsolete Specifications
+
+ This technical specification, as defined in Section 1, obsoletes
+ entirely the previously defined LDAP technical specification defined
+ in RFC 3377 (and consisting of RFCs 2251-2256, 2829, 2830, 3771, and
+ 3377 itself). The technical specification was significantly
+ reorganized.
+
+
+
+
+
+Zeilenga Standards Track [Page 2]
+
+RFC 4510 LDAP: TS Road Map June 2006
+
+
+ This document replaces RFC 3377 as well as Section 3.3 of RFC 2251.
+ [RFC4512] replaces portions of RFC 2251, RFC 2252, and RFC 2256.
+ [RFC4511] replaces the majority RFC 2251, portions of RFC 2252, and
+ all of RFC 3771. [RFC4513] replaces RFC 2829, RFC 2830, and portions
+ of RFC 2251. [RFC4517] replaces the majority of RFC 2252 and
+ portions of RFC 2256. [RFC4519] replaces the majority of RFC 2256.
+ [RFC4514] replaces RFC 2253. [RFC4515] replaces RFC 2254. [RFC4516]
+ replaces RFC 2255.
+
+ [RFC4518] is new to this revision of the LDAP technical
+ specification.
+
+ Each document of this specification contains appendices summarizing
+ changes to all sections of the specifications they replace. Appendix
+ A.1 of this document details changes made to RFC 3377. Appendix A.2
+ of this document details changes made to Section 3.3 of RFC 2251.
+
+ Additionally, portions of this technical specification update and/or
+ replace a number of other documents not listed above. These
+ relationships are discussed in the documents detailing these portions
+ of this technical specification.
+
+4. Security Considerations
+
+ LDAP security considerations are discussed in each document
+ comprising the technical specification.
+
+5. Acknowledgements
+
+ This document is based largely on RFC 3377 by J. Hodges and R.
+ Morgan, a product of the LDAPBIS and LDAPEXT Working Groups. The
+ document also borrows from RFC 2251 by M. Wahl, T. Howes, and S.
+ Kille, a product of the ASID Working Group.
+
+ This document is a product of the IETF LDAPBIS Working Group.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 3]
+
+RFC 4510 LDAP: TS Road Map June 2006
+
+
+6. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+ [RFC4513] Harrison, R., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Authentication Methods and Security
+ Mechanisms", RFC 4513, June 2006.
+
+ [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access
+ Protocol (LDAP): String Representation of Distinguished
+ Names", RFC 4514, June 2006.
+
+ [RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory
+ Access Protocol (LDAP): String Representation of Search
+ Filters", RFC 4515, June 2006.
+
+ [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory
+ Access Protocol (LDAP): Uniform Resource Locator", RFC
+ 4516, June 2006.
+
+ [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Syntaxes and Matching Rules", RFC 4517, June
+ 2006.
+
+ [RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Internationalized String Preparation", RFC
+ 4518, June 2006.
+
+ [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Schema for User Applications", RFC
+ 4519, June 2006.
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
+ (IANA) Considerations for the Lightweight Directory
+ Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+ [RFC4521] Zeilenga, K., "Considerations for LDAP Extensions", BCP
+ 118, RFC 4521, June 2006.
+
+
+
+
+
+Zeilenga Standards Track [Page 4]
+
+RFC 4510 LDAP: TS Road Map June 2006
+
+
+ [X.500] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory -- Overview of concepts, models and
+ services", X.500(1993) (also ISO/IEC 9594-1:1994).
+
+ [X.501] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory -- Models", X.501(1993) (also ISO/IEC 9594-
+ 2:1994).
+
+ [X.511] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory: Abstract Service Definition", X.511(1993)
+ (also ISO/IEC 9594-3:1993).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 5]
+
+RFC 4510 LDAP: TS Road Map June 2006
+
+
+Appendix A. Changes to Previous Documents
+
+ This appendix outlines changes this document makes relative to the
+ documents it replaces (in whole or in part).
+
+A.1. Changes to RFC 3377
+
+ This document is nearly a complete rewrite of RFC 3377 as much of the
+ material of RFC 3377 is no longer applicable. The changes include
+ redefining the terms "LDAP" and "LDAPv3" to refer to this revision of
+ the technical specification.
+
+A.2. Changes to Section 3.3 of RFC 2251
+
+ The section was modified slightly (the word "document" was replaced
+ with "technical specification") to clarify that it applies to the
+ entire LDAP technical specification.
+
+Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 6]
+
+RFC 4510 LDAP: TS Road Map June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 7]
+
diff --git a/doc/rfc/rfc4511.txt b/doc/rfc/rfc4511.txt
new file mode 100644
index 0000000000000000000000000000000000000000..8041f30544f10de095d6ace4715e2db46abfcb5a
--- /dev/null
+++ b/doc/rfc/rfc4511.txt
@@ -0,0 +1,3811 @@
+
+
+
+
+
+
+Network Working Group J. Sermersheim, Ed.
+Request for Comments: 4511 Novell, Inc.
+Obsoletes: 2251, 2830, 3771 June 2006
+Category: Standards Track
+
+
+ Lightweight Directory Access Protocol (LDAP): The Protocol
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This document describes the protocol elements, along with their
+ semantics and encodings, of the Lightweight Directory Access Protocol
+ (LDAP). LDAP provides access to distributed directory services that
+ act in accordance with X.500 data and service models. These protocol
+ elements are based on those described in the X.500 Directory Access
+ Protocol (DAP).
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Relationship to Other LDAP Specifications ..................3
+ 2. Conventions .....................................................3
+ 3. Protocol Model ..................................................4
+ 3.1. Operation and LDAP Message Layer Relationship ..............5
+ 4. Elements of Protocol ............................................5
+ 4.1. Common Elements ............................................5
+ 4.1.1. Message Envelope ....................................6
+ 4.1.2. String Types ........................................7
+ 4.1.3. Distinguished Name and Relative Distinguished Name ..8
+ 4.1.4. Attribute Descriptions ..............................8
+ 4.1.5. Attribute Value .....................................8
+ 4.1.6. Attribute Value Assertion ...........................9
+ 4.1.7. Attribute and PartialAttribute ......................9
+ 4.1.8. Matching Rule Identifier ...........................10
+ 4.1.9. Result Message .....................................10
+ 4.1.10. Referral ..........................................12
+
+
+
+Sermersheim Standards Track [Page 1]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ 4.1.11. Controls ..........................................14
+ 4.2. Bind Operation ............................................16
+ 4.2.1. Processing of the Bind Request .....................17
+ 4.2.2. Bind Response ......................................18
+ 4.3. Unbind Operation ..........................................18
+ 4.4. Unsolicited Notification ..................................19
+ 4.4.1. Notice of Disconnection ............................19
+ 4.5. Search Operation ..........................................20
+ 4.5.1. Search Request .....................................20
+ 4.5.2. Search Result ......................................27
+ 4.5.3. Continuation References in the Search Result .......28
+ 4.6. Modify Operation ..........................................31
+ 4.7. Add Operation .............................................33
+ 4.8. Delete Operation ..........................................34
+ 4.9. Modify DN Operation .......................................34
+ 4.10. Compare Operation ........................................36
+ 4.11. Abandon Operation ........................................36
+ 4.12. Extended Operation .......................................37
+ 4.13. IntermediateResponse Message .............................39
+ 4.13.1. Usage with LDAP ExtendedRequest and
+ ExtendedResponse ..................................40
+ 4.13.2. Usage with LDAP Request Controls ..................40
+ 4.14. StartTLS Operation .......................................40
+ 4.14.1. StartTLS Request ..................................40
+ 4.14.2. StartTLS Response .................................41
+ 4.14.3. Removal of the TLS Layer ..........................41
+ 5. Protocol Encoding, Connection, and Transfer ....................42
+ 5.1. Protocol Encoding .........................................42
+ 5.2. Transmission Control Protocol (TCP) .......................43
+ 5.3. Termination of the LDAP session ...........................43
+ 6. Security Considerations ........................................43
+ 7. Acknowledgements ...............................................45
+ 8. Normative References ...........................................46
+ 9. Informative References .........................................48
+ 10. IANA Considerations ...........................................48
+ Appendix A. LDAP Result Codes .....................................49
+ A.1. Non-Error Result Codes ....................................49
+ A.2. Result Codes ..............................................49
+ Appendix B. Complete ASN.1 Definition .............................54
+ Appendix C. Changes ...............................................60
+ C.1. Changes Made to RFC 2251 ..................................60
+ C.2. Changes Made to RFC 2830 ..................................66
+ C.3. Changes Made to RFC 3771 ..................................66
+
+
+
+
+
+
+
+
+Sermersheim Standards Track [Page 2]
+
+RFC 4511 LDAPv3 June 2006
+
+
+1. Introduction
+
+ The Directory is "a collection of open systems cooperating to provide
+ directory services" [X.500]. A directory user, which may be a human
+ or other entity, accesses the Directory through a client (or
+ Directory User Agent (DUA)). The client, on behalf of the directory
+ user, interacts with one or more servers (or Directory System Agents
+ (DSA)). Clients interact with servers using a directory access
+ protocol.
+
+ This document details the protocol elements of the Lightweight
+ Directory Access Protocol (LDAP), along with their semantics.
+ Following the description of protocol elements, it describes the way
+ in which the protocol elements are encoded and transferred.
+
+1.1. Relationship to Other LDAP Specifications
+
+ This document is an integral part of the LDAP Technical Specification
+ [RFC4510], which obsoletes the previously defined LDAP technical
+ specification, RFC 3377, in its entirety.
+
+ This document, together with [RFC4510], [RFC4513], and [RFC4512],
+ obsoletes RFC 2251 in its entirety. Section 3.3 is obsoleted by
+ [RFC4510]. Sections 4.2.1 (portions) and 4.2.2 are obsoleted by
+ [RFC4513]. Sections 3.2, 3.4, 4.1.3 (last paragraph), 4.1.4, 4.1.5,
+ 4.1.5.1, 4.1.9 (last paragraph), 5.1, 6.1, and 6.2 (last paragraph)
+ are obsoleted by [RFC4512]. The remainder of RFC 2251 is obsoleted
+ by this document. Appendix C.1 summarizes substantive changes in the
+ remainder.
+
+ This document obsoletes RFC 2830, Sections 2 and 4. The remainder of
+ RFC 2830 is obsoleted by [RFC4513]. Appendix C.2 summarizes
+ substantive changes to the remaining sections.
+
+ This document also obsoletes RFC 3771 in entirety.
+
+2. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
+ to be interpreted as described in [RFC2119].
+
+ Character names in this document use the notation for code points and
+ names from the Unicode Standard [Unicode]. For example, the letter
+ "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
+
+
+
+
+
+
+Sermersheim Standards Track [Page 3]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ Note: a glossary of terms used in Unicode can be found in [Glossary].
+ Information on the Unicode character encoding model can be found in
+ [CharModel].
+
+ The term "transport connection" refers to the underlying transport
+ services used to carry the protocol exchange, as well as associations
+ established by these services.
+
+ The term "TLS layer" refers to Transport Layer Security (TLS)
+ services used in providing security services, as well as associations
+ established by these services.
+
+ The term "SASL layer" refers to Simply Authentication and Security
+ Layer (SASL) services used in providing security services, as well as
+ associations established by these services.
+
+ The term "LDAP message layer" refers to the LDAP Message Protocol
+ Data Unit (PDU) services used in providing directory services, as
+ well as associations established by these services.
+
+ The term "LDAP session" refers to combined services (transport
+ connection, TLS layer, SASL layer, LDAP message layer) and their
+ associations.
+
+ See the table in Section 5 for an illustration of these four terms.
+
+3. Protocol Model
+
+ The general model adopted by this protocol is one of clients
+ performing protocol operations against servers. In this model, a
+ client transmits a protocol request describing the operation to be
+ performed to a server. The server is then responsible for performing
+ the necessary operation(s) in the Directory. Upon completion of an
+ operation, the server typically returns a response containing
+ appropriate data to the requesting client.
+
+ Protocol operations are generally independent of one another. Each
+ operation is processed as an atomic action, leaving the directory in
+ a consistent state.
+
+ Although servers are required to return responses whenever such
+ responses are defined in the protocol, there is no requirement for
+ synchronous behavior on the part of either clients or servers.
+ Requests and responses for multiple operations generally may be
+ exchanged between a client and server in any order. If required,
+ synchronous behavior may be controlled by client applications.
+
+
+
+
+
+Sermersheim Standards Track [Page 4]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ The core protocol operations defined in this document can be mapped
+ to a subset of the X.500 (1993) Directory Abstract Service [X.511].
+ However, there is not a one-to-one mapping between LDAP operations
+ and X.500 Directory Access Protocol (DAP) operations. Server
+ implementations acting as a gateway to X.500 directories may need to
+ make multiple DAP requests to service a single LDAP request.
+
+3.1. Operation and LDAP Message Layer Relationship
+
+ Protocol operations are exchanged at the LDAP message layer. When
+ the transport connection is closed, any uncompleted operations at the
+ LDAP message layer are abandoned (when possible) or are completed
+ without transmission of the response (when abandoning them is not
+ possible). Also, when the transport connection is closed, the client
+ MUST NOT assume that any uncompleted update operations have succeeded
+ or failed.
+
+4. Elements of Protocol
+
+ The protocol is described using Abstract Syntax Notation One
+ ([ASN.1]) and is transferred using a subset of ASN.1 Basic Encoding
+ Rules ([BER]). Section 5 specifies how the protocol elements are
+ encoded and transferred.
+
+ In order to support future extensions to this protocol, extensibility
+ is implied where it is allowed per ASN.1 (i.e., sequence, set,
+ choice, and enumerated types are extensible). In addition, ellipses
+ (...) have been supplied in ASN.1 types that are explicitly
+ extensible as discussed in [RFC4520]. Because of the implied
+ extensibility, clients and servers MUST (unless otherwise specified)
+ ignore trailing SEQUENCE components whose tags they do not recognize.
+
+ Changes to the protocol other than through the extension mechanisms
+ described here require a different version number. A client
+ indicates the version it is using as part of the BindRequest,
+ described in Section 4.2. If a client has not sent a Bind, the
+ server MUST assume the client is using version 3 or later.
+
+ Clients may attempt to determine the protocol versions a server
+ supports by reading the 'supportedLDAPVersion' attribute from the
+ root DSE (DSA-Specific Entry) [RFC4512].
+
+4.1. Common Elements
+
+ This section describes the LDAPMessage envelope Protocol Data Unit
+ (PDU) format, as well as data type definitions, which are used in the
+ protocol operations.
+
+
+
+
+Sermersheim Standards Track [Page 5]
+
+RFC 4511 LDAPv3 June 2006
+
+
+4.1.1. Message Envelope
+
+ For the purposes of protocol exchanges, all protocol operations are
+ encapsulated in a common envelope, the LDAPMessage, which is defined
+ as follows:
+
+ LDAPMessage ::= SEQUENCE {
+ messageID MessageID,
+ protocolOp CHOICE {
+ bindRequest BindRequest,
+ bindResponse BindResponse,
+ unbindRequest UnbindRequest,
+ searchRequest SearchRequest,
+ searchResEntry SearchResultEntry,
+ searchResDone SearchResultDone,
+ searchResRef SearchResultReference,
+ modifyRequest ModifyRequest,
+ modifyResponse ModifyResponse,
+ addRequest AddRequest,
+ addResponse AddResponse,
+ delRequest DelRequest,
+ delResponse DelResponse,
+ modDNRequest ModifyDNRequest,
+ modDNResponse ModifyDNResponse,
+ compareRequest CompareRequest,
+ compareResponse CompareResponse,
+ abandonRequest AbandonRequest,
+ extendedReq ExtendedRequest,
+ extendedResp ExtendedResponse,
+ ...,
+ intermediateResponse IntermediateResponse },
+ controls [0] Controls OPTIONAL }
+
+ MessageID ::= INTEGER (0 .. maxInt)
+
+ maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
+
+ The ASN.1 type Controls is defined in Section 4.1.11.
+
+ The function of the LDAPMessage is to provide an envelope containing
+ common fields required in all protocol exchanges. At this time, the
+ only common fields are the messageID and the controls.
+
+ If the server receives an LDAPMessage from the client in which the
+ LDAPMessage SEQUENCE tag cannot be recognized, the messageID cannot
+ be parsed, the tag of the protocolOp is not recognized as a request,
+ or the encoding structures or lengths of data fields are found to be
+ incorrect, then the server SHOULD return the Notice of Disconnection
+
+
+
+Sermersheim Standards Track [Page 6]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ described in Section 4.4.1, with the resultCode set to protocolError,
+ and MUST immediately terminate the LDAP session as described in
+ Section 5.3.
+
+ In other cases where the client or server cannot parse an LDAP PDU,
+ it SHOULD abruptly terminate the LDAP session (Section 5.3) where
+ further communication (including providing notice) would be
+ pernicious. Otherwise, server implementations MUST return an
+ appropriate response to the request, with the resultCode set to
+ protocolError.
+
+4.1.1.1. MessageID
+
+ All LDAPMessage envelopes encapsulating responses contain the
+ messageID value of the corresponding request LDAPMessage.
+
+ The messageID of a request MUST have a non-zero value different from
+ the messageID of any other request in progress in the same LDAP
+ session. The zero value is reserved for the unsolicited notification
+ message.
+
+ Typical clients increment a counter for each request.
+
+ A client MUST NOT send a request with the same messageID as an
+ earlier request in the same LDAP session unless it can be determined
+ that the server is no longer servicing the earlier request (e.g.,
+ after the final response is received, or a subsequent Bind
+ completes). Otherwise, the behavior is undefined. For this purpose,
+ note that Abandon and successfully abandoned operations do not send
+ responses.
+
+4.1.2. String Types
+
+ The LDAPString is a notational convenience to indicate that, although
+ strings of LDAPString type encode as ASN.1 OCTET STRING types, the
+ [ISO10646] character set (a superset of [Unicode]) is used, encoded
+ following the UTF-8 [RFC3629] algorithm. Note that Unicode
+ characters U+0000 through U+007F are the same as ASCII 0 through 127,
+ respectively, and have the same single octet UTF-8 encoding. Other
+ Unicode characters have a multiple octet UTF-8 encoding.
+
+ LDAPString ::= OCTET STRING -- UTF-8 encoded,
+ -- [ISO10646] characters
+
+ The LDAPOID is a notational convenience to indicate that the
+ permitted value of this string is a (UTF-8 encoded) dotted-decimal
+ representation of an OBJECT IDENTIFIER. Although an LDAPOID is
+
+
+
+
+Sermersheim Standards Track [Page 7]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ encoded as an OCTET STRING, values are limited to the definition of
+ <numericoid> given in Section 1.4 of [RFC4512].
+
+ LDAPOID ::= OCTET STRING -- Constrained to <numericoid>
+ -- [RFC4512]
+
+ For example,
+
+ 1.3.6.1.4.1.1466.1.2.3
+
+4.1.3. Distinguished Name and Relative Distinguished Name
+
+ An LDAPDN is defined to be the representation of a Distinguished Name
+ (DN) after encoding according to the specification in [RFC4514].
+
+ LDAPDN ::= LDAPString
+ -- Constrained to <distinguishedName> [RFC4514]
+
+ A RelativeLDAPDN is defined to be the representation of a Relative
+ Distinguished Name (RDN) after encoding according to the
+ specification in [RFC4514].
+
+ RelativeLDAPDN ::= LDAPString
+ -- Constrained to <name-component> [RFC4514]
+
+4.1.4. Attribute Descriptions
+
+ The definition and encoding rules for attribute descriptions are
+ defined in Section 2.5 of [RFC4512]. Briefly, an attribute
+ description is an attribute type and zero or more options.
+
+ AttributeDescription ::= LDAPString
+ -- Constrained to <attributedescription>
+ -- [RFC4512]
+
+4.1.5. Attribute Value
+
+ A field of type AttributeValue is an OCTET STRING containing an
+ encoded attribute value. The attribute value is encoded according to
+ the LDAP-specific encoding definition of its corresponding syntax.
+ The LDAP-specific encoding definitions for different syntaxes and
+ attribute types may be found in other documents and in particular
+ [RFC4517].
+
+ AttributeValue ::= OCTET STRING
+
+
+
+
+
+
+Sermersheim Standards Track [Page 8]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ Note that there is no defined limit on the size of this encoding;
+ thus, protocol values may include multi-megabyte attribute values
+ (e.g., photographs).
+
+ Attribute values may be defined that have arbitrary and non-printable
+ syntax. Implementations MUST NOT display or attempt to decode an
+ attribute value if its syntax is not known. The implementation may
+ attempt to discover the subschema of the source entry and to retrieve
+ the descriptions of 'attributeTypes' from it [RFC4512].
+
+ Clients MUST only send attribute values in a request that are valid
+ according to the syntax defined for the attributes.
+
+4.1.6. Attribute Value Assertion
+
+ The AttributeValueAssertion (AVA) type definition is similar to the
+ one in the X.500 Directory standards. It contains an attribute
+ description and a matching rule ([RFC4512], Section 4.1.3) assertion
+ value suitable for that type. Elements of this type are typically
+ used to assert that the value in assertionValue matches a value of an
+ attribute.
+
+ AttributeValueAssertion ::= SEQUENCE {
+ attributeDesc AttributeDescription,
+ assertionValue AssertionValue }
+
+ AssertionValue ::= OCTET STRING
+
+ The syntax of the AssertionValue depends on the context of the LDAP
+ operation being performed. For example, the syntax of the EQUALITY
+ matching rule for an attribute is used when performing a Compare
+ operation. Often this is the same syntax used for values of the
+ attribute type, but in some cases the assertion syntax differs from
+ the value syntax. See objectIdentiferFirstComponentMatch in
+ [RFC4517] for an example.
+
+4.1.7. Attribute and PartialAttribute
+
+ Attributes and partial attributes consist of an attribute description
+ and attribute values. A PartialAttribute allows zero values, while
+ Attribute requires at least one value.
+
+ PartialAttribute ::= SEQUENCE {
+ type AttributeDescription,
+ vals SET OF value AttributeValue }
+
+
+
+
+
+
+Sermersheim Standards Track [Page 9]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ Attribute ::= PartialAttribute(WITH COMPONENTS {
+ ...,
+ vals (SIZE(1..MAX))})
+
+ No two of the attribute values may be equivalent as described by
+ Section 2.2 of [RFC4512]. The set of attribute values is unordered.
+ Implementations MUST NOT rely upon the ordering being repeatable.
+
+4.1.8. Matching Rule Identifier
+
+ Matching rules are defined in Section 4.1.3 of [RFC4512]. A matching
+ rule is identified in the protocol by the printable representation of
+ either its <numericoid> or one of its short name descriptors
+ [RFC4512], e.g., 'caseIgnoreMatch' or '2.5.13.2'.
+
+ MatchingRuleId ::= LDAPString
+
+4.1.9. Result Message
+
+ The LDAPResult is the construct used in this protocol to return
+ success or failure indications from servers to clients. To various
+ requests, servers will return responses containing the elements found
+ in LDAPResult to indicate the final status of the protocol operation
+ request.
+
+ LDAPResult ::= SEQUENCE {
+ resultCode ENUMERATED {
+ success (0),
+ operationsError (1),
+ protocolError (2),
+ timeLimitExceeded (3),
+ sizeLimitExceeded (4),
+ compareFalse (5),
+ compareTrue (6),
+ authMethodNotSupported (7),
+ strongerAuthRequired (8),
+ -- 9 reserved --
+ referral (10),
+ adminLimitExceeded (11),
+ unavailableCriticalExtension (12),
+ confidentialityRequired (13),
+ saslBindInProgress (14),
+ noSuchAttribute (16),
+ undefinedAttributeType (17),
+ inappropriateMatching (18),
+ constraintViolation (19),
+ attributeOrValueExists (20),
+ invalidAttributeSyntax (21),
+
+
+
+Sermersheim Standards Track [Page 10]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ -- 22-31 unused --
+ noSuchObject (32),
+ aliasProblem (33),
+ invalidDNSyntax (34),
+ -- 35 reserved for undefined isLeaf --
+ aliasDereferencingProblem (36),
+ -- 37-47 unused --
+ inappropriateAuthentication (48),
+ invalidCredentials (49),
+ insufficientAccessRights (50),
+ busy (51),
+ unavailable (52),
+ unwillingToPerform (53),
+ loopDetect (54),
+ -- 55-63 unused --
+ namingViolation (64),
+ objectClassViolation (65),
+ notAllowedOnNonLeaf (66),
+ notAllowedOnRDN (67),
+ entryAlreadyExists (68),
+ objectClassModsProhibited (69),
+ -- 70 reserved for CLDAP --
+ affectsMultipleDSAs (71),
+ -- 72-79 unused --
+ other (80),
+ ... },
+ matchedDN LDAPDN,
+ diagnosticMessage LDAPString,
+ referral [3] Referral OPTIONAL }
+
+ The resultCode enumeration is extensible as defined in Section 3.8 of
+ [RFC4520]. The meanings of the listed result codes are given in
+ Appendix A. If a server detects multiple errors for an operation,
+ only one result code is returned. The server should return the
+ result code that best indicates the nature of the error encountered.
+ Servers may return substituted result codes to prevent unauthorized
+ disclosures.
+
+ The diagnosticMessage field of this construct may, at the server's
+ option, be used to return a string containing a textual, human-
+ readable diagnostic message (terminal control and page formatting
+ characters should be avoided). As this diagnostic message is not
+ standardized, implementations MUST NOT rely on the values returned.
+ Diagnostic messages typically supplement the resultCode with
+ additional information. If the server chooses not to return a
+ textual diagnostic, the diagnosticMessage field MUST be empty.
+
+
+
+
+
+Sermersheim Standards Track [Page 11]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ For certain result codes (typically, but not restricted to
+ noSuchObject, aliasProblem, invalidDNSyntax, and
+ aliasDereferencingProblem), the matchedDN field is set (subject to
+ access controls) to the name of the last entry (object or alias) used
+ in finding the target (or base) object. This will be a truncated
+ form of the provided name or, if an alias was dereferenced while
+ attempting to locate the entry, of the resulting name. Otherwise,
+ the matchedDN field is empty.
+
+4.1.10. Referral
+
+ The referral result code indicates that the contacted server cannot
+ or will not perform the operation and that one or more other servers
+ may be able to. Reasons for this include:
+
+ - The target entry of the request is not held locally, but the server
+ has knowledge of its possible existence elsewhere.
+
+ - The operation is restricted on this server -- perhaps due to a
+ read-only copy of an entry to be modified.
+
+ The referral field is present in an LDAPResult if the resultCode is
+ set to referral, and it is absent with all other result codes. It
+ contains one or more references to one or more servers or services
+ that may be accessed via LDAP or other protocols. Referrals can be
+ returned in response to any operation request (except Unbind and
+ Abandon, which do not have responses). At least one URI MUST be
+ present in the Referral.
+
+ During a Search operation, after the baseObject is located, and
+ entries are being evaluated, the referral is not returned. Instead,
+ continuation references, described in Section 4.5.3, are returned
+ when other servers would need to be contacted to complete the
+ operation.
+
+ Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
+
+ URI ::= LDAPString -- limited to characters permitted in
+ -- URIs
+
+ If the client wishes to progress the operation, it contacts one of
+ the supported services found in the referral. If multiple URIs are
+ present, the client assumes that any supported URI may be used to
+ progress the operation.
+
+ Clients that follow referrals MUST ensure that they do not loop
+ between servers. They MUST NOT repeatedly contact the same server
+ for the same request with the same parameters. Some clients use a
+
+
+
+Sermersheim Standards Track [Page 12]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ counter that is incremented each time referral handling occurs for an
+ operation, and these kinds of clients MUST be able to handle at least
+ ten nested referrals while progressing the operation.
+
+ A URI for a server implementing LDAP and accessible via TCP/IP (v4 or
+ v6) [RFC793][RFC791] is written as an LDAP URL according to
+ [RFC4516].
+
+ Referral values that are LDAP URLs follow these rules:
+
+ - If an alias was dereferenced, the <dn> part of the LDAP URL MUST be
+ present, with the new target object name.
+
+ - It is RECOMMENDED that the <dn> part be present to avoid ambiguity.
+
+ - If the <dn> part is present, the client uses this name in its next
+ request to progress the operation, and if it is not present the
+ client uses the same name as in the original request.
+
+ - Some servers (e.g., participating in distributed indexing) may
+ provide a different filter in a URL of a referral for a Search
+ operation.
+
+ - If the <filter> part of the LDAP URL is present, the client uses
+ this filter in its next request to progress this Search, and if it
+ is not present the client uses the same filter as it used for that
+ Search.
+
+ - For Search, it is RECOMMENDED that the <scope> part be present to
+ avoid ambiguity.
+
+ - If the <scope> part is missing, the scope of the original Search is
+ used by the client to progress the operation.
+
+ - Other aspects of the new request may be the same as or different
+ from the request that generated the referral.
+
+ Other kinds of URIs may be returned. The syntax and semantics of
+ such URIs is left to future specifications. Clients may ignore URIs
+ that they do not support.
+
+ UTF-8 encoded characters appearing in the string representation of a
+ DN, search filter, or other fields of the referral value may not be
+ legal for URIs (e.g., spaces) and MUST be escaped using the % method
+ in [RFC3986].
+
+
+
+
+
+
+Sermersheim Standards Track [Page 13]
+
+RFC 4511 LDAPv3 June 2006
+
+
+4.1.11. Controls
+
+ Controls provide a mechanism whereby the semantics and arguments of
+ existing LDAP operations may be extended. One or more controls may
+ be attached to a single LDAP message. A control only affects the
+ semantics of the message it is attached to.
+
+ Controls sent by clients are termed 'request controls', and those
+ sent by servers are termed 'response controls'.
+
+ Controls ::= SEQUENCE OF control Control
+
+ Control ::= SEQUENCE {
+ controlType LDAPOID,
+ criticality BOOLEAN DEFAULT FALSE,
+ controlValue OCTET STRING OPTIONAL }
+
+ The controlType field is the dotted-decimal representation of an
+ OBJECT IDENTIFIER that uniquely identifies the control. This
+ provides unambiguous naming of controls. Often, response control(s)
+ solicited by a request control share controlType values with the
+ request control.
+
+ The criticality field only has meaning in controls attached to
+ request messages (except UnbindRequest). For controls attached to
+ response messages and the UnbindRequest, the criticality field SHOULD
+ be FALSE, and MUST be ignored by the receiving protocol peer. A
+ value of TRUE indicates that it is unacceptable to perform the
+ operation without applying the semantics of the control.
+ Specifically, the criticality field is applied as follows:
+
+ - If the server does not recognize the control type, determines that
+ it is not appropriate for the operation, or is otherwise unwilling
+ to perform the operation with the control, and if the criticality
+ field is TRUE, the server MUST NOT perform the operation, and for
+ operations that have a response message, it MUST return with the
+ resultCode set to unavailableCriticalExtension.
+
+ - If the server does not recognize the control type, determines that
+ it is not appropriate for the operation, or is otherwise unwilling
+ to perform the operation with the control, and if the criticality
+ field is FALSE, the server MUST ignore the control.
+
+ - Regardless of criticality, if a control is applied to an
+ operation, it is applied consistently and impartially to the
+ entire operation.
+
+
+
+
+
+Sermersheim Standards Track [Page 14]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ The controlValue may contain information associated with the
+ controlType. Its format is defined by the specification of the
+ control. Implementations MUST be prepared to handle arbitrary
+ contents of the controlValue octet string, including zero bytes. It
+ is absent only if there is no value information that is associated
+ with a control of its type. When a controlValue is defined in terms
+ of ASN.1, and BER-encoded according to Section 5.1, it also follows
+ the extensibility rules in Section 4.
+
+ Servers list the controlType of request controls they recognize in
+ the 'supportedControl' attribute in the root DSE (Section 5.1 of
+ [RFC4512]).
+
+ Controls SHOULD NOT be combined unless the semantics of the
+ combination has been specified. The semantics of control
+ combinations, if specified, are generally found in the control
+ specification most recently published. When a combination of
+ controls is encountered whose semantics are invalid, not specified
+ (or not known), the message is considered not well-formed; thus, the
+ operation fails with protocolError. Controls with a criticality of
+ FALSE may be ignored in order to arrive at a valid combination.
+ Additionally, unless order-dependent semantics are given in a
+ specification, the order of a combination of controls in the SEQUENCE
+ is ignored. Where the order is to be ignored but cannot be ignored
+ by the server, the message is considered not well-formed, and the
+ operation fails with protocolError. Again, controls with a
+ criticality of FALSE may be ignored in order to arrive at a valid
+ combination.
+
+ This document does not specify any controls. Controls may be
+ specified in other documents. Documents detailing control extensions
+ are to provide for each control:
+
+ - the OBJECT IDENTIFIER assigned to the control,
+
+ - direction as to what value the sender should provide for the
+ criticality field (note: the semantics of the criticality field are
+ defined above should not be altered by the control's
+ specification),
+
+ - whether the controlValue field is present, and if so, the format of
+ its contents,
+
+ - the semantics of the control, and
+
+ - optionally, semantics regarding the combination of the control with
+ other controls.
+
+
+
+
+Sermersheim Standards Track [Page 15]
+
+RFC 4511 LDAPv3 June 2006
+
+
+4.2. Bind Operation
+
+ The function of the Bind operation is to allow authentication
+ information to be exchanged between the client and server. The Bind
+ operation should be thought of as the "authenticate" operation.
+ Operational, authentication, and security-related semantics of this
+ operation are given in [RFC4513].
+
+ The Bind request is defined as follows:
+
+ BindRequest ::= [APPLICATION 0] SEQUENCE {
+ version INTEGER (1 .. 127),
+ name LDAPDN,
+ authentication AuthenticationChoice }
+
+ AuthenticationChoice ::= CHOICE {
+ simple [0] OCTET STRING,
+ -- 1 and 2 reserved
+ sasl [3] SaslCredentials,
+ ... }
+
+ SaslCredentials ::= SEQUENCE {
+ mechanism LDAPString,
+ credentials OCTET STRING OPTIONAL }
+
+ Fields of the BindRequest are:
+
+ - version: A version number indicating the version of the protocol to
+ be used at the LDAP message layer. This document describes version
+ 3 of the protocol. There is no version negotiation. The client
+ sets this field to the version it desires. If the server does not
+ support the specified version, it MUST respond with a BindResponse
+ where the resultCode is set to protocolError.
+
+ - name: If not empty, the name of the Directory object that the
+ client wishes to bind as. This field may take on a null value (a
+ zero-length string) for the purposes of anonymous binds ([RFC4513],
+ Section 5.1) or when using SASL [RFC4422] authentication
+ ([RFC4513], Section 5.2). Where the server attempts to locate the
+ named object, it SHALL NOT perform alias dereferencing.
+
+ - authentication: Information used in authentication. This type is
+ extensible as defined in Section 3.7 of [RFC4520]. Servers that do
+ not support a choice supplied by a client return a BindResponse
+ with the resultCode set to authMethodNotSupported.
+
+
+
+
+
+
+Sermersheim Standards Track [Page 16]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ Textual passwords (consisting of a character sequence with a known
+ character set and encoding) transferred to the server using the
+ simple AuthenticationChoice SHALL be transferred as UTF-8 [RFC3629]
+ encoded [Unicode]. Prior to transfer, clients SHOULD prepare text
+ passwords as "query" strings by applying the SASLprep [RFC4013]
+ profile of the stringprep [RFC3454] algorithm. Passwords
+ consisting of other data (such as random octets) MUST NOT be
+ altered. The determination of whether a password is textual is a
+ local client matter.
+
+4.2.1. Processing of the Bind Request
+
+ Before processing a BindRequest, all uncompleted operations MUST
+ either complete or be abandoned. The server may either wait for the
+ uncompleted operations to complete, or abandon them. The server then
+ proceeds to authenticate the client in either a single-step or
+ multi-step Bind process. Each step requires the server to return a
+ BindResponse to indicate the status of authentication.
+
+ After sending a BindRequest, clients MUST NOT send further LDAP PDUs
+ until receiving the BindResponse. Similarly, servers SHOULD NOT
+ process or respond to requests received while processing a
+ BindRequest.
+
+ If the client did not bind before sending a request and receives an
+ operationsError to that request, it may then send a BindRequest. If
+ this also fails or the client chooses not to bind on the existing
+ LDAP session, it may terminate the LDAP session, re-establish it, and
+ begin again by first sending a BindRequest. This will aid in
+ interoperating with servers implementing other versions of LDAP.
+
+ Clients may send multiple Bind requests to change the authentication
+ and/or security associations or to complete a multi-stage Bind
+ process. Authentication from earlier binds is subsequently ignored.
+
+ For some SASL authentication mechanisms, it may be necessary for the
+ client to invoke the BindRequest multiple times ([RFC4513], Section
+ 5.2). Clients MUST NOT invoke operations between two Bind requests
+ made as part of a multi-stage Bind.
+
+ A client may abort a SASL bind negotiation by sending a BindRequest
+ with a different value in the mechanism field of SaslCredentials, or
+ an AuthenticationChoice other than sasl.
+
+
+
+
+
+
+
+
+Sermersheim Standards Track [Page 17]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ If the client sends a BindRequest with the sasl mechanism field as an
+ empty string, the server MUST return a BindResponse with the
+ resultCode set to authMethodNotSupported. This will allow the client
+ to abort a negotiation if it wishes to try again with the same SASL
+ mechanism.
+
+4.2.2. Bind Response
+
+ The Bind response is defined as follows.
+
+ BindResponse ::= [APPLICATION 1] SEQUENCE {
+ COMPONENTS OF LDAPResult,
+ serverSaslCreds [7] OCTET STRING OPTIONAL }
+
+ BindResponse consists simply of an indication from the server of the
+ status of the client's request for authentication.
+
+ A successful Bind operation is indicated by a BindResponse with a
+ resultCode set to success. Otherwise, an appropriate result code is
+ set in the BindResponse. For BindResponse, the protocolError result
+ code may be used to indicate that the version number supplied by the
+ client is unsupported.
+
+ If the client receives a BindResponse where the resultCode is set to
+ protocolError, it is to assume that the server does not support this
+ version of LDAP. While the client may be able proceed with another
+ version of this protocol (which may or may not require closing and
+ re-establishing the transport connection), how to proceed with
+ another version of this protocol is beyond the scope of this
+ document. Clients that are unable or unwilling to proceed SHOULD
+ terminate the LDAP session.
+
+ The serverSaslCreds field is used as part of a SASL-defined bind
+ mechanism to allow the client to authenticate the server to which it
+ is communicating, or to perform "challenge-response" authentication.
+ If the client bound with the simple choice, or the SASL mechanism
+ does not require the server to return information to the client, then
+ this field SHALL NOT be included in the BindResponse.
+
+4.3. Unbind Operation
+
+ The function of the Unbind operation is to terminate an LDAP session.
+ The Unbind operation is not the antithesis of the Bind operation as
+ the name implies. The naming of these operations are historical.
+ The Unbind operation should be thought of as the "quit" operation.
+
+
+
+
+
+
+Sermersheim Standards Track [Page 18]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ The Unbind operation is defined as follows:
+
+ UnbindRequest ::= [APPLICATION 2] NULL
+
+ The client, upon transmission of the UnbindRequest, and the server,
+ upon receipt of the UnbindRequest, are to gracefully terminate the
+ LDAP session as described in Section 5.3. Uncompleted operations are
+ handled as specified in Section 3.1.
+
+4.4. Unsolicited Notification
+
+ An unsolicited notification is an LDAPMessage sent from the server to
+ the client that is not in response to any LDAPMessage received by the
+ server. It is used to signal an extraordinary condition in the
+ server or in the LDAP session between the client and the server. The
+ notification is of an advisory nature, and the server will not expect
+ any response to be returned from the client.
+
+ The unsolicited notification is structured as an LDAPMessage in which
+ the messageID is zero and protocolOp is set to the extendedResp
+ choice using the ExtendedResponse type (See Section 4.12). The
+ responseName field of the ExtendedResponse always contains an LDAPOID
+ that is unique for this notification.
+
+ One unsolicited notification (Notice of Disconnection) is defined in
+ this document. The specification of an unsolicited notification
+ consists of:
+
+ - the OBJECT IDENTIFIER assigned to the notification (to be specified
+ in the responseName,
+
+ - the format of the contents of the responseValue (if any),
+
+ - the circumstances which will cause the notification to be sent, and
+
+ - the semantics of the message.
+
+4.4.1. Notice of Disconnection
+
+ This notification may be used by the server to advise the client that
+ the server is about to terminate the LDAP session on its own
+ initiative. This notification is intended to assist clients in
+ distinguishing between an exceptional server condition and a
+ transient network failure. Note that this notification is not a
+ response to an Unbind requested by the client. Uncompleted
+ operations are handled as specified in Section 3.1.
+
+
+
+
+
+Sermersheim Standards Track [Page 19]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ The responseName is 1.3.6.1.4.1.1466.20036, the responseValue field
+ is absent, and the resultCode is used to indicate the reason for the
+ disconnection. When the strongerAuthRequired resultCode is returned
+ with this message, it indicates that the server has detected that an
+ established security association between the client and server has
+ unexpectedly failed or been compromised.
+
+ Upon transmission of the Notice of Disconnection, the server
+ gracefully terminates the LDAP session as described in Section 5.3.
+
+4.5. Search Operation
+
+ The Search operation is used to request a server to return, subject
+ to access controls and other restrictions, a set of entries matching
+ a complex search criterion. This can be used to read attributes from
+ a single entry, from entries immediately subordinate to a particular
+ entry, or from a whole subtree of entries.
+
+4.5.1. Search Request
+
+ The Search request is defined as follows:
+
+ SearchRequest ::= [APPLICATION 3] SEQUENCE {
+ baseObject LDAPDN,
+ scope ENUMERATED {
+ baseObject (0),
+ singleLevel (1),
+ wholeSubtree (2),
+ ... },
+ derefAliases ENUMERATED {
+ neverDerefAliases (0),
+ derefInSearching (1),
+ derefFindingBaseObj (2),
+ derefAlways (3) },
+ sizeLimit INTEGER (0 .. maxInt),
+ timeLimit INTEGER (0 .. maxInt),
+ typesOnly BOOLEAN,
+ filter Filter,
+ attributes AttributeSelection }
+
+ AttributeSelection ::= SEQUENCE OF selector LDAPString
+ -- The LDAPString is constrained to
+ -- <attributeSelector> in Section 4.5.1.8
+
+ Filter ::= CHOICE {
+ and [0] SET SIZE (1..MAX) OF filter Filter,
+ or [1] SET SIZE (1..MAX) OF filter Filter,
+ not [2] Filter,
+
+
+
+Sermersheim Standards Track [Page 20]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ equalityMatch [3] AttributeValueAssertion,
+ substrings [4] SubstringFilter,
+ greaterOrEqual [5] AttributeValueAssertion,
+ lessOrEqual [6] AttributeValueAssertion,
+ present [7] AttributeDescription,
+ approxMatch [8] AttributeValueAssertion,
+ extensibleMatch [9] MatchingRuleAssertion,
+ ... }
+
+ SubstringFilter ::= SEQUENCE {
+ type AttributeDescription,
+ substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
+ initial [0] AssertionValue, -- can occur at most once
+ any [1] AssertionValue,
+ final [2] AssertionValue } -- can occur at most once
+ }
+
+ MatchingRuleAssertion ::= SEQUENCE {
+ matchingRule [1] MatchingRuleId OPTIONAL,
+ type [2] AttributeDescription OPTIONAL,
+ matchValue [3] AssertionValue,
+ dnAttributes [4] BOOLEAN DEFAULT FALSE }
+
+ Note that an X.500 "list"-like operation can be emulated by the
+ client requesting a singleLevel Search operation with a filter
+ checking for the presence of the 'objectClass' attribute, and that an
+ X.500 "read"-like operation can be emulated by a baseObject Search
+ operation with the same filter. A server that provides a gateway to
+ X.500 is not required to use the Read or List operations, although it
+ may choose to do so, and if it does, it must provide the same
+ semantics as the X.500 Search operation.
+
+4.5.1.1. SearchRequest.baseObject
+
+ The name of the base object entry (or possibly the root) relative to
+ which the Search is to be performed.
+
+4.5.1.2. SearchRequest.scope
+
+ Specifies the scope of the Search to be performed. The semantics (as
+ described in [X.511]) of the defined values of this field are:
+
+ baseObject: The scope is constrained to the entry named by
+ baseObject.
+
+ singleLevel: The scope is constrained to the immediate
+ subordinates of the entry named by baseObject.
+
+
+
+
+Sermersheim Standards Track [Page 21]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ wholeSubtree: The scope is constrained to the entry named by
+ baseObject and to all its subordinates.
+
+4.5.1.3. SearchRequest.derefAliases
+
+ An indicator as to whether or not alias entries (as defined in
+ [RFC4512]) are to be dereferenced during stages of the Search
+ operation.
+
+ The act of dereferencing an alias includes recursively dereferencing
+ aliases that refer to aliases.
+
+ Servers MUST detect looping while dereferencing aliases in order to
+ prevent denial-of-service attacks of this nature.
+
+ The semantics of the defined values of this field are:
+
+ neverDerefAliases: Do not dereference aliases in searching or in
+ locating the base object of the Search.
+
+ derefInSearching: While searching subordinates of the base object,
+ dereference any alias within the search scope. Dereferenced
+ objects become the vertices of further search scopes where the
+ Search operation is also applied. If the search scope is
+ wholeSubtree, the Search continues in the subtree(s) of any
+ dereferenced object. If the search scope is singleLevel, the
+ search is applied to any dereferenced objects and is not applied
+ to their subordinates. Servers SHOULD eliminate duplicate entries
+ that arise due to alias dereferencing while searching.
+
+ derefFindingBaseObj: Dereference aliases in locating the base
+ object of the Search, but not when searching subordinates of the
+ base object.
+
+ derefAlways: Dereference aliases both in searching and in locating
+ the base object of the Search.
+
+4.5.1.4. SearchRequest.sizeLimit
+
+ A size limit that restricts the maximum number of entries to be
+ returned as a result of the Search. A value of zero in this field
+ indicates that no client-requested size limit restrictions are in
+ effect for the Search. Servers may also enforce a maximum number of
+ entries to return.
+
+
+
+
+
+
+
+Sermersheim Standards Track [Page 22]
+
+RFC 4511 LDAPv3 June 2006
+
+
+4.5.1.5. SearchRequest.timeLimit
+
+ A time limit that restricts the maximum time (in seconds) allowed for
+ a Search. A value of zero in this field indicates that no client-
+ requested time limit restrictions are in effect for the Search.
+ Servers may also enforce a maximum time limit for the Search.
+
+4.5.1.6. SearchRequest.typesOnly
+
+ An indicator as to whether Search results are to contain both
+ attribute descriptions and values, or just attribute descriptions.
+ Setting this field to TRUE causes only attribute descriptions (and
+ not values) to be returned. Setting this field to FALSE causes both
+ attribute descriptions and values to be returned.
+
+4.5.1.7. SearchRequest.filter
+
+ A filter that defines the conditions that must be fulfilled in order
+ for the Search to match a given entry.
+
+ The 'and', 'or', and 'not' choices can be used to form combinations
+ of filters. At least one filter element MUST be present in an 'and'
+ or 'or' choice. The others match against individual attribute values
+ of entries in the scope of the Search. (Implementor's note: the
+ 'not' filter is an example of a tagged choice in an implicitly-tagged
+ module. In BER this is treated as if the tag were explicit.)
+
+ A server MUST evaluate filters according to the three-valued logic of
+ [X.511] (1993), Clause 7.8.1. In summary, a filter is evaluated to
+ "TRUE", "FALSE", or "Undefined". If the filter evaluates to TRUE for
+ a particular entry, then the attributes of that entry are returned as
+ part of the Search result (subject to any applicable access control
+ restrictions). If the filter evaluates to FALSE or Undefined, then
+ the entry is ignored for the Search.
+
+ A filter of the "and" choice is TRUE if all the filters in the SET OF
+ evaluate to TRUE, FALSE if at least one filter is FALSE, and
+ Undefined otherwise. A filter of the "or" choice is FALSE if all the
+ filters in the SET OF evaluate to FALSE, TRUE if at least one filter
+ is TRUE, and Undefined otherwise. A filter of the 'not' choice is
+ TRUE if the filter being negated is FALSE, FALSE if it is TRUE, and
+ Undefined if it is Undefined.
+
+ A filter item evaluates to Undefined when the server would not be
+ able to determine whether the assertion value matches an entry.
+ Examples include:
+
+
+
+
+
+Sermersheim Standards Track [Page 23]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ - An attribute description in an equalityMatch, substrings,
+ greaterOrEqual, lessOrEqual, approxMatch, or extensibleMatch filter
+ is not recognized by the server.
+
+ - The attribute type does not define the appropriate matching rule.
+
+ - A MatchingRuleId in the extensibleMatch is not recognized by the
+ server or is not valid for the attribute type.
+
+ - The type of filtering requested is not implemented.
+
+ - The assertion value is invalid.
+
+ For example, if a server did not recognize the attribute type
+ shoeSize, the filters (shoeSize=*), (shoeSize=12), (shoeSize>=12),
+ and (shoeSize<=12) would each evaluate to Undefined.
+
+ Servers MUST NOT return errors if attribute descriptions or matching
+ rule ids are not recognized, assertion values are invalid, or the
+ assertion syntax is not supported. More details of filter processing
+ are given in Clause 7.8 of [X.511].
+
+4.5.1.7.1. SearchRequest.filter.equalityMatch
+
+ The matching rule for an equalityMatch filter is defined by the
+ EQUALITY matching rule for the attribute type or subtype. The filter
+ is TRUE when the EQUALITY rule returns TRUE as applied to the
+ attribute or subtype and the asserted value.
+
+4.5.1.7.2. SearchRequest.filter.substrings
+
+ There SHALL be at most one 'initial' and at most one 'final' in the
+ 'substrings' of a SubstringFilter. If 'initial' is present, it SHALL
+ be the first element of 'substrings'. If 'final' is present, it
+ SHALL be the last element of 'substrings'.
+
+ The matching rule for an AssertionValue in a substrings filter item
+ is defined by the SUBSTR matching rule for the attribute type or
+ subtype. The filter is TRUE when the SUBSTR rule returns TRUE as
+ applied to the attribute or subtype and the asserted value.
+
+ Note that the AssertionValue in a substrings filter item conforms to
+ the assertion syntax of the EQUALITY matching rule for the attribute
+ type rather than to the assertion syntax of the SUBSTR matching rule
+ for the attribute type. Conceptually, the entire SubstringFilter is
+ converted into an assertion value of the substrings matching rule
+ prior to applying the rule.
+
+
+
+
+Sermersheim Standards Track [Page 24]
+
+RFC 4511 LDAPv3 June 2006
+
+
+4.5.1.7.3. SearchRequest.filter.greaterOrEqual
+
+ The matching rule for a greaterOrEqual filter is defined by the
+ ORDERING matching rule for the attribute type or subtype. The filter
+ is TRUE when the ORDERING rule returns FALSE as applied to the
+ attribute or subtype and the asserted value.
+
+4.5.1.7.4. SearchRequest.filter.lessOrEqual
+
+ The matching rules for a lessOrEqual filter are defined by the
+ ORDERING and EQUALITY matching rules for the attribute type or
+ subtype. The filter is TRUE when either the ORDERING or EQUALITY
+ rule returns TRUE as applied to the attribute or subtype and the
+ asserted value.
+
+4.5.1.7.5. SearchRequest.filter.present
+
+ A present filter is TRUE when there is an attribute or subtype of the
+ specified attribute description present in an entry, FALSE when no
+ attribute or subtype of the specified attribute description is
+ present in an entry, and Undefined otherwise.
+
+4.5.1.7.6. SearchRequest.filter.approxMatch
+
+ An approxMatch filter is TRUE when there is a value of the attribute
+ type or subtype for which some locally-defined approximate matching
+ algorithm (e.g., spelling variations, phonetic match, etc.) returns
+ TRUE. If a value matches for equality, it also satisfies an
+ approximate match. If approximate matching is not supported for the
+ attribute, this filter item should be treated as an equalityMatch.
+
+4.5.1.7.7. SearchRequest.filter.extensibleMatch
+
+ The fields of the extensibleMatch filter item are evaluated as
+ follows:
+
+ - If the matchingRule field is absent, the type field MUST be
+ present, and an equality match is performed for that type.
+
+ - If the type field is absent and the matchingRule is present, the
+ matchValue is compared against all attributes in an entry that
+ support that matchingRule.
+
+ - If the type field is present and the matchingRule is present, the
+ matchValue is compared against the specified attribute type and its
+ subtypes.
+
+
+
+
+
+Sermersheim Standards Track [Page 25]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ - If the dnAttributes field is set to TRUE, the match is additionally
+ applied against all the AttributeValueAssertions in an entry's
+ distinguished name, and it evaluates to TRUE if there is at least
+ one attribute or subtype in the distinguished name for which the
+ filter item evaluates to TRUE. The dnAttributes field is present
+ to alleviate the need for multiple versions of generic matching
+ rules (such as word matching), where one applies to entries and
+ another applies to entries and DN attributes as well.
+
+ The matchingRule used for evaluation determines the syntax for the
+ assertion value. Once the matchingRule and attribute(s) have been
+ determined, the filter item evaluates to TRUE if it matches at least
+ one attribute type or subtype in the entry, FALSE if it does not
+ match any attribute type or subtype in the entry, and Undefined if
+ the matchingRule is not recognized, the matchingRule is unsuitable
+ for use with the specified type, or the assertionValue is invalid.
+
+4.5.1.8. SearchRequest.attributes
+
+ A selection list of the attributes to be returned from each entry
+ that matches the search filter. Attributes that are subtypes of
+ listed attributes are implicitly included. LDAPString values of this
+ field are constrained to the following Augmented Backus-Naur Form
+ (ABNF) [RFC4234]:
+
+ attributeSelector = attributedescription / selectorspecial
+
+ selectorspecial = noattrs / alluserattrs
+
+ noattrs = %x31.2E.31 ; "1.1"
+
+ alluserattrs = %x2A ; asterisk ("*")
+
+ The <attributedescription> production is defined in Section 2.5 of
+ [RFC4512].
+
+ There are three special cases that may appear in the attributes
+ selection list:
+
+ 1. An empty list with no attributes requests the return of all
+ user attributes.
+
+ 2. A list containing "*" (with zero or more attribute
+ descriptions) requests the return of all user attributes in
+ addition to other listed (operational) attributes.
+
+
+
+
+
+
+Sermersheim Standards Track [Page 26]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ 3. A list containing only the OID "1.1" indicates that no
+ attributes are to be returned. If "1.1" is provided with other
+ attributeSelector values, the "1.1" attributeSelector is
+ ignored. This OID was chosen because it does not (and can not)
+ correspond to any attribute in use.
+
+ Client implementors should note that even if all user attributes are
+ requested, some attributes and/or attribute values of the entry may
+ not be included in Search results due to access controls or other
+ restrictions. Furthermore, servers will not return operational
+ attributes, such as objectClasses or attributeTypes, unless they are
+ listed by name. Operational attributes are described in [RFC4512].
+
+ Attributes are returned at most once in an entry. If an attribute
+ description is named more than once in the list, the subsequent names
+ are ignored. If an attribute description in the list is not
+ recognized, it is ignored by the server.
+
+4.5.2. Search Result
+
+ The results of the Search operation are returned as zero or more
+ SearchResultEntry and/or SearchResultReference messages, followed by
+ a single SearchResultDone message.
+
+ SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
+ objectName LDAPDN,
+ attributes PartialAttributeList }
+
+ PartialAttributeList ::= SEQUENCE OF
+ partialAttribute PartialAttribute
+
+ SearchResultReference ::= [APPLICATION 19] SEQUENCE
+ SIZE (1..MAX) OF uri URI
+
+ SearchResultDone ::= [APPLICATION 5] LDAPResult
+
+ Each SearchResultEntry represents an entry found during the Search.
+ Each SearchResultReference represents an area not yet explored during
+ the Search. The SearchResultEntry and SearchResultReference messages
+ may come in any order. Following all the SearchResultReference and
+ SearchResultEntry responses, the server returns a SearchResultDone
+ response, which contains an indication of success or details any
+ errors that have occurred.
+
+ Each entry returned in a SearchResultEntry will contain all
+ appropriate attributes as specified in the attributes field of the
+ Search Request, subject to access control and other administrative
+ policy. Note that the PartialAttributeList may hold zero elements.
+
+
+
+Sermersheim Standards Track [Page 27]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ This may happen when none of the attributes of an entry were
+ requested or could be returned. Note also that the partialAttribute
+ vals set may hold zero elements. This may happen when typesOnly is
+ requested, access controls prevent the return of values, or other
+ reasons.
+
+ Some attributes may be constructed by the server and appear in a
+ SearchResultEntry attribute list, although they are not stored
+ attributes of an entry. Clients SHOULD NOT assume that all
+ attributes can be modified, even if this is permitted by access
+ control.
+
+ If the server's schema defines short names [RFC4512] for an attribute
+ type, then the server SHOULD use one of those names in attribute
+ descriptions for that attribute type (in preference to using the
+ <numericoid> [RFC4512] format of the attribute type's object
+ identifier). The server SHOULD NOT use the short name if that name
+ is known by the server to be ambiguous, or if it is otherwise likely
+ to cause interoperability problems.
+
+4.5.3. Continuation References in the Search Result
+
+ If the server was able to locate the entry referred to by the
+ baseObject but was unable or unwilling to search one or more non-
+ local entries, the server may return one or more
+ SearchResultReference messages, each containing a reference to
+ another set of servers for continuing the operation. A server MUST
+ NOT return any SearchResultReference messages if it has not located
+ the baseObject and thus has not searched any entries. In this case,
+ it would return a SearchResultDone containing either a referral or
+ noSuchObject result code (depending on the server's knowledge of the
+ entry named in the baseObject).
+
+ If a server holds a copy or partial copy of the subordinate naming
+ context (Section 5 of [RFC4512]), it may use the search filter to
+ determine whether or not to return a SearchResultReference response.
+ Otherwise, SearchResultReference responses are always returned when
+ in scope.
+
+ The SearchResultReference is of the same data type as the Referral.
+
+ If the client wishes to progress the Search, it issues a new Search
+ operation for each SearchResultReference that is returned. If
+ multiple URIs are present, the client assumes that any supported URI
+ may be used to progress the operation.
+
+
+
+
+
+
+Sermersheim Standards Track [Page 28]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ Clients that follow search continuation references MUST ensure that
+ they do not loop between servers. They MUST NOT repeatedly contact
+ the same server for the same request with the same parameters. Some
+ clients use a counter that is incremented each time search result
+ reference handling occurs for an operation, and these kinds of
+ clients MUST be able to handle at least ten nested referrals while
+ progressing the operation.
+
+ Note that the Abandon operation described in Section 4.11 applies
+ only to a particular operation sent at the LDAP message layer between
+ a client and server. The client must individually abandon subsequent
+ Search operations it wishes to.
+
+ A URI for a server implementing LDAP and accessible via TCP/IP (v4 or
+ v6) [RFC793][RFC791] is written as an LDAP URL according to
+ [RFC4516].
+
+ SearchResultReference values that are LDAP URLs follow these rules:
+
+ - The <dn> part of the LDAP URL MUST be present, with the new target
+ object name. The client uses this name when following the
+ reference.
+
+ - Some servers (e.g., participating in distributed indexing) may
+ provide a different filter in the LDAP URL.
+
+ - If the <filter> part of the LDAP URL is present, the client uses
+ this filter in its next request to progress this Search, and if it
+ is not present the client uses the same filter as it used for that
+ Search.
+
+ - If the originating search scope was singleLevel, the <scope> part
+ of the LDAP URL will be "base".
+
+ - It is RECOMMENDED that the <scope> part be present to avoid
+ ambiguity. In the absence of a <scope> part, the scope of the
+ original Search request is assumed.
+
+ - Other aspects of the new Search request may be the same as or
+ different from the Search request that generated the
+ SearchResultReference.
+
+ - The name of an unexplored subtree in a SearchResultReference need
+ not be subordinate to the base object.
+
+ Other kinds of URIs may be returned. The syntax and semantics of
+ such URIs is left to future specifications. Clients may ignore URIs
+ that they do not support.
+
+
+
+Sermersheim Standards Track [Page 29]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ UTF-8-encoded characters appearing in the string representation of a
+ DN, search filter, or other fields of the referral value may not be
+ legal for URIs (e.g., spaces) and MUST be escaped using the % method
+ in [RFC3986].
+
+4.5.3.1. Examples
+
+ For example, suppose the contacted server (hosta) holds the entry
+ <DC=Example,DC=NET> and the entry <CN=Manager,DC=Example,DC=NET>. It
+ knows that both LDAP servers (hostb) and (hostc) hold
+ <OU=People,DC=Example,DC=NET> (one is the master and the other server
+ a shadow), and that LDAP-capable server (hostd) holds the subtree
+ <OU=Roles,DC=Example,DC=NET>. If a wholeSubtree Search of
+ <DC=Example,DC=NET> is requested to the contacted server, it may
+ return the following:
+
+ SearchResultEntry for DC=Example,DC=NET
+ SearchResultEntry for CN=Manager,DC=Example,DC=NET
+ SearchResultReference {
+ ldap://hostb/OU=People,DC=Example,DC=NET??sub
+ ldap://hostc/OU=People,DC=Example,DC=NET??sub }
+ SearchResultReference {
+ ldap://hostd/OU=Roles,DC=Example,DC=NET??sub }
+ SearchResultDone (success)
+
+ Client implementors should note that when following a
+ SearchResultReference, additional SearchResultReference may be
+ generated. Continuing the example, if the client contacted the
+ server (hostb) and issued the Search request for the subtree
+ <OU=People,DC=Example,DC=NET>, the server might respond as follows:
+
+ SearchResultEntry for OU=People,DC=Example,DC=NET
+ SearchResultReference {
+ ldap://hoste/OU=Managers,OU=People,DC=Example,DC=NET??sub }
+ SearchResultReference {
+ ldap://hostf/OU=Consultants,OU=People,DC=Example,DC=NET??sub }
+ SearchResultDone (success)
+
+ Similarly, if a singleLevel Search of <DC=Example,DC=NET> is
+ requested to the contacted server, it may return the following:
+
+ SearchResultEntry for CN=Manager,DC=Example,DC=NET
+ SearchResultReference {
+ ldap://hostb/OU=People,DC=Example,DC=NET??base
+ ldap://hostc/OU=People,DC=Example,DC=NET??base }
+ SearchResultReference {
+ ldap://hostd/OU=Roles,DC=Example,DC=NET??base }
+ SearchResultDone (success)
+
+
+
+Sermersheim Standards Track [Page 30]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ If the contacted server does not hold the base object for the Search,
+ but has knowledge of its possible location, then it may return a
+ referral to the client. In this case, if the client requests a
+ subtree Search of <DC=Example,DC=ORG> to hosta, the server returns a
+ SearchResultDone containing a referral.
+
+ SearchResultDone (referral) {
+ ldap://hostg/DC=Example,DC=ORG??sub }
+
+4.6. Modify Operation
+
+ The Modify operation allows a client to request that a modification
+ of an entry be performed on its behalf by a server. The Modify
+ Request is defined as follows:
+
+ ModifyRequest ::= [APPLICATION 6] SEQUENCE {
+ object LDAPDN,
+ changes SEQUENCE OF change SEQUENCE {
+ operation ENUMERATED {
+ add (0),
+ delete (1),
+ replace (2),
+ ... },
+ modification PartialAttribute } }
+
+ Fields of the Modify Request are:
+
+ - object: The value of this field contains the name of the entry to
+ be modified. The server SHALL NOT perform any alias dereferencing
+ in determining the object to be modified.
+
+ - changes: A list of modifications to be performed on the entry. The
+ entire list of modifications MUST be performed in the order they
+ are listed as a single atomic operation. While individual
+ modifications may violate certain aspects of the directory schema
+ (such as the object class definition and Directory Information Tree
+ (DIT) content rule), the resulting entry after the entire list of
+ modifications is performed MUST conform to the requirements of the
+ directory model and controlling schema [RFC4512].
+
+ - operation: Used to specify the type of modification being
+ performed. Each operation type acts on the following
+ modification. The values of this field have the following
+ semantics, respectively:
+
+ add: add values listed to the modification attribute,
+ creating the attribute if necessary.
+
+
+
+
+Sermersheim Standards Track [Page 31]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ delete: delete values listed from the modification attribute.
+ If no values are listed, or if all current values of the
+ attribute are listed, the entire attribute is removed.
+
+ replace: replace all existing values of the modification
+ attribute with the new values listed, creating the attribute
+ if it did not already exist. A replace with no value will
+ delete the entire attribute if it exists, and it is ignored
+ if the attribute does not exist.
+
+ - modification: A PartialAttribute (which may have an empty SET
+ of vals) used to hold the attribute type or attribute type and
+ values being modified.
+
+ Upon receipt of a Modify Request, the server attempts to perform the
+ necessary modifications to the DIT and returns the result in a Modify
+ Response, defined as follows:
+
+ ModifyResponse ::= [APPLICATION 7] LDAPResult
+
+ The server will return to the client a single Modify Response
+ indicating either the successful completion of the DIT modification,
+ or the reason that the modification failed. Due to the requirement
+ for atomicity in applying the list of modifications in the Modify
+ Request, the client may expect that no modifications of the DIT have
+ been performed if the Modify Response received indicates any sort of
+ error, and that all requested modifications have been performed if
+ the Modify Response indicates successful completion of the Modify
+ operation. Whether or not the modification was applied cannot be
+ determined by the client if the Modify Response was not received
+ (e.g., the LDAP session was terminated or the Modify operation was
+ abandoned).
+
+ Servers MUST ensure that entries conform to user and system schema
+ rules or other data model constraints. The Modify operation cannot
+ be used to remove from an entry any of its distinguished values,
+ i.e., those values which form the entry's relative distinguished
+ name. An attempt to do so will result in the server returning the
+ notAllowedOnRDN result code. The Modify DN operation described in
+ Section 4.9 is used to rename an entry.
+
+ For attribute types that specify no equality matching, the rules in
+ Section 2.5.1 of [RFC4512] are followed.
+
+ Note that due to the simplifications made in LDAP, there is not a
+ direct mapping of the changes in an LDAP ModifyRequest onto the
+ changes of a DAP ModifyEntry operation, and different implementations
+
+
+
+
+Sermersheim Standards Track [Page 32]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ of LDAP-DAP gateways may use different means of representing the
+ change. If successful, the final effect of the operations on the
+ entry MUST be identical.
+
+4.7. Add Operation
+
+ The Add operation allows a client to request the addition of an entry
+ into the Directory. The Add Request is defined as follows:
+
+ AddRequest ::= [APPLICATION 8] SEQUENCE {
+ entry LDAPDN,
+ attributes AttributeList }
+
+ AttributeList ::= SEQUENCE OF attribute Attribute
+
+ Fields of the Add Request are:
+
+ - entry: the name of the entry to be added. The server SHALL NOT
+ dereference any aliases in locating the entry to be added.
+
+ - attributes: the list of attributes that, along with those from the
+ RDN, make up the content of the entry being added. Clients MAY or
+ MAY NOT include the RDN attribute(s) in this list. Clients MUST
+ NOT supply NO-USER-MODIFICATION attributes such as the
+ createTimestamp or creatorsName attributes, since the server
+ maintains these automatically.
+
+ Servers MUST ensure that entries conform to user and system schema
+ rules or other data model constraints. For attribute types that
+ specify no equality matching, the rules in Section 2.5.1 of [RFC4512]
+ are followed (this applies to the naming attribute in addition to any
+ multi-valued attributes being added).
+
+ The entry named in the entry field of the AddRequest MUST NOT exist
+ for the AddRequest to succeed. The immediate superior (parent) of an
+ object or alias entry to be added MUST exist. For example, if the
+ client attempted to add <CN=JS,DC=Example,DC=NET>, the
+ <DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did
+ exist, then the server would return the noSuchObject result code with
+ the matchedDN field containing <DC=NET>.
+
+ Upon receipt of an Add Request, a server will attempt to add the
+ requested entry. The result of the Add attempt will be returned to
+ the client in the Add Response, defined as follows:
+
+ AddResponse ::= [APPLICATION 9] LDAPResult
+
+
+
+
+
+Sermersheim Standards Track [Page 33]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ A response of success indicates that the new entry has been added to
+ the Directory.
+
+4.8. Delete Operation
+
+ The Delete operation allows a client to request the removal of an
+ entry from the Directory. The Delete Request is defined as follows:
+
+ DelRequest ::= [APPLICATION 10] LDAPDN
+
+ The Delete Request consists of the name of the entry to be deleted.
+ The server SHALL NOT dereference aliases while resolving the name of
+ the target entry to be removed.
+
+ Only leaf entries (those with no subordinate entries) can be deleted
+ with this operation.
+
+ Upon receipt of a Delete Request, a server will attempt to perform
+ the entry removal requested and return the result in the Delete
+ Response defined as follows:
+
+ DelResponse ::= [APPLICATION 11] LDAPResult
+
+4.9. Modify DN Operation
+
+ The Modify DN operation allows a client to change the Relative
+ Distinguished Name (RDN) of an entry in the Directory and/or to move
+ a subtree of entries to a new location in the Directory. The Modify
+ DN Request is defined as follows:
+
+ ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
+ entry LDAPDN,
+ newrdn RelativeLDAPDN,
+ deleteoldrdn BOOLEAN,
+ newSuperior [0] LDAPDN OPTIONAL }
+
+ Fields of the Modify DN Request are:
+
+ - entry: the name of the entry to be changed. This entry may or may
+ not have subordinate entries.
+
+ - newrdn: the new RDN of the entry. The value of the old RDN is
+ supplied when moving the entry to a new superior without changing
+ its RDN. Attribute values of the new RDN not matching any
+ attribute value of the entry are added to the entry, and an
+ appropriate error is returned if this fails.
+
+
+
+
+
+Sermersheim Standards Track [Page 34]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ - deleteoldrdn: a boolean field that controls whether the old RDN
+ attribute values are to be retained as attributes of the entry or
+ deleted from the entry.
+
+ - newSuperior: if present, this is the name of an existing object
+ entry that becomes the immediate superior (parent) of the
+ existing entry.
+
+ The server SHALL NOT dereference any aliases in locating the objects
+ named in entry or newSuperior.
+
+ Upon receipt of a ModifyDNRequest, a server will attempt to perform
+ the name change and return the result in the Modify DN Response,
+ defined as follows:
+
+ ModifyDNResponse ::= [APPLICATION 13] LDAPResult
+
+ For example, if the entry named in the entry field was <cn=John
+ Smith,c=US>, the newrdn field was <cn=John Cougar Smith>, and the
+ newSuperior field was absent, then this operation would attempt to
+ rename the entry as <cn=John Cougar Smith,c=US>. If there was
+ already an entry with that name, the operation would fail with the
+ entryAlreadyExists result code.
+
+ Servers MUST ensure that entries conform to user and system schema
+ rules or other data model constraints. For attribute types that
+ specify no equality matching, the rules in Section 2.5.1 of [RFC4512]
+ are followed (this pertains to newrdn and deleteoldrdn).
+
+ The object named in newSuperior MUST exist. For example, if the
+ client attempted to add <CN=JS,DC=Example,DC=NET>, the
+ <DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did
+ exist, then the server would return the noSuchObject result code with
+ the matchedDN field containing <DC=NET>.
+
+ If the deleteoldrdn field is TRUE, the attribute values forming the
+ old RDN (but not the new RDN) are deleted from the entry. If the
+ deleteoldrdn field is FALSE, the attribute values forming the old RDN
+ will be retained as non-distinguished attribute values of the entry.
+
+ Note that X.500 restricts the ModifyDN operation to affect only
+ entries that are contained within a single server. If the LDAP
+ server is mapped onto DAP, then this restriction will apply, and the
+ affectsMultipleDSAs result code will be returned if this error
+ occurred. In general, clients MUST NOT expect to be able to perform
+ arbitrary movements of entries and subtrees between servers or
+ between naming contexts.
+
+
+
+
+Sermersheim Standards Track [Page 35]
+
+RFC 4511 LDAPv3 June 2006
+
+
+4.10. Compare Operation
+
+ The Compare operation allows a client to compare an assertion value
+ with the values of a particular attribute in a particular entry in
+ the Directory. The Compare Request is defined as follows:
+
+ CompareRequest ::= [APPLICATION 14] SEQUENCE {
+ entry LDAPDN,
+ ava AttributeValueAssertion }
+
+ Fields of the Compare Request are:
+
+ - entry: the name of the entry to be compared. The server SHALL NOT
+ dereference any aliases in locating the entry to be compared.
+
+ - ava: holds the attribute value assertion to be compared.
+
+ Upon receipt of a Compare Request, a server will attempt to perform
+ the requested comparison and return the result in the Compare
+ Response, defined as follows:
+
+ CompareResponse ::= [APPLICATION 15] LDAPResult
+
+ The resultCode is set to compareTrue, compareFalse, or an appropriate
+ error. compareTrue indicates that the assertion value in the ava
+ field matches a value of the attribute or subtype according to the
+ attribute's EQUALITY matching rule. compareFalse indicates that the
+ assertion value in the ava field and the values of the attribute or
+ subtype did not match. Other result codes indicate either that the
+ result of the comparison was Undefined (Section 4.5.1.7), or that
+ some error occurred.
+
+ Note that some directory systems may establish access controls that
+ permit the values of certain attributes (such as userPassword) to be
+ compared but not interrogated by other means.
+
+4.11. Abandon Operation
+
+ The function of the Abandon operation is to allow a client to request
+ that the server abandon an uncompleted operation. The Abandon
+ Request is defined as follows:
+
+ AbandonRequest ::= [APPLICATION 16] MessageID
+
+ The MessageID is that of an operation that was requested earlier at
+ this LDAP message layer. The Abandon request itself has its own
+ MessageID. This is distinct from the MessageID of the earlier
+ operation being abandoned.
+
+
+
+Sermersheim Standards Track [Page 36]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ There is no response defined in the Abandon operation. Upon receipt
+ of an AbandonRequest, the server MAY abandon the operation identified
+ by the MessageID. Since the client cannot tell the difference
+ between a successfully abandoned operation and an uncompleted
+ operation, the application of the Abandon operation is limited to
+ uses where the client does not require an indication of its outcome.
+
+ Abandon, Bind, Unbind, and StartTLS operations cannot be abandoned.
+
+ In the event that a server receives an Abandon Request on a Search
+ operation in the midst of transmitting responses to the Search, that
+ server MUST cease transmitting entry responses to the abandoned
+ request immediately, and it MUST NOT send the SearchResultDone. Of
+ course, the server MUST ensure that only properly encoded LDAPMessage
+ PDUs are transmitted.
+
+ The ability to abandon other (particularly update) operations is at
+ the discretion of the server.
+
+ Clients should not send Abandon requests for the same operation
+ multiple times, and they MUST also be prepared to receive results
+ from operations they have abandoned (since these might have been in
+ transit when the Abandon was requested or might not be able to be
+ abandoned).
+
+ Servers MUST discard Abandon requests for messageIDs they do not
+ recognize, for operations that cannot be abandoned, and for
+ operations that have already been abandoned.
+
+4.12. Extended Operation
+
+ The Extended operation allows additional operations to be defined for
+ services not already available in the protocol; for example, to Add
+ operations to install transport layer security (see Section 4.14).
+
+ The Extended operation allows clients to make requests and receive
+ responses with predefined syntaxes and semantics. These may be
+ defined in RFCs or be private to particular implementations.
+
+ Each Extended operation consists of an Extended request and an
+ Extended response.
+
+ ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
+ requestName [0] LDAPOID,
+ requestValue [1] OCTET STRING OPTIONAL }
+
+
+
+
+
+
+Sermersheim Standards Track [Page 37]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ The requestName is a dotted-decimal representation of the unique
+ OBJECT IDENTIFIER corresponding to the request. The requestValue is
+ information in a form defined by that request, encapsulated inside an
+ OCTET STRING.
+
+ The server will respond to this with an LDAPMessage containing an
+ ExtendedResponse.
+
+ ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
+ COMPONENTS OF LDAPResult,
+ responseName [10] LDAPOID OPTIONAL,
+ responseValue [11] OCTET STRING OPTIONAL }
+
+ The responseName field, when present, contains an LDAPOID that is
+ unique for this extended operation or response. This field is
+ optional (even when the extension specification defines an LDAPOID
+ for use in this field). The field will be absent whenever the server
+ is unable or unwilling to determine the appropriate LDAPOID to
+ return, for instance, when the requestName cannot be parsed or its
+ value is not recognized.
+
+ Where the requestName is not recognized, the server returns
+ protocolError. (The server may return protocolError in other cases.)
+
+ The requestValue and responseValue fields contain information
+ associated with the operation. The format of these fields is defined
+ by the specification of the Extended operation. Implementations MUST
+ be prepared to handle arbitrary contents of these fields, including
+ zero bytes. Values that are defined in terms of ASN.1 and BER-
+ encoded according to Section 5.1 also follow the extensibility rules
+ in Section 4.
+
+ Servers list the requestName of Extended Requests they recognize in
+ the 'supportedExtension' attribute in the root DSE (Section 5.1 of
+ [RFC4512]).
+
+ Extended operations may be specified in other documents. The
+ specification of an Extended operation consists of:
+
+ - the OBJECT IDENTIFIER assigned to the requestName,
+
+ - the OBJECT IDENTIFIER (if any) assigned to the responseName (note
+ that the same OBJECT IDENTIFIER may be used for both the
+ requestName and responseName),
+
+
+
+
+
+
+
+Sermersheim Standards Track [Page 38]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ - the format of the contents of the requestValue and responseValue
+ (if any), and
+
+ - the semantics of the operation.
+
+4.13. IntermediateResponse Message
+
+ While the Search operation provides a mechanism to return multiple
+ response messages for a single Search request, other operations, by
+ nature, do not provide for multiple response messages.
+
+ The IntermediateResponse message provides a general mechanism for
+ defining single-request/multiple-response operations in LDAP. This
+ message is intended to be used in conjunction with the Extended
+ operation to define new single-request/multiple-response operations
+ or in conjunction with a control when extending existing LDAP
+ operations in a way that requires them to return Intermediate
+ response information.
+
+ It is intended that the definitions and descriptions of Extended
+ operations and controls that make use of the IntermediateResponse
+ message will define the circumstances when an IntermediateResponse
+ message can be sent by a server and the associated meaning of an
+ IntermediateResponse message sent in a particular circumstance.
+
+ IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
+ responseName [0] LDAPOID OPTIONAL,
+ responseValue [1] OCTET STRING OPTIONAL }
+
+ IntermediateResponse messages SHALL NOT be returned to the client
+ unless the client issues a request that specifically solicits their
+ return. This document defines two forms of solicitation: Extended
+ operation and request control. IntermediateResponse messages are
+ specified in documents describing the manner in which they are
+ solicited (i.e., in the Extended operation or request control
+ specification that uses them). These specifications include:
+
+ - the OBJECT IDENTIFIER (if any) assigned to the responseName,
+
+ - the format of the contents of the responseValue (if any), and
+
+ - the semantics associated with the IntermediateResponse message.
+
+ Extensions that allow the return of multiple types of
+ IntermediateResponse messages SHALL identify those types using unique
+ responseName values (note that one of these may specify no value).
+
+
+
+
+
+Sermersheim Standards Track [Page 39]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ Sections 4.13.1 and 4.13.2 describe additional requirements on the
+ inclusion of responseName and responseValue in IntermediateResponse
+ messages.
+
+4.13.1. Usage with LDAP ExtendedRequest and ExtendedResponse
+
+ A single-request/multiple-response operation may be defined using a
+ single ExtendedRequest message to solicit zero or more
+ IntermediateResponse messages of one or more kinds, followed by an
+ ExtendedResponse message.
+
+4.13.2. Usage with LDAP Request Controls
+
+ A control's semantics may include the return of zero or more
+ IntermediateResponse messages prior to returning the final result
+ code for the operation. One or more kinds of IntermediateResponse
+ messages may be sent in response to a request control.
+
+ All IntermediateResponse messages associated with request controls
+ SHALL include a responseName. This requirement ensures that the
+ client can correctly identify the source of IntermediateResponse
+ messages when:
+
+ - two or more controls using IntermediateResponse messages are
+ included in a request for any LDAP operation or
+
+ - one or more controls using IntermediateResponse messages are
+ included in a request with an LDAP Extended operation that uses
+ IntermediateResponse messages.
+
+4.14. StartTLS Operation
+
+ The Start Transport Layer Security (StartTLS) operation's purpose is
+ to initiate installation of a TLS layer. The StartTLS operation is
+ defined using the Extended operation mechanism described in Section
+ 4.12.
+
+4.14.1. StartTLS Request
+
+ A client requests TLS establishment by transmitting a StartTLS
+ request message to the server. The StartTLS request is defined in
+ terms of an ExtendedRequest. The requestName is
+ "1.3.6.1.4.1.1466.20037", and the requestValue field is always
+ absent.
+
+
+
+
+
+
+
+Sermersheim Standards Track [Page 40]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ The client MUST NOT send any LDAP PDUs at this LDAP message layer
+ following this request until it receives a StartTLS Extended response
+ and, in the case of a successful response, completes TLS
+ negotiations.
+
+ Detected sequencing problems (particularly those detailed in Section
+ 3.1.1 of [RFC4513]) result in the resultCode being set to
+ operationsError.
+
+ If the server does not support TLS (whether by design or by current
+ configuration), it returns with the resultCode set to protocolError
+ as described in Section 4.12.
+
+4.14.2. StartTLS Response
+
+ When a StartTLS request is received, servers supporting the operation
+ MUST return a StartTLS response message to the requestor. The
+ responseName is "1.3.6.1.4.1.1466.20037" when provided (see Section
+ 4.12). The responseValue is always absent.
+
+ If the server is willing and able to negotiate TLS, it returns the
+ StartTLS response with the resultCode set to success. Upon client
+ receipt of a successful StartTLS response, protocol peers may
+ commence with TLS negotiation as discussed in Section 3 of [RFC4513].
+
+ If the server is otherwise unwilling or unable to perform this
+ operation, the server is to return an appropriate result code
+ indicating the nature of the problem. For example, if the TLS
+ subsystem is not presently available, the server may indicate this by
+ returning with the resultCode set to unavailable. In cases where a
+ non-success result code is returned, the LDAP session is left without
+ a TLS layer.
+
+4.14.3. Removal of the TLS Layer
+
+ Either the client or server MAY remove the TLS layer and leave the
+ LDAP message layer intact by sending and receiving a TLS closure
+ alert.
+
+ The initiating protocol peer sends the TLS closure alert and MUST
+ wait until it receives a TLS closure alert from the other peer before
+ sending further LDAP PDUs.
+
+ When a protocol peer receives the initial TLS closure alert, it may
+ choose to allow the LDAP message layer to remain intact. In this
+ case, it MUST immediately transmit a TLS closure alert. Following
+ this, it MAY send and receive LDAP PDUs.
+
+
+
+
+Sermersheim Standards Track [Page 41]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ Protocol peers MAY terminate the LDAP session after sending or
+ receiving a TLS closure alert.
+
+5. Protocol Encoding, Connection, and Transfer
+
+ This protocol is designed to run over connection-oriented, reliable
+ transports, where the data stream is divided into octets (8-bit
+ units), with each octet and each bit being significant.
+
+ One underlying service, LDAP over TCP, is defined in Section 5.2.
+ This service is generally applicable to applications providing or
+ consuming X.500-based directory services on the Internet. This
+ specification was generally written with the TCP mapping in mind.
+ Specifications detailing other mappings may encounter various
+ obstacles.
+
+ Implementations of LDAP over TCP MUST implement the mapping as
+ described in Section 5.2.
+
+ This table illustrates the relationship among the different layers
+ involved in an exchange between two protocol peers:
+
+ +----------------------+
+ | LDAP message layer |
+ +----------------------+ > LDAP PDUs
+ +----------------------+ < data
+ | SASL layer |
+ +----------------------+ > SASL-protected data
+ +----------------------+ < data
+ | TLS layer |
+ Application +----------------------+ > TLS-protected data
+ ------------+----------------------+ < data
+ Transport | transport connection |
+ +----------------------+
+
+5.1. Protocol Encoding
+
+ The protocol elements of LDAP SHALL be encoded for exchange using the
+ Basic Encoding Rules [BER] of [ASN.1] with the following
+ restrictions:
+
+ - Only the definite form of length encoding is used.
+
+ - OCTET STRING values are encoded in the primitive form only.
+
+ - If the value of a BOOLEAN type is true, the encoding of the value
+ octet is set to hex "FF".
+
+
+
+
+Sermersheim Standards Track [Page 42]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ - If a value of a type is its default value, it is absent. Only some
+ BOOLEAN and INTEGER types have default values in this protocol
+ definition.
+
+ These restrictions are meant to ease the overhead of encoding and
+ decoding certain elements in BER.
+
+ These restrictions do not apply to ASN.1 types encapsulated inside of
+ OCTET STRING values, such as attribute values, unless otherwise
+ stated.
+
+5.2. Transmission Control Protocol (TCP)
+
+ The encoded LDAPMessage PDUs are mapped directly onto the TCP
+ [RFC793] bytestream using the BER-based encoding described in Section
+ 5.1. It is recommended that server implementations running over the
+ TCP provide a protocol listener on the Internet Assigned Numbers
+ Authority (IANA)-assigned LDAP port, 389 [PortReg]. Servers may
+ instead provide a listener on a different port number. Clients MUST
+ support contacting servers on any valid TCP port.
+
+5.3. Termination of the LDAP session
+
+ Termination of the LDAP session is typically initiated by the client
+ sending an UnbindRequest (Section 4.3), or by the server sending a
+ Notice of Disconnection (Section 4.4.1). In these cases, each
+ protocol peer gracefully terminates the LDAP session by ceasing
+ exchanges at the LDAP message layer, tearing down any SASL layer,
+ tearing down any TLS layer, and closing the transport connection.
+
+ A protocol peer may determine that the continuation of any
+ communication would be pernicious, and in this case, it may abruptly
+ terminate the session by ceasing communication and closing the
+ transport connection.
+
+ In either case, when the LDAP session is terminated, uncompleted
+ operations are handled as specified in Section 3.1.
+
+6. Security Considerations
+
+ This version of the protocol provides facilities for simple
+ authentication using a cleartext password, as well as any SASL
+ [RFC4422] mechanism. Installing SASL and/or TLS layers can provide
+ integrity and other data security services.
+
+ It is also permitted that the server can return its credentials to
+ the client, if it chooses to do so.
+
+
+
+
+Sermersheim Standards Track [Page 43]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ Use of cleartext password is strongly discouraged where the
+ underlying transport service cannot guarantee confidentiality and may
+ result in disclosure of the password to unauthorized parties.
+
+ Servers are encouraged to prevent directory modifications by clients
+ that have authenticated anonymously [RFC4513].
+
+ Security considerations for authentication methods, SASL mechanisms,
+ and TLS are described in [RFC4513].
+
+ Note that SASL authentication exchanges do not provide data
+ confidentiality or integrity protection for the version or name
+ fields of the BindRequest or the resultCode, diagnosticMessage, or
+ referral fields of the BindResponse, nor for any information
+ contained in controls attached to Bind requests or responses. Thus,
+ information contained in these fields SHOULD NOT be relied on unless
+ it is otherwise protected (such as by establishing protections at the
+ transport layer).
+
+ Implementors should note that various security factors (including
+ authentication and authorization information and data security
+ services) may change during the course of the LDAP session or even
+ during the performance of a particular operation. For instance,
+ credentials could expire, authorization identities or access controls
+ could change, or the underlying security layer(s) could be replaced
+ or terminated. Implementations should be robust in the handling of
+ changing security factors.
+
+ In some cases, it may be appropriate to continue the operation even
+ in light of security factor changes. For instance, it may be
+ appropriate to continue an Abandon operation regardless of the
+ change, or to continue an operation when the change upgraded (or
+ maintained) the security factor. In other cases, it may be
+ appropriate to fail or alter the processing of the operation. For
+ instance, if confidential protections were removed, it would be
+ appropriate either to fail a request to return sensitive data or,
+ minimally, to exclude the return of sensitive data.
+
+ Implementations that cache attributes and entries obtained via LDAP
+ MUST ensure that access controls are maintained if that information
+ is to be provided to multiple clients, since servers may have access
+ control policies that prevent the return of entries or attributes in
+ Search results except to particular authenticated clients. For
+ example, caches could serve result information only to the client
+ whose request caused it to be in the cache.
+
+
+
+
+
+
+Sermersheim Standards Track [Page 44]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ Servers may return referrals or Search result references that
+ redirect clients to peer servers. It is possible for a rogue
+ application to inject such referrals into the data stream in an
+ attempt to redirect a client to a rogue server. Clients are advised
+ to be aware of this and possibly reject referrals when
+ confidentiality measures are not in place. Clients are advised to
+ reject referrals from the StartTLS operation.
+
+ The matchedDN and diagnosticMessage fields, as well as some
+ resultCode values (e.g., attributeOrValueExists and
+ entryAlreadyExists), could disclose the presence or absence of
+ specific data in the directory that is subject to access and other
+ administrative controls. Server implementations should restrict
+ access to protected information equally under both normal and error
+ conditions.
+
+ Protocol peers MUST be prepared to handle invalid and arbitrary-
+ length protocol encodings. Invalid protocol encodings include: BER
+ encoding exceptions, format string and UTF-8 encoding exceptions,
+ overflow exceptions, integer value exceptions, and binary mode on/off
+ flag exceptions. The LDAPv3 PROTOS [PROTOS-LDAP] test suite provides
+ excellent examples of these exceptions and test cases used to
+ discover flaws.
+
+ In the event that a protocol peer senses an attack that in its nature
+ could cause damage due to further communication at any layer in the
+ LDAP session, the protocol peer should abruptly terminate the LDAP
+ session as described in Section 5.3.
+
+7. Acknowledgements
+
+ This document is based on RFC 2251 by Mark Wahl, Tim Howes, and Steve
+ Kille. RFC 2251 was a product of the IETF ASID Working Group.
+
+ It is also based on RFC 2830 by Jeff Hodges, RL "Bob" Morgan, and
+ Mark Wahl. RFC 2830 was a product of the IETF LDAPEXT Working Group.
+
+ It is also based on RFC 3771 by Roger Harrison and Kurt Zeilenga.
+ RFC 3771 was an individual submission to the IETF.
+
+ This document is a product of the IETF LDAPBIS Working Group.
+ Significant contributors of technical review and content include Kurt
+ Zeilenga, Steven Legg, and Hallvard Furuseth.
+
+
+
+
+
+
+
+
+Sermersheim Standards Track [Page 45]
+
+RFC 4511 LDAPv3 June 2006
+
+
+8. Normative References
+
+ [ASN.1] ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824-
+ 1:2002 "Information Technology - Abstract Syntax
+ Notation One (ASN.1): Specification of basic notation".
+
+ [BER] ITU-T Rec. X.690 (07/2002) | ISO/IEC 8825-1:2002,
+ "Information technology - ASN.1 encoding rules:
+ Specification of Basic Encoding Rules (BER), Canonical
+ Encoding Rules (CER) and Distinguished Encoding Rules
+ (DER)", 2002.
+
+ [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
+ Architecture and Basic Multilingual Plane, ISO/IEC
+ 10646-1 : 1993.
+
+ [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ September 1981.
+
+ [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
+ 793, September 1981.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3454] Hoffman P. and M. Blanchet, "Preparation of
+ Internationalized Strings ('stringprep')", RFC 3454,
+ December 2002.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003.
+
+ [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
+ "Uniform Resource Identifier (URI): Generic Syntax",
+ STD 66, RFC 3986, January 2005.
+
+ [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User
+ Names and Passwords", RFC 4013, February 2005.
+
+ [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 4234, October 2005.
+
+ [RFC4346] Dierks, T. and E. Rescorla, "The TLS Protocol Version
+ 1.1", RFC 4346, March 2006.
+
+ [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
+ Authentication and Security Layer (SASL)", RFC 4422,
+ June 2006.
+
+
+
+Sermersheim Standards Track [Page 46]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Technical Specification Road Map", RFC
+ 4510, June 2006.
+
+ [RFC4512] Zeilenga, K., Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+ [RFC4513] Harrison, R., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Authentication Methods and Security
+ Mechanisms", RFC 4513, June 2006.
+
+ [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access
+ Protocol (LDAP): String Representation of Distinguished
+ Names", RFC 4514, June 2006.
+
+ [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory
+ Access Protocol (LDAP): Uniform Resource Locator", RFC
+ 4516, June 2006.
+
+ [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Syntaxes and Matching Rules", RFC 4517, June
+ 2006.
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
+ (IANA) Considerations for the Lightweight Directory
+ Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+ [Unicode] The Unicode Consortium, "The Unicode Standard, Version
+ 3.2.0" is defined by "The Unicode Standard, Version
+ 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
+ 61633-5), as amended by the "Unicode Standard Annex
+ #27: Unicode 3.1"
+ (http://www.unicode.org/reports/tr27/) and by the
+ "Unicode Standard Annex #28: Unicode 3.2"
+ (http://www.unicode.org/reports/tr28/).
+
+ [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
+ Models and Service", 1993.
+
+ [X.511] ITU-T Rec. X.511, "The Directory: Abstract Service
+ Definition", 1993.
+
+
+
+
+
+
+
+
+
+Sermersheim Standards Track [Page 47]
+
+RFC 4511 LDAPv3 June 2006
+
+
+9. Informative References
+
+ [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report
+ #17, Character Encoding Model", UTR17,
+ <http://www.unicode.org/unicode/reports/tr17/>, August
+ 2000.
+
+ [Glossary] The Unicode Consortium, "Unicode Glossary",
+ <http://www.unicode.org/glossary/>.
+
+ [PortReg] IANA, "Port Numbers",
+ <http://www.iana.org/assignments/port-numbers>.
+
+ [PROTOS-LDAP] University of Oulu, "PROTOS Test-Suite: c06-ldapv3"
+ <http://www.ee.oulu.fi/research/ouspg/protos/testing/
+ c06/ldapv3/>.
+
+10. IANA Considerations
+
+ The Internet Assigned Numbers Authority (IANA) has updated the LDAP
+ result code registry to indicate that this document provides the
+ definitive technical specification for result codes 0-36, 48-54, 64-
+ 70, 80-90. It is also noted that one resultCode value
+ (strongAuthRequired) has been renamed (to strongerAuthRequired).
+
+ The IANA has also updated the LDAP Protocol Mechanism registry to
+ indicate that this document and [RFC4513] provides the definitive
+ technical specification for the StartTLS (1.3.6.1.4.1.1466.20037)
+ Extended operation.
+
+ IANA has assigned LDAP Object Identifier 18 [RFC4520] to identify the
+ ASN.1 module defined in this document.
+
+ Subject: Request for LDAP Object Identifier Registration
+ Person & email address to contact for further information:
+ Jim Sermersheim <jimse@novell.com>
+ Specification: RFC 4511
+ Author/Change Controller: IESG
+ Comments:
+ Identifies the LDAP ASN.1 module
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Standards Track [Page 48]
+
+RFC 4511 LDAPv3 June 2006
+
+
+Appendix A. LDAP Result Codes
+
+ This normative appendix details additional considerations regarding
+ LDAP result codes and provides a brief, general description of each
+ LDAP result code enumerated in Section 4.1.9.
+
+ Additional result codes MAY be defined for use with extensions
+ [RFC4520]. Client implementations SHALL treat any result code that
+ they do not recognize as an unknown error condition.
+
+ The descriptions provided here do not fully account for result code
+ substitutions used to prevent unauthorized disclosures (such as
+ substitution of noSuchObject for insufficientAccessRights, or
+ invalidCredentials for insufficientAccessRights).
+
+A.1. Non-Error Result Codes
+
+ These result codes (called "non-error" result codes) do not indicate
+ an error condition:
+
+ success (0),
+ compareFalse (5),
+ compareTrue (6),
+ referral (10), and
+ saslBindInProgress (14).
+
+ The success, compareTrue, and compareFalse result codes indicate
+ successful completion (and, hence, are referred to as "successful"
+ result codes).
+
+ The referral and saslBindInProgress result codes indicate the client
+ needs to take additional action to complete the operation.
+
+A.2. Result Codes
+
+ Existing LDAP result codes are described as follows:
+
+ success (0)
+ Indicates the successful completion of an operation. Note:
+ this code is not used with the Compare operation. See
+ compareFalse (5) and compareTrue (6).
+
+
+
+
+
+
+
+
+
+
+Sermersheim Standards Track [Page 49]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ operationsError (1)
+ Indicates that the operation is not properly sequenced with
+ relation to other operations (of same or different type).
+
+ For example, this code is returned if the client attempts to
+ StartTLS [RFC4346] while there are other uncompleted operations
+ or if a TLS layer was already installed.
+
+ protocolError (2)
+ Indicates the server received data that is not well-formed.
+
+ For Bind operation only, this code is also used to indicate
+ that the server does not support the requested protocol
+ version.
+
+ For Extended operations only, this code is also used to
+ indicate that the server does not support (by design or
+ configuration) the Extended operation associated with the
+ requestName.
+
+ For request operations specifying multiple controls, this may
+ be used to indicate that the server cannot ignore the order
+ of the controls as specified, or that the combination of the
+ specified controls is invalid or unspecified.
+
+ timeLimitExceeded (3)
+ Indicates that the time limit specified by the client was
+ exceeded before the operation could be completed.
+
+ sizeLimitExceeded (4)
+ Indicates that the size limit specified by the client was
+ exceeded before the operation could be completed.
+
+ compareFalse (5)
+ Indicates that the Compare operation has successfully
+ completed and the assertion has evaluated to FALSE or
+ Undefined.
+
+ compareTrue (6)
+ Indicates that the Compare operation has successfully
+ completed and the assertion has evaluated to TRUE.
+
+ authMethodNotSupported (7)
+ Indicates that the authentication method or mechanism is not
+ supported.
+
+
+
+
+
+
+Sermersheim Standards Track [Page 50]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ strongerAuthRequired (8)
+ Indicates the server requires strong(er) authentication in
+ order to complete the operation.
+
+ When used with the Notice of Disconnection operation, this
+ code indicates that the server has detected that an
+ established security association between the client and
+ server has unexpectedly failed or been compromised.
+
+ referral (10)
+ Indicates that a referral needs to be chased to complete the
+ operation (see Section 4.1.10).
+
+ adminLimitExceeded (11)
+ Indicates that an administrative limit has been exceeded.
+
+ unavailableCriticalExtension (12)
+ Indicates a critical control is unrecognized (see Section
+ 4.1.11).
+
+ confidentialityRequired (13)
+ Indicates that data confidentiality protections are required.
+
+ saslBindInProgress (14)
+ Indicates the server requires the client to send a new bind
+ request, with the same SASL mechanism, to continue the
+ authentication process (see Section 4.2).
+
+ noSuchAttribute (16)
+ Indicates that the named entry does not contain the specified
+ attribute or attribute value.
+
+ undefinedAttributeType (17)
+ Indicates that a request field contains an unrecognized
+ attribute description.
+
+ inappropriateMatching (18)
+ Indicates that an attempt was made (e.g., in an assertion) to
+ use a matching rule not defined for the attribute type
+ concerned.
+
+ constraintViolation (19)
+ Indicates that the client supplied an attribute value that
+ does not conform to the constraints placed upon it by the
+ data model.
+
+ For example, this code is returned when multiple values are
+ supplied to an attribute that has a SINGLE-VALUE constraint.
+
+
+
+Sermersheim Standards Track [Page 51]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ attributeOrValueExists (20)
+ Indicates that the client supplied an attribute or value to
+ be added to an entry, but the attribute or value already
+ exists.
+
+ invalidAttributeSyntax (21)
+ Indicates that a purported attribute value does not conform
+ to the syntax of the attribute.
+
+ noSuchObject (32)
+ Indicates that the object does not exist in the DIT.
+
+ aliasProblem (33)
+ Indicates that an alias problem has occurred. For example,
+ the code may used to indicate an alias has been dereferenced
+ that names no object.
+
+ invalidDNSyntax (34)
+ Indicates that an LDAPDN or RelativeLDAPDN field (e.g., search
+ base, target entry, ModifyDN newrdn, etc.) of a request does
+ not conform to the required syntax or contains attribute
+ values that do not conform to the syntax of the attribute's
+ type.
+
+ aliasDereferencingProblem (36)
+ Indicates that a problem occurred while dereferencing an
+ alias. Typically, an alias was encountered in a situation
+ where it was not allowed or where access was denied.
+
+ inappropriateAuthentication (48)
+ Indicates the server requires the client that had attempted
+ to bind anonymously or without supplying credentials to
+ provide some form of credentials.
+
+ invalidCredentials (49)
+ Indicates that the provided credentials (e.g., the user's name
+ and password) are invalid.
+
+ insufficientAccessRights (50)
+ Indicates that the client does not have sufficient access
+ rights to perform the operation.
+
+ busy (51)
+ Indicates that the server is too busy to service the
+ operation.
+
+
+
+
+
+
+Sermersheim Standards Track [Page 52]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ unavailable (52)
+ Indicates that the server is shutting down or a subsystem
+ necessary to complete the operation is offline.
+
+ unwillingToPerform (53)
+ Indicates that the server is unwilling to perform the
+ operation.
+
+ loopDetect (54)
+ Indicates that the server has detected an internal loop (e.g.,
+ while dereferencing aliases or chaining an operation).
+
+ namingViolation (64)
+ Indicates that the entry's name violates naming restrictions.
+
+ objectClassViolation (65)
+ Indicates that the entry violates object class restrictions.
+
+ notAllowedOnNonLeaf (66)
+ Indicates that the operation is inappropriately acting upon a
+ non-leaf entry.
+
+ notAllowedOnRDN (67)
+ Indicates that the operation is inappropriately attempting to
+ remove a value that forms the entry's relative distinguished
+ name.
+
+ entryAlreadyExists (68)
+ Indicates that the request cannot be fulfilled (added, moved,
+ or renamed) as the target entry already exists.
+
+ objectClassModsProhibited (69)
+ Indicates that an attempt to modify the object class(es) of
+ an entry's 'objectClass' attribute is prohibited.
+
+ For example, this code is returned when a client attempts to
+ modify the structural object class of an entry.
+
+ affectsMultipleDSAs (71)
+ Indicates that the operation cannot be performed as it would
+ affect multiple servers (DSAs).
+
+ other (80)
+ Indicates the server has encountered an internal error.
+
+
+
+
+
+
+
+Sermersheim Standards Track [Page 53]
+
+RFC 4511 LDAPv3 June 2006
+
+
+Appendix B. Complete ASN.1 Definition
+
+ This appendix is normative.
+
+ Lightweight-Directory-Access-Protocol-V3 {1 3 6 1 1 18}
+ -- Copyright (C) The Internet Society (2006). This version of
+ -- this ASN.1 module is part of RFC 4511; see the RFC itself
+ -- for full legal notices.
+ DEFINITIONS
+ IMPLICIT TAGS
+ EXTENSIBILITY IMPLIED ::=
+
+ BEGIN
+
+ LDAPMessage ::= SEQUENCE {
+ messageID MessageID,
+ protocolOp CHOICE {
+ bindRequest BindRequest,
+ bindResponse BindResponse,
+ unbindRequest UnbindRequest,
+ searchRequest SearchRequest,
+ searchResEntry SearchResultEntry,
+ searchResDone SearchResultDone,
+ searchResRef SearchResultReference,
+ modifyRequest ModifyRequest,
+ modifyResponse ModifyResponse,
+ addRequest AddRequest,
+ addResponse AddResponse,
+ delRequest DelRequest,
+ delResponse DelResponse,
+ modDNRequest ModifyDNRequest,
+ modDNResponse ModifyDNResponse,
+ compareRequest CompareRequest,
+ compareResponse CompareResponse,
+ abandonRequest AbandonRequest,
+ extendedReq ExtendedRequest,
+ extendedResp ExtendedResponse,
+ ...,
+ intermediateResponse IntermediateResponse },
+ controls [0] Controls OPTIONAL }
+
+ MessageID ::= INTEGER (0 .. maxInt)
+
+ maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
+
+ LDAPString ::= OCTET STRING -- UTF-8 encoded,
+ -- [ISO10646] characters
+
+
+
+
+Sermersheim Standards Track [Page 54]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ LDAPOID ::= OCTET STRING -- Constrained to <numericoid>
+ -- [RFC4512]
+
+ LDAPDN ::= LDAPString -- Constrained to <distinguishedName>
+ -- [RFC4514]
+
+ RelativeLDAPDN ::= LDAPString -- Constrained to <name-component>
+ -- [RFC4514]
+
+ AttributeDescription ::= LDAPString
+ -- Constrained to <attributedescription>
+ -- [RFC4512]
+
+ AttributeValue ::= OCTET STRING
+
+ AttributeValueAssertion ::= SEQUENCE {
+ attributeDesc AttributeDescription,
+ assertionValue AssertionValue }
+
+ AssertionValue ::= OCTET STRING
+
+ PartialAttribute ::= SEQUENCE {
+ type AttributeDescription,
+ vals SET OF value AttributeValue }
+
+ Attribute ::= PartialAttribute(WITH COMPONENTS {
+ ...,
+ vals (SIZE(1..MAX))})
+
+ MatchingRuleId ::= LDAPString
+
+ LDAPResult ::= SEQUENCE {
+ resultCode ENUMERATED {
+ success (0),
+ operationsError (1),
+ protocolError (2),
+ timeLimitExceeded (3),
+ sizeLimitExceeded (4),
+ compareFalse (5),
+ compareTrue (6),
+ authMethodNotSupported (7),
+ strongerAuthRequired (8),
+ -- 9 reserved --
+ referral (10),
+ adminLimitExceeded (11),
+ unavailableCriticalExtension (12),
+ confidentialityRequired (13),
+ saslBindInProgress (14),
+
+
+
+Sermersheim Standards Track [Page 55]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ noSuchAttribute (16),
+ undefinedAttributeType (17),
+ inappropriateMatching (18),
+ constraintViolation (19),
+ attributeOrValueExists (20),
+ invalidAttributeSyntax (21),
+ -- 22-31 unused --
+ noSuchObject (32),
+ aliasProblem (33),
+ invalidDNSyntax (34),
+ -- 35 reserved for undefined isLeaf --
+ aliasDereferencingProblem (36),
+ -- 37-47 unused --
+ inappropriateAuthentication (48),
+ invalidCredentials (49),
+ insufficientAccessRights (50),
+ busy (51),
+ unavailable (52),
+ unwillingToPerform (53),
+ loopDetect (54),
+ -- 55-63 unused --
+ namingViolation (64),
+ objectClassViolation (65),
+ notAllowedOnNonLeaf (66),
+ notAllowedOnRDN (67),
+ entryAlreadyExists (68),
+ objectClassModsProhibited (69),
+ -- 70 reserved for CLDAP --
+ affectsMultipleDSAs (71),
+ -- 72-79 unused --
+ other (80),
+ ... },
+ matchedDN LDAPDN,
+ diagnosticMessage LDAPString,
+ referral [3] Referral OPTIONAL }
+
+ Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
+
+ URI ::= LDAPString -- limited to characters permitted in
+ -- URIs
+
+ Controls ::= SEQUENCE OF control Control
+
+ Control ::= SEQUENCE {
+ controlType LDAPOID,
+ criticality BOOLEAN DEFAULT FALSE,
+ controlValue OCTET STRING OPTIONAL }
+
+
+
+
+Sermersheim Standards Track [Page 56]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ BindRequest ::= [APPLICATION 0] SEQUENCE {
+ version INTEGER (1 .. 127),
+ name LDAPDN,
+ authentication AuthenticationChoice }
+
+ AuthenticationChoice ::= CHOICE {
+ simple [0] OCTET STRING,
+ -- 1 and 2 reserved
+ sasl [3] SaslCredentials,
+ ... }
+
+ SaslCredentials ::= SEQUENCE {
+ mechanism LDAPString,
+ credentials OCTET STRING OPTIONAL }
+
+ BindResponse ::= [APPLICATION 1] SEQUENCE {
+ COMPONENTS OF LDAPResult,
+ serverSaslCreds [7] OCTET STRING OPTIONAL }
+
+ UnbindRequest ::= [APPLICATION 2] NULL
+
+ SearchRequest ::= [APPLICATION 3] SEQUENCE {
+ baseObject LDAPDN,
+ scope ENUMERATED {
+ baseObject (0),
+ singleLevel (1),
+ wholeSubtree (2),
+ ... },
+ derefAliases ENUMERATED {
+ neverDerefAliases (0),
+ derefInSearching (1),
+ derefFindingBaseObj (2),
+ derefAlways (3) },
+ sizeLimit INTEGER (0 .. maxInt),
+ timeLimit INTEGER (0 .. maxInt),
+ typesOnly BOOLEAN,
+ filter Filter,
+ attributes AttributeSelection }
+
+ AttributeSelection ::= SEQUENCE OF selector LDAPString
+ -- The LDAPString is constrained to
+ -- <attributeSelector> in Section 4.5.1.8
+
+ Filter ::= CHOICE {
+ and [0] SET SIZE (1..MAX) OF filter Filter,
+ or [1] SET SIZE (1..MAX) OF filter Filter,
+ not [2] Filter,
+ equalityMatch [3] AttributeValueAssertion,
+
+
+
+Sermersheim Standards Track [Page 57]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ substrings [4] SubstringFilter,
+ greaterOrEqual [5] AttributeValueAssertion,
+ lessOrEqual [6] AttributeValueAssertion,
+ present [7] AttributeDescription,
+ approxMatch [8] AttributeValueAssertion,
+ extensibleMatch [9] MatchingRuleAssertion,
+ ... }
+
+ SubstringFilter ::= SEQUENCE {
+ type AttributeDescription,
+ substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
+ initial [0] AssertionValue, -- can occur at most once
+ any [1] AssertionValue,
+ final [2] AssertionValue } -- can occur at most once
+ }
+
+ MatchingRuleAssertion ::= SEQUENCE {
+ matchingRule [1] MatchingRuleId OPTIONAL,
+ type [2] AttributeDescription OPTIONAL,
+ matchValue [3] AssertionValue,
+ dnAttributes [4] BOOLEAN DEFAULT FALSE }
+
+ SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
+ objectName LDAPDN,
+ attributes PartialAttributeList }
+
+ PartialAttributeList ::= SEQUENCE OF
+ partialAttribute PartialAttribute
+
+ SearchResultReference ::= [APPLICATION 19] SEQUENCE
+ SIZE (1..MAX) OF uri URI
+
+ SearchResultDone ::= [APPLICATION 5] LDAPResult
+
+ ModifyRequest ::= [APPLICATION 6] SEQUENCE {
+ object LDAPDN,
+ changes SEQUENCE OF change SEQUENCE {
+ operation ENUMERATED {
+ add (0),
+ delete (1),
+ replace (2),
+ ... },
+ modification PartialAttribute } }
+
+ ModifyResponse ::= [APPLICATION 7] LDAPResult
+
+
+
+
+
+
+Sermersheim Standards Track [Page 58]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ AddRequest ::= [APPLICATION 8] SEQUENCE {
+ entry LDAPDN,
+ attributes AttributeList }
+
+ AttributeList ::= SEQUENCE OF attribute Attribute
+
+ AddResponse ::= [APPLICATION 9] LDAPResult
+
+ DelRequest ::= [APPLICATION 10] LDAPDN
+
+ DelResponse ::= [APPLICATION 11] LDAPResult
+
+ ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
+ entry LDAPDN,
+ newrdn RelativeLDAPDN,
+ deleteoldrdn BOOLEAN,
+ newSuperior [0] LDAPDN OPTIONAL }
+
+ ModifyDNResponse ::= [APPLICATION 13] LDAPResult
+
+ CompareRequest ::= [APPLICATION 14] SEQUENCE {
+ entry LDAPDN,
+ ava AttributeValueAssertion }
+
+ CompareResponse ::= [APPLICATION 15] LDAPResult
+
+ AbandonRequest ::= [APPLICATION 16] MessageID
+
+ ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
+ requestName [0] LDAPOID,
+ requestValue [1] OCTET STRING OPTIONAL }
+
+ ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
+ COMPONENTS OF LDAPResult,
+ responseName [10] LDAPOID OPTIONAL,
+ responseValue [11] OCTET STRING OPTIONAL }
+
+ IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
+ responseName [0] LDAPOID OPTIONAL,
+ responseValue [1] OCTET STRING OPTIONAL }
+
+ END
+
+
+
+
+
+
+
+
+
+Sermersheim Standards Track [Page 59]
+
+RFC 4511 LDAPv3 June 2006
+
+
+Appendix C. Changes
+
+ This appendix is non-normative.
+
+ This appendix summarizes substantive changes made to RFC 2251, RFC
+ 2830, and RFC 3771.
+
+C.1. Changes Made to RFC 2251
+
+ This section summarizes the substantive changes made to Sections 1,
+ 2, 3.1, and 4, and the remainder of RFC 2251. Readers should
+ consult [RFC4512] and [RFC4513] for summaries of changes to other
+ sections.
+
+C.1.1. Section 1 (Status of this Memo)
+
+ - Removed IESG note. Post publication of RFC 2251, mandatory LDAP
+ authentication mechanisms have been standardized which are
+ sufficient to remove this note. See [RFC4513] for authentication
+ mechanisms.
+
+C.1.2. Section 3.1 (Protocol Model) and others
+
+ - Removed notes giving history between LDAP v1, v2, and v3. Instead,
+ added sufficient language so that this document can stand on its
+ own.
+
+C.1.3. Section 4 (Elements of Protocol)
+
+ - Clarified where the extensibility features of ASN.1 apply to the
+ protocol. This change affected various ASN.1 types by the
+ inclusion of ellipses (...) to certain elements.
+ - Removed the requirement that servers that implement version 3 or
+ later MUST provide the 'supportedLDAPVersion' attribute. This
+ statement provided no interoperability advantages.
+
+C.1.4. Section 4.1.1 (Message Envelope)
+
+ - There was a mandatory requirement for the server to return a
+ Notice of Disconnection and drop the transport connection when a
+ PDU is malformed in a certain way. This has been updated such that
+ the server SHOULD return the Notice of Disconnection, and it MUST
+ terminate the LDAP Session.
+
+C.1.5. Section 4.1.1.1 (Message ID)
+
+ - Required that the messageID of requests MUST be non-zero as the
+ zero is reserved for Notice of Disconnection.
+
+
+
+Sermersheim Standards Track [Page 60]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ - Specified when it is and isn't appropriate to return an already
+ used messageID. RFC 2251 accidentally imposed synchronous server
+ behavior in its wording of this.
+
+C.1.6. Section 4.1.2 (String Types)
+
+ - Stated that LDAPOID is constrained to <numericoid> from [RFC4512].
+
+C.1.7. Section 4.1.5.1 (Binary Option) and others
+
+ - Removed the Binary Option from the specification. There are
+ numerous interoperability problems associated with this method of
+ alternate attribute type encoding. Work to specify a suitable
+ replacement is ongoing.
+
+C.1.8. Section 4.1.8 (Attribute)
+
+ - Combined the definitions of PartialAttribute and Attribute here,
+ and defined Attribute in terms of PartialAttribute.
+
+C.1.9. Section 4.1.10 (Result Message)
+
+ - Renamed "errorMessage" to "diagnosticMessage" as it is allowed to
+ be sent for non-error results.
+ - Moved some language into Appendix A, and referred the reader there.
+ - Allowed matchedDN to be present for other result codes than those
+ listed in RFC 2251.
+ - Renamed the code "strongAuthRequired" to "strongerAuthRequired" to
+ clarify that this code may often be returned to indicate that a
+ stronger authentication is needed to perform a given operation.
+
+C.1.10. Section 4.1.11 (Referral)
+
+ - Defined referrals in terms of URIs rather than URLs.
+ - Removed the requirement that all referral URIs MUST be equally
+ capable of progressing the operation. The statement was ambiguous
+ and provided no instructions on how to carry it out.
+ - Added the requirement that clients MUST NOT loop between servers.
+ - Clarified the instructions for using LDAPURLs in referrals, and in
+ doing so added a recommendation that the scope part be present.
+ - Removed imperatives which required clients to use URLs in specific
+ ways to progress an operation. These did nothing for
+ interoperability.
+
+
+
+
+
+
+
+
+Sermersheim Standards Track [Page 61]
+
+RFC 4511 LDAPv3 June 2006
+
+
+C.1.11. Section 4.1.12 (Controls)
+
+ - Specified how control values defined in terms of ASN.1 are to be
+ encoded.
+ - Noted that the criticality field is only applied to request
+ messages (except UnbindRequest), and must be ignored when present
+ on response messages and UnbindRequest.
+ - Specified that non-critical controls may be ignored at the
+ server's discretion. There was confusion in the original wording
+ which led some to believe that recognized controls may not be
+ ignored as long as they were associated with a proper request.
+ - Added language regarding combinations of controls and the ordering
+ of controls on a message.
+ - Specified that when the semantics of the combination of controls
+ is undefined or unknown, it results in a protocolError.
+ - Changed "The server MUST be prepared" to "Implementations MUST be
+ prepared" in paragraph 8 to reflect that both client and server
+ implementations must be able to handle this (as both parse
+ controls).
+
+C.1.12. Section 4.2 (Bind Operation)
+
+ - Mandated that servers return protocolError when the version is not
+ supported.
+ - Disambiguated behavior when the simple authentication is used, the
+ name is empty, and the password is non-empty.
+ - Required servers to not dereference aliases for Bind. This was
+ added for consistency with other operations and to help ensure
+ data consistency.
+ - Required that textual passwords be transferred as UTF-8 encoded
+ Unicode, and added recommendations on string preparation. This was
+ to help ensure interoperability of passwords being sent from
+ different clients.
+
+C.1.13. Section 4.2.1 (Sequencing of the Bind Request)
+
+ - This section was largely reorganized for readability, and language
+ was added to clarify the authentication state of failed and
+ abandoned Bind operations.
+ - Removed: "If a SASL transfer encryption or integrity mechanism has
+ been negotiated, that mechanism does not support the changing of
+ credentials from one identity to another, then the client MUST
+ instead establish a new connection."
+ If there are dependencies between multiple negotiations of a
+ particular SASL mechanism, the technical specification for that
+ SASL mechanism details how applications are to deal with them.
+ LDAP should not require any special handling.
+ - Dropped MUST imperative in paragraph 3 to align with [RFC2119].
+
+
+
+Sermersheim Standards Track [Page 62]
+
+RFC 4511 LDAPv3 June 2006
+
+
+ - Mandated that clients not send non-Bind operations while a Bind is
+ in progress, and suggested that servers not process them if they
+ are received. This is needed to ensure proper sequencing of the
+ Bind in relationship to other operations.
+
+C.1.14. Section 4.2.3 (Bind Response)
+
+ - Moved most error-related text to Appendix A, and added text
+ regarding certain errors used in conjunction with the Bind
+ operation.
+ - Prohibited the server from specifying serverSaslCreds when not
+ appropriate.
+
+C.1.15. Section 4.3 (Unbind Operation)
+
+ - Specified that both peers are to cease transmission and terminate
+ the LDAP session for the Unbind operation.
+
+C.1.16. Section 4.4 (Unsolicited Notification)
+
+ - Added instructions for future specifications of Unsolicited
+ Notifications.
+
+C.1.17. Section 4.5.1 (Search Request)
+
+ - SearchRequest attributes is now defined as an AttributeSelection
+ type rather than AttributeDescriptionList, and an ABNF is
+ provided.
+ - SearchRequest attributes may contain duplicate attribute
+ descriptions. This was previously prohibited. Now servers are
+ instructed to ignore subsequent names when they are duplicated.
+ This was relaxed in order to allow different short names and also
+ OIDs to be requested for an attribute.
+ - The present search filter now evaluates to Undefined when the
+ specified attribute is not known to the server. It used to
+ evaluate to FALSE, which caused behavior inconsistent with what
+ most would expect, especially when the 'not' operator was used.
+ - The Filter choice SubstringFilter substrings type is now defined
+ with a lower bound of 1.
+ - The SubstringFilter substrings 'initial, 'any', and 'final' types
+ are now AssertionValue rather than LDAPString. Also, added
+ imperatives stating that 'initial' (if present) must be listed
+ first, and 'final' (if present) must be listed last.
+ - Disambiguated the semantics of the derefAliases choices. There was
+ question as to whether derefInSearching applied to the base object
+ in a wholeSubtree Search.
+ - Added instructions for equalityMatch, substrings, greaterOrEqual,
+ lessOrEqual, and approxMatch.
+
+
+
+Sermersheim Standards Track [Page 63]
+
+RFC 4511 LDAPv3 June 2006
+
+
+
+C.1.18. Section 4.5.2 (Search Result)
+
+ - Recommended that servers not use attribute short names when it
+ knows they are ambiguous or may cause interoperability problems.
+ - Removed all mention of ExtendedResponse due to lack of
+ implementation.
+
+C.1.19. Section 4.5.3 (Continuation References in the Search Result)
+
+ - Made changes similar to those made to Section 4.1.11.
+
+C.1.20. Section 4.5.3.1 (Example)
+
+ - Fixed examples to adhere to changes made to Section 4.5.3.
+
+C.1.21. Section 4.6 (Modify Operation)
+
+ - Replaced AttributeTypeAndValues with Attribute as they are
+ equivalent.
+ - Specified the types of modification changes that might
+ temporarily violate schema. Some readers were under the impression
+ that any temporary schema violation was allowed.
+
+C.1.22. Section 4.7 (Add Operation)
+
+ - Aligned Add operation with X.511 in that the attributes of the RDN
+ are used in conjunction with the listed attributes to create the
+ entry. Previously, Add required that the distinguished values be
+ present in the listed attributes.
+ - Removed requirement that the objectClass attribute MUST be
+ specified as some DSE types do not require this attribute.
+ Instead, generic wording was added, requiring the added entry to
+ adhere to the data model.
+ - Removed recommendation regarding placement of objects. This is
+ covered in the data model document.
+
+C.1.23. Section 4.9 (Modify DN Operation)
+
+ - Required servers to not dereference aliases for Modify DN. This
+ was added for consistency with other operations and to help ensure
+ data consistency.
+ - Allow Modify DN to fail when moving between naming contexts.
+ - Specified what happens when the attributes of the newrdn are not
+ present on the entry.
+
+
+
+
+
+
+Sermersheim Standards Track [Page 64]
+
+RFC 4511 LDAPv3 June 2006
+
+
+C.1.24. Section 4.10 (Compare Operation)
+
+ - Specified that compareFalse means that the Compare took place and
+ the result is false. There was confusion that led people to
+ believe that an Undefined match resulted in compareFalse.
+ - Required servers to not dereference aliases for Compare. This was
+ added for consistency with other operations and to help ensure
+ data consistency.
+
+C.1.25. Section 4.11 (Abandon Operation)
+
+ - Explained that since Abandon returns no response, clients should
+ not use it if they need to know the outcome.
+ - Specified that Abandon and Unbind cannot be abandoned.
+
+C.1.26. Section 4.12 (Extended Operation)
+
+ - Specified how values of Extended operations defined in terms of
+ ASN.1 are to be encoded.
+ - Added instructions on what Extended operation specifications
+ consist of.
+ - Added a recommendation that servers advertise supported Extended
+ operations.
+
+C.1.27. Section 5.2 (Transfer Protocols)
+
+ - Moved referral-specific instructions into referral-related
+ sections.
+
+C.1.28. Section 7 (Security Considerations)
+
+ - Reworded notes regarding SASL not protecting certain aspects of
+ the LDAP Bind messages.
+ - Noted that Servers are encouraged to prevent directory
+ modifications by clients that have authenticated anonymously
+ [RFC4513].
+ - Added a note regarding the possibility of changes to security
+ factors (authentication, authorization, and data confidentiality).
+ - Warned against following referrals that may have been injected in
+ the data stream.
+ - Noted that servers should protect information equally, whether in
+ an error condition or not, and mentioned matchedDN,
+ diagnosticMessage, and resultCodes specifically.
+ - Added a note regarding malformed and long encodings.
+
+
+
+
+
+
+
+Sermersheim Standards Track [Page 65]
+
+RFC 4511 LDAPv3 June 2006
+
+
+C.1.29. Appendix A (Complete ASN.1 Definition)
+
+ - Added "EXTENSIBILITY IMPLIED" to ASN.1 definition.
+ - Removed AttributeType. It is not used.
+
+C.2. Changes Made to RFC 2830
+
+ This section summarizes the substantive changes made to Sections of
+ RFC 2830. Readers should consult [RFC4513] for summaries of changes
+ to other sections.
+
+C.2.1. Section 2.3 (Response other than "success")
+
+ - Removed wording indicating that referrals can be returned from
+ StartTLS.
+ - Removed requirement that only a narrow set of result codes can be
+ returned. Some result codes are required in certain scenarios, but
+ any other may be returned if appropriate.
+ - Removed requirement that the ExtendedResponse.responseName MUST be
+ present. There are circumstances where this is impossible, and
+ requiring this is at odds with language in Section 4.12.
+
+C.2.1. Section 4 (Closing a TLS Connection)
+
+ - Reworded most of this section to align with definitions of the
+ LDAP protocol layers.
+ - Removed instructions on abrupt closure as this is covered in other
+ areas of the document (specifically, Section 5.3)
+
+C.3. Changes Made to RFC 3771
+
+ - Rewrote to fit into this document. In general, semantics were
+ preserved. Supporting and background language seen as redundant
+ due to its presence in this document was omitted.
+
+ - Specified that Intermediate responses to a request may be of
+ different types, and one of the response types may be specified to
+ have no response value.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Standards Track [Page 66]
+
+RFC 4511 LDAPv3 June 2006
+
+
+Editor's Address
+
+ Jim Sermersheim
+ Novell, Inc.
+ 1800 South Novell Place
+ Provo, Utah 84606, USA
+
+ Phone: +1 801 861-3088
+ EMail: jimse@novell.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sermersheim Standards Track [Page 67]
+
+RFC 4511 LDAPv3 June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Sermersheim Standards Track [Page 68]
+
diff --git a/doc/rfc/rfc4512.txt b/doc/rfc/rfc4512.txt
new file mode 100644
index 0000000000000000000000000000000000000000..f45a3f3e73589d881fc62e3c2023b4268c881b9f
--- /dev/null
+++ b/doc/rfc/rfc4512.txt
@@ -0,0 +1,2915 @@
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 4512 OpenLDAP Foundation
+Obsoletes: 2251, 2252, 2256, 3674 June 2006
+Category: Standards Track
+
+
+ Lightweight Directory Access Protocol (LDAP):
+ Directory Information Models
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ The Lightweight Directory Access Protocol (LDAP) is an Internet
+ protocol for accessing distributed directory services that act in
+ accordance with X.500 data and service models. This document
+ describes the X.500 Directory Information Models, as used in LDAP.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 1]
+
+RFC 4512 LDAP Models June 2006
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Relationship to Other LDAP Specifications ..................3
+ 1.2. Relationship to X.501 ......................................4
+ 1.3. Conventions ................................................4
+ 1.4. Common ABNF Productions ....................................4
+ 2. Model of Directory User Information .............................6
+ 2.1. The Directory Information Tree .............................7
+ 2.2. Structure of an Entry ......................................7
+ 2.3. Naming of Entries ..........................................8
+ 2.4. Object Classes .............................................9
+ 2.5. Attribute Descriptions ....................................12
+ 2.6. Alias Entries .............................................16
+ 3. Directory Administrative and Operational Information ...........17
+ 3.1. Subtrees ..................................................17
+ 3.2. Subentries ................................................18
+ 3.3. The 'objectClass' attribute ...............................18
+ 3.4. Operational Attributes ....................................19
+ 4. Directory Schema ...............................................22
+ 4.1. Schema Definitions ........................................23
+ 4.2. Subschema Subentries ......................................32
+ 4.3. 'extensibleObject' object class ...........................35
+ 4.4. Subschema Discovery .......................................35
+ 5. DSA (Server) Informational Model ...............................36
+ 5.1. Server-Specific Data Requirements .........................36
+ 6. Other Considerations ...........................................40
+ 6.1. Preservation of User Information ..........................40
+ 6.2. Short Names ...............................................41
+ 6.3. Cache and Shadowing .......................................41
+ 7. Implementation Guidelines ......................................42
+ 7.1. Server Guidelines .........................................42
+ 7.2. Client Guidelines .........................................42
+ 8. Security Considerations ........................................43
+ 9. IANA Considerations ............................................43
+ 10. Acknowledgements ..............................................44
+ 11. Normative References ..........................................45
+ Appendix A. Changes ...............................................47
+ A.1. Changes to RFC 2251 .......................................47
+ A.2. Changes to RFC 2252 .......................................49
+ A.3. Changes to RFC 2256 .......................................50
+ A.4. Changes to RFC 3674 .......................................51
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 2]
+
+RFC 4512 LDAP Models June 2006
+
+
+1. Introduction
+
+ This document discusses the X.500 Directory Information Models
+ [X.501], as used by the Lightweight Directory Access Protocol (LDAP)
+ [RFC4510].
+
+ The Directory is "a collection of open systems cooperating to provide
+ directory services" [X.500]. The information held in the Directory
+ is collectively known as the Directory Information Base (DIB). A
+ Directory user, which may be a human or other entity, accesses the
+ Directory through a client (or Directory User Agent (DUA)). The
+ client, on behalf of the directory user, interacts with one or more
+ servers (or Directory System Agents (DSA)). A server holds a
+ fragment of the DIB.
+
+ The DIB contains two classes of information:
+
+ 1) user information (e.g., information provided and administrated
+ by users). Section 2 describes the Model of User Information.
+
+ 2) administrative and operational information (e.g., information
+ used to administer and/or operate the directory). Section 3
+ describes the model of Directory Administrative and Operational
+ Information.
+
+ These two models, referred to as the generic Directory Information
+ Models, describe how information is represented in the Directory.
+ These generic models provide a framework for other information
+ models. Section 4 discusses the subschema information model and
+ subschema discovery. Section 5 discusses the DSA (Server)
+ Informational Model.
+
+ Other X.500 information models (such as access control distribution
+ knowledge and replication knowledge information models) may be
+ adapted for use in LDAP. Specification of how these models apply to
+ LDAP is left to future documents.
+
+1.1. Relationship to Other LDAP Specifications
+
+ This document is a integral part of the LDAP technical specification
+ [RFC4510], which obsoletes the previously defined LDAP technical
+ specification, RFC 3377, in its entirety.
+
+ This document obsoletes RFC 2251, Sections 3.2 and 3.4, as well as
+ portions of Sections 4 and 6. Appendix A.1 summarizes changes to
+ these sections. The remainder of RFC 2251 is obsoleted by the
+ [RFC4511], [RFC4513], and [RFC4510] documents.
+
+
+
+
+Zeilenga Standards Track [Page 3]
+
+RFC 4512 LDAP Models June 2006
+
+
+ This document obsoletes RFC 2252, Sections 4, 5, and 7. Appendix A.2
+ summarizes changes to these sections. The remainder of RFC 2252 is
+ obsoleted by [RFC4517].
+
+ This document obsoletes RFC 2256, Sections 5.1, 5.2, 7.1, and 7.2.
+ Appendix A.3 summarizes changes to these sections. The remainder of
+ RFC 2256 is obsoleted by [RFC4519] and [RFC4517].
+
+ This document obsoletes RFC 3674 in its entirety. Appendix A.4
+ summarizes changes since RFC 3674.
+
+1.2. Relationship to X.501
+
+ This document includes material, with and without adaptation, from
+ [X.501] as necessary to describe this protocol. These adaptations
+ (and any other differences herein) apply to this protocol, and only
+ this protocol.
+
+1.3. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+ Schema definitions are provided using LDAP description formats (as
+ defined in Section 4.1). Definitions provided here are formatted
+ (line wrapped) for readability. Matching rules and LDAP syntaxes
+ referenced in these definitions are specified in [RFC4517].
+
+1.4. Common ABNF Productions
+
+ A number of syntaxes in this document are described using Augmented
+ Backus-Naur Form (ABNF) [RFC4234]. These syntaxes (as well as a
+ number of syntaxes defined in other documents) rely on the following
+ common productions:
+
+ keystring = leadkeychar *keychar
+ leadkeychar = ALPHA
+ keychar = ALPHA / DIGIT / HYPHEN
+ number = DIGIT / ( LDIGIT 1*DIGIT )
+
+ ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
+ DIGIT = %x30 / LDIGIT ; "0"-"9"
+ LDIGIT = %x31-39 ; "1"-"9"
+ HEX = DIGIT / %x41-46 / %x61-66 ; "0"-"9" / "A"-"F" / "a"-"f"
+
+ SP = 1*SPACE ; one or more " "
+ WSP = 0*SPACE ; zero or more " "
+
+
+
+Zeilenga Standards Track [Page 4]
+
+RFC 4512 LDAP Models June 2006
+
+
+ NULL = %x00 ; null (0)
+ SPACE = %x20 ; space (" ")
+ DQUOTE = %x22 ; quote (""")
+ SHARP = %x23 ; octothorpe (or sharp sign) ("#")
+ DOLLAR = %x24 ; dollar sign ("$")
+ SQUOTE = %x27 ; single quote ("'")
+ LPAREN = %x28 ; left paren ("(")
+ RPAREN = %x29 ; right paren (")")
+ PLUS = %x2B ; plus sign ("+")
+ COMMA = %x2C ; comma (",")
+ HYPHEN = %x2D ; hyphen ("-")
+ DOT = %x2E ; period (".")
+ SEMI = %x3B ; semicolon (";")
+ LANGLE = %x3C ; left angle bracket ("<")
+ EQUALS = %x3D ; equals sign ("=")
+ RANGLE = %x3E ; right angle bracket (">")
+ ESC = %x5C ; backslash ("\")
+ USCORE = %x5F ; underscore ("_")
+ LCURLY = %x7B ; left curly brace "{"
+ RCURLY = %x7D ; right curly brace "}"
+
+ ; Any UTF-8 [RFC3629] encoded Unicode [Unicode] character
+ UTF8 = UTF1 / UTFMB
+ UTFMB = UTF2 / UTF3 / UTF4
+ UTF0 = %x80-BF
+ UTF1 = %x00-7F
+ UTF2 = %xC2-DF UTF0
+ UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
+ %xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
+ UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
+ %xF4 %x80-8F 2(UTF0)
+
+ OCTET = %x00-FF ; Any octet (8-bit data unit)
+
+ Object identifiers (OIDs) [X.680] are represented in LDAP using a
+ dot-decimal format conforming to the ABNF:
+
+ numericoid = number 1*( DOT number )
+
+ Short names, also known as descriptors, are used as more readable
+ aliases for object identifiers. Short names are case insensitive and
+ conform to the ABNF:
+
+ descr = keystring
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 5]
+
+RFC 4512 LDAP Models June 2006
+
+
+ Where either an object identifier or a short name may be specified,
+ the following production is used:
+
+ oid = descr / numericoid
+
+ While the <descr> form is generally preferred when the usage is
+ restricted to short names referring to object identifiers that
+ identify like kinds of objects (e.g., attribute type descriptions,
+ matching rule descriptions, object class descriptions), the
+ <numericoid> form should be used when the object identifiers may
+ identify multiple kinds of objects or when an unambiguous short name
+ (descriptor) is not available.
+
+ Implementations SHOULD treat short names (descriptors) used in an
+ ambiguous manner (as discussed above) as unrecognized.
+
+ Short Names (descriptors) are discussed further in Section 6.2.
+
+2. Model of Directory User Information
+
+ As [X.501] states:
+
+ The purpose of the Directory is to hold, and provide access to,
+ information about objects of interest (objects) in some 'world'.
+ An object can be anything which is identifiable (can be named).
+
+ An object class is an identified family of objects, or conceivable
+ objects, which share certain characteristics. Every object
+ belongs to at least one class. An object class may be a subclass
+ of other object classes, in which case the members of the former
+ class, the subclass, are also considered to be members of the
+ latter classes, the superclasses. There may be subclasses of
+ subclasses, etc., to an arbitrary depth.
+
+ A directory entry, a named collection of information, is the basic
+ unit of information held in the Directory. There are multiple kinds
+ of directory entries.
+
+ An object entry represents a particular object. An alias entry
+ provides alternative naming. A subentry holds administrative and/or
+ operational information.
+
+ The set of entries representing the DIB are organized hierarchically
+ in a tree structure known as the Directory Information Tree (DIT).
+
+ Section 2.1 describes the Directory Information Tree.
+ Section 2.2 discusses the structure of entries.
+ Section 2.3 discusses naming of entries.
+
+
+
+Zeilenga Standards Track [Page 6]
+
+RFC 4512 LDAP Models June 2006
+
+
+ Section 2.4 discusses object classes.
+ Section 2.5 discusses attribute descriptions.
+ Section 2.6 discusses alias entries.
+
+2.1. The Directory Information Tree
+
+ As noted above, the DIB is composed of a set of entries organized
+ hierarchically in a tree structure known as the Directory Information
+ Tree (DIT); specifically, a tree where vertices are the entries.
+
+ The arcs between vertices define relations between entries. If an
+ arc exists from X to Y, then the entry at X is the immediate superior
+ of Y, and Y is the immediate subordinate of X. An entry's superiors
+ are the entry's immediate superior and its superiors. An entry's
+ subordinates are all of its immediate subordinates and their
+ subordinates.
+
+ Similarly, the superior/subordinate relationship between object
+ entries can be used to derive a relation between the objects they
+ represent. DIT structure rules can be used to govern relationships
+ between objects.
+
+ Note: An entry's immediate superior is also known as the entry's
+ parent, and an entry's immediate subordinate is also known as
+ the entry's child. Entries that have the same parent are known
+ as siblings.
+
+2.2. Structure of an Entry
+
+ An entry consists of a set of attributes that hold information about
+ the object that the entry represents. Some attributes represent user
+ information and are called user attributes. Other attributes
+ represent operational and/or administrative information and are
+ called operational attributes.
+
+ An attribute is an attribute description (a type and zero or more
+ options) with one or more associated values. An attribute is often
+ referred to by its attribute description. For example, the
+ 'givenName' attribute is the attribute that consists of the attribute
+ description 'givenName' (the 'givenName' attribute type [RFC4519] and
+ zero options) and one or more associated values.
+
+ The attribute type governs whether the attribute can have multiple
+ values, the syntax and matching rules used to construct and compare
+ values of that attribute, and other functions. Options indicate
+ subtypes and other functions.
+
+ Attribute values conform to the defined syntax of the attribute type.
+
+
+
+Zeilenga Standards Track [Page 7]
+
+RFC 4512 LDAP Models June 2006
+
+
+ No two values of an attribute may be equivalent. Two values are
+ considered equivalent if and only if they would match according to
+ the equality matching rule of the attribute type. Or, if the
+ attribute type is defined with no equality matching rule, two values
+ are equivalent if and only if they are identical. (See 2.5.1 for
+ other restrictions.)
+
+ For example, a 'givenName' attribute can have more than one value,
+ they must be Directory Strings, and they are case insensitive. A
+ 'givenName' attribute cannot hold both "John" and "JOHN", as these
+ are equivalent values per the equality matching rule of the attribute
+ type.
+
+ Additionally, no attribute is to have a value that is not equivalent
+ to itself. For example, the 'givenName' attribute cannot have as a
+ value a directory string that includes the REPLACEMENT CHARACTER
+ (U+FFFD) code point, as matching involving that directory string is
+ Undefined per this attribute's equality matching rule.
+
+ When an attribute is used for naming of the entry, one and only one
+ value of the attribute is used in forming the Relative Distinguished
+ Name. This value is known as a distinguished value.
+
+2.3. Naming of Entries
+
+2.3.1. Relative Distinguished Names
+
+ Each entry is named relative to its immediate superior. This
+ relative name, known as its Relative Distinguished Name (RDN)
+ [X.501], is composed of an unordered set of one or more attribute
+ value assertions (AVA) consisting of an attribute description with
+ zero options and an attribute value. These AVAs are chosen to match
+ attribute values (each a distinguished value) of the entry.
+
+ An entry's relative distinguished name must be unique among all
+ immediate subordinates of the entry's immediate superior (i.e., all
+ siblings).
+
+ The following are examples of string representations of RDNs
+ [RFC4514]:
+
+ UID=12345
+ OU=Engineering
+ CN=Kurt Zeilenga+L=Redwood Shores
+
+ The last is an example of a multi-valued RDN; that is, an RDN
+ composed of multiple AVAs.
+
+
+
+
+Zeilenga Standards Track [Page 8]
+
+RFC 4512 LDAP Models June 2006
+
+
+2.3.2. Distinguished Names
+
+ An entry's fully qualified name, known as its Distinguished Name (DN)
+ [X.501], is the concatenation of its RDN and its immediate superior's
+ DN. A Distinguished Name unambiguously refers to an entry in the
+ tree. The following are examples of string representations of DNs
+ [RFC4514]:
+
+ UID=nobody@example.com,DC=example,DC=com
+ CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US
+
+2.3.3. Alias Names
+
+ An alias, or alias name, is "an name for an object, provided by the
+ use of alias entries" [X.501]. Alias entries are described in
+ Section 2.6.
+
+2.4. Object Classes
+
+ An object class is "an identified family of objects (or conceivable
+ objects) that share certain characteristics" [X.501].
+
+ As defined in [X.501]:
+
+ Object classes are used in the Directory for a number of purposes:
+
+ - describing and categorizing objects and the entries that
+ correspond to these objects;
+
+ - where appropriate, controlling the operation of the Directory;
+
+ - regulating, in conjunction with DIT structure rule
+ specifications, the position of entries in the DIT;
+
+ - regulating, in conjunction with DIT content rule
+ specifications, the attributes that are contained in entries;
+
+ - identifying classes of entry that are to be associated with a
+ particular policy by the appropriate administrative authority.
+
+ An object class (a subclass) may be derived from an object class
+ (its direct superclass) which is itself derived from an even more
+ generic object class. For structural object classes, this process
+ stops at the most generic object class, 'top' (defined in Section
+ 2.4.1). An ordered set of superclasses up to the most superior
+ object class of an object class is its superclass chain.
+
+
+
+
+
+Zeilenga Standards Track [Page 9]
+
+RFC 4512 LDAP Models June 2006
+
+
+ An object class may be derived from two or more direct
+ superclasses (superclasses not part of the same superclass chain).
+ This feature of subclassing is termed multiple inheritance.
+
+ Each object class identifies the set of attributes required to be
+ present in entries belonging to the class and the set of attributes
+ allowed to be present in entries belonging to the class. As an entry
+ of a class must meet the requirements of each class it belongs to, it
+ can be said that an object class inherits the sets of allowed and
+ required attributes from its superclasses. A subclass can identify
+ an attribute allowed by its superclass as being required. If an
+ attribute is a member of both sets, it is required to be present.
+
+ Each object class is defined to be one of three kinds of object
+ classes: Abstract, Structural, or Auxiliary.
+
+ Each object class is identified by an object identifier (OID) and,
+ optionally, one or more short names (descriptors).
+
+2.4.1. Abstract Object Classes
+
+ An abstract object class, as the name implies, provides a base of
+ characteristics from which other object classes can be defined to
+ inherit from. An entry cannot belong to an abstract object class
+ unless it belongs to a structural or auxiliary class that inherits
+ from that abstract class.
+
+ Abstract object classes cannot derive from structural or auxiliary
+ object classes.
+
+ All structural object classes derive (directly or indirectly) from
+ the 'top' abstract object class. Auxiliary object classes do not
+ necessarily derive from 'top'.
+
+ The following is the object class definition (see Section 4.1.1) for
+ the 'top' object class:
+
+ ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
+
+ All entries belong to the 'top' abstract object class.
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 10]
+
+RFC 4512 LDAP Models June 2006
+
+
+2.4.2. Structural Object Classes
+
+ As stated in [X.501]:
+
+ An object class defined for use in the structural specification of
+ the DIT is termed a structural object class. Structural object
+ classes are used in the definition of the structure of the names
+ of the objects for compliant entries.
+
+ An object or alias entry is characterized by precisely one
+ structural object class superclass chain which has a single
+ structural object class as the most subordinate object class.
+ This structural object class is referred to as the structural
+ object class of the entry.
+
+ Structural object classes are related to associated entries:
+
+ - an entry conforming to a structural object class shall
+ represent the real-world object constrained by the object
+ class;
+
+ - DIT structure rules only refer to structural object classes;
+ the structural object class of an entry is used to specify the
+ position of the entry in the DIT;
+
+ - the structural object class of an entry is used, along with an
+ associated DIT content rule, to control the content of an
+ entry.
+
+ The structural object class of an entry shall not be changed.
+
+ Each structural object class is a (direct or indirect) subclass of
+ the 'top' abstract object class.
+
+ Structural object classes cannot subclass auxiliary object classes.
+
+ Each entry is said to belong to its structural object class as well
+ as all classes in its structural object class's superclass chain.
+
+2.4.3. Auxiliary Object Classes
+
+ Auxiliary object classes are used to augment the characteristics of
+ entries. They are commonly used to augment the sets of attributes
+ required and allowed to be present in an entry. They can be used to
+ describe entries or classes of entries.
+
+ Auxiliary object classes cannot subclass structural object classes.
+
+
+
+
+Zeilenga Standards Track [Page 11]
+
+RFC 4512 LDAP Models June 2006
+
+
+ An entry can belong to any subset of the set of auxiliary object
+ classes allowed by the DIT content rule associated with the
+ structural object class of the entry. If no DIT content rule is
+ associated with the structural object class of the entry, the entry
+ cannot belong to any auxiliary object class.
+
+ The set of auxiliary object classes that an entry belongs to can
+ change over time.
+
+2.5. Attribute Descriptions
+
+ An attribute description is composed of an attribute type (see
+ Section 2.5.1) and a set of zero or more attribute options (see
+ Section 2.5.2).
+
+ An attribute description is represented by the ABNF:
+
+ attributedescription = attributetype options
+ attributetype = oid
+ options = *( SEMI option )
+ option = 1*keychar
+
+ where <attributetype> identifies the attribute type and each <option>
+ identifies an attribute option. Both <attributetype> and <option>
+ productions are case insensitive. The order in which <option>s
+ appear is irrelevant. That is, any two <attributedescription>s that
+ consist of the same <attributetype> and same set of <option>s are
+ equivalent.
+
+ Examples of valid attribute descriptions:
+
+ 2.5.4.0
+ cn;lang-de;lang-en
+ owner
+
+ An attribute description with an unrecognized attribute type is to be
+ treated as unrecognized. Servers SHALL treat an attribute
+ description with an unrecognized attribute option as unrecognized.
+ Clients MAY treat an unrecognized attribute option as a tagging
+ option (see Section 2.5.2.1).
+
+ All attributes of an entry must have distinct attribute descriptions.
+
+2.5.1. Attribute Types
+
+ An attribute type governs whether the attribute can have multiple
+ values, the syntax and matching rules used to construct and compare
+ values of that attribute, and other functions.
+
+
+
+Zeilenga Standards Track [Page 12]
+
+RFC 4512 LDAP Models June 2006
+
+
+ If no equality matching is specified for the attribute type:
+
+ - the attribute (of the type) cannot be used for naming;
+ - when adding the attribute (or replacing all values), no two
+ values may be equivalent (see 2.2);
+ - individual values of a multi-valued attribute are not to be
+ independently added or deleted;
+ - attribute value assertions (such as matching in search filters
+ and comparisons) using values of such a type cannot be
+ performed.
+
+ Otherwise, the specified equality matching rule is to be used to
+ evaluate attribute value assertions concerning the attribute type.
+ The specified equality rule is to be transitive and commutative.
+
+ The attribute type indicates whether the attribute is a user
+ attribute or an operational attribute. If operational, the attribute
+ type indicates the operational usage and whether or not the attribute
+ is modifiable by users. Operational attributes are discussed in
+ Section 3.4.
+
+ An attribute type (a subtype) may derive from a more generic
+ attribute type (a direct supertype). The following restrictions
+ apply to subtyping:
+
+ - a subtype must have the same usage as its direct supertype,
+ - a subtype's syntax must be the same, or a refinement of, its
+ supertype's syntax, and
+ - a subtype must be collective [RFC3671] if its supertype is
+ collective.
+
+ An attribute description consisting of a subtype and no options is
+ said to be the direct description subtype of the attribute
+ description consisting of the subtype's direct supertype and no
+ options.
+
+ Each attribute type is identified by an object identifier (OID) and,
+ optionally, one or more short names (descriptors).
+
+2.5.2. Attribute Options
+
+ There are multiple kinds of attribute description options. The LDAP
+ technical specification details one kind: tagging options.
+
+ Not all options can be associated with attributes held in the
+ directory. Tagging options can be.
+
+
+
+
+
+Zeilenga Standards Track [Page 13]
+
+RFC 4512 LDAP Models June 2006
+
+
+ Not all options can be used in conjunction with all attribute types.
+ In such cases, the attribute description is to be treated as
+ unrecognized.
+
+ An attribute description that contains mutually exclusive options
+ shall be treated as unrecognized. That is, "cn;x-bar;x-foo", where
+ "x-foo" and "x-bar" are mutually exclusive, is to be treated as
+ unrecognized.
+
+ Other kinds of options may be specified in future documents. These
+ documents must detail how new kinds of options they define relate to
+ tagging options. In particular, these documents must detail whether
+ or not new kinds of options can be associated with attributes held in
+ the directory, how new kinds of options affect transfer of attribute
+ values, and how new kinds of options are treated in attribute
+ description hierarchies.
+
+ Options are represented as short, case-insensitive textual strings
+ conforming to the <option> production defined in Section 2.5 of this
+ document.
+
+ Procedures for registering options are detailed in BCP 64, RFC 4520
+ [RFC4520].
+
+2.5.2.1. Tagging Options
+
+ Attributes held in the directory can have attribute descriptions with
+ any number of tagging options. Tagging options are never mutually
+ exclusive.
+
+ An attribute description with N tagging options is a direct
+ (description) subtype of all attribute descriptions of the same
+ attribute type and all but one of the N options. If the attribute
+ type has a supertype, then the attribute description is also a direct
+ (description) subtype of the attribute description of the supertype
+ and the N tagging options. That is, 'cn;lang-de;lang-en' is a direct
+ (description) subtype of 'cn;lang-de', 'cn;lang-en', and
+ 'name;lang-de;lang-en' ('cn' is a subtype of 'name'; both are defined
+ in [RFC4519]).
+
+2.5.3. Attribute Description Hierarchies
+
+ An attribute description can be the direct subtype of zero or more
+ other attribute descriptions as indicated by attribute type subtyping
+ (as described in Section 2.5.1) or attribute tagging option subtyping
+ (as described in Section 2.5.2.1). These subtyping relationships are
+ used to form hierarchies of attribute descriptions and attributes.
+
+
+
+
+Zeilenga Standards Track [Page 14]
+
+RFC 4512 LDAP Models June 2006
+
+
+ As adapted from [X.501]:
+
+ Attribute hierarchies allow access to the DIB with varying degrees
+ of granularity. This is achieved by allowing the value components
+ of attributes to be accessed by using either their specific
+ attribute description (a direct reference to the attribute) or a
+ more generic attribute description (an indirect reference).
+
+ Semantically related attributes may be placed in a hierarchical
+ relationship, the more specialized being placed subordinate to the
+ more generalized. Searching for or retrieving attributes and
+ their values is made easier by quoting the more generalized
+ attribute description; a filter item so specified is evaluated for
+ the more specialized descriptions as well as for the quoted
+ description.
+
+ Where subordinate specialized descriptions are selected to be
+ returned as part of a search result these descriptions shall be
+ returned if available. Where the more general descriptions are
+ selected to be returned as part of a search result both the
+ general and the specialized descriptions shall be returned, if
+ available. An attribute value shall always be returned as a value
+ of its own attribute description.
+
+ All of the attribute descriptions in an attribute hierarchy are
+ treated as distinct and unrelated descriptions for user
+ modification of entry content.
+
+ An attribute value stored in an object or alias entry is of
+ precisely one attribute description. The description is indicated
+ when the value is originally added to the entry.
+
+ For the purpose of subschema administration of the entry, a
+ specification that an attribute is required is fulfilled if the entry
+ contains a value of an attribute description belonging to an
+ attribute hierarchy where the attribute type of that description is
+ the same as the required attribute's type. That is, a "MUST name"
+ specification is fulfilled by 'name' or 'name;x-tag-option', but is
+ not fulfilled by 'CN' or 'CN;x-tag-option' (even though 'CN' is a
+ subtype of 'name'). Likewise, an entry may contain a value of an
+ attribute description belonging to an attribute hierarchy where the
+ attribute type of that description is either explicitly included in
+ the definition of an object class to which the entry belongs or
+ allowed by the DIT content rule applicable to that entry. That is,
+ 'name' and 'name;x-tag-option' are allowed by "MAY name" (or by "MUST
+ name"), but 'CN' and 'CN;x-tag-option' are not allowed by "MAY name"
+ (or by "MUST name").
+
+
+
+
+Zeilenga Standards Track [Page 15]
+
+RFC 4512 LDAP Models June 2006
+
+
+ For the purposes of other policy administration, unless stated
+ otherwise in the specification of the particular administrative
+ model, all of the attribute descriptions in an attribute hierarchy
+ are treated as distinct and unrelated descriptions.
+
+2.6. Alias Entries
+
+ As adapted from [X.501]:
+
+ An alias, or an alias name, for an object is an alternative name
+ for an object or object entry which is provided by the use of
+ alias entries.
+
+ Each alias entry contains, within the 'aliasedObjectName'
+ attribute (known as the 'aliasedEntryName' attribute in X.500), a
+ name of some object. The distinguished name of the alias entry is
+ thus also a name for this object.
+
+ NOTE - The name within the 'aliasedObjectName' is said to be
+ pointed to by the alias. It does not have to be the
+ distinguished name of any entry.
+
+ The conversion of an alias name to an object name is termed
+ (alias) dereferencing and comprises the systematic replacement of
+ alias names, where found within a purported name, by the value of
+ the corresponding 'aliasedObjectName' attribute. The process may
+ require the examination of more than one alias entry.
+
+ Any particular entry in the DIT may have zero or more alias names.
+ It therefore follows that several alias entries may point to the
+ same entry. An alias entry may point to an entry that is not a
+ leaf entry and may point to another alias entry.
+
+ An alias entry shall have no subordinates, so that an alias entry
+ is always a leaf entry.
+
+ Every alias entry shall belong to the 'alias' object class.
+
+ An entry with the 'alias' object class must also belong to an object
+ class (or classes), or be governed by a DIT content rule, which
+ allows suitable naming attributes to be present.
+
+ Example:
+
+ dn: cn=bar,dc=example,dc=com
+ objectClass: top
+ objectClass: alias
+ objectClass: extensibleObject
+
+
+
+Zeilenga Standards Track [Page 16]
+
+RFC 4512 LDAP Models June 2006
+
+
+ cn: bar
+ aliasedObjectName: cn=foo,dc=example,dc=com
+
+2.6.1. 'alias' Object Class
+
+ Alias entries belong to the 'alias' object class.
+
+ ( 2.5.6.1 NAME 'alias'
+ SUP top STRUCTURAL
+ MUST aliasedObjectName )
+
+2.6.2. 'aliasedObjectName' Attribute Type
+
+ The 'aliasedObjectName' attribute holds the name of the entry an
+ alias points to. The 'aliasedObjectName' attribute is known as the
+ 'aliasedEntryName' attribute in X.500.
+
+ ( 2.5.4.1 NAME 'aliasedObjectName'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ SINGLE-VALUE )
+
+ The 'distinguishedNameMatch' matching rule and the DistinguishedName
+ (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
+
+3. Directory Administrative and Operational Information
+
+ This section discusses select aspects of the X.500 Directory
+ Administrative and Operational Information model [X.501]. LDAP
+ implementations MAY support other aspects of this model.
+
+3.1. Subtrees
+
+ As defined in [X.501]:
+
+ A subtree is a collection of object and alias entries situated at
+ the vertices of a tree. Subtrees do not contain subentries. The
+ prefix sub, in subtree, emphasizes that the base (or root) vertex
+ of this tree is usually subordinate to the root of the DIT.
+
+ A subtree begins at some vertex and extends to some identifiable
+ lower boundary, possibly extending to leaves. A subtree is always
+ defined within a context which implicitly bounds the subtree. For
+ example, the vertex and lower boundaries of a subtree defining a
+ replicated area are bounded by a naming context.
+
+
+
+
+
+
+Zeilenga Standards Track [Page 17]
+
+RFC 4512 LDAP Models June 2006
+
+
+3.2. Subentries
+
+ A subentry is a "special sort of entry, known by the Directory, used
+ to hold information associated with a subtree or subtree refinement"
+ [X.501]. Subentries are used in Directory to hold for administrative
+ and operational purposes as defined in [X.501]. Their use in LDAP is
+ detailed in [RFC3672].
+
+ The term "(sub)entry" in this specification indicates that servers
+ implementing X.500(93) models are, in accordance with X.500(93) as
+ described in [RFC3672], to use a subentry and that other servers are
+ to use an object entry belonging to the appropriate auxiliary class
+ normally used with the subentry (e.g., 'subschema' for subschema
+ subentries) to mimic the subentry. This object entry's RDN SHALL be
+ formed from a value of the 'cn' (commonName) attribute [RFC4519] (as
+ all subentries are named with 'cn').
+
+3.3. The 'objectClass' attribute
+
+ Each entry in the DIT has an 'objectClass' attribute.
+
+ ( 2.5.4.0 NAME 'objectClass'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
+
+ The 'objectIdentifierMatch' matching rule and the OBJECT IDENTIFIER
+ (1.3.6.1.4.1.1466.115.121.1.38) syntax are defined in [RFC4517].
+
+ The 'objectClass' attribute specifies the object classes of an entry,
+ which (among other things) are used in conjunction with the
+ controlling schema to determine the permitted attributes of an entry.
+ Values of this attribute can be modified by clients, but the
+ 'objectClass' attribute cannot be removed.
+
+ Servers that follow X.500(93) models SHALL restrict modifications of
+ this attribute to prevent the basic structural class of the entry
+ from being changed. That is, one cannot change a 'person' into a
+ 'country'.
+
+ When creating an entry or adding an 'objectClass' value to an entry,
+ all superclasses of the named classes SHALL be implicitly added as
+ well if not already present. That is, if the auxiliary class 'x-a'
+ is a subclass of the class 'x-b', adding 'x-a' to 'objectClass'
+ causes 'x-b' to be implicitly added (if is not already present).
+
+ Servers SHALL restrict modifications of this attribute to prevent
+ superclasses of remaining 'objectClass' values from being deleted.
+ That is, if the auxiliary class 'x-a' is a subclass of the auxiliary
+
+
+
+Zeilenga Standards Track [Page 18]
+
+RFC 4512 LDAP Models June 2006
+
+
+ class 'x-b' and the 'objectClass' attribute contains 'x-a' and 'x-b',
+ an attempt to delete only 'x-b' from the 'objectClass' attribute is
+ an error.
+
+3.4. Operational Attributes
+
+ Some attributes, termed operational attributes, are used or
+ maintained by servers for administrative and operational purposes.
+ As stated in [X.501]: "There are three varieties of operational
+ attributes: Directory operational attributes, DSA-shared operational
+ attributes, and DSA-specific operational attributes".
+
+ A directory operational attribute is used to represent operational
+ and/or administrative information in the Directory Information Model.
+ This includes operational attributes maintained by the server (e.g.,
+ 'createTimestamp') as well as operational attributes that hold values
+ administrated by the user (e.g., 'ditContentRules').
+
+ A DSA-shared operational attribute is used to represent information
+ of the DSA Information Model that is shared between DSAs.
+
+ A DSA-specific operational attribute is used to represent information
+ of the DSA Information Model that is specific to the DSA (though, in
+ some cases, may be derived from information shared between DSAs;
+ e.g., 'namingContexts').
+
+ The DSA Information Model operational attributes are detailed in
+ [X.501].
+
+ Operational attributes are not normally visible. They are not
+ returned in search results unless explicitly requested by name.
+
+ Not all operational attributes are user modifiable.
+
+ Entries may contain, among others, the following operational
+ attributes:
+
+ - creatorsName: the Distinguished Name of the user who added this
+ entry to the directory,
+
+ - createTimestamp: the time this entry was added to the directory,
+
+ - modifiersName: the Distinguished Name of the user who last
+ modified this entry, and
+
+ - modifyTimestamp: the time this entry was last modified.
+
+
+
+
+
+Zeilenga Standards Track [Page 19]
+
+RFC 4512 LDAP Models June 2006
+
+
+ Servers SHOULD maintain the 'creatorsName', 'createTimestamp',
+ 'modifiersName', and 'modifyTimestamp' attributes for all entries of
+ the DIT.
+
+3.4.1. 'creatorsName'
+
+ This attribute appears in entries that were added using the protocol
+ (e.g., using the Add operation). The value is the distinguished name
+ of the creator.
+
+ ( 2.5.18.3 NAME 'creatorsName'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ SINGLE-VALUE NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ The 'distinguishedNameMatch' matching rule and the DistinguishedName
+ (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
+
+3.4.2. 'createTimestamp'
+
+ This attribute appears in entries that were added using the protocol
+ (e.g., using the Add operation). The value is the time the entry was
+ added.
+
+ ( 2.5.18.1 NAME 'createTimestamp'
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch'
+ matching rules and the GeneralizedTime
+ (1.3.6.1.4.1.1466.115.121.1.24) syntax are defined in [RFC4517].
+
+3.4.3. 'modifiersName'
+
+ This attribute appears in entries that have been modified using the
+ protocol (e.g., using the Modify operation). The value is the
+ distinguished name of the last modifier.
+
+ ( 2.5.18.4 NAME 'modifiersName'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ SINGLE-VALUE NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+
+
+
+Zeilenga Standards Track [Page 20]
+
+RFC 4512 LDAP Models June 2006
+
+
+ The 'distinguishedNameMatch' matching rule and the DistinguishedName
+ (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
+
+3.4.4. 'modifyTimestamp'
+
+ This attribute appears in entries that have been modified using the
+ protocol (e.g., using the Modify operation). The value is the time
+ the entry was last modified.
+
+ ( 2.5.18.2 NAME 'modifyTimestamp'
+ EQUALITY generalizedTimeMatch
+ ORDERING generalizedTimeOrderingMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
+ SINGLE-VALUE NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch'
+ matching rules and the GeneralizedTime
+ (1.3.6.1.4.1.1466.115.121.1.24) syntax are defined in [RFC4517].
+
+3.4.5. 'structuralObjectClass'
+
+ This attribute indicates the structural object class of the entry.
+
+ ( 2.5.21.9 NAME 'structuralObjectClass'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ SINGLE-VALUE NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ The 'objectIdentifierMatch' matching rule and OBJECT IDENTIFIER
+ (1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [RFC4517].
+
+3.4.6. 'governingStructureRule'
+
+ This attribute indicates the structure rule governing the entry.
+
+ ( 2.5.21.10 NAME 'governingStructureRule'
+ EQUALITY integerMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ SINGLE-VALUE NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ The 'integerMatch' matching rule and INTEGER
+ (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in [RFC4517].
+
+
+
+
+
+
+Zeilenga Standards Track [Page 21]
+
+RFC 4512 LDAP Models June 2006
+
+
+4. Directory Schema
+
+ As defined in [X.501]:
+
+ The Directory Schema is a set of definitions and constraints
+ concerning the structure of the DIT, the possible ways entries are
+ named, the information that can be held in an entry, the
+ attributes used to represent that information and their
+ organization into hierarchies to facilitate search and retrieval
+ of the information and the ways in which values of attributes may
+ be matched in attribute value and matching rule assertions.
+
+ NOTE 1 - The schema enables the Directory system to, for example:
+
+ - prevent the creation of subordinate entries of the wrong
+ object-class (e.g., a country as a subordinate of a person);
+
+ - prevent the addition of attribute-types to an entry
+ inappropriate to the object-class (e.g., a serial number to a
+ person's entry);
+
+ - prevent the addition of an attribute value of a syntax not
+ matching that defined for the attribute-type (e.g., a printable
+ string to a bit string).
+
+ Formally, the Directory Schema comprises a set of:
+
+ a) Name Form definitions that define primitive naming relations
+ for structural object classes;
+
+ b) DIT Structure Rule definitions that define the names that
+ entries may have and the ways in which the entries may be
+ related to one another in the DIT;
+
+ c) DIT Content Rule definitions that extend the specification of
+ allowable attributes for entries beyond those indicated by the
+ structural object classes of the entries;
+
+ d) Object Class definitions that define the basic set of mandatory
+ and optional attributes that shall be present, and may be
+ present, respectively, in an entry of a given class, and which
+ indicate the kind of object class that is being defined;
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 22]
+
+RFC 4512 LDAP Models June 2006
+
+
+ e) Attribute Type definitions that identify the object identifier
+ by which an attribute is known, its syntax, associated matching
+ rules, whether it is an operational attribute and if so its
+ type, whether it is a collective attribute, whether it is
+ permitted to have multiple values and whether or not it is
+ derived from another attribute type;
+
+ f) Matching Rule definitions that define matching rules.
+
+ And in LDAP:
+
+ g) LDAP Syntax definitions that define encodings used in LDAP.
+
+4.1. Schema Definitions
+
+ Schema definitions in this section are described using ABNF and rely
+ on the common productions specified in Section 1.2 as well as these:
+
+ noidlen = numericoid [ LCURLY len RCURLY ]
+ len = number
+
+ oids = oid / ( LPAREN WSP oidlist WSP RPAREN )
+ oidlist = oid *( WSP DOLLAR WSP oid )
+
+ extensions = *( SP xstring SP qdstrings )
+ xstring = "X" HYPHEN 1*( ALPHA / HYPHEN / USCORE )
+
+ qdescrs = qdescr / ( LPAREN WSP qdescrlist WSP RPAREN )
+ qdescrlist = [ qdescr *( SP qdescr ) ]
+ qdescr = SQUOTE descr SQUOTE
+
+ qdstrings = qdstring / ( LPAREN WSP qdstringlist WSP RPAREN )
+ qdstringlist = [ qdstring *( SP qdstring ) ]
+ qdstring = SQUOTE dstring SQUOTE
+ dstring = 1*( QS / QQ / QUTF8 ) ; escaped UTF-8 string
+
+ QQ = ESC %x32 %x37 ; "\27"
+ QS = ESC %x35 ( %x43 / %x63 ) ; "\5C" / "\5c"
+
+ ; Any UTF-8 encoded Unicode character
+ ; except %x27 ("\'") and %x5C ("\")
+ QUTF8 = QUTF1 / UTFMB
+
+ ; Any ASCII character except %x27 ("\'") and %x5C ("\")
+ QUTF1 = %x00-26 / %x28-5B / %x5D-7F
+
+ Schema definitions in this section also share a number of common
+ terms.
+
+
+
+Zeilenga Standards Track [Page 23]
+
+RFC 4512 LDAP Models June 2006
+
+
+ The NAME field provides a set of short names (descriptors) that are
+ to be used as aliases for the OID.
+
+ The DESC field optionally allows a descriptive string to be provided
+ by the directory administrator and/or implementor. While
+ specifications may suggest a descriptive string, there is no
+ requirement that the suggested (or any) descriptive string be used.
+
+ The OBSOLETE field, if present, indicates the element is not active.
+
+ Implementors should note that future versions of this document may
+ expand these definitions to include additional terms. Terms whose
+ identifier begins with "X-" are reserved for private experiments and
+ are followed by <SP> and <qdstrings> tokens.
+
+4.1.1. Object Class Definitions
+
+ Object Class definitions are written according to the ABNF:
+
+ ObjectClassDescription = LPAREN WSP
+ numericoid ; object identifier
+ [ SP "NAME" SP qdescrs ] ; short names (descriptors)
+ [ SP "DESC" SP qdstring ] ; description
+ [ SP "OBSOLETE" ] ; not active
+ [ SP "SUP" SP oids ] ; superior object classes
+ [ SP kind ] ; kind of class
+ [ SP "MUST" SP oids ] ; attribute types
+ [ SP "MAY" SP oids ] ; attribute types
+ extensions WSP RPAREN
+
+ kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"
+
+ where:
+ <numericoid> is object identifier assigned to this object class;
+ NAME <qdescrs> are short names (descriptors) identifying this
+ object class;
+ DESC <qdstring> is a short descriptive string;
+ OBSOLETE indicates this object class is not active;
+ SUP <oids> specifies the direct superclasses of this object class;
+ the kind of object class is indicated by one of ABSTRACT,
+ STRUCTURAL, or AUXILIARY (the default is STRUCTURAL);
+ MUST and MAY specify the sets of required and allowed attribute
+ types, respectively; and
+ <extensions> describe extensions.
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 24]
+
+RFC 4512 LDAP Models June 2006
+
+
+4.1.2. Attribute Types
+
+ Attribute Type definitions are written according to the ABNF:
+
+ AttributeTypeDescription = LPAREN WSP
+ numericoid ; object identifier
+ [ SP "NAME" SP qdescrs ] ; short names (descriptors)
+ [ SP "DESC" SP qdstring ] ; description
+ [ SP "OBSOLETE" ] ; not active
+ [ SP "SUP" SP oid ] ; supertype
+ [ SP "EQUALITY" SP oid ] ; equality matching rule
+ [ SP "ORDERING" SP oid ] ; ordering matching rule
+ [ SP "SUBSTR" SP oid ] ; substrings matching rule
+ [ SP "SYNTAX" SP noidlen ] ; value syntax
+ [ SP "SINGLE-VALUE" ] ; single-value
+ [ SP "COLLECTIVE" ] ; collective
+ [ SP "NO-USER-MODIFICATION" ] ; not user modifiable
+ [ SP "USAGE" SP usage ] ; usage
+ extensions WSP RPAREN ; extensions
+
+ usage = "userApplications" / ; user
+ "directoryOperation" / ; directory operational
+ "distributedOperation" / ; DSA-shared operational
+ "dSAOperation" ; DSA-specific operational
+
+ where:
+ <numericoid> is object identifier assigned to this attribute type;
+ NAME <qdescrs> are short names (descriptors) identifying this
+ attribute type;
+ DESC <qdstring> is a short descriptive string;
+ OBSOLETE indicates this attribute type is not active;
+ SUP oid specifies the direct supertype of this type;
+ EQUALITY, ORDERING, and SUBSTR provide the oid of the equality,
+ ordering, and substrings matching rules, respectively;
+ SYNTAX identifies value syntax by object identifier and may suggest
+ a minimum upper bound;
+ SINGLE-VALUE indicates attributes of this type are restricted to a
+ single value;
+ COLLECTIVE indicates this attribute type is collective
+ [X.501][RFC3671];
+ NO-USER-MODIFICATION indicates this attribute type is not user
+ modifiable;
+ USAGE indicates the application of this attribute type; and
+ <extensions> describe extensions.
+
+ Each attribute type description must contain at least one of the SUP
+ or SYNTAX fields. If no SYNTAX field is provided, the attribute type
+ description takes its value from the supertype.
+
+
+
+Zeilenga Standards Track [Page 25]
+
+RFC 4512 LDAP Models June 2006
+
+
+ If SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING
+ fields, if not specified, take their value from the supertype.
+
+ Usage of userApplications, the default, indicates that attributes of
+ this type represent user information. That is, they are user
+ attributes.
+
+ A usage of directoryOperation, distributedOperation, or dSAOperation
+ indicates that attributes of this type represent operational and/or
+ administrative information. That is, they are operational
+ attributes.
+
+ directoryOperation usage indicates that the attribute of this type is
+ a directory operational attribute. distributedOperation usage
+ indicates that the attribute of this type is a DSA-shared usage
+ operational attribute. dSAOperation usage indicates that the
+ attribute of this type is a DSA-specific operational attribute.
+
+ COLLECTIVE requires usage userApplications. Use of collective
+ attribute types in LDAP is discussed in [RFC3671].
+
+ NO-USER-MODIFICATION requires an operational usage.
+
+ Note that the <AttributeTypeDescription> does not list the matching
+ rules that can be used with that attribute type in an extensibleMatch
+ search filter [RFC4511]. This is done using the 'matchingRuleUse'
+ attribute described in Section 4.1.4.
+
+ This document refines the schema description of X.501 by requiring
+ that the SYNTAX field in an <AttributeTypeDescription> be a string
+ representation of an object identifier for the LDAP string syntax
+ definition, with an optional indication of the suggested minimum
+ bound of a value of this attribute.
+
+ A suggested minimum upper bound on the number of characters in a
+ value with a string-based syntax, or the number of bytes in a value
+ for all other syntaxes, may be indicated by appending this bound
+ count inside of curly braces following the syntax's OBJECT IDENTIFIER
+ in an Attribute Type Description. This bound is not part of the
+ syntax name itself. For instance, "1.3.6.4.1.1466.0{64}" suggests
+ that server implementations should allow a string to be 64 characters
+ long, although they may allow longer strings. Note that a single
+ character of the Directory String syntax may be encoded in more than
+ one octet since UTF-8 [RFC3629] is a variable-length encoding.
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 26]
+
+RFC 4512 LDAP Models June 2006
+
+
+4.1.3. Matching Rules
+
+ Matching rules are used in performance of attribute value assertions,
+ such as in performance of a Compare operation. They are also used in
+ evaluating search filters, determining which individual values are to
+ be added or deleted during performance of a Modify operation, and in
+ comparing distinguished names.
+
+ Each matching rule is identified by an object identifier (OID) and,
+ optionally, one or more short names (descriptors).
+
+ Matching rule definitions are written according to the ABNF:
+
+ MatchingRuleDescription = LPAREN WSP
+ numericoid ; object identifier
+ [ SP "NAME" SP qdescrs ] ; short names (descriptors)
+ [ SP "DESC" SP qdstring ] ; description
+ [ SP "OBSOLETE" ] ; not active
+ SP "SYNTAX" SP numericoid ; assertion syntax
+ extensions WSP RPAREN ; extensions
+
+ where:
+ <numericoid> is object identifier assigned to this matching rule;
+ NAME <qdescrs> are short names (descriptors) identifying this
+ matching rule;
+ DESC <qdstring> is a short descriptive string;
+ OBSOLETE indicates this matching rule is not active;
+ SYNTAX identifies the assertion syntax (the syntax of the assertion
+ value) by object identifier; and
+ <extensions> describe extensions.
+
+4.1.4. Matching Rule Uses
+
+ A matching rule use lists the attribute types that are suitable for
+ use with an extensibleMatch search filter.
+
+ Matching rule use descriptions are written according to the following
+ ABNF:
+
+ MatchingRuleUseDescription = LPAREN WSP
+ numericoid ; object identifier
+ [ SP "NAME" SP qdescrs ] ; short names (descriptors)
+ [ SP "DESC" SP qdstring ] ; description
+ [ SP "OBSOLETE" ] ; not active
+ SP "APPLIES" SP oids ; attribute types
+ extensions WSP RPAREN ; extensions
+
+
+
+
+
+Zeilenga Standards Track [Page 27]
+
+RFC 4512 LDAP Models June 2006
+
+
+ where:
+ <numericoid> is the object identifier of the matching rule
+ associated with this matching rule use description;
+ NAME <qdescrs> are short names (descriptors) identifying this
+ matching rule use;
+ DESC <qdstring> is a short descriptive string;
+ OBSOLETE indicates this matching rule use is not active;
+ APPLIES provides a list of attribute types the matching rule
+ applies to; and
+ <extensions> describe extensions.
+
+4.1.5. LDAP Syntaxes
+
+ LDAP Syntaxes of (attribute and assertion) values are described in
+ terms of ASN.1 [X.680] and, optionally, have an octet string encoding
+ known as the LDAP-specific encoding. Commonly, the LDAP-specific
+ encoding is constrained to a string of Unicode [Unicode] characters
+ in UTF-8 [RFC3629] form.
+
+ Each LDAP syntax is identified by an object identifier (OID).
+
+ LDAP syntax definitions are written according to the ABNF:
+
+ SyntaxDescription = LPAREN WSP
+ numericoid ; object identifier
+ [ SP "DESC" SP qdstring ] ; description
+ extensions WSP RPAREN ; extensions
+
+ where:
+ <numericoid> is the object identifier assigned to this LDAP syntax;
+ DESC <qdstring> is a short descriptive string; and
+ <extensions> describe extensions.
+
+4.1.6. DIT Content Rules
+
+ A DIT content rule is a "rule governing the content of entries of a
+ particular structural object class" [X.501].
+
+ For DIT entries of a particular structural object class, a DIT
+ content rule specifies which auxiliary object classes the entries are
+ allowed to belong to and which additional attributes (by type) are
+ required, allowed, or not allowed to appear in the entries.
+
+ The list of precluded attributes cannot include any attribute listed
+ as mandatory in the rule, the structural object class, or any of the
+ allowed auxiliary object classes.
+
+
+
+
+
+Zeilenga Standards Track [Page 28]
+
+RFC 4512 LDAP Models June 2006
+
+
+ Each content rule is identified by the object identifier, as well as
+ any short names (descriptors), of the structural object class it
+ applies to.
+
+ An entry may only belong to auxiliary object classes listed in the
+ governing content rule.
+
+ An entry must contain all attributes required by the object classes
+ the entry belongs to as well as all attributes required by the
+ governing content rule.
+
+ An entry may contain any non-precluded attributes allowed by the
+ object classes the entry belongs to as well as all attributes allowed
+ by the governing content rule.
+
+ An entry cannot include any attribute precluded by the governing
+ content rule.
+
+ An entry is governed by (if present and active in the subschema) the
+ DIT content rule that applies to the structural object class of the
+ entry (see Section 2.4.2). If no active rule is present for the
+ entry's structural object class, the entry's content is governed by
+ the structural object class (and possibly other aspects of user and
+ system schema). DIT content rules for superclasses of the structural
+ object class of an entry are not applicable to that entry.
+
+ DIT content rule descriptions are written according to the ABNF:
+
+ DITContentRuleDescription = LPAREN WSP
+ numericoid ; object identifier
+ [ SP "NAME" SP qdescrs ] ; short names (descriptors)
+ [ SP "DESC" SP qdstring ] ; description
+ [ SP "OBSOLETE" ] ; not active
+ [ SP "AUX" SP oids ] ; auxiliary object classes
+ [ SP "MUST" SP oids ] ; attribute types
+ [ SP "MAY" SP oids ] ; attribute types
+ [ SP "NOT" SP oids ] ; attribute types
+ extensions WSP RPAREN ; extensions
+
+ where:
+ <numericoid> is the object identifier of the structural object
+ class associated with this DIT content rule;
+ NAME <qdescrs> are short names (descriptors) identifying this DIT
+ content rule;
+ DESC <qdstring> is a short descriptive string;
+ OBSOLETE indicates this DIT content rule use is not active;
+ AUX specifies a list of auxiliary object classes that entries
+ subject to this DIT content rule may belong to;
+
+
+
+Zeilenga Standards Track [Page 29]
+
+RFC 4512 LDAP Models June 2006
+
+
+ MUST, MAY, and NOT specify lists of attribute types that are
+ required, allowed, or precluded, respectively, from appearing
+ in entries subject to this DIT content rule; and
+ <extensions> describe extensions.
+
+4.1.7. DIT Structure Rules and Name Forms
+
+ It is sometimes desirable to regulate where object and alias entries
+ can be placed in the DIT and how they can be named based upon their
+ structural object class.
+
+4.1.7.1. DIT Structure Rules
+
+ A DIT structure rule is a "rule governing the structure of the DIT by
+ specifying a permitted superior to subordinate entry relationship. A
+ structure rule relates a name form, and therefore a structural object
+ class, to superior structure rules. This permits entries of the
+ structural object class identified by the name form to exist in the
+ DIT as subordinates to entries governed by the indicated superior
+ structure rules" [X.501].
+
+ DIT structure rule descriptions are written according to the ABNF:
+
+ DITStructureRuleDescription = LPAREN WSP
+ ruleid ; rule identifier
+ [ SP "NAME" SP qdescrs ] ; short names (descriptors)
+ [ SP "DESC" SP qdstring ] ; description
+ [ SP "OBSOLETE" ] ; not active
+ SP "FORM" SP oid ; NameForm
+ [ SP "SUP" ruleids ] ; superior rules
+ extensions WSP RPAREN ; extensions
+
+ ruleids = ruleid / ( LPAREN WSP ruleidlist WSP RPAREN )
+ ruleidlist = ruleid *( SP ruleid )
+ ruleid = number
+
+ where:
+ <ruleid> is the rule identifier of this DIT structure rule;
+ NAME <qdescrs> are short names (descriptors) identifying this DIT
+ structure rule;
+ DESC <qdstring> is a short descriptive string;
+ OBSOLETE indicates this DIT structure rule use is not active;
+ FORM is specifies the name form associated with this DIT structure
+ rule;
+ SUP identifies superior rules (by rule id); and
+ <extensions> describe extensions.
+
+
+
+
+
+Zeilenga Standards Track [Page 30]
+
+RFC 4512 LDAP Models June 2006
+
+
+ If no superior rules are identified, the DIT structure rule applies
+ to an autonomous administrative point (e.g., the root vertex of the
+ subtree controlled by the subschema) [X.501].
+
+4.1.7.2. Name Forms
+
+ A name form "specifies a permissible RDN for entries of a particular
+ structural object class. A name form identifies a named object class
+ and one or more attribute types to be used for naming (i.e., for the
+ RDN). Name forms are primitive pieces of specification used in the
+ definition of DIT structure rules" [X.501].
+
+ Each name form indicates the structural object class to be named, a
+ set of required attribute types, and a set of allowed attribute
+ types. A particular attribute type cannot be in both sets.
+
+ Entries governed by the form must be named using a value from each
+ required attribute type and zero or more values from the allowed
+ attribute types.
+
+ Each name form is identified by an object identifier (OID) and,
+ optionally, one or more short names (descriptors).
+
+ Name form descriptions are written according to the ABNF:
+
+ NameFormDescription = LPAREN WSP
+ numericoid ; object identifier
+ [ SP "NAME" SP qdescrs ] ; short names (descriptors)
+ [ SP "DESC" SP qdstring ] ; description
+ [ SP "OBSOLETE" ] ; not active
+ SP "OC" SP oid ; structural object class
+ SP "MUST" SP oids ; attribute types
+ [ SP "MAY" SP oids ] ; attribute types
+ extensions WSP RPAREN ; extensions
+
+ where:
+ <numericoid> is object identifier that identifies this name form;
+ NAME <qdescrs> are short names (descriptors) identifying this name
+ form;
+ DESC <qdstring> is a short descriptive string;
+ OBSOLETE indicates this name form is not active;
+ OC identifies the structural object class this rule applies to,
+ MUST and MAY specify the sets of required and allowed,
+ respectively, naming attributes for this name form; and
+ <extensions> describe extensions.
+
+ All attribute types in the required ("MUST") and allowed ("MAY")
+ lists shall be different.
+
+
+
+Zeilenga Standards Track [Page 31]
+
+RFC 4512 LDAP Models June 2006
+
+
+4.2. Subschema Subentries
+
+ Subschema (sub)entries are used for administering information about
+ the directory schema. A single subschema (sub)entry contains all
+ schema definitions (see Section 4.1) used by entries in a particular
+ part of the directory tree.
+
+ Servers that follow X.500(93) models SHOULD implement subschema using
+ the X.500 subschema mechanisms (as detailed in Section 12 of
+ [X.501]), so these are not ordinary object entries but subentries
+ (see Section 3.2). LDAP clients SHOULD NOT assume that servers
+ implement any of the other aspects of X.500 subschema.
+
+ Servers MAY allow subschema modification. Procedures for subschema
+ modification are discussed in Section 14.5 of [X.501].
+
+ A server that masters entries and permits clients to modify these
+ entries SHALL implement and provide access to these subschema
+ (sub)entries including providing a 'subschemaSubentry' attribute in
+ each modifiable entry. This is so clients may discover the
+ attributes and object classes that are permitted to be present. It
+ is strongly RECOMMENDED that all other servers implement this as
+ well.
+
+ The value of the 'subschemaSubentry' attribute is the name of the
+ subschema (sub)entry holding the subschema controlling the entry.
+
+ ( 2.5.18.10 NAME 'subschemaSubentry'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ SINGLE-VALUE NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ The 'distinguishedNameMatch' matching rule and the DistinguishedName
+ (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
+
+ Subschema is held in (sub)entries belonging to the subschema
+ auxiliary object class.
+
+ ( 2.5.20.1 NAME 'subschema' AUXILIARY
+ MAY ( dITStructureRules $ nameForms $ ditContentRules $
+ objectClasses $ attributeTypes $ matchingRules $
+ matchingRuleUse ) )
+
+ The 'ldapSyntaxes' operational attribute may also be present in
+ subschema entries.
+
+
+
+
+
+Zeilenga Standards Track [Page 32]
+
+RFC 4512 LDAP Models June 2006
+
+
+ Servers MAY provide additional attributes (described in other
+ documents) in subschema (sub)entries.
+
+ Servers SHOULD provide the attributes 'createTimestamp' and
+ 'modifyTimestamp' in subschema (sub)entries, in order to allow
+ clients to maintain their caches of schema information.
+
+ The following subsections provide attribute type definitions for each
+ of schema definition attribute types.
+
+4.2.1. 'objectClasses'
+
+ This attribute holds definitions of object classes.
+
+ ( 2.5.21.6 NAME 'objectClasses'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.37
+ USAGE directoryOperation )
+
+ The 'objectIdentifierFirstComponentMatch' matching rule and the
+ ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) syntax are
+ defined in [RFC4517].
+
+4.2.2. 'attributeTypes'
+
+ This attribute holds definitions of attribute types.
+
+ ( 2.5.21.5 NAME 'attributeTypes'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.3
+ USAGE directoryOperation )
+
+ The 'objectIdentifierFirstComponentMatch' matching rule and the
+ AttributeTypeDescription (1.3.6.1.4.1.1466.115.121.1.3) syntax are
+ defined in [RFC4517].
+
+4.2.3. 'matchingRules'
+
+ This attribute holds definitions of matching rules.
+
+ ( 2.5.21.4 NAME 'matchingRules'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.30
+ USAGE directoryOperation )
+
+ The 'objectIdentifierFirstComponentMatch' matching rule and the
+ MatchingRuleDescription (1.3.6.1.4.1.1466.115.121.1.30) syntax are
+ defined in [RFC4517].
+
+
+
+Zeilenga Standards Track [Page 33]
+
+RFC 4512 LDAP Models June 2006
+
+
+4.2.4 'matchingRuleUse'
+
+ This attribute holds definitions of matching rule uses.
+
+ ( 2.5.21.8 NAME 'matchingRuleUse'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.31
+ USAGE directoryOperation )
+
+ The 'objectIdentifierFirstComponentMatch' matching rule and the
+ MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) syntax are
+ defined in [RFC4517].
+
+4.2.5. 'ldapSyntaxes'
+
+ This attribute holds definitions of LDAP syntaxes.
+
+ ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.54
+ USAGE directoryOperation )
+
+ The 'objectIdentifierFirstComponentMatch' matching rule and the
+ SyntaxDescription (1.3.6.1.4.1.1466.115.121.1.54) syntax are defined
+ in [RFC4517].
+
+4.2.6. 'dITContentRules'
+
+ This attribute lists DIT Content Rules that are present in the
+ subschema.
+
+ ( 2.5.21.2 NAME 'dITContentRules'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.16
+ USAGE directoryOperation )
+
+ The 'objectIdentifierFirstComponentMatch' matching rule and the
+ DITContentRuleDescription (1.3.6.1.4.1.1466.115.121.1.16) syntax are
+ defined in [RFC4517].
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 34]
+
+RFC 4512 LDAP Models June 2006
+
+
+4.2.7. 'dITStructureRules'
+
+ This attribute lists DIT Structure Rules that are present in the
+ subschema.
+
+ ( 2.5.21.1 NAME 'dITStructureRules'
+ EQUALITY integerFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.17
+ USAGE directoryOperation )
+
+ The 'integerFirstComponentMatch' matching rule and the
+ DITStructureRuleDescription (1.3.6.1.4.1.1466.115.121.1.17) syntax
+ are defined in [RFC4517].
+
+4.2.8 'nameForms'
+
+ This attribute lists Name Forms that are in force.
+
+ ( 2.5.21.7 NAME 'nameForms'
+ EQUALITY objectIdentifierFirstComponentMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.35
+ USAGE directoryOperation )
+
+ The 'objectIdentifierFirstComponentMatch' matching rule and the
+ NameFormDescription (1.3.6.1.4.1.1466.115.121.1.35) syntax are
+ defined in [RFC4517].
+
+4.3. 'extensibleObject' object class
+
+ The 'extensibleObject' auxiliary object class allows entries that
+ belong to it to hold any user attribute. The set of allowed
+ attribute types of this object class is implicitly the set of all
+ attribute types of userApplications usage.
+
+ ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
+ SUP top AUXILIARY )
+
+ The mandatory attributes of the other object classes of this entry
+ are still required to be present, and any precluded attributes are
+ still not allowed to be present.
+
+4.4. Subschema Discovery
+
+ To discover the DN of the subschema (sub)entry holding the subschema
+ controlling a particular entry, a client reads that entry's
+ 'subschemaSubentry' operational attribute. To read schema attributes
+ from the subschema (sub)entry, clients MUST issue a Search operation
+ [RFC4511] where baseObject is the DN of the subschema (sub)entry,
+
+
+
+Zeilenga Standards Track [Page 35]
+
+RFC 4512 LDAP Models June 2006
+
+
+ scope is baseObject, filter is "(objectClass=subschema)" [RFC4515],
+ and the attributes field lists the names of the desired schema
+ attributes (as they are operational). Note: the
+ "(objectClass=subschema)" filter allows LDAP servers that gateway to
+ X.500 to detect that subentry information is being requested.
+
+ Clients SHOULD NOT assume that a published subschema is complete,
+ that the server supports all of the schema elements it publishes, or
+ that the server does not support an unpublished element.
+
+5. DSA (Server) Informational Model
+
+ The LDAP protocol assumes there are one or more servers that jointly
+ provide access to a Directory Information Tree (DIT). The server
+ holding the original information is called the "master" (for that
+ information). Servers that hold copies of the original information
+ are referred to as "shadowing" or "caching" servers.
+
+
+ As defined in [X.501]:
+
+ context prefix: The sequence of RDNs leading from the Root of the
+ DIT to the initial vertex of a naming context; corresponds to
+ the distinguished name of that vertex.
+
+ naming context: A subtree of entries held in a single master DSA.
+
+ That is, a naming context is the largest collection of entries,
+ starting at an entry that is mastered by a particular server, and
+ including all its subordinates and their subordinates, down to the
+ entries that are mastered by different servers. The context prefix
+ is the name of the initial entry.
+
+ The root of the DIT is a DSA-specific Entry (DSE) and not part of any
+ naming context (or any subtree); each server has different attribute
+ values in the root DSE.
+
+5.1. Server-Specific Data Requirements
+
+ An LDAP server SHALL provide information about itself and other
+ information that is specific to each server. This is represented as
+ a group of attributes located in the root DSE, which is named with
+ the DN with zero RDNs (whose [RFC4514] representation is as the
+ zero-length string).
+
+ These attributes are retrievable, subject to access control and other
+ restrictions, if a client performs a Search operation [RFC4511] with
+ an empty baseObject, scope of baseObject, the filter
+
+
+
+Zeilenga Standards Track [Page 36]
+
+RFC 4512 LDAP Models June 2006
+
+
+ "(objectClass=*)" [RFC4515], and the attributes field listing the
+ names of the desired attributes. It is noted that root DSE
+ attributes are operational and, like other operational attributes,
+ are not returned in search requests unless requested by name.
+
+ The root DSE SHALL NOT be included if the client performs a subtree
+ search starting from the root.
+
+ Servers may allow clients to modify attributes of the root DSE, where
+ appropriate.
+
+ The following attributes of the root DSE are defined below.
+ Additional attributes may be defined in other documents.
+
+ - altServer: alternative servers;
+
+ - namingContexts: naming contexts;
+
+ - supportedControl: recognized LDAP controls;
+
+ - supportedExtension: recognized LDAP extended operations;
+
+ - supportedFeatures: recognized LDAP features;
+
+ - supportedLDAPVersion: LDAP versions supported; and
+
+ - supportedSASLMechanisms: recognized Simple Authentication and
+ Security Layers (SASL) [RFC4422] mechanisms.
+
+ The values provided for these attributes may depend on session-
+ specific and other factors. For example, a server supporting the
+ SASL EXTERNAL mechanism might only list "EXTERNAL" when the client's
+ identity has been established by a lower level. See [RFC4513].
+
+ The root DSE may also include a 'subschemaSubentry' attribute. If it
+ does, the attribute refers to the subschema (sub)entry holding the
+ schema controlling the root DSE. Clients SHOULD NOT assume that this
+ subschema (sub)entry controls other entries held by the server.
+ General subschema discovery procedures are provided in Section 4.4.
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 37]
+
+RFC 4512 LDAP Models June 2006
+
+
+5.1.1. 'altServer'
+
+ The 'altServer' attribute lists URIs referring to alternative servers
+ that may be contacted when this server becomes unavailable. URIs for
+ servers implementing the LDAP are written according to [RFC4516].
+ Other kinds of URIs may be provided. If the server does not know of
+ any other servers that could be used, this attribute will be absent.
+ Clients may cache this information in case their preferred server
+ later becomes unavailable.
+
+ ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
+ USAGE dSAOperation )
+
+ The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax is defined in
+ [RFC4517].
+
+5.1.2. 'namingContexts'
+
+ The 'namingContexts' attribute lists the context prefixes of the
+ naming contexts the server masters or shadows (in part or in whole).
+ If the server is a first-level DSA [X.501], it should list (in
+ addition) an empty string (indicating the root of the DIT). If the
+ server does not master or shadow any information (e.g., it is an LDAP
+ gateway to a public X.500 directory) this attribute will be absent.
+ If the server believes it masters or shadows the entire directory,
+ the attribute will have a single value, and that value will be the
+ empty string (indicating the root of the DIT).
+
+ This attribute may be used, for example, to select a suitable entry
+ name for subsequent operations with this server.
+
+ ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+ USAGE dSAOperation )
+
+ The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax is
+ defined in [RFC4517].
+
+5.1.3. 'supportedControl'
+
+ The 'supportedControl' attribute lists object identifiers identifying
+ the request controls [RFC4511] the server supports. If the server
+ does not support any request controls, this attribute will be absent.
+ Object identifiers identifying response controls need not be listed.
+
+ Procedures for registering object identifiers used to discovery of
+ protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].
+
+
+
+Zeilenga Standards Track [Page 38]
+
+RFC 4512 LDAP Models June 2006
+
+
+ ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ USAGE dSAOperation )
+
+ The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
+ defined in [RFC4517].
+
+5.1.4. 'supportedExtension'
+
+ The 'supportedExtension' attribute lists object identifiers
+ identifying the extended operations [RFC4511] that the server
+ supports. If the server does not support any extended operations,
+ this attribute will be absent.
+
+ An extended operation generally consists of an extended request and
+ an extended response but may also include other protocol data units
+ (such as intermediate responses). The object identifier assigned to
+ the extended request is used to identify the extended operation.
+ Other object identifiers used in the extended operation need not be
+ listed as values of this attribute.
+
+ Procedures for registering object identifiers used to discovery of
+ protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].
+
+ ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ USAGE dSAOperation )
+
+ The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
+ defined in [RFC4517].
+
+5.1.5. 'supportedFeatures'
+
+ The 'supportedFeatures' attribute lists object identifiers
+ identifying elective features that the server supports. If the
+ server does not support any discoverable elective features, this
+ attribute will be absent.
+
+ ( 1.3.6.1.4.1.4203.1.3.5 NAME 'supportedFeatures'
+ EQUALITY objectIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
+ USAGE dSAOperation )
+
+ Procedures for registering object identifiers used to discovery of
+ protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].
+
+ The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax and
+ objectIdentifierMatch matching rule are defined in [RFC4517].
+
+
+
+Zeilenga Standards Track [Page 39]
+
+RFC 4512 LDAP Models June 2006
+
+
+5.1.6. 'supportedLDAPVersion'
+
+ The 'supportedLDAPVersion' attribute lists the versions of LDAP that
+ the server supports.
+
+ ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
+ USAGE dSAOperation )
+
+ The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in
+ [RFC4517].
+
+5.1.7. 'supportedSASLMechanisms'
+
+ The 'supportedSASLMechanisms' attribute lists the SASL mechanisms
+ [RFC4422] that the server recognizes and/or supports [RFC4513]. The
+ contents of this attribute may depend on the current session state.
+ If the server does not support any SASL mechanisms, this attribute
+ will not be present.
+
+ ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
+ USAGE dSAOperation )
+
+ The Directory String (1.3.6.1.4.1.1466.115.121.1.15) syntax is
+ defined in [RFC4517].
+
+6. Other Considerations
+
+6.1. Preservation of User Information
+
+ Syntaxes may be defined that have specific value and/or value form
+ (representation) preservation requirements. For example, a syntax
+ containing digitally signed data can mandate that the server preserve
+ both the value and form of value presented to ensure that the
+ signature is not invalidated.
+
+ Where such requirements have not been explicitly stated, servers
+ SHOULD preserve the value of user information but MAY return the
+ value in a different form. And where a server is unable (or
+ unwilling) to preserve the value of user information, the server
+ SHALL ensure that an equivalent value (per Section 2.3) is returned.
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 40]
+
+RFC 4512 LDAP Models June 2006
+
+
+6.2. Short Names
+
+ Short names, also known as descriptors, are used as more readable
+ aliases for object identifiers and are used to identify various
+ schema elements. However, it is not expected that LDAP
+ implementations with human user interface would display these short
+ names (or the object identifiers they refer to) to the user.
+ Instead, they would most likely be performing translations (such as
+ expressing the short name in one of the local national languages).
+ For example, the short name "st" (stateOrProvinceName) might be
+ displayed to a German-speaking user as "Land".
+
+ The same short name might have different meaning in different
+ subschemas, and, within a particular subschema, the same short name
+ might refer to different object identifiers each identifying a
+ different kind of schema element.
+
+ Implementations MUST be prepared that the same short name might be
+ used in a subschema to refer to the different kinds of schema
+ elements. That is, there might be an object class 'x-fubar' and an
+ attribute type 'x-fubar' in a subschema.
+
+ Implementations MUST be prepared that the same short name might be
+ used in the different subschemas to refer to the different schema
+ elements. That is, there might be two matching rules 'x-fubar', each
+ in different subschemas.
+
+ Procedures for registering short names (descriptors) are detailed in
+ BCP 64, RFC 4520 [RFC4520].
+
+6.3. Cache and Shadowing
+
+ Some servers may hold cache or shadow copies of entries, which can be
+ used to answer search and comparison queries, but will return
+ referrals or contact other servers if modification operations are
+ requested. Servers that perform shadowing or caching MUST ensure
+ that they do not violate any access control constraints placed on the
+ data by the originating server.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 41]
+
+RFC 4512 LDAP Models June 2006
+
+
+7. Implementation Guidelines
+
+7.1. Server Guidelines
+
+ Servers MUST recognize all names of attribute types and object
+ classes defined in this document but, unless stated otherwise, need
+ not support the associated functionality. Servers SHOULD recognize
+ all the names of attribute types and object classes defined in
+ Section 3 and 4, respectively, of [RFC4519].
+
+ Servers MUST ensure that entries conform to user and system schema
+ rules or other data model constraints.
+
+ Servers MAY support DIT Content Rules. Servers MAY support DIT
+ Structure Rules and Name Forms.
+
+ Servers MAY support alias entries.
+
+ Servers MAY support the 'extensibleObject' object class.
+
+ Servers MAY support subentries. If so, they MUST do so in accordance
+ with [RFC3672]. Servers that do not support subentries SHOULD use
+ object entries to mimic subentries as detailed in Section 3.2.
+
+ Servers MAY implement additional schema elements. Servers SHOULD
+ provide definitions of all schema elements they support in subschema
+ (sub)entries.
+
+7.2. Client Guidelines
+
+ In the absence of prior agreements with servers, clients SHOULD NOT
+ assume that servers support any particular schema elements beyond
+ those referenced in Section 7.1. The client can retrieve subschema
+ information as described in Section 4.4.
+
+ Clients MUST NOT display or attempt to decode a value as ASN.1 if the
+ value's syntax is not known. Clients MUST NOT assume the LDAP-
+ specific string encoding is restricted to a UTF-8 encoded string of
+ Unicode characters or any particular subset of Unicode (such as a
+ printable subset) unless such restriction is explicitly stated.
+ Clients SHOULD NOT send attribute values in a request that are not
+ valid according to the syntax defined for the attributes.
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 42]
+
+RFC 4512 LDAP Models June 2006
+
+
+8. Security Considerations
+
+ Attributes of directory entries are used to provide descriptive
+ information about the real-world objects they represent, which can be
+ people, organizations, or devices. Most countries have privacy laws
+ regarding the publication of information about people.
+
+ General security considerations for accessing directory information
+ with LDAP are discussed in [RFC4511] and [RFC4513].
+
+9. IANA Considerations
+
+ The Internet Assigned Numbers Authority (IANA) has updated the LDAP
+ descriptors registry as indicated in the following template:
+
+ Subject: Request for LDAP Descriptor Registration Update
+ Descriptor (short name): see comment
+ Object Identifier: see comment
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Usage: see comment
+ Specification: RFC 4512
+ Author/Change Controller: IESG
+ Comments:
+
+ The following descriptors (short names) has been added to
+ the registry.
+
+ NAME Type OID
+ ------------------------ ---- -----------------
+ governingStructureRule A 2.5.21.10
+ structuralObjectClass A 2.5.21.9
+
+ The following descriptors (short names) have been updated to
+ refer to this RFC.
+
+ NAME Type OID
+ ------------------------ ---- -----------------
+ alias O 2.5.6.1
+ aliasedObjectName A 2.5.4.1
+ altServer A 1.3.6.1.4.1.1466.101.120.6
+ attributeTypes A 2.5.21.5
+ createTimestamp A 2.5.18.1
+ creatorsName A 2.5.18.3
+ dITContentRules A 2.5.21.2
+ dITStructureRules A 2.5.21.1
+ extensibleObject O 1.3.6.1.4.1.1466.101.120.111
+ ldapSyntaxes A 1.3.6.1.4.1.1466.101.120.16
+
+
+
+Zeilenga Standards Track [Page 43]
+
+RFC 4512 LDAP Models June 2006
+
+
+ matchingRuleUse A 2.5.21.8
+ matchingRules A 2.5.21.4
+ modifiersName A 2.5.18.4
+ modifyTimestamp A 2.5.18.2
+ nameForms A 2.5.21.7
+ namingContexts A 1.3.6.1.4.1.1466.101.120.5
+ objectClass A 2.5.4.0
+ objectClasses A 2.5.21.6
+ subschema O 2.5.20.1
+ subschemaSubentry A 2.5.18.10
+ supportedControl A 1.3.6.1.4.1.1466.101.120.13
+ supportedExtension A 1.3.6.1.4.1.1466.101.120.7
+ supportedFeatures A 1.3.6.1.4.1.4203.1.3.5
+ supportedLDAPVersion A 1.3.6.1.4.1.1466.101.120.15
+ supportedSASLMechanisms A 1.3.6.1.4.1.1466.101.120.14
+ top O 2.5.6.0
+
+10. Acknowledgements
+
+ This document is based in part on RFC 2251 by M. Wahl, T. Howes, and
+ S. Kille; RFC 2252 by M. Wahl, A. Coulbeck, T. Howes, S. Kille; and
+ RFC 2556 by M. Wahl, all products of the IETF Access, Searching and
+ Indexing of Directories (ASID) Working Group. This document is also
+ based in part on "The Directory: Models" [X.501], a product of the
+ International Telephone Union (ITU). Additional text was borrowed
+ from RFC 2253 by M. Wahl, T. Howes, and S. Kille.
+
+ This document is a product of the IETF LDAP Revision (LDAPBIS)
+ Working Group.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 44]
+
+RFC 4512 LDAP Models June 2006
+
+
+11. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003.
+
+ [RFC3671] Zeilenga, K., "Collective Attributes in the Lightweight
+ Directory Access Protocol (LDAP)", RFC 3671, December
+ 2003.
+
+ [RFC3672] Zeilenga, K., "Subentries in the Lightweight Directory
+ Access Protocol (LDAP)", RFC 3672, December 2003.
+
+ [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 4234, October 2005.
+
+ [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
+ Authentication and Security Layer (SASL)", RFC 4422,
+ June 2006.
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Technical Specification Road Map", RFC
+ 4510, June 2006.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4513] Harrison, R., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Authentication Methods and Security
+ Mechanisms", RFC 4513, June 2006.
+
+ [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access
+ Protocol (LDAP): String Representation of Distinguished
+ Names", RFC 4514, June 2006.
+
+ [RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory
+ Access Protocol (LDAP): String Representation of Search
+ Filters", RFC 4515, June 2006.
+
+ [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory
+ Access Protocol (LDAP): Uniform Resource Locator", RFC
+ 4516, June 2006.
+
+ [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Syntaxes and Matching Rules", RFC 4517, June
+ 2006.
+
+
+
+Zeilenga Standards Track [Page 45]
+
+RFC 4512 LDAP Models June 2006
+
+
+ [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Schema for User Applications", RFC
+ 4519, June 2006.
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
+ (IANA) Considerations for the Lightweight Directory
+ Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+ [Unicode] The Unicode Consortium, "The Unicode Standard, Version
+ 3.2.0" is defined by "The Unicode Standard, Version
+ 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
+ 61633-5), as amended by the "Unicode Standard Annex
+ #27: Unicode 3.1"
+ (http://www.unicode.org/reports/tr27/) and by the
+ "Unicode Standard Annex #28: Unicode 3.2"
+ (http://www.unicode.org/reports/tr28/).
+
+ [X.500] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory -- Overview of concepts, models and
+ services," X.500(1993) (also ISO/IEC 9594-1:1994).
+
+ [X.501] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory -- Models," X.501(1993) (also ISO/IEC 9594-
+ 2:1994).
+
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 46]
+
+RFC 4512 LDAP Models June 2006
+
+
+Appendix A. Changes
+
+ This appendix is non-normative.
+
+ This document amounts to nearly a complete rewrite of portions of RFC
+ 2251, RFC 2252, and RFC 2256. This rewrite was undertaken to improve
+ overall clarity of technical specification. This appendix provides a
+ summary of substantive changes made to the portions of these
+ documents incorporated into this document. Readers should consult
+ [RFC4510], [RFC4511], [RFC4517], and [RFC4519] for summaries of
+ remaining portions of these documents.
+
+A.1. Changes to RFC 2251
+
+ This document incorporates from RFC 2251, Sections 3.2 and 3.4, and
+ portions of Sections 4 and 6 as summarized below.
+
+A.1.1. Section 3.2 of RFC 2251
+
+ Section 3.2 of RFC 2251 provided a brief introduction to the X.500
+ data model, as used by LDAP. The previous specification relied on
+ [X.501] but lacked clarity in how X.500 models are adapted for use by
+ LDAP. This document describes the X.500 data models, as used by
+ LDAP, in greater detail, especially in areas where adaptation is
+ needed.
+
+ Section 3.2.1 of RFC 2251 described an attribute as "a type with one
+ or more associated values". In LDAP, an attribute is better
+ described as an attribute description, a type with zero or more
+ options, and one or more associated values.
+
+ Section 3.2.2 of RFC 2251 mandated that subschema subentries contain
+ objectClasses and attributeTypes attributes, yet X.500(93) treats
+ these attributes as optional. While generally all implementations
+ that support X.500(93) subschema mechanisms will provide both of
+ these attributes, it is not absolutely required for interoperability
+ that all servers do. The mandate was removed for consistency with
+ X.500(93). The subschema discovery mechanism was also clarified to
+ indicate that subschema controlling an entry is obtained by reading
+ the (sub)entry referred to by that entry's 'subschemaSubentry'
+ attribute.
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 47]
+
+RFC 4512 LDAP Models June 2006
+
+
+A.1.2. Section 3.4 of RFC 2251
+
+ Section 3.4 of RFC 2251 provided "Server-specific Data Requirements".
+ This material, with changes, was incorporated in Section 5.1 of this
+ document.
+
+ Changes:
+
+ - Clarify that attributes of the root DSE are subject to "other
+ restrictions" in addition to access controls.
+
+ - Clarify that only recognized extended requests need to be
+ enumerated 'supportedExtension'.
+
+ - Clarify that only recognized request controls need to be enumerated
+ 'supportedControl'.
+
+ - Clarify that root DSE attributes are operational and, like other
+ operational attributes, will not be returned in search requests
+ unless requested by name.
+
+ - Clarify that not all root DSE attributes are user modifiable.
+
+ - Remove inconsistent text regarding handling of the
+ 'subschemaSubentry' attribute within the root DSE. The previous
+ specification stated that the 'subschemaSubentry' attribute held in
+ the root DSE referred to "subschema entries (or subentries) known
+ by this server". This is inconsistent with the attribute's
+ intended use as well as its formal definition as a single valued
+ attribute [X.501]. It is also noted that a simple (possibly
+ incomplete) list of subschema (sub)entries is not terribly useful.
+ This document (in Section 5.1) specifies that the
+ 'subschemaSubentry' attribute of the root DSE refers to the
+ subschema controlling the root DSE. It is noted that the general
+ subschema discovery mechanism remains available (see Section 4.4 of
+ this document).
+
+A.1.3. Section 4 of RFC 2251
+
+ Portions of Section 4 of RFC 2251 detailing aspects of the
+ information model used by LDAP were incorporated in this document,
+ including:
+
+ - Restriction of distinguished values to attributes whose
+ descriptions have no options (from Section 4.1.3);
+
+
+
+
+
+
+Zeilenga Standards Track [Page 48]
+
+RFC 4512 LDAP Models June 2006
+
+
+ - Data model aspects of Attribute Types (from Section 4.1.4),
+ Attribute Descriptions (from 4.1.5), Attribute (from 4.1.8),
+ Matching Rule Identifier (from 4.1.9); and
+
+ - User schema requirements (from Sections 4.1.6, 4.5.1, and 4.7).
+
+ Clarifications to these portions include:
+
+ - Subtyping and AttributeDescriptions with options.
+
+A.1.4. Section 6 of RFC 2251
+
+ The Section 6.1 and the second paragraph of Section 6.2 of RFC 2251
+ where incorporated into this document.
+
+A.2. Changes to RFC 2252
+
+ This document incorporates Sections 4, 5, and 7 from RFC 2252.
+
+A.2.1. Section 4 of RFC 2252
+
+ The specification was updated to use Augmented BNF [RFC4234]. The
+ string representation of an OBJECT IDENTIFIER was tightened to
+ disallow leading zeros as described in RFC 2252.
+
+ The <descr> syntax was changed to disallow semicolon (U+003B)
+ characters in order to appear to be consistent its natural language
+ specification "descr is the syntactic representation of an object
+ descriptor, which consists of letters and digits, starting with a
+ letter". In a related change, the statement "an AttributeDescription
+ can be used as the value in a NAME part of an
+ AttributeTypeDescription" was deleted. RFC 2252 provided no
+ specification of the semantics of attribute options appearing in NAME
+ fields.
+
+ RFC 2252 stated that the <descr> form of <oid> SHOULD be preferred
+ over the <numericoid> form. However, <descr> form can be ambiguous.
+ To address this issue, the imperative was replaced with a statement
+ (in Section 1.4) that while the <descr> form is generally preferred,
+ <numericoid> should be used where an unambiguous <descr> is not
+ available. Additionally, an expanded discussion of descriptor issues
+ is in Section 6.2 ("Short Names").
+
+ The ABNF for a quoted string (qdstring) was updated to reflect
+ support for the escaping mechanism described in Section 4.3 of RFC
+ 2252.
+
+
+
+
+
+Zeilenga Standards Track [Page 49]
+
+RFC 4512 LDAP Models June 2006
+
+
+A.2.2. Section 5 of RFC 2252
+
+ Definitions of operational attributes provided in Section 5 of RFC
+ 2252 where incorporated into this document.
+
+ The 'namingContexts' description was clarified. A first-level DSA
+ should publish, in addition to other values, "" indicating the root
+ of the DIT.
+
+ The 'altServer' description was clarified. It may hold any URI.
+
+ The 'supportedExtension' description was clarified. A server need
+ only list the OBJECT IDENTIFIERs associated with the extended
+ requests of the extended operations it recognizes.
+
+ The 'supportedControl' description was clarified. A server need only
+ list the OBJECT IDENTIFIERs associated with the request controls it
+ recognizes.
+
+ Descriptions for the 'structuralObjectClass' and
+ 'governingStructureRule' operational attribute types were added.
+
+ The attribute definition of 'subschemaSubentry' was corrected to list
+ the terms SINGLE-VALUE and NO-USER-MODIFICATION in proper order.
+
+A.2.3. Section 7 of RFC 2252
+
+ Section 7 of RFC 2252 provides definitions of the 'subschema' and
+ 'extensibleObject' object classes. These definitions where
+ integrated into Section 4.2 and Section 4.3 of this document,
+ respectively. Section 7 of RFC 2252 also contained the object class
+ implementation requirement. This was incorporated into Section 7 of
+ this document.
+
+ The specification of 'extensibleObject' was clarified regarding how
+ it interacts with precluded attributes.
+
+A.3. Changes to RFC 2256
+
+ This document incorporates Sections 5.1, 5.2, 7.1, and 7.2 of RFC
+ 2256.
+
+ Section 5.1 of RFC 2256 provided the definition of the 'objectClass'
+ attribute type. This was integrated into Section 2.4.1 of this
+ document. The statement "One of the values is either 'top' or
+ 'alias'" was replaced with statement that one of the values is 'top'
+ as entries belonging to 'alias' also belong to 'top'.
+
+
+
+
+Zeilenga Standards Track [Page 50]
+
+RFC 4512 LDAP Models June 2006
+
+
+ Section 5.2 of RFC 2256 provided the definition of the
+ 'aliasedObjectName' attribute type. This was integrated into Section
+ 2.6.2 of this document.
+
+ Section 7.1 of RFC 2256 provided the definition of the 'top' object
+ class. This was integrated into Section 2.4.1 of this document.
+
+ Section 7.2 of RFC 2256 provided the definition of the 'alias' object
+ class. This was integrated into Section 2.6.1 of this document.
+
+A.4. Changes to RFC 3674
+
+ This document made no substantive change to the 'supportedFeatures'
+ technical specification provided in RFC 3674.
+
+Editor's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 51]
+
+RFC 4512 LDAP Models June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 52]
+
diff --git a/doc/rfc/rfc4513.txt b/doc/rfc/rfc4513.txt
new file mode 100644
index 0000000000000000000000000000000000000000..7e6e7eb4bd585b5adee45d6122028ddd9d8e9b25
--- /dev/null
+++ b/doc/rfc/rfc4513.txt
@@ -0,0 +1,1907 @@
+
+
+
+
+
+
+Network Working Group R. Harrison, Ed.
+Request for Comments: 4513 Novell, Inc.
+Obsoletes: 2251, 2829, 2830 June 2006
+Category: Standards Track
+
+
+ Lightweight Directory Access Protocol (LDAP):
+ Authentication Methods and Security Mechanisms
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This document describes authentication methods and security
+ mechanisms of the Lightweight Directory Access Protocol (LDAP). This
+ document details establishment of Transport Layer Security (TLS)
+ using the StartTLS operation.
+
+ This document details the simple Bind authentication method including
+ anonymous, unauthenticated, and name/password mechanisms and the
+ Simple Authentication and Security Layer (SASL) Bind authentication
+ method including the EXTERNAL mechanism.
+
+ This document discusses various authentication and authorization
+ states through which a session to an LDAP server may pass and the
+ actions that trigger these state changes.
+
+ This document, together with other documents in the LDAP Technical
+ Specification (see Section 1 of the specification's road map),
+ obsoletes RFC 2251, RFC 2829, and RFC 2830.
+
+
+
+
+
+
+
+
+
+
+
+Harrison Standards Track [Page 1]
+
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+Table of Contents
+
+ 1. Introduction ....................................................4
+ 1.1. Relationship to Other Documents ............................6
+ 1.2. Conventions ................................................6
+ 2. Implementation Requirements .....................................7
+ 3. StartTLS Operation ..............................................8
+ 3.1. TLS Establishment Procedures ..............................8
+ 3.1.1. StartTLS Request Sequencing .........................8
+ 3.1.2. Client Certificate ..................................9
+ 3.1.3. Server Identity Check ...............................9
+ 3.1.3.1. Comparison of DNS Names ...................10
+ 3.1.3.2. Comparison of IP Addresses ................11
+ 3.1.3.3. Comparison of Other subjectName Types .....11
+ 3.1.4. Discovery of Resultant Security Level ..............11
+ 3.1.5. Refresh of Server Capabilities Information .........11
+ 3.2. Effect of TLS on Authorization State .....................12
+ 3.3. TLS Ciphersuites ..........................................12
+ 4. Authorization State ............................................13
+ 5. Bind Operation .................................................14
+ 5.1. Simple Authentication Method ..............................14
+ 5.1.1. Anonymous Authentication Mechanism of Simple Bind ..14
+ 5.1.2. Unauthenticated Authentication Mechanism of
+ Simple Bind ........................................14
+ 5.1.3. Name/Password Authentication Mechanism of
+ Simple Bind ........................................15
+ 5.2. SASL Authentication Method ................................16
+ 5.2.1. SASL Protocol Profile ..............................16
+ 5.2.1.1. SASL Service Name for LDAP ................16
+ 5.2.1.2. SASL Authentication Initiation and
+ Protocol Exchange .........................16
+ 5.2.1.3. Optional Fields ...........................17
+ 5.2.1.4. Octet Where Negotiated Security
+ Layers Take Effect ........................18
+ 5.2.1.5. Determination of Supported SASL
+ Mechanisms ................................18
+ 5.2.1.6. Rules for Using SASL Layers ...............19
+ 5.2.1.7. Support for Multiple Authentications ......19
+ 5.2.1.8. SASL Authorization Identities .............19
+ 5.2.2. SASL Semantics within LDAP .........................20
+ 5.2.3. SASL EXTERNAL Authentication Mechanism .............20
+ 5.2.3.1. Implicit Assertion ........................21
+ 5.2.3.2. Explicit Assertion ........................21
+ 6. Security Considerations ........................................21
+ 6.1. General LDAP Security Considerations ......................21
+ 6.2. StartTLS Security Considerations ..........................22
+ 6.3. Bind Operation Security Considerations ....................23
+ 6.3.1. Unauthenticated Mechanism Security Considerations ..23
+
+
+
+Harrison Standards Track [Page 2]
+
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ 6.3.2. Name/Password Mechanism Security Considerations ....23
+ 6.3.3. Password-Related Security Considerations ...........23
+ 6.3.4. Hashed Password Security Considerations ............24
+ 6.4. SASL Security Considerations ..............................24
+ 6.5. Related Security Considerations ...........................25
+ 7. IANA Considerations ............................................25
+ 8. Acknowledgements ...............................................25
+ 9. Normative References ...........................................26
+ 10. Informative References ........................................27
+ Appendix A. Authentication and Authorization Concepts .............28
+ A.1. Access Control Policy .....................................28
+ A.2. Access Control Factors ....................................28
+ A.3. Authentication, Credentials, Identity .....................28
+ A.4. Authorization Identity ....................................29
+ Appendix B. Summary of Changes ....................................29
+ B.1. Changes Made to RFC 2251 ..................................30
+ B.1.1. Section 4.2.1 ("Sequencing of the Bind Request") ...30
+ B.1.2. Section 4.2.2 ("Authentication and Other Security
+ Services") .........................................30
+ B.2. Changes Made to RFC 2829 ..................................30
+ B.2.1. Section 4 ("Required security mechanisms") .........30
+ B.2.2. Section 5.1 ("Anonymous authentication
+ procedure") ........................................31
+ B.2.3. Section 6 ("Password-based authentication") ........31
+ B.2.4. Section 6.1 ("Digest authentication") ..............31
+ B.2.5. Section 6.2 ("'simple' authentication choice under
+ TLS encryption") ...................................31
+ B.2.6. Section 6.3 ("Other authentication choices with
+ TLS") ..............................................31
+ B.2.7. Section 7.1 ("Certificate-based authentication
+ with TLS") .........................................31
+ B.2.8. Section 8 ("Other mechanisms") .....................32
+ B.2.9. Section 9 ("Authorization Identity") ...............32
+ B.2.10. Section 10 ("TLS Ciphersuites") ...................32
+ B.3. Changes Made to RFC 2830 ..................................32
+ B.3.1. Section 3.6 ("Server Identity Check") ..............32
+ B.3.2. Section 3.7 ("Refresh of Server Capabilities
+ Information") ......................................33
+ B.3.3. Section 5 ("Effects of TLS on a Client's
+ Authorization Identity") ...........................33
+ B.3.4. Section 5.2 ("TLS Connection Closure Effects") .....33
+
+
+
+
+
+
+
+
+
+
+Harrison Standards Track [Page 3]
+
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+1. Introduction
+
+ The Lightweight Directory Access Protocol (LDAP) [RFC4510] is a
+ powerful protocol for accessing directories. It offers means of
+ searching, retrieving, and manipulating directory content and ways to
+ access a rich set of security functions.
+
+ It is vital that these security functions be interoperable among all
+ LDAP clients and servers on the Internet; therefore there has to be a
+ minimum subset of security functions that is common to all
+ implementations that claim LDAP conformance.
+
+ Basic threats to an LDAP directory service include (but are not
+ limited to):
+
+ (1) Unauthorized access to directory data via data-retrieval
+ operations.
+
+ (2) Unauthorized access to directory data by monitoring access of
+ others.
+
+ (3) Unauthorized access to reusable client authentication information
+ by monitoring access of others.
+
+ (4) Unauthorized modification of directory data.
+
+ (5) Unauthorized modification of configuration information.
+
+ (6) Denial of Service: Use of resources (commonly in excess) in a
+ manner intended to deny service to others.
+
+ (7) Spoofing: Tricking a user or client into believing that
+ information came from the directory when in fact it did not,
+ either by modifying data in transit or misdirecting the client's
+ transport connection. Tricking a user or client into sending
+ privileged information to a hostile entity that appears to be the
+ directory server but is not. Tricking a directory server into
+ believing that information came from a particular client when in
+ fact it came from a hostile entity.
+
+ (8) Hijacking: An attacker seizes control of an established protocol
+ session.
+
+ Threats (1), (4), (5), (6), (7), and (8) are active attacks. Threats
+ (2) and (3) are passive attacks.
+
+
+
+
+
+
+Harrison Standards Track [Page 4]
+
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ Threats (1), (4), (5), and (6) are due to hostile clients. Threats
+ (2), (3), (7), and (8) are due to hostile agents on the path between
+ client and server or hostile agents posing as a server, e.g., IP
+ spoofing.
+
+ LDAP offers the following security mechanisms:
+
+ (1) Authentication by means of the Bind operation. The Bind
+ operation provides a simple method that supports anonymous,
+ unauthenticated, and name/password mechanisms, and the Simple
+ Authentication and Security Layer (SASL) method, which supports a
+ wide variety of authentication mechanisms.
+
+ (2) Mechanisms to support vendor-specific access control facilities
+ (LDAP does not offer a standard access control facility).
+
+ (3) Data integrity service by means of security layers in Transport
+ Layer Security (TLS) or SASL mechanisms.
+
+ (4) Data confidentiality service by means of security layers in TLS
+ or SASL mechanisms.
+
+ (5) Server resource usage limitation by means of administrative
+ limits configured on the server.
+
+ (6) Server authentication by means of the TLS protocol or SASL
+ mechanisms.
+
+ LDAP may also be protected by means outside the LDAP protocol, e.g.,
+ with IP layer security [RFC4301].
+
+ Experience has shown that simply allowing implementations to pick and
+ choose the security mechanisms that will be implemented is not a
+ strategy that leads to interoperability. In the absence of mandates,
+ clients will continue to be written that do not support any security
+ function supported by the server, or worse, they will only support
+ mechanisms that provide inadequate security for most circumstances.
+
+ It is desirable to allow clients to authenticate using a variety of
+ mechanisms including mechanisms where identities are represented as
+ distinguished names [X.501][RFC4512], in string form [RFC4514], or as
+ used in different systems (e.g., simple user names [RFC4013]).
+ Because some authentication mechanisms transmit credentials in plain
+ text form, and/or do not provide data security services and/or are
+ subject to passive attacks, it is necessary to ensure secure
+ interoperability by identifying a mandatory-to-implement mechanism
+ for establishing transport-layer security services.
+
+
+
+
+Harrison Standards Track [Page 5]
+
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ The set of security mechanisms provided in LDAP and described in this
+ document is intended to meet the security needs for a wide range of
+ deployment scenarios and still provide a high degree of
+ interoperability among various LDAP implementations and deployments.
+
+1.1. Relationship to Other Documents
+
+ This document is an integral part of the LDAP Technical Specification
+ [RFC4510].
+
+ This document, together with [RFC4510], [RFC4511], and [RFC4512],
+ obsoletes RFC 2251 in its entirety. Sections 4.2.1 (portions) and
+ 4.2.2 of RFC 2251 are obsoleted by this document. Appendix B.1
+ summarizes the substantive changes made to RFC 2251 by this document.
+
+ This document obsoletes RFC 2829 in its entirety. Appendix B.2
+ summarizes the substantive changes made to RFC 2829 by this document.
+
+ Sections 2 and 4 of RFC 2830 are obsoleted by [RFC4511]. The
+ remainder of RFC 2830 is obsoleted by this document. Appendix B.3
+ summarizes the substantive changes made to RFC 2830 by this document.
+
+1.2. Conventions
+
+ The key words "MUST", "MUST NOT", "SHALL", "SHOULD", "SHOULD NOT",
+ "MAY", and "OPTIONAL" in this document are to be interpreted as
+ described in RFC 2119 [RFC2119].
+
+ The term "user" represents any human or application entity that is
+ accessing the directory using a directory client. A directory client
+ (or client) is also known as a directory user agent (DUA).
+
+ The term "transport connection" refers to the underlying transport
+ services used to carry the protocol exchange, as well as associations
+ established by these services.
+
+ The term "TLS layer" refers to TLS services used in providing
+ security services, as well as associations established by these
+ services.
+
+ The term "SASL layer" refers to SASL services used in providing
+ security services, as well as associations established by these
+ services.
+
+ The term "LDAP message layer" refers to the LDAP Message (PDU)
+ services used in providing directory services, as well as
+ associations established by these services.
+
+
+
+
+Harrison Standards Track [Page 6]
+
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ The term "LDAP session" refers to combined services (transport
+ connection, TLS layer, SASL layer, LDAP message layer) and their
+ associations.
+
+ In general, security terms in this document are used consistently
+ with the definitions provided in [RFC2828]. In addition, several
+ terms and concepts relating to security, authentication, and
+ authorization are presented in Appendix A of this document. While
+ the formal definition of these terms and concepts is outside the
+ scope of this document, an understanding of them is prerequisite to
+ understanding much of the material in this document. Readers who are
+ unfamiliar with security-related concepts are encouraged to review
+ Appendix A before reading the remainder of this document.
+
+2. Implementation Requirements
+
+ LDAP server implementations MUST support the anonymous authentication
+ mechanism of the simple Bind method (Section 5.1.1).
+
+ LDAP implementations that support any authentication mechanism other
+ than the anonymous authentication mechanism of the simple Bind method
+ MUST support the name/password authentication mechanism of the simple
+ Bind method (Section 5.1.3) and MUST be capable of protecting this
+ name/password authentication using TLS as established by the StartTLS
+ operation (Section 3).
+
+ Implementations SHOULD disallow the use of the name/password
+ authentication mechanism by default when suitable data security
+ services are not in place, and they MAY provide other suitable data
+ security services for use with this authentication mechanism.
+
+ Implementations MAY support additional authentication mechanisms.
+ Some of these mechanisms are discussed below.
+
+ LDAP server implementations SHOULD support client assertion of
+ authorization identity via the SASL EXTERNAL mechanism (Section
+ 5.2.3).
+
+ LDAP server implementations that support no authentication mechanism
+ other than the anonymous mechanism of the simple bind method SHOULD
+ support use of TLS as established by the StartTLS operation (Section
+ 3). (Other servers MUST support TLS per the second paragraph of this
+ section.)
+
+
+
+
+
+
+
+
+Harrison Standards Track [Page 7]
+
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ Implementations supporting TLS MUST support the
+ TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite and SHOULD support the
+ TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite. Support for the
+ latter ciphersuite is recommended to encourage interoperability with
+ implementations conforming to earlier LDAP StartTLS specifications.
+
+3. StartTLS Operation
+
+ The Start Transport Layer Security (StartTLS) operation defined in
+ Section 4.14 of [RFC4511] provides the ability to establish TLS
+ [RFC4346] in an LDAP session.
+
+ The goals of using the TLS protocol with LDAP are to ensure data
+ confidentiality and integrity, and to optionally provide for
+ authentication. TLS expressly provides these capabilities, although
+ the authentication services of TLS are available to LDAP only in
+ combination with the SASL EXTERNAL authentication method (see Section
+ 5.2.3), and then only if the SASL EXTERNAL implementation chooses to
+ make use of the TLS credentials.
+
+3.1. TLS Establishment Procedures
+
+ This section describes the overall procedures clients and servers
+ must follow for TLS establishment. These procedures take into
+ consideration various aspects of the TLS layer including discovery of
+ resultant security level and assertion of the client's authorization
+ identity.
+
+3.1.1. StartTLS Request Sequencing
+
+ A client may send the StartTLS extended request at any time after
+ establishing an LDAP session, except:
+
+ - when TLS is currently established on the session,
+ - when a multi-stage SASL negotiation is in progress on the
+ session, or
+ - when there are outstanding responses for operation requests
+ previously issued on the session.
+
+ As described in [RFC4511], Section 4.14.1, a (detected) violation of
+ any of these requirements results in a return of the operationsError
+ resultCode.
+
+ Client implementers should ensure that they strictly follow these
+ operation sequencing requirements to prevent interoperability issues.
+ Operational experience has shown that violating these requirements
+
+
+
+
+
+Harrison Standards Track [Page 8]
+
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ causes interoperability issues because there are race conditions that
+ prevent servers from detecting some violations of these requirements
+ due to factors such as server hardware speed and network latencies.
+
+ There is no general requirement that the client have or have not
+ already performed a Bind operation (Section 5) before sending a
+ StartTLS operation request; however, where a client intends to
+ perform both a Bind operation and a StartTLS operation, it SHOULD
+ first perform the StartTLS operation so that the Bind request and
+ response messages are protected by the data security services
+ established by the StartTLS operation.
+
+3.1.2. Client Certificate
+
+ If an LDAP server requests or demands that a client provide a user
+ certificate during TLS negotiation and the client does not present a
+ suitable user certificate (e.g., one that can be validated), the
+ server may use a local security policy to determine whether to
+ successfully complete TLS negotiation.
+
+ If a client that has provided a suitable certificate subsequently
+ performs a Bind operation using the SASL EXTERNAL authentication
+ mechanism (Section 5.2.3), information in the certificate may be used
+ by the server to identify and authenticate the client.
+
+3.1.3. Server Identity Check
+
+ In order to prevent man-in-the-middle attacks, the client MUST verify
+ the server's identity (as presented in the server's Certificate
+ message). In this section, the client's understanding of the
+ server's identity (typically the identity used to establish the
+ transport connection) is called the "reference identity".
+
+ The client determines the type (e.g., DNS name or IP address) of the
+ reference identity and performs a comparison between the reference
+ identity and each subjectAltName value of the corresponding type
+ until a match is produced. Once a match is produced, the server's
+ identity has been verified, and the server identity check is
+ complete. Different subjectAltName types are matched in different
+ ways. Sections 3.1.3.1 - 3.1.3.3 explain how to compare values of
+ various subjectAltName types.
+
+ The client may map the reference identity to a different type prior
+ to performing a comparison. Mappings may be performed for all
+ available subjectAltName types to which the reference identity can be
+ mapped; however, the reference identity should only be mapped to
+ types for which the mapping is either inherently secure (e.g.,
+ extracting the DNS name from a URI to compare with a subjectAltName
+
+
+
+Harrison Standards Track [Page 9]
+
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ of type dNSName) or for which the mapping is performed in a secure
+ manner (e.g., using DNSSEC, or using user- or admin-configured host-
+ to-address/address-to-host lookup tables).
+
+ The server's identity may also be verified by comparing the reference
+ identity to the Common Name (CN) [RFC4519] value in the leaf Relative
+ Distinguished Name (RDN) of the subjectName field of the server's
+ certificate. This comparison is performed using the rules for
+ comparison of DNS names in Section 3.1.3.1, below, with the exception
+ that no wildcard matching is allowed. Although the use of the Common
+ Name value is existing practice, it is deprecated, and Certification
+ Authorities are encouraged to provide subjectAltName values instead.
+ Note that the TLS implementation may represent DNs in certificates
+ according to X.500 or other conventions. For example, some X.500
+ implementations order the RDNs in a DN using a left-to-right (most
+ significant to least significant) convention instead of LDAP's
+ right-to-left convention.
+
+ If the server identity check fails, user-oriented clients SHOULD
+ either notify the user (clients may give the user the opportunity to
+ continue with the LDAP session in this case) or close the transport
+ connection and indicate that the server's identity is suspect.
+ Automated clients SHOULD close the transport connection and then
+ return or log an error indicating that the server's identity is
+ suspect or both.
+
+ Beyond the server identity check described in this section, clients
+ should be prepared to do further checking to ensure that the server
+ is authorized to provide the service it is requested to provide. The
+ client may need to make use of local policy information in making
+ this determination.
+
+3.1.3.1. Comparison of DNS Names
+
+ If the reference identity is an internationalized domain name,
+ conforming implementations MUST convert it to the ASCII Compatible
+ Encoding (ACE) format as specified in Section 4 of RFC 3490 [RFC3490]
+ before comparison with subjectAltName values of type dNSName.
+ Specifically, conforming implementations MUST perform the conversion
+ operation specified in Section 4 of RFC 3490 as follows:
+
+ * in step 1, the domain name SHALL be considered a "stored
+ string";
+ * in step 3, set the flag called "UseSTD3ASCIIRules";
+ * in step 4, process each label with the "ToASCII" operation; and
+ * in step 5, change all label separators to U+002E (full stop).
+
+
+
+
+
+Harrison Standards Track [Page 10]
+
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ After performing the "to-ASCII" conversion, the DNS labels and names
+ MUST be compared for equality according to the rules specified in
+ Section 3 of RFC3490.
+
+ The '*' (ASCII 42) wildcard character is allowed in subjectAltName
+ values of type dNSName, and then only as the left-most (least
+ significant) DNS label in that value. This wildcard matches any
+ left-most DNS label in the server name. That is, the subject
+ *.example.com matches the server names a.example.com and
+ b.example.com, but does not match example.com or a.b.example.com.
+
+3.1.3.2. Comparison of IP Addresses
+
+ When the reference identity is an IP address, the identity MUST be
+ converted to the "network byte order" octet string representation
+ [RFC791][RFC2460]. For IP Version 4, as specified in RFC 791, the
+ octet string will contain exactly four octets. For IP Version 6, as
+ specified in RFC 2460, the octet string will contain exactly sixteen
+ octets. This octet string is then compared against subjectAltName
+ values of type iPAddress. A match occurs if the reference identity
+ octet string and value octet strings are identical.
+
+3.1.3.3. Comparison of Other subjectName Types
+
+ Client implementations MAY support matching against subjectAltName
+ values of other types as described in other documents.
+
+3.1.4. Discovery of Resultant Security Level
+
+ After a TLS layer is established in an LDAP session, both parties are
+ to each independently decide whether or not to continue based on
+ local policy and the security level achieved. If either party
+ decides that the security level is inadequate for it to continue, it
+ SHOULD remove the TLS layer immediately after the TLS (re)negotiation
+ has completed (see [RFC4511], Section 4.14.3, and Section 3.2 below).
+ Implementations may reevaluate the security level at any time and,
+ upon finding it inadequate, should remove the TLS layer.
+
+3.1.5. Refresh of Server Capabilities Information
+
+ After a TLS layer is established in an LDAP session, the client
+ SHOULD discard or refresh all information about the server that it
+ obtained prior to the initiation of the TLS negotiation and that it
+ did not obtain through secure mechanisms. This protects against
+ man-in-the-middle attacks that may have altered any server
+ capabilities information retrieved prior to TLS layer installation.
+
+
+
+
+
+Harrison Standards Track [Page 11]
+
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ The server may advertise different capabilities after installing a
+ TLS layer. In particular, the value of 'supportedSASLMechanisms' may
+ be different after a TLS layer has been installed (specifically, the
+ EXTERNAL and PLAIN [PLAIN] mechanisms are likely to be listed only
+ after a TLS layer has been installed).
+
+3.2. Effect of TLS on Authorization State
+
+ The establishment, change, and/or closure of TLS may cause the
+ authorization state to move to a new state. This is discussed
+ further in Section 4.
+
+3.3. TLS Ciphersuites
+
+ Several issues should be considered when selecting TLS ciphersuites
+ that are appropriate for use in a given circumstance. These issues
+ include the following:
+
+ - The ciphersuite's ability to provide adequate confidentiality
+ protection for passwords and other data sent over the transport
+ connection. Client and server implementers should recognize
+ that some TLS ciphersuites provide no confidentiality
+ protection, while other ciphersuites that do provide
+ confidentiality protection may be vulnerable to being cracked
+ using brute force methods, especially in light of ever-
+ increasing CPU speeds that reduce the time needed to
+ successfully mount such attacks.
+
+ - Client and server implementers should carefully consider the
+ value of the password or data being protected versus the level
+ of confidentiality protection provided by the ciphersuite to
+ ensure that the level of protection afforded by the ciphersuite
+ is appropriate.
+
+ - The ciphersuite's vulnerability (or lack thereof) to man-in-the-
+ middle attacks. Ciphersuites vulnerable to man-in-the-middle
+ attacks SHOULD NOT be used to protect passwords or sensitive
+ data, unless the network configuration is such that the danger
+ of a man-in-the-middle attack is negligible.
+
+ - After a TLS negotiation (either initial or subsequent) is
+ completed, both protocol peers should independently verify that
+ the security services provided by the negotiated ciphersuite are
+ adequate for the intended use of the LDAP session. If they are
+ not, the TLS layer should be closed.
+
+
+
+
+
+
+Harrison Standards Track [Page 12]
+
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+4. Authorization State
+
+ Every LDAP session has an associated authorization state. This state
+ is comprised of numerous factors such as what (if any) authentication
+ state has been established, how it was established, and what security
+ services are in place. Some factors may be determined and/or
+ affected by protocol events (e.g., Bind, StartTLS, or TLS closure),
+ and some factors may be determined by external events (e.g., time of
+ day or server load).
+
+ While it is often convenient to view authorization state in
+ simplistic terms (as we often do in this technical specification)
+ such as "an anonymous state", it is noted that authorization systems
+ in LDAP implementations commonly involve many factors that
+ interrelate in complex manners.
+
+ Authorization in LDAP is a local matter. One of the key factors in
+ making authorization decisions is authorization identity. The Bind
+ operation (defined in Section 4.2 of [RFC4511] and discussed further
+ in Section 5 below) allows information to be exchanged between the
+ client and server to establish an authorization identity for the LDAP
+ session. The Bind operation may also be used to move the LDAP
+ session to an anonymous authorization state (see Section 5.1.1).
+
+ Upon initial establishment of the LDAP session, the session has an
+ anonymous authorization identity. Among other things this implies
+ that the client need not send a BindRequest in the first PDU of the
+ LDAP message layer. The client may send any operation request prior
+ to performing a Bind operation, and the server MUST treat it as if it
+ had been performed after an anonymous Bind operation (Section 5.1.1).
+
+ Upon receipt of a Bind request, the server immediately moves the
+ session to an anonymous authorization state. If the Bind request is
+ successful, the session is moved to the requested authentication
+ state with its associated authorization state. Otherwise, the
+ session remains in an anonymous state.
+
+ It is noted that other events both internal and external to LDAP may
+ result in the authentication and authorization states being moved to
+ an anonymous one. For instance, the establishment, change, or
+ closure of data security services may result in a move to an
+ anonymous state, or the user's credential information (e.g.,
+ certificate) may have expired. The former is an example of an event
+ internal to LDAP, whereas the latter is an example of an event
+ external to LDAP.
+
+
+
+
+
+
+Harrison Standards Track [Page 13]
+
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+5. Bind Operation
+
+ The Bind operation ([RFC4511], Section 4.2) allows authentication
+ information to be exchanged between the client and server to
+ establish a new authorization state.
+
+ The Bind request typically specifies the desired authentication
+ identity. Some Bind mechanisms also allow the client to specify the
+ authorization identity. If the authorization identity is not
+ specified, the server derives it from the authentication identity in
+ an implementation-specific manner.
+
+ If the authorization identity is specified, the server MUST verify
+ that the client's authentication identity is permitted to assume
+ (e.g., proxy for) the asserted authorization identity. The server
+ MUST reject the Bind operation with an invalidCredentials resultCode
+ in the Bind response if the client is not so authorized.
+
+5.1. Simple Authentication Method
+
+ The simple authentication method of the Bind Operation provides three
+ authentication mechanisms:
+
+ - An anonymous authentication mechanism (Section 5.1.1).
+
+ - An unauthenticated authentication mechanism (Section 5.1.2).
+
+ - A name/password authentication mechanism using credentials
+ consisting of a name (in the form of an LDAP distinguished name
+ [RFC4514]) and a password (Section 5.1.3).
+
+5.1.1. Anonymous Authentication Mechanism of Simple Bind
+
+ An LDAP client may use the anonymous authentication mechanism of the
+ simple Bind method to explicitly establish an anonymous authorization
+ state by sending a Bind request with a name value of zero length and
+ specifying the simple authentication choice containing a password
+ value of zero length.
+
+5.1.2. Unauthenticated Authentication Mechanism of Simple Bind
+
+ An LDAP client may use the unauthenticated authentication mechanism
+ of the simple Bind method to establish an anonymous authorization
+ state by sending a Bind request with a name value (a distinguished
+ name in LDAP string form [RFC4514] of non-zero length) and specifying
+ the simple authentication choice containing a password value of zero
+ length.
+
+
+
+
+Harrison Standards Track [Page 14]
+
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ The distinguished name value provided by the client is intended to be
+ used for trace (e.g., logging) purposes only. The value is not to be
+ authenticated or otherwise validated (including verification that the
+ DN refers to an existing directory object). The value is not to be
+ used (directly or indirectly) for authorization purposes.
+
+ Unauthenticated Bind operations can have significant security issues
+ (see Section 6.3.1). In particular, users intending to perform
+ Name/Password Authentication may inadvertently provide an empty
+ password and thus cause poorly implemented clients to request
+ Unauthenticated access. Clients SHOULD be implemented to require
+ user selection of the Unauthenticated Authentication Mechanism by
+ means other than user input of an empty password. Clients SHOULD
+ disallow an empty password input to a Name/Password Authentication
+ user interface. Additionally, Servers SHOULD by default fail
+ Unauthenticated Bind requests with a resultCode of
+ unwillingToPerform.
+
+5.1.3. Name/Password Authentication Mechanism of Simple Bind
+
+ An LDAP client may use the name/password authentication mechanism of
+ the simple Bind method to establish an authenticated authorization
+ state by sending a Bind request with a name value (a distinguished
+ name in LDAP string form [RFC4514] of non-zero length) and specifying
+ the simple authentication choice containing an OCTET STRING password
+ value of non-zero length.
+
+ Servers that map the DN sent in the Bind request to a directory entry
+ with an associated set of one or more passwords used with this
+ mechanism will compare the presented password to that set of
+ passwords. The presented password is considered valid if it matches
+ any member of this set.
+
+ A resultCode of invalidDNSyntax indicates that the DN sent in the
+ name value is syntactically invalid. A resultCode of
+ invalidCredentials indicates that the DN is syntactically correct but
+ not valid for purposes of authentication, that the password is not
+ valid for the DN, or that the server otherwise considers the
+ credentials invalid. A resultCode of success indicates that the
+ credentials are valid and that the server is willing to provide
+ service to the entity these credentials identify.
+
+ Server behavior is undefined for Bind requests specifying the
+ name/password authentication mechanism with a zero-length name value
+ and a password value of non-zero length.
+
+
+
+
+
+
+Harrison Standards Track [Page 15]
+
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ The name/password authentication mechanism of the simple Bind method
+ is not suitable for authentication in environments without
+ confidentiality protection.
+
+5.2. SASL Authentication Method
+
+ The sasl authentication method of the Bind Operation provides
+ facilities for using any SASL mechanism including authentication
+ mechanisms and other services (e.g., data security services).
+
+5.2.1. SASL Protocol Profile
+
+ LDAP allows authentication via any SASL mechanism [RFC4422]. As LDAP
+ includes native anonymous and name/password (plain text)
+ authentication methods, the ANONYMOUS [RFC4505] and PLAIN [PLAIN]
+ SASL mechanisms are typically not used with LDAP.
+
+ Each protocol that utilizes SASL services is required to supply
+ certain information profiling the way they are exposed through the
+ protocol ([RFC4422], Section 4). This section explains how each of
+ these profiling requirements is met by LDAP.
+
+5.2.1.1. SASL Service Name for LDAP
+
+ The SASL service name for LDAP is "ldap", which has been registered
+ with the IANA as a SASL service name.
+
+5.2.1.2. SASL Authentication Initiation and Protocol Exchange
+
+ SASL authentication is initiated via a BindRequest message
+ ([RFC4511], Section 4.2) with the following parameters:
+
+ - The version is 3.
+ - The AuthenticationChoice is sasl.
+ - The mechanism element of the SaslCredentials sequence contains
+ the value of the desired SASL mechanism.
+ - The optional credentials field of the SaslCredentials sequence
+ MAY be used to provide an initial client response for mechanisms
+ that are defined to have the client send data first (see
+ [RFC4422], Sections 3 and 5).
+
+ In general, a SASL authentication protocol exchange consists of a
+ series of server challenges and client responses, the contents of
+ which are specific to and defined by the SASL mechanism. Thus, for
+ some SASL authentication mechanisms, it may be necessary for the
+ client to respond to one or more server challenges by sending
+ BindRequest messages multiple times. A challenge is indicated by the
+ server sending a BindResponse message with the resultCode set to
+
+
+
+Harrison Standards Track [Page 16]
+
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ saslBindInProgress. This indicates that the server requires the
+ client to send a new BindRequest message with the same SASL mechanism
+ to continue the authentication process.
+
+ To the LDAP message layer, these challenges and responses are opaque
+ binary tokens of arbitrary length. LDAP servers use the
+ serverSaslCreds field (an OCTET STRING) in a BindResponse message to
+ transmit each challenge. LDAP clients use the credentials field (an
+ OCTET STRING) in the SaslCredentials sequence of a BindRequest
+ message to transmit each response. Note that unlike some Internet
+ protocols where SASL is used, LDAP is not text based and does not
+ Base64-transform these challenge and response values.
+
+ Clients sending a BindRequest message with the sasl choice selected
+ SHOULD send a zero-length value in the name field. Servers receiving
+ a BindRequest message with the sasl choice selected SHALL ignore any
+ value in the name field.
+
+ A client may abort a SASL Bind negotiation by sending a BindRequest
+ message with a different value in the mechanism field of
+ SaslCredentials or with an AuthenticationChoice other than sasl.
+
+ If the client sends a BindRequest with the sasl mechanism field as an
+ empty string, the server MUST return a BindResponse with a resultCode
+ of authMethodNotSupported. This will allow the client to abort a
+ negotiation if it wishes to try again with the same SASL mechanism.
+
+ The server indicates completion of the SASL challenge-response
+ exchange by responding with a BindResponse in which the resultCode
+ value is not saslBindInProgress.
+
+ The serverSaslCreds field in the BindResponse can be used to include
+ an optional challenge with a success notification for mechanisms that
+ are defined to have the server send additional data along with the
+ indication of successful completion.
+
+5.2.1.3. Optional Fields
+
+ As discussed above, LDAP provides an optional field for carrying an
+ initial response in the message initiating the SASL exchange and
+ provides an optional field for carrying additional data in the
+ message indicating the outcome of the authentication exchange. As
+ the mechanism-specific content in these fields may be zero length,
+ SASL requires protocol specifications to detail how an empty field is
+ distinguished from an absent field.
+
+
+
+
+
+
+Harrison Standards Track [Page 17]
+
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ Zero-length initial response data is distinguished from no initial
+ response data in the initiating message, a BindRequest PDU, by the
+ presence of the SaslCredentials.credentials OCTET STRING (of length
+ zero) in that PDU. If the client does not intend to send an initial
+ response with the BindRequest initiating the SASL exchange, it MUST
+ omit the SaslCredentials.credentials OCTET STRING (rather than
+ include an zero-length OCTET STRING).
+
+ Zero-length additional data is distinguished from no additional
+ response data in the outcome message, a BindResponse PDU, by the
+ presence of the serverSaslCreds OCTET STRING (of length zero) in that
+ PDU. If a server does not intend to send additional data in the
+ BindResponse message indicating outcome of the exchange, the server
+ SHALL omit the serverSaslCreds OCTET STRING (rather than including a
+ zero-length OCTET STRING).
+
+5.2.1.4. Octet Where Negotiated Security Layers Take Effect
+
+ SASL layers take effect following the transmission by the server and
+ reception by the client of the final BindResponse in the SASL
+ exchange with a resultCode of success.
+
+ Once a SASL layer providing data integrity or confidentiality
+ services takes effect, the layer remains in effect until a new layer
+ is installed (i.e., at the first octet following the final
+ BindResponse of the Bind operation that caused the new layer to take
+ effect). Thus, an established SASL layer is not affected by a failed
+ or non-SASL Bind.
+
+5.2.1.5. Determination of Supported SASL Mechanisms
+
+ Clients may determine the SASL mechanisms a server supports by
+ reading the 'supportedSASLMechanisms' attribute from the root DSE
+ (DSA-Specific Entry) ([RFC4512], Section 5.1). The values of this
+ attribute, if any, list the mechanisms the server supports in the
+ current LDAP session state. LDAP servers SHOULD allow all clients --
+ even those with an anonymous authorization -- to retrieve the
+ 'supportedSASLMechanisms' attribute of the root DSE both before and
+ after the SASL authentication exchange. The purpose of the latter is
+ to allow the client to detect possible downgrade attacks (see Section
+ 6.4 and [RFC4422], Section 6.1.2).
+
+ Because SASL mechanisms provide critical security functions, clients
+ and servers should be configurable to specify what mechanisms are
+ acceptable and allow only those mechanisms to be used. Both clients
+ and servers must confirm that the negotiated security level meets
+ their requirements before proceeding to use the session.
+
+
+
+
+Harrison Standards Track [Page 18]
+
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+5.2.1.6. Rules for Using SASL Layers
+
+ Upon installing a SASL layer, the client SHOULD discard or refresh
+ all information about the server that it obtained prior to the
+ initiation of the SASL negotiation and that it did not obtain through
+ secure mechanisms.
+
+ If a lower-level security layer (such as TLS) is installed, any SASL
+ layer SHALL be layered on top of such security layers regardless of
+ the order of their negotiation. In all other respects, the SASL
+ layer and other security layers act independently, e.g., if both a
+ TLS layer and a SASL layer are in effect, then removing the TLS layer
+ does not affect the continuing service of the SASL layer.
+
+5.2.1.7. Support for Multiple Authentications
+
+ LDAP supports multiple SASL authentications as defined in [RFC4422],
+ Section 4.
+
+5.2.1.8. SASL Authorization Identities
+
+ Some SASL mechanisms allow clients to request a desired authorization
+ identity for the LDAP session ([RFC4422], Section 3.4). The decision
+ to allow or disallow the current authentication identity to have
+ access to the requested authorization identity is a matter of local
+ policy. The authorization identity is a string of UTF-8 [RFC3629]
+ encoded [Unicode] characters corresponding to the following Augmented
+ Backus-Naur Form (ABNF) [RFC4234] grammar:
+
+ authzId = dnAuthzId / uAuthzId
+
+ ; distinguished-name-based authz id
+ dnAuthzId = "dn:" distinguishedName
+
+ ; unspecified authorization id, UTF-8 encoded
+ uAuthzId = "u:" userid
+ userid = *UTF8 ; syntax unspecified
+
+ where the distinguishedName rule is defined in Section 3 of [RFC4514]
+ and the UTF8 rule is defined in Section 1.4 of [RFC4512].
+
+ The dnAuthzId choice is used to assert authorization identities in
+ the form of a distinguished name to be matched in accordance with the
+ distinguishedNameMatch matching rule ([RFC4517], Section 4.2.15).
+ There is no requirement that the asserted distinguishedName value be
+ that of an entry in the directory.
+
+
+
+
+
+Harrison Standards Track [Page 19]
+
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ The uAuthzId choice allows clients to assert an authorization
+ identity that is not in distinguished name form. The format of
+ userid is defined only as a sequence of UTF-8 [RFC3629] encoded
+ [Unicode] characters, and any further interpretation is a local
+ matter. For example, the userid could identify a user of a specific
+ directory service, be a login name, or be an email address. A
+ uAuthzId SHOULD NOT be assumed to be globally unique. To compare
+ uAuthzId values, each uAuthzId value MUST be prepared as a "query"
+ string ([RFC3454], Section 7) using the SASLprep [RFC4013] algorithm,
+ and then the two values are compared octet-wise.
+
+ The above grammar is extensible. The authzId production may be
+ extended to support additional forms of identities. Each form is
+ distinguished by its unique prefix (see Section 3.12 of [RFC4520] for
+ registration requirements).
+
+5.2.2. SASL Semantics within LDAP
+
+ Implementers must take care to maintain the semantics of SASL
+ specifications when handling data that has different semantics in the
+ LDAP protocol.
+
+ For example, the SASL DIGEST-MD5 authentication mechanism
+ [DIGEST-MD5] utilizes an authentication identity and a realm that are
+ syntactically simple strings and semantically simple username
+ [RFC4013] and realm values. These values are not LDAP DNs, and there
+ is no requirement that they be represented or treated as such.
+
+5.2.3. SASL EXTERNAL Authentication Mechanism
+
+ A client can use the SASL EXTERNAL ([RFC4422], Appendix A) mechanism
+ to request the LDAP server to authenticate and establish a resulting
+ authorization identity using security credentials exchanged by a
+ lower security layer (such as by TLS authentication). If the
+ client's authentication credentials have not been established at a
+ lower security layer, the SASL EXTERNAL Bind MUST fail with a
+ resultCode of inappropriateAuthentication. Although this situation
+ has the effect of leaving the LDAP session in an anonymous state
+ (Section 4), the state of any installed security layer is unaffected.
+
+ A client may either request that its authorization identity be
+ automatically derived from its authentication credentials exchanged
+ at a lower security layer, or it may explicitly provide a desired
+ authorization identity. The former is known as an implicit
+ assertion, and the latter as an explicit assertion.
+
+
+
+
+
+
+Harrison Standards Track [Page 20]
+
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+5.2.3.1. Implicit Assertion
+
+ An implicit authorization identity assertion is performed by invoking
+ a Bind request of the SASL form using the EXTERNAL mechanism name
+ that does not include the optional credentials field (found within
+ the SaslCredentials sequence in the BindRequest). The server will
+ derive the client's authorization identity from the authentication
+ identity supplied by a security layer (e.g., a public key certificate
+ used during TLS layer installation) according to local policy. The
+ underlying mechanics of how this is accomplished are implementation
+ specific.
+
+5.2.3.2. Explicit Assertion
+
+ An explicit authorization identity assertion is performed by invoking
+ a Bind request of the SASL form using the EXTERNAL mechanism name
+ that includes the credentials field (found within the SaslCredentials
+ sequence in the BindRequest). The value of the credentials field (an
+ OCTET STRING) is the asserted authorization identity and MUST be
+ constructed as documented in Section 5.2.1.8.
+
+6. Security Considerations
+
+ Security issues are discussed throughout this document. The
+ unsurprising conclusion is that security is an integral and necessary
+ part of LDAP. This section discusses a number of LDAP-related
+ security considerations.
+
+6.1. General LDAP Security Considerations
+
+ LDAP itself provides no security or protection from accessing or
+ updating the directory by means other than through the LDAP protocol,
+ e.g., from inspection of server database files by database
+ administrators.
+
+ Sensitive data may be carried in almost any LDAP message, and its
+ disclosure may be subject to privacy laws or other legal regulation
+ in many countries. Implementers should take appropriate measures to
+ protect sensitive data from disclosure to unauthorized entities.
+
+ A session on which the client has not established data integrity and
+ privacy services (e.g., via StartTLS, IPsec, or a suitable SASL
+ mechanism) is subject to man-in-the-middle attacks to view and modify
+ information in transit. Client and server implementers SHOULD take
+ measures to protect sensitive data in the LDAP session from these
+ attacks by using data protection services as discussed in this
+ document. Clients and servers should provide the ability to be
+ configured to require these protections. A resultCode of
+
+
+
+Harrison Standards Track [Page 21]
+
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ confidentialityRequired indicates that the server requires
+ establishment of (stronger) data confidentiality protection in order
+ to perform the requested operation.
+
+ Access control should always be applied when reading sensitive
+ information or updating directory information.
+
+ Various security factors, including authentication and authorization
+ information and data security services may change during the course
+ of the LDAP session, or even during the performance of a particular
+ operation. Implementations should be robust in the handling of
+ changing security factors.
+
+6.2. StartTLS Security Considerations
+
+ All security gained via use of the StartTLS operation is gained by
+ the use of TLS itself. The StartTLS operation, on its own, does not
+ provide any additional security.
+
+ The level of security provided through the use of TLS depends
+ directly on both the quality of the TLS implementation used and the
+ style of usage of that implementation. Additionally, a man-in-the-
+ middle attacker can remove the StartTLS extended operation from the
+ 'supportedExtension' attribute of the root DSE. Both parties SHOULD
+ independently ascertain and consent to the security level achieved
+ once TLS is established and before beginning use of the TLS-
+ protected session. For example, the security level of the TLS layer
+ might have been negotiated down to plaintext.
+
+ Clients MUST either warn the user when the security level achieved
+ does not provide an acceptable level of data confidentiality and/or
+ data integrity protection, or be configurable to refuse to proceed
+ without an acceptable level of security.
+
+ As stated in Section 3.1.2, a server may use a local security policy
+ to determine whether to successfully complete TLS negotiation.
+ Information in the user's certificate that is originated or verified
+ by the certification authority should be used by the policy
+ administrator when configuring the identification and authorization
+ policy.
+
+ Server implementers SHOULD allow server administrators to elect
+ whether and when data confidentiality and integrity are required, as
+ well as elect whether authentication of the client during the TLS
+ handshake is required.
+
+ Implementers should be aware of and understand TLS security
+ considerations as discussed in the TLS specification [RFC4346].
+
+
+
+Harrison Standards Track [Page 22]
+
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+6.3. Bind Operation Security Considerations
+
+ This section discusses several security considerations relevant to
+ LDAP authentication via the Bind operation.
+
+6.3.1. Unauthenticated Mechanism Security Considerations
+
+ Operational experience shows that clients can (and frequently do)
+ misuse the unauthenticated authentication mechanism of the simple
+ Bind method (see Section 5.1.2). For example, a client program might
+ make a decision to grant access to non-directory information on the
+ basis of successfully completing a Bind operation. LDAP server
+ implementations may return a success response to an unauthenticated
+ Bind request. This may erroneously leave the client with the
+ impression that the server has successfully authenticated the
+ identity represented by the distinguished name when in reality, an
+ anonymous authorization state has been established. Clients that use
+ the results from a simple Bind operation to make authorization
+ decisions should actively detect unauthenticated Bind requests (by
+ verifying that the supplied password is not empty) and react
+ appropriately.
+
+6.3.2. Name/Password Mechanism Security Considerations
+
+ The name/password authentication mechanism of the simple Bind method
+ discloses the password to the server, which is an inherent security
+ risk. There are other mechanisms, such as SASL DIGEST-MD5
+ [DIGEST-MD5], that do not disclose the password to the server.
+
+6.3.3. Password-Related Security Considerations
+
+ LDAP allows multi-valued password attributes. In systems where
+ entries are expected to have one and only one password,
+ administrative controls should be provided to enforce this behavior.
+
+ The use of clear text passwords and other unprotected authentication
+ credentials is strongly discouraged over open networks when the
+ underlying transport service cannot guarantee confidentiality. LDAP
+ implementations SHOULD NOT by default support authentication methods
+ using clear text passwords and other unprotected authentication
+ credentials unless the data on the session is protected using TLS or
+ other data confidentiality and data integrity protection.
+
+ The transmission of passwords in the clear -- typically for
+ authentication or modification -- poses a significant security risk.
+ This risk can be avoided by using SASL authentication [RFC4422]
+
+
+
+
+
+Harrison Standards Track [Page 23]
+
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ mechanisms that do not transmit passwords in the clear or by
+ negotiating transport or session layer data confidentiality services
+ before transmitting password values.
+
+ To mitigate the security risks associated with the transfer of
+ passwords, a server implementation that supports any password-based
+ authentication mechanism that transmits passwords in the clear MUST
+ support a policy mechanism that at the time of authentication or
+ password modification, requires that:
+
+ A TLS layer has been successfully installed.
+
+ OR
+
+ Some other data confidentiality mechanism that protects the
+ password value from eavesdropping has been provided.
+
+ OR
+
+ The server returns a resultCode of confidentialityRequired for
+ the operation (i.e., name/password Bind with password value,
+ SASL Bind transmitting a password value in the clear, add or
+ modify including a userPassword value, etc.), even if the
+ password value is correct.
+
+ Server implementations may also want to provide policy mechanisms to
+ invalidate or otherwise protect accounts in situations where a server
+ detects that a password for an account has been transmitted in the
+ clear.
+
+6.3.4. Hashed Password Security Considerations
+
+ Some authentication mechanisms (e.g., DIGEST-MD5) transmit a hash of
+ the password value that may be vulnerable to offline dictionary
+ attacks. Implementers should take care to protect such hashed
+ password values during transmission using TLS or other
+ confidentiality mechanisms.
+
+6.4. SASL Security Considerations
+
+ Until data integrity service is installed on an LDAP session, an
+ attacker can modify the transmitted values of the
+ 'supportedSASLMechanisms' attribute response and thus downgrade the
+ list of available SASL mechanisms to include only the least secure
+ mechanism. To detect this type of attack, the client may retrieve
+ the SASL mechanisms the server makes available both before and after
+ data integrity service is installed on an LDAP session. If the
+ client finds that the integrity-protected list (the list obtained
+
+
+
+Harrison Standards Track [Page 24]
+
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ after data integrity service was installed) contains a stronger
+ mechanism than those in the previously obtained list, the client
+ should assume the previously obtained list was modified by an
+ attacker. In this circumstance it is recommended that the client
+ close the underlying transport connection and then reconnect to
+ reestablish the session.
+
+6.5. Related Security Considerations
+
+ Additional security considerations relating to the various
+ authentication methods and mechanisms discussed in this document
+ apply and can be found in [RFC4422], [RFC4013], [RFC3454], and
+ [RFC3629].
+
+7. IANA Considerations
+
+ The IANA has updated the LDAP Protocol Mechanism registry to indicate
+ that this document and [RFC4511] provide the definitive technical
+ specification for the StartTLS (1.3.6.1.4.1.1466.20037) extended
+ operation.
+
+ The IANA has updated the LDAP LDAPMessage types registry to indicate
+ that this document and [RFC4511] provide the definitive technical
+ specification for the bindRequest (0) and bindResponse (1) message
+ types.
+
+ The IANA has updated the LDAP Bind Authentication Method registry to
+ indicate that this document and [RFC4511] provide the definitive
+ technical specification for the simple (0) and sasl (3) bind
+ authentication methods.
+
+ The IANA has updated the LDAP authzid prefixes registry to indicate
+ that this document provides the definitive technical specification
+ for the dnAuthzId (dn:) and uAuthzId (u:) authzid prefixes.
+
+8. Acknowledgements
+
+ This document combines information originally contained in RFC 2251,
+ RFC 2829, and RFC 2830. RFC 2251 was a product of the Access,
+ Searching, and Indexing of Directories (ASID) Working Group. RFC
+ 2829 and RFC 2830 were products of the LDAP Extensions (LDAPEXT)
+ Working Group.
+
+ This document is a product of the IETF LDAP Revision (LDAPBIS)
+ working group.
+
+
+
+
+
+
+Harrison Standards Track [Page 25]
+
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+9. Normative References
+
+ [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
+ September 1981.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
+ (IPv6) Specification", RFC 2460, December 1998.
+
+ [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
+ Internationalized Strings ("stringprep")", RFC 3454,
+ December 2002.
+
+ [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
+ "Internationalizing Domain Names in Applications
+ (IDNA)", RFC 3490, March 2003.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003.
+
+ [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User
+ Names and Passwords", RFC 4013, February 2005.
+
+ [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 4234, October 2005.
+
+ [RFC4346] Dierks, T. and E. Rescorla, "The TLS Protocol Version
+ 1.1", RFC 4346, March 2006.
+
+ [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
+ Authentication and Security Layer (SASL)", RFC 4422,
+ June 2006.
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Technical Specification Road Map", RFC
+ 4510, June 2006.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+
+
+
+
+
+Harrison Standards Track [Page 26]
+
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access
+ Protocol (LDAP): String Representation of Distinguished
+ Names", RFC 4514, June 2006.
+
+ [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Syntaxes and Matching Rules", RFC 4517, June
+ 2006.
+
+ [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Schema for User Applications", RFC
+ 4519, June 2006.
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
+ (IANA) Considerations for the Lightweight Directory
+ Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+ [Unicode] The Unicode Consortium, "The Unicode Standard, Version
+ 3.2.0" is defined by "The Unicode Standard, Version 3.0"
+ (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-
+ 5), as amended by the "Unicode Standard Annex #27:
+ Unicode 3.1" (http://www.unicode.org/reports/tr27/) and
+ by the "Unicode Standard Annex #28: Unicode 3.2"
+ (http://www.unicode.org/reports/tr28/).
+
+ [X.501] ITU-T Rec. X.501, "The Directory: Models", 1993.
+
+10. Informative References
+
+ [DIGEST-MD5] Leach, P., Newman, C., and A. Melnikov, "Using Digest
+ Authentication as a SASL Mechanism", Work in Progress,
+ March 2006.
+
+ [PLAIN] Zeilenga, K., "The Plain SASL Mechanism", Work in
+ Progress, March 2005.
+
+ [RFC2828] Shirey, R., "Internet Security Glossary", FYI 36, RFC
+ 2828, May 2000.
+
+ [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
+ Internet Protocol", RFC 4301, December 2005.
+
+ [RFC4505] Zeilenga, K., "The Anonymous SASL Mechanism", RFC 4505,
+ June 2006.
+
+
+
+
+
+
+
+
+Harrison Standards Track [Page 27]
+
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+Appendix A. Authentication and Authorization Concepts
+
+ This appendix is non-normative.
+
+ This appendix defines basic terms, concepts, and interrelationships
+ regarding authentication, authorization, credentials, and identity.
+ These concepts are used in describing how various security approaches
+ are utilized in client authentication and authorization.
+
+A.1. Access Control Policy
+
+ An access control policy is a set of rules defining the protection of
+ resources, generally in terms of the capabilities of persons or other
+ entities accessing those resources. Security objects and mechanisms,
+ such as those described here, enable the expression of access control
+ policies and their enforcement.
+
+A.2. Access Control Factors
+
+ A request, when it is being processed by a server, may be associated
+ with a wide variety of security-related factors. The server uses
+ these factors to determine whether and how to process the request.
+ These are called access control factors (ACFs). They might include
+ source IP address, encryption strength, the type of operation being
+ requested, time of day, etc.. Some factors may be specific to the
+ request itself; others may be associated with the transport
+ connection via which the request is transmitted; and others (e.g.,
+ time of day) may be "environmental".
+
+ Access control policies are expressed in terms of access control
+ factors; for example, "a request having ACFs i,j,k can perform
+ operation Y on resource Z". The set of ACFs that a server makes
+ available for such expressions is implementation specific.
+
+A.3. Authentication, Credentials, Identity
+
+ Authentication credentials are the evidence supplied by one party to
+ another, asserting the identity of the supplying party (e.g., a user)
+ who is attempting to establish a new authorization state with the
+ other party (typically a server). Authentication is the process of
+ generating, transmitting, and verifying these credentials and thus
+ the identity they assert. An authentication identity is the name
+ presented in a credential.
+
+ There are many forms of authentication credentials. The form used
+ depends upon the particular authentication mechanism negotiated by
+ the parties. X.509 certificates, Kerberos tickets, and simple
+ identity and password pairs are all examples of authentication
+
+
+
+Harrison Standards Track [Page 28]
+
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ credential forms. Note that an authentication mechanism may
+ constrain the form of authentication identities used with it.
+
+A.4. Authorization Identity
+
+ An authorization identity is one kind of access control factor. It
+ is the name of the user or other entity that requests that operations
+ be performed. Access control policies are often expressed in terms
+ of authorization identities; for example, "entity X can perform
+ operation Y on resource Z".
+
+ The authorization identity of an LDAP session is often semantically
+ the same as the authentication identity presented by the client, but
+ it may be different. SASL allows clients to specify an authorization
+ identity distinct from the authentication identity asserted by the
+ client's credentials. This permits agents such as proxy servers to
+ authenticate using their own credentials, yet request the access
+ privileges of the identity for which they are proxying [RFC4422].
+ Also, the form of authentication identity supplied by a service like
+ TLS may not correspond to the authorization identities used to
+ express a server's access control policy, thus requiring a server-
+ specific mapping to be done. The method by which a server composes
+ and validates an authorization identity from the authentication
+ credentials supplied by a client is implementation specific.
+
+Appendix B. Summary of Changes
+
+ This appendix is non-normative.
+
+ This appendix summarizes substantive changes made to RFC 2251, RFC
+ 2829 and RFC 2830. In addition to the specific changes detailed
+ below, the reader of this document should be aware that numerous
+ general editorial changes have been made to the original content from
+ the source documents. These changes include the following:
+
+ - The material originally found in RFC 2251 Sections 4.2.1 and 4.2.2,
+ RFC 2829 (all sections except Sections 2 and 4), and RFC 2830 was
+ combined into a single document.
+
+ - The combined material was substantially reorganized and edited to
+ group related subjects, improve the document flow, and clarify
+ intent.
+
+ - Changes were made throughout the text to align with definitions of
+ LDAP protocol layers and IETF security terminology.
+
+
+
+
+
+
+Harrison Standards Track [Page 29]
+
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+ - Substantial updates and additions were made to security
+ considerations from both documents based on current operational
+ experience.
+
+B.1. Changes Made to RFC 2251
+
+ This section summarizes the substantive changes made to Sections
+ 4.2.1 and 4.2.2 of RFC 2251 by this document. Additional substantive
+ changes to Section 4.2.1 of RFC 2251 are also documented in
+ [RFC4511].
+
+B.1.1. Section 4.2.1 ("Sequencing of the Bind Request")
+
+ - Paragraph 1: Removed the sentence, "If at any stage the client
+ wishes to abort the bind process it MAY unbind and then drop the
+ underlying connection". The Unbind operation still permits this
+ behavior, but it is not documented explicitly.
+
+ - Clarified that the session is moved to an anonymous state upon
+ receipt of the BindRequest PDU and that it is only moved to a non-
+ anonymous state if and when the Bind request is successful.
+
+B.1.2. Section 4.2.2 ("Authentication and Other Security Services")
+
+ - RFC 2251 states that anonymous authentication MUST be performed
+ using the simple bind method. This specification defines the
+ anonymous authentication mechanism of the simple bind method and
+ requires all conforming implementations to support it. Other
+ authentication mechanisms producing anonymous authentication and
+ authorization state may also be implemented and used by conforming
+ implementations.
+
+B.2. Changes Made to RFC 2829
+
+ This section summarizes the substantive changes made to RFC 2829.
+
+B.2.1. Section 4 ("Required security mechanisms")
+
+ - The name/password authentication mechanism (see Section B.2.5
+ below) protected by TLS replaces the SASL DIGEST-MD5 mechanism as
+ LDAP's mandatory-to-implement password-based authentication
+ mechanism. Implementations are encouraged to continue supporting
+ SASL DIGEST-MD5 [DIGEST-MD5].
+
+
+
+
+
+
+
+
+Harrison Standards Track [Page 30]
+
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+B.2.2. Section 5.1 ("Anonymous authentication procedure")
+
+ - Clarified that anonymous authentication involves a name value of
+ zero length and a password value of zero length. The
+ unauthenticated authentication mechanism was added to handle simple
+ Bind requests involving a name value with a non-zero length and a
+ password value of zero length.
+
+B.2.3. Section 6 ("Password-based authentication")
+
+ - See Section B.2.1.
+
+B.2.4. Section 6.1 ("Digest authentication")
+
+ - As the SASL-DIGEST-MD5 mechanism is no longer mandatory to
+ implement, this section is now historical and was not included in
+ this document. RFC 2829, Section 6.1, continues to document the
+ SASL DIGEST-MD5 authentication mechanism.
+
+B.2.5. Section 6.2 ("'simple' authentication choice under TLS
+ encryption")
+
+ - Renamed the "simple" authentication mechanism to the name/password
+ authentication mechanism to better describe it.
+
+ - The use of TLS was generalized to align with definitions of LDAP
+ protocol layers. TLS establishment is now discussed as an
+ independent subject and is generalized for use with all
+ authentication mechanisms and other security layers.
+
+ - Removed the implication that the userPassword attribute is the sole
+ location for storage of password values to be used in
+ authentication. There is no longer any implied requirement for how
+ or where passwords are stored at the server for use in
+ authentication.
+
+B.2.6. Section 6.3 ("Other authentication choices with TLS")
+
+ - See Section B.2.5.
+
+B.2.7. Section 7.1 ("Certificate-based authentication with TLS")
+
+ - See Section B.2.5.
+
+
+
+
+
+
+
+
+Harrison Standards Track [Page 31]
+
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+B.2.8. Section 8 ("Other mechanisms")
+
+ - All SASL authentication mechanisms are explicitly allowed within
+ LDAP. Specifically, this means the SASL ANONYMOUS and SASL PLAIN
+ mechanisms are no longer precluded from use within LDAP.
+
+B.2.9. Section 9 ("Authorization Identity")
+
+ - Specified matching rules for dnAuthzId and uAuthzId values. In
+ particular, the DN value in the dnAuthzId form must be matched
+ using DN matching rules, and the uAuthzId value MUST be prepared
+ using SASLprep rules before being compared octet-wise.
+
+ - Clarified that uAuthzId values should not be assumed to be globally
+ unique.
+
+B.2.10. Section 10 ("TLS Ciphersuites")
+
+ - TLS ciphersuite recommendations are no longer included in this
+ specification. Implementations must now support the
+ TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite and should continue to
+ support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite.
+
+ - Clarified that anonymous authentication involves a name value of
+ zero length and a password value of zero length. The
+ unauthenticated authentication mechanism was added to handle simple
+ Bind requests involving a name value with a non-zero length and a
+ password value of zero length.
+
+B.3. Changes Made to RFC 2830
+
+ This section summarizes the substantive changes made to Sections 3
+ and 5 of RFC 2830. Readers should consult [RFC4511] for summaries of
+ changes to other sections.
+
+B.3.1. Section 3.6 ("Server Identity Check")
+
+ - Substantially updated the server identity check algorithm to ensure
+ that it is complete and robust. In particular, the use of all
+ relevant values in the subjectAltName and the subjectName fields
+ are covered by the algorithm and matching rules are specified for
+ each type of value. Mapped (derived) forms of the server identity
+ may now be used when the mapping is performed in a secure fashion.
+
+
+
+
+
+
+
+
+Harrison Standards Track [Page 32]
+
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+B.3.2. Section 3.7 ("Refresh of Server Capabilities Information")
+
+ - Clients are no longer required to always refresh information about
+ server capabilities following TLS establishment. This is to allow
+ for situations where this information was obtained through a secure
+ mechanism.
+
+B.3.3. Section 5 ("Effects of TLS on a Client's Authorization
+ Identity")
+
+ - Establishing a TLS layer on an LDAP session may now cause the
+ authorization state of the LDAP session to change.
+
+B.3.4. Section 5.2 ("TLS Connection Closure Effects")
+
+ - Closing a TLS layer on an LDAP session changes the authentication
+ and authorization state of the LDAP session based on local policy.
+ Specifically, this means that implementations are not required to
+ change the authentication and authorization states to anonymous
+ upon TLS closure.
+
+ - Replaced references to RFC 2401 with RFC 4301.
+
+Author's Address
+
+ Roger Harrison
+ Novell, Inc.
+ 1800 S. Novell Place
+ Provo, UT 84606
+ USA
+
+ Phone: +1 801 861 2642
+ EMail: roger_harrison@novell.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harrison Standards Track [Page 33]
+
+RFC 4513 LDAP Authentication Methods June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Harrison Standards Track [Page 34]
+
diff --git a/doc/rfc/rfc4514.txt b/doc/rfc/rfc4514.txt
new file mode 100644
index 0000000000000000000000000000000000000000..036c077cbf8fdce0880d4c75c33f2cece88a2ab1
--- /dev/null
+++ b/doc/rfc/rfc4514.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group K. Zeilenga, Ed.
+Request for Comments: 4514 OpenLDAP Foundation
+Obsoletes: 2253 June 2006
+Category: Standards Track
+
+
+ Lightweight Directory Access Protocol (LDAP):
+ String Representation of Distinguished Names
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ The X.500 Directory uses distinguished names (DNs) as primary keys to
+ entries in the directory. This document defines the string
+ representation used in the Lightweight Directory Access Protocol
+ (LDAP) to transfer distinguished names. The string representation is
+ designed to give a clean representation of commonly used
+ distinguished names, while being able to represent any distinguished
+ name.
+
+1. Background and Intended Usage
+
+ In X.500-based directory systems [X.500], including those accessed
+ using the Lightweight Directory Access Protocol (LDAP) [RFC4510],
+ distinguished names (DNs) are used to unambiguously refer to
+ directory entries [X.501][RFC4512].
+
+ The structure of a DN [X.501] is described in terms of ASN.1 [X.680].
+ In the X.500 Directory Access Protocol [X.511] (and other ITU-defined
+ directory protocols), DNs are encoded using the Basic Encoding Rules
+ (BER) [X.690]. In LDAP, DNs are represented in the string form
+ described in this document.
+
+ It is important to have a common format to be able to unambiguously
+ represent a distinguished name. The primary goal of this
+ specification is ease of encoding and decoding. A secondary goal is
+ to have names that are human readable. It is not expected that LDAP
+
+
+
+Zeilenga Standards Track [Page 1]
+
+RFC 4514 LDAP: Distinguished Names June 2006
+
+
+ implementations with a human user interface would display these
+ strings directly to the user, but that they would most likely be
+ performing translations (such as expressing attribute type names in
+ the local national language).
+
+ This document defines the string representation of Distinguished
+ Names used in LDAP [RFC4511][RFC4517]. Section 2 details the
+ RECOMMENDED algorithm for converting a DN from its ASN.1 structured
+ representation to a string. Section 3 details how to convert a DN
+ from a string to an ASN.1 structured representation.
+
+ While other documents may define other algorithms for converting a DN
+ from its ASN.1 structured representation to a string, all algorithms
+ MUST produce strings that adhere to the requirements of Section 3.
+
+ This document does not define a canonical string representation for
+ DNs. Comparison of DNs for equality is to be performed in accordance
+ with the distinguishedNameMatch matching rule [RFC4517].
+
+ This document is a integral part of the LDAP technical specification
+ [RFC4510], which obsoletes the previously defined LDAP technical
+ specification, RFC 3377, in its entirety. This document obsoletes
+ RFC 2253. Changes since RFC 2253 are summarized in Appendix B.
+
+ This specification assumes familiarity with X.500 [X.500] and the
+ concept of Distinguished Name [X.501][RFC4512].
+
+1.1. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+ Character names in this document use the notation for code points and
+ names from the Unicode Standard [Unicode]. For example, the letter
+ "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
+
+ Note: a glossary of terms used in Unicode can be found in [Glossary].
+ Information on the Unicode character encoding model can be found in
+ [CharModel].
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 2]
+
+RFC 4514 LDAP: Distinguished Names June 2006
+
+
+2. Converting DistinguishedName from ASN.1 to a String
+
+ X.501 [X.501] defines the ASN.1 [X.680] structure of distinguished
+ name. The following is a variant provided for discussion purposes.
+
+ DistinguishedName ::= RDNSequence
+
+ RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
+
+ RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
+ AttributeTypeAndValue
+
+ AttributeTypeAndValue ::= SEQUENCE {
+ type AttributeType,
+ value AttributeValue }
+
+ This section defines the RECOMMENDED algorithm for converting a
+ distinguished name from an ASN.1-structured representation to a UTF-8
+ [RFC3629] encoded Unicode [Unicode] character string representation.
+ Other documents may describe other algorithms for converting a
+ distinguished name to a string, but only strings that conform to the
+ grammar defined in Section 3 SHALL be produced by LDAP
+ implementations.
+
+2.1. Converting the RDNSequence
+
+ If the RDNSequence is an empty sequence, the result is the empty or
+ zero-length string.
+
+ Otherwise, the output consists of the string encodings of each
+ RelativeDistinguishedName in the RDNSequence (according to Section
+ 2.2), starting with the last element of the sequence and moving
+ backwards toward the first.
+
+ The encodings of adjoining RelativeDistinguishedNames are separated
+ by a comma (',' U+002C) character.
+
+2.2. Converting RelativeDistinguishedName
+
+ When converting from an ASN.1 RelativeDistinguishedName to a string,
+ the output consists of the string encodings of each
+ AttributeTypeAndValue (according to Section 2.3), in any order.
+
+ Where there is a multi-valued RDN, the outputs from adjoining
+ AttributeTypeAndValues are separated by a plus sign ('+' U+002B)
+ character.
+
+
+
+
+
+Zeilenga Standards Track [Page 3]
+
+RFC 4514 LDAP: Distinguished Names June 2006
+
+
+2.3. Converting AttributeTypeAndValue
+
+ The AttributeTypeAndValue is encoded as the string representation of
+ the AttributeType, followed by an equals sign ('=' U+003D) character,
+ followed by the string representation of the AttributeValue. The
+ encoding of the AttributeValue is given in Section 2.4.
+
+ If the AttributeType is defined to have a short name (descriptor)
+ [RFC4512] and that short name is known to be registered [REGISTRY]
+ [RFC4520] as identifying the AttributeType, that short name, a
+ <descr>, is used. Otherwise the AttributeType is encoded as the
+ dotted-decimal encoding, a <numericoid>, of its OBJECT IDENTIFIER.
+ The <descr> and <numericoid> are defined in [RFC4512].
+
+ Implementations are not expected to dynamically update their
+ knowledge of registered short names. However, implementations SHOULD
+ provide a mechanism to allow their knowledge of registered short
+ names to be updated.
+
+2.4. Converting an AttributeValue from ASN.1 to a String
+
+ If the AttributeType is of the dotted-decimal form, the
+ AttributeValue is represented by an number sign ('#' U+0023)
+ character followed by the hexadecimal encoding of each of the octets
+ of the BER encoding of the X.500 AttributeValue. This form is also
+ used when the syntax of the AttributeValue does not have an LDAP-
+ specific ([RFC4517], Section 3.1) string encoding defined for it, or
+ the LDAP-specific string encoding is not restricted to UTF-8-encoded
+ Unicode characters. This form may also be used in other cases, such
+ as when a reversible string representation is desired (see Section
+ 5.2).
+
+ Otherwise, if the AttributeValue is of a syntax that has a LDAP-
+ specific string encoding, the value is converted first to a UTF-8-
+ encoded Unicode string according to its syntax specification (see
+ [RFC4517], Section 3.3, for examples). If that UTF-8-encoded Unicode
+ string does not have any of the following characters that need
+ escaping, then that string can be used as the string representation
+ of the value.
+
+ - a space (' ' U+0020) or number sign ('#' U+0023) occurring at
+ the beginning of the string;
+
+ - a space (' ' U+0020) character occurring at the end of the
+ string;
+
+
+
+
+
+
+Zeilenga Standards Track [Page 4]
+
+RFC 4514 LDAP: Distinguished Names June 2006
+
+
+ - one of the characters '"', '+', ',', ';', '<', '>', or '\'
+ (U+0022, U+002B, U+002C, U+003B, U+003C, U+003E, or U+005C,
+ respectively);
+
+ - the null (U+0000) character.
+
+ Other characters may be escaped.
+
+ Each octet of the character to be escaped is replaced by a backslash
+ and two hex digits, which form a single octet in the code of the
+ character. Alternatively, if and only if the character to be escaped
+ is one of
+
+ ' ', '"', '#', '+', ',', ';', '<', '=', '>', or '\'
+ (U+0020, U+0022, U+0023, U+002B, U+002C, U+003B,
+ U+003C, U+003D, U+003E, U+005C, respectively)
+
+ it can be prefixed by a backslash ('\' U+005C).
+
+ Examples of the escaping mechanism are shown in Section 4.
+
+3. Parsing a String Back to a Distinguished Name
+
+ The string representation of Distinguished Names is restricted to
+ UTF-8 [RFC3629] encoded Unicode [Unicode] characters. The structure
+ of this string representation is specified using the following
+ Augmented BNF [RFC4234] grammar:
+
+ distinguishedName = [ relativeDistinguishedName
+ *( COMMA relativeDistinguishedName ) ]
+ relativeDistinguishedName = attributeTypeAndValue
+ *( PLUS attributeTypeAndValue )
+ attributeTypeAndValue = attributeType EQUALS attributeValue
+ attributeType = descr / numericoid
+ attributeValue = string / hexstring
+
+ ; The following characters are to be escaped when they appear
+ ; in the value to be encoded: ESC, one of <escaped>, leading
+ ; SHARP or SPACE, trailing SPACE, and NULL.
+ string = [ ( leadchar / pair ) [ *( stringchar / pair )
+ ( trailchar / pair ) ] ]
+
+ leadchar = LUTF1 / UTFMB
+ LUTF1 = %x01-1F / %x21 / %x24-2A / %x2D-3A /
+ %x3D / %x3F-5B / %x5D-7F
+
+ trailchar = TUTF1 / UTFMB
+ TUTF1 = %x01-1F / %x21 / %x23-2A / %x2D-3A /
+
+
+
+Zeilenga Standards Track [Page 5]
+
+RFC 4514 LDAP: Distinguished Names June 2006
+
+
+ %x3D / %x3F-5B / %x5D-7F
+
+ stringchar = SUTF1 / UTFMB
+ SUTF1 = %x01-21 / %x23-2A / %x2D-3A /
+ %x3D / %x3F-5B / %x5D-7F
+
+ pair = ESC ( ESC / special / hexpair )
+ special = escaped / SPACE / SHARP / EQUALS
+ escaped = DQUOTE / PLUS / COMMA / SEMI / LANGLE / RANGLE
+ hexstring = SHARP 1*hexpair
+ hexpair = HEX HEX
+
+ where the productions <descr>, <numericoid>, <COMMA>, <DQUOTE>,
+ <EQUALS>, <ESC>, <HEX>, <LANGLE>, <NULL>, <PLUS>, <RANGLE>, <SEMI>,
+ <SPACE>, <SHARP>, and <UTFMB> are defined in [RFC4512].
+
+ Each <attributeType>, either a <descr> or a <numericoid>, refers to
+ an attribute type of an attribute value assertion (AVA). The
+ <attributeType> is followed by an <EQUALS> and an <attributeValue>.
+ The <attributeValue> is either in <string> or <hexstring> form.
+
+ If in <string> form, a LDAP string representation asserted value can
+ be obtained by replacing (left to right, non-recursively) each <pair>
+ appearing in the <string> as follows:
+
+ replace <ESC><ESC> with <ESC>;
+ replace <ESC><special> with <special>;
+ replace <ESC><hexpair> with the octet indicated by the <hexpair>.
+
+ If in <hexstring> form, a BER representation can be obtained from
+ converting each <hexpair> of the <hexstring> to the octet indicated
+ by the <hexpair>.
+
+ There is one or more attribute value assertions, separated by <PLUS>,
+ for a relative distinguished name.
+
+ There is zero or more relative distinguished names, separated by
+ <COMMA>, for a distinguished name.
+
+ Implementations MUST recognize AttributeType name strings
+ (descriptors) listed in the following table, but MAY recognize other
+ name strings.
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 6]
+
+RFC 4514 LDAP: Distinguished Names June 2006
+
+
+ String X.500 AttributeType
+ ------ --------------------------------------------
+ CN commonName (2.5.4.3)
+ L localityName (2.5.4.7)
+ ST stateOrProvinceName (2.5.4.8)
+ O organizationName (2.5.4.10)
+ OU organizationalUnitName (2.5.4.11)
+ C countryName (2.5.4.6)
+ STREET streetAddress (2.5.4.9)
+ DC domainComponent (0.9.2342.19200300.100.1.25)
+ UID userId (0.9.2342.19200300.100.1.1)
+
+ These attribute types are described in [RFC4519].
+
+ Implementations MAY recognize other DN string representations.
+ However, as there is no requirement that alternative DN string
+ representations be recognized (and, if so, how), implementations
+ SHOULD only generate DN strings in accordance with Section 2 of this
+ document.
+
+4. Examples
+
+ This notation is designed to be convenient for common forms of name.
+ This section gives a few examples of distinguished names written
+ using this notation. First is a name containing three relative
+ distinguished names (RDNs):
+
+ UID=jsmith,DC=example,DC=net
+
+ Here is an example of a name containing three RDNs, in which the
+ first RDN is multi-valued:
+
+ OU=Sales+CN=J. Smith,DC=example,DC=net
+
+ This example shows the method of escaping of a special characters
+ appearing in a common name:
+
+ CN=James \"Jim\" Smith\, III,DC=example,DC=net
+
+ The following shows the method for encoding a value that contains a
+ carriage return character:
+
+ CN=Before\0dAfter,DC=example,DC=net
+
+ In this RDN example, the type in the RDN is unrecognized, and the
+ value is the BER encoding of an OCTET STRING containing two octets,
+ 0x48 and 0x69.
+
+
+
+
+Zeilenga Standards Track [Page 7]
+
+RFC 4514 LDAP: Distinguished Names June 2006
+
+
+ 1.3.6.1.4.1.1466.0=#04024869
+
+ Finally, this example shows an RDN whose commonName value consists of
+ 5 letters:
+
+ Unicode Character Code UTF-8 Escaped
+ ------------------------------- ------ ------ --------
+ LATIN CAPITAL LETTER L U+004C 0x4C L
+ LATIN SMALL LETTER U U+0075 0x75 u
+ LATIN SMALL LETTER C WITH CARON U+010D 0xC48D \C4\8D
+ LATIN SMALL LETTER I U+0069 0x69 i
+ LATIN SMALL LETTER C WITH ACUTE U+0107 0xC487 \C4\87
+
+ This could be encoded in printable ASCII [ASCII] (useful for
+ debugging purposes) as:
+
+ CN=Lu\C4\8Di\C4\87
+
+5. Security Considerations
+
+ The following security considerations are specific to the handling of
+ distinguished names. LDAP security considerations are discussed in
+ [RFC4511] and other documents comprising the LDAP Technical
+ Specification [RFC4510].
+
+5.1. Disclosure
+
+ Distinguished Names typically consist of descriptive information
+ about the entries they name, which can be people, organizations,
+ devices, or other real-world objects. This frequently includes some
+ of the following kinds of information:
+
+ - the common name of the object (i.e., a person's full name)
+ - an email or TCP/IP address
+ - its physical location (country, locality, city, street address)
+ - organizational attributes (such as department name or
+ affiliation)
+
+ In some cases, such information can be considered sensitive. In many
+ countries, privacy laws exist that prohibit disclosure of certain
+ kinds of descriptive information (e.g., email addresses). Hence,
+ server implementers are encouraged to support Directory Information
+ Tree (DIT) structural rules and name forms [RFC4512], as these
+ provide a mechanism for administrators to select appropriate naming
+ attributes for entries. Administrators are encouraged to use
+ mechanisms, access controls, and other administrative controls that
+ may be available to restrict use of attributes containing sensitive
+ information in naming of entries. Additionally, use of
+
+
+
+Zeilenga Standards Track [Page 8]
+
+RFC 4514 LDAP: Distinguished Names June 2006
+
+
+ authentication and data security services in LDAP [RFC4513][RFC4511]
+ should be considered.
+
+5.2. Use of Distinguished Names in Security Applications
+
+ The transformations of an AttributeValue value from its X.501 form to
+ an LDAP string representation are not always reversible back to the
+ same BER (Basic Encoding Rules) or DER (Distinguished Encoding Rules)
+ form. An example of a situation that requires the DER form of a
+ distinguished name is the verification of an X.509 certificate.
+
+ For example, a distinguished name consisting of one RDN with one AVA,
+ in which the type is commonName and the value is of the TeletexString
+ choice with the letters 'Sam', would be represented in LDAP as the
+ string <CN=Sam>. Another distinguished name in which the value is
+ still 'Sam', but is of the PrintableString choice, would have the
+ same representation <CN=Sam>.
+
+ Applications that require the reconstruction of the DER form of the
+ value SHOULD NOT use the string representation of attribute syntaxes
+ when converting a distinguished name to the LDAP format. Instead,
+ they SHOULD use the hexadecimal form prefixed by the number sign ('#'
+ U+0023) as described in the first paragraph of Section 2.4.
+
+6. Acknowledgements
+
+ This document is an update to RFC 2253, by Mark Wahl, Tim Howes, and
+ Steve Kille. RFC 2253 was a product of the IETF ASID Working Group.
+
+ This document is a product of the IETF LDAPBIS Working Group.
+
+7. References
+
+7.1. Normative References
+
+ [REGISTRY] IANA, Object Identifier Descriptors Registry,
+ <http://www.iana.org/assignments/ldap-parameters>.
+
+ [Unicode] The Unicode Consortium, "The Unicode Standard, Version
+ 3.2.0" is defined by "The Unicode Standard, Version
+ 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
+ 61633-5), as amended by the "Unicode Standard Annex
+ #27: Unicode 3.1"
+ (http://www.unicode.org/reports/tr27/) and by the
+ "Unicode Standard Annex #28: Unicode 3.2"
+ (http://www.unicode.org/reports/tr28/).
+
+
+
+
+
+Zeilenga Standards Track [Page 9]
+
+RFC 4514 LDAP: Distinguished Names June 2006
+
+
+ [X.501] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory -- Models," X.501(1993) (also ISO/IEC 9594-
+ 2:1994).
+
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003.
+
+ [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 4234, October 2005.
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Technical Specification Road Map", RFC
+ 4510, June 2006.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+ [RFC4513] Harrison, R., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Authentication Methods and Security
+ Mechanisms", RFC 4513, June 2006.
+
+ [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Syntaxes and Matching Rules", RFC 4517, June
+ 2006.
+
+ [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Schema for User Applications", RFC
+ 4519, June 2006.
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
+ (IANA) Considerations for the Lightweight Directory
+ Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+
+
+
+
+
+Zeilenga Standards Track [Page 10]
+
+RFC 4514 LDAP: Distinguished Names June 2006
+
+
+7.2. Informative References
+
+ [ASCII] Coded Character Set--7-bit American Standard Code for
+ Information Interchange, ANSI X3.4-1986.
+
+ [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report
+ #17, Character Encoding Model", UTR17,
+ <http://www.unicode.org/unicode/reports/tr17/>, August
+ 2000.
+
+ [Glossary] The Unicode Consortium, "Unicode Glossary",
+ <http://www.unicode.org/glossary/>.
+
+ [X.500] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory -- Overview of concepts, models and
+ services," X.500(1993) (also ISO/IEC 9594-1:1994).
+
+ [X.511] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory: Abstract Service Definition", X.511(1993)
+ (also ISO/IEC 9594-3:1993).
+
+ [X.690] International Telecommunication Union -
+ Telecommunication Standardization Sector,
+ "Specification of ASN.1 encoding rules: Basic Encoding
+ Rules (BER), Canonical Encoding Rules (CER), and
+ Distinguished Encoding Rules (DER)", X.690(1997) (also
+ ISO/IEC 8825-1:1998).
+
+ [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) -
+ Technical Specification", RFC 2849, June 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 11]
+
+RFC 4514 LDAP: Distinguished Names June 2006
+
+
+Appendix A. Presentation Issues
+
+ This appendix is provided for informational purposes only; it is not
+ a normative part of this specification.
+
+ The string representation described in this document is not intended
+ to be presented to humans without translation. However, at times it
+ may be desirable to present non-translated DN strings to users. This
+ section discusses presentation issues associated with non-translated
+ DN strings. Issues with presentation of translated DN strings are
+ not discussed in this appendix. Transcoding issues are also not
+ discussed in this appendix.
+
+ This appendix provides guidance for applications presenting DN
+ strings to users. This section is not comprehensive; it does not
+ discuss all presentation issues that implementers may face.
+
+ Not all user interfaces are capable of displaying the full set of
+ Unicode characters. Some Unicode characters are not displayable.
+
+ It is recommended that human interfaces use the optional hex pair
+ escaping mechanism (Section 2.3) to produce a string representation
+ suitable for display to the user. For example, an application can
+ generate a DN string for display that escapes all non-printable
+ characters appearing in the AttributeValue's string representation
+ (as demonstrated in the final example of Section 4).
+
+ When a DN string is displayed in free-form text, it is often
+ necessary to distinguish the DN string from surrounding text. While
+ this is often done with whitespace (as demonstrated in Section 4), it
+ is noted that DN strings may end with whitespace. Careful readers of
+ Section 3 will note that the characters '<' (U+003C) and '>' (U+003E)
+ may only appear in the DN string if escaped. These characters are
+ intended to be used in free-form text to distinguish a DN string from
+ surrounding text. For example, <CN=Sam\ > distinguishes the string
+ representation of the DN composed of one RDN consisting of the AVA
+ (the commonName (CN) value 'Sam ') from the surrounding text. It
+ should be noted to the user that the wrapping '<' and '>' characters
+ are not part of the DN string.
+
+ DN strings can be quite long. It is often desirable to line-wrap
+ overly long DN strings in presentations. Line wrapping should be
+ done by inserting whitespace after the RDN separator character or, if
+ necessary, after the AVA separator character. It should be noted to
+ the user that the inserted whitespace is not part of the DN string
+ and is to be removed before use in LDAP. For example, the following
+ DN string is long:
+
+
+
+
+Zeilenga Standards Track [Page 12]
+
+RFC 4514 LDAP: Distinguished Names June 2006
+
+
+ CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores,
+ O=OpenLDAP Foundation,ST=California,C=US
+
+ So it has been line-wrapped for readability. The extra whitespace is
+ to be removed before the DN string is used in LDAP.
+
+ Inserting whitespace is not advised because it may not be obvious to
+ the user which whitespace is part of the DN string and which
+ whitespace was added for readability.
+
+ Another alternative is to use the LDAP Data Interchange Format (LDIF)
+ [RFC2849]. For example:
+
+ # This entry has a long DN...
+ dn: CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores,
+ O=OpenLDAP Foundation,ST=California,C=US
+ CN: Kurt D. Zeilenga
+ SN: Zeilenga
+ objectClass: person
+
+Appendix B. Changes Made since RFC 2253
+
+ This appendix is provided for informational purposes only, it is not
+ a normative part of this specification.
+
+ The following substantive changes were made to RFC 2253:
+
+ - Removed IESG Note. The IESG Note has been addressed.
+ - Replaced all references to ISO 10646-1 with [Unicode].
+ - Clarified (in Section 1) that this document does not define a
+ canonical string representation.
+ - Clarified that Section 2 describes the RECOMMENDED encoding
+ algorithm and that alternative algorithms are allowed. Some
+ encoding options described in RFC 2253 are now treated as
+ alternative algorithms in this specification.
+ - Revised specification (in Section 2) to allow short names of any
+ registered attribute type to appear in string representations of
+ DNs instead of being restricted to a "published table". Removed
+ "as an example" language. Added statement (in Section 3)
+ allowing recognition of additional names but require recognition
+ of those names in the published table. The table now appears in
+ Section 3.
+ - Removed specification of additional requirements for LDAPv2
+ implementations which also support LDAPv3 (RFC 2253, Section 4)
+ as LDAPv2 is now Historic.
+ - Allowed recognition of alternative string representations.
+ - Updated Section 2.4 to allow hex pair escaping of all characters
+ and clarified escaping for when multiple octet UTF-8 encodings
+
+
+
+Zeilenga Standards Track [Page 13]
+
+RFC 4514 LDAP: Distinguished Names June 2006
+
+
+ are present. Indicated that null (U+0000) character is to be
+ escaped. Indicated that equals sign ('=' U+003D) character may
+ be escaped as '\='.
+ - Rewrote Section 3 to use ABNF as defined in RFC 4234.
+ - Updated the Section 3 ABNF. Changes include:
+ + allowed AttributeType short names of length 1 (e.g., 'L'),
+ + used more restrictive <oid> production in AttributeTypes,
+ + did not require escaping of equals sign ('=' U+003D)
+ characters,
+ + did not require escaping of non-leading number sign ('#'
+ U+0023) characters,
+ + allowed space (' ' U+0020) to be escaped as '\ ',
+ + required hex escaping of null (U+0000) characters, and
+ + removed LDAPv2-only constructs.
+ - Updated Section 3 to describe how to parse elements of the
+ grammar.
+ - Rewrote examples.
+ - Added reference to documentations containing general LDAP
+ security considerations.
+ - Added discussion of presentation issues (Appendix A).
+ - Added this appendix.
+
+ In addition, numerous editorial changes were made.
+
+Editor's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 14]
+
+RFC 4514 LDAP: Distinguished Names June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 15]
+
diff --git a/doc/drafts/draft-ietf-ldapbis-filter-xx.txt b/doc/rfc/rfc4515.txt
similarity index 52%
rename from doc/drafts/draft-ietf-ldapbis-filter-xx.txt
rename to doc/rfc/rfc4515.txt
index 8f00270523b7bbe49569e8181cf3f924c39e7239..86f03ebcd3501f1e186a078877d5d44f6072d029 100644
--- a/doc/drafts/draft-ietf-ldapbis-filter-xx.txt
+++ b/doc/rfc/rfc4515.txt
@@ -1,115 +1,80 @@
-Network Working Group M. Smith, Editor
-Request for Comments: DRAFT Pearl Crescent, LLC
-Obsoletes: RFC 2254 T. Howes
-Expires: 16 May 2005 Opsware, Inc.
- 16 November 2004
- LDAP: String Representation of Search Filters
- <draft-ietf-ldapbis-filter-09.txt>
-Status of this Memo
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she become
- aware will be disclosed, in accordance with RFC 3668.
+Network Working Group M. Smith, Ed.
+Request for Comments: 4515 Pearl Crescent, LLC
+Obsoletes: 2254 T. Howes
+Category: Standards Track Opsware, Inc.
+ June 2006
- This document is intended to be published as a Standards Track RFC,
- replacing RFC 2254. Distribution of this memo is unlimited.
- Technical discussion of this document will take place on the IETF
- LDAP (v3) Revision (ldapbis) Working Group mailing list
- <ietf-ldapbis@openldap.org>. Please send editorial comments directly
- to the editor <mcs@pearlcrescent.com>.
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as
- Internet-Drafts.
+ Lightweight Directory Access Protocol (LDAP):
+ String Representation of Search Filters
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than a "work in progress."
+Status of This Memo
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
+Copyright Notice
- Copyright (C) The Internet Society (2004). All Rights Reserved.
- Please see the Full Copyright section near the end of this document
- for more information.
+ Copyright (C) The Internet Society (2006).
+Abstract
+ Lightweight Directory Access Protocol (LDAP) search filters are
+ transmitted in the LDAP protocol using a binary representation that
+ is appropriate for use on the network. This document defines a
+ human-readable string representation of LDAP search filters that is
+ appropriate for use in LDAP URLs (RFC 4516) and in other
+ applications.
+Table of Contents
+ 1. Introduction ....................................................2
+ 2. LDAP Search Filter Definition ...................................2
+ 3. String Search Filter Definition .................................3
+ 4. Examples ........................................................5
+ 5. Security Considerations .........................................7
+ 6. Normative References ............................................7
+ 7. Informative References ..........................................8
+ 8. Acknowledgements ................................................8
+ Appendix A: Changes Since RFC 2254 .................................9
+ A.1. Technical Changes ..........................................9
+ A.2. Editorial Changes ..........................................9
-Smith & Howes Intended Category: Standards Track [Page 1]
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
-Abstract
- LDAP search filters are transmitted in the LDAP protocol using a
- binary representation that is appropriate for use on the network.
- This document defines a human-readable string representation of LDAP
- search filters that is appropriate for use in LDAP URLs [LDAPURL] and
- in other applications.
-Table of Contents
+Smith and Howes Standards Track [Page 1]
+
+RFC 4515 LDAP: String Representation of Search Filters June 2006
- Status of this Memo............................................1
- Abstract.......................................................2
- Table of Contents..............................................2
-1. Introduction...................................................2
-2. LDAP Search Filter Definition..................................3
-3. String Search Filter Definition................................4
-4. Examples.......................................................6
-5. Security Considerations........................................7
-6. IANA Considerations............................................7
-7. Normative References...........................................7
-8. Informative References.........................................8
-9. Acknowledgments................................................8
-10. Authors' Addresses.............................................9
-11. Appendix A: Changes Since RFC 2254.............................9
-11.1. Technical Changes...........................................9
-11.2. Editorial Changes...........................................10
-12. Appendix B: Changes Since Previous Document Revision...........11
-12.1. Technical Changes...........................................11
-12.2. Editorial Changes...........................................12
- Intellectual Property Rights...................................12
- Full Copyright.................................................13
1. Introduction
- The Lightweight Directory Access Protocol (LDAP) [Roadmap] defines a
+ The Lightweight Directory Access Protocol (LDAP) [RFC4510] defines a
network representation of a search filter transmitted to an LDAP
server. Some applications may find it useful to have a common way of
representing these search filters in a human-readable form; LDAP URLs
- are an example of one such application. This document defines a
- human-readable string format for representing the full range of
- possible LDAP version 3 search filters, including extended match
- filters.
+ [RFC4516] are an example of one such application. This document
+ defines a human-readable string format for representing the full
+ range of possible LDAP version 3 search filters, including extended
+ match filters.
This document is a integral part of the LDAP technical specification
- [Roadmap] which obsoletes the previously defined LDAP technical
+ [RFC4510], which obsoletes the previously defined LDAP technical
specification, RFC 3377, in its entirety.
-
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 2]
-
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
-
-
This document replaces RFC 2254. Changes to RFC 2254 are summarized
in Appendix A.
@@ -119,7 +84,7 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
2. LDAP Search Filter Definition
- An LDAP search filter is defined in Section 4.5.1 of [Protocol] as
+ An LDAP search filter is defined in Section 4.5.1 of [RFC4511] as
follows:
Filter ::= CHOICE {
@@ -142,6 +107,15 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
any [1] AssertionValue,
final [2] AssertionValue } }
+
+
+
+
+Smith and Howes Standards Track [Page 2]
+
+RFC 4515 LDAP: String Representation of Search Filters June 2006
+
+
AttributeValueAssertion ::= SEQUENCE {
attributeDesc AttributeDescription,
assertionValue AssertionValue }
@@ -154,18 +128,10 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
AttributeDescription ::= LDAPString
-- Constrained to <attributedescription>
- -- [Models]
+ -- [RFC4512]
AttributeValue ::= OCTET STRING
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 3]
-
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
-
-
MatchingRuleId ::= LDAPString
AssertionValue ::= OCTET STRING
@@ -173,20 +139,20 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
LDAPString ::= OCTET STRING -- UTF-8 encoded,
-- [Unicode] characters
- The AttributeDescription, as defined in [Protocol], is a string
+ The AttributeDescription, as defined in [RFC4511], is a string
representation of the attribute description that is discussed in
- [Models]. The AttributeValue and AssertionValue OCTET STRING have
- the form defined in [Syntaxes]. The Filter is encoded for
+ [RFC4512]. The AttributeValue and AssertionValue OCTET STRING have
+ the form defined in [RFC4517]. The Filter is encoded for
transmission over a network using the Basic Encoding Rules (BER)
- defined in [X.690], with simplifications described in [Protocol].
+ defined in [X.690], with simplifications described in [RFC4511].
3. String Search Filter Definition
The string representation of an LDAP search filter is a string of
UTF-8 [RFC3629] encoded Unicode characters [Unicode] that is defined
by the following grammar, following the ABNF notation defined in
- [RFC2234]. The productions used that are not defined here are
- defined in section 1.4 (Common ABNF Productions) of [Models] unless
+ [RFC4234]. The productions used that are not defined here are
+ defined in Section 1.4 (Common ABNF Productions) of [RFC4512] unless
otherwise noted. The filter format uses a prefix notation.
filter = LPAREN filtercomp RPAREN
@@ -198,6 +164,14 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
item = simple / present / substring / extensible
simple = attr filtertype assertionvalue
filtertype = equal / approx / greaterorequal / lessorequal
+
+
+
+Smith and Howes Standards Track [Page 3]
+
+RFC 4515 LDAP: String Representation of Search Filters June 2006
+
+
equal = EQUALS
approx = TILDE EQUALS
greaterorequal = RANGLE EQUALS
@@ -213,20 +187,12 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
final = assertionvalue
attr = attributedescription
; The attributedescription rule is defined in
- ; Section 2.5 of [Models].
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 4]
-
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
-
-
+ ; Section 2.5 of [RFC4512].
dnattrs = COLON "dn"
matchingrule = COLON oid
assertionvalue = valueencoding
; The <valueencoding> rule is used to encode an <AssertionValue>
- ; from Section 4.1.6 of [Protocol].
+ ; from Section 4.1.6 of [RFC4511].
valueencoding = 0*(normal / escaped)
normal = UTF1SUBSET / UTFMB
escaped = ESC HEX HEX
@@ -240,7 +206,6 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
VERTBAR = %x7C ; vertical bar (or pipe) ("|")
TILDE = %x7E ; tilde ("~")
-
Note that although both the <substring> and <present> productions in
the grammar above can produce the "attr=*" construct, this construct
is used only to denote a presence filter.
@@ -252,10 +217,21 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
backslash "\" (ASCII 0x5c) followed by the two hexadecimal digits
representing the value of the encoded octet.
+
+
+
+
+
+
+Smith and Howes Standards Track [Page 4]
+
+RFC 4515 LDAP: String Representation of Search Filters June 2006
+
+
This simple escaping mechanism eliminates filter-parsing ambiguities
and allows any filter that can be represented in LDAP to be
- represented as a NUL-terminated string. Other octets that are part of
- the <normal> set may be escaped using this mechanism, for example,
+ represented as a NUL-terminated string. Other octets that are part
+ of the <normal> set may be escaped using this mechanism, for example,
non-printing ASCII characters.
For AssertionValues that contain UTF-8 character data, each octet of
@@ -269,18 +245,10 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
all octets greater than 0x7F that are not part of a valid UTF-8
encoding sequence when they generate a string representation of a
search filter. Implementations SHOULD accept as input strings that
- are not valid UTF-8 strings. This is necessary because RFC 2254 did
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 5]
-
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
-
-
+ are not valid UTF-8 strings. This is necessary because RFC 2254 did
not clearly define the term "string representation" (and in
particular did not mention that the string representation of an LDAP
- search filter is a string of UTF-8 encoded Unicode characters).
+ search filter is a string of UTF-8-encoded Unicode characters).
4. Examples
@@ -307,9 +275,18 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
The second example demonstrates use of a MatchingRuleAssertion form
without a matchingRule.
+
+
+
+
+Smith and Howes Standards Track [Page 5]
+
+RFC 4515 LDAP: String Representation of Search Filters June 2006
+
+
The third example illustrates the use of the ":oid" notation to
- indicate that matching rule identified by the OID "2.4.6.8.10" should
- be used when making comparisons, and that the attributes of an
+ indicate that the matching rule identified by the OID "2.4.6.8.10"
+ should be used when making comparisons, and that the attributes of an
entry's distinguished name should be considered part of the entry
when evaluating the match (indicated by the use of ":dn").
@@ -326,14 +303,6 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
supporting the matching rule contained in the DN should also be
considered.
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 6]
-
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
-
-
The following examples illustrate the use of the escaping mechanism.
(o=Parens R Us \28for all your parenthetical needs\29)
@@ -344,91 +313,100 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
(1.3.6.1.4.1.1466.0=\04\02\48\69)
The first example shows the use of the escaping mechanism to
- represent parenthesis characters. The second shows how to represent a
- "*" in an assertion value, preventing it from being interpreted as a
- substring indicator. The third illustrates the escaping of the
+ represent parenthesis characters. The second shows how to represent
+ a "*" in an assertion value, preventing it from being interpreted as
+ a substring indicator. The third illustrates the escaping of the
backslash character.
- The fourth example shows a filter searching for the four octet value
+ The fourth example shows a filter searching for the four-octet value
00 00 00 04 (hex), illustrating the use of the escaping mechanism to
represent arbitrary data, including NUL characters.
The fifth example illustrates the use of the escaping mechanism to
- represent various non-ASCII UTF-8 characters. Specifically, there are
- 5 characters in the <assertionvalue> portion of this example: LATIN
- CAPITAL LETTER L (U+004C), LATIN SMALL LETTER U (U+0075), LATIN SMALL
- LETTER C WITH CARON (U+010D), LATIN SMALL LETTER I (U+0069), and
- LATIN SMALL LETTER C WITH ACUTE (U+0107).
+ represent various non-ASCII UTF-8 characters. Specifically, there
+ are 5 characters in the <assertionvalue> portion of this example:
+ LATIN CAPITAL LETTER L (U+004C), LATIN SMALL LETTER U (U+0075), LATIN
+ SMALL LETTER C WITH CARON (U+010D), LATIN SMALL LETTER I (U+0069),
+ and LATIN SMALL LETTER C WITH ACUTE (U+0107).
- The sixth and final example demonstrates assertion of a BER encoded
+ The sixth and final example demonstrates assertion of a BER-encoded
value.
+
+
+
+Smith and Howes Standards Track [Page 6]
+
+RFC 4515 LDAP: String Representation of Search Filters June 2006
+
+
5. Security Considerations
This memo describes a string representation of LDAP search filters.
While the representation itself has no known security implications,
- LDAP search filters do. They are interpreted by LDAP servers to
+ LDAP search filters do. They are interpreted by LDAP servers to
select entries from which data is retrieved. LDAP servers should
take care to protect the data they maintain from unauthorized access.
- Please refer to the Security Considerations sections of [Protocol]
- and [AuthMeth] for more information.
-
-6. IANA Considerations
+ Please refer to the Security Considerations sections of [RFC4511] and
+ [RFC4513] for more information.
- This document has no actions for IANA.
+6. Normative References
-7. Normative References
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
-[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and
- Connection Level Security Mechanisms",
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003.
+ [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 4234, October 2005.
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Technical Specification Road Map", RFC 4510, June
+ 2006.
-Smith & Howes Intended Category: Standards Track [Page 7]
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+ [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Authentication Methods and Security Mechanisms",
+ RFC 4513, June 2006.
- draft-ietf-ldapbis-authmeth-xx.txt, a work in progress.
+ [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Syntaxes and Matching Rules", RFC 4517, June
+ 2006.
-[Models] Zeilenga, K. (editor), "LDAP: Directory Information Models",
- draft-ietf-ldapbis-models-xx.txt, a work in progress.
+ [Unicode] The Unicode Consortium, "The Unicode Standard, Version
+ 3.2.0" is defined by "The Unicode Standard, Version 3.0"
+ (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
+ as amended by the "Unicode Standard Annex #27: Unicode
+ 3.1" (http://www.unicode.org/reports/tr27/) and by the
+ "Unicode Standard Annex #28: Unicode 3.2."
-[Protocol] draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
-[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14 (also RFC 2119), March 1997.
-[RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
-[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
- RFC 3629, November 2003.
+Smith and Howes Standards Track [Page 7]
+
+RFC 4515 LDAP: String Representation of Search Filters June 2006
-[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification Road
- Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
-[Syntaxes] Dally, K. (editor), "LDAP: Syntaxes",
- draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
+7. Informative References
-[Unicode] The Unicode Consortium, "The Unicode Standard, Version
- 3.2.0" is defined by "The Unicode Standard, Version 3.0"
- (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as
- amended by the "Unicode Standard Annex #27: Unicode 3.1"
- (http://www.unicode.org/reports/tr27/) and by the "Unicode
- Standard Annex #28: Unicode 3.2."
+ [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory
+ Access Protocol (LDAP): Uniform Resource Locator", RFC
+ 4516, June 2006.
-8. Informative References
+ [X.690] Specification of ASN.1 encoding rules: Basic, Canonical,
+ and Distinguished Encoding Rules, ITU-T Recommendation
+ X.690, 1994.
-[LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator",
- draft-ietf-ldapbis-url-xx.txt, a work in progress.
-
-[X.690] Specification of ASN.1 encoding rules: Basic, Canonical, and
- Distinguished Encoding Rules, ITU-T Recommendation X.690,
- 1994.
-
-9. Acknowledgments
+8. Acknowledgements
This document replaces RFC 2254 by Tim Howes. RFC 2254 was a product
of the IETF ASID Working Group.
@@ -441,77 +419,75 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
-Smith & Howes Intended Category: Standards Track [Page 8]
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
-10. Authors' Addresses
- Mark Smith, Editor
- Pearl Crescent, LLC
- 447 Marlpool Dr.
- Saline, MI 48176
- USA
- +1 734 944-2856
- mcs@pearlcrescent.com
- Tim Howes
- Opsware, Inc.
- 599 N. Mathilda Ave.
- Sunnyvale, CA 94085
- USA
- +1 408 744-7509
- howes@opsware.com
-11. Appendix A: Changes Since RFC 2254
-11.1. Technical Changes
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith and Howes Standards Track [Page 8]
+
+RFC 4515 LDAP: String Representation of Search Filters June 2006
+
+
+Appendix A: Changes Since RFC 2254
+
+A.1. Technical Changes
Replaced [ISO 10646] reference with [Unicode].
The following technical changes were made to the contents of the
"String Search Filter Definition" section:
- Added statement that the string representation is a string of UTF-8
+ Added statement that the string representation is a string of UTF-8-
encoded Unicode characters.
- Revised all of the ABNF to use common productions from [Models].
+ Revised all of the ABNF to use common productions from [RFC4512].
Replaced the "value" rule with a new "assertionvalue" rule within the
"simple", "extensible", and "substring" ("initial", "any", and
- "final") rules. This matches a change made in [Syntaxes].
+ "final") rules. This matches a change made in [RFC4517].
Added "(" and ")" around the components of the <extensible>
subproductions for clarity.
Revised the "attr", "matchingrule", and "assertionvalue" ABNF to more
- precisely reference productions from the [Models] and [Protocol]
+ precisely reference productions from the [RFC4512] and [RFC4511]
documents.
"String Search Filter Definition" section: replaced "greater" and
"less" with "greaterorequal" and "lessorequal" to avoid confusion.
-
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 9]
-
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
-
-
Introduced the "valueencoding" and associated "normal" and "escaped"
- rules to reduce the dependence on descriptive text. The "normal"
+ rules to reduce the dependence on descriptive text. The "normal"
production restricts filter strings to valid UTF-8 sequences.
Added a statement about expected behavior in light of RFC 2254's lack
of a clear definition of "string representation."
-
-
-11.2. Editorial Changes
+A.2. Editorial Changes
Changed document title to include "LDAP:" prefix.
@@ -521,24 +497,30 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
Header and "Authors' Addresses" sections: added Mark Smith as the
document editor and updated affiliation and contact information.
- "Table of Contents", "IANA Considerations", and "Intellectual
- Property Rights" sections: added.
+ "Table of Contents" and "Intellectual Property" sections: added.
Copyright: updated per latest IETF guidelines.
+
+
+Smith and Howes Standards Track [Page 9]
+
+RFC 4515 LDAP: String Representation of Search Filters June 2006
+
+
"Abstract" section: separated from introductory material.
"Introduction" section: new section; separated from the Abstract.
Updated second paragraph to indicate that RFC 2254 is replaced by
- this document (instead of RFC 1960). Added reference to the [Roadmap]
- document.
+ this document (instead of RFC 1960). Added reference to the
+ [RFC4510] document.
"LDAP Search Filter Definition" section: made corrections to the LDAP
- search filter ABNF so it matches that used in [Protocol].
+ search filter ABNF so it matches that used in [RFC4511].
Clarified the definition of 'value' (now 'assertionvalue') to take
into account the fact that it is not precisely an AttributeAssertion
- from [Protocol] section 4.1.6 (special handling is required for some
+ from [RFC4511] Section 4.1.6 (special handling is required for some
characters). Added a note that each octet of a character to be
escaped is replaced by a backslash and two hex digits, which
represent a single octet.
@@ -550,152 +532,82 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
example: (sn:dn:2.4.6.8.10:=Barney Rubble). Replaced the numeric OID
in the first extensible match example with "caseExactMatch" to
demonstrate use of the descriptive form. Used "DN" (uppercase) in
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 10]
-
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
-
-
the last extensible match example to remind the reader to treat the
<dnattrs> production as case insensitive. Reworded the description
of the fourth escaping mechanism example to avoid making assumptions
about byte order. Added text to the fifth escaping mechanism example
to spell out what the non-ASCII characters are in Unicode terms.
- "Security Considerations" section: added references to [Protocol] and
- [AuthMeth].
+ "Security Considerations" section: added references to [RFC4511] and
+ [RFC4513].
"Normative References" section: renamed from "References" per new RFC
- guidelines. Changed from [1] style to [Protocol] style throughout the
- document. Added entries for [Unicode], [RFC2119], [AuthMeth],
- [Models], and [Roadmap] and updated the UTF-8 reference. Replaced
- RFC 822 reference with a reference to RFC 2234.
+ guidelines. Changed from [1] style to [RFC4511] style throughout the
+ document. Added entries for [Unicode], [RFC2119], [RFC4513],
+ [RFC4512], and [RFC4510] and updated the UTF-8 reference. Replaced
+ RFC 822 reference with a reference to RFC 4234.
"Informative References" section: (new section) moved [X.690] to this
- section. Added a reference to [LDAPURL].
+ section. Added a reference to [RFC4516].
- "Acknowledgments" section: added.
+ "Acknowledgements" section: added.
"Appendix A: Changes Since RFC 2254" section: added.
- "Appendix B: Changes Since Previous Document Revision" section:
- added.
-
Surrounded the names of all ABNF productions with "<" and ">" where
they are used in descriptive text.
- Replaced all occurrences of "LDAPv3" with "LDAP."
-12. Appendix B: Changes Since Previous Document Revision
+Smith and Howes Standards Track [Page 10]
+
+RFC 4515 LDAP: String Representation of Search Filters June 2006
- This appendix lists all changes relative to the previously published
- revision, draft-ietf-ldapbis-filter-08.txt. Note that when
- appropriate these changes are also included in Appendix A, but are
- also included here for the benefit of the people who have already
- reviewed draft-ietf-ldapbis-filter-08.txt. This section will be
- removed before this document is published as an RFC.
+ Replaced all occurrences of "LDAPv3" with "LDAP."
-12.1. Technical Changes
+Authors' Addresses
- Removed the third option from the "extensible" production that
- allowed creation of a MatchingRuleAssertion that only had a
- matchValue (disallowed By [Protocol]). Added "(" and ")" around the
- components of the <extensible> subproductions for clarity.
+ Mark Smith, Editor
+ Pearl Crescent, LLC
+ 447 Marlpool Dr.
+ Saline, MI 48176
+ USA
+ Phone: +1 734 944-2856
+ EMail: mcs@pearlcrescent.com
+ Tim Howes
+ Opsware, Inc.
+ 599 N. Mathilda Ave.
+ Sunnyvale, CA 94085
+ USA
-Smith & Howes Intended Category: Standards Track [Page 11]
+ Phone: +1 408 744-7509
+ EMail: howes@opsware.com
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
-12.2. Editorial Changes
- "Introduction" section: referenced [Roadmap] upon first use of LDAP
- and expanded the paragraph that begins "This document is an integral
- part of the LDAP technical specification..." to match the text used
- in [Protocol].
- "LDAP Search Filter Definition" section: reworded the last paragraph
- for clarity.
- "Examples" section: Replaced the numeric OID in the first extensible
- match example with "caseExactMatch" to demonstrate use of the
- descriptive form. Used "DN" (uppercase) in the last extensible match
- example to remind the reader to treat the <dnattrs> production as
- case insensitive. Reworded the description of the fourth escaping
- mechanism example to avoid making assumptions about byte order.
- Added text to the fifth escaping mechanism example to spell out what
- the non-ASCII characters are in Unicode terms.
- References: added [LDAPURL] and moved [X.690] to "Informative
- References."
- "Acknowledgements" section: added the sentence "RFC 2254 was a
- product of the IETF ASID Working Group."
- Changed these two sections to unnumbered ones: "Intellectual Property
- Rights" and "Full Copyright."
- Surrounded the names of all ABNF productions with "<" and ">" where
- they are used in descriptive text.
- Replaced all occurrences of "LDAPv3" with "LDAP."
-Intellectual Property Rights
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
-
-
-
-Smith & Howes Intended Category: Standards Track [Page 12]
-
-INTERNET-DRAFT LDAP: String Repres. of Search Filters 16 November 2004
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-Full Copyright
- Copyright (C) The Internet Society (2004). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-This Internet Draft expires on 16 May 2005.
@@ -703,17 +615,55 @@ This Internet Draft expires on 16 May 2005.
+Smith and Howes Standards Track [Page 11]
+
+RFC 4515 LDAP: String Representation of Search Filters June 2006
+Full Copyright Statement
+ Copyright (C) The Internet Society (2006).
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+Intellectual Property
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+Acknowledgement
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
@@ -721,4 +671,5 @@ This Internet Draft expires on 16 May 2005.
-Smith & Howes Intended Category: Standards Track [Page 13]
\ No newline at end of file
+Smith and Howes Standards Track [Page 12]
+
diff --git a/doc/rfc/rfc4516.txt b/doc/rfc/rfc4516.txt
new file mode 100644
index 0000000000000000000000000000000000000000..6de1e1d08ae66579b05fcc0c4409d34259cb107f
--- /dev/null
+++ b/doc/rfc/rfc4516.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group M. Smith, Ed.
+Request for Comments: 4516 Pearl Crescent, LLC
+Obsoletes: 2255 T. Howes
+Category: Standards Track Opsware, Inc.
+ June 2006
+
+
+ Lightweight Directory Access Protocol (LDAP):
+ Uniform Resource Locator
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This document describes a format for a Lightweight Directory Access
+ Protocol (LDAP) Uniform Resource Locator (URL). An LDAP URL
+ describes an LDAP search operation that is used to retrieve
+ information from an LDAP directory, or, in the context of an LDAP
+ referral or reference, an LDAP URL describes a service where an LDAP
+ operation may be progressed.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. URL Definition ..................................................2
+ 2.1. Percent-Encoding ...........................................4
+ 3. Defaults for Fields of the LDAP URL .............................5
+ 4. Examples ........................................................6
+ 5. Security Considerations .........................................8
+ 6. Normative References ............................................9
+ 7. Informative References .........................................10
+ 8. Acknowledgements ...............................................10
+ Appendix A: Changes Since RFC 2255 ................................11
+ A.1. Technical Changes .........................................11
+ A.2. Editorial Changes .........................................11
+
+
+
+
+
+
+Smith & Howes Standards Track [Page 1]
+
+RFC 4516 LDAP: Uniform Resource Locator June 2006
+
+
+1. Introduction
+
+ LDAP is the Lightweight Directory Access Protocol [RFC4510]. This
+ document specifies the LDAP URL format for version 3 of LDAP and
+ clarifies how LDAP URLs are resolved. This document also defines an
+ extension mechanism for LDAP URLs. This mechanism may be used to
+ provide access to new LDAP extensions.
+
+ Note that not all the parameters of the LDAP search operation
+ described in [RFC4511] can be expressed using the format defined in
+ this document. Note also that URLs may be used to represent
+ reference knowledge, including that for non-search operations.
+
+ This document is an integral part of the LDAP technical specification
+ [RFC4510], which obsoletes the previously defined LDAP technical
+ specification, RFC 3377, in its entirety.
+
+ This document replaces RFC 2255. See Appendix A for a list of
+ changes relative to RFC 2255.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+2. URL Definition
+
+ An LDAP URL begins with the protocol prefix "ldap" and is defined by
+ the following grammar, following the ABNF notation defined in
+ [RFC4234].
+
+ ldapurl = scheme COLON SLASH SLASH [host [COLON port]]
+ [SLASH dn [QUESTION [attributes]
+ [QUESTION [scope] [QUESTION [filter]
+ [QUESTION extensions]]]]]
+ ; <host> and <port> are defined
+ ; in Sections 3.2.2 and 3.2.3
+ ; of [RFC3986].
+ ; <filter> is from Section 3 of
+ ; [RFC4515], subject to the
+ ; provisions of the
+ ; "Percent-Encoding" section
+ ; below.
+
+ scheme = "ldap"
+
+
+
+
+
+
+
+Smith & Howes Standards Track [Page 2]
+
+RFC 4516 LDAP: Uniform Resource Locator June 2006
+
+
+ dn = distinguishedName ; From Section 3 of [RFC4514],
+ ; subject to the provisions of
+ ; the "Percent-Encoding"
+ ; section below.
+
+ attributes = attrdesc *(COMMA attrdesc)
+ attrdesc = selector *(COMMA selector)
+ selector = attributeSelector ; From Section 4.5.1 of
+ ; [RFC4511], subject to the
+ ; provisions of the
+ ; "Percent-Encoding" section
+ ; below.
+
+ scope = "base" / "one" / "sub"
+ extensions = extension *(COMMA extension)
+ extension = [EXCLAMATION] extype [EQUALS exvalue]
+ extype = oid ; From section 1.4 of [RFC4512].
+
+ exvalue = LDAPString ; From section 4.1.2 of
+ ; [RFC4511], subject to the
+ ; provisions of the
+ ; "Percent-Encoding" section
+ ; below.
+
+ EXCLAMATION = %x21 ; exclamation mark ("!")
+ SLASH = %x2F ; forward slash ("/")
+ COLON = %x3A ; colon (":")
+ QUESTION = %x3F ; question mark ("?")
+
+ The "ldap" prefix indicates an entry or entries accessible from the
+ LDAP server running on the given hostname at the given portnumber.
+ Note that the <host> may contain literal IPv6 addresses as specified
+ in Section 3.2.2 of [RFC3986].
+
+ The <dn> is an LDAP Distinguished Name using the string format
+ described in [RFC4514]. It identifies the base object of the LDAP
+ search or the target of a non-search operation.
+
+ The <attributes> construct is used to indicate which attributes
+ should be returned from the entry or entries.
+
+ The <scope> construct is used to specify the scope of the search to
+ perform in the given LDAP server. The allowable scopes are "base"
+ for a base object search, "one" for a one-level search, or "sub" for
+ a subtree search.
+
+
+
+
+
+
+Smith & Howes Standards Track [Page 3]
+
+RFC 4516 LDAP: Uniform Resource Locator June 2006
+
+
+ The <filter> is used to specify the search filter to apply to entries
+ within the specified scope during the search. It has the format
+ specified in [RFC4515].
+
+ The <extensions> construct provides the LDAP URL with an
+ extensibility mechanism, allowing the capabilities of the URL to be
+ extended in the future. Extensions are a simple comma-separated list
+ of type=value pairs, where the =value portion MAY be omitted for
+ options not requiring it. Each type=value pair is a separate
+ extension. These LDAP URL extensions are not necessarily related to
+ any of the LDAP extension mechanisms. Extensions may be supported or
+ unsupported by the client resolving the URL. An extension prefixed
+ with a '!' character (ASCII 0x21) is critical. An extension not
+ prefixed with a '!' character is non-critical.
+
+ If an LDAP URL extension is implemented (that is, if the
+ implementation understands it and is able to use it), the
+ implementation MUST make use of it. If an extension is not
+ implemented and is marked critical, the implementation MUST NOT
+ process the URL. If an extension is not implemented and is not
+ marked critical, the implementation MUST ignore the extension.
+
+ The extension type (<extype>) MAY be specified using the numeric OID
+ <numericoid> form (e.g., 1.2.3.4) or the descriptor <descr> form
+ (e.g., myLDAPURLExtension). Use of the <descr> form SHOULD be
+ restricted to registered object identifier descriptive names. See
+ [RFC4520] for registration details and usage guidelines for
+ descriptive names.
+
+ No LDAP URL extensions are defined in this document. Other documents
+ or a future version of this document MAY define one or more
+ extensions.
+
+2.1. Percent-Encoding
+
+ A generated LDAP URL MUST consist only of the restricted set of
+ characters included in one of the following three productions defined
+ in [RFC3986]:
+
+ <reserved>
+ <unreserved>
+ <pct-encoded>
+
+ Implementations SHOULD accept other valid UTF-8 strings [RFC3629] as
+ input. An octet MUST be encoded using the percent-encoding mechanism
+ described in section 2.1 of [RFC3986] in any of these situations:
+
+
+
+
+
+Smith & Howes Standards Track [Page 4]
+
+RFC 4516 LDAP: Uniform Resource Locator June 2006
+
+
+ The octet is not in the reserved set defined in section 2.2 of
+ [RFC3986] or in the unreserved set defined in section 2.3 of
+ [RFC3986].
+
+ It is the single Reserved character '?' and occurs inside a <dn>,
+ <filter>, or other element of an LDAP URL.
+
+ It is a comma character ',' that occurs inside an <exvalue>.
+
+ Note that before the percent-encoding mechanism is applied, the
+ extensions component of the LDAP URL may contain one or more null
+ (zero) bytes. No other component may.
+
+3. Defaults for Fields of the LDAP URL
+
+ Some fields of the LDAP URL are optional, as described above. In the
+ absence of any other specification, the following general defaults
+ SHOULD be used when a field is absent. Note that other documents MAY
+ specify different defaulting rules; for example, section 4.1.10 of
+ [RFC4511] specifies a different rule for determining the correct DN
+ to use when it is absent in an LDAP URL that is returned as a
+ referral.
+
+ <host>
+ If no <host> is given, the client must have some a priori
+ knowledge of an appropriate LDAP server to contact.
+
+ <port>
+ The default LDAP port is TCP port 389.
+
+ <dn>
+ If no <dn> is given, the default is the zero-length DN, "".
+
+ <attributes>
+ If the <attributes> part is omitted, all user attributes of the
+ entry or entries should be requested (e.g., by setting the
+ attributes field AttributeDescriptionList in the LDAP search
+ request to a NULL list, or by using the special <alluserattrs>
+ selector "*").
+
+ <scope>
+ If <scope> is omitted, a <scope> of "base" is assumed.
+
+ <filter>
+ If <filter> is omitted, a filter of "(objectClass=*)" is assumed.
+
+ <extensions>
+ If <extensions> is omitted, no extensions are assumed.
+
+
+
+Smith & Howes Standards Track [Page 5]
+
+RFC 4516 LDAP: Uniform Resource Locator June 2006
+
+
+4. Examples
+
+ The following are some example LDAP URLs that use the format defined
+ above. The first example is an LDAP URL referring to the University
+ of Michigan entry, available from an LDAP server of the client's
+ choosing:
+
+ ldap:///o=University%20of%20Michigan,c=US
+
+ The next example is an LDAP URL referring to the University of
+ Michigan entry in a particular ldap server:
+
+ ldap://ldap1.example.net/o=University%20of%20Michigan,c=US
+
+ Both of these URLs correspond to a base object search of the
+ "o=University of Michigan,c=US" entry using a filter of
+ "(objectclass=*)", requesting all attributes.
+
+ The next example is an LDAP URL referring to only the postalAddress
+ attribute of the University of Michigan entry:
+
+ ldap://ldap1.example.net/o=University%20of%20Michigan,
+ c=US?postalAddress
+
+ The corresponding LDAP search operation is the same as in the
+ previous example, except that only the postalAddress attribute is
+ requested.
+
+ The next example is an LDAP URL referring to the set of entries found
+ by querying the given LDAP server on port 6666 and doing a subtree
+ search of the University of Michigan for any entry with a common name
+ of "Babs Jensen", retrieving all attributes:
+
+ ldap://ldap1.example.net:6666/o=University%20of%20Michigan,
+ c=US??sub?(cn=Babs%20Jensen)
+
+ The next example is an LDAP URL referring to all children of the c=GB
+ entry:
+
+ LDAP://ldap1.example.com/c=GB?objectClass?ONE
+
+ The objectClass attribute is requested to be returned along with the
+ entries, and the default filter of "(objectclass=*)" is used.
+
+ The next example is an LDAP URL to retrieve the mail attribute for
+ the LDAP entry named "o=Question?,c=US", illustrating the use of the
+ percent-encoding mechanism on the reserved character '?'.
+
+
+
+
+Smith & Howes Standards Track [Page 6]
+
+RFC 4516 LDAP: Uniform Resource Locator June 2006
+
+
+ ldap://ldap2.example.com/o=Question%3f,c=US?mail
+
+ The next example (which is broken into two lines for readability)
+ illustrates the interaction between the LDAP string representation of
+ the filters-quoting mechanism and the URL-quoting mechanisms.
+
+ ldap://ldap3.example.com/o=Babsco,c=US
+ ???(four-octet=%5c00%5c00%5c00%5c04)
+
+ The filter in this example uses the LDAP escaping mechanism of \ to
+ encode three zero or null bytes in the value. In LDAP, the filter
+ would be written as (four-octet=\00\00\00\04). Because the \
+ character must be escaped in a URL, the \s are percent-encoded as %5c
+ (or %5C) in the URL encoding.
+
+ The next example illustrates the interaction between the LDAP string
+ representation of the DNs-quoting mechanism and URL-quoting
+ mechanisms.
+
+ ldap://ldap.example.com/o=An%20Example%5C2C%20Inc.,c=US
+
+ The DN encoded in the above URL is:
+
+ o=An Example\2C Inc.,c=US
+
+ That is, the left-most RDN value is:
+
+ An Example, Inc.
+
+ The following three URLs are equivalent, assuming that the defaulting
+ rules specified in Section 3 of this document are used:
+
+ ldap://ldap.example.net
+ ldap://ldap.example.net/
+ ldap://ldap.example.net/?
+
+ These three URLs point to the root DSE on the ldap.example.net
+ server.
+
+ The final two examples show use of a hypothetical, experimental bind
+ name extension (the value associated with the extension is an LDAP
+ DN).
+
+ ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com
+ ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com
+
+
+
+
+
+
+Smith & Howes Standards Track [Page 7]
+
+RFC 4516 LDAP: Uniform Resource Locator June 2006
+
+
+ The two URLs are the same, except that the second one marks the
+ e-bindname extension as critical. Notice the use of the percent-
+ encoding mechanism to encode the commas within the distinguished name
+ value in the e-bindname extension.
+
+5. Security Considerations
+
+ The general URL security considerations discussed in [RFC3986] are
+ relevant for LDAP URLs.
+
+ The use of security mechanisms when processing LDAP URLs requires
+ particular care, since clients may encounter many different servers
+ via URLs, and since URLs are likely to be processed automatically,
+ without user intervention. A client SHOULD have a user-configurable
+ policy that controls which servers the client will establish LDAP
+ sessions with and with which security mechanisms, and SHOULD NOT
+ establish LDAP sessions that are inconsistent with this policy. If a
+ client chooses to reuse an existing LDAP session when resolving one
+ or more LDAP URLs, it MUST ensure that the session is compatible with
+ the URL and that no security policies are violated.
+
+ Sending authentication information, no matter the mechanism, may
+ violate a user's privacy requirements. In the absence of specific
+ policy permitting authentication information to be sent to a server,
+ a client should use an anonymous LDAP session. (Note that clients
+ conforming to previous LDAP URL specifications, where all LDAP
+ sessions are anonymous and unprotected, are consistent with this
+ specification; they simply have the default security policy.) Simply
+ opening a transport connection to another server may violate some
+ users' privacy requirements, so clients should provide the user with
+ a way to control URL processing.
+
+ Some authentication methods, in particular, reusable passwords sent
+ to the server, may reveal easily-abused information to the remote
+ server or to eavesdroppers in transit and should not be used in URL
+ processing unless they are explicitly permitted by policy.
+ Confirmation by the human user of the use of authentication
+ information is appropriate in many circumstances. Use of strong
+ authentication methods that do not reveal sensitive information is
+ much preferred. If the URL represents a referral for an update
+ operation, strong authentication methods SHOULD be used. Please
+ refer to the Security Considerations section of [RFC4513] for more
+ information.
+
+ The LDAP URL format allows the specification of an arbitrary LDAP
+ search operation to be performed when evaluating the LDAP URL.
+ Following an LDAP URL may cause unexpected results, for example, the
+ retrieval of large amounts of data or the initiation of a long-lived
+
+
+
+Smith & Howes Standards Track [Page 8]
+
+RFC 4516 LDAP: Uniform Resource Locator June 2006
+
+
+ search. The security implications of resolving an LDAP URL are the
+ same as those of resolving an LDAP search query.
+
+6. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003.
+
+ [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+ Resource Identifier (URI): Generic Syntax", STD 66, RFC
+ 3986, January 2005.
+
+ [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 4234, October 2005.
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Technical Specification Road Map", RFC 4510, June
+ 2006.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+ [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Authentication Methods and Security Mechanisms",
+ RFC 4513, June 2006.
+
+ [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): String Representation of Distinguished Names", RFC
+ 4514, June 2006.
+
+ [RFC4515] Smith, M. Ed. and T. Howes, "Lightweight Directory Access
+ Protocol (LDAP): String Representation of Search Filters",
+ RFC 4515, June 2006.
+
+
+
+
+
+
+
+
+
+
+
+Smith & Howes Standards Track [Page 9]
+
+RFC 4516 LDAP: Uniform Resource Locator June 2006
+
+
+7. Informative References
+
+ [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+ Resource Identifiers (URI): Generic Syntax", RFC 2396,
+ August 1998.
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+8. Acknowledgements
+
+ The LDAP URL format was originally defined at the University of
+ Michigan. This material is based upon work supported by the National
+ Science Foundation under Grant No. NCR-9416667. The support of both
+ the University of Michigan and the National Science Foundation is
+ gratefully acknowledged.
+
+ This document obsoletes RFC 2255 by Tim Howes and Mark Smith.
+ Changes included in this revised specification are based upon
+ discussions among the authors, discussions within the LDAP (v3)
+ Revision Working Group (ldapbis), and discussions within other IETF
+ Working Groups. The contributions of individuals in these working
+ groups is gratefully acknowledged. Several people in particular have
+ made valuable comments on this document: RL "Bob" Morgan, Mark Wahl,
+ Kurt Zeilenga, Jim Sermersheim, and Hallvard Furuseth deserve special
+ thanks for their contributions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith & Howes Standards Track [Page 10]
+
+RFC 4516 LDAP: Uniform Resource Locator June 2006
+
+
+Appendix A: Changes Since RFC 2255
+
+A.1. Technical Changes
+
+ The following technical changes were made to the contents of the "URL
+ Definition" section:
+
+ Revised all of the ABNF to use common productions from [RFC4512].
+
+ Replaced references to [RFC2396] with a reference to [RFC3986] (this
+ allows literal IPv6 addresses to be used inside the <host> portion of
+ the URL, and a note was added to remind the reader of this
+ enhancement). Referencing [RFC3986] required changes to the ABNF and
+ text so that productions that are no longer defined by [RFC3986] are
+ not used. For example, <hostport> is not defined by [RFC3986] so it
+ has been replaced with host [COLON port]. Note that [RFC3986]
+ includes new definitions for the "Reserved" and "Unreserved" sets of
+ characters, and the net result is that the following two additional
+ characters should be percent-encoded when they appear anywhere in the
+ data used to construct an LDAP URL: "[" and "]" (these two characters
+ were first added to the Reserved set by RFC 2732).
+
+ Changed the definition of <attrdesc> to refer to <attributeSelector>
+ from [RFC4511]. This allows the use of "*" in the <attrdesc> part of
+ the URL. It is believed that existing implementations of RFC 2255
+ already support this.
+
+ Avoided use of <prose-val> (bracketed-string) productions in the
+ <dn>, <host>, <attrdesc>, and <exvalue> rules.
+
+ Changed the ABNF for <ldapurl> to group the <dn> component with the
+ preceding <SLASH>.
+
+ Changed the <extype> rule to be an <oid> from [RFC4512].
+
+ Changed the text about extension types so it references [RFC4520].
+ Reordered rules to more closely follow the order in which the
+ elements appear in the URL.
+
+ "Bindname Extension": removed due to lack of known implementations.
+
+A.2. Editorial Changes
+
+ Changed document title to include "LDAP:" prefix.
+
+ IESG Note: removed note about lack of satisfactory mandatory
+ authentication mechanisms.
+
+
+
+
+Smith & Howes Standards Track [Page 11]
+
+RFC 4516 LDAP: Uniform Resource Locator June 2006
+
+
+ "Status of this Memo" section: updated boilerplate to match current
+ I-D guidelines.
+
+ "Abstract" section: separated from introductory material.
+
+ "Table of Contents" and "Intellectual Property" sections: added.
+
+ "Introduction" section: new section; separated from the Abstract.
+ Changed the text indicate that RFC 2255 is replaced by this document
+ (instead of RFC 1959). Added text to indicate that LDAP URLs are
+ used for references and referrals. Fixed typo (replaced the nonsense
+ phrase "to perform to retrieve" with "used to retrieve"). Added a
+ note to let the reader know that not all of the parameters of the
+ LDAP search operation described in [RFC4511] can be expressed using
+ this format.
+
+ "URL Definition" section: removed second copy of <ldapurl> grammar
+ and following two paragraphs (editorial error in RFC 2255). Fixed
+ line break within '!' sequence. Reformatted the ABNF to improve
+ readability by aligning comments and adding some blank lines.
+ Replaced "residing in the LDAP server" with "accessible from the LDAP
+ server" in the sentence immediately following the ABNF. Removed the
+ sentence "Individual attrdesc names are as defined for
+ AttributeDescription in [RFC4511]." because [RFC4511]'s
+ <attributeSelector> is now used directly in the ABNF. Reworded last
+ paragraph to clarify which characters must be percent-encoded. Added
+ text to indicate that LDAP URLs are used for references and
+ referrals. Added text that refers to the ABNF from RFC 4234.
+ Clarified and strengthened the requirements with respect to
+ processing of URLs that contain implemented and not implemented
+ extensions (the approach now closely matches that specified in
+ [RFC4511] for LDAP controls).
+
+ "Defaults for Fields of the LDAP URL" section: added; formed by
+ moving text about defaults out of the "URL Definition" section.
+ Replaced direct reference to the attribute name "*" with a reference
+ to the special <alluserattrs> selector "*" defined in [RFC4511].
+
+ "URL Processing" section: removed.
+
+ "Examples" section: Modified examples to use example.com and
+ example.net hostnames. Added missing '?' to the LDAP URL example
+ whose filter contains three null bytes. Removed space after one
+ comma within a DN. Revised the bindname example to use e-bindname.
+ Changed the name of an attribute used in one example from "int" to
+ "four-octet" to avoid potential confusion. Added an example that
+ demonstrates the interaction between DN escaping and URL percent-
+ encoding. Added some examples to show URL equivalence with respect
+
+
+
+Smith & Howes Standards Track [Page 12]
+
+RFC 4516 LDAP: Uniform Resource Locator June 2006
+
+
+ to the <dn> portion of the URL. Used uppercase in some examples to
+ remind the reader that some tokens are case-insensitive.
+
+ "Security Considerations" section: Added a note about connection
+ reuse. Added a note about using strong authentication methods for
+ updates. Added a reference to [RFC4513]. Added note that simply
+ opening a connection may violate some users' privacy requirements.
+ Adopted the working group's revised LDAP terminology specification by
+ replacing the word "connection" with "LDAP session" or "LDAP
+ connection" as appropriate.
+
+ "Acknowledgements" section: added statement that this document
+ obsoletes RFC 2255. Added Kurt Zeilenga, Jim Sermersheim, and
+ Hallvard Furuseth.
+
+ "Normative References" section: renamed from "References" per new RFC
+ guidelines. Changed from [1] style to [RFC4511] style throughout the
+ document. Added references to RFC 4234 and RFC 3629. Updated all
+ RFC 1738 references to point to the appropriate sections within
+ [RFC3986]. Updated the LDAP references to refer to LDAPBis WG
+ documents. Removed the reference to the LDAP Attribute Syntaxes
+ document and added references to the [RFC4513], [RFC4520], and
+ [RFC4510] documents.
+
+ "Informative References" section: added.
+
+ Header and "Authors' Addresses" sections: added "editor" next to Mark
+ Smith's name. Updated affiliation and contact information.
+
+ Copyright: updated the year.
+
+ Throughout the document: surrounded the names of all ABNF productions
+ with "<" and ">" where they are used in descriptive text.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith & Howes Standards Track [Page 13]
+
+RFC 4516 LDAP: Uniform Resource Locator June 2006
+
+
+Authors' Addresses
+
+ Mark Smith, Editor
+ Pearl Crescent, LLC
+ 447 Marlpool Dr.
+ Saline, MI 48176
+ USA
+
+ Phone: +1 734 944-2856
+ EMail: mcs@pearlcrescent.com
+
+
+ Tim Howes
+ Opsware, Inc.
+ 599 N. Mathilda Ave.
+ Sunnyvale, CA 94085
+ USA
+
+ Phone: +1 408 744-7509
+ EMail: howes@opsware.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Smith & Howes Standards Track [Page 14]
+
+RFC 4516 LDAP: Uniform Resource Locator June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Smith & Howes Standards Track [Page 15]
+
diff --git a/doc/drafts/draft-ietf-ldapbis-syntaxes-xx.txt b/doc/rfc/rfc4517.txt
similarity index 70%
rename from doc/drafts/draft-ietf-ldapbis-syntaxes-xx.txt
rename to doc/rfc/rfc4517.txt
index 4eb566944634aa413565fa724394572a3305a0f3..177e08b2ac4ffa19345adac565cac0a14343ff3f 100644
--- a/doc/drafts/draft-ietf-ldapbis-syntaxes-xx.txt
+++ b/doc/rfc/rfc4517.txt
@@ -4,65 +4,34 @@
-INTERNET-DRAFT S. Legg
-draft-ietf-ldapbis-syntaxes-11.txt eB2Bcom
-Intended Category: Standards Track 23 June 2005
-Obsoletes: RFC 2252, RFC 2256 Updates: RFC 3698
+Network Working Group S. Legg, Ed.
+Request for Comments: 4517 eB2Bcom
+Obsoletes: 2252, 2256 June 2006
+Updates: 3698
+Category: Standards Track
Lightweight Directory Access Protocol (LDAP):
Syntaxes and Matching Rules
- Copyright (C) The Internet Society (2005). All Rights Reserved.
- Status of this Memo
+Status of This Memo
- By submitting this Internet-draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
- By submitting this Internet-draft, I accept the provisions of Section
- 3 of BCP 78.
+Copyright Notice
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as
- Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress".
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
- This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor as a Standard Track document.
- Distribution of this document is unlimited. Technical discussion of
- this document should take place on the IETF LDAP Revision Working
- Group (LDAPbis) mailing list <ietf-ldapbis@openldap.org>. Please
- send editorial comments directly to the editor
- <steven.legg@eb2bcom.com>.
-
- This Internet-Draft expires on 23 December 2005.
+ Copyright (C) The Internet Society (2006).
Abstract
-
-
-Legg Expires 23 December 2005 [Page 1]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
Each attribute stored in a Lightweight Directory Access Protocol
- (LDAP) directory, and whose values may be transfered in the LDAP
- protocol, has a defined syntax which constrains the structure and
+ (LDAP) directory, whose values may be transferred in the LDAP
+ protocol, has a defined syntax that constrains the structure and
format of its values. The comparison semantics for values of a
syntax are not part of the syntax definition but are instead provided
through separately defined matching rules. Matching rules specify an
@@ -70,188 +39,149 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
document defines a base set of syntaxes and matching rules for use in
defining attributes for LDAP directories.
+Table of Contents
+ 1. Introduction ....................................................3
+ 2. Conventions .....................................................4
+ 3. Syntaxes ........................................................4
+ 3.1. General Considerations .....................................5
+ 3.2. Common Definitions .........................................5
+ 3.3. Syntax Definitions .........................................6
+ 3.3.1. Attribute Type Description ..........................6
+ 3.3.2. Bit String ..........................................6
+ 3.3.3. Boolean .............................................7
+ 3.3.4. Country String ......................................7
+ 3.3.5. Delivery Method .....................................8
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Legg Expires 23 December 2005 [Page 2]
+Legg Standards Track [Page 1]
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 3. Syntaxes . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 3.1. General Considerations . . . . . . . . . . . . . . . . . 6
- 3.2. Common Definitions . . . . . . . . . . . . . . . . . . . 7
- 3.3. Syntax Definitions . . . . . . . . . . . . . . . . . . . 7
- 3.3.1. Attribute Type Description . . . . . . . . . . . 7
- 3.3.2. Bit String . . . . . . . . . . . . . . . . . . . 8
- 3.3.3. Boolean. . . . . . . . . . . . . . . . . . . . . 8
- 3.3.4. Country String . . . . . . . . . . . . . . . . . 8
- 3.3.5. Delivery Method. . . . . . . . . . . . . . . . . 9
- 3.3.6. Directory String . . . . . . . . . . . . . . . . 9
- 3.3.7. DIT Content Rule Description . . . . . . . . . . 10
- 3.3.8. DIT Structure Rule Description . . . . . . . . . 11
- 3.3.9. DN . . . . . . . . . . . . . . . . . . . . . . . 11
- 3.3.10. Enhanced Guide . . . . . . . . . . . . . . . . . 12
- 3.3.11. Facsimile Telephone Number . . . . . . . . . . . 13
- 3.3.12. Fax. . . . . . . . . . . . . . . . . . . . . . . 13
- 3.3.13. Generalized Time . . . . . . . . . . . . . . . . 14
- 3.3.14. Guide. . . . . . . . . . . . . . . . . . . . . . 15
- 3.3.15. IA5 String . . . . . . . . . . . . . . . . . . . 16
- 3.3.16. Integer. . . . . . . . . . . . . . . . . . . . . 16
- 3.3.17. JPEG . . . . . . . . . . . . . . . . . . . . . . 16
- 3.3.18. LDAP Syntax Description. . . . . . . . . . . . . 17
- 3.3.19. Matching Rule Description. . . . . . . . . . . . 17
- 3.3.20. Matching Rule Use Description. . . . . . . . . . 18
- 3.3.21. Name and Optional UID. . . . . . . . . . . . . . 18
- 3.3.22. Name Form Description. . . . . . . . . . . . . . 19
- 3.3.23. Numeric String . . . . . . . . . . . . . . . . . 19
- 3.3.24. Object Class Description . . . . . . . . . . . . 19
- 3.3.25. Octet String . . . . . . . . . . . . . . . . . . 20
- 3.3.26. OID. . . . . . . . . . . . . . . . . . . . . . . 20
- 3.3.27. Other Mailbox. . . . . . . . . . . . . . . . . . 21
- 3.3.28. Postal Address . . . . . . . . . . . . . . . . . 21
- 3.3.29. Printable String . . . . . . . . . . . . . . . . 22
- 3.3.30. Substring Assertion. . . . . . . . . . . . . . . 23
- 3.3.31. Telephone Number . . . . . . . . . . . . . . . . 23
- 3.3.32. Teletex Terminal Identifier. . . . . . . . . . . 24
- 3.3.33. Telex Number . . . . . . . . . . . . . . . . . . 25
- 3.3.34. UTC Time . . . . . . . . . . . . . . . . . . . . 25
- 4. Matching Rules . . . . . . . . . . . . . . . . . . . . . . . . 26
- 4.1. General Considerations . . . . . . . . . . . . . . . . . 26
- 4.2. Matching Rule Definitions. . . . . . . . . . . . . . . . 28
- 4.2.1. bitStringMatch . . . . . . . . . . . . . . . . . 28
- 4.2.2. booleanMatch . . . . . . . . . . . . . . . . . . 29
- 4.2.3. caseExactIA5Match. . . . . . . . . . . . . . . . 29
-
-
-
-Legg Expires 23 December 2005 [Page 3]
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ 3.3.6. Directory String ....................................8
+ 3.3.7. DIT Content Rule Description ........................9
+ 3.3.8. DIT Structure Rule Description .....................10
+ 3.3.9. DN .................................................10
+ 3.3.10. Enhanced Guide ....................................11
+ 3.3.11. Facsimile Telephone Number ........................12
+ 3.3.12. Fax ...............................................12
+ 3.3.13. Generalized Time ..................................13
+ 3.3.14. Guide .............................................14
+ 3.3.15. IA5 String ........................................15
+ 3.3.16. Integer ...........................................15
+ 3.3.17. JPEG ..............................................15
+ 3.3.18. LDAP Syntax Description ...........................16
+ 3.3.19. Matching Rule Description .........................16
+ 3.3.20. Matching Rule Use Description .....................17
+ 3.3.21. Name and Optional UID .............................17
+ 3.3.22. Name Form Description .............................18
+ 3.3.23. Numeric String ....................................18
+ 3.3.24. Object Class Description ..........................18
+ 3.3.25. Octet String ......................................19
+ 3.3.26. OID ...............................................19
+ 3.3.27. Other Mailbox .....................................20
+ 3.3.28. Postal Address ....................................20
+ 3.3.29. Printable String ..................................21
+ 3.3.30. Substring Assertion ...............................22
+ 3.3.31. Telephone Number ..................................23
+ 3.3.32. Teletex Terminal Identifier .......................23
+ 3.3.33. Telex Number ......................................24
+ 3.3.34. UTC Time ..........................................24
+ 4. Matching Rules .................................................25
+ 4.1. General Considerations ....................................25
+ 4.2. Matching Rule Definitions .................................27
+ 4.2.1. bitStringMatch .....................................27
+ 4.2.2. booleanMatch .......................................28
+ 4.2.3. caseExactIA5Match ..................................28
+ 4.2.4. caseExactMatch .....................................29
+ 4.2.5. caseExactOrderingMatch .............................29
+ 4.2.6. caseExactSubstringsMatch ...........................30
+ 4.2.7. caseIgnoreIA5Match .................................30
+ 4.2.8. caseIgnoreIA5SubstringsMatch .......................31
+ 4.2.9. caseIgnoreListMatch ................................31
+ 4.2.10. caseIgnoreListSubstringsMatch .....................32
+ 4.2.11. caseIgnoreMatch ...................................33
+ 4.2.12. caseIgnoreOrderingMatch ...........................33
+ 4.2.13. caseIgnoreSubstringsMatch .........................34
+ 4.2.14. directoryStringFirstComponentMatch ................34
+ 4.2.15. distinguishedNameMatch ............................35
+ 4.2.16. generalizedTimeMatch ..............................36
+
+
+
+Legg Standards Track [Page 2]
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- 4.2.4. caseExactMatch . . . . . . . . . . . . . . . . . 30
- 4.2.5. caseExactOrderingMatch . . . . . . . . . . . . . 30
- 4.2.6. caseExactSubstringsMatch . . . . . . . . . . . . 31
- 4.2.7. caseIgnoreIA5Match . . . . . . . . . . . . . . . 31
- 4.2.8. caseIgnoreIA5SubstringsMatch . . . . . . . . . . 32
- 4.2.9. caseIgnoreListMatch. . . . . . . . . . . . . . . 32
- 4.2.10. caseIgnoreListSubstringsMatch. . . . . . . . . . 33
- 4.2.11. caseIgnoreMatch. . . . . . . . . . . . . . . . . 33
- 4.2.12. caseIgnoreOrderingMatch. . . . . . . . . . . . . 34
- 4.2.13. caseIgnoreSubstringsMatch. . . . . . . . . . . . 34
- 4.2.14. directoryStringFirstComponentMatch . . . . . . . 35
- 4.2.15. distinguishedNameMatch . . . . . . . . . . . . . 36
- 4.2.16. generalizedTimeMatch . . . . . . . . . . . . . . 36
- 4.2.17. generalizedTimeOrderingMatch . . . . . . . . . . 37
- 4.2.18. integerFirstComponentMatch . . . . . . . . . . . 37
- 4.2.19. integerMatch . . . . . . . . . . . . . . . . . . 38
- 4.2.20. integerOrderingMatch . . . . . . . . . . . . . . 38
- 4.2.21. keywordMatch . . . . . . . . . . . . . . . . . . 38
- 4.2.22. numericStringMatch . . . . . . . . . . . . . . . 39
- 4.2.23. numericStringOrderingMatch . . . . . . . . . . . 39
- 4.2.24. numericStringSubstringsMatch . . . . . . . . . . 40
- 4.2.25. objectIdentifierFirstComponentMatch. . . . . . . 40
- 4.2.26. objectIdentifierMatch. . . . . . . . . . . . . . 41
- 4.2.27. octetStringMatch . . . . . . . . . . . . . . . . 41
- 4.2.28. octetStringOrderingMatch . . . . . . . . . . . . 42
- 4.2.29. telephoneNumberMatch . . . . . . . . . . . . . . 42
- 4.2.30. telephoneNumberSubstringsMatch . . . . . . . . . 43
- 4.2.31. uniqueMemberMatch. . . . . . . . . . . . . . . . 44
- 4.2.32. wordMatch. . . . . . . . . . . . . . . . . . . . 44
- 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 44
- 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45
- 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 45
- Appendix A. Summary of Syntax Object Identifiers . . . . . . . . . 47
- Appendix B. Changes from RFC 2252. . . . . . . . . . . . . . . . . 48
- Normative References . . . . . . . . . . . . . . . . . . . . . . . 50
- Informative References . . . . . . . . . . . . . . . . . . . . . . 52
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 53
- Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 53
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ 4.2.17. generalizedTimeOrderingMatch ......................36
+ 4.2.18. integerFirstComponentMatch ........................36
+ 4.2.19. integerMatch ......................................37
+ 4.2.20. integerOrderingMatch ..............................37
+ 4.2.21. keywordMatch ......................................38
+ 4.2.22. numericStringMatch ................................38
+ 4.2.23. numericStringOrderingMatch ........................39
+ 4.2.24. numericStringSubstringsMatch ......................39
+ 4.2.25. objectIdentifierFirstComponentMatch ...............40
+ 4.2.26. objectIdentifierMatch .............................40
+ 4.2.27. octetStringMatch ..................................41
+ 4.2.28. octetStringOrderingMatch ..........................41
+ 4.2.29. telephoneNumberMatch ..............................42
+ 4.2.30. telephoneNumberSubstringsMatch ....................42
+ 4.2.31. uniqueMemberMatch .................................43
+ 4.2.32. wordMatch .........................................44
+ 5. Security Considerations ........................................44
+ 6. Acknowledgements ...............................................44
+ 7. IANA Considerations ............................................45
+ 8. References .....................................................46
+ 8.1. Normative References ......................................46
+ 8.2. Informative References ....................................48
+ Appendix A. Summary of Syntax Object Identifiers ..................49
+ Appendix B. Changes from RFC 2252 .................................49
1. Introduction
Each attribute stored in a Lightweight Directory Access Protocol
- (LDAP) directory [ROADMAP], and whose values may be transfered in the
- LDAP protocol [PROT], has a defined syntax (i.e., data type) which
+ (LDAP) directory [RFC4510], whose values may be transferred in the
+ LDAP protocol [RFC4511], has a defined syntax (i.e., data type) that
constrains the structure and format of its values. The comparison
semantics for values of a syntax are not part of the syntax
definition but are instead provided through separately defined
matching rules. Matching rules specify an argument, an assertion
+ value, which also has a defined syntax. This document defines a base
+ set of syntaxes and matching rules for use in defining attributes for
+ LDAP directories.
+
+ Readers are advised to familiarize themselves with the Directory
+ Information Models [RFC4512] before reading the rest of this
+ document. Section 3 provides definitions for the base set of LDAP
+ syntaxes. Section 4 provides definitions for the base set of
+ matching rules for LDAP.
+
+ This document is an integral part of the LDAP technical specification
+ [RFC4510], which obsoletes the previously defined LDAP technical
+ specification, RFC 3377, in its entirety.
-Legg Expires 23 December 2005 [Page 4]
+
+Legg Standards Track [Page 3]
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
- value, which also has a defined syntax. This document defines a base
- set of syntaxes and matching rules for use in defining attributes for
- LDAP directories.
+ Sections 4, 5, and 7 of RFC 2252 are obsoleted by [RFC4512]. The
+ remainder of RFC 2252 is obsoleted by this document. Sections 6 and
+ 8 of RFC 2256 are obsoleted by this document. The remainder of RFC
+ 2256 is obsoleted by [RFC4519] and [RFC4512]. All but Section 2.11
+ of RFC 3698 is obsoleted by this document.
- Readers are advised to familiarize themselves with the Directory
- Information Models [MODELS] before reading the rest of this document.
- Section 3 provides definitions for the base set of LDAP syntaxes.
- Section 4 provides definitions for the base set of matching rules for
- LDAP.
-
- This document is a integral part of the LDAP technical specification
- [ROADMAP] which obsoletes the previously defined LDAP technical
- specification [RFC3377] in its entirety.
-
- Sections 4, 5 and 7 of RFC 2252 [RFC2252] are obsoleted by [MODELS].
- The remainder of RFC 2252 is obsoleted by this document. Sections 6
- and 8 of RFC 2256 [RFC2256] are obsoleted by this document. The
- remainder of RFC 2256 is obsoleted by [SCHEMA] and [MODELS]. All but
- Section 2.11 of RFC 3698 [RFC3698] is obsoleted by this document.
-
- A number of schema elements which were included in the previous
+ A number of schema elements that were included in the previous
revision of the LDAP technical specification are not included in this
revision of LDAP. Public Key Infrastructure schema elements are now
- specified in [LDAP-PKI]. Unless reintroduced in future technical
+ specified in [RFC4523]. Unless reintroduced in future technical
specifications, the remainder are to be considered Historic.
The changes with respect to RFC 2252 are described in Appendix B of
@@ -259,34 +189,26 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
2. Conventions
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
- document are to be interpreted as described in BCP 14, RFC 2119
- [KEYWORD].
+ In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+ "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+ and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
+ [RFC2119].
Syntax definitions are written according to the <SyntaxDescription>
- ABNF [ABNF] rule specified in [MODELS], and matching rule definitions
- are written according to the <MatchingRuleDescription> ABNF rule
- specified in [MODELS], except that the syntax and matching rule
- definitions provided in this document are line-wrapped for
- readability. When such definitions are transfered as attribute
+ ABNF [RFC4234] rule specified in [RFC4512], and matching rule
+ definitions are written according to the <MatchingRuleDescription>
+ ABNF rule specified in [RFC4512], except that the syntax and matching
+ rule definitions provided in this document are line-wrapped for
+ readability. When such definitions are transferred as attribute
values in the LDAP protocol (e.g., as values of the ldapSyntaxes and
- matchingRules attributes [MODELS] respectively) then those values
+ matchingRules attributes [RFC4512], respectively), then those values
would not contain line breaks.
3. Syntaxes
-
-
-
-Legg Expires 23 December 2005 [Page 5]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
Syntax definitions constrain the structure of attribute values stored
in an LDAP directory, and determine the representation of attribute
- and assertion values transfered in the LDAP protocol.
+ and assertion values transferred in the LDAP protocol.
Syntaxes that are required for directory operation, or that are in
common use, are specified in this section. Servers SHOULD recognize
@@ -297,23 +219,32 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
implementations typically do not have the ability to dynamically
recognize new syntaxes.
+
+
+
+
+Legg Standards Track [Page 4]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
3.1. General Considerations
The description of each syntax specifies how attribute or assertion
- values conforming to the syntax are to be represented when transfered
- in the LDAP protocol [PROT]. This representation is referred to as
- the LDAP-specific encoding to distinguish it from other methods of
- encoding attribute values (e.g., the Basic Encoding Rules (BER)
- encoding [BER] used by X.500 [X.500] directories).
+ values conforming to the syntax are to be represented when
+ transferred in the LDAP protocol [RFC4511]. This representation is
+ referred to as the LDAP-specific encoding to distinguish it from
+ other methods of encoding attribute values (e.g., the Basic Encoding
+ Rules (BER) encoding [BER] used by X.500 [X.500] directories).
The LDAP-specific encoding of a given attribute syntax always
produces octet-aligned values. To the greatest extent possible,
encoding rules for LDAP syntaxes should produce character strings
that can be displayed with little or no translation by clients
- implementing LDAP. However, clients MUST NOT assume that the
- LDAP-specific encoding of a value of an unrecognized syntax is a
- human-readable character string. There are a few cases (e.g., the
- JPEG syntax) when it is not reasonable to produce a human-readable
+ implementing LDAP. However, clients MUST NOT assume that the LDAP-
+ specific encoding of a value of an unrecognized syntax is a human-
+ readable character string. There are a few cases (e.g., the JPEG
+ syntax) when it is not reasonable to produce a human-readable
representation.
Each LDAP syntax is uniquely identified with an object identifier
@@ -326,24 +257,17 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
attribute value with a string-based syntax, or the number of octets
in a value for all other syntaxes, MAY be indicated by appending the
bound inside of curly braces following the syntax's OBJECT IDENTIFIER
- in an attribute type definition (see the <noidlen> rule in [MODELS]).
- Such a bound is not considered part of the syntax identifier.
+ in an attribute type definition (see the <noidlen> rule in
+ [RFC4512]). Such a bound is not considered part of the syntax
+ identifier.
For example, "1.3.6.1.4.1.1466.115.121.1.15{64}" in an attribute
definition suggests that the directory server will allow a value of
the attribute to be up to 64 characters long, although it may allow
-
-
-
-Legg Expires 23 December 2005 [Page 6]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
longer character strings. Note that a single character of the
- Directory String syntax can be encoded in more than one octet since
- UTF-8 [UTF8] is a variable-length encoding. Therefore a 64 character
- string may be more than 64 octets in length.
+ Directory String syntax can be encoded in more than one octet, since
+ UTF-8 [RFC3629] is a variable-length encoding. Therefore, a 64-
+ character string may be more than 64 octets in length.
3.2. Common Definitions
@@ -352,6 +276,14 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN /
PLUS / COMMA / HYPHEN / DOT / EQUALS /
+
+
+
+Legg Standards Track [Page 5]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
SLASH / COLON / QUESTION / SPACE
PrintableString = 1*PrintableCharacter
IA5String = *(%x00-7F)
@@ -360,7 +292,8 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
QUESTION = %x3F ; question mark ("?")
The <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>, <COMMA>,
- <HYPHEN>, <DOT>, <EQUALS> and <SPACE> rules are defined in [MODELS].
+ <HYPHEN>, <DOT>, <EQUALS>, and <SPACE> rules are defined in
+ [RFC4512].
3.3. Syntax Definitions
@@ -368,13 +301,14 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
A value of the Attribute Type Description syntax is the definition of
an attribute type. The LDAP-specific encoding of a value of this
- syntax is defined by the <AttributeTypeDescription> rule in [MODELS].
+ syntax is defined by the <AttributeTypeDescription> rule in
+ [RFC4512].
For example, the following definition of the createTimestamp
- attribute type from [MODELS] is also a value of the Attribute Type
- Description syntax (note: line breaks have been added for
- readability - they are not part of the value when transfered in
- protocol).
+ attribute type from [RFC4512] is also a value of the Attribute
+ Type Description syntax. (Note: Line breaks have been added for
+ readability; they are not part of the value when transferred in
+ protocol.)
( 2.5.18.1 NAME 'createTimestamp'
EQUALITY generalizedTimeMatch
@@ -388,14 +322,6 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' )
This syntax corresponds to the AttributeTypeDescription ASN.1 type
-
-
-
-Legg Expires 23 December 2005 [Page 7]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
from [X.501].
3.3.2. Bit String
@@ -407,7 +333,14 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
BitString = SQUOTE *binary-digit SQUOTE "B"
binary-digit = "0" / "1"
- The <SQUOTE> rule is defined in [MODELS].
+
+
+Legg Standards Track [Page 6]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ The <SQUOTE> rule is defined in [RFC4512].
Example:
'0101111101'B
@@ -435,8 +368,8 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
3.3.4. Country String
A value of the Country String syntax is one of the two-character
- codes from ISO 3166 [ISO3166] for representing a country. The
- LDAP-specific encoding of a value of this syntax is defined by the
+ codes from ISO 3166 [ISO3166] for representing a country. The LDAP-
+ specific encoding of a value of this syntax is defined by the
following ABNF:
CountryString = 2(PrintableCharacter)
@@ -445,13 +378,6 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
Examples:
-
-
-Legg Expires 23 December 2005 [Page 8]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
US
AU
@@ -463,6 +389,13 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
PrintableString (SIZE (2)) -- ISO 3166 codes only
+
+
+Legg Standards Track [Page 7]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
3.3.5. Delivery Method
A value of the Delivery Method syntax is a sequence of items that
@@ -475,7 +408,7 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
pdm = "any" / "mhs" / "physical" / "telex" / "teletex" /
"g3fax" / "g4fax" / "ia5" / "videotex" / "telephone"
- The <WSP> and <DOLLAR> rules are defined in [MODELS].
+ The <WSP> and <DOLLAR> rules are defined in [RFC4512].
Example:
telephone $ videotex
@@ -500,23 +433,24 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
3.3.6. Directory String
+ A value of the Directory String syntax is a string of one or more
+ arbitrary characters from the Universal Character Set (UCS) [UCS]. A
+ zero-length character string is not permitted. The LDAP-specific
+ encoding of a value of this syntax is the UTF-8 encoding [RFC3629] of
+ the character string. Such encodings conform to the following ABNF:
+
+ DirectoryString = 1*UTF8
+ The <UTF8> rule is defined in [RFC4512].
-Legg Expires 23 December 2005 [Page 9]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
- A value of the Directory String syntax is a string of one or more
- arbitrary characters from the Universal Character Set (UCS) [UCS]. A
- zero length character string is not permitted. The LDAP-specific
- encoding of a value of this syntax is the UTF-8 encoding [UTF8] of
- the character string. Such encodings conform to the following ABNF:
- DirectoryString = 1*UTF8
+Legg Standards Track [Page 8]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
- The <UTF8> rule is defined in [MODELS].
Example:
This is a value of Directory String containing #!%#@.
@@ -538,43 +472,42 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
type from [X.520].
The DirectoryString ASN.1 type allows a choice between the
- TeletexString, PrintableString or UniversalString ASN.1 types from
+ TeletexString, PrintableString, or UniversalString ASN.1 types from
[ASN.1]. However, note that the chosen alternative is not indicated
in the LDAP-specific encoding of a Directory String value.
- Implementations which convert Directory String values from the
- LDAP-specific encoding to the BER encoding used by X.500 must choose
- an alternative that permits the particular characters in the string,
- and must convert the characters from the UTF-8 encoding into the
+ Implementations that convert Directory String values from the LDAP-
+ specific encoding to the BER encoding used by X.500 must choose an
+ alternative that permits the particular characters in the string and
+ must convert the characters from the UTF-8 encoding into the
character encoding of the chosen alternative. When converting
Directory String values from the BER encoding to the LDAP-specific
- encoding the characters must be converted from the character encoding
- of the chosen alternative into the UTF-8 encoding. These conversions
- SHOULD be done in a manner consistent with the Transcode step of the
- string preparation algorithms [PREP] for LDAP.
+ encoding, the characters must be converted from the character
+ encoding of the chosen alternative into the UTF-8 encoding. These
+ conversions SHOULD be done in a manner consistent with the Transcode
+ step of the string preparation algorithms [RFC4518] for LDAP.
3.3.7. DIT Content Rule Description
A value of the DIT Content Rule Description syntax is the definition
-
-
-
-Legg Expires 23 December 2005 [Page 10]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- of a DIT (Directory Information Tree) content rule. The
- LDAP-specific encoding of a value of this syntax is defined by the
- <DITContentRuleDescription> rule in [MODELS].
+ of a DIT (Directory Information Tree) content rule. The LDAP-
+ specific encoding of a value of this syntax is defined by the
+ <DITContentRuleDescription> rule in [RFC4512].
Example:
( 2.5.6.4 DESC 'content rule for organization'
NOT ( x121Address $ telexNumber ) )
- Note: a line break has been added for readability - it is not part
+ Note: A line break has been added for readability; it is not part
of the value.
+
+
+Legg Standards Track [Page 9]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
The LDAP definition for the DIT Content Rule Description syntax is:
( 1.3.6.1.4.1.1466.115.121.1.16
@@ -588,7 +521,7 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
A value of the DIT Structure Rule Description syntax is the
definition of a DIT structure rule. The LDAP-specific encoding of a
value of this syntax is defined by the <DITStructureRuleDescription>
- rule in [MODELS].
+ rule in [RFC4512].
Example:
( 2 DESC 'organization structure rule' FORM 2.5.15.3 )
@@ -604,22 +537,14 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
3.3.9. DN
A value of the DN syntax is the (purported) distinguished name (DN)
- of an entry [MODELS]. The LDAP-specific encoding of a value of this
+ of an entry [RFC4512]. The LDAP-specific encoding of a value of this
syntax is defined by the <distinguishedName> rule from the string
- representation of distinguished names [LDAPDN].
+ representation of distinguished names [RFC4514].
- Examples (from [LDAPDN]):
+ Examples (from [RFC4514]):
UID=jsmith,DC=example,DC=net
OU=Sales+CN=J. Smith,DC=example,DC=net
CN=John Smith\, III,DC=example,DC=net
-
-
-
-Legg Expires 23 December 2005 [Page 11]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
CN=Before\0dAfter,DC=example,DC=net
1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com
CN=Lu\C4\8Di\C4\87
@@ -631,6 +556,14 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
The DN syntax corresponds to the DistinguishedName ASN.1 type from
[X.501]. Note that a BER encoded distinguished name (as used by
X.500) re-encoded into the LDAP-specific encoding is not necessarily
+
+
+
+Legg Standards Track [Page 10]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
reversible to the original BER encoding since the chosen string type
in any DirectoryString components of the distinguished name is not
indicated in the LDAP-specific encoding of the distinguished name
@@ -666,29 +599,29 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
AMPERSAND = %x26 ; ampersand ("&")
EXCLAIM = %x21 ; exclamation mark ("!")
- The <SHARP>, <WSP>, <oid>, <LPAREN>, <RPAREN>, <attributetype> and
- <DOLLAR> rules are defined in [MODELS].
-
-
-
-Legg Expires 23 December 2005 [Page 12]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
+ The <SHARP>, <WSP>, <oid>, <LPAREN>, <RPAREN>, <attributetype>, and
+ <DOLLAR> rules are defined in [RFC4512].
The LDAP definition for the Enhanced Guide syntax is:
( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' )
-
Example:
person#(sn$EQ)#oneLevel
The Enhanced Guide syntax corresponds to the EnhancedGuide ASN.1 type
from [X.520]. The EnhancedGuide type references the Criteria ASN.1
- type, also from [X.520]. The <true> rule above represents an empty
- "and" expression in a value of the Criteria type. The <false> rule
- above represents an empty "or" expression in a value of the Criteria
+ type, also from [X.520]. The <true> rule, above, represents an empty
+
+
+
+Legg Standards Track [Page 11]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ "and" expression in a value of the Criteria type. The <false> rule,
+ above, represents an empty "or" expression in a value of the Criteria
type.
3.3.11. Facsimile Telephone Number
@@ -711,7 +644,8 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
The <telephone-number> is a string of printable characters that
complies with the internationally agreed format for representing
international telephone numbers [E.123]. The <PrintableString> rule
- is defined in Section 3.2. The <DOLLAR> rule is defined in [MODELS].
+ is defined in Section 3.2. The <DOLLAR> rule is defined in
+ [RFC4512].
The LDAP definition for the Facsimile Telephone Number syntax is:
@@ -722,16 +656,8 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
3.3.12. Fax
- A value of the Fax syntax is an image which is produced using the
+ A value of the Fax syntax is an image that is produced using the
Group 3 facsimile process [FAX] to duplicate an object, such as a
-
-
-
-Legg Expires 23 December 2005 [Page 13]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
memo. The LDAP-specific encoding of a value of this syntax is the
string of octets for a Group 3 Fax image as defined in [FAX].
@@ -742,6 +668,14 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
The ASN.1 type corresponding to the Fax syntax is defined as follows,
assuming EXPLICIT TAGS:
+
+
+
+Legg Standards Track [Page 12]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
Fax ::= CHOICE {
g3-facsimile [3] G3FacsimileBodyPart
}
@@ -779,31 +713,32 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
g-differential = ( MINUS / PLUS ) hour [ minute ]
MINUS = %x2D ; minus sign ("-")
- The <DOT>, <COMMA> and <PLUS> rules are defined in [MODELS].
-
-
-
-Legg Expires 23 December 2005 [Page 14]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
+ The <DOT>, <COMMA>, and <PLUS> rules are defined in [RFC4512].
- The above ABNF allows character strings which do not represent valid
+ The above ABNF allows character strings that do not represent valid
dates (in the Gregorian calendar) and/or valid times (e.g., February
31, 1994). Such character strings SHOULD be considered invalid for
this syntax.
The time value represents coordinated universal time (equivalent to
- Greenwich Mean Time) if the "Z" form of <g-time-zone> is used,
- otherwise the value represents a local time in the time zone
+ Greenwich Mean Time) if the "Z" form of <g-time-zone> is used;
+ otherwise, the value represents a local time in the time zone
indicated by <g-differential>. In the latter case, coordinated
+
+
+
+Legg Standards Track [Page 13]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
universal time can be calculated by subtracting the differential from
the local time. The "Z" form of <g-time-zone> SHOULD be used in
preference to <g-differential>.
- If <minute> is omitted then <fraction> represents a fraction of an
- hour, otherwise if <second> and <leap-second> are omitted then
- <fraction> represents a fraction of a minute, otherwise <fraction>
+ If <minute> is omitted, then <fraction> represents a fraction of an
+ hour; otherwise, if <second> and <leap-second> are omitted, then
+ <fraction> represents a fraction of a minute; otherwise, <fraction>
represents a fraction of a second.
Examples:
@@ -835,24 +770,27 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
Guide = [ object-class SHARP ] criteria
The <object-class> and <criteria> rules are defined in Section
- 3.3.10. The <SHARP> rule is defined in [MODELS].
+ 3.3.10. The <SHARP> rule is defined in [RFC4512].
+ The LDAP definition for the Guide syntax is:
+ ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' )
+
+ The Guide syntax corresponds to the Guide ASN.1 type from [X.520].
-Legg Expires 23 December 2005 [Page 15]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
- The LDAP definition for the Guide syntax is:
- ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' )
- The Guide syntax corresponds to the Guide ASN.1 type from [X.520].
+
+Legg Standards Track [Page 14]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
3.3.15. IA5 String
- A value of the IA5 String syntax is a string of zero, one or more
+ A value of the IA5 String syntax is a string of zero, one, or more
characters from International Alphabet 5 (IA5) [T.50], the
international version of the ASCII character set. The LDAP-specific
encoding of a value of this syntax is the unconverted string of
@@ -869,14 +807,14 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
A value of the Integer syntax is a whole number of unlimited
magnitude. The LDAP-specific encoding of a value of this syntax is
the optionally signed decimal digit character string representation
- of the number (so, for example, the number 1321 is represented by the
+ of the number (for example, the number 1321 is represented by the
character string "1321"). The encoding is defined by the following
ABNF:
Integer = ( HYPHEN LDIGIT *DIGIT ) / number
- The <HYPHEN>, <LDIGIT>, <DIGIT> and <number> rules are defined in
- [MODELS].
+ The <HYPHEN>, <LDIGIT>, <DIGIT>, and <number> rules are defined in
+ [RFC4512].
The LDAP definition for the Integer syntax is:
@@ -893,16 +831,18 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
The LDAP definition for the JPEG syntax is:
+ ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )
+
+ The JPEG syntax corresponds to the following ASN.1 type:
-Legg Expires 23 December 2005 [Page 16]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
- ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )
- The JPEG syntax corresponds to the following ASN.1 type:
+Legg Standards Track [Page 15]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
JPEG ::= OCTET STRING (CONSTRAINED BY
{ -- contents octets are an image in the --
@@ -912,7 +852,7 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
A value of the LDAP Syntax Description syntax is the description of
an LDAP syntax. The LDAP-specific encoding of a value of this syntax
- is defined by the <SyntaxDescription> rule in [MODELS].
+ is defined by the <SyntaxDescription> rule in [RFC4512].
The LDAP definition for the LDAP Syntax Description syntax is:
@@ -937,37 +877,36 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
A value of the Matching Rule Description syntax is the definition of
a matching rule. The LDAP-specific encoding of a value of this
- syntax is defined by the <MatchingRuleDescription> rule in [MODELS].
+ syntax is defined by the <MatchingRuleDescription> rule in [RFC4512].
Example:
( 2.5.13.2 NAME 'caseIgnoreMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
- Note: a line break has been added for readability - it is not part of
+ Note: A line break has been added for readability; it is not part of
the syntax.
The LDAP definition for the Matching Rule Description syntax is:
+ ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' )
+ This syntax corresponds to the MatchingRuleDescription ASN.1 type
+ from [X.501].
-Legg Expires 23 December 2005 [Page 17]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
- ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' )
+Legg Standards Track [Page 16]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
- This syntax corresponds to the MatchingRuleDescription ASN.1 type
- from [X.501].
3.3.20. Matching Rule Use Description
A value of the Matching Rule Use Description syntax indicates the
attribute types to which a matching rule may be applied in an
- extensibleMatch search filter [PROT]. The LDAP-specific encoding of
- a value of this syntax is defined by the <MatchingRuleUseDescription>
- rule in [MODELS].
+ extensibleMatch search filter [RFC4511]. The LDAP-specific encoding
+ of a value of this syntax is defined by the
+ <MatchingRuleUseDescription> rule in [RFC4512].
Example:
( 2.5.13.16 APPLIES ( givenName $ surname ) )
@@ -983,7 +922,7 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
3.3.21. Name and Optional UID
A value of the Name and Optional UID syntax is the distinguished name
- [MODELS] of an entity optionally accompanied by a unique identifier
+ [RFC4512] of an entity optionally accompanied by a unique identifier
that serves to differentiate the entity from others with an identical
distinguished name.
@@ -993,8 +932,8 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
NameAndOptionalUID = distinguishedName [ SHARP BitString ]
The <BitString> rule is defined in Section 3.3.2. The
- <distinguishedName> rule is defined in [LDAPDN]. The <SHARP> rule is
- defined in [MODELS].
+ <distinguishedName> rule is defined in [RFC4514]. The <SHARP> rule
+ is defined in [RFC4512].
Note that although the '#' character may occur in the string
representation of a distinguished name, no additional escaping of
@@ -1004,17 +943,18 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
Example:
1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B
+ The LDAP definition for the Name and Optional UID syntax is:
+ ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' )
-Legg Expires 23 December 2005 [Page 18]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
- The LDAP definition for the Name and Optional UID syntax is:
- ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' )
+Legg Standards Track [Page 17]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
This syntax corresponds to the NameAndOptionalUID ASN.1 type from
[X.520].
@@ -1022,9 +962,9 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
3.3.22. Name Form Description
A value of the Name Form Description syntax is the definition of a
- name form, which regulates how entries may be named. The
- LDAP-specific encoding of a value of this syntax is defined by the
- <NameFormDescription> rule in [MODELS].
+ name form, which regulates how entries may be named. The LDAP-
+ specific encoding of a value of this syntax is defined by the
+ <NameFormDescription> rule in [RFC4512].
Example:
( 2.5.15.3 NAME 'orgNameForm' OC organization MUST o )
@@ -1045,7 +985,7 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
NumericString = 1*(DIGIT / SPACE)
- The <DIGIT> and <SPACE> rules are defined in [MODELS].
+ The <DIGIT> and <SPACE> rules are defined in [RFC4512].
Example:
15 079 672 281
@@ -1060,21 +1000,23 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
A value of the Object Class Description syntax is the definition of
an object class. The LDAP-specific encoding of a value of this
+ syntax is defined by the <ObjectClassDescription> rule in [RFC4512].
+
-Legg Expires 23 December 2005 [Page 19]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
- syntax is defined by the <ObjectClassDescription> rule in [MODELS].
+Legg Standards Track [Page 18]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
Example:
( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c
MAY ( searchGuide $ description ) )
- Note: a line break has been added for readability - it is not part of
+ Note: A line break has been added for readability; it is not part of
the syntax.
The LDAP definition for the Object Class Description syntax is:
@@ -1086,14 +1028,14 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
3.3.25. Octet String
- A value of the Octet String syntax is a sequence of zero, one or more
- arbitrary octets. The LDAP-specific encoding of a value of this
+ A value of the Octet String syntax is a sequence of zero, one, or
+ more arbitrary octets. The LDAP-specific encoding of a value of this
syntax is the unconverted sequence of octets, which conforms to the
following ABNF:
OctetString = *OCTET
- The <OCTET> rule is defined in [MODELS]. Values of this syntax are
+ The <OCTET> rule is defined in [RFC4512]. Values of this syntax are
not generally human-readable.
The LDAP definition for the Octet String syntax is:
@@ -1104,27 +1046,27 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
3.3.26. OID
- A value of the OID syntax is an object identifier; a sequence of two
+ A value of the OID syntax is an object identifier: a sequence of two
or more non-negative integers that uniquely identify some object or
item of specification. Many of the object identifiers used in LDAP
- also have IANA registered names [RFC3383].
+ also have IANA registered names [RFC4520].
The LDAP-specific encoding of a value of this syntax is defined by
- the <oid> rule in [MODELS].
+ the <oid> rule in [RFC4512].
Examples:
1.2.3.4
cn
+ The LDAP definition for the OID syntax is:
-Legg Expires 23 December 2005 [Page 20]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+Legg Standards Track [Page 19]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
- The LDAP definition for the OID syntax is:
( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' )
@@ -1142,10 +1084,10 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
mailbox = IA5String
The <mailbox-type> rule represents the type of mail system in which
- the mailbox resides, for example "MCIMail", and <mailbox> is the
+ the mailbox resides (for example, "MCIMail"), and <mailbox> is the
actual mailbox in the mail system described by <mailbox-type>. The
<PrintableString> and <IA5String> rules are defined in Section 3.2.
- The <DOLLAR> rule is defined in [MODELS].
+ The <DOLLAR> rule is defined in [RFC4512].
The LDAP definition for the Other Mailbox syntax is:
@@ -1168,28 +1110,34 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
The LDAP-specific encoding of a value of this syntax is defined by
the following ABNF:
- PostalAddress = line *( DOLLAR line )
- line = 1*line-char
- line-char = %x00-23
- / (%x5C "24") ; escaped "$"
-Legg Expires 23 December 2005 [Page 21]
+
+
+
+
+
+
+Legg Standards Track [Page 20]
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+ PostalAddress = line *( DOLLAR line )
+ line = 1*line-char
+ line-char = %x00-23
+ / (%x5C "24") ; escaped "$"
/ %x25-5B
/ (%x5C "5C") ; escaped "\"
/ %x5D-7F
/ UTFMB
Each character string (i.e., <line>) of a postal address value is
- encoded as a UTF-8 [UTF8] string except that "\" and "$" characters,
- if they occur in the string, are escaped by a "\" character followed
- by the two hexadecimal digit code for the character. The <DOLLAR>
- and <UTFMB> rules are defined in [MODELS].
+ encoded as a UTF-8 [RFC3629] string, except that "\" and "$"
+ characters, if they occur in the string, are escaped by a "\"
+ character followed by the two hexadecimal digit code for the
+ character. The <DOLLAR> and <UTFMB> rules are defined in [RFC4512].
Many servers limit the postal address to no more than six lines of no
more than thirty characters each.
@@ -1202,8 +1150,8 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' )
- This syntax corresponds to the PostalAddress ASN.1 type from [X.520],
- i.e.,
+ This syntax corresponds to the PostalAddress ASN.1 type from [X.520];
+ that is
PostalAddress ::= SEQUENCE SIZE(1..ub-postal-line) OF
DirectoryString { ub-postal-string }
@@ -1224,29 +1172,29 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
Example:
This is a PrintableString.
- The LDAP definition for the PrintableString syntax is:
- ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )
+Legg Standards Track [Page 21]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
-Legg Expires 23 December 2005 [Page 22]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+ The LDAP definition for the PrintableString syntax is:
+ ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )
This syntax corresponds to the PrintableString ASN.1 type from
[ASN.1].
3.3.30. Substring Assertion
- A value of the Substring Assertion syntax is a sequence of zero, one
+ A value of the Substring Assertion syntax is a sequence of zero, one,
or more character substrings used as an argument for substring
- extensible matching of character string attribute values, i.e., as
- the matchValue of a MatchingRuleAssertion [PROT]. Each substring is
- a string of one or more arbitrary characters from the Universal
- Character Set (UCS) [UCS]. A zero length substring is not permitted.
+ extensible matching of character string attribute values; i.e., as
+ the matchValue of a MatchingRuleAssertion [RFC4511]. Each substring
+ is a string of one or more arbitrary characters from the Universal
+ Character Set (UCS) [UCS]. A zero-length substring is not permitted.
The LDAP-specific encoding of a value of this syntax is defined by
the following ABNF:
@@ -1267,31 +1215,32 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
/ UTFMB
Each <substring> of a Substring Assertion value is encoded as a UTF-8
- [UTF8] string, except that "\" and "*" characters, if they occur in
- the substring, are escaped by a "\" character followed by the two
+ [RFC3629] string, except that "\" and "*" characters, if they occur
+ in the substring, are escaped by a "\" character followed by the two
hexadecimal digit code for the character.
The Substring Assertion syntax is used only as the syntax of
assertion values in the extensible match. It is not used as an
- attribute syntax, or in the SubstringFilter [PROT].
+ attribute syntax, or in the SubstringFilter [RFC4511].
The LDAP definition for the Substring Assertion syntax is:
( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' )
- This syntax corresponds to the SubstringAssertion ASN.1 type from
- [X.520].
-
-3.3.31. Telephone Number
-Legg Expires 23 December 2005 [Page 23]
+Legg Standards Track [Page 22]
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+ This syntax corresponds to the SubstringAssertion ASN.1 type from
+ [X.520].
+
+3.3.31. Telephone Number
+
A value of the Telephone Number syntax is a string of printable
characters that complies with the internationally agreed format for
representing international telephone numbers [E.123].
@@ -1335,18 +1284,18 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
/ (%x5C "24") ; escaped "$"
/ %x25-5B
/ (%x5C "5C") ; escaped "\"
- / %x5D-FF
- The <PrintableString> and <COLON> rules are defined in Section 3.2.
- The <DOLLAR> rule is defined in [MODELS].
+Legg Standards Track [Page 23]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
-Legg Expires 23 December 2005 [Page 24]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+ / %x5D-FF
+ The <PrintableString> and <COLON> rules are defined in Section 3.2.
+ The <DOLLAR> rule is defined in [RFC4512].
The LDAP definition for the Teletex Terminal Identifier syntax is:
@@ -1359,7 +1308,7 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
3.3.33. Telex Number
A value of the Telex Number syntax specifies the telex number,
- country code and answerback code of a telex terminal.
+ country code, and answerback code of a telex terminal.
The LDAP-specific encoding of a value of this syntax is defined by
the following ABNF:
@@ -1371,7 +1320,7 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
answerback = PrintableString
The <PrintableString> rule is defined in Section 3.2. The <DOLLAR>
- rule is defined in [MODELS].
+ rule is defined in [RFC4512].
The LDAP definition for the Telex Number syntax is:
@@ -1391,29 +1340,30 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
[ u-time-zone ]
u-time-zone = %x5A ; "Z"
/ u-differential
- u-differential = ( MINUS / PLUS ) hour minute
-
- The <year>, <month>, <day>, <hour>, <minute>, <second> and <MINUS>
- rules are defined in Section 3.3.13. The <PLUS> rule is defined in
- [MODELS].
-Legg Expires 23 December 2005 [Page 25]
+Legg Standards Track [Page 24]
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ u-differential = ( MINUS / PLUS ) hour minute
+ The <year>, <month>, <day>, <hour>, <minute>, <second>, and <MINUS>
+ rules are defined in Section 3.3.13. The <PLUS> rule is defined in
+ [RFC4512].
- The above ABNF allows character strings which do not represent valid
+ The above ABNF allows character strings that do not represent valid
dates (in the Gregorian calendar) and/or valid times. Such character
strings SHOULD be considered invalid for this syntax.
The time value represents coordinated universal time if the "Z" form
- of <u-time-zone> is used, otherwise the value represents a local
- time. In the latter case, if <u-differential> is provided then
+ of <u-time-zone> is used; otherwise, the value represents a local
+ time. In the latter case, if <u-differential> is provided, then
coordinated universal time can be calculated by subtracting the
differential from the local time. The <u-time-zone> SHOULD be
- present in time values and the "Z" form of <u-time-zone> SHOULD be
+ present in time values, and the "Z" form of <u-time-zone> SHOULD be
used in preference to <u-differential>.
The LDAP definition for the UTC Time syntax is:
@@ -1430,8 +1380,8 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
Matching rules are used by directory implementations to compare
attribute values against assertion values when performing Search and
- Compare operations [PROT]. They are also used when comparing a
- purported distinguished name [MODELS] with the name of an entry.
+ Compare operations [RFC4511]. They are also used when comparing a
+ purported distinguished name [RFC4512] with the name of an entry.
When modifying entries, matching rules are used to identify values to
be deleted and to prevent an attribute from containing two equal
values.
@@ -1442,33 +1392,33 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
4.1. General Considerations
A matching rule is applied to attribute values through an
- AttributeValueAssertion or MatchingRuleAssertion [PROT]. The
+ AttributeValueAssertion or MatchingRuleAssertion [RFC4511]. The
conditions under which an AttributeValueAssertion or
MatchingRuleAssertion evaluates to Undefined are specified elsewhere
- [PROT]. If an assertion is not Undefined then the result of the
- assertion is the result of applying the selected matching rule. A
- matching rule evaluates to TRUE, and in some cases Undefined, as
- specified in the description of the matching rule, otherwise it
- evaluates to FALSE.
-
- Each assertion contains an assertion value. The definition of each
+ [RFC4511]. If an assertion is not Undefined, then the result of the
-Legg Expires 23 December 2005 [Page 26]
+Legg Standards Track [Page 25]
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+ assertion is the result of applying the selected matching rule. A
+ matching rule evaluates to TRUE, and in some cases Undefined, as
+ specified in the description of the matching rule; otherwise, it
+ evaluates to FALSE.
+ Each assertion contains an assertion value. The definition of each
matching rule specifies the syntax for the assertion value. The
syntax of the assertion value is typically, but not necessarily, the
same as the syntax of the attribute values to which the matching rule
may be applied. Note that an AssertionValue in a SubstringFilter
- [PROT] conforms to the assertion syntax of the equality matching rule
- for the attribute type rather than the assertion syntax of the
- substrings matching rule for the attribute type. Conceptually, the
- entire SubstringFilter is converted into an assertion value of the
- substrings matching rule prior to applying the rule.
+ [RFC4511] conforms to the assertion syntax of the equality matching
+ rule for the attribute type rather than to the assertion syntax of
+ the substrings matching rule for the attribute type. Conceptually,
+ the entire SubstringFilter is converted into an assertion value of
+ the substrings matching rule prior to applying the rule.
The definition of each matching rule indicates the attribute syntaxes
to which the rule may be applied, by specifying conditions the
@@ -1476,46 +1426,46 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
satisfy. These conditions are also satisfied if the corresponding
ASN.1 type is a tagged or constrained derivative of the ASN.1 type
explicitly mentioned in the rule description (i.e., ASN.1 tags and
- constraints are ignored in checking applicability), or an alternative
- reference notation for the explicitly mentioned type. Each rule
- description lists as examples of applicable attribute syntaxes, the
- complete list of the syntaxes defined in this document to which the
- matching rule applies. A matching rule may be applicable to
- additional syntaxes defined in other documents if those syntaxes
- satisfy the conditions on the corresponding ASN.1 type.
+ constraints are ignored in checking applicability), or is an
+ alternative reference notation for the explicitly mentioned type.
+ Each rule description lists, as examples of applicable attribute
+ syntaxes, the complete list of the syntaxes defined in this document
+ to which the matching rule applies. A matching rule may be
+ applicable to additional syntaxes defined in other documents if those
+ syntaxes satisfy the conditions on the corresponding ASN.1 type.
The description of each matching rule indicates whether the rule is
suitable for use as the equality matching rule (EQUALITY), ordering
- matching rule (ORDERING) or substrings matching rule (SUBSTR) in an
- attribute type definition [MODELS].
+ matching rule (ORDERING), or substrings matching rule (SUBSTR) in an
+ attribute type definition [RFC4512].
Each matching rule is uniquely identified with an object identifier.
- The definition of a matching rule should not be subsequently changed.
- If a change is desirable then a new matching rule with a different
+ The definition of a matching rule should not subsequently be changed.
+ If a change is desirable, then a new matching rule with a different
object identifier should be defined instead.
Servers MAY implement the wordMatch and keywordMatch matching rules,
- but SHOULD implement the other matching rules in Section 4.2.
+ but they SHOULD implement the other matching rules in Section 4.2.
Servers MAY implement additional matching rules.
- Servers which implement the extensibleMatch filter SHOULD allow the
+ Servers that implement the extensibleMatch filter SHOULD allow the
matching rules listed in Section 4.2 to be used in the
extensibleMatch filter and SHOULD allow matching rules to be used
with all attribute types known to the server, where the assertion
- syntax of the matching rule is the same as the value syntax of the
- attribute.
-
- Servers MUST publish in the matchingRules attribute, the definitions
- of matching rules referenced by values of the attributeTypes and
- matchingRuleUse attributes in the same subschema entry. Other
-Legg Expires 23 December 2005 [Page 27]
+Legg Standards Track [Page 26]
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+ syntax of the matching rule is the same as the value syntax of the
+ attribute.
+ Servers MUST publish, in the matchingRules attribute, the definitions
+ of matching rules referenced by values of the attributeTypes and
+ matchingRuleUse attributes in the same subschema entry. Other
unreferenced matching rules MAY be published in the matchingRules
attribute.
@@ -1527,7 +1477,7 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
4.2. Matching Rule Definitions
Nominated character strings in assertion and attribute values are
- prepared according to the string preparation algorithms [PREP] for
+ prepared according to the string preparation algorithms [RFC4518] for
LDAP when evaluating the following matching rules:
numericStringMatch,
@@ -1548,9 +1498,9 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
telephoneNumberSubstringsMatch and
wordMatch.
- The Transcode, Normalize, Prohibit and Check bidi steps are the same
+ The Transcode, Normalize, Prohibit, and Check bidi steps are the same
for each of the matching rules. However, the Map and Insignificant
- Character Handling steps depends on the specific rule, as detailed in
+ Character Handling steps depend on the specific rule, as detailed in
the description of these matching rules in the sections that follow.
4.2.1. bitStringMatch
@@ -1559,21 +1509,21 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
syntax to an attribute value of a syntax (e.g., the Bit String
syntax) whose corresponding ASN.1 type is BIT STRING.
- If the corresponding ASN.1 type of the attribute syntax does not have
- a named bit list [ASN.1] (which is the case for the Bit String
- syntax) then the rule evaluates to TRUE if and only if the attribute
- value has the same number of bits as the assertion value and the bits
- match on a bitwise basis.
-
-Legg Expires 23 December 2005 [Page 28]
+Legg Standards Track [Page 27]
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+ If the corresponding ASN.1 type of the attribute syntax does not have
+ a named bit list [ASN.1] (which is the case for the Bit String
+ syntax), then the rule evaluates to TRUE if and only if the attribute
+ value has the same number of bits as the assertion value and the bits
+ match on a bitwise basis.
- If the corresponding ASN.1 type does have a named bit list then
- bitStringMatch operates as above except that trailing zero bits in
+ If the corresponding ASN.1 type does have a named bit list, then
+ bitStringMatch operates as above, except that trailing zero bits in
the attribute and assertion values are treated as absent.
The LDAP definition for the bitStringMatch rule is:
@@ -1602,7 +1552,7 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
4.2.3. caseExactIA5Match
The caseExactIA5Match rule compares an assertion value of the IA5
- String syntax to an attribute value of a syntax (e.g the IA5 String
+ String syntax to an attribute value of a syntax (e.g., the IA5 String
syntax) whose corresponding ASN.1 type is IA5String.
The rule evaluates to TRUE if and only if the prepared attribute
@@ -1615,18 +1565,17 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
Insignificant Space Handling is applied in the Insignificant
Character Handling step.
- The LDAP definition for the caseExactIA5Match rule is:
-
- ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+Legg Standards Track [Page 28]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
-Legg Expires 23 December 2005 [Page 29]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+ The LDAP definition for the caseExactIA5Match rule is:
+ ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
The caseExactIA5Match rule is an equality matching rule.
@@ -1634,9 +1583,9 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
The caseExactMatch rule compares an assertion value of the Directory
String syntax to an attribute value of a syntax (e.g., the Directory
- String, Printable String, Country String or Telephone Number syntax)
+ String, Printable String, Country String, or Telephone Number syntax)
whose corresponding ASN.1 type is DirectoryString or one of the
- alternative string types of DirectoryString, e.g., PrintableString
+ alternative string types of DirectoryString, such as PrintableString
(the other alternatives do not correspond to any syntax defined in
this document).
@@ -1661,28 +1610,30 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
The caseExactOrderingMatch rule compares an assertion value of the
Directory String syntax to an attribute value of a syntax (e.g., the
- Directory String, Printable String, Country String or Telephone
+ Directory String, Printable String, Country String, or Telephone
Number syntax) whose corresponding ASN.1 type is DirectoryString or
one of its alternative string types.
- The rule evaluates to TRUE if, and only if, in the code point
+ The rule evaluates to TRUE if and only if, in the code point
collation order, the prepared attribute value character string
- appears earlier than the prepared assertion value character string,
+ appears earlier than the prepared assertion value character string;
i.e., the attribute value is "less than" the assertion value.
- In preparing the attribute value and assertion value for comparison,
- characters are not case folded in the Map preparation step, and only
- Insignificant Space Handling is applied in the Insignificant
- Character Handling step.
- The LDAP definition for the caseExactOrderingMatch rule is:
-Legg Expires 23 December 2005 [Page 30]
+Legg Standards Track [Page 29]
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ In preparing the attribute value and assertion value for comparison,
+ characters are not case folded in the Map preparation step, and only
+ Insignificant Space Handling is applied in the Insignificant
+ Character Handling step.
+ The LDAP definition for the caseExactOrderingMatch rule is:
( 2.5.13.6 NAME 'caseExactOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
@@ -1693,16 +1644,16 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
The caseExactSubstringsMatch rule compares an assertion value of the
Substring Assertion syntax to an attribute value of a syntax (e.g.,
- the Directory String, Printable String, Country String or Telephone
+ the Directory String, Printable String, Country String, or Telephone
Number syntax) whose corresponding ASN.1 type is DirectoryString or
one of its alternative string types.
- The rule evaluates to TRUE if and only if the prepared substrings of
- the assertion value match disjoint portions of the prepared attribute
- value character string in the order of the substrings in the
- assertion value, and an <initial> substring, if present, matches the
- beginning of the prepared attribute value character string, and a
- <final> substring, if present, matches the end of the prepared
+ The rule evaluates to TRUE if and only if (1) the prepared substrings
+ of the assertion value match disjoint portions of the prepared
+ attribute value character string in the order of the substrings in
+ the assertion value, (2) an <initial> substring, if present, matches
+ the beginning of the prepared attribute value character string, and
+ (3) a <final> substring, if present, matches the end of the prepared
attribute value character string. A prepared substring matches a
portion of the prepared attribute value character string if
corresponding characters have the same code point.
@@ -1722,9 +1673,17 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
4.2.7. caseIgnoreIA5Match
The caseIgnoreIA5Match rule compares an assertion value of the IA5
- String syntax to an attribute value of a syntax (e.g the IA5 String
+ String syntax to an attribute value of a syntax (e.g., the IA5 String
syntax) whose corresponding ASN.1 type is IA5String.
+
+
+
+Legg Standards Track [Page 30]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
The rule evaluates to TRUE if and only if the prepared attribute
value character string and the prepared assertion value character
string have the same number of characters and corresponding
@@ -1732,14 +1691,6 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
In preparing the attribute value and assertion value for comparison,
characters are case folded in the Map preparation step, and only
-
-
-
-Legg Expires 23 December 2005 [Page 31]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
Insignificant Space Handling is applied in the Insignificant
Character Handling step.
@@ -1753,15 +1704,16 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
4.2.8. caseIgnoreIA5SubstringsMatch
The caseIgnoreIA5SubstringsMatch rule compares an assertion value of
- the Substring Assertion syntax to an attribute value of a syntax (e.g
- the IA5 String syntax) whose corresponding ASN.1 type is IA5String.
-
- The rule evaluates to TRUE if and only if the prepared substrings of
- the assertion value match disjoint portions of the prepared attribute
- value character string in the order of the substrings in the
- assertion value, and an <initial> substring, if present, matches the
- beginning of the prepared attribute value character string, and a
- <final> substring, if present, matches the end of the prepared
+ the Substring Assertion syntax to an attribute value of a syntax
+ (e.g., the IA5 String syntax) whose corresponding ASN.1 type is
+ IA5String.
+
+ The rule evaluates to TRUE if and only if (1) the prepared substrings
+ of the assertion value match disjoint portions of the prepared
+ attribute value character string in the order of the substrings in
+ the assertion value, (2) an <initial> substring, if present, matches
+ the beginning of the prepared attribute value character string, and
+ (3) a <final> substring, if present, matches the end of the prepared
attribute value character string. A prepared substring matches a
portion of the prepared attribute value character string if
corresponding characters have the same code point.
@@ -1780,6 +1732,14 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
The caseIgnoreListMatch rule compares an assertion value that is a
sequence of strings to an attribute value of a syntax (e.g., the
+
+
+
+Legg Standards Track [Page 31]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
Postal Address syntax) whose corresponding ASN.1 type is a SEQUENCE
OF the DirectoryString ASN.1 type.
@@ -1788,24 +1748,16 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
strings (by position) match according to the caseIgnoreMatch matching
rule.
-
-
-
-Legg Expires 23 December 2005 [Page 32]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- In [X.520] the assertion syntax for this matching rule is defined to
+ In [X.520], the assertion syntax for this matching rule is defined to
be:
SEQUENCE OF DirectoryString {ub-match}
- i.e., different from the corresponding type for the Postal Address
- syntax. The choice of the Postal Address syntax for the assertion
- syntax of the caseIgnoreListMatch in LDAP should not be seen as
- limiting the matching rule to only apply to attributes with the
- Postal Address syntax.
+ That is, it is different from the corresponding type for the Postal
+ Address syntax. The choice of the Postal Address syntax for the
+ assertion syntax of the caseIgnoreListMatch in LDAP should not be
+ seen as limiting the matching rule to apply only to attributes with
+ the Postal Address syntax.
The LDAP definition for the caseIgnoreListMatch rule is:
@@ -1836,23 +1788,23 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
The LDAP definition for the caseIgnoreListSubstringsMatch rule is:
( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
- The caseIgnoreListSubstringsMatch rule is a substrings matching rule.
-4.2.11. caseIgnoreMatch
- The caseIgnoreMatch rule compares an assertion value of the Directory
- String syntax to an attribute value of a syntax (e.g., the Directory
+Legg Standards Track [Page 32]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
-Legg Expires 23 December 2005 [Page 33]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+ The caseIgnoreListSubstringsMatch rule is a substrings matching rule.
+4.2.11. caseIgnoreMatch
- String, Printable String, Country String or Telephone Number syntax)
+ The caseIgnoreMatch rule compares an assertion value of the Directory
+ String syntax to an attribute value of a syntax (e.g., the Directory
+ String, Printable String, Country String, or Telephone Number syntax)
whose corresponding ASN.1 type is DirectoryString or one of its
alternative string types.
@@ -1877,13 +1829,13 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
The caseIgnoreOrderingMatch rule compares an assertion value of the
Directory String syntax to an attribute value of a syntax (e.g., the
- Directory String, Printable String, Country String or Telephone
+ Directory String, Printable String, Country String, or Telephone
Number syntax) whose corresponding ASN.1 type is DirectoryString or
one of its alternative string types.
- The rule evaluates to TRUE if, and only if, in the code point
+ The rule evaluates to TRUE if and only if, in the code point
collation order, the prepared attribute value character string
- appears earlier than the prepared assertion value character string,
+ appears earlier than the prepared assertion value character string;
i.e., the attribute value is "less than" the assertion value.
In preparing the attribute value and assertion value for comparison,
@@ -1893,33 +1845,32 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
The LDAP definition for the caseIgnoreOrderingMatch rule is:
- ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- The caseIgnoreOrderingMatch rule is an ordering matching rule.
-4.2.13. caseIgnoreSubstringsMatch
+Legg Standards Track [Page 33]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+ ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-Legg Expires 23 December 2005 [Page 34]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+ The caseIgnoreOrderingMatch rule is an ordering matching rule.
+4.2.13. caseIgnoreSubstringsMatch
The caseIgnoreSubstringsMatch rule compares an assertion value of the
Substring Assertion syntax to an attribute value of a syntax (e.g.,
- the Directory String, Printable String, Country String or Telephone
+ the Directory String, Printable String, Country String, or Telephone
Number syntax) whose corresponding ASN.1 type is DirectoryString or
one of its alternative string types.
- The rule evaluates to TRUE if and only if the prepared substrings of
- the assertion value match disjoint portions of the prepared attribute
- value character string in the order of the substrings in the
- assertion value, and an <initial> substring, if present, matches the
- beginning of the prepared attribute value character string, and a
- <final> substring, if present, matches the end of the prepared
+ The rule evaluates to TRUE if and only if (1) the prepared substrings
+ of the assertion value match disjoint portions of the prepared
+ attribute value character string in the order of the substrings in
+ the assertion value, (2) an <initial> substring, if present, matches
+ the beginning of the prepared attribute value character string, and
+ (3) a <final> substring, if present, matches the end of the prepared
attribute value character string. A prepared substring matches a
portion of the prepared attribute value character string if
corresponding characters have the same code point.
@@ -1947,6 +1898,16 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
attribute syntax of attributes for which this is the equality
matching rule.
+
+
+
+
+
+Legg Standards Track [Page 34]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
The rule evaluates to TRUE if and only if the assertion value matches
the first component of the attribute value using the rules of
caseIgnoreMatch.
@@ -1957,13 +1918,6 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
( 2.5.13.31 NAME 'directoryStringFirstComponentMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
-
-Legg Expires 23 December 2005 [Page 35]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
The directoryStringFirstComponentMatch rule is an equality matching
rule. When using directoryStringFirstComponentMatch to compare two
attribute values (of an applicable syntax), an assertion value must
@@ -2000,26 +1954,29 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
The distinguishedNameMatch rule is an equality matching rule.
+
+
+
+
+
+Legg Standards Track [Page 35]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
4.2.16. generalizedTimeMatch
The generalizedTimeMatch rule compares an assertion value of the
- Generalized Time syntax to an attribute value of a syntax (e.g the
+ Generalized Time syntax to an attribute value of a syntax (e.g., the
Generalized Time syntax) whose corresponding ASN.1 type is
GeneralizedTime.
The rule evaluates to TRUE if and only if the attribute value
represents the same universal coordinated time as the assertion
- value. If a time is specified with the minutes or seconds absent
+ value. If a time is specified with the minutes or seconds absent,
then the number of minutes or seconds (respectively) is assumed to be
zero.
-
-
-Legg Expires 23 December 2005 [Page 36]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
The LDAP definition for the generalizedTimeMatch rule is:
( 2.5.13.27 NAME 'generalizedTimeMatch'
@@ -2031,11 +1988,11 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
The generalizedTimeOrderingMatch rule compares the time ordering of
an assertion value of the Generalized Time syntax to an attribute
- value of a syntax (e.g the Generalized Time syntax) whose
+ value of a syntax (e.g., the Generalized Time syntax) whose
corresponding ASN.1 type is GeneralizedTime.
The rule evaluates to TRUE if and only if the attribute value
- represents a universal coordinated time which is earlier than the
+ represents a universal coordinated time that is earlier than the
universal coordinated time represented by the assertion value.
The LDAP definition for the generalizedTimeOrderingMatch rule is:
@@ -2048,11 +2005,21 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
4.2.18. integerFirstComponentMatch
The integerFirstComponentMatch rule compares an assertion value of
- the Integer syntax to an attribute value of a syntax (e.g the DIT
+ the Integer syntax to an attribute value of a syntax (e.g., the DIT
Structure Rule Description syntax) whose corresponding ASN.1 type is
a SEQUENCE with a mandatory first component of the INTEGER ASN.1
type.
+
+
+
+
+
+Legg Standards Track [Page 36]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
Note that the assertion syntax of this matching rule differs from the
attribute syntax of attributes for which this is the equality
matching rule.
@@ -2068,14 +2035,6 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
The integerFirstComponentMatch rule is an equality matching rule.
When using integerFirstComponentMatch to compare two attribute values
-
-
-
-Legg Expires 23 December 2005 [Page 37]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
(of an applicable syntax), an assertion value must first be derived
from one of the attribute values. An assertion value can be derived
from an attribute value by taking the first component of that
@@ -2084,7 +2043,7 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
4.2.19. integerMatch
The integerMatch rule compares an assertion value of the Integer
- syntax to an attribute value of a syntax (e.g the Integer syntax)
+ syntax to an attribute value of a syntax (e.g., the Integer syntax)
whose corresponding ASN.1 type is INTEGER.
The rule evaluates to TRUE if and only if the attribute value and the
@@ -2100,14 +2059,23 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
4.2.20. integerOrderingMatch
The integerOrderingMatch rule compares an assertion value of the
- Integer syntax to an attribute value of a syntax (e.g the Integer
+ Integer syntax to an attribute value of a syntax (e.g., the Integer
syntax) whose corresponding ASN.1 type is INTEGER.
The rule evaluates to TRUE if and only if the integer value of the
- attribute value is less than the integer value the assertion value.
+ attribute value is less than the integer value of the assertion
+ value.
The LDAP definition for the integerOrderingMatch matching rule is:
+
+
+
+Legg Standards Track [Page 37]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
( 2.5.13.15 NAME 'integerOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
@@ -2124,14 +2092,6 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
identification of keywords in the attribute value and the exactness
of the match are both implementation specific.
-
-
-
-Legg Expires 23 December 2005 [Page 38]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
The LDAP definition for the keywordMatch rule is:
( 2.5.13.33 NAME 'keywordMatch'
@@ -2140,7 +2100,7 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
4.2.22. numericStringMatch
The numericStringMatch rule compares an assertion value of the
- Numeric String syntax to an attribute value of a syntax (e.g the
+ Numeric String syntax to an attribute value of a syntax (e.g., the
Numeric String syntax) whose corresponding ASN.1 type is
NumericString.
@@ -2161,16 +2121,27 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
The numericStringMatch rule is an equality matching rule.
+
+
+
+
+
+
+Legg Standards Track [Page 38]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
4.2.23. numericStringOrderingMatch
The numericStringOrderingMatch rule compares an assertion value of
- the Numeric String syntax to an attribute value of a syntax (e.g the
- Numeric String syntax) whose corresponding ASN.1 type is
+ the Numeric String syntax to an attribute value of a syntax (e.g.,
+ the Numeric String syntax) whose corresponding ASN.1 type is
NumericString.
- The rule evaluates to TRUE if, and only if, in the code point
+ The rule evaluates to TRUE if and only if, in the code point
collation order, the prepared attribute value character string
- appears earlier than the prepared assertion value character string,
+ appears earlier than the prepared assertion value character string;
i.e., the attribute value is "less than" the assertion value.
In preparing the attribute value and assertion value for comparison,
@@ -2180,15 +2151,7 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
The rule is identical to the caseIgnoreOrderingMatch rule except that
all space characters are skipped during comparison (case is
-
-
-
-Legg Expires 23 December 2005 [Page 39]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- irrelevant as characters are numeric).
+ irrelevant as the characters are numeric).
The LDAP definition for the numericStringOrderingMatch matching rule
is:
@@ -2201,22 +2164,30 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
4.2.24. numericStringSubstringsMatch
The numericStringSubstringsMatch rule compares an assertion value of
- the Substring Assertion syntax to an attribute value of a syntax (e.g
- the Numeric String syntax) whose corresponding ASN.1 type is
+ the Substring Assertion syntax to an attribute value of a syntax
+ (e.g., the Numeric String syntax) whose corresponding ASN.1 type is
NumericString.
- The rule evaluates to TRUE if and only if the prepared substrings of
- the assertion value match disjoint portions of the prepared attribute
- value character string in the order of the substrings in the
- assertion value, and an <initial> substring, if present, matches the
- beginning of the prepared attribute value character string, and a
- <final> substring, if present, matches the end of the prepared
+ The rule evaluates to TRUE if and only if (1) the prepared substrings
+ of the assertion value match disjoint portions of the prepared
+ attribute value character string in the order of the substrings in
+ the assertion value, (2) an <initial> substring, if present, matches
+ the beginning of the prepared attribute value character string, and
+ (3) a <final> substring, if present, matches the end of the prepared
attribute value character string. A prepared substring matches a
portion of the prepared attribute value character string if
corresponding characters have the same code point.
In preparing the attribute value and assertion value for comparison,
characters are not case folded in the Map preparation step, and only
+
+
+
+Legg Standards Track [Page 39]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
numericString Insignificant Character Handling is applied in the
Insignificant Character Handling step.
@@ -2231,19 +2202,11 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
4.2.25. objectIdentifierFirstComponentMatch
The objectIdentifierFirstComponentMatch rule compares an assertion
- value of the OID syntax to an attribute value of a syntax (e.g the
+ value of the OID syntax to an attribute value of a syntax (e.g., the
Attribute Type Description, DIT Content Rule Description, LDAP Syntax
Description, Matching Rule Description, Matching Rule Use
- Description, Name Form Description or Object Class Description
+ Description, Name Form Description, or Object Class Description
syntax) whose corresponding ASN.1 type is a SEQUENCE with a mandatory
-
-
-
-Legg Expires 23 December 2005 [Page 40]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
first component of the OBJECT IDENTIFIER ASN.1 type.
Note that the assertion syntax of this matching rule differs from the
@@ -2270,17 +2233,25 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
4.2.26. objectIdentifierMatch
The objectIdentifierMatch rule compares an assertion value of the OID
- syntax to an attribute value of a syntax (e.g the OID syntax) whose
+ syntax to an attribute value of a syntax (e.g., the OID syntax) whose
corresponding ASN.1 type is OBJECT IDENTIFIER.
+
+
+
+Legg Standards Track [Page 40]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
The rule evaluates to TRUE if and only if the assertion value and the
- attribute value represent the same object identifier, that is, the
+ attribute value represent the same object identifier; that is, the
same sequence of integers, whether represented explicitly in the
<numericoid> form of <oid> or implicitly in the <descr> form (see
- [MODELS]).
+ [RFC4512]).
- If an LDAP client supplies an assertion value in the <descr> form,
- and the chosen descriptor is not recognized by the server, then the
+ If an LDAP client supplies an assertion value in the <descr> form and
+ the chosen descriptor is not recognized by the server, then the
objectIdentifierMatch rule evaluates to Undefined.
The LDAP definition for the objectIdentifierMatch matching rule is:
@@ -2292,18 +2263,10 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
4.2.27. octetStringMatch
-
-
-
-Legg Expires 23 December 2005 [Page 41]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
The octetStringMatch rule compares an assertion value of the Octet
- String syntax to an attribute value of a syntax (e.g the Octet String
- or JPEG syntax) whose corresponding ASN.1 type is the OCTET STRING
- ASN.1 type.
+ String syntax to an attribute value of a syntax (e.g., the Octet
+ String or JPEG syntax) whose corresponding ASN.1 type is the OCTET
+ STRING ASN.1 type.
The rule evaluates to TRUE if and only if the attribute value and the
assertion value are the same length and corresponding octets (by
@@ -2319,9 +2282,9 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
4.2.28. octetStringOrderingMatch
The octetStringOrderingMatch rule compares an assertion value of the
- Octet String syntax to an attribute value of a syntax (e.g the Octet
- String or JPEG syntax) whose corresponding ASN.1 type is the OCTET
- STRING ASN.1 type.
+ Octet String syntax to an attribute value of a syntax (e.g., the
+ Octet String or JPEG syntax) whose corresponding ASN.1 type is the
+ OCTET STRING ASN.1 type.
The rule evaluates to TRUE if and only if the attribute value appears
earlier in the collation order than the assertion value. The rule
@@ -2329,9 +2292,17 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
from the most significant bit to the least significant bit within the
octet. The first occurrence of a different bit determines the
ordering of the strings. A zero bit precedes a one bit. If the
+
+
+
+Legg Standards Track [Page 41]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
strings contain different numbers of octets but the longer string is
identical to the shorter string up to the length of the shorter
- string then the shorter string precedes the longer string.
+ string, then the shorter string precedes the longer string.
The LDAP definition for the octetStringOrderingMatch matching rule
is:
@@ -2344,18 +2315,10 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
4.2.29. telephoneNumberMatch
The telephoneNumberMatch rule compares an assertion value of the
- Telephone Number syntax to an attribute value of a syntax (e.g the
+ Telephone Number syntax to an attribute value of a syntax (e.g., the
Telephone Number syntax) whose corresponding ASN.1 type is a
PrintableString representing a telephone number.
-
-
-
-Legg Expires 23 December 2005 [Page 42]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
The rule evaluates to TRUE if and only if the prepared attribute
value character string and the prepared assertion value character
string have the same number of characters and corresponding
@@ -2377,15 +2340,23 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
The telephoneNumberSubstringsMatch rule compares an assertion value
of the Substring Assertion syntax to an attribute value of a syntax
- (e.g the Telephone Number syntax) whose corresponding ASN.1 type is a
- PrintableString representing a telephone number.
+ (e.g., the Telephone Number syntax) whose corresponding ASN.1 type is
+ a PrintableString representing a telephone number.
+
+ The rule evaluates to TRUE if and only if (1) the prepared substrings
+ of the assertion value match disjoint portions of the prepared
+ attribute value character string in the order of the substrings in
+ the assertion value, (2) an <initial> substring, if present, matches
+ the beginning of the prepared attribute value character string, and
+
+
- The rule evaluates to TRUE if and only if the prepared substrings of
- the assertion value match disjoint portions of the prepared attribute
- value character string in the order of the substrings in the
- assertion value, and an <initial> substring, if present, matches the
- beginning of the prepared attribute value character string, and a
- <final> substring, if present, matches the end of the prepared
+Legg Standards Track [Page 42]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ (3) a <final> substring, if present, matches the end of the prepared
attribute value character string. A prepared substring matches a
portion of the prepared attribute value character string if
corresponding characters have the same code point.
@@ -2404,29 +2375,21 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
The telephoneNumberSubstringsMatch rule is a substrings matching
rule.
-
-
-
-Legg Expires 23 December 2005 [Page 43]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
4.2.31. uniqueMemberMatch
The uniqueMemberMatch rule compares an assertion value of the Name
- And Optional UID syntax to an attribute value of a syntax (e.g the
+ And Optional UID syntax to an attribute value of a syntax (e.g., the
Name And Optional UID syntax) whose corresponding ASN.1 type is
NameAndOptionalUID.
The rule evaluates to TRUE if and only if the <distinguishedName>
components of the assertion value and attribute value match according
- to the distinguishedNameMatch rule and either, the <BitString>
+ to the distinguishedNameMatch rule and either, (1) the <BitString>
component is absent from both the attribute value and assertion
- value, or the <BitString> component is present in both the attribute
- value and the assertion value and the <BitString> component of the
- assertion value matches the <BitString> component of the attribute
- value according to the bitStringMatch rule.
+ value, or (2) the <BitString> component is present in both the
+ attribute value and the assertion value and the <BitString> component
+ of the assertion value matches the <BitString> component of the
+ attribute value according to the bitStringMatch rule.
Note that this matching rule has been altered from its description in
X.520 [X.520] in order to make the matching rule commutative. Server
@@ -2441,6 +2404,14 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
The uniqueMemberMatch rule is an equality matching rule.
+
+
+
+Legg Standards Track [Page 43]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
4.2.32. wordMatch
The wordMatch rule compares an assertion value of the Directory
@@ -2460,33 +2431,25 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
5. Security Considerations
In general, the LDAP-specific encodings for syntaxes defined in this
-
-
-
-Legg Expires 23 December 2005 [Page 44]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
document do not define canonical encodings. That is, a
transformation from an LDAP-specific encoding into some other
encoding (e.g., BER) and back into the LDAP-specific encoding will
- not necessarily reproduce exactly the original octets of the
- LDAP-specific encoding. Therefore an LDAP-specific encoding should
- not be used where a canonical encoding is required.
+ not necessarily reproduce exactly the original octets of the LDAP-
+ specific encoding. Therefore, an LDAP-specific encoding should not
+ be used where a canonical encoding is required.
Furthermore, the LDAP-specific encodings do not necessarily enable an
alternative encoding of values of the Directory String and DN
- syntaxes to be reconstructed, e.g., a transformation from a
+ syntaxes to be reconstructed; e.g., a transformation from a
Distinguished Encoding Rules (DER) [BER] encoding to an LDAP-specific
encoding and back to a DER encoding may not reproduce the original
- DER encoding. Therefore LDAP-specific encodings should not be used
- where reversibility to DER is needed, e.g., for the verification of
+ DER encoding. Therefore, LDAP-specific encodings should not be used
+ where reversibility to DER is needed; e.g., for the verification of
digital signatures. Instead, DER or a DER-reversible encoding should
be used.
- When interpreting security-sensitive fields, and in particular fields
- used to grant or deny access, implementations MUST ensure that any
+ When interpreting security-sensitive fields (in particular, fields
+ used to grant or deny access), implementations MUST ensure that any
matching rule comparisons are done on the underlying abstract value,
regardless of the particular encoding used.
@@ -2496,16 +2459,24 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
Coulbeck, T. Howes, and S. Kille. RFC 2252 was a product of the IETF
ASID Working Group.
- This document is based upon input of the IETF LDAPBIS working group.
+
+
+
+
+Legg Standards Track [Page 44]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ This document is based on input from the IETF LDAPBIS working group.
The author would like to thank Kathy Dally for editing the early
- drafts of this revision, and Jim Sermersheim and Kurt Zeilenga for
+ drafts of this document, and Jim Sermersheim and Kurt Zeilenga for
their significant contributions to this revision.
7. IANA Considerations
- The Internet Assigned Numbers Authority (IANA) is requested to update
- the LDAP descriptors registry [BCP64] as indicated by the following
- templates:
+ The Internet Assigned Numbers Authority (IANA) has updated the LDAP
+ descriptors registry [BCP64] as indicated by the following templates:
Subject: Request for LDAP Descriptor Registration Update
Descriptor (short name): see comment
@@ -2513,19 +2484,8 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
Person & email address to contact for further information:
Steven Legg <steven.legg@eb2bcom.com>
Usage: see comment
- Specification: RFC XXXX
+ Specification: RFC 4517
Author/Change Controller: IESG
- Comments:
-
-
-
-Legg Expires 23 December 2005 [Page 45]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- The following descriptors (short names) should be updated to refer
- to RFC XXXX.
NAME Type OID
------------------------------------------------------------------
@@ -2556,36 +2516,181 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
octetStringMatch M 2.5.13.17
octetStringOrderingMatch M 2.5.13.18
telephoneNumberMatch M 2.5.13.20
+
+
+
+Legg Standards Track [Page 45]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
telephoneNumberSubstringsMatch M 2.5.13.21
uniqueMemberMatch M 2.5.13.23
wordMatch M 2.5.13.32
The descriptor for the object identifier 2.5.13.0 was incorrectly
- registered as objectIdentifiersMatch (extraneous `s') in BCP 64.
- It should be changed to the following with a reference to
- RFC XXXX.
+ registered as objectIdentifiersMatch (extraneous \`s') in BCP 64.
+ It has been changed to the following, with a reference to
+ RFC 4517.
NAME Type OID
------------------------------------------------------------------
objectIdentifierMatch M 2.5.13.0
-
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): caseIgnoreIA5SubstringsMatch
+ Object Identifier: 1.3.6.1.4.1.1466.109.114.3
+ Person & email address to contact for further information:
+ Steven Legg <steven.legg@eb2bcom.com>
+ Usage: other (M)
+ Specification: RFC 4517
+ Author/Change Controller: IESG
+
+8. References
+
+8.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003.
+ [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 4234, October 2005.
-Legg Expires 23 December 2005 [Page 46]
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Technical Specification Road Map", RFC 4510, June
+ 2006.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+
+
+
+
+
+Legg Standards Track [Page 46]
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): String Representation of Distinguished Names", RFC
+ 4514, June 2006.
+
+ [RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Internationalized String Preparation", RFC 4518,
+ June 2006.
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+ [E.123] Notation for national and international telephone numbers,
+ ITU-T Recommendation E.123, 1988.
+
+ [FAX] Standardization of Group 3 facsimile apparatus for
+ document transmission - Terminal Equipment and Protocols
+ for Telematic Services, ITU-T Recommendation T.4, 1993
+
+ [T.50] International Reference Alphabet (IRA) (Formerly
+ International Alphabet No. 5 or IA5) Information
+ Technology - 7-Bit Coded Character Set for Information
+ Interchange, ITU-T Recommendation T.50, 1992
+
+ [X.420] ITU-T Recommendation X.420 (1996) | ISO/IEC 10021-7:1997,
+ Information Technology - Message Handling Systems (MHS):
+ Interpersonal messaging system
+
+ [X.501] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994,
+ Information Technology - Open Systems Interconnection -
+ The Directory: Models
+
+ [X.520] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994,
+ Information Technology - Open Systems Interconnection -
+ The Directory: Selected attribute types
+
+ [ASN.1] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002,
+ Information technology - Abstract Syntax Notation One
+ (ASN.1): Specification of basic notation
+
+ [ISO3166] ISO 3166, "Codes for the representation of names of
+ countries".
+
+ [ISO8601] ISO 8601:2004, "Data elements and interchange formats --
+ Information interchange -- Representation of dates and
+ times".
+
- Object Identifier: 1.3.6.1.4.1.1466.109.114.3
- Person & email address to contact for further information:
- Steven Legg <steven.legg@eb2bcom.com>
- Usage: other (M)
- Specification: RFC XXXX
- Author/Change Controller: IESG
+
+
+Legg Standards Track [Page 47]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
+ [UCS] Universal Multiple-Octet Coded Character Set (UCS) -
+ Architecture and Basic Multilingual Plane, ISO/IEC 10646-
+ 1: 1993 (with amendments).
+
+ [JPEG] JPEG File Interchange Format (Version 1.02). Eric
+ Hamilton, C-Cube Microsystems, Milpitas, CA, September 1,
+ 1992.
+
+8.2. Informative References
+
+ [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Schema for User Applications", RFC 4519, June
+ 2006.
+
+ [RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP) Schema Definitions for X.509 Certificates", RFC
+ 4523, June 2006.
+
+ [X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
+ Information Technology - Open Systems Interconnection -
+ The Directory: Overview of concepts, models and services
+
+ [BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1:2002,
+ Information technology - ASN.1 encoding rules:
+ Specification of Basic Encoding Rules (BER), Canonical
+ Encoding Rules (CER) and Distinguished Encoding Rules
+ (DER)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Legg Standards Track [Page 48]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
Appendix A. Summary of Syntax Object Identifiers
@@ -2629,29 +2734,31 @@ Appendix A. Summary of Syntax Object Identifiers
Telex Number 1.3.6.1.4.1.1466.115.121.1.52
UTC Time 1.3.6.1.4.1.1466.115.121.1.53
+Appendix B. Changes from RFC 2252
+ This annex lists the significant differences between this
+ specification and RFC 2252.
-Legg Expires 23 December 2005 [Page 47]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-Appendix B. Changes from RFC 2252
- This annex lists the significant differences between this
- specification and RFC 2252.
+
+Legg Standards Track [Page 49]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
This annex is provided for informational purposes only. It is not a
normative part of this specification.
1. The IESG Note has been removed.
- 2. The major part of Sections 4, 5 and 7 has been moved to [MODELS]
+ 2. The major part of Sections 4, 5 and 7 has been moved to [RFC4512]
and revised. Changes to the parts of these sections moved to
- [MODELS] are detailed in [MODELS].
+ [RFC4512] are detailed in [RFC4512].
3. BNF descriptions of syntax formats have been replaced by ABNF
- [ABNF] specifications.
+ [RFC4234] specifications.
4. The ambiguous statement in RFC 2252, Section 4.3 regarding the
use of a backslash quoting mechanism to escape separator symbols
@@ -2676,7 +2783,7 @@ Appendix B. Changes from RFC 2252
Number syntaxes are now required to have at least one character.
9. The <DITContentRuleDescription>, <NameFormDescription> and
- <DITStructureRuleDescription> rules have been moved to [MODELS].
+ <DITStructureRuleDescription> rules have been moved to [RFC4512].
10. The corresponding ASN.1 type for the Other Mailbox syntax has
been incorporated from RFC 1274.
@@ -2684,18 +2791,18 @@ Appendix B. Changes from RFC 2252
11. A corresponding ASN.1 type for the LDAP Syntax Description syntax
has been invented.
+ 12. The Binary syntax has been removed because it was not adequately
+ specified, implementations with different incompatible
+ interpretations exist, and it was confused with the ;binary
+ transfer encoding.
-Legg Expires 23 December 2005 [Page 48]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+Legg Standards Track [Page 50]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
- 12. The Binary syntax has been removed because it was not adequately
- specified, implementations with different incompatible
- interpretations exist, and it was confused with the ;binary
- transfer encoding.
13. All discussion of transfer options, including the ";binary"
option, has been removed. All imperatives regarding binary
@@ -2713,7 +2820,7 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
17. The PKI-related syntaxes (Certificate, Certificate List and
Certificate Pair) have been removed. They are reintroduced in
- [LDAP-PKI] (as is the Supported Algorithm syntax from RFC 2256).
+ [RFC4523] (as is the Supported Algorithm syntax from RFC 2256).
18. The MHS OR Address syntax has been removed since its
specification (in RFC 2156) is not at draft standard maturity.
@@ -2740,19 +2847,19 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
interpretation.
24. The caseIgnoreIA5SubstringsMatch matching rule from RFC 2798 has
+ been added.
+ 25. The caseIgnoreListSubstringsMatch, caseIgnoreOrderingMatch and
+ caseIgnoreSubstringsMatch matching rules have been added to the
+ list of matching rules for which the provisions for handling
-Legg Expires 23 December 2005 [Page 49]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+Legg Standards Track [Page 51]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
- been added.
- 25. The caseIgnoreListSubstringsMatch, caseIgnoreOrderingMatch and
- caseIgnoreSubstringsMatch matching rules have been added to the
- list of matching rules for which the provisions for handling
leading, trailing and multiple adjoining whitespace characters
apply (now through string preparation). This is consistent with
the definitions of these matching rules in X.500. The
@@ -2785,143 +2892,6 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
octetStringOrderingMatch and wordMatch matching rules from
RFC 3698 & X.520 have been added.
-Normative References
-
- [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", RFC 3629, November 2003.
-
- [BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
- Considerations for the Lightweight Directory Access
- Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
-
-
-
-Legg Expires 23 December 2005 [Page 50]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", draft-crocker-abnf-rfc2234bis-
- xx.txt, a work in progress, March 2005.
-
- [ROADMAP] Zeilenga, K., "Lightweight Directory Access Protocol
- (LDAP): Technical Specification Road Map", draft-ietf-
- ldapbis-roadmap-xx.txt, a work in progress, February 2005.
-
- [MODELS] Zeilenga, K., "LDAP: Directory Information Models", draft-
- ietf-ldapbis-models-xx.txt, a work in progress, February
- 2005.
-
- [PROT] Sermersheim, J., "LDAP: The Protocol", draft-ietf-ldapbis-
- protocol-xx.txt, a work in progress, May 2005.
-
- [LDAPDN] Zeilenga, K., "LDAP: String Representation of
- Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work
- in progress, February 2005.
-
- [PREP] Zeilenga, K., "LDAP: Internationalized String
- Preparation", draft-ietf-ldapbis-strprep-xx.txt, a work in
- progress, February 2005.
-
- [E.123] Notation for national and international telephone numbers,
- ITU-T Recommendation E.123, 1988.
-
- [FAX] Standardization of Group 3 facsimile apparatus for
- document transmission - Terminal Equipment and Protocols
- for Telematic Services, ITU-T Recommendation T.4, 1993
-
- [T.50] International Reference Alphabet (IRA) (Formerly
- International Alphabet No. 5 or IA5) Information
- Technology - 7-Bit Coded Character Set for Information
- Interchange, ITU-T Recommendation T.50, 1992
-
- [X.420] ITU-T Recommendation X.420 (1996) | ISO/IEC 10021-7:1997,
- Information Technology - Message Handling Systems (MHS):
- Interpersonal messaging system
-
- [X.501] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994,
- Information Technology - Open Systems Interconnection -
- The Directory: Models
-
- [X.520] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994,
- Information Technology - Open Systems Interconnection -
- The Directory: Selected attribute types
-
- [ASN.1] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002,
-
-
-
-Legg Expires 23 December 2005 [Page 51]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- Information technology - Abstract Syntax Notation One
- (ASN.1): Specification of basic notation
-
- [ISO3166] ISO 3166, "Codes for the representation of names of
- countries".
-
- [ISO8601] ISO 8601:2004, "Data elements and interchange formats --
- Information interchange -- Representation of dates and
- times".
-
- [UCS] Universal Multiple-Octet Coded Character Set (UCS) -
- Architecture and Basic Multilingual Plane, ISO/IEC
- 10646-1: 1993 (with amendments).
-
- [JPEG] JPEG File Interchange Format (Version 1.02). Eric
- Hamilton, C-Cube Microsystems, Milpitas, CA, September 1,
- 1992.
-
-Informative References
-
- [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
- "Lightweight Directory Access Protocol (v3): Attribute
- Syntax Definitions", RFC 2252, December 1997.
-
- [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
- with LDAPv3", RFC 2256, December 1997.
-
- [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
- Protocol (v3): Technical Specification", RFC 3377,
- September 2002.
-
- [RFC3698] Zeilenga, K., "Lightweight Directory Access Protocol
- (LDAP): Additional Matching Rules", RFC 3698, February
- 2004.
-
- [SCHEMA] Sciberras, A., "LDAP: Schema for User Applications",
- draft-ietf-ldapbis-user-schema-xx.txt, a work in progress,
- April 2005.
-
- [LDAP-PKI] Zeilenga, K. D., "Lightweight Directory Access Protocol
- (LDAP) schema definitions for X.509 Certificates", draft-
- zeilenga-ldap-x509-xx.txt, a work in progress, February
- 2005.
-
- [X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
- Information Technology - Open Systems Interconnection -
- The Directory: Overview of concepts, models and services
-
-
-
-
-Legg Expires 23 December 2005 [Page 52]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
- [BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1:2002,
- Information technology - ASN.1 encoding rules:
- Specification of Basic Encoding Rules (BER), Canonical
- Encoding Rules (CER) and Distinguished Encoding Rules
- (DER)
-
Author's Address
Steven Legg
@@ -2932,12 +2902,23 @@ Author's Address
AUSTRALIA
Phone: +61 3 9896 7830
- Fax: +61 3 9896 7801
+ Fax: +61 3 9896 7801
EMail: steven.legg@eb2bcom.com
+
+
+
+
+
+
+Legg Standards Track [Page 52]
+
+RFC 4517 LDAP: Syntaxes and Matching Rules June 2006
+
+
Full Copyright Statement
- Copyright (C) The Internet Society (2005).
+ Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
@@ -2964,14 +2945,6 @@ Intellectual Property
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
-
-
-
-Legg Expires 23 December 2005 [Page 53]
-
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
@@ -2983,7 +2956,10 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
+Acknowledgement
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
@@ -2991,37 +2967,5 @@ INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Legg Expires 23 December 2005 [Page 54]
+Legg Standards Track [Page 53]
diff --git a/doc/rfc/rfc4518.txt b/doc/rfc/rfc4518.txt
new file mode 100644
index 0000000000000000000000000000000000000000..f886bdfb5dc08668401ed7d6d01809ebcc9682a7
--- /dev/null
+++ b/doc/rfc/rfc4518.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 4518 OpenLDAP Foundation
+Category: Standards Track June 2006
+
+
+ Lightweight Directory Access Protocol (LDAP):
+ Internationalized String Preparation
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ The previous Lightweight Directory Access Protocol (LDAP) technical
+ specifications did not precisely define how character string matching
+ is to be performed. This led to a number of usability and
+ interoperability problems. This document defines string preparation
+ algorithms for character-based matching rules defined for use in
+ LDAP.
+
+1. Introduction
+
+1.1. Background
+
+ A Lightweight Directory Access Protocol (LDAP) [RFC4510] matching
+ rule [RFC4517] defines an algorithm for determining whether a
+ presented value matches an attribute value in accordance with the
+ criteria defined for the rule. The proposition may be evaluated to
+ True, False, or Undefined.
+
+ True - the attribute contains a matching value,
+
+ False - the attribute contains no matching value,
+
+ Undefined - it cannot be determined whether the attribute contains
+ a matching value.
+
+
+
+
+
+
+Zeilenga Standards Track [Page 1]
+
+RFC 4518 LDAP: Internationalized String Preparation June 2006
+
+
+ For instance, the caseIgnoreMatch matching rule may be used to
+ compare whether the commonName attribute contains a particular value
+ without regard for case and insignificant spaces.
+
+1.2. X.500 String Matching Rules
+
+ "X.520: Selected attribute types" [X.520] provides (among other
+ things) value syntaxes and matching rules for comparing values
+ commonly used in the directory [X.500]. These specifications are
+ inadequate for strings composed of Unicode [Unicode] characters.
+
+ The caseIgnoreMatch matching rule [X.520], for example, is simply
+ defined as being a case-insensitive comparison where insignificant
+ spaces are ignored. For printableString, there is only one space
+ character and case mapping is bijective, hence this definition is
+ sufficient. However, for Unicode string types such as
+ universalString, this is not sufficient. For example, a case-
+ insensitive matching implementation that folded lowercase characters
+ to uppercase would yield different results than an implementation
+ that used uppercase to lowercase folding. Or one implementation may
+ view space as referring to only SPACE (U+0020), a second
+ implementation may view any character with the space separator (Zs)
+ property as a space, and another implementation may view any
+ character with the whitespace (WS) category as a space.
+
+ The lack of precise specification for character string matching has
+ led to significant interoperability problems. When used in
+ certificate chain validation, security vulnerabilities can arise. To
+ address these problems, this document defines precise algorithms for
+ preparing character strings for matching.
+
+1.3. Relationship to "stringprep"
+
+ The character string preparation algorithms described in this
+ document are based upon the "stringprep" approach [RFC3454]. In
+ "stringprep", presented and stored values are first prepared for
+ comparison so that a character-by-character comparison yields the
+ "correct" result.
+
+ The approach used here is a refinement of the "stringprep" [RFC3454]
+ approach. Each algorithm involves two additional preparation steps.
+
+ a) Prior to applying the Unicode string preparation steps outlined in
+ "stringprep", the string is transcoded to Unicode.
+
+ b) After applying the Unicode string preparation steps outlined in
+ "stringprep", the string is modified to appropriately handle
+ characters insignificant to the matching rule.
+
+
+
+Zeilenga Standards Track [Page 2]
+
+RFC 4518 LDAP: Internationalized String Preparation June 2006
+
+
+ Hence, preparation of character strings for X.500 [X.500] matching
+ [X.501] involves the following steps:
+
+ 1) Transcode
+ 2) Map
+ 3) Normalize
+ 4) Prohibit
+ 5) Check Bidi (Bidirectional)
+ 6) Insignificant Character Handling
+
+ These steps are described in Section 2.
+
+ It is noted that while various tables of Unicode characters included
+ or referenced by this specification are derived from Unicode
+ [Unicode] data, these tables are to be considered definitive for the
+ purpose of implementing this specification.
+
+1.4. Relationship to the LDAP Technical Specification
+
+ This document is an integral part of the LDAP technical specification
+ [RFC4510], which obsoletes the previously defined LDAP technical
+ specification [RFC3377] in its entirety.
+
+ This document details new LDAP internationalized character string
+ preparation algorithms used by [RFC4517] and possible other technical
+ specifications defining LDAP syntaxes and/or matching rules.
+
+1.5. Relationship to X.500
+
+ LDAP is defined [RFC4510] in X.500 terms as an X.500 access
+ mechanism. As such, there is a strong desire for alignment between
+ LDAP and X.500 syntax and semantics. The character string
+ preparation algorithms described in this document are based upon
+ "Internationalized String Matching Rules for X.500" [XMATCH] proposal
+ to ITU/ISO Joint Study Group 2.
+
+1.6. Conventions and Terms
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+ Character names in this document use the notation for code points and
+ names from the Unicode Standard [Unicode]. For example, the letter
+ "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
+ In the lists of mappings and the prohibited characters, the "U+" is
+
+
+
+
+
+Zeilenga Standards Track [Page 3]
+
+RFC 4518 LDAP: Internationalized String Preparation June 2006
+
+
+ left off to make the lists easier to read. The comments for
+ character ranges are shown in square brackets (such as "[CONTROL
+ CHARACTERS]") and do not come from the standard.
+
+ Note: a glossary of terms used in Unicode can be found in [Glossary].
+ Information on the Unicode character encoding model can be found in
+ [CharModel].
+
+ The term "combining mark", as used in this specification, refers to
+ any Unicode [Unicode] code point that has a mark property (Mn, Mc,
+ Me). Appendix A provides a definitive list of combining marks.
+
+2. String Preparation
+
+ The following six-step process SHALL be applied to each presented and
+ attribute value in preparation for character string matching rule
+ evaluation.
+
+ 1) Transcode
+ 2) Map
+ 3) Normalize
+ 4) Prohibit
+ 5) Check bidi
+ 6) Insignificant Character Handling
+
+ Failure in any step causes the assertion to evaluate to Undefined.
+
+ The character repertoire of this process is Unicode 3.2 [Unicode].
+
+ Note that this six-step process specification is intended to describe
+ expected matching behavior. Implementations are free to use
+ alternative processes so long as the matching rule evaluation
+ behavior provided is consistent with the behavior described by this
+ specification.
+
+2.1. Transcode
+
+ Each non-Unicode string value is transcoded to Unicode.
+
+ PrintableString [X.680] values are transcoded directly to Unicode.
+
+ UniversalString, UTF8String, and bmpString [X.680] values need not be
+ transcoded as they are Unicode-based strings (in the case of
+ bmpString, a subset of Unicode).
+
+ TeletexString [X.680] values are transcoded to Unicode. As there is
+ no standard for mapping TeletexString values to Unicode, the mapping
+ is left a local matter.
+
+
+
+Zeilenga Standards Track [Page 4]
+
+RFC 4518 LDAP: Internationalized String Preparation June 2006
+
+
+ For these and other reasons, use of TeletexString is NOT RECOMMENDED.
+
+ The output is the transcoded string.
+
+2.2. Map
+
+ SOFT HYPHEN (U+00AD) and MONGOLIAN TODO SOFT HYPHEN (U+1806) code
+ points are mapped to nothing. COMBINING GRAPHEME JOINER (U+034F) and
+ VARIATION SELECTORs (U+180B-180D, FF00-FE0F) code points are also
+ mapped to nothing. The OBJECT REPLACEMENT CHARACTER (U+FFFC) is
+ mapped to nothing.
+
+ CHARACTER TABULATION (U+0009), LINE FEED (LF) (U+000A), LINE
+ TABULATION (U+000B), FORM FEED (FF) (U+000C), CARRIAGE RETURN (CR)
+ (U+000D), and NEXT LINE (NEL) (U+0085) are mapped to SPACE (U+0020).
+
+ All other control code (e.g., Cc) points or code points with a
+ control function (e.g., Cf) are mapped to nothing. The following is
+ a complete list of these code points: U+0000-0008, 000E-001F, 007F-
+ 0084, 0086-009F, 06DD, 070F, 180E, 200C-200F, 202A-202E, 2060-2063,
+ 206A-206F, FEFF, FFF9-FFFB, 1D173-1D17A, E0001, E0020-E007F.
+
+ ZERO WIDTH SPACE (U+200B) is mapped to nothing. All other code
+ points with Separator (space, line, or paragraph) property (e.g., Zs,
+ Zl, or Zp) are mapped to SPACE (U+0020). The following is a complete
+ list of these code points: U+0020, 00A0, 1680, 2000-200A, 2028-2029,
+ 202F, 205F, 3000.
+
+ For case ignore, numeric, and stored prefix string matching rules,
+ characters are case folded per B.2 of [RFC3454].
+
+ The output is the mapped string.
+
+2.3. Normalize
+
+ The input string is to be normalized to Unicode Form KC
+ (compatibility composed) as described in [UAX15]. The output is the
+ normalized string.
+
+2.4. Prohibit
+
+ All Unassigned code points are prohibited. Unassigned code points
+ are listed in Table A.1 of [RFC3454].
+
+ Characters that, per Section 5.8 of [RFC3454], change display
+ properties or are deprecated are prohibited. These characters are
+ listed in Table C.8 of [RFC3454].
+
+
+
+
+Zeilenga Standards Track [Page 5]
+
+RFC 4518 LDAP: Internationalized String Preparation June 2006
+
+
+ Private Use code points are prohibited. These characters are listed
+ in Table C.3 of [RFC3454].
+
+ All non-character code points are prohibited. These code points are
+ listed in Table C.4 of [RFC3454].
+
+ Surrogate codes are prohibited. These characters are listed in Table
+ C.5 of [RFC3454].
+
+ The REPLACEMENT CHARACTER (U+FFFD) code point is prohibited.
+
+ The step fails if the input string contains any prohibited code
+ point. Otherwise, the output is the input string.
+
+2.5. Check bidi
+
+ Bidirectional characters are ignored.
+
+2.6. Insignificant Character Handling
+
+ In this step, the string is modified to ensure proper handling of
+ characters insignificant to the matching rule. This modification
+ differs from matching rule to matching rule.
+
+ Section 2.6.1 applies to case ignore and exact string matching.
+ Section 2.6.2 applies to numericString matching.
+ Section 2.6.3 applies to telephoneNumber matching.
+
+2.6.1. Insignificant Space Handling
+
+ For the purposes of this section, a space is defined to be the SPACE
+ (U+0020) code point followed by no combining marks.
+
+ NOTE - The previous steps ensure that the string cannot contain
+ any code points in the separator class, other than SPACE
+ (U+0020).
+
+ For input strings that are attribute values or non-substring
+ assertion values: If the input string contains no non-space
+ character, then the output is exactly two SPACEs. Otherwise (the
+ input string contains at least one non-space character), the string
+ is modified such that the string starts with exactly one space
+ character, ends with exactly one SPACE character, and any inner
+ (non-empty) sequence of space characters is replaced with exactly two
+ SPACE characters. For instance, the input strings
+ "foo<SPACE>bar<SPACE><SPACE>", result in the output
+ "<SPACE>foo<SPACE><SPACE>bar<SPACE>".
+
+
+
+
+Zeilenga Standards Track [Page 6]
+
+RFC 4518 LDAP: Internationalized String Preparation June 2006
+
+
+ For input strings that are substring assertion values: If the string
+ being prepared contains no non-space characters, then the output
+ string is exactly one SPACE. Otherwise, the following steps are
+ taken:
+
+ - If the input string is an initial substring, it is modified to
+ start with exactly one SPACE character;
+
+ - If the input string is an initial or an any substring that ends in
+ one or more space characters, it is modified to end with exactly
+ one SPACE character;
+
+ - If the input string is an any or a final substring that starts in
+ one or more space characters, it is modified to start with exactly
+ one SPACE character; and
+
+ - If the input string is a final substring, it is modified to end
+ with exactly one SPACE character.
+
+ For instance, for the input string "foo<SPACE>bar<SPACE><SPACE>" as
+ an initial substring, the output would be
+ "<SPACE>foo<SPACE><SPACE>bar<SPACE>". As an any or final substring,
+ the same input would result in "foo<SPACE>bar<SPACE>".
+
+ Appendix B discusses the rationale for the behavior.
+
+2.6.2. numericString Insignificant Character Handling
+
+ For the purposes of this section, a space is defined to be the SPACE
+ (U+0020) code point followed by no combining marks.
+
+ All spaces are regarded as insignificant and are to be removed.
+
+ For example, removal of spaces from the Form KC string:
+ "<SPACE><SPACE>123<SPACE><SPACE>456<SPACE><SPACE>"
+ would result in the output string:
+ "123456"
+ and the Form KC string:
+ "<SPACE><SPACE><SPACE>"
+ would result in the output string:
+ "" (an empty string).
+
+2.6.3. telephoneNumber Insignificant Character Handling
+
+ For the purposes of this section, a hyphen is defined to be a
+ HYPHEN-MINUS (U+002D), ARMENIAN HYPHEN (U+058A), HYPHEN (U+2010),
+ NON-BREAKING HYPHEN (U+2011), MINUS SIGN (U+2212), SMALL HYPHEN-MINUS
+ (U+FE63), or FULLWIDTH HYPHEN-MINUS (U+FF0D) code point followed by
+
+
+
+Zeilenga Standards Track [Page 7]
+
+RFC 4518 LDAP: Internationalized String Preparation June 2006
+
+
+ no combining marks and a space is defined to be the SPACE (U+0020)
+ code point followed by no combining marks.
+
+ All hyphens and spaces are considered insignificant and are to be
+ removed.
+
+ For example, removal of hyphens and spaces from the Form KC string:
+ "<SPACE><HYPHEN>123<SPACE><SPACE>456<SPACE><HYPHEN>"
+ would result in the output string:
+ "123456"
+ and the Form KC string:
+ "<HYPHEN><HYPHEN><HYPHEN>"
+ would result in the (empty) output string:
+ "".
+
+3. Security Considerations
+
+ "Preparation of Internationalized Strings ("stringprep")" [RFC3454]
+ security considerations generally apply to the algorithms described
+ here.
+
+4. Acknowledgements
+
+ The approach used in this document is based upon design principles
+ and algorithms described in "Preparation of Internationalized Strings
+ ('stringprep')" [RFC3454] by Paul Hoffman and Marc Blanchet. Some
+ additional guidance was drawn from Unicode Technical Standards,
+ Technical Reports, and Notes.
+
+ This document is a product of the IETF LDAP Revision (LDAPBIS)
+ Working Group.
+
+5. References
+
+5.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
+ Internationalized Strings ("stringprep")", RFC 3454,
+ December 2002.
+
+ [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Technical Specification Road Map", RFC 4510,
+ June 2006.
+
+
+
+
+
+Zeilenga Standards Track [Page 8]
+
+RFC 4518 LDAP: Internationalized String Preparation June 2006
+
+
+ [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Syntaxes and Matching Rules", RFC 4517, June
+ 2006.
+
+ [Unicode] The Unicode Consortium, "The Unicode Standard, Version
+ 3.2.0" is defined by "The Unicode Standard, Version
+ 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
+ 61633-5), as amended by the "Unicode Standard Annex
+ #27: Unicode 3.1"
+ (http://www.unicode.org/reports/tr27/) and by the
+ "Unicode Standard Annex #28: Unicode 3.2"
+ (http://www.unicode.org/reports/tr28/).
+
+ [UAX15] Davis, M. and M. Duerst, "Unicode Standard Annex #15:
+ Unicode Normalization Forms, Version 3.2.0".
+ <http://www.unicode.org/unicode/reports/tr15/tr15-
+ 22.html>, March 2002.
+
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
+
+5.2. Informative References
+
+ [X.500] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory -- Overview of concepts, models and
+ services," X.500(1993) (also ISO/IEC 9594-1:1994).
+
+ [X.501] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory -- Models," X.501(1993) (also ISO/IEC 9594-
+ 2:1994).
+
+ [X.520] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory: Selected Attribute Types", X.520(1993) (also
+ ISO/IEC 9594-6:1994).
+
+ [Glossary] The Unicode Consortium, "Unicode Glossary",
+ <http://www.unicode.org/glossary/>.
+
+ [CharModel] Whistler, K. and M. Davis, "Unicode Technical Report
+ #17, Character Encoding Model", UTR17,
+ <http://www.unicode.org/unicode/reports/tr17/>, August
+ 2000.
+
+
+
+
+Zeilenga Standards Track [Page 9]
+
+RFC 4518 LDAP: Internationalized String Preparation June 2006
+
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory
+ Access Protocol (LDAP): String Representation of Search
+ Filters", RFC 4515, June 2006.
+
+ [XMATCH] Zeilenga, K., "Internationalized String Matching Rules
+ for X.500", Work in Progress.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 10]
+
+RFC 4518 LDAP: Internationalized String Preparation June 2006
+
+
+Appendix A. Combining Marks
+
+ This appendix is normative.
+
+ This table was derived from Unicode [Unicode] data files; it lists
+ all code points with the Mn, Mc, or Me properties. This table is to
+ be considered definitive for the purposes of implementation of this
+ specification.
+
+ 0300-034F 0360-036F 0483-0486 0488-0489 0591-05A1
+ 05A3-05B9 05BB-05BC 05BF 05C1-05C2 05C4 064B-0655 0670
+ 06D6-06DC 06DE-06E4 06E7-06E8 06EA-06ED 0711 0730-074A
+ 07A6-07B0 0901-0903 093C 093E-094F 0951-0954 0962-0963
+ 0981-0983 09BC 09BE-09C4 09C7-09C8 09CB-09CD 09D7
+ 09E2-09E3 0A02 0A3C 0A3E-0A42 0A47-0A48 0A4B-0A4D
+ 0A70-0A71 0A81-0A83 0ABC 0ABE-0AC5 0AC7-0AC9 0ACB-0ACD
+ 0B01-0B03 0B3C 0B3E-0B43 0B47-0B48 0B4B-0B4D 0B56-0B57
+ 0B82 0BBE-0BC2 0BC6-0BC8 0BCA-0BCD 0BD7 0C01-0C03
+ 0C3E-0C44 0C46-0C48 0C4A-0C4D 0C55-0C56 0C82-0C83
+ 0CBE-0CC4 0CC6-0CC8 0CCA-0CCD 0CD5-0CD6 0D02-0D03
+ 0D3E-0D43 0D46-0D48 0D4A-0D4D 0D57 0D82-0D83 0DCA
+ 0DCF-0DD4 0DD6 0DD8-0DDF 0DF2-0DF3 0E31 0E34-0E3A
+ 0E47-0E4E 0EB1 0EB4-0EB9 0EBB-0EBC 0EC8-0ECD 0F18-0F19
+ 0F35 0F37 0F39 0F3E-0F3F 0F71-0F84 0F86-0F87 0F90-0F97
+ 0F99-0FBC 0FC6 102C-1032 1036-1039 1056-1059 1712-1714
+ 1732-1734 1752-1753 1772-1773 17B4-17D3 180B-180D 18A9
+ 20D0-20EA 302A-302F 3099-309A FB1E FE00-FE0F FE20-FE23
+ 1D165-1D169 1D16D-1D172 1D17B-1D182 1D185-1D18B
+ 1D1AA-1D1AD
+
+Appendix B. Substrings Matching
+
+ This appendix is non-normative.
+
+ In the absence of substrings matching, the insignificant space
+ handling for case ignore/exact matching could be simplified.
+ Specifically, the handling could be to require that all sequences of
+ one or more spaces be replaced with one space and, if the string
+ contains non-space characters, removal of all leading spaces and
+ trailing spaces.
+
+ In the presence of substrings matching, this simplified space
+ handling would lead to unexpected and undesirable matching behavior.
+ For instance:
+
+ 1) (CN=foo\20*\20bar) would match the CN value "foobar";
+
+
+
+
+
+Zeilenga Standards Track [Page 11]
+
+RFC 4518 LDAP: Internationalized String Preparation June 2006
+
+
+ 2) (CN=*\20foobar\20*) would match "foobar", but
+ (CN=*\20*foobar*\20*) would not.
+
+ Note to readers not familiar with LDAP substrings matching: the LDAP
+ filter [RFC4515] assertion (CN=A*B*C) says to "match any value (of
+ the attribute CN) that begins with A, contains B after A, ends with C
+ where C is also after B."
+
+ The first case illustrates that this simplified space handling would
+ cause leading and trailing spaces in substrings of the string to be
+ regarded as insignificant. However, only leading and trailing (as
+ well as multiple consecutive spaces) of the string (as a whole) are
+ insignificant.
+
+ The second case illustrates that this simplified space handling would
+ cause sub-partitioning failures. That is, if a prepared any
+ substring matches a partition of the attribute value, then an
+ assertion constructed by subdividing that substring into multiple
+ substrings should also match.
+
+ In designing an appropriate approach for space handling for
+ substrings matching, one must study key aspects of X.500 case
+ exact/ignore matching. X.520 [X.520] says:
+
+ The [substrings] rule returns TRUE if there is a partitioning of
+ the attribute value (into portions) such that:
+
+ - the specified substrings (initial, any, final) match
+ different portions of the value in the order of the strings
+ sequence;
+
+ - initial, if present, matches the first portion of the value;
+
+ - final, if present, matches the last portion of the value;
+
+ - any, if present, matches some arbitrary portion of the
+ value.
+
+ That is, the substrings assertion (CN=foo\20*\20bar) matches the
+ attribute value "foo<SPACE><SPACE>bar" as the value can be
+ partitioned into the portions "foo<SPACE>" and "<SPACE>bar" meeting
+ the above requirements.
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 12]
+
+RFC 4518 LDAP: Internationalized String Preparation June 2006
+
+
+ X.520 also says:
+
+ [T]he following spaces are regarded as not significant:
+
+ - leading spaces (i.e., those preceding the first character
+ that is not a space);
+
+ - trailing spaces (i.e., those following the last character
+ that is not a space);
+
+ - multiple consecutive spaces (these are taken as equivalent
+ to a single space character).
+
+ This statement applies to the assertion values and attribute values
+ as whole strings, and not individually to substrings of an assertion
+ value. In particular, the statements should be taken to mean that if
+ an assertion value and attribute value match without any
+ consideration to insignificant characters, then that assertion value
+ should also match any attribute value that differs only by inclusion
+ nor removal of insignificant characters.
+
+ Hence the assertion (CN=foo\20*\20bar) matches
+ "foo<SPACE><SPACE><SPACE>bar" and "foo<SPACE>bar" as these values
+ only differ from "foo<SPACE><SPACE>bar" by the inclusion or removal
+ of insignificant spaces.
+
+ Astute readers of this text will also note that there are special
+ cases where the specified space handling does not ignore spaces that
+ could be considered insignificant. For instance, the assertion
+ (CN=\20*\20*\20) does not match "<SPACE><SPACE><SPACE>"
+ (insignificant spaces present in value) or " " (insignificant spaces
+ not present in value). However, as these cases have no practical
+ application that cannot be met by simple assertions, e.g., (cn=\20),
+ and this minor anomaly can only be fully addressed by a preparation
+ algorithm to be used in conjunction with character-by-character
+ partitioning and matching, the anomaly is considered acceptable.
+
+Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 13]
+
+RFC 4518 LDAP: Internationalized String Preparation June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 14]
+
diff --git a/doc/drafts/draft-ietf-ldapbis-user-schema-xx.txt b/doc/rfc/rfc4519.txt
similarity index 58%
rename from doc/drafts/draft-ietf-ldapbis-user-schema-xx.txt
rename to doc/rfc/rfc4519.txt
index fb2e7a231b8c7faa371b855c66e9978157e10cb4..f2e9b7c4b6e4d092ce43cb7b4ec7f27fd3010320 100644
--- a/doc/drafts/draft-ietf-ldapbis-user-schema-xx.txt
+++ b/doc/rfc/rfc4519.txt
@@ -4,89 +4,38 @@
-INTERNET-DRAFT Editor: A. Sciberras
-Intended Category: Standard Track eB2Bcom
-Updates: RFC 2247, RFC 2798, RFC 2377 January 30, 2006
-Obsoletes: RFC 2256
+Network Working Group A. Sciberras, Ed.
+Request for Comments: 4519 eB2Bcom
+Obsoletes: 2256 June 2006
+Updates: 2247, 2798, 2377
+Category: Standards Track
- LDAP: Schema for User Applications
- draft-ietf-ldapbis-user-schema-11.txt
- Copyright (C) The Internet Society (2006). All Rights Reserved.
+ Lightweight Directory Access Protocol (LDAP):
+ Schema for User Applications
- Status of this Memo
+Status of This Memo
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
- By submitting this Internet-Draft, I accept the provisions of Section
- 3 of BCP 78.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as
- Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress".
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
- This document is intended to be, after appropriate review and
- revision, submitted to the RFC Editor as a Standard Track document.
- Distribution of this document is unlimited. Technical discussion of
- this document should take place on the IETF LDAP Revision Working
- Group (LDAPbis) mailing list <ietf-ldapbis@openldap.org>. Please
- send editorial comments directly to the editor
- <andrew.sciberras@eb2bcom.com>.
-
- This Internet-Draft expires on 30 July 2006.
-
-
-
-
-
-
-Sciberras Expires 30 July 2006 [Page 1]
-
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+Copyright Notice
+ Copyright (C) The Internet Society (2006).
Abstract
This document is an integral part of the Lightweight Directory Access
- Protocol (LDAP) technical specification [Roadmap]. It provides a
- technical specification of attribute types and object classes
- intended for use by LDAP directory clients for many directory
- services, such as, White Pages. These objects are widely used as a
- basis for the schema in many LDAP directories. This document does
- not cover attributes used for the administration of directory
- servers, nor does it include directory objects defined for specific
- uses in other documents.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+ Protocol (LDAP) technical specification. It provides a technical
+ specification of attribute types and object classes intended for use
+ by LDAP directory clients for many directory services, such as White
+ Pages. These objects are widely used as a basis for the schema in
+ many LDAP directories. This document does not cover attributes used
+ for the administration of directory servers, nor does it include
+ directory objects defined for specific uses in other documents.
@@ -106,193 +55,161 @@ Abstract
-
-
-
-
-
-Sciberras Expires 30 July 2006 [Page 2]
+Sciberras Standards Track [Page 1]
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+RFC 4519 LDAP: Schema for User Applications June 2006
Table of Contents
- Status of this Memo . . . . . . . . . . . . . . . . . . . . . . . 1
- Copyright Notice. . . . . . . . . . . . . . . . . . . . . . . . . 1
- Abstract. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
- Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 5
- 1.1 Relationship with other specifications . . . . . . . . . 5
- 1.2 Conventions. . . . . . . . . . . . . . . . . . . . . . . 5
- 1.3 General Issues . . . . . . . . . . . . . . . . . . . . . 5
-
- 2. Attribute Types . . . . . . . . . . . . . . . . . . . . . . . 6
- 2.1 'businessCategory' . . . . . . . . . . . . . . . . . . . 6
- 2.2 'c'. . . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 2.3 'cn' . . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 2.4 'dc' . . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 2.5 'description'. . . . . . . . . . . . . . . . . . . . . . 8
- 2.6 'destinationIndicator' . . . . . . . . . . . . . . . . . 8
- 2.7 'distinguishedName'. . . . . . . . . . . . . . . . . . . 8
- 2.8 'dnQualifier'. . . . . . . . . . . . . . . . . . . . . . 9
- 2.9 'enhancedSearchGuide'. . . . . . . . . . . . . . . . . . 9
- 2.10 'facsimileTelephoneNumber' . . . . . . . . . . . . . . . 10
- 2.11 'generationQualifier'. . . . . . . . . . . . . . . . . . 10
- 2.12 'givenName'. . . . . . . . . . . . . . . . . . . . . . . 10
- 2.13 'houseIdentifier'. . . . . . . . . . . . . . . . . . . . 11
- 2.14 'initials' . . . . . . . . . . . . . . . . . . . . . . . 11
- 2.15 'internationalISDNNumber'. . . . . . . . . . . . . . . . 11
- 2.16 'l'. . . . . . . . . . . . . . . . . . . . . . . . . . . 12
- 2.17 'member' . . . . . . . . . . . . . . . . . . . . . . . . 12
- 2.18 'name' . . . . . . . . . . . . . . . . . . . . . . . . . 12
- 2.19 'o'. . . . . . . . . . . . . . . . . . . . . . . . . . . 13
- 2.20 'ou' . . . . . . . . . . . . . . . . . . . . . . . . . . 13
- 2.21 'owner'. . . . . . . . . . . . . . . . . . . . . . . . . 13
- 2.22 'physicalDeliveryOfficeName' . . . . . . . . . . . . . . 13
- 2.23 'postalAddress'. . . . . . . . . . . . . . . . . . . . . 14
- 2.24 'postalCode' . . . . . . . . . . . . . . . . . . . . . . 14
- 2.25 'postOfficeBox'. . . . . . . . . . . . . . . . . . . . . 14
- 2.26 'preferredDeliveryMethod'. . . . . . . . . . . . . . . . 15
- 2.27 'registeredAddress'. . . . . . . . . . . . . . . . . . . 15
- 2.28 'roleOccupant' . . . . . . . . . . . . . . . . . . . . . 16
- 2.29 'searchGuide'. . . . . . . . . . . . . . . . . . . . . . 16
- 2.30 'seeAlso'. . . . . . . . . . . . . . . . . . . . . . . . 16
- 2.31 'serialNumber' . . . . . . . . . . . . . . . . . . . . . 17
- 2.32 'sn' . . . . . . . . . . . . . . . . . . . . . . . . . . 17
- 2.33 'st' . . . . . . . . . . . . . . . . . . . . . . . . . . 17
- 2.34 'street' . . . . . . . . . . . . . . . . . . . . . . . . 18
- 2.35 'telephoneNumber'. . . . . . . . . . . . . . . . . . . . 18
- 2.36 'teletexTerminalIdentifier'. . . . . . . . . . . . . . . 18
-
-
-
-Sciberras Expires 30 July 2006 [Page 3]
-
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
- 2.37 'telexNumber'. . . . . . . . . . . . . . . . . . . . . . 19
- 2.38 'title'. . . . . . . . . . . . . . . . . . . . . . . . . 19
- 2.39 'uid'. . . . . . . . . . . . . . . . . . . . . . . . . . 19
- 2.40 'uniqueMember' . . . . . . . . . . . . . . . . . . . . . 19
- 2.41 'userPassword' . . . . . . . . . . . . . . . . . . . . . 20
- 2.42 'x121Address'. . . . . . . . . . . . . . . . . . . . . . 21
- 2.43 'x500UniqueIdentifier' . . . . . . . . . . . . . . . . . 21
-
- 3. Object Classes. . . . . . . . . . . . . . . . . . . . . . . . 22
- 3.1 'applicationProcess' . . . . . . . . . . . . . . . . . . 22
- 3.2 'country'. . . . . . . . . . . . . . . . . . . . . . . . 22
- 3.3 'dcObject' . . . . . . . . . . . . . . . . . . . . . . . 22
- 3.4 'device' . . . . . . . . . . . . . . . . . . . . . . . . 23
- 3.5 'groupOfNames' . . . . . . . . . . . . . . . . . . . . . 23
- 3.6 'groupOfUniqueNames' . . . . . . . . . . . . . . . . . . 23
- 3.7 'locality' . . . . . . . . . . . . . . . . . . . . . . . 24
- 3.8 'organization' . . . . . . . . . . . . . . . . . . . . . 24
- 3.9 'organizationalPerson' . . . . . . . . . . . . . . . . . 24
- 3.10 'organizationalRole' . . . . . . . . . . . . . . . . . . 25
- 3.11 'organizationalUnit' . . . . . . . . . . . . . . . . . . 25
- 3.12 'person' . . . . . . . . . . . . . . . . . . . . . . . . 26
- 3.13 'residentialPerson'. . . . . . . . . . . . . . . . . . . 26
- 3.14 'uidObject'. . . . . . . . . . . . . . . . . . . . . . . 26
-
- 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
-
- 5. Security Considerations . . . . . . . . . . . . . . . . . . . 28
-
- 6. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 29
-
- 7. References. . . . . . . . . . . . . . . . . . . . . . . . . . 30
- 7.1 Normative. . . . . . . . . . . . . . . . . . . . . . . . 30
- 7.2 Informative. . . . . . . . . . . . . . . . . . . . . . . 31
-
- 8. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 31
-
- 9. Intellectual Property Statement . . . . . . . . . . . . . . . 32
-
- 10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 32
-
-
-
-
-
-
-
-
-
-
-
-
-Sciberras Expires 30 July 2006 [Page 4]
+ 1. Introduction ....................................................3
+ 1.1. Relationship with Other Specifications .....................3
+ 1.2. Conventions ................................................4
+ 1.3. General Issues .............................................4
+ 2. Attribute Types .................................................4
+ 2.1. 'businessCategory' .........................................5
+ 2.2. 'c' ........................................................5
+ 2.3. 'cn' .......................................................5
+ 2.4. 'dc' .......................................................6
+ 2.5. 'description' ..............................................6
+ 2.6. 'destinationIndicator' .....................................7
+ 2.7. 'distinguishedName' ........................................7
+ 2.8. 'dnQualifier' ..............................................8
+ 2.9. 'enhancedSearchGuide' ......................................8
+ 2.10. 'facsimileTelephoneNumber' ................................9
+ 2.11. 'generationQualifier' .....................................9
+ 2.12. 'givenName' ...............................................9
+ 2.13. 'houseIdentifier' .........................................9
+ 2.14. 'initials' ...............................................10
+ 2.15. 'internationalISDNNumber' ................................10
+ 2.16. 'l' ......................................................10
+ 2.17. 'member' .................................................11
+ 2.18. 'name' ...................................................11
+ 2.19. 'o' ......................................................11
+ 2.20. 'ou' .....................................................12
+ 2.21. 'owner' ..................................................12
+ 2.22. 'physicalDeliveryOfficeName' .............................12
+ 2.23. 'postalAddress' ..........................................13
+ 2.24. 'postalCode' .............................................13
+ 2.25. 'postOfficeBox' ..........................................14
+ 2.26. 'preferredDeliveryMethod' ................................14
+ 2.27. 'registeredAddress' ......................................14
+ 2.28. 'roleOccupant' ...........................................15
+ 2.29. 'searchGuide' ............................................15
+ 2.30. 'seeAlso' ................................................15
+ 2.31. 'serialNumber' ...........................................16
+ 2.32. 'sn' .....................................................16
+ 2.33. 'st' .....................................................16
+ 2.34. 'street' .................................................17
+ 2.35. 'telephoneNumber' ........................................17
+ 2.36. 'teletexTerminalIdentifier' ..............................17
+ 2.37. 'telexNumber' ............................................18
+ 2.38. 'title' ..................................................18
+ 2.39. 'uid' ....................................................18
+ 2.40. 'uniqueMember' ...........................................19
+ 2.41. 'userPassword' ...........................................19
+
+
+
+Sciberras Standards Track [Page 2]
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+ 2.42. 'x121Address' ............................................20
+ 2.43. 'x500UniqueIdentifier' ...................................20
+ 3. Object Classes .................................................20
+ 3.1. 'applicationProcess' ......................................21
+ 3.2. 'country' .................................................21
+ 3.3. 'dcObject' ................................................21
+ 3.4. 'device' ..................................................21
+ 3.5. 'groupOfNames' ............................................22
+ 3.6. 'groupOfUniqueNames' ......................................22
+ 3.7. 'locality' ................................................23
+ 3.8. 'organization' ............................................23
+ 3.9. 'organizationalPerson' ....................................24
+ 3.10. 'organizationalRole' .....................................24
+ 3.11. 'organizationalUnit' .....................................24
+ 3.12. 'person' .................................................25
+ 3.13. 'residentialPerson' ......................................25
+ 3.14. 'uidObject' ..............................................26
+ 4. IANA Considerations ............................................26
+ 5. Security Considerations ........................................28
+ 6. Acknowledgements ...............................................28
+ 7. References .....................................................29
+ 7.1. Normative References ......................................29
+ 7.2. Informative References ....................................30
+ Appendix A Changes Made Since RFC 2256 ...........................32
1. Introduction
This document provides an overview of attribute types and object
classes intended for use by Lightweight Directory Access Protocol
- (LDAP) directory clients for many directory services, such as, White
+ (LDAP) directory clients for many directory services, such as White
Pages. Originally specified in the X.500 [X.500] documents, these
objects are widely used as a basis for the schema in many LDAP
directories. This document does not cover attributes used for the
administration of directory servers, nor does it include directory
objects defined for specific uses in other documents.
-1.1 Relationship with other specifications
+1.1. Relationship with Other Specifications
This document is an integral part of the LDAP technical specification
- [Roadmap] which obsoletes the previously defined LDAP technical
+ [RFC4510], which obsoletes the previously defined LDAP technical
specification, RFC 3377, in its entirety. In terms of RFC 2256,
- Sections 6 and 8 of RFC 2256 are obsoleted by [Syntaxes]. Sections
- 5.1, 5.2, 7.1 and 7.2 of RFC 2256 are obsoleted by [Models]. The
- remainder of RFC 2256 is obsoleted by this document. Section 2.4 of
- this document supersedes the technical specification for the 'dc'
- attribute type and 'dcObject' object class found in RFC 2247. The
- remainder of RFC 2247 remains in force.
+ Sections 6 and 8 of RFC 2256 are obsoleted by [RFC4517]. Sections
+ 5.1, 5.2, 7.1, and 7.2 of RFC 2256 are obsoleted by [RFC4512]. The
+ remainder of RFC 2256 is obsoleted by this document. The technical
+ specification for the 'dc' attribute type and 'dcObject' object class
+ found in RFC 2247 are superseded by sections 2.4 and 3.3 of this
+ document. The remainder of RFC 2247 remains in force.
+
+
+
+
+Sciberras Standards Track [Page 3]
+
+RFC 4519 LDAP: Schema for User Applications June 2006
+
This document updates RFC 2798 by replacing the informative
- description of the 'uid' attribute type, with the definitive
+ description of the 'uid' attribute type with the definitive
description provided in Section 2.39 of this document.
- A number of schema elements which were included in the previous
+ This document updates RFC 2377 by replacing the informative
+ description of the 'uidObject' object class with the definitive
+ description provided in Section 3.14 of this document.
+
+ A number of schema elements that were included in the previous
revision of the LDAP Technical Specification are not included in this
revision of LDAP. PKI-related schema elements are now specified in
- [LDAP-PKI]. Unless reintroduced in future technical specifications,
+ [RFC4523]. Unless reintroduced in future technical specifications,
the remainder are to be considered Historic.
The descriptions in this document SHALL be considered definitive for
use in LDAP.
-1.2 Conventions
+1.2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
-1.3 General Issues
+1.3. General Issues
- This document references Syntaxes defined in Section 3 of [Syntaxes]
- and Matching Rules defined in Section 4 of [Syntaxes].
+ This document references Syntaxes defined in Section 3 of [RFC4517]
+ and Matching Rules defined in Section 4 of [RFC4517].
The definitions of Attribute Types and Object Classes are written
-
-
-
-Sciberras Expires 30 July 2006 [Page 5]
-
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
using the Augmented Backus-Naur Form (ABNF) [RFC4234] of
AttributeTypeDescription and ObjectClassDescription given in
- [Models]. Lines have been folded for readability. When such values
- are transferred as attribute values in the LDAP Protocol the values
+ [RFC4512]. Lines have been folded for readability. When such values
+ are transferred as attribute values in the LDAP Protocol, the values
will not contain line breaks.
2. Attribute Types
- The Attribute Types contained in this section hold user information.
+ The attribute types contained in this section hold user information.
There is no requirement that servers implement the 'searchGuide' and
'teletexTerminalIdentifier' attribute types. In fact, their use is
@@ -301,7 +218,17 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
An LDAP server implementation SHOULD recognize the rest of the
attribute types described in this section.
-2.1 'businessCategory'
+
+
+
+
+
+Sciberras Standards Track [Page 4]
+
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+2.1. 'businessCategory'
The 'businessCategory' attribute type describes the kinds of business
performed by an organization. Each kind is one value of this
@@ -314,11 +241,11 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
- [Syntaxes].
+ [RFC4517].
- Examples: "banking", "transportation" and "real estate".
+ Examples: "banking", "transportation", and "real estate".
-2.2 'c'
+2.2. 'c'
The 'c' ('countryName' in X.500) attribute type contains a two-letter
ISO 3166 [ISO3166] country code.
@@ -330,19 +257,11 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
SINGLE-VALUE )
1.3.6.1.4.1.1466.115.121.1.11 refers to the Country String syntax
- [Syntaxes].
-
-
-
-
-Sciberras Expires 30 July 2006 [Page 6]
-
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
+ [RFC4517].
Examples: "DE", "AU" and "FR".
-2.3 'cn'
+2.3. 'cn'
The 'cn' ('commonName' in X.500) attribute type contains names of an
object. Each name is one value of this multi-valued attribute. If
@@ -355,72 +274,90 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
Examples: "Martin K Smith", "Marty Smith" and "printer12".
-2.4 'dc'
- The 'dc' ('domainComponent' in RFC 2247) attribute type is a string
- holding one component, a label, of a DNS domain name [RFC1034]. The
- encoding of IA5String for use in LDAP is simply the characters of the
- ASCII label. The equality matching rule is case insensitive, as is
- today's DNS.
- (Source: RFC 2247 [RFC2247])
- ( 0.9.2342.19200300.100.1.25 NAME 'dc'
- EQUALITY caseIgnoreIA5Match
- SUBSTR caseIgnoreIA5SubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
- SINGLE-VALUE )
- 1.3.6.1.4.1.1466.115.121.1.26 refers to the IA5 String syntax
- [Syntaxes].
- Examples: Valid values include "example" and "com". The value
- "example.com" is invalid, because it contains two label
- components.
- Directory applications supporting International Domain Names SHALL
- use the ToASCII method [RFC3490] to produce the domain name component
- label. The special considerations discussed in section 4 of RFC 3490
- [RFC3490] should be taken, depending on whether the domain component
- is used for "stored" or "query" purposes.
+Sciberras Standards Track [Page 5]
+
+RFC 4519 LDAP: Schema for User Applications June 2006
+2.4. 'dc'
+ The 'dc' ('domainComponent' in RFC 1274) attribute type is a string
+ holding one component, a label, of a DNS domain name
+ [RFC1034][RFC2181] naming a host [RFC1123]. That is, a value of this
+ attribute is a string of ASCII characters adhering to the following
+ ABNF [RFC4234]:
+ label = (ALPHA / DIGIT) [*61(ALPHA / DIGIT / HYPHEN) (ALPHA / DIGIT)]
+ ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
+ DIGIT = %x30-39 ; "0"-"9"
+ HYPHEN = %x2D ; hyphen ("-")
+ The encoding of IA5String for use in LDAP is simply the characters of
+ the ASCII label. The equality matching rule is case insensitive, as
+ is today's DNS. (Source: RFC 2247 [RFC2247] and RFC 1274 [RFC 1274])
+ ( 0.9.2342.19200300.100.1.25 NAME 'dc'
+ EQUALITY caseIgnoreIA5Match
+ SUBSTR caseIgnoreIA5SubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
+ SINGLE-VALUE )
+ 1.3.6.1.4.1.1466.115.121.1.26 refers to the IA5 String syntax
+ [RFC4517].
+ Examples: Valid values include "example" and "com" but not
+ "example.com". The latter is invalid as it contains multiple domain
+ components.
-Sciberras Expires 30 July 2006 [Page 7]
-
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+ It is noted that the directory service will not ensure that values of
+ this attribute conform to the host label restrictions [RFC1123]
+ illustrated by the <label> production provided above. It is the
+ directory client's responsibility to ensure that the labels it stores
+ in this attribute are appropriately restricted.
+ Directory applications supporting International Domain Names SHALL
+ use the ToASCII method [RFC3490] to produce the domain component
+ label. The special considerations discussed in Section 4 of RFC 3490
+ [RFC3490] should be taken, depending on whether the domain component
+ is used for "stored" or "query" purposes.
-2.5 'description'
+2.5. 'description'
The 'description' attribute type contains human-readable descriptive
phrases about the object. Each description is one value of this
multi-valued attribute.
(Source: X.520 [X.520])
+
+
+Sciberras Standards Track [Page 6]
+
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
( 2.5.4.13 NAME 'description'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
- [Syntaxes].
+ [RFC4517].
Examples: "a color printer", "Maintenance is done every Monday, at
- 1pm." and "distribution list for all technical staff".
+ 1pm.", and "distribution list for all technical staff".
-2.6 'destinationIndicator'
+2.6. 'destinationIndicator'
The 'destinationIndicator' attribute type contains country and city
- strings, associated with the object (the addressee), needed to
- provide the Public Telegram Service. The strings are composed in
- accordance with CCITT Recommendations F.1 [F.1] and F.31 [F.31].
- Each string is one value of this multi-valued attribute.
+ strings associated with the object (the addressee) needed to provide
+ the Public Telegram Service. The strings are composed in accordance
+ with CCITT Recommendations F.1 [F.1] and F.31 [F.31]. Each string is
+ one value of this multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.27 NAME 'destinationIndicator'
@@ -429,50 +366,50 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
- [Syntaxes].
+ [RFC4517].
Examples: "AASD" as a destination indicator for Sydney, Australia.
"GBLD" as a destination indicator for London, United
Kingdom.
It is noted that the directory will not ensure that values of this
- attribute conform to the F.1 and F.30 CCITT Recommendations. It is
+ attribute conform to the F.1 and F.31 CCITT Recommendations. It is
the application's responsibility to ensure destination indicators
that it stores in this attribute are appropriately constructed.
-2.7 'distinguishedName'
+2.7. 'distinguishedName'
The 'distinguishedName' attribute type is not used as the name of the
object itself, but it is instead a base type from which some user
-
-
-
-Sciberras Expires 30 July 2006 [Page 8]
-
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
attribute types with a DN syntax can inherit.
It is unlikely that values of this type itself will occur in an
- entry. LDAP server implementations which do not support attribute
+ entry. LDAP server implementations that do not support attribute
subtyping need not recognize this attribute in requests. Client
implementations MUST NOT assume that LDAP servers are capable of
performing attribute subtyping.
+
+
+
+Sciberras Standards Track [Page 7]
+
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
(Source: X.520 [X.520])
( 2.5.4.49 NAME 'distinguishedName'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
- 1.3.6.1.4.1.1466.115.121.1.12 refers to the DN syntax [Syntaxes].
+ 1.3.6.1.4.1.1466.115.121.1.12 refers to the DN syntax [RFC4517].
-2.8 'dnQualifier'
+2.8. 'dnQualifier'
The 'dnQualifier' attribute type contains disambiguating information
strings to add to the relative distinguished name of an entry. The
information is intended for use when merging data from multiple
- sources in order to prevent conflicts between entries which would
+ sources in order to prevent conflicts between entries that would
otherwise have the same name. Each string is one value of this
multi-valued attribute. It is recommended that a value of the
'dnQualifier' attribute be the same for all entries from a particular
@@ -486,38 +423,39 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
- [Syntaxes].
+ [RFC4517].
Examples: "20050322123345Z" - timestamps can be used to disambiguate
information.
"123456A" - serial numbers can be used to disambiguate
information.
-2.9 'enhancedSearchGuide'
+2.9. 'enhancedSearchGuide'
The 'enhancedSearchGuide' attribute type contains sets of information
for use by directory clients in constructing search filters. Each
set is one value of this multi-valued attribute.
(Source: X.520 [X.520])
+ ( 2.5.4.47 NAME 'enhancedSearchGuide'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 )
+ 1.3.6.1.4.1.1466.115.121.1.21 refers to the Enhanced Guide syntax
+ [RFC4517].
-Sciberras Expires 30 July 2006 [Page 9]
-
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
- ( 2.5.4.47 NAME 'enhancedSearchGuide'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 )
- 1.3.6.1.4.1.1466.115.121.1.21 refers to the Enhanced Guide syntax
- [Syntaxes].
+Sciberras Standards Track [Page 8]
+
+RFC 4519 LDAP: Schema for User Applications June 2006
+
Examples: "person#(sn$APPROX)#wholeSubtree" and
"organizationalUnit#(ou$SUBSTR)#oneLevel".
-2.10 'facsimileTelephoneNumber'
+2.10. 'facsimileTelephoneNumber'
The 'facsimileTelephoneNumber' attribute type contains telephone
numbers (and, optionally, the parameters) for facsimile terminals.
@@ -528,60 +466,59 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )
1.3.6.1.4.1.1466.115.121.1.22 refers to the Facsimile Telephone
- Number syntax [Syntaxes].
+ Number syntax [RFC4517].
Examples: "+61 3 9896 7801" and "+81 3 347 7418$fineResolution".
-2.11 'generationQualifier'
+2.11. 'generationQualifier'
The 'generationQualifier' attribute type contains name strings that
- are the part of a person's name which typically is the suffix. Each
- string is one value of this multi-valued attribute.
+ are typically the suffix part of a person's name. Each string is one
+ value of this multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.44 NAME 'generationQualifier'
SUP name )
- Examples: "III", "3rd" and "Jr.".
+ Examples: "III", "3rd", and "Jr.".
-2.12 'givenName'
+2.12. 'givenName'
The 'givenName' attribute type contains name strings that are the
- part of a person's name which is not their surname. Each string is
+ part of a person's name that is not their surname. Each string is
one value of this multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.42 NAME 'givenName'
SUP name )
- Examples: "Andrew", "Charles" and "Joanne".
-
-
-
-
-Sciberras Expires 30 July 2006 [Page 10]
-
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+ Examples: "Andrew", "Charles", and "Joanne".
-
-2.13 'houseIdentifier'
+2.13. 'houseIdentifier'
The 'houseIdentifier' attribute type contains identifiers for a
building within a location. Each identifier is one value of this
multi-valued attribute.
(Source: X.520 [X.520])
+
+
+Sciberras Standards Track [Page 9]
+
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
( 2.5.4.51 NAME 'houseIdentifier'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
- [Syntaxes].
+ [RFC4517].
- Examples: "20" to represent the house number 20.
+ Example: "20" to represent the house number 20.
-2.14 'initials'
+2.14. 'initials'
The 'initials' attribute type contains strings of initials of some or
all of an individual's names, except the surname(s). Each string is
@@ -593,7 +530,7 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
Examples: "K. A." and "K".
-2.15 'internationalISDNNumber'
+2.15. 'internationalISDNNumber'
The 'internationalISDNNumber' attribute type contains Integrated
Services Digital Network (ISDN) addresses, as defined in the
@@ -607,34 +544,34 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax
- [Syntaxes].
+ [RFC4517].
Example: "0198 333 333".
+2.16. 'l'
+ The 'l' ('localityName' in X.500) attribute type contains names of a
+ locality or place, such as a city, county, or other geographic
+ region. Each name is one value of this multi-valued attribute.
+ (Source: X.520 [X.520])
-Sciberras Expires 30 July 2006 [Page 11]
-
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-2.16 'l'
+Sciberras Standards Track [Page 10]
+
+RFC 4519 LDAP: Schema for User Applications June 2006
- The 'l' ('localityName' in X.500) attribute type contains names of a
- locality or place, such as a city, county or other geographic region.
- Each name is one value of this multi-valued attribute.
- (Source: X.520 [X.520])
( 2.5.4.7 NAME 'l'
SUP name )
- Examples: "Geneva", "Paris" and "Edinburgh".
+ Examples: "Geneva", "Paris", and "Edinburgh".
-2.17 'member'
+2.17. 'member'
- The 'member' attribute type contains the Distinguished Names of
+ The 'member' attribute type contains the distinguished names of
objects that are on a list or in a group. Each name is one value of
this multi-valued attribute.
(Source: X.520 [X.520])
@@ -645,17 +582,18 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
Examples: "cn=James Clarke,ou=Finance,o=Widget\, Inc." and
"cn=John Xerri,ou=Finance,o=Widget\, Inc." may
be two members of the financial team (group) at Widget,
- Inc. In which case, both of these distinguished names would
- be present as individual values of the member attribute.
+ Inc., in which case, both of these distinguished names
+ would be present as individual values of the member
+ attribute.
-2.18 'name'
+2.18. 'name'
The 'name' attribute type is the attribute supertype from which user
attribute types with the name syntax inherit. Such attribute types
are typically used for naming. The attribute type is multi-valued.
It is unlikely that values of this type itself will occur in an
- entry. LDAP server implementations which do not support attribute
+ entry. LDAP server implementations that do not support attribute
subtyping need not recognize this attribute in requests. Client
implementations MUST NOT assume that LDAP servers are capable of
performing attribute subtyping.
@@ -667,28 +605,29 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
- [Syntaxes].
+ [RFC4517].
+2.19. 'o'
+ The 'o' ('organizationName' in X.500) attribute type contains the
+ names of an organization. Each name is one value of this
+ multi-valued attribute.
-Sciberras Expires 30 July 2006 [Page 12]
-
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-2.19 'o'
+Sciberras Standards Track [Page 11]
+
+RFC 4519 LDAP: Schema for User Applications June 2006
+
- The 'o' ('organizationName' in X.500) attribute type contains the
- names of an organization. Each name is one value of this
- multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.10 NAME 'o'
SUP name )
- Examples: "Widget", "Widget, Inc." and "Widget, Incorporated.".
+ Examples: "Widget", "Widget, Inc.", and "Widget, Incorporated.".
-2.20 'ou'
+2.20. 'ou'
The 'ou' ('organizationalUnitName' in X.500) attribute type contains
the names of an organizational unit. Each name is one value of this
@@ -698,12 +637,12 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
( 2.5.4.11 NAME 'ou'
SUP name )
- Examples: "Finance", "Human Resources" and "Research and
+ Examples: "Finance", "Human Resources", and "Research and
Development".
-2.21 'owner'
+2.21. 'owner'
- The 'owner' attribute type contains the Distinguished Names of
+ The 'owner' attribute type contains the distinguished names of
objects that have an ownership responsibility for the object that is
owned. Each owner's name is one value of this multi-valued
attribute.
@@ -715,11 +654,12 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
Example: The mailing list object, whose DN is "cn=All Employees,
ou=Mailing List,o=Widget\, Inc.", is owned by the Human
Resources Director.
+
Therefore, the value of the 'owner' attribute within the
mailing list object, would be the DN of the director (role):
"cn=Human Resources Director,ou=employee,o=Widget\, Inc.".
-2.22 'physicalDeliveryOfficeName'
+2.22. 'physicalDeliveryOfficeName'
The 'physicalDeliveryOfficeName' attribute type contains names that a
Postal Service uses to identify a post office.
@@ -727,9 +667,13 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-Sciberras Expires 30 July 2006 [Page 13]
+
+
+
+
+Sciberras Standards Track [Page 12]
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+RFC 4519 LDAP: Schema for User Applications June 2006
( 2.5.4.19 NAME 'physicalDeliveryOfficeName'
@@ -738,11 +682,11 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
- [Syntaxes].
+ [RFC4517].
Examples: "Bremerhaven, Main" and "Bremerhaven, Bonnstrasse".
-2.23 'postalAddress'
+2.23. 'postalAddress'
The 'postalAddress' attribute type contains addresses used by a
Postal Service to perform services for the object. Each address is
@@ -755,11 +699,11 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax
- [Syntaxes].
+ [RFC4517].
Example: "15 Main St.$Ottawa$Canada".
-2.24 'postalCode'
+2.24. 'postalCode'
The 'postalCode' attribute type contains codes used by a Postal
Service to identify postal service zones. Each code is one value of
@@ -772,23 +716,27 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
- [Syntaxes].
+ [RFC4517].
- Example: "22180", to identify Vienna, VA in the USA.
+ Example: "22180", to identify Vienna, VA, in the USA.
-2.25 'postOfficeBox'
- The 'postOfficeBox' attribute type contains postal box identifiers
- that a Postal Service uses when a customer arranges to receive mail
-Sciberras Expires 30 July 2006 [Page 14]
+
+
+
+Sciberras Standards Track [Page 13]
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+2.25. 'postOfficeBox'
- at a box on premises of the Postal Service. Each postal box
+ The 'postOfficeBox' attribute type contains postal box identifiers
+ that a Postal Service uses when a customer arranges to receive mail
+ at a box on the premises of the Postal Service. Each postal box
identifier is a single value of this multi-valued attribute.
(Source: X.520 [X.520])
@@ -798,11 +746,11 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
- [Syntaxes].
+ [RFC4517].
Example: "Box 45".
-2.26 'preferredDeliveryMethod'
+2.26. 'preferredDeliveryMethod'
The 'preferredDeliveryMethod' attribute type contains an indication
of the preferred method of getting a message to the object.
@@ -813,13 +761,13 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
SINGLE-VALUE )
1.3.6.1.4.1.1466.115.121.1.14 refers to the Delivery Method syntax
- [Syntaxes].
+ [RFC4517].
Example: If the mhs-delivery Delivery Method is preferred over
telephone-delivery, which is preferred over all other
methods, the value would be: "mhs $ telephone".
-2.27 'registeredAddress'
+2.27. 'registeredAddress'
The 'registeredAddress' attribute type contains postal addresses
suitable for reception of telegrams or expedited documents, where it
@@ -831,22 +779,23 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
SUP postalAddress
SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
- 1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax
- [Syntaxes].
- Example: "Receptionist$Widget, Inc.$15 Main St.$Ottawa$Canada".
-
-Sciberras Expires 30 July 2006 [Page 15]
+Sciberras Standards Track [Page 14]
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+ 1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax
+ [RFC4517].
+ Example: "Receptionist$Widget, Inc.$15 Main St.$Ottawa$Canada".
-2.28 'roleOccupant'
+2.28. 'roleOccupant'
- The 'roleOccupant' attribute type contains the Distinguished Names of
+ The 'roleOccupant' attribute type contains the distinguished names of
objects (normally people) that fulfill the responsibilities of a role
object. Each distinguished name is one value of this multi-valued
attribute.
@@ -863,48 +812,47 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
attribute will contain both of these distinguished names,
since they are the occupants of this role.
-2.29 'searchGuide'
+2.29. 'searchGuide'
The 'searchGuide' attribute type contains sets of information for use
by clients in constructing search filters. It is superseded by
- 'enhancedSearchGuide', described above in section 2.9. Each set is
+ 'enhancedSearchGuide', described above in Section 2.9. Each set is
one value of this multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.14 NAME 'searchGuide'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 )
- 1.3.6.1.4.1.1466.115.121.1.25 refers to the Guide syntax [Syntaxes].
+ 1.3.6.1.4.1.1466.115.121.1.25 refers to the Guide syntax [RFC4517].
Example: "person#sn$EQ".
-2.30 'seeAlso'
+2.30. 'seeAlso'
- The 'seeAlso' attribute type contains Distinguished Names of objects
- that are related to the subject object. Each related object name is
- one value of this multi-valued attribute.
+ The 'seeAlso' attribute type contains the distinguished names of
+ objects that are related to the subject object. Each related object
+ name is one value of this multi-valued attribute.
(Source: X.520 [X.520])
( 2.5.4.34 NAME 'seeAlso'
SUP distinguishedName )
- Example: The person object, "cn=James Brown,ou=employee,o=Widget\,
- Inc." is related to the role objects, "cn=Football Team
- Captain,ou=sponsored activities,o=Widget\, Inc." and
- "cn=Chess Team,ou=sponsored activities,o=Widget\, Inc.".
-
-Sciberras Expires 30 July 2006 [Page 16]
+Sciberras Standards Track [Page 15]
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+RFC 4519 LDAP: Schema for User Applications June 2006
+ Example: The person object "cn=James Brown,ou=employee,o=Widget\,
+ Inc." is related to the role objects "cn=Football Team
+ Captain,ou=sponsored activities,o=Widget\, Inc." and
+ "cn=Chess Team,ou=sponsored activities,o=Widget\, Inc.".
Since the role objects are related to the person object, the
'seeAlso' attribute will contain the distinguished name of
each role object as separate values.
-2.31 'serialNumber'
+2.31. 'serialNumber'
The 'serialNumber' attribute type contains the serial numbers of
devices. Each serial number is one value of this multi-valued
@@ -917,11 +865,11 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
- [Syntaxes].
+ [RFC4517].
Examples: "WI-3005" and "XF551426".
-2.32 'sn'
+2.32. 'sn'
The 'sn' ('surname' in X.500) attribute type contains name strings
for the family names of a person. Each string is one value of this
@@ -933,7 +881,7 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
Example: "Smith".
-2.33 'st'
+2.33. 'st'
The 'st' ('stateOrProvinceName' in X.500) attribute type contains the
full names of states or provinces. Each name is one value of this
@@ -947,20 +895,16 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
-
-
-Sciberras Expires 30 July 2006 [Page 17]
+Sciberras Standards Track [Page 16]
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+RFC 4519 LDAP: Schema for User Applications June 2006
-2.34 'street'
+2.34. 'street'
The 'street' ('streetAddress' in X.500) attribute type contains site
information from a postal address (i.e., the street name, place,
- avenue, and the house number.). Each street is one value of this
+ avenue, and the house number). Each street is one value of this
multi-valued attribute.
(Source: X.520 [X.520])
@@ -970,11 +914,11 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
- [Syntaxes].
+ [RFC4517].
Example: "15 Main St.".
-2.35 'telephoneNumber'
+2.35. 'telephoneNumber'
The 'telephoneNumber' attribute type contains telephone numbers that
comply with the ITU Recommendation E.123 [E.123]. Each number is one
@@ -987,34 +931,34 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
1.3.6.1.4.1.1466.115.121.1.50 refers to the Telephone Number syntax
- [Syntaxes].
+ [RFC4517].
Example: "+1 234 567 8901".
-2.36 'teletexTerminalIdentifier'
+2.36. 'teletexTerminalIdentifier'
- The withdrawal of Rec. F.200 has resulted in the withdrawal of this
- attribute.
+ The withdrawal of Recommendation F.200 has resulted in the withdrawal
+ of this attribute.
(Source: X.520 [X.520])
( 2.5.4.22 NAME 'teletexTerminalIdentifier'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 )
1.3.6.1.4.1.1466.115.121.1.51 refers to the Teletex Terminal
- Identifier syntax [Syntaxes].
+ Identifier syntax [RFC4517].
-Sciberras Expires 30 July 2006 [Page 18]
+Sciberras Standards Track [Page 17]
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+RFC 4519 LDAP: Schema for User Applications June 2006
-2.37 'telexNumber'
+2.37. 'telexNumber'
- The 'telexNumber' attribute type contains sets of strings which are a
+ The 'telexNumber' attribute type contains sets of strings that are a
telex number, country code, and answerback code of a telex terminal.
Each set is one value of this multi-valued attribute.
(Source: X.520 [X.520])
@@ -1023,11 +967,11 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 )
1.3.6.1.4.1.1466.115.121.1.52 refers to the Telex Number syntax
- [Syntaxes].
+ [RFC4517].
Example: "12345$023$ABCDE".
-2.38 'title'
+2.38. 'title'
The 'title' attribute type contains the title of a person in their
organizational context. Each title is one value of this multi-valued
@@ -1036,9 +980,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
( 2.5.4.12 NAME 'title'
SUP name )
- Examples: "Vice President", "Software Engineer" and "CEO".
+ Examples: "Vice President", "Software Engineer", and "CEO".
-2.39 'uid'
+2.39. 'uid'
The 'uid' ('userid' in RFC 1274) attribute type contains computer
system login names associated with the object. Each name is one
@@ -1051,23 +995,28 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
- [Syntaxes].
+ [RFC4517].
+
+ Examples: "s9709015", "admin", and "Administrator".
+
- Examples: "s9709015", "admin" and "Administrator".
-2.40 'uniqueMember'
- The 'uniqueMember' attribute type contains the Distinguished Names of
- an object that is on a list or in a group, where the Relative
- Distinguished Names of the object include a value that distinguishes
-Sciberras Expires 30 July 2006 [Page 19]
+
+
+Sciberras Standards Track [Page 18]
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+RFC 4519 LDAP: Schema for User Applications June 2006
+2.40. 'uniqueMember'
+
+ The 'uniqueMember' attribute type contains the distinguished names of
+ an object that is on a list or in a group, where the relative
+ distinguished names of the object include a value that distinguishes
between objects when a distinguished name has been reused. Each
distinguished name is one value of this multi-valued attribute.
(Source: X.520 [X.520])
@@ -1077,14 +1026,14 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
1.3.6.1.4.1.1466.115.121.1.34 refers to the Name and Optional UID
- syntax [Syntaxes].
+ syntax [RFC4517].
Example: If "ou=1st Battalion,o=Defense,c=US" is a battalion that was
disbanded, establishing a new battalion with the "same" name
would have a unique identifier value added, resulting in
"ou=1st Battalion, o=Defense,c=US#'010101'B".
-2.41 'userPassword'
+2.41. 'userPassword'
The 'userPassword' attribute contains octet strings that are known
only to the user and the system to which the user has access. Each
@@ -1101,7 +1050,7 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
1.3.6.1.4.1.1466.115.121.1.40 refers to the Octet String syntax
- [Syntaxes].
+ [RFC4517].
Passwords are stored using an Octet String syntax and are not
encrypted. Transfer of cleartext passwords is strongly discouraged
@@ -1110,21 +1059,21 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
unauthorized parties.
An example of a need for multiple values in the 'userPassword'
- attribute is an environment where every month the user was expected
- to use a different password generated by some automated system.
- During transitional periods, like the last and first day of the
- periods, it may be necessary to allow two passwords for the two
- consecutive periods to be valid in the system.
-
+ attribute is an environment where every month the user is expected to
-Sciberras Expires 30 July 2006 [Page 20]
+Sciberras Standards Track [Page 19]
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+RFC 4519 LDAP: Schema for User Applications June 2006
-2.42 'x121Address'
+ use a different password generated by some automated system. During
+ transitional periods, like the last and first day of the periods, it
+ may be necessary to allow two passwords for the two consecutive
+ periods to be valid in the system.
+
+2.42. 'x121Address'
The 'x121Address' attribute type contains data network addresses as
defined by ITU Recommendation X.121 [X.121]. Each address is one
@@ -1137,20 +1086,21 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax
- [Syntaxes].
+ [RFC4517].
Example: "36111222333444555".
-2.43 'x500UniqueIdentifier'
+2.43. 'x500UniqueIdentifier'
The 'x500UniqueIdentifier' attribute type contains binary strings
that are used to distinguish between objects when a distinguished
name has been reused. Each string is one value of this multi-valued
attribute.
+
In X.520 [X.520], this attribute type is called 'uniqueIdentifier'.
This is a different attribute type from both the 'uid' and
'uniqueIdentifier' LDAP attribute types. The 'uniqueIdentifier'
- attribute type is defined in [RFC1274].
+ attribute type is defined in [RFC4524].
(Source: X.520 [X.520])
( 2.5.4.45 NAME 'x500UniqueIdentifier'
@@ -1158,37 +1108,26 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
1.3.6.1.4.1.1466.115.121.1.6 refers to the Bit String syntax
- [Syntaxes].
-
-
-
-
-
-
-
-
-
+ [RFC4517].
+3. Object Classes
+ LDAP servers SHOULD recognize all the Object Classes listed here as
+ values of the 'objectClass' attribute (see [RFC4512]).
-Sciberras Expires 30 July 2006 [Page 21]
+Sciberras Standards Track [Page 20]
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
-3. Object Classes
+RFC 4519 LDAP: Schema for User Applications June 2006
- LDAP servers SHOULD recognize all the Object Classes listed here as
- values of the 'objectClass' attribute (see [Models]).
-3.1 'applicationProcess'
+3.1. 'applicationProcess'
The 'applicationProcess' object class definition is the basis of an
- entry which represents an application executing in a computer system.
+ entry that represents an application executing in a computer system.
(Source: X.521 [X.521])
( 2.5.6.11 NAME 'applicationProcess'
@@ -1200,9 +1139,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
l $
description ) )
-3.2 'country'
+3.2. 'country'
- The 'country' object class definition is the basis of an entry which
+ The 'country' object class definition is the basis of an entry that
represents a country.
(Source: X.521 [X.521])
@@ -1213,7 +1152,7 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
MAY ( searchGuide $
description ) )
-3.3 'dcObject'
+3.3. 'dcObject'
The 'dcObject' object class permits an entry to contains domain
component information. This object class is defined as auxiliary,
@@ -1226,21 +1165,20 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
AUXILIARY
MUST dc )
+3.4. 'device'
+ The 'device' object class is the basis of an entry that represents an
+ appliance, computer, or network element.
+ (Source: X.521 [X.521])
-Sciberras Expires 30 July 2006 [Page 22]
-
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+Sciberras Standards Track [Page 21]
+
+RFC 4519 LDAP: Schema for User Applications June 2006
-3.4 'device'
-
- The 'device' object class is the basis of an entry which represents
- an appliance, computer or network element.
- (Source: X.521 [X.521])
( 2.5.6.14 NAME 'device'
SUP top
@@ -1254,9 +1192,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
l $
description ) )
-3.5 'groupOfNames'
+3.5. 'groupOfNames'
- The 'groupOfNames' object class is the basis of an entry which
+ The 'groupOfNames' object class is the basis of an entry that
represents a set of named objects including information related to
the purpose or maintenance of the set.
(Source: X.521 [X.521])
@@ -1273,25 +1211,35 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
o $
description ) )
-3.6 'groupOfUniqueNames'
+3.6. 'groupOfUniqueNames'
The 'groupOfUniqueNames' object class is the same as the
'groupOfNames' object class except that the object names are not
repeated or reassigned within a set scope.
(Source: X.521 [X.521])
- ( 2.5.6.17 NAME 'groupOfUniqueNames'
- SUP top
- STRUCTURAL
- MUST ( uniqueMember $
-Sciberras Expires 30 July 2006 [Page 23]
+
+
+
+
+
+
+
+
+
+
+Sciberras Standards Track [Page 22]
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+RFC 4519 LDAP: Schema for User Applications June 2006
+ ( 2.5.6.17 NAME 'groupOfUniqueNames'
+ SUP top
+ STRUCTURAL
+ MUST ( uniqueMember $
cn )
MAY ( businessCategory $
seeAlso $
@@ -1300,9 +1248,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
o $
description ) )
-3.7 'locality'
+3.7. 'locality'
- The 'locality' object class is the basis of an entry which represents
+ The 'locality' object class is the basis of an entry that represents
a place in the physical world.
(Source: X.521 [X.521])
@@ -1316,9 +1264,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
l $
description ) )
-3.8 'organization'
+3.8. 'organization'
- The 'organization' object class is the basis of an entry which
+ The 'organization' object class is the basis of an entry that
represents a structured group of people.
(Source: X.521 [X.521])
@@ -1330,39 +1278,41 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
businessCategory $ x121Address $ registeredAddress $
destinationIndicator $ preferredDeliveryMethod $
telexNumber $ teletexTerminalIdentifier $
- telephoneNumber $ internationaliSDNNumber $
+ telephoneNumber $ internationalISDNNumber $
facsimileTelephoneNumber $ street $ postOfficeBox $
postalCode $ postalAddress $ physicalDeliveryOfficeName $
st $ l $ description ) )
-3.9 'organizationalPerson'
- The 'organizationalPerson' object class is the basis of an entry
- which represents a person in relation to an organization.
- (Source: X.521 [X.521])
-Sciberras Expires 30 July 2006 [Page 24]
+Sciberras Standards Track [Page 23]
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+RFC 4519 LDAP: Schema for User Applications June 2006
+3.9. 'organizationalPerson'
+
+ The 'organizationalPerson' object class is the basis of an entry that
+ represents a person in relation to an organization.
+ (Source: X.521 [X.521])
+
( 2.5.6.7 NAME 'organizationalPerson'
SUP person
STRUCTURAL
MAY ( title $ x121Address $ registeredAddress $
destinationIndicator $ preferredDeliveryMethod $
telexNumber $ teletexTerminalIdentifier $
- telephoneNumber $ internationaliSDNNumber $
+ telephoneNumber $ internationalISDNNumber $
facsimileTelephoneNumber $ street $ postOfficeBox $
postalCode $ postalAddress $ physicalDeliveryOfficeName $
ou $ st $ l ) )
-3.10 'organizationalRole'
+3.10. 'organizationalRole'
- The 'organizationalRole' object class is the basis of an entry which
- represents a job, function or position in an organization.
+ The 'organizationalRole' object class is the basis of an entry that
+ represents a job, function, or position in an organization.
(Source: X.521 [X.521])
( 2.5.6.8 NAME 'organizationalRole'
@@ -1372,41 +1322,47 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
MAY ( x121Address $ registeredAddress $ destinationIndicator $
preferredDeliveryMethod $ telexNumber $
teletexTerminalIdentifier $ telephoneNumber $
- internationaliSDNNumber $ facsimileTelephoneNumber $
+ internationalISDNNumber $ facsimileTelephoneNumber $
seeAlso $ roleOccupant $ preferredDeliveryMethod $
street $ postOfficeBox $ postalCode $ postalAddress $
physicalDeliveryOfficeName $ ou $ st $ l $
description ) )
-3.11 'organizationalUnit'
+3.11. 'organizationalUnit'
- The 'organizationalUnit' object class is the basis of an entry which
+ The 'organizationalUnit' object class is the basis of an entry that
represents a piece of an organization.
(Source: X.521 [X.521])
+
+
+
+
+
+
+
+
+
+Sciberras Standards Track [Page 24]
+
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
( 2.5.6.5 NAME 'organizationalUnit'
SUP top
STRUCTURAL
MUST ou
MAY ( businessCategory $ description $ destinationIndicator $
- facsimileTelephoneNumber $ internationaliSDNNumber $ l $
+ facsimileTelephoneNumber $ internationalISDNNumber $ l $
physicalDeliveryOfficeName $ postalAddress $ postalCode $
postOfficeBox $ preferredDeliveryMethod $
registeredAddress $ searchGuide $ seeAlso $ st $ street $
telephoneNumber $ teletexTerminalIdentifier $
telexNumber $ userPassword $ x121Address ) )
-
-
-
-Sciberras Expires 30 July 2006 [Page 25]
-
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
3.12 'person'
- The 'person' object class is the basis of an entry which represents a
+ The 'person' object class is the basis of an entry that represents a
human being.
(Source: X.521 [X.521])
@@ -1419,9 +1375,9 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
telephoneNumber $
seeAlso $ description ) )
-3.13 'residentialPerson'
+3.13. 'residentialPerson'
- The 'residentialPerson' object class is the basis of an entry which
+ The 'residentialPerson' object class is the basis of an entry that
includes a person's residence in the representation of the person.
(Source: X.521 [X.521])
@@ -1432,12 +1388,23 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
MAY ( businessCategory $ x121Address $ registeredAddress $
destinationIndicator $ preferredDeliveryMethod $
telexNumber $ teletexTerminalIdentifier $
- telephoneNumber $ internationaliSDNNumber $
+ telephoneNumber $ internationalISDNNumber $
facsimileTelephoneNumber $ preferredDeliveryMethod $
street $ postOfficeBox $ postalCode $ postalAddress $
physicalDeliveryOfficeName $ st $ l ) )
-3.14 'uidObject'
+
+
+
+
+
+
+Sciberras Standards Track [Page 25]
+
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+3.14. 'uidObject'
The 'uidObject' object class permits an entry to contains user
identification information. This object class is defined as
@@ -1450,37 +1417,26 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
AUXILIARY
MUST uid )
-
-
-
-
-
-Sciberras Expires 30 July 2006 [Page 26]
-
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
4. IANA Considerations
- It is requested that the Internet Assigned Numbers Authority (IANA)
- update the LDAP descriptors registry as indicated in the following
- template:
+ The Internet Assigned Numbers Authority (IANA) has updated the LDAP
+ descriptors registry as indicated in the following template:
Subject: Request for LDAP Descriptor Registration Update
- Descriptor (short name): see comment
- Object Identifier: see comment
+ Descriptor (short name): see comments
+ Object Identifier: see comments
Person & email address to contact for further information:
Andrew Sciberras <andrew.sciberras@eb2bcom.com>
Usage: (A = attribute type, O = Object Class) see comment
- Specification: RFC XXXX [editor's note: The RFC number will be
- the one assigned to this document.]
+ Specification: RFC 4519
Author/Change Controller: IESG
+
Comments
- In the LDAP descriptors registry, the following descriptors (short
- names) should be updated to refer to RFC XXXX [editor's note: This
- document]. Names that need to be reserved, rather than assigned to
- an Object Identifier, will contain an Object Identifier value of
- RESERVED.
+
+ In the LDAP descriptors registry, the following descriptors (short
+ names) have been updated to refer to RFC 4519. Names that need to
+ be reserved, rather than assigned to an Object Identifier, will
+ contain an Object Identifier value of RESERVED.
NAME Type OID
------------------------ ---- ----------------------------
@@ -1491,11 +1447,21 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
commonName A 2.5.4.3
country O 2.5.6.2
countryName A 2.5.4.6
- DC A 0.9.2342.19200300.100.1.25
+ dc A 0.9.2342.19200300.100.1.25
dcObject O 1.3.6.1.4.1.1466.344
description A 2.5.4.13
destinationIndicator A 2.5.4.27
device O 2.5.6.14
+
+
+
+Sciberras Standards Track [Page 26]
+
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+ NAME Type OID
+ ------------------------ ---- ----------------------------
distinguishedName A 2.5.4.49
dnQualifier A 2.5.4.46
domainComponent A 0.9.2342.19200300.100.1.25
@@ -1503,21 +1469,13 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
facsimileTelephoneNumber A 2.5.4.23
generationQualifier A 2.5.4.44
givenName A 2.5.4.42
- GN A RESERVED
+ gn A RESERVED
groupOfNames O 2.5.6.9
groupOfUniqueNames O 2.5.6.17
houseIdentifier A 2.5.4.51
initials A 2.5.4.43
-
-
-
-Sciberras Expires 30 July 2006 [Page 27]
-
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
internationalISDNNumber A 2.5.4.25
- L A 2.5.4.7
+ l A 2.5.4.7
locality O 2.5.6.3
localityName A 2.5.4.7
member A 2.5.4.31
@@ -1550,11 +1508,21 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
telephoneNumber A 2.5.4.20
teletexTerminalIdentifier A 2.5.4.22
telexNumber A 2.5.4.21
+
+
+
+Sciberras Standards Track [Page 27]
+
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+ NAME Type OID
+ ------------------------ ---- ----------------------------
title A 2.5.4.12
uid A 0.9.2342.19200300.100.1.1
uidObject O 1.3.6.1.1.3.1
uniqueMember A 2.5.4.50
- userId A 0.9.2342.19200300.100.1.1
+ userid A 0.9.2342.19200300.100.1.1
userPassword A 2.5.4.35
x121Address A 2.5.4.24
x500UniqueIdentifier A 2.5.4.45
@@ -1563,15 +1531,7 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
Attributes of directory entries are used to provide descriptive
information about the real-world objects they represent, which can be
- people, organizations or devices. Most countries have privacy laws
-
-
-
-Sciberras Expires 30 July 2006 [Page 28]
-
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
+ people, organizations, or devices. Most countries have privacy laws
regarding the publication of information about people.
Transfer of cleartext passwords is strongly discouraged where the
@@ -1580,22 +1540,20 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
unauthorized parties.
Multiple attribute values for the 'userPassword' attribute need to be
- used with care. Especially reset/deletion of a password by an admin
- without knowing the old user password gets tricky or impossible if
- multiple values for different applications are present.
+ used with care. Especially reset/deletion of a password by an
+ administrator without knowing the old user password gets tricky or
+ impossible if multiple values for different applications are present.
- Certainly, applications which intend to replace the 'userPassword'
+ Certainly, applications that intend to replace the 'userPassword'
value(s) with new value(s) should use modify/replaceValues (or
- modify/deleteAttribute+addAttribute). Additionally, server
+ modify/deleteAttribute+addAttribute). In addition, server
implementations are encouraged to provide administrative controls
- which, if enabled, restrict the 'userPassword' attribute to one
- value.
+ that, if enabled, restrict the 'userPassword' attribute to one value.
- Note that when used for authentication purposes [AuthMeth], the user
+ Note that when used for authentication purposes [RFC4513], the user
need only prove knowledge of one of the values, not all of the
values.
-
6. Acknowledgements
The definitions, on which this document is based, have been developed
@@ -1604,6 +1562,16 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
This document is an update of RFC 2256 by Mark Wahl. RFC 2256 was a
product of the IETF ASID Working Group.
+
+
+
+
+
+Sciberras Standards Track [Page 28]
+
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
The 'dc' attribute type definition and the 'dcObject' object class
definition in this document supersede the specification in RFC 2247
by S. Kille, M. Wahl, A. Grimstad, R. Huber, and S. Sataluri.
@@ -1614,173 +1582,145 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
The 'uidObject' object class definition in this document supersedes
the specification of the 'uidObject' in RFC 2377 by A. Grimstad, R.
- Huber, S. Sataluri and M. Smith.
+ Huber, S. Sataluri, and M. Wahl.
This document is based upon input of the IETF LDAPBIS working group.
The author wishes to thank S. Legg and K. Zeilenga for their
significant contribution to this update. The author would also like
- to thank Kathy Dally who edited early drafts of this document.
+ to thank Kathy Dally, who edited early versions of this document.
+7. References
+7.1. Normative References
-Sciberras Expires 30 July 2006 [Page 29]
-
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+ [E.123] Notation for national and international telephone numbers,
+ ITU-T Recommendation E.123, 1988
+ [E.164] The international public telecommunication numbering plan,
+ ITU-T Recommendation E.164, 1997
-7. References
+ [F.1] Operational Provisions For The International Public
+ Telegram Service Transmission System, CCITT Recommendation
+ F.1, 1992
+
+ [F.31] Telegram Retransmission System, CCITT Recommendation F.31,
+ 1988
+
+ [ISO3166] ISO 3166, "Codes for the representation of names of
+ countries".
+
+ [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
+ STD 13, RFC 1034, November 1987.
+
+ [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
+ and Support", STD 3, RFC 1123, October 1989.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
+ Specification", RFC 2181, July 1997.
+
+
+
+Sciberras Standards Track [Page 29]
+
+RFC 4519 LDAP: Schema for User Applications June 2006
-7.1 Normative
- [E.123] Notation for national and international telephone
- numbers, ITU-T Recommendation E.123, 1988
+ [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
+ "Internationalizing Domain Names in Applications (IDNA)",
+ RFC 3490, March 2003.
- [E.164] The international public telecommunication numbering
- plan, ITU-T Recommendation E.164, 1997
+ [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names
+ and Passwords", RFC 4013, February 2005.
- [F.1] Operational Provisions For The International Public
- Telegram Service Transmission System, CCITT
- Recommendation F.1, 1992
+ [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 4234, October 2005.
- [F.31] Telegram Retransmission System, CCITT Recommendation
- F.31, 1988
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Technical Specification Road Map", RFC 4510, June
+ 2006.
- [ISO3166] ISO 3166, "Codes for the representation of names of
- countries".
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
- [Models] K. Zeilenga, "LDAP: The Models", draft-ietf-ldapbis-
- models-xx (a work in progress)
+ [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
- [RFC1034] P. Mockapetris, " DOMAIN NAMES - CONCEPTS AND
- FACILITIES", RFC 1034, January 1987
+ [X.121] International numbering plan for public data networks,
+ ITU-T Recommendation X.121, 1996
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, March 1997
+ [X.509] The Directory: Authentication Framework, ITU-T
+ Recommendation X.509, 1993
- [RFC3490] Faltstrom P., Hoffman P., Costello A.,
- "Internationalizing Domain Names in Applications
- (IDNA)", RFC 3490, March 2003
+ [X.520] The Directory: Selected Attribute Types, ITU-T
+ Recommendation X.520, 1993
- [RFC4013] Zeilenga K., "SASLprep: Stringprep profile for User
- Names and Passwords", RFC 4013, February 2005.
+ [X.521] The Directory: Selected Object Classes. ITU-T
+ Recommendation X.521, 1993
- [RFC4234] Crocker, D., Overell P., "Augmented BNF for Syntax
- Specifications: ABNF", RFC 4234, October 2005
+7.2. Informative References
- [Roadmap] Zeilenga, K., "LDAP: Technical Specification Road
- Map", draft-ietf-ldapbis-roadmap-xx (a work in
- progress)
+ [RFC1274] Barker, P. and S. Kille, "The COSINE and Internet X.500
+ Schema", RFC 1274, November 1991.
- [Syntaxes] S. Legg (editor), "LDAP: Syntaxes", draft-ietf-ldapbis-
- syntaxes-xx (a work in progress)
+ [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S.
+ Sataluri, "Using Domains in LDAP/X.500 Distinguished
+ Names", RFC 2247, January 1998.
- [X.121] International numbering plan for public data networks,
- ITU-T Recommendation X.121, 1996
+ [RFC2377] Grimstad, A., Huber, R., Sataluri, S., and M. Wahl,
+ "Naming Plan for Internet Directory-Enabled Applications",
+ RFC 2377, September 1998.
+ [RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP Object
+ Class", RFC 2798, April 2000.
-Sciberras Expires 30 July 2006 [Page 30]
+
+Sciberras Standards Track [Page 30]
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+RFC 4519 LDAP: Schema for User Applications June 2006
- [X.509] The Directory: Authentication Framework, ITU-T
- Recommendation X.509, 1993
+ [RFC4513] Harrison R., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Authentication Methods and Security Mechanisms",
+ RFC 4513, June 2006.
- [X.520] The Directory: Selected Attribute Types, ITU-T
- Recommendation X.520, 1993
+ [RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP) Schema Definitions for X.509 Certificates", RFC
+ 4523, June 2006.
- [X.521] The Directory: Selected Object Classes. ITU-T
- Recommendation X.521, 1993
+ [RFC4524] Zeilenga, E., Ed., "COSINE LDAP/X.500 Schema", RFC 4524,
+ June 2006.
-7.2 Informative
+ [X.500] ITU-T Recommendations X.500 (1993) | ISO/IEC 9594-1:1994,
+ Information Technology - Open Systems Interconnection -
+ The Directory: Overview of concepts, models and services.
- [AuthMeth] Harrison R., "LDAP: Authentication Methods and
- Connection Level Security Mechanisms", draft-ietf-
- ldapbis-authmeth-xx (a work in progress)
- [LDAP-PKI] Zeilenga, K., "Lightweight Directory Access Protocol
- (LDAP) schema definitions for X.509 Certificates",
- draft-zeilenga-ldap-x509-xx (a work in progress)
- [RFC1274] Barker, P., Kille, S.,"The COSINE and Internet X.500
- Schema", RFC 1274, November 1991
- [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and
- Sataluri, S., "Using Domains in LDAP/X.500
- Distinguished Names", RFC 2247, January 1998
- [RFC2377] Grimstad, A., Huber, R., Sataluri, S., and Wahl, M.,
- "Naming Plan for Internet-Enabled Applications", RFC
- 2377, September 1998.
- [RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP Object
- Class", RFC 2798, April 2000
- [X.500] ITU-T Recommendations X.500 (1993) | ISO/IEC
- 9594-1:1994, Information Technology - Open Systems
- Interconnection - The Directory: Overview of concepts,
- models and services.
-8. Author's Address
- Andrew Sciberras
- eB2Bcom
- Suite 3, Woodhouse Corporate Centre,
- 935 Station Street,
- Box Hill North, Victoria 3129
- AUSTRALIA
- Phone: +61 3 9896 7833
-Sciberras Expires 30 July 2006 [Page 31]
-
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
- Email: andrew.sciberras@eb2bcom.com
-9. Intellectual Property Statement
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-10. Full Copyright Statement
- Copyright (C) The Internet Society (2006).
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
@@ -1791,15 +1731,19 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-Sciberras Expires 30 July 2006 [Page 32]
+
+
+
+
+Sciberras Standards Track [Page 31]
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+RFC 4519 LDAP: Schema for User Applications June 2006
- Appendix A Changes Made Since RFC 2256
+Appendix A. Changes Made Since RFC 2256
This appendix lists the changes that have been made from RFC 2256 to
- this I-D.
+ RFC 4519.
This appendix is not a normative part of this specification, which
has been provided for informational purposes only.
@@ -1811,15 +1755,15 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
3. Dependencies on RFC 1274 have been eliminated.
4. Added a Security Considerations section and an IANA
- considerations section.
+ Considerations section.
5. Deleted the conformance requirement for subschema object
- classes in favor of a statement in [Syntaxes].
+ classes in favor of a statement in [RFC4517].
6. Added explanation to attribute types and to each object class.
7. Removed Section 4, Syntaxes, and Section 6, Matching Rules,
- (moved to [Syntaxes]).
+ (moved to [RFC4517]).
8. Removed the certificate-related attribute types:
authorityRevocationList, cACertificate,
@@ -1831,7 +1775,7 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
cRLDistributionPoint, strongAuthenticationUser, and
userSecurityInformation
- LDAP PKI is now discussed in [LDAP-CRL] and [LDAP-CERT].
+ LDAP PKI is now discussed in [RFC4523].
9. Removed the dmdName, knowledgeInformation,
presentationAddress, protocolInformation, and
@@ -1840,83 +1784,44 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
10. Deleted the aliasedObjectName and objectClass attribute type
definitions. Deleted the alias and top object class
- definitions. They are included in [Models].
+ definitions. They are included in [RFC4512].
- 11. Added the 'dc' attribute type from RFC 2247.
-Sciberras Expires 30 July 2006 [Page 33]
+
+Sciberras Standards Track [Page 32]
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+ 11. Added the 'dc' attribute type from RFC 2247, making the
+ distinction between 'stored' and 'query' values when preparing
+ IDN strings.
- 12. Numerous edititorial changes.
+ 12. Numerous editorial changes.
13. Removed upper bound after the SYNTAX oid in all attribute
definitions where it appeared.
- 14. Added text about Unicode, SASLprep and UTF-8 for userPassword.
-
- changes since 07:
+ 14. Added text about Unicode, SASLprep [RFC4013], and UTF-8 for
+ userPassword.
- 15. Corrected examples in preferredDeliveryMethod, uniqueMember,
- postalAddress, and registeredAddress attribute types.
-
- 16. Clarified and corrected examples in owner and roleOccupant
- attribute types.
-
- 17. Added RFC 2234 to normative references.
-
- 18. Added RFC 1274 and RFC 2798 to informative references.
-
- 19. Removed the statement about RFC 2026 conformance.
-
- 20. Added the IPR Disclosure and Notice
-
- 21. Updated the Copyright text.
-
- changes since 08:
-
- 22. Included RFC 2377 into Updates header and Informative
- References
-
- 23. Changed Editor information to Andrew Sciberras.
-
- 24. Updated I-D Template information.
-
- 25. References made consistent with other LDAPbis ID's. [ROADMAP]
- -> [RoadMap] and [AUTHMETH] -> [AuthMeth].
-
- 26. Changed Introduction to include an (LDAP) acronym after the
- first usage.
-
- 27. Renamed section 1.1 to "Relationship with other
- specifications" from "Situation".
-
- 28. Included definitions, comments and references for 'dcObject'
+ 15. Included definitions, comments and references for 'dcObject'
and 'uidObject'.
- 29. Replaced PKI schema references to use draft-zeilenga-ldap-
- x509-xx
-
+ 16. Replaced PKI schema references to use RFC 4523.
+ 17. Spelt out and referenced ABNF on first usage.
-Sciberras Expires 30 July 2006 [Page 34]
-
-INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
-
-
- 30. Spelt out and referenced ABNF on first usage.
-
- 31. Removed Section 2.4 (Source). Replaced the source table with
+ 18. Removed Section 2.4 (Source). Replaced the source table with
explicit references for each definition.
- 32. All references to an attribute type or object class are
+ 19. All references to an attribute type or object class are
enclosed in single quotes.
- 33. The layout of attribute type definitions has been changed to
+ 20. The layout of attribute type definitions has been changed to
provide consistency throughout the document:
> Section Heading
> Description of Attribute type
@@ -1929,35 +1834,130 @@ INTERNET-DRAFT LDAP: Schema for User Applications January 30, 2006
Adding this consistent output included the addition of
examples to some definitions.
- 34. References to alternate names for attributes types are
+ 21. References to alternate names for attributes types are
provided with a reference to where they were originally
specified.
- 35. Clarification of the description of 'distinguishedName' and
+ 22. Clarification of the description of 'distinguishedName' and
'name', in regards to these attribute types being supertypes.
- 36. Spelt out ISDN on first usage.
+ 23. Spelt out ISDN on first usage.
+
+
+
+
- 37. Inserted a reference to [Syntaxes] for the
+Sciberras Standards Track [Page 33]
+
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+ 24. Inserted a reference to [RFC4517] for the
'teletexTerminalIdentifier' definition's SYNTAX OID.
- 38. Additional names were added to the IANA Considerations. Names
+ 25. Additional names were added to the IANA Considerations. Names
include 'commonName', 'dcObject', 'domainComponent', 'GN',
'localityName', 'organizationName', 'organizationUnitName',
'surname', 'uidObject' and 'userid'.
- 39. Renamed all instances of supercede to supersede.
+ 26. Renamed all instances of supercede to supersede.
- 40. Moved [F.1], [F.30] and [SASLprep] from informative to
+ 27. Moved [F.1], [F.31] and [RFC4013] from informative to
normative references.
- 41. Changed the 'c' definition to be consistent with X.500.
+ 28. Changed the 'c' definition to be consistent with X.500.
+
+Author's Address
+
+ Andrew Sciberras
+ eB2Bcom
+ Suite 3, Woodhouse Corporate Centre,
+ 935 Station Street,
+ Box Hill North, Victoria 3129
+ AUSTRALIA
+
+ Phone: +61 3 9896 7833
+ EMail: andrew.sciberras@eb2bcom.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sciberras Standards Track [Page 34]
+
+RFC 4519 LDAP: Schema for User Applications June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
- 42. Added text to 'dc', making the distinction between 'stored'
- and 'query' values when preparing IDN strings.
-Sciberras Expires 30 July 2006 [Page 35]
+Sciberras Standards Track [Page 35]
diff --git a/doc/rfc/rfc4520.txt b/doc/rfc/rfc4520.txt
new file mode 100644
index 0000000000000000000000000000000000000000..9ef5daadea6eac64b9db0557665b7f7a03e5117f
--- /dev/null
+++ b/doc/rfc/rfc4520.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 4520 OpenLDAP Foundation
+BCP: 64 June 2006
+Obsoletes: 3383
+Category: Best Current Practice
+
+
+ Internet Assigned Numbers Authority (IANA) Considerations for
+ the Lightweight Directory Access Protocol (LDAP)
+
+Status of This Memo
+
+ This document specifies an Internet Best Current Practices for the
+ Internet Community, and requests discussion and suggestions for
+ improvements. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This document provides procedures for registering extensible elements
+ of the Lightweight Directory Access Protocol (LDAP). The document
+ also provides guidelines to the Internet Assigned Numbers Authority
+ (IANA) describing conditions under which new values can be assigned.
+
+1. Introduction
+
+ The Lightweight Directory Access Protocol [RFC4510] (LDAP) is an
+ extensible protocol. LDAP supports:
+
+ - the addition of new operations,
+ - the extension of existing operations, and
+ - the extensible schema.
+
+ This document details procedures for registering values used to
+ unambiguously identify extensible elements of the protocol, including
+ the following:
+
+ - LDAP message types
+ - LDAP extended operations and controls
+ - LDAP result codes
+ - LDAP authentication methods
+ - LDAP attribute description options
+ - Object Identifier descriptors
+
+
+
+
+
+Zeilenga Best Current Practice [Page 1]
+
+RFC 4520 IANA Considerations for LDAP June 2006
+
+
+ These registries are maintained by the Internet Assigned Numbers
+ Authority (IANA).
+
+ In addition, this document provides guidelines to IANA describing the
+ conditions under which new values can be assigned.
+
+ This document replaces RFC 3383.
+
+2. Terminology and Conventions
+
+ This section details terms and conventions used in this document.
+
+2.1. Policy Terminology
+
+ The terms "IESG Approval", "Standards Action", "IETF Consensus",
+ "Specification Required", "First Come First Served", "Expert Review",
+ and "Private Use" are used as defined in BCP 26 [RFC2434].
+
+ The term "registration owner" (or "owner") refers to the party
+ authorized to change a value's registration.
+
+2.2. Requirement Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119]. In
+ this case, "the specification", as used by BCP 14, refers to the
+ processing of protocols being submitted to the IETF standards
+ process.
+
+2.3. Common ABNF Productions
+
+ A number of syntaxes in this document are described using ABNF
+ [RFC4234]. These syntaxes rely on the following common productions:
+
+ ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
+ LDIGIT = %x31-39 ; "1"-"9"
+ DIGIT = %x30 / LDIGIT ; "0"-"9"
+ HYPHEN = %x2D ; "-"
+ DOT = %x2E ; "."
+ number = DIGIT / ( LDIGIT 1*DIGIT )
+ keychar = ALPHA / DIGIT / HYPHEN
+ leadkeychar = ALPHA
+ keystring = leadkeychar *keychar
+ keyword = keystring
+
+ Keywords are case insensitive.
+
+
+
+
+Zeilenga Best Current Practice [Page 2]
+
+RFC 4520 IANA Considerations for LDAP June 2006
+
+
+3. IANA Considerations for LDAP
+
+ This section details each kind of protocol value that can be
+ registered and provides IANA guidelines on how to assign new values.
+
+ IANA may reject obviously bogus registrations.
+
+ LDAP values specified in RFCs MUST be registered. Other LDAP values,
+ except those in private-use name spaces, SHOULD be registered. RFCs
+ SHOULD NOT reference, use, or otherwise recognize unregistered LDAP
+ values.
+
+3.1. Object Identifiers
+
+ Numerous LDAP schema and protocol elements are identified by Object
+ Identifiers (OIDs) [X.680]. Specifications that assign OIDs to
+ elements SHOULD state who delegated the OIDs for their use.
+
+ For IETF-developed elements, specifications SHOULD use OIDs under
+ "Internet Directory Numbers" (1.3.6.1.1.x). For elements developed
+ by others, any properly delegated OID can be used, including those
+ under "Internet Directory Numbers" (1.3.6.1.1.x) or "Internet Private
+ Enterprise Numbers" (1.3.6.1.4.1.x).
+
+ Internet Directory Numbers (1.3.6.1.1.x) will be assigned upon Expert
+ Review with Specification Required. Only one OID per specification
+ will be assigned. The specification MAY then assign any number of
+ OIDs within this arc without further coordination with IANA.
+
+ Internet Private Enterprise Numbers (1.3.6.1.4.1.x) are assigned by
+ IANA <http://www.iana.org/cgi-bin/enterprise.pl>. Practices for IANA
+ assignment of Internet Private Enterprise Numbers are detailed in RFC
+ 2578 [RFC2578].
+
+ To avoid interoperability problems between early implementations of a
+ "work in progress" and implementations of the published specification
+ (e.g., the RFC), experimental OIDs SHOULD be used in "works in
+ progress" and early implementations. OIDs under the Internet
+ Experimental OID arc (1.3.6.1.3.x) may be used for this purpose.
+ Practices for IANA assignment of these Internet Experimental numbers
+ are detailed in RFC 2578 [RFC2578].
+
+3.2. Protocol Mechanisms
+
+ LDAP provides a number of Root DSA-Specific Entry (DSE) attributes
+ for discovery of protocol mechanisms identified by OIDs, including
+ the supportedControl, supportedExtension, and supportedFeatures
+ attributes [RFC4512].
+
+
+
+Zeilenga Best Current Practice [Page 3]
+
+RFC 4520 IANA Considerations for LDAP June 2006
+
+
+ A registry of OIDs used for discovery of protocol mechanisms is
+ provided to allow implementors and others to locate the technical
+ specification for these protocol mechanisms. Future specifications
+ of additional Root DSE attributes holding values identifying protocol
+ mechanisms MAY extend this registry for their values.
+
+ Protocol mechanisms are registered on a First Come First Served
+ basis.
+
+3.3. LDAP Syntaxes
+
+ This registry provides a listing of LDAP syntaxes [RFC4512]. Each
+ LDAP syntax is identified by an OID. This registry is provided to
+ allow implementors and others to locate the technical specification
+ describing a particular LDAP Syntax.
+
+ LDAP Syntaxes are registered on a First Come First Served with
+ Specification Required basis.
+
+ Note: Unlike object classes, attribute types, and various other kinds
+ of schema elements, descriptors are not used in LDAP to
+ identify LDAP Syntaxes.
+
+3.4. Object Identifier Descriptors
+
+ LDAP allows short descriptive names (or descriptors) to be used
+ instead of a numeric Object Identifier to identify select protocol
+ extensions [RFC4511], schema elements [RFC4512], LDAP URL [RFC4516]
+ extensions, and other objects.
+
+ Although the protocol allows the same descriptor to refer to
+ different object identifiers in certain cases and the registry
+ supports multiple registrations of the same descriptor (each
+ indicating a different kind of schema element and different object
+ identifier), multiple registrations of the same descriptor are to be
+ avoided. All such multiple registration requests require Expert
+ Review.
+
+ Descriptors are restricted to strings of UTF-8 [RFC3629] encoded
+ Unicode characters restricted by the following ABNF:
+
+ name = keystring
+
+ Descriptors are case insensitive.
+
+ Multiple names may be assigned to a given OID. For purposes of
+ registration, an OID is to be represented in numeric OID form (e.g.,
+ 1.1.0.23.40) conforming to the following ABNF:
+
+
+
+Zeilenga Best Current Practice [Page 4]
+
+RFC 4520 IANA Considerations for LDAP June 2006
+
+
+ numericoid = number 1*( DOT number )
+
+ While the protocol places no maximum length restriction upon
+ descriptors, they should be short. Descriptors longer than 48
+ characters may be viewed as too long to register.
+
+ A value ending with a hyphen ("-") reserves all descriptors that
+ start with that value. For example, the registration of the option
+ "descrFamily-" reserves all options that start with "descrFamily-"
+ for some related purpose.
+
+ Descriptors beginning with "x-" are for Private Use and cannot be
+ registered.
+
+ Descriptors beginning with "e-" are reserved for experiments and will
+ be registered on a First Come First Served basis.
+
+ All other descriptors require Expert Review to be registered.
+
+ The registrant need not "own" the OID being named.
+
+ The OID name space is managed by the ISO/IEC Joint Technical
+ Committee 1 - Subcommittee 6.
+
+3.5. AttributeDescription Options
+
+ An AttributeDescription [RFC4512] can contain zero or more options
+ specifying additional semantics. An option SHALL be restricted to a
+ string of UTF-8 encoded Unicode characters limited by the following
+ ABNF:
+
+ option = keystring
+
+ Options are case insensitive.
+
+ While the protocol places no maximum length restriction upon option
+ strings, they should be short. Options longer than 24 characters may
+ be viewed as too long to register.
+
+ Values ending with a hyphen ("-") reserve all option names that start
+ with the name. For example, the registration of the option
+ "optionFamily-" reserves all options that start with "optionFamily-"
+ for some related purpose.
+
+ Options beginning with "x-" are for Private Use and cannot be
+ registered.
+
+
+
+
+
+Zeilenga Best Current Practice [Page 5]
+
+RFC 4520 IANA Considerations for LDAP June 2006
+
+
+ Options beginning with "e-" are reserved for experiments and will be
+ registered on a First Come First Served basis.
+
+ All other options require Standards Action or Expert Review with
+ Specification Required to be registered.
+
+3.6. LDAP Message Types
+
+ Each protocol message is encapsulated in an LDAPMessage envelope
+ [RFC4511. The protocolOp CHOICE indicates the type of message
+ encapsulated. Each message type consists of an ASN.1 identifier in
+ the form of a keyword and a non-negative choice number. The choice
+ number is combined with the class (APPLICATION) and data type
+ (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the message's
+ encoding. The choice numbers for existing protocol messages are
+ implicit in the protocol's ASN.1 defined in [RFC4511].
+
+ New values will be registered upon Standards Action.
+
+ Note: LDAP provides extensible messages that reduce but do not
+ eliminate the need to add new message types.
+
+3.7. LDAP Authentication Method
+
+ The LDAP Bind operation supports multiple authentication methods
+ [RFC4511]. Each authentication choice consists of an ASN.1
+ identifier in the form of a keyword and a non-negative integer.
+
+ The registrant SHALL classify the authentication method usage using
+ one of the following terms:
+
+ COMMON - method is appropriate for common use on the
+ Internet.
+ LIMITED USE - method is appropriate for limited use.
+ OBSOLETE - method has been deprecated or otherwise found to
+ be inappropriate for any use.
+
+ Methods without publicly available specifications SHALL NOT be
+ classified as COMMON. New registrations of the class OBSOLETE cannot
+ be registered.
+
+ New authentication method integers in the range 0-1023 require
+ Standards Action to be registered. New authentication method
+ integers in the range 1024-4095 require Expert Review with
+ Specification Required. New authentication method integers in the
+ range 4096-16383 will be registered on a First Come First Served
+ basis. Keywords associated with integers in the range 0-4095 SHALL
+ NOT start with "e-" or "x-". Keywords associated with integers in
+
+
+
+Zeilenga Best Current Practice [Page 6]
+
+RFC 4520 IANA Considerations for LDAP June 2006
+
+
+ the range 4096-16383 SHALL start with "e-". Values greater than or
+ equal to 16384 and keywords starting with "x-" are for Private Use
+ and cannot be registered.
+
+ Note: LDAP supports Simple Authentication and Security Layers
+ [RFC4422] as an authentication choice. SASL is an extensible
+ authentication framework.
+
+3.8. LDAP Result Codes
+
+ LDAP result messages carry a resultCode enumerated value to indicate
+ the outcome of the operation [RFC4511]. Each result code consists of
+ an ASN.1 identifier in the form of a keyword and a non-negative
+ integer.
+
+ New resultCodes integers in the range 0-1023 require Standards Action
+ to be registered. New resultCode integers in the range 1024-4095
+ require Expert Review with Specification Required. New resultCode
+ integers in the range 4096-16383 will be registered on a First Come
+ First Served basis. Keywords associated with integers in the range
+ 0-4095 SHALL NOT start with "e-" or "x-". Keywords associated with
+ integers in the range 4096-16383 SHALL start with "e-". Values
+ greater than or equal to 16384 and keywords starting with "x-" are
+ for Private Use and cannot be registered.
+
+3.9. LDAP Search Scope
+
+ LDAP SearchRequest messages carry a scope-enumerated value to
+ indicate the extent of search within the DIT [RFC4511]. Each search
+ value consists of an ASN.1 identifier in the form of a keyword and a
+ non-negative integer.
+
+ New scope integers in the range 0-1023 require Standards Action to be
+ registered. New scope integers in the range 1024-4095 require Expert
+ Review with Specification Required. New scope integers in the range
+ 4096-16383 will be registered on a First Come First Served basis.
+ Keywords associated with integers in the range 0-4095 SHALL NOT start
+ with "e-" or "x-". Keywords associated with integers in the range
+ 4096-16383 SHALL start with "e-". Values greater than or equal to
+ 16384 and keywords starting with "x-" are for Private Use and cannot
+ be registered.
+
+3.10. LDAP Filter Choice
+
+ LDAP filters are used in making assertions against an object
+ represented in the directory [RFC4511]. The Filter CHOICE indicates
+ a type of assertion. Each Filter CHOICE consists of an ASN.1
+ identifier in the form of a keyword and a non-negative choice number.
+
+
+
+Zeilenga Best Current Practice [Page 7]
+
+RFC 4520 IANA Considerations for LDAP June 2006
+
+
+ The choice number is combined with the class (APPLICATION) and data
+ type (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the
+ message's encoding.
+
+ Note: LDAP provides the extensibleMatching choice, which reduces but
+ does not eliminate the need to add new filter choices.
+
+3.11. LDAP ModifyRequest Operation Type
+
+ The LDAP ModifyRequest carries a sequence of modification operations
+ [RFC4511]. Each kind (e.g., add, delete, replace) of operation
+ consists of an ASN.1 identifier in the form of a keyword and a non-
+ negative integer.
+
+ New operation type integers in the range 0-1023 require Standards
+ Action to be registered. New operation type integers in the range
+ 1024-4095 require Expert Review with Specification Required. New
+ operation type integers in the range 4096-16383 will be registered on
+ a First Come First Served basis. Keywords associated with integers
+ in the range 0-4095 SHALL NOT start with "e-" or "x-". Keywords
+ associated with integers in the range 4096-16383 SHALL start with
+ "e-". Values greater than or equal to 16384 and keywords starting
+ with "x-" are for Private Use and cannot be registered.
+
+3.12. LDAP authzId Prefixes
+
+ Authorization Identities in LDAP are strings conforming to the
+ <authzId> production [RFC4513]. This production is extensible. Each
+ new specific authorization form is identified by a prefix string
+ conforming to the following ABNF:
+
+ prefix = keystring COLON
+ COLON = %x3A ; COLON (":" U+003A)
+
+ Prefixes are case insensitive.
+
+ While the protocol places no maximum length restriction upon prefix
+ strings, they should be short. Prefixes longer than 12 characters
+ may be viewed as too long to register.
+
+ Prefixes beginning with "x-" are for Private Use and cannot be
+ registered.
+
+ Prefixes beginning with "e-" are reserved for experiments and will be
+ registered on a First Come First Served basis.
+
+ All other prefixes require Standards Action or Expert Review with
+ Specification Required to be registered.
+
+
+
+Zeilenga Best Current Practice [Page 8]
+
+RFC 4520 IANA Considerations for LDAP June 2006
+
+
+3.13. Directory Systems Names
+
+ The IANA-maintained "Directory Systems Names" registry [IANADSN] of
+ valid keywords for well-known attributes was used in the LDAPv2
+ string representation of a distinguished name [RFC1779]. LDAPv2 is
+ now Historic [RFC3494].
+
+ Directory systems names are not known to be used in any other
+ context. LDAPv3 [RFC4514] uses Object Identifier Descriptors
+ [Section 3.2] (which have a different syntax than directory system
+ names).
+
+ New Directory System Names will no longer be accepted. For
+ historical purposes, the current list of registered names should
+ remain publicly available.
+
+4. Registration Procedure
+
+ The procedure given here MUST be used by anyone who wishes to use a
+ new value of a type described in Section 3 of this document.
+
+ The first step is for the requester to fill out the appropriate form.
+ Templates are provided in Appendix A.
+
+ If the policy is Standards Action, the completed form SHOULD be
+ provided to the IESG with the request for Standards Action. Upon
+ approval of the Standards Action, the IESG SHALL forward the request
+ (possibly revised) to IANA. The IESG SHALL be regarded as the
+ registration owner of all values requiring Standards Action.
+
+ If the policy is Expert Review, the requester SHALL post the
+ completed form to the <directory@apps.ietf.org> mailing list for
+ public review. The review period is two (2) weeks. If a revised
+ form is later submitted, the review period is restarted. Anyone may
+ subscribe to this list by sending a request to <directory-
+ request@apps.ietf.org>. During the review, objections may be raised
+ by anyone (including the Expert) on the list. After completion of
+ the review, the Expert, based on public comments, SHALL either
+ approve the request and forward it to the IANA OR deny the request.
+ In either case, the Expert SHALL promptly notify the requester of the
+ action. Actions of the Expert may be appealed [RFC2026]. The Expert
+ is appointed by Applications Area Directors. The requester is viewed
+ as the registration owner of values registered under Expert Review.
+
+ If the policy is First Come First Served, the requester SHALL submit
+ the completed form directly to the IANA: <iana@iana.org>. The
+ requester is viewed as the registration owner of values registered
+ under First Come First Served.
+
+
+
+Zeilenga Best Current Practice [Page 9]
+
+RFC 4520 IANA Considerations for LDAP June 2006
+
+
+ Neither the Expert nor IANA will take position on the claims of
+ copyright or trademark issues regarding completed forms.
+
+ Prior to submission of the Internet Draft (I-D) to the RFC Editor but
+ after IESG review and tentative approval, the document editor SHOULD
+ revise the I-D to use registered values.
+
+5. Registration Maintenance
+
+ This section discusses maintenance of registrations.
+
+5.1. Lists of Registered Values
+
+ IANA makes lists of registered values readily available to the
+ Internet community on its web site: <http://www.iana.org/>.
+
+5.2. Change Control
+
+ The registration owner MAY update the registration subject to the
+ same constraints and review as with new registrations. In cases
+ where the registration owner is unable or is unwilling to make
+ necessary updates, the IESG MAY assume ownership of the registration
+ in order to update the registration.
+
+5.3. Comments
+
+ For cases where others (anyone other than the registration owner)
+ have significant objections to the claims in a registration and the
+ registration owner does not agree to change the registration,
+ comments MAY be attached to a registration upon Expert Review. For
+ registrations owned by the IESG, the objections SHOULD be addressed
+ by initiating a request for Expert Review.
+
+ The form of these requests is ad hoc, but MUST include the specific
+ objections to be reviewed and SHOULD contain (directly or by
+ reference) materials supporting the objections.
+
+6. Security Considerations
+
+ The security considerations detailed in BCP 26 [RFC2434] are
+ generally applicable to this document. Additional security
+ considerations specific to each name space are discussed in Section
+ 3, where appropriate.
+
+ Security considerations for LDAP are discussed in documents
+ comprising the technical specification [RFC4510].
+
+
+
+
+
+Zeilenga Best Current Practice [Page 10]
+
+RFC 4520 IANA Considerations for LDAP June 2006
+
+
+7. Acknowledgement
+
+ This document is a product of the IETF LDAP Revision (LDAPBIS)
+ Working Group (WG). This document is a revision of RFC 3383, also a
+ product of the LDAPBIS WG.
+
+ This document includes text borrowed from "Guidelines for Writing an
+ IANA Considerations Section in RFCs" [RFC2434] by Thomas Narten and
+ Harald Alvestrand.
+
+8. References
+
+8.1. Normative References
+
+ [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
+ 3", BCP 9, RFC 2026, October 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+ October 1998.
+
+ [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
+ "Structure of Management Information Version 2 (SMIv2)",
+ STD 58, RFC 2578, April 1999.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003.
+
+ [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 4234, October 2005.
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Technical Specification Road Map", RFC 4510, June
+ 2006.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+ [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Authentication Methods and Security Mechanisms",
+ RFC 4513, June 2006.
+
+
+
+Zeilenga Best Current Practice [Page 11]
+
+RFC 4520 IANA Considerations for LDAP June 2006
+
+
+ [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory Access
+ Protocol (LDAP): Uniform Resource Locator", RFC 4516, June
+ 2006.
+
+ [Unicode] The Unicode Consortium, "The Unicode Standard, Version
+ 3.2.0" is defined by "The Unicode Standard, Version 3.0"
+ (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
+ as amended by the "Unicode Standard Annex #27: Unicode
+ 3.1" (http://www.unicode.org/reports/tr27/) and by the
+ "Unicode Standard Annex #28: Unicode 3.2"
+ (http://www.unicode.org/reports/tr28/).
+
+ [X.680] International Telecommunication Union - Telecommunication
+ Standardization Sector, "Abstract Syntax Notation One
+ (ASN.1) - Specification of Basic Notation", X.680(2002)
+ (also ISO/IEC 8824-1:2002).
+
+8.2. Informative References
+
+ [RFC1779] Kille, S., "A String Representation of Distinguished
+ Names", RFC 1779, March 1995.
+
+ [RFC3494] Zeilenga, K.,"Lightweight Directory Access Protocol
+ version 2 (LDAPv2) to Historic Status", RFC 3494, March
+ 2003.
+
+ [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): String Representation of Distinguished Names", RFC
+ 4514, June 2006.
+
+ [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
+ Authentication and Security Layer (SASL)", RFC 4422, June
+ 2006.
+
+ [IANADSN] IANA, "Directory Systems Names",
+ http://www.iana.org/assignments/directory-system-names.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 12]
+
+RFC 4520 IANA Considerations for LDAP June 2006
+
+
+Appendix A. Registration Templates
+
+ This appendix provides registration templates for registering new
+ LDAP values. Note that more than one value may be requested by
+ extending the template by listing multiple values, or through use of
+ tables.
+
+A.1. LDAP Object Identifier Registration Template
+
+ Subject: Request for LDAP OID Registration
+
+ Person & email address to contact for further information:
+
+ Specification: (I-D)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request.)
+
+A.2. LDAP Protocol Mechanism Registration Template
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+
+ Object Identifier:
+
+ Description:
+
+ Person & email address to contact for further information:
+
+ Usage: (One of Control or Extension or Feature or other)
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request.)
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 13]
+
+RFC 4520 IANA Considerations for LDAP June 2006
+
+
+A.3. LDAP Syntax Registration Template
+
+ Subject: Request for LDAP Syntax Registration
+
+ Object Identifier:
+
+ Description:
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request.)
+
+A.4. LDAP Descriptor Registration Template
+
+ Subject: Request for LDAP Descriptor Registration
+
+ Descriptor (short name):
+
+ Object Identifier:
+
+ Person & email address to contact for further information:
+
+ Usage: (One of administrative role, attribute type, matching rule,
+ name form, object class, URL extension, or other)
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request.)
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 14]
+
+RFC 4520 IANA Considerations for LDAP June 2006
+
+
+A.5. LDAP Attribute Description Option Registration Template
+
+ Subject: Request for LDAP Attribute Description Option Registration
+ Option Name:
+
+ Family of Options: (YES or NO)
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request.)
+
+A.6. LDAP Message Type Registration Template
+
+ Subject: Request for LDAP Message Type Registration
+
+ LDAP Message Name:
+
+ Person & email address to contact for further information:
+
+ Specification: (Approved I-D)
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request.)
+
+A.7. LDAP Authentication Method Registration Template
+
+ Subject: Request for LDAP Authentication Method Registration
+
+ Authentication Method Name:
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Intended Usage: (One of COMMON, LIMITED-USE, OBSOLETE)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request.)
+
+
+
+Zeilenga Best Current Practice [Page 15]
+
+RFC 4520 IANA Considerations for LDAP June 2006
+
+
+A.8. LDAP Result Code Registration Template
+
+ Subject: Request for LDAP Result Code Registration
+
+ Result Code Name:
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request.)
+
+A.8. LDAP Search Scope Registration Template
+
+ Subject: Request for LDAP Search Scope Registration
+
+ Search Scope Name:
+
+ Filter Scope String:
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request.)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 16]
+
+RFC 4520 IANA Considerations for LDAP June 2006
+
+
+A.9. LDAP Filter Choice Registration Template
+
+ Subject: Request for LDAP Filter Choice Registration
+
+ Filter Choice Name:
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request.)
+
+A.10. LDAP ModifyRequest Operation Registration Template
+
+ Subject: Request for LDAP ModifyRequest Operation Registration
+
+ ModifyRequest Operation Name:
+
+ Person & email address to contact for further information:
+
+ Specification: (RFC, I-D, URI)
+
+ Author/Change Controller:
+
+ Comments:
+
+ (Any comments that the requester deems relevant to the request.)
+
+Appendix B. Changes since RFC 3383
+
+ This informative appendix provides a summary of changes made since
+ RFC 3383.
+
+ - Object Identifier Descriptors practices were updated to require
+ all descriptors defined in RFCs to be registered and
+ recommending all other descriptors (excepting those in
+ private-use name space) be registered. Additionally, all
+ requests for multiple registrations of the same descriptor are
+ now subject to Expert Review.
+
+ - Protocol Mechanisms practices were updated to include values of
+ the 'supportedFeatures' attribute type.
+
+
+
+
+
+Zeilenga Best Current Practice [Page 17]
+
+RFC 4520 IANA Considerations for LDAP June 2006
+
+
+ - LDAP Syntax, Search Scope, Filter Choice, ModifyRequest
+ operation, and authzId prefixes registries were added.
+
+ - References to RFCs comprising the LDAP technical specifications
+ have been updated to latest revisions.
+
+ - References to ISO 10646 have been replaced with [Unicode].
+
+ - The "Assigned Values" appendix providing initial registry
+ values was removed.
+
+ - Numerous editorial changes were made.
+
+Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 18]
+
+RFC 4520 IANA Considerations for LDAP June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 19]
+
diff --git a/doc/rfc/rfc4521.txt b/doc/rfc/rfc4521.txt
new file mode 100644
index 0000000000000000000000000000000000000000..813ff1e30f39b665916bfa4880d4f2f4cdb465af
--- /dev/null
+++ b/doc/rfc/rfc4521.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 4521 OpenLDAP Foundation
+BCP: 118 June 2006
+Category: Best Current Practice
+
+
+ Considerations for
+ Lightweight Directory Access Protocol (LDAP) Extensions
+
+Status of This Memo
+
+ This document specifies an Internet Best Current Practices for the
+ Internet Community, and requests discussion and suggestions for
+ improvements. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ The Lightweight Directory Access Protocol (LDAP) is extensible. It
+ provides mechanisms for adding new operations, extending existing
+ operations, and expanding user and system schemas. This document
+ discusses considerations for designers of LDAP extensions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 1]
+
+RFC 4521 LDAP Extensions June 2006
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Terminology ................................................3
+ 2. General Considerations ..........................................4
+ 2.1. Scope of Extension .........................................4
+ 2.2. Interaction between extensions .............................4
+ 2.3. Discovery Mechanism ........................................4
+ 2.4. Internationalization Considerations ........................5
+ 2.5. Use of the Basic Encoding Rules ............................5
+ 2.6. Use of Formal Languages ....................................5
+ 2.7. Examples ...................................................5
+ 2.8. Registration of Protocol Values ............................5
+ 3. LDAP Operation Extensions .......................................6
+ 3.1. Controls ...................................................6
+ 3.1.1. Extending Bind Operation with Controls ..............6
+ 3.1.2. Extending the Start TLS Operation with Controls .....7
+ 3.1.3. Extending the Search Operation with Controls ........7
+ 3.1.4. Extending the Update Operations with Controls .......8
+ 3.1.5. Extending the Responseless Operations with Controls..8
+ 3.2. Extended Operations ........................................8
+ 3.3. Intermediate Responses .....................................8
+ 3.4. Unsolicited Notifications ..................................9
+ 4. Extending the LDAP ASN.1 Definition .............................9
+ 4.1. Result Codes ...............................................9
+ 4.2. LDAP Message Types .........................................9
+ 4.3. Authentication Methods ....................................10
+ 4.4. General ASN.1 Extensibility ...............................10
+ 5. Schema Extensions ..............................................10
+ 5.1. LDAP Syntaxes .............................................11
+ 5.2. Matching Rules ............................................11
+ 5.3. Attribute Types ...........................................12
+ 5.4. Object Classes ............................................12
+ 6. Other Extension Mechanisms .....................................12
+ 6.1. Attribute Description Options .............................12
+ 6.2. Authorization Identities ..................................12
+ 6.3. LDAP URL Extensions .......................................12
+ 7. Security Considerations ........................................12
+ 8. Acknowledgements ...............................................13
+ 9. References .....................................................13
+ 9.1. Normative References ......................................13
+ 9.2. Informative References ....................................15
+
+
+
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 2]
+
+RFC 4521 LDAP Extensions June 2006
+
+
+1. Introduction
+
+ The Lightweight Directory Access Protocol (LDAP) [RFC4510] is an
+ extensible protocol.
+
+ LDAP allows for new operations to be added and for existing
+ operations to be enhanced [RFC4511].
+
+ LDAP allows additional schema to be defined [RFC4512][RFC4517]. This
+ can include additional object classes, attribute types, matching
+ rules, additional syntaxes, and other elements of schema. LDAP
+ provides an ability to extend attribute types with options [RFC4512].
+
+ LDAP supports a Simple Authentication and Security Layer (SASL)
+ authentication method [RFC4511][RFC4513]. SASL [RFC4422] is
+ extensible. LDAP may be extended to support additional
+ authentication methods [RFC4511].
+
+ LDAP supports establishment of Transport Layer Security (TLS)
+ [RFC4511][RFC4513]. TLS [RFC4346] is extensible.
+
+ LDAP has an extensible Uniform Resource Locator (URL) format
+ [RFC4516].
+
+ Lastly, LDAP allows for certain extensions to the protocol's Abstract
+ Syntax Notation - One (ASN.1) [X.680] definition to be made. This
+ facilitates a wide range of protocol enhancements, for example, new
+ result codes needed to support extensions to be added through
+ extension of the protocol's ASN.1 definition.
+
+ This document describes practices that engineers should consider when
+ designing extensions to LDAP.
+
+1.1. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119]. In
+ this document, "the specification", as used by BCP 14, RFC 2119,
+ refers to the engineering of LDAP extensions.
+
+ The term "Request Control" refers to a control attached to a client-
+ generated message sent to a server. The term "Response Control"
+ refers to a control attached to a server-generated message sent to a
+ client.
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 3]
+
+RFC 4521 LDAP Extensions June 2006
+
+
+ DIT stands for Directory Information Tree.
+ DSA stands for Directory System Agent, a server.
+ DSE stands for DSA-Specific Entry.
+ DUA stands for Directory User Agent, a client.
+ DN stands for Distinguished Name.
+
+2. General Considerations
+
+2.1. Scope of Extension
+
+ Mutually agreeing peers may, within the confines of an extension,
+ agree to significant changes in protocol semantics. However,
+ designers MUST consider the impact of an extension upon protocol
+ peers that have not agreed to implement or otherwise recognize and
+ support the extension. Extensions MUST be "truly optional"
+ [RFC2119].
+
+2.2. Interaction between extensions
+
+ Designers SHOULD consider how extensions they engineer interact with
+ other extensions.
+
+ Designers SHOULD consider the extensibility of extensions they
+ specify. Extensions to LDAP SHOULD themselves be extensible.
+
+ Except where it is stated otherwise, extensibility is implied.
+
+2.3. Discovery Mechanism
+
+ Extensions SHOULD provide adequate discovery mechanisms.
+
+ As LDAP design is based upon the client-request/server-response
+ paradigm, the general discovery approach is for the client to
+ discover the capabilities of the server before utilizing a particular
+ extension. Commonly, this discovery involves querying the root DSE
+ and/or other DSEs for operational information associated with the
+ extension. LDAP provides no mechanism for a server to discover the
+ capabilities of a client.
+
+ The 'supportedControl' attribute [RFC4512] is used to advertise
+ supported controls. The 'supportedExtension' attribute [RFC4512] is
+ used to advertise supported extended operations. The
+ 'supportedFeatures' attribute [RFC4512] is used to advertise
+ features. Other root DSE attributes MAY be defined to advertise
+ other capabilities.
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 4]
+
+RFC 4521 LDAP Extensions June 2006
+
+
+2.4. Internationalization Considerations
+
+ LDAP is designed to support the full Unicode [Unicode] repertory of
+ characters. Extensions SHOULD avoid unnecessarily restricting
+ applications to subsets of Unicode (e.g., Basic Multilingual Plane,
+ ISO 8859-1, ASCII, Printable String).
+
+ LDAP Language Tag options [RFC3866] provide a mechanism for tagging
+ text (and other) values with language information. Extensions that
+ define attribute types SHOULD allow use of language tags with these
+ attributes.
+
+2.5. Use of the Basic Encoding Rules
+
+ Numerous elements of LDAP are described using ASN.1 [X.680] and are
+ encoded using a particular subset [Protocol, Section 5.2] of the
+ Basic Encoding Rules (BER) [X.690]. To allow reuse of
+ parsers/generators used in implementing the LDAP "core" technical
+ specification [RFC4510], it is RECOMMENDED that extension elements
+ (e.g., extension specific contents of controlValue, requestValue,
+ responseValue fields) described by ASN.1 and encoded using BER be
+ subjected to the restrictions of [Protocol, Section 5.2].
+
+2.6. Use of Formal Languages
+
+ Formal languages SHOULD be used in specifications in accordance with
+ IESG guidelines [FORMAL].
+
+2.7. Examples
+
+ Example DN strings SHOULD conform to the syntax defined in [RFC4518].
+ Example LDAP filter strings SHOULD conform to the syntax defined in
+ [RFC4515]. Example LDAP URLs SHOULD conform to the syntax defined in
+ [RFC4516]. Entries SHOULD be represented using LDIF [RFC2849].
+
+2.8. Registration of Protocol Values
+
+ Designers SHALL register protocol values of their LDAP extensions in
+ accordance with BCP 64, RFC 4520 [RFC4520]. Specifications that
+ create new extensible protocol elements SHALL extend existing
+ registries or establish new registries for values of these elements
+ in accordance with BCP 64, RFC 4520 [RFC4520] and BCP 26, RFC 2434
+ [RFC2434].
+
+
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 5]
+
+RFC 4521 LDAP Extensions June 2006
+
+
+3. LDAP Operation Extensions
+
+ Extensions SHOULD use controls in defining extensions that complement
+ existing operations. Where the extension to be defined does not
+ complement an existing operation, designers SHOULD consider defining
+ an extended operation instead.
+
+ For example, a subtree delete operation could be designed as either
+ an extension of the delete operation or as a new operation. As the
+ feature complements the existing delete operation, use of the control
+ mechanism to extend the delete operation is likely more appropriate.
+
+ As a counter (and contrived) example, a locate services operation (an
+ operation that would return for a DN a set of LDAP URLs to services
+ that may hold the entry named by this DN) could be designed as either
+ a search operation or a new operation. As the feature doesn't
+ complement the search operation (e.g., the operation is not contrived
+ to search for entries held in the Directory Information Tree), it is
+ likely more appropriate to define a new operation using the extended
+ operation mechanism.
+
+3.1. Controls
+
+ Controls [Protocol, Section 4.1.11] are the RECOMMENDED mechanism for
+ extending existing operations. The existing operation can be a base
+ operation defined in [RFC4511] (e.g., search, modify) , an extended
+ operation (e.g., Start TLS [RFC4511], Password Modify [RFC3062]), or
+ an operation defined as an extension to a base or extended operation.
+
+ Extensions SHOULD NOT return Response controls unless the server has
+ specific knowledge that the client can make use of the control.
+ Generally, the client requests the return of a particular response
+ control by providing a related request control.
+
+ An existing operation MAY be extended to return IntermediateResponse
+ messages [Protocol, Section 4.13].
+
+ Specifications of controls SHALL NOT attach additional semantics to
+ the criticality of controls beyond those defined in [Protocol,
+ Section 4.1.11]. A specification MAY mandate the criticality take on
+ a particular value (e.g., TRUE or FALSE), where appropriate.
+
+3.1.1. Extending Bind Operation with Controls
+
+ Controls attached to the request and response messages of a Bind
+ Operation [RFC4511] are not protected by any security layers
+ established by that Bind operation.
+
+
+
+
+Zeilenga Best Current Practice [Page 6]
+
+RFC 4521 LDAP Extensions June 2006
+
+
+ Specifications detailing controls extending the Bind operation SHALL
+ detail that the Bind negotiated security layers do not protect the
+ information contained in these controls and SHALL detail how the
+ information in these controls is protected or why the information
+ does not need protection.
+
+ It is RECOMMENDED that designers consider alternative mechanisms for
+ providing the function. For example, an extended operation issued
+ subsequent to the Bind operation (hence, protected by the security
+ layers negotiated by the Bind operation) might be used to provide the
+ desired function.
+
+ Additionally, designers of Bind control extensions MUST also consider
+ how the controls' semantics interact with individual steps of a
+ multi-step Bind operation. Note that some steps are optional and
+ thus may require special attention in the design.
+
+3.1.2. Extending the Start TLS Operation with Controls
+
+ Controls attached to the request and response messages of a Start TLS
+ Operation [RFC4511] are not protected by the security layers
+ established by the Start TLS operation.
+
+ Specifications detailing controls extending the Start TLS operation
+ SHALL detail that the Start TLS negotiated security layers do not
+ protect the information contained in these controls and SHALL detail
+ how the information in these controls is protected or why the
+ information does not need protection.
+
+ It is RECOMMENDED that designers consider alternative mechanisms for
+ providing the function. For example, an extended operation issued
+ subsequent to the Start TLS operation (hence, protected by the
+ security layers negotiated by the Start TLS operation) might be used
+ to provided the desired function.
+
+3.1.3. Extending the Search Operation with Controls
+
+ The Search operation processing has two distinct phases:
+
+ - finding the base object; and
+
+ - searching for objects at or under that base object.
+
+ Specifications of controls extending the Search Operation should
+ clearly state in which phase(s) the control's semantics apply.
+ Semantics of controls that are not specific to the Search Operation
+ SHOULD apply in the finding phase.
+
+
+
+
+Zeilenga Best Current Practice [Page 7]
+
+RFC 4521 LDAP Extensions June 2006
+
+
+3.1.4. Extending the Update Operations with Controls
+
+ Update operations have properties of atomicity, consistency,
+ isolation, and durability ([ACID]).
+
+ - atomicity: All or none of the DIT changes requested are made.
+
+ - consistency: The resulting DIT state must be conform to schema
+ and other constraints.
+
+ - isolation: Intermediate states are not exposed.
+
+ - durability: The resulting DIT state is preserved until
+ subsequently updated.
+
+ When defining a control that requests additional (or other) DIT
+ changes be made to the DIT, these additional changes SHOULD NOT be
+ treated as part of a separate transaction. The specification MUST be
+ clear as to whether the additional DIT changes are part of the same
+ or a separate transaction as the DIT changes expressed in the request
+ of the base operation.
+
+ When defining a control that requests additional (or other) DIT
+ changes be made to the DIT, the specification MUST be clear as to the
+ order in which these and the base changes are to be applied to the
+ DIT.
+
+3.1.5. Extending the Responseless Operations with Controls
+
+ The Abandon and Unbind operations do not include a response message.
+ For this reason, specifications for controls designed to be attached
+ to Abandon and Unbind requests SHOULD mandate that the control's
+ criticality be FALSE.
+
+3.2. Extended Operations
+
+ Extended Operations [Protocol, Section 4.12] are the RECOMMENDED
+ mechanism for defining new operations. An extended operation
+ consists of an ExtendedRequest message, zero or more
+ IntermediateResponse messages, and an ExtendedResponse message.
+
+3.3. Intermediate Responses
+
+ Extensions SHALL use IntermediateResponse messages instead of
+ ExtendedResponse messages to return intermediate results.
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 8]
+
+RFC 4521 LDAP Extensions June 2006
+
+
+3.4. Unsolicited Notifications
+
+ Unsolicited notifications [Protocol, Section 4.4] offer a capability
+ for the server to notify the client of events not associated with the
+ operation currently being processed.
+
+ Extensions SHOULD be designed such that unsolicited notifications are
+ not returned unless the server has specific knowledge that the client
+ can make use of the notification. Generally, the client requests the
+ return of a particular unsolicited notification by performing a
+ related extended operation.
+
+ For example, a time hack extension could be designed to return
+ unsolicited notifications at regular intervals that were enabled by
+ an extended operation (which possibly specified the desired
+ interval).
+
+4. Extending the LDAP ASN.1 Definition
+
+ LDAP allows limited extension [Protocol, Section 4] of the LDAP ASN.1
+ definition [Protocol, Appendix B] to be made.
+
+4.1. Result Codes
+
+ Extensions that specify new operations or enhance existing operations
+ often need to define new result codes. The extension SHOULD be
+ designed such that a client has a reasonably clear indication of the
+ nature of the successful or non-successful result.
+
+ Extensions SHOULD use existing result codes to indicate conditions
+ that are consistent with the intended meaning [RFC4511][X.511] of
+ these codes. Extensions MAY introduce new result codes [RFC4520]
+ where no existing result code provides an adequate indication of the
+ nature of the result.
+
+ Extensions SHALL NOT disallow or otherwise restrict the return of
+ general service result codes, especially those reporting a protocol,
+ service, or security problem, or indicating that the server is unable
+ or unwilling to complete the operation.
+
+4.2. LDAP Message Types
+
+ While extensions can specify new types of LDAP messages by extending
+ the protocolOp CHOICE of the LDAPMessage SEQUENCE, this is generally
+ unnecessary and inappropriate. Existing operation extension
+ mechanisms (e.g., extended operations, unsolicited notifications, and
+ intermediate responses) SHOULD be used instead. However, there may
+ be cases where an extension does not fit well into these mechanisms.
+
+
+
+Zeilenga Best Current Practice [Page 9]
+
+RFC 4521 LDAP Extensions June 2006
+
+
+ In such cases, a new extension mechanism SHOULD be defined that can
+ be used by multiple extensions that have similar needs.
+
+4.3. Authentication Methods
+
+ The Bind operation currently supports two authentication methods,
+ simple and SASL. SASL [RFC4422] is an extensible authentication
+ framework used by multiple application-level protocols (e.g., BEEP,
+ IMAP, SMTP). It is RECOMMENDED that new authentication processes be
+ defined as SASL mechanisms. New LDAP authentication methods MAY be
+ added to support new authentication frameworks.
+
+ The Bind operation's primary function is to establish the LDAP
+ association [RFC4513]. No other operation SHALL be defined (or
+ extended) to establish the LDAP association. However, other
+ operations MAY be defined to establish other security associations
+ (e.g., IPsec).
+
+4.4. General ASN.1 Extensibility
+
+ Section 4 of [RFC4511] states the following:
+
+ In order to support future extensions to this protocol,
+ extensibility is implied where it is allowed per ASN.1 (i.e.,
+ sequence, set, choice, and enumerated types are extensible). In
+ addition, ellipses (...) have been supplied in ASN.1 types that
+ are explicitly extensible as discussed in [RFC4520]. Because of
+ the implied extensibility, clients and servers MUST (unless
+ otherwise specified) ignore trailing SEQUENCE components whose
+ tags they do not recognize.
+
+ Designers SHOULD avoid introducing extensions that rely on
+ unsuspecting implementations to ignore trailing components of
+ SEQUENCE whose tags they do not recognize.
+
+5. Schema Extensions
+
+ Extensions defining LDAP schema elements SHALL provide schema
+ definitions conforming with syntaxes defined in [Models, Section
+ 4.1]. While provided definitions MAY be reformatted (line wrapped)
+ for readability, this SHALL be noted in the specification.
+
+ For definitions that allow a NAME field, new schema elements SHOULD
+ provide one and only one name. The name SHOULD be short.
+
+ Each schema definition allows a DESC field. The DESC field, if
+ provided, SHOULD contain a short descriptive phrase. The DESC field
+ MUST be regarded as informational. That is, the specification MUST
+
+
+
+Zeilenga Best Current Practice [Page 10]
+
+RFC 4521 LDAP Extensions June 2006
+
+
+ be written such that its interpretation is the same with and without
+ the provided DESC fields.
+
+ The extension SHALL NOT mandate that implementations provide the same
+ DESC field in the schema they publish. Implementors MAY replace or
+ remove the DESC field.
+
+ Published schema elements SHALL NOT be redefined. Replacement schema
+ elements (new OIDs, new NAMEs) SHOULD be defined as needed.
+
+ Schema designers SHOULD reuse existing schema elements, where
+ appropriate. However, any reuse MUST not alter the semantics of the
+ element.
+
+5.1. LDAP Syntaxes
+
+ Each LDAP syntax [RFC4517] is defined in terms of ASN.1 [X.680].
+ Each extension detailing an LDAP syntax MUST specify the ASN.1 data
+ definition associated with the syntax. A distinct LDAP syntax SHOULD
+ be created for each distinct ASN.1 data definition (including
+ constraints).
+
+ Each LDAP syntax SHOULD have a string encoding defined for it. It is
+ RECOMMENDED that this string encoding be restricted to UTF-8
+ [RFC3629] encoded Unicode [Unicode] characters. Use of Generic
+ String Encoding Rules (GSER) [RFC3641][RFC3642] or other generic
+ string encoding rules to provide string encodings for complex ASN.1
+ data definitions is RECOMMENDED. Otherwise, it is RECOMMENDED that
+ the string encoding be described using a formal language (e.g., ABNF
+ [RFC4234]). Formal languages SHOULD be used in specifications in
+ accordance with IESG guidelines [FORMAL].
+
+ If no string encoding is defined, the extension SHALL specify how the
+ transfer encoding is to be indicated. Generally, the extension
+ SHOULD mandate use of binary or other transfer encoding option.
+
+5.2. Matching Rules
+
+ Three basic kinds of matching rules (e.g., EQUALITY, ORDERING, and
+ SUBSTRING) may be associated with an attribute type. In addition,
+ LDAP provides an extensible matching rule mechanism.
+
+ The matching rule specification SHOULD detail which kind of matching
+ rule it is and SHOULD describe which kinds of values it can be used
+ with.
+
+ In addition to requirements stated in the LDAP technical
+ specification, equality matching rules SHOULD be commutative.
+
+
+
+Zeilenga Best Current Practice [Page 11]
+
+RFC 4521 LDAP Extensions June 2006
+
+
+5.3. Attribute Types
+
+ Designers SHOULD carefully consider how the structure of values is to
+ be restricted. Designers SHOULD consider that servers will only
+ enforce constraints of the attribute's syntax. That is, an attribute
+ intended to hold URIs, but that has directoryString syntax, is not
+ restricted to values that are URIs.
+
+ Designers SHOULD carefully consider which matching rules, if any, are
+ appropriate for the attribute type. Matching rules specified for an
+ attribute type MUST be compatible with the attribute type's syntax.
+
+ Extensions specifying operational attributes MUST detail how servers
+ are to maintain and/or utilize values of each operational attribute.
+
+5.4. Object Classes
+
+ Designers SHOULD carefully consider whether each attribute of an
+ object class is required ("MUST") or allowed ("MAY").
+
+ Extensions specifying object classes that allow (or require)
+ operational attributes MUST specify how servers are to maintain
+ and/or utilize entries belonging to these object classes.
+
+6. Other Extension Mechanisms
+
+6.1. Attribute Description Options
+
+ Each option is identified by a string of letters, numbers, and
+ hyphens. This string SHOULD be short.
+
+6.2. Authorization Identities
+
+ Extensions interacting with authorization identities SHALL support
+ the LDAP authzId format [RFC4513]. The authzId format is extensible.
+
+6.3. LDAP URL Extensions
+
+ LDAP URL extensions are identified by a short string, a descriptor.
+ Like other descriptors, the string SHOULD be short.
+
+7. Security Considerations
+
+ LDAP does not place undue restrictions on the kinds of extensions
+ that can be implemented. While this document attempts to outline
+ some specific issues that designers need to consider, it is not (and
+
+
+
+
+
+Zeilenga Best Current Practice [Page 12]
+
+RFC 4521 LDAP Extensions June 2006
+
+
+ cannot be) all encompassing. Designers MUST do their own evaluations
+ of the security considerations applicable to their extensions.
+
+ Designers MUST NOT assume that the LDAP "core" technical
+ specification [RFC4510] adequately addresses the specific concerns
+ surrounding their extensions or assume that their extensions have no
+ specific concerns.
+
+ Extension specifications, however, SHOULD note whether security
+ considerations specific to the feature they are extending, as well as
+ general LDAP security considerations, apply to the extension.
+
+8. Acknowledgements
+
+ The author thanks the IETF LDAP community for their thoughtful
+ comments.
+
+ This work builds upon "LDAP Extension Style Guide" [GUIDE] by Bruce
+ Greenblatt.
+
+9. References
+
+9.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+ October 1998.
+
+ [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) -
+ Technical Specification", RFC 2849, June 2000.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003.
+
+ [RFC3641] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1
+ Types", RFC 3641, October 2003.
+
+ [RFC3642] Legg, S., "Common Elements of Generic String Encoding
+ Rules (GSER) Encodings", RFC 3642, October 2003.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+
+
+
+
+Zeilenga Best Current Practice [Page 13]
+
+RFC 4521 LDAP Extensions June 2006
+
+
+ [RFC3866] Zeilenga, K., Ed., "Language Tags and Ranges in the
+ Lightweight Directory Access Protocol (LDAP)", RFC 3866,
+ July 2004.
+
+ [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 4234, October 2005.
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Technical Specification Road Map", RFC 4510, June
+ 2006.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+ [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Authentication Methods and Security Mechanisms",
+ RFC 4513, June 2006.
+
+ [RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory Access
+ Protocol (LDAP): String Representation of Search Filters",
+ RFC 4515, June 2006.
+
+ [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory Access
+ Protocol (LDAP): Uniform Resource Locator", RFC 4516, June
+ 2006.
+
+ [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
+
+ [RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): String Representation of Distinguished Names", RFC
+ 4518, June 2006.
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+ [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
+ Authentication and Security Layer (SASL)", RFC 4422, June
+ 2006.
+
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 14]
+
+RFC 4521 LDAP Extensions June 2006
+
+
+ [Unicode] The Unicode Consortium, "The Unicode Standard, Version
+ 3.2.0" is defined by "The Unicode Standard, Version 3.0"
+ (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
+ as amended by the "Unicode Standard Annex #27: Unicode
+ 3.1" (http://www.unicode.org/reports/tr27/) and by the
+ "Unicode Standard Annex #28: Unicode 3.2"
+ (http://www.unicode.org/reports/tr28/).
+
+ [FORMAL] IESG, "Guidelines for the use of formal languages in IETF
+ specifications",
+ <http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-
+ specs.txt>, 2001.
+
+ [X.511] International Telecommunication Union - Telecommunication
+ Standardization Sector, "The Directory: Abstract Service
+ Definition", X.511(1993) (also ISO/IEC 9594-3:1993).
+
+ [X.680] International Telecommunication Union - Telecommunication
+ Standardization Sector, "Abstract Syntax Notation One
+ (ASN.1) - Specification of Basic Notation", X.680(2002)
+ (also ISO/IEC 8824-1:2002).
+
+ [X.690] International Telecommunication Union - Telecommunication
+ Standardization Sector, "Specification of ASN.1 encoding
+ rules: Basic Encoding Rules (BER), Canonical Encoding
+ Rules (CER), and Distinguished Encoding Rules (DER)",
+ X.690(2002) (also ISO/IEC 8825-1:2002).
+
+9.2. Informative References
+
+ [ACID] Section 4 of ISO/IEC 10026-1:1992.
+
+ [GUIDE] Greenblatt, B., "LDAP Extension Style Guide", Work in
+ Progress.
+
+ [RFC3062] Zeilenga, K., "LDAP Password Modify Extended Operation",
+ RFC 3062, February 2001.
+
+ [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.1", RFC 4346, April 2006.
+
+Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+Zeilenga Best Current Practice [Page 15]
+
+RFC 4521 LDAP Extensions June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga Best Current Practice [Page 16]
+
diff --git a/doc/drafts/draft-legg-ldap-binary-xx.txt b/doc/rfc/rfc4522.txt
similarity index 53%
rename from doc/drafts/draft-legg-ldap-binary-xx.txt
rename to doc/rfc/rfc4522.txt
index 1a6010758cf63a42824ee34d4607725e8172cf57..11156a07f10eb02317718c5bb197a5009a52c767 100644
--- a/doc/drafts/draft-legg-ldap-binary-xx.txt
+++ b/doc/rfc/rfc4522.txt
@@ -4,45 +4,25 @@
-INTERNET-DRAFT S. Legg
-draft-legg-ldap-binary-04.txt eB2Bcom
-Intended Category: Standards Track 30 January 2006
+Network Working Group S. Legg
+Request for Comments: 4522 eB2Bcom
+Category: Standards Track June 2006
Lightweight Directory Access Protocol (LDAP):
The Binary Encoding Option
- Copyright (C) The Internet Society (2006).
+Status of This Memo
- Status of this Memo
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
- By submitting this Internet-draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
+Copyright Notice
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as
- Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress".
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/1id-abstracts.html
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html
-
- Technical discussion of this document should take place on the IETF
- LDAP Revision Working Group (LDAPbis) mailing list
- <ietf-ldapbis@openldap.org>. Please send editorial comments directly
- to the editor <steven.legg@eb2bcom.com>.
-
- This Internet-Draft expires on 30 July 2006.
+ Copyright (C) The Internet Society (2006).
Abstract
@@ -52,108 +32,55 @@ Abstract
are normally represented when transferred in LDAP operations. This
representation is referred to as the LDAP-specific encoding to
distinguish it from other methods of encoding attribute values. This
-
-
-
-Legg Expires 30 July 2006 [Page 1]
-
-INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
-
-
- document defines an attribute option, the binary option, which can be
+ document defines an attribute option, the binary option, that can be
used to specify that the associated attribute values are instead
encoded according to the Basic Encoding Rules (BER) used by X.500
directories.
+Table of Contents
+ 1. Introduction ....................................................2
+ 2. Conventions .....................................................2
+ 3. The Binary Option ...............................................2
+ 4. Syntaxes Requiring Binary Transfer ..............................3
+ 5. Attributes Returned in a Search .................................4
+ 6. All User Attributes .............................................4
+ 7. Conflicting Requests ............................................5
+ 8. Security Considerations .........................................5
+ 9. IANA Considerations .............................................5
+ 10. References .....................................................5
+ 10.1. Normative References ......................................5
+ 10.2. Informative References ....................................6
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Legg Expires 30 July 2006 [Page 2]
+Legg Standards Track [Page 1]
-INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
+RFC 4522 LDAP: The Binary Encoding Option June 2006
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 3. The binary Option. . . . . . . . . . . . . . . . . . . . . . . 4
- 4. Syntaxes Requiring Binary Transfer . . . . . . . . . . . . . . 4
- 5. Attributes Returned in a Search. . . . . . . . . . . . . . . . 5
- 6. All User Attributes. . . . . . . . . . . . . . . . . . . . . . 6
- 7. Conflicting Requests . . . . . . . . . . . . . . . . . . . . . 6
- 8. Security Considerations. . . . . . . . . . . . . . . . . . . . 6
- 9. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 6
- 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
- 10.1. Normative References. . . . . . . . . . . . . . . . . . 7
- 10.2. Informative References. . . . . . . . . . . . . . . . . 7
- Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
- Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 8
-
1. Introduction
Each attribute stored in a Lightweight Directory Access Protocol
- (LDAP) directory [ROADMAP] has a defined syntax (i.e., data type)
+ (LDAP) directory [RFC4510] has a defined syntax (i.e., data type)
which constrains the structure and format of its values.
- The description of each syntax [SYNTAX] specifies how attribute or
- assertion values [MODELS] conforming to the syntax are normally
- represented when transferred in LDAP operations [PROT]. This
+ The description of each syntax [RFC4517] specifies how attribute or
+ assertion values [RFC4512] conforming to the syntax are normally
+ represented when transferred in LDAP operations [RFC4511]. This
representation is referred to as the LDAP-specific encoding to
distinguish it from other methods of encoding attribute values.
This document defines an attribute option, the binary option, which
- can be used in an attribute description [MODELS] in an LDAP operation
- to specify that the associated attribute values or assertion values
- are, or are requested to be, encoded according to the Basic Encoding
- Rules (BER) [BER] as used by X.500 [X.500] directories, instead of
- the usual LDAP-specific encoding.
+ can be used in an attribute description [RFC4512] in an LDAP
+ operation to specify that the associated attribute values or
+ assertion values are, or are requested to be, encoded according to
+ the Basic Encoding Rules (BER) [BER] as used by X.500 [X.500]
+ directories, instead of the usual LDAP-specific encoding.
The binary option was originally defined in RFC 2251 [RFC2251]. The
- LDAP technical specification [ROADMAP] has obsoleted the previously
+ LDAP technical specification [RFC4510] has obsoleted the previously
defined LDAP technical specification [RFC3377], which included RFC
2251. The binary option was not included in the revised LDAP
technical specification for a variety of reasons including
@@ -161,48 +88,48 @@ Table of Contents
the known inconsistencies.
This document reintroduces the binary option for use with certain
- attribute syntaxes, such as certificate syntax [PKI], which
+ attribute syntaxes, such as certificate syntax [RFC4523], that
specifically require it. No attempt has been made to address use of
- the binary option with attributes of syntaxes which do not require
-
-
-
-Legg Expires 30 July 2006 [Page 3]
-
-INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
-
-
- its use. Unless addressed in a future specification, this use is to
- be avoided.
-
+ the binary option with attributes of syntaxes that do not require its
+ use. Unless addressed in a future specification, this use is to be
+ avoided.
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
[BCP14].
-3. The binary Option
+3. The Binary Option
The binary option is indicated with the attribute option string
"binary" in an attribute description. Note that, like all attribute
options, the string representing the binary option is case
insensitive.
- Where the binary option is present in an attribute description the
+
+
+
+Legg Standards Track [Page 2]
+
+RFC 4522 LDAP: The Binary Encoding Option June 2006
+
+
+ Where the binary option is present in an attribute description, the
associated attribute values or assertion values MUST be BER encoded
(otherwise the values are encoded according to the LDAP-specific
- encoding [SYNTAX] for the attribute's syntax). Note that it is
+ encoding [RFC4517] for the attribute's syntax). Note that it is
possible for a syntax to be defined such that its LDAP-specific
encoding is exactly the same as its BER encoding.
- In terms of the protocol [PROT], the binary option specifies that the
- contents octets of the associated AttributeValue or AssertionValue
- OCTET STRING are a complete BER encoding of the relevant value.
+ In terms of the protocol [RFC4511], the binary option specifies that
+ the contents octets of the associated AttributeValue or
+ AssertionValue OCTET STRING are a complete BER encoding of the
+ relevant value.
- The binary option is not a tagging option [MODELS] so the presence of
- the binary option does not specify an attribute subtype. An
+ The binary option is not a tagging option [RFC4512], so the presence
+ of the binary option does not specify an attribute subtype. An
attribute description containing the binary option references exactly
the same attribute as the attribute description without the binary
option. The supertype/subtype relationships of attributes with
@@ -211,29 +138,21 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
An attribute description SHALL be treated as unrecognized if it
contains the binary option and the syntax of the attribute does not
- have an associated ASN.1 type [SYNTAX], or the BER encoding of values
- of that type is not supported.
+ have an associated ASN.1 type [RFC4517], or the BER encoding of
+ values of that type is not supported.
The presence or absence of the binary option only affects the
- transfer of attribute and assertion values in protocol; servers store
- any particular attribute value in a format of their choosing.
+ transfer of attribute and assertion values in the protocol; servers
+ store any particular attribute value in a format of their choosing.
4. Syntaxes Requiring Binary Transfer
-
-
-
-Legg Expires 30 July 2006 [Page 4]
-
-INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
-
-
The attribute values of certain attribute syntaxes are defined
without an LDAP-specific encoding and are required to be transferred
- in the BER encoded form. For the purposes of this document, these
+ in the BER-encoded form. For the purposes of this document, these
syntaxes are said to have a binary transfer requirement. The
- Certificate, Certificate List, Certificate Pair and Supported
- Algorithm syntaxes [PKI] are examples of syntaxes with a binary
+ certificate, certificate list, certificate pair, and supported
+ algorithm syntaxes [RFC4523] are examples of syntaxes with a binary
transfer requirement. These syntaxes also have an additional
requirement that the exact BER encoding must be preserved. Note that
this is a property of the syntaxes themselves, and not a property of
@@ -241,14 +160,26 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
would need to re-encode values using the Distinguished Encoding Rules
(DER).
+
+
+
+
+
+
+
+Legg Standards Track [Page 3]
+
+RFC 4522 LDAP: The Binary Encoding Option June 2006
+
+
5. Attributes Returned in a Search
- An LDAP search request [PROT] contains a list of the attributes (the
- requested attributes list) to be returned from each entry matching
- the search filter. An attribute description in the requested
- attributes list also implicitly requests all subtypes of the
- attribute type in the attribute description, whether through
- attribute subtyping or attribute tagging option subtyping [MODELS].
+ An LDAP search request [RFC4511] contains a list of the attributes
+ (the requested attributes list) to be returned from each entry
+ matching the search filter. An attribute description in the
+ requested attributes list also implicitly requests all subtypes of
+ the attribute type in the attribute description, whether through
+ attribute subtyping or attribute tagging option subtyping [RFC4512].
The requested attributes list MAY contain attribute descriptions with
the binary option, but MUST NOT contain two attribute descriptions
@@ -259,42 +190,44 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
description (however, see Section 7).
Attributes of a syntax with the binary transfer requirement, if
- returned, SHALL be returned in the binary form, i.e., with the binary
+ returned, SHALL be returned in the binary form (i.e., with the binary
option in the attribute description and the associated attribute
- values BER encoded, regardless of whether the binary option was
+ values BER encoded) regardless of whether the binary option was
present in the request (for the attribute or for one of its
supertypes).
Attributes of a syntax without the binary transfer requirement, if
returned, SHOULD be returned in the form explicitly requested. That
is, if the attribute description in the requested attributes list
- contains the binary option then the corresponding attribute in the
+ contains the binary option, then the corresponding attribute in the
result SHOULD be in the binary form. If the attribute description in
- the request does not contain the binary option then the corresponding
- attribute in the result SHOULD NOT be in the binary form. A server
- MAY omit an attribute from the result if it does not support the
- requested encoding.
+ the request does not contain the binary option, then the
+ corresponding attribute in the result SHOULD NOT be in the binary
+ form. A server MAY omit an attribute from the result if it does not
+ support the requested encoding.
Regardless of the encoding chosen, a particular attribute value is
-
-
-
-Legg Expires 30 July 2006 [Page 5]
-
-INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
-
-
returned at most once.
6. All User Attributes
- If the list of attributes in a search request is empty, or contains
+ If the list of attributes in a search request is empty or contains
the special attribute description string "*", then all user
attributes are requested to be returned.
Attributes of a syntax with the binary transfer requirement, if
returned, SHALL be returned in the binary form.
+
+
+
+
+
+Legg Standards Track [Page 4]
+
+RFC 4522 LDAP: The Binary Encoding Option June 2006
+
+
Attributes of a syntax without the binary transfer requirement and
having a defined LDAP-specific encoding SHOULD NOT be returned in the
binary form.
@@ -308,10 +241,10 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
A particular attribute could be explicitly requested by an attribute
description and/or implicitly requested by the attribute descriptions
of one or more of its supertypes, or by the special attribute
- description string "*". If the binary option is not present in all
- these attribute descriptions, nor absent in all these attribute
- descriptions, then the effect of the request with respect to binary
- transfer is implementation defined.
+ description string "*". If the binary option is present in at least
+ one, but not all, of these attribute descriptions then the effect of
+ the request with respect to binary transfer is implementation
+ defined.
8. Security Considerations
@@ -322,9 +255,9 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
9. IANA Considerations
- The Internet Assigned Numbers Authority (IANA) is requested to update
- the LDAP attribute description option registry [BCP64] as indicated
- by the following template:
+ The Internet Assigned Numbers Authority (IANA) has updated the LDAP
+ attribute description option registry [BCP64] as indicated by the
+ following template:
Subject:
Request for LDAP Attribute Description Option Registration
@@ -332,18 +265,8 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
Family of Options: NO
Person & email address to contact for further information:
Steven Legg <steven.legg@eb2bcom.com>
-
-
-
-Legg Expires 30 July 2006 [Page 6]
-
-INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
-
-
- Specification: RFC XXXX
+ Specification: RFC 4522
Author/Change Controller: IESG
- Comments: The existing registration for "binary"
- should be updated to refer to RFC XXXX.
10. References
@@ -352,32 +275,37 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
[BCP14] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+Legg Standards Track [Page 5]
+
+RFC 4522 LDAP: The Binary Encoding Option June 2006
+
+
[BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
Considerations for the Lightweight Directory Access
- Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
+ Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
- [ROADMAP] Zeilenga, K., "Lightweight Directory Access Protocol
- (LDAP): Technical Specification Road Map",
- draft-ietf-ldapbis-roadmap-xx.txt, a work in progress,
- February 2005.
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Technical Specification Road Map", RFC RFC 4510,
+ June 2006.
- [MODELS] Zeilenga, K., "LDAP: Directory Information Models",
- draft-ietf-ldapbis-models-xx.txt, a work in progress,
- February 2005.
+ [RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol
+ (LDAP): The Protocol", RFC 4511, June 2006.
- [PROT] Sermersheim, J., "LDAP: The Protocol",
- draft-ietf-ldapbis-protocol-xx.txt, a work in progress,
- October 2005.
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
- [SYNTAX] Legg, S., "Lightweight Directory Access Protocol (LDAP):
- Syntaxes and Matching Rules",
- draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress,
- June 2005.
+ [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Syntaxes and Matching Rules", RFC 4517, June
+ 2006.
- [PKI] Zeilenga, Kurt D., "Lightweight Directory Access Protocol
- (LDAP) schema definitions for X.509 Certificates",
- draft-zeilenga-ldap-x509-xx.txt, a work in progress, July
- 2005.
+ [RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP) Schema Definitions for X.509 Certificates", RFC
+ 4523, June 2006.
[BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1,
Information Technology - ASN.1 encoding rules:
@@ -387,15 +315,7 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
10.2. Informative References
- [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
-
-
-
-Legg Expires 30 July 2006 [Page 7]
-
-INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
-
-
+ [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
@@ -404,7 +324,21 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
[X.500] ITU-T Recommendation X.500 (02/01) | ISO/IEC 9594-1:2001,
Information technology - Open Systems Interconnection -
- The Directory: Overview of concepts, models and services
+ The Directory: Overview of concepts, models and services
+
+
+
+
+
+
+
+
+
+
+Legg Standards Track [Page 6]
+
+RFC 4522 LDAP: The Binary Encoding Option June 2006
+
Author's Address
@@ -416,56 +350,21 @@ Author's Address
AUSTRALIA
Phone: +61 3 9896 7830
- Fax: +61 3 9896 7801
+ Fax: +61 3 9896 7801
EMail: steven.legg@eb2bcom.com
-Full Copyright Statement
- Copyright (C) The Internet Society (2006).
- This document is subject to the rights, licenses and restrictions
- contained in BCP 78, and except as set forth therein, the authors
- retain all their rights.
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-Intellectual Property
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
-Legg Expires 30 July 2006 [Page 8]
-
-INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
- found in BCP 78 and BCP 79.
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
@@ -492,10 +391,55 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
+Legg Standards Track [Page 7]
+
+RFC 4522 LDAP: The Binary Encoding Option June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+Acknowledgement
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
@@ -503,5 +447,5 @@ INTERNET-DRAFT LDAP: The Binary Encoding Option January 30, 2006
-Legg Expires 30 July 2006 [Page 9]
+Legg Standards Track [Page 8]
diff --git a/doc/rfc/rfc4523.txt b/doc/rfc/rfc4523.txt
new file mode 100644
index 0000000000000000000000000000000000000000..d2589811c78d3f686210651b709c158c2e1761b4
--- /dev/null
+++ b/doc/rfc/rfc4523.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 4523 OpenLDAP Foundation
+Obsoletes: 2252, 2256, 2587 June 2006
+Category: Standards Track
+
+
+ Lightweight Directory Access Protocol (LDAP)
+ Schema Definitions for X.509 Certificates
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+ Abstract
+
+ This document describes schema for representing X.509 certificates,
+ X.521 security information, and related elements in directories
+ accessible using the Lightweight Directory Access Protocol (LDAP).
+ The LDAP definitions for these X.509 and X.521 schema elements
+ replace those provided in RFCs 2252 and 2256.
+
+1. Introduction
+
+ This document provides LDAP [RFC4510] schema definitions [RFC4512]
+ for a subset of elements specified in X.509 [X.509] and X.521
+ [X.521], including attribute types for certificates, cross
+ certificate pairs, and certificate revocation lists; matching rules
+ to be used with these attribute types; and related object classes.
+ LDAP syntax definitions are also provided for associated assertion
+ and attribute values.
+
+ As the semantics of these elements are as defined in X.509 and X.521,
+ knowledge of X.509 and X.521 is necessary to make use of the LDAP
+ schema definitions provided herein.
+
+ This document, together with [RFC4510], obsoletes RFCs 2252 and 2256
+ in their entirety. The changes (in this document) made since RFC
+ 2252 and RFC 2256 include:
+
+ - addition of pkiUser, pkiCA, and deltaCRL classes;
+
+
+
+Zeilenga Standards Track [Page 1]
+
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+ - update of attribute types to include equality matching rules in
+ accordance with their X.500 specifications;
+
+ - addition of certificate, certificate pair, certificate list,
+ and algorithm identifier matching rules; and
+
+ - addition of LDAP syntax for assertion syntaxes for these
+ matching rules.
+
+ This document obsoletes RFC 2587. The X.509 schema descriptions for
+ LDAPv2 [RFC1777] are Historic, as is LDAPv2 [RFC3494].
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+ Schema definitions are provided using LDAP description formats
+ [RFC4512]. Definitions provided here are formatted (line wrapped)
+ for readability.
+
+2. Syntaxes
+
+ This section describes various syntaxes used in LDAP to transfer
+ certificates and related data types.
+
+2.1. Certificate
+
+ ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'X.509 Certificate' )
+
+ A value of this syntax is an X.509 Certificate [X.509, clause 7].
+
+ Due to changes made to the definition of a Certificate through time,
+ no LDAP-specific encoding is defined for this syntax. Values of this
+ syntax SHOULD be encoded using Distinguished Encoding Rules (DER)
+ [X.690] and MUST only be transferred using the ;binary transfer
+ option [RFC4522]; that is, by requesting and returning values using
+ attribute descriptions such as "userCertificate;binary".
+
+ As values of this syntax contain digitally signed data, values of
+ this syntax and the form of each value MUST be preserved as
+ presented.
+
+2.2. CertificateList
+
+ ( 1.3.6.1.4.1.1466.115.121.1.9 DESC 'X.509 Certificate List' )
+
+ A value of this syntax is an X.509 CertificateList [X.509, clause
+ 7.3].
+
+
+
+Zeilenga Standards Track [Page 2]
+
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+ Due to changes made to the definition of a CertificateList through
+ time, no LDAP-specific encoding is defined for this syntax. Values
+ of this syntax SHOULD be encoded using DER [X.690] and MUST only be
+ transferred using the ;binary transfer option [RFC4522]; that is, by
+ requesting and returning values using attribute descriptions such as
+ "certificateRevocationList;binary".
+
+ As values of this syntax contain digitally signed data, values of
+ this syntax and the form of each value MUST be preserved as
+ presented.
+
+2.3. CertificatePair
+
+ ( 1.3.6.1.4.1.1466.115.121.1.10 DESC 'X.509 Certificate Pair' )
+
+ A value of this syntax is an X.509 CertificatePair [X.509, clause
+ 11.2.3].
+
+ Due to changes made to the definition of an X.509 CertificatePair
+ through time, no LDAP-specific encoding is defined for this syntax.
+ Values of this syntax SHOULD be encoded using DER [X.690] and MUST
+ only be transferred using the ;binary transfer option [RFC4522]; that
+ is, by requesting and returning values using attribute descriptions
+ such as "crossCertificatePair;binary".
+
+ As values of this syntax contain digitally signed data, values of
+ this syntax and the form of each value MUST be preserved as
+ presented.
+
+2.4. SupportedAlgorithm
+
+ ( 1.3.6.1.4.1.1466.115.121.1.49
+ DESC 'X.509 Supported Algorithm' )
+
+ A value of this syntax is an X.509 SupportedAlgorithm [X.509, clause
+ 11.2.7].
+
+ Due to changes made to the definition of an X.509 SupportedAlgorithm
+ through time, no LDAP-specific encoding is defined for this syntax.
+ Values of this syntax SHOULD be encoded using DER [X.690] and MUST
+ only be transferred using the ;binary transfer option [RFC4522]; that
+ is, by requesting and returning values using attribute descriptions
+ such as "supportedAlgorithms;binary".
+
+ As values of this syntax contain digitally signed data, values of
+ this syntax and the form of the value MUST be preserved as presented.
+
+
+
+
+
+Zeilenga Standards Track [Page 3]
+
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+2.5. CertificateExactAssertion
+
+ ( 1.3.6.1.1.15.1 DESC 'X.509 Certificate Exact Assertion' )
+
+ A value of this syntax is an X.509 CertificateExactAssertion [X.509,
+ clause 11.3.1]. Values of this syntax MUST be encoded using the
+ Generic String Encoding Rules (GSER) [RFC3641]. Appendix A.1
+ provides an equivalent Augmented Backus-Naur Form (ABNF) [RFC4234]
+ grammar for this syntax.
+
+2.6. CertificateAssertion
+
+ ( 1.3.6.1.1.15.2 DESC 'X.509 Certificate Assertion' )
+
+ A value of this syntax is an X.509 CertificateAssertion [X.509,
+ clause 11.3.2]. Values of this syntax MUST be encoded using GSER
+ [RFC3641]. Appendix A.2 provides an equivalent ABNF [RFC4234]
+ grammar for this syntax.
+
+2.7. CertificatePairExactAssertion
+
+ ( 1.3.6.1.1.15.3
+ DESC 'X.509 Certificate Pair Exact Assertion' )
+
+ A value of this syntax is an X.509 CertificatePairExactAssertion
+ [X.509, clause 11.3.3]. Values of this syntax MUST be encoded using
+ GSER [RFC3641]. Appendix A.3 provides an equivalent ABNF [RFC4234]
+ grammar for this syntax.
+
+2.8. CertificatePairAssertion
+
+ ( 1.3.6.1.1.15.4 DESC 'X.509 Certificate Pair Assertion' )
+
+ A value of this syntax is an X.509 CertificatePairAssertion [X.509,
+ clause 11.3.4]. Values of this syntax MUST be encoded using GSER
+ [RFC3641]. Appendix A.4 provides an equivalent ABNF [RFC4234]
+ grammar for this syntax.
+
+2.9. CertificateListExactAssertion
+
+ ( 1.3.6.1.1.15.5
+ DESC 'X.509 Certificate List Exact Assertion' )
+
+ A value of this syntax is an X.509 CertificateListExactAssertion
+ [X.509, clause 11.3.5]. Values of this syntax MUST be encoded using
+ GSER [RFC3641]. Appendix A.5 provides an equivalent ABNF grammar for
+ this syntax.
+
+
+
+
+Zeilenga Standards Track [Page 4]
+
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+2.10. CertificateListAssertion
+
+ ( 1.3.6.1.1.15.6 DESC 'X.509 Certificate List Assertion' )
+
+ A value of this syntax is an X.509 CertificateListAssertion [X.509,
+ clause 11.3.6]. Values of this syntax MUST be encoded using GSER
+ [RFC3641]. Appendix A.6 provides an equivalent ABNF [RFC4234]
+ grammar for this syntax.
+
+2.11. AlgorithmIdentifier
+
+ ( 1.3.6.1.1.15.7 DESC 'X.509 Algorithm Identifier' )
+
+ A value of this syntax is an X.509 AlgorithmIdentifier [X.509, Clause
+ 7]. Values of this syntax MUST be encoded using GSER [RFC3641].
+
+ Appendix A.7 provides an equivalent ABNF [RFC4234] grammar for this
+ syntax.
+
+3. Matching Rules
+
+ This section introduces a set of certificate and related matching
+ rules for use in LDAP. These rules are intended to act in accordance
+ with their X.500 counterparts.
+
+3.1. certificateExactMatch
+
+ The certificateExactMatch matching rule compares the presented
+ certificate exact assertion value with an attribute value of the
+ certificate syntax as described in clause 11.3.1 of [X.509].
+
+ ( 2.5.13.34 NAME 'certificateExactMatch'
+ DESC 'X.509 Certificate Exact Match'
+ SYNTAX 1.3.6.1.1.15.1 )
+
+3.2. certificateMatch
+
+ The certificateMatch matching rule compares the presented certificate
+ assertion value with an attribute value of the certificate syntax as
+ described in clause 11.3.2 of [X.509].
+
+ ( 2.5.13.35 NAME 'certificateMatch'
+ DESC 'X.509 Certificate Match'
+ SYNTAX 1.3.6.1.1.15.2 )
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 5]
+
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+3.3. certificatePairExactMatch
+
+ The certificatePairExactMatch matching rule compares the presented
+ certificate pair exact assertion value with an attribute value of the
+ certificate pair syntax as described in clause 11.3.3 of [X.509].
+
+ ( 2.5.13.36 NAME 'certificatePairExactMatch'
+ DESC 'X.509 Certificate Pair Exact Match'
+ SYNTAX 1.3.6.1.1.15.3 )
+
+3.4. certificatePairMatch
+
+ The certificatePairMatch matching rule compares the presented
+ certificate pair assertion value with an attribute value of the
+ certificate pair syntax as described in clause 11.3.4 of [X.509].
+
+ ( 2.5.13.37 NAME 'certificatePairMatch'
+ DESC 'X.509 Certificate Pair Match'
+ SYNTAX 1.3.6.1.1.15.4 )
+
+3.5. certificateListExactMatch
+
+ The certificateListExactMatch matching rule compares the presented
+ certificate list exact assertion value with an attribute value of the
+ certificate pair syntax as described in clause 11.3.5 of [X.509].
+
+ ( 2.5.13.38 NAME 'certificateListExactMatch'
+ DESC 'X.509 Certificate List Exact Match'
+ SYNTAX 1.3.6.1.1.15.5 )
+
+3.6. certificateListMatch
+
+ The certificateListMatch matching rule compares the presented
+ certificate list assertion value with an attribute value of the
+ certificate pair syntax as described in clause 11.3.6 of [X.509].
+
+ ( 2.5.13.39 NAME 'certificateListMatch'
+ DESC 'X.509 Certificate List Match'
+ SYNTAX 1.3.6.1.1.15.6 )
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 6]
+
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+3.7. algorithmIdentifierMatch
+
+ The algorithmIdentifierMatch mating rule compares a presented
+ algorithm identifier with an attribute value of the supported
+ algorithm as described in clause 11.3.7 of [X.509].
+
+ ( 2.5.13.40 NAME 'algorithmIdentifier'
+ DESC 'X.509 Algorithm Identifier Match'
+ SYNTAX 1.3.6.1.1.15.7 )
+
+4. Attribute Types
+
+ This section details a set of certificate and related attribute types
+ for use in LDAP.
+
+4.1. userCertificate
+
+ The userCertificate attribute holds the X.509 certificates issued to
+ the user by one or more certificate authorities, as discussed in
+ clause 11.2.1 of [X.509].
+
+ ( 2.5.4.36 NAME 'userCertificate'
+ DESC 'X.509 user certificate'
+ EQUALITY certificateExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
+
+ As required by this attribute type's syntax, values of this attribute
+ are requested and transferred using the attribute description
+ "userCertificate;binary".
+
+4.2. cACertificate
+
+ The cACertificate attribute holds the X.509 certificates issued to
+ the certificate authority (CA), as discussed in clause 11.2.2 of
+ [X.509].
+
+ ( 2.5.4.37 NAME 'cACertificate'
+ DESC 'X.509 CA certificate'
+ EQUALITY certificateExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
+
+ As required by this attribute type's syntax, values of this attribute
+ are requested and transferred using the attribute description
+ "cACertificate;binary".
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 7]
+
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+4.3. crossCertificatePair
+
+ The crossCertificatePair attribute holds an X.509 certificate pair,
+ as discussed in clause 11.2.3 of [X.509].
+
+ ( 2.5.4.40 NAME 'crossCertificatePair'
+ DESC 'X.509 cross certificate pair'
+ EQUALITY certificatePairExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.10 )
+
+ As required by this attribute type's syntax, values of this attribute
+ are requested and transferred using the attribute description
+ "crossCertificatePair;binary".
+
+4.4. certificateRevocationList
+
+ The certificateRevocationList attribute holds certificate lists, as
+ discussed in 11.2.4 of [X.509].
+
+ ( 2.5.4.39 NAME 'certificateRevocationList'
+ DESC 'X.509 certificate revocation list'
+ EQUALITY certificateListExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
+
+ As required by this attribute type's syntax, values of this attribute
+ are requested and transferred using the attribute description
+ "certificateRevocationList;binary".
+
+4.5. authorityRevocationList
+
+ The authorityRevocationList attribute holds certificate lists, as
+ discussed in 11.2.5 of [X.509].
+
+ ( 2.5.4.38 NAME 'authorityRevocationList'
+ DESC 'X.509 authority revocation list'
+ EQUALITY certificateListExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
+
+ As required by this attribute type's syntax, values of this attribute
+ are requested and transferred using the attribute description
+ "authorityRevocationList;binary".
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 8]
+
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+4.6. deltaRevocationList
+
+ The deltaRevocationList attribute holds certificate lists, as
+ discussed in 11.2.6 of [X.509].
+
+ ( 2.5.4.53 NAME 'deltaRevocationList'
+ DESC 'X.509 delta revocation list'
+ EQUALITY certificateListExactMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
+
+ As required by this attribute type's syntax, values of this attribute
+ MUST be requested and transferred using the attribute description
+ "deltaRevocationList;binary".
+
+4.7. supportedAlgorithms
+
+ The supportedAlgorithms attribute holds supported algorithms, as
+ discussed in 11.2.7 of [X.509].
+
+ ( 2.5.4.52 NAME 'supportedAlgorithms'
+ DESC 'X.509 supported algorithms'
+ EQUALITY algorithmIdentifierMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.49 )
+
+ As required by this attribute type's syntax, values of this attribute
+ MUST be requested and transferred using the attribute description
+ "supportedAlgorithms;binary".
+
+5. Object Classes
+
+ This section details a set of certificate-related object classes for
+ use in LDAP.
+
+5.1. pkiUser
+
+ This object class is used in augment entries for objects that may be
+ subject to certificates, as defined in clause 11.1.1 of [X.509].
+
+ ( 2.5.6.21 NAME 'pkiUser'
+ DESC 'X.509 PKI User'
+ SUP top AUXILIARY
+ MAY userCertificate )
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 9]
+
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+5.2. pkiCA
+
+ This object class is used to augment entries for objects that act as
+ certificate authorities, as defined in clause 11.1.2 of [X.509]
+
+ ( 2.5.6.22 NAME 'pkiCA'
+ DESC 'X.509 PKI Certificate Authority'
+ SUP top AUXILIARY
+ MAY ( cACertificate $ certificateRevocationList $
+ authorityRevocationList $ crossCertificatePair ) )
+
+5.3. cRLDistributionPoint
+
+ This class is used to represent objects that act as CRL distribution
+ points, as discussed in clause 11.1.3 of [X.509].
+
+ ( 2.5.6.19 NAME 'cRLDistributionPoint'
+ DESC 'X.509 CRL distribution point'
+ SUP top STRUCTURAL
+ MUST cn
+ MAY ( certificateRevocationList $
+ authorityRevocationList $ deltaRevocationList ) )
+
+5.4. deltaCRL
+
+ The deltaCRL object class is used to augment entries to hold delta
+ revocation lists, as discussed in clause 11.1.4 of [X.509].
+
+ ( 2.5.6.23 NAME 'deltaCRL'
+ DESC 'X.509 delta CRL'
+ SUP top AUXILIARY
+ MAY deltaRevocationList )
+
+5.5. strongAuthenticationUser
+
+ This object class is used to augment entries for objects
+ participating in certificate-based authentication, as defined in
+ clause 6.15 of [X.521]. This object class is deprecated in favor of
+ pkiUser.
+
+ ( 2.5.6.15 NAME 'strongAuthenticationUser'
+ DESC 'X.521 strong authentication user'
+ SUP top AUXILIARY
+ MUST userCertificate )
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 10]
+
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+5.6. userSecurityInformation
+
+ This object class is used to augment entries with needed additional
+ associated security information, as defined in clause 6.16 of
+ [X.521].
+
+ ( 2.5.6.18 NAME 'userSecurityInformation'
+ DESC 'X.521 user security information'
+ SUP top AUXILIARY
+ MAY ( supportedAlgorithms ) )
+
+5.7. certificationAuthority
+
+ This object class is used to augment entries for objects that act as
+ certificate authorities, as defined in clause 6.17 of [X.521]. This
+ object class is deprecated in favor of pkiCA.
+
+ ( 2.5.6.16 NAME 'certificationAuthority'
+ DESC 'X.509 certificate authority'
+ SUP top AUXILIARY
+ MUST ( authorityRevocationList $
+ certificateRevocationList $ cACertificate )
+ MAY crossCertificatePair )
+
+5.8. certificationAuthority-V2
+
+ This object class is used to augment entries for objects that act as
+ certificate authorities, as defined in clause 6.18 of [X.521]. This
+ object class is deprecated in favor of pkiCA.
+
+ ( 2.5.6.16.2 NAME 'certificationAuthority-V2'
+ DESC 'X.509 certificate authority, version 2'
+ SUP certificationAuthority AUXILIARY
+ MAY deltaRevocationList )
+
+6. Security Considerations
+
+ General certificate considerations [RFC3280] apply to LDAP-aware
+ certificate applications. General LDAP security considerations
+ [RFC4510] apply as well.
+
+ While elements of certificate information are commonly signed, these
+ signatures only protect the integrity of the signed information. In
+ the absence of data integrity protections in LDAP (or lower layer,
+ e.g., IPsec), a server is not assured that client certificate request
+ (or other request) was unaltered in transit. Likewise, a client
+ cannot be assured that the results of the query were unaltered in
+
+
+
+
+Zeilenga Standards Track [Page 11]
+
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+ transit. Hence, it is generally recommended that implementations
+ make use of authentication and data integrity services in LDAP
+ [RFC4513][RFC4511].
+
+7. IANA Considerations
+
+7.1. Object Identifier Registration
+
+ The IANA has registered an LDAP Object Identifier [RFC4520] for use
+ in this technical specification.
+
+ Subject: Request for LDAP OID Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Specification: RFC 4523
+ Author/Change Controller: IESG
+ Comments:
+ Identifies the LDAP X.509 Certificate schema elements
+ introduced in this document.
+
+7.2. Descriptor Registration
+
+ The IANA has updated the LDAP
+ Descriptor registry [RFC44520] as indicated below.
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): see table
+ Object Identifier: see table
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Usage: see table
+ Specification: RFC 4523
+ Author/Change Controller: IESG
+
+ algorithmIdentifierMatch M 2.5.13.40
+ authorityRevocationList A 2.5.4.38 *
+ cACertificate A 2.5.4.37 *
+ cRLDistributionPoint O 2.5.6.19 *
+ certificateExactMatch M 2.5.13.34
+ certificateListExactMatch M 2.5.13.38
+ certificateListMatch M 2.5.13.39
+ certificateMatch M 2.5.13.35
+ certificatePairExactMatch M 2.5.13.36
+ certificatePairMatch M 2.5.13.37
+ certificateRevocationList A 2.5.4.39 *
+ certificationAuthority O 2.5.6.16 *
+ certificationAuthority-V2 O 2.5.6.16.2 *
+ crossCertificatePair A 2.5.4.40 *
+
+
+
+Zeilenga Standards Track [Page 12]
+
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+ deltaCRL O 2.5.6.23 *
+ deltaRevocationList A 2.5.4.53 *
+ pkiCA O 2.5.6.22 *
+ pkiUser O 2.5.6.21 *
+ strongAuthenticationUser O 2.5.6.15 *
+ supportedAlgorithms A 2.5.4.52 *
+ userCertificate A 2.5.4.36 *
+ userSecurityInformation O 2.5.6.18 *
+
+ * Updates previous registration
+
+8. Acknowledgements
+
+ This document is based on X.509, a product of the ITU-T. A number of
+ LDAP schema definitions were based on those found in RFCs 2252 and
+ 2256, both products of the IETF ASID WG. The ABNF productions in
+ Appendix A were provided by Steven Legg. Additional material was
+ borrowed from prior works by David Chadwick and Steven Legg to refine
+ the LDAP X.509 schema.
+
+9. References
+
+9.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3641] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1
+ Types", RFC 3641, October 2003.
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Technical Specification Road Map", RFC 4510, June
+ 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+ [RFC4522] Legg, S., "Lightweight Directory Access Protocol (LDAP):
+ The Binary Encoding Option", RFC 4522, June 2006.
+
+ [X.509] International Telecommunication Union - Telecommunication
+ Standardization Sector, "The Directory: Authentication
+ Framework", X.509(2000).
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 13]
+
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+ [X.521] International Telecommunication Union - Telecommunication
+ Standardization Sector, "The Directory: Selected Object
+ Classes", X.521(2000).
+
+ [X.690] International Telecommunication Union - Telecommunication
+ Standardization Sector, "Specification of ASN.1 encoding
+ rules: Basic Encoding Rules (BER), Canonical Encoding
+ Rules (CER), and Distinguished Encoding Rules (DER)",
+ X.690(2002) (also ISO/IEC 8825-1:2002).
+
+9.2. Informative References
+
+ [RFC1777] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory
+ Access Protocol", RFC 1777, March 1995.
+
+ [RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay):
+ Mapping between X.400 and RFC 822/MIME", RFC 2156, January
+ 1998.
+
+ [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+ X.509 Public Key Infrastructure Certificate and
+ Certificate Revocation List (CRL) Profile", RFC 3280,
+ April 2002.
+
+ [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol
+ version 2 (LDAPv2) to Historic Status", RFC 3494, March
+ 2003.
+
+ [RFC3642] Legg, S., "Common Elements of Generic String Encoding
+ Rules (GSER) Encodings", RFC 3642, October 2003.
+
+ [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 4234, October 2005.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4513] Harrison, R. Ed., "Lightweight Directory Access Protocol
+ (LDAP): Authentication Methods and Security Mechanisms",
+ RFC 4513, June 2006.
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 14]
+
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+Appendix A.
+
+ This appendix is informative.
+
+ This appendix provides ABNF [RFC4234] grammars for GSER-based
+ [RFC3641] LDAP-specific encodings specified in this document. These
+ grammars where produced using, and relying on, Common Elements for
+ GSER Encodings [RFC3642].
+
+A.1. CertificateExactAssertion
+
+ CertificateExactAssertion = "{" sp cea-serialNumber ","
+ sp cea-issuer sp "}"
+
+ cea-serialNumber = id-serialNumber msp CertificateSerialNumber
+ cea-issuer = id-issuer msp Name
+
+ id-serialNumber =
+ %x73.65.72.69.61.6C.4E.75.6D.62.65.72 ; 'serialNumber'
+ id-issuer = %x69.73.73.75.65.72 ; 'issuer'
+
+ Name = id-rdnSequence ":" RDNSequence
+ id-rdnSequence = %x72.64.6E.53.65.71.75.65.6E.63.65 ; 'rdnSequence'
+
+ CertificateSerialNumber = INTEGER
+
+A.2. CertificateAssertion
+
+CertificateAssertion = "{" [ sp ca-serialNumber ]
+ [ sep sp ca-issuer ]
+ [ sep sp ca-subjectKeyIdentifier ]
+ [ sep sp ca-authorityKeyIdentifier ]
+ [ sep sp ca-certificateValid ]
+ [ sep sp ca-privateKeyValid ]
+ [ sep sp ca-subjectPublicKeyAlgID ]
+ [ sep sp ca-keyUsage ]
+ [ sep sp ca-subjectAltName ]
+ [ sep sp ca-policy ]
+ [ sep sp ca-pathToName ]
+ [ sep sp ca-subject ]
+ [ sep sp ca-nameConstraints ] sp "}"
+
+ca-serialNumber = id-serialNumber msp CertificateSerialNumber
+ca-issuer = id-issuer msp Name
+ca-subjectKeyIdentifier = id-subjectKeyIdentifier msp
+ SubjectKeyIdentifier
+ca-authorityKeyIdentifier = id-authorityKeyIdentifier msp
+ AuthorityKeyIdentifier
+
+
+
+Zeilenga Standards Track [Page 15]
+
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+ca-certificateValid = id-certificateValid msp Time
+ca-privateKeyValid = id-privateKeyValid msp GeneralizedTime
+ca-subjectPublicKeyAlgID = id-subjectPublicKeyAlgID msp
+ OBJECT-IDENTIFIER
+ca-keyUsage = id-keyUsage msp KeyUsage
+ca-subjectAltName = id-subjectAltName msp AltNameType
+ca-policy = id-policy msp CertPolicySet
+ca-pathToName = id-pathToName msp Name
+ca-subject = id-subject msp Name
+ca-nameConstraints = id-nameConstraints msp NameConstraintsSyntax
+
+id-subjectKeyIdentifier =
+ %x73.75.62.6A.65.63.74.4B.65.79.49.64.65.6E.74.69.66.69.65.72
+ ; 'subjectKeyIdentifier'
+id-authorityKeyIdentifier =
+ %x61.75.74.68.6F.72.69.74.79.4B.65.79.49.64.65.6E.74.69.66.69.65.72
+ ; 'authorityKeyIdentifier'
+id-certificateValid = %x63.65.72.74.69.66.69.63.61.74.65.56.61.6C.69.64
+ ; 'certificateValid'
+id-privateKeyValid = %x70.72.69.76.61.74.65.4B.65.79.56.61.6C.69.64
+ ; 'privateKeyValid'
+id-subjectPublicKeyAlgID =
+ %x73.75.62.6A.65.63.74.50.75.62.6C.69.63.4B.65.79.41.6C.67.49.44
+ ; 'subjectPublicKeyAlgID'
+id-keyUsage = %x6B.65.79.55.73.61.67.65 ; 'keyUsage'
+id-subjectAltName = %x73.75.62.6A.65.63.74.41.6C.74.4E.61.6D.65
+ ; 'subjectAltName'
+id-policy = %x70.6F.6C.69.63.79 ; 'policy'
+id-pathToName = %x70.61.74.68.54.6F.4E.61.6D.65 ; 'pathToName'
+id-subject = %x73.75.62.6A.65.63.74 ; 'subject'
+id-nameConstraints = %x6E.61.6D.65.43.6F.6E.73.74.72.61.69.6E.74.73
+ ; 'nameConstraints'
+
+SubjectKeyIdentifier = KeyIdentifier
+
+KeyIdentifier = OCTET-STRING
+
+AuthorityKeyIdentifier = "{" [ sp aki-keyIdentifier ]
+ [ sep sp aki-authorityCertIssuer ]
+ [ sep sp aki-authorityCertSerialNumber ] sp "}"
+
+aki-keyIdentifier = id-keyIdentifier msp KeyIdentifier
+aki-authorityCertIssuer = id-authorityCertIssuer msp GeneralNames
+
+GeneralNames = "{" sp GeneralName *( "," sp GeneralName ) sp "}"
+GeneralName = gn-otherName
+ / gn-rfc822Name
+ / gn-dNSName
+
+
+
+Zeilenga Standards Track [Page 16]
+
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+ / gn-x400Address
+ / gn-directoryName
+ / gn-ediPartyName
+ / gn-uniformResourceIdentifier
+ / gn-iPAddress
+ / gn-registeredID
+
+gn-otherName = id-otherName ":" OtherName
+gn-rfc822Name = id-rfc822Name ":" IA5String
+gn-dNSName = id-dNSName ":" IA5String
+gn-x400Address = id-x400Address ":" ORAddress
+gn-directoryName = id-directoryName ":" Name
+gn-ediPartyName = id-ediPartyName ":" EDIPartyName
+gn-iPAddress = id-iPAddress ":" OCTET-STRING
+gn-registeredID = gn-id-registeredID ":" OBJECT-IDENTIFIER
+
+gn-uniformResourceIdentifier = id-uniformResourceIdentifier
+ ":" IA5String
+
+id-otherName = %x6F.74.68.65.72.4E.61.6D.65 ; 'otherName'
+gn-id-registeredID = %x72.65.67.69.73.74.65.72.65.64.49.44
+ ; 'registeredID'
+
+OtherName = "{" sp on-type-id "," sp on-value sp "}"
+on-type-id = id-type-id msp OBJECT-IDENTIFIER
+on-value = id-value msp Value
+ ;; <Value> as defined in Section 3 of [RFC3641]
+
+id-type-id = %x74.79.70.65.2D.69.64 ; 'type-id'
+id-value = %x76.61.6C.75.65 ; 'value'
+
+ORAddress = dquote *SafeIA5Character dquote
+SafeIA5Character = %x01-21 / %x23-7F / ; ASCII minus dquote
+ dquote dquote ; escaped double quote
+dquote = %x22 ; '"' (double quote)
+
+;; Note: The <ORAddress> rule encodes the x400Address component
+;; of a GeneralName as a character string between double quotes.
+;; The character string is first derived according to Section 4.1
+;; of [RFC2156], and then any embedded double quotes are escaped
+;; by being repeated. This resulting string is output between
+;; double quotes.
+
+EDIPartyName = "{" [ sp nameAssigner "," ] sp partyName sp "}"
+nameAssigner = id-nameAssigner msp DirectoryString
+partyName = id-partyName msp DirectoryString
+id-nameAssigner = %x6E.61.6D.65.41.73.73.69.67.6E.65.72
+ ; 'nameAssigner'
+
+
+
+Zeilenga Standards Track [Page 17]
+
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+id-partyName = %x70.61.72.74.79.4E.61.6D.65 ; 'partyName'
+
+aki-authorityCertSerialNumber = id-authorityCertSerialNumber
+ msp CertificateSerialNumber
+
+id-keyIdentifier = %x6B.65.79.49.64.65.6E.74.69.66.69.65.72
+ ; 'keyIdentifier'
+id-authorityCertIssuer =
+ %x61.75.74.68.6F.72.69.74.79.43.65.72.74.49.73.73.75.65.72
+ ; 'authorityCertIssuer'
+
+id-authorityCertSerialNumber = %x61.75.74.68.6F.72.69.74.79.43
+ %x65.72.74.53.65.72.69.61.6C.4E.75.6D.62.65.72
+ ; 'authorityCertSerialNumber'
+
+Time = time-utcTime / time-generalizedTime
+time-utcTime = id-utcTime ":" UTCTime
+time-generalizedTime = id-generalizedTime ":" GeneralizedTime
+id-utcTime = %x75.74.63.54.69.6D.65 ; 'utcTime'
+id-generalizedTime = %x67.65.6E.65.72.61.6C.69.7A.65.64.54.69.6D.65
+ ; 'generalizedTime'
+
+KeyUsage = BIT-STRING / key-usage-bit-list
+key-usage-bit-list = "{" [ sp key-usage *( "," sp key-usage ) ] sp "}"
+
+;; Note: The <key-usage-bit-list> rule encodes the one bits in
+;; a KeyUsage value as a comma separated list of identifiers.
+
+key-usage = id-digitalSignature
+ / id-nonRepudiation
+ / id-keyEncipherment
+ / id-dataEncipherment
+ / id-keyAgreement
+ / id-keyCertSign
+ / id-cRLSign
+ / id-encipherOnly
+ / id-decipherOnly
+
+id-digitalSignature = %x64.69.67.69.74.61.6C.53.69.67.6E.61.74
+ %x75.72.65 ; 'digitalSignature'
+id-nonRepudiation = %x6E.6F.6E.52.65.70.75.64.69.61.74.69.6F.6E
+ ; 'nonRepudiation'
+id-keyEncipherment = %x6B.65.79.45.6E.63.69.70.68.65.72.6D.65.6E.74
+ ; 'keyEncipherment'
+id-dataEncipherment = %x64.61.74.61.45.6E.63.69.70.68.65.72.6D.65.6E
+ %x74 ; "dataEncipherment'
+id-keyAgreement = %x6B.65.79.41.67.72.65.65.6D.65.6E.74
+ ; 'keyAgreement'
+
+
+
+Zeilenga Standards Track [Page 18]
+
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+id-keyCertSign = %x6B.65.79.43.65.72.74.53.69.67.6E
+ ; 'keyCertSign'
+id-cRLSign = %x63.52.4C.53.69.67.6E ; "cRLSign"
+id-encipherOnly = %x65.6E.63.69.70.68.65.72.4F.6E.6C.79
+ ; 'encipherOnly'
+id-decipherOnly = %x64.65.63.69.70.68.65.72.4F.6E.6C.79
+ ; 'decipherOnly'
+
+AltNameType = ant-builtinNameForm / ant-otherNameForm
+
+ant-builtinNameForm = id-builtinNameForm ":" BuiltinNameForm
+ant-otherNameForm = id-otherNameForm ":" OBJECT-IDENTIFIER
+
+id-builtinNameForm = %x62.75.69.6C.74.69.6E.4E.61.6D.65.46.6F.72.6D
+ ; 'builtinNameForm'
+id-otherNameForm = %x6F.74.68.65.72.4E.61.6D.65.46.6F.72.6D
+ ; 'otherNameForm'
+
+BuiltinNameForm = id-rfc822Name
+ / id-dNSName
+ / id-x400Address
+ / id-directoryName
+ / id-ediPartyName
+ / id-uniformResourceIdentifier
+ / id-iPAddress
+ / id-registeredId
+
+id-rfc822Name = %x72.66.63.38.32.32.4E.61.6D.65 ; 'rfc822Name'
+id-dNSName = %x64.4E.53.4E.61.6D.65 ; 'dNSName'
+id-x400Address = %x78.34.30.30.41.64.64.72.65.73.73 ; 'x400Address'
+id-directoryName = %x64.69.72.65.63.74.6F.72.79.4E.61.6D.65
+ ; 'directoryName'
+id-ediPartyName = %x65.64.69.50.61.72.74.79.4E.61.6D.65
+ ; 'ediPartyName'
+id-iPAddress = %x69.50.41.64.64.72.65.73.73 ; 'iPAddress'
+id-registeredId = %x72.65.67.69.73.74.65.72.65.64.49.64
+ ; 'registeredId'
+
+id-uniformResourceIdentifier = %x75.6E.69.66.6F.72.6D.52.65.73.6F.75
+ %x72.63.65.49.64.65.6E.74.69.66.69.65.72
+ ; 'uniformResourceIdentifier'
+
+CertPolicySet = "{" sp CertPolicyId *( "," sp CertPolicyId ) sp "}"
+CertPolicyId = OBJECT-IDENTIFIER
+
+NameConstraintsSyntax = "{" [ sp ncs-permittedSubtrees ]
+ [ sep sp ncs-excludedSubtrees ] sp "}"
+
+
+
+
+Zeilenga Standards Track [Page 19]
+
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+ncs-permittedSubtrees = id-permittedSubtrees msp GeneralSubtrees
+ncs-excludedSubtrees = id-excludedSubtrees msp GeneralSubtrees
+
+id-permittedSubtrees =
+ %x70.65.72.6D.69.74.74.65.64.53.75.62.74.72.65.65.73
+ ; 'permittedSubtrees'
+id-excludedSubtrees =
+ %x65.78.63.6C.75.64.65.64.53.75.62.74.72.65.65.73
+ ; 'excludedSubtrees'
+
+GeneralSubtrees = "{" sp GeneralSubtree
+ *( "," sp GeneralSubtree ) sp "}"
+GeneralSubtree = "{" sp gs-base
+ [ "," sp gs-minimum ]
+ [ "," sp gs-maximum ] sp "}"
+
+gs-base = id-base msp GeneralName
+gs-minimum = id-minimum msp BaseDistance
+gs-maximum = id-maximum msp BaseDistance
+
+id-base = %x62.61.73.65 ; 'base'
+id-minimum = %x6D.69.6E.69.6D.75.6D ; 'minimum'
+id-maximum = %x6D.61.78.69.6D.75.6D ; 'maximum'
+
+BaseDistance = INTEGER-0-MAX
+
+A.3. CertificatePairExactAssertion
+
+ CertificatePairExactAssertion = "{" [ sp cpea-issuedTo ]
+ [sep sp cpea-issuedBy ] sp "}"
+ ;; At least one of <cpea-issuedTo> or <cpea-issuedBy> MUST be present.
+
+ cpea-issuedTo = id-issuedToThisCAAssertion msp
+ CertificateExactAssertion
+ cpea-issuedBy = id-issuedByThisCAAssertion msp
+ CertificateExactAssertion
+
+ id-issuedToThisCAAssertion = %x69.73.73.75.65.64.54.6F.54.68.69.73
+ %x43.41.41.73.73.65.72.74.69.6F.6E ; 'issuedToThisCAAssertion'
+ id-issuedByThisCAAssertion = %x69.73.73.75.65.64.42.79.54.68.69.73
+ %x43.41.41.73.73.65.72.74.69.6F.6E ; 'issuedByThisCAAssertion'
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 20]
+
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+A.4. CertificatePairAssertion
+
+ CertificatePairAssertion = "{" [ sp cpa-issuedTo ]
+ [sep sp cpa-issuedBy ] sp "}"
+ ;; At least one of <cpa-issuedTo> and <cpa-issuedBy> MUST be present.
+
+ cpa-issuedTo = id-issuedToThisCAAssertion msp CertificateAssertion
+ cpa-issuedBy = id-issuedByThisCAAssertion msp CertificateAssertion
+
+A.5. CertificateListExactAssertion
+
+ CertificateListExactAssertion = "{" sp clea-issuer ","
+ sp clea-thisUpdate
+ [ "," sp clea-distributionPoint ] sp "}"
+
+ clea-issuer = id-issuer msp Name
+ clea-thisUpdate = id-thisUpdate msp Time
+ clea-distributionPoint = id-distributionPoint msp
+ DistributionPointName
+
+ id-thisUpdate = %x74.68.69.73.55.70.64.61.74.65 ; 'thisUpdate'
+ id-distributionPoint =
+ %x64.69.73.74.72.69.62.75.74.69.6F.6E.50.6F.69.6E.74
+ ; 'distributionPoint'
+
+ DistributionPointName = dpn-fullName / dpn-nameRelativeToCRLIssuer
+
+ dpn-fullName = id-fullName ":" GeneralNames
+ dpn-nameRelativeToCRLIssuer = id-nameRelativeToCRLIssuer ":"
+ RelativeDistinguishedName
+
+ id-fullName = %x66.75.6C.6C.4E.61.6D.65 ; 'fullName'
+ id-nameRelativeToCRLIssuer = %x6E.61.6D.65.52.65.6C.61.74.69.76.65
+ %x54.6F.43.52.4C.49.73.73.75.65.72 ; 'nameRelativeToCRLIssuer'
+
+A.6. CertificateListAssertion
+
+ CertificateListAssertion = "{" [ sp cla-issuer ]
+ [ sep sp cla-minCRLNumber ]
+ [ sep sp cla-maxCRLNumber ]
+ [ sep sp cla-reasonFlags ]
+ [ sep sp cla-dateAndTime ]
+ [ sep sp cla-distributionPoint ]
+ [ sep sp cla-authorityKeyIdentifier ] sp "}"
+
+ cla-issuer = id-issuer msp Name
+ cla-minCRLNumber = id-minCRLNumber msp CRLNumber
+ cla-maxCRLNumber = id-maxCRLNumber msp CRLNumber
+
+
+
+Zeilenga Standards Track [Page 21]
+
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+ cla-reasonFlags = id-reasonFlags msp ReasonFlags
+ cla-dateAndTime = id-dateAndTime msp Time
+
+ cla-distributionPoint = id-distributionPoint msp
+ DistributionPointName
+
+ cla-authorityKeyIdentifier = id-authorityKeyIdentifier msp
+ AuthorityKeyIdentifier
+
+ id-minCRLNumber = %x6D.69.6E.43.52.4C.4E.75.6D.62.65.72
+ ; 'minCRLNumber'
+ id-maxCRLNumber = %x6D.61.78.43.52.4C.4E.75.6D.62.65.72
+ ; 'maxCRLNumber'
+ id-reasonFlags = %x72.65.61.73.6F.6E.46.6C.61.67.73 ; 'reasonFlags'
+ id-dateAndTime = %x64.61.74.65.41.6E.64.54.69.6D.65 ; 'dateAndTime'
+
+ CRLNumber = INTEGER-0-MAX
+
+ ReasonFlags = BIT-STRING
+ / "{" [ sp reason-flag *( "," sp reason-flag ) ] sp "}"
+
+ reason-flag = id-unused
+ / id-keyCompromise
+ / id-cACompromise
+ / id-affiliationChanged
+ / id-superseded
+ / id-cessationOfOperation
+ / id-certificateHold
+ / id-privilegeWithdrawn
+ / id-aACompromise
+
+ id-unused = %x75.6E.75.73.65.64 ; 'unused'
+ id-keyCompromise = %x6B.65.79.43.6F.6D.70.72.6F.6D.69.73.65
+ ; 'keyCompromise'
+ id-cACompromise = %x63.41.43.6F.6D.70.72.6F.6D.69.73.65
+ ; 'cACompromise'
+ id-affiliationChanged =
+ %x61.66.66.69.6C.69.61.74.69.6F.6E.43.68.61.6E.67.65.64
+ ; 'affiliationChanged'
+ id-superseded = %x73.75.70.65.72.73.65.64.65.64 ; 'superseded'
+ id-cessationOfOperation =
+ %x63.65.73.73.61.74.69.6F.6E.4F.66.4F.70.65.72.61.74.69.6F.6E
+ ; 'cessationOfOperation'
+ id-certificateHold = %x63.65.72.74.69.66.69.63.61.74.65.48.6F.6C.64
+ ; 'certificateHold'
+ id-privilegeWithdrawn =
+ %x70.72.69.76.69.6C.65.67.65.57.69.74.68.64.72.61.77.6E
+ ; 'privilegeWithdrawn'
+
+
+
+Zeilenga Standards Track [Page 22]
+
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+ id-aACompromise = %x61.41.43.6F.6D.70.72.6F.6D.69.73.65
+ ; 'aACompromise'
+
+A.7. AlgorithmIdentifier
+
+ AlgorithmIdentifier = "{" sp ai-algorithm
+ [ "," sp ai-parameters ] sp "}"
+
+ ai-algorithm = id-algorithm msp OBJECT-IDENTIFIER
+ ai-parameters = id-parameters msp Value
+ id-algorithm = %x61.6C.67.6F.72.69.74.68.6D ; 'algorithm'
+ id-parameters = %x70.61.72.61.6D.65.74.65.72.73 ; 'parameters'
+
+Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 23]
+
+RFC 4523 LDAP X.509 Schema June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 24]
+
diff --git a/doc/rfc/rfc4524.txt b/doc/rfc/rfc4524.txt
new file mode 100644
index 0000000000000000000000000000000000000000..fa36be27a37deb91d5bdd0ae9ab97513eb8ac9b3
--- /dev/null
+++ b/doc/rfc/rfc4524.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Network Working Group K. Zeilenga, Ed.
+Request for Comments: 4524 OpenLDAP Foundation
+Obsoletes: 1274 June 2006
+Updates: 2247, 2798
+Category: Standards Track
+
+
+ COSINE LDAP/X.500 Schema
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This document provides a collection of schema elements for use with
+ the Lightweight Directory Access Protocol (LDAP) from the COSINE and
+ Internet X.500 pilot projects.
+
+ This document obsoletes RFC 1274 and updates RFCs 2247 and 2798.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Relationship to Other Documents ............................3
+ 1.2. Terminology and Conventions ................................4
+ 2. COSINE Attribute Types ..........................................4
+ 2.1. associatedDomain ...........................................4
+ 2.2. associatedName .............................................5
+ 2.3. buildingName ...............................................5
+ 2.4. co .........................................................5
+ 2.5. documentAuthor .............................................6
+ 2.6. documentIdentifier .........................................6
+ 2.7. documentLocation ...........................................6
+ 2.8. documentPublisher ..........................................7
+ 2.9. documentTitle ..............................................7
+ 2.10. documentVersion ...........................................7
+ 2.11. drink .....................................................8
+ 2.12. homePhone .................................................8
+ 2.13. homePostalAddress .........................................8
+
+
+
+Zeilenga Standards Track [Page 1]
+
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+ 2.14. host ......................................................9
+ 2.15. info ......................................................9
+ 2.16. mail ......................................................9
+ 2.17. manager ..................................................10
+ 2.18. mobile ...................................................10
+ 2.19. organizationalStatus .....................................11
+ 2.20. pager ....................................................11
+ 2.21. personalTitle ............................................11
+ 2.22. roomNumber ...............................................12
+ 2.23. secretary ................................................12
+ 2.24. uniqueIdentifier .........................................12
+ 2.25. userClass ................................................13
+ 3. COSINE Object Classes ..........................................13
+ 3.1. account ...................................................13
+ 3.2. document ..................................................14
+ 3.3. documentSeries ............................................14
+ 3.4. domain ....................................................15
+ 3.5. domainRelatedObject .......................................16
+ 3.6. friendlyCountry ...........................................16
+ 3.7. rFC822LocalPart ...........................................17
+ 3.8. room ......................................................18
+ 3.9. simpleSecurityObject ......................................18
+ 4. Security Considerations ........................................18
+ 5. IANA Considerations ............................................19
+ 6. Acknowledgements ...............................................20
+ 7. References .....................................................20
+ 7.1. Normative References ......................................20
+ 7.2. Informative References ....................................21
+ Appendix A. Changes since RFC 1274 ...............................23
+ A.1. LDAP Short Names .........................................23
+ A.2. pilotObject ..............................................23
+ A.3. pilotPerson ..............................................23
+ A.4. dNSDomain ................................................24
+ A.5. pilotDSA and qualityLabelledData .........................24
+ A.6. Attribute Syntaxes .......................................24
+ Appendix B. Changes since RFC 2247 ...............................24
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 2]
+
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+1. Introduction
+
+ In the late 1980s, X.500 Directory Services were standardized by the
+ CCITT (Commite' Consultatif International de Telegraphique et
+ Telephonique), now a part of the ITU (International Telephone Union).
+ This lead to Directory Service piloting activities in the early
+ 1990s, including the COSINE (Co-operation and Open Systems
+ Interconnection in Europe) PARADISE Project pilot [COSINEpilot] in
+ Europe. Motivated by needs for large-scale directory pilots, RFC
+ 1274 was published to standardize the directory schema and naming
+ architecture for use in the COSINE and other Internet X.500 pilots
+ [RFC1274].
+
+ In the years that followed, X.500 Directory Services have evolved to
+ incorporate new capabilities and even new protocols. In particular,
+ the Lightweight Directory Access Protocol (LDAP) [RFC4510] was
+ introduced in the early 1990s [RFC1487], with Version 3 of LDAP
+ introduced in the late 1990s [RFC2251] and subsequently revised in
+ 2005 [RFC4510].
+
+ While much of the material in RFC 1274 has been superceded by
+ subsequently published ITU-T Recommendations and IETF RFCs, many of
+ the schema elements lack standardized schema descriptions for use in
+ modern X.500 and LDAP directory services despite the fact that these
+ schema elements are in wide use today. As the old schema
+ descriptions cannot be used without adaptation, interoperability
+ issues may arise due to lack of standardized modern schema
+ descriptions.
+
+ This document addresses these issues by offering standardized schema
+ descriptions, where needed, for widely used COSINE schema elements.
+
+1.1. Relationship to Other Documents
+
+ This document, together with [RFC4519] and [RFC4517], obsoletes RFC
+ 1274 in its entirety. [RFC4519] replaces Sections 9.3.1 (Userid) and
+ 9.3.21 (Domain Component) of RFC 1274. [RFC4517] replaces Section
+ 9.4 (Generally useful syntaxes) of RFC 1274.
+
+ This document replaces the remainder of RFC 1274. Appendix A
+ discusses changes since RFC 1274, as well as why certain schema
+ elements were not brought forward in this revision of the COSINE
+ schema. All elements not brought are to be regarded as Historic.
+
+ The description of the 'domain' object class provided in this
+ document supercedes that found in RFC 2247. That is, Section 3.4 of
+ this document replaces Section 5.2 of [RFC2247].
+
+
+
+
+Zeilenga Standards Track [Page 3]
+
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+ Some of the schema elements specified here were described in RFC 2798
+ (inetOrgPerson schema). This document supersedes these descriptions.
+ This document, together with [RFC4519], replaces Section 9.1.3 of RFC
+ 2798.
+
+1.2. Terminology and Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+ DIT stands for Directory Information Tree.
+ DN stands for Distinguished Name.
+ DSA stands for Directory System Agent, a server.
+ DSE stands for DSA-Specific Entry.
+ DUA stands for Directory User Agent, a client.
+
+ These terms are discussed in [RFC4512].
+
+ Schema definitions are provided using LDAP description formats
+ [RFC4512]. Definitions provided here are formatted (line wrapped)
+ for readability.
+
+2. COSINE Attribute Types
+
+ This section details COSINE attribute types for use in LDAP.
+
+2.1. associatedDomain
+
+ The 'associatedDomain' attribute specifies DNS [RFC1034][RFC2181]
+ host names [RFC1123] that are associated with an object. That is,
+ values of this attribute should conform to the following ABNF:
+
+ domain = root / label *( DOT label )
+ root = SPACE
+ label = LETDIG [ *61( LETDIG / HYPHEN ) LETDIG ]
+ LETDIG = %x30-39 / %x41-5A / %x61-7A ; "0" - "9" / "A"-"Z" / "a"-"z"
+ SPACE = %x20 ; space (" ")
+ HYPHEN = %x2D ; hyphen ("-")
+ DOT = %x2E ; period (".")
+
+ For example, the entry in the DIT with a DN <DC=example,DC=com> might
+ have an associated domain of "example.com".
+
+ ( 0.9.2342.19200300.100.1.37 NAME 'associatedDomain'
+ EQUALITY caseIgnoreIA5Match
+ SUBSTR caseIgnoreIA5SubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
+
+
+
+Zeilenga Standards Track [Page 4]
+
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+ The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax and the
+ 'caseIgnoreIA5Match' and 'caseIgnoreIA5SubstringsMatch' rules are
+ described in [RFC4517].
+
+ Note that the directory will not ensure that values of this attribute
+ conform to the <domain> production provided above. It is the
+ application's responsibility to ensure that domains it stores in this
+ attribute are appropriately represented.
+
+ Also note that applications supporting Internationalized Domain Names
+ SHALL use the ToASCII method [RFC3490] to produce <label> components
+ of the <domain> production.
+
+2.2. associatedName
+
+ The 'associatedName' attribute specifies names of entries in the
+ organizational DIT associated with a DNS domain [RFC1034][RFC2181].
+
+ ( 0.9.2342.19200300.100.1.38 NAME 'associatedName'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+ The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the
+ 'distinguishedNameMatch' rule are described in [RFC4517].
+
+2.3. buildingName
+
+ The 'buildingName' attribute specifies names of the buildings where
+ an organization or organizational unit is based, for example, "The
+ White House".
+
+ ( 0.9.2342.19200300.100.1.48 NAME 'buildingName'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [RFC4517].
+
+2.4. co
+
+ The 'co' (Friendly Country Name) attribute specifies names of
+ countries in human-readable format, for example, "Germany" and
+ "Federal Republic of Germany". It is commonly used in conjunction
+ with the 'c' (Country Name) [RFC4519] attribute (whose values are
+ restricted to the two-letter codes defined in [ISO3166]).
+
+
+
+
+Zeilenga Standards Track [Page 5]
+
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+ ( 0.9.2342.19200300.100.1.43 NAME 'co'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [RFC4517].
+
+2.5. documentAuthor
+
+ The 'documentAuthor' attribute specifies the distinguished names of
+ authors (or editors) of a document. For example,
+
+ ( 0.9.2342.19200300.100.1.14 NAME 'documentAuthor'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+ The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the
+ 'distinguishedNameMatch' rule are described in [RFC4517].
+
+2.6. documentIdentifier
+
+ The 'documentIdentifier' attribute specifies unique identifiers for a
+ document. A document may be identified by more than one unique
+ identifier. For example, RFC 3383 and BCP 64 are unique identifiers
+ that (presently) refer to the same document.
+
+ ( 0.9.2342.19200300.100.1.11 NAME 'documentIdentifier'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [RFC4517].
+
+2.7. documentLocation
+
+ The 'documentLocation' attribute specifies locations of the document
+ original.
+
+ ( 0.9.2342.19200300.100.1.15 NAME 'documentLocation'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+
+
+
+
+Zeilenga Standards Track [Page 6]
+
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [RFC4517].
+
+2.8. documentPublisher
+
+ The 'documentPublisher' attribute is the persons and/or organizations
+ that published the document. Documents that are jointly published
+ have one value for each publisher.
+
+ ( 0.9.2342.19200300.100.1.56 NAME 'documentPublisher'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [RFC4517].
+
+2.9. documentTitle
+
+ The 'documentTitle' attribute specifies the titles of a document.
+ Multiple values are allowed to accommodate both long and short
+ titles, or other situations where a document has multiple titles, for
+ example, "The Lightweight Directory Access Protocol Technical
+ Specification" and "The LDAP Technical Specification".
+
+ ( 0.9.2342.19200300.100.1.12 NAME 'documentTitle'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [RFC4517].
+
+2.10. documentVersion
+
+ The 'documentVersion' attribute specifies the version information of
+ a document.
+
+ ( 0.9.2342.19200300.100.1.13 NAME 'documentVersion'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+
+
+
+
+
+Zeilenga Standards Track [Page 7]
+
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [RFC4517].
+
+2.11. drink
+
+ The 'drink' (favoriteDrink) attribute specifies the favorite drinks
+ of an object (or person), for instance, "cola" and "beer".
+
+ ( 0.9.2342.19200300.100.1.5 NAME 'drink'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [RFC4517].
+
+2.12. homePhone
+
+ The 'homePhone' (Home Telephone Number) attribute specifies home
+ telephone numbers (e.g., "+1 775 555 1234") associated with a person.
+
+ ( 0.9.2342.19200300.100.1.20 NAME 'homePhone'
+ EQUALITY telephoneNumberMatch
+ SUBSTR telephoneNumberSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+
+ The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the
+ 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are
+ described in [RFC4517].
+
+2.13. homePostalAddress
+
+ The 'homePostalAddress' attribute specifies home postal addresses for
+ an object. Each value should be limited to up to 6 directory strings
+ of 30 characters each. (Note: It is not intended that the directory
+ service enforce these limits.)
+
+ ( 0.9.2342.19200300.100.1.39 NAME 'homePostalAddress'
+ EQUALITY caseIgnoreListMatch
+ SUBSTR caseIgnoreListSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
+
+ The PostalAddress (1.3.6.1.4.1.1466.115.121.1.41) syntax and the
+ 'caseIgnoreListMatch' and 'caseIgnoreListSubstringsMatch' rules are
+ described in [RFC4517].
+
+
+
+
+Zeilenga Standards Track [Page 8]
+
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+2.14. host
+
+ The 'host' attribute specifies host computers, generally by their
+ primary fully qualified domain name (e.g., my-host.example.com).
+
+ ( 0.9.2342.19200300.100.1.9 NAME 'host'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [RFC4517].
+
+2.15. info
+
+ The 'info' attribute specifies any general information pertinent to
+ an object. This information is not necessarily descriptive of the
+ object.
+
+ Applications should not attach specific semantics to values of this
+ attribute. The 'description' attribute [RFC4519] is available for
+ specifying descriptive information pertinent to an object.
+
+ ( 0.9.2342.19200300.100.1.4 NAME 'info'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{2048} )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [RFC4517].
+
+2.16. mail
+
+ The 'mail' (rfc822mailbox) attribute type holds Internet mail
+ addresses in Mailbox [RFC2821] form (e.g., user@example.com).
+
+ ( 0.9.2342.19200300.100.1.3 NAME 'mail'
+ EQUALITY caseIgnoreIA5Match
+ SUBSTR caseIgnoreIA5SubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
+
+ The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax and the
+ 'caseIgnoreIA5Match' and 'caseIgnoreIA5SubstringsMatch' rules are
+ described in [RFC4517].
+
+
+
+
+
+Zeilenga Standards Track [Page 9]
+
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+ Note that the directory will not ensure that values of this attribute
+ conform to the <Mailbox> production [RFC2821]. It is the
+ application's responsibility to ensure that domains it stores in this
+ attribute are appropriately represented.
+
+ Additionally, the directory will compare values per the matching
+ rules named in the above attribute type description. As these rules
+ differ from rules that normally apply to <Mailbox> comparisons,
+ operational issues may arise. For example, the assertion
+ (mail=joe@example.com) will match "JOE@example.com" even though the
+ <local-parts> differ. Also, where a user has two <Mailbox>es whose
+ addresses differ only by case of the <local-part>, both cannot be
+ listed as values of the user's mail attribute (as they are considered
+ equal by the 'caseIgnoreIA5Match' rule).
+
+ Also note that applications supporting internationalized domain names
+ SHALL use the ToASCII method [RFC3490] to produce <sub-domain>
+ components of the <Mailbox> production.
+
+2.17. manager
+
+ The 'manager' attribute specifies managers, by distinguished name, of
+ the person (or entity).
+
+ ( 0.9.2342.19200300.100.1.10 NAME 'manager'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+ The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the
+ 'distinguishedNameMatch' rule are described in [RFC4517].
+
+2.18. mobile
+
+ The 'mobile' (mobileTelephoneNumber) attribute specifies mobile
+ telephone numbers (e.g., "+1 775 555 6789") associated with a person
+ (or entity).
+
+ ( 0.9.2342.19200300.100.1.41 NAME 'mobile'
+ EQUALITY telephoneNumberMatch
+ SUBSTR telephoneNumberSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+
+ The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the
+ 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are
+ described in [RFC4517].
+
+
+
+
+
+
+Zeilenga Standards Track [Page 10]
+
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+2.19. organizationalStatus
+
+ The 'organizationalStatus' attribute specifies categories by which a
+ person is often referred to in an organization. Examples of usage in
+ academia might include "undergraduate student", "researcher",
+ "professor", and "staff". Multiple values are allowed where the
+ person is in multiple categories.
+
+ Directory administrators and application designers SHOULD consider
+ carefully the distinctions between this and the 'title' and
+ 'userClass' attributes.
+
+ ( 0.9.2342.19200300.100.1.45 NAME 'organizationalStatus'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [RFC4517].
+
+2.20. pager
+
+ The 'pager' (pagerTelephoneNumber) attribute specifies pager
+ telephone numbers (e.g., "+1 775 555 5555") for an object.
+
+ ( 0.9.2342.19200300.100.1.42 NAME 'pager'
+ EQUALITY telephoneNumberMatch
+ SUBSTR telephoneNumberSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
+
+ The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the
+ 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are
+ described in [RFC4517].
+
+2.21. personalTitle
+
+ The 'personalTitle' attribute specifies personal titles for a person.
+ Examples of personal titles are "Frau", "Dr.", "Herr", and
+ "Professor".
+
+ ( 0.9.2342.19200300.100.1.40 NAME 'personalTitle'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+
+
+
+
+
+Zeilenga Standards Track [Page 11]
+
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [RFC4517].
+
+2.22. roomNumber
+
+ The 'roomNumber' attribute specifies the room number of an object.
+ During periods of renumbering, or in other circumstances where a room
+ has multiple valid room numbers associated with it, multiple values
+ may be provided. Note that the 'cn' (commonName) attribute type
+ SHOULD be used for naming room objects.
+
+ ( 0.9.2342.19200300.100.1.6 NAME 'roomNumber'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [RFC4517].
+
+2.23. secretary
+
+ The 'secretary' attribute specifies secretaries and/or administrative
+ assistants, by distinguished name.
+
+ ( 0.9.2342.19200300.100.1.21 NAME 'secretary'
+ EQUALITY distinguishedNameMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
+
+ The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the
+ 'distinguishedNameMatch' rule are described in [RFC4517].
+
+2.24. uniqueIdentifier
+
+ The 'uniqueIdentifier' attribute specifies a unique identifier for an
+ object represented in the Directory. The domain within which the
+ identifier is unique and the exact semantics of the identifier are
+ for local definition. For a person, this might be an institution-
+ wide payroll number. For an organizational unit, it might be a
+ department code.
+
+ ( 0.9.2342.19200300.100.1.44 NAME 'uniqueIdentifier'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+
+
+
+
+Zeilenga Standards Track [Page 12]
+
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [RFC4517].
+
+ Note: X.520 also describes an attribute called 'uniqueIdentifier'
+ (2.5.4.45), which is called 'x500UniqueIdentifier' in LDAP
+ [RFC4519]. The attribute detailed here ought not be confused
+ with 'x500UniqueIdentifier'.
+
+2.25. userClass
+
+ The 'userClass' attribute specifies categories of computer or
+ application user. The semantics placed on this attribute are for
+ local interpretation. Examples of current usage of this attribute in
+ academia are "student", "staff", and "faculty". Note that the
+ 'organizationalStatus' attribute type is now often preferred, as it
+ makes no distinction between persons as opposed to users.
+
+ ( 0.9.2342.19200300.100.1.8 NAME 'userClass'
+ EQUALITY caseIgnoreMatch
+ SUBSTR caseIgnoreSubstringsMatch
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
+
+ The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
+ 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
+ in [RFC4517].
+
+3. COSINE Object Classes
+
+ This section details COSINE object classes for use in LDAP.
+
+3.1. account
+
+ The 'account' object class is used to define entries representing
+ computer accounts. The 'uid' attribute SHOULD be used for naming
+ entries of this object class.
+
+ ( 0.9.2342.19200300.100.4.5 NAME 'account'
+ SUP top STRUCTURAL
+ MUST uid
+ MAY ( description $ seeAlso $ l $ o $ ou $ host ) )
+
+ The 'top' object class is described in [RFC4512]. The 'description',
+ 'seeAlso', 'l', 'o', 'ou', and 'uid' attribute types are described in
+ [RFC4519]. The 'host' attribute type is described in Section 2 of
+ this document.
+
+
+
+
+
+Zeilenga Standards Track [Page 13]
+
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+ 3.3. documentSeriesExample:
+
+ dn: uid=kdz,cn=Accounts,dc=Example,dc=COM
+ objectClass: account
+ uid: kdz
+ seeAlso: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM
+
+3.2. document
+
+ The 'document' object class is used to define entries that represent
+ documents.
+
+ ( 0.9.2342.19200300.100.4.6 NAME 'document'
+ SUP top STRUCTURAL
+ MUST documentIdentifier
+ MAY ( cn $ description $ seeAlso $ l $ o $ ou $
+ documentTitle $ documentVersion $ documentAuthor $
+ documentLocation $ documentPublisher ) )
+
+ The 'top' object class is described in [RFC4512]. The 'cn',
+ 'description', 'seeAlso', 'l', 'o', and 'ou' attribute types are
+ described in [RFC4519]. The 'documentIdentifier', 'documentTitle',
+ 'documentVersion', 'documentAuthor', 'documentLocation', and
+ 'documentPublisher' attribute types are described in Section 2 of
+ this document.
+
+ Example:
+
+ dn: documentIdentifier=RFC 4524,cn=RFC,dc=Example,dc=COM
+ objectClass: document
+ documentIdentifier: RFC 4524
+ documentTitle: COSINE LDAP/X.500 Schema
+ documentAuthor: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM
+ documentLocation: http://www.rfc-editor.org/rfc/rfc4524.txt
+ documentPublisher: Internet Engineering Task Force
+ description: A collection of schema elements for use in LDAP
+ description: Obsoletes RFC 1274
+ seeAlso: documentIdentifier=RFC 4510,cn=RFC,dc=Example,dc=COM
+ seeAlso: documentIdentifier=RFC 1274,cn=RFC,dc=Example,dc=COM
+
+3.3. documentSeries
+
+ The 'documentSeries' object class is used to define an entry that
+ represents a series of documents (e.g., The Request For Comments
+ memos).
+
+
+
+
+
+
+Zeilenga Standards Track [Page 14]
+
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+ ( 0.9.2342.19200300.100.4.9 NAME 'documentSeries'
+ SUP top STRUCTURAL
+ MUST cn
+ MAY ( description $ l $ o $ ou $ seeAlso $
+ telephonenumber ) )
+
+ The 'top' object class is described in [RFC4512]. The 'description',
+ 'l', 'o', 'ou', 'seeAlso', and 'telephoneNumber' attribute types are
+ described in [RFC4519].
+
+ Example:
+
+ dn: cn=RFC,dc=Example,dc=COM
+ objectClass: documentSeries
+ cn: Request for Comments
+ cn: RFC
+ description: a series of memos about the Internet
+
+3.4. domain
+
+ The 'domain' object class is used to define entries that represent
+ DNS domains for objects that are not organizations, organizational
+ units, or other kinds of objects more appropriately defined using an
+ object class specific to the kind of object being defined (e.g.,
+ 'organization', 'organizationUnit').
+
+ The 'dc' attribute should be used for naming entries of the 'domain'
+ object class.
+
+ ( 0.9.2342.19200300.100.4.13 NAME 'domain'
+ SUP top STRUCTURAL
+ MUST dc
+ MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
+ x121Address $ registeredAddress $ destinationIndicator $
+ preferredDeliveryMethod $ telexNumber $
+ teletexTerminalIdentifier $ telephoneNumber $
+ internationaliSDNNumber $ facsimileTelephoneNumber $ street $
+ postOfficeBox $ postalCode $ postalAddress $
+ physicalDeliveryOfficeName $ st $ l $ description $ o $
+ associatedName ) )
+
+ The 'top' object class and the 'dc', 'userPassword', 'searchGuide',
+ 'seeAlso', 'businessCategory', 'x121Address', 'registeredAddress',
+ 'destinationIndicator', 'preferredDeliveryMethod', 'telexNumber',
+ 'teletexTerminalIdentifier', 'telephoneNumber',
+ 'internationaliSDNNumber', 'facsimileTelephoneNumber', 'street',
+ 'postOfficeBox', 'postalCode', 'postalAddress',
+ 'physicalDeliveryOfficeName', 'st', 'l', 'description', and 'o' types
+
+
+
+Zeilenga Standards Track [Page 15]
+
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+ are described in [RFC4519]. The 'associatedName' attribute type is
+ described in Section 2 of this document.
+
+ Example:
+
+ dn: dc=com
+ objectClass: domain
+ dc: com
+ description: the .COM TLD
+
+3.5. domainRelatedObject
+
+ The 'domainRelatedObject' object class is used to define entries that
+ represent DNS domains that are "equivalent" to an X.500 domain, e.g.,
+ an organization or organizational unit.
+
+ ( 0.9.2342.19200300.100.4.17 NAME 'domainRelatedObject'
+ SUP top AUXILIARY
+ MUST associatedDomain )
+
+ The 'top' object class is described in [RFC4512]. The
+ 'associatedDomain' attribute type is described in Section 2 of this
+ document.
+
+ Example:
+
+ dn: dc=example,dc=com
+ objectClass: organization
+ objectClass: dcObject
+ objectClass: domainRelatedObject
+ dc: example
+ associatedDomain: example.com
+ o: Example Organization
+
+ The 'organization' and 'dcObject' object classes and the 'dc' and 'o'
+ attribute types are described in [RFC4519].
+
+3.6. friendlyCountry
+
+ The 'friendlyCountry' object class is used to define entries
+ representing countries in the DIT. The object class is used to allow
+ friendlier naming of countries than that allowed by the object class
+ 'country' [RFC4519].
+
+ ( 0.9.2342.19200300.100.4.18 NAME 'friendlyCountry'
+ SUP country STRUCTURAL
+ MUST co )
+
+
+
+
+Zeilenga Standards Track [Page 16]
+
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+ The 'country' object class is described in [RFC4519]. The 'co'
+ attribute type is described in Section 2 of this document.
+
+ Example:
+
+ dn: c=DE
+ objectClass: country
+ objectClass: friendlyCountry
+ c: DE
+ co: Deutschland
+ co: Germany
+ co: Federal Republic of Germany
+ co: FRG
+
+ The 'c' attribute type is described in [RFC4519].
+
+3.7. rFC822LocalPart
+
+ The 'rFC822LocalPart' object class is used to define entries that
+ represent the local part of Internet mail addresses [RFC2822]. This
+ treats the local part of the address as a 'domain' object.
+
+ ( 0.9.2342.19200300.100.4.14 NAME 'rFC822localPart'
+ SUP domain STRUCTURAL
+ MAY ( cn $ description $ destinationIndicator $
+ facsimileTelephoneNumber $ internationaliSDNNumber $
+ physicalDeliveryOfficeName $ postalAddress $ postalCode $
+ postOfficeBox $ preferredDeliveryMethod $ registeredAddress $
+ seeAlso $ sn $ street $ telephoneNumber $
+ teletexTerminalIdentifier $ telexNumber $ x121Address ) )
+
+ The 'domain' object class is described in Section 3.4 of this
+ document. The 'cn', 'description', 'destinationIndicator',
+ 'facsimileTelephoneNumber', 'internationaliSDNNumber,
+ 'physicalDeliveryOfficeName', 'postalAddress', 'postalCode',
+ 'postOfficeBox', 'preferredDeliveryMethod', 'registeredAddress',
+ 'seeAlso', 'sn, 'street', 'telephoneNumber',
+ 'teletexTerminalIdentifier', 'telexNumber', and 'x121Address'
+ attribute types are described in [RFC4519].
+
+ Example:
+
+ dn: dc=kdz,dc=example,dc=com
+ objectClass: domain
+ objectClass: rFC822LocalPart
+ dc: kdz
+ associatedName: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM
+
+
+
+
+Zeilenga Standards Track [Page 17]
+
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+ The 'dc' attribute type is described in [RFC4519].
+
+3.8. room
+
+ The 'room' object class is used to define entries representing rooms.
+ The 'cn' (commonName) attribute SHOULD be used for naming entries of
+ this object class.
+
+ ( 0.9.2342.19200300.100.4.7 NAME 'room'
+ SUP top STRUCTURAL
+ MUST cn
+ MAY ( roomNumber $ description $ seeAlso $ telephoneNumber ) )
+
+ The 'top' object class is described in [RFC4512]. The 'cn',
+ 'description', 'seeAlso', and 'telephoneNumber' attribute types are
+ described in [RFC4519]. The 'roomNumber' attribute type is described
+ in Section 2 of this document.
+
+ dn: cn=conference room,dc=example,dc=com
+ objectClass: room
+ cn: conference room
+ telephoneNumber: +1 755 555 1111
+
+3.9. simpleSecurityObject
+
+ The 'simpleSecurityObject' object class is used to require an entry
+ to have a 'userPassword' attribute when the entry's structural object
+ class does not require (or allow) the 'userPassword attribute'.
+
+ ( 0.9.2342.19200300.100.4.19 NAME 'simpleSecurityObject'
+ SUP top AUXILIARY
+ MUST userPassword )
+
+ The 'top' object class is described in [RFC4512]. The 'userPassword'
+ attribute type is described in [RFC4519].
+
+ dn: dc=kdz,dc=Example,dc=COM
+ objectClass: account
+ objectClass: simpleSecurityObject
+ uid: kdz
+ userPassword: My Password
+ seeAlso: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM
+
+4. Security Considerations
+
+ General LDAP security considerations [RFC4510] are applicable to the
+ use of this schema. Additional considerations are noted above where
+ appropriate.
+
+
+
+Zeilenga Standards Track [Page 18]
+
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+ Directories administrators should ensure that access to sensitive
+ information be restricted to authorized entities and that appropriate
+ data security services, including data integrity and data
+ confidentiality, are used to protect against eavesdropping.
+
+ Simple authentication (e.g., plain text passwords) mechanisms should
+ only be used when adequate data security services are in place. LDAP
+ offers reasonably strong authentication and data security services
+ [RFC4513].
+
+5. IANA Considerations
+
+ The Internet Assigned Numbers Authority (IANA) has updated the LDAP
+ descriptors registry [RFC4520] as indicated in the following
+ template:
+
+ Subject: Request for LDAP Descriptor Registration Update
+ Descriptor (short name): see comment
+ Object Identifier: see comments
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Usage: see comments
+ Specification: RFC 4524
+ Author/Change Controller: IESG
+ Comments:
+
+ The following descriptors have been updated to refer to RFC 4524.
+
+ NAME Type OID
+ ------------------------ ---- --------------------------
+ account O 0.9.2342.19200300.100.4.5
+ associatedDomain A 0.9.2342.19200300.100.1.37
+ associatedName A 0.9.2342.19200300.100.1.38
+ buildingName A 0.9.2342.19200300.100.1.48
+ co A 0.9.2342.19200300.100.1.43
+ document O 0.9.2342.19200300.100.4.6
+ documentAuthor A 0.9.2342.19200300.100.1.14
+ documentIdentifier A 0.9.2342.19200300.100.1.11
+ documentLocation A 0.9.2342.19200300.100.1.15
+ documentPublisher A 0.9.2342.19200300.100.1.56
+ documentSeries O 0.9.2342.19200300.100.4.8
+ documentTitle A 0.9.2342.19200300.100.1.12
+ documentVersion A 0.9.2342.19200300.100.1.13
+ domain O 0.9.2342.19200300.100.4.13
+ domainRelatedObject O 0.9.2342.19200300.100.4.17
+ drink A 0.9.2342.19200300.100.1.5
+ favouriteDrink A* 0.9.2342.19200300.100.1.5
+ friendlyCountry O 0.9.2342.19200300.100.4.18
+
+
+
+Zeilenga Standards Track [Page 19]
+
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+ friendlyCountryName A* 0.9.2342.19200300.100.1.43
+ homePhone A 0.9.2342.19200300.100.1.20
+ homePostalAddress A 0.9.2342.19200300.100.1.39
+ homeTelephone A* 0.9.2342.19200300.100.1.20
+ host A 0.9.2342.19200300.100.1.9
+ info A 0.9.2342.19200300.100.1.4
+ mail A 0.9.2342.19200300.100.1.3
+ manager A 0.9.2342.19200300.100.1.10
+ mobile A 0.9.2342.19200300.100.1.41
+ mobileTelephoneNumber A* 0.9.2342.19200300.100.1.41
+ organizationalStatus A 0.9.2342.19200300.100.1.45
+ pager A 0.9.2342.19200300.100.1.42
+ pagerTelephoneNumber A* 0.9.2342.19200300.100.1.42
+ personalTitle A 0.9.2342.19200300.100.1.40
+ rFC822LocalPart O 0.9.2342.19200300.100.4.14
+ rfc822Mailbox A* 0.9.2342.19200300.100.1.3
+ room O 0.9.2342.19200300.100.4.7
+ roomNumber A 0.9.2342.19200300.100.1.6
+ secretary A 0.9.2342.19200300.100.1.21
+ simpleSecurityObject O 0.9.2342.19200300.100.4.19
+ singleLevelQuality A 0.9.2342.19200300.100.1.50
+ uniqueIdentifier A 0.9.2342.19200300.100.1.44
+ userClass A 0.9.2342.19200300.100.1.8
+
+ where Type A is Attribute, Type O is ObjectClass, and *
+ indicates that the registration is historic in nature.
+
+6. Acknowledgements
+
+ This document is based on RFC 1274, by Paul Barker and Steve Kille,
+ as well as on RFC 2247, by Steve Kill, Mark Wahl, Al Grimstad, Rick
+ Huber, and Sri Satulari.
+
+7. References
+
+7.1. Normative References
+
+ [RFC1034] Mockapetris, P., "Domain names - concepts and
+ facilities", STD 13, RFC 1034, November 1987.
+
+ [RFC1123] Braden, R., "Requirements for Internet Hosts -
+ Application and Support", STD 3, RFC 1123, October
+ 1989.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+Zeilenga Standards Track [Page 20]
+
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+ [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
+ Specification", RFC 2181, July 1997.
+
+ [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S.
+ Sataluri, "Using Domains in LDAP/X.500 Distinguished
+ Names", RFC 2247, January 1998.
+
+ [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC
+ 2821, April 2001.
+
+ [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
+ 2001.
+
+ [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
+ "Internationalizing Domain Names in Applications
+ (IDNA)", RFC 3490, March 2003.
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Technical Specification Road Map", RFC
+ 4510, June 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+ [RFC4513] Harrison, R., "Lightweight Directory Access Protocol
+ (LDAP): Authentication Methods and Security
+ Mechanisms", RFC 4513, June 2006.
+
+ [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Syntaxes and Matching Rules", RC 4517, June
+ 2006.
+
+ [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Schema for User Applications", RFC
+ 4519, June 2006.
+
+ [X.501] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory -- Models," X.501(1993) (also ISO/IEC 9594-
+ 2:1994).
+
+7.2. Informative References
+
+ [COSINEpilot] Goodman, D., "PARADISE" section of the March 1991
+ INTERNET MONTHLY REPORTS (p. 28-29),
+ http://www.iana.org/periodic-reports/imr-mar91.txt
+
+
+
+
+Zeilenga Standards Track [Page 21]
+
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+ [ISO3166] International Organization for Standardization, "Codes
+ for the representation of names of countries", ISO
+ 3166.
+
+ [RFC1274] Barker, P. and S. Kille, "The COSINE and Internet X.500
+ Schema", RFC 1274, November 1991.
+
+ [RFC1279] Hardcastle-Kille, S., "X.500 and Domains", RFC 1279,
+ November 1991.
+
+ [RFC1487] Yeong, W., Howes, T., and S. Kille, "X.500 Lightweight
+ Directory Access Protocol", RFC 1487, July 1993.
+
+ [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight
+ Directory Access Protocol (v3)", RFC 2251, December
+ 1997.
+
+ [RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP Object
+ Class", RFC 2798, April 2000.
+
+ [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol
+ version 2 (LDAPv2) to Historic Status", RFC 3494, March
+ 2003.
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
+ (IANA) Considerations for the Lightweight Directory
+ Access Protocol (LDAP)", BCP 64, RFC 4520.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 22]
+
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+Appendix A. Changes since RFC 1274
+
+ This document represents a substantial rewrite of RFC 1274. The
+ following sections summarize the substantive changes.
+
+A.1. LDAP Short Names
+
+ A number of COSINE attribute types have short names in LDAP.
+
+ X.500 Name LDAP Short Name
+ ------------- ---------------
+ domainComponent dc
+ favoriteDrink drink
+ friendCountryName co
+ homeTelephoneNumber homePhone
+ mobileTelephoneNumber mobile
+ pagerTelephoneNumber pager
+ rfc822Mailbox mail
+ userid uid
+
+ While the LDAP short names are generally used in LDAP, some
+ implementations may (for legacy reasons [RFC3494]) recognize the
+ attribute type by its X.500 name. Hence, the X.500 names have been
+ reserved solely for this purpose.
+
+ Note: 'uid' and 'dc' are described in [RFC4519].
+
+A.2. pilotObject
+
+ The 'pilotObject' object class was not brought forward as its
+ function is largely replaced by operational attributes introduced in
+ X.500(93) [X.501] and version 3 of LDAP [RFC4512]. For instance, the
+ function of the 'lastModifiedBy' and 'lastModifiedTime' attribute
+ types is now served by the 'creatorsName', 'createTimestamp',
+ 'modifiersName', and 'modifyTimestamp' operational attributes
+ [RFC4512].
+
+A.3. pilotPerson
+
+ The 'pilotPerson' object class was not brought forward as its
+ function is largely replaced by the 'organizationalPerson' [RFC4512]
+ object class and its subclasses, such as 'inetOrgPerson' [RFC2798].
+
+ Most of the related attribute types (e.g., 'mail', 'manager') were
+ brought forward as they are used in other object classes.
+
+
+
+
+
+
+Zeilenga Standards Track [Page 23]
+
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+A.4. dNSDomain
+
+ The 'dNSDomain' object class and related attribute types were not
+ brought forward as its use is primarily experimental [RFC1279].
+
+A.5. pilotDSA and qualityLabelledData
+
+ The 'pilotDSA' and 'qualityLabelledData' object classes, as well as
+ related attribute types, were not brought forward as its use is
+ primarily experimental [QoS].
+
+A.6. Attribute Syntaxes
+
+ RFC 1274 defined and used caseIgnoreIA5StringSyntax attribute syntax.
+ This has been replaced with the IA5String syntax and appropriate
+ matching rules in 'mail' and 'associatedDomain'.
+
+ RFC 1274 restricted 'mail' to have non-zero length values. This
+ restriction is not reflected in the IA5String syntax used in the
+ definitions provided in this specification. However, as values are
+ to conform to the <Mailbox> production, the 'mail' should not contain
+ zero-length values. Unfortunately, the directory service will not
+ enforce this restriction.
+
+Appendix B. Changes since RFC 2247
+
+ The 'domainNameForm' name form was not brought forward as
+ specification of name forms used in LDAP is left to a future
+ specification.
+
+Editor's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 24]
+
+RFC 4524 COSINE LDAP/X.500 Schema June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 25]
+
diff --git a/doc/rfc/rfc4525.txt b/doc/rfc/rfc4525.txt
new file mode 100644
index 0000000000000000000000000000000000000000..6e15e4f6e974aca5a3ccb3895bdc125b027fd18c
--- /dev/null
+++ b/doc/rfc/rfc4525.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 4525 OpenLDAP Foundation
+Category: Informational June 2006
+
+
+ Lightweight Directory Access Protocol (LDAP)
+ Modify-Increment Extension
+
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This document describes an extension to the Lightweight Directory
+ Access Protocol (LDAP) Modify operation to support an increment
+ capability. This extension is useful in provisioning applications,
+ especially when combined with the assertion control and/or the pre-
+ read or post-read control extension.
+
+Table of Contents
+
+ 1. Background and Intended Use .....................................1
+ 2. The Modify-Increment Extension ..................................2
+ 3. LDIF Support ....................................................2
+ 4. Security Considerations .........................................3
+ 5. IANA Considerations .............................................3
+ 5.1. Object Identifier ..........................................3
+ 5.2. LDAP Protocol Mechanism ....................................3
+ 5.3. LDAP Protocol Mechanism ....................................4
+ 6. References ......................................................4
+ 6.1. Normative References .......................................4
+ 6.2. Informative References .....................................5
+
+1. Background and Intended Use
+
+ The Lightweight Directory Access Protocol (LDAP) [RFC4510] does not
+ currently provide an operation to increment values of an attribute.
+ A client must read the values of the attribute and then modify those
+ values to increment them by the desired amount. As the values may be
+ updated by other clients between this add and modify, the client must
+
+
+
+Zeilenga Informational [Page 1]
+
+RFC 4525 LDAP Modify-Increment Extension June 2006
+
+
+ be careful to construct the modify request so that it fails in this
+ case, and upon failure, to re-read the values and construct a new
+ modify request.
+
+ This document extends the LDAP Modify Operation [RFC4511] to support
+ an increment values capability. This feature is intended to be used
+ with either the LDAP pre-read or post-read control extensions
+ [RFC4527]. This feature may also be used with the LDAP assertion
+ control extension [RFC4528] to provide test-and-increment
+ functionality.
+
+ In this document key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
+ "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
+ "OPTIONAL" are to be interpreted as described in BCP 14 [RFC2119].
+
+2. The Modify-Increment Extension
+
+ This document extends the LDAP Modify request to support a increment
+ values capability. Implementations of this extension SHALL support
+ an additional ModifyRequest operation enumeration value increment
+ (3), as described herein. Implementations not supporting this
+ extension will treat this value as they would an unlisted value,
+ e.g., as a protocol error.
+
+ The increment (3) operation value specifies that an increment values
+ modification is requested. All existing values of the modification
+ attribute are to be incremented by the listed value. The
+ modification attribute must be appropriate for the request (e.g., it
+ must have INTEGER or other increment-able values), and the
+ modification must provide one and only one value. If the attribute
+ is not appropriate for the request, a constraintViolation or other
+ appropriate error is to be returned. If multiple values are
+ provided, a protocolError is to be returned.
+
+ Servers supporting this feature SHOULD publish the object identifier
+ (OID) 1.3.6.1.1.14 as a value of the 'supportedFeatures' [RFC4512]
+ attribute in the root DSE. Clients supporting this feature SHOULD
+ NOT use the feature unless they know the server supports it.
+
+3. LDIF Support
+
+ To represent Modify-Increment requests in LDAP Data Interchange
+ Format [RFC2849], the ABNF [RFC4234] production <mod-spec> is
+ extended as follows:
+
+ mod-spec =/ "increment:" FILL AttributeDescription SEP
+ attrval-spec "-" SEP
+
+
+
+
+Zeilenga Informational [Page 2]
+
+RFC 4525 LDAP Modify-Increment Extension June 2006
+
+
+ For example,
+
+ # Increment uidNumber
+ dn: cn=max-assigned uidNumber,dc=example,dc=com
+ changetype: modify
+ increment: uidNumber
+ uidNumber: 1
+ -
+
+ This LDIF fragment represents a Modify request to increment the
+ value(s) of uidNumber by 1.
+
+4. Security Considerations
+
+ General LDAP security considerations [RFC4510], as well as those
+ specific to the LDAP Modify [RFC4511], apply to this Modify-Increment
+ extension. Beyond these considerations, it is noted that
+ introduction of this extension should reduce application complexity
+ (by providing one operation for what presently requires multiple
+ operations) and, hence, it may aid in the production of correct and
+ secure implementations.
+
+5. IANA Considerations
+
+ Registration of the following values [RFC4520] have been completed.
+
+5.1. Object Identifier
+
+ The IANA has assigned an LDAP Object Identifier to identify the LDAP
+ Modify-Increment feature, as defined in this document.
+
+ Subject: Request for LDAP Object Identifier Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Specification: RFC 4525
+ Author/Change Controller: Author
+ Comments:
+ Identifies the LDAP Modify-Increment feature
+
+5.2. LDAP Protocol Mechanism
+
+ The following LDAP Protocol Mechanism has been registered.
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: 1.3.6.1.1.14
+ Description: Modify-Increment
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+
+
+
+Zeilenga Informational [Page 3]
+
+RFC 4525 LDAP Modify-Increment Extension June 2006
+
+
+ Usage: Feature
+ Specification: RFC 4525
+ Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
+ Comments: none
+
+5.3. LDAP Protocol Mechanism
+
+ The IANA has assigned an LDAP ModifyRequest Operation Type (3)
+ [RFC4520] for use in this document.
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ ModifyRequest Operation Name: increment
+ Description: Modify-Increment
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+ Usage: Feature
+ Specification: RFC 4525
+ Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
+ Comments: none
+
+6. References
+
+6.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 4234, October 2005.
+
+ [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) -
+ Technical Specification", RFC 2849, June 2000.
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Technical Specification Road Map", RFC
+ 4510, June 2006.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+
+
+
+
+
+
+
+Zeilenga Informational [Page 4]
+
+RFC 4525 LDAP Modify-Increment Extension June 2006
+
+
+6.2. Informative References
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
+ (IANA) Considerations for the Lightweight Directory
+ Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+ [RFC4527] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP) Read Entry Controls", RFC 4527, June 2006.
+
+ [RFC4528] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP) Assertion Control", RFC 4528, June 2006.
+
+Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Informational [Page 5]
+
+RFC 4525 LDAP Modify-Increment Extension June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga Informational [Page 6]
+
diff --git a/doc/rfc/rfc4526.txt b/doc/rfc/rfc4526.txt
new file mode 100644
index 0000000000000000000000000000000000000000..9795632b99f77f59c85f0471e5f1b418d0797f36
--- /dev/null
+++ b/doc/rfc/rfc4526.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 4526 OpenLDAP Foundation
+Category: Standards Track June 2006
+
+
+ Lightweight Directory Access Protocol (LDAP)
+ Absolute True and False Filters
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This document extends the Lightweight Directory Access Protocol
+ (LDAP) to support absolute True and False filters based upon similar
+ capabilities found in X.500 directory systems. The document also
+ extends the String Representation of LDAP Search Filters to support
+ these filters.
+
+Table of Contents
+
+ 1. Background ......................................................1
+ 2. Absolute True and False Filters .................................2
+ 3. Security Considerations .........................................2
+ 4. IANA Considerations .............................................3
+ 5. References ......................................................3
+ 5.1. Normative References .......................................3
+ 5.2. Informative References .....................................3
+
+1. Background
+
+ The X.500 Directory Access Protocol (DAP) [X.511] supports absolute
+ True and False assertions. An 'and' filter with zero elements always
+ evaluates to True. An 'or' filter with zero elements always
+ evaluates to False. These filters are commonly used when requesting
+ DSA-specific Entries (DSEs) that do not necessarily have
+ 'objectClass' attributes; that is, where "(objectClass=*)" may
+ evaluate to False.
+
+
+
+
+Zeilenga Standards Track [Page 1]
+
+RFC 4526 LDAP Absolute True and False Filters June 2006
+
+
+ Although LDAPv2 [RFC1777][RFC3494] placed no restriction on the
+ number of elements in 'and' and 'or' filter sets, the LDAPv2 string
+ representation [RFC1960][RFC3494] could not represent empty 'and' and
+ 'or' filter sets. Due to this, absolute True or False filters were
+ (unfortunately) eliminated from LDAPv3 [RFC4510].
+
+ This documents extends LDAPv3 to support absolute True and False
+ assertions by allowing empty 'and' and 'or' in Search filters
+ [RFC4511] and extends the filter string representation [RFC4515] to
+ allow empty filter lists.
+
+ It is noted that certain search operations, such as those used to
+ retrieve subschema information [RFC4512], require use of particular
+ filters. This document does not change these requirements.
+
+ This feature is intended to allow a more direct mapping between DAP
+ and LDAP (as needed to implement DAP-to-LDAP gateways).
+
+ In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+ "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+ and "OPTIONAL" are to be interpreted as described in BCP 14
+ [RFC2119].
+
+2. Absolute True and False Filters
+
+ Implementations of this extension SHALL allow 'and' and 'or' choices
+ with zero filter elements.
+
+ An 'and' filter consisting of an empty set of filters SHALL evaluate
+ to True. This filter is represented by the string "(&)".
+
+ An 'or' filter consisting of an empty set of filters SHALL evaluate
+ to False. This filter is represented by the string "(|)".
+
+ Servers supporting this feature SHOULD publish the Object Identifier
+ 1.3.6.1.4.1.4203.1.5.3 as a value of the 'supportedFeatures'
+ [RFC4512] attribute in the root DSE.
+
+ Clients supporting this feature SHOULD NOT use the feature unless
+ they know that the server supports it.
+
+3. Security Considerations
+
+ The (re)introduction of absolute True and False filters is not
+ believed to raise any new security considerations.
+
+ Implementors of this (or any) LDAPv3 extension should be familiar
+ with general LDAPv3 security considerations [RFC4510].
+
+
+
+Zeilenga Standards Track [Page 2]
+
+RFC 4526 LDAP Absolute True and False Filters June 2006
+
+
+4. IANA Considerations
+
+ Registration of this feature has been completed by the IANA
+ [RFC4520].
+
+ Subject: Request for LDAP Protocol Mechanism Registration Object
+ Identifier: 1.3.6.1.4.1.4203.1.5.3 Description: True/False filters
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org> Usage: Feature Specification:
+ RFC 4526 Author/Change Controller: IESG Comments: none
+
+ This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its
+ IANA-assigned private enterprise allocation [PRIVATE], for use in
+ this specification.
+
+5. References
+
+5.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4510] Zeilenga, K., Ed, "Lightweight Directory Access
+ Protocol (LDAP): Technical Specification Road Map", RFC
+ 4510, June 2006.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+ [RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory
+ Access Protocol (LDAP): String Representation of Search
+ Filters", RFC 4515, June 2006.
+
+5.2. Informative References
+
+ [RFC1777] Yeong, W., Howes, T., and S. Kille, "Lightweight
+ Directory Access Protocol", RFC 1777, March 1995.
+
+ [RFC1960] Howes, T., "A String Representation of LDAP Search
+ Filters", RFC 1960, June 1996.
+
+ [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol
+ version 2 (LDAPv2) to Historic Status", RFC 3494, March
+ 2003.
+
+
+
+Zeilenga Standards Track [Page 3]
+
+RFC 4526 LDAP Absolute True and False Filters June 2006
+
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
+ (IANA) Considerations for the Lightweight Directory
+ Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+ [X.500] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory -- Overview of concepts, models and
+ services," X.500(1993) (also ISO/IEC 9594-1:1994).
+
+ [X.501] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory -- Models," X.501(1993) (also ISO/IEC 9594-
+ 2:1994).
+
+ [X.511] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory: Abstract Service Definition", X.511(1993)
+ (also ISO/IEC 9594-3:1993).
+
+ [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
+ http://www.openldap.org/foundation/oid-delegate.txt.
+
+ [PRIVATE] IANA, "Private Enterprise Numbers",
+ http://www.iana.org/assignments/enterprise-numbers.
+
+Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 4]
+
+RFC 4526 LDAP Absolute True and False Filters June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 5]
+
diff --git a/doc/rfc/rfc4527.txt b/doc/rfc/rfc4527.txt
new file mode 100644
index 0000000000000000000000000000000000000000..de6e5d0d544c052cbb5ae84066c709a3283facbe
--- /dev/null
+++ b/doc/rfc/rfc4527.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 4527 OpenLDAP Foundation
+Category: Standards Track June 2006
+
+
+ Lightweight Directory Access Protocol (LDAP)
+ Read Entry Controls
+
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This document specifies an extension to the Lightweight Directory
+ Access Protocol (LDAP) to allow the client to read the target entry
+ of an update operation. The client may request to read the entry
+ before and/or after the modifications are applied. These reads are
+ done as an atomic part of the update operation.
+
+Table of Contents
+
+ 1. Background and Intent of Use ....................................2
+ 2. Terminology .....................................................2
+ 3. Read Entry Controls .............................................3
+ 3.1. The Pre-Read Controls ......................................3
+ 3.2. The Post-Read Controls .....................................3
+ 4. Interaction with Other Controls .................................4
+ 5. Security Considerations .........................................4
+ 6. IANA Considerations .............................................5
+ 6.1. Object Identifier ..........................................5
+ 6.2. LDAP Protocol Mechanisms ...................................5
+ 7. Acknowledgement .................................................5
+ 8. References ......................................................6
+ 8.1. Normative References .......................................6
+ 8.2. Informative References .....................................7
+
+
+
+
+
+
+Zeilenga Standards Track [Page 1]
+
+RFC 4527 LDAP Read Entry Controls June 2006
+
+
+1. Background and Intent of Use
+
+ This document specifies an extension to the Lightweight Directory
+ Access Protocol (LDAP) [RFC4510] to allow the client to read the
+ target entry of an update operation (e.g., Add, Delete, Modify,
+ ModifyDN). The extension utilizes controls [RFC4511] attached to
+ update requests to request and return copies of the target entry.
+ One request control, called the Pre-Read request control, indicates
+ that a copy of the entry before application of update is to be
+ returned. Another control, called the Post-Read request control,
+ indicates that a copy of the entry after application of the update is
+ to be returned. Each request control has a corresponding response
+ control used to return the entry.
+
+ To ensure proper isolation, the controls are processed as an atomic
+ part of the update operation.
+
+ The functionality offered by these controls is based upon similar
+ functionality in the X.500 Directory Access Protocol (DAP) [X.511].
+
+ The Pre-Read controls may be used to obtain replaced or deleted
+ values of modified attributes or a copy of the entry being deleted.
+
+ The Post-Read controls may be used to obtain values of operational
+ attributes, such as the 'entryUUID' [RFC4530] and 'modifyTimestamp'
+ [RFC4512] attributes, updated by the server as part of the update
+ operation.
+
+2. Terminology
+
+ Protocol elements are described using ASN.1 [X.680] with implicit
+ tags. The term "BER-encoded" means the element is to be encoded
+ using the Basic Encoding Rules [X.690] under the restrictions
+ detailed in Section 5.1 of [RFC4511].
+
+ DN stands for Distinguished Name.
+ DSA stands for Directory System Agent (i.e., a directory server).
+ DSE stands for DSA-specific Entry.
+
+ In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+ "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+ and "OPTIONAL" are to be interpreted as described in BCP 14
+ [RFC2119].
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 2]
+
+RFC 4527 LDAP Read Entry Controls June 2006
+
+
+3. Read Entry Controls
+
+3.1. The Pre-Read Controls
+
+ The Pre-Read request and response controls are identified by the
+ 1.3.6.1.1.13.1 object identifier. Servers implementing these
+ controls SHOULD publish 1.3.6.1.1.13.1 as a value of the
+ 'supportedControl' [RFC4512] in their root DSE.
+
+ The Pre-Read request control is a LDAP Control [RFC4511] whose
+ controlType is 1.3.6.1.1.13.1 and whose controlValue is a BER-encoded
+ AttributeSelection [RFC4511], as extended by [RFC3673]. The
+ criticality may be TRUE or FALSE. This control is appropriate for
+ the modifyRequest, delRequest, and modDNRequest LDAP messages.
+
+ The corresponding response control is a LDAP Control whose
+ controlType is 1.3.6.1.1.13.1 and whose the controlValue, an OCTET
+ STRING, contains a BER-encoded SearchResultEntry. The criticality
+ may be TRUE or FALSE. This control is appropriate for the
+ modifyResponse, delResponse, and modDNResponse LDAP messages with a
+ resultCode of success (0).
+
+ When the request control is attached to an appropriate update LDAP
+ request, the control requests the return of a copy of the target
+ entry prior to the application of the update. The AttributeSelection
+ indicates, as discussed in [RFC4511][RFC3673], which attributes are
+ requested to appear in the copy. The server is to return a
+ SearchResultEntry containing, subject to access controls and other
+ constraints, values of the requested attributes.
+
+ The normal processing of the update operation and the processing of
+ this control MUST be performed as one atomic action isolated from
+ other update operations.
+
+ If the update operation fails (in either normal or control
+ processing), no Pre-Read response control is provided.
+
+3.2. The Post-Read Controls
+
+ The Post-Read request and response controls are identified by the
+ 1.3.6.1.1.13.2 object identifier. Servers implementing these
+ controls SHOULD publish 1.3.6.1.1.13.2 as a value of the
+ 'supportedControl' [RFC4512] in their root DSE.
+
+ The Post-Read request control is a LDAP Control [RFC4511] whose
+ controlType is 1.3.6.1.1.13.2 and whose controlValue, an OCTET
+ STRING, contains a BER-encoded AttributeSelection [RFC4511], as
+ extended by [RFC3673]. The criticality may be TRUE or FALSE. This
+
+
+
+Zeilenga Standards Track [Page 3]
+
+RFC 4527 LDAP Read Entry Controls June 2006
+
+
+ control is appropriate for the addRequest, modifyRequest, and
+ modDNRequest LDAP messages.
+
+ The corresponding response control is a LDAP Control whose
+ controlType is 1.3.6.1.1.13.2 and whose controlValue is a BER-encoded
+ SearchResultEntry. The criticality may be TRUE or FALSE. This
+ control is appropriate for the addResponse, modifyResponse, and
+ modDNResponse LDAP messages with a resultCode of success (0).
+
+ When the request control is attached to an appropriate update LDAP
+ request, the control requests the return of a copy of the target
+ entry after the application of the update. The AttributeSelection
+ indicates, as discussed in [RFC4511][RFC3673], which attributes are
+ requested to appear in the copy. The server is to return a
+ SearchResultEntry containing, subject to access controls and other
+ constraints, values of the requested attributes.
+
+ The normal processing of the update operation and the processing of
+ this control MUST be performed as one atomic action isolated from
+ other update operations.
+
+ If the update operation fails (in either normal or control
+ processing), no Post-Read response control is provided.
+
+4. Interaction with Other Controls
+
+ The Pre-Read and Post-Read controls may be combined with each other
+ and/or with a variety of other controls. When combined with the
+ assertion control [RFC4528] and/or the manageDsaIT control [RFC3296],
+ the semantics of each control included in the combination applies.
+ The Pre-Read and Post-Read controls may be combined with other
+ controls as detailed in other technical specifications.
+
+5. Security Considerations
+
+ The controls defined in this document extend update operations to
+ support read capabilities. Servers MUST ensure that the client is
+ authorized for reading of the information provided in this control
+ and that the client is authorized to perform the requested directory
+ update.
+
+ Security considerations for the update operations [RFC4511] extended
+ by this control, as well as general LDAP security considerations
+ [RFC4510], generally apply to implementation and use of this
+ extension
+
+
+
+
+
+
+Zeilenga Standards Track [Page 4]
+
+RFC 4527 LDAP Read Entry Controls June 2006
+
+
+6. IANA Considerations
+
+ Registration of the following protocol values [RFC4520] have been
+ completed by the IANA.
+
+6.1. Object Identifier
+
+ The IANA has registered an LDAP Object Identifier to identify LDAP
+ protocol elements defined in this document.
+
+ Subject: Request for LDAP Object Identifier Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Specification: RFC 4527
+ Author/Change Controller: IESG
+ Comments: Identifies the LDAP Read Entry Controls
+
+6.2. LDAP Protocol Mechanisms
+
+ The IANA has registered the LDAP Protocol Mechanism described in this
+ document.
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: 1.3.6.1.1.13.1
+ Description: LDAP Pre-read Control
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+ Usage: Control
+ Specification: RFC 4527
+ Author/Change Controller: IESG
+ Comments: none
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: 1.3.6.1.1.13.2
+ Description: LDAP Post-read Control
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+ Usage: Control
+ Specification: RFC 4527
+ Author/Change Controller: IESG
+ Comments: none
+
+7. Acknowledgement
+
+ The LDAP Pre-Read and Post-Read controls are modeled after similar
+ capabilities offered in the DAP [X.511].
+
+
+
+
+
+Zeilenga Standards Track [Page 5]
+
+RFC 4527 LDAP Read Entry Controls June 2006
+
+
+8. References
+
+8.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3296] Zeilenga, K., "Named Subordinate References in
+ Lightweight Directory Access Protocol (LDAP)
+ Directories", RFC 3296, July 2002.
+
+ [RFC3673] Zeilenga, K., "Lightweight Directory Access Protocol
+ version 3 (LDAPv3): All Operational Attributes", RFC
+ 3673, December 2003.
+
+ [RFC4510] Zeilenga, K., Ed, "Lightweight Directory Access
+ Protocol (LDAP): Technical Specification Road Map", RFC
+ 4510, June 2006.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+ [RFC4528] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP) Assertion Control", RFC 4528, June 2006.
+
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
+
+ [X.690] International Telecommunication Union -
+ Telecommunication Standardization Sector,
+ "Specification of ASN.1 encoding rules: Basic Encoding
+ Rules (BER), Canonical Encoding Rules (CER), and
+ Distinguished Encoding Rules (DER)", X.690(1997) (also
+ ISO/IEC 8825-1:1998).
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 6]
+
+RFC 4527 LDAP Read Entry Controls June 2006
+
+
+8.2. Informative References
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
+ (IANA) Considerations for the Lightweight Directory
+ Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+ [RFC4530] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP) EntryUUID Operational Attribute", RFC 4530, June
+ 2006.
+
+ [X.511] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory: Abstract Service Definition", X.511(1993)
+ (also ISO/IEC 9594-3:1993).
+
+Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 7]
+
+RFC 4527 LDAP Read Entry Controls June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 8]
+
diff --git a/doc/rfc/rfc4528.txt b/doc/rfc/rfc4528.txt
new file mode 100644
index 0000000000000000000000000000000000000000..5b1fee0c1b4568a1fcac0703cbec3c8084e9c3dc
--- /dev/null
+++ b/doc/rfc/rfc4528.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 4528 OpenLDAP Foundation
+Category: Standards Track June 2006
+
+
+ Lightweight Directory Access Protocol (LDAP)
+ Assertion Control
+
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This document defines the Lightweight Directory Access Protocol
+ (LDAP) Assertion Control, which allows a client to specify that a
+ directory operation should only be processed if an assertion applied
+ to the target entry of the operation is true. It can be used to
+ construct "test and set", "test and clear", and other conditional
+ operations.
+
+Table of Contents
+
+ 1. Overview ........................................................2
+ 2. Terminology .....................................................2
+ 3. The Assertion Control ...........................................2
+ 4. Security Considerations .........................................3
+ 5. IANA Considerations .............................................4
+ 5.1. Object Identifier ..........................................4
+ 5.2. LDAP Protocol Mechanism ....................................4
+ 5.3. LDAP Result Code ...........................................4
+ 6. Acknowledgements ................................................5
+ 7. References ......................................................5
+ 7.1. Normative References .......................................5
+ 7.2. Informative References .....................................5
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 1]
+
+RFC 4528 LDAP Assertion Control June 2006
+
+
+1. Overview
+
+ This document defines the Lightweight Directory Access Protocol
+ (LDAP) [RFC4510] assertion control. The assertion control allows the
+ client to specify a condition that must be true for the operation to
+ be processed normally. Otherwise, the operation is not performed.
+ For instance, the control can be used with the Modify operation
+ [RFC4511] to perform atomic "test and set" and "test and clear"
+ operations.
+
+ The control may be attached to any update operation to support
+ conditional addition, deletion, modification, and renaming of the
+ target object. The asserted condition is evaluated as an integral
+ part the operation.
+
+ The control may also be used with the search operation. Here, the
+ assertion is applied to the base object of the search before
+ searching for objects that match the search scope and filter.
+
+ The control may also be used with the compare operation. Here, it
+ extends the compare operation to allow a more complex assertion.
+
+2. Terminology
+
+ Protocol elements are described using ASN.1 [X.680] with implicit
+ tags. The term "BER-encoded" means the element is to be encoded
+ using the Basic Encoding Rules [X.690] under the restrictions
+ detailed in Section 5.1 of [RFC4511].
+
+ DSA stands for Directory System Agent (or server).
+ DSE stands for DSA-specific Entry.
+
+ In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+ "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+ and "OPTIONAL" are to be interpreted as described in BCP 14
+ [RFC2119].
+
+3. The Assertion Control
+
+ The assertion control is an LDAP Control [RFC4511] whose controlType
+ is 1.3.6.1.1.12 and whose controlValue is a BER-encoded Filter
+ [Protocol, Section 4.5.1]. The criticality may be TRUE or FALSE.
+ There is no corresponding response control.
+
+ The control is appropriate for both LDAP interrogation and update
+ operations [RFC4511], including Add, Compare, Delete, Modify,
+ ModifyDN (rename), and Search. It is inappropriate for Abandon,
+ Bind, Unbind, and StartTLS operations.
+
+
+
+Zeilenga Standards Track [Page 2]
+
+RFC 4528 LDAP Assertion Control June 2006
+
+
+ When the control is attached to an LDAP request, the processing of
+ the request is conditional on the evaluation of the Filter as applied
+ against the target of the operation. If the Filter evaluates to
+ TRUE, then the request is processed normally. If the Filter
+ evaluates to FALSE or Undefined, then assertionFailed (122)
+ resultCode is returned, and no further processing is performed.
+
+ For Add, Compare, and ModifyDN operations, the target is indicated by
+ the entry field in the request. For Modify operations, the target is
+ indicated by the object field. For Delete operations, the target is
+ indicated by the DelRequest type. For Compare operations and all
+ update operations, the evaluation of the assertion MUST be performed
+ as an integral part of the operation. That is, the evaluation of the
+ assertion and the normal processing of the operation SHALL be done as
+ one atomic action.
+
+ For Search operations, the target is indicated by the baseObject
+ field, and the evaluation is done after "finding" but before
+ "searching" [RFC4511]. Hence, no entries or continuations references
+ are returned if the assertion fails.
+
+ Servers implementing this technical specification SHOULD publish the
+ object identifier 1.3.6.1.1.12 as a value of the 'supportedControl'
+ attribute [RFC4512] in their root DSE. A server MAY choose to
+ advertise this extension only when the client is authorized to use
+ it.
+
+ Other documents may specify how this control applies to other LDAP
+ operations. In doing so, they must state how the target entry is
+ determined.
+
+4. Security Considerations
+
+ The filter may, like other components of the request, contain
+ sensitive information. When it does, this information should be
+ appropriately protected.
+
+ As with any general assertion mechanism, the mechanism can be used to
+ determine directory content. Hence, this mechanism SHOULD be subject
+ to appropriate access controls.
+
+ Some assertions may be very complex, requiring significant time and
+ resources to evaluate. Hence, this mechanism SHOULD be subject to
+ appropriate administrative controls.
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 3]
+
+RFC 4528 LDAP Assertion Control June 2006
+
+
+ Security considerations for the base operations [RFC4511] extended by
+ this control, as well as general LDAP security considerations
+ [RFC4510], generally apply to implementation and use of this
+ extension.
+
+5. IANA Considerations
+
+5.1. Object Identifier
+
+ The IANA has assigned an LDAP Object Identifier [RFC4520] to identify
+ the LDAP Assertion Control defined in this document.
+
+ Subject: Request for LDAP Object Identifier Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Specification: RFC 4528
+ Author/Change Controller: IESG
+ Comments:
+ Identifies the LDAP Assertion Control
+
+5.2. LDAP Protocol Mechanism
+
+ Registration of this protocol mechanism [RFC4520] is requested.
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: 1.3.6.1.1.12
+ Description: Assertion Control
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+ Usage: Control
+ Specification: RFC 4528
+ Author/Change Controller: IESG
+ Comments: none
+
+5.3. LDAP Result Code
+
+ The IANA has assigned an LDAP Result Code [RFC4520] called
+ 'assertionFailed' (122).
+
+ Subject: LDAP Result Code Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Result Code Name: assertionFailed
+ Specification: RFC 4528
+ Author/Change Controller: IESG
+ Comments: none
+
+
+
+
+
+Zeilenga Standards Track [Page 4]
+
+RFC 4528 LDAP Assertion Control June 2006
+
+
+6. Acknowledgements
+
+ The assertion control concept is attributed to Morteza Ansari.
+
+7. References
+
+7.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Technical Specification Road Map", RFC
+ 4510, June 2006.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
+
+ [X.690] International Telecommunication Union -
+ Telecommunication Standardization Sector,
+ "Specification of ASN.1 encoding rules: Basic Encoding
+ Rules (BER), Canonical Encoding Rules (CER), and
+ Distinguished Encoding Rules (DER)", X.690(2002) (also
+ ISO/IEC 8825-1:2002).
+
+7.2. Informative References
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
+ (IANA) Considerations for the Lightweight Directory
+ Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+Zeilenga Standards Track [Page 5]
+
+RFC 4528 LDAP Assertion Control June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 6]
+
diff --git a/doc/rfc/rfc4529.txt b/doc/rfc/rfc4529.txt
new file mode 100644
index 0000000000000000000000000000000000000000..47449c040f0564c5fdb89697749b018c3fa3494a
--- /dev/null
+++ b/doc/rfc/rfc4529.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 4529 OpenLDAP Foundation
+Category: Informational June 2006
+
+
+ Requesting Attributes by Object Class in the
+ Lightweight Directory Access Protocol (LDAP)
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ The Lightweight Directory Access Protocol (LDAP) search operation
+ provides mechanisms for clients to request all user application
+ attributes, all operational attributes, and/or attributes selected by
+ their description. This document extends LDAP to support a mechanism
+ that LDAP clients may use to request the return of all attributes of
+ an object class.
+
+Table of Contents
+
+ 1. Background and Intended Use .....................................1
+ 2. Terminology .....................................................2
+ 3. Return of all Attributes of an Object Class .....................2
+ 4. Security Considerations .........................................3
+ 5. IANA Considerations .............................................3
+ 6. References ......................................................4
+ 6.1. Normative References .......................................4
+ 6.2. Informative References .....................................4
+
+1. Background and Intended Use
+
+ In the Lightweight Directory Access Protocol (LDAP) [RFC4510], the
+ search operation [RFC4511] supports requesting the return of a set of
+ attributes. This set is determined by a list of attribute
+ descriptions. Two special descriptors are defined to request all
+ user attributes ("*") [RFC4511] and all operational attributes ("+")
+ [RFC3673]. However, there is no convenient mechanism for requesting
+ pre-defined sets of attributes such as the set of attributes used to
+ represent a particular class of object.
+
+
+
+Zeilenga Informational [Page 1]
+
+RFC 4529 Requesting Attributes by Object Class June 2006
+
+
+ This document extends LDAP to allow an object class identifier to be
+ specified in attributes lists, such as in Search requests, to request
+ the return of all attributes belonging to an object class. The
+ COMMERCIAL AT ("@", U+0040) character is used to distinguish an
+ object class identifier from an attribute descriptions.
+
+ For example, the attribute list of "@country" is equivalent to the
+ attribute list of 'c', 'searchGuide', 'description', and
+ 'objectClass'. This object class is described in [RFC4519].
+
+ This extension is intended primarily to be used where the user is in
+ direct control of the parameters of the LDAP search operation, for
+ instance when entering an LDAP URL [RFC4516] into a web browser, such
+ as <ldap:///dc=example,dc=com?@organization?base>.
+
+2. Terminology
+
+ In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+ "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+ and "OPTIONAL" are to be interpreted as described in BCP 14
+ [RFC2119].
+
+ DSA stands for Directory System Agent (or server).
+ DSE stands for DSA-specific Entry.
+
+3. Return of All Attributes of an Object Class
+
+ This extension allows object class identifiers to be provided in the
+ attributes field of the LDAP SearchRequest [RFC4511] or other request
+ values of the AttributeSelection data type (e.g., attributes field in
+ pre/post read controls [ReadEntry]) and/or <attributeSelector>
+ production (e.g., attributes of an LDAP URL [RFC4516]). For each
+ object class identified in the attributes field, the request is to be
+ treated as if each attribute allowed by that class (by "MUST" or
+ "MAY", directly or by "SUP"erior) [RFC4512] were itself listed.
+
+ This extension extends the <attributeSelector> [RFC4511] production
+ as indicated by the following ABNF [RFC4234]:
+
+ attributeSelector =/ objectclassdescription
+ objectclassdescription = ATSIGN oid options
+ ATSIGN = %x40 ; COMMERCIAL AT ("@" U+0040)
+
+ where <oid> and <options> productions are as defined in [RFC4512].
+
+
+
+
+
+
+
+Zeilenga Informational [Page 2]
+
+RFC 4529 Requesting Attributes by Object Class June 2006
+
+
+ The <oid> component of an <objectclassdescription> production
+ identifies the object class by short name (descr) or object
+ identifier (numericoid). If the value of the <oid> component is
+ unrecognized or does not refer to an object class, the object class
+ description is to be treated as an unrecognized attribute
+ description.
+
+ The <options> production is included in the grammar for extensibility
+ purposes. An object class description with an unrecognized or
+ inappropriate option is to be treated as unrecognized.
+
+ Although object class description options and attribute description
+ options share the same syntax, they are not semantically related.
+ This document does not define any object description option.
+
+ Servers supporting this feature SHOULD publish the object identifier
+ (OID) 1.3.6.1.4.1.4203.1.5.2 as a value of the 'supportedFeatures'
+ [RFC4512] attribute in the root DSE. Clients supporting this feature
+ SHOULD NOT use the feature unless they know that the server supports
+ it.
+
+4. Security Considerations
+
+ This extension provides a shorthand for requesting all attributes of
+ an object class. Because these attributes could have been listed
+ individually, introduction of this shorthand is not believed to raise
+ additional security considerations.
+
+ Implementors of this LDAP extension should be familiar with security
+ considerations applicable to the LDAP search operation [RFC4511], as
+ well as with general LDAP security considerations [RFC4510].
+
+5. IANA Considerations
+
+ Registration of the LDAP Protocol Mechanism [RFC4520] defined in this
+ document has been completed.
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: 1.3.6.1.4.1.4203.1.5.2
+ Description: OC AD Lists
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+ Usage: Feature
+ Specification: RFC 4529
+ Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
+ Comments: none
+
+
+
+
+
+Zeilenga Informational [Page 3]
+
+RFC 4529 Requesting Attributes by Object Class June 2006
+
+
+ This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its
+ IANA-assigned private enterprise allocation [PRIVATE], for use in
+ this specification.
+
+6. References
+
+6.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
+ Syntax Specifications: ABNF", RFC 4234, October 2005.
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Technical Specification Road Map", RFC
+ 4510, June 2006.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+ [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory
+ Access Protocol (LDAP): Uniform Resource Locator", RFC
+ 4516, June 2006.
+
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
+
+6.2. Informative References
+
+ [RFC3673] Zeilenga, K., "Lightweight Directory Access Protocol
+ version 3 (LDAPv3): All Operational Attributes", RFC
+ 3673, December 2003.
+
+ [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Schema for User Applications", RFC
+ 4519, June 2006.
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
+ (IANA) Considerations for the Lightweight Directory
+ Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+
+
+
+Zeilenga Informational [Page 4]
+
+RFC 4529 Requesting Attributes by Object Class June 2006
+
+
+ [ReadEntry] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP) Read Entry Controls", RFC 4527, June 2006.
+
+ [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
+ http://www.openldap.org/foundation/oid-delegate.txt.
+
+ [PRIVATE] IANA, "Private Enterprise Numbers",
+ http://www.iana.org/assignments/enterprise-numbers.
+
+Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Informational [Page 5]
+
+RFC 4529 Requesting Attributes by Object Class June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga Informational [Page 6]
+
diff --git a/doc/rfc/rfc4530.txt b/doc/rfc/rfc4530.txt
new file mode 100644
index 0000000000000000000000000000000000000000..219a7c2d0cc14fa60848af342318100e89d855b0
--- /dev/null
+++ b/doc/rfc/rfc4530.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 4530 OpenLDAP Foundation
+Category: Standards Track June 2006
+
+
+ Lightweight Directory Access Protocol (LDAP)
+ entryUUID Operational Attribute
+
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This document describes the LDAP/X.500 'entryUUID' operational
+ attribute and associated matching rules and syntax. The attribute
+ holds a server-assigned Universally Unique Identifier (UUID) for the
+ object. Directory clients may use this attribute to distinguish
+ objects identified by a distinguished name or to locate an object
+ after renaming.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 1]
+
+RFC 4530 LDAP entryUUID June 2006
+
+
+Table of Contents
+
+ 1. Background and Intended Use .....................................2
+ 2. UUID Schema Elements ............................................3
+ 2.1. UUID Syntax ................................................3
+ 2.2. 'uuidMatch' Matching Rule ..................................3
+ 2.3. 'uuidOrderingMatch' Matching Rule ..........................3
+ 2.4. 'entryUUID' Attribute ......................................4
+ 3. Security Considerations .........................................4
+ 4. IANA Considerations .............................................5
+ 4.1. Object Identifier Registration .............................5
+ 4.2. UUID Syntax Registration ...................................5
+ 4.3. 'uuidMatch' Descriptor Registration ........................5
+ 4.4. 'uuidOrderingMatch' Descriptor Registration ................5
+ 4.5. 'entryUUID' Descriptor Registration ........................6
+ 5. Acknowledgements ................................................6
+ 6. References ......................................................6
+ 6.1. Normative References .......................................6
+ 6.2. Informative References .....................................7
+
+1. Background and Intended Use
+
+ In X.500 Directory Services [X.501], such as those accessible using
+ the Lightweight Directory Access Protocol (LDAP) [RFC4510], an object
+ is identified by its distinguished name (DN). However, DNs are not
+ stable identifiers. That is, a new object may be identified by a DN
+ that previously identified another (now renamed or deleted) object.
+
+ A Universally Unique Identifier (UUID) is "an identifier unique
+ across both space and time, with respect to the space of all UUIDs"
+ [RFC4122]. UUIDs are used in a wide range of systems.
+
+ This document describes the 'entryUUID' operational attribute, which
+ holds the UUID assigned to the object by the server. Clients may use
+ this attribute to distinguish objects identified by a particular
+ distinguished name or to locate a particular object after renaming.
+
+ This document defines the UUID syntax, the 'uuidMatch' and
+ 'uuidOrderingMatch' matching rules, and the 'entryUUID' attribute
+ type.
+
+ Schema definitions are provided using LDAP description formats
+ [RFC4512]. Definitions provided here are formatted (line wrapped)
+ for readability.
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 2]
+
+RFC 4530 LDAP entryUUID June 2006
+
+
+ In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+ "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+ and "OPTIONAL" are to be interpreted as described in BCP 14
+ [RFC2119].
+
+2. UUID Schema Elements
+
+2.1. UUID Syntax
+
+ A Universally Unique Identifier (UUID) [RFC4122] is a 16-octet (128-
+ bit) value that identifies an object. The ASN.1 [X.680] type UUID is
+ defined to represent UUIDs as follows:
+
+ UUID ::= OCTET STRING (SIZE(16))
+ -- constrained to an UUID [RFC4122]
+
+ In LDAP, UUID values are encoded using the [ASCII] character string
+ representation described in [RFC4122]. For example,
+ "597ae2f6-16a6-1027-98f4-d28b5365dc14".
+
+ The following is an LDAP syntax description suitable for publication
+ in subschema subentries.
+
+ ( 1.3.6.1.1.16.1 DESC 'UUID' )
+
+2.2. 'uuidMatch' Matching Rule
+
+ The 'uuidMatch' matching rule compares an asserted UUID with a stored
+ UUID for equality. Its semantics are the same as the
+ 'octetStringMatch' [X.520][RFC4517] matching rule. The rule differs
+ from 'octetStringMatch' in that the assertion value is encoded using
+ the UUID string representation instead of the normal OCTET STRING
+ string representation.
+
+ The following is an LDAP matching rule description suitable for
+ publication in subschema subentries.
+
+ ( 1.3.6.1.1.16.2 NAME 'uuidMatch'
+ SYNTAX 1.3.6.1.1.16.1 )
+
+2.3. 'uuidOrderingMatch' Matching Rule
+
+ The 'uuidOrderingMatch' matching rule compares an asserted UUID with
+ a stored UUID for ordering. Its semantics are the same as the
+ 'octetStringOrderingMatch' [X.520][RFC4517] matching rule. The rule
+ differs from 'octetStringOrderingMatch' in that the assertion value
+ is encoded using the UUID string representation instead of the normal
+ OCTET STRING string representation.
+
+
+
+Zeilenga Standards Track [Page 3]
+
+RFC 4530 LDAP entryUUID June 2006
+
+
+ The following is an LDAP matching rule description suitable for
+ publication in subschema subentries.
+
+ ( 1.3.6.1.1.16.3 NAME 'uuidOrderingMatch'
+ SYNTAX 1.3.6.1.1.16.1 )
+
+ Note that not all UUID variants have a defined ordering; and even
+ where it does, servers are not obligated to assign UUIDs in any
+ particular order. This matching rule is provided for completeness.
+
+2.4. 'entryUUID' Attribute
+
+ The 'entryUUID' operational attribute provides the Universally Unique
+ Identifier (UUID) assigned to the entry.
+
+ The following is an LDAP attribute type description suitable for
+ publication in subschema subentries.
+
+ ( 1.3.6.1.1.16.4 NAME 'entryUUID'
+ DESC 'UUID of the entry'
+ EQUALITY uuidMatch
+ ORDERING uuidOrderingMatch
+ SYNTAX 1.3.6.1.1.16.1
+ SINGLE-VALUE
+ NO-USER-MODIFICATION
+ USAGE directoryOperation )
+
+ Servers SHALL generate and assign a new UUID to each entry upon its
+ addition to the directory and provide that UUID as the value of the
+ 'entryUUID' operational attribute. An entry's UUID is immutable.
+
+ UUID are to be generated in accordance with Section 4 of [RFC4122].
+ In particular, servers MUST ensure that each generated UUID is unique
+ in space and time.
+
+3. Security Considerations
+
+ An entry's relative distinguish name (RDN) is composed from attribute
+ values of the entry, which are commonly descriptive of the object the
+ entry represents. Although deployers are encouraged to use naming
+ attributes whose values are widely disclosable [RFC4514], entries are
+ often named using information that cannot be disclosed to all
+ parties. As UUIDs do not contain any descriptive information of the
+ object they identify, UUIDs may be used to identify a particular
+ entry without disclosure of its contents.
+
+ General UUID security considerations [RFC4122] apply.
+
+
+
+
+Zeilenga Standards Track [Page 4]
+
+RFC 4530 LDAP entryUUID June 2006
+
+
+ General LDAP security considerations [RFC4510] apply.
+
+4. IANA Considerations
+
+ The IANA has registered the LDAP values [RFC4520] specified in this
+ document.
+
+4.1. Object Identifier Registration
+
+ Subject: Request for LDAP OID Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Specification: RFC 4530
+ Author/Change Controller: IESG
+ Comments:
+ Identifies the UUID schema elements
+
+4.2. UUID Syntax Registration
+
+ Subject: Request for LDAP Syntax Registration
+ Object Identifier: 1.3.6.1.1.16.1
+ Description: UUID
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Specification: RFC 4530
+ Author/Change Controller: IESG
+ Comments:
+ Identifies the UUID syntax
+
+4.3. 'uuidMatch' Descriptor Registration
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): uuidMatch
+ Object Identifier: 1.3.6.1.1.16.2
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Usage: Matching Rule
+ Specification: RFC 4530
+ Author/Change Controller: IESG
+
+4.4. 'uuidOrderingMatch' Descriptor Registration
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): uuidOrderingMatch
+ Object Identifier: 1.3.6.1.1.16.3
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Usage: Matching Rule
+
+
+
+Zeilenga Standards Track [Page 5]
+
+RFC 4530 LDAP entryUUID June 2006
+
+
+ Specification: RFC 4530
+ Author/Change Controller: IESG
+
+4.5. 'entryUUID' Descriptor Registration
+
+ The IANA has registered the LDAP 'entryUUID' descriptor.
+
+ Subject: Request for LDAP Descriptor Registration
+ Descriptor (short name): entryUUID
+ Object Identifier: 1.3.6.1.1.16.4
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Usage: Attribute Type
+ Specification: RFC 4530
+ Author/Change Controller: IESG
+
+5. Acknowledgements
+
+ This document is based upon discussions in the LDAP Update and
+ Duplication Protocols (LDUP) WG. Members of the LDAP Directorate
+ provided review.
+
+6. References
+
+6.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
+ Unique IDentifier (UUID) URN Namespace", RFC 4122, July
+ 2005.
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Technical Specification Road Map", RFC
+ 4510, June 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+ [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Syntaxes and Matching Rules", RFC 4517, June
+ 2006.
+
+ [ASCII] Coded Character Set--7-bit American Standard Code for
+ Information Interchange, ANSI X3.4-1986.
+
+
+
+
+Zeilenga Standards Track [Page 6]
+
+RFC 4530 LDAP entryUUID June 2006
+
+
+ [X.501] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory -- Models," X.501(1993) (also ISO/IEC 9594-
+ 2:1994).
+
+ [X.520] International Telecommunication Union -
+ Telecommunication Standardization Sector, "The
+ Directory: Selected Attribute Types", X.520(1993) (also
+ ISO/IEC 9594-6:1994).
+
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
+
+6.2. Informative References
+
+ [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access
+ Protocol (LDAP): String Representation of Distinguished
+ Names", RFC 4514, June 2006.
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
+ (IANA) Considerations for the Lightweight Directory
+ Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 7]
+
+RFC 4530 LDAP entryUUID June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 8]
+
diff --git a/doc/rfc/rfc4531.txt b/doc/rfc/rfc4531.txt
new file mode 100644
index 0000000000000000000000000000000000000000..b551d441cbfb18d7c173f7c32fb8e1ce26a8e54b
--- /dev/null
+++ b/doc/rfc/rfc4531.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 4531 OpenLDAP Foundation
+Category: Experimental June 2006
+
+
+ Lightweight Directory Access Protocol (LDAP)
+ Turn Operation
+
+
+Status of This Memo
+
+ This memo defines an Experimental Protocol for the Internet
+ community. It does not specify an Internet standard of any kind.
+ Discussion and suggestions for improvement are requested.
+ Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This specification describes a Lightweight Directory Access Protocol
+ (LDAP) extended operation to reverse (or "turn") the roles of client
+ and server for subsequent protocol exchanges in the session, or to
+ enable each peer to act as both client and server with respect to the
+ other.
+
+Table of Contents
+
+ 1. Background and Intent of Use ....................................2
+ 1.1. Terminology ................................................2
+ 2. Turn Operation ..................................................2
+ 2.1. Turn Request ...............................................3
+ 2.2. Turn Response ..............................................3
+ 3. Authentication ..................................................3
+ 3.1. Use with TLS and Simple Authentication .....................4
+ 3.2. Use with TLS and SASL EXTERNAL .............................4
+ 3.3. Use of Mutual Authentication and SASL EXTERNAL .............4
+ 4. TLS and SASL Security Layers ....................................5
+ 5. Security Considerations .........................................6
+ 6. IANA Considerations .............................................6
+ 6.1. Object Identifier ..........................................6
+ 6.2. LDAP Protocol Mechanism ....................................7
+ 7. References ......................................................7
+ 7.1. Normative References .......................................7
+ 7.2. Informative References .....................................8
+
+
+
+
+Zeilenga Experimental [Page 1]
+
+RFC 4531 LDAP Turn Operation June 2006
+
+
+1. Background and Intent of Use
+
+ The Lightweight Directory Access Protocol (LDAP) [RFC4510][RFC4511]
+ is a client-server protocol that typically operates over reliable
+ octet-stream transports, such as the Transport Control Protocol
+ (TCP). Generally, the client initiates the stream by connecting to
+ the server's listener at some well-known address.
+
+ There are cases where it is desirable for the server to initiate the
+ stream. Although it certainly is possible to write a technical
+ specification detailing how to implement server-initiated LDAP
+ sessions, this would require the design of new authentication and
+ other security mechanisms to support server-initiated LDAP sessions.
+
+ Instead, this document introduces an operation, the Turn operation,
+ which may be used to reverse the client-server roles of the protocol
+ peers. This allows the initiating protocol peer to become the server
+ (after the reversal).
+
+ As an additional feature, the Turn operation may be used to allow
+ both peers to act in both roles. This is useful where both peers are
+ directory servers that desire to request, as LDAP clients, that
+ operations be performed by the other. This may be useful in
+ replicated and/or distributed environments.
+
+ This operation is intended to be used between protocol peers that
+ have established a mutual agreement, by means outside of the
+ protocol, that requires reversal of client-server roles, or allows
+ both peers to act both as client and server.
+
+1.1. Terminology
+
+ Protocol elements are described using ASN.1 [X.680] with implicit
+ tags. The term "BER-encoded" means the element is to be encoded
+ using the Basic Encoding Rules [X.690] under the restrictions
+ detailed in Section 5.1 of [RFC4511].
+
+2. Turn Operation
+
+ The Turn operation is defined as an LDAP-Extended Operation
+ [Protocol, Section 4.12] identified by the 1.3.6.1.1.19 OID. The
+ function of the Turn Operation is to request that the client-server
+ roles be reversed, or, optionally, to request that both protocol
+ peers be able to act both as client and server in respect to the
+ other.
+
+
+
+
+
+
+Zeilenga Experimental [Page 2]
+
+RFC 4531 LDAP Turn Operation June 2006
+
+
+2.1. Turn Request
+
+ The Turn request is an ExtendedRequest where the requestName field
+ contains the 1.3.6.1.1.19 OID and the requestValue field is a BER-
+ encoded turnValue:
+
+ turnValue ::= SEQUENCE {
+ mutual BOOLEAN DEFAULT FALSE,
+ identifier LDAPString
+ }
+
+ A TRUE mutual field value indicates a request to allow both peers to
+ act both as client and server. A FALSE mutual field value indicates
+ a request to reserve the client and server roles.
+
+ The value of the identifier field is a locally defined policy
+ identifier (typically associated with a mutual agreement for which
+ this turn is be executed as part of).
+
+2.2. Turn Response
+
+ A Turn response is an ExtendedResponse where the responseName and
+ responseValue fields are absent. A resultCode of success is returned
+ if and only if the responder is willing and able to turn the session
+ as requested. Otherwise, a different resultCode is returned.
+
+3. Authentication
+
+ This extension's authentication model assumes separate authentication
+ of the peers in each of their roles. A separate Bind exchange is
+ expected between the peers in their new roles to establish identities
+ in these roles.
+
+ Upon completion of the Turn, the responding peer in its new client
+ role has an anonymous association at the initiating peer in its new
+ server role. If the turn was mutual, the authentication association
+ of the initiating peer in its pre-existing client role is left intact
+ at the responding peer in its pre-existing server role. If the turn
+ was not mutual, this association is void.
+
+ The responding peer may establish its identity in its client role by
+ requesting and successfully completing a Bind operation.
+
+ The remainder of this section discusses some authentication
+ scenarios. In the protocol exchange illustrations, A refers to the
+ initiating peer (the original client) and B refers to the responding
+ peer (the original server).
+
+
+
+
+Zeilenga Experimental [Page 3]
+
+RFC 4531 LDAP Turn Operation June 2006
+
+
+3.1. Use with TLS and Simple Authentication
+
+ A->B: StartTLS Request
+ B->A: StartTLS(success) Response
+ A->B: Bind(Simple(cn=B,dc=example,dc=net,B's secret)) Request
+ B->A: Bind(success) Response
+ A->B: Turn(TRUE,"XXYYZ") Request
+ B->A: Turn(success) Response
+ B->A: Bind(Simple(cn=A,dc=example,dc=net,A's secret)) Request
+ A->B: Bind(success) Response
+
+ In this scenario, TLS (Transport Layer Security) [RFC4346] is started
+ and the initiating peer (the original client) establishes its
+ identity with the responding peer prior to the Turn using the
+ DN/password mechanism of the Simple method of the Bind operation.
+ After the turn, the responding peer, in its new client role,
+ establishes its identity with the initiating peer in its new server
+ role.
+
+3.2. Use with TLS and SASL EXTERNAL
+
+ A->B: StartTLS Request
+ B->A: StartTLS(success) Response
+ A->B: Bind(SASL(EXTERNAL)) Request
+ B->A: Bind(success) Response
+ A->B: Turn(TRUE,"XXYYZ") Request
+ B->A: Turn(success) Response
+ B->A: Bind(SASL(EXTERNAL)) Request
+ A->B: Bind(success) Response
+
+ In this scenario, TLS is started (with each peer providing a valid
+ certificate), and the initiating peer (the original client)
+ establishes its identity through the use of the EXTERNAL mechanism of
+ the SASL (Simple Authentication and Security Layer) [RFC4422] method
+ of the Bind operation prior to the Turn. After the turn, the
+ responding peer, in its new client role, establishes its identity
+ with the initiating peer in its new server role.
+
+3.3. Use of Mutual Authentication and SASL EXTERNAL
+
+ A number of SASL mechanisms, such as GSSAPI [SASL-K5], support mutual
+ authentication. The initiating peer, in its new server role, may use
+ the identity of the responding peer, established by a prior
+ authentication exchange, as its source for "external" identity in
+ subsequent EXTERNAL exchange.
+
+ A->B: Bind(SASL(GSSAPI)) Request
+ <intermediate messages>
+
+
+
+Zeilenga Experimental [Page 4]
+
+RFC 4531 LDAP Turn Operation June 2006
+
+
+ B->A: Bind(success) Response
+ A->B: Turn(TRUE,"XXYYZ") Request
+ B->A: Turn(success) Response
+ B->A: Bind(SASL(EXTERNAL)) Request
+ A->B: Bind(success) Response
+
+ In this scenario, a GSSAPI mutual-authentication exchange is
+ completed between the initiating peer (the original client) and the
+ responding server (the original server) prior to the turn. After the
+ turn, the responding peer, in its new client role, requests that the
+ initiating peer utilize an "external" identity to establish its LDAP
+ authorization identity.
+
+4. TLS and SASL Security Layers
+
+ As described in [RFC4511], LDAP supports both Transport Layer
+ Security (TLS) [RFC4346] and Simple Authentication and Security Layer
+ (SASL) [RFC4422] security frameworks. The following table
+ illustrates the relationship between the LDAP message layer, SASL
+ layer, TLS layer, and transport connection within an LDAP session.
+
+ +----------------------+
+ | LDAP message layer |
+ +----------------------+ > LDAP PDUs
+ +----------------------+ < data
+ | SASL layer |
+ +----------------------+ > SASL-protected data
+ +----------------------+ < data
+ | TLS layer |
+ Application +----------------------+ > TLS-protected data
+ ------------+----------------------+ < data
+ Transport | transport connection |
+ +----------------------+
+
+ This extension does not alter this relationship, nor does it remove
+ the general restriction against multiple TLS layers, nor does it
+ remove the general restriction against multiple SASL layers.
+
+ As specified in [RFC4511], the StartTLS operation is used to initiate
+ negotiation of a TLS layer. If a TLS is already installed, the
+ StartTLS operation must fail. Upon establishment of the TLS layer,
+ regardless of which peer issued the request to start TLS, the peer
+ that initiated the LDAP session (the original client) performs the
+ "server identity check", as described in Section 3.1.5 of [RFC4513],
+ treating itself as the "client" and its peer as the "server".
+
+ As specified in [RFC4422], a newly negotiated SASL security layer
+ replaces the installed SASL security layer. Though the client/server
+
+
+
+Zeilenga Experimental [Page 5]
+
+RFC 4531 LDAP Turn Operation June 2006
+
+
+ roles in LDAP, and hence SASL, may be reversed in subsequent
+ exchanges, only one SASL security layer may be installed at any
+ instance.
+
+5. Security Considerations
+
+ Implementors should be aware that the reversing of client/server
+ roles and/or allowing both peers to act as client and server likely
+ introduces security considerations not foreseen by the authors of
+ this document. In particular, the security implications of the
+ design choices made in the authentication and data security models
+ for this extension (discussed in Sections 3 and 4, respectively) are
+ not fully studied. It is hoped that experimentation with this
+ extension will lead to better understanding of the security
+ implications of these models and other aspects of this extension, and
+ that appropriate considerations will be documented in a future
+ document. The following security considerations are apparent at this
+ time.
+
+ Implementors should take special care to process LDAP, SASL, TLS, and
+ other events in the appropriate roles for the peers. Note that while
+ the Turn reverses the client/server roles with LDAP, and in SASL
+ authentication exchanges, it does not reverse the roles within the
+ TLS layer or the transport connection.
+
+ The responding server (the original server) should restrict use of
+ this operation to authorized clients. Client knowledge of a valid
+ identifier should not be the sole factor in determining authorization
+ to turn.
+
+ Where the peers except to establish TLS, TLS should be started prior
+ to the Turn and any request to authenticate via the Bind operation.
+
+ LDAP security considerations [RFC4511][RFC4513] generally apply to
+ this extension.
+
+6. IANA Considerations
+
+ The following values [RFC4520] have been registered by the IANA.
+
+6.1. Object Identifier
+
+ The IANA has assigned an LDAP Object Identifier to identify the LDAP
+ Turn Operation, as defined in this document.
+
+
+
+
+
+
+
+Zeilenga Experimental [Page 6]
+
+RFC 4531 LDAP Turn Operation June 2006
+
+
+ Subject: Request for LDAP Object Identifier Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Specification: RFC 4531
+ Author/Change Controller: Author
+ Comments:
+ Identifies the LDAP Turn Operation
+
+6.2. LDAP Protocol Mechanism
+
+ The IANA has registered the LDAP Protocol Mechanism described in this
+ document.
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: 1.3.6.1.1.19
+ Description: LDAP Turn Operation
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+ Usage: Extended Operation
+ Specification: RFC 4531
+ Author/Change Controller: Author
+ Comments: none
+
+7. References
+
+7.1. Normative References
+
+ [RFC4346] Dierks, T. and, E. Rescorla, "The Transport Layer
+ Security (TLS) Protocol Version 1.1", RFC 4346, April
+ 2006.
+
+ [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
+ Authentication and Security Layer (SASL)", RFC 4422,
+ June 2006.
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Technical Specification Road Map", RFC
+ 4510, June 2006.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4513] Harrison, R., Ed., "Lightweight Directory Access
+ Protocol (LDAP): Authentication Methods and Security
+ Mechanisms", RFC 4513, June 2006.
+
+
+
+
+
+
+Zeilenga Experimental [Page 7]
+
+RFC 4531 LDAP Turn Operation June 2006
+
+
+ [X.680] International Telecommunication Union -
+ Telecommunication Standardization Sector, "Abstract
+ Syntax Notation One (ASN.1) - Specification of Basic
+ Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
+
+ [X.690] International Telecommunication Union -
+ Telecommunication Standardization Sector,
+ "Specification of ASN.1 encoding rules: Basic Encoding
+ Rules (BER), Canonical Encoding Rules (CER), and
+ Distinguished Encoding Rules (DER)", X.690(2002) (also
+ ISO/IEC 8825-1:2002).
+
+7.2. Informative References
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
+ (IANA) Considerations for the Lightweight Directory
+ Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+ [SASL-K5] Melnikov, A., Ed., "The Kerberos V5 ("GSSAPI") SASL
+ Mechanism", Work in Progress, May 2006.
+
+Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Experimental [Page 8]
+
+RFC 4531 LDAP Turn Operation June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga Experimental [Page 9]
+
diff --git a/doc/rfc/rfc4532.txt b/doc/rfc/rfc4532.txt
new file mode 100644
index 0000000000000000000000000000000000000000..277b3b7442b0ad7e0f6ca9a6c7a84e314ea6bd2a
--- /dev/null
+++ b/doc/rfc/rfc4532.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 4532 OpenLDAP Foundation
+Category: Standards Track June 2006
+
+
+ Lightweight Directory Access Protocol (LDAP)
+ "Who am I?" Operation
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This specification provides a mechanism for Lightweight Directory
+ Access Protocol (LDAP) clients to obtain the authorization identity
+ the server has associated with the user or application entity. This
+ mechanism is specified as an LDAP extended operation called the LDAP
+ "Who am I?" operation.
+
+1. Background and Intent of Use
+
+ This specification describes a Lightweight Directory Access Protocol
+ (LDAP) [RFC4510] operation that clients can use to obtain the primary
+ authorization identity, in its primary form, that the server has
+ associated with the user or application entity. The operation is
+ called the "Who am I?" operation.
+
+ This specification is intended to replace the existing Authorization
+ Identity Controls [RFC3829] mechanism, which uses Bind request and
+ response controls to request and return the authorization identity.
+ Bind controls are not protected by security layers established by the
+ Bind operation that includes them. While it is possible to establish
+ security layers using StartTLS [RFC4511][RFC4513] prior to the Bind
+ operation, it is often desirable to use security layers established
+ by the Bind operation. An extended operation sent after a Bind
+ operation is protected by the security layers established by the Bind
+ operation.
+
+
+
+
+
+Zeilenga Standards Track [Page 1]
+
+RFC 4532 LDAP "Who am I?" Operation June 2006
+
+
+ There are other cases where it is desirable to request the
+ authorization identity that the server associated with the client
+ separately from the Bind operation. For example, the "Who am I?"
+ operation can be augmented with a Proxied Authorization Control
+ [RFC4370] to determine the authorization identity that the server
+ associates with the identity asserted in the Proxied Authorization
+ Control. The "Who am I?" operation can also be used prior to the
+ Bind operation.
+
+ Servers often associate multiple authorization identities with the
+ client, and each authorization identity may be represented by
+ multiple authzId [RFC4513] strings. This operation requests and
+ returns the authzId that the server considers primary. In the
+ specification, the term "the authorization identity" and "the
+ authzId" are generally to be read as "the primary authorization
+ identity" and the "the primary authzId", respectively.
+
+1.1. Conventions Used in This Document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+2. The "Who am I?" Operation
+
+ The "Who am I?" operation is defined as an LDAP Extended Operation
+ [RFC4511] identified by the whoamiOID Object Identifier (OID). This
+ section details the syntax of the operation's whoami request and
+ response messages.
+
+ whoamiOID ::= "1.3.6.1.4.1.4203.1.11.3"
+
+2.1. The whoami Request
+
+ The whoami request is an ExtendedRequest with a requestName field
+ containing the whoamiOID OID and an absent requestValue field. For
+ example, a whoami request could be encoded as the sequence of octets
+ (in hex):
+
+ 30 1e 02 01 02 77 19 80 17 31 2e 33 2e 36 2e 31
+ 2e 34 2e 31 2e 34 32 30 33 2e 31 2e 31 31 2e 33
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 2]
+
+RFC 4532 LDAP "Who am I?" Operation June 2006
+
+
+2.2. The whoami Response
+
+ The whoami response is an ExtendedResponse where the responseName
+ field is absent and the response field, if present, is empty or an
+ authzId [RFC4513]. For example, a whoami response returning the
+ authzId "u:xxyyz@EXAMPLE.NET" (in response to the example request)
+ would be encoded as the sequence of octets (in hex):
+
+ 30 21 02 01 02 78 1c 0a 01 00 04 00 04 00 8b 13
+ 75 3a 78 78 79 79 7a 40 45 58 41 4d 50 4c 45 2e
+ 4e 45 54
+
+3. Operational Semantics
+
+ The "Who am I?" operation provides a mechanism, a whoami Request, for
+ the client to request that the server return the authorization
+ identity it currently associates with the client. It also provides a
+ mechanism, a whoami Response, for the server to respond to that
+ request.
+
+ Servers indicate their support for this extended operation by
+ providing a whoamiOID object identifier as a value of the
+ 'supportedExtension' attribute type in their root DSE. The server
+ SHOULD advertise this extension only when the client is willing and
+ able to perform this operation.
+
+ If the server is willing and able to provide the authorization
+ identity it associates with the client, the server SHALL return a
+ whoami Response with a success resultCode. If the server is treating
+ the client as an anonymous entity, the response field is present but
+ empty. Otherwise, the server provides the authzId [RFC4513]
+ representing the authorization identity it currently associates with
+ the client in the response field.
+
+ If the server is unwilling or unable to provide the authorization
+ identity it associates with the client, the server SHALL return a
+ whoami Response with an appropriate non-success resultCode (such as
+ operationsError, protocolError, confidentialityRequired,
+ insufficientAccessRights, busy, unavailable, unwillingToPerform, or
+ other) and an absent response field.
+
+ As described in [RFC4511] and [RFC4513], an LDAP session has an
+ "anonymous" association until the client has been successfully
+ authenticated using the Bind operation. Clients MUST NOT invoke the
+ "Who am I?" operation while any Bind operation is in progress,
+ including between two Bind requests made as part of a multi-stage
+
+
+
+
+
+Zeilenga Standards Track [Page 3]
+
+RFC 4532 LDAP "Who am I?" Operation June 2006
+
+
+ Bind operation. Where a whoami Request is received in violation of
+ this absolute prohibition, the server should return a whoami Response
+ with an operationsError resultCode.
+
+4. Extending the "Who am I?" Operation with Controls
+
+ Future specifications may extend the "Who am I?" operation using the
+ control mechanism [RFC4511]. When extended by controls, the "Who am
+ I?" operation requests and returns the authorization identity the
+ server associates with the client in a particular context indicated
+ by the controls.
+
+4.1. Proxied Authorization Control
+
+ The Proxied Authorization Control [RFC4370] is used by clients to
+ request that the operation it is attached to operate under the
+ authorization of an assumed identity. The client provides the
+ identity to assume in the Proxied Authorization request control. If
+ the client is authorized to assume the requested identity, the server
+ executes the operation as if the requested identity had issued the
+ operation.
+
+ As servers often map the asserted authzId to another identity
+ [RFC4513], it is desirable to request that the server provide the
+ authzId it associates with the assumed identity.
+
+ When a Proxied Authorization Control is be attached to the "Who am
+ I?" operation, the operation requests the return of the authzId the
+ server associates with the identity asserted in the Proxied
+ Authorization Control. The authorizationDenied (123) result code is
+ used to indicate that the server does not allow the client to assume
+ the asserted identity.
+
+5. Security Considerations
+
+ Identities associated with users may be sensitive information. When
+ they are, security layers [RFC4511][RFC4513] should be established to
+ protect this information. This mechanism is specifically designed to
+ allow security layers established by a Bind operation to protect the
+ integrity and/or confidentiality of the authorization identity.
+
+ Servers may place access control or other restrictions upon the use
+ of this operation. As stated in Section 3, the server SHOULD
+ advertise this extension when it is willing and able to perform the
+ operation.
+
+ As with any other extended operations, general LDAP security
+ considerations [RFC4510] apply.
+
+
+
+Zeilenga Standards Track [Page 4]
+
+RFC 4532 LDAP "Who am I?" Operation June 2006
+
+
+6. IANA Considerations
+
+ The OID 1.3.6.1.4.1.4203.1.11.3 is used to identify the LDAP "Who am
+ I?" extended operation. This OID was assigned [ASSIGN] by the
+ OpenLDAP Foundation, under its IANA-assigned private enterprise
+ allocation [PRIVATE], for use in this specification.
+
+ Registration of this protocol mechanism [RFC4520] has been completed
+ by the IANA.
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: 1.3.6.1.4.1.4203.1.11.3
+ Description: Who am I?
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+ Usage: Extended Operation
+ Specification: RFC 4532
+ Author/Change Controller: IESG
+ Comments: none
+
+7. Acknowledgement
+
+ This document borrows from prior work in this area, including
+ "Authentication Response Control" [RFC3829] by Rob Weltman, Mark
+ Smith, and Mark Wahl.
+
+ The LDAP "Who am I?" operation takes it's name from the UNIX
+ whoami(1) command. The whoami(1) command displays the effective user
+ ID.
+
+8. References
+
+8.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4370] Weltman, R., "Lightweight Directory Access Protocol (LDAP)
+ Proxied Authorization Control", RFC 4370, February 2006.
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Technical Specification Road Map", RFC 4510, June
+ 2006.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+
+
+
+
+Zeilenga Standards Track [Page 5]
+
+RFC 4532 LDAP "Who am I?" Operation June 2006
+
+
+ [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Authentication Methods and Security Mechanisms",
+ RFC 4513, June 2006.
+
+8.2. Informative References
+
+ [RFC3829] Weltman, R., Smith, M., and M. Wahl, "Lightweight Directory
+ Access Protocol (LDAP) Authorization Identity Request and
+ Response Controls", RFC 3829, July 2004.
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+ [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
+ http://www.openldap.org/foundation/oid-delegate.txt.
+
+ [PRIVATE] IANA, "Private Enterprise Numbers",
+ http://www.iana.org/assignments/enterprise-numbers.
+
+Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 6]
+
+RFC 4532 LDAP "Who am I?" Operation June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga Standards Track [Page 7]
+
diff --git a/doc/rfc/rfc4533.txt b/doc/rfc/rfc4533.txt
new file mode 100644
index 0000000000000000000000000000000000000000..5f507ceae896b46e6b0507239e9fa39589504b0e
--- /dev/null
+++ b/doc/rfc/rfc4533.txt
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+Network Working Group K. Zeilenga
+Request for Comments: 4533 OpenLDAP Foundation
+Category: Experimental J.H. Choi
+ IBM Corporation
+ June 2006
+
+
+ The Lightweight Directory Access Protocol (LDAP)
+ Content Synchronization Operation
+
+Status of This Memo
+
+ This memo defines an Experimental Protocol for the Internet
+ community. It does not specify an Internet standard of any kind.
+ Discussion and suggestions for improvement are requested.
+ Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+IESG Note
+
+ The IESG notes that this work was originally discussed in the LDUP
+ working group. The group came to consensus on a different approach,
+ documented in RFC 3928; that document is on the standards track and
+ should be reviewed by those considering implementation of this
+ proposal.
+
+Abstract
+
+ This specification describes the Lightweight Directory Access
+ Protocol (LDAP) Content Synchronization Operation. The operation
+ allows a client to maintain a copy of a fragment of the Directory
+ Information Tree (DIT). It supports both polling for changes and
+ listening for changes. The operation is defined as an extension of
+ the LDAP Search Operation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga & Choi Experimental [Page 1]
+
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 1.1. Background .................................................3
+ 1.2. Intended Usage .............................................4
+ 1.3. Overview ...................................................5
+ 1.4. Conventions ................................................8
+ 2. Elements of the Sync Operation ..................................8
+ 2.1. Common ASN.1 Elements ......................................9
+ 2.2. Sync Request Control .......................................9
+ 2.3. Sync State Control ........................................10
+ 2.4. Sync Done Control .........................................10
+ 2.5. Sync Info Message .........................................11
+ 2.6. Sync Result Codes .........................................11
+ 3. Content Synchronization ........................................11
+ 3.1. Synchronization Session ...................................12
+ 3.2. Content Determination .....................................12
+ 3.3. refreshOnly Mode ..........................................13
+ 3.4. refreshAndPersist Mode ....................................16
+ 3.5. Search Request Parameters .................................17
+ 3.6. objectName ................................................18
+ 3.7. Canceling the Sync Operation ..............................19
+ 3.8. Refresh Required ..........................................19
+ 3.9. Chattiness Considerations .................................20
+ 3.10. Operation Multiplexing ...................................21
+ 4. Meta Information Considerations ................................22
+ 4.1. Entry DN ..................................................22
+ 4.2. Operational Attributes ....................................22
+ 4.3. Collective Attributes .....................................23
+ 4.4. Access and Other Administrative Controls ..................23
+ 5. Interaction with Other Controls ................................23
+ 5.1. ManageDsaIT Control .......................................24
+ 5.2. Subentries Control ........................................24
+ 6. Shadowing Considerations .......................................24
+ 7. Security Considerations ........................................25
+ 8. IANA Considerations ............................................26
+ 8.1. Object Identifier .........................................26
+ 8.2. LDAP Protocol Mechanism ...................................26
+ 8.3. LDAP Result Codes .........................................26
+ 9. Acknowledgements ...............................................26
+ 10. Normative References ..........................................27
+ 11. Informative References ........................................28
+ Appendix A. CSN-based Implementation Considerations ..............29
+
+
+
+
+
+
+
+
+Zeilenga & Choi Experimental [Page 2]
+
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+1. Introduction
+
+ The Lightweight Directory Access Protocol (LDAP) [RFC4510] provides a
+ mechanism, the search operation [RFC4511], that allows a client to
+ request directory content matching a complex set of assertions and to
+ request that the server return this content, subject to access
+ control and other restrictions, to the client. However, LDAP does
+ not provide (despite the introduction of numerous extensions in this
+ area) an effective and efficient mechanism for maintaining
+ synchronized copies of directory content. This document introduces a
+ new mechanism specifically designed to meet the content
+ synchronization requirements of sophisticated directory applications.
+
+ This document defines the LDAP Content Synchronization Operation, or
+ Sync Operation for short, which allows a client to maintain a
+ synchronized copy of a fragment of a Directory Information Tree
+ (DIT). The Sync Operation is defined as a set of controls and other
+ protocol elements that extend the Search Operation.
+
+1.1. Background
+
+ Over the years, a number of content synchronization approaches have
+ been suggested for use in LDAP directory services. These approaches
+ are inadequate for one or more of the following reasons:
+
+ - failure to ensure a reasonable level of convergence;
+
+ - failure to detect that convergence cannot be achieved (without
+ reload);
+
+ - require pre-arranged synchronization agreements;
+
+ - require the server to maintain histories of past changes to DIT
+ content and/or meta information;
+
+ - require the server to maintain synchronization state on a per-
+ client basis; and/or
+
+ - are overly chatty.
+
+ The Sync Operation provides eventual convergence of synchronized
+ content when possible and, when not, notification that a full reload
+ is required.
+
+ The Sync Operation does not require pre-arranged synchronization
+ agreements.
+
+
+
+
+
+Zeilenga & Choi Experimental [Page 3]
+
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ The Sync Operation does not require that servers maintain or use any
+ history of past changes to the DIT or to meta information. However,
+ servers may maintain and use histories (e.g., change logs,
+ tombstones, DIT snapshots) to reduce the number of messages generated
+ and to reduce their size. As it is not always feasible to maintain
+ and use histories, the operation may be implemented using purely
+ (current) state-based approaches. The Sync Operation allows use of
+ either the state-based approach or the history-based approach on an
+ operation-by-operation basis to balance the size of history and the
+ amount of traffic. The Sync Operation also allows the combined use
+ of the state-based and the history-based approaches.
+
+ The Sync Operation does not require that servers maintain
+ synchronization state on a per-client basis. However, servers may
+ maintain and use per-client state information to reduce the number of
+ messages generated and the size of such messages.
+
+ A synchronization mechanism can be considered overly chatty when
+ synchronization traffic is not reasonably bounded. The Sync
+ Operation traffic is bounded by the size of updated (or new) entries
+ and the number of unchanged entries in the content. The operation is
+ designed to avoid full content exchanges, even when the history
+ information available to the server is insufficient to determine the
+ client's state. The operation is also designed to avoid transmission
+ of out-of-content history information, as its size is not bounded by
+ the content and it is not always feasible to transmit such history
+ information due to security reasons.
+
+ This document includes a number of non-normative appendices providing
+ additional information to server implementors.
+
+1.2. Intended Usage
+
+ The Sync Operation is intended to be used in applications requiring
+ eventually-convergent content synchronization. Upon completion of
+ each synchronization stage of the operation, all information to
+ construct a synchronized client copy of the content has been provided
+ to the client or the client has been notified that a complete content
+ reload is necessary. Except for transient inconsistencies due to
+ concurrent operation (or other) processing at the server, the client
+ copy is an accurate reflection of the content held by the server.
+ Transient inconsistencies will be resolved by subsequent
+ synchronization operations.
+
+
+
+
+
+
+
+
+Zeilenga & Choi Experimental [Page 4]
+
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ Possible uses include the following:
+
+ - White page service applications may use the Sync Operation to
+ maintain a current copy of a DIT fragment, for example, a mail
+ user agent that uses the sync operation to maintain a local
+ copy of an enterprise address book.
+
+ - Meta-information engines may use the Sync Operation to maintain
+ a copy of a DIT fragment.
+
+ - Caching proxy services may use the Sync Operation to maintain a
+ coherent content cache.
+
+ - Lightweight master-slave replication between heterogeneous
+ directory servers. For example, the Sync Operation can be used
+ by a slave server to maintain a shadow copy of a DIT fragment.
+ (Note: The International Telephone Union (ITU) has defined the
+ X.500 Directory [X.500] Information Shadowing Protocol (DISP)
+ [X.525], which may be used for master-slave replication between
+ directory servers. Other experimental LDAP replication
+ protocols also exist.)
+
+ This protocol is not intended to be used in applications requiring
+ transactional data consistency.
+
+ As this protocol transfers all visible values of entries belonging to
+ the content upon change instead of change deltas, this protocol is
+ not appropriate for bandwidth-challenged applications or deployments.
+
+1.3. Overview
+
+ This section provides an overview of basic ways the Sync Operation
+ can be used to maintain a synchronized client copy of a DIT fragment.
+
+ - Polling for changes: refreshOnly mode
+
+ - Listening for changes: refreshAndPersist mode
+
+1.3.1. Polling for Changes (refreshOnly)
+
+ To obtain its initial client copy, the client issues a Sync request:
+ a search request with the Sync Request Control with mode set to
+ refreshOnly. The server, much like it would with a normal search
+ operation, returns (subject to access controls and other
+ restrictions) the content matching the search criteria (baseObject,
+ scope, filter, attributes). Additionally, with each entry returned,
+ the server provides a Sync State Control indicating state add. This
+ control contains the Universally Unique Identifier (UUID) [UUID] of
+
+
+
+Zeilenga & Choi Experimental [Page 5]
+
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ the entry [RFC4530]. Unlike the Distinguished Name (DN), which may
+ change over time, an entry's UUID is stable. The initial content is
+ followed by a SearchResultDone with a Sync Done Control. The Sync
+ Done Control provides a syncCookie. The syncCookie represents
+ session state.
+
+ To poll for updates to the client copy, the client reissues the Sync
+ Operation with the syncCookie previously returned. The server, much
+ as it would with a normal search operation, determines which content
+ would be returned as if the operation were a normal search operation.
+ However, using the syncCookie as an indicator of what content the
+ client was sent previously, the server sends copies of entries that
+ have changed with a Sync State Control indicating state add. For
+ each changed entry, all (modified or unmodified) attributes belonging
+ to the content are sent.
+
+ The server may perform either or both of the two distinct
+ synchronization phases that are distinguished by how to synchronize
+ entries deleted from the content: the present and the delete phases.
+ When the server uses a single phase for the refresh stage, each phase
+ is marked as ended by a SearchResultDone with a Sync Done Control. A
+ present phase is identified by a FALSE refreshDeletes value in the
+ Sync Done Control. A delete phase is identified by a TRUE
+ refreshDeletes value. The present phase may be followed by a delete
+ phase. The two phases are delimited by a refreshPresent Sync Info
+ Message having a FALSE refreshDone value. In the case that both the
+ phases are used, the present phase is used to bring the client copy
+ up to the state at which the subsequent delete phase can begin.
+
+ In the present phase, the server sends an empty entry (i.e., no
+ attributes) with a Sync State Control indicating state present for
+ each unchanged entry.
+
+ The delete phase may be used when the server can reliably determine
+ which entries in the prior client copy are no longer present in the
+ content and the number of such entries is less than or equal to the
+ number of unchanged entries. In the delete mode, the server sends an
+ empty entry with a Sync State Control indicating state delete for
+ each entry that is no longer in the content, instead of returning an
+ empty entry with state present for each present entry.
+
+ The server may send syncIdSet Sync Info Messages containing the set
+ of UUIDs of either unchanged present entries or deleted entries,
+ instead of sending multiple individual messages. If refreshDeletes
+ of syncIdSet is set to FALSE, the UUIDs of unchanged present entries
+ are contained in the syncUUIDs set; if refreshDeletes of syncIdSet is
+ set to TRUE, the UUIDs of the entries no longer present in the
+ content are contained in the syncUUIDs set. An optional cookie can
+
+
+
+Zeilenga & Choi Experimental [Page 6]
+
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ be included in the syncIdSet to represent the state of the content
+ after synchronizing the presence or the absence of the entries
+ contained in the syncUUIDs set.
+
+ The synchronized copy of the DIT fragment is constructed by the
+ client.
+
+ If refreshDeletes of syncDoneValue is FALSE, the new copy includes
+ all changed entries returned by the reissued Sync Operation, as well
+ as all unchanged entries identified as being present by the reissued
+ Sync Operation, but whose content is provided by the previous Sync
+ Operation. The unchanged entries not identified as being present are
+ deleted from the client content. They had been either deleted,
+ moved, or otherwise scoped-out from the content.
+
+ If refreshDeletes of syncDoneValue is TRUE, the new copy includes all
+ changed entries returned by the reissued Sync Operation, as well as
+ all other entries of the previous copy except for those that are
+ identified as having been deleted from the content.
+
+ The client can, at some later time, re-poll for changes to this
+ synchronized client copy.
+
+1.3.2. Listening for Changes (refreshAndPersist)
+
+ Polling for changes can be expensive in terms of server, client, and
+ network resources. The refreshAndPersist mode allows for active
+ updates of changed entries in the content.
+
+ By selecting the refreshAndPersist mode, the client requests that the
+ server send updates of entries that are changed after the initial
+ refresh content is determined. Instead of sending a SearchResultDone
+ Message as in polling, the server sends a Sync Info Message to the
+ client indicating that the refresh stage is complete and then enters
+ the persist stage. After receipt of this Sync Info Message, the
+ client will construct a synchronized copy as described in Section
+ 1.3.1.
+
+ The server may then send change notifications as the result of the
+ original Sync search request, which now remains persistent in the
+ server. For entries to be added to the returned content, the server
+ sends a SearchResultEntry (with attributes) with a Sync State Control
+ indicating state add. For entries to be deleted from the content,
+ the server sends a SearchResultEntry containing no attributes and a
+ Sync State Control indicating state delete. For entries to be
+ modified in the return content, the server sends a SearchResultEntry
+ (with attributes) with a Sync State Control indicating state modify.
+
+
+
+
+Zeilenga & Choi Experimental [Page 7]
+
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ Upon modification of an entry, all (modified or unmodified)
+ attributes belonging to the content are sent.
+
+ Note that renaming an entry of the DIT may cause an add state change
+ where the entry is renamed into the content, a delete state change
+ where the entry is renamed out of the content, and a modify state
+ change where the entry remains in the content. Also note that a
+ modification of an entry of the DIT may cause an add, delete, or
+ modify state change to the content.
+
+ Upon receipt of a change notification, the client updates its copy of
+ the content.
+
+ If the server desires to update the syncCookie during the persist
+ stage, it may include the syncCookie in any Sync State Control or
+ Sync Info Message returned.
+
+ The operation persists until canceled [RFC3909] by the client or
+ terminated by the server. A Sync Done Control shall be attached to
+ SearchResultDone Message to provide a new syncCookie.
+
+1.4. Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+ Protocol elements are described using ASN.1 [X.680] with implicit
+ tags. The term "BER-encoded" means the element is to be encoded
+ using the Basic Encoding Rules [X.690] under the restrictions
+ detailed in Section 5.1 of [RFC4511].
+
+2. Elements of the Sync Operation
+
+ The Sync Operation is defined as an extension to the LDAP Search
+ Operation [RFC4511] where the directory user agent (DUA or client)
+ submits a SearchRequest Message with a Sync Request Control and the
+ directory system agent (DSA or server) responds with zero or more
+ SearchResultEntry Messages, each with a Sync State Control; zero or
+ more SearchResultReference Messages, each with a Sync State Control;
+ zero or more Sync Info Intermediate Response Messages; and a
+ SearchResultDone Message with a Sync Done Control.
+
+ To allow clients to discover support for this operation, servers
+ implementing this operation SHOULD publish 1.3.6.1.4.1.4203.1.9.1.1
+ as a value of the 'supportedControl' attribute [RFC4512] of the root
+ DSA-specific entry (DSE). A server MAY choose to advertise this
+ extension only when the client is authorized to use it.
+
+
+
+Zeilenga & Choi Experimental [Page 8]
+
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+2.1. Common ASN.1 Elements
+
+2.1.1. syncUUID
+
+ The syncUUID data type is an OCTET STRING holding a 128-bit
+ (16-octet) Universally Unique Identifier (UUID) [UUID].
+
+ syncUUID ::= OCTET STRING (SIZE(16))
+ -- constrained to UUID
+
+2.1.2. syncCookie
+
+ The syncCookie is a notational convenience to indicate that, while
+ the syncCookie type is encoded as an OCTET STRING, its value is an
+ opaque value containing information about the synchronization session
+ and its state. Generally, the session information would include a
+ hash of the operation parameters that the server requires not be
+ changed and the synchronization state information would include a
+ commit (log) sequence number, a change sequence number, or a time
+ stamp. For convenience of description, the term "no cookie" refers
+ either to a null cookie or to a cookie with pre-initialized
+ synchronization state.
+
+ syncCookie ::= OCTET STRING
+
+2.2. Sync Request Control
+
+ The Sync Request Control is an LDAP Control [RFC4511] where the
+ controlType is the object identifier 1.3.6.1.4.1.4203.1.9.1.1 and the
+ controlValue, an OCTET STRING, contains a BER-encoded
+ syncRequestValue. The criticality field is either TRUE or FALSE.
+
+ syncRequestValue ::= SEQUENCE {
+ mode ENUMERATED {
+ -- 0 unused
+ refreshOnly (1),
+ -- 2 reserved
+ refreshAndPersist (3)
+ },
+ cookie syncCookie OPTIONAL,
+ reloadHint BOOLEAN DEFAULT FALSE
+ }
+
+ The Sync Request Control is only applicable to the SearchRequest
+ Message.
+
+
+
+
+
+
+Zeilenga & Choi Experimental [Page 9]
+
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+2.3. Sync State Control
+
+ The Sync State Control is an LDAP Control [RFC4511] where the
+ controlType is the object identifier 1.3.6.1.4.1.4203.1.9.1.2 and the
+ controlValue, an OCTET STRING, contains a BER-encoded syncStateValue.
+ The criticality is FALSE.
+
+ syncStateValue ::= SEQUENCE {
+ state ENUMERATED {
+ present (0),
+ add (1),
+ modify (2),
+ delete (3)
+ },
+ entryUUID syncUUID,
+ cookie syncCookie OPTIONAL
+ }
+
+ The Sync State Control is only applicable to SearchResultEntry and
+ SearchResultReference Messages.
+
+2.4. Sync Done Control
+
+ The Sync Done Control is an LDAP Control [RFC4511] where the
+ controlType is the object identifier 1.3.6.1.4.1.4203.1.9.1.3 and the
+ controlValue contains a BER-encoded syncDoneValue. The criticality
+ is FALSE (and hence absent).
+
+ syncDoneValue ::= SEQUENCE {
+ cookie syncCookie OPTIONAL,
+ refreshDeletes BOOLEAN DEFAULT FALSE
+ }
+
+ The Sync Done Control is only applicable to the SearchResultDone
+ Message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga & Choi Experimental [Page 10]
+
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+2.5. Sync Info Message
+
+ The Sync Info Message is an LDAP Intermediate Response Message
+ [RFC4511] where responseName is the object identifier
+ 1.3.6.1.4.1.4203.1.9.1.4 and responseValue contains a BER-encoded
+ syncInfoValue. The criticality is FALSE (and hence absent).
+
+ syncInfoValue ::= CHOICE {
+ newcookie [0] syncCookie,
+ refreshDelete [1] SEQUENCE {
+ cookie syncCookie OPTIONAL,
+ refreshDone BOOLEAN DEFAULT TRUE
+ },
+ refreshPresent [2] SEQUENCE {
+ cookie syncCookie OPTIONAL,
+ refreshDone BOOLEAN DEFAULT TRUE
+ },
+ syncIdSet [3] SEQUENCE {
+ cookie syncCookie OPTIONAL,
+ refreshDeletes BOOLEAN DEFAULT FALSE,
+ syncUUIDs SET OF syncUUID
+ }
+ }
+
+2.6. Sync Result Codes
+
+ The following LDAP resultCode [RFC4511] is defined:
+
+ e-syncRefreshRequired (4096)
+
+3. Content Synchronization
+
+ The Sync Operation is invoked when the client sends a SearchRequest
+ Message with a Sync Request Control.
+
+ The absence of a cookie or an initialized synchronization state in a
+ cookie indicates a request for initial content, while the presence of
+ a cookie representing a state of a client copy indicates a request
+ for a content update. Synchronization Sessions are discussed in
+ Section 3.1. Content Determination is discussed in Section 3.2.
+
+ The mode is either refreshOnly or refreshAndPersist. The refreshOnly
+ and refreshAndPersist modes are discussed in Sections 3.3 and 3.4,
+ respectively. The refreshOnly mode consists only of a refresh stage,
+ while the refreshAndPersist mode consists of a refresh stage and a
+ subsequent persist stage.
+
+
+
+
+
+Zeilenga & Choi Experimental [Page 11]
+
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+3.1. Synchronization Session
+
+ A sequence of Sync Operations where the last cookie returned by the
+ server for one operation is provided by the client in the next
+ operation is said to belong to the same Synchronization Session.
+
+ The client MUST specify the same content-controlling parameters (see
+ Section 3.5) in each Search Request of the session. The client
+ SHOULD also issue each Sync request of a session under the same
+ authentication and authorization associations with equivalent
+ integrity and protections. If the server does not recognize the
+ request cookie or the request is made under different associations or
+ non-equivalent protections, the server SHALL return the initial
+ content as if no cookie had been provided or return an empty content
+ with the e-syncRefreshRequired LDAP result code. The decision
+ between the return of the initial content and the return of the empty
+ content with the e-syncRefreshRequired result code MAY be based on
+ reloadHint in the Sync Request Control from the client. If the
+ server recognizes the request cookie as representing empty or initial
+ synchronization state of the client copy, the server SHALL return the
+ initial content.
+
+ A Synchronization Session may span multiple LDAP sessions between the
+ client and the server. The client SHOULD issue each Sync request of
+ a session to the same server. (Note: Shadowing considerations are
+ discussed in Section 6.)
+
+3.2. Content Determination
+
+ The content to be provided is determined by parameters of the Search
+ Request, as described in [RFC4511], and possibly other controls. The
+ same content parameters SHOULD be used in each Sync request of a
+ session. If different content is requested and the server is
+ unwilling or unable to process the request, the server SHALL return
+ the initial content as if no cookie had been provided or return an
+ empty content with the e-syncRefreshRequired LDAP result code. The
+ decision between the return of the initial content and the return of
+ the empty content with the e-syncRefreshRequired result code MAY be
+ based on reloadHint in the Sync Request Control from the client.
+
+ The content may not necessarily include all entries or references
+ that would be returned by a normal search operation, nor, for those
+ entries included, all attributes returned by a normal search. When
+ the server is unwilling or unable to provide synchronization for any
+ attribute for a set of entries, the server MUST treat all filter
+ components matching against these attributes as Undefined and MUST
+ NOT return these attributes in SearchResultEntry responses.
+
+
+
+
+Zeilenga & Choi Experimental [Page 12]
+
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ Servers SHOULD support synchronization for all non-collective user-
+ application attributes for all entries.
+
+ The server may also return continuation references to other servers
+ or to itself. The latter is allowed as the server may partition the
+ entries it holds into separate synchronization contexts.
+
+ The client may chase all or some of these continuations, each as a
+ separate content synchronization session.
+
+3.3. refreshOnly Mode
+
+ A Sync request with mode refreshOnly and with no cookie is a poll for
+ initial content. A Sync request with mode refreshOnly and with a
+ cookie representing a synchronization state is a poll for content
+ update.
+
+3.3.1. Initial Content Poll
+
+ Upon receipt of the request, the server provides the initial content
+ using a set of zero or more SearchResultEntry and
+ SearchResultReference Messages followed by a SearchResultDone
+ Message.
+
+ Each SearchResultEntry Message SHALL include a Sync State Control of
+ state add, an entryUUID containing the entry's UUID, and no cookie.
+ Each SearchResultReference Message SHALL include a Sync State Control
+ of state add, an entryUUID containing the UUID associated with the
+ reference (normally the UUID of the associated named referral
+ [RFC3296] object), and no cookie. The SearchResultDone Message SHALL
+ include a Sync Done Control having refreshDeletes set to FALSE.
+
+ A resultCode value of success indicates that the operation
+ successfully completed. Otherwise, the result code indicates the
+ nature of the failure. The server may return e-syncRefreshRequired
+ result code on the initial content poll if it is safe to do so when
+ it is unable to perform the operation due to various reasons.
+ reloadHint is set to FALSE in the SearchRequest Message requesting
+ the initial content poll.
+
+ If the operation is successful, a cookie representing the
+ synchronization state of the current client copy SHOULD be returned
+ for use in subsequent Sync Operations.
+
+3.3.2. Content Update Poll
+
+ Upon receipt of the request, the server provides the content refresh
+ using a set of zero or more SearchResultEntry and
+
+
+
+Zeilenga & Choi Experimental [Page 13]
+
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ SearchResultReference Messages followed by a SearchResultDone
+ Message.
+
+ The server is REQUIRED to:
+
+ a) provide the sequence of messages necessary for eventual
+ convergence of the client's copy of the content to the server's
+ copy,
+
+ b) treat the request as an initial content request (e.g., ignore
+ the cookie or the synchronization state represented in the
+ cookie),
+
+ c) indicate that the incremental convergence is not possible by
+ returning e-syncRefreshRequired,
+
+ d) return a resultCode other than success or e-
+ syncRefreshRequired.
+
+ A Sync Operation may consist of a single present phase, a single
+ delete phase, or a present phase followed by a delete phase.
+
+ In each phase, for each entry or reference that has been added to the
+ content or been changed since the previous Sync Operation indicated
+ by the cookie, the server returns a SearchResultEntry or
+ SearchResultReference Message, respectively, each with a Sync State
+ Control consisting of state add, an entryUUID containing the UUID of
+ the entry or reference, and no cookie. Each SearchResultEntry
+ Message represents the current state of a changed entry. Each
+ SearchResultReference Message represents the current state of a
+ changed reference.
+
+ In the present phase, for each entry that has not been changed since
+ the previous Sync Operation, an empty SearchResultEntry is returned
+ whose objectName reflects the entry's current DN, whose attributes
+ field is empty, and whose Sync State Control consists of state
+ present, an entryUUID containing the UUID of the entry, and no
+ cookie. For each reference that has not been changed since the
+ previous Sync Operation, an empty SearchResultReference containing an
+ empty SEQUENCE OF LDAPURL is returned with a Sync State Control
+ consisting of state present, an entryUUID containing the UUID of the
+ entry, and no cookie. No messages are sent for entries or references
+ that are no longer in the content.
+
+ Multiple empty entries with a Sync State Control of state present
+ SHOULD be coalesced into one or more Sync Info Messages of syncIdSet
+ value with refreshDeletes set to FALSE. syncUUIDs contain a set of
+ UUIDs of the entries and references unchanged since the last Sync
+
+
+
+Zeilenga & Choi Experimental [Page 14]
+
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ Operation. syncUUIDs may be empty. The Sync Info Message of
+ syncIdSet may contain a cookie to represent the state of the content
+ after performing the synchronization of the entries in the set.
+
+ In the delete phase, for each entry no longer in the content, the
+ server returns a SearchResultEntry whose objectName reflects a past
+ DN of the entry or is empty, whose attributes field is empty, and
+ whose Sync State Control consists of state delete, an entryUUID
+ containing the UUID of the deleted entry, and no cookie. For each
+ reference no longer in the content, a SearchResultReference
+ containing an empty SEQUENCE OF LDAPURL is returned with a Sync State
+ Control consisting of state delete, an entryUUID containing the UUID
+ of the deleted reference, and no cookie.
+
+ Multiple empty entries with a Sync State Control of state delete
+ SHOULD be coalesced into one or more Sync Info Messages of syncIdSet
+ value with refreshDeletes set to TRUE. syncUUIDs contain a set of
+ UUIDs of the entries and references that have been deleted from the
+ content since the last Sync Operation. syncUUIDs may be empty. The
+ Sync Info Message of syncIdSet may contain a cookie to represent the
+ state of the content after performing the synchronization of the
+ entries in the set.
+
+ When a present phase is followed by a delete phase, the two phases
+ are delimited by a Sync Info Message containing syncInfoValue of
+ refreshPresent, which may contain a cookie representing the state
+ after completing the present phase. The refreshPresent contains
+ refreshDone, which is always FALSE in the refreshOnly mode of Sync
+ Operation because it is followed by a delete phase.
+
+ If a Sync Operation consists of a single phase, each phase and hence
+ the Sync Operation are marked as ended by a SearchResultDone Message
+ with Sync Done Control, which SHOULD contain a cookie representing
+ the state of the content after completing the Sync Operation. The
+ Sync Done Control contains refreshDeletes, which is set to FALSE for
+ the present phase and set to TRUE for the delete phase.
+
+ If a Sync Operation consists of a present phase followed by a delete
+ phase, the Sync Operation is marked as ended at the end of the delete
+ phase by a SearchResultDone Message with Sync Done Control, which
+ SHOULD contain a cookie representing the state of the content after
+ completing the Sync Operation. The Sync Done Control contains
+ refreshDeletes, which is set to TRUE.
+
+ The client can specify whether it prefers to receive an initial
+ content by supplying reloadHint of TRUE or to receive a e-
+ syncRefreshRequired resultCode by supplying reloadHint of FALSE
+ (hence absent), in the case that the server determines that it is
+
+
+
+Zeilenga & Choi Experimental [Page 15]
+
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ impossible or inefficient to achieve the eventual convergence by
+ continuing the current incremental synchronization thread.
+
+ A resultCode value of success indicates that the operation is
+ successfully completed. A resultCode value of e-syncRefreshRequired
+ indicates that a full or partial refresh is needed. Otherwise, the
+ result code indicates the nature of failure. A cookie is provided in
+ the Sync Done Control for use in subsequent Sync Operations for
+ incremental synchronization.
+
+3.4. refreshAndPersist Mode
+
+ A Sync request with mode refreshAndPersist asks for initial content
+ or content update (during the refresh stage) followed by change
+ notifications (during the persist stage).
+
+3.4.1. refresh Stage
+
+ The content refresh is provided as described in Section 3.3, except
+ that the successful completion of content refresh is indicated by
+ sending a Sync Info Message of refreshDelete or refreshPresent with a
+ refreshDone value set to TRUE instead of a SearchResultDone Message
+ with resultCode success. A cookie SHOULD be returned in the Sync
+ Info Message to represent the state of the content after finishing
+ the refresh stage of the Sync Operation.
+
+3.4.2. persist Stage
+
+ Change notifications are provided during the persist stage.
+
+ As updates are made to the DIT, the server notifies the client of
+ changes to the content. DIT updates may cause entries and references
+ to be added to the content, deleted from the content, or modified
+ within the content. DIT updates may also cause references to be
+ added, deleted, or modified within the content.
+
+ Where DIT updates cause an entry to be added to the content, the
+ server provides a SearchResultEntry Message that represents the entry
+ as it appears in the content. The message SHALL include a Sync State
+ Control with state of add, an entryUUID containing the entry's UUID,
+ and an optional cookie.
+
+ Where DIT updates cause a reference to be added to the content, the
+ server provides a SearchResultReference Message that represents the
+ reference in the content. The message SHALL include a Sync State
+ Control with state of add, an entryUUID containing the UUID
+ associated with the reference, and an optional cookie.
+
+
+
+
+Zeilenga & Choi Experimental [Page 16]
+
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ Where DIT updates cause an entry to be modified within the content,
+ the server provides a SearchResultEntry Message that represents the
+ entry as it appears in the content. The message SHALL include a Sync
+ State Control with state of modify, an entryUUID containing the
+ entry's UUID, and an optional cookie.
+
+ Where DIT updates cause a reference to be modified within the
+ content, the server provides a SearchResultReference Message that
+ represents the reference in the content. The message SHALL include a
+ Sync State Control with state of modify, an entryUUID containing the
+ UUID associated with the reference, and an optional cookie.
+
+ Where DIT updates cause an entry to be deleted from the content, the
+ server provides a SearchResultEntry Message with no attributes. The
+ message SHALL include a Sync State Control with state of delete, an
+ entryUUID containing the entry's UUID, and an optional cookie.
+
+ Where DIT updates cause a reference to be deleted from the content,
+ the server provides a SearchResultReference Message with an empty
+ SEQUENCE OF LDAPURL. The message SHALL include a Sync State Control
+ with state of delete, an entryUUID containing the UUID associated
+ with the reference, and an optional cookie.
+
+ Multiple empty entries with a Sync State Control of state delete
+ SHOULD be coalesced into one or more Sync Info Messages of syncIdSet
+ value with refreshDeletes set to TRUE. syncUUIDs contain a set of
+ UUIDs of the entries and references that have been deleted from the
+ content. The Sync Info Message of syncIdSet may contain a cookie to
+ represent the state of the content after performing the
+ synchronization of the entries in the set.
+
+ With each of these messages, the server may provide a new cookie to
+ be used in subsequent Sync Operations. Additionally, the server may
+ also return Sync Info Messages of choice newCookie to provide a new
+ cookie. The client SHOULD use the newest (last) cookie it received
+ from the server in subsequent Sync Operations.
+
+3.5. Search Request Parameters
+
+ As stated in Section 3.1, the client SHOULD specify the same
+ content-controlling parameters in each Search Request of the session.
+ All fields of the SearchRequest Message are considered content-
+ controlling parameters except for sizeLimit and timeLimit.
+
+
+
+
+
+
+
+
+Zeilenga & Choi Experimental [Page 17]
+
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+3.5.1. baseObject
+
+ As with the normal search operation, the refresh and persist stages
+ are not isolated from DIT changes. It is possible that the entry
+ referred to by the baseObject is deleted, renamed, or moved. It is
+ also possible that the alias object used in finding the entry
+ referred to by the baseObject is changed such that the baseObject
+ refers to a different entry.
+
+ If the DIT is updated during processing of the Sync Operation in a
+ manner that causes the baseObject no longer to refer to any entry or
+ in a manner that changes the entry the baseObject refers to, the
+ server SHALL return an appropriate non-success result code, such as
+ noSuchObject, aliasProblem, aliasDereferencingProblem, referral, or
+ e-syncRefreshRequired.
+
+3.5.2. derefAliases
+
+ This operation does not support alias dereferencing during searching.
+ The client SHALL specify neverDerefAliases or derefFindingBaseObj for
+ the SearchRequest derefAliases parameter. The server SHALL treat
+ other values (e.g., derefInSearching, derefAlways) as protocol
+ errors.
+
+3.5.3. sizeLimit
+
+ The sizeLimit applies only to entries (regardless of their state in
+ Sync State Control) returned during the refreshOnly operation or the
+ refresh stage of the refreshAndPersist operation.
+
+3.5.4. timeLimit
+
+ For a refreshOnly Sync Operation, the timeLimit applies to the whole
+ operation. For a refreshAndPersist operation, the timeLimit applies
+ only to the refresh stage including the generation of the Sync Info
+ Message with a refreshDone value of TRUE.
+
+3.5.5. filter
+
+ The client SHOULD avoid filter assertions that apply to the values of
+ the attributes likely to be considered by the server as ones holding
+ meta-information. See Section 4.
+
+3.6. objectName
+
+ The Sync Operation uses entryUUID values provided in the Sync State
+ Control as the primary keys to entries. The client MUST use these
+ entryUUIDs to correlate synchronization messages.
+
+
+
+Zeilenga & Choi Experimental [Page 18]
+
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ In some circumstances, the DN returned may not reflect the entry's
+ current DN. In particular, when the entry is being deleted from the
+ content, the server may provide an empty DN if the server does not
+ wish to disclose the entry's current DN (or, if deleted from the DIT,
+ the entry's last DN).
+
+ Also note that the entry's DN may be viewed as meta information (see
+ Section 4.1).
+
+3.7. Canceling the Sync Operation
+
+ Servers MUST implement the LDAP Cancel [RFC3909] Operation and
+ support cancellation of outstanding Sync Operations as described
+ here.
+
+ To cancel an outstanding Sync Operation, the client issues an LDAP
+ Cancel [RFC3909] Operation.
+
+ If at any time the server becomes unwilling or unable to continue
+ processing a Sync Operation, the server SHALL return a
+ SearchResultDone with a non-success resultCode indicating the reason
+ for the termination of the operation.
+
+ Whether the client or the server initiated the termination, the
+ server may provide a cookie in the Sync Done Control for use in
+ subsequent Sync Operations.
+
+3.8. Refresh Required
+
+ In order to achieve the eventually-convergent synchronization, the
+ server may terminate the Sync Operation in the refresh or persist
+ stages by returning an e-syncRefreshRequired resultCode to the
+ client. If no cookie is provided, a full refresh is needed. If a
+ cookie representing a synchronization state is provided in this
+ response, an incremental refresh is needed.
+
+ To obtain a full refresh, the client then issues a new
+ synchronization request with no cookie. To obtain an incremental
+ reload, the client issues a new synchronization with the provided
+ cookie.
+
+ The server may choose to provide a full copy in the refresh stage
+ (e.g., ignore the cookie or the synchronization state represented in
+ the cookie) instead of providing an incremental refresh in order to
+ achieve the eventual convergence.
+
+
+
+
+
+
+Zeilenga & Choi Experimental [Page 19]
+
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ The decision between the return of the initial content and the return
+ of the e-syncRefreshRequired result code may be based on reloadHint
+ in the Sync Request Control from the client.
+
+ In the case of persist stage Sync, the server returns the resultCode
+ of e-syncRefreshRequired to the client to indicate that the client
+ needs to issue a new Sync Operation in order to obtain a synchronized
+ copy of the content. If no cookie is provided, a full refresh is
+ needed. If a cookie representing a synchronization state is
+ provided, an incremental refresh is needed.
+
+ The server may also return e-syncRefreshRequired if it determines
+ that a refresh would be more efficient than sending all the messages
+ required for convergence.
+
+ Note that the client may receive one or more of SearchResultEntry,
+ SearchResultReference, and/or Sync Info Messages before it receives a
+ SearchResultDone Message with the e-syncRefreshRequired result code.
+
+3.9. Chattiness Considerations
+
+ The server MUST ensure that the number of entry messages generated to
+ refresh the client content does not exceed the number of entries
+ presently in the content. While there is no requirement for servers
+ to maintain history information, if the server has sufficient history
+ to allow it to reliably determine which entries in the prior client
+ copy are no longer present in the content and the number of such
+ entries is less than or equal to the number of unchanged entries, the
+ server SHOULD generate delete entry messages instead of present entry
+ messages (see Section 3.3.2).
+
+ When the amount of history information maintained in the server is
+ not enough for the clients to perform infrequent refreshOnly Sync
+ Operations, it is likely that the server has incomplete history
+ information (e.g., due to truncation) by the time those clients
+ connect again.
+
+ The server SHOULD NOT resort to full reload when the history
+ information is not enough to generate delete entry messages. The
+ server SHOULD generate either present entry messages only or present
+ entry messages followed by delete entry messages to bring the client
+ copy to the current state. In the latter case, the present entry
+ messages bring the client copy to a state covered by the history
+ information maintained in the server.
+
+ The server SHOULD maintain enough (current or historical) state
+ information (such as a context-wide last modify time stamp) to
+ determine if no changes were made in the context since the content
+
+
+
+Zeilenga & Choi Experimental [Page 20]
+
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ refresh was provided and, when no changes were made, generate zero
+ delete entry messages instead of present messages.
+
+ The server SHOULD NOT use the history information when its use does
+ not reduce the synchronization traffic or when its use can expose
+ sensitive information not allowed to be received by the client.
+
+ The server implementor should also consider chattiness issues that
+ span multiple Sync Operations of a session. As noted in Section 3.8,
+ the server may return e-syncRefreshRequired if it determines that a
+ reload would be more efficient than continuing under the current
+ operation. If reloadHint in the Sync Request is TRUE, the server may
+ initiate a reload without directing the client to request a reload.
+
+ The server SHOULD transfer a new cookie frequently to avoid having to
+ transfer information already provided to the client. Even where DIT
+ changes do not cause content synchronization changes to be
+ transferred, it may be advantageous to provide a new cookie using a
+ Sync Info Message. However, the server SHOULD avoid overloading the
+ client or network with Sync Info Messages.
+
+ During persist mode, the server SHOULD coalesce multiple outstanding
+ messages updating the same entry. The server MAY delay generation of
+ an entry update in anticipation of subsequent changes to that entry
+ that could be coalesced. The length of the delay should be long
+ enough to allow coalescing of update requests issued back to back but
+ short enough that the transient inconsistency induced by the delay is
+ corrected in a timely manner.
+
+ The server SHOULD use the syncIdSet Sync Info Message when there are
+ multiple delete or present messages to reduce the amount of
+ synchronization traffic.
+
+ Also note that there may be many clients interested in a particular
+ directory change, and that servers attempting to service all of these
+ at once may cause congestion on the network. The congestion issues
+ are magnified when the change requires a large transfer to each
+ interested client. Implementors and deployers of servers should take
+ steps to prevent and manage network congestion.
+
+3.10. Operation Multiplexing
+
+ The LDAP protocol model [RFC4511] allows operations to be multiplexed
+ over a single LDAP session. Clients SHOULD NOT maintain multiple
+ LDAP sessions with the same server. Servers SHOULD ensure that
+ responses from concurrently processed operations are interleaved
+ fairly.
+
+
+
+
+Zeilenga & Choi Experimental [Page 21]
+
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ Clients SHOULD combine Sync Operations whose result set is largely
+ overlapping. This avoids having to return multiple messages, once
+ for each overlapping session, for changes to entries in the overlap.
+
+ Clients SHOULD NOT combine Sync Operations whose result sets are
+ largely non-overlapping. This ensures that an event requiring an
+ e-syncRefreshRequired response can be limited to as few result sets
+ as possible.
+
+4. Meta Information Considerations
+
+4.1. Entry DN
+
+ As an entry's DN is constructed from its relative DN (RDN) and the
+ entry's parent's DN, it is often viewed as meta information.
+
+ While renaming or moving to a new superior causes the entry's DN to
+ change, that change SHOULD NOT, by itself, cause synchronization
+ messages to be sent for that entry. However, if the renaming or the
+ moving could cause the entry to be added or deleted from the content,
+ appropriate synchronization messages should be generated to indicate
+ this to the client.
+
+ When a server treats the entry's DN as meta information, the server
+ SHALL either
+
+ - evaluate all MatchingRuleAssertions [RFC4511] to TRUE if
+ matching a value of an attribute of the entry, otherwise
+ Undefined, or
+
+ - evaluate all MatchingRuleAssertion with dnAttributes of TRUE as
+ Undefined.
+
+ The latter choice is offered for ease of server implementation.
+
+4.2. Operational Attributes
+
+ Where values of an operational attribute are determined by values not
+ held as part of the entry it appears in, the operational attribute
+ SHOULD NOT support synchronization of that operational attribute.
+
+ For example, in servers that implement the X.501 subschema model
+ [X.501], servers should not support synchronization of the
+ subschemaSubentry attribute as its value is determined by values held
+ and administrated in subschema subentries.
+
+
+
+
+
+
+Zeilenga & Choi Experimental [Page 22]
+
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ As a counter example, servers that implement aliases [RFC4512][X.501]
+ can support synchronization of the aliasedObjectName attribute as its
+ values are held and administrated as part of the alias entries.
+
+ Servers SHOULD support synchronization of the following operational
+ attributes: createTimestamp, modifyTimestamp, creatorsName,
+ modifiersName [RFC4512]. Servers MAY support synchronization of
+ other operational attributes.
+
+4.3. Collective Attributes
+
+ A collective attribute is "a user attribute whose values are the same
+ for each member of an entry collection" [X.501]. Use of collective
+ attributes in LDAP is discussed in [RFC3671].
+
+ Modification of a collective attribute generally affects the content
+ of multiple entries, which are the members of the collection. It is
+ inefficient to include values of collective attributes visible in
+ entries of the collection, as a single modification of a collective
+ attribute requires transmission of multiple SearchResultEntry (one
+ for each entry of the collection that the modification affected).
+
+ Servers SHOULD NOT synchronize collective attributes appearing in
+ entries of any collection. Servers MAY support synchronization of
+ collective attributes appearing in collective attribute subentries.
+
+4.4. Access and Other Administrative Controls
+
+ Entries are commonly subject to access and other administrative
+ Controls. While portions of the policy information governing a
+ particular entry may be held in the entry, policy information is
+ often held elsewhere (in superior entries, in subentries, in the root
+ DSE, in configuration files, etc.). Because of this, changes to
+ policy information make it difficult to ensure eventual convergence
+ during incremental synchronization.
+
+ Where it is impractical or infeasible to generate content changes
+ resulting from a change to policy information, servers may opt to
+ return e-syncRefreshRequired or to treat the Sync Operation as an
+ initial content request (e.g., ignore the cookie or the
+ synchronization state represented in the cookie).
+
+5. Interaction with Other Controls
+
+ The Sync Operation may be used with:
+
+ - ManageDsaIT Control [RFC3296]
+
+
+
+
+Zeilenga & Choi Experimental [Page 23]
+
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ - Subentries Control [RFC3672]
+
+ as described below. The Sync Operation may be used with other LDAP
+ extensions as detailed in other documents.
+
+5.1. ManageDsaIT Control
+
+ The ManageDsaIT Control [RFC3296] indicates that the operation acts
+ upon the DSA Information Tree and causes referral and other special
+ entries to be treated as object entries with respect to the
+ operation.
+
+5.2. Subentries Control
+
+ The Subentries Control is used with the search operation "to control
+ the visibility of entries and subentries which are within scope"
+ [RFC3672]. When used with the Sync Operation, the subentries control
+ and other factors (search scope, filter, etc.) are used to determine
+ whether an entry or subentry appears in the content.
+
+6. Shadowing Considerations
+
+ As noted in [RFC4511], some servers may hold shadow copies of entries
+ that can be used to answer search and comparison queries. Such
+ servers may also support content synchronization requests. This
+ section discusses considerations for implementors and deployers for
+ the implementation and deployment of the Sync operation in shadowed
+ directories.
+
+ While a client may know of multiple servers that are equally capable
+ of being used to obtain particular directory content from, a client
+ SHOULD NOT assume that each of these servers is equally capable of
+ continuing a content synchronization session. As stated in Section
+ 3.1, the client SHOULD issue each Sync request of a Sync session to
+ the same server.
+
+ However, through domain naming or IP address redirection or other
+ techniques, multiple physical servers can be made to appear as one
+ logical server to a client. Only servers that are equally capable in
+ regards to their support for the Sync operation and that hold equally
+ complete copies of the entries should be made to appear as one
+ logical server. In particular, each physical server acting as one
+ logical server SHOULD be equally capable of continuing a content
+ synchronization based upon cookies provided by any of the other
+ physical servers without requiring a full reload. Because there is
+ no standard LDAP shadowing mechanism, the specification of how to
+ independently implement equally capable servers (as well as the
+ precise definition of "equally capable") is left to future documents.
+
+
+
+Zeilenga & Choi Experimental [Page 24]
+
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ Note that it may be difficult for the server to reliably determine
+ what content was provided to the client by another server, especially
+ in the shadowing environments that allow shadowing events to be
+ coalesced. For these servers, the use of the delete phase discussed
+ in Section 3.3.2 may not be applicable.
+
+7. Security Considerations
+
+ In order to maintain a synchronized copy of the content, a client is
+ to delete information from its copy of the content as described
+ above. However, the client may maintain knowledge of information
+ disclosed to it by the server separate from its copy of the content
+ used for synchronization. Management of this knowledge is beyond the
+ scope of this document. Servers should be careful not to disclose
+ information for content the client is not authorized to have
+ knowledge of and/or about.
+
+ While the information provided by a series of refreshOnly Sync
+ Operations is similar to that provided by a series of Search
+ Operations, persist stage may disclose additional information. A
+ client may be able to discern information about the particular
+ sequence of update operations that caused content change.
+
+ Implementors should take precautions against malicious cookie
+ content, including malformed cookies or valid cookies used with
+ different security associations and/or protections in an attempt to
+ obtain unauthorized access to information. Servers may include a
+ digital signature in the cookie to detect tampering.
+
+ The operation may be the target of direct denial-of-service attacks.
+ Implementors should provide safeguards to ensure the operation is not
+ abused. Servers may place access control or other restrictions upon
+ the use of this operation.
+
+ Note that even small updates to the directory may cause a significant
+ amount of traffic to be generated to clients using this operation. A
+ user could abuse its update privileges to mount an indirect denial of
+ service to these clients, other clients, and/or portions of the
+ network. Servers should provide safeguards to ensure that update
+ operations are not abused.
+
+ Implementors of this (or any) LDAP extension should be familiar with
+ general LDAP security considerations [RFC4510].
+
+
+
+
+
+
+
+
+Zeilenga & Choi Experimental [Page 25]
+
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+8. IANA Considerations
+
+ Registration of the following values have been completed by the IANA
+ [RFC4520].
+
+8.1. Object Identifier
+
+ The OID arc 1.3.6.1.4.1.4203.1.9.1 was assigned [ASSIGN] by the
+ OpenLDAP Foundation, under its IANA-assigned private enterprise
+ allocation [PRIVATE], for use in this specification.
+
+8.2. LDAP Protocol Mechanism
+
+ The IANA has registered the LDAP Protocol Mechanism described in this
+ document.
+
+ Subject: Request for LDAP Protocol Mechanism Registration
+ Object Identifier: 1.3.6.1.4.1.4203.1.9.1.1
+ Description: LDAP Content Synchronization Control
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@openldap.org>
+ Usage: Control
+ Specification: RFC 4533
+ Author/Change Controller: Kurt D. Zeilenga, Jong Hyuk Choi
+ Comments: none
+
+8.3. LDAP Result Codes
+
+ The IANA has registered the LDAP Result Code described in this
+ document.
+
+ Subject: LDAP Result Code Registration
+ Person & email address to contact for further information:
+ Kurt Zeilenga <kurt@OpenLDAP.org>
+ Result Code Name: e-syncRefreshRequired (4096)
+ Specification: RFC 4533
+ Author/Change Controller: Kurt D. Zeilenga, Jong Hyuk Choi
+ Comments: none
+
+9. Acknowledgements
+
+ This document borrows significantly from the LDAP Client Update
+ Protocol [RFC3928], a product of the IETF LDUP working group. This
+ document also benefited from Persistent Search [PSEARCH], Triggered
+ Search [TSEARCH], and Directory Synchronization [DIRSYNC] works.
+ This document also borrows from "Lightweight Directory Access
+ Protocol (v3)" [RFC2251].
+
+
+
+
+Zeilenga & Choi Experimental [Page 26]
+
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+10. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3296] Zeilenga, K., "Named Subordinate References in
+ Lightweight Directory Access Protocol (LDAP)
+ Directories", RFC 3296, July 2002.
+
+ [RFC3671] Zeilenga, K., "Collective Attributes in the Lightweight
+ Directory Access Protocol (LDAP)", RFC 3671, December
+ 2003.
+
+ [RFC3672] Zeilenga, K., "Subentries in the Lightweight Directory
+ Access Protocol (LDAP)", RFC 3672, December 2003.
+
+ [RFC3909] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP) Cancel Operation", RFC 3909, October 2004.
+
+ [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): Technical Specification Road Map", RFC 4510, June
+ 2006.
+
+ [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
+ Protocol (LDAP): The Protocol", RFC 4511, June 2006.
+
+ [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Directory Information Models", RFC 4512, June
+ 2006.
+
+ [RFC4530] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP) entryUUID Operational Attribute", RFC 4530, June
+ 2006.
+
+ [UUID] International Organization for Standardization (ISO),
+ "Information technology - Open Systems Interconnection -
+ Remote Procedure Call", ISO/IEC 11578:1996
+
+ [X.501] International Telecommunication Union - Telecommunication
+ Standardization Sector, "The Directory -- Models,"
+ X.501(1993) (also ISO/IEC 9594-2:1994).
+
+ [X.680] International Telecommunication Union - Telecommunication
+ Standardization Sector, "Abstract Syntax Notation One
+ (ASN.1) - Specification of Basic Notation", X.680(1997)
+ (also ISO/IEC 8824-1:1998).
+
+
+
+
+
+Zeilenga & Choi Experimental [Page 27]
+
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ [X.690] International Telecommunication Union - Telecommunication
+ Standardization Sector, "Specification of ASN.1 encoding
+ rules: Basic Encoding Rules (BER), Canonical Encoding
+ Rules (CER), and Distinguished Encoding Rules (DER)",
+ X.690(1997) (also ISO/IEC 8825-1:1998).
+
+11. Informative References
+
+ [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC3928] Megginson, R., Ed., Smith, M., Natkovich, O., and J.
+ Parham, "Lightweight Directory Access Protocol (LDAP)
+ Client Update Protocol (LCUP)", RFC 3928, October 2004.
+
+ [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
+
+ [PRIVATE] IANA, "Private Enterprise Numbers",
+ http://www.iana.org/assignments/enterprise-numbers.
+
+ [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
+ http://www.openldap.org/foundation/oid-delegate.txt.
+
+ [X.500] International Telecommunication Union - Telecommunication
+ Standardization Sector, "The Directory -- Overview of
+ concepts, models and services," X.500(1993) (also ISO/IEC
+ 9594-1:1994).
+
+ [X.525] International Telecommunication Union - Telecommunication
+ Standardization Sector, "The Directory: Replication",
+ X.525(1993).
+
+ [DIRSYNC] Armijo, M., "Microsoft LDAP Control for Directory
+ Synchronization", Work in Progress.
+
+ [PSEARCH] Smith, M., et al., "Persistent Search: A Simple LDAP
+ Change Notification Mechanism", Work in Progress.
+
+ [TSEARCH] Wahl, M., "LDAPv3 Triggered Search Control", Work in
+ Progress.
+
+
+
+
+
+
+
+
+
+Zeilenga & Choi Experimental [Page 28]
+
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+Appendix A. CSN-based Implementation Considerations
+
+ This appendix is provided for informational purposes only; it is not
+ a normative part of the LDAP Content Synchronization Operation's
+ technical specification.
+
+ This appendix discusses LDAP Content Synchronization Operation server
+ implementation considerations associated with Change Sequence Number
+ based approaches.
+
+ Change Sequence Number based approaches are targeted for use in
+ servers that do not maintain history information (e.g., change logs,
+ state snapshots) about changes made to the Directory and hence, must
+ rely on current directory state and minimal synchronization state
+ information embedded in Sync Cookie. Servers that maintain history
+ information should consider other approaches that exploit the history
+ information.
+
+ A Change Sequence Number is effectively a time stamp that has
+ sufficient granularity to ensure that the precedence relationship in
+ time of two updates to the same object can be determined. Change
+ Sequence Numbers are not to be confused with Commit Sequence Numbers
+ or Commit Log Record Numbers. A Commit Sequence Number allows one to
+ determine how two commits (to the same object or different objects)
+ relate to each other in time. A Change Sequence Number associated
+ with different entries may be committed out of order. In the
+ remainder of this Appendix, the term CSN refers to a Change Sequence
+ Number.
+
+ In these approaches, the server not only maintains a CSN for each
+ directory entry (the entry CSN) but also maintains a value that we
+ will call the context CSN. The context CSN is the greatest committed
+ entry CSN that is not greater than any outstanding (uncommitted)
+ entry CSNs for all entries in a directory context. The values of
+ context CSN are used in syncCookie values as synchronization state
+ indicators.
+
+ As search operations are not isolated from individual directory
+ update operations and individual update operations cannot be assumed
+ to be serialized, one cannot assume that the returned content
+ incorporates each relevant change whose change sequence number is
+ less than or equal to the greatest entry CSN in the content. The
+ content incorporates all the relevant changes whose change sequence
+ numbers are less than or equal to context CSN before search
+ processing. The content may also incorporate any subset of the
+ changes whose change sequence number is greater than context CSN
+ before search processing but less than or equal to the context CSN
+ after search processing. The content does not incorporate any of the
+
+
+
+Zeilenga & Choi Experimental [Page 29]
+
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+ changes whose CSN is greater than the context CSN after search
+ processing.
+
+ A simple server implementation could use the value of the context CSN
+ before search processing to indicate state. Such an implementation
+ would embed this value into each SyncCookie returned. We'll call
+ this the cookie CSN. When a refresh was requested, the server would
+ simply generate "update" messages for all entries in the content
+ whose CSN is greater than the supplied cookie CSN and generate
+ "present" messages for all other entries in the content. However, if
+ the current context CSN is the same as the cookie CSN, the server
+ should instead generate zero "updates" and zero "delete" messages and
+ indicate a refreshDeletes of TRUE, as the directory has not changed.
+
+ The implementation should also consider the impact of changes to meta
+ information, such as access controls, that affect content
+ determination. One approach is for the server to maintain a
+ context-wide meta information CSN or meta CSN. This meta CSN would
+ be updated whenever meta information affecting content determination
+ was changed. If the value of the meta CSN is greater than the cookie
+ CSN, the server should ignore the cookie and treat the request as an
+ initial request for content.
+
+ Additionally, servers may want to consider maintaining some per-
+ session history information to reduce the number of messages needed
+ to be transferred during incremental refreshes. Specifically, a
+ server could record information about entries as they leave the scope
+ of a disconnected sync session and later use this information to
+ generate delete messages instead of present messages.
+
+ When the history information is truncated, the CSN of the latest
+ truncated history information entry may be recorded as the truncated
+ CSN of the history information. The truncated CSN may be used to
+ determine whether a client copy can be covered by the history
+ information by comparing it to the synchronization state contained in
+ the cookie supplied by the client.
+
+ When there is a large number of sessions, it may make sense to
+ maintain such history only for the selected clients. Also, servers
+ taking this approach need to consider resource consumption issues to
+ ensure reasonable server operation and to protect against abuse. It
+ may be appropriate to restrict this mode of operation by policy.
+
+
+
+
+
+
+
+
+
+Zeilenga & Choi Experimental [Page 30]
+
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+Authors' Addresses
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+
+ EMail: Kurt@OpenLDAP.org
+
+
+ Jong Hyuk Choi
+ IBM Corporation
+
+ EMail: jongchoi@us.ibm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga & Choi Experimental [Page 31]
+
+RFC 4533 LDAP Content Synchronization Operation June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78 and at www.rfc-editor.org/copyright.html, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga & Choi Experimental [Page 32]
+
diff --git a/include/avl.h b/include/avl.h
index 05315377c0544e0ded177b7db212957bde92811b..7b1bafb14e7bd52cb020b37aabf6190f715188c5 100644
--- a/include/avl.h
+++ b/include/avl.h
@@ -134,6 +134,9 @@ tavl_find LDAP_P((Avlnode *, const void*, AVL_CMP));
LDAP_AVL_F( Avlnode* )
tavl_find2 LDAP_P((Avlnode *, const void*, AVL_CMP));
+LDAP_AVL_F( Avlnode* )
+tavl_find3 LDAP_P((Avlnode *, const void*, AVL_CMP, int *ret));
+
#define TAVL_DIR_LEFT 0
#define TAVL_DIR_RIGHT 1
diff --git a/include/ldap.h b/include/ldap.h
index c567d6adcc0389b41f205d4b6d12286f1bf4dc33..ad7d6966f12fec02a163b693117c4c1c9eadadc5 100644
--- a/include/ldap.h
+++ b/include/ldap.h
@@ -76,7 +76,7 @@ LDAP_BEGIN_DECL
#define LDAP_ALL_USER_ATTRIBUTES "*"
#define LDAP_ALL_OPERATIONAL_ATTRIBUTES "+" /* RFC 3673 */
-/* RFC 2251: maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- */
+/* RFC 4511: maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- */
#define LDAP_MAXINT (2147483647)
/*
@@ -124,7 +124,7 @@ LDAP_BEGIN_DECL
/* OpenLDAP TLS options */
#define LDAP_OPT_X_TLS 0x6000
-#define LDAP_OPT_X_TLS_CTX 0x6001 /* SSL CTX */
+#define LDAP_OPT_X_TLS_CTX 0x6001 /* OpenSSL CTX */
#define LDAP_OPT_X_TLS_CACERTFILE 0x6002
#define LDAP_OPT_X_TLS_CACERTDIR 0x6003
#define LDAP_OPT_X_TLS_CERTFILE 0x6004
@@ -212,9 +212,9 @@ typedef struct ldapcontrol {
#define LDAP_CONTROL_VALUESRETURNFILTER "1.2.826.0.1.3344810.2.3"/* RFC 3876 */
-#define LDAP_CONTROL_ASSERT "1.3.6.1.1.12" /* RFC TBD */
-#define LDAP_CONTROL_PRE_READ "1.3.6.1.1.13.1" /* RFC TBD */
-#define LDAP_CONTROL_POST_READ "1.3.6.1.1.13.2" /* RFC TBD */
+#define LDAP_CONTROL_ASSERT "1.3.6.1.1.12" /* RFC 4528 */
+#define LDAP_CONTROL_PRE_READ "1.3.6.1.1.13.1" /* RFC 4527 */
+#define LDAP_CONTROL_POST_READ "1.3.6.1.1.13.2" /* RFC 4527 */
/* standard track - not implemented in slapd(8) */
#define LDAP_CONTROL_SORTREQUEST "1.2.840.113556.1.4.473" /* RFC 2891 */
@@ -223,7 +223,7 @@ typedef struct ldapcontrol {
/* non-standard track controls */
#define LDAP_CONTROL_PAGEDRESULTS "1.2.840.113556.1.4.319" /* RFC 2696 */
-/* LDAP Sync -- draft-zeilenga-ldup-sync *//* RFC TBD */
+/* LDAP Content Synchronization Operation -- RFC 4533 */
#define LDAP_SYNC_OID "1.3.6.1.4.1.4203.1.9.1"
#define LDAP_CONTROL_SYNC LDAP_SYNC_OID ".1"
#define LDAP_CONTROL_SYNC_STATE LDAP_SYNC_OID ".2"
@@ -313,11 +313,11 @@ typedef struct ldapcontrol {
/* LDAP Unsolicited Notifications */
-#define LDAP_NOTICE_OF_DISCONNECTION "1.3.6.1.4.1.1466.20036" /* RFC 2251 */
+#define LDAP_NOTICE_OF_DISCONNECTION "1.3.6.1.4.1.1466.20036" /* RFC 4511 */
#define LDAP_NOTICE_DISCONNECT LDAP_NOTICE_OF_DISCONNECTION
/* LDAP Extended Operations */
-#define LDAP_EXOP_START_TLS "1.3.6.1.4.1.1466.20037" /* RFC 2830 */
+#define LDAP_EXOP_START_TLS "1.3.6.1.4.1.1466.20037" /* RFC 4511 */
#define LDAP_EXOP_MODIFY_PASSWD "1.3.6.1.4.1.4203.1.11.1" /* RFC 3062 */
#define LDAP_TAG_EXOP_MODIFY_PASSWD_ID ((ber_tag_t) 0x80U)
@@ -325,7 +325,7 @@ typedef struct ldapcontrol {
#define LDAP_TAG_EXOP_MODIFY_PASSWD_NEW ((ber_tag_t) 0x82U)
#define LDAP_TAG_EXOP_MODIFY_PASSWD_GEN ((ber_tag_t) 0x80U)
-#define LDAP_EXOP_CANCEL "1.3.6.1.1.8" /* RFC 3909 */
+#define LDAP_EXOP_CANCEL "1.3.6.1.1.8" /* RFC 3909 */
#define LDAP_EXOP_X_CANCEL LDAP_EXOP_CANCEL
#define LDAP_EXOP_REFRESH "1.3.6.1.4.1.1466.101.119.1" /* RFC 2589 */
@@ -333,12 +333,12 @@ typedef struct ldapcontrol {
#define LDAP_TAG_EXOP_REFRESH_REQ_TTL ((ber_tag_t) 0x81U)
#define LDAP_TAG_EXOP_REFRESH_RES_TTL ((ber_tag_t) 0x80U)
-#define LDAP_EXOP_WHO_AM_I "1.3.6.1.4.1.4203.1.11.3"
+#define LDAP_EXOP_WHO_AM_I "1.3.6.1.4.1.4203.1.11.3" /* RFC 4532 */
#define LDAP_EXOP_X_WHO_AM_I LDAP_EXOP_WHO_AM_I
/* various works in progress */
#ifdef LDAP_DEVEL
-#define LDAP_EXOP_X_TURN "1.3.6.1.4.1.4203.666.6.4"
+#define LDAP_EXOP_X_TURN "1.3.6.1.4.1.4203.666.6.4" /* RFC 4531 */
#endif
/* LDAP Distributed Procedures <draft-sermersheim-ldap-distproc> */
@@ -888,9 +888,9 @@ ldap_abandon_ext LDAP_P((
LDAPControl **serverctrls,
LDAPControl **clientctrls ));
-#if LDAP_DEPRECATED
+#if LDAP_DEPRECATED
LDAP_F( int )
-ldap_abandon LDAP_P(( /* deprecated */
+ldap_abandon LDAP_P(( /* deprecated, use ldap_abandon_ext */
LDAP *ld,
int msgid ));
#endif
@@ -917,13 +917,13 @@ ldap_add_ext_s LDAP_P((
#if LDAP_DEPRECATED
LDAP_F( int )
-ldap_add LDAP_P(( /* deprecated */
+ldap_add LDAP_P(( /* deprecated, use ldap_add_ext */
LDAP *ld,
LDAP_CONST char *dn,
LDAPMod **attrs ));
LDAP_F( int )
-ldap_add_s LDAP_P(( /* deprecated */
+ldap_add_s LDAP_P(( /* deprecated, use ldap_add_ext_s */
LDAP *ld,
LDAP_CONST char *dn,
LDAPMod **attrs ));
@@ -996,14 +996,14 @@ ldap_parse_sasl_bind_result LDAP_P((
* (deprecated)
*/
LDAP_F( int )
-ldap_bind LDAP_P(( /* deprecated */
+ldap_bind LDAP_P(( /* deprecated, use ldap_sasl_bind */
LDAP *ld,
LDAP_CONST char *who,
LDAP_CONST char *passwd,
int authmethod ));
LDAP_F( int )
-ldap_bind_s LDAP_P(( /* deprecated */
+ldap_bind_s LDAP_P(( /* deprecated, use ldap_sasl_bind_s */
LDAP *ld,
LDAP_CONST char *who,
LDAP_CONST char *cred,
@@ -1013,13 +1013,13 @@ ldap_bind_s LDAP_P(( /* deprecated */
* in sbind.c:
*/
LDAP_F( int )
-ldap_simple_bind LDAP_P(( /* deprecated */
+ldap_simple_bind LDAP_P(( /* deprecated, use ldap_sasl_bind */
LDAP *ld,
LDAP_CONST char *who,
LDAP_CONST char *passwd ));
LDAP_F( int )
-ldap_simple_bind_s LDAP_P(( /* deprecated */
+ldap_simple_bind_s LDAP_P(( /* deprecated, use ldap_sasl_bind_s */
LDAP *ld,
LDAP_CONST char *who,
LDAP_CONST char *passwd ));
@@ -1027,7 +1027,7 @@ ldap_simple_bind_s LDAP_P(( /* deprecated */
/*
* in kbind.c:
- * (deprecated)
+ * (deprecated - use SASL instead)
*/
LDAP_F( int )
ldap_kerberos_bind_s LDAP_P(( /* deprecated */
@@ -1080,14 +1080,14 @@ ldap_compare_ext_s LDAP_P((
#if LDAP_DEPRECATED
LDAP_F( int )
-ldap_compare LDAP_P(( /* deprecated */
+ldap_compare LDAP_P(( /* deprecated, use ldap_compare_ext */
LDAP *ld,
LDAP_CONST char *dn,
LDAP_CONST char *attr,
LDAP_CONST char *value ));
LDAP_F( int )
-ldap_compare_s LDAP_P(( /* deprecated */
+ldap_compare_s LDAP_P(( /* deprecated, use ldap_compare_ext_s */
LDAP *ld,
LDAP_CONST char *dn,
LDAP_CONST char *attr,
@@ -1115,12 +1115,12 @@ ldap_delete_ext_s LDAP_P((
#if LDAP_DEPRECATED
LDAP_F( int )
-ldap_delete LDAP_P(( /* deprecated */
+ldap_delete LDAP_P(( /* deprecated, use ldap_delete_ext */
LDAP *ld,
LDAP_CONST char *dn ));
LDAP_F( int )
-ldap_delete_s LDAP_P(( /* deprecated */
+ldap_delete_s LDAP_P(( /* deprecated, use ldap_delete_ext_s */
LDAP *ld,
LDAP_CONST char *dn ));
#endif
@@ -1146,13 +1146,13 @@ ldap_err2string LDAP_P((
#if LDAP_DEPRECATED
LDAP_F( int )
-ldap_result2error LDAP_P(( /* deprecated */
+ldap_result2error LDAP_P(( /* deprecated, use ldap_parse_result */
LDAP *ld,
LDAPMessage *r,
int freeit ));
LDAP_F( void )
-ldap_perror LDAP_P(( /* deprecated */
+ldap_perror LDAP_P(( /* deprecated, use ldap_err2string */
LDAP *ld,
LDAP_CONST char *s ));
#endif
@@ -1180,13 +1180,13 @@ ldap_modify_ext_s LDAP_P((
#if LDAP_DEPRECATED
LDAP_F( int )
-ldap_modify LDAP_P(( /* deprecated */
+ldap_modify LDAP_P(( /* deprecated, use ldap_modify_ext */
LDAP *ld,
LDAP_CONST char *dn,
LDAPMod **mods ));
LDAP_F( int )
-ldap_modify_s LDAP_P(( /* deprecated */
+ldap_modify_s LDAP_P(( /* deprecated, use ldap_modify_ext_s */
LDAP *ld,
LDAP_CONST char *dn,
LDAPMod **mods ));
@@ -1219,7 +1219,7 @@ ldap_rename_s LDAP_P((
#if LDAP_DEPRECATED
LDAP_F( int )
-ldap_rename2 LDAP_P(( /* deprecated */
+ldap_rename2 LDAP_P(( /* deprecated, use ldap_rename */
LDAP *ld,
LDAP_CONST char *dn,
LDAP_CONST char *newrdn,
@@ -1227,7 +1227,7 @@ ldap_rename2 LDAP_P(( /* deprecated */
int deleteoldrdn ));
LDAP_F( int )
-ldap_rename2_s LDAP_P(( /* deprecated */
+ldap_rename2_s LDAP_P(( /* deprecated, use ldap_rename_s */
LDAP *ld,
LDAP_CONST char *dn,
LDAP_CONST char *newrdn,
@@ -1235,26 +1235,26 @@ ldap_rename2_s LDAP_P(( /* deprecated */
int deleteoldrdn ));
LDAP_F( int )
-ldap_modrdn LDAP_P(( /* deprecated */
+ldap_modrdn LDAP_P(( /* deprecated, use ldap_rename */
LDAP *ld,
LDAP_CONST char *dn,
LDAP_CONST char *newrdn ));
LDAP_F( int )
-ldap_modrdn_s LDAP_P(( /* deprecated */
+ldap_modrdn_s LDAP_P(( /* deprecated, use ldap_rename_s */
LDAP *ld,
LDAP_CONST char *dn,
LDAP_CONST char *newrdn ));
LDAP_F( int )
-ldap_modrdn2 LDAP_P(( /* deprecated */
+ldap_modrdn2 LDAP_P(( /* deprecated, use ldap_rename */
LDAP *ld,
LDAP_CONST char *dn,
LDAP_CONST char *newrdn,
int deleteoldrdn ));
LDAP_F( int )
-ldap_modrdn2_s LDAP_P(( /* deprecated */
+ldap_modrdn2_s LDAP_P(( /* deprecated, use ldap_rename_s */
LDAP *ld,
LDAP_CONST char *dn,
LDAP_CONST char *newrdn,
@@ -1267,12 +1267,12 @@ ldap_modrdn2_s LDAP_P(( /* deprecated */
*/
#if LDAP_DEPRECATED
LDAP_F( LDAP * )
-ldap_init LDAP_P(( /* deprecated */
+ldap_init LDAP_P(( /* deprecated, use ldap_create or ldap_initialize */
LDAP_CONST char *host,
int port ));
LDAP_F( LDAP * )
-ldap_open LDAP_P(( /* deprecated */
+ldap_open LDAP_P(( /* deprecated, use ldap_create or ldap_initialize */
LDAP_CONST char *host,
int port ));
#endif
@@ -1496,16 +1496,16 @@ ldap_dn_normalize LDAP_P((
char **out, unsigned oflags ));
LDAP_F( char * )
-ldap_dn2ufn LDAP_P(( /* deprecated */
+ldap_dn2ufn LDAP_P(( /* deprecated, use ldap_str2dn/dn2str */
LDAP_CONST char *dn ));
LDAP_F( char ** )
-ldap_explode_dn LDAP_P(( /* deprecated */
+ldap_explode_dn LDAP_P(( /* deprecated, ldap_str2dn */
LDAP_CONST char *dn,
int notypes ));
LDAP_F( char ** )
-ldap_explode_rdn LDAP_P(( /* deprecated */
+ldap_explode_rdn LDAP_P(( /* deprecated, ldap_str2rdn */
LDAP_CONST char *rdn,
int notypes ));
@@ -1517,13 +1517,16 @@ ldap_X509dn2bv LDAP_P(( void *x509_name, struct berval *dn,
LDAPDN_rewrite_func *func, unsigned flags ));
LDAP_F( char * )
-ldap_dn2dcedn LDAP_P(( LDAP_CONST char *dn )); /* deprecated */
+ldap_dn2dcedn LDAP_P(( /* deprecated, ldap_str2dn/dn2str */
+ LDAP_CONST char *dn ));
LDAP_F( char * )
-ldap_dcedn2dn LDAP_P(( LDAP_CONST char *dce )); /* deprecated */
+ldap_dcedn2dn LDAP_P(( /* deprecated, ldap_str2dn/dn2str */
+ LDAP_CONST char *dce ));
LDAP_F( char * )
-ldap_dn2ad_canonical LDAP_P(( LDAP_CONST char *dn )); /* deprecated */
+ldap_dn2ad_canonical LDAP_P(( /* deprecated, ldap_str2dn/dn2str */
+ LDAP_CONST char *dn ));
LDAP_F( int )
ldap_get_dn_ber LDAP_P((
@@ -1569,17 +1572,17 @@ ldap_value_free_len LDAP_P((
#if LDAP_DEPRECATED
LDAP_F( char ** )
-ldap_get_values LDAP_P(( /* deprecated */
+ldap_get_values LDAP_P(( /* deprecated, use ldap_get_values_len */
LDAP *ld,
LDAPMessage *entry,
LDAP_CONST char *target ));
LDAP_F( int )
-ldap_count_values LDAP_P(( /* deprecated */
+ldap_count_values LDAP_P(( /* deprecated, use ldap_count_values_len */
char **vals ));
LDAP_F( void )
-ldap_value_free LDAP_P(( /* deprecated */
+ldap_value_free LDAP_P(( /* deprecated, use ldap_values_free_len */
char **vals ));
#endif
@@ -1650,7 +1653,7 @@ ldap_search_ext_s LDAP_P((
#if LDAP_DEPRECATED
LDAP_F( int )
-ldap_search LDAP_P(( /* deprecated */
+ldap_search LDAP_P(( /* deprecated, use ldap_search_ext */
LDAP *ld,
LDAP_CONST char *base,
int scope,
@@ -1659,7 +1662,7 @@ ldap_search LDAP_P(( /* deprecated */
int attrsonly ));
LDAP_F( int )
-ldap_search_s LDAP_P(( /* deprecated */
+ldap_search_s LDAP_P(( /* deprecated, use ldap_search_ext_s */
LDAP *ld,
LDAP_CONST char *base,
int scope,
@@ -1669,7 +1672,7 @@ ldap_search_s LDAP_P(( /* deprecated */
LDAPMessage **res ));
LDAP_F( int )
-ldap_search_st LDAP_P(( /* deprecated */
+ldap_search_st LDAP_P(( /* deprecated, use ldap_search_ext_s */
LDAP *ld,
LDAP_CONST char *base,
int scope,
@@ -1697,11 +1700,11 @@ ldap_unbind_ext_s LDAP_P((
#if LDAP_DEPRECATED
LDAP_F( int )
-ldap_unbind LDAP_P(( /* deprecated */
+ldap_unbind LDAP_P(( /* deprecated, use ldap_unbind_ext */
LDAP *ld ));
LDAP_F( int )
-ldap_unbind_s LDAP_P(( /* deprecated */
+ldap_unbind_s LDAP_P(( /* deprecated, use ldap_unbind_ext_s */
LDAP *ld ));
#endif
@@ -1751,7 +1754,7 @@ ldap_mods_free LDAP_P((
#if LDAP_DEPRECATED
/*
- * in sort.c (deprecated)
+ * in sort.c (deprecated, use custom code instead)
*/
typedef int (LDAP_SORT_AD_CMP_PROC) LDAP_P(( /* deprecated */
LDAP_CONST char *left,
@@ -1872,6 +1875,7 @@ ldap_create_page_control LDAP_P((
#if LDAP_DEPRECATED
LDAP_F( int )
ldap_parse_page_control LDAP_P((
+ /* deprecated, use ldap_parse_pageresponse_control */
LDAP *ld,
LDAPControl **ctrls,
ber_int_t *count,
@@ -2060,7 +2064,7 @@ ldap_passwordpolicy_err2txt LDAP_P(( LDAPPasswordPolicyError ));
#endif /* LDAP_CONTROL_PASSWORDPOLICYREQUEST */
/*
- * LDAP Dynamic Directory Services Refresh RFC2589
+ * LDAP Dynamic Directory Services Refresh -- RFC 2589
* in dds.c
*/
#define LDAP_API_FEATURE_REFRESH 1000
diff --git a/include/slapi-plugin.h b/include/slapi-plugin.h
index 6b0a60ba80ee59aa05c625996176a1a108dd6a18..a59e7a9d3f4515716ce2122b8ad9ddb2565f98da 100644
--- a/include/slapi-plugin.h
+++ b/include/slapi-plugin.h
@@ -531,6 +531,7 @@ int slapi_x_backend_get_flags( const Slapi_Backend *be, unsigned long *flags );
#define SLAPI_X_MANAGEDIT 1306
#define SLAPI_X_OPERATION_NO_SCHEMA_CHECK 1307
#define SLAPI_X_ADD_STRUCTURAL_CLASS 1308
+#define SLAPI_X_OPERATION_NO_SUBORDINATE_GLUE 1309
/* Authentication types */
#define SLAPD_AUTH_NONE "none"
@@ -726,6 +727,20 @@ int slapi_x_backend_get_flags( const Slapi_Backend *be, unsigned long *flags );
#define SLAPI_X_GROUP_OPERATION_DN 1252 /* asserted value */
#define SLAPI_X_GROUP_TARGET_ENTRY 1253 /* target entry */
+/* internal preoperation extensions */
+#define SLAPI_PLUGIN_INTERNAL_PRE_BIND_FN 1260
+#define SLAPI_PLUGIN_INTERNAL_PRE_UNBIND_FN 1261
+#define SLAPI_PLUGIN_INTERNAL_PRE_SEARCH_FN 1262
+#define SLAPI_PLUGIN_INTERNAL_PRE_COMPARE_FN 1263
+#define SLAPI_PLUGIN_INTERNAL_PRE_ABANDON_FN 1264
+
+/* internal postoperation extensions */
+#define SLAPI_PLUGIN_INTERNAL_POST_BIND_FN 1270
+#define SLAPI_PLUGIN_INTERNAL_POST_UNBIND_FN 1271
+#define SLAPI_PLUGIN_INTERNAL_POST_SEARCH_FN 1272
+#define SLAPI_PLUGIN_INTERNAL_POST_COMPARE_FN 1273
+#define SLAPI_PLUGIN_INTERNAL_POST_ABANDON_FN 1274
+
/* config stuff */
#define SLAPI_CONFIG_FILENAME 40
#define SLAPI_CONFIG_LINENO 41
diff --git a/libraries/liblber/memory.c b/libraries/liblber/memory.c
index f45ec52b68d8d6968d6e2a4d94b90d795f8cb134..ddd78622f2547923b3519748c81cab0b6117da0e 100644
--- a/libraries/liblber/memory.c
+++ b/libraries/liblber/memory.c
@@ -700,8 +700,9 @@ struct berval *
ber_bvreplace_x( struct berval *dst, LDAP_CONST struct berval *src, void *ctx )
{
assert( dst != NULL );
+ assert( !BER_BVISNULL( src ) );
- if ( dst->bv_len < src->bv_len ) {
+ if ( BER_BVISNULL( dst ) || dst->bv_len < src->bv_len ) {
dst->bv_val = ber_memrealloc_x( dst->bv_val, src->bv_len + 1, ctx );
}
diff --git a/libraries/libldap/abandon.c b/libraries/libldap/abandon.c
index bc9aae03e03cfe691acb8b7ef5306ac723f7e7da..551940d1b1655dbbe13d3584db06cf2be8dd05ae 100644
--- a/libraries/libldap/abandon.c
+++ b/libraries/libldap/abandon.c
@@ -110,11 +110,11 @@ do_abandon(
ber_int_t origid,
ber_int_t msgid,
LDAPControl **sctrls,
- LDAPControl **cctrls)
+ LDAPControl **cctrls )
{
BerElement *ber;
int i, err, sendabandon;
- ber_int_t *old_abandon;
+ ber_int_t *old_abandon;
Sockbuf *sb;
LDAPRequest *lr;
@@ -191,23 +191,24 @@ do_abandon(
i = ++(ld)->ld_msgid;
#ifdef LDAP_CONNECTIONLESS
if ( LDAP_IS_UDP(ld) ) {
- err = ber_write( ber, ld->ld_options.ldo_peer,
- sizeof(struct sockaddr), 0);
+ err = ber_write( ber, ld->ld_options.ldo_peer,
+ sizeof(struct sockaddr), 0);
}
if ( LDAP_IS_UDP(ld) && ld->ld_options.ldo_version ==
- LDAP_VERSION2) {
- char *dn = ld->ld_options.ldo_cldapdn;
- if (!dn) dn = "";
- err = ber_printf( ber, "{isti", /* '}' */
- i, dn,
- LDAP_REQ_ABANDON, msgid );
+ LDAP_VERSION2 )
+ {
+ char *dn = ld->ld_options.ldo_cldapdn;
+ if (!dn) dn = "";
+ err = ber_printf( ber, "{isti", /* '}' */
+ i, dn,
+ LDAP_REQ_ABANDON, msgid );
} else
#endif
{
- /* create a message to send */
- err = ber_printf( ber, "{iti", /* '}' */
- i,
- LDAP_REQ_ABANDON, msgid );
+ /* create a message to send */
+ err = ber_printf( ber, "{iti", /* '}' */
+ i,
+ LDAP_REQ_ABANDON, msgid );
}
if( err == -1 ) {
diff --git a/libraries/libldap/controls.c b/libraries/libldap/controls.c
index d12afd41b5fd0d476699b90477bbb562ccc70429..ad8384e9c3abaf57374b411a9d163214a007595d 100644
--- a/libraries/libldap/controls.c
+++ b/libraries/libldap/controls.c
@@ -30,13 +30,13 @@
* can be found in the file "build/LICENSE-2.0.1" in this distribution
* of OpenLDAP Software.
*/
-/* Portions Copyright (C) The Internet Society (1997)
- * ASN.1 fragments are from RFC 2251; see RFC for full legal notices.
+/* Portions Copyright (C) The Internet Society (2006)
+ * ASN.1 fragments are from RFC 4511; see RFC for full legal notices.
*/
-/* LDAPv3 Controls (RFC2251)
+/* LDAPv3 Controls (RFC 4511)
*
- * Controls ::= SEQUENCE OF Control
+ * Controls ::= SEQUENCE OF control Control
*
* Control ::= SEQUENCE {
* controlType LDAPOID,
diff --git a/libraries/libldap/dnssrv.c b/libraries/libldap/dnssrv.c
index 3090c66d4dc5c64301811467b760654434e4245a..09e3936cc38544f816a4649ed8946f3aef68c97e 100644
--- a/libraries/libldap/dnssrv.c
+++ b/libraries/libldap/dnssrv.c
@@ -275,8 +275,12 @@ int ldap_domain2hostlist(
/* weight = (p[2] << 8) | p[3]; */
port = (p[4] << 8) | p[5];
- buflen = strlen(host) + sizeof(":65355 ");
- hostlist = (char *) LDAP_REALLOC(hostlist, cur + buflen);
+ if ( port == 0 || host[ 0 ] == '\0' ) {
+ goto add_size;
+ }
+
+ buflen = strlen(host) + STRLENOF(":65355 ");
+ hostlist = (char *) LDAP_REALLOC(hostlist, cur + buflen + 1);
if (hostlist == NULL) {
rc = LDAP_NO_MEMORY;
goto out;
@@ -287,6 +291,7 @@ int ldap_domain2hostlist(
}
cur += sprintf(&hostlist[cur], "%s:%hd", host, port);
}
+add_size:;
p += size;
}
}
diff --git a/libraries/libldap/filter.c b/libraries/libldap/filter.c
index 9241a61c8bc0712c9579ba0493b4baad9b114277..c6453a09fa47cb6ff6df7289abcbb875ef5bc6cb 100644
--- a/libraries/libldap/filter.c
+++ b/libraries/libldap/filter.c
@@ -16,8 +16,8 @@
/* Portions Copyright (c) 1990 Regents of the University of Michigan.
* All rights reserved.
*/
-/* Portions Copyright (C) The Internet Society (1997).
- * ASN.1 fragments are from RFC 2251; see RFC for full legal notices.
+/* Portions Copyright (C) The Internet Society (2006)
+ * ASN.1 fragments are from RFC 4511; see RFC for full legal notices.
*/
#include "portable.h"
@@ -334,36 +334,36 @@ ldap_pvt_put_filter( BerElement *ber, const char *str_in )
int parens, balance, escape;
/*
- * A Filter looks like this:
- * Filter ::= CHOICE {
- * and [0] SET OF Filter,
- * or [1] SET OF Filter,
- * not [2] Filter,
- * equalityMatch [3] AttributeValueAssertion,
- * substrings [4] SubstringFilter,
- * greaterOrEqual [5] AttributeValueAssertion,
- * lessOrEqual [6] AttributeValueAssertion,
- * present [7] AttributeType,
- * approxMatch [8] AttributeValueAssertion,
- * extensibleMatch [9] MatchingRuleAssertion -- LDAPv3
- * }
+ * A Filter looks like this (RFC 4511 as extended by RFC 4526):
+ * Filter ::= CHOICE {
+ * and [0] SET SIZE (0..MAX) OF filter Filter,
+ * or [1] SET SIZE (0..MAX) OF filter Filter,
+ * not [2] Filter,
+ * equalityMatch [3] AttributeValueAssertion,
+ * substrings [4] SubstringFilter,
+ * greaterOrEqual [5] AttributeValueAssertion,
+ * lessOrEqual [6] AttributeValueAssertion,
+ * present [7] AttributeDescription,
+ * approxMatch [8] AttributeValueAssertion,
+ * extensibleMatch [9] MatchingRuleAssertion,
+ * ... }
*
- * SubstringFilter ::= SEQUENCE {
- * type AttributeType,
- * SEQUENCE OF CHOICE {
- * initial [0] IA5String,
- * any [1] IA5String,
- * final [2] IA5String
- * }
- * }
+ * SubstringFilter ::= SEQUENCE {
+ * type AttributeDescription,
+ * substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE {
+ * initial [0] AssertionValue, -- only once
+ * any [1] AssertionValue,
+ * final [2] AssertionValue -- only once
+ * }
+ * }
*
- * MatchingRuleAssertion ::= SEQUENCE { -- LDAPv3
- * matchingRule [1] MatchingRuleId OPTIONAL,
- * type [2] AttributeDescription OPTIONAL,
- * matchValue [3] AssertionValue,
- * dnAttributes [4] BOOLEAN DEFAULT FALSE }
+ * MatchingRuleAssertion ::= SEQUENCE {
+ * matchingRule [1] MatchingRuleId OPTIONAL,
+ * type [2] AttributeDescription OPTIONAL,
+ * matchValue [3] AssertionValue,
+ * dnAttributes [4] BOOLEAN DEFAULT FALSE }
*
- * Note: tags in a choice are always explicit
+ * Note: tags in a CHOICE are always explicit
*/
Debug( LDAP_DEBUG_TRACE, "put_filter: \"%s\"\n", str_in, 0, 0 );
@@ -586,7 +586,7 @@ put_simple_filter(
break;
case ':':
- /* RFC2254 extensible filters are off the form:
+ /* RFC 4515 extensible filters are off the form:
* type [:dn] [:rule] := value
* or [:dn]:rule := value
*/
diff --git a/libraries/libldap/request.c b/libraries/libldap/request.c
index 2fa9f0f8abf6e4f37781b627d38e2d2e3e9cc139..2b9060d9d70aa52bc603f426202d4282e21813b0 100644
--- a/libraries/libldap/request.c
+++ b/libraries/libldap/request.c
@@ -70,7 +70,8 @@ ldap_alloc_ber_with_options( LDAP *ld )
{
BerElement *ber;
- if (( ber = ber_alloc_t( ld->ld_lberoptions )) == NULL ) {
+ ber = ber_alloc_t( ld->ld_lberoptions );
+ if ( ber == NULL ) {
ld->ld_errno = LDAP_NO_MEMORY;
}
@@ -236,7 +237,7 @@ ldap_send_server_request(
}
if ( rc ) return rc;
- lr = (LDAPRequest *)LDAP_CALLOC( 1, sizeof( LDAPRequest ));
+ lr = (LDAPRequest *)LDAP_CALLOC( 1, sizeof( LDAPRequest ) );
if ( lr == NULL ) {
ld->ld_errno = LDAP_NO_MEMORY;
ldap_free_connection( ld, lc, 0, 0 );
@@ -516,7 +517,7 @@ find_connection( LDAP *ld, LDAPURLDesc *srv, int any )
if ( lsu_port == lcu_port
&& strcmp( lcu->lud_scheme, lsu->lud_scheme ) == 0
&& lcu->lud_host != NULL && *lcu->lud_host != '\0'
- && lsu->lud_host != NULL && *lsu->lud_host != '\0'
+ && lsu->lud_host != NULL && *lsu->lud_host != '\0'
&& strcasecmp( lsu->lud_host, lcu->lud_host ) == 0 )
{
found = 1;
@@ -646,37 +647,38 @@ ldap_dump_connection( LDAP *ld, LDAPConn *lconns, int all )
LDAPConn *lc;
char timebuf[32];
- fprintf( stderr, "** ld %p Connection%s:\n", (void *)ld, all ? "s" : "" );
+ Debug( LDAP_DEBUG_TRACE, "** ld %p Connection%s:\n", (void *)ld, all ? "s" : "", 0 );
for ( lc = lconns; lc != NULL; lc = lc->lconn_next ) {
if ( lc->lconn_server != NULL ) {
- fprintf( stderr, "* host: %s port: %d%s\n",
- ( lc->lconn_server->lud_host == NULL ) ? "(null)"
- : lc->lconn_server->lud_host,
- lc->lconn_server->lud_port, ( lc->lconn_sb ==
- ld->ld_sb ) ? " (default)" : "" );
+ Debug( LDAP_DEBUG_TRACE, "* host: %s port: %d%s\n",
+ ( lc->lconn_server->lud_host == NULL ) ? "(null)"
+ : lc->lconn_server->lud_host,
+ lc->lconn_server->lud_port, ( lc->lconn_sb ==
+ ld->ld_sb ) ? " (default)" : "" );
}
- fprintf( stderr, " refcnt: %d status: %s\n", lc->lconn_refcnt,
- ( lc->lconn_status == LDAP_CONNST_NEEDSOCKET ) ?
- "NeedSocket" : ( lc->lconn_status ==
- LDAP_CONNST_CONNECTING ) ? "Connecting" : "Connected" );
- fprintf( stderr, " last used: %s",
- ldap_pvt_ctime( &lc->lconn_lastused, timebuf ));
- if( lc->lconn_rebind_inprogress ) {
- fprintf( stderr, " rebind in progress\n");
- if( lc->lconn_rebind_queue != NULL) {
- int i = 0;
- for( ;lc->lconn_rebind_queue[i] != NULL; i++) {
- int j = 0;
- for( ;lc->lconn_rebind_queue[i][j] != 0; j++) {
- fprintf( stderr, " queue %d entry %d - %s\n",
- i, j, lc->lconn_rebind_queue[i][j]);
+ Debug( LDAP_DEBUG_TRACE, " refcnt: %d status: %s\n", lc->lconn_refcnt,
+ ( lc->lconn_status == LDAP_CONNST_NEEDSOCKET )
+ ? "NeedSocket" : ( lc->lconn_status == LDAP_CONNST_CONNECTING )
+ ? "Connecting" : "Connected", 0 );
+ Debug( LDAP_DEBUG_TRACE, " last used: %s%s\n",
+ ldap_pvt_ctime( &lc->lconn_lastused, timebuf ),
+ lc->lconn_rebind_inprogress ? " rebind in progress" : "", 0 );
+ if ( lc->lconn_rebind_inprogress ) {
+ if ( lc->lconn_rebind_queue != NULL) {
+ int i;
+
+ for ( i = 0; lc->lconn_rebind_queue[i] != NULL; i++ ) {
+ int j;
+ for( j = 0; lc->lconn_rebind_queue[i][j] != 0; j++ ) {
+ Debug( LDAP_DEBUG_TRACE, " queue %d entry %d - %s\n",
+ i, j, lc->lconn_rebind_queue[i][j] );
}
}
} else {
- fprintf( stderr, " queue is empty\n");
+ Debug( LDAP_DEBUG_TRACE, " queue is empty\n", 0, 0, 0 );
}
}
- fprintf(stderr, "\n");
+ Debug( LDAP_DEBUG_TRACE, "\n", 0, 0, 0 );
if ( !all ) {
break;
}
@@ -689,46 +691,45 @@ ldap_dump_requests_and_responses( LDAP *ld )
{
LDAPRequest *lr;
LDAPMessage *lm, *l;
+ int i;
-#ifdef LDAP_R_COMPILE
- ldap_pvt_thread_mutex_lock( &ld->ld_req_mutex );
-#endif
- fprintf( stderr, "** ld %p Outstanding Requests:\n", (void *)ld );
- if (( lr = ld->ld_requests ) == NULL ) {
- fprintf( stderr, " Empty\n" );
+ Debug( LDAP_DEBUG_TRACE, "** ld %p Outstanding Requests:\n",
+ (void *)ld, 0, 0 );
+ lr = ld->ld_requests;
+ if ( lr == NULL ) {
+ Debug( LDAP_DEBUG_TRACE, " Empty\n", 0, 0, 0 );
}
- for ( ; lr != NULL; lr = lr->lr_next ) {
- fprintf( stderr, " * msgid %d, origid %d, status %s\n",
- lr->lr_msgid, lr->lr_origid,
- ( lr->lr_status == LDAP_REQST_INPROGRESS ) ? "InProgress" :
- ( lr->lr_status == LDAP_REQST_CHASINGREFS ) ? "ChasingRefs" :
- ( lr->lr_status == LDAP_REQST_NOTCONNECTED ) ? "NotConnected" :
- ( lr->lr_status == LDAP_REQST_WRITING ) ? "Writing" :
- ( lr->lr_status == LDAP_REQST_COMPLETED ) ? "RequestCompleted"
- : "InvalidStatus");
- fprintf( stderr, " outstanding referrals %d, parent count %d\n",
- lr->lr_outrefcnt, lr->lr_parentcnt );
+ for ( i = 0; lr != NULL; lr = lr->lr_next, i++ ) {
+ Debug( LDAP_DEBUG_TRACE, " * msgid %d, origid %d, status %s\n",
+ lr->lr_msgid, lr->lr_origid,
+ ( lr->lr_status == LDAP_REQST_INPROGRESS ) ? "InProgress" :
+ ( lr->lr_status == LDAP_REQST_CHASINGREFS ) ? "ChasingRefs" :
+ ( lr->lr_status == LDAP_REQST_NOTCONNECTED ) ? "NotConnected" :
+ ( lr->lr_status == LDAP_REQST_WRITING ) ? "Writing" :
+ ( lr->lr_status == LDAP_REQST_COMPLETED ) ? "RequestCompleted"
+ : "InvalidStatus" );
+ Debug( LDAP_DEBUG_TRACE, " outstanding referrals %d, parent count %d\n",
+ lr->lr_outrefcnt, lr->lr_parentcnt, 0 );
}
-#ifdef LDAP_R_COMPILE
- ldap_pvt_thread_mutex_unlock( &ld->ld_req_mutex );
-#endif
- fprintf( stderr, "** ld %p Response Queue:\n", (void *)ld );
- if (( lm = ld->ld_responses ) == NULL ) {
- fprintf( stderr, " Empty\n" );
+ Debug( LDAP_DEBUG_TRACE, " ld %p request count %d\n", (void *)ld, i, 0 );
+ Debug( LDAP_DEBUG_TRACE, "** ld %p Response Queue:\n", (void *)ld, 0, 0 );
+ if ( ( lm = ld->ld_responses ) == NULL ) {
+ Debug( LDAP_DEBUG_TRACE, " Empty\n", 0, 0, 0 );
}
- for ( ; lm != NULL; lm = lm->lm_next ) {
- fprintf( stderr, " * msgid %d, type %lu\n",
- lm->lm_msgid, (unsigned long) lm->lm_msgtype );
- if (( l = lm->lm_chain ) != NULL ) {
- fprintf( stderr, " chained responses:\n" );
+ for ( i = 0; lm != NULL; lm = lm->lm_next, i++ ) {
+ Debug( LDAP_DEBUG_TRACE, " * msgid %d, type %lu\n",
+ lm->lm_msgid, (unsigned long)lm->lm_msgtype, 0 );
+ if ( ( l = lm->lm_chain ) != NULL ) {
+ Debug( LDAP_DEBUG_TRACE, " chained responses:\n", 0, 0, 0 );
for ( ; l != NULL; l = l->lm_chain ) {
- fprintf( stderr,
- " * msgid %d, type %lu\n",
- l->lm_msgid,
- (unsigned long) l->lm_msgtype );
+ Debug( LDAP_DEBUG_TRACE,
+ " * msgid %d, type %lu\n",
+ l->lm_msgid,
+ (unsigned long)l->lm_msgtype, 0 );
}
}
}
+ Debug( LDAP_DEBUG_TRACE, " ld %p response count %d\n", (void *)ld, i, 0 );
}
#endif /* LDAP_DEBUG */
@@ -1175,12 +1176,12 @@ ldap_chase_referrals( LDAP *ld,
LDAPRequest *lp;
int looped = 0;
int len = srv->lud_dn ? strlen( srv->lud_dn ) : 0;
- for (lp = lr; lp; lp = lp->lr_parent ) {
+ for ( lp = lr; lp; lp = lp->lr_parent ) {
if ( lp->lr_conn == lc
- && len == lp->lr_dn.bv_len
- && len
- && strncmp( srv->lud_dn, lp->lr_dn.bv_val, len ) == 0 )
+ && len == lp->lr_dn.bv_len )
{
+ if ( len && strncmp( srv->lud_dn, lp->lr_dn.bv_val, len ) )
+ continue;
looped = 1;
break;
}
@@ -1413,7 +1414,7 @@ ldap_find_request_by_msgid( LDAP *ld, ber_int_t msgid )
ldap_pvt_thread_mutex_lock( &ld->ld_req_mutex );
#endif
for ( lr = ld->ld_requests; lr != NULL; lr = lr->lr_next ) {
- if( lr->lr_status == LDAP_REQST_COMPLETED ) {
+ if ( lr->lr_status == LDAP_REQST_COMPLETED ) {
continue; /* Skip completed requests */
}
if ( msgid == lr->lr_msgid ) {
diff --git a/libraries/libldap/result.c b/libraries/libldap/result.c
index 04e5fdb96aab709a397ab53193a4fdc5a70adfd3..9045dd32fd09d53b9ce2c05f5dd5b5d0dead8678 100644
--- a/libraries/libldap/result.c
+++ b/libraries/libldap/result.c
@@ -37,17 +37,17 @@
* can be found in the file "build/LICENSE-2.0.1" in this distribution
* of OpenLDAP Software.
*/
-/* Portions Copyright (C) The Internet Society (1997)
- * ASN.1 fragments are from RFC 2251; see RFC for full legal notices.
+/* Portions Copyright (C) The Internet Society (2006)
+ * ASN.1 fragments are from RFC 4511; see RFC for full legal notices.
*/
/*
- * LDAPv3 (RFC2251)
+ * LDAPv3 (RFC 4511)
* LDAPResult ::= SEQUENCE {
- * resultCode ENUMERATED { ... },
- * matchedDN LDAPDN,
- * errorMessage LDAPString,
- * referral Referral OPTIONAL
+ * resultCode ENUMERATED { ... },
+ * matchedDN LDAPDN,
+ * diagnosticMessage LDAPString,
+ * referral [3] Referral OPTIONAL
* }
* Referral ::= SEQUENCE OF LDAPURL (one or more)
* LDAPURL ::= LDAPString (limited to URL chars)
@@ -239,7 +239,7 @@ wait4msg(
*tvp;
time_t start_time = 0;
time_t tmp_time;
- LDAPConn *lc, *nextlc;
+ LDAPConn *lc;
assert( ld != NULL );
assert( result != NULL );
@@ -273,12 +273,22 @@ wait4msg(
if ( ldap_debug & LDAP_DEBUG_TRACE ) {
Debug( LDAP_DEBUG_TRACE, "wait4msg continue ld %p msgid %d all %d\n",
(void *)ld, msgid, all );
+#ifdef LDAP_R_COMPILE
+ ldap_pvt_thread_mutex_lock( &ld->ld_conn_mutex );
+#endif
ldap_dump_connection( ld, ld->ld_conns, 1 );
+#ifdef LDAP_R_COMPILE
+ ldap_pvt_thread_mutex_unlock( &ld->ld_conn_mutex );
+ ldap_pvt_thread_mutex_lock( &ld->ld_req_mutex );
+#endif
ldap_dump_requests_and_responses( ld );
+#ifdef LDAP_R_COMPILE
+ ldap_pvt_thread_mutex_unlock( &ld->ld_req_mutex );
+#endif
}
#endif /* LDAP_DEBUG */
- if ( (*result = chkResponseList(ld, msgid, all)) != NULL ) {
+ if ( ( *result = chkResponseList( ld, msgid, all ) ) != NULL ) {
rc = (*result)->lm_msgtype;
} else {
@@ -287,10 +297,10 @@ wait4msg(
#ifdef LDAP_R_COMPILE
ldap_pvt_thread_mutex_lock( &ld->ld_conn_mutex );
#endif
- for ( lc = ld->ld_conns; lc != NULL; lc = nextlc ) {
- nextlc = lc->lconn_next;
+ for ( lc = ld->ld_conns; lc != NULL; lc = lc->lconn_next ) {
if ( ber_sockbuf_ctrl( lc->lconn_sb,
- LBER_SB_OPT_DATA_READY, NULL ) ) {
+ LBER_SB_OPT_DATA_READY, NULL ) )
+ {
#ifdef LDAP_R_COMPILE
ldap_pvt_thread_mutex_unlock( &ld->ld_conn_mutex );
#endif
@@ -318,7 +328,7 @@ wait4msg(
if ( rc == 0 || ( rc == -1 && (
!LDAP_BOOL_GET(&ld->ld_options, LDAP_BOOL_RESTART)
- || errno != EINTR )))
+ || errno != EINTR ) ) )
{
ld->ld_errno = (rc == -1 ? LDAP_SERVER_DOWN :
LDAP_TIMEOUT);
@@ -343,21 +353,28 @@ wait4msg(
ldap_pvt_thread_mutex_unlock( &ld->ld_req_mutex );
ldap_pvt_thread_mutex_lock( &ld->ld_conn_mutex );
#endif
- for ( lc = ld->ld_conns; rc == LDAP_MSG_X_KEEP_LOOKING && lc != NULL;
- lc = nextlc )
+ for ( lc = ld->ld_conns;
+ rc == LDAP_MSG_X_KEEP_LOOKING && lc != NULL;
+ lc = lc->lconn_next )
{
- nextlc = lc->lconn_next;
if ( lc->lconn_status == LDAP_CONNST_CONNECTED &&
- ldap_is_read_ready( ld, lc->lconn_sb ))
+ ldap_is_read_ready( ld, lc->lconn_sb ) )
{
#ifdef LDAP_R_COMPILE
ldap_pvt_thread_mutex_unlock( &ld->ld_conn_mutex );
#endif
rc = try_read1msg( ld, msgid, all, &lc, result );
- if ( lc == NULL ) lc = nextlc;
#ifdef LDAP_R_COMPILE
ldap_pvt_thread_mutex_lock( &ld->ld_conn_mutex );
#endif
+ if ( lc == NULL ) {
+ /* if lc gets free()'d,
+ * there's no guarantee
+ * lc->lconn_next is still
+ * sane; better restart
+ * (ITS#4405) */
+ lc = ld->ld_conns;
+ }
}
}
#ifdef LDAP_R_COMPILE
@@ -437,7 +454,7 @@ try_read1msg(
retry:
if ( lc->lconn_ber == NULL ) {
- lc->lconn_ber = ldap_alloc_ber_with_options(ld);
+ lc->lconn_ber = ldap_alloc_ber_with_options( ld );
if( lc->lconn_ber == NULL ) {
return -1;
@@ -453,7 +470,7 @@ retry:
if ( LDAP_IS_UDP(ld) ) {
struct sockaddr from;
ber_int_sb_read( lc->lconn_sb, &from, sizeof(struct sockaddr) );
- if (ld->ld_options.ldo_version == LDAP_VERSION2) isv2=1;
+ if (ld->ld_options.ldo_version == LDAP_VERSION2) isv2 = 1;
}
nextresp3:
#endif
@@ -509,7 +526,7 @@ retry_ber:
if ( lr == NULL ) {
Debug( LDAP_DEBUG_ANY,
"no request for response on ld %p msgid %ld (tossing)\n",
- (void *)ld, (long) id, 0 );
+ (void *)ld, (long)id, 0 );
goto retry_ber;
}
#ifdef LDAP_CONNECTIONLESS
@@ -562,7 +579,7 @@ nextresp2:
if ( refer_cnt > 0 ) {
/* sucessfully chased reference */
/* If haven't got end search, set chasing referrals */
- if( lr->lr_status != LDAP_REQST_COMPLETED) {
+ if ( lr->lr_status != LDAP_REQST_COMPLETED ) {
lr->lr_status = LDAP_REQST_CHASINGREFS;
Debug( LDAP_DEBUG_TRACE,
"read1msg: search ref chased, "
@@ -620,7 +637,7 @@ nextresp2:
* Note: refs arrary is freed by ldap_chase_v3referrals
*/
refer_cnt = ldap_chase_v3referrals( ld, lr, refs,
- 0, &lr->lr_res_error, &hadref );
+ 0, &lr->lr_res_error, &hadref );
lr->lr_status = LDAP_REQST_COMPLETED;
Debug( LDAP_DEBUG_TRACE,
"read1msg: referral chased, mark request completed, ld %p msgid %d\n",
@@ -673,13 +690,11 @@ nextresp2:
!= LBER_ERROR )
{
if ( lr_res_error != NULL ) {
- {
- if ( lr->lr_res_error != NULL ) {
- (void)ldap_append_referral( ld, &lr->lr_res_error, lr_res_error );
- LDAP_FREE( (char *)lr_res_error );
- } else {
- lr->lr_res_error = lr_res_error;
- }
+ if ( lr->lr_res_error != NULL ) {
+ (void)ldap_append_referral( ld, &lr->lr_res_error, lr_res_error );
+ LDAP_FREE( (char *)lr_res_error );
+ } else {
+ lr->lr_res_error = lr_res_error;
}
lr_res_error = NULL;
}
@@ -770,12 +785,12 @@ nextresp2:
/* Check if all requests are finished, lr is now parent */
tmplr = lr;
- if (tmplr->lr_status == LDAP_REQST_COMPLETED) {
+ if ( tmplr->lr_status == LDAP_REQST_COMPLETED ) {
for ( tmplr=lr->lr_child;
tmplr != NULL;
tmplr=tmplr->lr_refnext)
{
- if( tmplr->lr_status != LDAP_REQST_COMPLETED) break;
+ if ( tmplr->lr_status != LDAP_REQST_COMPLETED ) break;
}
}
diff --git a/libraries/libldap/tls.c b/libraries/libldap/tls.c
index 9dfbd73ef478a126db7e71cc49dcfaf83dec1578..fc2e31d55a7b57506916069d547d1dad91eb0614 100644
--- a/libraries/libldap/tls.c
+++ b/libraries/libldap/tls.c
@@ -93,6 +93,7 @@ static void tls_locking_cb( int mode, int type, const char *file, int line )
*/
static ldap_pvt_thread_mutex_t tls_def_ctx_mutex;
+static ldap_pvt_thread_mutex_t tls_connect_mutex;
static void tls_init_threads( void )
{
@@ -105,6 +106,7 @@ static void tls_init_threads( void )
/* FIXME: the thread id should be added somehow... */
ldap_pvt_thread_mutex_init( &tls_def_ctx_mutex );
+ ldap_pvt_thread_mutex_init( &tls_connect_mutex );
}
#endif /* LDAP_R_COMPILE */
@@ -862,7 +864,13 @@ ldap_pvt_tls_accept( Sockbuf *sb, void *ctx_arg )
LBER_SBIOD_LEVEL_TRANSPORT, (void *)ssl );
}
+#ifdef LDAP_R_COMPILE
+ ldap_pvt_thread_mutex_lock( &tls_connect_mutex );
+#endif
err = SSL_accept( ssl );
+#ifdef LDAP_R_COMPILE
+ ldap_pvt_thread_mutex_unlock( &tls_connect_mutex );
+#endif
#ifdef HAVE_WINSOCK
errno = WSAGetLastError();
@@ -1358,6 +1366,7 @@ ldap_pvt_tls_set_option( LDAP *ld, int option, void *arg )
if ( lo->ldo_tls_ctx )
SSL_CTX_free( lo->ldo_tls_ctx );
lo->ldo_tls_ctx = arg;
+ CRYPTO_add( &((SSL_CTX *)arg)->references, 1, CRYPTO_LOCK_SSL_CTX );
return 0;
case LDAP_OPT_X_TLS_CONNECT_CB:
lo->ldo_tls_connect_cb = (LDAP_TLS_CONNECT_CB *)arg;
diff --git a/libraries/liblutil/passwd.c b/libraries/liblutil/passwd.c
index 03024cb1181ed7fee27969db2e7d595d04c05a57..a14071da05cf689d6a305e3415181f800b5e51c5 100644
--- a/libraries/liblutil/passwd.c
+++ b/libraries/liblutil/passwd.c
@@ -309,7 +309,7 @@ lutil_passwd(
* didn't recognize? Assume a scheme name is at least 1 character.
*/
if (( passwd->bv_val[0] == '{' ) &&
- ( strchr( passwd->bv_val, '}' ) > passwd->bv_val+1 ))
+ ( ber_bvchr( passwd, '}' ) > passwd->bv_val+1 ))
{
return 1;
}
diff --git a/libraries/liblutil/tavl.c b/libraries/liblutil/tavl.c
index f4a8d84e53b36b9706fc57d195094681eb6cd11a..0fd2b7992adeee784e46ae9199880d68a62f0edb 100644
--- a/libraries/liblutil/tavl.c
+++ b/libraries/liblutil/tavl.c
@@ -284,6 +284,13 @@ tavl_delete( Avlnode **root, void* data, AVL_CMP fcmp )
ber_memfree( p );
+ /* Update child thread */
+ if ( q ) {
+ for ( ; q->avl_bits[nside] == AVL_CHILD && q->avl_link[nside];
+ q = q->avl_link[nside] ) ;
+ q->avl_link[nside] = r;
+ }
+
if ( !depth ) {
*root = q;
return data;
@@ -295,12 +302,7 @@ tavl_delete( Avlnode **root, void* data, AVL_CMP fcmp )
side = pdir[depth];
p->avl_link[side] = q;
- /* Update child thread */
- if ( q ) {
- for ( ; q->avl_bits[nside] == AVL_CHILD && q->avl_link[nside];
- q = q->avl_link[nside] ) ;
- q->avl_link[nside] = r;
- } else {
+ if ( !q ) {
p->avl_bits[side] = AVL_THREAD;
p->avl_link[side] = r;
}
@@ -443,6 +445,26 @@ tavl_free( Avlnode *root, AVL_FREE dfree )
* < 0 if arg1 is less than arg2 and > 0 if arg1 is greater than arg2.
*/
+/*
+ * tavl_find2 - returns Avlnode instead of data pointer.
+ * tavl_find3 - as above, but returns Avlnode even if no match is found.
+ * also return the last comparison result in ret.
+ */
+Avlnode *
+tavl_find3( Avlnode *root, const void *data, AVL_CMP fcmp, int *ret )
+{
+ int cmp, dir;
+ Avlnode *prev;
+
+ while ( root != 0 && (cmp = (*fcmp)( data, root->avl_data )) != 0 ) {
+ prev = root;
+ dir = cmp > 0;
+ root = avl_child( root, dir );
+ }
+ *ret = cmp;
+ return root ? root : prev;
+}
+
Avlnode *
tavl_find2( Avlnode *root, const void *data, AVL_CMP fcmp )
{
diff --git a/servers/slapd/DB_CONFIG b/servers/slapd/DB_CONFIG
index 7977195342aa87fdc60cccf0eee455302a16e97e..cc05b85eed4f14fc295c26b1f1495da37621fa32 100644
--- a/servers/slapd/DB_CONFIG
+++ b/servers/slapd/DB_CONFIG
@@ -10,6 +10,9 @@
# in particular:
# <http://www.openldap.org/faq/index.cgi?file=1075>
+# Note: most DB_CONFIG settings will take effect only upon rebuilding
+# the DB environment.
+
# one 0.25 GB cache
set_cachesize 0 268435456 1
diff --git a/servers/slapd/acl.c b/servers/slapd/acl.c
index 0044e6849ecfd40121b5dd8189f48aecf5b9ba27..f3959b3ed590ed041ffd777b7de73222672f8835 100644
--- a/servers/slapd/acl.c
+++ b/servers/slapd/acl.c
@@ -134,7 +134,6 @@ slap_access_allowed(
slap_access_t access_level;
const char *attr;
regmatch_t matches[MAXREMATCHES];
- int st_same_attr = 0;
assert( op != NULL );
assert( e != NULL );
@@ -198,24 +197,17 @@ slap_access_allowed(
ret = 0;
control = ACL_BREAK;
- if ( st_same_attr ) {
- assert( state->as_vd_acl != NULL );
-
+ if ( state && state->as_vd_ad == desc ) {
a = state->as_vd_acl;
count = state->as_vd_acl_count;
- if ( !ACL_IS_INVALID( state->as_vd_acl_mask ) ) {
- mask = state->as_vd_acl_mask;
- AC_MEMCPY( matches, state->as_vd_acl_matches, sizeof(matches) );
- goto vd_access;
- }
} else {
if ( state ) state->as_vi_acl = NULL;
a = NULL;
- ACL_PRIV_ASSIGN( mask, *maskp );
count = 0;
- memset( matches, '\0', sizeof( matches ) );
}
+ ACL_PRIV_ASSIGN( mask, *maskp );
+ memset( matches, '\0', sizeof( matches ) );
while ( ( a = slap_acl_get( a, &count, op, e, desc, val,
MAXREMATCHES, matches, state ) ) != NULL )
@@ -340,7 +332,6 @@ access_allowed_mask(
slap_mask_t mask;
slap_access_t access_level;
const char *attr;
- int st_same_attr = 0;
static AccessControlState state_init = ACL_STATE_INIT;
assert( e != NULL );
@@ -377,17 +368,10 @@ access_allowed_mask(
{
return state->as_result;
- } else if ( ( state->as_recorded & ACL_STATE_RECORDED_VD ) &&
- val != NULL && state->as_vd_acl == NULL )
- {
- return state->as_result;
}
- st_same_attr = 1;
} else {
*state = state_init;
}
-
- state->as_vd_ad = desc;
}
Debug( LDAP_DEBUG_ACL,
@@ -403,14 +387,12 @@ access_allowed_mask(
op->o_bd = LDAP_STAILQ_FIRST( &backendDB );
be_null = 1;
-#ifdef LDAP_DEVEL
- /*
- * FIXME: experimental; use first backend rules
- * iff there is no global_acl (ITS#3100) */
+ /* FIXME: experimental; use first backend rules
+ * iff there is no global_acl (ITS#3100)
+ */
if ( frontendDB->be_acl != NULL ) {
op->o_bd = frontendDB;
}
-#endif /* LDAP_DEVEL */
}
assert( op->o_bd != NULL );
@@ -455,6 +437,7 @@ done:
state->as_result = ret;
}
state->as_recorded |= ACL_STATE_RECORDED;
+ state->as_vd_ad = desc;
}
if ( be_null ) op->o_bd = NULL;
if ( maskp ) ACL_PRIV_ASSIGN( *maskp, mask );
@@ -509,7 +492,7 @@ slap_acl_get(
dnlen = e->e_nname.bv_len;
- for ( ; a != NULL; a = a->acl_next ) {
+ for ( ; a != NULL; prev = a, a = a->acl_next ) {
(*count) ++;
if ( a->acl_dn_pat.bv_len || ( a->acl_dn_style != ACL_STYLE_REGEX )) {
@@ -580,11 +563,8 @@ slap_acl_get(
if( state && !( state->as_recorded & ACL_STATE_RECORDED_VD )) {
state->as_recorded |= ACL_STATE_RECORDED_VD;
- state->as_vd_acl = a;
- state->as_vd_acl_count = *count;
- state->as_vd_access = a->acl_access;
- state->as_vd_access_count = 1;
- ACL_INVALIDATE( state->as_vd_acl_mask );
+ state->as_vd_acl = prev;
+ state->as_vd_acl_count = *count - 1;
}
if ( a->acl_attrval_style == ACL_STYLE_REGEX ) {
@@ -667,6 +647,17 @@ slap_acl_get(
return( NULL );
}
+/*
+ * Record value-dependent access control state
+ */
+#define ACL_RECORD_VALUE_STATE do { \
+ if( state && !( state->as_recorded & ACL_STATE_RECORDED_VD )) { \
+ state->as_recorded |= ACL_STATE_RECORDED_VD; \
+ state->as_vd_acl = a; \
+ state->as_vd_acl_count = count; \
+ } \
+ } while( 0 )
+
static int
acl_mask_dn(
Operation *op,
@@ -676,7 +667,7 @@ acl_mask_dn(
AccessControl *a,
int nmatch,
regmatch_t *matches,
- slap_dn_access *b,
+ slap_dn_access *bdn,
struct berval *opndn )
{
/*
@@ -688,40 +679,20 @@ acl_mask_dn(
* NOTE: styles "anonymous", "users" and "self"
* have been moved to enum slap_style_t, whose
* value is set in a_dn_style; however, the string
- * is maintaned in a_dn_pat.
+ * is maintained in a_dn_pat.
*/
- if ( b->a_style == ACL_STYLE_ANONYMOUS ) {
+
+ if ( bdn->a_style == ACL_STYLE_ANONYMOUS ) {
if ( !BER_BVISEMPTY( opndn ) ) {
return 1;
}
- } else if ( b->a_style == ACL_STYLE_USERS ) {
+ } else if ( bdn->a_style == ACL_STYLE_USERS ) {
if ( BER_BVISEMPTY( opndn ) ) {
return 1;
}
- if ( b->a_self ) {
- const char *dummy;
- int rc, match = 0;
-
- /* must have DN syntax */
- if ( desc->ad_type->sat_syntax != slap_schema.si_syn_distinguishedName ) return 1;
-
- /* check if the target is an attribute. */
- if ( val == NULL ) return 1;
-
- /* target is attribute, check if the attribute value
- * is the op dn.
- */
- rc = value_match( &match, desc,
- desc->ad_type->sat_equality, 0,
- val, opndn, &dummy );
- /* on match error or no match, fail the ACL clause */
- if ( rc != LDAP_SUCCESS || match != 0 )
- return 1;
- }
-
- } else if ( b->a_style == ACL_STYLE_SELF ) {
+ } else if ( bdn->a_style == ACL_STYLE_SELF ) {
struct berval ndn, selfndn;
int level;
@@ -729,7 +700,7 @@ acl_mask_dn(
return 1;
}
- level = b->a_self_level;
+ level = bdn->a_self_level;
if ( level < 0 ) {
selfndn = *opndn;
ndn = e->e_nname;
@@ -752,8 +723,8 @@ acl_mask_dn(
return 1;
}
- } else if ( b->a_style == ACL_STYLE_REGEX ) {
- if ( !ber_bvccmp( &b->a_pat, '*' ) ) {
+ } else if ( bdn->a_style == ACL_STYLE_REGEX ) {
+ if ( !ber_bvccmp( &bdn->a_pat, '*' ) ) {
int tmp_nmatch;
regmatch_t tmp_matches[2],
*tmp_matchesp = tmp_matches;
@@ -795,7 +766,7 @@ acl_mask_dn(
return 1;
}
- if ( !regex_matches( &b->a_pat, opndn->bv_val,
+ if ( !regex_matches( &bdn->a_pat, opndn->bv_val,
e->e_ndn, tmp_nmatch, tmp_matchesp ) )
{
return 1;
@@ -810,7 +781,7 @@ acl_mask_dn(
if ( e->e_dn == NULL )
return 1;
- if ( b->a_expand ) {
+ if ( bdn->a_expand ) {
struct berval bv;
char buf[ACL_BUF_SIZE];
@@ -858,7 +829,7 @@ acl_mask_dn(
return 1;
}
- if ( acl_string_expand( &bv, &b->a_pat,
+ if ( acl_string_expand( &bv, &bdn->a_pat,
e->e_nname.bv_val,
tmp_nmatch, tmp_matchesp ) )
{
@@ -874,7 +845,7 @@ acl_mask_dn(
}
} else {
- pat = b->a_pat;
+ pat = bdn->a_pat;
}
patlen = pat.bv_len;
@@ -884,13 +855,13 @@ acl_mask_dn(
}
- if ( b->a_style == ACL_STYLE_BASE ) {
+ if ( bdn->a_style == ACL_STYLE_BASE ) {
/* base dn -- entire object DN must match */
if ( odnlen != patlen ) {
goto dn_match_cleanup;
}
- } else if ( b->a_style == ACL_STYLE_ONE ) {
+ } else if ( bdn->a_style == ACL_STYLE_ONE ) {
ber_len_t rdnlen = 0;
if ( odnlen <= patlen ) {
@@ -906,12 +877,12 @@ acl_mask_dn(
goto dn_match_cleanup;
}
- } else if ( b->a_style == ACL_STYLE_SUBTREE ) {
+ } else if ( bdn->a_style == ACL_STYLE_SUBTREE ) {
if ( odnlen > patlen && !DN_SEPARATOR( opndn->bv_val[odnlen - patlen - 1] ) ) {
goto dn_match_cleanup;
}
- } else if ( b->a_style == ACL_STYLE_CHILDREN ) {
+ } else if ( bdn->a_style == ACL_STYLE_CHILDREN ) {
if ( odnlen <= patlen ) {
goto dn_match_cleanup;
}
@@ -920,8 +891,8 @@ acl_mask_dn(
goto dn_match_cleanup;
}
- } else if ( b->a_style == ACL_STYLE_LEVEL ) {
- int level = b->a_level;
+ } else if ( bdn->a_style == ACL_STYLE_LEVEL ) {
+ int level = bdn->a_level;
struct berval ndn;
if ( odnlen <= patlen ) {
@@ -952,7 +923,7 @@ acl_mask_dn(
got_match = !strcmp( pat.bv_val, &opndn->bv_val[ odnlen - patlen ] );
dn_match_cleanup:;
- if ( pat.bv_val != b->a_pat.bv_val ) {
+ if ( pat.bv_val != bdn->a_pat.bv_val ) {
slap_sl_free( pat.bv_val, op->o_tmpmemctx );
}
@@ -964,21 +935,6 @@ dn_match_cleanup:;
return 0;
}
-/*
- * Record value-dependent access control state
- */
-#define ACL_RECORD_VALUE_STATE do { \
- if( state && !( state->as_recorded & ACL_STATE_RECORDED_VD )) { \
- state->as_recorded |= ACL_STATE_RECORDED_VD; \
- state->as_vd_acl = a; \
- AC_MEMCPY( state->as_vd_acl_matches, matches, \
- sizeof( state->as_vd_acl_matches )) ; \
- state->as_vd_acl_count = count; \
- state->as_vd_access = b; \
- state->as_vd_access_count = i; \
- } \
- } while( 0 )
-
static int
acl_mask_dnattr(
Operation *op,
@@ -1050,7 +1006,7 @@ acl_mask_dnattr(
return 1;
ACL_RECORD_VALUE_STATE;
-
+
/* this is a self clause, check if the target is an
* attribute.
*/
@@ -1122,16 +1078,8 @@ slap_acl_mask(
accessmask2str( *mask, accessmaskbuf, 1 ) );
- if( state && ( state->as_recorded & ACL_STATE_RECORDED_VD )
- && state->as_vd_acl == a )
- {
- b = state->as_vd_access;
- i = state->as_vd_access_count;
-
- } else {
- b = a->acl_access;
- i = 1;
- }
+ b = a->acl_access;
+ i = 1;
for ( ; b != NULL; b = b->a_next, i++ ) {
slap_mask_t oldmask, modmask;
@@ -1151,7 +1099,7 @@ slap_acl_mask(
* NOTE: styles "anonymous", "users" and "self"
* have been moved to enum slap_style_t, whose
* value is set in a_dn_style; however, the string
- * is maintaned in a_dn_pat.
+ * is maintained in a_dn_pat.
*/
if ( acl_mask_dn( op, e, desc, val, a, nmatch, matches,
@@ -1175,7 +1123,7 @@ slap_acl_mask(
* NOTE: styles "anonymous", "users" and "self"
* have been moved to enum slap_style_t, whose
* value is set in a_dn_style; however, the string
- * is maintaned in a_dn_pat.
+ * is maintained in a_dn_pat.
*/
if ( op->o_conn && !BER_BVISNULL( &op->o_conn->c_ndn ) )
@@ -1661,6 +1609,36 @@ slap_acl_mask(
}
}
+ /* check for the "self" modifier in the <access> field */
+ if ( b->a_dn.a_self ) {
+ const char *dummy;
+ int rc, match = 0;
+
+ ACL_RECORD_VALUE_STATE;
+
+ /* must have DN syntax */
+ if ( desc->ad_type->sat_syntax != slap_schema.si_syn_distinguishedName &&
+ !is_at_syntax( desc->ad_type, SLAPD_NAMEUID_SYNTAX )) continue;
+
+ /* check if the target is an attribute. */
+ if ( val == NULL ) continue;
+
+ /* a DN must be present */
+ if ( BER_BVISEMPTY( &op->o_ndn ) ) {
+ continue;
+ }
+
+ /* target is attribute, check if the attribute value
+ * is the op dn.
+ */
+ rc = value_match( &match, desc,
+ desc->ad_type->sat_equality, 0,
+ val, &op->o_ndn, &dummy );
+ /* on match error or no match, fail the ACL clause */
+ if ( rc != LDAP_SUCCESS || match != 0 )
+ continue;
+ }
+
#ifdef SLAP_DYNACL
if ( b->a_dynacl ) {
slap_dynacl_t *da;
@@ -2228,7 +2206,7 @@ acl_match_set (
} else {
struct berval subjdn, ndn = BER_BVNULL;
struct berval setat;
- BerVarray bvals;
+ BerVarray bvals = NULL;
const char *text;
AttributeDescription *desc = NULL;
diff --git a/servers/slapd/back-bdb/add.c b/servers/slapd/back-bdb/add.c
index fabf6b12c6ab917b2bcb3654b2362126c43e6d8e..1c7be0387ec1622d656111bb6a321eb0bde16f26 100644
--- a/servers/slapd/back-bdb/add.c
+++ b/servers/slapd/back-bdb/add.c
@@ -125,7 +125,9 @@ txnReturn:
retry: /* transaction retry */
if( p ) {
/* free parent and reader lock */
- bdb_unlocked_cache_return_entry_r( &bdb->bi_cache, p );
+ if ( p != (Entry *)&slap_entry_root ) {
+ bdb_unlocked_cache_return_entry_r( &bdb->bi_cache, p );
+ }
p = NULL;
}
rs->sr_err = TXN_ABORT( ltid );
@@ -197,102 +199,89 @@ retry: /* transaction retry */
}
p = ei->bei_e;
- if ( p ) {
- if ( !bvmatch( &pdn, &p->e_nname ) ) {
- rs->sr_matched = ber_strdup_x( p->e_name.bv_val,
- op->o_tmpmemctx );
- rs->sr_ref = is_entry_referral( p )
- ? get_entry_referrals( op, p )
- : NULL;
- bdb_unlocked_cache_return_entry_r( &bdb->bi_cache, p );
- p = NULL;
- Debug( LDAP_DEBUG_TRACE,
- LDAP_XSTRING(bdb_add) ": parent "
- "does not exist\n", 0, 0, 0 );
-
- rs->sr_err = LDAP_REFERRAL;
- rs->sr_flags = REP_MATCHED_MUSTBEFREED | REP_REF_MUSTBEFREED;
- goto return_results;
- }
-
- rs->sr_err = access_allowed( op, p,
- children, NULL, ACL_WADD, NULL );
+ if ( !p )
+ p = (Entry *)&slap_entry_root;
+
+ if ( !bvmatch( &pdn, &p->e_nname ) ) {
+ rs->sr_matched = ber_strdup_x( p->e_name.bv_val,
+ op->o_tmpmemctx );
+ rs->sr_ref = is_entry_referral( p )
+ ? get_entry_referrals( op, p )
+ : NULL;
+ bdb_unlocked_cache_return_entry_r( &bdb->bi_cache, p );
+ p = NULL;
+ Debug( LDAP_DEBUG_TRACE,
+ LDAP_XSTRING(bdb_add) ": parent "
+ "does not exist\n", 0, 0, 0 );
- if ( ! rs->sr_err ) {
- switch( opinfo.boi_err ) {
- case DB_LOCK_DEADLOCK:
- case DB_LOCK_NOTGRANTED:
- goto retry;
- }
+ rs->sr_err = LDAP_REFERRAL;
+ rs->sr_flags = REP_MATCHED_MUSTBEFREED | REP_REF_MUSTBEFREED;
+ goto return_results;
+ }
- Debug( LDAP_DEBUG_TRACE,
- LDAP_XSTRING(bdb_add) ": no write access to parent\n",
- 0, 0, 0 );
- rs->sr_err = LDAP_INSUFFICIENT_ACCESS;
- rs->sr_text = "no write access to parent";
- goto return_results;;
- }
+ rs->sr_err = access_allowed( op, p,
+ children, NULL, ACL_WADD, NULL );
- if ( is_entry_subentry( p ) ) {
- /* parent is a subentry, don't allow add */
- Debug( LDAP_DEBUG_TRACE,
- LDAP_XSTRING(bdb_add) ": parent is subentry\n",
- 0, 0, 0 );
- rs->sr_err = LDAP_OBJECT_CLASS_VIOLATION;
- rs->sr_text = "parent is a subentry";
- goto return_results;;
- }
- if ( is_entry_alias( p ) ) {
- /* parent is an alias, don't allow add */
- Debug( LDAP_DEBUG_TRACE,
- LDAP_XSTRING(bdb_add) ": parent is alias\n",
- 0, 0, 0 );
- rs->sr_err = LDAP_ALIAS_PROBLEM;
- rs->sr_text = "parent is an alias";
- goto return_results;;
+ if ( ! rs->sr_err ) {
+ switch( opinfo.boi_err ) {
+ case DB_LOCK_DEADLOCK:
+ case DB_LOCK_NOTGRANTED:
+ goto retry;
}
- if ( is_entry_referral( p ) ) {
- /* parent is a referral, don't allow add */
- rs->sr_matched = ber_strdup_x( p->e_name.bv_val,
- op->o_tmpmemctx );
- rs->sr_ref = get_entry_referrals( op, p );
- bdb_unlocked_cache_return_entry_r( &bdb->bi_cache, p );
- p = NULL;
- Debug( LDAP_DEBUG_TRACE,
- LDAP_XSTRING(bdb_add) ": parent is referral\n",
- 0, 0, 0 );
-
- rs->sr_err = LDAP_REFERRAL;
- rs->sr_flags = REP_MATCHED_MUSTBEFREED | REP_REF_MUSTBEFREED;
- goto return_results;
- }
+ Debug( LDAP_DEBUG_TRACE,
+ LDAP_XSTRING(bdb_add) ": no write access to parent\n",
+ 0, 0, 0 );
+ rs->sr_err = LDAP_INSUFFICIENT_ACCESS;
+ rs->sr_text = "no write access to parent";
+ goto return_results;;
+ }
- if ( subentry ) {
- /* FIXME: */
- /* parent must be an administrative point of the required kind */
- }
+ if ( is_entry_subentry( p ) ) {
+ /* parent is a subentry, don't allow add */
+ Debug( LDAP_DEBUG_TRACE,
+ LDAP_XSTRING(bdb_add) ": parent is subentry\n",
+ 0, 0, 0 );
+ rs->sr_err = LDAP_OBJECT_CLASS_VIOLATION;
+ rs->sr_text = "parent is a subentry";
+ goto return_results;;
+ }
+ if ( is_entry_alias( p ) ) {
+ /* parent is an alias, don't allow add */
+ Debug( LDAP_DEBUG_TRACE,
+ LDAP_XSTRING(bdb_add) ": parent is alias\n",
+ 0, 0, 0 );
+ rs->sr_err = LDAP_ALIAS_PROBLEM;
+ rs->sr_text = "parent is an alias";
+ goto return_results;;
+ }
- /* free parent and reader lock */
+ if ( is_entry_referral( p ) ) {
+ /* parent is a referral, don't allow add */
+ rs->sr_matched = ber_strdup_x( p->e_name.bv_val,
+ op->o_tmpmemctx );
+ rs->sr_ref = get_entry_referrals( op, p );
bdb_unlocked_cache_return_entry_r( &bdb->bi_cache, p );
p = NULL;
+ Debug( LDAP_DEBUG_TRACE,
+ LDAP_XSTRING(bdb_add) ": parent is referral\n",
+ 0, 0, 0 );
- } else {
- /*
- * no parent!
- * if not attempting to add entry at suffix or with parent ""
- */
- if ((( !be_isroot( op ) && !be_shadow_update(op) )
- || pdn.bv_len > 0 ) && !is_entry_glue( op->oq_add.rs_e ))
- {
- Debug( LDAP_DEBUG_TRACE,
- LDAP_XSTRING(bdb_add) ": %s denied\n",
- pdn.bv_len == 0 ? "suffix" : "entry at root",
- 0, 0 );
- rs->sr_err = LDAP_NO_SUCH_OBJECT;
- goto return_results;
- }
+ rs->sr_err = LDAP_REFERRAL;
+ rs->sr_flags = REP_MATCHED_MUSTBEFREED | REP_REF_MUSTBEFREED;
+ goto return_results;
+ }
+
+ if ( subentry ) {
+ /* FIXME: */
+ /* parent must be an administrative point of the required kind */
+ }
+
+ /* free parent and reader lock */
+ if ( p != (Entry *)&slap_entry_root ) {
+ bdb_unlocked_cache_return_entry_r( &bdb->bi_cache, p );
}
+ p = NULL;
rs->sr_err = access_allowed( op, op->oq_add.rs_e,
entry, NULL, ACL_WADD, NULL );
diff --git a/servers/slapd/back-bdb/cache.c b/servers/slapd/back-bdb/cache.c
index 4bff759a9e14febe0c78280a9b83661b7343feb9..ae7ef6c0ea61fa78b4aadb688fbd656d526ba387 100644
--- a/servers/slapd/back-bdb/cache.c
+++ b/servers/slapd/back-bdb/cache.c
@@ -146,7 +146,7 @@ bdb_cache_entry_db_unlock ( DB_ENV *env, DB_LOCK *lock )
#else
int rc;
- if ( !lock ) return 0;
+ if ( !lock || lock->mode == DB_LOCK_NG ) return 0;
rc = LOCK_PUT ( env, lock );
return rc;
@@ -556,7 +556,9 @@ bdb_cache_lru_add(
lockp = NULL;
}
- ldap_pvt_thread_mutex_lock( &bdb->bi_cache.lru_tail_mutex );
+ /* Don't bother if we can't get the lock */
+ if ( ldap_pvt_thread_mutex_trylock( &bdb->bi_cache.lru_tail_mutex ) )
+ return;
/* Look for an unused entry to remove */
for (elru = bdb->bi_cache.c_lrutail; elru; elru = elprev ) {
@@ -568,7 +570,6 @@ bdb_cache_lru_add(
if ( bdb_cache_entry_db_lock( bdb->bi_dbenv,
bdb->bi_cache.c_locker, elru, 1, 1, lockp ) == 0 ) {
- int stop = 0;
/* If this node is in the process of linking into the cache,
* or this node is being deleted, skip it.
@@ -608,16 +609,12 @@ bdb_cache_lru_add(
}
bdb_cache_entry_db_unlock( bdb->bi_dbenv, lockp );
- if ( count == bdb->bi_cache.c_minfree ) {
+ if ( count >= bdb->bi_cache.c_minfree ) {
ldap_pvt_thread_rdwr_wlock( &bdb->bi_cache.c_rwlock );
- bdb->bi_cache.c_cursize -= bdb->bi_cache.c_minfree;
- if ( bdb->bi_cache.c_maxsize - bdb->bi_cache.c_cursize >=
- bdb->bi_cache.c_minfree )
- stop = 1;
- count = 0;
+ bdb->bi_cache.c_cursize -= count;
ldap_pvt_thread_rdwr_wunlock( &bdb->bi_cache.c_rwlock );
+ break;
}
- if (stop) break;
}
}
@@ -1019,6 +1016,10 @@ bdb_cache_modrdn(
avl_delete( &pei->bei_kids, (caddr_t) ei, bdb_rdn_cmp );
free( ei->bei_nrdn.bv_val );
ber_dupbv( &ei->bei_nrdn, nrdn );
+
+ if ( !pei->bei_kids )
+ pei->bei_state |= CACHE_ENTRY_NO_KIDS | CACHE_ENTRY_NO_GRANDKIDS;
+
#ifdef BDB_HIER
free( ei->bei_rdn.bv_val );
@@ -1029,6 +1030,8 @@ bdb_cache_modrdn(
rdn.bv_len = ptr - rdn.bv_val;
}
ber_dupbv( &ei->bei_rdn, &rdn );
+ pei->bei_ckids--;
+ if ( pei->bei_dkids ) pei->bei_dkids--;
#endif
if (!ein) {
@@ -1038,7 +1041,16 @@ bdb_cache_modrdn(
bdb_cache_entryinfo_unlock( pei );
bdb_cache_entryinfo_lock( ein );
}
+ /* parent now has kids */
+ if ( ein->bei_state & CACHE_ENTRY_NO_KIDS )
+ ein->bei_state ^= CACHE_ENTRY_NO_KIDS;
+
#ifdef BDB_HIER
+ /* parent might now have grandkids */
+ if ( ein->bei_state & CACHE_ENTRY_NO_GRANDKIDS &&
+ !(ei->bei_state & (CACHE_ENTRY_NO_KIDS)))
+ ein->bei_state ^= CACHE_ENTRY_NO_GRANDKIDS;
+
{
/* Record the generation number of this change */
ldap_pvt_thread_mutex_lock( &bdb->bi_modrdns_mutex );
@@ -1046,6 +1058,8 @@ bdb_cache_modrdn(
ei->bei_modrdns = bdb->bi_modrdns;
ldap_pvt_thread_mutex_unlock( &bdb->bi_modrdns_mutex );
}
+ ein->bei_ckids++;
+ if ( ein->bei_dkids ) ein->bei_dkids++;
#endif
avl_insert( &ein->bei_kids, ei, bdb_rdn_cmp, avl_dup_error );
bdb_cache_entryinfo_unlock( ein );
diff --git a/servers/slapd/back-bdb/dn2entry.c b/servers/slapd/back-bdb/dn2entry.c
index 1814cc22c77d55276b6504dbb157a06bf199ff16..1ba92956ce986a5d664dd4fe319ffb10dfb0f078 100644
--- a/servers/slapd/back-bdb/dn2entry.c
+++ b/servers/slapd/back-bdb/dn2entry.c
@@ -56,8 +56,11 @@ bdb_dn2entry(
rc2 = bdb_cache_find_id( op, tid, ei->bei_id,
&ei, 1, locker, lock );
if ( rc2 ) rc = rc2;
- } else if ( ei )
+ } else if ( ei ) {
bdb_cache_entryinfo_unlock( ei );
+ memset( lock, 0, sizeof( *lock ));
+ lock->mode = DB_LOCK_NG;
+ }
} else if ( ei ) {
bdb_cache_entryinfo_unlock( ei );
}
diff --git a/servers/slapd/back-dnssrv/referral.c b/servers/slapd/back-dnssrv/referral.c
index 10da6a724ad43c2adea27b4f796f4105906e7466..586a538a79bc773d9545ffed68229e1324d0b2e0 100644
--- a/servers/slapd/back-dnssrv/referral.c
+++ b/servers/slapd/back-dnssrv/referral.c
@@ -42,13 +42,11 @@ dnssrv_back_referrals(
BerVarray urls = NULL;
if ( BER_BVISEMPTY( &op->o_req_dn ) ) {
-#ifdef LDAP_DEVEL
/* FIXME: need some means to determine whether the database
* is a glue instance */
if ( SLAP_GLUE_INSTANCE( op->o_bd ) ) {
return LDAP_SUCCESS;
}
-#endif /* LDAP_DEVEL */
rs->sr_text = "DNS SRV operation upon null (empty) DN disallowed";
return LDAP_UNWILLING_TO_PERFORM;
diff --git a/servers/slapd/back-dnssrv/search.c b/servers/slapd/back-dnssrv/search.c
index b010c40dee5537534679d4f384e164fd744f8546..3cbc89647c3104dcd425604a288f07faf4f86127 100644
--- a/servers/slapd/back-dnssrv/search.c
+++ b/servers/slapd/back-dnssrv/search.c
@@ -48,7 +48,6 @@ dnssrv_back_search(
rs->sr_ref = NULL;
if ( BER_BVISEMPTY( &op->o_req_ndn ) ) {
-#ifdef LDAP_DEVEL
/* FIXME: need some means to determine whether the database
* is a glue instance; if we got here with empty DN, then
* we passed this same test in dnssrv_back_referrals() */
@@ -60,7 +59,6 @@ dnssrv_back_search(
rs->sr_err = LDAP_SUCCESS;
}
goto done;
-#endif /* LDAP_DEVEL */
}
manageDSAit = get_manageDSAit( op );
diff --git a/servers/slapd/back-ldap/add.c b/servers/slapd/back-ldap/add.c
index 94cab8eda6edebd2aa79c43b614116041ccddbdb..e79f847bc64424390f40e508364cc0246c0126f7 100644
--- a/servers/slapd/back-ldap/add.c
+++ b/servers/slapd/back-ldap/add.c
@@ -36,18 +36,18 @@ ldap_back_add(
Operation *op,
SlapReply *rs )
{
- ldapinfo_t *li = (ldapinfo_t *)op->o_bd->be_private;
-
- ldapconn_t *lc;
- int i = 0,
- j = 0;
- Attribute *a;
- LDAPMod **attrs = NULL,
- *attrs2 = NULL;
- ber_int_t msgid;
- int isupdate;
- int do_retry = 1;
- LDAPControl **ctrls = NULL;
+ ldapinfo_t *li = (ldapinfo_t *)op->o_bd->be_private;
+
+ ldapconn_t *lc;
+ int i = 0,
+ j = 0;
+ Attribute *a;
+ LDAPMod **attrs = NULL,
+ *attrs2 = NULL;
+ ber_int_t msgid;
+ int isupdate;
+ ldap_back_send_t retrying = LDAP_BACK_RETRYING;
+ LDAPControl **ctrls = NULL;
rs->sr_err = LDAP_SUCCESS;
@@ -93,7 +93,8 @@ ldap_back_add(
attrs[ i ] = NULL;
ctrls = op->o_ctrls;
- rs->sr_err = ldap_back_proxy_authz_ctrl( lc, op, rs, &ctrls );
+ rs->sr_err = ldap_back_proxy_authz_ctrl( &lc->lc_bound_ndn,
+ li->li_version, &li->li_idassert, op, rs, &ctrls );
if ( rs->sr_err != LDAP_SUCCESS ) {
send_ldap_result( op, rs );
goto cleanup;
@@ -103,9 +104,10 @@ retry:
rs->sr_err = ldap_add_ext( lc->lc_ld, op->o_req_dn.bv_val, attrs,
ctrls, NULL, &msgid );
rs->sr_err = ldap_back_op_result( lc, op, rs, msgid,
- li->li_timeout[ LDAP_BACK_OP_ADD ], LDAP_BACK_SENDRESULT );
- if ( rs->sr_err == LDAP_UNAVAILABLE && do_retry ) {
- do_retry = 0;
+ li->li_timeout[ LDAP_BACK_OP_ADD ],
+ ( LDAP_BACK_SENDRESULT | retrying ) );
+ if ( rs->sr_err == LDAP_UNAVAILABLE && retrying ) {
+ retrying &= ~LDAP_BACK_RETRYING;
if ( ldap_back_retry( &lc, op, rs, LDAP_BACK_SENDERR ) ) {
goto retry;
}
diff --git a/servers/slapd/back-ldap/back-ldap.h b/servers/slapd/back-ldap/back-ldap.h
index e8e73cc462679fbcf91420b7c64af0bffa88f89c..a1fb091f311964d3cfc9077515d1c63ad77f50ca 100644
--- a/servers/slapd/back-ldap/back-ldap.h
+++ b/servers/slapd/back-ldap/back-ldap.h
@@ -26,6 +26,8 @@
LDAP_BEGIN_DECL
+struct ldapinfo_t;
+
typedef struct ldapconn_t {
Connection *lc_conn;
#define LDAP_BACK_PCONN ((void *)0x0)
@@ -42,18 +44,23 @@ typedef struct ldapconn_t {
struct berval lc_bound_ndn;
struct berval lc_local_ndn;
unsigned lc_lcflags;
-#define LDAP_BACK_CONN_ISSET(lc,f) ((lc)->lc_lcflags & (f))
-#define LDAP_BACK_CONN_SET(lc,f) ((lc)->lc_lcflags |= (f))
-#define LDAP_BACK_CONN_CLEAR(lc,f) ((lc)->lc_lcflags &= ~(f))
-#define LDAP_BACK_CONN_CPY(lc,f,mlc) \
+#define LDAP_BACK_CONN_ISSET_F(fp,f) (*(fp) & (f))
+#define LDAP_BACK_CONN_SET_F(fp,f) (*(fp) |= (f))
+#define LDAP_BACK_CONN_CLEAR_F(fp,f) (*(fp) &= ~(f))
+#define LDAP_BACK_CONN_CPY_F(fp,f,mfp) \
do { \
- if ( ((f) & (mlc)->lc_lcflags) == (f) ) { \
- (lc)->lc_lcflags |= (f); \
+ if ( ((f) & *(mfp)) == (f) ) { \
+ *(fp) |= (f); \
} else { \
- (lc)->lc_lcflags &= ~(f); \
+ *(fp) &= ~(f); \
} \
} while ( 0 )
+#define LDAP_BACK_CONN_ISSET(lc,f) LDAP_BACK_CONN_ISSET_F(&(lc)->lc_lcflags, (f))
+#define LDAP_BACK_CONN_SET(lc,f) LDAP_BACK_CONN_SET_F(&(lc)->lc_lcflags, (f))
+#define LDAP_BACK_CONN_CLEAR(lc,f) LDAP_BACK_CONN_CLEAR_F(&(lc)->lc_lcflags, (f))
+#define LDAP_BACK_CONN_CPY(lc,f,mlc) LDAP_BACK_CONN_CPY_F(&(lc)->lc_lcflags, (f), &(mlc)->lc_lcflags)
+
#define LDAP_BACK_FCONN_ISBOUND (0x00000001U)
#define LDAP_BACK_FCONN_ISANON (0x00000002U)
#define LDAP_BACK_FCONN_ISBMASK (LDAP_BACK_FCONN_ISBOUND|LDAP_BACK_FCONN_ISANON)
@@ -94,18 +101,6 @@ typedef struct ldapconn_t {
time_t lc_time;
} ldapconn_t;
-/*
- * identity assertion modes
- */
-enum {
- LDAP_BACK_IDASSERT_LEGACY = 1,
- LDAP_BACK_IDASSERT_NOASSERT,
- LDAP_BACK_IDASSERT_ANONYMOUS,
- LDAP_BACK_IDASSERT_SELF,
- LDAP_BACK_IDASSERT_OTHERDN,
- LDAP_BACK_IDASSERT_OTHERID
-};
-
/*
* operation enumeration for timeouts
*/
@@ -122,13 +117,72 @@ typedef struct ldap_avl_info_t {
Avlnode *lai_tree;
} ldap_avl_info_t;
+typedef struct slap_retry_info_t {
+ time_t *ri_interval;
+ int *ri_num;
+ int ri_idx;
+ int ri_count;
+ time_t ri_last;
+
+#define SLAP_RETRYNUM_FOREVER (-1) /* retry forever */
+#define SLAP_RETRYNUM_TAIL (-2) /* end of retrynum array */
+#define SLAP_RETRYNUM_VALID(n) ((n) >= SLAP_RETRYNUM_FOREVER) /* valid retrynum */
+#define SLAP_RETRYNUM_FINITE(n) ((n) > SLAP_RETRYNUM_FOREVER) /* not forever */
+} slap_retry_info_t;
+
+/*
+ * identity assertion modes
+ */
+typedef enum {
+ LDAP_BACK_IDASSERT_LEGACY = 1,
+ LDAP_BACK_IDASSERT_NOASSERT,
+ LDAP_BACK_IDASSERT_ANONYMOUS,
+ LDAP_BACK_IDASSERT_SELF,
+ LDAP_BACK_IDASSERT_OTHERDN,
+ LDAP_BACK_IDASSERT_OTHERID
+} slap_idassert_mode_t;
+
+/* ID assert stuff */
+typedef struct slap_idassert_t {
+ slap_idassert_mode_t si_mode;
+#define li_idassert_mode li_idassert.si_mode
+
+ slap_bindconf si_bc;
+#define li_idassert_authcID li_idassert.si_bc.sb_authcId
+#define li_idassert_authcDN li_idassert.si_bc.sb_binddn
+#define li_idassert_passwd li_idassert.si_bc.sb_cred
+#define li_idassert_authzID li_idassert.si_bc.sb_authzId
+#define li_idassert_authmethod li_idassert.si_bc.sb_method
+#define li_idassert_sasl_mech li_idassert.si_bc.sb_saslmech
+#define li_idassert_sasl_realm li_idassert.si_bc.sb_realm
+#define li_idassert_secprops li_idassert.si_bc.sb_secprops
+#define li_idassert_tls li_idassert.si_bc.sb_tls
+
+ unsigned si_flags;
+#define LDAP_BACK_AUTH_NONE 0x00U
+#define LDAP_BACK_AUTH_NATIVE_AUTHZ 0x01U
+#define LDAP_BACK_AUTH_OVERRIDE 0x02U
+#define LDAP_BACK_AUTH_PRESCRIPTIVE 0x04U
+#define LDAP_BACK_AUTH_OBSOLETE_PROXY_AUTHZ 0x08U
+#define LDAP_BACK_AUTH_OBSOLETE_ENCODING_WORKAROUND 0x10U
+#define li_idassert_flags li_idassert.si_flags
+
+ BerVarray si_authz;
+#define li_idassert_authz li_idassert.si_authz
+} slap_idassert_t;
+
+/*
+ * Hook to allow mucking with ldapinfo_t when quarantine is over
+ */
+typedef int (*ldap_back_quarantine_f)( struct ldapinfo_t *, void * );
+
typedef struct ldapinfo_t {
/* li_uri: the string that goes into ldap_initialize()
* TODO: use li_acl.sb_uri instead */
- char *li_uri;
+ char *li_uri;
/* li_bvuri: an array of each single URI that is equivalent;
* to be checked for the presence of a certain item */
- BerVarray li_bvuri;
+ BerVarray li_bvuri;
ldap_pvt_thread_mutex_t li_uri_mutex;
LDAP_REBIND_PROC *li_rebind_f;
@@ -146,27 +200,7 @@ typedef struct ldapinfo_t {
#define li_acl_secprops li_acl.sb_secprops
/* ID assert stuff */
- int li_idassert_mode;
-
- slap_bindconf li_idassert;
-#define li_idassert_authcID li_idassert.sb_authcId
-#define li_idassert_authcDN li_idassert.sb_binddn
-#define li_idassert_passwd li_idassert.sb_cred
-#define li_idassert_authzID li_idassert.sb_authzId
-#define li_idassert_authmethod li_idassert.sb_method
-#define li_idassert_sasl_mech li_idassert.sb_saslmech
-#define li_idassert_sasl_realm li_idassert.sb_realm
-#define li_idassert_secprops li_idassert.sb_secprops
-
- unsigned li_idassert_flags;
-#define LDAP_BACK_AUTH_NONE 0x00U
-#define LDAP_BACK_AUTH_NATIVE_AUTHZ 0x01U
-#define LDAP_BACK_AUTH_OVERRIDE 0x02U
-#define LDAP_BACK_AUTH_PRESCRIPTIVE 0x04U
-#define LDAP_BACK_AUTH_OBSOLETE_PROXY_AUTHZ 0x08U
-#define LDAP_BACK_AUTH_OBSOLETE_ENCODING_WORKAROUND 0x10U
-
- BerVarray li_idassert_authz;
+ slap_idassert_t li_idassert;
/* end of ID assert stuff */
int li_nretries;
@@ -176,38 +210,72 @@ typedef struct ldapinfo_t {
#define LDAP_BACK_RETRY_DEFAULT (3)
unsigned li_flags;
-#define LDAP_BACK_F_NONE 0x0000U
-#define LDAP_BACK_F_SAVECRED 0x0001U
-#define LDAP_BACK_F_USE_TLS 0x0002U
-#define LDAP_BACK_F_PROPAGATE_TLS 0x0004U
-#define LDAP_BACK_F_TLS_CRITICAL 0x0008U
+#define LDAP_BACK_F_NONE (0x0000U)
+#define LDAP_BACK_F_SAVECRED (0x0001U)
+#define LDAP_BACK_F_USE_TLS (0x0002U)
+#define LDAP_BACK_F_PROPAGATE_TLS (0x0004U)
+#define LDAP_BACK_F_TLS_CRITICAL (0x0008U)
#define LDAP_BACK_F_TLS_USE_MASK (LDAP_BACK_F_USE_TLS|LDAP_BACK_F_TLS_CRITICAL)
#define LDAP_BACK_F_TLS_PROPAGATE_MASK (LDAP_BACK_F_PROPAGATE_TLS|LDAP_BACK_F_TLS_CRITICAL)
#define LDAP_BACK_F_TLS_MASK (LDAP_BACK_F_TLS_USE_MASK|LDAP_BACK_F_TLS_PROPAGATE_MASK)
-#define LDAP_BACK_F_CHASE_REFERRALS 0x0010U
-#define LDAP_BACK_F_PROXY_WHOAMI 0x0020U
+#define LDAP_BACK_F_CHASE_REFERRALS (0x0010U)
+#define LDAP_BACK_F_PROXY_WHOAMI (0x0020U)
+
+#define LDAP_BACK_F_T_F (0x0040U)
+#define LDAP_BACK_F_T_F_DISCOVER (0x0080U)
+#define LDAP_BACK_F_T_F_MASK (LDAP_BACK_F_T_F)
+#define LDAP_BACK_F_T_F_MASK2 (LDAP_BACK_F_T_F_MASK|LDAP_BACK_F_T_F_DISCOVER)
+
+#define LDAP_BACK_F_MONITOR (0x0100U)
+#define LDAP_BACK_F_SINGLECONN (0x0200U)
-#define LDAP_BACK_F_SUPPORT_T_F_DISCOVER 0x0040U
-#define LDAP_BACK_F_SUPPORT_T_F 0x0080U
-#define LDAP_BACK_F_SUPPORT_T_F_MASK (LDAP_BACK_F_SUPPORT_T_F|LDAP_BACK_F_SUPPORT_T_F_DISCOVER)
+#define LDAP_BACK_F_ISOPEN (0x0400U)
-#define LDAP_BACK_F_MONITOR 0x0100U
-#define LDAP_BACK_F_SINGLECONN 0x0200U
+#define LDAP_BACK_F_CANCEL_ABANDON (0x0000U)
+#define LDAP_BACK_F_CANCEL_IGNORE (0x1000U)
+#define LDAP_BACK_F_CANCEL_EXOP (0x2000U)
+#define LDAP_BACK_F_CANCEL_EXOP_DISCOVER (0x4000U)
+#define LDAP_BACK_F_CANCEL_MASK (LDAP_BACK_F_CANCEL_IGNORE|LDAP_BACK_F_CANCEL_EXOP)
+#define LDAP_BACK_F_CANCEL_MASK2 (LDAP_BACK_F_CANCEL_MASK|LDAP_BACK_F_CANCEL_EXOP_DISCOVER)
#define LDAP_BACK_ISSET(li,f) ( ( (li)->li_flags & (f) ) == (f) )
+#define LDAP_BACK_ISMASK(li,m,f) ( ( (li)->li_flags & (m) ) == (f) )
+
#define LDAP_BACK_SAVECRED(li) LDAP_BACK_ISSET( (li), LDAP_BACK_F_SAVECRED )
#define LDAP_BACK_USE_TLS(li) LDAP_BACK_ISSET( (li), LDAP_BACK_F_USE_TLS )
#define LDAP_BACK_PROPAGATE_TLS(li) LDAP_BACK_ISSET( (li), LDAP_BACK_F_PROPAGATE_TLS )
#define LDAP_BACK_TLS_CRITICAL(li) LDAP_BACK_ISSET( (li), LDAP_BACK_F_TLS_CRITICAL )
#define LDAP_BACK_CHASE_REFERRALS(li) LDAP_BACK_ISSET( (li), LDAP_BACK_F_CHASE_REFERRALS )
#define LDAP_BACK_PROXY_WHOAMI(li) LDAP_BACK_ISSET( (li), LDAP_BACK_F_PROXY_WHOAMI )
+
+#define LDAP_BACK_T_F(li) LDAP_BACK_ISMASK( (li), LDAP_BACK_F_T_F_MASK, LDAP_BACK_F_T_F )
+#define LDAP_BACK_T_F_DISCOVER(li) LDAP_BACK_ISMASK( (li), LDAP_BACK_F_T_F_MASK2, LDAP_BACK_F_T_F_DISCOVER )
+
#define LDAP_BACK_MONITOR(li) LDAP_BACK_ISSET( (li), LDAP_BACK_F_MONITOR )
#define LDAP_BACK_SINGLECONN(li) LDAP_BACK_ISSET( (li), LDAP_BACK_F_SINGLECONN )
+#define LDAP_BACK_ISOPEN(li) LDAP_BACK_ISSET( (li), LDAP_BACK_F_ISOPEN )
+
+#define LDAP_BACK_ABANDON(li) LDAP_BACK_ISMASK( (li), LDAP_BACK_F_CANCEL_MASK, LDAP_BACK_F_CANCEL_ABANDON )
+#define LDAP_BACK_IGNORE(li) LDAP_BACK_ISMASK( (li), LDAP_BACK_F_CANCEL_MASK, LDAP_BACK_F_CANCEL_IGNORE )
+#define LDAP_BACK_CANCEL(li) LDAP_BACK_ISMASK( (li), LDAP_BACK_F_CANCEL_MASK, LDAP_BACK_F_CANCEL_EXOP )
+#define LDAP_BACK_CANCEL_DISCOVER(li) LDAP_BACK_ISMASK( (li), LDAP_BACK_F_CANCEL_MASK2, LDAP_BACK_F_CANCEL_EXOP_DISCOVER )
+
int li_version;
ldap_avl_info_t li_conninfo;
+ sig_atomic_t li_isquarantined;
+#define LDAP_BACK_FQ_NO (0)
+#define LDAP_BACK_FQ_YES (1)
+#define LDAP_BACK_FQ_RETRYING (2)
+
+ slap_retry_info_t li_quarantine;
+#define LDAP_BACK_QUARANTINE(li) ( (li)->li_quarantine.ri_num != NULL )
+ ldap_pvt_thread_mutex_t li_quarantine_mutex;
+ ldap_back_quarantine_f li_quarantine_f;
+ void *li_quarantine_p;
+
time_t li_network_timeout;
time_t li_conn_ttl;
time_t li_idle_timeout;
@@ -220,10 +288,17 @@ typedef enum ldap_back_send_t {
LDAP_BACK_SENDERR = 0x02,
LDAP_BACK_SENDRESULT = (LDAP_BACK_SENDOK|LDAP_BACK_SENDERR),
LDAP_BACK_BINDING = 0x04,
+
LDAP_BACK_BIND_DONTSEND = (LDAP_BACK_BINDING),
LDAP_BACK_BIND_SOK = (LDAP_BACK_BINDING|LDAP_BACK_SENDOK),
LDAP_BACK_BIND_SERR = (LDAP_BACK_BINDING|LDAP_BACK_SENDERR),
- LDAP_BACK_BIND_SRES = (LDAP_BACK_BINDING|LDAP_BACK_SENDRESULT)
+ LDAP_BACK_BIND_SRES = (LDAP_BACK_BINDING|LDAP_BACK_SENDRESULT),
+
+ LDAP_BACK_RETRYING = 0x08,
+ LDAP_BACK_RETRY_DONTSEND = (LDAP_BACK_RETRYING),
+ LDAP_BACK_RETRY_SOK = (LDAP_BACK_RETRYING|LDAP_BACK_SENDOK),
+ LDAP_BACK_RETRY_SERR = (LDAP_BACK_RETRYING|LDAP_BACK_SENDERR),
+ LDAP_BACK_RETRY_SRES = (LDAP_BACK_RETRYING|LDAP_BACK_SENDRESULT)
} ldap_back_send_t;
/* define to use asynchronous StartTLS */
diff --git a/servers/slapd/back-ldap/bind.c b/servers/slapd/back-ldap/bind.c
index 44d621d45c383e48e23dd3eaffd5b448bff98cbf..3df85b3cce1ab5fa340e6d332419dbdce2f99cac 100644
--- a/servers/slapd/back-ldap/bind.c
+++ b/servers/slapd/back-ldap/bind.c
@@ -33,7 +33,7 @@
#include "slap.h"
#include "back-ldap.h"
-#include <lutil_ldap.h>
+#include "lutil_ldap.h"
#ifndef PRINT_CONNTREE
#define PRINT_CONNTREE 0
@@ -182,7 +182,7 @@ retry_lock:;
"=>ldap_back_bind: destroying conn %ld (refcnt=%u)\n",
LDAP_BACK_PCONN_ID( lc->lc_conn ), lc->lc_refcnt, 0 );
- if ( lc->lc_refcnt != 0 ) {
+ if ( tmplc->lc_refcnt != 0 ) {
/* taint it */
LDAP_BACK_CONN_TAINTED_SET( tmplc );
@@ -600,6 +600,37 @@ ldap_back_getconn( Operation *op, SlapReply *rs, ldap_back_send_t sendok )
lc_curr = { 0 };
int refcnt = 1, binding = 1;
+ /* if the server is quarantined, and
+ * - the current interval did not expire yet, or
+ * - no more retries should occur,
+ * don't return the connection */
+ if ( li->li_isquarantined ) {
+ slap_retry_info_t *ri = &li->li_quarantine;
+ int dont_retry = 1;
+
+ ldap_pvt_thread_mutex_lock( &li->li_quarantine_mutex );
+ if ( li->li_isquarantined == LDAP_BACK_FQ_YES ) {
+ dont_retry = ( ri->ri_num[ ri->ri_idx ] == SLAP_RETRYNUM_TAIL
+ || slap_get_time() < ri->ri_last + ri->ri_interval[ ri->ri_idx ] );
+ if ( !dont_retry ) {
+ Debug( LDAP_DEBUG_ANY,
+ "%s: ldap_back_getconn quarantine "
+ "retry block #%d try #%d.\n",
+ op->o_log_prefix, ri->ri_idx, ri->ri_count );
+ li->li_isquarantined = LDAP_BACK_FQ_RETRYING;
+ }
+ }
+ ldap_pvt_thread_mutex_unlock( &li->li_quarantine_mutex );
+
+ if ( dont_retry ) {
+ rs->sr_err = LDAP_UNAVAILABLE;
+ if ( op->o_conn && ( sendok & LDAP_BACK_SENDERR ) ) {
+ send_ldap_result( op, rs );
+ }
+ return NULL;
+ }
+ }
+
/* Internal searches are privileged and shared. So is root. */
if ( op->o_do_not_cache || be_isroot( op ) ) {
LDAP_BACK_CONN_ISPRIV_SET( &lc_curr );
@@ -632,6 +663,7 @@ retry_lock:
ldap_pvt_thread_yield();
goto retry_lock;
}
+
refcnt = ++lc->lc_refcnt;
binding = ++lc->lc_binding;
}
@@ -742,7 +774,6 @@ retry_lock:
}
} else {
- char buf[ SLAP_TEXT_BUFLEN ];
int expiring = 0;
if ( ( li->li_idle_timeout != 0 && op->o_time > lc->lc_time + li->li_idle_timeout )
@@ -760,13 +791,14 @@ retry_lock:
}
if ( LogTest( LDAP_DEBUG_TRACE ) ) {
+ char buf[ SLAP_TEXT_BUFLEN ];
+
snprintf( buf, sizeof( buf ),
"conn %p fetched refcnt=%u binding=%u%s",
(void *)lc, refcnt, binding, expiring ? " expiring" : "" );
Debug( LDAP_DEBUG_TRACE,
"=>ldap_back_getconn: %s.\n", buf, 0, 0 );
}
-
}
#ifdef HAVE_TLS
@@ -802,6 +834,73 @@ ldap_back_release_conn_lock(
}
}
+void
+ldap_back_quarantine(
+ Operation *op,
+ SlapReply *rs )
+{
+ ldapinfo_t *li = (ldapinfo_t *)op->o_bd->be_private;
+
+ slap_retry_info_t *ri = &li->li_quarantine;
+
+ ldap_pvt_thread_mutex_lock( &li->li_quarantine_mutex );
+
+ if ( rs->sr_err == LDAP_UNAVAILABLE ) {
+ time_t new_last = slap_get_time();
+
+ switch ( li->li_isquarantined ) {
+ case LDAP_BACK_FQ_NO:
+ if ( ri->ri_last == new_last ) {
+ goto done;
+ }
+
+ Debug( LDAP_DEBUG_ANY,
+ "%s: ldap_back_quarantine enter.\n",
+ op->o_log_prefix, 0, 0 );
+
+ ri->ri_idx = 0;
+ ri->ri_count = 0;
+ break;
+
+ case LDAP_BACK_FQ_RETRYING:
+ Debug( LDAP_DEBUG_ANY,
+ "%s: ldap_back_quarantine block #%d try #%d failed.\n",
+ op->o_log_prefix, ri->ri_idx, ri->ri_count );
+
+ ++ri->ri_count;
+ if ( ri->ri_num[ ri->ri_idx ] != SLAP_RETRYNUM_FOREVER
+ && ri->ri_count == ri->ri_num[ ri->ri_idx ] )
+ {
+ ri->ri_count = 0;
+ ++ri->ri_idx;
+ }
+ break;
+
+ default:
+ break;
+ }
+
+ li->li_isquarantined = LDAP_BACK_FQ_YES;
+ ri->ri_last = new_last;
+
+ } else if ( li->li_isquarantined != LDAP_BACK_FQ_NO ) {
+ Debug( LDAP_DEBUG_ANY,
+ "%s: ldap_back_quarantine exit.\n",
+ op->o_log_prefix, ri->ri_idx, ri->ri_count );
+
+ if ( li->li_quarantine_f ) {
+ (void)li->li_quarantine_f( li, li->li_quarantine_p );
+ }
+
+ ri->ri_count = 0;
+ ri->ri_idx = 0;
+ li->li_isquarantined = LDAP_BACK_FQ_NO;
+ }
+
+done:;
+ ldap_pvt_thread_mutex_unlock( &li->li_quarantine_mutex );
+}
+
/*
* ldap_back_dobind
*
@@ -872,24 +971,6 @@ retry_lock:;
ldap_pvt_thread_mutex_unlock( &li->li_conninfo.lai_mutex );
}
-#if 0
- while ( lc->lc_refcnt > 1 ) {
- ldap_pvt_thread_yield();
- rc = LDAP_BACK_CONN_ISBOUND( lc );
- if ( rc ) {
- return rc;
- }
- }
-
- if ( dolock ) {
- ldap_pvt_thread_mutex_lock( &li->li_conninfo.lai_mutex );
- }
- LDAP_BACK_CONN_BINDING_SET( lc );
- if ( dolock ) {
- ldap_pvt_thread_mutex_unlock( &li->li_conninfo.lai_mutex );
- }
-#endif
-
/*
* FIXME: we need to let clients use proxyAuthz
* otherwise we cannot do symmetric pools of servers;
@@ -929,7 +1010,7 @@ retry_lock:;
if ( li->li_acl_secprops != NULL ) {
rc = ldap_set_option( lc->lc_ld,
- LDAP_OPT_X_SASL_SECPROPS, li->li_acl_secprops);
+ LDAP_OPT_X_SASL_SECPROPS, li->li_acl_secprops );
if ( rc != LDAP_OPT_SUCCESS ) {
Debug( LDAP_DEBUG_ANY, "Error: ldap_set_option "
@@ -962,6 +1043,11 @@ retry_lock:;
} else {
LDAP_BACK_CONN_ISBOUND_SET( lc );
}
+
+ if ( LDAP_BACK_QUARANTINE( li ) ) {
+ ldap_back_quarantine( op, rs );
+ }
+
goto done;
}
#endif /* HAVE_CYRUS_SASL */
@@ -1012,10 +1098,15 @@ retry:;
}
}
+ /* FIXME: one binding-- too many? */
lc->lc_binding--;
ldap_back_freeconn( op, lc, dolock );
rs->sr_err = slap_map_api2result( rs );
+ if ( LDAP_BACK_QUARANTINE( li ) ) {
+ ldap_back_quarantine( op, rs );
+ }
+
return 0;
}
@@ -1114,6 +1205,35 @@ ldap_back_default_urllist(
return LDAP_SUCCESS;
}
+int
+ldap_back_cancel(
+ ldapconn_t *lc,
+ Operation *op,
+ SlapReply *rs,
+ ber_int_t msgid,
+ ldap_back_send_t sendok )
+{
+ ldapinfo_t *li = (ldapinfo_t *)op->o_bd->be_private;
+
+ /* default behavior */
+ if ( LDAP_BACK_ABANDON( li ) ) {
+ return ldap_abandon_ext( lc->lc_ld, msgid, NULL, NULL );
+ }
+
+ if ( LDAP_BACK_IGNORE( li ) ) {
+ return LDAP_SUCCESS;
+ }
+
+ if ( LDAP_BACK_CANCEL( li ) ) {
+ /* FIXME: asynchronous? */
+ return ldap_cancel_s( lc->lc_ld, msgid, NULL, NULL );
+ }
+
+ assert( 0 );
+
+ return LDAP_OTHER;
+}
+
int
ldap_back_op_result(
ldapconn_t *lc,
@@ -1123,14 +1243,19 @@ ldap_back_op_result(
time_t timeout,
ldap_back_send_t sendok )
{
+ ldapinfo_t *li = (ldapinfo_t *)op->o_bd->be_private;
+
char *match = NULL;
- LDAPMessage *res = NULL;
char *text = NULL;
+ char **refs = NULL;
+ LDAPControl **ctrls = NULL;
#define ERR_OK(err) ((err) == LDAP_SUCCESS || (err) == LDAP_COMPARE_FALSE || (err) == LDAP_COMPARE_TRUE)
rs->sr_text = NULL;
rs->sr_matched = NULL;
+ rs->sr_ref = NULL;
+ rs->sr_ctrls = NULL;
/* if the error recorded in the reply corresponds
* to a successful state, get the error from the
@@ -1138,6 +1263,7 @@ ldap_back_op_result(
if ( ERR_OK( rs->sr_err ) ) {
int rc;
struct timeval tv;
+ LDAPMessage *res = NULL;
if ( timeout ) {
tv.tv_sec = timeout;
@@ -1153,9 +1279,9 @@ retry:;
switch ( rc ) {
case 0:
if ( timeout ) {
- (void)ldap_abandon_ext( lc->lc_ld, msgid, NULL, NULL );
+ (void)ldap_back_cancel( lc, op, rs, msgid, sendok );
rs->sr_err = op->o_protocol >= LDAP_VERSION3 ?
- LDAP_ADMINLIMIT_EXCEEDED : LDAP_OPERATIONS_ERROR;
+ LDAP_ADMINLIMIT_EXCEEDED : LDAP_OTHER;
rs->sr_text = "Operation timed out";
break;
}
@@ -1176,11 +1302,26 @@ retry:;
* LDAP_COMPARE_{TRUE|FALSE}) */
default:
rc = ldap_parse_result( lc->lc_ld, res, &rs->sr_err,
- &match, &text, NULL, NULL, 1 );
+ &match, &text, &refs, &ctrls, 1 );
rs->sr_text = text;
if ( rc != LDAP_SUCCESS ) {
rs->sr_err = rc;
}
+ if ( refs != NULL ) {
+ int i;
+
+ for ( i = 0; refs[ i ] != NULL; i++ )
+ /* count */ ;
+ rs->sr_ref = op->o_tmpalloc( sizeof( struct berval ) * ( i + 1 ),
+ op->o_tmpmemctx );
+ for ( i = 0; refs[ i ] != NULL; i++ ) {
+ ber_str2bv( refs[ i ], 0, 0, &rs->sr_ref[ i ] );
+ }
+ BER_BVZERO( &rs->sr_ref[ i ] );
+ }
+ if ( ctrls != NULL ) {
+ rs->sr_ctrls = ctrls;
+ }
}
}
@@ -1199,12 +1340,24 @@ retry:;
rs->sr_matched = match;
}
}
- if ( op->o_conn &&
- ( ( sendok & LDAP_BACK_SENDOK )
- || ( ( sendok & LDAP_BACK_SENDERR ) && rs->sr_err != LDAP_SUCCESS ) ) )
+
+ if ( rs->sr_err == LDAP_UNAVAILABLE ) {
+ if ( !( sendok & LDAP_BACK_RETRYING ) ) {
+ if ( LDAP_BACK_QUARANTINE( li ) ) {
+ ldap_back_quarantine( op, rs );
+ }
+ if ( op->o_conn && ( sendok & LDAP_BACK_SENDERR ) ) {
+ send_ldap_result( op, rs );
+ }
+ }
+
+ } else if ( op->o_conn &&
+ ( ( ( sendok & LDAP_BACK_SENDOK ) && ERR_OK( rs->sr_err ) )
+ || ( ( sendok & LDAP_BACK_SENDERR ) && rs->sr_err != LDAP_SUCCESS ) ) )
{
send_ldap_result( op, rs );
}
+
if ( match ) {
if ( rs->sr_matched != match ) {
free( (char *)rs->sr_matched );
@@ -1212,10 +1365,25 @@ retry:;
rs->sr_matched = NULL;
ldap_memfree( match );
}
+
if ( text ) {
ldap_memfree( text );
}
rs->sr_text = NULL;
+
+ if ( rs->sr_ref ) {
+ assert( refs != NULL );
+ ber_memvfree( (void **)refs );
+ op->o_tmpfree( rs->sr_ref, op->o_tmpmemctx );
+ rs->sr_ref = NULL;
+ }
+
+ if ( ctrls ) {
+ assert( rs->sr_ctrls != NULL );
+ ldap_controls_free( ctrls );
+ rs->sr_ctrls = NULL;
+ }
+
return( ERR_OK( rs->sr_err ) ? LDAP_SUCCESS : rs->sr_err );
}
@@ -1248,11 +1416,15 @@ ldap_back_retry( ldapconn_t **lcp, Operation *op, SlapReply *rs, ldap_back_send_
rc = ldap_back_prepare_conn( lcp, op, rs, sendok );
if ( rc != LDAP_SUCCESS ) {
rc = 0;
+ /* freeit, because lc_refcnt == 1 */
+ (void)ldap_back_conn_free( *lcp );
*lcp = NULL;
} else {
rc = ldap_back_dobind_int( *lcp, op, rs, sendok, 0, 0 );
- if ( rc == 0 ) {
+ if ( rc == 0 && *lcp != NULL ) {
+ /* freeit, because lc_refcnt == 1 */
+ (void)ldap_back_conn_free( *lcp );
*lcp = NULL;
}
}
@@ -1262,6 +1434,7 @@ ldap_back_retry( ldapconn_t **lcp, Operation *op, SlapReply *rs, ldap_back_send_
"ldap_back_retry: conn %p refcnt=%u unable to retry.\n",
(void *)(*lcp), (*lcp)->lc_refcnt, 0 );
+ LDAP_BACK_CONN_TAINTED_SET( *lcp );
ldap_back_release_conn_lock( op, rs, *lcp, 0 );
*lcp = NULL;
@@ -1300,6 +1473,11 @@ ldap_back_proxy_authz_bind( ldapconn_t *lc, Operation *op, SlapReply *rs, ldap_b
/* fall thru */
default:
+ rs->sr_err = LDAP_UNWILLING_TO_PERFORM;
+ if ( sendok & LDAP_BACK_SENDERR ) {
+ send_ldap_result( op, rs );
+ }
+ LDAP_BACK_CONN_ISBOUND_CLEAR( lc );
goto done;
}
@@ -1490,8 +1668,9 @@ ldap_back_proxy_authz_bind( ldapconn_t *lc, Operation *op, SlapReply *rs, ldap_b
switch ( li->li_idassert_authmethod ) {
case LDAP_AUTH_NONE:
- rc = LDAP_SUCCESS;
- break;
+ BER_BVSTR( &binddn, "" );
+ BER_BVSTR( &bindcred, "" );
+ /* fallthru */
case LDAP_AUTH_SIMPLE:
rs->sr_err = ldap_sasl_bind( lc->lc_ld,
@@ -1558,24 +1737,25 @@ done:;
*/
int
ldap_back_proxy_authz_ctrl(
- ldapconn_t *lc,
+ struct berval *bound_ndn,
+ int version,
+ slap_idassert_t *si,
Operation *op,
SlapReply *rs,
LDAPControl ***pctrls )
{
- ldapinfo_t *li = (ldapinfo_t *) op->o_bd->be_private;
- LDAPControl **ctrls = NULL;
- int i = 0,
- mode;
- struct berval assertedID,
- ndn;
+ LDAPControl **ctrls = NULL;
+ int i = 0;
+ slap_idassert_mode_t mode;
+ struct berval assertedID,
+ ndn;
*pctrls = NULL;
rs->sr_err = LDAP_SUCCESS;
/* don't proxyAuthz if protocol is not LDAPv3 */
- switch ( li->li_version ) {
+ switch ( version ) {
case LDAP_VERSION3:
break;
@@ -1592,8 +1772,8 @@ ldap_back_proxy_authz_ctrl(
/* FIXME: SASL/EXTERNAL over ldapi:// doesn't honor the authcID,
* but if it is not set this test fails. We need a different
* means to detect if idassert is enabled */
- if ( ( BER_BVISNULL( &li->li_idassert_authcID ) || BER_BVISEMPTY( &li->li_idassert_authcID ) )
- && ( BER_BVISNULL( &li->li_idassert_authcDN ) || BER_BVISEMPTY( &li->li_idassert_authcDN ) ) )
+ if ( ( BER_BVISNULL( &si->si_bc.sb_authcId ) || BER_BVISEMPTY( &si->si_bc.sb_authcId ) )
+ && ( BER_BVISNULL( &si->si_bc.sb_binddn ) || BER_BVISEMPTY( &si->si_bc.sb_binddn ) ) )
{
goto done;
}
@@ -1602,14 +1782,17 @@ ldap_back_proxy_authz_ctrl(
goto done;
}
- if ( !BER_BVISNULL( &op->o_conn->c_ndn ) ) {
+ if ( op->o_tag == LDAP_REQ_BIND ) {
+ ndn = op->o_req_ndn;
+
+ } else if ( !BER_BVISNULL( &op->o_conn->c_ndn ) ) {
ndn = op->o_conn->c_ndn;
} else {
ndn = op->o_ndn;
}
- if ( li->li_idassert_mode == LDAP_BACK_IDASSERT_LEGACY ) {
+ if ( si->si_mode == LDAP_BACK_IDASSERT_LEGACY ) {
if ( op->o_proxy_authz ) {
/*
* FIXME: we do not want to perform proxyAuthz
@@ -1628,7 +1811,7 @@ ldap_back_proxy_authz_ctrl(
goto done;
}
- if ( !BER_BVISNULL( &lc->lc_bound_ndn ) ) {
+ if ( !BER_BVISNULL( bound_ndn ) ) {
goto done;
}
@@ -1636,23 +1819,18 @@ ldap_back_proxy_authz_ctrl(
goto done;
}
- if ( BER_BVISNULL( &li->li_idassert_authcDN ) ) {
+ if ( BER_BVISNULL( &si->si_bc.sb_binddn ) ) {
goto done;
}
- } else if ( li->li_idassert_authmethod == LDAP_AUTH_SASL ) {
- if ( ( li->li_idassert_flags & LDAP_BACK_AUTH_NATIVE_AUTHZ )
- /* && ( !BER_BVISNULL( &ndn )
- || LDAP_BACK_CONN_ISBOUND( lc ) ) */ )
+ } else if ( si->si_bc.sb_method == LDAP_AUTH_SASL ) {
+ if ( ( si->si_flags & LDAP_BACK_AUTH_NATIVE_AUTHZ ) )
{
/* already asserted in SASL via native authz */
- /* NOTE: the test on lc->lc_bound is used to trap
- * native authorization of anonymous users,
- * since in that case ndn is NULL */
goto done;
}
- } else if ( li->li_idassert_authz && !be_isroot( op ) ) {
+ } else if ( si->si_authz && !be_isroot( op ) ) {
int rc;
struct berval authcDN;
@@ -1661,11 +1839,10 @@ ldap_back_proxy_authz_ctrl(
} else {
authcDN = ndn;
}
- rc = slap_sasl_matches( op, li->li_idassert_authz,
+ rc = slap_sasl_matches( op, si->si_authz,
&authcDN, & authcDN );
if ( rc != LDAP_SUCCESS ) {
- if ( li->li_idassert_flags & LDAP_BACK_AUTH_PRESCRIPTIVE )
- {
+ if ( si->si_flags & LDAP_BACK_AUTH_PRESCRIPTIVE ) {
/* ndn is not authorized
* to use idassert */
rs->sr_err = rc;
@@ -1700,7 +1877,7 @@ ldap_back_proxy_authz_ctrl(
mode = LDAP_BACK_IDASSERT_NOASSERT;
} else {
- mode = li->li_idassert_mode;
+ mode = si->si_mode;
}
switch ( mode ) {
@@ -1733,7 +1910,7 @@ ldap_back_proxy_authz_ctrl(
case LDAP_BACK_IDASSERT_OTHERID:
case LDAP_BACK_IDASSERT_OTHERDN:
/* assert idassert DN */
- assertedID = li->li_idassert_authzID;
+ assertedID = si->si_bc.sb_authzId;
break;
default:
@@ -1745,7 +1922,7 @@ ldap_back_proxy_authz_ctrl(
}
/* don't idassert the bound DN (ITS#4497) */
- if ( dn_match( &assertedID, &lc->lc_bound_ndn ) ) {
+ if ( dn_match( &assertedID, bound_ndn ) ) {
goto done;
}
@@ -1761,7 +1938,7 @@ ldap_back_proxy_authz_ctrl(
ctrls[ 0 ]->ldctl_oid = LDAP_CONTROL_PROXY_AUTHZ;
ctrls[ 0 ]->ldctl_iscritical = 1;
- switch ( li->li_idassert_mode ) {
+ switch ( si->si_mode ) {
/* already in u:ID or dn:DN form */
case LDAP_BACK_IDASSERT_OTHERID:
case LDAP_BACK_IDASSERT_OTHERDN:
@@ -1783,7 +1960,7 @@ ldap_back_proxy_authz_ctrl(
* to encode the value of the authzID (and called it proxyDN);
* this hack provides compatibility with those DSAs that
* implement it this way */
- if ( li->li_idassert_flags & LDAP_BACK_AUTH_OBSOLETE_ENCODING_WORKAROUND ) {
+ if ( si->si_flags & LDAP_BACK_AUTH_OBSOLETE_ENCODING_WORKAROUND ) {
struct berval authzID = ctrls[ 0 ]->ldctl_value;
BerElementBuffer berbuf;
BerElement *ber = (BerElement *)&berbuf;
@@ -1813,7 +1990,7 @@ free_ber:;
goto done;
}
- } else if ( li->li_idassert_flags & LDAP_BACK_AUTH_OBSOLETE_PROXY_AUTHZ ) {
+ } else if ( si->si_flags & LDAP_BACK_AUTH_OBSOLETE_PROXY_AUTHZ ) {
struct berval authzID = ctrls[ 0 ]->ldctl_value,
tmp;
BerElementBuffer berbuf;
diff --git a/servers/slapd/back-ldap/chain.c b/servers/slapd/back-ldap/chain.c
index ca6afdd2d6f9797f194031158da891d7594eb6a9..c0707c16a273a153e6fe013bac6dd4e1f7ab2f98 100644
--- a/servers/slapd/back-ldap/chain.c
+++ b/servers/slapd/back-ldap/chain.c
@@ -58,10 +58,11 @@
static int sc_chainingBehavior;
#endif /* LDAP_CONTROL_X_CHAINING_BEHAVIOR */
-#define LDAP_CH_NONE ((void *)(0))
-#define LDAP_CH_RES ((void *)(1))
-#define LDAP_CH_ERR ((void *)(2))
-
+typedef enum {
+ LDAP_CH_NONE = 0,
+ LDAP_CH_RES,
+ LDAP_CH_ERR
+} ldap_chain_status_t;
static BackendInfo *lback;
typedef struct ldap_chain_t {
@@ -87,13 +88,19 @@ typedef struct ldap_chain_t {
/* tree of configured[/generated?] "uri" info */
ldap_avl_info_t lc_lai;
+ /* max depth in nested referrals chaining */
+ int lc_max_depth;
+
unsigned lc_flags;
#define LDAP_CHAIN_F_NONE (0x00U)
#define LDAP_CHAIN_F_CHAINING (0x01U)
-#define LDAP_CHAIN_F_CACHE_URI (0x10U)
+#define LDAP_CHAIN_F_CACHE_URI (0x02U)
+#define LDAP_CHAIN_F_RETURN_ERR (0x04U)
-#define LDAP_CHAIN_CHAINING( lc ) ( ( (lc)->lc_flags & LDAP_CHAIN_F_CHAINING ) == LDAP_CHAIN_F_CHAINING )
-#define LDAP_CHAIN_CACHE_URI( lc ) ( ( (lc)->lc_flags & LDAP_CHAIN_F_CACHE_URI ) == LDAP_CHAIN_F_CACHE_URI )
+#define LDAP_CHAIN_ISSET(lc, f) ( ( (lc)->lc_flags & (f) ) == (f) )
+#define LDAP_CHAIN_CHAINING( lc ) LDAP_CHAIN_ISSET( (lc), LDAP_CHAIN_F_CHAINING )
+#define LDAP_CHAIN_CACHE_URI( lc ) LDAP_CHAIN_ISSET( (lc), LDAP_CHAIN_F_CACHE_URI )
+#define LDAP_CHAIN_RETURN_ERR( lc ) LDAP_CHAIN_ISSET( (lc), LDAP_CHAIN_F_RETURN_ERR )
#ifdef LDAP_CONTROL_X_CHAINING_BEHAVIOR
LDAPControl lc_chaining_ctrl;
@@ -107,6 +114,28 @@ static int ldap_chain_db_init_one( BackendDB *be );
#define ldap_chain_db_close_one(be) (0)
#define ldap_chain_db_destroy_one(be) (lback)->bi_db_destroy( (be) )
+typedef struct ldap_chain_cb_t {
+ ldap_chain_status_t lb_status;
+ ldap_chain_t *lb_lc;
+ BI_op_func *lb_op_f;
+ int lb_depth;
+} ldap_chain_cb_t;
+
+static int
+ldap_chain_op(
+ Operation *op,
+ SlapReply *rs,
+ BI_op_func *op_f,
+ BerVarray ref,
+ int depth );
+
+static int
+ldap_chain_search(
+ Operation *op,
+ SlapReply *rs,
+ BerVarray ref,
+ int depth );
+
#ifdef LDAP_CONTROL_X_CHAINING_BEHAVIOR
static int
chaining_control_add(
@@ -225,10 +254,12 @@ ldap_chain_uri_dup( void *c1, void *c2 )
static int
ldap_chain_cb_search_response( Operation *op, SlapReply *rs )
{
+ ldap_chain_cb_t *lb = (ldap_chain_cb_t *)op->o_callback->sc_private;
+
assert( op->o_tag == LDAP_REQ_SEARCH );
/* if in error, don't proceed any further */
- if ( op->o_callback->sc_private == LDAP_CH_ERR ) {
+ if ( lb->lb_status == LDAP_CH_ERR ) {
return 0;
}
@@ -260,12 +291,15 @@ ldap_chain_cb_search_response( Operation *op, SlapReply *rs )
} else if ( rs->sr_type == REP_SEARCHREF ) {
/* if we get it here, it means the library was unable
* to chase the referral... */
+ if ( lb->lb_depth < lb->lb_lc->lc_max_depth && rs->sr_ref != NULL ) {
+ rs->sr_err = ldap_chain_search( op, rs, rs->sr_ref, lb->lb_depth );
+ }
#ifdef LDAP_CONTROL_X_CHAINING_BEHAVIOR
- if ( get_chaining( op ) > SLAP_CONTROL_IGNORED ) {
+ if ( rs->sr_err == LDAP_REFERRAL && get_chaining( op ) > SLAP_CONTROL_IGNORED ) {
switch ( get_continuationBehavior( op ) ) {
case SLAP_CH_RESOLVE_CHAINING_REQUIRED:
- op->o_callback->sc_private = LDAP_CH_ERR;
+ lb->lb_status = LDAP_CH_ERR;
return rs->sr_err = LDAP_X_CANNOT_CHAIN;
default:
@@ -276,8 +310,15 @@ ldap_chain_cb_search_response( Operation *op, SlapReply *rs )
return SLAP_CB_CONTINUE;
} else if ( rs->sr_type == REP_RESULT ) {
+ if ( rs->sr_err == LDAP_REFERRAL
+ && lb->lb_depth < lb->lb_lc->lc_max_depth
+ && rs->sr_ref != NULL )
+ {
+ rs->sr_err = ldap_chain_op( op, rs, lb->lb_op_f, rs->sr_ref, lb->lb_depth );
+ }
+
/* back-ldap tried to send result */
- op->o_callback->sc_private = LDAP_CH_RES;
+ lb->lb_status = LDAP_CH_RES;
}
return 0;
@@ -290,12 +331,15 @@ ldap_chain_cb_search_response( Operation *op, SlapReply *rs )
static int
ldap_chain_cb_response( Operation *op, SlapReply *rs )
{
+ ldap_chain_cb_t *lb = (ldap_chain_cb_t *)op->o_callback->sc_private;
+
/* if in error, don't proceed any further */
- if ( op->o_callback->sc_private == LDAP_CH_ERR ) {
+ if ( lb->lb_status == LDAP_CH_ERR ) {
return 0;
}
if ( rs->sr_type == REP_RESULT ) {
+retry:;
switch ( rs->sr_err ) {
case LDAP_COMPARE_TRUE:
case LDAP_COMPARE_FALSE:
@@ -305,15 +349,20 @@ ldap_chain_cb_response( Operation *op, SlapReply *rs )
/* fallthru */
case LDAP_SUCCESS:
- op->o_callback->sc_private = LDAP_CH_RES;
+ lb->lb_status = LDAP_CH_RES;
break;
case LDAP_REFERRAL:
+ if ( lb->lb_depth < lb->lb_lc->lc_max_depth && rs->sr_ref != NULL ) {
+ rs->sr_err = ldap_chain_op( op, rs, lb->lb_op_f, rs->sr_ref, lb->lb_depth );
+ goto retry;
+ }
+
#ifdef LDAP_CONTROL_X_CHAINING_BEHAVIOR
if ( get_chaining( op ) > SLAP_CONTROL_IGNORED ) {
switch ( get_continuationBehavior( op ) ) {
case SLAP_CH_RESOLVE_CHAINING_REQUIRED:
- op->o_callback->sc_private = LDAP_CH_ERR;
+ lb->lb_status = LDAP_CH_ERR;
return rs->sr_err = LDAP_X_CANNOT_CHAIN;
default:
@@ -341,15 +390,18 @@ ldap_chain_op(
Operation *op,
SlapReply *rs,
BI_op_func *op_f,
- BerVarray ref )
+ BerVarray ref,
+ int depth )
{
slap_overinst *on = (slap_overinst *) op->o_bd->bd_info;
+ ldap_chain_cb_t *lb = (ldap_chain_cb_t *)op->o_callback->sc_private;
ldap_chain_t *lc = (ldap_chain_t *)on->on_bi.bi_private;
ldapinfo_t li = { 0 }, *lip = NULL;
struct berval bvuri[ 2 ] = { { 0 } };
/* NOTE: returned if ref is empty... */
- int rc = LDAP_OTHER;
+ int rc = LDAP_OTHER,
+ first_rc;
#ifdef LDAP_CONTROL_X_CHAINING_BEHAVIOR
LDAPControl **ctrls = NULL;
@@ -358,6 +410,7 @@ ldap_chain_op(
#endif /* LDAP_CONTROL_X_CHAINING_BEHAVIOR */
li.li_bvuri = bvuri;
+ first_rc = -1;
for ( ; !BER_BVISNULL( ref ); ref++ ) {
LDAPURLDesc *srv;
char *save_dn;
@@ -446,8 +499,16 @@ Document: draft-ietf-ldapbis-protocol-27.txt
}
}
+ lb->lb_op_f = op_f;
+ lb->lb_depth = depth + 1;
+
rc = op_f( op, rs );
+ /* note the first error */
+ if ( first_rc == -1 ) {
+ first_rc = rc;
+ }
+
cleanup:;
ldap_memfree( li.li_uri );
li.li_uri = NULL;
@@ -468,6 +529,181 @@ cleanup:;
(void)chaining_control_remove( op, &ctrls );
#endif /* LDAP_CONTROL_X_CHAINING_BEHAVIOR */
+ if ( rc != LDAP_SUCCESS && first_rc > 0 ) {
+ rc = first_rc;
+ }
+
+ return rc;
+}
+
+static int
+ldap_chain_search(
+ Operation *op,
+ SlapReply *rs,
+ BerVarray ref,
+ int depth )
+
+{
+ slap_overinst *on = (slap_overinst *) op->o_bd->bd_info;
+ ldap_chain_cb_t *lb = (ldap_chain_cb_t *)op->o_callback->sc_private;
+ ldap_chain_t *lc = (ldap_chain_t *)on->on_bi.bi_private;
+ ldapinfo_t li = { 0 }, *lip = NULL;
+ struct berval bvuri[ 2 ] = { { 0 } };
+
+ struct berval odn = op->o_req_dn,
+ ondn = op->o_req_ndn;
+ slap_response *save_response = op->o_callback->sc_response;
+
+ int rc = LDAP_OTHER,
+ first_rc = -1;
+
+#ifdef LDAP_CONTROL_X_CHAINING_BEHAVIOR
+ LDAPControl **ctrls = NULL;
+
+ (void)chaining_control_add( lc, op, &ctrls );
+#endif /* LDAP_CONTROL_X_CHAINING_BEHAVIOR */
+
+ rs->sr_type = REP_SEARCH;
+
+ op->o_callback->sc_response = ldap_chain_cb_search_response;
+
+ /* if we parse the URI then by no means
+ * we can cache stuff or reuse connections,
+ * because in back-ldap there's no caching
+ * based on the URI value, which is supposed
+ * to be set once for all (correct?) */
+ li.li_bvuri = bvuri;
+ for ( ; !BER_BVISNULL( &ref[0] ); ref++ ) {
+ LDAPURLDesc *srv;
+ char *save_dn;
+ int temporary = 0;
+
+ /* parse reference and use
+ * proto://[host][:port]/ only */
+ rc = ldap_url_parse_ext( ref[0].bv_val, &srv, LDAP_PVT_URL_PARSE_NONE );
+ if ( rc != LDAP_URL_SUCCESS ) {
+ /* try next */
+ rs->sr_err = LDAP_OTHER;
+ continue;
+ }
+
+ /* remove DN essentially because later on
+ * ldap_initialize() will parse the URL
+ * as a comma-separated URL list */
+ save_dn = srv->lud_dn;
+ srv->lud_dn = "";
+ srv->lud_scope = LDAP_SCOPE_DEFAULT;
+ li.li_uri = ldap_url_desc2str( srv );
+ if ( li.li_uri != NULL ) {
+ ber_str2bv_x( save_dn, 0, 1, &op->o_req_dn,
+ op->o_tmpmemctx );
+ ber_dupbv_x( &op->o_req_ndn, &op->o_req_dn,
+ op->o_tmpmemctx );
+ }
+
+ srv->lud_dn = save_dn;
+ ldap_free_urldesc( srv );
+
+ if ( li.li_uri == NULL ) {
+ /* try next */
+ rs->sr_err = LDAP_OTHER;
+ continue;
+ }
+
+ ber_str2bv( li.li_uri, 0, 0, &li.li_bvuri[ 0 ] );
+
+ /* Searches for a ldapinfo in the avl tree */
+ ldap_pvt_thread_mutex_lock( &lc->lc_lai.lai_mutex );
+ lip = (ldapinfo_t *)avl_find( lc->lc_lai.lai_tree,
+ (caddr_t)&li, ldap_chain_uri_cmp );
+ ldap_pvt_thread_mutex_unlock( &lc->lc_lai.lai_mutex );
+
+ if ( lip != NULL ) {
+ op->o_bd->be_private = (void *)lip;
+
+ } else {
+ /* if none is found, create a temporary... */
+ rc = ldap_chain_db_init_one( op->o_bd );
+ if ( rc != 0 ) {
+ goto cleanup;
+ }
+ lip = (ldapinfo_t *)op->o_bd->be_private;
+ lip->li_uri = li.li_uri;
+ lip->li_bvuri = bvuri;
+ rc = ldap_chain_db_open_one( op->o_bd );
+ if ( rc != 0 ) {
+ (void)ldap_chain_db_destroy_one( op->o_bd );
+ goto cleanup;
+ }
+
+ if ( LDAP_CHAIN_CACHE_URI( lc ) ) {
+ ldap_pvt_thread_mutex_lock( &lc->lc_lai.lai_mutex );
+ if ( avl_insert( &lc->lc_lai.lai_tree,
+ (caddr_t)lip, ldap_chain_uri_cmp, ldap_chain_uri_dup ) )
+ {
+ /* someone just inserted another;
+ * don't bother, use this and then
+ * just free it */
+ temporary = 1;
+ }
+ ldap_pvt_thread_mutex_unlock( &lc->lc_lai.lai_mutex );
+
+ } else {
+ temporary = 1;
+ }
+ }
+
+ lb->lb_op_f = lback->bi_op_search;
+ lb->lb_depth = depth + 1;
+
+ /* FIXME: should we also copy filter and scope?
+ * according to RFC3296, no */
+ rc = lback->bi_op_search( op, rs );
+ if ( first_rc == -1 ) {
+ first_rc = rc;
+ }
+
+cleanup:;
+ ldap_memfree( li.li_uri );
+ li.li_uri = NULL;
+
+ op->o_tmpfree( op->o_req_dn.bv_val, op->o_tmpmemctx );
+ op->o_tmpfree( op->o_req_ndn.bv_val, op->o_tmpmemctx );
+
+ if ( temporary ) {
+ lip->li_uri = NULL;
+ lip->li_bvuri = NULL;
+ (void)ldap_chain_db_close_one( op->o_bd );
+ (void)ldap_chain_db_destroy_one( op->o_bd );
+ }
+
+ if ( rc == LDAP_SUCCESS && rs->sr_err == LDAP_SUCCESS ) {
+ break;
+ }
+
+ rc = rs->sr_err;
+ }
+
+#ifdef LDAP_CONTROL_X_CHAINING_BEHAVIOR
+ (void)chaining_control_remove( op, &ctrls );
+#endif /* LDAP_CONTROL_X_CHAINING_BEHAVIOR */
+
+ op->o_req_dn = odn;
+ op->o_req_ndn = ondn;
+ op->o_callback->sc_response = save_response;
+ rs->sr_type = REP_SEARCHREF;
+ rs->sr_entry = NULL;
+
+ if ( rc != LDAP_SUCCESS ) {
+ /* couldn't chase any of the referrals */
+ if ( first_rc != -1 ) {
+ rc = first_rc;
+
+ } else {
+ rc = SLAP_CB_CONTINUE;
+ }
+ }
+
return rc;
}
@@ -475,7 +711,9 @@ static int
ldap_chain_response( Operation *op, SlapReply *rs )
{
slap_overinst *on = (slap_overinst *)op->o_bd->bd_info;
+ ldap_chain_t *lc = (ldap_chain_t *)on->on_bi.bi_private;
void *private = op->o_bd->be_private;
+ ldap_chain_cb_t lb = { 0 };
slap_callback *sc = op->o_callback,
sc2 = { 0 };
int rc = 0;
@@ -536,6 +774,8 @@ ldap_chain_response( Operation *op, SlapReply *rs )
rs->sr_ref = NULL;
/* we need this to know if back-ldap returned any result */
+ lb.lb_lc = lc;
+ sc2.sc_private = &lb;
sc2.sc_response = ldap_chain_cb_response;
op->o_callback = &sc2;
@@ -556,30 +796,30 @@ ldap_chain_response( Operation *op, SlapReply *rs )
/* FIXME: can we really get a referral for binds? */
op->o_req_ndn = slap_empty_bv;
op->o_conn = NULL;
- rc = ldap_chain_op( op, rs, lback->bi_op_bind, ref );
+ rc = ldap_chain_op( op, rs, lback->bi_op_bind, ref, 0 );
op->o_req_ndn = rndn;
op->o_conn = conn;
}
break;
case LDAP_REQ_ADD:
- rc = ldap_chain_op( op, rs, lback->bi_op_add, ref );
+ rc = ldap_chain_op( op, rs, lback->bi_op_add, ref, 0 );
break;
case LDAP_REQ_DELETE:
- rc = ldap_chain_op( op, rs, lback->bi_op_delete, ref );
+ rc = ldap_chain_op( op, rs, lback->bi_op_delete, ref, 0 );
break;
case LDAP_REQ_MODRDN:
- rc = ldap_chain_op( op, rs, lback->bi_op_modrdn, ref );
+ rc = ldap_chain_op( op, rs, lback->bi_op_modrdn, ref, 0 );
break;
case LDAP_REQ_MODIFY:
- rc = ldap_chain_op( op, rs, lback->bi_op_modify, ref );
+ rc = ldap_chain_op( op, rs, lback->bi_op_modify, ref, 0 );
break;
case LDAP_REQ_COMPARE:
- rc = ldap_chain_op( op, rs, lback->bi_op_compare, ref );
+ rc = ldap_chain_op( op, rs, lback->bi_op_compare, ref, 0 );
if ( rs->sr_err == LDAP_COMPARE_TRUE || rs->sr_err == LDAP_COMPARE_FALSE ) {
rc = LDAP_SUCCESS;
}
@@ -587,150 +827,7 @@ ldap_chain_response( Operation *op, SlapReply *rs )
case LDAP_REQ_SEARCH:
if ( rs->sr_type == REP_SEARCHREF ) {
- ldap_chain_t *lc = (ldap_chain_t *)on->on_bi.bi_private;
- ldapinfo_t li = { 0 }, *lip = NULL;
- struct berval bvuri[ 2 ] = { { 0 } };
-
- struct berval *curr = ref,
- odn = op->o_req_dn,
- ondn = op->o_req_ndn;
-
-#ifdef LDAP_CONTROL_X_CHAINING_BEHAVIOR
- LDAPControl **ctrls = NULL;
-
- (void)chaining_control_add( lc, op, &ctrls );
-#endif /* LDAP_CONTROL_X_CHAINING_BEHAVIOR */
-
- rs->sr_type = REP_SEARCH;
-
- sc2.sc_response = ldap_chain_cb_search_response;
-
- /* if we parse the URI then by no means
- * we can cache stuff or reuse connections,
- * because in back-ldap there's no caching
- * based on the URI value, which is supposed
- * to be set once for all (correct?) */
- li.li_bvuri = bvuri;
- for ( ; !BER_BVISNULL( &curr[0] ); curr++ ) {
- LDAPURLDesc *srv;
- char *save_dn;
- int temporary = 0;
-
- /* parse reference and use
- * proto://[host][:port]/ only */
- rc = ldap_url_parse_ext( curr[0].bv_val, &srv, LDAP_PVT_URL_PARSE_NONE );
- if ( rc != LDAP_URL_SUCCESS ) {
- /* try next */
- rs->sr_err = LDAP_OTHER;
- continue;
- }
-
- /* remove DN essentially because later on
- * ldap_initialize() will parse the URL
- * as a comma-separated URL list */
- save_dn = srv->lud_dn;
- srv->lud_dn = "";
- srv->lud_scope = LDAP_SCOPE_DEFAULT;
- li.li_uri = ldap_url_desc2str( srv );
- if ( li.li_uri != NULL ) {
- ber_str2bv_x( save_dn, 0, 1, &op->o_req_dn,
- op->o_tmpmemctx );
- ber_dupbv_x( &op->o_req_ndn, &op->o_req_dn,
- op->o_tmpmemctx );
- }
-
- srv->lud_dn = save_dn;
- ldap_free_urldesc( srv );
-
- if ( li.li_uri == NULL ) {
- /* try next */
- rs->sr_err = LDAP_OTHER;
- continue;
- }
-
- ber_str2bv( li.li_uri, 0, 0, &li.li_bvuri[ 0 ] );
-
- /* Searches for a ldapinfo in the avl tree */
- ldap_pvt_thread_mutex_lock( &lc->lc_lai.lai_mutex );
- lip = (ldapinfo_t *)avl_find( lc->lc_lai.lai_tree,
- (caddr_t)&li, ldap_chain_uri_cmp );
- ldap_pvt_thread_mutex_unlock( &lc->lc_lai.lai_mutex );
-
- if ( lip != NULL ) {
- op->o_bd->be_private = (void *)lip;
-
- } else {
- /* if none is found, create a temporary... */
- rc = ldap_chain_db_init_one( op->o_bd );
- if ( rc != 0 ) {
- goto cleanup;
- }
- lip = (ldapinfo_t *)op->o_bd->be_private;
- lip->li_uri = li.li_uri;
- lip->li_bvuri = bvuri;
- rc = ldap_chain_db_open_one( op->o_bd );
- if ( rc != 0 ) {
- (void)ldap_chain_db_destroy_one( op->o_bd );
- goto cleanup;
- }
-
- if ( LDAP_CHAIN_CACHE_URI( lc ) ) {
- ldap_pvt_thread_mutex_lock( &lc->lc_lai.lai_mutex );
- if ( avl_insert( &lc->lc_lai.lai_tree,
- (caddr_t)lip, ldap_chain_uri_cmp, ldap_chain_uri_dup ) )
- {
- /* someone just inserted another;
- * don't bother, use this and then
- * just free it */
- temporary = 1;
- }
- ldap_pvt_thread_mutex_unlock( &lc->lc_lai.lai_mutex );
-
- } else {
- temporary = 1;
- }
- }
-
- /* FIXME: should we also copy filter and scope?
- * according to RFC3296, no */
- rc = lback->bi_op_search( op, rs );
-
-cleanup:;
- ldap_memfree( li.li_uri );
- li.li_uri = NULL;
-
- op->o_tmpfree( op->o_req_dn.bv_val,
- op->o_tmpmemctx );
- op->o_tmpfree( op->o_req_ndn.bv_val,
- op->o_tmpmemctx );
-
- if ( temporary ) {
- lip->li_uri = NULL;
- lip->li_bvuri = NULL;
- (void)ldap_chain_db_close_one( op->o_bd );
- (void)ldap_chain_db_destroy_one( op->o_bd );
- }
-
- if ( rc == LDAP_SUCCESS && rs->sr_err == LDAP_SUCCESS ) {
- break;
- }
-
- rc = rs->sr_err;
- }
-
-#ifdef LDAP_CONTROL_X_CHAINING_BEHAVIOR
- (void)chaining_control_remove( op, &ctrls );
-#endif /* LDAP_CONTROL_X_CHAINING_BEHAVIOR */
-
- op->o_req_dn = odn;
- op->o_req_ndn = ondn;
- rs->sr_type = REP_SEARCHREF;
- rs->sr_entry = NULL;
-
- if ( rc != LDAP_SUCCESS ) {
- /* couldn't chase any of the referrals */
- rc = SLAP_CB_CONTINUE;
- }
+ rc = ldap_chain_search( op, rs, ref, 0 );
} else {
/* we might get here before any database actually
@@ -738,7 +835,7 @@ cleanup:;
* to check limits, to make sure safe defaults
* are in place */
if ( op->ors_limit != NULL || limits_check( op, rs ) == 0 ) {
- rc = ldap_chain_op( op, rs, lback->bi_op_search, ref );
+ rc = ldap_chain_op( op, rs, lback->bi_op_search, ref, 0 );
} else {
rc = SLAP_CB_CONTINUE;
@@ -747,7 +844,7 @@ cleanup:;
break;
case LDAP_REQ_EXTENDED:
- rc = ldap_chain_op( op, rs, lback->bi_extended, ref );
+ rc = ldap_chain_op( op, rs, lback->bi_extended, ref, 0 );
/* FIXME: ldap_back_extended() by design
* doesn't send result; frontend is expected
* to send it... */
@@ -756,7 +853,7 @@ cleanup:;
send_ldap_extended( op, rs );
rc = LDAP_SUCCESS;
}
- sc2.sc_private = LDAP_CH_RES;
+ lb.lb_status = LDAP_CH_RES;
break;
default:
@@ -771,7 +868,7 @@ cleanup:;
case LDAP_SUCCESS:
case LDAP_REFERRAL:
/* slapd-ldap sent response */
- if ( !op->o_abandon && sc2.sc_private != LDAP_CH_RES ) {
+ if ( !op->o_abandon && lb.lb_status != LDAP_CH_RES ) {
/* FIXME: should we send response? */
Debug( LDAP_DEBUG_ANY,
"%s: ldap_chain_response: "
@@ -782,7 +879,7 @@ cleanup:;
default:
#ifdef LDAP_CONTROL_X_CHAINING_BEHAVIOR
- if ( sc2.sc_private == LDAP_CH_ERR && rs->sr_err == LDAP_X_CANNOT_CHAIN ) {
+ if ( lb.lb_status == LDAP_CH_ERR && rs->sr_err == LDAP_X_CANNOT_CHAIN ) {
goto cannot_chain;
}
@@ -796,18 +893,24 @@ cannot_chain:;
default:
#endif /* LDAP_CONTROL_X_CHAINING_BEHAVIOR */
- rc = SLAP_CB_CONTINUE;
- rs->sr_err = sr_err;
- rs->sr_type = sr_type;
- rs->sr_matched = matched;
- rs->sr_ref = ref;
+ if ( LDAP_CHAIN_RETURN_ERR( lc ) ) {
+ rs->sr_err = rc;
+ rs->sr_type = sr_type;
+
+ } else {
+ rc = SLAP_CB_CONTINUE;
+ rs->sr_err = sr_err;
+ rs->sr_type = sr_type;
+ rs->sr_matched = matched;
+ rs->sr_ref = ref;
+ }
#ifdef LDAP_CONTROL_X_CHAINING_BEHAVIOR
break;
}
#endif /* LDAP_CONTROL_X_CHAINING_BEHAVIOR */
}
- if ( sc2.sc_private == LDAP_CH_NONE && rc != SLAPD_ABANDON ) {
+ if ( lb.lb_status == LDAP_CH_NONE && rc != SLAPD_ABANDON ) {
op->o_callback = NULL;
rc = rs->sr_err = slap_map_api2result( rs );
send_ldap_result( op, rs );
@@ -858,7 +961,9 @@ str2chain( const char *s )
enum {
CH_CHAINING = 1,
- CH_CACHE_URI = 2,
+ CH_CACHE_URI,
+ CH_MAX_DEPTH,
+ CH_RETURN_ERR,
CH_LAST
};
@@ -877,9 +982,21 @@ static ConfigTable chaincfg[] = {
#endif /* LDAP_CONTROL_X_CHAINING_BEHAVIOR */
{ "chain-cache-uri", "TRUE/FALSE",
2, 2, 0, ARG_MAGIC|ARG_ON_OFF|CH_CACHE_URI, chain_cf_gen,
- "( OLcfgOvAt:3.2 NAME 'olcCacheURI' "
+ "( OLcfgOvAt:3.2 NAME 'olcChainCacheURI' "
"DESC 'Enables caching of URIs not present in configuration' "
"SYNTAX OMsBoolean SINGLE-VALUE )", NULL, NULL },
+ { "chain-max-depth", "args",
+ 2, 2, 0, ARG_MAGIC|ARG_INT|CH_MAX_DEPTH, chain_cf_gen,
+ "( OLcfgOvAt:3.3 NAME 'olcChainMaxReferralDepth' "
+ "DESC 'max referral depth' "
+ "SYNTAX OMsInteger "
+ "EQUALITY integerMatch "
+ "SINGLE-VALUE )", NULL, NULL },
+ { "chain-return-error", "TRUE/FALSE",
+ 2, 2, 0, ARG_MAGIC|ARG_ON_OFF|CH_RETURN_ERR, chain_cf_gen,
+ "( OLcfgOvAt:3.4 NAME 'olcChainReturnError' "
+ "DESC 'Errors are returned instead of the original referral' "
+ "SYNTAX OMsBoolean SINGLE-VALUE )", NULL, NULL },
{ NULL, NULL, 0, 0, 0, ARG_IGNORED }
};
@@ -892,7 +1009,9 @@ static ConfigOCs chainocs[] = {
#ifdef LDAP_CONTROL_X_CHAINING_BEHAVIOR
"olcChainingBehavior $ "
#endif /* LDAP_CONTROL_X_CHAINING_BEHAVIOR */
- "olcCacheURI "
+ "olcChainCacheURI $ "
+ "olcChainMaxReferralDepth $ "
+ "olcChainReturnError "
") )",
Cft_Overlay, chaincfg, NULL, chain_cfadd },
{ "( OLcfgOvOc:3.2 "
@@ -1110,6 +1229,14 @@ chain_cf_gen( ConfigArgs *c )
c->value_int = LDAP_CHAIN_CACHE_URI( lc );
break;
+ case CH_MAX_DEPTH:
+ c->value_int = lc->lc_max_depth;
+ break;
+
+ case CH_RETURN_ERR:
+ c->value_int = LDAP_CHAIN_RETURN_ERR( lc );
+ break;
+
default:
assert( 0 );
rc = 1;
@@ -1125,6 +1252,14 @@ chain_cf_gen( ConfigArgs *c )
lc->lc_flags &= ~LDAP_CHAIN_F_CACHE_URI;
break;
+ case CH_MAX_DEPTH:
+ c->value_int = 0;
+ break;
+
+ case CH_RETURN_ERR:
+ lc->lc_flags &= ~LDAP_CHAIN_F_RETURN_ERR;
+ break;
+
default:
return 1;
}
@@ -1257,6 +1392,26 @@ chain_cf_gen( ConfigArgs *c )
}
break;
+ case CH_MAX_DEPTH:
+ if ( c->value_int < 0 ) {
+ snprintf( c->msg, sizeof( c->msg ),
+ "<%s> invalid max referral depth %d",
+ c->argv[0], c->value_int );
+ Debug( LDAP_DEBUG_ANY, "%s: %s.\n",
+ c->log, c->msg, 0 );
+ rc = 1;
+ break;
+ }
+ lc->lc_max_depth = c->value_int;
+
+ case CH_RETURN_ERR:
+ if ( c->value_int ) {
+ lc->lc_flags |= LDAP_CHAIN_F_RETURN_ERR;
+ } else {
+ lc->lc_flags &= ~LDAP_CHAIN_F_RETURN_ERR;
+ }
+ break;
+
default:
assert( 0 );
return 1;
@@ -1284,6 +1439,7 @@ ldap_chain_db_init(
return 1;
}
memset( lc, 0, sizeof( ldap_chain_t ) );
+ lc->lc_max_depth = 1;
ldap_pvt_thread_mutex_init( &lc->lc_lai.lai_mutex );
on->on_bi.bi_private = (void *)lc;
diff --git a/servers/slapd/back-ldap/compare.c b/servers/slapd/back-ldap/compare.c
index 8d31acabb898265d20096740c7c26f5f22eadd51..11fd3eb9c30cbdb44bc461772fcb5db733f5471c 100644
--- a/servers/slapd/back-ldap/compare.c
+++ b/servers/slapd/back-ldap/compare.c
@@ -36,11 +36,13 @@ ldap_back_compare(
Operation *op,
SlapReply *rs )
{
- ldapconn_t *lc;
- ber_int_t msgid;
- int do_retry = 1;
- LDAPControl **ctrls = NULL;
- int rc = LDAP_SUCCESS;
+ ldapinfo_t *li = (ldapinfo_t *)op->o_bd->be_private;
+
+ ldapconn_t *lc;
+ ber_int_t msgid;
+ ldap_back_send_t retrying = LDAP_BACK_RETRYING;
+ LDAPControl **ctrls = NULL;
+ int rc = LDAP_SUCCESS;
lc = ldap_back_getconn( op, rs, LDAP_BACK_SENDERR );
if ( !lc || !ldap_back_dobind( lc, op, rs, LDAP_BACK_SENDERR ) ) {
@@ -49,7 +51,8 @@ ldap_back_compare(
}
ctrls = op->o_ctrls;
- rc = ldap_back_proxy_authz_ctrl( lc, op, rs, &ctrls );
+ rc = ldap_back_proxy_authz_ctrl( &lc->lc_bound_ndn,
+ li->li_version, &li->li_idassert, op, rs, &ctrls );
if ( rc != LDAP_SUCCESS ) {
send_ldap_result( op, rs );
goto cleanup;
@@ -60,9 +63,10 @@ retry:
op->orc_ava->aa_desc->ad_cname.bv_val,
&op->orc_ava->aa_value,
ctrls, NULL, &msgid );
- rc = ldap_back_op_result( lc, op, rs, msgid, 0, LDAP_BACK_SENDRESULT );
- if ( rc == LDAP_UNAVAILABLE && do_retry ) {
- do_retry = 0;
+ rc = ldap_back_op_result( lc, op, rs, msgid, 0,
+ ( LDAP_BACK_SENDRESULT | retrying ) );
+ if ( rc == LDAP_UNAVAILABLE && retrying ) {
+ retrying &= ~LDAP_BACK_RETRYING;
if ( ldap_back_retry( &lc, op, rs, LDAP_BACK_SENDERR ) ) {
goto retry;
}
diff --git a/servers/slapd/back-ldap/config.c b/servers/slapd/back-ldap/config.c
index d270b40eab65115d9409f4b5ec45ac5fd0cbc5ef..154f4c305a6beef5f72b31baa33979780f80a291 100644
--- a/servers/slapd/back-ldap/config.c
+++ b/servers/slapd/back-ldap/config.c
@@ -65,6 +65,8 @@ enum {
LDAP_BACK_CFG_NETWORK_TIMEOUT,
LDAP_BACK_CFG_VERSION,
LDAP_BACK_CFG_SINGLECONN,
+ LDAP_BACK_CFG_CANCEL,
+ LDAP_BACK_CFG_QUARANTINE,
LDAP_BACK_CFG_REWRITE,
LDAP_BACK_CFG_LAST
@@ -259,6 +261,22 @@ static ConfigTable ldapcfg[] = {
"SYNTAX OMsBoolean "
"SINGLE-VALUE )",
NULL, NULL },
+ { "cancel", "ABANDON|ignore|exop", 2, 0, 0,
+ ARG_MAGIC|LDAP_BACK_CFG_CANCEL,
+ ldap_back_cf_gen, "( OLcfgDbAt:3.20 "
+ "NAME 'olcDbCancel' "
+ "DESC 'abandon/ignore/exop operations when appropriate' "
+ "SYNTAX OMsDirectoryString "
+ "SINGLE-VALUE )",
+ NULL, NULL },
+ { "quarantine", "retrylist", 2, 0, 0,
+ ARG_MAGIC|LDAP_BACK_CFG_QUARANTINE,
+ ldap_back_cf_gen, "( OLcfgDbAt:3.21 "
+ "NAME 'olcDbQuarantine' "
+ "DESC 'Quarantine database if connection fails and retry according to rule' "
+ "SYNTAX OMsDirectoryString "
+ "SINGLE-VALUE )",
+ NULL, NULL },
{ "suffixmassage", "[virtual]> <real", 2, 3, 0,
ARG_STRING|ARG_MAGIC|LDAP_BACK_CFG_REWRITE,
ldap_back_cf_gen, NULL, NULL, NULL },
@@ -294,6 +312,8 @@ static ConfigOCs ldapocs[] = {
"$ olcDbTimeout "
"$ olcDbIdleTimeout "
"$ olcDbSingleConn "
+ "$ olcDbCancel "
+ "$ olcDbQuarantine "
") )",
Cft_Database, ldapcfg},
{ NULL, 0, NULL }
@@ -317,12 +337,20 @@ static slap_verbmasks tls_mode[] = {
};
static slap_verbmasks t_f_mode[] = {
- { BER_BVC( "yes" ), LDAP_BACK_F_SUPPORT_T_F },
- { BER_BVC( "discover" ), LDAP_BACK_F_SUPPORT_T_F_DISCOVER },
+ { BER_BVC( "yes" ), LDAP_BACK_F_T_F },
+ { BER_BVC( "discover" ), LDAP_BACK_F_T_F_DISCOVER },
{ BER_BVC( "no" ), LDAP_BACK_F_NONE },
{ BER_BVNULL, 0 }
};
+static slap_verbmasks cancel_mode[] = {
+ { BER_BVC( "ignore" ), LDAP_BACK_F_CANCEL_IGNORE },
+ { BER_BVC( "exop" ), LDAP_BACK_F_CANCEL_EXOP },
+ { BER_BVC( "exop-discover" ), LDAP_BACK_F_CANCEL_EXOP_DISCOVER },
+ { BER_BVC( "abandon" ), LDAP_BACK_F_CANCEL_ABANDON },
+ { BER_BVNULL, 0 }
+};
+
static slap_cf_aux_table timeout_table[] = {
{ BER_BVC("add="), 0 * sizeof( time_t ), 'u', 0, NULL },
{ BER_BVC("delete="), 1 * sizeof( time_t ), 'u', 0, NULL },
@@ -331,16 +359,343 @@ static slap_cf_aux_table timeout_table[] = {
{ BER_BVNULL, 0, 0, 0, NULL }
};
+int
+slap_retry_info_parse(
+ char *in,
+ slap_retry_info_t *ri,
+ char *buf,
+ ber_len_t buflen )
+{
+ char **retrylist = NULL;
+ int rc = 0;
+ int i;
+
+ slap_str2clist( &retrylist, in, " ;" );
+ if ( retrylist == NULL ) {
+ return 1;
+ }
+
+ for ( i = 0; retrylist[ i ] != NULL; i++ )
+ /* count */ ;
+
+ ri->ri_interval = ch_calloc( sizeof( time_t ), i + 1 );
+ ri->ri_num = ch_calloc( sizeof( int ), i + 1 );
+
+ for ( i = 0; retrylist[ i ] != NULL; i++ ) {
+ unsigned long t;
+ char *sep = strchr( retrylist[ i ], ',' );
+
+ if ( sep == NULL ) {
+ snprintf( buf, buflen,
+ "missing comma in retry pattern #%d \"%s\"",
+ i, retrylist[ i ] );
+ rc = 1;
+ goto done;
+ }
+
+ *sep++ = '\0';
+
+ if ( lutil_parse_time( retrylist[ i ], &t ) ) {
+ snprintf( buf, buflen,
+ "unable to parse interval #%d \"%s\"",
+ i, retrylist[ i ] );
+ rc = 1;
+ goto done;
+ }
+ ri->ri_interval[ i ] = (time_t)t;
+
+ if ( strcmp( sep, "+" ) == 0 ) {
+ if ( retrylist[ i + 1 ] != NULL ) {
+ snprintf( buf, buflen,
+ "extra cruft after retry pattern "
+ "#%d \"%s,+\" with \"forever\" mark",
+ i, retrylist[ i ] );
+ rc = 1;
+ goto done;
+ }
+ ri->ri_num[ i ] = SLAP_RETRYNUM_FOREVER;
+
+ } else if ( lutil_atoi( &ri->ri_num[ i ], sep ) ) {
+ snprintf( buf, buflen,
+ "unable to parse retry num #%d \"%s\"",
+ i, sep );
+ rc = 1;
+ goto done;
+ }
+ }
+
+ ri->ri_num[ i ] = SLAP_RETRYNUM_TAIL;
+
+ ri->ri_idx = 0;
+ ri->ri_count = 0;
+ ri->ri_last = (time_t)(-1);
+
+done:;
+ ldap_charray_free( retrylist );
+
+ if ( rc ) {
+ slap_retry_info_destroy( ri );
+ }
+
+ return rc;
+}
+
+int
+slap_retry_info_unparse(
+ slap_retry_info_t *ri,
+ struct berval *bvout )
+{
+ int i;
+ char buf[ BUFSIZ * 2 ],
+ *ptr = buf;
+ struct berval bv = BER_BVNULL;
+
+ assert( ri != NULL );
+ assert( bvout != NULL );
+
+ BER_BVZERO( bvout );
+
+#define WHATSLEFT ( sizeof( buf ) - ( ptr - buf ) )
+
+ for ( i = 0; ri->ri_num[ i ] != SLAP_RETRYNUM_TAIL; i++ ) {
+ if ( i > 0 ) {
+ if ( WHATSLEFT <= 1 ) {
+ return 1;
+ }
+ *ptr++ = ';';
+ }
+
+ if ( lutil_unparse_time( ptr, WHATSLEFT, (long)ri->ri_interval[i] ) ) {
+ return 1;
+ }
+ ptr += strlen( ptr );
+
+ if ( WHATSLEFT <= 1 ) {
+ return 1;
+ }
+ *ptr++ = ',';
+
+ if ( ri->ri_num[i] == SLAP_RETRYNUM_FOREVER ) {
+ if ( WHATSLEFT <= 1 ) {
+ return 1;
+ }
+ *ptr++ = '+';
+
+ } else {
+ ptr += snprintf( ptr, WHATSLEFT, "%d", ri->ri_num[i] );
+ if ( WHATSLEFT <= 0 ) {
+ return 1;
+ }
+ }
+ }
+
+ bv.bv_val = buf;
+ bv.bv_len = ptr - buf;
+
+ ber_dupbv( bvout, &bv );
+
+ return 0;
+}
+
+void
+slap_retry_info_destroy(
+ slap_retry_info_t *ri )
+{
+ assert( ri != NULL );
+
+ assert( ri->ri_interval != NULL );
+ ch_free( ri->ri_interval );
+ ri->ri_interval = NULL;
+
+ assert( ri->ri_num != NULL );
+ ch_free( ri->ri_num );
+ ri->ri_num = NULL;
+}
+
+static int
+slap_idassert_authzfrom_parse( ConfigArgs *c, slap_idassert_t *si )
+{
+ struct berval bv;
+ struct berval in;
+ int rc;
+
+ ber_str2bv( c->argv[ 1 ], 0, 0, &in );
+ rc = authzNormalize( 0, NULL, NULL, &in, &bv, NULL );
+ if ( rc != LDAP_SUCCESS ) {
+ snprintf( c->msg, sizeof( c->msg ),
+ "\"idassert-authzFrom <authz>\": "
+ "invalid syntax" );
+ Debug( LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->msg, 0 );
+ return 1;
+ }
+ ber_bvarray_add( &si->si_authz, &bv );
+
+ return 0;
+}
+
+static int
+slap_idassert_parse( ConfigArgs *c, slap_idassert_t *si )
+{
+ int i;
+
+ for ( i = 1; i < c->argc; i++ ) {
+ if ( strncasecmp( c->argv[ i ], "mode=", STRLENOF( "mode=" ) ) == 0 ) {
+ char *argvi = c->argv[ i ] + STRLENOF( "mode=" );
+ int j;
+
+ j = verb_to_mask( argvi, idassert_mode );
+ if ( BER_BVISNULL( &idassert_mode[ j ].word ) ) {
+ snprintf( c->msg, sizeof( c->msg ),
+ "\"idassert-bind <args>\": "
+ "unknown mode \"%s\"",
+ argvi );
+ Debug( LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->msg, 0 );
+ return 1;
+ }
+
+ si->si_mode = idassert_mode[ j ].mask;
+
+ } else if ( strncasecmp( c->argv[ i ], "authz=", STRLENOF( "authz=" ) ) == 0 ) {
+ char *argvi = c->argv[ i ] + STRLENOF( "authz=" );
+
+ if ( strcasecmp( argvi, "native" ) == 0 ) {
+ if ( si->si_bc.sb_method != LDAP_AUTH_SASL ) {
+ snprintf( c->msg, sizeof( c->msg ),
+ "\"idassert-bind <args>\": "
+ "authz=\"native\" incompatible "
+ "with auth method" );
+ Debug( LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->msg, 0 );
+ return 1;
+ }
+ si->si_flags |= LDAP_BACK_AUTH_NATIVE_AUTHZ;
+
+ } else if ( strcasecmp( argvi, "proxyAuthz" ) == 0 ) {
+ si->si_flags &= ~LDAP_BACK_AUTH_NATIVE_AUTHZ;
+
+ } else {
+ snprintf( c->msg, sizeof( c->msg ),
+ "\"idassert-bind <args>\": "
+ "unknown authz \"%s\"",
+ argvi );
+ Debug( LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->msg, 0 );
+ return 1;
+ }
+
+ } else if ( strncasecmp( c->argv[ i ], "flags=", STRLENOF( "flags=" ) ) == 0 ) {
+ char *argvi = c->argv[ i ] + STRLENOF( "flags=" );
+ char **flags = ldap_str2charray( argvi, "," );
+ int j, err = 0;
+
+ if ( flags == NULL ) {
+ snprintf( c->msg, sizeof( c->msg ),
+ "\"idassert-bind <args>\": "
+ "unable to parse flags \"%s\"",
+ argvi );
+ Debug( LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->msg, 0 );
+ return 1;
+ }
+
+ for ( j = 0; flags[ j ] != NULL; j++ ) {
+
+ if ( strcasecmp( flags[ j ], "override" ) == 0 ) {
+ si->si_flags |= LDAP_BACK_AUTH_OVERRIDE;
+
+ } else if ( strcasecmp( flags[ j ], "prescriptive" ) == 0 ) {
+ si->si_flags |= LDAP_BACK_AUTH_PRESCRIPTIVE;
+
+ } else if ( strcasecmp( flags[ j ], "non-prescriptive" ) == 0 ) {
+ si->si_flags &= ( ~LDAP_BACK_AUTH_PRESCRIPTIVE );
+
+ } else if ( strcasecmp( flags[ j ], "obsolete-proxy-authz" ) == 0 ) {
+ if ( si->si_flags & LDAP_BACK_AUTH_OBSOLETE_ENCODING_WORKAROUND ) {
+ Debug( LDAP_DEBUG_ANY,
+ "%s: \"obsolete-proxy-authz\" flag "
+ "in \"idassert-mode <args>\" "
+ "incompatible with previously issued \"obsolete-encoding-workaround\" flag.\n",
+ c->log, 0, 0 );
+ err = 1;
+ break;
+
+ } else {
+ si->si_flags |= LDAP_BACK_AUTH_OBSOLETE_PROXY_AUTHZ;
+ }
+
+ } else if ( strcasecmp( flags[ j ], "obsolete-encoding-workaround" ) == 0 ) {
+ if ( si->si_flags & LDAP_BACK_AUTH_OBSOLETE_PROXY_AUTHZ ) {
+ Debug( LDAP_DEBUG_ANY,
+ "%s: \"obsolete-encoding-workaround\" flag "
+ "in \"idassert-mode <args>\" "
+ "incompatible with previously issued \"obsolete-proxy-authz\" flag.\n",
+ c->log, 0, 0 );
+ err = 1;
+ break;
+
+ } else {
+ si->si_flags |= LDAP_BACK_AUTH_OBSOLETE_ENCODING_WORKAROUND;
+ }
+
+ } else {
+ snprintf( c->msg, sizeof( c->msg ),
+ "\"idassert-bind <args>\": "
+ "unknown flag \"%s\"",
+ flags[ j ] );
+ Debug( LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->msg, 0 );
+ err = 1;
+ break;
+ }
+ }
+
+ ldap_charray_free( flags );
+ if ( err ) {
+ return 1;
+ }
+
+ } else if ( bindconf_parse( c->argv[ i ], &si->si_bc ) ) {
+ return 1;
+ }
+ }
+
+ return 0;
+}
+
+/* NOTE: temporary, until back-meta is ported to back-config */
+int
+slap_idassert_authzfrom_parse_cf( const char *fname, int lineno, const char *arg, slap_idassert_t *si )
+{
+ ConfigArgs c = { 0 };
+ char *argv[ 3 ];
+
+ snprintf( c.log, sizeof( c.log ), "%s: line %d", fname, lineno );
+ c.argc = 2;
+ c.argv = argv;
+ argv[ 0 ] = "idassert-authzFrom";
+ argv[ 1 ] = (char *)arg;
+ argv[ 2 ] = NULL;
+
+ return slap_idassert_authzfrom_parse( &c, si );
+}
+
+int
+slap_idassert_parse_cf( const char *fname, int lineno, int argc, char *argv[], slap_idassert_t *si )
+{
+ ConfigArgs c = { 0 };
+
+ snprintf( c.log, sizeof( c.log ), "%s: line %d", fname, lineno );
+ c.argc = argc;
+ c.argv = argv;
+
+ return slap_idassert_parse( &c, si );
+}
+
static int
ldap_back_cf_gen( ConfigArgs *c )
{
ldapinfo_t *li = ( ldapinfo_t * )c->be->be_private;
- int rc;
+ int rc = 0;
int i;
if ( c->op == SLAP_CONFIG_EMIT ) {
struct berval bv = BER_BVNULL;
- rc = 0;
if ( li == NULL ) {
return 1;
@@ -509,7 +864,7 @@ ldap_back_cf_gen( ConfigArgs *c )
/* end-of-flags */
}
- bindconf_unparse( &li->li_idassert, &bc );
+ bindconf_unparse( &li->li_idassert.si_bc, &bc );
if ( !BER_BVISNULL( &bv ) ) {
ber_len_t len = bv.bv_len + bc.bv_len;
@@ -548,7 +903,7 @@ ldap_back_cf_gen( ConfigArgs *c )
break;
case LDAP_BACK_CFG_T_F:
- enum_to_verb( t_f_mode, (li->li_flags & LDAP_BACK_F_SUPPORT_T_F_MASK), &bv );
+ enum_to_verb( t_f_mode, (li->li_flags & LDAP_BACK_F_T_F_MASK2), &bv );
if ( BER_BVISNULL( &bv ) ) {
/* there's something wrong... */
assert( 0 );
@@ -643,6 +998,35 @@ ldap_back_cf_gen( ConfigArgs *c )
c->value_int = LDAP_BACK_SINGLECONN( li );
break;
+ case LDAP_BACK_CFG_CANCEL: {
+ slap_mask_t mask = LDAP_BACK_F_CANCEL_MASK2;
+
+ if ( LDAP_BACK_CANCEL_DISCOVER( li ) ) {
+ mask &= ~LDAP_BACK_F_CANCEL_EXOP;
+ }
+ enum_to_verb( cancel_mode, (li->li_flags & mask), &bv );
+ if ( BER_BVISNULL( &bv ) ) {
+ /* there's something wrong... */
+ assert( 0 );
+ rc = 1;
+
+ } else {
+ value_add_one( &c->rvalue_vals, &bv );
+ }
+ } break;
+
+ case LDAP_BACK_CFG_QUARANTINE:
+ if ( !LDAP_BACK_QUARANTINE( li ) ) {
+ rc = 1;
+ break;
+ }
+
+ rc = slap_retry_info_unparse( &li->li_quarantine, &bv );
+ if ( rc == 0 ) {
+ ber_bvarray_add( &c->rvalue_vals, &bv );
+ }
+ break;
+
default:
/* FIXME: we need to handle all... */
assert( 0 );
@@ -651,7 +1035,6 @@ ldap_back_cf_gen( ConfigArgs *c )
return rc;
} else if ( c->op == LDAP_MOD_DELETE ) {
- rc = 0;
switch( c->type ) {
case LDAP_BACK_CFG_URI:
if ( li->li_uri != NULL ) {
@@ -704,13 +1087,14 @@ ldap_back_cf_gen( ConfigArgs *c )
break;
case LDAP_BACK_CFG_IDASSERT_BIND:
- bindconf_free( &li->li_idassert );
+ bindconf_free( &li->li_idassert.si_bc );
break;
case LDAP_BACK_CFG_REBIND:
case LDAP_BACK_CFG_CHASE:
case LDAP_BACK_CFG_T_F:
case LDAP_BACK_CFG_WHOAMI:
+ case LDAP_BACK_CFG_CANCEL:
rc = 1;
break;
@@ -740,6 +1124,16 @@ ldap_back_cf_gen( ConfigArgs *c )
li->li_flags &= ~LDAP_BACK_F_SINGLECONN;
break;
+ case LDAP_BACK_CFG_QUARANTINE:
+ if ( !LDAP_BACK_QUARANTINE( li ) ) {
+ break;
+ }
+
+ slap_retry_info_destroy( &li->li_quarantine );
+ ldap_pvt_thread_mutex_destroy( &li->li_quarantine_mutex );
+ li->li_isquarantined = 0;
+ break;
+
default:
/* FIXME: we need to handle all... */
assert( 0 );
@@ -1096,22 +1490,9 @@ done_url:;
ber_str2bv( c->argv[ 1 ], 0, 1, &li->li_idassert_passwd );
break;
- case LDAP_BACK_CFG_IDASSERT_AUTHZFROM: {
- struct berval bv;
- struct berval in;
- int rc;
-
- ber_str2bv( c->argv[ 1 ], 0, 0, &in );
- rc = authzNormalize( 0, NULL, NULL, &in, &bv, NULL );
- if ( rc != LDAP_SUCCESS ) {
- snprintf( c->msg, sizeof( c->msg ),
- "\"idassert-authzFrom <authz>\": "
- "invalid syntax" );
- Debug( LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->msg, 0 );
- return 1;
- }
- ber_bvarray_add( &li->li_idassert_authz, &bv );
- } break;
+ case LDAP_BACK_CFG_IDASSERT_AUTHZFROM:
+ rc = slap_idassert_authzfrom_parse( c, &li->li_idassert );
+ break;
case LDAP_BACK_CFG_IDASSERT_METHOD:
/* no longer supported */
@@ -1122,122 +1503,7 @@ done_url:;
return 1;
case LDAP_BACK_CFG_IDASSERT_BIND:
- for ( i = 1; i < c->argc; i++ ) {
- if ( strncasecmp( c->argv[ i ], "mode=", STRLENOF( "mode=" ) ) == 0 ) {
- char *argvi = c->argv[ i ] + STRLENOF( "mode=" );
- int j;
-
- j = verb_to_mask( argvi, idassert_mode );
- if ( BER_BVISNULL( &idassert_mode[ j ].word ) ) {
- snprintf( c->msg, sizeof( c->msg ),
- "\"idassert-bind <args>\": "
- "unknown mode \"%s\"",
- argvi );
- Debug( LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->msg, 0 );
- return 1;
- }
-
- li->li_idassert_mode = idassert_mode[ j ].mask;
-
- } else if ( strncasecmp( c->argv[ i ], "authz=", STRLENOF( "authz=" ) ) == 0 ) {
- char *argvi = c->argv[ i ] + STRLENOF( "authz=" );
-
- if ( strcasecmp( argvi, "native" ) == 0 ) {
- if ( li->li_idassert_authmethod != LDAP_AUTH_SASL ) {
- snprintf( c->msg, sizeof( c->msg ),
- "\"idassert-bind <args>\": "
- "authz=\"native\" incompatible "
- "with auth method" );
- Debug( LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->msg, 0 );
- return 1;
- }
- li->li_idassert_flags |= LDAP_BACK_AUTH_NATIVE_AUTHZ;
-
- } else if ( strcasecmp( argvi, "proxyAuthz" ) == 0 ) {
- li->li_idassert_flags &= ~LDAP_BACK_AUTH_NATIVE_AUTHZ;
-
- } else {
- snprintf( c->msg, sizeof( c->msg ),
- "\"idassert-bind <args>\": "
- "unknown authz \"%s\"",
- argvi );
- Debug( LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->msg, 0 );
- return 1;
- }
-
- } else if ( strncasecmp( c->argv[ i ], "flags=", STRLENOF( "flags=" ) ) == 0 ) {
- char *argvi = c->argv[ i ] + STRLENOF( "flags=" );
- char **flags = ldap_str2charray( argvi, "," );
- int j, err = 0;
-
- if ( flags == NULL ) {
- snprintf( c->msg, sizeof( c->msg ),
- "\"idassert-bind <args>\": "
- "unable to parse flags \"%s\"",
- argvi );
- Debug( LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->msg, 0 );
- return 1;
- }
-
- for ( j = 0; flags[ j ] != NULL; j++ ) {
-
- if ( strcasecmp( flags[ j ], "override" ) == 0 ) {
- li->li_idassert_flags |= LDAP_BACK_AUTH_OVERRIDE;
-
- } else if ( strcasecmp( flags[ j ], "prescriptive" ) == 0 ) {
- li->li_idassert_flags |= LDAP_BACK_AUTH_PRESCRIPTIVE;
-
- } else if ( strcasecmp( flags[ j ], "non-prescriptive" ) == 0 ) {
- li->li_idassert_flags &= ( ~LDAP_BACK_AUTH_PRESCRIPTIVE );
-
- } else if ( strcasecmp( flags[ j ], "obsolete-proxy-authz" ) == 0 ) {
- if ( li->li_idassert_flags & LDAP_BACK_AUTH_OBSOLETE_ENCODING_WORKAROUND ) {
- Debug( LDAP_DEBUG_ANY,
- "%s: line %d: \"obsolete-proxy-authz\" flag "
- "in \"idassert-mode <args>\" "
- "incompatible with previously issued \"obsolete-encoding-workaround\" flag.\n",
- c->fname, c->lineno, 0 );
- err = 1;
- break;
-
- } else {
- li->li_idassert_flags |= LDAP_BACK_AUTH_OBSOLETE_PROXY_AUTHZ;
- }
-
- } else if ( strcasecmp( flags[ j ], "obsolete-encoding-workaround" ) == 0 ) {
- if ( li->li_idassert_flags & LDAP_BACK_AUTH_OBSOLETE_PROXY_AUTHZ ) {
- Debug( LDAP_DEBUG_ANY,
- "%s: line %d: \"obsolete-encoding-workaround\" flag "
- "in \"idassert-mode <args>\" "
- "incompatible with previously issued \"obsolete-proxy-authz\" flag.\n",
- c->fname, c->lineno, 0 );
- err = 1;
- break;
-
- } else {
- li->li_idassert_flags |= LDAP_BACK_AUTH_OBSOLETE_ENCODING_WORKAROUND;
- }
-
- } else {
- snprintf( c->msg, sizeof( c->msg ),
- "\"idassert-bind <args>\": "
- "unknown flag \"%s\"",
- flags[ j ] );
- Debug( LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->msg, 0 );
- err = 1;
- break;
- }
- }
-
- ldap_charray_free( flags );
- if ( err ) {
- return 1;
- }
-
- } else if ( bindconf_parse( c->argv[ i ], &li->li_idassert ) ) {
- return 1;
- }
- }
+ rc = slap_idassert_parse( c, &li->li_idassert );
break;
case LDAP_BACK_CFG_REBIND:
@@ -1258,14 +1524,41 @@ done_url:;
}
break;
- case LDAP_BACK_CFG_T_F:
+ case LDAP_BACK_CFG_T_F: {
+ slap_mask_t mask;
+
i = verb_to_mask( c->argv[1], t_f_mode );
if ( BER_BVISNULL( &t_f_mode[i].word ) ) {
return 1;
}
- li->li_flags &= ~LDAP_BACK_F_SUPPORT_T_F_MASK;
- li->li_flags |= t_f_mode[i].mask;
- break;
+
+ mask = t_f_mode[i].mask;
+
+ if ( LDAP_BACK_ISOPEN( li )
+ && mask == LDAP_BACK_F_T_F_DISCOVER
+ && !LDAP_BACK_T_F( li ) )
+ {
+ int rc;
+
+ if ( li->li_uri == NULL ) {
+ snprintf( c->msg, sizeof( c->msg ),
+ "need URI to discover \"cancel\" support "
+ "in \"cancel exop-discover\"" );
+ Debug( LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->msg, 0 );
+ return 1;
+ }
+
+ rc = slap_discover_feature( li->li_uri, li->li_version,
+ slap_schema.si_ad_supportedFeatures->ad_cname.bv_val,
+ LDAP_FEATURE_ABSOLUTE_FILTERS );
+ if ( rc == LDAP_COMPARE_TRUE ) {
+ mask |= LDAP_BACK_F_T_F;
+ }
+ }
+
+ li->li_flags &= ~LDAP_BACK_F_T_F_MASK2;
+ li->li_flags |= mask;
+ } break;
case LDAP_BACK_CFG_WHOAMI:
if ( c->argc == 1 || c->value_int ) {
@@ -1362,6 +1655,62 @@ done_url:;
}
break;
+ case LDAP_BACK_CFG_CANCEL: {
+ slap_mask_t mask;
+
+ i = verb_to_mask( c->argv[1], cancel_mode );
+ if ( BER_BVISNULL( &cancel_mode[i].word ) ) {
+ return 1;
+ }
+
+ mask = cancel_mode[i].mask;
+
+ if ( LDAP_BACK_ISOPEN( li )
+ && mask == LDAP_BACK_F_CANCEL_EXOP_DISCOVER
+ && !LDAP_BACK_CANCEL( li ) )
+ {
+ int rc;
+
+ if ( li->li_uri == NULL ) {
+ snprintf( c->msg, sizeof( c->msg ),
+ "need URI to discover \"cancel\" support "
+ "in \"cancel exop-discover\"" );
+ Debug( LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->msg, 0 );
+ return 1;
+ }
+
+ rc = slap_discover_feature( li->li_uri, li->li_version,
+ slap_schema.si_ad_supportedExtension->ad_cname.bv_val,
+ LDAP_EXOP_CANCEL );
+ if ( rc == LDAP_COMPARE_TRUE ) {
+ mask |= LDAP_BACK_F_CANCEL_EXOP;
+ }
+ }
+
+ li->li_flags &= ~LDAP_BACK_F_CANCEL_MASK2;
+ li->li_flags |= mask;
+ } break;
+
+ case LDAP_BACK_CFG_QUARANTINE:
+ if ( LDAP_BACK_QUARANTINE( li ) ) {
+ snprintf( c->msg, sizeof( c->msg ),
+ "quarantine already defined" );
+ Debug( LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->msg, 0 );
+ return 1;
+ }
+ rc = slap_retry_info_parse( c->argv[1], &li->li_quarantine,
+ c->msg, sizeof( c->msg ) );
+ if ( rc ) {
+ Debug( LDAP_DEBUG_ANY, "%s: %s.\n", c->log, c->msg, 0 );
+
+ } else {
+ ldap_pvt_thread_mutex_init( &li->li_quarantine_mutex );
+ /* give it a chance to retry if the pattern gets reset
+ * via back-config */
+ li->li_isquarantined = 0;
+ }
+ break;
+
case LDAP_BACK_CFG_REWRITE:
snprintf( c->msg, sizeof( c->msg ),
"rewrite/remap capabilities have been moved "
@@ -1377,7 +1726,7 @@ done_url:;
break;
}
- return 0;
+ return rc;
}
int
diff --git a/servers/slapd/back-ldap/delete.c b/servers/slapd/back-ldap/delete.c
index e0f7c67905935758f3ac5af59ac23d509bb21f98..f95660cace1fe32a9a93f5b2fec1b7140691e524 100644
--- a/servers/slapd/back-ldap/delete.c
+++ b/servers/slapd/back-ldap/delete.c
@@ -38,11 +38,11 @@ ldap_back_delete(
{
ldapinfo_t *li = (ldapinfo_t *)op->o_bd->be_private;
- ldapconn_t *lc;
- ber_int_t msgid;
- LDAPControl **ctrls = NULL;
- int do_retry = 1;
- int rc = LDAP_SUCCESS;
+ ldapconn_t *lc;
+ ber_int_t msgid;
+ LDAPControl **ctrls = NULL;
+ ldap_back_send_t retrying = LDAP_BACK_RETRYING;
+ int rc = LDAP_SUCCESS;
lc = ldap_back_getconn( op, rs, LDAP_BACK_SENDERR );
@@ -51,7 +51,8 @@ ldap_back_delete(
}
ctrls = op->o_ctrls;
- rc = ldap_back_proxy_authz_ctrl( lc, op, rs, &ctrls );
+ rc = ldap_back_proxy_authz_ctrl( &lc->lc_bound_ndn,
+ li->li_version, &li->li_idassert, op, rs, &ctrls );
if ( rc != LDAP_SUCCESS ) {
send_ldap_result( op, rs );
rc = rs->sr_err;
@@ -62,9 +63,10 @@ retry:
rs->sr_err = ldap_delete_ext( lc->lc_ld, op->o_req_dn.bv_val,
ctrls, NULL, &msgid );
rc = ldap_back_op_result( lc, op, rs, msgid,
- li->li_timeout[ LDAP_BACK_OP_DELETE], LDAP_BACK_SENDRESULT );
- if ( rs->sr_err == LDAP_SERVER_DOWN && do_retry ) {
- do_retry = 0;
+ li->li_timeout[ LDAP_BACK_OP_DELETE],
+ ( LDAP_BACK_SENDRESULT | retrying ) );
+ if ( rs->sr_err == LDAP_SERVER_DOWN && retrying ) {
+ retrying &= ~LDAP_BACK_RETRYING;
if ( ldap_back_retry( &lc, op, rs, LDAP_BACK_SENDERR ) ) {
goto retry;
}
diff --git a/servers/slapd/back-ldap/distproc.c b/servers/slapd/back-ldap/distproc.c
index 5710a2198bf4b4550724c5e5327a2ac6188c3e7f..bdb382653223e69faf1b0da123bf36e555ed8f69 100644
--- a/servers/slapd/back-ldap/distproc.c
+++ b/servers/slapd/back-ldap/distproc.c
@@ -22,14 +22,15 @@
#include "portable.h"
-#ifdef LDAP_DEVEL
-
#include <stdio.h>
#include <ac/string.h>
#include <ac/socket.h>
#include "slap.h"
+
+#ifdef SLAP_DISTPROC
+
#include "back-ldap.h"
#include "config.h"
@@ -336,9 +337,10 @@ static ConfigTable distproc_cfg[] = {
"SYNTAX OMsDirectoryString SINGLE-VALUE )", NULL, NULL },
{ "distproc-cache-uri", "TRUE/FALSE",
2, 2, 0, ARG_MAGIC|ARG_ON_OFF|DP_CACHE_URI, distproc_cfgen,
- "( OLcfgOvAt:3.2 NAME 'olcCacheURI' "
+ "( OLcfgOvAt:3.2 NAME 'olcChainCacheURI' "
"DESC 'Enables caching of URIs not present in configuration' "
- "SYNTAX OMsBoolean SINGLE-VALUE )", NULL, NULL },
+ "SYNTAX OMsBoolean "
+ "SINGLE-VALUE )", NULL, NULL },
{ NULL, NULL, 0, 0, 0, ARG_IGNORED }
};
@@ -349,7 +351,7 @@ static ConfigOCs distproc_ocs[] = {
"SUP olcOverlayConfig "
"MAY ( "
"olcChainingBehavior $ "
- "olcCacheURI "
+ "olcChainCacheURI "
") )",
Cft_Overlay, distproc_cfg, NULL, distproc_cfadd },
{ "( OLcfgOvOc:7.2 "
@@ -1006,4 +1008,4 @@ distproc_initialize( void )
return overlay_register( &distproc );
}
-#endif /* LDAP_DEVEL */
+#endif /* SLAP_DISTPROC */
diff --git a/servers/slapd/back-ldap/extended.c b/servers/slapd/back-ldap/extended.c
index c4f43f8a4c334585ea36f809602a7ac0aa8de820..9af2738a8b5f5699da56297413de1e4469d9e448 100644
--- a/servers/slapd/back-ldap/extended.c
+++ b/servers/slapd/back-ldap/extended.c
@@ -42,6 +42,8 @@ static struct exop {
static int
ldap_back_extended_one( Operation *op, SlapReply *rs, BI_op_extended exop )
{
+ ldapinfo_t *li = (ldapinfo_t *) op->o_bd->be_private;
+
ldapconn_t *lc;
LDAPControl **oldctrls = NULL;
int rc;
@@ -56,7 +58,9 @@ ldap_back_extended_one( Operation *op, SlapReply *rs, BI_op_extended exop )
}
oldctrls = op->o_ctrls;
- if ( ldap_back_proxy_authz_ctrl( lc, op, rs, &op->o_ctrls ) ) {
+ if ( ldap_back_proxy_authz_ctrl( &lc->lc_bound_ndn,
+ li->li_version, &li->li_idassert, op, rs, &op->o_ctrls ) )
+ {
op->o_ctrls = oldctrls;
send_ldap_extended( op, rs );
rs->sr_text = NULL;
@@ -106,6 +110,8 @@ ldap_back_exop_passwd(
Operation *op,
SlapReply *rs )
{
+ ldapinfo_t *li = (ldapinfo_t *) op->o_bd->be_private;
+
ldapconn_t *lc;
req_pwdexop_s *qpw = &op->oq_pwdexop;
LDAPMessage *res;
@@ -181,10 +187,18 @@ retry:
goto retry;
}
}
+
+ if ( LDAP_BACK_QUARANTINE( li ) ) {
+ ldap_back_quarantine( op, rs );
+ }
+
if ( text ) rs->sr_text = text;
send_ldap_extended( op, rs );
/* otherwise frontend resends result */
rc = rs->sr_err = SLAPD_ABANDON;
+
+ } else if ( LDAP_BACK_QUARANTINE( li ) ) {
+ ldap_back_quarantine( op, rs );
}
/* these have to be freed anyway... */
@@ -210,6 +224,8 @@ ldap_back_exop_generic(
Operation *op,
SlapReply *rs )
{
+ ldapinfo_t *li = (ldapinfo_t *) op->o_bd->be_private;
+
ldapconn_t *lc;
LDAPMessage *res;
ber_int_t msgid;
@@ -241,7 +257,7 @@ retry:
*/
rc = ldap_parse_result( lc->lc_ld, res, &rs->sr_err,
(char **)&rs->sr_matched,
- text,
+ &text,
NULL, NULL, 0 );
if ( rc == LDAP_SUCCESS ) {
if ( rs->sr_err == LDAP_SUCCESS ) {
@@ -267,10 +283,18 @@ retry:
goto retry;
}
}
+
+ if ( LDAP_BACK_QUARANTINE( li ) ) {
+ ldap_back_quarantine( op, rs );
+ }
+
if ( text ) rs->sr_text = text;
send_ldap_extended( op, rs );
/* otherwise frontend resends result */
rc = rs->sr_err = SLAPD_ABANDON;
+
+ } else if ( LDAP_BACK_QUARANTINE( li ) ) {
+ ldap_back_quarantine( op, rs );
}
/* these have to be freed anyway... */
diff --git a/servers/slapd/back-ldap/init.c b/servers/slapd/back-ldap/init.c
index 765f201c21e1a0f8ce97667b23a0297dbb37570b..06cc1beda8c9b65bbf780a6f078913bcc513355a 100644
--- a/servers/slapd/back-ldap/init.c
+++ b/servers/slapd/back-ldap/init.c
@@ -84,7 +84,7 @@ ldap_back_initialize( BackendInfo *bi )
return -1;
}
-#ifdef LDAP_DEVEL
+#ifdef SLAP_DISTPROC
if ( distproc_initialize() ) {
return -1;
}
@@ -126,7 +126,7 @@ ldap_back_db_init( Backend *be )
li->li_idassert_authmethod = LDAP_AUTH_NONE;
BER_BVZERO( &li->li_idassert_sasl_mech );
- li->li_idassert.sb_tls = SB_TLS_DEFAULT;
+ li->li_idassert_tls = SB_TLS_DEFAULT;
/* by default, use proxyAuthz control on each operation */
li->li_idassert_flags = LDAP_BACK_AUTH_PRESCRIPTIVE;
@@ -200,19 +200,30 @@ ldap_back_db_open( BackendDB *be )
}
#endif /* SLAPD_MONITOR */
- if ( li->li_flags & LDAP_BACK_F_SUPPORT_T_F_DISCOVER ) {
+ if ( LDAP_BACK_T_F_DISCOVER( li ) && !LDAP_BACK_T_F( li ) ) {
int rc;
- li->li_flags &= ~LDAP_BACK_F_SUPPORT_T_F_DISCOVER;
-
rc = slap_discover_feature( li->li_uri, li->li_version,
slap_schema.si_ad_supportedFeatures->ad_cname.bv_val,
LDAP_FEATURE_ABSOLUTE_FILTERS );
if ( rc == LDAP_COMPARE_TRUE ) {
- li->li_flags |= LDAP_BACK_F_SUPPORT_T_F;
+ li->li_flags |= LDAP_BACK_F_T_F;
+ }
+ }
+
+ if ( LDAP_BACK_CANCEL_DISCOVER( li ) && !LDAP_BACK_CANCEL( li ) ) {
+ int rc;
+
+ rc = slap_discover_feature( li->li_uri, li->li_version,
+ slap_schema.si_ad_supportedExtension->ad_cname.bv_val,
+ LDAP_EXOP_CANCEL );
+ if ( rc == LDAP_COMPARE_TRUE ) {
+ li->li_flags |= LDAP_BACK_F_CANCEL_EXOP;
}
}
+ li->li_flags |= LDAP_BACK_F_ISOPEN;
+
return 0;
}
@@ -306,6 +317,10 @@ ldap_back_db_destroy(
if ( li->li_conninfo.lai_tree ) {
avl_free( li->li_conninfo.lai_tree, ldap_back_conn_free );
}
+ if ( LDAP_BACK_QUARANTINE( li ) ) {
+ slap_retry_info_destroy( &li->li_quarantine );
+ ldap_pvt_thread_mutex_destroy( &li->li_quarantine_mutex );
+ }
ldap_pvt_thread_mutex_unlock( &li->li_conninfo.lai_mutex );
ldap_pvt_thread_mutex_destroy( &li->li_conninfo.lai_mutex );
diff --git a/servers/slapd/back-ldap/modify.c b/servers/slapd/back-ldap/modify.c
index 6b75ef74f7ab2c5a6584f5d157281ed22b607502..7e6e7ecad5596d19888117f41e99370944583a27 100644
--- a/servers/slapd/back-ldap/modify.c
+++ b/servers/slapd/back-ldap/modify.c
@@ -36,17 +36,17 @@ ldap_back_modify(
Operation *op,
SlapReply *rs )
{
- ldapinfo_t *li = (ldapinfo_t *)op->o_bd->be_private;
-
- ldapconn_t *lc;
- LDAPMod **modv = NULL,
- *mods = NULL;
- Modifications *ml;
- int i, j, rc;
- ber_int_t msgid;
- int isupdate;
- int do_retry = 1;
- LDAPControl **ctrls = NULL;
+ ldapinfo_t *li = (ldapinfo_t *)op->o_bd->be_private;
+
+ ldapconn_t *lc;
+ LDAPMod **modv = NULL,
+ *mods = NULL;
+ Modifications *ml;
+ int i, j, rc;
+ ber_int_t msgid;
+ int isupdate;
+ ldap_back_send_t retrying = LDAP_BACK_RETRYING;
+ LDAPControl **ctrls = NULL;
lc = ldap_back_getconn( op, rs, LDAP_BACK_SENDERR );
if ( !lc || !ldap_back_dobind( lc, op, rs, LDAP_BACK_SENDERR ) ) {
@@ -99,7 +99,8 @@ ldap_back_modify(
modv[ i ] = 0;
ctrls = op->o_ctrls;
- rc = ldap_back_proxy_authz_ctrl( lc, op, rs, &ctrls );
+ rc = ldap_back_proxy_authz_ctrl( &lc->lc_bound_ndn,
+ li->li_version, &li->li_idassert, op, rs, &ctrls );
if ( rc != LDAP_SUCCESS ) {
send_ldap_result( op, rs );
rc = -1;
@@ -110,9 +111,10 @@ retry:
rs->sr_err = ldap_modify_ext( lc->lc_ld, op->o_req_dn.bv_val, modv,
ctrls, NULL, &msgid );
rc = ldap_back_op_result( lc, op, rs, msgid,
- li->li_timeout[ LDAP_BACK_OP_MODIFY], LDAP_BACK_SENDRESULT );
- if ( rs->sr_err == LDAP_UNAVAILABLE && do_retry ) {
- do_retry = 0;
+ li->li_timeout[ LDAP_BACK_OP_MODIFY],
+ ( LDAP_BACK_SENDRESULT | retrying ) );
+ if ( rs->sr_err == LDAP_UNAVAILABLE && retrying ) {
+ retrying &= ~LDAP_BACK_RETRYING;
if ( ldap_back_retry( &lc, op, rs, LDAP_BACK_SENDERR ) ) {
goto retry;
}
diff --git a/servers/slapd/back-ldap/modrdn.c b/servers/slapd/back-ldap/modrdn.c
index eb5690ce6c1b9b0d040144d48f501c2b33713c74..37e1afe7e86f91c000d0e0e859b4321b384d8feb 100644
--- a/servers/slapd/back-ldap/modrdn.c
+++ b/servers/slapd/back-ldap/modrdn.c
@@ -36,14 +36,14 @@ ldap_back_modrdn(
Operation *op,
SlapReply *rs )
{
- ldapinfo_t *li = (ldapinfo_t *)op->o_bd->be_private;
+ ldapinfo_t *li = (ldapinfo_t *)op->o_bd->be_private;
- ldapconn_t *lc;
- ber_int_t msgid;
- LDAPControl **ctrls = NULL;
- int do_retry = 1;
- int rc = LDAP_SUCCESS;
- char *newSup = NULL;
+ ldapconn_t *lc;
+ ber_int_t msgid;
+ LDAPControl **ctrls = NULL;
+ ldap_back_send_t retrying = LDAP_BACK_RETRYING;
+ int rc = LDAP_SUCCESS;
+ char *newSup = NULL;
lc = ldap_back_getconn( op, rs, LDAP_BACK_SENDERR );
if ( !lc || !ldap_back_dobind( lc, op, rs, LDAP_BACK_SENDERR ) ) {
@@ -74,7 +74,8 @@ ldap_back_modrdn(
}
ctrls = op->o_ctrls;
- rc = ldap_back_proxy_authz_ctrl( lc, op, rs, &ctrls );
+ rc = ldap_back_proxy_authz_ctrl( &lc->lc_bound_ndn,
+ li->li_version, &li->li_idassert, op, rs, &ctrls );
if ( rc != LDAP_SUCCESS ) {
send_ldap_result( op, rs );
rc = -1;
@@ -86,9 +87,10 @@ retry:
op->orr_newrdn.bv_val, newSup,
op->orr_deleteoldrdn, ctrls, NULL, &msgid );
rc = ldap_back_op_result( lc, op, rs, msgid,
- li->li_timeout[ LDAP_BACK_OP_MODRDN ], LDAP_BACK_SENDRESULT );
- if ( rs->sr_err == LDAP_SERVER_DOWN && do_retry ) {
- do_retry = 0;
+ li->li_timeout[ LDAP_BACK_OP_MODRDN ],
+ ( LDAP_BACK_SENDRESULT | retrying ) );
+ if ( rs->sr_err == LDAP_SERVER_DOWN && retrying ) {
+ retrying &= ~LDAP_BACK_RETRYING;
if ( ldap_back_retry( &lc, op, rs, LDAP_BACK_SENDERR ) ) {
goto retry;
}
diff --git a/servers/slapd/back-ldap/proto-ldap.h b/servers/slapd/back-ldap/proto-ldap.h
index 05d68832549e6ff20bc9cbae843202be0340bb5d..d37eea9cbf782eb2cf3c03ab4eb6b4eed8084ce1 100644
--- a/servers/slapd/back-ldap/proto-ldap.h
+++ b/servers/slapd/back-ldap/proto-ldap.h
@@ -56,6 +56,7 @@ int ldap_back_retry( ldapconn_t **lcp, Operation *op, SlapReply *rs, ldap_back_s
int ldap_back_map_result( SlapReply *rs );
int ldap_back_op_result( ldapconn_t *lc, Operation *op, SlapReply *rs,
ber_int_t msgid, time_t timeout, ldap_back_send_t sendok );
+int ldap_back_cancel( ldapconn_t *lc, Operation *op, SlapReply *rs, ber_int_t msgid, ldap_back_send_t sendok );
int ldap_back_init_cf( BackendInfo *bi );
@@ -66,7 +67,9 @@ extern void ldap_back_conn_free( void *c );
extern int
ldap_back_proxy_authz_ctrl(
- ldapconn_t *lc,
+ struct berval *bound_ndn,
+ int version,
+ slap_idassert_t *si,
Operation *op,
SlapReply *rs,
LDAPControl ***pctrls );
@@ -76,8 +79,21 @@ ldap_back_proxy_authz_ctrl_free(
Operation *op,
LDAPControl ***pctrls );
+extern void
+ldap_back_quarantine(
+ Operation *op,
+ SlapReply *rs );
+
+extern void slap_retry_info_destroy( slap_retry_info_t *ri );
+extern int slap_retry_info_parse( char *in, slap_retry_info_t *ri,
+ char *buf, ber_len_t buflen );
+extern int slap_retry_info_unparse( slap_retry_info_t *ri, struct berval *bvout );
+
+extern int slap_idassert_authzfrom_parse_cf( const char *fname, int lineno, const char *arg, slap_idassert_t *si );
+extern int slap_idassert_parse_cf( const char *fname, int lineno, int argc, char *argv[], slap_idassert_t *si );
+
extern int chain_initialize( void );
-#ifdef LDAP_DEVEL
+#ifdef SLAP_DISTPROC
extern int distproc_initialize( void );
#endif
diff --git a/servers/slapd/back-ldap/search.c b/servers/slapd/back-ldap/search.c
index dbe612d5497ef5b10f393604b6798d7fa71e6331..97d4ee2c7a87d6cfd5025e03a383ce0090968840 100644
--- a/servers/slapd/back-ldap/search.c
+++ b/servers/slapd/back-ldap/search.c
@@ -75,7 +75,7 @@ ldap_back_munge_filter(
if ( strncmp( ptr, bv_true.bv_val, bv_true.bv_len ) == 0 ) {
oldbv = &bv_true;
- if ( li->li_flags & LDAP_BACK_F_SUPPORT_T_F ) {
+ if ( LDAP_BACK_T_F( li ) ) {
newbv = &bv_t;
} else {
@@ -85,7 +85,7 @@ ldap_back_munge_filter(
} else if ( strncmp( ptr, bv_false.bv_val, bv_false.bv_len ) == 0 )
{
oldbv = &bv_false;
- if ( li->li_flags & LDAP_BACK_F_SUPPORT_T_F ) {
+ if ( LDAP_BACK_T_F( li ) ) {
newbv = &bv_f;
} else {
@@ -141,6 +141,8 @@ ldap_back_search(
Operation *op,
SlapReply *rs )
{
+ ldapinfo_t *li = (ldapinfo_t *) op->o_bd->be_private;
+
ldapconn_t *lc;
struct timeval tv;
time_t stoptime = (time_t)-1;
@@ -201,7 +203,8 @@ ldap_back_search(
}
ctrls = op->o_ctrls;
- rc = ldap_back_proxy_authz_ctrl( lc, op, rs, &ctrls );
+ rc = ldap_back_proxy_authz_ctrl( &lc->lc_bound_ndn,
+ li->li_version, &li->li_idassert, op, rs, &ctrls );
if ( rc != LDAP_SUCCESS ) {
goto finish;
}
@@ -264,7 +267,7 @@ retry:
if ( rc > 0 ) {
ldap_msgfree( res );
}
- ldap_abandon_ext( lc->lc_ld, msgid, NULL, NULL );
+ (void)ldap_back_cancel( lc, op, rs, msgid, LDAP_BACK_DONTSEND );
rc = SLAPD_ABANDON;
goto finish;
}
@@ -277,7 +280,7 @@ retry:
if ( op->ors_tlimit != SLAP_NO_LIMIT
&& slap_get_time() > stoptime )
{
- ldap_abandon_ext( lc->lc_ld, msgid, NULL, NULL );
+ (void)ldap_back_cancel( lc, op, rs, msgid, LDAP_BACK_DONTSEND );
rc = rs->sr_err = LDAP_TIMELIMIT_EXCEEDED;
goto finish;
}
@@ -320,7 +323,7 @@ retry:
if ( rc == LDAP_UNAVAILABLE ) {
rc = rs->sr_err = LDAP_OTHER;
} else {
- ldap_abandon_ext( lc->lc_ld, msgid, NULL, NULL );
+ (void)ldap_back_cancel( lc, op, rs, msgid, LDAP_BACK_DONTSEND );
}
goto finish;
}
@@ -344,7 +347,8 @@ retry:
/* NO OP */ ;
/* FIXME: there MUST be at least one */
- rs->sr_ref = ch_malloc( ( cnt + 1 ) * sizeof( struct berval ) );
+ rs->sr_ref = op->o_tmpalloc( ( cnt + 1 ) * sizeof( struct berval ),
+ op->o_tmpmemctx );
for ( cnt = 0; references[ cnt ]; cnt++ ) {
ber_str2bv( references[ cnt ], 0, 0, &rs->sr_ref[ cnt ] );
@@ -365,7 +369,7 @@ retry:
/* cleanup */
if ( references ) {
ber_memvfree( (void **)references );
- ch_free( rs->sr_ref );
+ op->o_tmpfree( rs->sr_ref, op->o_tmpmemctx );
rs->sr_ref = NULL;
}
@@ -405,7 +409,8 @@ retry:
for ( cnt = 0; references[ cnt ]; cnt++ )
/* NO OP */ ;
- rs->sr_ref = ch_malloc( ( cnt + 1 ) * sizeof( struct berval ) );
+ rs->sr_ref = op->o_tmpalloc( ( cnt + 1 ) * sizeof( struct berval ),
+ op->o_tmpmemctx );
for ( cnt = 0; references[ cnt ]; cnt++ ) {
/* duplicating ...*/
@@ -415,9 +420,7 @@ retry:
}
if ( match.bv_val != NULL ) {
- {
- match.bv_len = strlen( match.bv_val );
- }
+ match.bv_len = strlen( match.bv_val );
}
/* cleanup */
@@ -462,7 +465,15 @@ retry:
}
finish:;
- if ( rc != SLAPD_ABANDON ) {
+ if ( LDAP_BACK_QUARANTINE( li ) ) {
+ ldap_back_quarantine( op, rs );
+ }
+
+#if 0
+ /* let send_ldap_result play cleanup handlers (ITS#4645) */
+ if ( rc != SLAPD_ABANDON )
+#endif
+ {
send_ldap_result( op, rs );
}
@@ -495,7 +506,7 @@ finish:;
}
if ( rs->sr_ref ) {
- ber_bvarray_free( rs->sr_ref );
+ ber_bvarray_free_x( rs->sr_ref, op->o_tmpmemctx );
rs->sr_ref = NULL;
}
@@ -702,9 +713,10 @@ ldap_back_entry_get(
ObjectClass *oc,
AttributeDescription *at,
int rw,
- Entry **ent
-)
+ Entry **ent )
{
+ ldapinfo_t *li = (ldapinfo_t *) op->o_bd->be_private;
+
ldapconn_t *lc;
int rc = 1,
do_not_cache;
@@ -754,7 +766,8 @@ ldap_back_entry_get(
}
ctrls = op->o_ctrls;
- rc = ldap_back_proxy_authz_ctrl( lc, op, &rs, &ctrls );
+ rc = ldap_back_proxy_authz_ctrl( &lc->lc_bound_ndn,
+ li->li_version, &li->li_idassert, op, &rs, &ctrls );
if ( rc != LDAP_SUCCESS ) {
goto cleanup;
}
diff --git a/servers/slapd/back-ldif/ldif.c b/servers/slapd/back-ldif/ldif.c
index db629ba55dae5c1a8f6bf9cd8891a7b4e7d2dbc0..ca1d36bf6389bb5ceeea08d1fdad6db2a61d5453 100644
--- a/servers/slapd/back-ldif/ldif.c
+++ b/servers/slapd/back-ldif/ldif.c
@@ -86,6 +86,7 @@ dn2path(struct berval * dn, struct berval * suffixdn, struct berval * base_path,
struct berval *res)
{
char *ptr, *sep, *end;
+ struct berval bv;
assert( dn != NULL );
assert( !BER_BVISNULL( dn ) );
@@ -107,14 +108,19 @@ dn2path(struct berval * dn, struct berval * suffixdn, struct berval * base_path,
}
strcpy(ptr, LDIF);
#if IX_FSL != IX_DNL
- ptr = res->bv_val;
- while( ptr=strchr(ptr, IX_DNL) ) {
+ bv = *res;
+ while ( ptr = ber_bvchr( &bv, IX_DNL ) ) {
*ptr++ = IX_FSL;
- ptr = strchr(ptr, IX_DNR);
- if ( ptr )
- *ptr++ = IX_FSR;
- else
+ assert( ( ptr - bv.bv_val ) <= bv.bv_len );
+ bv.bv_len -= ( ptr - bv.bv_val );
+ bv.bv_val = ptr;
+ ptr = ber_bvchr( &bv, IX_DNR );
+ if ( !ptr )
break;
+ *ptr++ = IX_FSR;
+ assert( ( ptr - bv.bv_val ) <= bv.bv_len );
+ bv.bv_len -= ( ptr - bv.bv_val );
+ bv.bv_val = ptr;
}
#endif
}
@@ -412,11 +418,13 @@ static int r_enum_tree(enumCookie *ck, struct berval *path,
bvl = ch_malloc( sizeof(bvlist) );
ber_dupbv( &bvl->bv, &fname );
BER_BVZERO( &bvl->num );
- itmp.bv_val = strchr( bvl->bv.bv_val, IX_FSL );
+ itmp.bv_val = ber_bvchr( &bvl->bv, IX_FSL );
if ( itmp.bv_val ) {
char *ptr;
itmp.bv_val++;
- ptr = strchr( itmp.bv_val, IX_FSR );
+ itmp.bv_len = bvl->bv.bv_len
+ - ( itmp.bv_val - bvl->bv.bv_val );
+ ptr = ber_bvchr( &itmp, IX_FSR );
if ( ptr ) {
itmp.bv_len = ptr - itmp.bv_val;
ber_dupbv( &bvl->num, &itmp );
diff --git a/servers/slapd/back-meta/add.c b/servers/slapd/back-meta/add.c
index 02a0093d5c9d65ec4a329ba58c1626e3076498f5..6ff7a9c81e0e92b009d05c69b20dc1fc65c0851d 100644
--- a/servers/slapd/back-meta/add.c
+++ b/servers/slapd/back-meta/add.c
@@ -36,6 +36,7 @@ int
meta_back_add( Operation *op, SlapReply *rs )
{
metainfo_t *mi = ( metainfo_t * )op->o_bd->be_private;
+ metatarget_t *mt;
metaconn_t *mc;
int i, candidate = -1;
int isupdate;
@@ -45,7 +46,7 @@ meta_back_add( Operation *op, SlapReply *rs )
dncookie dc;
int msgid;
int do_retry = 1;
- int maperr = 1;
+ LDAPControl **ctrls = NULL;
Debug(LDAP_DEBUG_ARGS, "==> meta_back_add: %s\n",
op->o_req_dn.bv_val, 0, 0 );
@@ -63,7 +64,8 @@ meta_back_add( Operation *op, SlapReply *rs )
/*
* Rewrite the add dn, if needed
*/
- dc.target = mi->mi_targets[ candidate ];
+ mt = mi->mi_targets[ candidate ];
+ dc.target = mt;
dc.conn = op->o_conn;
dc.rs = rs;
dc.ctx = "addDN";
@@ -96,7 +98,7 @@ meta_back_add( Operation *op, SlapReply *rs )
mapped = a->a_desc->ad_cname;
} else {
- ldap_back_map( &mi->mi_targets[ candidate ]->mt_rwmap.rwm_at,
+ ldap_back_map( &mt->mt_rwmap.rwm_at,
&a->a_desc->ad_cname, &mapped, BACKLDAP_MAP );
if ( BER_BVISNULL( &mapped ) || BER_BVISEMPTY( &mapped ) ) {
continue;
@@ -121,11 +123,11 @@ meta_back_add( Operation *op, SlapReply *rs )
for ( j = 0; !BER_BVISNULL( &a->a_vals[ j ] ); ) {
struct ldapmapping *mapping;
- ldap_back_mapping( &mi->mi_targets[ candidate ]->mt_rwmap.rwm_oc,
+ ldap_back_mapping( &mt->mt_rwmap.rwm_oc,
&a->a_vals[ j ], &mapping, BACKLDAP_MAP );
if ( mapping == NULL ) {
- if ( mi->mi_targets[ candidate ]->mt_rwmap.rwm_oc.drop_missing ) {
+ if ( mt->mt_rwmap.rwm_oc.drop_missing ) {
continue;
}
attrs[ i ]->mod_bvalues[ j ] = &a->a_vals[ j ];
@@ -165,65 +167,29 @@ meta_back_add( Operation *op, SlapReply *rs )
}
attrs[ i ] = NULL;
+ ctrls = op->o_ctrls;
+ if ( ldap_back_proxy_authz_ctrl( &mc->mc_conns[ candidate ].msc_bound_ndn,
+ mt->mt_version, &mt->mt_idassert, op, rs, &ctrls ) != LDAP_SUCCESS )
+ {
+ send_ldap_result( op, rs );
+ goto cleanup;
+ }
+
retry:;
rs->sr_err = ldap_add_ext( mc->mc_conns[ candidate ].msc_ld, mdn.bv_val,
- attrs, op->o_ctrls, NULL, &msgid );
+ attrs, ctrls, NULL, &msgid );
+ rs->sr_err = meta_back_op_result( mc, op, rs, candidate, msgid,
+ mt->mt_timeout[ LDAP_BACK_OP_ADD ], LDAP_BACK_SENDRESULT );
if ( rs->sr_err == LDAP_UNAVAILABLE && do_retry ) {
do_retry = 0;
if ( meta_back_retry( op, rs, &mc, candidate, LDAP_BACK_SENDERR ) ) {
goto retry;
}
- goto cleanup;
-
- } else if ( rs->sr_err == LDAP_SUCCESS ) {
- struct timeval tv, *tvp = NULL;
- LDAPMessage *res = NULL;
- int rc;
-
- if ( mi->mi_targets[ candidate ]->mt_timeout[ LDAP_BACK_OP_ADD ] != 0 ) {
- tv.tv_sec = mi->mi_targets[ candidate ]->mt_timeout[ LDAP_BACK_OP_ADD ];
- tv.tv_usec = 0;
- tvp = &tv;
- }
-
- rs->sr_err = LDAP_OTHER;
- maperr = 0;
- rc = ldap_result( mc->mc_conns[ candidate ].msc_ld,
- msgid, LDAP_MSG_ALL, tvp, &res );
- switch ( rc ) {
- case -1:
- break;
-
- case 0:
- ldap_abandon_ext( mc->mc_conns[ candidate ].msc_ld,
- msgid, NULL, NULL );
- rs->sr_err = op->o_protocol >= LDAP_VERSION3 ?
- LDAP_ADMINLIMIT_EXCEEDED : LDAP_OPERATIONS_ERROR;
- break;
-
- case LDAP_RES_ADD:
- rc = ldap_parse_result( mc->mc_conns[ candidate ].msc_ld,
- res, &rs->sr_err, NULL, NULL, NULL, NULL, 1 );
- if ( rc != LDAP_SUCCESS ) {
- rs->sr_err = rc;
- }
- maperr = 1;
- break;
-
- default:
- ldap_msgfree( res );
- break;
- }
- }
-
- if ( maperr ) {
- rs->sr_err = meta_back_op_result( mc, op, rs, candidate );
-
- } else {
- send_ldap_result( op, rs );
}
cleanup:;
+ (void)ldap_back_proxy_authz_ctrl_free( op, &ctrls );
+
for ( --i; i >= 0; --i ) {
free( attrs[ i ]->mod_bvalues );
free( attrs[ i ] );
diff --git a/servers/slapd/back-meta/back-meta.h b/servers/slapd/back-meta/back-meta.h
index 0516f619f3ba3d27546664dd73d574f80b4f159d..21259ca6378402ac4f09e5b66a6acb2bdb45ea1a 100644
--- a/servers/slapd/back-meta/back-meta.h
+++ b/servers/slapd/back-meta/back-meta.h
@@ -157,8 +157,21 @@ struct metainfo_t;
typedef struct metasingleconn_t {
int msc_candidate;
-#define META_NOT_CANDIDATE ((ber_tag_t)0)
-#define META_CANDIDATE ((ber_tag_t)1)
+#define META_NOT_CANDIDATE ((ber_tag_t)0x0)
+#define META_CANDIDATE ((ber_tag_t)0x1)
+#define META_BINDING ((ber_tag_t)0x2)
+
+#define META_CND_ISSET(rs,f) ( ( (rs)->sr_tag & (f) ) == (f) )
+#define META_CND_SET(rs,f) ( (rs)->sr_tag |= (f) )
+#define META_CND_CLEAR(rs,f) ( (rs)->sr_tag &= ~(f) )
+
+#define META_CANDIDATE_RESET(rs) ( (rs)->sr_tag = 0 )
+#define META_IS_CANDIDATE(rs) META_CND_ISSET( (rs), META_CANDIDATE )
+#define META_CANDIDATE_SET(rs) META_CND_SET( (rs), META_CANDIDATE )
+#define META_CANDIDATE_CLEAR(rs) META_CND_CLEAR( (rs), META_CANDIDATE )
+#define META_IS_BINDING(rs) META_CND_ISSET( (rs), META_BINDING )
+#define META_BINDING_SET(rs) META_CND_SET( (rs), META_BINDING )
+#define META_BINDING_CLEAR(rs) META_CND_CLEAR( (rs), META_BINDING )
LDAP *msc_ld;
struct berval msc_bound_ndn;
@@ -216,18 +229,45 @@ typedef struct metatarget_t {
struct berval mt_binddn;
struct berval mt_bindpw;
- struct berval mt_pseudorootdn;
- struct berval mt_pseudorootpw;
+ slap_idassert_t mt_idassert;
+#define mt_idassert_mode mt_idassert.si_mode
+#define mt_idassert_authcID mt_idassert.si_bc.sb_authcId
+#define mt_idassert_authcDN mt_idassert.si_bc.sb_binddn
+#define mt_idassert_passwd mt_idassert.si_bc.sb_cred
+#define mt_idassert_authzID mt_idassert.si_bc.sb_authzId
+#define mt_idassert_authmethod mt_idassert.si_bc.sb_method
+#define mt_idassert_sasl_mech mt_idassert.si_bc.sb_saslmech
+#define mt_idassert_sasl_realm mt_idassert.si_bc.sb_realm
+#define mt_idassert_secprops mt_idassert.si_bc.sb_secprops
+#define mt_idassert_tls mt_idassert.si_bc.sb_tls
+#define mt_idassert_flags mt_idassert.si_flags
+#define mt_idassert_authz mt_idassert.si_authz
int mt_nretries;
#define META_RETRY_UNDEFINED (-2)
#define META_RETRY_FOREVER (-1)
#define META_RETRY_NEVER (0)
-#define META_RETRY_DEFAULT (3)
+#define META_RETRY_DEFAULT (10)
struct ldaprwmap mt_rwmap;
+ sig_atomic_t mt_isquarantined;
+ slap_retry_info_t mt_quarantine;
+ ldap_pvt_thread_mutex_t mt_quarantine_mutex;
+#define META_BACK_TGT_QUARANTINE(mt) ( (mt)->mt_quarantine.ri_num != NULL )
+
unsigned mt_flags;
+#define META_BACK_TGT_ISSET(mt,f) ( ( (mt)->mt_flags & (f) ) == (f) )
+#define META_BACK_TGT_ISMASK(mt,m,f) ( ( (mt)->mt_flags & (m) ) == (f) )
+
+#define META_BACK_TGT_T_F(mt) META_BACK_TGT_ISMASK( (mt), LDAP_BACK_F_T_F_MASK, LDAP_BACK_F_T_F )
+#define META_BACK_TGT_T_F_DISCOVER(mt) META_BACK_TGT_ISMASK( (mt), LDAP_BACK_F_T_F_MASK2, LDAP_BACK_F_T_F_DISCOVER )
+
+#define META_BACK_TGT_ABANDON(mt) META_BACK_TGT_ISMASK( (mt), LDAP_BACK_F_CANCEL_MASK, LDAP_BACK_F_CANCEL_ABANDON )
+#define META_BACK_TGT_IGNORE(mt) META_BACK_TGT_ISMASK( (mt), LDAP_BACK_F_CANCEL_MASK, LDAP_BACK_F_CANCEL_IGNORE )
+#define META_BACK_TGT_CANCEL(mt) META_BACK_TGT_ISMASK( (mt), LDAP_BACK_F_CANCEL_MASK, LDAP_BACK_F_CANCEL_EXOP )
+#define META_BACK_TGT_CANCEL_DISCOVER(mt) META_BACK_TGT_ISMASK( (mt), LDAP_BACK_F_CANCEL_MASK2, LDAP_BACK_F_CANCEL_EXOP_DISCOVER )
+
int mt_version;
time_t mt_network_timeout;
struct timeval mt_bind_timeout;
@@ -249,6 +289,11 @@ typedef struct metacandidates_t {
SlapReply *mc_candidates;
} metacandidates_t;
+/*
+ * Hook to allow mucking with metainfo_t/metatarget_t when quarantine is over
+ */
+typedef int (*meta_back_quarantine_f)( struct metainfo_t *, int target, void * );
+
typedef struct metainfo_t {
int mi_ntargets;
int mi_defaulttarget;
@@ -265,6 +310,13 @@ typedef struct metainfo_t {
ldap_avl_info_t mi_conninfo;
+ /* NOTE: quarantine uses the connection mutex */
+ slap_retry_info_t mi_quarantine;
+
+#define META_BACK_QUARANTINE(mi) ( (mi)->mi_quarantine.ri_num != NULL )
+ meta_back_quarantine_f mi_quarantine_f;
+ void *mi_quarantine_p;
+
unsigned mi_flags;
#define li_flags mi_flags
/* uses flags as defined in <back-ldap/back-ldap.h> */
@@ -323,19 +375,16 @@ extern int
meta_back_init_one_conn(
Operation *op,
SlapReply *rs,
- metatarget_t *mt,
metaconn_t *mc,
int candidate,
int ispriv,
ldap_back_send_t sendok );
-extern int
-meta_back_single_bind(
+extern void
+meta_back_quarantine(
Operation *op,
SlapReply *rs,
- metaconn_t *mc,
- int candidate,
- int massage );
+ int candidate );
extern int
meta_back_dobind(
@@ -354,12 +403,35 @@ meta_back_single_dobind(
int retries,
int dolock );
+extern int
+meta_back_proxy_authz_cred(
+ metaconn_t *mc,
+ int candidate,
+ Operation *op,
+ SlapReply *rs,
+ ldap_back_send_t sendok,
+ struct berval *binddn,
+ struct berval *bindcred,
+ int *method );
+
+extern int
+meta_back_cancel(
+ metaconn_t *mc,
+ Operation *op,
+ SlapReply *rs,
+ ber_int_t msgid,
+ int candidate,
+ ldap_back_send_t sendok );
+
extern int
meta_back_op_result(
metaconn_t *mc,
Operation *op,
SlapReply *rs,
- int candidate );
+ int candidate,
+ ber_int_t msgid,
+ time_t timeout,
+ ldap_back_send_t sendok );
extern int
back_meta_LTX_init_module(
@@ -386,9 +458,7 @@ meta_back_conndn_dup(
*/
extern int
meta_back_is_candidate(
- struct berval *nsuffix,
- int suffixscope,
- BerVarray subtree_exclude,
+ metatarget_t *mt,
struct berval *ndn,
int scope );
diff --git a/servers/slapd/back-meta/bind.c b/servers/slapd/back-meta/bind.c
index cd79a04ced6ab3e6392cafe01782ef6dadfa236e..9a3b8c8f33fc6d7340397790ce2c250862559522 100644
--- a/servers/slapd/back-meta/bind.c
+++ b/servers/slapd/back-meta/bind.c
@@ -34,6 +34,23 @@
#include "../back-ldap/back-ldap.h"
#include "back-meta.h"
+#include "lutil_ldap.h"
+
+static int
+meta_back_proxy_authz_bind(
+ metaconn_t *mc,
+ int candidate,
+ Operation *op,
+ SlapReply *rs,
+ ldap_back_send_t sendok );
+
+static int
+meta_back_single_bind(
+ Operation *op,
+ SlapReply *rs,
+ metaconn_t *mc,
+ int candidate );
+
int
meta_back_bind( Operation *op, SlapReply *rs )
{
@@ -78,17 +95,19 @@ meta_back_bind( Operation *op, SlapReply *rs )
* invalidCredentials */
mc = meta_back_getconn( op, rs, NULL, LDAP_BACK_BIND_DONTSEND );
if ( !mc ) {
- char buf[ SLAP_TEXT_BUFLEN ];
-
- snprintf( buf, sizeof( buf ),
- "meta_back_bind: no target "
- "for dn \"%s\" (%d%s%s).",
- op->o_req_dn.bv_val, rs->sr_err,
- rs->sr_text ? ". " : "",
- rs->sr_text ? rs->sr_text : "" );
- Debug( LDAP_DEBUG_ANY,
- "%s %s\n",
- op->o_log_prefix, buf, 0 );
+ if ( LogTest( LDAP_DEBUG_ANY ) ) {
+ char buf[ SLAP_TEXT_BUFLEN ];
+
+ snprintf( buf, sizeof( buf ),
+ "meta_back_bind: no target "
+ "for dn \"%s\" (%d%s%s).",
+ op->o_req_dn.bv_val, rs->sr_err,
+ rs->sr_text ? ". " : "",
+ rs->sr_text ? rs->sr_text : "" );
+ Debug( LDAP_DEBUG_ANY,
+ "%s %s\n",
+ op->o_log_prefix, buf, 0 );
+ }
/* FIXME: there might be cases where we don't want
* to map the error onto invalidCredentials */
@@ -110,13 +129,11 @@ meta_back_bind( Operation *op, SlapReply *rs )
for ( i = 0; i < mi->mi_ntargets; i++ ) {
metatarget_t *mt = mi->mi_targets[ i ];
int lerr;
- Operation op2 = *op;
- int massage = 1;
/*
* Skip non-candidates
*/
- if ( candidates[ i ].sr_tag != META_CANDIDATE ) {
+ if ( !META_IS_CANDIDATE( &candidates[ i ] ) ) {
continue;
}
@@ -138,7 +155,8 @@ meta_back_bind( Operation *op, SlapReply *rs )
}
if ( isroot ) {
- if ( BER_BVISNULL( &mt->mt_pseudorootdn ) )
+ if ( mt->mt_idassert_authmethod == LDAP_AUTH_NONE
+ || BER_BVISNULL( &mt->mt_idassert_authcDN ) )
{
metasingleconn_t *msc = &mc->mc_conns[ i ];
@@ -161,15 +179,13 @@ meta_back_bind( Operation *op, SlapReply *rs )
continue;
}
- op2.o_req_dn = mt->mt_pseudorootdn;
- op2.o_req_ndn = mt->mt_pseudorootdn;
- op2.orb_cred = mt->mt_pseudorootpw;
- op2.orb_method = LDAP_AUTH_SIMPLE;
+
+ (void)meta_back_proxy_authz_bind( mc, i, op, rs, LDAP_BACK_DONTSEND );
+ lerr = rs->sr_err;
- massage = 0;
+ } else {
+ lerr = meta_back_single_bind( op, rs, mc, i );
}
-
- lerr = meta_back_single_bind( &op2, rs, mc, i, massage );
if ( lerr != LDAP_SUCCESS ) {
rc = rs->sr_err = lerr;
@@ -177,7 +193,7 @@ meta_back_bind( Operation *op, SlapReply *rs )
* do not assume it's not candidate; rather
* mark this as an error to be eventually
* reported to client */
- candidates[ i ].sr_tag = META_NOT_CANDIDATE;
+ META_CANDIDATE_CLEAR( &candidates[ i ] );
break;
}
}
@@ -215,7 +231,7 @@ retry_lock:;
"=>meta_back_bind: destroying conn %ld (refcnt=%u)\n",
LDAP_BACK_PCONN_ID( mc->mc_conn ), mc->mc_refcnt, 0 );
- if ( mc->mc_refcnt != 0 ) {
+ if ( tmpmc->mc_refcnt != 0 ) {
/* taint it */
LDAP_BACK_CONN_TAINTED_SET( tmpmc );
@@ -231,7 +247,7 @@ retry_lock:;
}
ber_bvreplace( &mc->mc_local_ndn, &op->o_req_ndn );
- if ( be_isroot_dn( op->o_bd, &op->o_req_ndn ) ) {
+ if ( isroot ) {
mc->mc_conn = LDAP_BACK_PCONN_SET( op );
}
lerr = avl_insert( &mi->mi_conninfo.lai_tree, (caddr_t)mc,
@@ -280,76 +296,25 @@ retry_lock:;
return LDAP_SUCCESS;
}
-/*
- * meta_back_single_bind
- *
- * attempts to perform a bind with creds
- */
-int
-meta_back_single_bind(
+static int
+meta_back_bind_op_result(
Operation *op,
SlapReply *rs,
metaconn_t *mc,
int candidate,
- int massage )
+ int msgid,
+ ldap_back_send_t sendok )
{
metainfo_t *mi = ( metainfo_t * )op->o_bd->be_private;
metatarget_t *mt = mi->mi_targets[ candidate ];
- struct berval mdn = BER_BVNULL;
metasingleconn_t *msc = &mc->mc_conns[ candidate ];
- int msgid,
- rebinding = 0;
-
-
- if ( !BER_BVISNULL( &msc->msc_bound_ndn ) ) {
- ch_free( msc->msc_bound_ndn.bv_val );
- BER_BVZERO( &msc->msc_bound_ndn );
- }
-
- if ( LDAP_BACK_SAVECRED( mi ) && !BER_BVISNULL( &msc->msc_cred ) ) {
- /* destroy sensitive data */
- memset( msc->msc_cred.bv_val, 0, msc->msc_cred.bv_len );
- ch_free( msc->msc_cred.bv_val );
- BER_BVZERO( &msc->msc_cred );
- }
-
- /*
- * Rewrite the bind dn if needed
- */
- if ( massage ) {
- dncookie dc;
-
- dc.target = mt;
- dc.conn = op->o_conn;
- dc.rs = rs;
- dc.ctx = "bindDN";
-
- if ( ldap_back_dn_massage( &dc, &op->o_req_dn, &mdn ) ) {
- rs->sr_text = "DN rewrite error";
- rs->sr_err = LDAP_OTHER;
- return rs->sr_err;
- }
-
- } else {
- mdn = op->o_req_dn;
- }
+ LDAPMessage *res;
+ struct timeval tv;
+ int rc;
+ int nretries = mt->mt_nretries;
+ char buf[ SLAP_TEXT_BUFLEN ];
- /* FIXME: this fixes the bind problem right now; we need
- * to use the asynchronous version to get the "matched"
- * and more in case of failure ... */
- /* FIXME: should we check if at least some of the op->o_ctrls
- * can/should be passed? */
-rebind:;
- rs->sr_err = ldap_sasl_bind( msc->msc_ld, mdn.bv_val,
- LDAP_SASL_SIMPLE, &op->orb_cred,
- op->o_ctrls, NULL, &msgid );
if ( rs->sr_err == LDAP_SUCCESS ) {
- LDAPMessage *res;
- struct timeval tv;
- int rc;
- int nretries = mt->mt_nretries;
- char buf[ SLAP_TEXT_BUFLEN ];
-
LDAP_BACK_TV_SET( &tv );
/*
@@ -358,12 +323,9 @@ rebind:;
retry:;
switch ( ldap_result( msc->msc_ld, msgid, LDAP_MSG_ALL, &tv, &res ) ) {
case 0:
- snprintf( buf, sizeof( buf ),
- "ldap_result=0 nretries=%d%s",
- nretries, rebinding ? " rebinding" : "" );
Debug( LDAP_DEBUG_ANY,
- "%s meta_back_single_bind[%d]: %s.\n",
- op->o_log_prefix, candidate, buf );
+ "%s meta_back_bind_op_result[%d]: ldap_result=0 nretries=%d.\n",
+ op->o_log_prefix, candidate, nretries );
if ( nretries != META_RETRY_NEVER ) {
ldap_pvt_thread_yield();
@@ -375,49 +337,23 @@ retry:;
}
rs->sr_err = LDAP_BUSY;
- if ( rebinding ) {
- ldap_abandon_ext( msc->msc_ld, msgid, NULL, NULL );
- break;
- }
-
- /* FIXME: some times the request times out
- * while the other party is not willing to
- * send a response any more. Give it a second
- * chance with a freshly bound connection */
- rebinding = 1;
- nretries = mt->mt_nretries;
- /* fallthru */
+ (void)meta_back_cancel( mc, op, rs, msgid, candidate, sendok );
+ break;
case -1:
ldap_get_option( msc->msc_ld, LDAP_OPT_ERROR_NUMBER,
&rs->sr_err );
- if ( rebinding ) {
- ldap_abandon_ext( msc->msc_ld, msgid, NULL, NULL );
- }
-
snprintf( buf, sizeof( buf ),
"err=%d (%s) nretries=%d",
rs->sr_err, ldap_err2string( rs->sr_err ), nretries );
Debug( LDAP_DEBUG_ANY,
- "### %s meta_back_single_bind[%d]: %s.\n",
+ "### %s meta_back_bind_op_result[%d]: %s.\n",
op->o_log_prefix, candidate, buf );
-
- rc = slap_map_api2result( rs );
- if ( rs->sr_err == LDAP_UNAVAILABLE && nretries != META_RETRY_NEVER ) {
- rc = meta_back_retry( op, rs, &mc, candidate, LDAP_BACK_DONTSEND );
- if ( rc ) {
- if ( nretries > 0 ) {
- nretries--;
- }
- ldap_pvt_thread_yield();
- goto rebind;
- }
- goto return_results;
- }
break;
default:
+ /* FIXME: matched? referrals? response controls? */
rc = ldap_parse_result( msc->msc_ld, res, &rs->sr_err,
NULL, NULL, NULL, NULL, 1 );
if ( rc != LDAP_SUCCESS ) {
@@ -427,12 +363,81 @@ retry:;
}
}
+ return rs->sr_err = slap_map_api2result( rs );
+}
+
+/*
+ * meta_back_single_bind
+ *
+ * attempts to perform a bind with creds
+ */
+static int
+meta_back_single_bind(
+ Operation *op,
+ SlapReply *rs,
+ metaconn_t *mc,
+ int candidate )
+{
+ metainfo_t *mi = ( metainfo_t * )op->o_bd->be_private;
+ metatarget_t *mt = mi->mi_targets[ candidate ];
+ struct berval mdn = BER_BVNULL;
+ metasingleconn_t *msc = &mc->mc_conns[ candidate ];
+ int msgid;
+ dncookie dc;
+
+ if ( !BER_BVISNULL( &msc->msc_bound_ndn ) ) {
+ ch_free( msc->msc_bound_ndn.bv_val );
+ BER_BVZERO( &msc->msc_bound_ndn );
+ }
+
+ if ( LDAP_BACK_SAVECRED( mi ) && !BER_BVISNULL( &msc->msc_cred ) ) {
+ /* destroy sensitive data */
+ memset( msc->msc_cred.bv_val, 0, msc->msc_cred.bv_len );
+ ch_free( msc->msc_cred.bv_val );
+ BER_BVZERO( &msc->msc_cred );
+ }
+
+ /*
+ * Rewrite the bind dn if needed
+ */
+ dc.target = mt;
+ dc.conn = op->o_conn;
+ dc.rs = rs;
+ dc.ctx = "bindDN";
+
+ if ( ldap_back_dn_massage( &dc, &op->o_req_dn, &mdn ) ) {
+ rs->sr_text = "DN rewrite error";
+ rs->sr_err = LDAP_OTHER;
+ return rs->sr_err;
+ }
+
+ /* FIXME: this fixes the bind problem right now; we need
+ * to use the asynchronous version to get the "matched"
+ * and more in case of failure ... */
+ /* FIXME: should we check if at least some of the op->o_ctrls
+ * can/should be passed? */
+ rs->sr_err = ldap_sasl_bind( msc->msc_ld, mdn.bv_val,
+ LDAP_SASL_SIMPLE, &op->orb_cred,
+ op->o_ctrls, NULL, &msgid );
+ meta_back_bind_op_result( op, rs, mc, candidate, msgid, LDAP_BACK_DONTSEND );
if ( rs->sr_err != LDAP_SUCCESS ) {
- rs->sr_err = slap_map_api2result( rs );
goto return_results;
}
- ber_bvreplace( &msc->msc_bound_ndn, &op->o_req_dn );
+ /* If defined, proxyAuthz will be used also when
+ * back-ldap is the authorizing backend; for this
+ * purpose, a successful bind is followed by a
+ * bind with the configured identity assertion */
+ /* NOTE: use with care */
+ if ( mt->mt_idassert_flags & LDAP_BACK_AUTH_OVERRIDE ) {
+ meta_back_proxy_authz_bind( mc, candidate, op, rs, LDAP_BACK_SENDERR );
+ if ( !LDAP_BACK_CONN_ISBOUND( msc ) ) {
+ goto return_results;
+ }
+ goto cache_refresh;
+ }
+
+ ber_bvreplace( &msc->msc_bound_ndn, &op->o_req_ndn );
LDAP_BACK_CONN_ISBOUND_SET( msc );
mc->mc_authz_target = candidate;
@@ -441,8 +446,9 @@ retry:;
ldap_set_rebind_proc( msc->msc_ld, mt->mt_rebind_f, msc );
}
+cache_refresh:;
if ( mi->mi_cache.ttl != META_DNCACHE_DISABLED
- && op->o_req_ndn.bv_len != 0 )
+ && !BER_BVISEMPTY( &op->o_req_ndn ) )
{
( void )meta_dncache_update_entry( &mi->mi_cache,
&op->o_req_ndn, candidate );
@@ -453,6 +459,10 @@ return_results:;
free( mdn.bv_val );
}
+ if ( META_BACK_TGT_QUARANTINE( mt ) ) {
+ meta_back_quarantine( op, rs, candidate );
+ }
+
return rs->sr_err;
}
@@ -475,164 +485,27 @@ meta_back_single_dobind(
metasingleconn_t *msc = &mc->mc_conns[ candidate ];
int rc;
static struct berval cred = BER_BVC( "" );
- int msgid,
- rebinding = 0,
- save_nretries = nretries;
+ int msgid;
assert( !LDAP_BACK_CONN_ISBOUND( msc ) );
- /*
- * meta_back_single_dobind() calls meta_back_single_bind()
- * if required.
- */
- if ( be_isroot( op ) && !BER_BVISNULL( &mt->mt_pseudorootdn ) )
+ /* NOTE: this obsoletes pseudorootdn */
+ if ( op->o_conn != NULL &&
+ !op->o_do_not_cache &&
+ ( BER_BVISNULL( &msc->msc_bound_ndn ) ||
+ BER_BVISEMPTY( &msc->msc_bound_ndn ) ||
+ ( mt->mt_idassert_flags & LDAP_BACK_AUTH_OVERRIDE ) ) )
{
- Operation op2 = *op;
-
- op2.o_tag = LDAP_REQ_BIND;
- op2.o_req_dn = mt->mt_pseudorootdn;
- op2.o_req_ndn = mt->mt_pseudorootdn;
- op2.orb_cred = mt->mt_pseudorootpw;
- op2.orb_method = LDAP_AUTH_SIMPLE;
-
- rc = meta_back_single_bind( &op2, rs, *mcp, candidate, 0 );
+ (void)meta_back_proxy_authz_bind( mc, candidate, op, rs, sendok );
+ rc = rs->sr_err;
goto done;
}
- /*
- * Otherwise an anonymous bind is performed
- * (note: if the target was already bound, the anonymous
- * bind clears the previous bind).
- */
- if ( !BER_BVISNULL( &msc->msc_bound_ndn ) ) {
- ber_memfree( msc->msc_bound_ndn.bv_val );
- BER_BVZERO( &msc->msc_bound_ndn );
- }
-
- if ( LDAP_BACK_SAVECRED( mi ) && !BER_BVISNULL( &msc->msc_cred ) ) {
- /* destroy sensitive data */
- memset( msc->msc_cred.bv_val, 0, msc->msc_cred.bv_len );
- ber_memfree( msc->msc_cred.bv_val );
- BER_BVZERO( &msc->msc_cred );
- }
-
/* FIXME: should we check if at least some of the op->o_ctrls
* can/should be passed? */
-rebind:;
- rc = ldap_sasl_bind( msc->msc_ld, "", LDAP_SASL_SIMPLE, &cred,
+ rs->sr_err = ldap_sasl_bind( msc->msc_ld, "", LDAP_SASL_SIMPLE, &cred,
NULL, NULL, &msgid );
- if ( rc == LDAP_SUCCESS ) {
- LDAPMessage *res;
- struct timeval tv;
- char buf[ SLAP_TEXT_BUFLEN ];
-
- LDAP_BACK_TV_SET( &tv );
-
- /*
- * handle response!!!
- */
-retry:;
- switch ( ldap_result( msc->msc_ld, msgid, LDAP_MSG_ALL, &tv, &res ) ) {
- case 0:
- snprintf( buf, sizeof( buf ),
- "ldap_result=0 nretries=%d%s",
- nretries, rebinding ? " rebinding" : "" );
- Debug( LDAP_DEBUG_ANY,
- "%s meta_back_single_dobind[%d]: %s.\n",
- op->o_log_prefix, candidate, buf );
-
- if ( nretries != META_RETRY_NEVER ) {
- ldap_pvt_thread_yield();
- if ( nretries > 0 ) {
- nretries--;
- }
- tv = mt->mt_bind_timeout;
- goto retry;
- }
-
- rc = LDAP_BUSY;
- if ( rebinding ) {
- ldap_abandon_ext( msc->msc_ld, msgid, NULL, NULL );
- break;
- }
-
- /* FIXME: some times the request times out
- * while the other party is not willing to
- * send a response any more. Give it a second
- * chance with a freshly bound connection */
- rebinding = 1;
- nretries = save_nretries;
- /* fallthru */
-
- case -1:
- ldap_get_option( msc->msc_ld, LDAP_OPT_ERROR_NUMBER,
- &rs->sr_err );
-
- if ( rebinding ) {
- ldap_abandon_ext( msc->msc_ld, msgid, NULL, NULL );
- }
-
- snprintf( buf, sizeof( buf ),
- "err=%d (%s) nretries=%d",
- rs->sr_err, ldap_err2string( rs->sr_err ), nretries );
- Debug( LDAP_DEBUG_ANY,
- "### %s meta_back_single_dobind[%d]: %s.\n",
- op->o_log_prefix, candidate, buf );
-
- rc = slap_map_api2result( rs );
- if ( rc == LDAP_UNAVAILABLE && nretries != META_RETRY_NEVER ) {
- if ( dolock ) {
- ldap_pvt_thread_mutex_lock( &mi->mi_conninfo.lai_mutex );
- }
-
- if ( mc->mc_refcnt == 1 ) {
- meta_clear_one_candidate( msc );
- LDAP_BACK_CONN_ISBOUND_CLEAR( msc );
-
- ( void )rewrite_session_delete( mt->mt_rwmap.rwm_rw, op->o_conn );
-
- /* mc here must be the regular mc,
- * reset and ready for init */
- rc = meta_back_init_one_conn( op, rs,
- mt, mc, candidate,
- LDAP_BACK_CONN_ISPRIV( mc ),
- LDAP_BACK_DONTSEND );
- if ( rc == LDAP_SUCCESS ) {
- LDAP_BACK_CONN_BINDING_SET( msc );
- }
-
- } else {
- /* can't do anything about it */
- rc = LDAP_UNAVAILABLE;
- }
-
- if ( dolock ) {
- ldap_pvt_thread_mutex_unlock( &mi->mi_conninfo.lai_mutex );
- }
-
- if ( rc == LDAP_SUCCESS ) {
- ldap_pvt_thread_yield();
- if ( nretries > 0 ) {
- nretries--;
- }
- goto rebind;
- }
- }
- break;
-
- default:
- rc = ldap_parse_result( msc->msc_ld, res, &rs->sr_err,
- NULL, NULL, NULL, NULL, 1 );
- if ( rc == LDAP_SUCCESS ) {
- rc = slap_map_api2result( rs );
- }
- break;
- }
-
- } else {
- rs->sr_err = rc;
- rc = slap_map_api2result( rs );
- }
+ rc = meta_back_bind_op_result( op, rs, mc, candidate, msgid, sendok );
done:;
rs->sr_err = rc;
@@ -643,7 +516,7 @@ done:;
LDAP_BACK_CONN_BINDING_CLEAR( msc );
if ( META_BACK_ONERR_STOP( mi ) ) {
LDAP_BACK_CONN_TAINTED_SET( mc );
- meta_back_release_conn_lock( op, mc, dolock );
+ meta_back_release_conn_lock( op, mc, 0 );
*mcp = NULL;
}
if ( dolock ) {
@@ -655,6 +528,10 @@ done:;
}
}
+ if ( META_BACK_TGT_QUARANTINE( mt ) ) {
+ meta_back_quarantine( op, rs, candidate );
+ }
+
return rc;
}
@@ -697,12 +574,12 @@ meta_back_dobind(
for ( i = 0; i < mi->mi_ntargets; i++ ) {
metatarget_t *mt = mi->mi_targets[ i ];
metasingleconn_t *msc = &mc->mc_conns[ i ];
- int rc, do_retry = 1;
+ int rc;
/*
* Not a candidate
*/
- if ( candidates[ i ].sr_tag != META_CANDIDATE ) {
+ if ( !META_IS_CANDIDATE( &candidates[ i ] ) ) {
continue;
}
@@ -714,7 +591,10 @@ meta_back_dobind(
retry_binding:;
ldap_pvt_thread_mutex_lock( &mi->mi_conninfo.lai_mutex );
- if ( LDAP_BACK_CONN_ISBOUND( msc ) || LDAP_BACK_CONN_ISANON( msc ) ) {
+ if ( LDAP_BACK_CONN_ISBOUND( msc )
+ || ( LDAP_BACK_CONN_ISANON( msc )
+ && mt->mt_idassert_authmethod == LDAP_AUTH_NONE ) )
+ {
ldap_pvt_thread_mutex_unlock( &mi->mi_conninfo.lai_mutex );
++bound;
continue;
@@ -724,12 +604,11 @@ retry_binding:;
ldap_pvt_thread_yield();
goto retry_binding;
- } else {
- LDAP_BACK_CONN_BINDING_SET( msc );
- ldap_pvt_thread_mutex_unlock( &mi->mi_conninfo.lai_mutex );
- }
+ }
+
+ LDAP_BACK_CONN_BINDING_SET( msc );
+ ldap_pvt_thread_mutex_unlock( &mi->mi_conninfo.lai_mutex );
-retry:;
rc = meta_back_single_dobind( op, rs, &mc, i,
LDAP_BACK_DONTSEND, mt->mt_nretries, 1 );
/*
@@ -746,10 +625,11 @@ retry:;
}
- if ( rc == LDAP_UNAVAILABLE && do_retry ) {
- do_retry = 0;
+ if ( rc == LDAP_UNAVAILABLE ) {
+ /* FIXME: meta_back_retry() already calls
+ * meta_back_single_dobind() */
if ( meta_back_retry( op, rs, &mc, i, sendok ) ) {
- goto retry;
+ goto retry_ok;
}
if ( mc != NULL ) {
@@ -789,7 +669,8 @@ retry:;
continue;
} /* else */
-
+
+retry_ok:;
Debug( LDAP_DEBUG_TRACE,
"%s meta_back_dobind[%d]: "
"(%s)\n",
@@ -887,70 +768,175 @@ meta_back_default_urllist(
return LDAP_SUCCESS;
}
+int
+meta_back_cancel(
+ metaconn_t *mc,
+ Operation *op,
+ SlapReply *rs,
+ ber_int_t msgid,
+ int candidate,
+ ldap_back_send_t sendok )
+{
+ metainfo_t *mi = (metainfo_t *)op->o_bd->be_private;
+
+ metatarget_t *mt = mi->mi_targets[ candidate ];
+ metasingleconn_t *msc = &mc->mc_conns[ candidate ];
+
+ /* default behavior */
+ if ( META_BACK_TGT_ABANDON( mt ) ) {
+ return ldap_abandon_ext( msc->msc_ld, msgid, NULL, NULL );
+ }
+
+ if ( META_BACK_TGT_IGNORE( mt ) ) {
+ return LDAP_SUCCESS;
+ }
+
+ if ( META_BACK_TGT_CANCEL( mt ) ) {
+ /* FIXME: asynchronous? */
+ return ldap_cancel_s( msc->msc_ld, msgid, NULL, NULL );
+ }
+
+ assert( 0 );
+
+ return LDAP_OTHER;
+}
+
+
+
/*
* FIXME: error return must be handled in a cleaner way ...
*/
int
meta_back_op_result(
- metaconn_t *mc,
- Operation *op,
- SlapReply *rs,
- int candidate )
+ metaconn_t *mc,
+ Operation *op,
+ SlapReply *rs,
+ int candidate,
+ ber_int_t msgid,
+ time_t timeout,
+ ldap_back_send_t sendok )
{
- metainfo_t *mi = ( metainfo_t * )op->o_bd->be_private;
+ metainfo_t *mi = ( metainfo_t * )op->o_bd->be_private;
- int i,
- rerr = LDAP_SUCCESS;
- char *rmsg = NULL,
- *rmatch = NULL;
- const char *save_rmsg = NULL,
- *save_rmatch = NULL;
- void *rmatch_ctx = NULL;
+ const char *save_text = rs->sr_text,
+ *save_matched = rs->sr_matched;
+ BerVarray save_ref = rs->sr_ref;
+ LDAPControl **save_ctrls = rs->sr_ctrls;
+ void *matched_ctx = NULL;
+
+ char *matched = NULL;
+ char *text = NULL;
+ char **refs = NULL;
+ LDAPControl **ctrls = NULL;
assert( mc != NULL );
+ rs->sr_text = NULL;
+ rs->sr_matched = NULL;
+ rs->sr_ref = NULL;
+ rs->sr_ctrls = NULL;
+
if ( candidate != META_TARGET_NONE ) {
+ metatarget_t *mt = mi->mi_targets[ candidate ];
metasingleconn_t *msc = &mc->mc_conns[ candidate ];
- rs->sr_err = LDAP_SUCCESS;
+#define ERR_OK(err) ((err) == LDAP_SUCCESS || (err) == LDAP_COMPARE_FALSE || (err) == LDAP_COMPARE_TRUE)
- ldap_get_option( msc->msc_ld, LDAP_OPT_ERROR_NUMBER, &rs->sr_err );
- if ( rs->sr_err != LDAP_SUCCESS ) {
- /*
- * better check the type of error. In some cases
- * (search ?) it might be better to return a
- * success if at least one of the targets gave
- * positive result ...
- */
- ldap_get_option( msc->msc_ld,
- LDAP_OPT_ERROR_STRING, &rmsg );
- if ( rmsg != NULL && rmsg[ 0 ] == '\0' ) {
- ldap_memfree( rmsg );
- rmsg = NULL;
+ if ( ERR_OK( rs->sr_err ) ) {
+ int rc;
+ struct timeval tv;
+ LDAPMessage *res = NULL;
+
+ if ( timeout ) {
+ tv.tv_sec = timeout;
+ tv.tv_usec = 0;
+
+ } else {
+ LDAP_BACK_TV_SET( &tv );
}
- ldap_get_option( msc->msc_ld,
- LDAP_OPT_MATCHED_DN, &rmatch );
- if ( rmatch != NULL && rmatch[ 0 ] == '\0' ) {
- ldap_memfree( rmatch );
- rmatch = NULL;
+retry:;
+ rc = ldap_result( msc->msc_ld, msgid, LDAP_MSG_ALL, &tv, &res );
+ switch ( rc ) {
+ case 0:
+ if ( timeout ) {
+ (void)meta_back_cancel( mc, op, rs, msgid, candidate, sendok );
+ rs->sr_err = op->o_protocol >= LDAP_VERSION3 ?
+ LDAP_ADMINLIMIT_EXCEEDED : LDAP_OTHER;
+ rs->sr_text = "Operation timed out";
+ break;
+ }
+
+ LDAP_BACK_TV_SET( &tv );
+ ldap_pvt_thread_yield();
+ goto retry;
+
+ case -1:
+ ldap_get_option( msc->msc_ld, LDAP_OPT_ERROR_NUMBER,
+ &rs->sr_err );
+ break;
+
+
+ /* otherwise get the result; if it is not
+ * LDAP_SUCCESS, record it in the reply
+ * structure (this includes
+ * LDAP_COMPARE_{TRUE|FALSE}) */
+ default:
+ rc = ldap_parse_result( msc->msc_ld, res, &rs->sr_err,
+ &matched, &text, &refs, &ctrls, 1 );
+ res = NULL;
+ rs->sr_text = text;
+ if ( rc != LDAP_SUCCESS ) {
+ rs->sr_err = rc;
+ }
+ if ( refs != NULL ) {
+ int i;
+
+ for ( i = 0; refs[ i ] != NULL; i++ )
+ /* count */ ;
+ rs->sr_ref = op->o_tmpalloc( sizeof( struct berval ) * ( i + 1 ),
+ op->o_tmpmemctx );
+ for ( i = 0; refs[ i ] != NULL; i++ ) {
+ ber_str2bv( refs[ i ], 0, 0, &rs->sr_ref[ i ] );
+ }
+ BER_BVZERO( &rs->sr_ref[ i ] );
+ }
+ if ( ctrls != NULL ) {
+ rs->sr_ctrls = ctrls;
+ }
}
- rerr = rs->sr_err = slap_map_api2result( rs );
+ assert( res == NULL );
+ }
+
+ /* if the error in the reply structure is not
+ * LDAP_SUCCESS, try to map it from client
+ * to server error */
+ if ( !ERR_OK( rs->sr_err ) ) {
+ rs->sr_err = slap_map_api2result( rs );
+
+ /* internal ops ( op->o_conn == NULL )
+ * must not reply to client */
+ if ( op->o_conn && !op->o_do_not_cache && matched ) {
+
+ /* record the (massaged) matched
+ * DN into the reply structure */
+ rs->sr_matched = matched;
+ }
+ }
- Debug(LDAP_DEBUG_ANY,
- "==> meta_back_op_result: target"
- " <%d> sending msg \"%s\""
- " (matched \"%s\")\n",
- candidate, ( rmsg ? rmsg : "" ),
- ( rmatch ? rmatch : "" ) );
+ if ( META_BACK_TGT_QUARANTINE( mt ) ) {
+ meta_back_quarantine( op, rs, candidate );
}
} else {
+ int i,
+ err = rs->sr_err;
+
for ( i = 0; i < mi->mi_ntargets; i++ ) {
metasingleconn_t *msc = &mc->mc_conns[ i ];
- char *msg = NULL;
- char *match = NULL;
+ char *xtext = NULL;
+ char *xmatched = NULL;
rs->sr_err = LDAP_SUCCESS;
@@ -963,89 +949,415 @@ meta_back_op_result(
* positive result ...
*/
ldap_get_option( msc->msc_ld,
- LDAP_OPT_ERROR_STRING, &msg );
- if ( msg != NULL && msg[ 0 ] == '\0' ) {
- ldap_memfree( msg );
- msg = NULL;
+ LDAP_OPT_ERROR_STRING, &xtext );
+ if ( xtext != NULL && xtext [ 0 ] == '\0' ) {
+ ldap_memfree( xtext );
+ xtext = NULL;
}
ldap_get_option( msc->msc_ld,
- LDAP_OPT_MATCHED_DN, &match );
- if ( match != NULL && match[ 0 ] == '\0' ) {
- ldap_memfree( match );
- match = NULL;
+ LDAP_OPT_MATCHED_DN, &xmatched );
+ if ( xmatched != NULL && xmatched[ 0 ] == '\0' ) {
+ ldap_memfree( xmatched );
+ xmatched = NULL;
}
rs->sr_err = slap_map_api2result( rs );
- Debug(LDAP_DEBUG_ANY,
- "==> meta_back_op_result: target"
- " <%d> sending msg \"%s\""
- " (matched \"%s\")\n",
- i, ( msg ? msg : "" ),
- ( match ? match : "" ) );
-
+ if ( LogTest( LDAP_DEBUG_ANY ) ) {
+ char buf[ SLAP_TEXT_BUFLEN ];
+
+ snprintf( buf, sizeof( buf ),
+ "meta_back_op_result[%d] "
+ "err=%d text=\"%s\" matched=\"%s\"",
+ i, rs->sr_err,
+ ( xtext ? xtext : "" ),
+ ( xmatched ? xmatched : "" ) );
+ Debug( LDAP_DEBUG_ANY, "%s %s.\n",
+ op->o_log_prefix, buf, 0 );
+ }
+
/*
* FIXME: need to rewrite "match" (need rwinfo)
*/
switch ( rs->sr_err ) {
default:
- rerr = rs->sr_err;
- if ( msg != NULL ) {
- if ( rmsg ) {
- ldap_memfree( rmsg );
+ err = rs->sr_err;
+ if ( xtext != NULL ) {
+ if ( text ) {
+ ldap_memfree( text );
}
- rmsg = msg;
- msg = NULL;
+ text = xtext;
+ xtext = NULL;
}
- if ( match != NULL ) {
- if ( rmatch ) {
- ldap_memfree( rmatch );
+ if ( xmatched != NULL ) {
+ if ( matched ) {
+ ldap_memfree( matched );
}
- rmatch = match;
- match = NULL;
+ matched = xmatched;
+ xmatched = NULL;
}
break;
}
- if ( msg ) {
- ldap_memfree( msg );
+ if ( xtext ) {
+ ldap_memfree( xtext );
}
- if ( match ) {
- ldap_memfree( match );
+ if ( xmatched ) {
+ ldap_memfree( xmatched );
}
}
+
+ if ( META_BACK_TGT_QUARANTINE( mi->mi_targets[ i ] ) ) {
+ meta_back_quarantine( op, rs, i );
+ }
+ }
+
+ if ( err != LDAP_SUCCESS ) {
+ rs->sr_err = err;
}
}
-
- rs->sr_err = rerr;
- if ( rmsg != NULL ) {
- save_rmsg = rs->sr_text;
- rs->sr_text = rmsg;
- }
- if ( rmatch != NULL ) {
+
+ if ( matched != NULL ) {
struct berval dn, pdn;
- ber_str2bv( rmatch, 0, 0, &dn );
+ ber_str2bv( matched, 0, 0, &dn );
if ( dnPretty( NULL, &dn, &pdn, op->o_tmpmemctx ) == LDAP_SUCCESS ) {
- ldap_memfree( rmatch );
- rmatch_ctx = op->o_tmpmemctx;
- rmatch = pdn.bv_val;
+ ldap_memfree( matched );
+ matched_ctx = op->o_tmpmemctx;
+ matched = pdn.bv_val;
+ }
+ rs->sr_matched = matched;
+ }
+
+ if ( op->o_conn &&
+ ( ( sendok & LDAP_BACK_SENDOK )
+ || ( ( sendok & LDAP_BACK_SENDERR ) && rs->sr_err != LDAP_SUCCESS ) ) )
+ {
+ send_ldap_result( op, rs );
+ }
+ if ( matched ) {
+ op->o_tmpfree( (char *)rs->sr_matched, matched_ctx );
+ }
+ if ( text ) {
+ ldap_memfree( text );
+ }
+ if ( rs->sr_ref ) {
+ assert( refs != NULL );
+ ber_memvfree( (void **)refs );
+ op->o_tmpfree( rs->sr_ref, op->o_tmpmemctx );
+ }
+ if ( ctrls ) {
+ assert( rs->sr_ctrls != NULL );
+ ldap_controls_free( ctrls );
+ }
+
+ rs->sr_text = save_text;
+ rs->sr_matched = save_matched;
+ rs->sr_ref = save_ref;
+ rs->sr_ctrls = save_ctrls;
+
+ return( ERR_OK( rs->sr_err ) ? LDAP_SUCCESS : rs->sr_err );
+}
+
+/*
+ * meta_back_proxy_authz_cred()
+ *
+ * prepares credentials & method for meta_back_proxy_authz_bind();
+ * or, if method is SASL, performs the SASL bind directly.
+ */
+int
+meta_back_proxy_authz_cred(
+ metaconn_t *mc,
+ int candidate,
+ Operation *op,
+ SlapReply *rs,
+ ldap_back_send_t sendok,
+ struct berval *binddn,
+ struct berval *bindcred,
+ int *method )
+{
+ metainfo_t *mi = (metainfo_t *)op->o_bd->be_private;
+ metatarget_t *mt = mi->mi_targets[ candidate ];
+ metasingleconn_t *msc = &mc->mc_conns[ candidate ];
+ struct berval ndn;
+ int dobind = 0;
+
+ /* don't proxyAuthz if protocol is not LDAPv3 */
+ switch ( mt->mt_version ) {
+ case LDAP_VERSION3:
+ break;
+
+ case 0:
+ if ( op->o_protocol == 0 || op->o_protocol == LDAP_VERSION3 ) {
+ break;
+ }
+ /* fall thru */
+
+ default:
+ rs->sr_err = LDAP_UNWILLING_TO_PERFORM;
+ if ( sendok & LDAP_BACK_SENDERR ) {
+ send_ldap_result( op, rs );
+ }
+ LDAP_BACK_CONN_ISBOUND_CLEAR( msc );
+ goto done;
+ }
+
+ if ( op->o_tag == LDAP_REQ_BIND ) {
+ ndn = op->o_req_ndn;
+
+ } else if ( !BER_BVISNULL( &op->o_conn->c_ndn ) ) {
+ ndn = op->o_conn->c_ndn;
+
+ } else {
+ ndn = op->o_ndn;
+ }
+
+ /*
+ * FIXME: we need to let clients use proxyAuthz
+ * otherwise we cannot do symmetric pools of servers;
+ * we have to live with the fact that a user can
+ * authorize itself as any ID that is allowed
+ * by the authzTo directive of the "proxyauthzdn".
+ */
+ /*
+ * NOTE: current Proxy Authorization specification
+ * and implementation do not allow proxy authorization
+ * control to be provided with Bind requests
+ */
+ /*
+ * if no bind took place yet, but the connection is bound
+ * and the "proxyauthzdn" is set, then bind as
+ * "proxyauthzdn" and explicitly add the proxyAuthz
+ * control to every operation with the dn bound
+ * to the connection as control value.
+ */
+
+ /* bind as proxyauthzdn only if no idassert mode
+ * is requested, or if the client's identity
+ * is authorized */
+ switch ( mt->mt_idassert_mode ) {
+ case LDAP_BACK_IDASSERT_LEGACY:
+ if ( !BER_BVISNULL( &ndn ) && !BER_BVISEMPTY( &ndn ) ) {
+ if ( !BER_BVISNULL( &mt->mt_idassert_authcDN ) && !BER_BVISEMPTY( &mt->mt_idassert_authcDN ) )
+ {
+ *binddn = mt->mt_idassert_authcDN;
+ *bindcred = mt->mt_idassert_passwd;
+ dobind = 1;
+ }
+ }
+ break;
+
+ default:
+ /* NOTE: rootdn can always idassert */
+ if ( BER_BVISNULL( &ndn ) && mt->mt_idassert_authz == NULL ) {
+ if ( mt->mt_idassert_flags & LDAP_BACK_AUTH_PRESCRIPTIVE ) {
+ rs->sr_err = LDAP_INAPPROPRIATE_AUTH;
+ if ( sendok & LDAP_BACK_SENDERR ) {
+ send_ldap_result( op, rs );
+ }
+ LDAP_BACK_CONN_ISBOUND_CLEAR( msc );
+
+ } else {
+ rs->sr_err = LDAP_SUCCESS;
+ *binddn = slap_empty_bv;
+ *bindcred = slap_empty_bv;
+ break;
+ }
+
+ goto done;
+
+ } else if ( mt->mt_idassert_authz && !be_isroot( op ) ) {
+ struct berval authcDN;
+
+ if ( BER_BVISNULL( &ndn ) ) {
+ authcDN = slap_empty_bv;
+
+ } else {
+ authcDN = ndn;
+ }
+ rs->sr_err = slap_sasl_matches( op, mt->mt_idassert_authz,
+ &authcDN, &authcDN );
+ if ( rs->sr_err != LDAP_SUCCESS ) {
+ if ( mt->mt_idassert_flags & LDAP_BACK_AUTH_PRESCRIPTIVE ) {
+ if ( sendok & LDAP_BACK_SENDERR ) {
+ send_ldap_result( op, rs );
+ }
+ LDAP_BACK_CONN_ISBOUND_CLEAR( msc );
+
+ } else {
+ rs->sr_err = LDAP_SUCCESS;
+ *binddn = slap_empty_bv;
+ *bindcred = slap_empty_bv;
+ break;
+ }
+
+ goto done;
+ }
}
- save_rmatch = rs->sr_matched;
- rs->sr_matched = rmatch;
+
+ *binddn = mt->mt_idassert_authcDN;
+ *bindcred = mt->mt_idassert_passwd;
+ dobind = 1;
+ break;
}
- send_ldap_result( op, rs );
- if ( rmsg != NULL ) {
- ber_memfree( rmsg );
- rs->sr_text = save_rmsg;
+
+ if ( dobind && mt->mt_idassert_authmethod == LDAP_AUTH_SASL ) {
+#ifdef HAVE_CYRUS_SASL
+ void *defaults = NULL;
+ struct berval authzID = BER_BVNULL;
+ int freeauthz = 0;
+
+ /* if SASL supports native authz, prepare for it */
+ if ( ( !op->o_do_not_cache || !op->o_is_auth_check ) &&
+ ( mt->mt_idassert_flags & LDAP_BACK_AUTH_NATIVE_AUTHZ ) )
+ {
+ switch ( mt->mt_idassert_mode ) {
+ case LDAP_BACK_IDASSERT_OTHERID:
+ case LDAP_BACK_IDASSERT_OTHERDN:
+ authzID = mt->mt_idassert_authzID;
+ break;
+
+ case LDAP_BACK_IDASSERT_ANONYMOUS:
+ BER_BVSTR( &authzID, "dn:" );
+ break;
+
+ case LDAP_BACK_IDASSERT_SELF:
+ if ( BER_BVISNULL( &ndn ) ) {
+ /* connection is not authc'd, so don't idassert */
+ BER_BVSTR( &authzID, "dn:" );
+ break;
+ }
+ authzID.bv_len = STRLENOF( "dn:" ) + ndn.bv_len;
+ authzID.bv_val = slap_sl_malloc( authzID.bv_len + 1, op->o_tmpmemctx );
+ AC_MEMCPY( authzID.bv_val, "dn:", STRLENOF( "dn:" ) );
+ AC_MEMCPY( authzID.bv_val + STRLENOF( "dn:" ),
+ ndn.bv_val, ndn.bv_len + 1 );
+ freeauthz = 1;
+ break;
+
+ default:
+ break;
+ }
+ }
+
+ if ( mt->mt_idassert_secprops != NULL ) {
+ rs->sr_err = ldap_set_option( msc->msc_ld,
+ LDAP_OPT_X_SASL_SECPROPS,
+ (void *)mt->mt_idassert_secprops );
+
+ if ( rs->sr_err != LDAP_OPT_SUCCESS ) {
+ rs->sr_err = LDAP_OTHER;
+ if ( sendok & LDAP_BACK_SENDERR ) {
+ send_ldap_result( op, rs );
+ }
+ LDAP_BACK_CONN_ISBOUND_CLEAR( msc );
+ goto done;
+ }
+ }
+
+ defaults = lutil_sasl_defaults( msc->msc_ld,
+ mt->mt_idassert_sasl_mech.bv_val,
+ mt->mt_idassert_sasl_realm.bv_val,
+ mt->mt_idassert_authcID.bv_val,
+ mt->mt_idassert_passwd.bv_val,
+ authzID.bv_val );
+
+ rs->sr_err = ldap_sasl_interactive_bind_s( msc->msc_ld, binddn->bv_val,
+ mt->mt_idassert_sasl_mech.bv_val, NULL, NULL,
+ LDAP_SASL_QUIET, lutil_sasl_interact,
+ defaults );
+
+ rs->sr_err = slap_map_api2result( rs );
+ if ( rs->sr_err != LDAP_SUCCESS ) {
+ LDAP_BACK_CONN_ISBOUND_CLEAR( msc );
+ if ( sendok & LDAP_BACK_SENDERR ) {
+ send_ldap_result( op, rs );
+ }
+
+ } else {
+ LDAP_BACK_CONN_ISBOUND_SET( msc );
+ }
+
+ lutil_sasl_freedefs( defaults );
+ if ( freeauthz ) {
+ slap_sl_free( authzID.bv_val, op->o_tmpmemctx );
+ }
+
+ goto done;
+#endif /* HAVE_CYRUS_SASL */
}
- if ( rmatch != NULL ) {
- ber_memfree_x( rmatch, rmatch_ctx );
- rs->sr_matched = save_rmatch;
+
+ *method = mt->mt_idassert_authmethod;
+ switch ( mt->mt_idassert_authmethod ) {
+ case LDAP_AUTH_NONE:
+ BER_BVSTR( binddn, "" );
+ BER_BVSTR( bindcred, "" );
+ /* fallthru */
+
+ case LDAP_AUTH_SIMPLE:
+ break;
+
+ default:
+ /* unsupported! */
+ LDAP_BACK_CONN_ISBOUND_CLEAR( msc );
+ rs->sr_err = LDAP_AUTH_METHOD_NOT_SUPPORTED;
+ if ( sendok & LDAP_BACK_SENDERR ) {
+ send_ldap_result( op, rs );
+ }
+ break;
}
- return ( ( rerr == LDAP_SUCCESS ) ? 0 : -1 );
+done:;
+ return rs->sr_err;
}
+static int
+meta_back_proxy_authz_bind( metaconn_t *mc, int candidate, Operation *op, SlapReply *rs, ldap_back_send_t sendok )
+{
+ metainfo_t *mi = (metainfo_t *)op->o_bd->be_private;
+ metatarget_t *mt = mi->mi_targets[ candidate ];
+ metasingleconn_t *msc = &mc->mc_conns[ candidate ];
+ struct berval binddn = BER_BVC( "" ),
+ cred = BER_BVC( "" );
+ int method = LDAP_AUTH_NONE,
+ rc;
+
+ rc = meta_back_proxy_authz_cred( mc, candidate, op, rs, sendok, &binddn, &cred, &method );
+ if ( rc == LDAP_SUCCESS && !LDAP_BACK_CONN_ISBOUND( msc ) ) {
+ int msgid;
+
+ switch ( method ) {
+ case LDAP_AUTH_NONE:
+ case LDAP_AUTH_SIMPLE:
+ rs->sr_err = ldap_sasl_bind( msc->msc_ld,
+ binddn.bv_val, LDAP_SASL_SIMPLE,
+ &cred, NULL, NULL, &msgid );
+ rc = meta_back_bind_op_result( op, rs, mc, candidate, msgid, sendok );
+ if ( rc == LDAP_SUCCESS ) {
+ /* set rebind stuff in case of successful proxyAuthz bind,
+ * so that referral chasing is attempted using the right
+ * identity */
+ LDAP_BACK_CONN_ISBOUND_SET( msc );
+ ber_bvreplace( &msc->msc_bound_ndn, &binddn );
+
+ if ( LDAP_BACK_SAVECRED( mi ) ) {
+ if ( !BER_BVISNULL( &msc->msc_cred ) ) {
+ memset( msc->msc_cred.bv_val, 0,
+ msc->msc_cred.bv_len );
+ }
+ ber_bvreplace( &msc->msc_cred, &cred );
+ ldap_set_rebind_proc( msc->msc_ld, mt->mt_rebind_f, msc );
+ }
+ }
+ break;
+
+ default:
+ assert( 0 );
+ break;
+ }
+ }
+
+ return LDAP_BACK_CONN_ISBOUND( msc );
+}
diff --git a/servers/slapd/back-meta/candidates.c b/servers/slapd/back-meta/candidates.c
index 27d3c2eaa16f4a6b0b5f280df29ce98ff92bad6b..64b56cc8ada7baad0059492bb2532136c8388d56 100644
--- a/servers/slapd/back-meta/candidates.c
+++ b/servers/slapd/back-meta/candidates.c
@@ -59,40 +59,38 @@
*/
int
meta_back_is_candidate(
- struct berval *nsuffix,
- int suffixscope,
- BerVarray subtree_exclude,
+ metatarget_t *mt,
struct berval *ndn,
int scope )
{
- if ( dnIsSuffix( ndn, nsuffix ) ) {
- if ( subtree_exclude ) {
+ if ( dnIsSuffix( ndn, &mt->mt_nsuffix ) ) {
+ if ( mt->mt_subtree_exclude ) {
int i;
- for ( i = 0; !BER_BVISNULL( &subtree_exclude[ i ] ); i++ ) {
- if ( dnIsSuffix( ndn, &subtree_exclude[ i ] ) ) {
+ for ( i = 0; !BER_BVISNULL( &mt->mt_subtree_exclude[ i ] ); i++ ) {
+ if ( dnIsSuffix( ndn, &mt->mt_subtree_exclude[ i ] ) ) {
return META_NOT_CANDIDATE;
}
}
}
- switch ( suffixscope ) {
+ switch ( mt->mt_scope ) {
case LDAP_SCOPE_SUBTREE:
default:
return META_CANDIDATE;
case LDAP_SCOPE_SUBORDINATE:
- if ( ndn->bv_len > nsuffix->bv_len ) {
+ if ( ndn->bv_len > mt->mt_nsuffix.bv_len ) {
return META_CANDIDATE;
}
break;
/* nearly useless; not allowed by config */
case LDAP_SCOPE_ONELEVEL:
- if ( ndn->bv_len > nsuffix->bv_len ) {
+ if ( ndn->bv_len > mt->mt_nsuffix.bv_len ) {
struct berval rdn = *ndn;
- rdn.bv_len -= nsuffix->bv_len
+ rdn.bv_len -= mt->mt_nsuffix.bv_len
+ STRLENOF( "," );
if ( dnIsOneLevelRDN( &rdn ) ) {
return META_CANDIDATE;
@@ -102,7 +100,7 @@ meta_back_is_candidate(
/* nearly useless; not allowed by config */
case LDAP_SCOPE_BASE:
- if ( ndn->bv_len == nsuffix->bv_len ) {
+ if ( ndn->bv_len == mt->mt_nsuffix.bv_len ) {
return META_CANDIDATE;
}
break;
@@ -111,7 +109,7 @@ meta_back_is_candidate(
return META_NOT_CANDIDATE;
}
- if ( scope == LDAP_SCOPE_SUBTREE && dnIsSuffix( nsuffix, ndn ) ) {
+ if ( scope == LDAP_SCOPE_SUBTREE && dnIsSuffix( &mt->mt_nsuffix, ndn ) ) {
/*
* suffix longer than dn, but common part matches
*/
@@ -139,11 +137,7 @@ meta_back_select_unique_candidate(
for ( i = 0; i < mi->mi_ntargets; i++ ) {
metatarget_t *mt = mi->mi_targets[ i ];
- if ( meta_back_is_candidate( &mt->mt_nsuffix,
- mt->mt_scope,
- mt->mt_subtree_exclude,
- ndn, LDAP_SCOPE_BASE ) )
- {
+ if ( meta_back_is_candidate( mt, ndn, LDAP_SCOPE_BASE ) ) {
if ( candidate == META_TARGET_NONE ) {
candidate = i;
@@ -174,7 +168,7 @@ meta_clear_unused_candidates(
if ( i == candidate ) {
continue;
}
- candidates[ i ].sr_tag = META_NOT_CANDIDATE;
+ META_CANDIDATE_RESET( &candidates[ i ] );
}
return 0;
@@ -220,9 +214,7 @@ meta_clear_candidates( Operation *op, metaconn_t *mc )
int c;
for ( c = 0; c < mi->mi_ntargets; c++ ) {
- if ( mc->mc_conns[ c ].msc_ld != NULL ) {
- meta_clear_one_candidate( &mc->mc_conns[ c ] );
- }
+ meta_clear_one_candidate( &mc->mc_conns[ c ] );
}
return 0;
diff --git a/servers/slapd/back-meta/compare.c b/servers/slapd/back-meta/compare.c
index cd6815bee7e3e5418fc2d54278f8bed1918f3d60..7b9ab0243034f68a87dff31c36fbf5db2960077a 100644
--- a/servers/slapd/back-meta/compare.c
+++ b/servers/slapd/back-meta/compare.c
@@ -74,8 +74,10 @@ meta_back_compare( Operation *op, SlapReply *rs )
struct berval mdn = BER_BVNULL;
struct berval mapped_attr = op->orc_ava->aa_desc->ad_cname;
struct berval mapped_value = op->orc_ava->aa_value;
+ metatarget_t *mt = mi->mi_targets[ i ];
+ LDAPControl **ctrls = NULL;
- if ( candidates[ i ].sr_tag != META_CANDIDATE ) {
+ if ( ! META_IS_CANDIDATE( &candidates[ i ] ) ) {
msgid[ i ] = -1;
continue;
}
@@ -83,7 +85,7 @@ meta_back_compare( Operation *op, SlapReply *rs )
/*
* Rewrite the compare dn, if needed
*/
- dc.target = mi->mi_targets[ i ];
+ dc.target = mt;
switch ( ldap_back_dn_massage( &dc, &op->o_req_dn, &mdn ) ) {
case LDAP_UNWILLING_TO_PERFORM:
@@ -98,7 +100,7 @@ meta_back_compare( Operation *op, SlapReply *rs )
* if attr is objectClass, try to remap the value
*/
if ( op->orc_ava->aa_desc == slap_schema.si_ad_objectClass ) {
- ldap_back_map( &mi->mi_targets[ i ]->mt_rwmap.rwm_oc,
+ ldap_back_map( &mt->mt_rwmap.rwm_oc,
&op->orc_ava->aa_value,
&mapped_value, BACKLDAP_MAP );
@@ -109,7 +111,7 @@ meta_back_compare( Operation *op, SlapReply *rs )
* else try to remap the attribute
*/
} else {
- ldap_back_map( &mi->mi_targets[ i ]->mt_rwmap.rwm_at,
+ ldap_back_map( &mt->mt_rwmap.rwm_at,
&op->orc_ava->aa_desc->ad_cname,
&mapped_attr, BACKLDAP_MAP );
if ( BER_BVISNULL( &mapped_attr ) || mapped_attr.bv_val[0] == '\0' ) {
@@ -132,6 +134,13 @@ meta_back_compare( Operation *op, SlapReply *rs )
}
}
+ ctrls = op->o_ctrls;
+ if ( ldap_back_proxy_authz_ctrl( &mc->mc_conns[ i ].msc_bound_ndn,
+ mt->mt_version, &mt->mt_idassert, op, rs, &ctrls ) != LDAP_SUCCESS )
+ {
+ continue;
+ }
+
/*
* the compare op is spawned across the targets and the first
* that returns determines the result; a constraint on unicity
@@ -139,7 +148,9 @@ meta_back_compare( Operation *op, SlapReply *rs )
*/
rc = ldap_compare_ext( mc->mc_conns[ i ].msc_ld, mdn.bv_val,
mapped_attr.bv_val, &mapped_value,
- op->o_ctrls, NULL, &msgid[ i ] );
+ ctrls, NULL, &msgid[ i ] );
+
+ (void)ldap_back_proxy_authz_ctrl_free( op, &ctrls );
if ( mdn.bv_val != op->o_req_dn.bv_val ) {
free( mdn.bv_val );
@@ -208,6 +219,7 @@ meta_back_compare( Operation *op, SlapReply *rs )
goto finish;
}
+ /* FIXME: matched? referrals? response controls? */
rc = ldap_parse_result( msc->msc_ld, res,
&rs->sr_err,
NULL, NULL, NULL, NULL, 1 );
diff --git a/servers/slapd/back-meta/config.c b/servers/slapd/back-meta/config.c
index abd351e70d469e49b59faba317379b604f994a91..3fd0b2dbed0dc0688305768ca34339135403c5f8 100644
--- a/servers/slapd/back-meta/config.c
+++ b/servers/slapd/back-meta/config.c
@@ -72,6 +72,13 @@ meta_back_new_target(
ldap_pvt_thread_mutex_init( &mt->mt_uri_mutex );
+ mt->mt_idassert_mode = LDAP_BACK_IDASSERT_LEGACY;
+ mt->mt_idassert_authmethod = LDAP_AUTH_NONE;
+ mt->mt_idassert_tls = SB_TLS_DEFAULT;
+
+ /* by default, use proxyAuthz control on each operation */
+ mt->mt_idassert_flags = LDAP_BACK_AUTH_PRESCRIPTIVE;
+
*mtp = mt;
return 0;
@@ -171,6 +178,10 @@ meta_back_db_config(
mt->mt_urllist_p = mt;
mt->mt_nretries = mi->mi_nretries;
+ mt->mt_quarantine = mi->mi_quarantine;
+ if ( META_BACK_QUARANTINE( mi ) ) {
+ ldap_pvt_thread_mutex_init( &mt->mt_quarantine_mutex );
+ }
mt->mt_flags = mi->mi_flags;
mt->mt_version = mi->mi_version;
mt->mt_network_timeout = mi->mi_network_timeout;
@@ -734,16 +745,16 @@ meta_back_db_config(
switch ( check_true_false( argv[ 1 ] ) ) {
case 0:
- *flagsp &= ~(LDAP_BACK_F_SUPPORT_T_F|LDAP_BACK_F_SUPPORT_T_F_DISCOVER);
+ *flagsp &= ~LDAP_BACK_F_T_F_MASK2;
break;
case 1:
- *flagsp |= LDAP_BACK_F_SUPPORT_T_F;
+ *flagsp |= LDAP_BACK_F_T_F;
break;
default:
if ( strcasecmp( argv[ 1 ], "discover" ) == 0 ) {
- *flagsp |= LDAP_BACK_F_SUPPORT_T_F_DISCOVER;
+ *flagsp |= LDAP_BACK_F_T_F_DISCOVER;
} else {
Debug( LDAP_DEBUG_ANY,
@@ -777,10 +788,12 @@ meta_back_db_config(
}
/* bind-defer? */
- } else if ( strcasecmp( argv[ 0 ], "pseudoroot-bind-defer" ) == 0 ) {
+ } else if ( strcasecmp( argv[ 0 ], "pseudoroot-bind-defer" ) == 0
+ || strcasecmp( argv[ 0 ], "root-bind-defer" ) == 0 )
+ {
if ( argc != 2 ) {
Debug( LDAP_DEBUG_ANY,
- "%s: line %d: \"pseudoroot-bind-defer {FALSE|true}\" takes 1 argument\n",
+ "%s: line %d: \"[pseudo]root-bind-defer {FALSE|true}\" takes 1 argument\n",
fname, lineno, 0 );
return( 1 );
}
@@ -796,7 +809,7 @@ meta_back_db_config(
default:
Debug( LDAP_DEBUG_ANY,
- "%s: line %d: \"pseudoroot-bind-defer {FALSE|true}\": invalid arg \"%s\".\n",
+ "%s: line %d: \"[pseudo]root-bind-defer {FALSE|true}\": invalid arg \"%s\".\n",
fname, lineno, argv[ 1 ] );
return 1;
}
@@ -833,6 +846,41 @@ meta_back_db_config(
return 1;
}
+ } else if ( strcasecmp( argv[ 0 ], "cancel" ) == 0 ) {
+ unsigned flag = 0;
+ unsigned *flagsp = mi->mi_ntargets ?
+ &mi->mi_targets[ mi->mi_ntargets - 1 ]->mt_flags
+ : &mi->mi_flags;
+
+ if ( argc != 2 ) {
+ Debug( LDAP_DEBUG_ANY,
+ "%s: line %d: \"cancel {abandon|ignore|exop}\" takes 1 argument\n",
+ fname, lineno, 0 );
+ return( 1 );
+ }
+
+ if ( strcasecmp( argv[ 1 ], "abandon" ) == 0 ) {
+ flag = LDAP_BACK_F_CANCEL_ABANDON;
+
+ } else if ( strcasecmp( argv[ 1 ], "ignore" ) == 0 ) {
+ flag = LDAP_BACK_F_CANCEL_IGNORE;
+
+ } else if ( strcasecmp( argv[ 1 ], "exop" ) == 0 ) {
+ flag = LDAP_BACK_F_CANCEL_EXOP;
+
+ } else if ( strcasecmp( argv[ 1 ], "exop-discover" ) == 0 ) {
+ flag = LDAP_BACK_F_CANCEL_EXOP_DISCOVER;
+
+ } else {
+ Debug( LDAP_DEBUG_ANY,
+ "%s: line %d: \"cancel {abandon|ignore|exop[-discover]}\": unknown mode \"%s\" \n",
+ fname, lineno, argv[ 1 ] );
+ return( 1 );
+ }
+
+ *flagsp &= ~LDAP_BACK_F_CANCEL_MASK2;
+ *flagsp |= flag;
+
} else if ( strcasecmp( argv[ 0 ], "timeout" ) == 0 ) {
char *sep;
time_t *tv = mi->mi_ntargets ?
@@ -901,7 +949,6 @@ meta_back_db_config(
/* name to use as pseudo-root dn */
} else if ( strcasecmp( argv[ 0 ], "pseudorootdn" ) == 0 ) {
int i = mi->mi_ntargets - 1;
- struct berval dn;
if ( i < 0 ) {
Debug( LDAP_DEBUG_ANY,
@@ -917,15 +964,74 @@ meta_back_db_config(
return 1;
}
- dn.bv_val = argv[ 1 ];
- dn.bv_len = strlen( argv[ 1 ] );
- if ( dnNormalize( 0, NULL, NULL, &dn,
- &mi->mi_targets[ i ]->mt_pseudorootdn, NULL ) != LDAP_SUCCESS )
+ /*
+ * exact replacement:
+ *
+
+idassert-bind bindmethod=simple
+ binddn=<pseudorootdn>
+ credentials=<pseudorootpw>
+ mode=none
+ flags=non-prescriptive
+idassert-authzFrom "dn:<rootdn>"
+
+ * so that only when authc'd as <rootdn> the proxying occurs
+ * rebinding as the <pseudorootdn> without proxyAuthz.
+ */
+
+ Debug( LDAP_DEBUG_ANY,
+ "%s: line %d: \"pseudorootdn\", \"pseudorootpw\" are no longer supported; "
+ "use \"idassert-bind\" and \"idassert-authzFrom\" instead.\n",
+ fname, lineno, 0 );
+
{
- Debug( LDAP_DEBUG_ANY, "%s: line %d: "
- "pseudoroot DN '%s' is invalid\n",
- fname, lineno, argv[ 1 ] );
- return( 1 );
+ char binddn[ SLAP_TEXT_BUFLEN ];
+ char *cargv[] = {
+ "idassert-bind",
+ "bindmethod=simple",
+ NULL,
+ "mode=none",
+ "flags=non-prescriptive",
+ NULL
+ };
+ int cargc = 5;
+ int rc;
+
+ if ( BER_BVISNULL( &be->be_rootndn ) ) {
+ Debug( LDAP_DEBUG_ANY, "%s: line %d: \"pseudorootpw\": \"rootdn\" must be defined first.\n",
+ fname, lineno, 0 );
+ return 1;
+ }
+
+ if ( snprintf( binddn, sizeof( binddn ), "binddn=%s", argv[ 1 ] ) >= sizeof( binddn ) ) {
+ Debug( LDAP_DEBUG_ANY, "%s: line %d: \"pseudorootdn\" too long.\n",
+ fname, lineno, 0 );
+ return 1;
+ }
+ cargv[ 2 ] = binddn;
+
+ rc = slap_idassert_parse_cf( fname, lineno, cargc, cargv, &mi->mi_targets[ mi->mi_ntargets - 1 ]->mt_idassert );
+ if ( rc == 0 ) {
+ struct berval bv;
+
+ if ( mi->mi_targets[ mi->mi_ntargets - 1 ]->mt_idassert_authz != NULL ) {
+ Debug( LDAP_DEBUG_ANY, "%s: line %d: \"idassert-authzFrom\" already defined (discarded).\n",
+ fname, lineno, 0 );
+ ber_bvarray_free( mi->mi_targets[ mi->mi_ntargets - 1 ]->mt_idassert_authz );
+ mi->mi_targets[ mi->mi_ntargets - 1 ]->mt_idassert_authz = NULL;
+ }
+
+ assert( !BER_BVISNULL( &mi->mi_targets[ mi->mi_ntargets - 1 ]->mt_idassert_authcDN ) );
+
+ bv.bv_len = STRLENOF( "dn:" ) + be->be_rootndn.bv_len;
+ bv.bv_val = ber_memalloc( bv.bv_len + 1 );
+ AC_MEMCPY( bv.bv_val, "dn:", STRLENOF( "dn:" ) );
+ AC_MEMCPY( &bv.bv_val[ STRLENOF( "dn:" ) ], be->be_rootndn.bv_val, be->be_rootndn.bv_len + 1 );
+
+ ber_bvarray_add( &mi->mi_targets[ mi->mi_ntargets - 1 ]->mt_idassert_authz, &bv );
+ }
+
+ return rc;
}
/* password to use as pseudo-root */
@@ -945,7 +1051,114 @@ meta_back_db_config(
fname, lineno, 0 );
return 1;
}
- ber_str2bv( argv[ 1 ], 0L, 1, &mi->mi_targets[ i ]->mt_pseudorootpw );
+
+ Debug( LDAP_DEBUG_ANY,
+ "%s: line %d: \"pseudorootdn\", \"pseudorootpw\" are no longer supported; "
+ "use \"idassert-bind\" and \"idassert-authzFrom\" instead.\n",
+ fname, lineno, 0 );
+
+ if ( BER_BVISNULL( &mi->mi_targets[ i ]->mt_idassert_authcDN ) ) {
+ Debug( LDAP_DEBUG_ANY, "%s: line %d: \"pseudorootpw\": \"pseudorootdn\" must be defined first.\n",
+ fname, lineno, 0 );
+ return 1;
+ }
+
+ if ( !BER_BVISNULL( &mi->mi_targets[ i ]->mt_idassert_passwd ) ) {
+ memset( mi->mi_targets[ i ]->mt_idassert_passwd.bv_val, 0,
+ mi->mi_targets[ i ]->mt_idassert_passwd.bv_len );
+ ber_memfree( mi->mi_targets[ i ]->mt_idassert_passwd.bv_val );
+ }
+ ber_str2bv( argv[ 1 ], 0, 1, &mi->mi_targets[ i ]->mt_idassert_passwd );
+
+ /* idassert-bind */
+ } else if ( strcasecmp( argv[ 0 ], "idassert-bind" ) == 0 ) {
+ if ( mi->mi_ntargets == 0 ) {
+ Debug( LDAP_DEBUG_ANY,
+ "%s: line %d: \"idassert-bind\" "
+ "must appear inside a target specification.\n",
+ fname, lineno, 0 );
+ return 1;
+ }
+
+ return slap_idassert_parse_cf( fname, lineno, argc, argv, &mi->mi_targets[ mi->mi_ntargets - 1 ]->mt_idassert );
+
+ /* idassert-authzFrom */
+ } else if ( strcasecmp( argv[ 0 ], "idassert-authzFrom" ) == 0 ) {
+ if ( mi->mi_ntargets == 0 ) {
+ Debug( LDAP_DEBUG_ANY,
+ "%s: line %d: \"idassert-bind\" "
+ "must appear inside a target specification.\n",
+ fname, lineno, 0 );
+ return 1;
+ }
+
+ switch ( argc ) {
+ case 2:
+ break;
+
+ case 1:
+ Debug( LDAP_DEBUG_ANY,
+ "%s: line %d: missing <id> in \"idassert-authzFrom <id>\".\n",
+ fname, lineno, 0 );
+ return 1;
+
+ default:
+ Debug( LDAP_DEBUG_ANY,
+ "%s: line %d: extra cruft after <id> in \"idassert-authzFrom <id>\".\n",
+ fname, lineno, 0 );
+ return 1;
+ }
+
+ return slap_idassert_authzfrom_parse_cf( fname, lineno, argv[ 1 ], &mi->mi_targets[ mi->mi_ntargets - 1 ]->mt_idassert );
+
+ /* quarantine */
+ } else if ( strcasecmp( argv[ 0 ], "quarantine" ) == 0 ) {
+ char buf[ SLAP_TEXT_BUFLEN ] = { '\0' };
+ slap_retry_info_t *ri = mi->mi_ntargets ?
+ &mi->mi_targets[ mi->mi_ntargets - 1 ]->mt_quarantine
+ : &mi->mi_quarantine;
+
+ if ( ( mi->mi_ntargets == 0 && META_BACK_QUARANTINE( mi ) )
+ || ( mi->mi_ntargets > 0 && META_BACK_TGT_QUARANTINE( mi->mi_targets[ mi->mi_ntargets - 1 ] ) ) )
+ {
+ Debug( LDAP_DEBUG_ANY,
+ "%s: line %d: quarantine already defined.\n",
+ fname, lineno, 0 );
+ return 1;
+ }
+
+ switch ( argc ) {
+ case 2:
+ break;
+
+ case 1:
+ Debug( LDAP_DEBUG_ANY,
+ "%s: line %d: missing arg in \"quarantine <pattern list>\".\n",
+ fname, lineno, 0 );
+ return 1;
+
+ default:
+ Debug( LDAP_DEBUG_ANY,
+ "%s: line %d: extra cruft after \"quarantine <pattern list>\".\n",
+ fname, lineno, 0 );
+ return 1;
+ }
+
+ if ( ri != &mi->mi_quarantine ) {
+ ri->ri_interval = NULL;
+ ri->ri_num = NULL;
+ }
+
+ if ( mi->mi_ntargets > 0 && !META_BACK_QUARANTINE( mi ) ) {
+ ldap_pvt_thread_mutex_init( &mi->mi_targets[ mi->mi_ntargets - 1 ]->mt_quarantine_mutex );
+ }
+
+ if ( slap_retry_info_parse( argv[ 1 ], ri, buf, sizeof( buf ) ) ) {
+ Debug( LDAP_DEBUG_ANY,
+ "%s line %d: %s.\n",
+ fname, lineno, buf );
+ return 1;
+ }
/* dn massaging */
} else if ( strcasecmp( argv[ 0 ], "suffixmassage" ) == 0 ) {
diff --git a/servers/slapd/back-meta/conn.c b/servers/slapd/back-meta/conn.c
index 5364650a07e5578ad88a937eab09313a39b88c2d..58d727d44c55465942aec0f933b197d041d17bd4 100644
--- a/servers/slapd/back-meta/conn.c
+++ b/servers/slapd/back-meta/conn.c
@@ -207,46 +207,22 @@ metaconn_alloc(
assert( ntargets > 0 );
/* malloc all in one */
- mc = ( metaconn_t * )ch_malloc( sizeof( metaconn_t )
+ mc = ( metaconn_t * )ch_calloc( 1, sizeof( metaconn_t )
+ sizeof( metasingleconn_t ) * ntargets );
if ( mc == NULL ) {
return NULL;
}
for ( i = 0; i < ntargets; i++ ) {
- mc->mc_conns[ i ].msc_ld = NULL;
- BER_BVZERO( &mc->mc_conns[ i ].msc_bound_ndn );
- BER_BVZERO( &mc->mc_conns[ i ].msc_cred );
- mc->mc_conns[ i ].msc_mscflags = 0;
mc->mc_conns[ i ].msc_info = mi;
}
- BER_BVZERO( &mc->mc_local_ndn );
- mc->msc_mscflags = 0;
mc->mc_authz_target = META_BOUND_NONE;
mc->mc_refcnt = 1;
return mc;
}
-static void
-meta_back_freeconn(
- Operation *op,
- metaconn_t *mc )
-{
- metainfo_t *mi = ( metainfo_t * )op->o_bd->be_private;
-
- assert( mc != NULL );
-
- ldap_pvt_thread_mutex_lock( &mi->mi_conninfo.lai_mutex );
-
- if ( --mc->mc_refcnt == 0 ) {
- meta_back_conn_free( mc );
- }
-
- ldap_pvt_thread_mutex_unlock( &mi->mi_conninfo.lai_mutex );
-}
-
/*
* meta_back_init_one_conn
*
@@ -256,13 +232,13 @@ int
meta_back_init_one_conn(
Operation *op,
SlapReply *rs,
- metatarget_t *mt,
metaconn_t *mc,
int candidate,
int ispriv,
ldap_back_send_t sendok )
{
metainfo_t *mi = ( metainfo_t * )op->o_bd->be_private;
+ metatarget_t *mt = mi->mi_targets[ candidate ];
metasingleconn_t *msc = &mc->mc_conns[ candidate ];
int version;
dncookie dc;
@@ -271,6 +247,42 @@ meta_back_init_one_conn(
int is_ldaps = 0;
#endif /* HAVE_TLS */
+ /* if the server is quarantined, and
+ * - the current interval did not expire yet, or
+ * - no more retries should occur,
+ * don't return the connection */
+ if ( mt->mt_isquarantined ) {
+ slap_retry_info_t *ri = &mt->mt_quarantine;
+ int dont_retry = 1;
+
+ if ( mt->mt_isquarantined == LDAP_BACK_FQ_YES ) {
+ dont_retry = ( ri->ri_num[ ri->ri_idx ] == SLAP_RETRYNUM_TAIL
+ || slap_get_time() < ri->ri_last + ri->ri_interval[ ri->ri_idx ] );
+ if ( !dont_retry ) {
+ if ( LogTest( LDAP_DEBUG_ANY ) ) {
+ char buf[ SLAP_TEXT_BUFLEN ];
+
+ snprintf( buf, sizeof( buf ),
+ "meta_back_init_one_conn[%d]: quarantine "
+ "retry block #%d try #%d",
+ candidate, ri->ri_idx, ri->ri_count );
+ Debug( LDAP_DEBUG_ANY, "%s %s.\n",
+ op->o_log_prefix, buf, 0 );
+ }
+
+ mt->mt_isquarantined = LDAP_BACK_FQ_RETRYING;
+ }
+ }
+
+ if ( dont_retry ) {
+ rs->sr_err = LDAP_UNAVAILABLE;
+ if ( op->o_conn && ( sendok & LDAP_BACK_SENDERR ) ) {
+ send_ldap_result( op, rs );
+ }
+ return rs->sr_err;
+ }
+ }
+
/*
* Already init'ed
*/
@@ -356,6 +368,7 @@ retry:;
if ( rs->sr_err == LDAP_SUCCESS ) {
int err;
+ /* FIXME: matched? referrals? response controls? */
rs->sr_err = ldap_parse_result( msc->msc_ld, res,
&err, NULL, NULL, NULL, NULL, 1 );
res = NULL;
@@ -431,21 +444,28 @@ retry:;
*/
if ( ispriv ) {
- if ( !BER_BVISNULL( &mt->mt_pseudorootdn ) ) {
- ber_dupbv( &msc->msc_bound_ndn, &mt->mt_pseudorootdn );
- if ( !BER_BVISNULL( &mt->mt_pseudorootpw ) ) {
- ber_dupbv( &msc->msc_cred, &mt->mt_pseudorootpw );
+ if ( !BER_BVISNULL( &mt->mt_idassert_authcDN ) ) {
+ ber_bvreplace( &msc->msc_bound_ndn, &mt->mt_idassert_authcDN );
+ if ( !BER_BVISNULL( &mt->mt_idassert_passwd ) ) {
+ ber_bvreplace( &msc->msc_cred, &mt->mt_idassert_passwd );
}
} else {
- ber_str2bv( "", 0, 1, &msc->msc_bound_ndn );
+ ber_bvreplace( &msc->msc_bound_ndn, &slap_empty_bv );
}
LDAP_BACK_CONN_ISPRIV_SET( msc );
} else {
- BER_BVZERO( &msc->msc_cred );
- BER_BVZERO( &msc->msc_bound_ndn );
+ if ( !BER_BVISNULL( &msc->msc_cred ) ) {
+ memset( msc->msc_cred.bv_val, 0, msc->msc_cred.bv_len );
+ ber_memfree_x( msc->msc_cred.bv_val, NULL );
+ BER_BVZERO( &msc->msc_cred );
+ }
+ if ( !BER_BVISNULL( &msc->msc_bound_ndn ) ) {
+ ber_memfree_x( msc->msc_bound_ndn.bv_val, NULL );
+ BER_BVZERO( &msc->msc_bound_ndn );
+ }
if ( !BER_BVISEMPTY( &op->o_ndn )
&& SLAP_IS_AUTHZ_BACKEND( op )
&& isauthz )
@@ -466,13 +486,13 @@ retry:;
goto error_return;
}
- /* copy the DN idf needed */
+ /* copy the DN if needed */
if ( msc->msc_bound_ndn.bv_val == op->o_conn->c_dn.bv_val ) {
ber_dupbv( &msc->msc_bound_ndn, &op->o_conn->c_dn );
}
} else {
- ber_str2bv( "", 0, 1, &msc->msc_bound_ndn );
+ ber_dupbv( &msc->msc_bound_ndn, (struct berval *)&slap_empty_bv );
}
}
@@ -542,7 +562,7 @@ meta_back_retry(
( void )rewrite_session_delete( mt->mt_rwmap.rwm_rw, op->o_conn );
/* mc here must be the regular mc, reset and ready for init */
- rc = meta_back_init_one_conn( op, rs, mt, mc, candidate,
+ rc = meta_back_init_one_conn( op, rs, mc, candidate,
LDAP_BACK_CONN_ISPRIV( mc ), sendok );
if ( binding ) {
LDAP_BACK_CONN_BINDING_SET( msc );
@@ -592,6 +612,10 @@ meta_back_retry(
}
}
+ if ( META_BACK_TGT_QUARANTINE( mt ) ) {
+ meta_back_quarantine( op, rs, candidate );
+ }
+
ldap_pvt_thread_mutex_unlock( &mi->mi_conninfo.lai_mutex );
return rc == LDAP_SUCCESS ? 1 : 0;
@@ -686,9 +710,7 @@ meta_back_get_candidate(
* and a default target is defined, and it is
* a candidate, try using it (FIXME: YMMV) */
if ( mi->mi_defaulttarget != META_DEFAULT_TARGET_NONE
- && meta_back_is_candidate( &mi->mi_targets[ mi->mi_defaulttarget ]->mt_nsuffix,
- mi->mi_targets[ mi->mi_defaulttarget ]->mt_scope,
- mi->mi_targets[ mi->mi_defaulttarget ]->mt_subtree_exclude,
+ && meta_back_is_candidate( mi->mi_targets[ mi->mi_defaulttarget ],
ndn, op->o_tag == LDAP_REQ_SEARCH ? op->ors_scope : LDAP_SCOPE_BASE ) )
{
candidate = mi->mi_defaulttarget;
@@ -851,7 +873,7 @@ meta_back_getconn(
/* Explicit Bind requests always get their own conn */
if ( !( sendok & LDAP_BACK_BINDING ) ) {
/* Searches for a metaconn in the avl tree */
-retry_lock:
+retry_lock:;
ldap_pvt_thread_mutex_lock( &mi->mi_conninfo.lai_mutex );
mc = (metaconn_t *)avl_find( mi->mi_conninfo.lai_tree,
(caddr_t)&mc_curr, meta_back_conndn_cmp );
@@ -927,6 +949,7 @@ retry_lock:
/* Looks like we didn't get a bind. Open a new session... */
if ( mc == NULL ) {
+ assert( new_conn == 0 );
mc = metaconn_alloc( op );
mc->mc_conn = mc_curr.mc_conn;
ber_dupbv( &mc->mc_local_ndn, &mc_curr.mc_local_ndn );
@@ -937,17 +960,15 @@ retry_lock:
}
for ( i = 0; i < mi->mi_ntargets; i++ ) {
- metatarget_t *mt = mi->mi_targets[ i ];
-
/*
* The target is activated; if needed, it is
* also init'd
*/
candidates[ i ].sr_err = meta_back_init_one_conn( op,
- rs, mt, mc, i,
- LDAP_BACK_CONN_ISPRIV( &mc_curr ), sendok );
+ rs, mc, i, LDAP_BACK_CONN_ISPRIV( &mc_curr ),
+ sendok );
if ( candidates[ i ].sr_err == LDAP_SUCCESS ) {
- candidates[ i ].sr_tag = META_CANDIDATE;
+ META_CANDIDATE_SET( &candidates[ i ] );
ncandidates++;
} else {
@@ -957,7 +978,7 @@ retry_lock:
* be init'd, should the other ones
* be tried?
*/
- candidates[ i ].sr_tag = META_NOT_CANDIDATE;
+ META_CANDIDATE_RESET( &candidates[ i ] );
err = candidates[ i ].sr_err;
continue;
}
@@ -965,7 +986,8 @@ retry_lock:
if ( ncandidates == 0 ) {
if ( new_conn ) {
- meta_back_freeconn( op, mc );
+ mc->mc_refcnt = 0;
+ meta_back_conn_free( mc );
} else {
meta_back_release_conn( op, mc );
@@ -1003,7 +1025,7 @@ retry_lock:
int j;
for ( j = 0; j < mi->mi_ntargets; j++ ) {
- candidates[ j ].sr_tag = META_NOT_CANDIDATE;
+ META_CANDIDATE_RESET( &candidates[ j ] );
}
/*
@@ -1079,6 +1101,7 @@ retry_lock2:;
/* Looks like we didn't get a bind. Open a new session... */
if ( mc == NULL ) {
+ assert( new_conn == 0 );
mc = metaconn_alloc( op );
mc->mc_conn = mc_curr.mc_conn;
ber_dupbv( &mc->mc_local_ndn, &mc_curr.mc_local_ndn );
@@ -1102,7 +1125,7 @@ retry_lock2:;
* also init'd. In case of error, meta_back_init_one_conn
* sends the appropriate result.
*/
- err = meta_back_init_one_conn( op, rs, mt, mc, i,
+ err = meta_back_init_one_conn( op, rs, mc, i,
LDAP_BACK_CONN_ISPRIV( &mc_curr ), sendok );
if ( err != LDAP_SUCCESS ) {
/*
@@ -1110,10 +1133,10 @@ retry_lock2:;
* be init'd, should the other ones
* be tried?
*/
- candidates[ i ].sr_tag = META_NOT_CANDIDATE;
+ META_CANDIDATE_RESET( &candidates[ i ] );
if ( new_conn ) {
- (void)meta_clear_one_candidate( msc );
- meta_back_freeconn( op, mc );
+ mc->mc_refcnt = 0;
+ meta_back_conn_free( mc );
} else {
meta_back_release_conn( op, mc );
@@ -1122,7 +1145,7 @@ retry_lock2:;
}
candidates[ i ].sr_err = LDAP_SUCCESS;
- candidates[ i ].sr_tag = META_CANDIDATE;
+ META_CANDIDATE_SET( &candidates[ i ] );
ncandidates++;
if ( candidate ) {
@@ -1136,6 +1159,7 @@ retry_lock2:;
/* Looks like we didn't get a bind. Open a new session... */
if ( mc == NULL ) {
+ assert( new_conn == 0 );
mc = metaconn_alloc( op );
mc->mc_conn = mc_curr.mc_conn;
ber_dupbv( &mc->mc_local_ndn, &mc_curr.mc_local_ndn );
@@ -1150,29 +1174,32 @@ retry_lock2:;
metasingleconn_t *msc = &mc->mc_conns[ i ];
if ( i == cached
- || meta_back_is_candidate( &mt->mt_nsuffix,
- mt->mt_scope,
- mt->mt_subtree_exclude,
- &op->o_req_ndn,
- LDAP_SCOPE_SUBTREE ) )
+ || meta_back_is_candidate( mt, &op->o_req_ndn,
+ LDAP_SCOPE_SUBTREE ) )
{
/*
* The target is activated; if needed, it is
* also init'd
*/
- int lerr = meta_back_init_one_conn( op, rs,
- mt, mc, i,
- LDAP_BACK_CONN_ISPRIV( &mc_curr ),
- sendok );
+ int lerr = meta_back_init_one_conn( op, rs, mc, i,
+ LDAP_BACK_CONN_ISPRIV( &mc_curr ), LDAP_BACK_DONTSEND );
if ( lerr == LDAP_SUCCESS ) {
- candidates[ i ].sr_tag = META_CANDIDATE;
+ META_CANDIDATE_SET( &candidates[ i ] );
candidates[ i ].sr_err = LDAP_SUCCESS;
ncandidates++;
Debug( LDAP_DEBUG_TRACE, "%s: meta_back_getconn[%d]\n",
op->o_log_prefix, i, 0 );
+ } else if ( lerr == LDAP_UNAVAILABLE && !META_BACK_ONERR_STOP( mi ) ) {
+ META_CANDIDATE_SET( &candidates[ i ] );
+ candidates[ i ].sr_err = LDAP_UNAVAILABLE;
+
+ Debug( LDAP_DEBUG_TRACE, "%s: meta_back_getconn[%d] %s\n",
+ op->o_log_prefix, i,
+ mt->mt_isquarantined != LDAP_BACK_FQ_NO ? "quarantined" : "unavailable" );
+
} else {
/*
@@ -1187,9 +1214,32 @@ retry_lock2:;
candidates[ i ].sr_err = lerr;
err = lerr;
- Debug( LDAP_DEBUG_ANY, "%s: meta_back_getconn[%d] failed: %d\n",
- op->o_log_prefix, i, lerr );
+ if ( lerr == LDAP_UNAVAILABLE && mt->mt_isquarantined != LDAP_BACK_FQ_NO ) {
+ Debug( LDAP_DEBUG_TRACE, "%s: meta_back_getconn[%d] quarantined: %d\n",
+ op->o_log_prefix, i, lerr );
+
+ } else {
+ Debug( LDAP_DEBUG_ANY, "%s: meta_back_getconn[%d] failed: %d\n",
+ op->o_log_prefix, i, lerr );
+ }
+
+ if ( META_BACK_ONERR_STOP( mi ) ) {
+ if ( sendok & LDAP_BACK_SENDERR ) {
+ send_ldap_result( op, rs );
+ rs->sr_text = NULL;
+ }
+ if ( new_conn ) {
+ mc->mc_refcnt = 0;
+ meta_back_conn_free( mc );
+
+ } else {
+ meta_back_release_conn( op, mc );
+ }
+
+ return NULL;
+ }
+ rs->sr_text = NULL;
continue;
}
@@ -1197,13 +1247,14 @@ retry_lock2:;
if ( new_conn ) {
( void )meta_clear_one_candidate( msc );
}
- candidates[ i ].sr_tag = META_NOT_CANDIDATE;
+ META_CANDIDATE_RESET( &candidates[ i ] );
}
}
if ( ncandidates == 0 ) {
if ( new_conn ) {
- meta_back_freeconn( op, mc );
+ mc->mc_refcnt = 0;
+ meta_back_conn_free( mc );
} else {
meta_back_release_conn( op, mc );
@@ -1261,8 +1312,9 @@ done:;
break;
case -1:
+ /* duplicate: free and try to get the newly created one */
if ( !( sendok & LDAP_BACK_BINDING ) ) {
- /* duplicate: free and try to get the newly created one */
+ new_conn = 0;
goto retry_lock;
}
LDAP_BACK_CONN_TAINTED_SET( mc );
@@ -1273,8 +1325,9 @@ done:;
"%s meta_back_getconn: candidates=%d conn=%ld insert failed\n",
op->o_log_prefix, ncandidates,
LDAP_BACK_PCONN_ID( mc->mc_conn ) );
-
- meta_back_freeconn( op, mc );
+
+ mc->mc_refcnt = 0;
+ meta_back_conn_free( mc );
rs->sr_err = LDAP_OTHER;
rs->sr_text = "proxy bind collision";
@@ -1317,12 +1370,11 @@ meta_back_release_conn_lock(
mc->mc_refcnt--;
LDAP_BACK_CONN_BINDING_CLEAR( mc );
if ( LDAP_BACK_CONN_TAINTED( mc ) ) {
- Debug( LDAP_DEBUG_TRACE, "%s meta_back_release_conn: mc=%p conn=%ld expired.\n",
+ Debug( LDAP_DEBUG_TRACE, "%s meta_back_release_conn: mc=%p conn=%ld tainted.\n",
op->o_log_prefix, (void *)mc, LDAP_BACK_PCONN_ID( mc->mc_conn ) );
(void)avl_delete( &mi->mi_conninfo.lai_tree,
( caddr_t )mc, meta_back_conndnmc_cmp );
if ( mc->mc_refcnt == 0 ) {
- meta_clear_candidates( op, mc );
meta_back_conn_free( mc );
}
}
@@ -1330,3 +1382,80 @@ meta_back_release_conn_lock(
ldap_pvt_thread_mutex_unlock( &mi->mi_conninfo.lai_mutex );
}
}
+
+void
+meta_back_quarantine(
+ Operation *op,
+ SlapReply *rs,
+ int candidate )
+{
+ metainfo_t *mi = (metainfo_t *)op->o_bd->be_private;
+ metatarget_t *mt = mi->mi_targets[ candidate ];
+
+ slap_retry_info_t *ri = &mt->mt_quarantine;
+
+ ldap_pvt_thread_mutex_lock( &mt->mt_quarantine_mutex );
+
+ if ( rs->sr_err == LDAP_UNAVAILABLE ) {
+ time_t new_last = slap_get_time();
+
+ switch ( mt->mt_isquarantined ) {
+ case LDAP_BACK_FQ_NO:
+ if ( ri->ri_last == new_last ) {
+ goto done;
+ }
+
+ Debug( LDAP_DEBUG_ANY,
+ "%s meta_back_quarantine[%d]: enter.\n",
+ op->o_log_prefix, candidate, 0 );
+
+ ri->ri_idx = 0;
+ ri->ri_count = 0;
+ break;
+
+ case LDAP_BACK_FQ_RETRYING:
+ if ( LogTest( LDAP_DEBUG_ANY ) ) {
+ char buf[ SLAP_TEXT_BUFLEN ];
+
+ snprintf( buf, sizeof( buf ),
+ "meta_back_quarantine[%d]: block #%d try #%d failed",
+ candidate, ri->ri_idx, ri->ri_count );
+ Debug( LDAP_DEBUG_ANY, "%s %s.\n",
+ op->o_log_prefix, buf, 0 );
+ }
+
+ ++ri->ri_count;
+ if ( ri->ri_num[ ri->ri_idx ] != SLAP_RETRYNUM_FOREVER
+ && ri->ri_count == ri->ri_num[ ri->ri_idx ] )
+ {
+ ri->ri_count = 0;
+ ++ri->ri_idx;
+ }
+ break;
+
+ default:
+ break;
+ }
+
+ mt->mt_isquarantined = LDAP_BACK_FQ_YES;
+ ri->ri_last = new_last;
+
+ } else if ( mt->mt_isquarantined == LDAP_BACK_FQ_RETRYING ) {
+ Debug( LDAP_DEBUG_ANY,
+ "%s meta_back_quarantine[%d]: exit.\n",
+ op->o_log_prefix, candidate, 0 );
+
+ if ( mi->mi_quarantine_f ) {
+ (void)mi->mi_quarantine_f( mi, candidate,
+ mi->mi_quarantine_p );
+ }
+
+ ri->ri_count = 0;
+ ri->ri_idx = 0;
+ mt->mt_isquarantined = LDAP_BACK_FQ_NO;
+ }
+
+done:;
+ ldap_pvt_thread_mutex_unlock( &mt->mt_quarantine_mutex );
+}
+
diff --git a/servers/slapd/back-meta/delete.c b/servers/slapd/back-meta/delete.c
index 4d23793a8378a7d98df17b5ef20d05ef9f4f5106..2d7ee6745496dd382f7912929f1988f910babc2a 100644
--- a/servers/slapd/back-meta/delete.c
+++ b/servers/slapd/back-meta/delete.c
@@ -35,13 +35,14 @@ int
meta_back_delete( Operation *op, SlapReply *rs )
{
metainfo_t *mi = ( metainfo_t * )op->o_bd->be_private;
+ metatarget_t *mt;
metaconn_t *mc = NULL;
int candidate = -1;
struct berval mdn = BER_BVNULL;
dncookie dc;
int msgid;
int do_retry = 1;
- int maperr = 1;
+ LDAPControl **ctrls = NULL;
mc = meta_back_getconn( op, rs, &candidate, LDAP_BACK_SENDERR );
if ( !mc || !meta_back_dobind( op, rs, mc, LDAP_BACK_SENDERR ) ) {
@@ -53,82 +54,45 @@ meta_back_delete( Operation *op, SlapReply *rs )
/*
* Rewrite the compare dn, if needed
*/
- dc.target = mi->mi_targets[ candidate ];
+ mt = mi->mi_targets[ candidate ];
+ dc.target = mt;
dc.conn = op->o_conn;
dc.rs = rs;
dc.ctx = "deleteDN";
if ( ldap_back_dn_massage( &dc, &op->o_req_dn, &mdn ) ) {
send_ldap_result( op, rs );
- goto done;
+ goto cleanup;
+ }
+
+ ctrls = op->o_ctrls;
+ if ( ldap_back_proxy_authz_ctrl( &mc->mc_conns[ candidate ].msc_bound_ndn,
+ mt->mt_version, &mt->mt_idassert, op, rs, &ctrls ) != LDAP_SUCCESS )
+ {
+ send_ldap_result( op, rs );
+ goto cleanup;
}
retry:;
rs->sr_err = ldap_delete_ext( mc->mc_conns[ candidate ].msc_ld,
- mdn.bv_val, op->o_ctrls, NULL, &msgid );
+ mdn.bv_val, ctrls, NULL, &msgid );
+ rs->sr_err = meta_back_op_result( mc, op, rs, candidate, msgid,
+ mt->mt_timeout[ LDAP_BACK_OP_DELETE ], LDAP_BACK_SENDRESULT );
if ( rs->sr_err == LDAP_UNAVAILABLE && do_retry ) {
do_retry = 0;
if ( meta_back_retry( op, rs, &mc, candidate, LDAP_BACK_SENDERR ) ) {
goto retry;
}
- goto cleanup;
-
- } else if ( rs->sr_err == LDAP_SUCCESS ) {
- struct timeval tv, *tvp = NULL;
- LDAPMessage *res = NULL;
- int rc;
-
- if ( mi->mi_targets[ candidate ]->mt_timeout[ LDAP_BACK_OP_DELETE ] != 0 ) {
- tv.tv_sec = mi->mi_targets[ candidate ]->mt_timeout[ LDAP_BACK_OP_DELETE ];
- tv.tv_usec = 0;
- tvp = &tv;
- }
-
- rs->sr_err = LDAP_OTHER;
- maperr = 0;
- rc = ldap_result( mc->mc_conns[ candidate ].msc_ld,
- msgid, LDAP_MSG_ALL, tvp, &res );
- switch ( rc ) {
- case -1:
- rs->sr_err = LDAP_OTHER;
- break;
-
- case 0:
- ldap_abandon_ext( mc->mc_conns[ candidate ].msc_ld,
- msgid, NULL, NULL );
- rs->sr_err = op->o_protocol >= LDAP_VERSION3 ?
- LDAP_ADMINLIMIT_EXCEEDED : LDAP_OPERATIONS_ERROR;
- break;
-
- case LDAP_RES_DELETE:
- rc = ldap_parse_result( mc->mc_conns[ candidate ].msc_ld,
- res, &rs->sr_err, NULL, NULL, NULL, NULL, 1 );
- if ( rc != LDAP_SUCCESS ) {
- rs->sr_err = rc;
- }
- maperr = 1;
- break;
-
- default:
- ldap_msgfree( res );
- break;
- }
- }
-
- if ( maperr ) {
- rs->sr_err = meta_back_op_result( mc, op, rs, candidate );
-
- } else {
- send_ldap_result( op, rs );
}
cleanup:;
+ (void)ldap_back_proxy_authz_ctrl_free( op, &ctrls );
+
if ( mdn.bv_val != op->o_req_dn.bv_val ) {
free( mdn.bv_val );
BER_BVZERO( &mdn );
}
-done:;
if ( mc ) {
meta_back_release_conn( op, mc );
}
diff --git a/servers/slapd/back-meta/init.c b/servers/slapd/back-meta/init.c
index 09f7007afc493f9a7a57fe351db58ae2205d21fd..7fee4d1c3feb00f74efa5c7d8d65a91c9f64dfca 100644
--- a/servers/slapd/back-meta/init.c
+++ b/servers/slapd/back-meta/init.c
@@ -130,15 +130,23 @@ meta_back_db_open(
for ( i = 0; i < mi->mi_ntargets; i++ ) {
metatarget_t *mt = mi->mi_targets[ i ];
- if ( mt->mt_flags & LDAP_BACK_F_SUPPORT_T_F_DISCOVER )
- {
- mt->mt_flags &= ~LDAP_BACK_F_SUPPORT_T_F_DISCOVER;
+ if ( META_BACK_TGT_T_F_DISCOVER( mt ) ) {
rc = slap_discover_feature( mt->mt_uri,
mt->mt_version,
slap_schema.si_ad_supportedFeatures->ad_cname.bv_val,
LDAP_FEATURE_ABSOLUTE_FILTERS );
if ( rc == LDAP_COMPARE_TRUE ) {
- mt->mt_flags |= LDAP_BACK_F_SUPPORT_T_F;
+ mt->mt_flags |= LDAP_BACK_F_T_F;
+ }
+ }
+
+ if ( META_BACK_TGT_CANCEL_DISCOVER( mt ) ) {
+ rc = slap_discover_feature( mt->mt_uri,
+ mt->mt_version,
+ slap_schema.si_ad_supportedExtension->ad_cname.bv_val,
+ LDAP_EXOP_CANCEL );
+ if ( rc == LDAP_COMPARE_TRUE ) {
+ mt->mt_flags |= LDAP_BACK_F_CANCEL_EXOP;
}
}
}
@@ -146,27 +154,33 @@ meta_back_db_open(
return 0;
}
+/*
+ * meta_back_conn_free()
+ *
+ * actually frees a connection; the reference count must be 0,
+ * and it must not (or no longer) be in the cache.
+ */
void
meta_back_conn_free(
void *v_mc )
{
metaconn_t *mc = v_mc;
- int i, ntargets;
+ int ntargets;
assert( mc != NULL );
assert( mc->mc_refcnt == 0 );
- if ( !BER_BVISNULL( &mc->mc_local_ndn ) ) {
- free( mc->mc_local_ndn.bv_val );
- }
-
- assert( mc->mc_conns != NULL );
-
/* at least one must be present... */
+ assert( mc->mc_conns != NULL );
ntargets = mc->mc_conns[ 0 ].msc_info->mi_ntargets;
+ assert( ntargets > 0 );
- for ( i = 0; i < ntargets; i++ ) {
- (void)meta_clear_one_candidate( &mc->mc_conns[ i ] );
+ for ( ; ntargets--; ) {
+ (void)meta_clear_one_candidate( &mc->mc_conns[ ntargets ] );
+ }
+
+ if ( !BER_BVISNULL( &mc->mc_local_ndn ) ) {
+ free( mc->mc_local_ndn.bv_val );
}
free( mc );
@@ -216,11 +230,26 @@ target_free(
if ( !BER_BVISNULL( &mt->mt_bindpw ) ) {
free( mt->mt_bindpw.bv_val );
}
- if ( !BER_BVISNULL( &mt->mt_pseudorootdn ) ) {
- free( mt->mt_pseudorootdn.bv_val );
+ if ( !BER_BVISNULL( &mt->mt_idassert_authcID ) ) {
+ ch_free( mt->mt_idassert_authcID.bv_val );
+ }
+ if ( !BER_BVISNULL( &mt->mt_idassert_authcDN ) ) {
+ ch_free( mt->mt_idassert_authcDN.bv_val );
+ }
+ if ( !BER_BVISNULL( &mt->mt_idassert_passwd ) ) {
+ ch_free( mt->mt_idassert_passwd.bv_val );
+ }
+ if ( !BER_BVISNULL( &mt->mt_idassert_authzID ) ) {
+ ch_free( mt->mt_idassert_authzID.bv_val );
}
- if ( !BER_BVISNULL( &mt->mt_pseudorootpw ) ) {
- free( mt->mt_pseudorootpw.bv_val );
+ if ( !BER_BVISNULL( &mt->mt_idassert_sasl_mech ) ) {
+ ch_free( mt->mt_idassert_sasl_mech.bv_val );
+ }
+ if ( !BER_BVISNULL( &mt->mt_idassert_sasl_realm ) ) {
+ ch_free( mt->mt_idassert_sasl_realm.bv_val );
+ }
+ if ( mt->mt_idassert_authz != NULL ) {
+ ber_bvarray_free( mt->mt_idassert_authz );
}
if ( mt->mt_rwmap.rwm_rw ) {
rewrite_info_delete( &mt->mt_rwmap.rwm_rw );
@@ -259,7 +288,18 @@ meta_back_db_destroy(
*/
if ( mi->mi_targets != NULL ) {
for ( i = 0; i < mi->mi_ntargets; i++ ) {
- target_free( mi->mi_targets[ i ] );
+ metatarget_t *mt = mi->mi_targets[ i ];
+
+ if ( META_BACK_TGT_QUARANTINE( mt ) ) {
+ if ( mt->mt_quarantine.ri_num != mi->mi_quarantine.ri_num )
+ {
+ slap_retry_info_destroy( &mt->mt_quarantine );
+ }
+
+ ldap_pvt_thread_mutex_destroy( &mt->mt_quarantine_mutex );
+ }
+
+ target_free( mt );
}
free( mi->mi_targets );
@@ -279,6 +319,10 @@ meta_back_db_destroy(
if ( mi->mi_candidates != NULL ) {
ber_memfree_x( mi->mi_candidates, NULL );
}
+
+ if ( META_BACK_QUARANTINE( mi ) ) {
+ slap_retry_info_destroy( &mi->mi_quarantine );
+ }
}
free( be->be_private );
diff --git a/servers/slapd/back-meta/map.c b/servers/slapd/back-meta/map.c
index 912bd1671ded37bcf0150c5d4aa7436559be663e..0f01e6bfc553eec7114d1cfda86e7c9afb41fe47 100644
--- a/servers/slapd/back-meta/map.c
+++ b/servers/slapd/back-meta/map.c
@@ -516,7 +516,7 @@ ldap_back_int_filter_map_rewrite(
/* FIXME: treat UNDEFINED as FALSE */
case SLAPD_COMPARE_UNDEFINED:
computed:;
- if ( dc->target->mt_flags & LDAP_BACK_F_SUPPORT_T_F ) {
+ if ( META_BACK_TGT_T_F( dc->target ) ) {
tmp = &ber_bvtf_false;
break;
}
@@ -524,7 +524,7 @@ computed:;
break;
case LDAP_COMPARE_TRUE:
- if ( dc->target->mt_flags & LDAP_BACK_F_SUPPORT_T_F ) {
+ if ( META_BACK_TGT_T_F( dc->target ) ) {
tmp = &ber_bvtf_true;
break;
}
diff --git a/servers/slapd/back-meta/modify.c b/servers/slapd/back-meta/modify.c
index 2e11c5b696663bf169326f52606fc857c183974f..6d1c3732f6265840e1367f64306ba27a02d9ae3f 100644
--- a/servers/slapd/back-meta/modify.c
+++ b/servers/slapd/back-meta/modify.c
@@ -35,9 +35,9 @@ int
meta_back_modify( Operation *op, SlapReply *rs )
{
metainfo_t *mi = ( metainfo_t * )op->o_bd->be_private;
+ metatarget_t *mt;
metaconn_t *mc;
int rc = 0;
- int maperr = 1;
LDAPMod **modv = NULL;
LDAPMod *mods = NULL;
Modifications *ml;
@@ -48,6 +48,7 @@ meta_back_modify( Operation *op, SlapReply *rs )
dncookie dc;
int msgid;
int do_retry = 1;
+ LDAPControl **ctrls = NULL;
mc = meta_back_getconn( op, rs, &candidate, LDAP_BACK_SENDERR );
if ( !mc || !meta_back_dobind( op, rs, mc, LDAP_BACK_SENDERR ) ) {
@@ -59,13 +60,14 @@ meta_back_modify( Operation *op, SlapReply *rs )
/*
* Rewrite the modify dn, if needed
*/
- dc.target = mi->mi_targets[ candidate ];
+ mt = mi->mi_targets[ candidate ];
+ dc.target = mt;
dc.conn = op->o_conn;
dc.rs = rs;
dc.ctx = "modifyDN";
if ( ldap_back_dn_massage( &dc, &op->o_req_dn, &mdn ) ) {
- maperr = 0;
+ send_ldap_result( op, rs );
goto cleanup;
}
@@ -74,14 +76,14 @@ meta_back_modify( Operation *op, SlapReply *rs )
mods = ch_malloc( sizeof( LDAPMod )*i );
if ( mods == NULL ) {
- rs->sr_err = LDAP_NO_MEMORY;
- maperr = 0;
+ rs->sr_err = LDAP_OTHER;
+ send_ldap_result( op, rs );
goto cleanup;
}
modv = ( LDAPMod ** )ch_malloc( ( i + 1 )*sizeof( LDAPMod * ) );
if ( modv == NULL ) {
- rs->sr_err = LDAP_NO_MEMORY;
- maperr = 0;
+ rs->sr_err = LDAP_OTHER;
+ send_ldap_result( op, rs );
goto cleanup;
}
@@ -102,7 +104,7 @@ meta_back_modify( Operation *op, SlapReply *rs )
mapped = ml->sml_desc->ad_cname;
} else {
- ldap_back_map( &mi->mi_targets[ candidate ]->mt_rwmap.rwm_at,
+ ldap_back_map( &mt->mt_rwmap.rwm_at,
&ml->sml_desc->ad_cname, &mapped,
BACKLDAP_MAP );
if ( BER_BVISNULL( &mapped ) || BER_BVISEMPTY( &mapped ) ) {
@@ -129,11 +131,11 @@ meta_back_modify( Operation *op, SlapReply *rs )
for ( j = 0; !BER_BVISNULL( &ml->sml_values[ j ] ); ) {
struct ldapmapping *mapping;
- ldap_back_mapping( &mi->mi_targets[ candidate ]->mt_rwmap.rwm_oc,
+ ldap_back_mapping( &mt->mt_rwmap.rwm_oc,
&ml->sml_values[ j ], &mapping, BACKLDAP_MAP );
if ( mapping == NULL ) {
- if ( mi->mi_targets[ candidate ]->mt_rwmap.rwm_oc.drop_missing ) {
+ if ( mt->mt_rwmap.rwm_oc.drop_missing ) {
continue;
}
mods[ i ].mod_bvalues[ j ] = &ml->sml_values[ j ];
@@ -174,67 +176,29 @@ meta_back_modify( Operation *op, SlapReply *rs )
}
modv[ i ] = 0;
+ ctrls = op->o_ctrls;
+ rc = ldap_back_proxy_authz_ctrl( &mc->mc_conns[ candidate ].msc_bound_ndn,
+ mt->mt_version, &mt->mt_idassert, op, rs, &ctrls );
+ if ( rc != LDAP_SUCCESS ) {
+ send_ldap_result( op, rs );
+ goto cleanup;
+ }
+
retry:;
rs->sr_err = ldap_modify_ext( mc->mc_conns[ candidate ].msc_ld, mdn.bv_val,
- modv, op->o_ctrls, NULL, &msgid );
+ modv, ctrls, NULL, &msgid );
+ rs->sr_err = meta_back_op_result( mc, op, rs, candidate, msgid,
+ mt->mt_timeout[ LDAP_BACK_OP_MODIFY ], LDAP_BACK_SENDRESULT );
if ( rs->sr_err == LDAP_UNAVAILABLE && do_retry ) {
do_retry = 0;
if ( meta_back_retry( op, rs, &mc, candidate, LDAP_BACK_SENDERR ) ) {
goto retry;
}
- goto done;
-
- } else if ( rs->sr_err == LDAP_SUCCESS ) {
- struct timeval tv, *tvp = NULL;
- LDAPMessage *res = NULL;
-
- if ( mi->mi_targets[ candidate ]->mt_timeout[ LDAP_BACK_OP_MODIFY ] != 0 ) {
- tv.tv_sec = mi->mi_targets[ candidate ]->mt_timeout[ LDAP_BACK_OP_MODIFY ];
- tv.tv_usec = 0;
- tvp = &tv;
- }
-
- rs->sr_err = LDAP_OTHER;
- rc = ldap_result( mc->mc_conns[ candidate ].msc_ld,
- msgid, LDAP_MSG_ALL, tvp, &res );
- switch ( rc ) {
- case -1:
- maperr = 0;
- break;
-
- case 0:
- ldap_abandon_ext( mc->mc_conns[ candidate ].msc_ld,
- msgid, NULL, NULL );
- rs->sr_err = op->o_protocol >= LDAP_VERSION3 ?
- LDAP_ADMINLIMIT_EXCEEDED : LDAP_OPERATIONS_ERROR;
- maperr = 0;
- break;
-
- case LDAP_RES_MODIFY:
- rc = ldap_parse_result( mc->mc_conns[ candidate ].msc_ld,
- res, &rs->sr_err, NULL, NULL, NULL, NULL, 1 );
- if ( rc != LDAP_SUCCESS ) {
- rs->sr_err = rc;
- }
- maperr = 1;
- break;
-
- default:
- maperr = 0;
- ldap_msgfree( res );
- break;
- }
}
cleanup:;
- if ( maperr ) {
- rc = meta_back_op_result( mc, op, rs, candidate );
-
- } else {
- send_ldap_result( op, rs );
- }
+ (void)ldap_back_proxy_authz_ctrl_free( op, &ctrls );
-done:;
if ( mdn.bv_val != op->o_req_dn.bv_val ) {
free( mdn.bv_val );
BER_BVZERO( &mdn );
diff --git a/servers/slapd/back-meta/modrdn.c b/servers/slapd/back-meta/modrdn.c
index 2c7d603b2bb4717afdfff4acad681f92de5c81a5..1ec273a9bb8dac32abca6699c65761df1643b6c8 100644
--- a/servers/slapd/back-meta/modrdn.c
+++ b/servers/slapd/back-meta/modrdn.c
@@ -35,6 +35,7 @@ int
meta_back_modrdn( Operation *op, SlapReply *rs )
{
metainfo_t *mi = ( metainfo_t * )op->o_bd->be_private;
+ metatarget_t *mt;
metaconn_t *mc;
int candidate = -1;
struct berval mdn = BER_BVNULL,
@@ -42,7 +43,7 @@ meta_back_modrdn( Operation *op, SlapReply *rs )
dncookie dc;
int msgid;
int do_retry = 1;
- int maperr = 1;
+ LDAPControl **ctrls = NULL;
mc = meta_back_getconn( op, rs, &candidate, LDAP_BACK_SENDERR );
if ( !mc || !meta_back_dobind( op, rs, mc, LDAP_BACK_SENDERR ) ) {
@@ -51,6 +52,8 @@ meta_back_modrdn( Operation *op, SlapReply *rs )
assert( mc->mc_conns[ candidate ].msc_ld != NULL );
+ mt = mi->mi_targets[ candidate ];
+ dc.target = mt;
dc.conn = op->o_conn;
dc.rs = rs;
@@ -76,7 +79,7 @@ meta_back_modrdn( Operation *op, SlapReply *rs )
*/
/* needs LDAPv3 */
- switch ( mi->mi_targets[ candidate ]->mt_version ) {
+ switch ( mt->mt_version ) {
case LDAP_VERSION3:
break;
@@ -90,18 +93,17 @@ meta_back_modrdn( Operation *op, SlapReply *rs )
/* op->o_protocol cannot be anything but LDAPv3,
* otherwise wouldn't be here */
rs->sr_err = LDAP_UNWILLING_TO_PERFORM;
- maperr = 0;
+ send_ldap_result( op, rs );
goto cleanup;
}
/*
* Rewrite the new superior, if defined and required
*/
- dc.target = mi->mi_targets[ candidate ];
dc.ctx = "newSuperiorDN";
if ( ldap_back_dn_massage( &dc, op->orr_newSup, &mnewSuperior ) ) {
rs->sr_err = LDAP_OTHER;
- maperr = 0;
+ send_ldap_result( op, rs );
goto cleanup;
}
}
@@ -109,11 +111,18 @@ meta_back_modrdn( Operation *op, SlapReply *rs )
/*
* Rewrite the modrdn dn, if required
*/
- dc.target = mi->mi_targets[ candidate ];
dc.ctx = "modrDN";
if ( ldap_back_dn_massage( &dc, &op->o_req_dn, &mdn ) ) {
rs->sr_err = LDAP_OTHER;
- maperr = 0;
+ send_ldap_result( op, rs );
+ goto cleanup;
+ }
+
+ ctrls = op->o_ctrls;
+ if ( ldap_back_proxy_authz_ctrl( &mc->mc_conns[ candidate ].msc_bound_ndn,
+ mt->mt_version, &mt->mt_idassert, op, rs, &ctrls ) != LDAP_SUCCESS )
+ {
+ send_ldap_result( op, rs );
goto cleanup;
}
@@ -121,64 +130,19 @@ retry:;
rs->sr_err = ldap_rename( mc->mc_conns[ candidate ].msc_ld,
mdn.bv_val, op->orr_newrdn.bv_val,
mnewSuperior.bv_val, op->orr_deleteoldrdn,
- op->o_ctrls, NULL, &msgid );
+ ctrls, NULL, &msgid );
+ rs->sr_err = meta_back_op_result( mc, op, rs, candidate, msgid,
+ mt->mt_timeout[ LDAP_BACK_OP_MODRDN ], LDAP_BACK_SENDRESULT );
if ( rs->sr_err == LDAP_UNAVAILABLE && do_retry ) {
do_retry = 0;
if ( meta_back_retry( op, rs, &mc, candidate, LDAP_BACK_SENDERR ) ) {
goto retry;
}
- goto done;
-
- } else if ( rs->sr_err == LDAP_SUCCESS ) {
- struct timeval tv, *tvp = NULL;
- LDAPMessage *res = NULL;
- int rc;
-
- if ( mi->mi_targets[ candidate ]->mt_timeout[ LDAP_BACK_OP_MODRDN ] != 0 ) {
- tv.tv_sec = mi->mi_targets[ candidate ]->mt_timeout[ LDAP_BACK_OP_MODRDN ];
- tv.tv_usec = 0;
- tvp = &tv;
- }
-
- rs->sr_err = LDAP_OTHER;
- rc = ldap_result( mc->mc_conns[ candidate ].msc_ld,
- msgid, LDAP_MSG_ALL, tvp, &res );
- maperr = 0;
- switch ( rc ) {
- case -1:
- break;
-
- case 0:
- ldap_abandon_ext( mc->mc_conns[ candidate ].msc_ld,
- msgid, NULL, NULL );
- rs->sr_err = op->o_protocol >= LDAP_VERSION3 ?
- LDAP_ADMINLIMIT_EXCEEDED : LDAP_OPERATIONS_ERROR;
- break;
-
- case LDAP_RES_RENAME:
- rc = ldap_parse_result( mc->mc_conns[ candidate ].msc_ld,
- res, &rs->sr_err, NULL, NULL, NULL, NULL, 1 );
- if ( rc != LDAP_SUCCESS ) {
- rs->sr_err = rc;
- }
- maperr = 1;
- break;
-
- default:
- ldap_msgfree( res );
- break;
- }
}
cleanup:;
- if ( maperr ) {
- meta_back_op_result( mc, op, rs, candidate );
-
- } else {
- send_ldap_result( op, rs );
- }
+ (void)ldap_back_proxy_authz_ctrl_free( op, &ctrls );
-done:;
if ( mdn.bv_val != op->o_req_dn.bv_val ) {
free( mdn.bv_val );
BER_BVZERO( &mdn );
diff --git a/servers/slapd/back-meta/search.c b/servers/slapd/back-meta/search.c
index 45c16240bd47d1f2894e23951e3d9d5af3f2002d..0a2efbeb53d24e17f4445cb3bedc987fd9ddc0d0 100644
--- a/servers/slapd/back-meta/search.c
+++ b/servers/slapd/back-meta/search.c
@@ -76,11 +76,11 @@ meta_search_dobind_init(
metatarget_t *mt = mi->mi_targets[ candidate ];
metasingleconn_t *msc = &mc->mc_conns[ candidate ];
- char *binddn = "";
- struct berval cred = BER_BVC( "" );
+ struct berval binddn = msc->msc_bound_ndn,
+ cred = msc->msc_cred;
+ int method;
int rc;
- int nretries = 1;
meta_search_candidate_t retcode;
@@ -108,41 +108,61 @@ meta_search_dobind_init(
LDAP_BACK_CONN_BINDING_SET( msc );
ldap_pvt_thread_mutex_unlock( &mi->mi_conninfo.lai_mutex );
- if ( be_isroot( op ) && !BER_BVISNULL( &mt->mt_pseudorootdn ) ) {
- binddn = mt->mt_pseudorootdn.bv_val;
- cred = mt->mt_pseudorootpw;
- }
+ /* NOTE: this obsoletes pseudorootdn */
+ if ( op->o_conn != NULL &&
+ !op->o_do_not_cache &&
+ ( BER_BVISNULL( &msc->msc_bound_ndn ) ||
+ BER_BVISEMPTY( &msc->msc_bound_ndn ) ||
+ ( mt->mt_idassert_flags & LDAP_BACK_AUTH_OVERRIDE ) ) )
+ {
+ rc = meta_back_proxy_authz_cred( mc, candidate, op, rs, LDAP_BACK_DONTSEND, &binddn, &cred, &method );
+ if ( rc != LDAP_SUCCESS ) {
+ goto down;
+ }
- /*
- * Otherwise an anonymous bind is performed
- * (note: if the target was already bound, the anonymous
- * bind clears the previous bind).
- */
- if ( !BER_BVISNULL( &msc->msc_bound_ndn ) ) {
- ber_memfree( msc->msc_bound_ndn.bv_val );
- BER_BVZERO( &msc->msc_bound_ndn );
- }
-
- if ( LDAP_BACK_SAVECRED( mi ) && !BER_BVISNULL( &msc->msc_cred ) ) {
- /* destroy sensitive data */
- memset( msc->msc_cred.bv_val, 0, msc->msc_cred.bv_len );
- ber_memfree( msc->msc_cred.bv_val );
- BER_BVZERO( &msc->msc_cred );
+ /* NOTE: we copy things here, even if bind didn't succeed yet,
+ * because the connection is not shared until bind is over */
+ if ( !BER_BVISNULL( &binddn ) ) {
+ ber_bvreplace( &msc->msc_bound_ndn, &binddn );
+ if ( LDAP_BACK_SAVECRED( mi ) && !BER_BVISNULL( &cred ) ) {
+ ber_dupbv( &msc->msc_cred, &cred );
+ }
+ }
+
+ if ( LDAP_BACK_CONN_ISBOUND( msc ) ) {
+ /* idassert ws configured with SASL bind */
+ ldap_pvt_thread_mutex_lock( &mi->mi_conninfo.lai_mutex );
+ LDAP_BACK_CONN_BINDING_CLEAR( msc );
+ ldap_pvt_thread_mutex_unlock( &mi->mi_conninfo.lai_mutex );
+ return META_SEARCH_CANDIDATE;
+ }
+
+ /* paranoid */
+ switch ( method ) {
+ case LDAP_AUTH_NONE:
+ case LDAP_AUTH_SIMPLE:
+ /* do a simple bind with binddn, cred */
+ break;
+
+ default:
+ assert( 0 );
+ break;
+ }
}
-retry:;
assert( msc->msc_ld != NULL );
- rc = ldap_sasl_bind( msc->msc_ld, binddn, LDAP_SASL_SIMPLE, &cred,
+ rc = ldap_sasl_bind( msc->msc_ld, binddn.bv_val, LDAP_SASL_SIMPLE, &cred,
NULL, NULL, &candidates[ candidate ].sr_msgid );
switch ( rc ) {
case LDAP_SUCCESS:
+ META_BINDING_SET( &candidates[ candidate ] );
return META_SEARCH_BINDING;
+down:;
case LDAP_SERVER_DOWN:
- if ( nretries && meta_back_retry( op, rs, mcp, candidate, LDAP_BACK_DONTSEND ) ) {
- nretries = 0;
- goto retry;
+ if ( meta_back_retry( op, rs, mcp, candidate, LDAP_BACK_DONTSEND ) ) {
+ return META_SEARCH_CANDIDATE;
}
if ( *mcp == NULL ) {
@@ -194,12 +214,14 @@ meta_search_dobind_result(
assert( msc->msc_ld != NULL );
+ /* FIXME: matched? referrals? response controls? */
rc = ldap_parse_result( msc->msc_ld, res,
&candidates[ candidate ].sr_err,
NULL, NULL, NULL, NULL, 1 );
- if ( rc == LDAP_SUCCESS ) {
- rc = slap_map_api2result( &candidates[ candidate ] );
+ if ( rc != LDAP_SUCCESS ) {
+ candidates[ candidate ].sr_err = rc;
}
+ rc = slap_map_api2result( &candidates[ candidate ] );
ldap_pvt_thread_mutex_lock( &mi->mi_conninfo.lai_mutex );
LDAP_BACK_CONN_BINDING_CLEAR( msc );
@@ -221,6 +243,8 @@ meta_search_dobind_result(
}
ldap_pvt_thread_mutex_unlock( &mi->mi_conninfo.lai_mutex );
+ META_BINDING_CLEAR( &candidates[ candidate ] );
+
return retcode;
}
@@ -235,11 +259,9 @@ meta_back_search_start(
{
metainfo_t *mi = ( metainfo_t * )op->o_bd->be_private;
metatarget_t *mt = mi->mi_targets[ candidate ];
- metaconn_t *mc = *mcp;
- metasingleconn_t *msc = &mc->mc_conns[ candidate ];
+ metasingleconn_t *msc = &(*mcp)->mc_conns[ candidate ];
struct berval realbase = op->o_req_dn;
int realscope = op->ors_scope;
- ber_len_t suffixlen = 0;
struct berval mbase = BER_BVNULL;
struct berval mfilter = BER_BVNULL;
char **mapped_attrs = NULL;
@@ -247,29 +269,26 @@ meta_back_search_start(
meta_search_candidate_t retcode;
struct timeval tv, *tvp = NULL;
int nretries = 1;
-
- Debug( LDAP_DEBUG_TRACE, "%s >>> meta_back_search_start[%d]\n", op->o_log_prefix, candidate, 0 );
-
- /* should we check return values? */
- if ( op->ors_deref != -1 ) {
- assert( msc->msc_ld != NULL );
- (void)ldap_set_option( msc->msc_ld, LDAP_OPT_DEREF,
- ( void * )&op->ors_deref );
- }
-
- if ( op->ors_tlimit != SLAP_NO_LIMIT ) {
- tv.tv_sec = op->ors_tlimit > 0 ? op->ors_tlimit : 1;
- tv.tv_usec = 0;
- tvp = &tv;
+ LDAPControl **ctrls = NULL;
+
+ /* this should not happen; just in case... */
+ if ( msc->msc_ld == NULL ) {
+ Debug( LDAP_DEBUG_ANY,
+ "%s: meta_back_search_start candidate=%d ld=NULL%s.\n",
+ op->o_log_prefix, candidate,
+ META_BACK_ONERR_STOP( mi ) ? "" : " (ignored)" );
+ if ( META_BACK_ONERR_STOP( mi ) ) {
+ return META_SEARCH_ERR;
+ }
+ return META_SEARCH_NOT_CANDIDATE;
}
- dc->target = mt;
+ Debug( LDAP_DEBUG_TRACE, "%s >>> meta_back_search_start[%d]\n", op->o_log_prefix, candidate, 0 );
/*
* modifies the base according to the scope, if required
*/
- suffixlen = mt->mt_nsuffix.bv_len;
- if ( suffixlen > op->o_req_ndn.bv_len ) {
+ if ( mt->mt_nsuffix.bv_len > op->o_req_ndn.bv_len ) {
switch ( op->ors_scope ) {
case LDAP_SCOPE_SUBTREE:
/*
@@ -341,6 +360,7 @@ meta_back_search_start(
/*
* Rewrite the search base, if required
*/
+ dc->target = mt;
dc->ctx = "searchBase";
switch ( ldap_back_dn_massage( dc, &realbase, &mbase ) ) {
default:
@@ -391,6 +411,28 @@ meta_back_search_start(
goto done;
}
+ /* should we check return values? */
+ if ( op->ors_deref != -1 ) {
+ assert( msc->msc_ld != NULL );
+ (void)ldap_set_option( msc->msc_ld, LDAP_OPT_DEREF,
+ ( void * )&op->ors_deref );
+ }
+
+ if ( op->ors_tlimit != SLAP_NO_LIMIT ) {
+ tv.tv_sec = op->ors_tlimit > 0 ? op->ors_tlimit : 1;
+ tv.tv_usec = 0;
+ tvp = &tv;
+ }
+
+ ctrls = op->o_ctrls;
+ if ( ldap_back_proxy_authz_ctrl( &msc->msc_bound_ndn,
+ mt->mt_version, &mt->mt_idassert, op, rs, &ctrls ) != LDAP_SUCCESS )
+ {
+ candidates[ candidate ].sr_msgid = META_MSGID_IGNORE;
+ retcode = META_SEARCH_NOT_CANDIDATE;
+ goto done;
+ }
+
/*
* Starts the search
*/
@@ -399,7 +441,7 @@ retry:;
rc = ldap_search_ext( msc->msc_ld,
mbase.bv_val, realscope, mfilter.bv_val,
mapped_attrs, op->ors_attrsonly,
- op->o_ctrls, NULL, tvp, op->ors_slimit,
+ ctrls, NULL, tvp, op->ors_slimit,
&candidates[ candidate ].sr_msgid );
switch ( rc ) {
case LDAP_SUCCESS:
@@ -424,6 +466,8 @@ retry:;
}
done:;
+ (void)ldap_back_proxy_authz_ctrl_free( op, &ctrls );
+
if ( mapped_attrs ) {
free( mapped_attrs );
}
@@ -475,7 +519,7 @@ meta_back_search( Operation *op, SlapReply *rs )
for ( i = 0; i < mi->mi_ntargets; i++ ) {
candidates[ i ].sr_msgid = META_MSGID_IGNORE;
- if ( candidates[ i ].sr_tag != META_CANDIDATE ) {
+ if ( !META_IS_CANDIDATE( &candidates[ i ] ) ) {
continue;
}
@@ -486,7 +530,7 @@ meta_back_search( Operation *op, SlapReply *rs )
}
for ( i = 0; i < mi->mi_ntargets; i++ ) {
- if ( candidates[ i ].sr_tag != META_CANDIDATE
+ if ( !META_IS_CANDIDATE( &candidates[ i ] )
|| candidates[ i ].sr_err != LDAP_SUCCESS )
{
continue;
@@ -522,7 +566,7 @@ meta_back_search( Operation *op, SlapReply *rs )
int i;
for ( i = 0; i < mi->mi_ntargets; i++ ) {
- if ( candidates[ i ].sr_tag == META_CANDIDATE ) {
+ if ( META_IS_CANDIDATE( &candidates[ i ] ) ) {
cnd[ i ] = '*';
} else {
cnd[ i ] = ' ';
@@ -553,7 +597,7 @@ meta_back_search( Operation *op, SlapReply *rs )
* maybe we should pick the worst... */
rc = LDAP_NO_SUCH_OBJECT;
for ( i = 0; i < mi->mi_ntargets; i++ ) {
- if ( candidates[ i ].sr_tag == META_CANDIDATE
+ if ( META_IS_CANDIDATE( &candidates[ i ] )
&& candidates[ i ].sr_err != LDAP_SUCCESS )
{
rc = candidates[ i ].sr_err;
@@ -657,6 +701,7 @@ meta_back_search( Operation *op, SlapReply *rs )
assert( 0 );
break;
}
+ break;
default:
/* impossible */
@@ -739,8 +784,7 @@ really_bad:;
*/
candidates[ i ].sr_msgid = META_MSGID_IGNORE;
--ncandidates;
- rs->sr_err = candidates[ i ].sr_err = LDAP_OTHER;
- rs->sr_text = "remote server unavailable";
+ rs->sr_err = candidates[ i ].sr_err;
} else if ( rc == LDAP_RES_SEARCH_ENTRY ) {
if ( candidates[ i ].sr_type == REP_INTERMEDIATE ) {
@@ -881,6 +925,7 @@ really_bad:;
* back-meta would need to merge them
* consistently (think of pagedResults...)
*/
+ /* FIXME: response controls? */
rs->sr_err = ldap_parse_result( msc->msc_ld,
res,
&candidates[ i ].sr_err,
@@ -1072,20 +1117,19 @@ really_bad:;
/* check for abandon */
if ( op->o_abandon || doabandon ) {
for ( i = 0; i < mi->mi_ntargets; i++ ) {
- metasingleconn_t *msc = &mc->mc_conns[ i ];
-
if ( candidates[ i ].sr_msgid != META_MSGID_IGNORE )
{
- ldap_abandon_ext( msc->msc_ld,
- candidates[ i ].sr_msgid,
- NULL, NULL );
+ (void)meta_back_cancel( mc, op, rs,
+ candidates[ i ].sr_msgid, i,
+ LDAP_BACK_DONTSEND );
candidates[ i ].sr_msgid = META_MSGID_IGNORE;
}
}
if ( op->o_abandon ) {
rc = SLAPD_ABANDON;
- goto finish;
+ /* let send_ldap_result play cleanup handlers (ITS#4645) */
+ break;
}
}
@@ -1105,7 +1149,9 @@ really_bad:;
* FIXME: need a better strategy to handle errors
*/
if ( mc ) {
- rc = meta_back_op_result( mc, op, rs, META_TARGET_NONE );
+ rc = meta_back_op_result( mc, op, rs, META_TARGET_NONE,
+ -1, stoptime != -1 ? (stoptime - slap_get_time()) : 0,
+ LDAP_BACK_SENDERR );
} else {
rc = rs->sr_err;
}
@@ -1124,7 +1170,7 @@ really_bad:;
/* we use the first one */
for ( i = 0; i < mi->mi_ntargets; i++ ) {
- if ( candidates[ i ].sr_tag == META_CANDIDATE
+ if ( META_IS_CANDIDATE( &candidates[ i ] )
&& candidates[ i ].sr_matched != NULL )
{
struct berval bv, pbv;
@@ -1185,7 +1231,7 @@ really_bad:;
int i;
for ( i = 0; i < mi->mi_ntargets; i++ ) {
- if ( candidates[ i ].sr_tag == META_CANDIDATE ) {
+ if ( META_IS_CANDIDATE( &candidates[ i ] ) ) {
cnd[ i ] = '*';
} else {
cnd[ i ] = ' ';
@@ -1229,16 +1275,17 @@ finish:;
}
for ( i = 0; i < mi->mi_ntargets; i++ ) {
- if ( candidates[ i ].sr_tag != META_CANDIDATE ) {
+ if ( !META_IS_CANDIDATE( &candidates[ i ] ) ) {
continue;
}
- if ( mc && candidates[ i ].sr_msgid >= 0 ) {
+ if ( mc && META_IS_BINDING( &candidates[ i ] ) ) {
ldap_pvt_thread_mutex_lock( &mi->mi_conninfo.lai_mutex );
if ( LDAP_BACK_CONN_BINDING( &mc->mc_conns[ i ] ) ) {
LDAP_BACK_CONN_BINDING_CLEAR( &mc->mc_conns[ i ] );
}
ldap_pvt_thread_mutex_unlock( &mi->mi_conninfo.lai_mutex );
+ META_BINDING_CLEAR( &candidates[ i ] );
}
if ( candidates[ i ].sr_matched ) {
@@ -1260,6 +1307,10 @@ finish:;
ldap_controls_free( candidates[ i ].sr_ctrls );
candidates[ i ].sr_ctrls = NULL;
}
+
+ if ( META_BACK_TGT_QUARANTINE( mi->mi_targets[ i ] ) ) {
+ meta_back_quarantine( op, &candidates[ i ], i );
+ }
}
if ( mc ) {
diff --git a/servers/slapd/back-monitor/conn.c b/servers/slapd/back-monitor/conn.c
index 21f0a1d34da0c8c6292e237ebfc1a2a6e8699f2f..a35036237c239044ba00882d99a6bd34846614c3 100644
--- a/servers/slapd/back-monitor/conn.c
+++ b/servers/slapd/back-monitor/conn.c
@@ -28,10 +28,6 @@
#include "lutil.h"
#include "back-monitor.h"
-#ifndef LDAP_DEVEL
-#define MONITOR_LEGACY_CONN
-#endif
-
static int
monitor_subsys_conn_update(
Operation *op,
diff --git a/servers/slapd/back-monitor/entry.c b/servers/slapd/back-monitor/entry.c
index a7b83d489fb9be3175b0d44e4e468e67a32ca858..3a2377489bb10613aeee8762347b30f09436b986 100644
--- a/servers/slapd/back-monitor/entry.c
+++ b/servers/slapd/back-monitor/entry.c
@@ -42,11 +42,7 @@ monitor_entry_update(
mp = ( monitor_entry_t * )e->e_private;
- if ( mp->mp_info && mp->mp_info->mss_update ) {
- rc = mp->mp_info->mss_update( op, rs, e );
- }
-
- if ( rc == SLAP_CB_CONTINUE && mp->mp_cb ) {
+ if ( mp->mp_cb ) {
struct monitor_callback_t *mc;
for ( mc = mp->mp_cb; mc; mc = mc->mc_next ) {
@@ -59,6 +55,10 @@ monitor_entry_update(
}
}
+ if ( rc == SLAP_CB_CONTINUE && mp->mp_info && mp->mp_info->mss_update ) {
+ rc = mp->mp_info->mss_update( op, rs, e );
+ }
+
if ( rc == SLAP_CB_CONTINUE ) {
rc = LDAP_SUCCESS;
}
@@ -115,11 +115,7 @@ monitor_entry_modify(
mp = ( monitor_entry_t * )e->e_private;
- if ( mp->mp_info && mp->mp_info->mss_modify ) {
- rc = mp->mp_info->mss_modify( op, rs, e );
- }
-
- if ( rc == SLAP_CB_CONTINUE && mp->mp_cb ) {
+ if ( mp->mp_cb ) {
struct monitor_callback_t *mc;
for ( mc = mp->mp_cb; mc; mc = mc->mc_next ) {
@@ -132,6 +128,10 @@ monitor_entry_modify(
}
}
+ if ( rc == SLAP_CB_CONTINUE && mp->mp_info && mp->mp_info->mss_modify ) {
+ rc = mp->mp_info->mss_modify( op, rs, e );
+ }
+
if ( rc == SLAP_CB_CONTINUE ) {
rc = LDAP_SUCCESS;
}
diff --git a/servers/slapd/back-monitor/thread.c b/servers/slapd/back-monitor/thread.c
index c66df017d6eaaee33ecb3af3cafabff22f4a01ca..47b39c82d0e475fe45f53370361a3e04c111653f 100644
--- a/servers/slapd/back-monitor/thread.c
+++ b/servers/slapd/back-monitor/thread.c
@@ -175,6 +175,42 @@ monitor_subsys_thread_init(
*ep = e;
ep = &mp->mp_next;
+ /*
+ * Tasklist
+ */
+ BER_BVSTR( &bv, "cn=Tasklist" );
+ e = monitor_entry_stub( &ms->mss_dn, &ms->mss_ndn, &bv,
+ mi->mi_oc_monitoredObject, mi, NULL, NULL );
+ if ( e == NULL ) {
+ Debug( LDAP_DEBUG_ANY,
+ "monitor_subsys_thread_init: "
+ "unable to create entry \"%s,%s\"\n",
+ bv.bv_val, ms->mss_ndn.bv_val, 0 );
+ return( -1 );
+ }
+ BER_BVSTR( &bv, "0" );
+ attr_merge_normalize_one( e, mi->mi_ad_monitoredInfo, &bv, NULL );
+
+ mp = monitor_entrypriv_create();
+ if ( mp == NULL ) {
+ return -1;
+ }
+ e->e_private = ( void * )mp;
+ mp->mp_info = ms;
+ mp->mp_flags = ms->mss_flags \
+ | MONITOR_F_SUB | MONITOR_F_PERSISTENT;
+
+ if ( monitor_cache_add( mi, e ) ) {
+ Debug( LDAP_DEBUG_ANY,
+ "monitor_subsys_thread_init: "
+ "unable to add entry \"%s\"\n",
+ e->e_name.bv_val, 0, 0 );
+ return( -1 );
+ }
+
+ *ep = e;
+ ep = &mp->mp_next;
+
monitor_cache_release( mi, e_thread );
return( 0 );
@@ -189,23 +225,33 @@ monitor_subsys_thread_update(
monitor_info_t *mi = ( monitor_info_t * )op->o_bd->be_private;
Attribute *a;
char buf[ BACKMONITOR_BUFSIZE ];
- static struct berval backload_bv = BER_BVC( "cn=backload" );
- static struct berval runqueue_bv = BER_BVC( "cn=runqueue" );
+ enum {
+ MT_UNKNOWN,
+ MT_BACKLOAD,
+ MT_RUNQUEUE,
+ MT_TASKLIST,
+ MT_MAX /* unused */
+ };
+ static slap_verbmasks mt[] = {
+ { BER_BVC( "cn=backload" ), MT_BACKLOAD },
+ { BER_BVC( "cn=runqueue" ), MT_RUNQUEUE },
+ { BER_BVC( "cn=tasklist" ), MT_TASKLIST },
+ { BER_BVC( "cn=max" ), MT_UNKNOWN },
+ { BER_BVNULL, MT_UNKNOWN }
+ };
struct berval rdn, bv;
ber_len_t len;
- int which = 0, i;
- struct re_s *re;
+ int which, i;
+ struct re_s *re;
assert( mi != NULL );
dnRdn( &e->e_nname, &rdn );
- if ( dn_match( &rdn, &backload_bv ) ) {
- which = 1;
-
- } else if ( dn_match( &rdn, &runqueue_bv ) ) {
- which = 2;
- } else {
+ which = bverb_to_mask( &rdn, mt );
+ if ( BER_BVISNULL( &mt[ which ].word )
+ || mt[ which ].mask == MT_UNKNOWN )
+ {
return SLAP_CB_CONTINUE;
}
@@ -214,8 +260,8 @@ monitor_subsys_thread_update(
return rs->sr_err = LDAP_OTHER;
}
- switch ( which ) {
- case 1:
+ switch ( mt[ which ].mask ) {
+ case MT_BACKLOAD:
snprintf( buf, sizeof( buf ), "%d",
ldap_pvt_thread_pool_backload( &connection_pool ) );
len = strlen( buf );
@@ -226,25 +272,64 @@ monitor_subsys_thread_update(
AC_MEMCPY( a->a_vals[ 0 ].bv_val, buf, len + 1 );
break;
- case 2:
+ case MT_RUNQUEUE:
for ( i = 0; !BER_BVISNULL( &a->a_vals[ i ] ); i++ ) {
- ch_free( a->a_vals[i].bv_val );
+ ch_free( a->a_vals[ i ].bv_val );
BER_BVZERO( &a->a_vals[ i ] );
}
+ if ( a->a_nvals != a->a_vals ) {
+ ber_bvarray_free( a->a_nvals );
+ }
+ a->a_nvals = NULL;
bv.bv_val = buf;
ldap_pvt_thread_mutex_lock( &slapd_rq.rq_mutex );
+ i = 0;
LDAP_STAILQ_FOREACH( re, &slapd_rq.run_list, rnext ) {
- bv.bv_len = snprintf( buf, sizeof( buf ), "%s(%s)",
- re->tname, re->tspec );
+ bv.bv_len = snprintf( buf, sizeof( buf ), "{%d}%s(%s)",
+ i, re->tname, re->tspec );
+ if ( bv.bv_len < sizeof( buf ) ) {
+ value_add_one( &a->a_vals, &bv );
+ }
+ i++;
+ }
+ ldap_pvt_thread_mutex_unlock( &slapd_rq.rq_mutex );
+
+ /* don't leave 'round attributes with no values */
+ if ( BER_BVISNULL( &a->a_vals[ 0 ] ) ) {
+ BER_BVSTR( &bv, "{0}()" );
value_add_one( &a->a_vals, &bv );
}
+ a->a_nvals = a->a_vals;
+ break;
+
+ case MT_TASKLIST:
+ for ( i = 0; !BER_BVISNULL( &a->a_vals[ i ] ); i++ ) {
+ ch_free( a->a_vals[ i ].bv_val );
+ BER_BVZERO( &a->a_vals[ i ] );
+ }
+ if ( a->a_nvals != a->a_vals ) {
+ ber_bvarray_free( a->a_nvals );
+ }
+ a->a_nvals = NULL;
+ bv.bv_val = buf;
+ ldap_pvt_thread_mutex_lock( &slapd_rq.rq_mutex );
+ i = 0;
+ LDAP_STAILQ_FOREACH( re, &slapd_rq.task_list, tnext ) {
+ bv.bv_len = snprintf( buf, sizeof( buf ), "{%d}%s(%s)",
+ i, re->tname, re->tspec );
+ if ( bv.bv_len < sizeof( buf ) ) {
+ value_add_one( &a->a_vals, &bv );
+ }
+ i++;
+ }
ldap_pvt_thread_mutex_unlock( &slapd_rq.rq_mutex );
/* don't leave 'round attributes with no values */
if ( BER_BVISNULL( &a->a_vals[ 0 ] ) ) {
- BER_BVSTR( &bv, "()" );
+ BER_BVSTR( &bv, "{0}()" );
value_add_one( &a->a_vals, &bv );
}
+ a->a_nvals = a->a_vals;
break;
}
diff --git a/servers/slapd/back-sql/add.c b/servers/slapd/back-sql/add.c
index 078df583a1728668eaee3de434789e9d52086921..eb24f67b928cd61e29a50932023c521973690df6 100644
--- a/servers/slapd/back-sql/add.c
+++ b/servers/slapd/back-sql/add.c
@@ -1461,6 +1461,7 @@ done:;
SQLUSMALLINT CompletionType = SQL_ROLLBACK;
if ( rs->sr_err == LDAP_SUCCESS && !op->o_noop ) {
+ assert( e == NULL );
CompletionType = SQL_COMMIT;
}
@@ -1503,6 +1504,10 @@ done:;
}
}
+ if ( op->o_noop && rs->sr_err == LDAP_SUCCESS ) {
+ rs->sr_err = LDAP_X_NO_OPERATION;
+ }
+
send_ldap_result( op, rs );
slap_graduate_commit_csn( op );
diff --git a/servers/slapd/back-sql/delete.c b/servers/slapd/back-sql/delete.c
index a6656a89844014fcd3221e2b21f3ff0d736dcaac..7f010fb083af0efa8c44e7a5cca4cc1464a4b5a6 100644
--- a/servers/slapd/back-sql/delete.c
+++ b/servers/slapd/back-sql/delete.c
@@ -441,6 +441,7 @@ backsql_delete( Operation *op, SlapReply *rs )
SQLUSMALLINT CompletionType = SQL_ROLLBACK;
if ( rs->sr_err == LDAP_SUCCESS && !op->o_noop ) {
+ assert( e == NULL );
CompletionType = SQL_COMMIT;
}
@@ -462,6 +463,10 @@ done:;
}
}
+ if ( op->o_noop && rs->sr_err == LDAP_SUCCESS ) {
+ rs->sr_err = LDAP_X_NO_OPERATION;
+ }
+
send_ldap_result( op, rs );
Debug( LDAP_DEBUG_TRACE, "<==backsql_delete()\n", 0, 0, 0 );
diff --git a/servers/slapd/back-sql/entry-id.c b/servers/slapd/back-sql/entry-id.c
index 0e17f1c1f860e0cceaa3306c7e816458e6ce68d3..801729e73363a8e2d7a8ccd7aa5666949dc0655b 100644
--- a/servers/slapd/back-sql/entry-id.c
+++ b/servers/slapd/back-sql/entry-id.c
@@ -90,7 +90,7 @@ backsql_dn2id(
{
backsql_info *bi = op->o_bd->be_private;
SQLHSTMT sth = SQL_NULL_HSTMT;
- BACKSQL_ROW_NTS row;
+ BACKSQL_ROW_NTS row = { 0 };
RETCODE rc;
int res;
struct berval realndn = BER_BVNULL;
diff --git a/servers/slapd/back-sql/init.c b/servers/slapd/back-sql/init.c
index a8fc074795cff9ec07f85f39addc72dbc797227a..42bbb9c2a36469f43b9845a6565a967a3b48739e 100644
--- a/servers/slapd/back-sql/init.c
+++ b/servers/slapd/back-sql/init.c
@@ -36,10 +36,8 @@ sql_back_initialize(
static char *controls[] = {
LDAP_CONTROL_ASSERT,
LDAP_CONTROL_MANAGEDSAIT,
-#if 0 /* needs improvements */
LDAP_CONTROL_NOOP,
-#endif
-#ifdef SLAP_CONTROL_X_TREE_DELETE
+#if 0 /* SLAP_CONTROL_X_TREE_DELETE */
SLAP_CONTROL_X_TREE_DELETE,
#endif /* SLAP_CONTROL_X_TREE_DELETE */
NULL
diff --git a/servers/slapd/back-sql/modify.c b/servers/slapd/back-sql/modify.c
index a3a93d983790d8751e76f84eac61a3048fa88dc7..df1c95341e5f8fc77cdfd148abaf5c5c081c62ac 100644
--- a/servers/slapd/back-sql/modify.c
+++ b/servers/slapd/back-sql/modify.c
@@ -168,6 +168,7 @@ do_transact:;
* Commit only if all operations succeed
*/
if ( rs->sr_err == LDAP_SUCCESS && !op->o_noop ) {
+ assert( e == NULL );
CompletionType = SQL_COMMIT;
}
@@ -188,6 +189,10 @@ done:;
}
}
+ if ( op->o_noop && rs->sr_err == LDAP_SUCCESS ) {
+ rs->sr_err = LDAP_X_NO_OPERATION;
+ }
+
send_ldap_result( op, rs );
slap_graduate_commit_csn( op );
diff --git a/servers/slapd/back-sql/modrdn.c b/servers/slapd/back-sql/modrdn.c
index 1c81cead296a9a68023a045965eb1983988313ed..67940a58ba881d3e649c0ffc6a2ca950bc595729 100644
--- a/servers/slapd/back-sql/modrdn.c
+++ b/servers/slapd/back-sql/modrdn.c
@@ -491,6 +491,10 @@ done:;
SQLTransact( SQL_NULL_HENV, dbh, CompletionType );
}
+ if ( op->o_noop && rs->sr_err == LDAP_SUCCESS ) {
+ rs->sr_err = LDAP_X_NO_OPERATION;
+ }
+
send_ldap_result( op, rs );
slap_graduate_commit_csn( op );
diff --git a/servers/slapd/back-sql/rdbms_depend/README b/servers/slapd/back-sql/rdbms_depend/README
index 65af67a196732b5a03238411a647df98a9929c71..8c9ffe14f26217f6a15caa3f6611b7983ddddfdb 100644
--- a/servers/slapd/back-sql/rdbms_depend/README
+++ b/servers/slapd/back-sql/rdbms_depend/README
@@ -120,7 +120,7 @@ example=> <control-D>
3.1.5) Run the test:
[root@localhost]# cd $SOURCES/tests
-[root@localhost]# SLAPD_USE_SQL=pgsql ./run test031
+[root@localhost]# SLAPD_USE_SQL=pgsql ./run sql-test000
3.2) MySQL
@@ -149,7 +149,7 @@ mysql> exit;
3.2.5) Run the test:
[root@localhost]# cd $SOURCES/tests
-[root@localhost]# SLAPD_USE_SQL=mysql ./run test031
+[root@localhost]# SLAPD_USE_SQL=mysql ./run sql-test000
3.3) IBM db2
[n.a.]
@@ -173,7 +173,7 @@ in auto-commit mode (-c)
3.3.5) Run the test:
[root@localhost]# cd $SOURCES/tests
-[root@localhost]# SLAPD_USE_SQL=ibmdb2 ./run test031
+[root@localhost]# SLAPD_USE_SQL=ibmdb2 ./run sql-test000
4) Cleanup:
The test is basically readonly; this can be performed by all RDBMSes
diff --git a/servers/slapd/back-sql/search.c b/servers/slapd/back-sql/search.c
index c1ea9952f50bf8243805aebeda74817a9570ffc2..6824827a0959af93bb4e74dfa5422469fd26857a 100644
--- a/servers/slapd/back-sql/search.c
+++ b/servers/slapd/back-sql/search.c
@@ -314,9 +314,7 @@ backsql_init_search(
}
} else {
- rs->sr_ref = referral_rewrite( default_referral,
- NULL, &op->o_req_dn, scope );
- rc = rs->sr_err = LDAP_REFERRAL;
+ rs->sr_err = rc;
}
}
}
@@ -654,9 +652,35 @@ backsql_process_filter( backsql_srch_info *bsi, Filter *f )
Debug( LDAP_DEBUG_TRACE, "==>backsql_process_filter()\n", 0, 0, 0 );
if ( f->f_choice == SLAPD_FILTER_COMPUTED ) {
+ struct berval flt;
+ char *msg = NULL;
+
+ switch ( f->f_result ) {
+ case LDAP_COMPARE_TRUE:
+ BER_BVSTR( &flt, "10=10" );
+ msg = "TRUE";
+ break;
+
+ case LDAP_COMPARE_FALSE:
+ BER_BVSTR( &flt, "11=0" );
+ msg = "FALSE";
+ break;
+
+ case SLAPD_COMPARE_UNDEFINED:
+ BER_BVSTR( &flt, "12=0" );
+ msg = "UNDEFINED";
+ break;
+
+ default:
+ rc = -1;
+ goto done;
+ }
+
Debug( LDAP_DEBUG_TRACE, "backsql_process_filter(): "
- "invalid filter\n", 0, 0, 0 );
- rc = -1;
+ "filter computed (%s)\n", msg, 0, 0 );
+ backsql_strfcat_x( &bsi->bsi_flt_where,
+ bsi->bsi_op->o_tmpmemctx, "b", &flt );
+ rc = 1;
goto done;
}
diff --git a/servers/slapd/backend.c b/servers/slapd/backend.c
index 978f94649c77ca0df27b387b06f25d63adc0e2fc..514a919a68d06f316a38a4c9dd9c85e3d3c02a74 100644
--- a/servers/slapd/backend.c
+++ b/servers/slapd/backend.c
@@ -592,7 +592,7 @@ select_backend(
Backend *be, *b2 = NULL;
LDAP_STAILQ_FOREACH( be, &backendDB, be_next ) {
- if ( be->be_nsuffix == NULL ) {
+ if ( be->be_nsuffix == NULL || SLAP_DBHIDDEN( be )) {
continue;
}
diff --git a/servers/slapd/backglue.c b/servers/slapd/backglue.c
index 202c63cd9d882ec212ec6b39bd2c1b56a4f50c79..cce5905ee1b827595b6ea2bd2a8037e8765a0804 100644
--- a/servers/slapd/backglue.c
+++ b/servers/slapd/backglue.c
@@ -65,7 +65,7 @@ glue_back_select (
glueinfo *gi = (glueinfo *)on->on_bi.bi_private;
int i;
- for (i = 0; i<gi->gi_nodes; i++) {
+ for (i = gi->gi_nodes-1; i >= 0; i--) {
assert( gi->gi_n[i].gn_be->be_nsuffix != NULL );
if (dnIsSuffix(dn, &gi->gi_n[i].gn_be->be_nsuffix[0])) {
@@ -262,6 +262,13 @@ glue_chk_controls ( Operation *op, SlapReply *rs )
return rc;
}
+/* ITS#4615 - overlays configured above the glue overlay should be
+ * invoked for the entire glued tree. Overlays configured below the
+ * glue overlay should only be invoked on the master backend.
+ * So, if we're searching on any subordinates, we need to force the
+ * current overlay chain to stop processing, without stopping the
+ * overall callback flow.
+ */
static int
glue_sub_search( Operation *op, SlapReply *rs, BackendDB *b0,
slap_overinst *on )
@@ -333,7 +340,7 @@ glue_op_search ( Operation *op, SlapReply *rs )
b1 = op->o_bd;
/*
- * Execute in reverse order, most general first
+ * Execute in reverse order, most specific first
*/
for (i = gi->gi_nodes; i >= 0; i--) {
if ( i == gi->gi_nodes ) {
@@ -347,6 +354,9 @@ glue_op_search ( Operation *op, SlapReply *rs )
continue;
if (!dnIsSuffix(&btmp->be_nsuffix[0], &b1->be_nsuffix[0]))
continue;
+ if (get_no_subordinate_glue(op) && btmp != b1)
+ continue;
+
if (tlimit0 != SLAP_NO_LIMIT) {
op->o_time = slap_get_time();
op->ors_tlimit = stoptime - op->o_time;
@@ -377,6 +387,9 @@ glue_op_search ( Operation *op, SlapReply *rs )
if ( rs->sr_err == LDAP_NO_SUCH_OBJECT ) {
gs.err = LDAP_SUCCESS;
}
+ op->ors_scope = LDAP_SCOPE_ONELEVEL;
+ op->o_req_dn = dn;
+ op->o_req_ndn = ndn;
} else if (scope0 == LDAP_SCOPE_SUBTREE &&
dn_match(&op->o_bd->be_nsuffix[0], &ndn))
@@ -769,6 +782,13 @@ glue_db_init(
BackendInfo *bi = oi->oi_orig;
glueinfo *gi;
+ if ( SLAP_GLUE_SUBORDINATE( be )) {
+ Debug( LDAP_DEBUG_ANY, "glue: backend %s is already subordinate, "
+ "cannot have glue overlay!\n",
+ be->be_suffix[0].bv_val, 0, 0 );
+ return LDAP_OTHER;
+ }
+
gi = ch_calloc( 1, sizeof(glueinfo));
on->on_bi.bi_private = gi;
dnParent( be->be_nsuffix, &gi->gi_pdn );
@@ -954,6 +974,12 @@ glue_sub_add( BackendDB *be, int advert, int online )
glue_Addrec *ga;
int rc = 0;
+ if ( overlay_is_inst( be, "glue" )) {
+ Debug( LDAP_DEBUG_ANY, "glue: backend %s already has glue overlay, "
+ "cannot be a subordinate!\n",
+ be->be_suffix[0].bv_val, 0, 0 );
+ return LDAP_OTHER;
+ }
SLAP_DBFLAGS( be ) |= SLAP_DBFLAG_GLUE_SUBORDINATE;
if ( advert )
SLAP_DBFLAGS( be ) |= SLAP_DBFLAG_GLUE_ADVERTISE;
diff --git a/servers/slapd/backover.c b/servers/slapd/backover.c
index 3128840ce9f541c2f470526ae947ab698f1d2327..f14b327019ee72e5a25a283346ff22911a15a439 100644
--- a/servers/slapd/backover.c
+++ b/servers/slapd/backover.c
@@ -1054,7 +1054,11 @@ overlay_config( BackendDB *be, const char *ov )
be->bd_info = (BackendInfo *)on2;
rc = on2->on_bi.bi_db_init( be );
be->bd_info = (BackendInfo *)oi;
- if ( rc ) return rc;
+ if ( rc ) {
+ oi->oi_list = on2->on_next;
+ ch_free( on2 );
+ return rc;
+ }
}
return 0;
diff --git a/servers/slapd/bconfig.c b/servers/slapd/bconfig.c
index 2f4528645074d32f1169648bda14ca298587098f..ada0f53d21a1f7c406988b9525ad36cf015f81b6 100644
--- a/servers/slapd/bconfig.c
+++ b/servers/slapd/bconfig.c
@@ -162,6 +162,7 @@ enum {
CFG_SSTR_IF_MIN,
CFG_TTHREADS,
CFG_MIRRORMODE,
+ CFG_HIDDEN,
CFG_LAST
};
@@ -220,6 +221,7 @@ static OidRec OidMacros[] = {
* OLcfgOv{Oc|At}:12 -> ppolicy
* OLcfgOv{Oc|At}:13 -> constraint
* OLcfgOv{Oc|At}:14 -> translucent
+ * OLcfgOv{Oc|At}:15 -> auditlog
*/
/* alphabetical ordering */
@@ -319,6 +321,9 @@ static ConfigTable config_back_cf_table[] = {
#endif
"( OLcfgGlAt:17 NAME 'olcGentleHUP' "
"SYNTAX OMsBoolean SINGLE-VALUE )", NULL, NULL },
+ { "hidden", "on|off", 2, 2, 0, ARG_DB|ARG_ON_OFF|ARG_MAGIC|CFG_HIDDEN,
+ &config_generic, "( OLcfgDbAt:0.17 NAME 'olcHidden' "
+ "SYNTAX OMsBoolean SINGLE-VALUE )", NULL, NULL },
{ "idletimeout", "timeout", 2, 2, 0, ARG_INT,
&global_idletimeout, "( OLcfgGlAt:18 NAME 'olcIdleTimeout' "
"SYNTAX OMsInteger SINGLE-VALUE )", NULL, NULL },
@@ -693,7 +698,8 @@ static ConfigOCs cf_ocs[] = {
"DESC 'OpenLDAP Database-specific options' "
"SUP olcConfig STRUCTURAL "
"MUST olcDatabase "
- "MAY ( olcSuffix $ olcSubordinate $ olcAccess $ olcLastMod $ olcLimits $ "
+ "MAY ( olcHidden $ olcSuffix $ olcSubordinate $ olcAccess $ "
+ "olcLastMod $ olcLimits $ "
"olcMaxDerefDepth $ olcPlugin $ olcReadOnly $ olcReplica $ "
"olcReplicaArgsFile $ olcReplicaPidFile $ olcReplicationInterval $ "
"olcReplogFile $ olcRequires $ olcRestrict $ olcRootDN $ olcRootPW $ "
@@ -806,6 +812,13 @@ config_generic(ConfigArgs *c) {
case CFG_DEPTH:
c->value_int = c->be->be_max_deref_depth;
break;
+ case CFG_HIDDEN:
+ if ( SLAP_DBHIDDEN( c->be )) {
+ c->value_int = 1;
+ } else {
+ rc = 1;
+ }
+ break;
case CFG_OID: {
ConfigFile *cf = c->private;
if ( !cf )
@@ -1057,6 +1070,10 @@ config_generic(ConfigArgs *c) {
logfileName = NULL;
break;
+ case CFG_HIDDEN:
+ c->be->be_flags &= ~SLAP_DBFLAG_HIDDEN;
+ break;
+
case CFG_ACL:
if ( c->valx < 0 ) {
AccessControl *end;
@@ -1401,6 +1418,13 @@ config_generic(ConfigArgs *c) {
SLAP_DBFLAGS(c->be) |= SLAP_DBFLAG_SINGLE_SHADOW;
break;
+ case CFG_HIDDEN:
+ if (c->value_int)
+ SLAP_DBFLAGS(c->be) |= SLAP_DBFLAG_HIDDEN;
+ else
+ SLAP_DBFLAGS(c->be) &= ~SLAP_DBFLAG_HIDDEN;
+ break;
+
case CFG_SSTR_IF_MAX:
if (c->value_int < index_substr_if_minlen) {
snprintf( c->msg, sizeof( c->msg ), "<%s> invalid value", c->argv[0] );
@@ -1908,7 +1932,10 @@ config_suffix(ConfigArgs *c)
pdn = c->value_dn;
ndn = c->value_ndn;
- tbe = select_backend(&ndn, 0, 0);
+ if (SLAP_DBHIDDEN( c->be ))
+ tbe = NULL;
+ else
+ tbe = select_backend(&ndn, 0, 0);
if(tbe == c->be) {
Debug( LDAP_DEBUG_ANY, "%s: suffix already served by this backend!.\n",
c->log, 0, 0);
@@ -2118,8 +2145,10 @@ config_disallows(ConfigArgs *c) {
static int
config_requires(ConfigArgs *c) {
- slap_mask_t requires = 0;
- int i;
+ slap_mask_t requires = frontendDB->be_requires;
+ int i, argc = c->argc;
+ char **argv = c->argv;
+
slap_verbmasks requires_ops[] = {
{ BER_BVC("bind"), SLAP_REQUIRE_BIND },
{ BER_BVC("LDAPv3"), SLAP_REQUIRE_LDAP_V3 },
@@ -2139,11 +2168,23 @@ config_requires(ConfigArgs *c) {
}
return 0;
}
- i = verbs_to_mask(c->argc, c->argv, requires_ops, &requires);
+ /* "none" can only be first, to wipe out default/global values */
+ if ( strcasecmp( c->argv[ 1 ], "none" ) == 0 ) {
+ argv++;
+ argc--;
+ requires = 0;
+ }
+ i = verbs_to_mask(argc, argv, requires_ops, &requires);
if ( i ) {
- snprintf( c->msg, sizeof( c->msg ), "<%s> unknown feature", c->argv[0] );
- Debug(LDAP_DEBUG_ANY, "%s: %s %s\n",
- c->log, c->msg, c->argv[i]);
+ if (strcasecmp( c->argv[ i ], "none" ) == 0 ) {
+ snprintf( c->msg, sizeof( c->msg ), "<%s> \"none\" (#%d) must be listed first", c->argv[0], i - 1 );
+ Debug(LDAP_DEBUG_ANY, "%s: %s\n",
+ c->log, c->msg, 0);
+ } else {
+ snprintf( c->msg, sizeof( c->msg ), "<%s> unknown feature #%d", c->argv[0], i - 1 );
+ Debug(LDAP_DEBUG_ANY, "%s: %s \"%s\"\n",
+ c->log, c->msg, c->argv[i]);
+ }
return(1);
}
c->be->be_requires = requires;
@@ -2589,6 +2630,8 @@ config_replica(ConfigArgs *c) {
nr = add_replica_info(c->be, replicauri, replicahost);
break;
} else if(!strncasecmp(c->argv[i], "uri=", STRLENOF("uri="))) {
+ ber_len_t len;
+
if ( replicauri ) {
snprintf( c->msg, sizeof( c->msg ), "<%s> replica host/URI already specified", c->argv[0] );
Debug(LDAP_DEBUG_ANY, "%s: %s \"%s\"\n", c->log, c->msg, replicauri );
@@ -2607,11 +2650,28 @@ config_replica(ConfigArgs *c) {
Debug(LDAP_DEBUG_ANY, "%s: %s\n", c->log, c->msg, 0 );
return(1);
}
+
+ len = strlen(ludp->lud_scheme) + strlen(ludp->lud_host) +
+ STRLENOF("://") + 1;
+ if (ludp->lud_port != LDAP_PORT) {
+ if (ludp->lud_port < 1 || ludp->lud_port > 65535) {
+ ldap_free_urldesc(ludp);
+ snprintf( c->msg, sizeof( c->msg ), "<%s> invalid port",
+ c->argv[0] );
+ Debug(LDAP_DEBUG_ANY, "%s: %s\n", c->log, c->msg, 0 );
+ return(1);
+ }
+ len += STRLENOF(":65535");
+ }
+ replicauri = ch_malloc( len );
+ replicahost = lutil_strcopy( replicauri, ludp->lud_scheme );
+ replicahost = lutil_strcopy( replicahost, "://" );
+ if (ludp->lud_port == LDAP_PORT) {
+ strcpy( replicahost, ludp->lud_host );
+ } else {
+ sprintf( replicahost, "%s:%d",ludp->lud_host,ludp->lud_port );
+ }
ldap_free_urldesc(ludp);
- replicauri = c->argv[i] + STRLENOF("uri=");
- replicauri = ch_strdup( replicauri );
- replicahost = strchr( replicauri, '/' );
- replicahost += 2;
nr = add_replica_info(c->be, replicauri, replicahost);
break;
}
@@ -4620,6 +4680,7 @@ config_back_db_open( BackendDB *be )
return -1;
}
ce = e->e_private;
+ ce->ce_private = cfb->cb_config;
/* Create schema nodes for included schema... */
if ( cfb->cb_config->c_kids ) {
diff --git a/servers/slapd/config.c b/servers/slapd/config.c
index d6e09186f2fb36dc5ed06256057682ff70338d47..cbf71e3bde8016ef8833f0057ee1e1f46e0caab3 100644
--- a/servers/slapd/config.c
+++ b/servers/slapd/config.c
@@ -43,6 +43,7 @@
#include "slapi/slapi.h"
#endif
#include "lutil.h"
+#include "lutil_ldap.h"
#include "config.h"
#ifdef HAVE_TLS
@@ -315,7 +316,8 @@ int config_set_vals(ConfigTable *Conf, ConfigArgs *c) {
return(0);
}
if(arg_type & ARG_OFFSET) {
- if (c->be)
+ if (c->be && (!overlay_is_over(c->be) ||
+ ((slap_overinfo *)c->be->bd_info)->oi_orig == c->bi))
ptr = c->be->be_private;
else if (c->bi)
ptr = c->bi->bi_private;
@@ -406,7 +408,8 @@ config_get_vals(ConfigTable *cf, ConfigArgs *c)
if ( rc ) return rc;
} else {
if ( cf->arg_type & ARG_OFFSET ) {
- if ( c->be )
+ if (c->be && (!overlay_is_over(c->be) ||
+ ((slap_overinfo *)c->be->bd_info)->oi_orig == c->bi))
ptr = c->be->be_private;
else if ( c->bi )
ptr = c->bi->bi_private;
@@ -431,6 +434,7 @@ config_get_vals(ConfigTable *cf, ConfigArgs *c)
}
}
if ( cf->arg_type & ARGS_TYPES) {
+ bv.bv_len = 0;
bv.bv_val = c->log;
switch(cf->arg_type & ARGS_TYPES) {
case ARG_INT: bv.bv_len = snprintf(bv.bv_val, sizeof( c->log ), "%d", c->value_int); break;
@@ -452,14 +456,19 @@ config_get_vals(ConfigTable *cf, ConfigArgs *c)
return 1;
}
break;
+ default:
+ bv.bv_val = NULL;
+ break;
}
if (bv.bv_val == c->log && bv.bv_len >= sizeof( c->log ) ) {
return 1;
}
- if (( cf->arg_type & ARGS_TYPES ) == ARG_STRING )
+ if (( cf->arg_type & ARGS_TYPES ) == ARG_STRING ) {
ber_bvarray_add(&c->rvalue_vals, &bv);
- else
+ } else if ( !BER_BVISNULL( &bv ) ) {
value_add_one(&c->rvalue_vals, &bv);
+ }
+ /* else: maybe c->rvalue_vals already set? */
}
return rc;
}
@@ -871,14 +880,21 @@ done:
/* restrictops, allows, disallows, requires, loglevel */
int
-verb_to_mask(const char *word, slap_verbmasks *v) {
+bverb_to_mask(struct berval *bword, slap_verbmasks *v) {
int i;
for(i = 0; !BER_BVISNULL(&v[i].word); i++) {
- if(!strcasecmp(word, v[i].word.bv_val)) break;
+ if(!ber_bvstrcasecmp(bword, &v[i].word)) break;
}
return(i);
}
+int
+verb_to_mask(const char *word, slap_verbmasks *v) {
+ struct berval bword;
+ ber_str2bv( word, 0, 0, &bword );
+ return bverb_to_mask( &bword, v );
+}
+
int
verbs_to_mask(int argc, char *argv[], slap_verbmasks *v, slap_mask_t *m) {
int i, j;
@@ -1389,6 +1405,157 @@ int bindconf_tls_set( slap_bindconf *bc, LDAP *ld )
}
#endif
+/*
+ * connect to a client using the bindconf data
+ * note: should move "version" into bindconf...
+ */
+int
+slap_client_connect( LDAP **ldp, slap_bindconf *sb, int version )
+{
+ LDAP *ld = NULL;
+ int rc;
+
+ /* Init connection to master */
+ rc = ldap_initialize( &ld, sb->sb_uri.bv_val );
+ if ( rc != LDAP_SUCCESS ) {
+ Debug( LDAP_DEBUG_ANY,
+ "slap_client_connect: "
+ "ldap_initialize(%s) failed (%d)\n",
+ sb->sb_uri.bv_val, rc, 0 );
+ return rc;
+ }
+
+ if ( version != 0 ) {
+ ldap_set_option( ld, LDAP_OPT_PROTOCOL_VERSION,
+ (const void *)&version );
+ }
+
+#ifdef HAVE_TLS
+ if ( sb->sb_tls_do_init ) {
+ rc = bindconf_tls_set( sb, ld );
+
+ } else if ( sb->sb_tls_ctx ) {
+ rc = ldap_set_option( ld, LDAP_OPT_X_TLS_CTX,
+ sb->sb_tls_ctx );
+ }
+
+ if ( rc ) {
+ Debug( LDAP_DEBUG_ANY,
+ "slap_client_connect: "
+ "URI=%s TLS context initialization failed (%d)\n",
+ sb->sb_uri.bv_val, rc, 0 );
+ return rc;
+ }
+#endif
+
+ /* Bind */
+ if ( sb->sb_tls ) {
+ rc = ldap_start_tls_s( ld, NULL, NULL );
+ if ( rc != LDAP_SUCCESS ) {
+ Debug( LDAP_DEBUG_ANY,
+ "slap_client_connect: URI=%s "
+ "%s, ldap_start_tls failed (%d)\n",
+ sb->sb_uri.bv_val,
+ sb->sb_tls == SB_TLS_CRITICAL ?
+ "Error" : "Warning",
+ rc );
+ if ( sb->sb_tls == SB_TLS_CRITICAL ) {
+ goto done;
+ }
+ }
+ }
+
+ if ( sb->sb_method == LDAP_AUTH_SASL ) {
+#ifdef HAVE_CYRUS_SASL
+ void *defaults;
+
+ if ( sb->sb_secprops != NULL ) {
+ rc = ldap_set_option( ld,
+ LDAP_OPT_X_SASL_SECPROPS, sb->sb_secprops);
+
+ if( rc != LDAP_OPT_SUCCESS ) {
+ Debug( LDAP_DEBUG_ANY,
+ "slap_client_connect: "
+ "error, ldap_set_option "
+ "(%s,SECPROPS,\"%s\") failed!\n",
+ sb->sb_uri.bv_val, sb->sb_secprops, 0 );
+ goto done;
+ }
+ }
+
+ defaults = lutil_sasl_defaults( ld,
+ sb->sb_saslmech.bv_val,
+ sb->sb_realm.bv_val,
+ sb->sb_authcId.bv_val,
+ sb->sb_cred.bv_val,
+ sb->sb_authzId.bv_val );
+
+ rc = ldap_sasl_interactive_bind_s( ld,
+ sb->sb_binddn.bv_val,
+ sb->sb_saslmech.bv_val,
+ NULL, NULL,
+ LDAP_SASL_QUIET,
+ lutil_sasl_interact,
+ defaults );
+
+ lutil_sasl_freedefs( defaults );
+
+ /* FIXME: different error behaviors according to
+ * 1) return code
+ * 2) on err policy : exit, retry, backoff ...
+ */
+ if ( rc != LDAP_SUCCESS ) {
+ static struct berval bv_GSSAPI = BER_BVC( "GSSAPI" );
+
+ Debug( LDAP_DEBUG_ANY, "slap_client_connect: URI=%s "
+ "ldap_sasl_interactive_bind_s failed (%d)\n",
+ sb->sb_uri.bv_val, rc, 0 );
+
+ /* FIXME (see above comment) */
+ /* if Kerberos credentials cache is not active, retry */
+ if ( ber_bvcmp( &sb->sb_saslmech, &bv_GSSAPI ) == 0 &&
+ rc == LDAP_LOCAL_ERROR )
+ {
+ rc = LDAP_SERVER_DOWN;
+ }
+
+ goto done;
+ }
+#else /* HAVE_CYRUS_SASL */
+ /* Should never get here, we trapped this at config time */
+ assert(0);
+ Debug( LDAP_DEBUG_SYNC, "not compiled with SASL support\n", 0, 0, 0 );
+ rc = LDAP_OTHER;
+ goto done;
+#endif
+
+ } else if ( sb->sb_method == LDAP_AUTH_SIMPLE ) {
+ rc = ldap_sasl_bind_s( ld,
+ sb->sb_binddn.bv_val, LDAP_SASL_SIMPLE,
+ &sb->sb_cred, NULL, NULL, NULL );
+ if ( rc != LDAP_SUCCESS ) {
+ Debug( LDAP_DEBUG_ANY, "slap_client_connect: "
+ "URI=%s DN=\"%s\" "
+ "ldap_sasl_bind_s failed (%d)\n",
+ sb->sb_uri.bv_val, sb->sb_binddn.bv_val, rc );
+ goto done;
+ }
+ }
+
+done:;
+ if ( rc ) {
+ if ( ld ) {
+ ldap_unbind_ext( ld, NULL, NULL );
+ *ldp = NULL;
+ }
+
+ } else {
+ *ldp = ld;
+ }
+
+ return rc;
+}
+
/* -------------------------------------- */
diff --git a/servers/slapd/connection.c b/servers/slapd/connection.c
index 4cf698c15b3767c8b135aca7487d392c0eedcc36..e9e60db17c687ad972bbe0eb33db695e95eec51e 100644
--- a/servers/slapd/connection.c
+++ b/servers/slapd/connection.c
@@ -653,7 +653,7 @@ void connection2anonymous( Connection *c )
static void
connection_destroy( Connection *c )
{
- ber_socket_t sd;
+ ber_socket_t sd, inval = AC_SOCKET_INVALID;
unsigned long connid;
const char *close_reason;
Sockbuf *sb;
@@ -733,6 +733,7 @@ connection_destroy( Connection *c )
ber_sockbuf_ctrl( sb, LBER_SB_OPT_GET_FD, &sd );
slapd_sd_lock();
+ ber_sockbuf_ctrl( sb, LBER_SB_OPT_SET_FD, &inval );
ber_sockbuf_free( sb );
/* c must be fully reset by this point; when we call slapd_remove
@@ -919,6 +920,17 @@ Connection* connection_next( Connection *c, ber_socket_t *index )
if( connections[*index].c_struct_state == SLAP_C_USED ) {
assert( connections[*index].c_conn_state != SLAP_C_INVALID );
c = &connections[(*index)++];
+ if ( ldap_pvt_thread_mutex_trylock( &c->c_mutex )) {
+ /* avoid deadlock */
+ ldap_pvt_thread_mutex_unlock( &connections_mutex );
+ ldap_pvt_thread_mutex_lock( &c->c_mutex );
+ ldap_pvt_thread_mutex_lock( &connections_mutex );
+ if ( c->c_struct_state != SLAP_C_USED ) {
+ ldap_pvt_thread_mutex_unlock( &c->c_mutex );
+ c = NULL;
+ continue;
+ }
+ }
break;
}
@@ -926,7 +938,6 @@ Connection* connection_next( Connection *c, ber_socket_t *index )
assert( connections[*index].c_conn_state == SLAP_C_INVALID );
}
- if( c != NULL ) ldap_pvt_thread_mutex_lock( &c->c_mutex );
ldap_pvt_thread_mutex_unlock( &connections_mutex );
return c;
}
@@ -972,7 +983,7 @@ void connection_done( Connection *c )
/*
* NOTE: keep in sync with enum in slapd.h
*/
-static int (*opfun[])( Operation *op, SlapReply *rs ) = {
+static BI_op_func *opfun[] = {
do_bind,
do_unbind,
do_add,
@@ -1208,6 +1219,7 @@ void connection_client_stop(
ber_socket_t s )
{
Connection *c;
+ ber_socket_t inval = AC_SOCKET_INVALID;
/* get (locked) connection */
c = connection_get( s );
@@ -1219,6 +1231,7 @@ void connection_client_stop(
c->c_struct_state = SLAP_C_UNUSED;
c->c_close_reason = "?"; /* should never be needed */
slapd_sd_lock();
+ ber_sockbuf_ctrl( c->c_sb, LBER_SB_OPT_SET_FD, &inval );
ber_sockbuf_free( c->c_sb );
slapd_remove( s, 0, 1, 1 );
c->c_sb = ber_sockbuf_alloc( );
diff --git a/servers/slapd/ctxcsn.c b/servers/slapd/ctxcsn.c
index d00eff2bfc7eca5867188098f9c3ee5f3d0e0339..a018d471191d86b218a7540d883e340608b67f55 100644
--- a/servers/slapd/ctxcsn.c
+++ b/servers/slapd/ctxcsn.c
@@ -32,8 +32,7 @@ const struct berval slap_ldapsync_cn_bv = BER_BVC("cn=ldapsync");
void
slap_get_commit_csn(
Operation *op,
- struct berval *maxcsn,
- struct berval *curcsn
+ struct berval *maxcsn
)
{
struct slap_csn_entry *csne, *committed_csne = NULL;
@@ -46,7 +45,6 @@ slap_get_commit_csn(
LDAP_TAILQ_FOREACH( csne, op->o_bd->be_pending_csn_list, ce_csn_link ) {
if ( csne->ce_opid == op->o_opid && csne->ce_connid == op->o_connid ) {
- if ( curcsn ) *curcsn = csne->ce_csn;
csne->ce_state = SLAP_CSN_COMMIT;
break;
}
diff --git a/servers/slapd/daemon.c b/servers/slapd/daemon.c
index 03559d6288a9742454d5ef0068c8ea5b350f3b56..b84d7c5caaee3ac9f14f98749228577abb613dcb 100644
--- a/servers/slapd/daemon.c
+++ b/servers/slapd/daemon.c
@@ -339,7 +339,7 @@ static struct slap_daemon {
static char** slapd_srvurls = NULL;
static SLPHandle slapd_hslp = 0;
int slapd_register_slp = 0;
-char *slapd_slp_attrs = NULL;
+const char *slapd_slp_attrs = NULL;
static SLPError slapd_slp_cookie;
@@ -527,6 +527,8 @@ void slapd_remove(
SLAP_DEL_SOCK(s);
+ tcp_close(s);
+
/* If we ran out of file descriptors, we dropped a listener from
* the select() loop. Now that we're removing a session from our
* control, we can try to resume a dropped listener to use.
diff --git a/servers/slapd/dn.c b/servers/slapd/dn.c
index be7b0aea0fa6d5c72cb7d1448a75125c0da4389c..487890ef6a7ea1d8138f2de190d2639730628e9b 100644
--- a/servers/slapd/dn.c
+++ b/servers/slapd/dn.c
@@ -1412,7 +1412,8 @@ dnX509normalize( void *x509_name, struct berval *out )
int rc = ldap_X509dn2bv( x509_name, out, LDAPDN_rewrite, 0 );
Debug( LDAP_DEBUG_TRACE,
- "dnX509Normalize: <%s>\n", out->bv_val, 0, 0 );
+ "dnX509Normalize: <%s> (%d)\n",
+ BER_BVISNULL( out ) ? "(null)" : out->bv_val, rc, 0 );
return rc;
}
diff --git a/servers/slapd/extended.c b/servers/slapd/extended.c
index 27e7ffd1ab1fad12936d797a2ebb1866c0a5c742..60c50b07290d0d5d2816909ab5e35fca593ebc1d 100644
--- a/servers/slapd/extended.c
+++ b/servers/slapd/extended.c
@@ -39,8 +39,6 @@
#include "slap.h"
#include "lber_pvt.h"
-#define UNSUPPORTED_EXOP "unsupported extended operation"
-
static struct extop_list {
struct extop_list *next;
struct berval oid;
@@ -261,11 +259,15 @@ load_extop2(
return -1;
}
- if ( ext_oid == NULL || BER_BVISNULL( ext_oid ) || BER_BVISEMPTY( ext_oid ) ) {
+ if ( ext_oid == NULL || BER_BVISNULL( ext_oid ) ||
+ BER_BVISEMPTY( ext_oid ) )
+ {
return -1;
}
- if ( numericoidValidate( NULL, (struct berval *)ext_oid ) != LDAP_SUCCESS ) {
+ if ( numericoidValidate( NULL, (struct berval *)ext_oid ) !=
+ LDAP_SUCCESS )
+ {
oidm.bv_val = oidm_find( ext_oid->bv_val );
if ( ext_oid == NULL ) {
return -1;
diff --git a/servers/slapd/ldapsync.c b/servers/slapd/ldapsync.c
index 7d9b9cf20e76bc1f7319cfdaa262973f8787c4c1..693bf7c7e38b46abe777d51c73a31dd1fe48cfd1 100644
--- a/servers/slapd/ldapsync.c
+++ b/servers/slapd/ldapsync.c
@@ -38,24 +38,29 @@ slap_compose_sync_cookie(
int rid )
{
char cookiestr[ LDAP_LUTIL_CSNSTR_BUFSIZE + 20 ];
+ int len;
if ( BER_BVISNULL( csn )) {
if ( rid == -1 ) {
cookiestr[0] = '\0';
+ len = 0;
} else {
- snprintf( cookiestr, LDAP_LUTIL_CSNSTR_BUFSIZE + 20,
+ len = snprintf( cookiestr, LDAP_LUTIL_CSNSTR_BUFSIZE + 20,
"rid=%03d", rid );
}
} else {
- if ( rid == -1 ) {
- snprintf( cookiestr, LDAP_LUTIL_CSNSTR_BUFSIZE + 20,
- "csn=%s", csn->bv_val );
- } else {
- snprintf( cookiestr, LDAP_LUTIL_CSNSTR_BUFSIZE + 20,
- "csn=%s,rid=%03d", csn->bv_val, rid );
+ char *end = cookiestr + sizeof(cookiestr);
+ char *ptr = lutil_strcopy( cookiestr, "csn=" );
+ len = csn->bv_len;
+ if ( ptr + len >= end )
+ len = end - ptr;
+ ptr = lutil_strncopy( ptr, csn->bv_val, len );
+ if ( rid != -1 && ptr < end - STRLENOF(",rid=xxx") ) {
+ ptr += sprintf( ptr, ",rid=%03d", rid );
}
+ len = ptr - cookiestr;
}
- ber_str2bv_x( cookiestr, strlen(cookiestr), 1, cookie,
+ ber_str2bv_x( cookiestr, len, 1, cookie,
op ? op->o_tmpmemctx : NULL );
}
diff --git a/servers/slapd/limits.c b/servers/slapd/limits.c
index baa2e65feca0f79695cd0dc1c7295d9aef3dbed7..7eda28ec60e1f82da3a0e79ac39a8c0527e3b399 100644
--- a/servers/slapd/limits.c
+++ b/servers/slapd/limits.c
@@ -926,8 +926,6 @@ limits_unparse( struct slap_limits *lim, struct berval *bv, ber_len_t buflen )
break;
}
}
- if ( WHATSLEFT <= STRLENOF( " " ) ) return -1;
- *ptr++ = ' ';
bv->bv_len = ptr - bv->bv_val;
btmp.bv_val = ptr;
btmp.bv_len = 0;
@@ -947,7 +945,7 @@ limits_unparse_one( struct slap_limits_set *lim, int which, struct berval *bv, b
{
char *ptr;
- if ( !bv || !bv->bv_val ) return;
+ if ( !bv || !bv->bv_val ) return -1;
ptr = bv->bv_val;
@@ -1085,6 +1083,8 @@ t_hard:
*ptr = '\0';
bv->bv_len = ptr - bv->bv_val;
}
+
+ return 0;
}
int
diff --git a/servers/slapd/main.c b/servers/slapd/main.c
index 70f2ebe12dac1bf103cbd1c553fb73df2604672f..a62e633e388b0277b918790844aac6d26feaadd1 100644
--- a/servers/slapd/main.c
+++ b/servers/slapd/main.c
@@ -106,10 +106,6 @@ static int version = 0;
void *slap_tls_ctx;
LDAP *slap_tls_ld;
-#ifdef LOG_LOCAL4
-#define DEFAULT_SYSLOG_USER LOG_LOCAL4
-#endif /* LOG_LOCAL4 */
-
static int
slapd_opt_slp( const char *val, void *arg )
{
@@ -162,7 +158,7 @@ struct option_helper {
#if defined(LDAP_DEBUG) && defined(LDAP_SYSLOG)
#ifdef LOG_LOCAL4
-static int
+int
parse_syslog_user( const char *arg, int *syslogUser )
{
static slap_verbmasks syslogUsers[] = {
@@ -182,12 +178,12 @@ parse_syslog_user( const char *arg, int *syslogUser )
#endif /* LOG_DAEMON */
{ BER_BVNULL, 0 }
};
- int i = verb_to_mask( optarg, syslogUsers );
+ int i = verb_to_mask( arg, syslogUsers );
if ( BER_BVISNULL( &syslogUsers[ i ].word ) ) {
Debug( LDAP_DEBUG_ANY,
"unrecognized syslog user \"%s\".\n",
- optarg, 0, 0 );
+ arg, 0, 0 );
return 1;
}
@@ -197,7 +193,7 @@ parse_syslog_user( const char *arg, int *syslogUser )
}
#endif /* LOG_LOCAL4 */
-static int
+int
parse_syslog_level( const char *arg, int *levelp )
{
static slap_verbmasks str2syslog_level[] = {
@@ -352,7 +348,7 @@ int main( int argc, char **argv )
char *sandbox = NULL;
#endif
#ifdef LOG_LOCAL4
- int syslogUser = DEFAULT_SYSLOG_USER;
+ int syslogUser = SLAP_DEFAULT_SYSLOG_USER;
#endif
int g_argc = argc;
@@ -963,11 +959,8 @@ stop:
lutil_passwd_destroy();
#ifdef HAVE_TLS
- /* Setting it to itself decreases refcount, allowing it to be freed
- * when the LD is freed.
- */
if ( slap_tls_ld ) {
- ldap_pvt_tls_set_option( slap_tls_ld, LDAP_OPT_X_TLS_CTX, slap_tls_ctx );
+ SSL_CTX_free( slap_tls_ctx );
ldap_unbind( slap_tls_ld );
}
ldap_pvt_tls_destroy();
@@ -989,6 +982,9 @@ stop:
if ( urls )
ch_free( urls );
+ /* kludge, get symbols referenced */
+ tavl_free( NULL, NULL );
+
#ifdef CSRIMALLOC
mal_dumpleaktrace( leakfile );
#endif
diff --git a/servers/slapd/overlays/accesslog.c b/servers/slapd/overlays/accesslog.c
index 27cd9c9adc30753857a71470fe89fec1b4e00e0d..16400140d6c58aec71fe03cd03ee193d48c74efc 100644
--- a/servers/slapd/overlays/accesslog.c
+++ b/servers/slapd/overlays/accesslog.c
@@ -504,6 +504,8 @@ log_old_lookup( Operation *op, SlapReply *rs )
if ( rs->sr_type != REP_SEARCH) return 0;
+ if ( slapd_shutdown ) return 0;
+
if ( pd->used >= pd->slots ) {
pd->slots += PURGE_INCREMENT;
pd->dn = ch_realloc( pd->dn, pd->slots * sizeof( struct berval ));
@@ -576,7 +578,8 @@ accesslog_purge( void *ctx, void *arg )
for (i=0; i<pd.used; i++) {
op->o_req_dn = pd.dn[i];
op->o_req_ndn = pd.ndn[i];
- op->o_bd->be_delete( op, &rs );
+ if ( !slapd_shutdown )
+ op->o_bd->be_delete( op, &rs );
ch_free( pd.ndn[i].bv_val );
ch_free( pd.dn[i].bv_val );
}
@@ -605,6 +608,14 @@ log_cf_gen(ConfigArgs *c)
case SLAP_CONFIG_EMIT:
switch( c->type ) {
case LOG_DB:
+ if ( li->li_db == NULL ) {
+ snprintf( c->msg, sizeof( c->msg ),
+ "accesslog: \"logdb <suffix>\" must be specified" );
+ Debug( LDAP_DEBUG_ANY, "%s: %s \"%s\"\n",
+ c->log, c->msg, c->value_dn.bv_val );
+ rc = 1;
+ break;
+ }
value_add( &c->rvalue_vals, li->li_db->be_suffix );
value_add( &c->rvalue_nvals, li->li_db->be_nsuffix );
break;
@@ -612,6 +623,10 @@ log_cf_gen(ConfigArgs *c)
rc = mask_to_verbs( logops, li->li_ops, &c->rvalue_vals );
break;
case LOG_PURGE:
+ if ( !li->li_age ) {
+ rc = 1;
+ break;
+ }
agebv.bv_val = agebuf;
log_age_unparse( li->li_age, &agebv );
agebv.bv_val[agebv.bv_len] = ' ';
@@ -690,7 +705,7 @@ log_cf_gen(ConfigArgs *c)
ch_free( la );
}
} else {
- log_attr *la, **lp;
+ log_attr *la = NULL, **lp;
int i;
for ( lp = &li->li_oldattrs, i=0; i < c->valx; i++ ) {
@@ -708,7 +723,15 @@ log_cf_gen(ConfigArgs *c)
case LOG_DB:
li->li_db = select_backend( &c->value_ndn, 0, 0 );
if ( !li->li_db ) {
- sprintf( c->msg, "<%s> no matching backend found for suffix",
+ snprintf( c->msg, sizeof( c->msg ),
+ "<%s> no matching backend found for suffix",
+ c->argv[0] );
+ Debug( LDAP_DEBUG_ANY, "%s: %s \"%s\"\n",
+ c->log, c->msg, c->value_dn.bv_val );
+ rc = 1;
+ } else if ( BER_BVISEMPTY( &li->li_db->be_rootdn )) {
+ snprintf( c->msg, sizeof( c->msg ),
+ "<%s> no rootDN was configured for suffix",
c->argv[0] );
Debug( LDAP_DEBUG_ANY, "%s: %s \"%s\"\n",
c->log, c->msg, c->value_dn.bv_val );
@@ -724,11 +747,11 @@ log_cf_gen(ConfigArgs *c)
break;
case LOG_PURGE:
li->li_age = log_age_parse( c->argv[1] );
- if ( li->li_age == -1 ) {
+ if ( li->li_age < 1 ) {
rc = 1;
} else {
li->li_cycle = log_age_parse( c->argv[2] );
- if ( li->li_cycle == -1 ) {
+ if ( li->li_cycle < 1 ) {
rc = 1;
} else if ( slapMode & SLAP_SERVER_MODE ) {
struct re_s *re = li->li_task;
@@ -1426,6 +1449,13 @@ accesslog_db_open(
int rc;
void *thrctx;
+ if ( li->li_db == NULL ) {
+ Debug( LDAP_DEBUG_ANY,
+ "accesslog: \"logdb <suffix>\" must be specified.\n",
+ 0, 0, 0 );
+ return 1;
+ }
+
if ( slapMode & SLAP_TOOL_MODE )
return 0;
diff --git a/servers/slapd/overlays/auditlog.c b/servers/slapd/overlays/auditlog.c
index f603c1429eec0c65c71d3606307a8456ed15a8b4..56f349bee29b123a0654140b2ac4c7d6cfcc4a41 100644
--- a/servers/slapd/overlays/auditlog.c
+++ b/servers/slapd/overlays/auditlog.c
@@ -29,6 +29,7 @@
#include <ac/ctype.h>
#include "slap.h"
+#include "config.h"
#include "ldif.h"
typedef struct auditlog_data {
@@ -36,6 +37,26 @@ typedef struct auditlog_data {
char *ad_logfile;
} auditlog_data;
+static ConfigTable auditlogcfg[] = {
+ { "auditlog", "filename", 2, 2, 0,
+ ARG_STRING|ARG_OFFSET,
+ (void *)offsetof(auditlog_data, ad_logfile),
+ "( OLcfgOvAt:15.1 NAME 'olcAuditlogFile' "
+ "DESC 'Filename for auditlogging' "
+ "SYNTAX OMsDirectoryString )", NULL, NULL },
+ { NULL, NULL, 0, 0, 0, ARG_IGNORED }
+};
+
+static ConfigOCs auditlogocs[] = {
+ { "( OLcfgOvOc:15.1 "
+ "NAME 'olcAuditlogConfig' "
+ "DESC 'Auditlog configuration' "
+ "SUP olcOverlayConfig "
+ "MAY ( olcAuditlogFile ) )",
+ Cft_Overlay, auditlogcfg },
+ { NULL, 0, NULL }
+};
+
static int fprint_ldif(FILE *f, char *name, char *val, ber_len_t len) {
char *s;
if((s = ldif_put(LDIF_PUT_VALUE, name, val, len)) == NULL)
@@ -107,9 +128,9 @@ static int auditlog_response(Operation *op, SlapReply *rs) {
fprintf(f, "# %s %ld %s%s%s\n",
what, stamp, suffix, who ? " " : "", who ? who->bv_val : "");
- if ( !who || !dn_match( who, &op->o_conn->c_dn ))
- fprintf(f, "# realdn: %s\n", op->o_conn->c_dn.bv_val ? op->o_conn->c_dn.bv_val :
- "<empty>" );
+ if ( !BER_BVISEMPTY( &op->o_conn->c_dn ) &&
+ (!who || !dn_match( who, &op->o_conn->c_dn )))
+ fprintf(f, "# realdn: %s\n", op->o_conn->c_dn.bv_val );
fprintf(f, "dn: %s\nchangetype: %s\n",
op->o_req_dn.bv_val, what);
@@ -167,7 +188,7 @@ auditlog_db_init(
)
{
slap_overinst *on = (slap_overinst *)be->bd_info;
- auditlog_data *ad = ch_malloc(sizeof(auditlog_data));
+ auditlog_data *ad = ch_calloc(1, sizeof(auditlog_data));
on->on_bi.bi_private = ad;
ldap_pvt_thread_mutex_init( &ad->ad_mutex );
@@ -227,14 +248,18 @@ auditlog_config(
}
int auditlog_initialize() {
+ int rc;
auditlog.on_bi.bi_type = "auditlog";
auditlog.on_bi.bi_db_init = auditlog_db_init;
- auditlog.on_bi.bi_db_config = auditlog_config;
auditlog.on_bi.bi_db_close = auditlog_db_close;
auditlog.on_bi.bi_db_destroy = auditlog_db_destroy;
auditlog.on_response = auditlog_response;
+ auditlog.on_bi.bi_cf_ocs = auditlogocs;
+ rc = config_register_schema( auditlogcfg, auditlogocs );
+ if ( rc ) return rc;
+
return overlay_register(&auditlog);
}
diff --git a/servers/slapd/overlays/constraint.c b/servers/slapd/overlays/constraint.c
index 18a3078077b14dfa7aceccc9429767240d6e36db..7f33dd1cb3f63570ba1f81dfd00fc86a6609805f 100644
--- a/servers/slapd/overlays/constraint.c
+++ b/servers/slapd/overlays/constraint.c
@@ -26,6 +26,7 @@
#include <ac/regex.h>
#include "slap.h"
+#include "config.h"
/*
* This overlay limits the values which can be placed into an
@@ -35,6 +36,8 @@
* control the add and modify value mods of a modify)
*/
+#define REGEX_STR "regex"
+
/*
* Linked list of attribute constraints which we should enforce.
* This is probably a sub optimal structure - some form of sorted
@@ -42,12 +45,179 @@
* likely to be much bigger than 4 or 5. We stick with a list for
* the moment.
*/
+
typedef struct constraint {
struct constraint *ap_next;
AttributeDescription *ap;
regex_t *re;
+ char *re_str; /* string representation of regex */
} constraint;
+enum {
+ CONSTRAINT_ATTRIBUTE = 1
+};
+
+static ConfigDriver constraint_cf_gen;
+
+static ConfigTable constraintcfg[] = {
+ { "constraint_attribute", "attribute regex <regular expression>",
+ 4, 4, 0, ARG_MAGIC | CONSTRAINT_ATTRIBUTE, constraint_cf_gen,
+ "( OLcfgOvAt:13.1 NAME 'olcConstraintAttribute' "
+ "DESC 'regular expression constraint for attribute' "
+ "SYNTAX OMsDirectoryString )", NULL, NULL },
+ { NULL, NULL, 0, 0, 0, ARG_IGNORED }
+};
+
+static ConfigOCs constraintocs[] = {
+ { "( OLcfgOvOc:13.1 "
+ "NAME 'olcConstraintConfig' "
+ "DESC 'Constraint overlay configuration' "
+ "SUP olcOverlayConfig "
+ "MAY ( olcConstraintAttribute ) )",
+ Cft_Overlay, constraintcfg },
+ { NULL, 0, NULL }
+};
+
+static int
+constraint_cf_gen( ConfigArgs *c )
+{
+ slap_overinst *on = (slap_overinst *)(c->bi);
+ constraint *cn = on->on_bi.bi_private, *cp;
+ struct berval bv;
+ int i, rc = 0;
+ constraint ap = { NULL, NULL, NULL }, *a2 = NULL;
+ regmatch_t rm[2];
+ const char *text = NULL;
+
+ switch ( c->op ) {
+ case SLAP_CONFIG_EMIT:
+ switch (c->type) {
+ case CONSTRAINT_ATTRIBUTE:
+ for (cp=cn; cp; cp=cp->ap_next) {
+ int len;
+ char *s;
+
+ len = cp->ap->ad_cname.bv_len +
+ strlen( REGEX_STR ) + strlen( cp->re_str) + 3;
+ s = ch_malloc(len);
+ if (!s) continue;
+ snprintf(s, len, "%s %s %s", cp->ap->ad_cname.bv_val,
+ REGEX_STR, cp->re_str);
+ bv.bv_val = s;
+ bv.bv_len = strlen(s);
+ rc = value_add_one( &c->rvalue_vals, &bv );
+ if (rc) return rc;
+ rc = value_add_one( &c->rvalue_nvals, &bv );
+ if (rc) return rc;
+ ch_free(s);
+ }
+ break;
+ default:
+ abort();
+ break;
+ }
+ break;
+ case LDAP_MOD_DELETE:
+ switch (c->type) {
+ case CONSTRAINT_ATTRIBUTE:
+ if (!cn) break; /* nothing to do */
+
+ if (c->valx < 0) {
+ /* zap all constraints */
+ while (cn) {
+ cp = cn->ap_next;
+ if (cn->re) {
+ regfree(cn->re);
+ ch_free(cn->re);
+ }
+ if (cn->re_str) ch_free(cn->re_str);
+ ch_free(cn);
+ cn = cp;
+ }
+
+ on->on_bi.bi_private = NULL;
+ } else {
+ constraint **cpp;
+
+ /* zap constraint numbered 'valx' */
+ for(i=0, cp = cn, cpp = &cn;
+ (cp) && (i<c->valx);
+ i++, cpp = &cp->ap_next, cp = *cpp);
+
+ if (cp) {
+ /* zap cp, and join cpp to cp->ap_next */
+ *cpp = cp->ap_next;
+ if (cp->re) {
+ regfree(cp->re);
+ ch_free(cp->re);
+ }
+ if (cp->re_str) ch_free(cp->re_str);
+ ch_free(cp);
+ }
+ on->on_bi.bi_private = cn;
+ }
+
+ break;
+ default:
+ abort();
+ break;
+ }
+ break;
+ case SLAP_CONFIG_ADD:
+ case LDAP_MOD_ADD:
+ switch (c->type) {
+ case CONSTRAINT_ATTRIBUTE:
+ if ( slap_str2ad( c->argv[1], &ap.ap, &text ) ) {
+ Debug( LDAP_DEBUG_CONFIG,
+ "constraint_add: <%s>: attribute description unknown %s.\n",
+ c->argv[1], text, 0 );
+ return( ARG_BAD_CONF );
+ }
+
+ if ( strcasecmp( c->argv[2], "regex" ) == 0) {
+ int err;
+
+ ap.re = ch_malloc( sizeof(regex_t) );
+ if ((err = regcomp( ap.re,
+ c->argv[3], REG_EXTENDED )) != 0) {
+ char errmsg[1024];
+
+ regerror( err, ap.re, errmsg, sizeof(errmsg) );
+ ch_free(ap.re);
+ Debug( LDAP_DEBUG_CONFIG,
+ "%s: Illegal regular expression \"%s\": Error %s\n",
+ c->argv[1], c->argv[3], errmsg);
+ ap.re = NULL;
+ return( ARG_BAD_CONF );
+ }
+ ap.re_str = ch_strdup( c->argv[3] );
+ } else {
+ Debug( LDAP_DEBUG_CONFIG,
+ "%s: Unknown constraint type: %s\n",
+ c->argv[1], c->argv[2], 0 );
+ return ( ARG_BAD_CONF );
+ }
+
+
+ a2 = ch_malloc( sizeof(constraint) );
+ a2->ap_next = on->on_bi.bi_private;
+ a2->ap = ap.ap;
+ a2->re = ap.re;
+ a2->re_str = ap.re_str;
+ on->on_bi.bi_private = a2;
+ break;
+ default:
+ abort();
+ break;
+ }
+ break;
+ default:
+ abort();
+ }
+
+ return rc;
+}
+
static int
constraint_violation( constraint *c, struct berval *bv )
{
@@ -166,75 +336,6 @@ constraint_modify( Operation *op, SlapReply *rs )
return SLAP_CB_CONTINUE;
}
-static int constraint_config(
- BackendDB *be,
- const char *fname,
- int lineno,
- int argc,
- char **argv
- )
-{
- slap_overinst *on = (slap_overinst *) be->bd_info;
- constraint ap = { NULL, NULL, NULL }, *a2 = NULL;
- regmatch_t rm[2];
-
- if ( strcasecmp( argv[0], "constraint_attribute" ) == 0 ) {
- const char *text;
-
- if ( argc != 4 ) {
- Debug( LDAP_DEBUG_ANY, "%s: line %d: "
- "wrong number of parameters in"
- "\"constraint_attribute <attribute> <constraint> <constraint_value>\" line.\n",
- fname, lineno, 0 );
- return( 1 );
- }
- if ( slap_str2ad( argv[1], &ap.ap, &text ) ) {
- Debug( LDAP_DEBUG_ANY, "%s: line %d: "
- "attribute description unknown \"constraint_attribute\" line: %s.\n",
- fname, lineno, text );
- return( 1 );
- }
-
- if ( strcasecmp( argv[2], "regex" ) == 0) {
- int err;
-
- ap.re = ch_malloc( sizeof(regex_t) );
- if ((err = regcomp( ap.re, argv[3], REG_EXTENDED )) != 0) {
- const char *fmt = "%s: line %d: Illegal regular expression \"%s\": Error %s\n";
- char errmsg[1024], *msg;
- int i, l, msgsize;
-
- msgsize = regerror( err, ap.re, errmsg, sizeof(errmsg) );
- msgsize += strlen(fmt) + strlen(argv[3]) + strlen(fname);
- for(l=lineno; l>0; l/=10, msgsize++);
- msgsize++;
-
- msg = ch_malloc( msgsize + 1 );
- snprintf( msg, msgsize, fmt, fname, lineno, argv[3], errmsg );
- ch_free(ap.re);
- Debug( LDAP_DEBUG_ANY, msg, 0, 0, 0);
- ch_free(msg);
- ap.re = NULL;
- return(1);
- }
- } else
- Debug( LDAP_DEBUG_ANY, "%s: line %d: "
- "Unknown constraint type: %s",
- fname, lineno, argv[2] );
-
-
- a2 = ch_malloc( sizeof(constraint) );
- a2->ap_next = on->on_bi.bi_private;
- a2->ap = ap.ap;
- a2->re = ap.re;
- on->on_bi.bi_private = a2;
- } else {
- return SLAP_CONF_UNKNOWN;
- }
-
- return 0;
-}
-
static int
constraint_close(
BackendDB *be
@@ -245,6 +346,7 @@ constraint_close(
for ( ap = on->on_bi.bi_private; ap; ap = a2 ) {
a2 = ap->ap_next;
+ if (ap->re_str) ch_free(ap->re_str);
if (ap->re) {
regfree( ap->re );
ch_free( ap->re );
@@ -268,12 +370,19 @@ static
#endif
int
constraint_initialize( void ) {
+ int rc;
+
constraint_ovl.on_bi.bi_type = "constraint";
- constraint_ovl.on_bi.bi_db_config = constraint_config;
constraint_ovl.on_bi.bi_db_close = constraint_close;
constraint_ovl.on_bi.bi_op_add = constraint_add;
constraint_ovl.on_bi.bi_op_modify = constraint_modify;
+ constraint_ovl.on_bi.bi_private = NULL;
+
+ constraint_ovl.on_bi.bi_cf_ocs = constraintocs;
+ rc = config_register_schema( constraintcfg, constraintocs );
+ if (rc) return rc;
+
return overlay_register( &constraint_ovl );
}
diff --git a/servers/slapd/overlays/dynlist.c b/servers/slapd/overlays/dynlist.c
index a679e16f6e53e96e4f06272ad95b5a783119ed03..47fb55584a40a66d829befdbee03fe9f82e8e8d1 100644
--- a/servers/slapd/overlays/dynlist.c
+++ b/servers/slapd/overlays/dynlist.c
@@ -24,7 +24,7 @@
#if LDAP_VENDOR_VERSION_MINOR != X && LDAP_VENDOR_VERSION_MINOR < 3
#define OL_2_2_COMPAT
-#elif defined(LDAP_DEVEL) && SLAPD_OVER_DYNGROUP != SLAPD_MOD_STATIC
+#elif SLAPD_OVER_DYNGROUP != SLAPD_MOD_STATIC
#define TAKEOVER_DYNGROUP
#endif
diff --git a/servers/slapd/overlays/pcache.c b/servers/slapd/overlays/pcache.c
index 8c3829bb733ceb66ea1e44fdfb14cc52c7a2f44a..3face5171975a5a522abe7fb8e49fccd0f89ae91 100644
--- a/servers/slapd/overlays/pcache.c
+++ b/servers/slapd/overlays/pcache.c
@@ -31,6 +31,7 @@
#include "slap.h"
#include "lutil.h"
#include "ldap_rq.h"
+#include "avl.h"
#include "config.h"
@@ -39,17 +40,26 @@
typedef struct Query_s {
Filter* filter; /* Search Filter */
- AttributeName* attrs; /* Projected attributes */
- AttributeName* save_attrs; /* original attributes, saved for response */
struct berval base; /* Search Base */
int scope; /* Search scope */
} Query;
+struct query_template_s;
+
+typedef struct Qbase_s {
+ Avlnode *scopes[4]; /* threaded AVL trees of cached queries */
+ struct berval base;
+ int queries;
+} Qbase;
+
/* struct representing a cached query */
typedef struct cached_query_s {
- Query query; /* LDAP query */
+ Filter *filter;
+ Filter *first;
+ Qbase *qbase;
+ int scope;
struct berval q_uuid; /* query identifier */
- int template_id; /* template of the query */
+ struct query_template_s *qtemp; /* template of the query */
time_t expiry_time; /* time till the query is considered valid */
struct cached_query_s *next; /* next query in the template */
struct cached_query_s *prev; /* previous query in the template */
@@ -57,42 +67,47 @@ typedef struct cached_query_s {
struct cached_query_s *lru_down; /* next query in the LRU list */
} CachedQuery;
+/*
+ * Represents a set of projected attributes.
+ */
+
+struct attr_set {
+ struct query_template_s *templates;
+ AttributeName* attrs; /* specifies the set */
+ unsigned flags;
+#define PC_CONFIGURED (0x1)
+#define PC_REFERENCED (0x2)
+#define PC_GOT_OC (0x4)
+ int count; /* number of attributes */
+};
+
/* struct representing a query template
* e.g. template string = &(cn=)(mail=)
*/
typedef struct query_template_s {
- struct berval querystr; /* Filter string corresponding to the QT */
- int attr_set_index; /* determines the projected attributes */
+ struct query_template_s *qtnext;
+ struct query_template_s *qmnext;
+ Avlnode* qbase;
CachedQuery* query; /* most recent query cached for the template */
CachedQuery* query_last; /* oldest query cached for the template */
+ ldap_pvt_thread_rdwr_t t_rwlock; /* Rd/wr lock for accessing queries in the template */
+ struct berval querystr; /* Filter string corresponding to the QT */
+ int attr_set_index; /* determines the projected attributes */
int no_of_queries; /* Total number of queries in the template */
time_t ttl; /* TTL for the queries of this template */
time_t negttl; /* TTL for negative results */
- ldap_pvt_thread_rdwr_t *t_rwlock; /* Rd/wr lock for accessing queries in the template */
+ struct attr_set t_attrs; /* filter attrs + attr_set */
} QueryTemplate;
-/*
- * Represents a set of projected attributes.
- */
-
-struct attr_set {
- unsigned flags;
-#define PC_CONFIGURED (0x1)
-#define PC_REFERENCED (0x2)
-#define PC_GOT_OC (0x4)
- AttributeName* attrs; /* specifies the set */
- int count; /* number of attributes */
-};
-
struct query_manager_s;
/* prototypes for functions for 1) query containment
* 2) query addition, 3) cache replacement
*/
-typedef CachedQuery * (QCfunc)(Operation *op, struct query_manager_s*, Query*, int );
-typedef void (AddQueryfunc)(struct query_manager_s*, Query*, int, struct berval*);
+typedef CachedQuery * (QCfunc)(Operation *op, struct query_manager_s*, Query*, QueryTemplate*);
+typedef CachedQuery * (AddQueryfunc)(Operation *op, struct query_manager_s*, Query*, QueryTemplate*, int positive);
typedef void (CRfunc)(struct query_manager_s*, struct berval * );
/* LDAP query cache */
@@ -117,7 +132,6 @@ typedef struct cache_manager_s {
unsigned long num_cached_queries; /* total number of cached queries */
unsigned long max_queries; /* upper bound on # of cached queries */
int numattrsets; /* number of attribute sets */
- int numtemplates; /* number of cacheable templates */
int cur_entries; /* current number of entries cached */
int max_entries; /* max number of entries cached */
int num_entries_limit; /* max # of entries in a cacheable query */
@@ -209,44 +223,110 @@ merge_entry(
return rc;
}
-/* compare base and scope of incoming and cached queries */
-static int base_scope_compare(
- struct berval* ndn_stored,
- struct berval* ndn_incoming,
- int scope_stored,
- int scope_incoming )
+/* Length-ordered sort on normalized DNs */
+static int pcache_dn_cmp( const void *v1, const void *v2 )
{
- struct berval pdn_incoming = BER_BVNULL;
+ const Qbase *q1 = v1, *q2 = v2;
- if (scope_stored < scope_incoming)
- return 0;
-
- if ( !dnIsSuffix(ndn_incoming, ndn_stored))
- return 0;
-
- switch(scope_stored) {
- case LDAP_SCOPE_BASE:
- return (ndn_incoming->bv_len == ndn_stored->bv_len);
+ int rc = q1->base.bv_len - q2->base.bv_len;
+ if ( rc == 0 )
+ rc = strncmp( q1->base.bv_val, q2->base.bv_val, q1->base.bv_len );
+ return rc;
+}
- case LDAP_SCOPE_ONELEVEL:
- switch(scope_incoming){
- case LDAP_SCOPE_BASE:
- dnParent(ndn_incoming, &pdn_incoming);
- return (pdn_incoming.bv_len == ndn_stored->bv_len);
+static int lex_bvcmp( struct berval *bv1, struct berval *bv2 )
+{
+ int len, dif;
+ dif = bv1->bv_len - bv2->bv_len;
+ len = bv1->bv_len;
+ if ( dif > 0 ) len -= dif;
+ len = memcmp( bv1->bv_val, bv2->bv_val, len );
+ if ( !len )
+ len = dif;
+ return len;
+}
- case LDAP_SCOPE_ONELEVEL:
- return (ndn_incoming->bv_len == ndn_stored->bv_len);
+/* compare the first value in each filter */
+static int pcache_filter_cmp( const void *v1, const void *v2 )
+{
+ const CachedQuery *q1 = v1, *q2 =v2;
+ int rc, weight1, weight2;
- default:
- return 0;
- }
- case LDAP_SCOPE_SUBTREE:
- return 1;
+ switch( q1->first->f_choice ) {
+ case LDAP_FILTER_PRESENT:
+ weight1 = 0;
+ break;
+ case LDAP_FILTER_EQUALITY:
+ case LDAP_FILTER_GE:
+ case LDAP_FILTER_LE:
+ weight1 = 1;
break;
default:
- return 0;
+ weight1 = 2;
+ }
+ switch( q2->first->f_choice ) {
+ case LDAP_FILTER_PRESENT:
+ weight2 = 0;
+ break;
+ case LDAP_FILTER_EQUALITY:
+ case LDAP_FILTER_GE:
+ case LDAP_FILTER_LE:
+ weight2 = 1;
break;
- }
+ default:
+ weight2 = 2;
+ }
+ rc = weight1 - weight2;
+ if ( !rc ) {
+ switch( weight1 ) {
+ case 0: return 0;
+ case 1:
+ rc = lex_bvcmp( &q1->first->f_av_value, &q2->first->f_av_value );
+ break;
+ case 2:
+ if ( q1->first->f_choice == LDAP_FILTER_SUBSTRINGS ) {
+ rc = 0;
+ if ( !BER_BVISNULL( &q1->first->f_sub_initial )) {
+ if ( !BER_BVISNULL( &q2->first->f_sub_initial )) {
+ rc = lex_bvcmp( &q1->first->f_sub_initial,
+ &q2->first->f_sub_initial );
+ } else {
+ rc = 1;
+ }
+ } else if ( !BER_BVISNULL( &q2->first->f_sub_initial )) {
+ rc = -1;
+ }
+ if ( rc ) break;
+ if ( q1->first->f_sub_any ) {
+ if ( q2->first->f_sub_any ) {
+ rc = lex_bvcmp( q1->first->f_sub_any,
+ q2->first->f_sub_any );
+ } else {
+ rc = 1;
+ }
+ } else if ( q2->first->f_sub_any ) {
+ rc = -1;
+ }
+ if ( rc ) break;
+ if ( !BER_BVISNULL( &q1->first->f_sub_final )) {
+ if ( !BER_BVISNULL( &q2->first->f_sub_final )) {
+ rc = lex_bvcmp( &q1->first->f_sub_final,
+ &q2->first->f_sub_final );
+ } else {
+ rc = 1;
+ }
+ } else if ( !BER_BVISNULL( &q2->first->f_sub_final )) {
+ rc = -1;
+ }
+ } else {
+ rc = lex_bvcmp( &q1->first->f_mr_value,
+ &q2->first->f_mr_value );
+ }
+ break;
+ }
+ }
+
+ return rc;
}
/* add query on top of LRU list */
@@ -254,7 +334,6 @@ static void
add_query_on_top (query_manager* qm, CachedQuery* qc)
{
CachedQuery* top = qm->lru_top;
- Query* q = (Query*)qc;
qm->lru_top = qc;
@@ -266,7 +345,7 @@ add_query_on_top (query_manager* qm, CachedQuery* qc)
qc->lru_down = top;
qc->lru_up = NULL;
Debug( pcache_debug, "Base of added query = %s\n",
- q->base.bv_val, 0, 0 );
+ qc->qbase->base.bv_val, 0, 0 );
}
/* remove_query from LRU list */
@@ -471,134 +550,253 @@ final:
return rc;
}
+static Filter *
+filter_first( Filter *f )
+{
+ while ( f->f_choice == LDAP_FILTER_OR || f->f_choice == LDAP_FILTER_AND )
+ f = f->f_and;
+ return f;
+}
+
+
+static CachedQuery *
+find_filter( Operation *op, Avlnode *root, Filter *inputf, Filter *first )
+{
+ Filter* fs;
+ Filter* fi;
+ MatchingRule* mrule = NULL;
+ int res=0, eqpass= 0;
+ int ret, rc, dir;
+ Avlnode *ptr;
+ CachedQuery cq, *qc;
+
+ cq.filter = inputf;
+ cq.first = first;
+
+ /* substring matches sort to the end, and we just have to
+ * walk the entire list.
+ */
+ if ( first->f_choice == LDAP_FILTER_SUBSTRINGS ) {
+ ptr = tavl_end( root, 1 );
+ dir = TAVL_DIR_LEFT;
+ } else {
+ ptr = tavl_find3( root, &cq, pcache_filter_cmp, &ret );
+ dir = (first->f_choice == LDAP_FILTER_GE) ? TAVL_DIR_LEFT :
+ TAVL_DIR_RIGHT;
+ }
+
+ while (ptr) {
+ qc = ptr->avl_data;
+ fi = inputf;
+ fs = qc->filter;
+
+ /* an incoming substr query can only be satisfied by a cached
+ * substr query.
+ */
+ if ( first->f_choice == LDAP_FILTER_SUBSTRINGS &&
+ qc->first->f_choice != LDAP_FILTER_SUBSTRINGS )
+ break;
+
+ /* an incoming eq query can be satisfied by a cached eq or substr
+ * query
+ */
+ if ( first->f_choice == LDAP_FILTER_EQUALITY ) {
+ if ( eqpass == 0 ) {
+ if ( qc->first->f_choice != LDAP_FILTER_EQUALITY ) {
+nextpass: eqpass = 1;
+ ptr = tavl_end( root, 1 );
+ dir = TAVL_DIR_LEFT;
+ continue;
+ }
+ } else {
+ if ( qc->first->f_choice != LDAP_FILTER_SUBSTRINGS )
+ break;
+ }
+ }
+ do {
+ res=0;
+ switch (fs->f_choice) {
+ case LDAP_FILTER_EQUALITY:
+ if (fi->f_choice == LDAP_FILTER_EQUALITY)
+ mrule = fs->f_ava->aa_desc->ad_type->sat_equality;
+ else
+ ret = 1;
+ break;
+ case LDAP_FILTER_GE:
+ case LDAP_FILTER_LE:
+ mrule = fs->f_ava->aa_desc->ad_type->sat_ordering;
+ break;
+ default:
+ mrule = NULL;
+ }
+ if (mrule) {
+ const char *text;
+ rc = value_match(&ret, fs->f_ava->aa_desc, mrule,
+ SLAP_MR_VALUE_OF_ASSERTION_SYNTAX,
+ &(fi->f_ava->aa_value),
+ &(fs->f_ava->aa_value), &text);
+ if (rc != LDAP_SUCCESS) {
+ return NULL;
+ }
+ if ( fi==first && fi->f_choice==LDAP_FILTER_EQUALITY && ret )
+ goto nextpass;
+ }
+ switch (fs->f_choice) {
+ case LDAP_FILTER_OR:
+ case LDAP_FILTER_AND:
+ fs = fs->f_and;
+ fi = fi->f_and;
+ res=1;
+ break;
+ case LDAP_FILTER_SUBSTRINGS:
+ /* check if the equality query can be
+ * answered with cached substring query */
+ if ((fi->f_choice == LDAP_FILTER_EQUALITY)
+ && substr_containment_equality( op,
+ fs, fi))
+ res=1;
+ /* check if the substring query can be
+ * answered with cached substring query */
+ if ((fi->f_choice ==LDAP_FILTER_SUBSTRINGS
+ ) && substr_containment_substr( op,
+ fs, fi))
+ res= 1;
+ fs=fs->f_next;
+ fi=fi->f_next;
+ break;
+ case LDAP_FILTER_PRESENT:
+ res=1;
+ fs=fs->f_next;
+ fi=fi->f_next;
+ break;
+ case LDAP_FILTER_EQUALITY:
+ if (ret == 0)
+ res = 1;
+ fs=fs->f_next;
+ fi=fi->f_next;
+ break;
+ case LDAP_FILTER_GE:
+ if (mrule && ret >= 0)
+ res = 1;
+ fs=fs->f_next;
+ fi=fi->f_next;
+ break;
+ case LDAP_FILTER_LE:
+ if (mrule && ret <= 0)
+ res = 1;
+ fs=fs->f_next;
+ fi=fi->f_next;
+ break;
+ case LDAP_FILTER_NOT:
+ res=0;
+ break;
+ default:
+ break;
+ }
+ } while((res) && (fi != NULL) && (fs != NULL));
+
+ if ( res )
+ return qc;
+ ptr = tavl_next( ptr, dir );
+ }
+ return NULL;
+}
+
/* check whether query is contained in any of
- * the cached queries in template template_index
+ * the cached queries in template
*/
static CachedQuery *
query_containment(Operation *op, query_manager *qm,
Query *query,
- int template_index)
+ QueryTemplate *templa)
{
- QueryTemplate* templa= qm->templates;
CachedQuery* qc;
- Query* q;
- Filter* inputf = query->filter;
- struct berval* base = &(query->base);
- int scope = query->scope;
- int res=0;
- Filter* fs;
- Filter* fi;
- int ret, rc;
- const char* text;
-
- MatchingRule* mrule = NULL;
- if (inputf != NULL) {
- Debug( pcache_debug, "Lock QC index = %d\n",
- template_index, 0, 0 );
- ldap_pvt_thread_rdwr_rlock(templa[template_index].t_rwlock);
- for(qc=templa[template_index].query; qc != NULL; qc= qc->next) {
- q = (Query*)qc;
- if(base_scope_compare(&(q->base), base, q->scope, scope)) {
- fi = inputf;
- fs = q->filter;
- do {
- res=0;
- switch (fs->f_choice) {
- case LDAP_FILTER_EQUALITY:
- if (fi->f_choice == LDAP_FILTER_EQUALITY)
- mrule = fs->f_ava->aa_desc->ad_type->sat_equality;
- else
- ret = 1;
+ int depth = 0, tscope;
+ Qbase qbase, *qbptr = NULL;
+ struct berval pdn;
+
+ if (query->filter != NULL) {
+ Filter *first;
+
+ Debug( pcache_debug, "Lock QC index = %p\n",
+ (void *) templa, 0, 0 );
+ qbase.base = query->base;
+
+ first = filter_first( query->filter );
+
+ ldap_pvt_thread_rdwr_rlock(&templa->t_rwlock);
+ for( ;; ) {
+ /* Find the base */
+ qbptr = avl_find( templa->qbase, &qbase, pcache_dn_cmp );
+ if ( qbptr ) {
+ tscope = query->scope;
+ /* Find a matching scope:
+ * match at depth 0 OK
+ * scope is BASE,
+ * one at depth 1 OK
+ * subord at depth > 0 OK
+ * subtree at any depth OK
+ * scope is ONE,
+ * subtree or subord at any depth OK
+ * scope is SUBORD,
+ * subtree or subord at any depth OK
+ * scope is SUBTREE,
+ * subord at depth > 0 OK
+ * subtree at any depth OK
+ */
+ for ( tscope = 0 ; tscope <= LDAP_SCOPE_CHILDREN; tscope++ ) {
+ switch ( query->scope ) {
+ case LDAP_SCOPE_BASE:
+ if ( tscope == LDAP_SCOPE_BASE && depth ) continue;
+ if ( tscope == LDAP_SCOPE_ONE && depth != 1) continue;
+ if ( tscope == LDAP_SCOPE_CHILDREN && !depth ) continue;
break;
- case LDAP_FILTER_GE:
- case LDAP_FILTER_LE:
- mrule = fs->f_ava->aa_desc->ad_type->sat_ordering;
+ case LDAP_SCOPE_ONE:
+ if ( tscope == LDAP_SCOPE_BASE )
+ tscope = LDAP_SCOPE_ONE;
+ if ( tscope == LDAP_SCOPE_ONE && depth ) continue;
+ if ( !depth ) break;
+ if ( tscope < LDAP_SCOPE_SUBTREE )
+ tscope = LDAP_SCOPE_SUBTREE;
break;
- default:
- mrule = NULL;
- }
- if (mrule) {
- rc = value_match(&ret, fs->f_ava->aa_desc, mrule,
- SLAP_MR_VALUE_OF_ASSERTION_SYNTAX,
- &(fi->f_ava->aa_value),
- &(fs->f_ava->aa_value), &text);
- if (rc != LDAP_SUCCESS) {
- ldap_pvt_thread_rdwr_runlock(templa[template_index].t_rwlock);
- Debug( pcache_debug,
- "Unlock: Exiting QC index=%d\n",
- template_index, 0, 0 );
- return NULL;
- }
- }
- switch (fs->f_choice) {
- case LDAP_FILTER_OR:
- case LDAP_FILTER_AND:
- fs = fs->f_and;
- fi = fi->f_and;
- res=1;
- break;
- case LDAP_FILTER_SUBSTRINGS:
- /* check if the equality query can be
- * answered with cached substring query */
- if ((fi->f_choice == LDAP_FILTER_EQUALITY)
- && substr_containment_equality( op,
- fs, fi))
- res=1;
- /* check if the substring query can be
- * answered with cached substring query */
- if ((fi->f_choice ==LDAP_FILTER_SUBSTRINGS
- ) && substr_containment_substr( op,
- fs, fi))
- res= 1;
- fs=fs->f_next;
- fi=fi->f_next;
- break;
- case LDAP_FILTER_PRESENT:
- res=1;
- fs=fs->f_next;
- fi=fi->f_next;
+ case LDAP_SCOPE_SUBTREE:
+ if ( tscope < LDAP_SCOPE_SUBTREE )
+ tscope = LDAP_SCOPE_SUBTREE;
+ if ( tscope == LDAP_SCOPE_CHILDREN && !depth ) continue;
break;
- case LDAP_FILTER_EQUALITY:
- if (ret == 0)
- res = 1;
- fs=fs->f_next;
- fi=fi->f_next;
- break;
- case LDAP_FILTER_GE:
- if (mrule && ret >= 0)
- res = 1;
- fs=fs->f_next;
- fi=fi->f_next;
- break;
- case LDAP_FILTER_LE:
- if (mrule && ret <= 0)
- res = 1;
- fs=fs->f_next;
- fi=fi->f_next;
- break;
- case LDAP_FILTER_NOT:
- res=0;
- break;
- default:
+ case LDAP_SCOPE_CHILDREN:
+ if ( tscope < LDAP_SCOPE_SUBTREE )
+ tscope = LDAP_SCOPE_SUBTREE;
break;
}
- } while((res) && (fi != NULL) && (fs != NULL));
-
- if(res) {
- ldap_pvt_thread_mutex_lock(&qm->lru_mutex);
- if (qm->lru_top != qc) {
- remove_query(qm, qc);
- add_query_on_top(qm, qc);
+ if ( !qbptr->scopes[tscope] ) continue;
+
+ /* Find filter */
+ qc = find_filter( op, qbptr->scopes[tscope],
+ query->filter, first );
+ if ( qc ) {
+ ldap_pvt_thread_mutex_lock(&qm->lru_mutex);
+ if (qm->lru_top != qc) {
+ remove_query(qm, qc);
+ add_query_on_top(qm, qc);
+ }
+ ldap_pvt_thread_mutex_unlock(&qm->lru_mutex);
+ return qc;
}
- ldap_pvt_thread_mutex_unlock(&qm->lru_mutex);
- return qc;
}
}
+ if ( be_issuffix( op->o_bd, &qbase.base ))
+ break;
+ /* Up a level */
+ dnParent( &qbase.base, &pdn );
+ qbase.base = pdn;
+ depth++;
}
+
Debug( pcache_debug,
- "Not answerable: Unlock QC index=%d\n",
- template_index, 0, 0 );
- ldap_pvt_thread_rdwr_runlock(templa[template_index].t_rwlock);
+ "Not answerable: Unlock QC index=%p\n",
+ (void *) templa, 0, 0 );
+ ldap_pvt_thread_rdwr_runlock(&templa->t_rwlock);
}
return NULL;
}
@@ -606,68 +804,89 @@ query_containment(Operation *op, query_manager *qm,
static void
free_query (CachedQuery* qc)
{
- Query* q = (Query*)qc;
-
free(qc->q_uuid.bv_val);
- filter_free(q->filter);
- free (q->base.bv_val);
- free(q->attrs);
+ filter_free(qc->filter);
free(qc);
}
/* Add query to query cache */
-static void add_query(
+static CachedQuery * add_query(
+ Operation *op,
query_manager* qm,
Query* query,
- int template_index,
- struct berval* uuid)
+ QueryTemplate *templ,
+ int positive)
{
CachedQuery* new_cached_query = (CachedQuery*) ch_malloc(sizeof(CachedQuery));
- QueryTemplate* templ = (qm->templates)+template_index;
- Query* new_query;
- new_cached_query->template_id = template_index;
- if ( uuid ) {
- new_cached_query->q_uuid = *uuid;
+ Qbase *qbase, qb;
+ Filter *first;
+ int rc;
+
+ new_cached_query->qtemp = templ;
+ BER_BVZERO( &new_cached_query->q_uuid );
+ if ( positive ) {
new_cached_query->expiry_time = slap_get_time() + templ->ttl;
} else {
- BER_BVZERO( &new_cached_query->q_uuid );
new_cached_query->expiry_time = slap_get_time() + templ->negttl;
}
new_cached_query->lru_up = NULL;
new_cached_query->lru_down = NULL;
Debug( pcache_debug, "Added query expires at %ld\n",
(long) new_cached_query->expiry_time, 0, 0 );
- new_query = (Query*)new_cached_query;
- ber_dupbv(&new_query->base, &query->base);
- new_query->scope = query->scope;
- new_query->filter = query->filter;
- new_query->attrs = query->attrs;
+ new_cached_query->scope = query->scope;
+ new_cached_query->filter = query->filter;
+ new_cached_query->first = first = filter_first( query->filter );
+
+ qb.base = query->base;
/* Adding a query */
- Debug( pcache_debug, "Lock AQ index = %d\n",
- template_index, 0, 0 );
- ldap_pvt_thread_rdwr_wlock(templ->t_rwlock);
- if (templ->query == NULL)
- templ->query_last = new_cached_query;
- else
- templ->query->prev = new_cached_query;
+ Debug( pcache_debug, "Lock AQ index = %p\n",
+ (void *) templ, 0, 0 );
+ ldap_pvt_thread_rdwr_wlock(&templ->t_rwlock);
+ qbase = avl_find( templ->qbase, &qb, pcache_dn_cmp );
+ if ( !qbase ) {
+ qbase = ch_calloc( 1, sizeof(Qbase) + qb.base.bv_len + 1 );
+ qbase->base.bv_len =qb.base.bv_len;
+ qbase->base.bv_val = (char *)(qbase+1);
+ memcpy( qbase->base.bv_val, qb.base.bv_val, qb.base.bv_len );
+ qbase->base.bv_val[qbase->base.bv_len] = '\0';
+ avl_insert( &templ->qbase, qbase, pcache_dn_cmp, avl_dup_error );
+ }
new_cached_query->next = templ->query;
new_cached_query->prev = NULL;
- templ->query = new_cached_query;
- templ->no_of_queries++;
- Debug( pcache_debug, "TEMPLATE %d QUERIES++ %d\n",
- template_index, templ->no_of_queries, 0 );
+ new_cached_query->qbase = qbase;
+ rc = tavl_insert( &qbase->scopes[query->scope], new_cached_query,
+ pcache_filter_cmp, avl_dup_error );
+ if ( rc == 0 ) {
+ qbase->queries++;
+ if (templ->query == NULL)
+ templ->query_last = new_cached_query;
+ else
+ templ->query->prev = new_cached_query;
+ templ->query = new_cached_query;
+ templ->no_of_queries++;
+ } else {
+ ch_free( new_cached_query );
+ new_cached_query = find_filter( op, qbase->scopes[query->scope],
+ query->filter, first );
+ filter_free( query->filter );
+ }
+ Debug( pcache_debug, "TEMPLATE %p QUERIES++ %d\n",
+ (void *) templ, templ->no_of_queries, 0 );
- Debug( pcache_debug, "Unlock AQ index = %d \n",
- template_index, 0, 0 );
- ldap_pvt_thread_rdwr_wunlock(templ->t_rwlock);
+ Debug( pcache_debug, "Unlock AQ index = %p \n",
+ (void *) templ, 0, 0 );
+ ldap_pvt_thread_rdwr_wunlock(&templ->t_rwlock);
/* Adding on top of LRU list */
- ldap_pvt_thread_mutex_lock(&qm->lru_mutex);
- add_query_on_top(qm, new_cached_query);
- ldap_pvt_thread_mutex_unlock(&qm->lru_mutex);
+ if ( rc == 0 ) {
+ ldap_pvt_thread_mutex_lock(&qm->lru_mutex);
+ add_query_on_top(qm, new_cached_query);
+ ldap_pvt_thread_mutex_unlock(&qm->lru_mutex);
+ }
+ return rc == 0 ? new_cached_query : NULL;
}
static void
@@ -685,6 +904,13 @@ remove_from_template (CachedQuery* qc, QueryTemplate* template)
qc->next->prev = qc->prev;
qc->prev->next = qc->next;
}
+ tavl_delete( &qc->qbase->scopes[qc->scope], qc, pcache_filter_cmp );
+ qc->qbase->queries--;
+ if ( qc->qbase->queries == 0 ) {
+ avl_delete( &template->qbase, qc->qbase, pcache_dn_cmp );
+ ch_free( qc->qbase );
+ qc->qbase = NULL;
+ }
template->no_of_queries--;
}
@@ -693,7 +919,7 @@ remove_from_template (CachedQuery* qc, QueryTemplate* template)
static void cache_replacement(query_manager* qm, struct berval *result)
{
CachedQuery* bottom;
- int temp_id;
+ QueryTemplate *temp;
ldap_pvt_thread_mutex_lock(&qm->lru_mutex);
bottom = qm->lru_bottom;
@@ -709,20 +935,20 @@ static void cache_replacement(query_manager* qm, struct berval *result)
return;
}
- temp_id = bottom->template_id;
+ temp = bottom->qtemp;
remove_query(qm, bottom);
ldap_pvt_thread_mutex_unlock(&qm->lru_mutex);
*result = bottom->q_uuid;
bottom->q_uuid.bv_val = NULL;
- Debug( pcache_debug, "Lock CR index = %d\n", temp_id, 0, 0 );
- ldap_pvt_thread_rdwr_wlock(qm->templates[temp_id].t_rwlock);
- remove_from_template(bottom, (qm->templates+temp_id));
- Debug( pcache_debug, "TEMPLATE %d QUERIES-- %d\n",
- temp_id, qm->templates[temp_id].no_of_queries, 0 );
- Debug( pcache_debug, "Unlock CR index = %d\n", temp_id, 0, 0 );
- ldap_pvt_thread_rdwr_wunlock(qm->templates[temp_id].t_rwlock);
+ Debug( pcache_debug, "Lock CR index = %p\n", (void *) temp, 0, 0 );
+ ldap_pvt_thread_rdwr_wlock(&temp->t_rwlock);
+ remove_from_template(bottom, temp);
+ Debug( pcache_debug, "TEMPLATE %p QUERIES-- %d\n",
+ (void *) temp, temp->no_of_queries, 0 );
+ Debug( pcache_debug, "Unlock CR index = %p\n", (void *) temp, 0, 0 );
+ ldap_pvt_thread_rdwr_wunlock(&temp->t_rwlock);
free_query(bottom);
}
@@ -948,7 +1174,8 @@ filter2template(
struct search_info {
slap_overinst *on;
Query query;
- int template_id;
+ QueryTemplate *qtemp;
+ AttributeName* save_attrs; /* original attributes, saved for response */
int max;
int over;
int count;
@@ -1032,12 +1259,11 @@ pcache_response(
slap_overinst *on = si->on;
cache_manager *cm = on->on_bi.bi_private;
query_manager* qm = cm->qm;
- struct berval uuid;
- if ( si->query.save_attrs != NULL ) {
- rs->sr_attrs = si->query.save_attrs;
- op->ors_attrs = si->query.save_attrs;
- si->query.save_attrs = NULL;
+ if ( si->save_attrs != NULL ) {
+ rs->sr_attrs = si->save_attrs;
+ op->ors_attrs = si->save_attrs;
+ si->save_attrs = NULL;
}
if ( rs->sr_type == REP_SEARCH ) {
@@ -1066,32 +1292,42 @@ pcache_response(
}
} else if ( rs->sr_type == REP_RESULT ) {
- QueryTemplate* templ = (qm->templates)+si->template_id;
- if (( si->count && cache_entries( op, rs, &uuid ) == 0 ) ||
- ( templ->negttl && !si->count && !si->over &&
+ if ( si->count ||
+ ( si->qtemp->negttl && !si->count && !si->over &&
rs->sr_err == LDAP_SUCCESS )) {
- qm->addfunc(qm, &si->query, si->template_id,
- si->count ? &uuid : NULL);
-
- ldap_pvt_thread_mutex_lock(&cm->cache_mutex);
- cm->num_cached_queries++;
- Debug( pcache_debug, "STORED QUERIES = %lu\n",
- cm->num_cached_queries, 0, 0 );
- ldap_pvt_thread_mutex_unlock(&cm->cache_mutex);
+ CachedQuery *qc = qm->addfunc(op, qm, &si->query, si->qtemp,
+ si->count);
+
+ if ( qc != NULL ) {
+ if ( si->count )
+ cache_entries( op, rs, &qc->q_uuid );
+ ldap_pvt_thread_mutex_lock(&cm->cache_mutex);
+ cm->num_cached_queries++;
+ Debug( pcache_debug, "STORED QUERIES = %lu\n",
+ cm->num_cached_queries, 0, 0 );
+ ldap_pvt_thread_mutex_unlock(&cm->cache_mutex);
- /* If the consistency checker suspended itself,
- * wake it back up
- */
- if ( cm->cc_paused ) {
- ldap_pvt_thread_mutex_lock( &slapd_rq.rq_mutex );
+ /* If the consistency checker suspended itself,
+ * wake it back up
+ */
if ( cm->cc_paused ) {
- cm->cc_paused = 0;
- ldap_pvt_runqueue_resched( &slapd_rq, cm->cc_arg, 0 );
+ ldap_pvt_thread_mutex_lock( &slapd_rq.rq_mutex );
+ if ( cm->cc_paused ) {
+ cm->cc_paused = 0;
+ ldap_pvt_runqueue_resched( &slapd_rq, cm->cc_arg, 0 );
+ }
+ ldap_pvt_thread_mutex_unlock( &slapd_rq.rq_mutex );
+ }
+ } else if ( si->count ) {
+ /* duplicate query, free it */
+ Entry *e;
+ for (;si->head; si->head=e) {
+ e = si->head->e_private;
+ si->head->e_private = NULL;
+ entry_free(si->head);
}
- ldap_pvt_thread_mutex_unlock( &slapd_rq.rq_mutex );
}
} else {
- free( si->query.attrs );
filter_free( si->query.filter );
}
@@ -1208,9 +1444,9 @@ pcache_op_search(
AttributeName *filter_attrs = NULL;
Query query;
+ QueryTemplate *qtemp = NULL;
int attr_set = -1;
- int template_id = -1;
CachedQuery *answerable = NULL;
int cacheable = 0;
int fattr_cnt=0;
@@ -1230,31 +1466,27 @@ pcache_op_search(
tempstr.bv_val, 0, 0 );
/* FIXME: cannot cache/answer requests with pagedResults control */
-
/* find attr set */
attr_set = get_attr_set(op->ors_attrs, qm, cm->numattrsets);
query.filter = op->ors_filter;
- query.attrs = op->ors_attrs;
- query.save_attrs = NULL;
query.base = op->o_req_ndn;
query.scope = op->ors_scope;
/* check for query containment */
if (attr_set > -1) {
- QueryTemplate *qt = qm->templates;
- for (i=0; i<cm->numtemplates; i++, qt++) {
+ QueryTemplate *qt = qm->attr_sets[attr_set].templates;
+ for (; qt; qt = qt->qtnext ) {
/* find if template i can potentially answer tempstr */
- if ( qt->attr_set_index != attr_set ||
- qt->querystr.bv_len != tempstr.bv_len ||
+ if (qt->querystr.bv_len != tempstr.bv_len ||
strcasecmp( qt->querystr.bv_val, tempstr.bv_val ))
continue;
cacheable = 1;
- template_id = i;
- Debug( LDAP_DEBUG_NONE, "Entering QC, querystr = %s\n",
+ qtemp = qt;
+ Debug( pcache_debug, "Entering QC, querystr = %s\n",
op->ors_filterstr.bv_val, 0, 0 );
- answerable = (*(qm->qcfunc))(op, qm, &query, i);
+ answerable = (*(qm->qcfunc))(op, qm, &query, qt);
if (answerable)
break;
@@ -1262,9 +1494,6 @@ pcache_op_search(
}
op->o_tmpfree( tempstr.bv_val, op->o_tmpmemctx );
- query.save_attrs = op->ors_attrs;
- query.attrs = NULL;
-
if (answerable) {
/* Need to clear the callbacks of the original operation,
* in case there are other overlays */
@@ -1273,7 +1502,6 @@ pcache_op_search(
Debug( pcache_debug, "QUERY ANSWERABLE\n", 0, 0, 0 );
op->o_tmpfree( filter_attrs, op->o_tmpmemctx );
- ldap_pvt_thread_rdwr_runlock(qm->templates[i].t_rwlock);
if ( BER_BVISNULL( &answerable->q_uuid )) {
/* No entries cached, just an empty result set */
i = rs->sr_err = 0;
@@ -1283,6 +1511,7 @@ pcache_op_search(
op->o_callback = NULL;
i = cm->db.bd_info->bi_op_search( op, rs );
}
+ ldap_pvt_thread_rdwr_runlock(&qtemp->t_rwlock);
op->o_bd = save_bd;
op->o_callback = save_cb;
return i;
@@ -1305,10 +1534,13 @@ pcache_op_search(
Debug( pcache_debug, "QUERY CACHEABLE\n", 0, 0, 0 );
query.filter = filter_dup(op->ors_filter, NULL);
- add_filter_attrs(op, &query.attrs, &qm->attr_sets[attr_set],
- filter_attrs, fattr_cnt, fattr_got_oc);
-
- op->ors_attrs = query.attrs;
+ ldap_pvt_thread_rdwr_wlock(&qtemp->t_rwlock);
+ if ( !qtemp->t_attrs.count ) {
+ add_filter_attrs(op, &qtemp->t_attrs.attrs,
+ &qm->attr_sets[attr_set],
+ filter_attrs, fattr_cnt, fattr_got_oc);
+ }
+ ldap_pvt_thread_rdwr_wunlock(&qtemp->t_rwlock);
cb = op->o_tmpalloc( sizeof(*cb) + sizeof(*si), op->o_tmpmemctx);
cb->sc_response = pcache_response;
@@ -1317,12 +1549,15 @@ pcache_op_search(
si = cb->sc_private;
si->on = on;
si->query = query;
- si->template_id = template_id;
+ si->qtemp = qtemp;
si->max = cm->num_entries_limit ;
si->over = 0;
si->count = 0;
si->head = NULL;
si->tail = NULL;
+ si->save_attrs = op->ors_attrs;
+
+ op->ors_attrs = qtemp->t_attrs.attrs;
if ( cm->response_cb == PCACHE_RESPONSE_CB_HEAD ) {
cb->sc_next = op->o_callback;
@@ -1401,8 +1636,8 @@ consistency_check(
Operation *op;
SlapReply rs = {REP_RESULT};
- CachedQuery* query, *query_prev;
- int i, return_val, pause = 1;
+ CachedQuery* query;
+ int return_val, pause = 1;
QueryTemplate* templ;
op = (Operation *) &opbuf;
@@ -1414,21 +1649,28 @@ consistency_check(
cm->cc_arg = arg;
- for (i=0; qm->templates[i].querystr.bv_val; i++) {
- templ = qm->templates + i;
+ for (templ = qm->templates; templ; templ=templ->qmnext) {
query = templ->query_last;
if ( query ) pause = 0;
op->o_time = slap_get_time();
while (query && (query->expiry_time < op->o_time)) {
- Debug( pcache_debug, "Lock CR index = %d\n",
- i, 0, 0 );
- ldap_pvt_thread_rdwr_wlock(templ->t_rwlock);
- remove_from_template(query, templ);
- Debug( pcache_debug, "TEMPLATE %d QUERIES-- %d\n",
- i, templ->no_of_queries, 0 );
- Debug( pcache_debug, "Unlock CR index = %d\n",
- i, 0, 0 );
- ldap_pvt_thread_rdwr_wunlock(templ->t_rwlock);
+ int rem = 0;
+ Debug( pcache_debug, "Lock CR index = %p\n",
+ (void *) templ, 0, 0 );
+ ldap_pvt_thread_rdwr_wlock(&templ->t_rwlock);
+ if ( query == templ->query_last ) {
+ rem = 1;
+ remove_from_template(query, templ);
+ Debug( pcache_debug, "TEMPLATE %p QUERIES-- %d\n",
+ (void *) templ, templ->no_of_queries, 0 );
+ Debug( pcache_debug, "Unlock CR index = %p\n",
+ (void *) templ, 0, 0 );
+ }
+ ldap_pvt_thread_rdwr_wunlock(&templ->t_rwlock);
+ if ( !rem ) {
+ query = templ->query_last;
+ continue;
+ }
ldap_pvt_thread_mutex_lock(&qm->lru_mutex);
remove_query(qm, query);
ldap_pvt_thread_mutex_unlock(&qm->lru_mutex);
@@ -1448,9 +1690,8 @@ consistency_check(
"STALE QUERY REMOVED, CACHE ="
"%d entries\n",
cm->cur_entries, 0, 0 );
- query_prev = query;
- query = query->prev;
- free_query(query_prev);
+ free_query(query);
+ query = templ->query_last;
}
}
ldap_pvt_thread_mutex_lock( &slapd_rq.rq_mutex );
@@ -1611,23 +1852,23 @@ pc_cf_gen( ConfigArgs *c )
rc = 1;
break;
case PC_TEMP:
- for (i=0; i<cm->numtemplates; i++) {
- if ( qm->templates[i].negttl ) {
+ for (temp=qm->templates; temp; temp=temp->qmnext) {
+ if ( temp->negttl ) {
bv.bv_len = snprintf( c->msg, sizeof( c->msg ),
" %d %ld %ld",
- qm->templates[i].attr_set_index,
- qm->templates[i].ttl,
- qm->templates[i].negttl );
+ temp->attr_set_index,
+ temp->ttl,
+ temp->negttl );
} else {
bv.bv_len = snprintf( c->msg, sizeof( c->msg ), " %d %ld",
- qm->templates[i].attr_set_index,
- qm->templates[i].ttl );
+ temp->attr_set_index,
+ temp->ttl );
}
- bv.bv_len += qm->templates[i].querystr.bv_len + 2;
+ bv.bv_len += temp->querystr.bv_len + 2;
bv.bv_val = ch_malloc( bv.bv_len+1 );
ptr = bv.bv_val;
*ptr++ = '"';
- ptr = lutil_strcopy( ptr, qm->templates[i].querystr.bv_val );
+ ptr = lutil_strcopy( ptr, temp->querystr.bv_val );
*ptr++ = '"';
strcpy( ptr, c->msg );
ber_bvarray_add( &c->rvalue_vals, &bv );
@@ -1792,18 +2033,17 @@ pc_cf_gen( ConfigArgs *c )
return( 1 );
}
- if ( i < 0 || i >= cm->numattrsets ) {
+ if ( i < 0 || i >= cm->numattrsets ||
+ !(qm->attr_sets[i].flags & PC_CONFIGURED )) {
snprintf( c->msg, sizeof( c->msg ), "template index %d invalid (%s%d)",
i, cm->numattrsets > 1 ? "0->" : "", cm->numattrsets - 1 );
Debug( LDAP_DEBUG_CONFIG, "%s: %s.\n", c->log, c->msg, 0 );
return 1;
}
- num = cm->numtemplates;
- qm->templates = ( QueryTemplate* )ch_realloc( qm->templates,
- ( num + 2 ) * sizeof( QueryTemplate ));
- temp = qm->templates + num;
- temp->t_rwlock = ch_malloc( sizeof( ldap_pvt_thread_rdwr_t ) );
- ldap_pvt_thread_rdwr_init( temp->t_rwlock );
+ temp = ch_calloc( 1, sizeof( QueryTemplate ));
+ temp->qmnext = qm->templates;
+ qm->templates = temp;
+ ldap_pvt_thread_rdwr_init( &temp->t_rwlock );
temp->query = temp->query_last = NULL;
if ( lutil_parse_time( c->argv[3], &t ) != 0 ) {
snprintf( c->msg, sizeof( c->msg ), "unable to parse template ttl=\"%s\"",
@@ -1833,15 +2073,14 @@ pc_cf_gen( ConfigArgs *c )
temp->querystr.bv_val, 0, 0 );
temp->attr_set_index = i;
qm->attr_sets[i].flags |= PC_REFERENCED;
+ temp->qtnext = qm->attr_sets[i].templates;
+ qm->attr_sets[i].templates = temp;
Debug( pcache_debug, " attributes: \n", 0, 0, 0 );
if ( ( attrarray = qm->attr_sets[i].attrs ) != NULL ) {
for ( i=0; attrarray[i].an_name.bv_val; i++ )
Debug( pcache_debug, "\t%s\n",
attrarray[i].an_name.bv_val, 0, 0 );
}
- temp++;
- temp->querystr.bv_val = NULL;
- cm->numtemplates++;
break;
case PC_RESP:
if ( strcasecmp( c->argv[1], "head" ) == 0 ) {
@@ -1907,7 +2146,6 @@ pcache_db_init(
cm->db.be_pcl_mutexp = &cm->db.be_pcl_mutex;
cm->qm = qm;
cm->numattrsets = 0;
- cm->numtemplates = 0;
cm->num_entries_limit = 5;
cm->num_cached_queries = 0;
cm->max_entries = 0;
@@ -2002,6 +2240,17 @@ pcache_db_open(
return rc;
}
+static void
+pcache_free_qbase( void *v )
+{
+ Qbase *qb = v;
+ int i;
+
+ for (i=0; i<3; i++)
+ tavl_free( qb->scopes[i], NULL );
+ ch_free( qb );
+}
+
static int
pcache_db_close(
BackendDB *be
@@ -2010,6 +2259,7 @@ pcache_db_close(
slap_overinst *on = (slap_overinst *)be->bd_info;
cache_manager *cm = on->on_bi.bi_private;
query_manager *qm = cm->qm;
+ QueryTemplate *tm;
int i, rc = 0;
/* cleanup stuff inherited from the original database... */
@@ -2019,18 +2269,19 @@ pcache_db_close(
if ( cm->db.bd_info->bi_db_close ) {
rc = cm->db.bd_info->bi_db_close( &cm->db );
}
- for ( i=0; i<cm->numtemplates; i++ ) {
+ while ( (tm = qm->templates) != NULL ) {
CachedQuery *qc, *qn;
- for ( qc = qm->templates[i].query; qc; qc = qn ) {
+ qm->templates = tm->qmnext;
+ for ( qc = tm->query; qc; qc = qn ) {
qn = qc->next;
free_query( qc );
}
- free( qm->templates[i].querystr.bv_val );
- ldap_pvt_thread_rdwr_destroy( qm->templates[i].t_rwlock );
- ch_free( qm->templates[i].t_rwlock );
+ avl_free( tm->qbase, pcache_free_qbase );
+ free( tm->querystr.bv_val );
+ ldap_pvt_thread_rdwr_destroy( &tm->t_rwlock );
+ free( tm->t_attrs.attrs );
+ free( tm );
}
- free( qm->templates );
- qm->templates = NULL;
for ( i=0; i<cm->numattrsets; i++ ) {
free( qm->attr_sets[i].attrs );
diff --git a/servers/slapd/overlays/ppolicy.c b/servers/slapd/overlays/ppolicy.c
index 95ff1fd7c84d914cae5a6c6c7a79fde2dc4e81b1..cc5066ffa7042c7fc93de43953114d1668585cbf 100644
--- a/servers/slapd/overlays/ppolicy.c
+++ b/servers/slapd/overlays/ppolicy.c
@@ -39,6 +39,7 @@
#include <ac/time.h>
#include <ac/string.h>
#include <ac/ctype.h>
+#include "config.h"
#ifndef MODULE_NAME_SZ
#define MODULE_NAME_SZ 256
@@ -202,6 +203,95 @@ static struct schema_info pwd_UsSchema[] = {
static ldap_pvt_thread_mutex_t chk_syntax_mutex;
+enum {
+ PPOLICY_DEFAULT = 1,
+ PPOLICY_HASH_CLEARTEXT,
+ PPOLICY_USE_LOCKOUT
+};
+
+static ConfigDriver ppolicy_cf_default;
+
+static ConfigTable ppolicycfg[] = {
+ { "ppolicy_default", "policyDN", 2, 2, 0,
+ ARG_DN|ARG_MAGIC|PPOLICY_DEFAULT, ppolicy_cf_default,
+ "( OLcfgOvAt:12.1 NAME 'olcPPolicyDefault' "
+ "DESC 'DN of a pwdPolicy object for uncustomized objects' "
+ "SYNTAX OMsDN SINGLE-VALUE )", NULL, NULL },
+ { "ppolicy_hash_cleartext", "on|off", 1, 2, 0,
+ ARG_ON_OFF|ARG_OFFSET|PPOLICY_HASH_CLEARTEXT,
+ (void *)offsetof(pp_info,hash_passwords),
+ "( OLcfgOvAt:12.2 NAME 'olcPPolicyHashCleartext' "
+ "DESC 'Hash passwords on add or modify' "
+ "SYNTAX OMsBoolean SINGLE-VALUE )", NULL, NULL },
+ { "ppolicy_use_lockout", "on|off", 1, 2, 0,
+ ARG_ON_OFF|ARG_OFFSET|PPOLICY_USE_LOCKOUT,
+ (void *)offsetof(pp_info,use_lockout),
+ "( OLcfgOvAt:12.3 NAME 'olcPPolicyUseLockout' "
+ "DESC 'Warn clients with AccountLocked' "
+ "SYNTAX OMsBoolean SINGLE-VALUE )", NULL, NULL },
+ { NULL, NULL, 0, 0, 0, ARG_IGNORED }
+};
+
+static ConfigOCs ppolicyocs[] = {
+ { "( OLcfgOvOc:12.1 "
+ "NAME 'olcPPolicyConfig' "
+ "DESC 'Password Policy configuration' "
+ "SUP olcOverlayConfig "
+ "MAY ( olcPPolicyDefault $ olcPPolicyHashCleartext $ "
+ "olcPPolicyUseLockout ) )",
+ Cft_Overlay, ppolicycfg },
+ { NULL, 0, NULL }
+};
+
+static int
+ppolicy_cf_default( ConfigArgs *c )
+{
+ slap_overinst *on = (slap_overinst *)c->bi;
+ pp_info *pi = (pp_info *)on->on_bi.bi_private;
+ BackendDB *be = (BackendDB *)c->be;
+ const char *text;
+ int rc = ARG_BAD_CONF;
+
+ assert ( c->type == PPOLICY_DEFAULT );
+ Debug(LDAP_DEBUG_TRACE, "==> ppolicy_cf_default\n", 0, 0, 0);
+
+ switch ( c->op ) {
+ case SLAP_CONFIG_EMIT:
+ Debug(LDAP_DEBUG_TRACE, "==> ppolicy_cf_default emit\n", 0, 0, 0);
+ rc = 0;
+ if ( !BER_BVISEMPTY( &pi->def_policy )) {
+ rc = value_add_one( &c->rvalue_vals,
+ &pi->def_policy );
+ if ( rc ) return rc;
+ rc = value_add_one( &c->rvalue_nvals,
+ &pi->def_policy );
+ }
+ break;
+ case LDAP_MOD_DELETE:
+ Debug(LDAP_DEBUG_TRACE, "==> ppolicy_cf_default delete\n", 0, 0, 0);
+ if ( pi->def_policy.bv_val ) {
+ ber_memfree ( pi->def_policy.bv_val );
+ pi->def_policy.bv_val = NULL;
+ }
+ pi->def_policy.bv_len = 0;
+ rc = 0;
+ break;
+ case SLAP_CONFIG_ADD:
+ /* fallthrough to LDAP_MOD_ADD */
+ case LDAP_MOD_ADD:
+ Debug(LDAP_DEBUG_TRACE, "==> ppolicy_cf_default add\n", 0, 0, 0);
+ if ( pi->def_policy.bv_val )
+ ber_memfree ( pi->def_policy.bv_val );
+ pi->def_policy = c->value_ndn;
+ rc = 0;
+ break;
+ default:
+ abort ();
+ }
+
+ return rc;
+}
+
static time_t
parse_time( char *atm )
{
@@ -326,6 +416,8 @@ ppolicy_get( Operation *op, Entry *e, PassPolicy *pp )
memset( pp, 0, sizeof(PassPolicy) );
+ pp->ad = slap_schema.si_ad_userPassword;
+
/* Users can change their own password by default */
pp->pwdAllowUserChange = 1;
@@ -354,8 +446,6 @@ ppolicy_get( Operation *op, Entry *e, PassPolicy *pp )
#if 0 /* Only worry about userPassword for now */
if ((a = attr_find( pe->e_attrs, ad_pwdAttribute )))
slap_bv2ad( &a->a_vals[0], &pp->ad, &text );
-#else
- pp->ad = slap_schema.si_ad_userPassword;
#endif
if ( ( a = attr_find( pe->e_attrs, ad_pwdMinAge ) )
@@ -411,7 +501,7 @@ ppolicy_get( Operation *op, Entry *e, PassPolicy *pp )
return;
defaultpol:
- Debug( LDAP_DEBUG_ANY,
+ Debug( LDAP_DEBUG_TRACE,
"ppolicy_get: using default policy\n", 0, 0, 0 );
return;
}
@@ -435,9 +525,11 @@ password_scheme( struct berval *cred, struct berval *sch )
if (cred->bv_val[e]) {
int rc;
rc = lutil_passwd_scheme( cred->bv_val );
- if (rc && sch) {
- sch->bv_val = cred->bv_val;
- sch->bv_len = e;
+ if (rc) {
+ if (sch) {
+ sch->bv_val = cred->bv_val;
+ sch->bv_len = e;
+ }
return LDAP_SUCCESS;
}
}
@@ -1186,6 +1278,19 @@ ppolicy_add(
return SLAP_CB_CONTINUE;
}
+static int
+ppolicy_mod_cb( Operation *op, SlapReply *rs )
+{
+ slap_callback *sc = op->o_callback;
+ op->o_callback = sc->sc_next;
+ if ( rs->sr_err == LDAP_SUCCESS ) {
+ ch_free( pwcons[op->o_conn->c_conn_idx].dn.bv_val );
+ BER_BVZERO( &pwcons[op->o_conn->c_conn_idx].dn );
+ }
+ op->o_tmpfree( sc, op->o_tmpmemctx );
+ return SLAP_CB_CONTINUE;
+}
+
static int
ppolicy_modify( Operation *op, SlapReply *rs )
{
@@ -1583,7 +1688,23 @@ do_modify:
struct berval timestamp;
char timebuf[ LDAP_LUTIL_GENTIME_BUFSIZE ];
time_t now = slap_get_time();
-
+
+ /* If the conn is restricted, set a callback to clear it
+ * if the pwmod succeeds
+ */
+ if (!BER_BVISEMPTY( &pwcons[op->o_conn->c_conn_idx].dn )) {
+ slap_callback *sc = op->o_tmpcalloc( 1, sizeof( slap_callback ),
+ op->o_tmpmemctx );
+ sc->sc_next = op->o_callback;
+ /* Must use sc_response to insure we reset on success, before
+ * the client sees the response. Must use sc_cleanup to insure
+ * that it gets cleaned up if sc_response is not called.
+ */
+ sc->sc_response = ppolicy_mod_cb;
+ sc->sc_cleanup = ppolicy_mod_cb;
+ op->o_callback = sc;
+ }
+
/*
* keep the necessary pwd.. operational attributes
* up to date.
@@ -1807,11 +1928,9 @@ ppolicy_parseCtrl(
rs->sr_text = "passwordPolicyRequest control value not empty";
return LDAP_PROTOCOL_ERROR;
}
- if ( ctrl->ldctl_iscritical ) {
- rs->sr_text = "passwordPolicyRequest control invalid criticality";
- return LDAP_PROTOCOL_ERROR;
- }
- op->o_ctrlflag[ppolicy_cid] = SLAP_CONTROL_NONCRITICAL;
+ op->o_ctrlflag[ppolicy_cid] = ctrl->ldctl_iscritical
+ ? SLAP_CONTROL_CRITICAL
+ : SLAP_CONTROL_NONCRITICAL;
return LDAP_SUCCESS;
}
@@ -1920,54 +2039,6 @@ ppolicy_close(
return 0;
}
-static int
-ppolicy_config(
- BackendDB *be,
- const char *fname,
- int lineno,
- int argc,
- char **argv
-)
-{
- slap_overinst *on = (slap_overinst *) be->bd_info;
- pp_info *pi = on->on_bi.bi_private;
- struct berval dn;
-
-
- if ( strcasecmp( argv[0], "ppolicy_default" ) == 0 ) {
- if ( argc != 2 ) {
- fprintf( stderr, "%s: line %d: invalid arguments in \"ppolicy_default"
- " <policyDN>\n", fname, lineno );
- return ( 1 );
- }
- ber_str2bv( argv[1], 0, 0, &dn );
- if ( dnNormalize( 0, NULL, NULL, &dn, &pi->def_policy, NULL ) ) {
- fprintf( stderr, "%s: line %d: policyDN is invalid\n",
- fname, lineno );
- return 1;
- }
- return 0;
-
- } else if ( strcasecmp( argv[0], "ppolicy_use_lockout" ) == 0 ) {
- if ( argc != 1 ) {
- fprintf( stderr, "%s: line %d: ppolicy_use_lockout "
- "takes no arguments\n", fname, lineno );
- return ( 1 );
- }
- pi->use_lockout = 1;
- return 0;
- } else if ( strcasecmp( argv[0], "ppolicy_hash_cleartext" ) == 0 ) {
- if ( argc != 1 ) {
- fprintf( stderr, "%s: line %d: ppolicy_hash_cleartext "
- "takes no arguments\n", fname, lineno );
- return ( 1 );
- }
- pi->hash_passwords = 1;
- return 0;
- }
- return SLAP_CONF_UNKNOWN;
-}
-
static char *extops[] = {
LDAP_EXOP_MODIFY_PASSWD,
NULL
@@ -2019,7 +2090,6 @@ int ppolicy_initialize()
ppolicy.on_bi.bi_type = "ppolicy";
ppolicy.on_bi.bi_db_init = ppolicy_db_init;
ppolicy.on_bi.bi_db_open = ppolicy_db_open;
- ppolicy.on_bi.bi_db_config = ppolicy_config;
ppolicy.on_bi.bi_db_close = ppolicy_close;
ppolicy.on_bi.bi_op_add = ppolicy_add;
@@ -2030,6 +2100,10 @@ int ppolicy_initialize()
ppolicy.on_bi.bi_op_search = ppolicy_restrict;
ppolicy.on_bi.bi_connection_destroy = ppolicy_connection_destroy;
+ ppolicy.on_bi.bi_cf_ocs = ppolicyocs;
+ code = config_register_schema( ppolicycfg, ppolicyocs );
+ if ( code ) return code;
+
return overlay_register( &ppolicy );
}
diff --git a/servers/slapd/overlays/refint.c b/servers/slapd/overlays/refint.c
index 96fc8cd2ba6661b271b4938b5adbbf57ecba4426..ce4ecaa29c03f8679ef2a77403af59bfc7441e20 100644
--- a/servers/slapd/overlays/refint.c
+++ b/servers/slapd/overlays/refint.c
@@ -26,8 +26,8 @@
* DN whenever the DN is changed or its entry is deleted, and making
* the appropriate update.
*
- * Updates are performed using the database rootdn, but the ModifiersName
- * is always set to refint_dn.
+ * Updates are performed using the database rootdn in a separate task
+ * to allow the original operation to complete immediately.
*/
#ifdef SLAPD_OVER_REFINT
@@ -39,11 +39,13 @@
#include "slap.h"
#include "config.h"
+#include "ldap_rq.h"
static slap_overinst refint;
/* The DN to use in the ModifiersName for all refint updates */
static BerValue refint_dn = BER_BVC("cn=Referential Integrity Overlay");
+static BerValue refint_ndn = BER_BVC("cn=referential integrity overlay");
typedef struct refint_attrs_s {
struct refint_attrs_s *next;
@@ -53,20 +55,35 @@ typedef struct refint_attrs_s {
typedef struct dependents_s {
struct dependents_s *next;
BerValue dn; /* target dn */
- Modifications *mm;
+ BerValue ndn;
+ refint_attrs *attrs;
} dependent_data;
+typedef struct refint_q {
+ struct refint_q *next;
+ struct refint_data_s *rdata;
+ dependent_data *attrs; /* entries and attrs returned from callback */
+ BackendDB *db;
+ BerValue olddn;
+ BerValue oldndn;
+ BerValue newdn;
+ BerValue newndn;
+} refint_q;
+
typedef struct refint_data_s {
const char *message; /* breadcrumbs */
struct refint_attrs_s *attrs; /* list of known attrs */
- struct dependents_s *mods; /* modifications returned from callback */
- BerValue dn; /* basedn in parent, searchdn in call */
- BerValue newdn; /* replacement value for modrdn callback */
- BerValue nnewdn; /* normalized replacement value */
+ BerValue dn; /* basedn in parent, */
BerValue nothing; /* the nothing value, if needed */
BerValue nnothing; /* normalized nothingness */
+ struct re_s *qtask;
+ refint_q *qhead;
+ refint_q *qtail;
+ ldap_pvt_thread_mutex_t qmutex;
} refint_data;
+#define RUNQ_INTERVAL 36000 /* a long time */
+
enum {
REFINT_ATTRS = 1,
REFINT_NOTHING
@@ -238,6 +255,7 @@ refint_db_init(
id->message = "_init";
on->on_bi.bi_private = id;
+ ldap_pvt_thread_mutex_init( &id->qmutex );
return(0);
}
@@ -249,8 +267,10 @@ refint_db_destroy(
slap_overinst *on = (slap_overinst *)be->bd_info;
if ( on->on_bi.bi_private ) {
- ch_free( on->on_bi.bi_private );
+ refint_data *id = on->on_bi.bi_private;
on->on_bi.bi_private = NULL;
+ ldap_pvt_thread_mutex_destroy( &id->qmutex );
+ ch_free( id );
}
return(0);
}
@@ -313,204 +333,305 @@ refint_close(
}
/*
-** delete callback
-** generates a list of Modification* from search results
+** search callback
+** generates a list of Attributes from search results
*/
static int
-refint_delete_cb(
+refint_search_cb(
Operation *op,
SlapReply *rs
)
{
Attribute *a;
BerVarray b = NULL;
- refint_data *dd = op->o_callback->sc_private;
- refint_attrs *ia, *da = dd->attrs;
+ refint_q *rq = op->o_callback->sc_private;
+ refint_data *dd = rq->rdata;
+ refint_attrs *ia, *da = dd->attrs, *na;
dependent_data *ip;
- Modifications *mp, *ma;
int i;
- Debug(LDAP_DEBUG_TRACE, "refint_delete_cb <%s>\n",
+ Debug(LDAP_DEBUG_TRACE, "refint_search_cb <%s>\n",
rs->sr_entry ? rs->sr_entry->e_name.bv_val : "NOTHING", 0, 0);
if (rs->sr_type != REP_SEARCH || !rs->sr_entry) return(0);
- dd->message = "_delete_cb";
/*
** foreach configured attribute type:
** if this attr exists in the search result,
** and it has a value matching the target:
- ** allocate a Modification;
- ** allocate its array of 2 BerValues;
- ** if only one value, and we have a configured Nothing:
- ** allocate additional Modification
- ** type = MOD_ADD
- ** BerValues[] = { Nothing, NULL };
- ** add to list
- ** type = MOD_DELETE
- ** BerValues[] = { our target dn, NULL };
- ** add this mod to the list of mods;
+ ** allocate an attr;
+ ** if this is a delete and there's only one value:
+ ** allocate the same attr again;
**
*/
- ip = ch_malloc(sizeof(dependent_data));
- ip->dn.bv_val = NULL;
- ip->next = NULL;
- ip->mm = NULL;
- ma = NULL;
+ ip = op->o_tmpalloc(sizeof(dependent_data), op->o_tmpmemctx );
+ ber_dupbv_x( &ip->dn, &rs->sr_entry->e_name, op->o_tmpmemctx );
+ ber_dupbv_x( &ip->ndn, &rs->sr_entry->e_nname, op->o_tmpmemctx );
+ ip->next = rq->attrs;
+ rq->attrs = ip;
+ ip->attrs = NULL;
for(ia = da; ia; ia = ia->next) {
if ( (a = attr_find(rs->sr_entry->e_attrs, ia->attr) ) )
for(i = 0, b = a->a_nvals; b[i].bv_val; i++)
- if(bvmatch(&dd->dn, &b[i])) {
- if(!ip->dn.bv_val) ber_dupbv(&ip->dn, &rs->sr_entry->e_nname);
- if(!b[1].bv_val && dd->nothing.bv_val) {
- mp = ch_malloc(sizeof(Modifications));
- mp->sml_desc = ia->attr; /* XXX */
- mp->sml_type = a->a_desc->ad_cname;
- mp->sml_values = ch_malloc(2 * sizeof(BerValue));
- mp->sml_nvalues = ch_malloc(2 * sizeof(BerValue));
- mp->sml_values[1].bv_len = mp->sml_nvalues[1].bv_len = 0;
- mp->sml_values[1].bv_val = mp->sml_nvalues[1].bv_val = NULL;
-
- mp->sml_op = LDAP_MOD_ADD;
- mp->sml_flags = 0;
- ber_dupbv(&mp->sml_values[0], &dd->nothing);
- ber_dupbv(&mp->sml_nvalues[0], &dd->nnothing);
- mp->sml_next = ma;
- ma = mp;
+ if(bvmatch(&rq->oldndn, &b[i])) {
+ na = op->o_tmpalloc(sizeof( refint_attrs ), op->o_tmpmemctx );
+ na->next = ip->attrs;
+ ip->attrs = na;
+ na->attr = ia->attr;
+ /* If this is a delete and there's only one value, and
+ * we have a nothing DN configured, allocate the attr again.
+ */
+ if(!b[1].bv_val && BER_BVISEMPTY( &rq->newdn ) &&
+ dd->nothing.bv_val) {
+ na = op->o_tmpalloc(sizeof( refint_attrs ), op->o_tmpmemctx );
+ na->next = ip->attrs;
+ ip->attrs = na;
+ na->attr = ia->attr;
}
- /* this might violate the object class */
- mp = ch_malloc(sizeof(Modifications));
- mp->sml_desc = ia->attr; /* XXX */
- mp->sml_type = a->a_desc->ad_cname;
- mp->sml_values = ch_malloc(2 * sizeof(BerValue));
- mp->sml_nvalues = ch_malloc(2 * sizeof(BerValue));
- mp->sml_values[1].bv_len = mp->sml_nvalues[1].bv_len = 0;
- mp->sml_values[1].bv_val = mp->sml_nvalues[1].bv_val = NULL;
- mp->sml_op = LDAP_MOD_DELETE;
- mp->sml_flags = 0;
- ber_dupbv(&mp->sml_values[0], &dd->dn);
- ber_dupbv(&mp->sml_nvalues[0], &mp->sml_values[0]);
- mp->sml_next = ma;
- ma = mp;
- Debug(LDAP_DEBUG_TRACE, "refint_delete_cb: %s: %s\n",
- a->a_desc->ad_cname.bv_val, dd->dn.bv_val, 0);
+ Debug(LDAP_DEBUG_TRACE, "refint_search_cb: %s: %s\n",
+ a->a_desc->ad_cname.bv_val, rq->olddn.bv_val, 0);
break;
}
}
- ip->mm = ma;
- ip->next = dd->mods;
- dd->mods = ip;
-
return(0);
}
-/*
-** null callback
-** does nothing
-*/
-
-static int
-refint_null_cb(
- Operation *op,
- SlapReply *rs
-)
-{
- ((refint_data *)op->o_callback->sc_private)->message = "_null_cb";
- return(LDAP_SUCCESS);
-}
-
-/*
-** modrdn callback
-** generates a list of Modification* from search results
-*/
-
-static int
-refint_modrdn_cb(
- Operation *op,
- SlapReply *rs
-)
+static void *
+refint_qtask( void *ctx, void *arg )
{
- Attribute *a;
- BerVarray b = NULL;
- refint_data *dd = op->o_callback->sc_private;
- refint_attrs *ia, *da = dd->attrs;
- dependent_data *ip = NULL;
- Modifications *mp;
- int i, fix;
-
- Debug(LDAP_DEBUG_TRACE, "refint_modrdn_cb <%s>\n",
- rs->sr_entry ? rs->sr_entry->e_name.bv_val : "NOTHING", 0, 0);
+ struct re_s *rtask = arg;
+ refint_data *id = rtask->arg;
+ Connection conn = {0};
+ OperationBuffer opbuf;
+ Operation *op;
+ SlapReply rs = {REP_RESULT};
+ slap_callback cb = { NULL, NULL, NULL, NULL };
+ Filter ftop, *fptr;
+ refint_q *rq;
+ dependent_data *dp;
+ refint_attrs *ra, *ip;
+ int rc;
- if (rs->sr_type != REP_SEARCH || !rs->sr_entry) return(0);
- dd->message = "_modrdn_cb";
+ op = (Operation *) &opbuf;
+ connection_fake_init( &conn, op, ctx );
/*
- ** foreach configured attribute type:
- ** if this attr exists in the search result,
- ** and it has a value matching the target:
- ** allocate a pair of Modifications;
- ** make it MOD_ADD the new value and MOD_DELETE the old;
- ** allocate its array of BerValues;
- ** foreach value in the search result:
- ** if it matches our target value, replace it;
- ** otherwise, copy from the search result;
- ** terminate the array of BerValues;
- ** add these mods to the list of mods;
+ ** build a search filter for all configured attributes;
+ ** populate our Operation;
+ ** pass our data (attr list, dn) to backend via sc_private;
+ ** call the backend search function;
+ ** nb: (|(one=thing)) is valid, but do smart formatting anyway;
+ ** nb: 16 is arbitrarily a dozen or so extra bytes;
**
*/
- for(ia = da; ia; ia = ia->next) {
- if((a = attr_find(rs->sr_entry->e_attrs, ia->attr))) {
- for(fix = 0, i = 0, b = a->a_nvals; b[i].bv_val; i++)
- if(bvmatch(&dd->dn, &b[i])) { fix++; break; }
- if(fix) {
- if (!ip) {
- ip = ch_malloc(sizeof(dependent_data));
- ip->next = NULL;
- ip->mm = NULL;
- ber_dupbv(&ip->dn, &rs->sr_entry->e_nname);
+ ftop.f_choice = LDAP_FILTER_OR;
+ ftop.f_next = NULL;
+ ftop.f_or = NULL;
+ op->ors_filter = &ftop;
+ for(ip = id->attrs; ip; ip = ip->next) {
+ fptr = op->o_tmpalloc( sizeof(Filter) + sizeof(AttributeAssertion),
+ op->o_tmpmemctx );
+ fptr->f_choice = LDAP_FILTER_EQUALITY;
+ fptr->f_ava = (AttributeAssertion *)(fptr+1);
+ fptr->f_ava->aa_desc = ip->attr;
+ fptr->f_next = ftop.f_or;
+ ftop.f_or = fptr;
+ }
+
+ for (;;) {
+ /* Dequeue an op */
+ ldap_pvt_thread_mutex_lock( &id->qmutex );
+ rq = id->qhead;
+ if ( rq ) {
+ id->qhead = rq->next;
+ if ( !id->qhead )
+ id->qtail = NULL;
+ }
+ ldap_pvt_thread_mutex_unlock( &id->qmutex );
+ if ( !rq )
+ break;
+
+ for (fptr = ftop.f_or; fptr; fptr=fptr->f_next )
+ fptr->f_av_value = rq->oldndn;
+
+ filter2bv_x( op, op->ors_filter, &op->ors_filterstr );
+
+ /* callback gets the searched dn instead */
+ cb.sc_private = rq;
+ cb.sc_response = refint_search_cb;
+ op->o_callback = &cb;
+ op->o_tag = LDAP_REQ_SEARCH;
+ op->ors_scope = LDAP_SCOPE_SUBTREE;
+ op->ors_deref = LDAP_DEREF_NEVER;
+ op->ors_limit = NULL;
+ op->ors_slimit = SLAP_NO_LIMIT;
+ op->ors_tlimit = SLAP_NO_LIMIT;
+
+ /* no attrs! */
+ op->ors_attrs = slap_anlist_no_attrs;
+
+ op->o_req_ndn = id->dn;
+ op->o_req_dn = id->dn;
+ op->o_bd = rq->db;
+ op->o_dn = op->o_bd->be_rootdn;
+ op->o_ndn = op->o_bd->be_rootndn;
+ slap_op_time( &op->o_time, &op->o_tincr );
+
+ /* search */
+ rc = op->o_bd->be_search(op, &rs);
+
+ op->o_tmpfree( op->ors_filterstr.bv_val, op->o_tmpmemctx );
+
+ if(rc != LDAP_SUCCESS) {
+ Debug( LDAP_DEBUG_TRACE,
+ "refint_response: search failed: %d\n",
+ rc, 0, 0 );
+ continue;
+ }
+
+ /* safety? paranoid just in case */
+ if(!cb.sc_private) {
+ Debug( LDAP_DEBUG_TRACE,
+ "refint_response: callback wiped out sc_private?!\n",
+ 0, 0, 0 );
+ continue;
+ }
+
+ /* Set up the Modify requests */
+ cb.sc_response = &slap_null_cb;
+ op->o_tag = LDAP_REQ_MODIFY;
+
+ /*
+ ** [our search callback builds a list of attrs]
+ ** foreach attr:
+ ** make sure its dn has a backend;
+ ** build Modification* chain;
+ ** call the backend modify function;
+ **
+ */
+
+ for(dp = rq->attrs; dp; dp = dp->next) {
+ Modifications *m, *first = NULL;
+
+ op->orm_modlist = NULL;
+
+ op->o_req_dn = dp->dn;
+ op->o_req_ndn = dp->ndn;
+ op->o_bd = select_backend(&dp->ndn, 0, 1);
+ if(!op->o_bd) {
+ Debug( LDAP_DEBUG_TRACE,
+ "refint_response: no backend for DN %s!\n",
+ dp->dn.bv_val, 0, 0 );
+ goto done;
}
- mp = ch_malloc(sizeof(Modifications));
- mp->sml_op = LDAP_MOD_ADD;
- mp->sml_flags = 0;
- mp->sml_desc = ia->attr; /* XXX */
- mp->sml_type = ia->attr->ad_cname;
- mp->sml_values = ch_malloc(2 * sizeof(BerValue));
- mp->sml_nvalues = ch_malloc(2 * sizeof(BerValue));
- ber_dupbv(&mp->sml_values[0], &dd->newdn);
- ber_dupbv(&mp->sml_nvalues[0], &dd->nnewdn);
- mp->sml_values[1].bv_len = mp->sml_nvalues[1].bv_len = 0;
- mp->sml_values[1].bv_val = mp->sml_nvalues[1].bv_val = NULL;
- mp->sml_next = ip->mm;
- ip->mm = mp;
- mp = ch_malloc(sizeof(Modifications));
- mp->sml_op = LDAP_MOD_DELETE;
- mp->sml_flags = 0;
- mp->sml_desc = ia->attr; /* XXX */
- mp->sml_type = ia->attr->ad_cname;
- mp->sml_values = ch_malloc(2 * sizeof(BerValue));
- mp->sml_nvalues = ch_malloc(2 * sizeof(BerValue));
- ber_dupbv(&mp->sml_values[0], &dd->dn);
- ber_dupbv(&mp->sml_nvalues[0], &dd->dn);
- mp->sml_values[1].bv_len = mp->sml_nvalues[1].bv_len = 0;
- mp->sml_values[1].bv_val = mp->sml_nvalues[1].bv_val = NULL;
- mp->sml_next = ip->mm;
- ip->mm = mp;
- Debug(LDAP_DEBUG_TRACE, "refint_modrdn_cb: %s: %s\n",
- a->a_desc->ad_cname.bv_val, dd->dn.bv_val, 0);
+ rs.sr_type = REP_RESULT;
+ for (ra = dp->attrs; ra; ra = dp->attrs) {
+ dp->attrs = ra->next;
+ /* Set our ModifiersName */
+ if ( SLAP_LASTMOD( op->o_bd )) {
+ m = op->o_tmpalloc( sizeof(Modifications) +
+ 4*sizeof(BerValue), op->o_tmpmemctx );
+ m->sml_next = op->orm_modlist;
+ if ( !first )
+ first = m;
+ op->orm_modlist = m;
+ m->sml_op = LDAP_MOD_REPLACE;
+ m->sml_flags = SLAP_MOD_INTERNAL;
+ m->sml_desc = slap_schema.si_ad_modifiersName;
+ m->sml_type = m->sml_desc->ad_cname;
+ m->sml_values = (BerVarray)(m+1);
+ m->sml_nvalues = m->sml_values+2;
+ BER_BVZERO( &m->sml_values[1] );
+ BER_BVZERO( &m->sml_nvalues[1] );
+ m->sml_values[0] = refint_dn;
+ m->sml_nvalues[0] = refint_ndn;
+ }
+ if ( !BER_BVISEMPTY( &rq->newdn ) || ( ra->next &&
+ ra->attr == ra->next->attr )) {
+ m = op->o_tmpalloc( sizeof(Modifications) +
+ 4*sizeof(BerValue), op->o_tmpmemctx );
+ m->sml_next = op->orm_modlist;
+ if ( !first )
+ first = m;
+ op->orm_modlist = m;
+ m->sml_op = LDAP_MOD_ADD;
+ m->sml_flags = 0;
+ m->sml_desc = ra->attr;
+ m->sml_type = ra->attr->ad_cname;
+ m->sml_values = (BerVarray)(m+1);
+ m->sml_nvalues = m->sml_values+2;
+ BER_BVZERO( &m->sml_values[1] );
+ BER_BVZERO( &m->sml_nvalues[1] );
+ if ( BER_BVISEMPTY( &rq->newdn )) {
+ op->o_tmpfree( ra, op->o_tmpmemctx );
+ ra = dp->attrs;
+ dp->attrs = ra->next;
+ m->sml_values[0] = id->nothing;
+ m->sml_nvalues[0] = id->nnothing;
+ } else {
+ m->sml_values[0] = rq->newdn;
+ m->sml_nvalues[0] = rq->newndn;
+ }
+ }
+ m = op->o_tmpalloc( sizeof(Modifications) + 4*sizeof(BerValue),
+ op->o_tmpmemctx );
+ m->sml_next = op->orm_modlist;
+ op->orm_modlist = m;
+ if ( !first )
+ first = m;
+ m->sml_op = LDAP_MOD_DELETE;
+ m->sml_flags = 0;
+ m->sml_desc = ra->attr;
+ m->sml_type = ra->attr->ad_cname;
+ m->sml_values = (BerVarray)(m+1);
+ m->sml_nvalues = m->sml_values+2;
+ m->sml_values[0] = rq->olddn;
+ m->sml_nvalues[0] = rq->oldndn;
+ BER_BVZERO( &m->sml_values[1] );
+ BER_BVZERO( &m->sml_nvalues[1] );
+ op->o_tmpfree( ra, op->o_tmpmemctx );
+ }
+
+ op->o_dn = op->o_bd->be_rootdn;
+ op->o_ndn = op->o_bd->be_rootndn;
+ slap_op_time( &op->o_time, &op->o_tincr );
+ if((rc = op->o_bd->be_modify(op, &rs)) != LDAP_SUCCESS) {
+ Debug( LDAP_DEBUG_TRACE,
+ "refint_response: dependent modify failed: %d\n",
+ rs.sr_err, 0, 0 );
+ }
+
+ while (( m = op->orm_modlist )) {
+ op->orm_modlist = m->sml_next;
+ op->o_tmpfree( m, op->o_tmpmemctx );
+ if ( m == first ) break;
+ }
+ slap_mods_free( op->orm_modlist, 1 );
+ op->o_tmpfree( dp->ndn.bv_val, op->o_tmpmemctx );
+ op->o_tmpfree( dp->dn.bv_val, op->o_tmpmemctx );
+ op->o_tmpfree( dp, op->o_tmpmemctx );
}
- }
- }
- if (ip) {
- ip->next = dd->mods;
- dd->mods = ip;
+done:
+ if ( !BER_BVISNULL( &rq->newndn )) {
+ ch_free( rq->newndn.bv_val );
+ ch_free( rq->newdn.bv_val );
+ }
+ ch_free( rq->oldndn.bv_val );
+ ch_free( rq->olddn.bv_val );
+ ch_free( rq );
}
- return(0);
-}
+ /* wait until we get explicitly scheduled again */
+ ldap_pvt_thread_mutex_lock( &slapd_rq.rq_mutex );
+ ldap_pvt_runqueue_stoptask( &slapd_rq, id->qtask );
+ ldap_pvt_runqueue_resched( &slapd_rq,id->qtask, 1 );
+ ldap_pvt_thread_mutex_unlock( &slapd_rq.rq_mutex );
+ return NULL;
+}
/*
** refint_response
@@ -523,19 +644,13 @@ refint_response(
SlapReply *rs
)
{
- Operation nop = *op;
- SlapReply nrs = { REP_RESULT };
- slap_callback cb = { NULL, NULL, NULL, NULL };
- slap_callback cb2 = { NULL, slap_replog_cb, NULL, NULL };
- slap_callback *cbo, *cbp;
slap_overinst *on = (slap_overinst *) op->o_bd->bd_info;
refint_data *id = on->on_bi.bi_private;
- refint_data dd = *id;
- refint_attrs *ip;
- dependent_data *dp;
BerValue pdn;
int rc, ac;
- Filter ftop, *fptr;
+ refint_q *rq;
+ BackendDB *db;
+ refint_attrs *ip;
id->message = "_refint_response";
@@ -562,10 +677,10 @@ refint_response(
**
*/
- nop.o_bd = select_backend(&id->dn, 0, 1);
+ db = select_backend(&id->dn, 0, 1);
- if(nop.o_bd) {
- if (!nop.o_bd->be_search || !nop.o_bd->be_modify) {
+ if(db) {
+ if (!db->be_search || !db->be_modify) {
Debug( LDAP_DEBUG_TRACE,
"refint_response: backend missing search and/or modify\n",
0, 0, 0 );
@@ -578,169 +693,57 @@ refint_response(
return SLAP_CB_CONTINUE;
}
- cb2.sc_next = &cb;
+ rq = ch_calloc( 1, sizeof( refint_q ));
+ ber_dupbv( &rq->olddn, &op->o_req_dn );
+ ber_dupbv( &rq->oldndn, &op->o_req_ndn );
+ rq->db = db;
+ rq->rdata = id;
- /*
- ** if delete: set delete callback;
- ** else modrdn: create a newdn, set modify callback;
- **
- */
-
- if(op->o_tag == LDAP_REQ_DELETE) {
- cb.sc_response = &refint_delete_cb;
- dd.newdn.bv_val = NULL;
- dd.nnewdn.bv_val = NULL;
- } else {
- cb.sc_response = &refint_modrdn_cb;
+ if(op->o_tag == LDAP_REQ_MODRDN) {
if ( op->oq_modrdn.rs_newSup ) {
pdn = *op->oq_modrdn.rs_newSup;
} else {
dnParent( &op->o_req_dn, &pdn );
}
- build_new_dn( &dd.newdn, &pdn, &op->orr_newrdn, NULL );
+ build_new_dn( &rq->newdn, &pdn, &op->orr_newrdn, NULL );
if ( op->oq_modrdn.rs_nnewSup ) {
pdn = *op->oq_modrdn.rs_nnewSup;
} else {
dnParent( &op->o_req_ndn, &pdn );
}
- build_new_dn( &dd.nnewdn, &pdn, &op->orr_nnewrdn, NULL );
+ build_new_dn( &rq->newndn, &pdn, &op->orr_nnewrdn, NULL );
}
- /*
- ** build a search filter for all configured attributes;
- ** populate our Operation;
- ** pass our data (attr list, dn) to backend via sc_private;
- ** call the backend search function;
- ** nb: (|(one=thing)) is valid, but do smart formatting anyway;
- ** nb: 16 is arbitrarily a dozen or so extra bytes;
- **
- */
-
- ftop.f_choice = LDAP_FILTER_OR;
- ftop.f_next = NULL;
- ftop.f_or = NULL;
- nop.ors_filter = &ftop;
- for(ip = id->attrs; ip; ip = ip->next) {
- fptr = ch_malloc( sizeof(Filter) + sizeof(AttributeAssertion) );
- fptr->f_choice = LDAP_FILTER_EQUALITY;
- fptr->f_ava = (AttributeAssertion *)(fptr+1);
- fptr->f_ava->aa_desc = ip->attr;
- fptr->f_ava->aa_value = op->o_req_ndn;
- fptr->f_next = ftop.f_or;
- ftop.f_or = fptr;
- }
- filter2bv( nop.ors_filter, &nop.ors_filterstr );
-
- /* callback gets the searched dn instead */
- dd.dn = op->o_req_ndn;
- dd.message = "_dependent_search";
- dd.mods = NULL;
- cb.sc_private = ⅆ
- nop.o_callback = &cb;
- nop.o_tag = LDAP_REQ_SEARCH;
- nop.ors_scope = LDAP_SCOPE_SUBTREE;
- nop.ors_deref = LDAP_DEREF_NEVER;
- nop.ors_limit = NULL;
- nop.ors_slimit = SLAP_NO_LIMIT;
- nop.ors_tlimit = SLAP_NO_LIMIT;
-
- /* no attrs! */
- nop.ors_attrs = slap_anlist_no_attrs;
- nop.ors_attrsonly = 1;
-
- nop.o_req_ndn = id->dn;
- nop.o_req_dn = id->dn;
-
- /* search */
- rc = nop.o_bd->be_search(&nop, &nrs);
-
- ch_free( nop.ors_filterstr.bv_val );
- while ( (fptr = ftop.f_or) != NULL ) {
- ftop.f_or = fptr->f_next;
- ch_free( fptr );
- }
- ch_free(dd.nnewdn.bv_val);
- ch_free(dd.newdn.bv_val);
- dd.newdn.bv_val = NULL;
- dd.nnewdn.bv_val = NULL;
-
- if(rc != LDAP_SUCCESS) {
- Debug( LDAP_DEBUG_TRACE,
- "refint_response: search failed: %d\n",
- rc, 0, 0 );
- goto done;
- }
-
- /* safety? paranoid just in case */
- if(!cb.sc_private) {
- Debug( LDAP_DEBUG_TRACE,
- "refint_response: callback wiped out sc_private?!\n",
- 0, 0, 0 );
- goto done;
- }
-
- /* presto! now it's a modify request with null callback */
- cb.sc_response = &refint_null_cb;
- nop.o_tag = LDAP_REQ_MODIFY;
- dd.message = "_dependent_modify";
-
- /* See if the parent operation is going into the replog */
- for (cbo=op->o_callback, cbp = cbo->sc_next; cbp; cbo=cbp,cbp=cbp->sc_next) {
- if (cbp->sc_response == slap_replog_cb) {
- /* Invoke replog now, arrange for our
- * dependent mods to also be logged
- */
- cbo->sc_next = cbp->sc_next;
- replog( op );
- nop.o_callback = &cb2;
- break;
- }
+ ldap_pvt_thread_mutex_lock( &id->qmutex );
+ if ( id->qtail ) {
+ id->qtail->next = rq;
+ } else {
+ id->qhead = rq;
}
-
- /*
- ** [our search callback builds a list of mods]
- ** foreach mod:
- ** make sure its dn has a backend;
- ** connect Modification* chain to our op;
- ** call the backend modify function;
- ** pass any errors upstream;
- **
- */
-
- for(dp = dd.mods; dp; dp = dp->next) {
- nop.o_req_dn = dp->dn;
- nop.o_req_ndn = dp->dn;
- nop.o_bd = select_backend(&dp->dn, 0, 1);
- if(!nop.o_bd) {
- Debug( LDAP_DEBUG_TRACE,
- "refint_response: no backend for DN %s!\n",
- dp->dn.bv_val, 0, 0 );
- goto done;
- }
- nrs.sr_type = REP_RESULT;
- nop.orm_modlist = dp->mm; /* callback did all the work */
- nop.o_dn = refint_dn;
- nop.o_ndn = refint_dn;
- nop.o_dn = nop.o_bd->be_rootdn;
- nop.o_ndn = nop.o_bd->be_rootndn;
- if(rs->sr_err != LDAP_SUCCESS) goto done;
- if((rc = nop.o_bd->be_modify(&nop, &nrs)) != LDAP_SUCCESS) {
- Debug( LDAP_DEBUG_TRACE,
- "refint_response: dependent modify failed: %d\n",
- nrs.sr_err, 0, 0 );
- goto done;
+ id->qtail = rq;
+ ldap_pvt_thread_mutex_unlock( &id->qmutex );
+
+ ac = 0;
+ ldap_pvt_thread_mutex_lock( &slapd_rq.rq_mutex );
+ if ( !id->qtask ) {
+ id->qtask = ldap_pvt_runqueue_insert( &slapd_rq, RUNQ_INTERVAL,
+ refint_qtask, id, "refint_qtask",
+ op->o_bd->be_suffix[0].bv_val );
+ ac = 1;
+ } else {
+ if ( !ldap_pvt_runqueue_isrunning( &slapd_rq, id->qtask ) &&
+ !id->qtask->next_sched.tv_sec ) {
+ id->qtask->interval.tv_sec = 0;
+ ldap_pvt_runqueue_resched( &slapd_rq, id->qtask, 0 );
+ id->qtask->interval.tv_sec = RUNQ_INTERVAL;
+ ac = 1;
}
}
+ ldap_pvt_thread_mutex_unlock( &slapd_rq.rq_mutex );
+ if ( ac )
+ slap_wake_listener();
-done:
- for(dp = dd.mods; dp; dp = dd.mods) {
- dd.mods = dp->next;
- ch_free(dp->dn.bv_val);
- slap_mods_free(dp->mm, 1);
- }
- dd.mods = NULL;
-
- return(SLAP_CB_CONTINUE);
+ return SLAP_CB_CONTINUE;
}
/*
diff --git a/servers/slapd/overlays/syncprov.c b/servers/slapd/overlays/syncprov.c
index 3fe92a3e2be5bebf771c1117b007895ea60f53e6..db037774693f70488de90fee7b11bcf17ee6302a 100644
--- a/servers/slapd/overlays/syncprov.c
+++ b/servers/slapd/overlays/syncprov.c
@@ -65,6 +65,7 @@ typedef struct syncops {
#define PS_IS_DETACHED 0x02
#define PS_WROTE_BASE 0x04
#define PS_FIND_BASE 0x08
+#define PS_FIX_FILTER 0x10
int s_inuse; /* reference count */
struct syncres *s_res;
@@ -911,6 +912,33 @@ syncprov_qtask( void *ctx, void *arg )
return NULL;
}
+/* Start the task to play back queued psearch responses */
+static void
+syncprov_qstart( syncops *so )
+{
+ int wake=0;
+ ldap_pvt_thread_mutex_lock( &slapd_rq.rq_mutex );
+ if ( !so->s_qtask ) {
+ so->s_qtask = ldap_pvt_runqueue_insert( &slapd_rq, RUNQ_INTERVAL,
+ syncprov_qtask, so, "syncprov_qtask",
+ so->s_op->o_conn->c_peer_name.bv_val );
+ ++so->s_inuse;
+ wake = 1;
+ } else {
+ if (!ldap_pvt_runqueue_isrunning( &slapd_rq, so->s_qtask ) &&
+ !so->s_qtask->next_sched.tv_sec ) {
+ so->s_qtask->interval.tv_sec = 0;
+ ldap_pvt_runqueue_resched( &slapd_rq, so->s_qtask, 0 );
+ so->s_qtask->interval.tv_sec = RUNQ_INTERVAL;
+ ++so->s_inuse;
+ wake = 1;
+ }
+ }
+ ldap_pvt_thread_mutex_unlock( &slapd_rq.rq_mutex );
+ if ( wake )
+ slap_wake_listener();
+}
+
/* Queue a persistent search response */
static int
syncprov_qresp( opcookie *opc, syncops *so, int mode )
@@ -949,27 +977,7 @@ syncprov_qresp( opcookie *opc, syncops *so, int mode )
so->s_flags |= PS_FIND_BASE;
}
if ( so->s_flags & PS_IS_DETACHED ) {
- int wake=0;
- ldap_pvt_thread_mutex_lock( &slapd_rq.rq_mutex );
- if ( !so->s_qtask ) {
- so->s_qtask = ldap_pvt_runqueue_insert( &slapd_rq, RUNQ_INTERVAL,
- syncprov_qtask, so, "syncprov_qtask",
- so->s_op->o_conn->c_peer_name.bv_val );
- ++so->s_inuse;
- wake = 1;
- } else {
- if (!ldap_pvt_runqueue_isrunning( &slapd_rq, so->s_qtask ) &&
- !so->s_qtask->next_sched.tv_sec ) {
- so->s_qtask->interval.tv_sec = 0;
- ldap_pvt_runqueue_resched( &slapd_rq, so->s_qtask, 0 );
- so->s_qtask->interval.tv_sec = RUNQ_INTERVAL;
- ++so->s_inuse;
- wake = 1;
- }
- }
- ldap_pvt_thread_mutex_unlock( &slapd_rq.rq_mutex );
- if ( wake )
- slap_wake_listener();
+ syncprov_qstart( so );
}
ldap_pvt_thread_mutex_unlock( &so->s_mutex );
return LDAP_SUCCESS;
@@ -1055,6 +1063,7 @@ syncprov_matchops( Operation *op, opcookie *opc, int saveit )
int rc;
struct berval newdn;
int freefdn = 0;
+ BackendDB *b0 = op->o_bd, db;
fc.fdn = &op->o_req_ndn;
/* compute new DN */
@@ -1067,6 +1076,10 @@ syncprov_matchops( Operation *op, opcookie *opc, int saveit )
freefdn = 1;
}
if ( op->o_tag != LDAP_REQ_ADD ) {
+ if ( !SLAP_ISOVERLAY( op->o_bd )) {
+ db = *op->o_bd;
+ op->o_bd = &db;
+ }
op->o_bd->bd_info = (BackendInfo *)on->on_info;
rc = be_entry_get_rw( op, fc.fdn, NULL, NULL, 0, &e );
/* If we're sending responses now, make a copy and unlock the DB */
@@ -1076,7 +1089,10 @@ syncprov_matchops( Operation *op, opcookie *opc, int saveit )
e = e2;
}
op->o_bd->bd_info = (BackendInfo *)on;
- if ( rc ) return;
+ if ( rc ) {
+ op->o_bd = b0;
+ return;
+ }
} else {
e = op->ora_e;
}
@@ -1174,6 +1190,7 @@ syncprov_matchops( Operation *op, opcookie *opc, int saveit )
if ( freefdn ) {
op->o_tmpfree( fc.fdn->bv_val, op->o_tmpmemctx );
}
+ op->o_bd = b0;
}
static int
@@ -1235,9 +1252,14 @@ syncprov_checkpoint( Operation *op, SlapReply *rs, slap_overinst *on )
struct berval bv[2];
slap_callback cb = {0};
- mod.sml_values = bv;
- bv[1].bv_val = NULL;
- bv[0] = si->si_ctxcsn;
+ /* If ctxcsn is empty, delete it */
+ if ( BER_BVISEMPTY( &si->si_ctxcsn )) {
+ mod.sml_values = NULL;
+ } else {
+ mod.sml_values = bv;
+ bv[1].bv_val = NULL;
+ bv[0] = si->si_ctxcsn;
+ }
mod.sml_nvalues = NULL;
mod.sml_desc = slap_schema.si_ad_contextCSN;
mod.sml_op = LDAP_MOD_REPLACE;
@@ -1262,7 +1284,7 @@ syncprov_checkpoint( Operation *op, SlapReply *rs, slap_overinst *on )
}
static void
-syncprov_add_slog( Operation *op, struct berval *csn )
+syncprov_add_slog( Operation *op )
{
opcookie *opc = op->o_callback->sc_private;
slap_overinst *on = opc->son;
@@ -1274,7 +1296,7 @@ syncprov_add_slog( Operation *op, struct berval *csn )
{
/* Allocate a record. UUIDs are not NUL-terminated. */
se = ch_malloc( sizeof( slog_entry ) + opc->suuid.bv_len +
- csn->bv_len + 1 );
+ op->o_csn.bv_len + 1 );
se->se_next = NULL;
se->se_tag = op->o_tag;
@@ -1283,9 +1305,9 @@ syncprov_add_slog( Operation *op, struct berval *csn )
se->se_uuid.bv_len = opc->suuid.bv_len;
se->se_csn.bv_val = se->se_uuid.bv_val + opc->suuid.bv_len;
- AC_MEMCPY( se->se_csn.bv_val, csn->bv_val, csn->bv_len );
- se->se_csn.bv_val[csn->bv_len] = '\0';
- se->se_csn.bv_len = csn->bv_len;
+ AC_MEMCPY( se->se_csn.bv_val, op->o_csn.bv_val, op->o_csn.bv_len );
+ se->se_csn.bv_val[op->o_csn.bv_len] = '\0';
+ se->se_csn.bv_len = op->o_csn.bv_len;
ldap_pvt_thread_mutex_lock( &sl->sl_mutex );
if ( sl->sl_head ) {
@@ -1357,6 +1379,7 @@ syncprov_playlog( Operation *op, SlapReply *rs, sessionlog *sl,
i++;
AC_MEMCPY( cbuf, se->se_csn.bv_val, se->se_csn.bv_len );
delcsn.bv_len = se->se_csn.bv_len;
+ delcsn.bv_val[delcsn.bv_len] = '\0';
} else {
nmods++;
j = num - nmods;
@@ -1468,13 +1491,13 @@ syncprov_op_response( Operation *op, SlapReply *rs )
if ( rs->sr_err == LDAP_SUCCESS )
{
- struct berval maxcsn = BER_BVNULL, curcsn = BER_BVNULL;
+ struct berval maxcsn = BER_BVNULL;
char cbuf[LDAP_LUTIL_CSNSTR_BUFSIZE];
/* Update our context CSN */
cbuf[0] = '\0';
ldap_pvt_thread_mutex_lock( &si->si_csn_mutex );
- slap_get_commit_csn( op, &maxcsn, &curcsn );
+ slap_get_commit_csn( op, &maxcsn );
if ( !BER_BVISNULL( &maxcsn ) ) {
strcpy( cbuf, maxcsn.bv_val );
if ( ber_bvcmp( &maxcsn, &si->si_ctxcsn ) > 0 ) {
@@ -1535,7 +1558,7 @@ syncprov_op_response( Operation *op, SlapReply *rs )
/* Add any log records */
if ( si->si_logs && op->o_tag != LDAP_REQ_ADD ) {
- syncprov_add_slog( op, &curcsn );
+ syncprov_add_slog( op );
}
}
@@ -1770,7 +1793,15 @@ syncprov_detach_op( Operation *op, syncops *so, slap_overinst *on )
op2->ors_filterstr.bv_val = ptr;
strcpy( ptr, so->s_filterstr.bv_val );
op2->ors_filterstr.bv_len = so->s_filterstr.bv_len;
- op2->ors_filter = filter_dup( op->ors_filter, NULL );
+
+ /* Skip the AND/GE clause that we stuck on in front */
+ if ( so->s_flags & PS_FIX_FILTER ) {
+ op2->ors_filter = op->ors_filter->f_and->f_next;
+ so->s_flags ^= PS_FIX_FILTER;
+ } else {
+ op2->ors_filter = op->ors_filter;
+ }
+ op2->ors_filter = filter_dup( op2->ors_filter, NULL );
so->s_op = op2;
/* Copy any cached group ACLs individually */
@@ -1862,7 +1893,7 @@ syncprov_search_response( Operation *op, SlapReply *rs )
op->o_tmpfree( cookie.bv_val, op->o_tmpmemctx );
} else {
/* It's RefreshAndPersist, transition to Persist phase */
- syncprov_sendinfo( op, rs, ( ss->ss_present && rs->sr_nentries ) ?
+ syncprov_sendinfo( op, rs, ss->ss_present ?
LDAP_TAG_SYNC_REFRESH_PRESENT : LDAP_TAG_SYNC_REFRESH_DELETE,
&cookie, 1, NULL, 0 );
op->o_tmpfree( cookie.bv_val, op->o_tmpmemctx );
@@ -1874,6 +1905,10 @@ syncprov_search_response( Operation *op, SlapReply *rs )
ss->ss_so->s_flags ^= PS_IS_REFRESHING;
syncprov_detach_op( op, ss->ss_so, on );
+
+ /* If there are queued responses, fire them off */
+ if ( ss->ss_so->s_res )
+ syncprov_qstart( ss->ss_so );
ldap_pvt_thread_mutex_unlock( &ss->ss_so->s_mutex );
return LDAP_SUCCESS;
@@ -1981,7 +2016,10 @@ syncprov_op_search( Operation *op, SlapReply *rs )
sl=si->si_logs;
if ( sl ) {
ldap_pvt_thread_mutex_lock( &sl->sl_mutex );
- if ( ber_bvcmp( &srs->sr_state.ctxcsn, &sl->sl_mincsn ) >= 0 ) {
+ /* Are there any log entries, and is the consumer state
+ * present in the session log?
+ */
+ if ( sl->sl_num > 0 && ber_bvcmp( &srs->sr_state.ctxcsn, &sl->sl_mincsn ) >= 0 ) {
do_present = 0;
/* mutex is unlocked in playlog */
syncprov_playlog( op, rs, sl, srs, &ctxcsn );
@@ -2035,6 +2073,8 @@ shortcut:
fava->f_next = op->ors_filter;
op->ors_filter = fand;
filter2bv_x( op, op->ors_filter, &op->ors_filterstr );
+ if ( sop )
+ sop->s_flags |= PS_FIX_FILTER;
}
/* Let our callback add needed info to returned entries */
@@ -2317,6 +2357,12 @@ syncprov_db_open(
int rc;
void *thrctx = NULL;
+ if ( !SLAP_LASTMOD( be )) {
+ Debug( LDAP_DEBUG_ANY,
+ "syncprov_db_open: invalid config, lastmod must be enabled\n", 0, 0, 0 );
+ return -1;
+ }
+
if ( slapMode & SLAP_TOOL_MODE ) {
return 0;
}
@@ -2360,15 +2406,16 @@ syncprov_db_open(
ldap_pvt_thread_create( &tid, 0, syncprov_db_otask, op );
ldap_pvt_thread_join( tid, NULL );
}
- } else if ( SLAP_SYNC_SHADOW( op->o_bd )) {
- /* If we're also a consumer, and we didn't find the context entry,
- * then don't generate anything, wait for our provider to send it
- * to us.
- */
- goto out;
}
if ( BER_BVISEMPTY( &si->si_ctxcsn ) ) {
+ if ( SLAP_SYNC_SHADOW( op->o_bd )) {
+ /* If we're also a consumer, and we didn't get a contextCSN,
+ * then don't generate anything, wait for our provider to send it
+ * to us.
+ */
+ goto out;
+ }
si->si_ctxcsn.bv_len = sizeof( si->si_ctxcsnbuf );
slap_get_csn( op, &si->si_ctxcsn, 0 );
}
diff --git a/servers/slapd/overlays/translucent.c b/servers/slapd/overlays/translucent.c
index 43d7f45cbfe337dcd5b24b438e6b17aaf07b9335..0a446c83abd70a50d305f2a332d01d9ab07aae59 100644
--- a/servers/slapd/overlays/translucent.c
+++ b/servers/slapd/overlays/translucent.c
@@ -31,24 +31,92 @@
#include "slap.h"
#include "lutil.h"
-/* config block */
+#include "config.h"
-typedef struct translucent_configuration {
- int debug;
+/* config block */
+typedef struct translucent_info {
+ BackendDB db; /* captive backend */
int strict;
- int no_add;
- int glue;
-} translucent_configuration;
+ int no_glue;
+} translucent_info;
+
+static ConfigLDAPadd translucent_ldadd;
+static ConfigCfAdd translucent_cfadd;
+
+static ConfigTable translucentcfg[] = {
+ { "translucent_strict", "on|off", 1, 2, 0,
+ ARG_ON_OFF|ARG_OFFSET,
+ (void *)offsetof(translucent_info, strict),
+ "( OLcfgOvAt:14.1 NAME 'olcTranslucentStrict' "
+ "DESC 'Reveal attribute deletion constraint violations' "
+ "SYNTAX OMsBoolean SINGLE-VALUE )", NULL, NULL },
+ { "translucent_no_glue", "on|off", 1, 2, 0,
+ ARG_ON_OFF|ARG_OFFSET,
+ (void *)offsetof(translucent_info, no_glue),
+ "( OLcfgOvAt:14.2 NAME 'olcTranslucentNoGlue' "
+ "DESC 'Disable automatic glue records for ADD and MODRDN' "
+ "SYNTAX OMsBoolean SINGLE-VALUE )", NULL, NULL },
+ { NULL, NULL, 0, 0, 0, ARG_IGNORED }
+};
+
+static ConfigOCs translucentocs[] = {
+ { "( OLcfgOvOc:14.1 "
+ "NAME 'olcTranslucentConfig' "
+ "DESC 'Translucent configuration' "
+ "SUP olcOverlayConfig "
+ "MAY ( olcTranslucentStrict $ olcTranslucentNoGlue ) )",
+ Cft_Overlay, translucentcfg, NULL, translucent_cfadd },
+ { "( OLcfgOvOc:14.2 "
+ "NAME 'olcTranslucentDatabase' "
+ "DESC 'Translucent target database configuration' "
+ "AUXILIARY )", Cft_Misc, translucentcfg, translucent_ldadd },
+ { NULL, 0, NULL }
+};
+/* for translucent_init() */
+
+static int
+translucent_ldadd( CfEntryInfo *cei, Entry *e, ConfigArgs *ca )
+{
+ slap_overinst *on;
+ translucent_info *ov;
-/* stack of captive backends */
+ Debug(LDAP_DEBUG_TRACE, "==> translucent_ldadd\n", 0, 0, 0);
-typedef struct overlay_stack {
- BackendInfo *info; /* captive backend */
- void *private; /* local backend_private */
- translucent_configuration *config; /* our_private: configuration */
-} overlay_stack;
+ if ( cei->ce_type != Cft_Overlay || !cei->ce_bi ||
+ cei->ce_bi->bi_cf_ocs != translucentocs )
+ return LDAP_CONSTRAINT_VIOLATION;
-/* for translucent_init() */
+ on = (slap_overinst *)cei->ce_bi;
+ ov = on->on_bi.bi_private;
+ ca->be = &ov->db;
+ return LDAP_SUCCESS;
+}
+
+static int
+translucent_cfadd( Operation *op, SlapReply *rs, Entry *e, ConfigArgs *ca )
+{
+ CfEntryInfo *cei = e->e_private;
+ slap_overinst *on = (slap_overinst *)cei->ce_bi;
+ translucent_info *ov = on->on_bi.bi_private;
+ struct berval bv;
+
+ Debug(LDAP_DEBUG_TRACE, "==> translucent_cfadd\n", 0, 0, 0);
+
+ /* FIXME: should not hardcode "olcDatabase" here */
+ bv.bv_len = sprintf( ca->msg, "olcDatabase=%s",
+ ov->db.bd_info->bi_type );
+ bv.bv_val = ca->msg;
+ ca->be = &ov->db;
+
+ /* We can only create this entry if the database is table-driven
+ */
+ if ( ov->db.bd_info->bi_cf_ocs )
+ config_build_entry( op, rs, cei, ca, &bv,
+ ov->db.bd_info->bi_cf_ocs,
+ &translucentocs[1] );
+
+ return 0;
+}
static slap_overinst translucent;
@@ -100,9 +168,10 @@ void glue_parent(Operation *op) {
nop.o_req_dn = ndn;
nop.o_req_ndn = ndn;
nop.ora_e = e;
- nop.o_bd->bd_info = (BackendInfo *) on->on_info->oi_orig;
+ nop.o_bd->bd_info = (BackendInfo *) on->on_info->oi_orig;
syncrepl_add_glue(&nop, e);
+ nop.o_bd->bd_info = (BackendInfo *) on;
op->o_tmpfree( ndn.bv_val, op->o_tmpmemctx );
@@ -142,46 +211,48 @@ void free_attr_chain(Attribute *a) {
/*
** translucent_add()
** if not bound as root, send ACCESS error;
-** if config.glue, glue_parent();
+** if glue, glue_parent();
** return CONTINUE;
**
*/
static int translucent_add(Operation *op, SlapReply *rs) {
slap_overinst *on = (slap_overinst *) op->o_bd->bd_info;
- overlay_stack *ov = on->on_bi.bi_private;
+ translucent_info *ov = on->on_bi.bi_private;
Debug(LDAP_DEBUG_TRACE, "==> translucent_add: %s\n",
op->o_req_dn.bv_val, 0, 0);
if(!be_isroot(op)) {
op->o_bd->bd_info = (BackendInfo *) on->on_info;
send_ldap_error(op, rs, LDAP_INSUFFICIENT_ACCESS,
"user modification of overlay database not permitted");
+ op->o_bd->bd_info = (BackendInfo *) on;
return(rs->sr_err);
}
- if(!ov->config->glue) glue_parent(op);
+ if(!ov->no_glue) glue_parent(op);
return(SLAP_CB_CONTINUE);
}
/*
** translucent_modrdn()
** if not bound as root, send ACCESS error;
-** if !config.glue, glue_parent();
+** if !glue, glue_parent();
** else return CONTINUE;
**
*/
static int translucent_modrdn(Operation *op, SlapReply *rs) {
slap_overinst *on = (slap_overinst *) op->o_bd->bd_info;
- overlay_stack *ov = on->on_bi.bi_private;
+ translucent_info *ov = on->on_bi.bi_private;
Debug(LDAP_DEBUG_TRACE, "==> translucent_modrdn: %s -> %s\n",
op->o_req_dn.bv_val, op->orr_newrdn.bv_val, 0);
if(!be_isroot(op)) {
op->o_bd->bd_info = (BackendInfo *) on->on_info;
send_ldap_error(op, rs, LDAP_INSUFFICIENT_ACCESS,
"user modification of overlay database not permitted");
+ op->o_bd->bd_info = (BackendInfo *) on;
return(rs->sr_err);
}
- if(!ov->config->glue) glue_parent(op);
+ if(!ov->no_glue) glue_parent(op);
return(SLAP_CB_CONTINUE);
}
@@ -200,6 +271,7 @@ static int translucent_delete(Operation *op, SlapReply *rs) {
op->o_bd->bd_info = (BackendInfo *) on->on_info;
send_ldap_error(op, rs, LDAP_INSUFFICIENT_ACCESS,
"user modification of overlay database not permitted");
+ op->o_bd->bd_info = (BackendInfo *) on;
return(rs->sr_err);
}
return(SLAP_CB_CONTINUE);
@@ -228,8 +300,7 @@ static int translucent_modify(Operation *op, SlapReply *rs) {
Operation nop = *op;
slap_overinst *on = (slap_overinst *) op->o_bd->bd_info;
- overlay_stack *ov = on->on_bi.bi_private;
- void *private = op->o_bd->be_private;
+ translucent_info *ov = on->on_bi.bi_private;
Entry ne, *e = NULL, *re = NULL;
Attribute *a, *ax;
Modifications *m, *mm;
@@ -246,18 +317,14 @@ static int translucent_modify(Operation *op, SlapReply *rs) {
**
*/
- op->o_bd->bd_info = (BackendInfo *) on->on_info;
- op->o_bd->be_private = ov->private;
- rc = ov->info->bi_entry_get_rw(op, &op->o_req_ndn, NULL, NULL, 0, &re);
- op->o_bd->be_private = private;
-
- /* if(ov->config->no_add && (!re || rc != LDAP_SUCCESS)) */
+ nop.o_bd = &ov->db;
+ rc = ov->db.bd_info->bi_entry_get_rw(&nop, &nop.o_req_ndn, NULL, NULL, 0, &re);
if(rc != LDAP_SUCCESS || re == NULL ) {
- send_ldap_error(op, rs, LDAP_NO_SUCH_OBJECT,
+ send_ldap_error((&nop), rs, LDAP_NO_SUCH_OBJECT,
"attempt to modify nonexistent local record");
return(rs->sr_err);
}
-
+ nop = *op;
/*
** fetch entry from local backend;
** if it exists:
@@ -271,7 +338,9 @@ static int translucent_modify(Operation *op, SlapReply *rs) {
**
*/
+ op->o_bd->bd_info = (BackendInfo *) on->on_info;
rc = be_entry_get_rw(op, &op->o_req_ndn, NULL, NULL, 0, &e);
+ op->o_bd->bd_info = (BackendInfo *) on;
if(e && rc == LDAP_SUCCESS) {
Debug(LDAP_DEBUG_TRACE, "=> translucent_modify: found local entry\n", 0, 0, 0);
@@ -287,7 +356,7 @@ static int translucent_modify(Operation *op, SlapReply *rs) {
erc = LDAP_NO_SUCH_ATTRIBUTE;
goto release;
}
- if(ov->config->strict) {
+ if(ov->strict) {
erc = LDAP_CONSTRAINT_VIOLATION;
goto release;
}
@@ -307,16 +376,15 @@ static int translucent_modify(Operation *op, SlapReply *rs) {
erc = SLAP_CB_CONTINUE;
release:
if(re) {
- op->o_bd->be_private = ov->private;
- if(ov->info->bi_entry_release_rw)
- ov->info->bi_entry_release_rw(op, re, 0);
+ if(ov->db.bd_info->bi_entry_release_rw)
+ ov->db.bd_info->bi_entry_release_rw(&nop, re, 0);
else
entry_free(re);
- op->o_bd->be_private = private;
}
+ op->o_bd->bd_info = (BackendInfo *) on->on_info;
be_entry_release_r(op, e);
+ op->o_bd->bd_info = (BackendInfo *) on;
if(erc == SLAP_CB_CONTINUE) {
- op->o_bd->bd_info = (BackendInfo *) on;
return(erc);
} else if(erc) {
send_ldap_error(op, rs, erc,
@@ -327,18 +395,16 @@ release:
/* don't leak remote entry copy */
if(re) {
- op->o_bd->be_private = ov->private;
- if(ov->info->bi_entry_release_rw)
- ov->info->bi_entry_release_rw(op, re, 0);
+ if(ov->db.bd_info->bi_entry_release_rw)
+ ov->db.bd_info->bi_entry_release_rw(&nop, re, 0);
else
entry_free(re);
- op->o_bd->be_private = private;
}
/*
** foreach Modification:
** if MOD_ADD or MOD_REPLACE, add Attribute;
** if no Modifications were suitable:
-** if config.strict, throw CONSTRAINT_VIOLATION;
+** if strict, throw CONSTRAINT_VIOLATION;
** else, return early SUCCESS;
** fabricate Entry with new Attribute chain;
** glue_parent() for this Entry;
@@ -365,7 +431,7 @@ release:
ax = a;
}
- if(del && ov->config->strict) {
+ if(del && ov->strict) {
free_attr_chain(a);
send_ldap_error(op, rs, LDAP_CONSTRAINT_VIOLATION,
"attempt to delete attributes from local database");
@@ -373,12 +439,11 @@ release:
}
if(!ax) {
- if(ov->config->strict) {
+ if(ov->strict) {
send_ldap_error(op, rs, LDAP_CONSTRAINT_VIOLATION,
"modification contained other than ADD or REPLACE");
return(rs->sr_err);
}
- op->o_bd->bd_info = (BackendInfo *) on;
/* rs->sr_text = "no valid modification found"; */
rs->sr_err = LDAP_SUCCESS;
send_ldap_result(op, rs);
@@ -397,7 +462,6 @@ release:
nop.o_tag = LDAP_REQ_ADD;
nop.oq_add.rs_e = ≠
- op->o_bd->bd_info = (BackendInfo *) on;
glue_parent(&nop);
cb.sc_response = translucent_tag_cb;
@@ -411,10 +475,9 @@ release:
}
static int translucent_compare(Operation *op, SlapReply *rs) {
+ Operation nop = *op;
slap_overinst *on = (slap_overinst *) op->o_bd->bd_info;
- overlay_stack *ov = on->on_bi.bi_private;
- void *private = op->o_bd->be_private;
-
+ translucent_info *ov = on->on_bi.bi_private;
AttributeAssertion *ava = op->orc_ava;
Entry *e;
int rc;
@@ -427,7 +490,6 @@ static int translucent_compare(Operation *op, SlapReply *rs) {
** CONTINUE and let it do the compare;
**
*/
-
op->o_bd->bd_info = (BackendInfo *) on->on_info;
rc = be_entry_get_rw(op, &op->o_req_ndn, NULL, ava->aa_desc, 0, &e);
if(e && rc == LDAP_SUCCESS) {
@@ -435,17 +497,17 @@ static int translucent_compare(Operation *op, SlapReply *rs) {
op->o_bd->bd_info = (BackendInfo *) on;
return(SLAP_CB_CONTINUE);
}
+ op->o_bd->bd_info = (BackendInfo *) on;
/*
** call compare() in the captive backend;
** return the result;
**
*/
+ nop.o_bd = &ov->db;
+ nop.o_callback = NULL;
+ rc = ov->db.bd_info->bi_op_compare(&nop, rs);
- op->o_bd->be_private = ov->private;
- rc = ov->info->bi_op_compare(op, rs);
- op->o_bd->be_private = private;
- op->o_bd->bd_info = (BackendInfo *) on;
return(rc);
}
@@ -459,22 +521,22 @@ static int translucent_search_cb(Operation *op, SlapReply *rs) {
slap_overinst *on;
Entry *e, *re = NULL;
Attribute *a, *ax, *an, *as = NULL;
- void *private;
+ Operation * original_op, local_op;
int rc;
if(!op || !rs || rs->sr_type != REP_SEARCH || !rs->sr_entry)
return(SLAP_CB_CONTINUE);
- Debug(LDAP_DEBUG_TRACE, "==> tranclucent_search_cb: %s\n",
+ Debug(LDAP_DEBUG_TRACE, "==> translucent_search_cb: %s\n",
rs->sr_entry->e_name.bv_val, 0, 0);
- on = (slap_overinst *) op->o_bd->bd_info;
- op->o_bd->bd_info = (BackendInfo *) on->on_info;
+ original_op = op->o_callback->sc_private;
+ on = (slap_overinst *) original_op->o_bd->bd_info;
+ local_op = *original_op;
- private = op->o_bd->be_private;
- op->o_bd->be_private = op->o_callback->sc_private;
-
- rc = be_entry_get_rw(op, &rs->sr_entry->e_nname, NULL, NULL, 0, &e);
+ local_op.o_bd->bd_info = (BackendInfo *) on->on_info->oi_orig;
+ rc = be_entry_get_rw(&local_op, &rs->sr_entry->e_nname, NULL, NULL, 0, &e);
+ local_op.o_bd->bd_info = (BackendInfo *) on;
/*
** if we got an entry from local backend:
@@ -509,7 +571,9 @@ static int translucent_search_cb(Operation *op, SlapReply *rs) {
an->a_next = as;
as = an;
}
- be_entry_release_r(op, e);
+ local_op.o_bd->bd_info = (BackendInfo *) on->on_info->oi_orig;
+ be_entry_release_r(&local_op, e);
+ local_op.o_bd->bd_info = (BackendInfo *) on;
/* literally append, so locals are always last */
if(as) {
@@ -524,9 +588,6 @@ static int translucent_search_cb(Operation *op, SlapReply *rs) {
rs->sr_flags |= REP_ENTRY_MUSTBEFREED;
}
- op->o_bd->be_private = private;
- op->o_bd->bd_info = (BackendInfo *) on;
-
return(SLAP_CB_CONTINUE);
}
@@ -538,27 +599,21 @@ static int translucent_search_cb(Operation *op, SlapReply *rs) {
*/
static int translucent_search(Operation *op, SlapReply *rs) {
- Operation nop = *op;
-
slap_overinst *on = (slap_overinst *) op->o_bd->bd_info;
+ Operation nop = *op;
+ translucent_info *ov = on->on_bi.bi_private;
slap_callback cb = { NULL, NULL, NULL, NULL };
- overlay_stack *ov = on->on_bi.bi_private;
- void *private = op->o_bd->be_private;
- int rc;
Debug(LDAP_DEBUG_TRACE, "==> translucent_search: <%s> %s\n",
op->o_req_dn.bv_val, op->ors_filterstr.bv_val, 0);
- cb.sc_response = (slap_response *) translucent_search_cb;
- cb.sc_private = private;
+ cb.sc_response = (slap_response *) translucent_search_cb;
+ cb.sc_private = op;
cb.sc_next = nop.o_callback;
- nop.o_callback = &cb;
- op->o_bd->be_private = ov->private;
- rc = ov->info->bi_op_search(&nop, rs);
- op->o_bd->be_private = private;
-
- return(rs->sr_err);
+ nop.o_callback = &cb;
+ nop.o_bd = &ov->db;
+ return (ov->db.bd_info->bi_op_search(&nop, rs));
}
@@ -570,18 +625,14 @@ static int translucent_search(Operation *op, SlapReply *rs) {
static int translucent_bind(Operation *op, SlapReply *rs) {
slap_overinst *on = (slap_overinst *) op->o_bd->bd_info;
- overlay_stack *ov = on->on_bi.bi_private;
- void *private = op->o_bd->be_private;
- int rc = 0;
+ Operation nop = *op;
+ translucent_info *ov = on->on_bi.bi_private;
Debug(LDAP_DEBUG_TRACE, "translucent_bind: <%s> method %d\n",
op->o_req_dn.bv_val, op->orb_method, 0);
- op->o_bd->be_private = ov->private;
- rc = ov->info->bi_op_bind(op, rs);
- op->o_bd->be_private = private;
-
- return(rc);
+ nop.o_bd = &ov->db;
+ return (ov->db.bd_info->bi_op_bind(&nop, rs));
}
/*
@@ -592,15 +643,12 @@ static int translucent_bind(Operation *op, SlapReply *rs) {
static int translucent_connection_destroy(BackendDB *be, Connection *conn) {
slap_overinst *on = (slap_overinst *) be->bd_info;
- overlay_stack *ov = on->on_bi.bi_private;
- void *private = be->be_private;
+ translucent_info *ov = on->on_bi.bi_private;
int rc = 0;
Debug(LDAP_DEBUG_TRACE, "translucent_connection_destroy\n", 0, 0, 0);
- be->be_private = ov->private;
- rc = ov->info->bi_connection_destroy(be, conn);
- be->be_private = private;
+ rc = ov->db.bd_info->bi_connection_destroy(&ov->db, conn);
return(rc);
}
@@ -621,55 +669,16 @@ static int translucent_db_config(
)
{
slap_overinst *on = (slap_overinst *) be->bd_info;
- overlay_stack *ov = on->on_bi.bi_private;
- void *private = be->be_private;
- void *be_cf_ocs = be->be_cf_ocs;
- int rc;
+ translucent_info *ov = on->on_bi.bi_private;
- /* "this should never happen" */
- if(!ov->info) {
- fprintf(stderr, "fatal: captive backend not initialized");
- return(1);
- }
+ Debug(LDAP_DEBUG_TRACE, "==> translucent_db_config: %s\n",
+ argc ? argv[0] : "", 0, 0);
- be->be_private = ov->private;
- be->be_cf_ocs = ov->info->bi_cf_ocs;
- rc = ov->info->bi_db_config ? ov->info->bi_db_config(be, fname, lineno, argc, argv) : 0;
- be->be_private = private;
- be->be_cf_ocs = be_cf_ocs;
-
- /* pass okay or error up, SLAP_CONF_UNKNOWN might be ours */
- if(rc == 0 || rc == 1) return(rc);
-
- rc = 0;
- if(!strcasecmp(*argv, "translucent_strict")) {
- ov->config->strict++;
- } else if(!strcasecmp(*argv, "translucent_no_add")) {
- ov->config->no_add++;
- } else if(!strcasecmp(*argv, "translucent_no_glue")) {
- ov->config->glue++;
- } else if(!strcasecmp(*argv, "translucent_debug")) {
- if(argc == 1) {
- ov->config->debug = 0xFFFF;
- rc = 0;
- } else if(argc == 2) {
- if ( lutil_atoi( &ov->config->debug, argv[1]) != 0 ) {
- fprintf(stderr, "%s: line %d: unable to parse debug \"%s\"\n",
- fname, lineno, argv[1]);
- return 1;
- }
- rc = 0;
- } else {
- fprintf(stderr, "%s: line %d: too many arguments (%d) to debug\n",
- fname, lineno, argc);
- rc = 1;
- }
- } else {
- fprintf(stderr, "%s: line %d: unknown keyword %s\n",
- fname, lineno, *argv);
- rc = SLAP_CONF_UNKNOWN;
- }
- return(rc);
+ /* Something for the captive database? */
+ if ( ov->db.bd_info && ov->db.bd_info->bi_db_config )
+ return ov->db.bd_info->bi_db_config( &ov->db, fname, lineno,
+ argc, argv );
+ return SLAP_CONF_UNKNOWN;
}
/*
@@ -680,35 +689,25 @@ static int translucent_db_config(
static int translucent_db_init(BackendDB *be) {
slap_overinst *on = (slap_overinst *) be->bd_info;
- void *private = be->be_private;
- overlay_stack *ov;
+ translucent_info *ov;
int rc;
- Debug(LDAP_DEBUG_TRACE, "==> translucent_init\n", 0, 0, 0);
+ Debug(LDAP_DEBUG_TRACE, "==> translucent_db_init\n", 0, 0, 0);
- ov = ch_calloc(1, sizeof(overlay_stack));
- ov->config = ch_calloc(1, sizeof(translucent_configuration));
- ov->info = backend_info("ldap");
+ ov = ch_calloc(1, sizeof(translucent_info));
+ on->on_bi.bi_private = ov;
+ ov->db = *be;
+ ov->db.be_private = NULL;
+ ov->db.be_pcl_mutexp = &ov->db.be_pcl_mutex;
- if(!ov->info) {
- ch_free( ov );
- Debug(LDAP_DEBUG_ANY, "translucent: backend_info failed!\n", 0, 0, 0);
- return(1);
+ if ( !backend_db_init( "ldap", &ov->db )) {
+ Debug( LDAP_DEBUG_CONFIG, "translucent: unable to open captive back-ldap\n", 0, 0, 0);
+ return 1;
}
-
- /* forcibly disable schema checking on the local backend */
SLAP_DBFLAGS(be) |= SLAP_DBFLAG_NO_SCHEMA_CHECK;
+ SLAP_DBFLAGS(be) |= SLAP_DBFLAG_NOLASTMOD;
- be->be_private = NULL;
- rc = ov->info->bi_db_init ? ov->info->bi_db_init(be) : 0;
-
- if(rc) Debug(LDAP_DEBUG_TRACE,
- "translucent: bi_db_init() returned error %d\n", rc, 0, 0);
-
- ov->private = be->be_private;
- be->be_private = private;
- on->on_bi.bi_private = ov;
- return(rc);
+ return 0;
}
/*
@@ -719,21 +718,18 @@ static int translucent_db_init(BackendDB *be) {
static int translucent_db_open(BackendDB *be) {
slap_overinst *on = (slap_overinst *) be->bd_info;
- overlay_stack *ov = on->on_bi.bi_private;
- void *private = be->be_private;
+ translucent_info *ov = on->on_bi.bi_private;
int rc;
- /* "should never happen" */
- if(!ov->info) {
- Debug(LDAP_DEBUG_ANY, "translucent_open() called with bad ov->info\n", 0, 0, 0);
- return(LDAP_OTHER);
- }
+ Debug(LDAP_DEBUG_TRACE, "==> translucent_db_open\n", 0, 0, 0);
- Debug(LDAP_DEBUG_TRACE, "translucent_open\n", 0, 0, 0);
+ /* need to inherit something from the original database... */
+ ov->db.be_def_limit = be->be_def_limit;
+ ov->db.be_limits = be->be_limits;
+ ov->db.be_acl = be->be_acl;
+ ov->db.be_dfltaccess = be->be_dfltaccess;
- be->be_private = ov->private;
- rc = ov->info->bi_db_open ? ov->info->bi_db_open(be) : 0;
- be->be_private = private;
+ rc = backend_startup_one( &ov->db );
if(rc) Debug(LDAP_DEBUG_TRACE,
"translucent: bi_db_open() returned error %d\n", rc, 0, 0);
@@ -750,17 +746,13 @@ static int translucent_db_open(BackendDB *be) {
static int translucent_db_close(BackendDB *be) {
slap_overinst *on = (slap_overinst *) be->bd_info;
- overlay_stack *ov = on->on_bi.bi_private;
+ translucent_info *ov = on->on_bi.bi_private;
int rc = 0;
- if ( ov ) {
- void *private = be->be_private;
+ Debug(LDAP_DEBUG_TRACE, "==> translucent_db_close\n", 0, 0, 0);
- be->be_private = ov->private;
- rc = (ov->info && ov->info->bi_db_close) ? ov->info->bi_db_close(be) : 0;
- be->be_private = private;
- if(ov->config) ch_free(ov->config);
- ov->config = NULL;
+ if ( ov ) {
+ rc = (ov->db.bd_info && ov->db.bd_info->bi_db_close) ? ov->db.bd_info->bi_db_close(&ov->db) : 0;
}
return(rc);
@@ -774,15 +766,13 @@ static int translucent_db_close(BackendDB *be) {
static int translucent_db_destroy(BackendDB *be) {
slap_overinst *on = (slap_overinst *) be->bd_info;
- overlay_stack *ov = on->on_bi.bi_private;
+ translucent_info *ov = on->on_bi.bi_private;
int rc = 0;
- if ( ov ) {
- void *private = be->be_private;
+ Debug(LDAP_DEBUG_TRACE, "==> translucent_db_close\n", 0, 0, 0);
- be->be_private = ov->private;
- rc = (ov->info && ov->info->bi_db_destroy) ? ov->info->bi_db_destroy(be) : 0;
- be->be_private = private;
+ if ( ov ) {
+ rc = (ov->db.bd_info && ov->db.bd_info->bi_db_destroy) ? ov->db.bd_info->bi_db_destroy(&ov->db) : 0;
ch_free(ov);
on->on_bi.bi_private = NULL;
}
@@ -798,6 +788,10 @@ static int translucent_db_destroy(BackendDB *be) {
int translucent_initialize() {
+ int rc;
+
+ Debug(LDAP_DEBUG_TRACE, "==> translucent_initialize\n", 0, 0, 0);
+
translucent.on_bi.bi_type = "translucent";
translucent.on_bi.bi_db_init = translucent_db_init;
translucent.on_bi.bi_db_config = translucent_db_config;
@@ -813,6 +807,10 @@ int translucent_initialize() {
translucent.on_bi.bi_op_compare = translucent_compare;
translucent.on_bi.bi_connection_destroy = translucent_connection_destroy;
+ translucent.on_bi.bi_cf_ocs = translucentocs;
+ rc = config_register_schema ( translucentcfg, translucentocs );
+ if ( rc ) return rc;
+
return(overlay_register(&translucent));
}
@@ -823,4 +821,3 @@ int init_module(int argc, char *argv[]) {
#endif
#endif /* SLAPD_OVER_TRANSLUCENT */
-
diff --git a/servers/slapd/proto-slap.h b/servers/slapd/proto-slap.h
index 5a8bb9c5d605d6d7f086a0ee800a747e5e7dfabb..99934a9f80b9664d59c55be93c770a888d274825 100644
--- a/servers/slapd/proto-slap.h
+++ b/servers/slapd/proto-slap.h
@@ -589,6 +589,8 @@ LDAP_SLAPD_F (int) read_config LDAP_P(( const char *fname, const char *dir ));
LDAP_SLAPD_F (void) config_destroy LDAP_P ((void));
LDAP_SLAPD_F (char **) slap_str2clist LDAP_P((
char ***, char *, const char * ));
+LDAP_SLAPD_F (int) bverb_to_mask LDAP_P((
+ struct berval *bword, slap_verbmasks *v ));
LDAP_SLAPD_F (int) verb_to_mask LDAP_P((
const char *word, slap_verbmasks *v ));
LDAP_SLAPD_F (int) verbs_to_mask LDAP_P((
@@ -608,6 +610,7 @@ LDAP_SLAPD_F (int) bindconf_unparse LDAP_P((
LDAP_SLAPD_F (int) bindconf_tls_set LDAP_P((
slap_bindconf *bc, LDAP *ld ));
LDAP_SLAPD_F (void) bindconf_free LDAP_P(( slap_bindconf *bc ));
+LDAP_SLAPD_F (int) slap_client_connect LDAP_P(( LDAP **ldp, slap_bindconf *sb, int version ));
LDAP_SLAPD_F (int) config_generic_wrapper LDAP_P(( Backend *be,
const char *fname, int lineno, int argc, char **argv ));
LDAP_SLAPD_F (char *) anlist_unparse LDAP_P(( AttributeName *, char *, ber_len_t buflen ));
@@ -695,7 +698,7 @@ LDAP_SLAPD_F (ContentRule *) cr_bvfind LDAP_P((
LDAP_SLAPD_V( const struct berval ) slap_ldapsync_bv;
LDAP_SLAPD_V( const struct berval ) slap_ldapsync_cn_bv;
LDAP_SLAPD_F (void) slap_get_commit_csn LDAP_P((
- Operation *, struct berval *maxcsn, struct berval *curcsn ));
+ Operation *, struct berval *maxcsn ));
LDAP_SLAPD_F (void) slap_rewind_commit_csn LDAP_P(( Operation * ));
LDAP_SLAPD_F (void) slap_graduate_commit_csn LDAP_P(( Operation * ));
LDAP_SLAPD_F (Entry *) slap_create_context_csn_entry LDAP_P(( Backend *, struct berval *));
@@ -727,7 +730,7 @@ LDAP_SLAPD_F (int) slapd_clr_read LDAP_P((ber_socket_t s, int wake));
LDAP_SLAPD_V (volatile sig_atomic_t) slapd_abrupt_shutdown;
LDAP_SLAPD_V (volatile sig_atomic_t) slapd_shutdown;
LDAP_SLAPD_V (int) slapd_register_slp;
-LDAP_SLAPD_V (char *) slapd_slp_attrs;
+LDAP_SLAPD_V (const char *) slapd_slp_attrs;
LDAP_SLAPD_V (slap_ssf_t) local_ssf;
LDAP_SLAPD_V (struct runqueue_s) slapd_rq;
@@ -1021,6 +1024,10 @@ LDAP_SLAPD_F (int) lock_fclose LDAP_P(( FILE *fp, FILE *lfp ));
LDAP_SLAPD_F (int)
parse_debug_level LDAP_P(( const char *arg, int *levelp, char ***unknowns ));
LDAP_SLAPD_F (int)
+parse_syslog_level LDAP_P(( const char *arg, int *levelp ));
+LDAP_SLAPD_F (int)
+parse_syslog_user LDAP_P(( const char *arg, int *syslogUser ));
+LDAP_SLAPD_F (int)
parse_debug_unknowns LDAP_P(( char **unknowns, int *levelp ));
/*
diff --git a/servers/slapd/schema_prep.c b/servers/slapd/schema_prep.c
index 881ca16251e8569b3733b3da87b5b9c5db0d473d..85717e2c04a70fd006ed89ea1381f4c85dcd6e44 100644
--- a/servers/slapd/schema_prep.c
+++ b/servers/slapd/schema_prep.c
@@ -338,12 +338,12 @@ static struct slap_schema_oc_map {
0, 0, offsetof(struct slap_internal_schema, si_oc_top) },
{ "extensibleObject", "( 1.3.6.1.4.1.1466.101.120.111 "
"NAME 'extensibleObject' "
- "DESC 'RFC2252: extensible object' "
+ "DESC 'RFC4512: extensible object' "
"SUP top AUXILIARY )",
0, SLAP_OC_OPERATIONAL,
offsetof(struct slap_internal_schema, si_oc_extensibleObject) },
{ "alias", "( 2.5.6.1 NAME 'alias' "
- "DESC 'RFC2256: an alias' "
+ "DESC 'RFC4512: an alias' "
"SUP top STRUCTURAL "
"MUST aliasedObjectName )",
aliasObjectClass, SLAP_OC_ALIAS|SLAP_OC_OPERATIONAL,
@@ -360,12 +360,13 @@ static struct slap_schema_oc_map {
rootDseObjectClass, SLAP_OC_OPERATIONAL,
offsetof(struct slap_internal_schema, si_oc_rootdse) },
{ "subentry", "( 2.5.17.0 NAME 'subentry' "
+ "DESC 'RFC3672: subentry' "
"SUP top STRUCTURAL "
"MUST ( cn $ subtreeSpecification ) )",
subentryObjectClass, SLAP_OC_SUBENTRY|SLAP_OC_OPERATIONAL,
offsetof(struct slap_internal_schema, si_oc_subentry) },
{ "subschema", "( 2.5.20.1 NAME 'subschema' "
- "DESC 'RFC2252: controlling subschema (sub)entry' "
+ "DESC 'RFC4512: controlling subschema (sub)entry' "
"AUXILIARY "
"MAY ( dITStructureRules $ nameForms $ ditContentRules $ "
"objectClasses $ attributeTypes $ matchingRules $ "
@@ -438,7 +439,7 @@ static struct slap_schema_ad_map {
size_t ssam_offset;
} ad_map[] = {
{ "objectClass", "( 2.5.4.0 NAME 'objectClass' "
- "DESC 'RFC2256: object classes of the entity' "
+ "DESC 'RFC4512: object classes of the entity' "
"EQUALITY objectIdentifierMatch "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )",
NULL, SLAP_AT_FINAL,
@@ -449,7 +450,7 @@ static struct slap_schema_ad_map {
/* user entry operational attributes */
{ "structuralObjectClass", "( 2.5.21.9 NAME 'structuralObjectClass' "
- "DESC 'X.500(93): structural object class of entry' "
+ "DESC 'RFC4512: structural object class of entry' "
"EQUALITY objectIdentifierMatch "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 "
"SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )",
@@ -459,7 +460,7 @@ static struct slap_schema_ad_map {
objectSubClassIndexer, objectSubClassFilter,
offsetof(struct slap_internal_schema, si_ad_structuralObjectClass) },
{ "createTimestamp", "( 2.5.18.1 NAME 'createTimestamp' "
- "DESC 'RFC2252: time which object was created' "
+ "DESC 'RFC4512: time which object was created' "
"EQUALITY generalizedTimeMatch "
"ORDERING generalizedTimeOrderingMatch "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 "
@@ -469,7 +470,7 @@ static struct slap_schema_ad_map {
NULL, NULL, NULL, NULL, NULL,
offsetof(struct slap_internal_schema, si_ad_createTimestamp) },
{ "modifyTimestamp", "( 2.5.18.2 NAME 'modifyTimestamp' "
- "DESC 'RFC2252: time which object was last modified' "
+ "DESC 'RFC4512: time which object was last modified' "
"EQUALITY generalizedTimeMatch "
"ORDERING generalizedTimeOrderingMatch "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 "
@@ -479,7 +480,7 @@ static struct slap_schema_ad_map {
NULL, NULL, NULL, NULL, NULL,
offsetof(struct slap_internal_schema, si_ad_modifyTimestamp) },
{ "creatorsName", "( 2.5.18.3 NAME 'creatorsName' "
- "DESC 'RFC2252: name of creator' "
+ "DESC 'RFC4512: name of creator' "
"EQUALITY distinguishedNameMatch "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 "
"SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )",
@@ -488,7 +489,7 @@ static struct slap_schema_ad_map {
NULL, NULL, NULL, NULL, NULL,
offsetof(struct slap_internal_schema, si_ad_creatorsName) },
{ "modifiersName", "( 2.5.18.4 NAME 'modifiersName' "
- "DESC 'RFC2252: name of last modifier' "
+ "DESC 'RFC4512: name of last modifier' "
"EQUALITY distinguishedNameMatch "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 "
"SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )",
@@ -506,7 +507,7 @@ static struct slap_schema_ad_map {
NULL, NULL, NULL, NULL, NULL,
offsetof(struct slap_internal_schema, si_ad_hasSubordinates) },
{ "subschemaSubentry", "( 2.5.18.10 NAME 'subschemaSubentry' "
- "DESC 'RFC2252: name of controlling subschema entry' "
+ "DESC 'RFC4512: name of controlling subschema entry' "
"EQUALITY distinguishedNameMatch "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE "
"NO-USER-MODIFICATION USAGE directoryOperation )",
@@ -628,7 +629,7 @@ static struct slap_schema_ad_map {
/* root DSE attributes */
{ "altServer", "( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer' "
- "DESC 'RFC2252: alternative servers' "
+ "DESC 'RFC4512: alternative servers' "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 USAGE dSAOperation )",
rootDseAttribute, 0,
NULL, NULL,
@@ -636,7 +637,7 @@ static struct slap_schema_ad_map {
offsetof(struct slap_internal_schema, si_ad_altServer) },
{ "namingContexts", "( 1.3.6.1.4.1.1466.101.120.5 "
"NAME 'namingContexts' "
- "DESC 'RFC2252: naming contexts' "
+ "DESC 'RFC4512: naming contexts' "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 USAGE dSAOperation )",
rootDseAttribute, 0,
NULL, NULL,
@@ -644,7 +645,7 @@ static struct slap_schema_ad_map {
offsetof(struct slap_internal_schema, si_ad_namingContexts) },
{ "supportedControl", "( 1.3.6.1.4.1.1466.101.120.13 "
"NAME 'supportedControl' "
- "DESC 'RFC2252: supported controls' "
+ "DESC 'RFC4512: supported controls' "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation )",
rootDseAttribute, 0,
NULL, NULL,
@@ -652,7 +653,7 @@ static struct slap_schema_ad_map {
offsetof(struct slap_internal_schema, si_ad_supportedControl) },
{ "supportedExtension", "( 1.3.6.1.4.1.1466.101.120.7 "
"NAME 'supportedExtension' "
- "DESC 'RFC2252: supported extended operations' "
+ "DESC 'RFC4512: supported extended operations' "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation )",
rootDseAttribute, 0,
NULL, NULL,
@@ -660,7 +661,7 @@ static struct slap_schema_ad_map {
offsetof(struct slap_internal_schema, si_ad_supportedExtension) },
{ "supportedLDAPVersion", "( 1.3.6.1.4.1.1466.101.120.15 "
"NAME 'supportedLDAPVersion' "
- "DESC 'RFC2252: supported LDAP versions' "
+ "DESC 'RFC4512: supported LDAP versions' "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 USAGE dSAOperation )",
rootDseAttribute, 0,
NULL, NULL,
@@ -668,7 +669,7 @@ static struct slap_schema_ad_map {
offsetof(struct slap_internal_schema, si_ad_supportedLDAPVersion) },
{ "supportedSASLMechanisms", "( 1.3.6.1.4.1.1466.101.120.14 "
"NAME 'supportedSASLMechanisms' "
- "DESC 'RFC2252: supported SASL mechanisms'"
+ "DESC 'RFC4512: supported SASL mechanisms'"
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE dSAOperation )",
rootDseAttribute, 0,
NULL, NULL,
@@ -676,7 +677,7 @@ static struct slap_schema_ad_map {
offsetof(struct slap_internal_schema, si_ad_supportedSASLMechanisms) },
{ "supportedFeatures", "( 1.3.6.1.4.1.4203.1.3.5 "
"NAME 'supportedFeatures' "
- "DESC 'features supported by the server' "
+ "DESC 'RFC4512: features supported by the server' "
"EQUALITY objectIdentifierMatch "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 "
"USAGE dSAOperation )",
@@ -727,6 +728,7 @@ static struct slap_schema_ad_map {
/* subentry attributes */
{ "administrativeRole", "( 2.5.18.5 NAME 'administrativeRole' "
+ "DESC 'RFC3672: administrative role' "
"EQUALITY objectIdentifierMatch "
"USAGE directoryOperation "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )",
@@ -735,6 +737,7 @@ static struct slap_schema_ad_map {
NULL, NULL, NULL, NULL, NULL,
offsetof(struct slap_internal_schema, si_ad_administrativeRole) },
{ "subtreeSpecification", "( 2.5.18.6 NAME 'subtreeSpecification' "
+ "DESC 'RFC3672: subtree specification' "
"SINGLE-VALUE "
"USAGE directoryOperation "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.45 )",
@@ -745,7 +748,7 @@ static struct slap_schema_ad_map {
/* subschema subentry attributes */
{ "ditStructureRules", "( 2.5.21.1 NAME 'dITStructureRules' "
- "DESC 'RFC2252: DIT structure rules' "
+ "DESC 'RFC4512: DIT structure rules' "
"EQUALITY integerFirstComponentMatch "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.17 "
"USAGE directoryOperation ) ",
@@ -754,7 +757,7 @@ static struct slap_schema_ad_map {
NULL, NULL, NULL, NULL, NULL,
offsetof(struct slap_internal_schema, si_ad_ditStructureRules) },
{ "ditContentRules", "( 2.5.21.2 NAME 'dITContentRules' "
- "DESC 'RFC2252: DIT content rules' "
+ "DESC 'RFC4512: DIT content rules' "
"EQUALITY objectIdentifierFirstComponentMatch "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.16 USAGE directoryOperation )",
subentryAttribute, SLAP_AT_HIDE,
@@ -762,7 +765,7 @@ static struct slap_schema_ad_map {
NULL, NULL, objectClassMatch, NULL, NULL,
offsetof(struct slap_internal_schema, si_ad_ditContentRules) },
{ "matchingRules", "( 2.5.21.4 NAME 'matchingRules' "
- "DESC 'RFC2252: matching rules' "
+ "DESC 'RFC4512: matching rules' "
"EQUALITY objectIdentifierFirstComponentMatch "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.30 USAGE directoryOperation )",
subentryAttribute, 0,
@@ -770,7 +773,7 @@ static struct slap_schema_ad_map {
NULL, NULL, matchingRuleMatch, NULL, NULL,
offsetof(struct slap_internal_schema, si_ad_matchingRules) },
{ "attributeTypes", "( 2.5.21.5 NAME 'attributeTypes' "
- "DESC 'RFC2252: attribute types' "
+ "DESC 'RFC4512: attribute types' "
"EQUALITY objectIdentifierFirstComponentMatch "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.3 USAGE directoryOperation )",
subentryAttribute, 0,
@@ -778,7 +781,7 @@ static struct slap_schema_ad_map {
NULL, NULL, attributeTypeMatch, NULL, NULL,
offsetof(struct slap_internal_schema, si_ad_attributeTypes) },
{ "objectClasses", "( 2.5.21.6 NAME 'objectClasses' "
- "DESC 'RFC2252: object classes' "
+ "DESC 'RFC4512: object classes' "
"EQUALITY objectIdentifierFirstComponentMatch "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.37 USAGE directoryOperation )",
subentryAttribute, 0,
@@ -786,7 +789,7 @@ static struct slap_schema_ad_map {
NULL, NULL, objectClassMatch, NULL, NULL,
offsetof(struct slap_internal_schema, si_ad_objectClasses) },
{ "nameForms", "( 2.5.21.7 NAME 'nameForms' "
- "DESC 'RFC2252: name forms ' "
+ "DESC 'RFC4512: name forms ' "
"EQUALITY objectIdentifierFirstComponentMatch "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.35 USAGE directoryOperation )",
subentryAttribute, SLAP_AT_HIDE,
@@ -794,7 +797,7 @@ static struct slap_schema_ad_map {
NULL, NULL, NULL, NULL, NULL,
offsetof(struct slap_internal_schema, si_ad_nameForms) },
{ "matchingRuleUse", "( 2.5.21.8 NAME 'matchingRuleUse' "
- "DESC 'RFC2252: matching rule uses' "
+ "DESC 'RFC4512: matching rule uses' "
"EQUALITY objectIdentifierFirstComponentMatch "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.31 USAGE directoryOperation )",
subentryAttribute, 0,
@@ -803,7 +806,7 @@ static struct slap_schema_ad_map {
offsetof(struct slap_internal_schema, si_ad_matchingRuleUse) },
{ "ldapSyntaxes", "( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes' "
- "DESC 'RFC2252: LDAP syntaxes' "
+ "DESC 'RFC4512: LDAP syntaxes' "
"EQUALITY objectIdentifierFirstComponentMatch "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.54 USAGE directoryOperation )",
subentryAttribute, 0,
@@ -814,7 +817,7 @@ static struct slap_schema_ad_map {
/* knowledge information */
{ "aliasedObjectName", "( 2.5.4.1 "
"NAME ( 'aliasedObjectName' 'aliasedEntryName' ) "
- "DESC 'RFC2256: name of aliased object' "
+ "DESC 'RFC4512: name of aliased object' "
"EQUALITY distinguishedNameMatch "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )",
aliasAttribute, SLAP_AT_FINAL,
@@ -822,7 +825,7 @@ static struct slap_schema_ad_map {
NULL, NULL, NULL, NULL, NULL,
offsetof(struct slap_internal_schema, si_ad_aliasedObjectName) },
{ "ref", "( 2.16.840.1.113730.3.1.34 NAME 'ref' "
- "DESC 'namedref: subordinate referral URL' "
+ "DESC 'RFC3296: subordinate referral URL' "
"EQUALITY caseExactMatch "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 "
"USAGE distributedOperation )",
@@ -897,7 +900,7 @@ static struct slap_schema_ad_map {
/* userApplication attributes (which system schema depends upon) */
{ "distinguishedName", "( 2.5.4.49 NAME 'distinguishedName' "
- "DESC 'RFC2256: common supertype of DN attributes' "
+ "DESC 'RFC4519: common supertype of DN attributes' "
"EQUALITY distinguishedNameMatch "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )",
NULL, SLAP_AT_ABSTRACT,
@@ -905,7 +908,7 @@ static struct slap_schema_ad_map {
NULL, NULL, NULL, NULL, NULL,
offsetof(struct slap_internal_schema, si_ad_distinguishedName) },
{ "name", "( 2.5.4.41 NAME 'name' "
- "DESC 'RFC2256: common supertype of name attributes' "
+ "DESC 'RFC4519: common supertype of name attributes' "
"EQUALITY caseIgnoreMatch "
"SUBSTR caseIgnoreSubstringsMatch "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )",
@@ -914,14 +917,14 @@ static struct slap_schema_ad_map {
NULL, NULL, NULL, NULL, NULL,
offsetof(struct slap_internal_schema, si_ad_name) },
{ "cn", "( 2.5.4.3 NAME ( 'cn' 'commonName' ) "
- "DESC 'RFC2256: common name(s) for which the entity is known by' "
+ "DESC 'RFC4519: common name(s) for which the entity is known by' "
"SUP name )",
NULL, 0,
NULL, NULL,
NULL, NULL, NULL, NULL, NULL,
offsetof(struct slap_internal_schema, si_ad_cn) },
{ "uid", "( 0.9.2342.19200300.100.1.1 NAME ( 'uid' 'userid' ) "
- "DESC 'RFC1274: user identifier' "
+ "DESC 'RFC4519: user identifier' "
"EQUALITY caseIgnoreMatch "
"SUBSTR caseIgnoreSubstringsMatch "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )",
@@ -931,7 +934,7 @@ static struct slap_schema_ad_map {
offsetof(struct slap_internal_schema, si_ad_uid) },
{ "uidNumber", /* for ldapi:// */
"( 1.3.6.1.1.1.1.0 NAME 'uidNumber' "
- "DESC 'An integer uniquely identifying a user "
+ "DESC 'RFC2307: An integer uniquely identifying a user "
"in an administrative domain' "
"EQUALITY integerMatch "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )",
@@ -941,7 +944,7 @@ static struct slap_schema_ad_map {
offsetof(struct slap_internal_schema, si_ad_uidNumber) },
{ "gidNumber", /* for ldapi:// */
"( 1.3.6.1.1.1.1.1 NAME 'gidNumber' "
- "DESC 'An integer uniquely identifying a group "
+ "DESC 'RFC2307: An integer uniquely identifying a group "
"in an administrative domain' "
"EQUALITY integerMatch "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )",
@@ -950,7 +953,7 @@ static struct slap_schema_ad_map {
NULL, NULL, NULL, NULL, NULL,
offsetof(struct slap_internal_schema, si_ad_gidNumber) },
{ "userPassword", "( 2.5.4.35 NAME 'userPassword' "
- "DESC 'RFC2256/2307: password of user' "
+ "DESC 'RFC4519/2307: password of user' "
"EQUALITY octetStringMatch "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )",
NULL, 0,
@@ -1002,7 +1005,7 @@ static struct slap_schema_ad_map {
#endif
{ "description", "( 2.5.4.13 NAME 'description' "
- "DESC 'RFC2256: descriptive information' "
+ "DESC 'RFC4519: descriptive information' "
"EQUALITY caseIgnoreMatch "
"SUBSTR caseIgnoreSubstringsMatch "
"SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} )",
@@ -1012,7 +1015,7 @@ static struct slap_schema_ad_map {
offsetof(struct slap_internal_schema, si_ad_description) },
{ "seeAlso", "( 2.5.4.34 NAME 'seeAlso' "
- "DESC 'RFC2256: DN of related object' "
+ "DESC 'RFC4519: DN of related object' "
"SUP distinguishedName )",
NULL, 0,
NULL, NULL,
diff --git a/servers/slapd/slap.h b/servers/slapd/slap.h
index adfb0167467a764812fdcec7f5af7e594784b2b7..9177407c7679c109df5c936adf4c9ede90884a5f 100644
--- a/servers/slapd/slap.h
+++ b/servers/slapd/slap.h
@@ -71,6 +71,7 @@ LDAP_BEGIN_DECL
#define LDAP_DYNAMIC_OBJECTS
#define SLAP_CONTROL_X_TREE_DELETE LDAP_CONTROL_X_TREE_DELETE
+#define SLAP_DISTPROC
#ifdef ENABLE_REWRITE
#define SLAP_AUTH_REWRITE 1 /* use librewrite for sasl-regexp */
@@ -1448,23 +1449,18 @@ typedef enum {
} slap_acl_state_t;
typedef struct slap_acl_state {
- slap_acl_state_t as_recorded;
-
/* Access state */
- AccessControl *as_vd_acl;
AccessControl *as_vi_acl;
- slap_mask_t as_vd_acl_mask;
- regmatch_t as_vd_acl_matches[MAXREMATCHES];
- int as_vd_acl_count;
+ AccessControl *as_vd_acl;
+ AttributeDescription *as_vd_ad;
- Access *as_vd_access;
- int as_vd_access_count;
+ slap_acl_state_t as_recorded;
+ int as_vd_acl_count;
int as_result;
- AttributeDescription *as_vd_ad;
} AccessControlState;
-#define ACL_STATE_INIT { ACL_STATE_NOT_RECORDED, NULL, NULL, 0UL, \
- { { 0, 0 } }, 0, NULL, 0, 0, NULL }
+#define ACL_STATE_INIT { NULL, NULL, NULL, \
+ ACL_STATE_NOT_RECORDED, 0, 0 }
/*
* Backend-info
@@ -1698,6 +1694,7 @@ struct slap_backend_db {
/* Database flags */
#define SLAP_DBFLAG_NOLASTMOD 0x0001U
#define SLAP_DBFLAG_NO_SCHEMA_CHECK 0x0002U
+#define SLAP_DBFLAG_HIDDEN 0x0004U
#define SLAP_DBFLAG_GLUE_INSTANCE 0x0010U /* a glue backend */
#define SLAP_DBFLAG_GLUE_SUBORDINATE 0x0020U /* child of a glue hierarchy */
#define SLAP_DBFLAG_GLUE_LINKED 0x0040U /* child is connected to parent */
@@ -1713,6 +1710,7 @@ struct slap_backend_db {
#define SLAP_DBFLAGS(be) ((be)->be_flags)
#define SLAP_NOLASTMOD(be) (SLAP_DBFLAGS(be) & SLAP_DBFLAG_NOLASTMOD)
#define SLAP_LASTMOD(be) (!SLAP_NOLASTMOD(be))
+#define SLAP_DBHIDDEN(be) (SLAP_DBFLAGS(be) & SLAP_DBFLAG_HIDDEN)
#define SLAP_ISOVERLAY(be) (SLAP_DBFLAGS(be) & SLAP_DBFLAG_OVERLAY)
#define SLAP_ISGLOBALOVERLAY(be) (SLAP_DBFLAGS(be) & SLAP_DBFLAG_GLOBAL_OVERLAY)
#define SLAP_NO_SCHEMA_CHECK(be) \
@@ -2442,6 +2440,8 @@ typedef struct slap_op {
char o_delete_glue_parent;
char o_no_schema_check;
#define get_no_schema_check(op) ((op)->o_no_schema_check)
+ char o_no_subordinate_glue;
+#define get_no_subordinate_glue(op) ((op)->o_no_subordinate_glue)
#define SLAP_CONTROL_NONE 0
#define SLAP_CONTROL_IGNORED 1
@@ -2681,21 +2681,27 @@ typedef struct slap_conn {
SEND_LDAP_INTERMEDIATE *c_send_ldap_intermediate;
} Connection;
-#if defined(LDAP_SYSLOG) && defined(LDAP_DEBUG)
+#ifdef LDAP_DEBUG
+#ifdef LDAP_SYSLOG
+#ifdef LOG_LOCAL4
+#define SLAP_DEFAULT_SYSLOG_USER LOG_LOCAL4
+#endif /* LOG_LOCAL4 */
+
#define Statslog( level, fmt, connid, opid, arg1, arg2, arg3 ) \
Log5( (level), ldap_syslog_level, (fmt), (connid), (opid), (arg1), (arg2), (arg3) )
#define StatslogTest( level ) ((ldap_debug | ldap_syslog) & (level))
-#elif defined(LDAP_DEBUG)
+#else /* !LDAP_SYSLOG */
#define Statslog( level, fmt, connid, opid, arg1, arg2, arg3 ) \
do { \
if ( ldap_debug & (level) ) \
fprintf( stderr, (fmt), (connid), (opid), (arg1), (arg2), (arg3) );\
} while (0)
#define StatslogTest( level ) (ldap_debug & (level))
-#else
+#endif /* !LDAP_SYSLOG */
+#else /* !LDAP_DEBUG */
#define Statslog( level, fmt, connid, opid, arg1, arg2, arg3 ) ((void) 0)
#define StatslogTest( level ) (0)
-#endif
+#endif /* !LDAP_DEBUG */
/*
* listener; need to access it from monitor backend
diff --git a/servers/slapd/slapacl.c b/servers/slapd/slapacl.c
index c7b6c274cf5b170ebea4027cb5fa47e71b8063a1..31edffa527d581283ca231caef8e1bc1d1271aab 100644
--- a/servers/slapd/slapacl.c
+++ b/servers/slapd/slapacl.c
@@ -330,6 +330,9 @@ slapacl( int argc, char **argv )
attr );
invalid = 1;
break;
+
+ default:
+ break;
}
if ( invalid ) {
diff --git a/servers/slapd/slapadd.c b/servers/slapd/slapadd.c
index 11cf55f371a93a12a7b458070c4d9120079a2421..6a01077dae327813f45dcb482c4aafadb0acf54b 100644
--- a/servers/slapd/slapadd.c
+++ b/servers/slapd/slapadd.c
@@ -62,7 +62,7 @@ slapadd( int argc, char **argv )
int match;
int ret;
int checkvals;
- int lineno;
+ int lineno, nextline;
int lmax;
int rc = EXIT_SUCCESS;
int manage = 0;
@@ -93,7 +93,7 @@ slapadd( int argc, char **argv )
checkvals = (slapMode & SLAP_TOOL_QUICK) ? 0 : 1;
lmax = 0;
- lineno = 0;
+ nextline = 0;
if( !dryrun && be->be_entry_open( be, 1 ) != 0 ) {
fprintf( stderr, "%s: could not open database.\n",
@@ -106,8 +106,15 @@ slapadd( int argc, char **argv )
maxcsn.bv_len = 0;
}
- while( ldif_read_record( ldiffp, &lineno, &buf, &lmax ) ) {
- Entry *e = str2entry2( buf, checkvals );
+ /* nextline is the line number of the end of the current entry */
+ for( lineno=1; ldif_read_record( ldiffp, &nextline, &buf, &lmax );
+ lineno=nextline+1 ) {
+ Entry *e;
+
+ if ( lineno < jumpline )
+ continue;
+
+ e = str2entry2( buf, checkvals );
/*
* Initialize text buffer
diff --git a/servers/slapd/slapcommon.c b/servers/slapd/slapcommon.c
index 59e1e01cf359190006c5d6b693584f285daa120d..b9ac4f1beeffe170a9d03e2c55073c4a64948d7a 100644
--- a/servers/slapd/slapcommon.c
+++ b/servers/slapd/slapcommon.c
@@ -47,23 +47,31 @@ static FILE *leakfile;
static LDIFFP dummy;
+#ifdef LDAP_SYSLOG
+int start_syslog;
+static char **syslog_unknowns;
+#ifdef LOG_LOCAL4
+static int syslogUser = SLAP_DEFAULT_SYSLOG_USER;
+#endif /* LOG_LOCAL4 */
+#endif /* LDAP_SYSLOG */
+
static void
usage( int tool, const char *progname )
{
char *options = NULL;
fprintf( stderr,
- "usage: %s [-v] [-d debuglevel] [-f configfile] [-F configdir]",
+ "usage: %s [-v] [-d debuglevel] [-f configfile] [-F configdir] [-o <name>[=<value>]]",
progname );
switch( tool ) {
case SLAPACL:
options = "\n\t[-U authcID | -D authcDN] [-X authzID | -o authzDN=<DN>]"
- "\n\t-b DN -o <var>[=<val>] [-u] [attr[/access][:value]] [...]\n";
+ "\n\t-b DN [-u] [attr[/access][:value]] [...]\n";
break;
case SLAPADD:
options = " [-c]\n\t[-g] [-n databasenumber | -b suffix]\n"
- "\t[-l ldiffile] [-q] [-u] [-s] [-w]\n";
+ "\t[-l ldiffile] [-j linenumber] [-q] [-u] [-s] [-w]\n";
break;
case SLAPAUTH:
@@ -95,19 +103,17 @@ usage( int tool, const char *progname )
}
static int
-parse_slapacl( void )
+parse_slapopt( void )
{
- size_t len;
+ size_t len = 0;
char *p;
p = strchr( optarg, '=' );
- if ( p == NULL ) {
- return -1;
+ if ( p != NULL ) {
+ len = p - optarg;
+ p++;
}
- len = p - optarg;
- p++;
-
if ( strncasecmp( optarg, "sockurl", len ) == 0 ) {
if ( !BER_BVISNULL( &listener_url ) ) {
ber_memfree( listener_url.bv_val );
@@ -159,6 +165,28 @@ parse_slapacl( void )
} else if ( strncasecmp( optarg, "authzDN", len ) == 0 ) {
ber_str2bv( p, 0, 1, &authzDN );
+#ifdef LDAP_SYSLOG
+ } else if ( strncasecmp( optarg, "syslog", len ) == 0 ) {
+ if ( parse_debug_level( p, &ldap_syslog, &syslog_unknowns ) ) {
+ return -1;
+ }
+ start_syslog = 1;
+
+ } else if ( strncasecmp( optarg, "syslog-level", len ) == 0 ) {
+ if ( parse_syslog_level( p, &ldap_syslog_level ) ) {
+ return -1;
+ }
+ start_syslog = 1;
+
+#ifdef LOG_LOCAL4
+ } else if ( strncasecmp( optarg, "syslog-user", len ) == 0 ) {
+ if ( parse_syslog_user( p, &syslogUser ) ) {
+ return -1;
+ }
+ start_syslog = 1;
+#endif /* LOG_LOCAL4 */
+#endif /* LDAP_SYSLOG */
+
} else {
return -1;
}
@@ -200,6 +228,7 @@ slap_tool_init(
* messages show up; use -d 0 to reset */
slap_debug = LDAP_DEBUG_NONE;
#endif
+ ldap_syslog = 0;
#ifdef CSRIMALLOC
leakfilename = malloc( strlen( progname ) + STRLENOF( ".leak" ) + 1 );
@@ -212,31 +241,31 @@ slap_tool_init(
switch( tool ) {
case SLAPADD:
- options = "b:cd:f:F:gl:n:qstuvw";
+ options = "b:cd:f:F:gj:l:n:o:qstuvw";
break;
case SLAPCAT:
- options = "a:b:cd:f:F:gl:n:s:v";
+ options = "a:b:cd:f:F:gl:n:o:s:v";
mode |= SLAP_TOOL_READMAIN | SLAP_TOOL_READONLY;
break;
case SLAPDN:
- options = "d:f:F:NPv";
+ options = "d:f:F:No:Pv";
mode |= SLAP_TOOL_READMAIN | SLAP_TOOL_READONLY;
break;
case SLAPTEST:
- options = "d:f:F:uv";
+ options = "d:f:F:o:uv";
mode |= SLAP_TOOL_READMAIN | SLAP_TOOL_READONLY;
break;
case SLAPAUTH:
- options = "d:f:F:M:R:U:vX:";
+ options = "d:f:F:M:o:R:U:vX:";
mode |= SLAP_TOOL_READMAIN | SLAP_TOOL_READONLY;
break;
case SLAPINDEX:
- options = "b:cd:f:F:gn:qv";
+ options = "b:cd:f:F:gn:o:qv";
mode |= SLAP_TOOL_READMAIN;
break;
@@ -302,6 +331,12 @@ slap_tool_init(
use_glue = 0;
break;
+ case 'j': /* jump to linenumber */
+ if ( lutil_atoi( &jumpline, optarg ) ) {
+ usage( tool, progname );
+ }
+ break;
+
case 'l': /* LDIF file */
ldiffile = strdup( optarg );
break;
@@ -324,7 +359,7 @@ slap_tool_init(
break;
case 'o':
- if ( parse_slapacl() ) {
+ if ( parse_slapopt() ) {
usage( tool, progname );
}
break;
@@ -382,6 +417,27 @@ slap_tool_init(
}
}
+#ifdef LDAP_SYSLOG
+ if ( start_syslog ) {
+ char *logName;
+#ifdef HAVE_EBCDIC
+ logName = ch_strdup( progname );
+ __atoe( logName );
+#else
+ logName = (char *)progname;
+#endif
+
+#ifdef LOG_LOCAL4
+ openlog( logName, OPENLOG_OPTIONS, syslogUser );
+#elif LOG_DEBUG
+ openlog( logName, OPENLOG_OPTIONS );
+#endif
+#ifdef HAVE_EBCDIC
+ free( logName );
+#endif
+ }
+#endif /* LDAP_SYSLOG */
+
switch ( tool ) {
case SLAPADD:
case SLAPCAT:
@@ -424,8 +480,6 @@ slap_tool_init(
break;
}
- ldap_syslog = 0;
-
if ( ldiffile == NULL ) {
dummy.fp = tool == SLAPCAT ? stdout : stdin;
ldiffp = &dummy;
@@ -463,6 +517,14 @@ slap_tool_init(
exit( EXIT_FAILURE );
}
+ if ( syslog_unknowns ) {
+ rc = parse_debug_unknowns( syslog_unknowns, &ldap_syslog );
+ ldap_charray_free( syslog_unknowns );
+ syslog_unknowns = NULL;
+ if ( rc )
+ exit( EXIT_FAILURE );
+ }
+
at_oc_cache = 1;
switch ( tool ) {
diff --git a/servers/slapd/slapcommon.h b/servers/slapd/slapcommon.h
index 9584986915b176593b9115090fac21393b9c07df..a5da19eb763510b2a178679a7b0ed37196ed4a82 100644
--- a/servers/slapd/slapcommon.h
+++ b/servers/slapd/slapcommon.h
@@ -39,6 +39,7 @@ typedef struct tool_vars {
int tv_continuemode;
int tv_nosubordinates;
int tv_dryrun;
+ int tv_jumpline;
Filter *tv_filter;
struct berval tv_sub_ndn;
struct LDIFFP *tv_ldiffp;
@@ -64,6 +65,7 @@ extern tool_vars tool_globals;
#define be tool_globals.tv_be
#define verbose tool_globals.tv_verbose
+#define jumpline tool_globals.tv_jumpline
#define update_ctxcsn tool_globals.tv_update_ctxcsn
#define continuemode tool_globals.tv_continuemode
#define nosubordinates tool_globals.tv_nosubordinates
diff --git a/servers/slapd/slapi/slapi_overlay.c b/servers/slapd/slapi/slapi_overlay.c
index 12425f06c1067c83448ddf365822e1ec5af3cd56..cdd6e0f7c1c56378e69dddf9962e88311a48c19f 100644
--- a/servers/slapd/slapi/slapi_overlay.c
+++ b/servers/slapd/slapi/slapi_overlay.c
@@ -303,7 +303,8 @@ slapi_op_search_callback( Operation *op, SlapReply *rs, int prc )
rs->sr_err = LDAP_SUCCESS;
- if ( slapi_int_call_plugins( op->o_bd, SLAPI_PLUGIN_COMPUTE_SEARCH_REWRITER_FN, pb ) == 0 ) {
+ if ( pb->pb_intop == 0 &&
+ slapi_int_call_plugins( op->o_bd, SLAPI_PLUGIN_COMPUTE_SEARCH_REWRITER_FN, pb ) == 0 ) {
/*
* The plugin can set the SLAPI_SEARCH_FILTER.
* SLAPI_SEARCH_STRFILER is not normative.
@@ -325,29 +326,29 @@ struct slapi_op_info {
{
SLAPI_PLUGIN_PRE_BIND_FN,
SLAPI_PLUGIN_POST_BIND_FN,
- 0,
- 0,
+ SLAPI_PLUGIN_INTERNAL_PRE_BIND_FN,
+ SLAPI_PLUGIN_INTERNAL_POST_BIND_FN,
slapi_op_bind_callback
},
{
SLAPI_PLUGIN_PRE_UNBIND_FN,
SLAPI_PLUGIN_POST_UNBIND_FN,
- 0,
- 0,
+ SLAPI_PLUGIN_INTERNAL_PRE_UNBIND_FN,
+ SLAPI_PLUGIN_INTERNAL_POST_UNBIND_FN,
NULL
},
{
SLAPI_PLUGIN_PRE_SEARCH_FN,
SLAPI_PLUGIN_POST_SEARCH_FN,
- 0,
- 0,
+ SLAPI_PLUGIN_INTERNAL_PRE_SEARCH_FN,
+ SLAPI_PLUGIN_INTERNAL_POST_SEARCH_FN,
slapi_op_search_callback
},
{
SLAPI_PLUGIN_PRE_COMPARE_FN,
SLAPI_PLUGIN_POST_COMPARE_FN,
- 0,
- 0,
+ SLAPI_PLUGIN_INTERNAL_PRE_COMPARE_FN,
+ SLAPI_PLUGIN_INTERNAL_POST_COMPARE_FN,
NULL
},
{
@@ -381,8 +382,8 @@ struct slapi_op_info {
{
SLAPI_PLUGIN_PRE_ABANDON_FN,
SLAPI_PLUGIN_POST_ABANDON_FN,
- 0,
- 0,
+ SLAPI_PLUGIN_INTERNAL_PRE_ABANDON_FN,
+ SLAPI_PLUGIN_INTERNAL_POST_ABANDON_FN,
NULL
},
{
diff --git a/servers/slapd/slapi/slapi_pblock.c b/servers/slapd/slapi/slapi_pblock.c
index ea6d4edcb2ae8eaee35e99b34cfd04e6264b7f08..ab75cd67835b06dea1b3c971e2a6f54a2c58bb4c 100644
--- a/servers/slapd/slapi/slapi_pblock.c
+++ b/servers/slapd/slapi/slapi_pblock.c
@@ -168,6 +168,16 @@ pblock_get_param_class( int param )
case SLAPI_X_PLUGIN_PRE_GROUP_FN:
case SLAPI_X_PLUGIN_POST_GROUP_FN:
case SLAPI_PLUGIN_AUDIT_FN:
+ case SLAPI_PLUGIN_INTERNAL_PRE_BIND_FN:
+ case SLAPI_PLUGIN_INTERNAL_PRE_UNBIND_FN:
+ case SLAPI_PLUGIN_INTERNAL_PRE_SEARCH_FN:
+ case SLAPI_PLUGIN_INTERNAL_PRE_COMPARE_FN:
+ case SLAPI_PLUGIN_INTERNAL_PRE_ABANDON_FN:
+ case SLAPI_PLUGIN_INTERNAL_POST_BIND_FN:
+ case SLAPI_PLUGIN_INTERNAL_POST_UNBIND_FN:
+ case SLAPI_PLUGIN_INTERNAL_POST_SEARCH_FN:
+ case SLAPI_PLUGIN_INTERNAL_POST_COMPARE_FN:
+ case SLAPI_PLUGIN_INTERNAL_POST_ABANDON_FN:
return PBLOCK_CLASS_FUNCTION_POINTER;
break;
@@ -473,7 +483,7 @@ pblock_get( Slapi_PBlock *pb, int param, void **value )
break;
case SLAPI_X_OPERATION_DELETE_GLUE_PARENT:
PBLOCK_ASSERT_OP( pb, 0 );
- *((ber_tag_t *)value) = pb->pb_op->o_delete_glue_parent;
+ *((int *)value) = pb->pb_op->o_delete_glue_parent;
break;
case SLAPI_X_OPERATION_NO_SCHEMA_CHECK:
PBLOCK_ASSERT_OP( pb, 0 );
@@ -493,6 +503,10 @@ pblock_get( Slapi_PBlock *pb, int param, void **value )
rc = PBLOCK_ERROR;
}
break;
+ case SLAPI_X_OPERATION_NO_SUBORDINATE_GLUE:
+ PBLOCK_ASSERT_OP( pb, 0 );
+ *((int *)value) = pb->pb_op->o_no_subordinate_glue;
+ break;
case SLAPI_REQCONTROLS:
PBLOCK_ASSERT_OP( pb, 0 );
*((LDAPControl ***)value) = pb->pb_op->o_ctrls;
@@ -572,6 +586,12 @@ pblock_get( Slapi_PBlock *pb, int param, void **value )
break;
case SLAPI_CONN_DN:
PBLOCK_ASSERT_CONN( pb );
+#if 0
+ /* This would be necessary to keep plugin compat after the fix in ITS#4158 */
+ if ( pb->pb_op->o_tag == LDAP_REQ_BIND && pb->pb_rs->sr_err == LDAP_SUCCESS )
+ *((char **)value) = pb->pb_op->orb_edn.bv_val;
+ else
+#endif
*((char **)value) = pb->pb_conn->c_dn.bv_val;
break;
case SLAPI_CONN_CLIENTIP:
@@ -590,14 +610,14 @@ pblock_get( Slapi_PBlock *pb, int param, void **value )
break;
case SLAPI_CONN_SERVERIP:
PBLOCK_ASSERT_CONN( pb );
- if ( strncmp( pb->pb_conn->c_peer_name.bv_val, "IP=", 3 ) == 0 )
+ if ( strncmp( pb->pb_conn->c_sock_name.bv_val, "IP=", 3 ) == 0 )
*((char **)value) = &pb->pb_conn->c_sock_name.bv_val[3];
else
*value = NULL;
break;
case SLAPI_X_CONN_SERVERPATH:
PBLOCK_ASSERT_CONN( pb );
- if ( strncmp( pb->pb_conn->c_peer_name.bv_val, "PATH=", 3 ) == 0 )
+ if ( strncmp( pb->pb_conn->c_sock_name.bv_val, "PATH=", 3 ) == 0 )
*((char **)value) = &pb->pb_conn->c_sock_name.bv_val[5];
else
*value = NULL;
@@ -873,6 +893,10 @@ pblock_set( Slapi_PBlock *pb, int param, void *value )
PBLOCK_ASSERT_OP( pb, 0 );
pb->pb_op->o_no_schema_check = *((int *)value);
break;
+ case SLAPI_X_OPERATION_NO_SUBORDINATE_GLUE:
+ PBLOCK_ASSERT_OP( pb, 0 );
+ pb->pb_op->o_no_subordinate_glue = *((int *)value);
+ break;
case SLAPI_REQCONTROLS:
PBLOCK_ASSERT_OP( pb, 0 );
pb->pb_op->o_ctrls = (LDAPControl **)value;
@@ -1098,7 +1122,7 @@ pblock_set( Slapi_PBlock *pb, int param, void *value )
break;
case SLAPI_SEARCH_ATTRS: {
AttributeName *an = NULL;
- size_t i = 0;
+ size_t i = 0, j = 0;
char **attrs = (char **)value;
PBLOCK_ASSERT_OP( pb, 0 );
@@ -1122,18 +1146,20 @@ pblock_set( Slapi_PBlock *pb, int param, void *value )
;
}
if ( i ) {
- an = (AttributeName *)pb->pb_op->o_tmpalloc( (i + 1) *
+ an = (AttributeName *)pb->pb_op->o_tmpcalloc( i + 1,
sizeof(AttributeName), pb->pb_op->o_tmpmemctx );
for ( i = 0; attrs[i] != NULL; i++ ) {
- an[i].an_desc = NULL;
- an[i].an_oc = NULL;
- an[i].an_oc_exclude = 0;
- an[i].an_name.bv_val = attrs[i];
- an[i].an_name.bv_len = strlen( attrs[i] );
- slap_bv2ad( &an[i].an_name, &an[i].an_desc, &pb->pb_rs->sr_text );
+ an[j].an_desc = NULL;
+ an[j].an_oc = NULL;
+ an[j].an_oc_exclude = 0;
+ an[j].an_name.bv_val = attrs[i];
+ an[j].an_name.bv_len = strlen( attrs[i] );
+ if ( slap_bv2ad( &an[j].an_name, &an[j].an_desc, &pb->pb_rs->sr_text ) == LDAP_SUCCESS ) {
+ j++;
+ }
}
- an[i].an_name.bv_val = NULL;
- an[i].an_name.bv_len = 0;
+ an[j].an_name.bv_val = NULL;
+ an[j].an_name.bv_len = 0;
}
pb->pb_op->ors_attrs = an;
break;
diff --git a/servers/slapd/slapi/slapi_utils.c b/servers/slapd/slapi/slapi_utils.c
index 554cfb2fa0f7f3d1f69e053a81baa89f7afbe8c2..d3fa90ab745c84f0e1290c5fece7aa6f3699eee8 100644
--- a/servers/slapd/slapi/slapi_utils.c
+++ b/servers/slapd/slapi/slapi_utils.c
@@ -1349,8 +1349,13 @@ slapi_send_ldap_result(
} else {
if ( pb->pb_op->o_tag == LDAP_REQ_SEARCH )
rs->sr_nentries = nentries;
+ if ( urls != NULL )
+ bvptr2obj( urls, &rs->sr_ref );
send_ldap_result( pb->pb_op, rs );
+
+ if ( urls != NULL )
+ slapi_ch_free( (void **)&rs->sr_ref );
}
}
@@ -1363,7 +1368,7 @@ slapi_send_ldap_search_entry(
int attrsonly )
{
SlapReply rs = { REP_SEARCH };
- int i = 0;
+ int i = 0, j = 0;
AttributeName *an = NULL;
const char *text;
int rc;
@@ -1377,19 +1382,17 @@ slapi_send_ldap_search_entry(
}
if ( i ) {
- an = (AttributeName *) slapi_ch_malloc( (i+1) * sizeof(AttributeName) );
+ an = (AttributeName *) slapi_ch_calloc( i + 1, sizeof(AttributeName) );
for ( i = 0; attrs[i] != NULL; i++ ) {
- an[i].an_name.bv_val = attrs[i];
- an[i].an_name.bv_len = strlen( attrs[i] );
- an[i].an_desc = NULL;
- rs.sr_err = slap_bv2ad( &an[i].an_name, &an[i].an_desc, &text );
- if ( rs.sr_err != LDAP_SUCCESS) {
- slapi_ch_free( (void **)&an );
- return -1;
+ an[j].an_name.bv_val = attrs[i];
+ an[j].an_name.bv_len = strlen( attrs[i] );
+ an[j].an_desc = NULL;
+ if ( slap_bv2ad( &an[j].an_name, &an[j].an_desc, &text ) == LDAP_SUCCESS) {
+ j++;
}
}
- an[i].an_name.bv_len = 0;
- an[i].an_name.bv_val = NULL;
+ an[j].an_name.bv_len = 0;
+ an[j].an_name.bv_val = NULL;
}
rs.sr_err = LDAP_SUCCESS;
diff --git a/servers/slapd/syncrepl.c b/servers/slapd/syncrepl.c
index de322be98fad93ff755c7fba5b7dc78b8fb07b1f..1d72a0893402feed674a035693cae5fd80555942 100644
--- a/servers/slapd/syncrepl.c
+++ b/servers/slapd/syncrepl.c
@@ -423,118 +423,11 @@ do_syncrep1(
psub = &si->si_be->be_nsuffix[0];
- /* Init connection to master */
- rc = ldap_initialize( &si->si_ld, si->si_bindconf.sb_uri.bv_val );
+ rc = slap_client_connect( &si->si_ld, &si->si_bindconf, LDAP_VERSION3 );
if ( rc != LDAP_SUCCESS ) {
- Debug( LDAP_DEBUG_ANY,
- "do_syncrep1: ldap_initialize failed (%s)\n",
- si->si_bindconf.sb_uri.bv_val, 0, 0 );
- return rc;
- }
-
- op->o_protocol = LDAP_VERSION3;
- ldap_set_option( si->si_ld, LDAP_OPT_PROTOCOL_VERSION,
- (const void *)&op->o_protocol );
-
-#ifdef HAVE_TLS
- if ( si->si_bindconf.sb_tls_do_init ) {
- rc = bindconf_tls_set( &si->si_bindconf, si->si_ld );
- } else if ( si->si_bindconf.sb_tls_ctx ) {
- rc = ldap_set_option( si->si_ld, LDAP_OPT_X_TLS_CTX,
- si->si_bindconf.sb_tls_ctx );
- }
- if ( rc ) {
- Debug( LDAP_DEBUG_ANY,
- "do_syncrep1: TLS context initialization failed\n", 0, 0, 0 );
- return rc;
- }
-#endif
-
- /* Bind to master */
-
- if ( si->si_bindconf.sb_tls ) {
- rc = ldap_start_tls_s( si->si_ld, NULL, NULL );
- if( rc != LDAP_SUCCESS ) {
- Debug( LDAP_DEBUG_ANY,
- "%s: ldap_start_tls failed (%d)\n",
- si->si_bindconf.sb_tls == SB_TLS_CRITICAL ? "Error" : "Warning",
- rc, 0 );
- if( si->si_bindconf.sb_tls == SB_TLS_CRITICAL ) goto done;
- }
- }
-
- if ( si->si_bindconf.sb_method == LDAP_AUTH_SASL ) {
-#ifdef HAVE_CYRUS_SASL
- void *defaults;
-
- if ( si->si_bindconf.sb_secprops != NULL ) {
- rc = ldap_set_option( si->si_ld,
- LDAP_OPT_X_SASL_SECPROPS, si->si_bindconf.sb_secprops);
-
- if( rc != LDAP_OPT_SUCCESS ) {
- Debug( LDAP_DEBUG_ANY, "Error: ldap_set_option "
- "(%s,SECPROPS,\"%s\") failed!\n",
- si->si_bindconf.sb_uri.bv_val, si->si_bindconf.sb_secprops, 0 );
- goto done;
- }
- }
-
- defaults = lutil_sasl_defaults( si->si_ld,
- si->si_bindconf.sb_saslmech.bv_val,
- si->si_bindconf.sb_realm.bv_val,
- si->si_bindconf.sb_authcId.bv_val,
- si->si_bindconf.sb_cred.bv_val,
- si->si_bindconf.sb_authzId.bv_val );
-
- rc = ldap_sasl_interactive_bind_s( si->si_ld,
- si->si_bindconf.sb_binddn.bv_val,
- si->si_bindconf.sb_saslmech.bv_val,
- NULL, NULL,
- LDAP_SASL_QUIET,
- lutil_sasl_interact,
- defaults );
-
- lutil_sasl_freedefs( defaults );
-
- /* FIXME: different error behaviors according to
- * 1) return code
- * 2) on err policy : exit, retry, backoff ...
- */
- if ( rc != LDAP_SUCCESS ) {
- static struct berval bv_GSSAPI = BER_BVC( "GSSAPI" );
-
- Debug( LDAP_DEBUG_ANY, "do_syncrep1: "
- "ldap_sasl_interactive_bind_s failed (%d)\n",
- rc, 0, 0 );
-
- /* FIXME (see above comment) */
- /* if Kerberos credentials cache is not active, retry */
- if ( ber_bvcmp( &si->si_bindconf.sb_saslmech, &bv_GSSAPI ) == 0 &&
- rc == LDAP_LOCAL_ERROR )
- {
- rc = LDAP_SERVER_DOWN;
- }
-
- goto done;
- }
-#else /* HAVE_CYRUS_SASL */
- /* Should never get here, we trapped this at config time */
- assert(0);
- Debug( LDAP_DEBUG_SYNC, "not compiled with SASL support\n", 0, 0, 0 );
- rc = LDAP_OTHER;
goto done;
-#endif
-
- } else if ( si->si_bindconf.sb_method == LDAP_AUTH_SIMPLE ) {
- rc = ldap_sasl_bind_s( si->si_ld,
- si->si_bindconf.sb_binddn.bv_val, LDAP_SASL_SIMPLE,
- &si->si_bindconf.sb_cred, NULL, NULL, NULL );
- if ( rc != LDAP_SUCCESS ) {
- Debug( LDAP_DEBUG_ANY, "do_syncrep1: "
- "ldap_sasl_bind_s failed (%d)\n", rc, 0, 0 );
- goto done;
- }
}
+ op->o_protocol = LDAP_VERSION3;
/* Set SSF to strongest of TLS, SASL SSFs */
op->o_sasl_ssf = 0;
@@ -808,11 +701,6 @@ do_syncrep2(
&syncCookie_req.ctxcsn, &syncCookie.ctxcsn,
&text );
}
- if ( !BER_BVISNULL( &syncCookie.ctxcsn ) &&
- match < 0 && err == LDAP_SUCCESS )
- {
- rc = syncrepl_updateCookie( si, op, psub, &syncCookie );
- }
if ( rctrls ) {
ldap_controls_free( rctrls );
}
@@ -824,12 +712,17 @@ do_syncrep2(
if ( refreshDeletes == 0 && match < 0 &&
err == LDAP_SUCCESS )
{
- syncrepl_del_nonpresent( op, si, NULL, NULL );
+ syncrepl_del_nonpresent( op, si, NULL, &syncCookie.ctxcsn );
} else {
avl_free( si->si_presentlist, avl_ber_bvfree );
si->si_presentlist = NULL;
}
}
+ if ( !BER_BVISNULL( &syncCookie.ctxcsn ) &&
+ match < 0 && err == LDAP_SUCCESS )
+ {
+ rc = syncrepl_updateCookie( si, op, psub, &syncCookie );
+ }
if ( err == LDAP_SUCCESS
&& si->si_logstate == SYNCLOG_FALLBACK ) {
si->si_logstate = SYNCLOG_LOGGING;
@@ -930,6 +823,7 @@ do_syncrep2(
}
slap_sl_free( syncUUIDs, op->o_tmpmemctx );
}
+ slap_sync_cookie_free( &syncCookie, 0 );
break;
default:
Debug( LDAP_DEBUG_ANY,
@@ -952,15 +846,14 @@ do_syncrep2(
&syncCookie.ctxcsn, &text );
}
- if ( !BER_BVISNULL( &syncCookie.ctxcsn ) &&
- match < 0 )
- {
- rc = syncrepl_updateCookie( si, op, psub, &syncCookie);
- }
+ if ( match < 0 ) {
+ if ( si->si_refreshPresent == 1 ) {
+ syncrepl_del_nonpresent( op, si, NULL, &syncCookie.ctxcsn );
+ }
- if ( si->si_refreshPresent == 1 ) {
- if ( match < 0 ) {
- syncrepl_del_nonpresent( op, si, NULL, NULL );
+ if ( !BER_BVISNULL( &syncCookie.ctxcsn ))
+ {
+ rc = syncrepl_updateCookie( si, op, psub, &syncCookie);
}
}
@@ -1350,6 +1243,7 @@ syncrepl_message_to_op(
}
op->o_callback = &cb;
+ slap_op_time( &op->o_time, &op->o_tincr );
switch( op->o_tag ) {
case LDAP_REQ_ADD:
@@ -1768,8 +1662,25 @@ syncrepl_entry(
ber_memfree( a->a_vals[0].bv_val );
ber_dupbv( &a->a_vals[0], &syncUUID_strrep );
}
+ /* Don't save the contextCSN on the inooming context entry,
+ * we'll write it when syncrepl_updateCookie eventually
+ * gets called. (ITS#4622)
+ */
+ if ( syncstate == LDAP_SYNC_ADD && dn_match( &entry->e_nname,
+ &be->be_nsuffix[0] )) {
+ Attribute **ap;
+ for ( ap = &entry->e_attrs; *ap; ap=&(*ap)->a_next ) {
+ a = *ap;
+ if ( a->a_desc == slap_schema.si_ad_contextCSN ) {
+ *ap = a->a_next;
+ attr_free( a );
+ break;
+ }
+ }
+ }
}
+ slap_op_time( &op->o_time, &op->o_tincr );
switch ( syncstate ) {
case LDAP_SYNC_ADD:
case LDAP_SYNC_MODIFY:
@@ -1848,6 +1759,7 @@ retry_add:;
if ( rc ) goto done;
retry = 0;
+ slap_op_time( &op->o_time, &op->o_tincr );
goto retry_add;
}
/* FALLTHRU */
@@ -1882,7 +1794,17 @@ retry_add:;
if (( rc = slap_modrdn2mods( op, &rs_modify ))) {
goto done;
}
+
+ /* RDNs must be NUL-terminated for back-ldap */
+ noldp = op->orr_newrdn;
+ ber_dupbv_x( &op->orr_newrdn, &noldp, op->o_tmpmemctx );
+ noldp = op->orr_nnewrdn;
+ ber_dupbv_x( &op->orr_nnewrdn, &noldp, op->o_tmpmemctx );
+
rc = be->be_modrdn( op, &rs_modify );
+ op->o_tmpfree( op->orr_nnewrdn.bv_val, op->o_tmpmemctx );
+ op->o_tmpfree( op->orr_newrdn.bv_val, op->o_tmpmemctx );
+
slap_mods_free( op->orr_modlist, 1 );
Debug( LDAP_DEBUG_SYNC,
"syncrepl_entry: %s (%d)\n",
@@ -1893,6 +1815,8 @@ retry_add:;
} else {
goto done;
}
+ if ( dni.wasChanged )
+ slap_op_time( &op->o_time, &op->o_tincr );
}
if ( dni.wasChanged ) {
Modifications *mod, *modhead = NULL;
@@ -3207,8 +3131,14 @@ add_syncrepl(
int rc = 0;
if ( !( c->be->be_search && c->be->be_add && c->be->be_modify && c->be->be_delete ) ) {
- Debug( LDAP_DEBUG_ANY, "%s: database %s does not support operations "
- "required for syncrepl\n", c->log, c->be->be_type, 0 );
+ snprintf( c->msg, sizeof(c->msg), "database %s does not support "
+ "operations required for syncrepl", c->be->be_type );
+ Debug( LDAP_DEBUG_ANY, "%s: %s\n", c->log, c->msg, 0 );
+ return 1;
+ }
+ if ( BER_BVISEMPTY( &c->be->be_rootdn )) {
+ strcpy( c->msg, "rootDN must be defined before syncrepl may be used" );
+ Debug( LDAP_DEBUG_ANY, "%s: %s\n", c->log, c->msg, 0 );
return 1;
}
si = (syncinfo_t *) ch_calloc( 1, sizeof( syncinfo_t ) );
diff --git a/tests/data/acl.out.master b/tests/data/acl.out.master
index 1d4423e1d4ff47cb1238464bc86627730ee782f5..8fd99a621ffcadb9d0af9c3f0219e23ea8219dfe 100644
--- a/tests/data/acl.out.master
+++ b/tests/data/acl.out.master
@@ -68,7 +68,6 @@ member: cn=Jane Doe,ou=Alumni Association,ou=People,dc=example,dc=com
member: cn=John Doe,ou=Information Technology Division,ou=People,dc=example,dc
=com
member: cn=Mark Elliot,ou=Alumni Association,ou=People,dc=example,dc=com
-member: cn=James A Jones 1,ou=Alumni Association,ou=People,dc=example,dc=com
member: cn=James A Jones 2,ou=Information Technology Division,ou=People,dc=exa
mple,dc=com
member: cn=Jennifer Smith,ou=Alumni Association,ou=People,dc=example,dc=com
@@ -76,6 +75,7 @@ member: cn=Dorothy Stevens,ou=Alumni Association,ou=People,dc=example,dc=com
member: cn=Ursula Hampster,ou=Alumni Association,ou=People,dc=example,dc=com
member: cn=Bjorn Jensen,ou=Information Technology Division,ou=People,dc=exampl
e,dc=com
+member: cn=James A Jones 1,ou=Alumni Association,ou=People,dc=example,dc=com
owner: cn=Manager,dc=example,dc=com
cn: All Staff
description: Everyone in the sample data
diff --git a/tests/data/slapd-acl.conf b/tests/data/slapd-acl.conf
index 531a1b730e2d61dde49a5661fc5e80ce8d884ebf..a168e5cd5ec647ff12ce4eab64fcd44e5c6ebbd4 100644
--- a/tests/data/slapd-acl.conf
+++ b/tests/data/slapd-acl.conf
@@ -110,6 +110,7 @@ access to dn.children="ou=Alumni Association,ou=People,dc=example,dc=com"
#access to attrs=member,uniquemember dn.subtree="dc=example,dc=com"
access to attrs=member,uniquemember
+ by dn.exact="cn=James A Jones 1,ou=Alumni Association,ou=People,dc=example,dc=com" selfwrite
by dnattr=member selfwrite
by dnattr=uniquemember selfwrite
by * read
diff --git a/tests/data/slapd-repl-slave-remote.conf b/tests/data/slapd-repl-slave-remote.conf
index 0bfb3a17ed71bc44a1cf529ff3b5c2199d38aa1d..68f9944032ca13a8aab61e35792bd117731d746a 100644
--- a/tests/data/slapd-repl-slave-remote.conf
+++ b/tests/data/slapd-repl-slave-remote.conf
@@ -40,6 +40,10 @@ argsfile @TESTDIR@/slapd.2.args
# database definitions
#######################################################################
+access to dn.base="" attrs=children
+ by dn.exact="cn=Monitor" write
+ by * break
+
access to *
by * read
diff --git a/tests/data/slapd-syncrepl-multiproxy.conf b/tests/data/slapd-syncrepl-multiproxy.conf
new file mode 100644
index 0000000000000000000000000000000000000000..547f8e2dc1d5ec6c00ee87e948b005b71ecd69f8
--- /dev/null
+++ b/tests/data/slapd-syncrepl-multiproxy.conf
@@ -0,0 +1,108 @@
+# slave slapd config -- for testing of SYNC replication with intermediate proxy
+# $OpenLDAP$
+## This work is part of OpenLDAP Software <http://www.openldap.org/>.
+##
+## Copyright 1998-2006 The OpenLDAP Foundation.
+## All rights reserved.
+##
+## Redistribution and use in source and binary forms, with or without
+## modification, are permitted only as authorized by the OpenLDAP
+## Public License.
+##
+## A copy of this license is available in the file LICENSE in the
+## top-level directory of the distribution or, alternatively, at
+## <http://www.OpenLDAP.org/license.html>.
+
+include @SCHEMADIR@/core.schema
+include @SCHEMADIR@/cosine.schema
+include @SCHEMADIR@/inetorgperson.schema
+include @SCHEMADIR@/openldap.schema
+include @SCHEMADIR@/nis.schema
+#
+pidfile @TESTDIR@/slapd.1.pid
+argsfile @TESTDIR@/slapd.1.args
+
+#mod#modulepath ../servers/slapd/back-@BACKEND@/
+#mod#moduleload back_@BACKEND@.la
+#monitormod#modulepath ../servers/slapd/back-monitor/
+#monitormod#moduleload back_monitor.la
+#syncprovmod#modulepath ../servers/slapd/overlays/
+#syncprovmod#moduleload syncprov.la
+#ldapmod#modulepath ../servers/slapd/back-ldap/
+#ldapmod#moduleload back_ldap.la
+
+#######################################################################
+# master database definitions
+#######################################################################
+
+database @BACKEND@
+suffix "dc=example,dc=com"
+directory @TESTDIR@/db.1.a
+rootdn "cn=Manager,dc=example,dc=com"
+rootpw secret
+#bdb#index objectClass eq
+#bdb#index cn,sn,uid pres,eq,sub
+#bdb#index entryUUID,entryCSN eq
+#hdb#index objectClass eq
+#hdb#index cn,sn,uid pres,eq,sub
+#hdb#index entryUUID,entryCSN eq
+#ldbm#index objectClass eq
+#ldbm#index cn,sn,uid pres,eq,sub
+
+overlay syncprov
+syncprov-sessionlog 100
+
+#######################################################################
+# consumer proxy database definitions
+#######################################################################
+
+database ldap
+hidden on
+suffix "dc=example,dc=com"
+rootdn "cn=Whoever"
+uri @URI2@
+
+acl-bind bindmethod=simple
+ binddn="cn=Monitor"
+ credentials=monitor
+
+# Don't change syncrepl spec yet
+
+syncrepl rid=1
+ provider=@URI1@
+ binddn="cn=Manager,dc=example,dc=com"
+ bindmethod=simple
+ credentials=secret
+ searchbase="dc=example,dc=com"
+ filter="(objectClass=*)"
+ schemachecking=off
+ scope=sub
+ type=refreshAndPersist
+ retry="5 5 300 5"
+
+database ldap
+hidden on
+suffix "dc=example,dc=com"
+rootdn "cn=Whoever"
+uri @URI3@
+
+acl-bind bindmethod=simple
+ binddn="cn=Monitor"
+ credentials=monitor
+
+# Don't change syncrepl spec yet
+
+syncrepl rid=2
+ provider=@URI1@
+ binddn="cn=Manager,dc=example,dc=com"
+ bindmethod=simple
+ credentials=secret
+ searchbase="dc=example,dc=com"
+ filter="(objectClass=*)"
+ schemachecking=off
+ scope=sub
+ type=refreshOnly
+ interval=00:00:00:10
+ retry="5 5 300 5"
+
+#monitor#database monitor
diff --git a/tests/data/slapd-syncrepl-slave-persist-ldap.conf b/tests/data/slapd-syncrepl-slave-persist-ldap.conf
index 977006b4b53918985996023e8ce31b0113c3860e..43207eeb51815d9b583ae04bc4ec5ba5fbd4c3fd 100644
--- a/tests/data/slapd-syncrepl-slave-persist-ldap.conf
+++ b/tests/data/slapd-syncrepl-slave-persist-ldap.conf
@@ -43,6 +43,11 @@ suffix "dc=example,dc=com"
rootdn "cn=Whoever"
uri @URI2@
+# ITS#4632: syncprov now wants this on (ITS#4613); however, since checks
+# are in place to prevent lastmod operational attrs to be added twice,
+# this shuld make no harm
+lastmod on
+
# HACK: use the RootDN of the monitor database as UpdateDN so ACLs apply
# whithout the need to write the UpdateDN before starting replication
acl-bind bindmethod=simple
diff --git a/tests/data/slapd-translucent-local.conf b/tests/data/slapd-translucent-local.conf
index 6dad2c3a03b362485ce34c53ad9a58d0052373f7..33bbcfd34a5be1f35de52f6d8b2c5c83dce221a9 100644
--- a/tests/data/slapd-translucent-local.conf
+++ b/tests/data/slapd-translucent-local.conf
@@ -61,3 +61,6 @@ uri @URI1@
# a reminder.
lastmod off
acl-bind binddn="uid=binder,o=translucent" credentials="bindtest"
+
+database config
+include "configpw.conf"
diff --git a/tests/data/slapd-valsort.conf b/tests/data/slapd-valsort.conf
index 0d6b8c0dc068abad4fe8fd0eb25d0c43ef5c44ce..52c556dc9d7b14aec30882a376741aa8f568d5dc 100644
--- a/tests/data/slapd-valsort.conf
+++ b/tests/data/slapd-valsort.conf
@@ -52,6 +52,6 @@ valsort-attr ou ou=users,o=valsort weighted
valsort-attr employeeType ou=users,o=valsort weighted alpha-ascend
database config
-rootpw @CONFIGPW@
+include configpw.conf
#monitor#database monitor
diff --git a/tests/data/sql-concurrency/do_bind.0 b/tests/data/sql-concurrency/do_bind.0
new file mode 100644
index 0000000000000000000000000000000000000000..e0d04815aa18ecd1bfb16847929d9b975725d16e
--- /dev/null
+++ b/tests/data/sql-concurrency/do_bind.0
@@ -0,0 +1,2 @@
+cn=Mitya Kovalev,dc=example,dc=com
+mit
diff --git a/tests/data/sql-read.out b/tests/data/sql-read.out
index 53fe8c059ce135012a6976752d07e27491eb8df3..a88f3192b0a78b5d5fa009fbc92ea93ae10010cc 100644
--- a/tests/data/sql-read.out
+++ b/tests/data/sql-read.out
@@ -382,6 +382,15 @@ objectClass: dcObject
o: Example
dc: example
+# Testing undefined attribute in filter...
+# refldap://localhost:9012/dc=example,dc=com??sub
+
+dn: dc=example,dc=com
+objectClass: organization
+objectClass: dcObject
+o: Example
+dc: example
+
# Testing objectClass inheritance in filter...
dn: cn=Mitya Kovalev,dc=example,dc=com
objectClass: inetOrgPerson
diff --git a/tests/progs/slapd-addel.c b/tests/progs/slapd-addel.c
index ff131b1879bbec38583c3deb72c7d750d63431e6..5e9fd13e31e1d094443de83eb623314748a3b1d9 100644
--- a/tests/progs/slapd-addel.c
+++ b/tests/progs/slapd-addel.c
@@ -55,6 +55,7 @@ usage( char *name )
"-D <manager> "
"-w <passwd> "
"-f <addfile> "
+ "[-i <ignore>] "
"[-l <loops>] "
"[-L <outerloops>] "
"[-r <maxretries>] "
@@ -84,7 +85,7 @@ main( int argc, char **argv )
int chaserefs = 0;
LDAPMod **attrs = NULL;
- tester_init( "slapd-modify" );
+ tester_init( "slapd-addel", TESTER_ADDEL );
while ( (i = getopt( argc, argv, "CFH:h:p:D:w:f:l:L:r:t:" )) != EOF ) {
switch( i ) {
@@ -104,6 +105,10 @@ main( int argc, char **argv )
host = strdup( optarg );
break;
+ case 'i':
+ /* ignored (!) by now */
+ break;
+
case 'p': /* the servers port */
if ( lutil_atoi( &port, optarg ) != 0 ) {
usage( argv[0] );
@@ -117,6 +122,7 @@ main( int argc, char **argv )
case 'w': /* the server managers password */
passwd.bv_val = strdup( optarg );
passwd.bv_len = strlen( optarg );
+ memset( optarg, '*', passwd.bv_len );
break;
case 'f': /* file with entry search request */
diff --git a/tests/progs/slapd-bind.c b/tests/progs/slapd-bind.c
index 7118fb6b0fb251d8e93a9f5a2d5c87ae7fd368aa..4a5f09d541880dc3532d944019884a8b56e15910 100644
--- a/tests/progs/slapd-bind.c
+++ b/tests/progs/slapd-bind.c
@@ -45,7 +45,7 @@ do_bind( char *uri, char *dn, struct berval *pass, int maxloop,
int force, int chaserefs, int noinit, LDAP **ldp );
static int
-do_base( char *uri, struct berval *base, struct berval *pass, char *pwattr,
+do_base( char *uri, char *dn, struct berval *pass, char *base, char *filter, char *pwattr,
int maxloop, int force, int chaserefs, int noinit, int delay );
/* This program can be invoked two ways: if -D is used to specify a Bind DN,
@@ -67,13 +67,12 @@ usage( char *name )
"[-F] "
"[-C] "
"[-I] "
+ "[-i <ignore>] "
"[-t delay]\n",
name );
exit( EXIT_FAILURE );
}
-static char *filter = "(objectClass=person)";
-
int
main( int argc, char **argv )
{
@@ -81,7 +80,8 @@ main( int argc, char **argv )
char *uri = NULL;
char *host = "localhost";
char *dn = NULL;
- struct berval base = { 0, NULL };
+ char *base = NULL;
+ char *filter = "(objectClass=person)";
struct berval pass = { 0, NULL };
char *pwattr = NULL;
int port = -1;
@@ -92,16 +92,19 @@ main( int argc, char **argv )
int noinit = 0;
int delay = 0;
- tester_init( "slapd-bind" );
+ tester_init( "slapd-bind", TESTER_BIND );
+
+ /* by default, tolerate invalid credentials */
+ tester_ignore_str2errlist( "INVALID_CREDENTIALS" );
- while ( (i = getopt( argc, argv, "a:b:H:h:p:D:w:l:L:f:FIt:" )) != EOF ) {
+ while ( (i = getopt( argc, argv, "a:b:H:h:i:p:D:w:l:L:f:FIt:" )) != EOF ) {
switch( i ) {
case 'a':
pwattr = optarg;
break;
case 'b': /* base DN of a tree of user DNs */
- ber_str2bv( optarg, 0, 0, &base );
+ base = optarg;
break;
case 'C':
@@ -116,6 +119,10 @@ main( int argc, char **argv )
host = optarg;
break;
+ case 'i':
+ tester_ignore_str2errlist( optarg );
+ break;
+
case 'p': /* the servers port */
if ( lutil_atoi( &port, optarg ) != 0 ) {
usage( argv[0] );
@@ -127,7 +134,8 @@ main( int argc, char **argv )
break;
case 'w':
- ber_str2bv( optarg, 0, 0, &pass );
+ ber_str2bv( optarg, 0, 1, &pass );
+ memset( optarg, '*', pass.bv_len );
break;
case 'l': /* the number of loops */
@@ -175,8 +183,8 @@ main( int argc, char **argv )
uri = tester_uri( uri, host, port );
for ( i = 0; i < outerloops; i++ ) {
- if ( base.bv_val != NULL ) {
- do_base( uri, &base, &pass, pwattr, loops,
+ if ( base != NULL ) {
+ do_base( uri, dn, &pass, base, filter, pwattr, loops,
force, chaserefs, noinit, delay );
} else {
do_bind( uri, dn, &pass, loops,
@@ -193,7 +201,7 @@ do_bind( char *uri, char *dn, struct berval *pass, int maxloop,
int force, int chaserefs, int noinit, LDAP **ldp )
{
LDAP *ld = ldp ? *ldp : NULL;
- int i, first = 1, rc = -1;
+ int i, rc = -1;
pid_t pid = getpid();
if ( maxloop > 1 )
@@ -217,29 +225,28 @@ do_bind( char *uri, char *dn, struct berval *pass, int maxloop,
}
rc = ldap_sasl_bind_s( ld, dn, LDAP_SASL_SIMPLE, pass, NULL, NULL, NULL );
- switch ( rc ) {
- case LDAP_SUCCESS:
- break;
-
- case LDAP_INVALID_CREDENTIALS:
- /* don't log: it's intended */
- if ( force >= 2 ) {
- if ( !first ) {
- break;
+ if ( rc ) {
+ unsigned first = tester_ignore_err( rc );
+
+ /* if ignore.. */
+ if ( first ) {
+ /* only log if first occurrence */
+ if ( force < 2 || first == 1 ) {
+ tester_ldap_error( ld, "ldap_sasl_bind_s", NULL );
}
- first = 0;
- }
- /* fallthru */
+ rc = LDAP_SUCCESS;
- default:
- tester_ldap_error( ld, "ldap_sasl_bind_s", NULL );
+ } else {
+ tester_ldap_error( ld, "ldap_sasl_bind_s", NULL );
+ }
}
-
+
if ( !noinit ) {
ldap_unbind_ext( ld, NULL, NULL );
ld = NULL;
}
- if ( rc != LDAP_SUCCESS && !force ) {
+
+ if ( rc != LDAP_SUCCESS ) {
break;
}
}
@@ -260,7 +267,7 @@ do_bind( char *uri, char *dn, struct berval *pass, int maxloop,
static int
-do_base( char *uri, struct berval *base, struct berval *pass, char *pwattr,
+do_base( char *uri, char *dn, struct berval *pass, char *base, char *filter, char *pwattr,
int maxloop, int force, int chaserefs, int noinit, int delay )
{
LDAP *ld = NULL;
@@ -279,7 +286,6 @@ do_base( char *uri, struct berval *base, struct berval *pass, char *pwattr,
struct timeval beg, end;
#endif
int version = LDAP_VERSION3;
- struct berval pw = { 0, NULL };
char *nullstr = "";
srand(pid);
@@ -294,19 +300,19 @@ do_base( char *uri, struct berval *base, struct berval *pass, char *pwattr,
(void) ldap_set_option( ld, LDAP_OPT_REFERRALS,
chaserefs ? LDAP_OPT_ON: LDAP_OPT_OFF );
- rc = ldap_sasl_bind_s( ld, NULL, LDAP_SASL_SIMPLE, &pw, NULL, NULL, NULL );
+ rc = ldap_sasl_bind_s( ld, dn, LDAP_SASL_SIMPLE, pass, NULL, NULL, NULL );
if ( rc != LDAP_SUCCESS ) {
tester_ldap_error( ld, "ldap_sasl_bind_s", NULL );
exit( EXIT_FAILURE );
}
fprintf( stderr, "PID=%ld - Bind(%d): base=\"%s\", filter=\"%s\" attr=\"%s\".\n",
- (long) pid, maxloop, base->bv_val, filter, pwattr );
+ (long) pid, maxloop, base, filter, pwattr );
if ( pwattr != NULL ) {
attrs[ 0 ] = pwattr;
}
- rc = ldap_search_ext( ld, base->bv_val, LDAP_SCOPE_SUBTREE,
+ rc = ldap_search_ext( ld, base, LDAP_SCOPE_SUBTREE,
filter, attrs, 0, NULL, NULL, 0, 0, &msgid );
if ( rc != LDAP_SUCCESS ) {
tester_ldap_error( ld, "ldap_search_ext", NULL );
@@ -333,13 +339,8 @@ do_base( char *uri, struct berval *base, struct berval *pass, char *pwattr,
creds = realloc( creds, (ndns + 1)*sizeof(struct berval) );
if ( values == NULL ) {
novals:;
- if ( pass != NULL ) {
- ber_dupbv( &creds[ndns], pass );
-
- } else {
- creds[ndns].bv_len = 0;
- creds[ndns].bv_val = nullstr;
- }
+ creds[ndns].bv_len = 0;
+ creds[ndns].bv_val = nullstr;
} else {
static struct berval cleartext = BER_BVC( "{CLEARTEXT} " );
@@ -387,25 +388,26 @@ novals:;
#endif
if ( ndns == 0 ) {
- tester_error( "No RDNs" );
+ tester_error( "No DNs" );
return 1;
}
- fprintf( stderr, "PID=%ld - got %d values.\n", (long) pid, ndns );
+ fprintf( stderr, " PID=%ld - Bind base=\"%s\" filter=\"%s\" got %d values.\n",
+ (long) pid, base, filter, ndns );
- /* Ok, got list of RDNs, now start binding to each */
+ /* Ok, got list of DNs, now start binding to each */
for ( i = 0; i < maxloop; i++ ) {
int j, k;
- struct berval *cred = pass;
+ struct berval cred = { 0, NULL };
for ( j = 0, k = 0; k < ndns; k++) {
j = rand() % ndns;
}
if ( creds && !BER_BVISEMPTY( &creds[j] ) ) {
- cred = &creds[j];
+ cred = creds[j];
}
- if ( do_bind( uri, dns[j], cred, 1, force, chaserefs, noinit, &ld )
+ if ( do_bind( uri, dns[j], &cred, 1, force, chaserefs, noinit, &ld )
&& !force )
{
break;
@@ -425,8 +427,8 @@ novals:;
end = GetTickCount();
end -= beg;
- fprintf( stderr, "Done %d Binds in %d.%03d seconds.\n", i,
- end / 1000, end % 1000 );
+ fprintf( stderr, " PID=%ld - Bind done %d in %d.%03d seconds.\n",
+ (long) pid, i, end / 1000, end % 1000 );
#else
gettimeofday( &end, NULL );
end.tv_usec -= beg.tv_usec;
@@ -436,8 +438,8 @@ novals:;
}
end.tv_sec -= beg.tv_sec;
- fprintf( stderr, "Done %d Binds in %ld.%06ld seconds.\n", i,
- (long) end.tv_sec, (long) end.tv_usec );
+ fprintf( stderr, " PID=%ld - Bind done %d in %ld.%06ld seconds.\n",
+ (long) pid, i, (long) end.tv_sec, (long) end.tv_usec );
#endif
if ( dns ) {
diff --git a/tests/progs/slapd-common.c b/tests/progs/slapd-common.c
index 3724794a8b1797fc32b93e31c24d295ed656bf62..e5f1d41a01521e1d1c2b4edd00718b5a773c3869 100644
--- a/tests/progs/slapd-common.c
+++ b/tests/progs/slapd-common.c
@@ -28,12 +28,188 @@
#include <ldap.h>
+#include "ldap_pvt.h"
+#include "slapd-common.h"
+
static char progname[ BUFSIZ ];
+tester_t progtype;
+
+#define TESTER_SERVER_LAST (LDAP_OTHER + 1)
+#define TESTER_CLIENT_LAST (- LDAP_REFERRAL_LIMIT_EXCEEDED + 1)
+static unsigned ignore_server[ TESTER_SERVER_LAST ];
+static unsigned ignore_client[ TESTER_CLIENT_LAST ];
+
+static struct {
+ char *name;
+ int err;
+} ignore_str2err[] = {
+ { "OPERATIONS_ERROR", LDAP_OPERATIONS_ERROR },
+ { "PROTOCOL_ERROR", LDAP_PROTOCOL_ERROR },
+ { "TIMELIMIT_EXCEEDED", LDAP_TIMELIMIT_EXCEEDED },
+ { "SIZELIMIT_EXCEEDED", LDAP_SIZELIMIT_EXCEEDED },
+ { "COMPARE_FALSE", LDAP_COMPARE_FALSE },
+ { "COMPARE_TRUE", LDAP_COMPARE_TRUE },
+ { "AUTH_METHOD_NOT_SUPPORTED", LDAP_AUTH_METHOD_NOT_SUPPORTED },
+ { "STRONG_AUTH_NOT_SUPPORTED", LDAP_STRONG_AUTH_NOT_SUPPORTED },
+ { "STRONG_AUTH_REQUIRED", LDAP_STRONG_AUTH_REQUIRED },
+ { "STRONGER_AUTH_REQUIRED", LDAP_STRONGER_AUTH_REQUIRED },
+ { "PARTIAL_RESULTS", LDAP_PARTIAL_RESULTS },
+
+ { "REFERRAL", LDAP_REFERRAL },
+ { "ADMINLIMIT_EXCEEDED", LDAP_ADMINLIMIT_EXCEEDED },
+ { "UNAVAILABLE_CRITICAL_EXTENSION", LDAP_UNAVAILABLE_CRITICAL_EXTENSION },
+ { "CONFIDENTIALITY_REQUIRED", LDAP_CONFIDENTIALITY_REQUIRED },
+ { "SASL_BIND_IN_PROGRESS", LDAP_SASL_BIND_IN_PROGRESS },
+
+ { "NO_SUCH_ATTRIBUTE", LDAP_NO_SUCH_ATTRIBUTE },
+ { "UNDEFINED_TYPE", LDAP_UNDEFINED_TYPE },
+ { "INAPPROPRIATE_MATCHING", LDAP_INAPPROPRIATE_MATCHING },
+ { "CONSTRAINT_VIOLATION", LDAP_CONSTRAINT_VIOLATION },
+ { "TYPE_OR_VALUE_EXISTS", LDAP_TYPE_OR_VALUE_EXISTS },
+ { "INVALID_SYNTAX", LDAP_INVALID_SYNTAX },
+
+ { "NO_SUCH_OBJECT", LDAP_NO_SUCH_OBJECT },
+ { "ALIAS_PROBLEM", LDAP_ALIAS_PROBLEM },
+ { "INVALID_DN_SYNTAX", LDAP_INVALID_DN_SYNTAX },
+ { "IS_LEAF", LDAP_IS_LEAF },
+ { "ALIAS_DEREF_PROBLEM", LDAP_ALIAS_DEREF_PROBLEM },
+
+ /* obsolete */
+ { "PROXY_AUTHZ_FAILURE", LDAP_X_PROXY_AUTHZ_FAILURE },
+ { "INAPPROPRIATE_AUTH", LDAP_INAPPROPRIATE_AUTH },
+ { "INVALID_CREDENTIALS", LDAP_INVALID_CREDENTIALS },
+ { "INSUFFICIENT_ACCESS", LDAP_INSUFFICIENT_ACCESS },
+
+ { "BUSY", LDAP_BUSY },
+ { "UNAVAILABLE", LDAP_UNAVAILABLE },
+ { "UNWILLING_TO_PERFORM", LDAP_UNWILLING_TO_PERFORM },
+ { "LOOP_DETECT", LDAP_LOOP_DETECT },
+
+ { "NAMING_VIOLATION", LDAP_NAMING_VIOLATION },
+ { "OBJECT_CLASS_VIOLATION", LDAP_OBJECT_CLASS_VIOLATION },
+ { "NOT_ALLOWED_ON_NONLEAF", LDAP_NOT_ALLOWED_ON_NONLEAF },
+ { "NOT_ALLOWED_ON_RDN", LDAP_NOT_ALLOWED_ON_RDN },
+ { "ALREADY_EXISTS", LDAP_ALREADY_EXISTS },
+ { "NO_OBJECT_CLASS_MODS", LDAP_NO_OBJECT_CLASS_MODS },
+ { "RESULTS_TOO_LARGE", LDAP_RESULTS_TOO_LARGE },
+ { "AFFECTS_MULTIPLE_DSAS", LDAP_AFFECTS_MULTIPLE_DSAS },
+
+ { "OTHER", LDAP_OTHER },
+
+ { "SERVER_DOWN", LDAP_SERVER_DOWN },
+ { "LOCAL_ERROR", LDAP_LOCAL_ERROR },
+ { "ENCODING_ERROR", LDAP_ENCODING_ERROR },
+ { "DECODING_ERROR", LDAP_DECODING_ERROR },
+ { "TIMEOUT", LDAP_TIMEOUT },
+ { "AUTH_UNKNOWN", LDAP_AUTH_UNKNOWN },
+ { "FILTER_ERROR", LDAP_FILTER_ERROR },
+ { "USER_CANCELLED", LDAP_USER_CANCELLED },
+ { "PARAM_ERROR", LDAP_PARAM_ERROR },
+ { "NO_MEMORY", LDAP_NO_MEMORY },
+ { "CONNECT_ERROR", LDAP_CONNECT_ERROR },
+ { "NOT_SUPPORTED", LDAP_NOT_SUPPORTED },
+ { "CONTROL_NOT_FOUND", LDAP_CONTROL_NOT_FOUND },
+ { "NO_RESULTS_RETURNED", LDAP_NO_RESULTS_RETURNED },
+ { "MORE_RESULTS_TO_RETURN", LDAP_MORE_RESULTS_TO_RETURN },
+ { "CLIENT_LOOP", LDAP_CLIENT_LOOP },
+ { "REFERRAL_LIMIT_EXCEEDED", LDAP_REFERRAL_LIMIT_EXCEEDED },
+
+ { NULL }
+};
+
+#define UNKNOWN_ERR (1234567890)
+
+static int
+tester_ignore_str2err( const char *err )
+{
+ int i;
+ unsigned ignore = 1;
+
+ if ( strcmp( err, "ALL" ) == 0 ) {
+ for ( i = 0; ignore_str2err[ i ].name != NULL; i++ ) {
+ int err = ignore_str2err[ i ].err;
+
+ if ( err > 0 ) {
+ ignore_server[ err ] = 1;
+
+ } else if ( err < 0 ) {
+ ignore_client[ -err ] = 1;
+ }
+ }
+
+ return 0;
+ }
+
+ if ( err[ 0 ] == '!' ) {
+ ignore = 0;
+ err++;
+ }
+
+ for ( i = 0; ignore_str2err[ i ].name != NULL; i++ ) {
+ if ( strcmp( err, ignore_str2err[ i ].name ) == 0 ) {
+ int err = ignore_str2err[ i ].err;
+
+ if ( err > 0 ) {
+ ignore_server[ err ] = ignore;
+
+ } else if ( err < 0 ) {
+ ignore_client[ -err ] = ignore;
+ }
+
+ return err;
+ }
+ }
+
+ return UNKNOWN_ERR;
+}
+
+int
+tester_ignore_str2errlist( const char *err )
+{
+ int i;
+ char **errs = ldap_str2charray( err, "," );
+
+ for ( i = 0; errs[ i ] != NULL; i++ ) {
+ /* TODO: allow <err>:<prog> to ignore <err> only when <prog> */
+ (void)tester_ignore_str2err( errs[ i ] );
+ }
+
+ ldap_charray_free( errs );
+
+ return 0;
+}
+
+unsigned
+tester_ignore_err( int err )
+{
+ unsigned rc = 1;
+
+ if ( err > 0 ) {
+ if ( err < TESTER_SERVER_LAST ) {
+ rc = ignore_server[ err ];
+ if ( rc ) {
+ ignore_server[ err ]++;
+ }
+ }
+
+ } else if ( err < 0 ) {
+ if ( -err < TESTER_CLIENT_LAST ) {
+ rc = ignore_client[ -err ];
+ if ( rc ) {
+ ignore_client[ -err ]++;
+ }
+ }
+ }
+
+ /* SUCCESS is always "ignored" */
+ return rc;
+}
void
-tester_init( const char *pname )
+tester_init( const char *pname, tester_t ptype )
{
snprintf( progname, sizeof( progname ), "%s PID=%d", pname, getpid() );
+ progtype = ptype;
}
char *
diff --git a/tests/progs/slapd-common.h b/tests/progs/slapd-common.h
index e1142ead0a8c285a404cbc2c5b405ddf8e3ecdf6..e42e8080a655ebe6d7f64c1e451f95bec6b0db51 100644
--- a/tests/progs/slapd-common.h
+++ b/tests/progs/slapd-common.h
@@ -20,10 +20,22 @@
#ifndef SLAPD_COMMON_H
#define SLAPD_COMMON_H
-extern void tester_init( const char *pname );
+typedef enum {
+ TESTER_TESTER,
+ TESTER_ADDEL,
+ TESTER_BIND,
+ TESTER_MODIFY,
+ TESTER_MODRDN,
+ TESTER_READ,
+ TESTER_SEARCH
+} tester_t;
+
+extern void tester_init( const char *pname, tester_t ptype );
extern char * tester_uri( char *uri, char *host, int port );
extern void tester_error( const char *msg );
extern void tester_perror( const char *fname, const char *msg );
extern void tester_ldap_error( LDAP *ld, const char *fname, const char *msg );
+extern int tester_ignore_str2errlist( const char *err );
+extern unsigned tester_ignore_err( int err );
#endif /* SLAPD_COMMON_H */
diff --git a/tests/progs/slapd-modify.c b/tests/progs/slapd-modify.c
index 887d9462db30743275751ac6c28811fbf998c809..cb416d861180984e3df3edaac42d4dcb98a21454 100644
--- a/tests/progs/slapd-modify.c
+++ b/tests/progs/slapd-modify.c
@@ -49,6 +49,7 @@ usage( char *name )
"-D <manager> "
"-w <passwd> "
"-e <entry> "
+ "[-i <ignore>] "
"[-l <loops>] "
"[-L <outerloops>] "
"[-r <maxretries>] "
@@ -78,9 +79,9 @@ main( int argc, char **argv )
int friendly = 0;
int chaserefs = 0;
- tester_init( "slapd-modify" );
+ tester_init( "slapd-modify", TESTER_MODIFY );
- while ( (i = getopt( argc, argv, "CFH:h:p:D:w:e:a:l:L:r:t:" )) != EOF ) {
+ while ( (i = getopt( argc, argv, "CFH:h:i:p:D:w:e:a:l:L:r:t:" )) != EOF ) {
switch ( i ) {
case 'C':
chaserefs++;
@@ -98,6 +99,10 @@ main( int argc, char **argv )
host = strdup( optarg );
break;
+ case 'i':
+ /* ignored (!) by now */
+ break;
+
case 'p': /* the servers port */
if ( lutil_atoi( &port, optarg ) != 0 ) {
usage( argv[0] );
@@ -111,6 +116,7 @@ main( int argc, char **argv )
case 'w': /* the server managers password */
passwd.bv_val = strdup( optarg );
passwd.bv_len = strlen( optarg );
+ memset( optarg, '*', passwd.bv_len );
break;
case 'e': /* entry to modify */
diff --git a/tests/progs/slapd-modrdn.c b/tests/progs/slapd-modrdn.c
index 515e58efca2a4cd361096c7c0fa249650feef611..f2e7ad82f3f53f4671138836d214ce8a5e86350d 100644
--- a/tests/progs/slapd-modrdn.c
+++ b/tests/progs/slapd-modrdn.c
@@ -52,6 +52,7 @@ usage( char *name )
"-D <manager> "
"-w <passwd> "
"-e <entry> "
+ "[-i <ignore>] "
"[-l <loops>] "
"[-L <outerloops>] "
"[-r <maxretries>] "
@@ -79,9 +80,9 @@ main( int argc, char **argv )
int friendly = 0;
int chaserefs = 0;
- tester_init( "slapd-modrdn" );
+ tester_init( "slapd-modrdn", TESTER_MODRDN );
- while ( (i = getopt( argc, argv, "CFH:h:p:D:w:e:l:L:r:t:" )) != EOF ) {
+ while ( (i = getopt( argc, argv, "CFH:h:i:p:D:w:e:l:L:r:t:" )) != EOF ) {
switch( i ) {
case 'C':
chaserefs++;
@@ -99,6 +100,10 @@ main( int argc, char **argv )
host = strdup( optarg );
break;
+ case 'i':
+ /* ignored (!) by now */
+ break;
+
case 'p': /* the servers port */
if ( lutil_atoi( &port, optarg ) != 0 ) {
usage( argv[0] );
@@ -112,6 +117,7 @@ main( int argc, char **argv )
case 'w': /* the server managers password */
passwd.bv_val = strdup( optarg );
passwd.bv_len = strlen( optarg );
+ memset( optarg, '*', passwd.bv_len );
break;
case 'e': /* entry to rename */
diff --git a/tests/progs/slapd-read.c b/tests/progs/slapd-read.c
index c94878acee718b52a15e703f749b20a80b30c645..0de1b109f642f0cf7ec12479a0026663da9de0bf 100644
--- a/tests/progs/slapd-read.c
+++ b/tests/progs/slapd-read.c
@@ -61,6 +61,7 @@ usage( char *name )
"[-C] "
"[-F] "
"[-f filter] "
+ "[-i <ignore>] "
"[-l <loops>] "
"[-L <outerloops>] "
"[-r <maxretries>] "
@@ -88,9 +89,12 @@ main( int argc, char **argv )
int chaserefs = 0;
int noattrs = 0;
- tester_init( "slapd-read" );
+ tester_init( "slapd-read", TESTER_READ );
- while ( (i = getopt( argc, argv, "ACD:H:h:p:e:Ff:l:L:r:t:w:" )) != EOF ) {
+ /* by default, tolerate referrals and no such object */
+ tester_ignore_str2errlist( "REFERRAL,NO_SUCH_OBJECT" );
+
+ while ( (i = getopt( argc, argv, "ACD:H:h:i:p:e:Ff:l:L:r:t:w:" )) != EOF ) {
switch( i ) {
case 'A':
noattrs++;
@@ -108,6 +112,10 @@ main( int argc, char **argv )
host = strdup( optarg );
break;
+ case 'i':
+ tester_ignore_str2errlist( optarg );
+ break;
+
case 'p': /* the servers port */
if ( lutil_atoi( &port, optarg ) != 0 ) {
usage( argv[0] );
@@ -121,6 +129,7 @@ main( int argc, char **argv )
case 'w': /* the server managers password */
passwd.bv_val = strdup( optarg );
passwd.bv_len = strlen( optarg );
+ memset( optarg, '*', passwd.bv_len );
break;
case 'e': /* DN to search for */
@@ -261,7 +270,8 @@ do_random( char *uri, char *manager, struct berval *passwd,
ldap_msgfree( res );
if ( do_retry == maxretries ) {
- fprintf( stderr, "PID=%ld - got %d values.\n", (long) pid, nvalues );
+ fprintf( stderr, " PID=%ld - Read base=\"%s\" filter=\"%s\" got %d values.\n",
+ (long) pid, sbase, filter, nvalues );
}
for ( i = 0; i < innerloop; i++ ) {
@@ -294,7 +304,6 @@ do_read( char *uri, char *manager, struct berval *passwd, char *entry,
pid_t pid = getpid();
int rc = LDAP_SUCCESS;
int version = LDAP_VERSION3;
- int first = 1;
retry:;
if ( ld == NULL ) {
@@ -341,39 +350,37 @@ retry:;
rc = ldap_search_ext_s( ld, entry, LDAP_SCOPE_BASE,
NULL, attrs, noattrs, NULL, NULL, NULL,
LDAP_NO_LIMIT, &res );
- switch ( rc ) {
- case LDAP_REFERRAL:
- /* don't log: it's intended */
- if ( force >= 2 ) {
- if ( !first ) {
- break;
+ if ( res != NULL ) {
+ ldap_msgfree( res );
+ }
+
+ if ( rc ) {
+ unsigned first = tester_ignore_err( rc );
+ char buf[ BUFSIZ ];
+
+ snprintf( buf, sizeof( buf ), "ldap_search_ext_s(%s)", entry );
+
+ /* if ignore.. */
+ if ( first ) {
+ /* only log if first occurrence */
+ if ( force < 2 || first == 1 ) {
+ tester_ldap_error( ld, buf, NULL );
}
- first = 0;
+ continue;
}
- tester_ldap_error( ld, "ldap_search_ext_s", NULL );
- /* fallthru */
-
- case LDAP_SUCCESS:
- break;
- default:
- tester_ldap_error( ld, "ldap_search_ext_s", NULL );
+ /* busy needs special handling */
+ tester_ldap_error( ld, buf, NULL );
if ( rc == LDAP_BUSY && do_retry > 0 ) {
+ ldap_unbind_ext( ld, NULL, NULL );
+ ld = NULL;
do_retry--;
goto retry;
}
- if ( rc != LDAP_NO_SUCH_OBJECT ) {
- goto done;
- }
break;
}
-
- if ( res != NULL ) {
- ldap_msgfree( res );
- }
}
-done:;
if ( ldp != NULL ) {
*ldp = ld;
diff --git a/tests/progs/slapd-search.c b/tests/progs/slapd-search.c
index 51d0ff2d7d36241ab3d56e06c6cf3c557150d402..1b7795cca771821a302a97ae683f7882eafc92b3 100644
--- a/tests/progs/slapd-search.c
+++ b/tests/progs/slapd-search.c
@@ -62,6 +62,7 @@ usage( char *name )
"[-A] "
"[-C] "
"[-F] "
+ "[-i <ignore>] "
"[-l <loops>] "
"[-L <outerloops>] "
"[-r <maxretries>] "
@@ -90,9 +91,12 @@ main( int argc, char **argv )
int chaserefs = 0;
int noattrs = 0;
- tester_init( "slapd-search" );
+ tester_init( "slapd-search", TESTER_SEARCH );
- while ( (i = getopt( argc, argv, "Aa:b:CD:f:FH:h:l:L:p:w:r:t:" )) != EOF ) {
+ /* by default, tolerate referrals and no such object */
+ tester_ignore_str2errlist( "REFERRAL,NO_SUCH_OBJECT" );
+
+ while ( (i = getopt( argc, argv, "Aa:b:CD:f:FH:h:i:l:L:p:w:r:t:" )) != EOF ) {
switch( i ) {
case 'A':
noattrs++;
@@ -110,6 +114,10 @@ main( int argc, char **argv )
host = strdup( optarg );
break;
+ case 'i':
+ tester_ignore_str2errlist( optarg );
+ break;
+
case 'p': /* the servers port */
if ( lutil_atoi( &port, optarg ) != 0 ) {
usage( argv[0] );
@@ -123,6 +131,7 @@ main( int argc, char **argv )
case 'w': /* the server managers password */
passwd.bv_val = strdup( optarg );
passwd.bv_len = strlen( optarg );
+ memset( optarg, '*', passwd.bv_len );
break;
case 'a':
@@ -279,7 +288,8 @@ do_random( char *uri, char *manager, struct berval *passwd,
ldap_msgfree( res );
if ( do_retry == maxretries ) {
- fprintf( stderr, "PID=%ld - got %d values.\n", (long) pid, nvalues );
+ fprintf( stderr, " PID=%ld - Search base=\"%s\" filter=\"%s\" got %d values.\n",
+ (long) pid, sbase, filter, nvalues );
}
for ( i = 0; i < innerloop; i++ ) {
@@ -316,7 +326,6 @@ do_search( char *uri, char *manager, struct berval *passwd,
pid_t pid = getpid();
int rc = LDAP_SUCCESS;
int version = LDAP_VERSION3;
- int first = 1;
char buf[ BUFSIZ ];
@@ -371,39 +380,32 @@ retry:;
ldap_msgfree( res );
}
- switch ( rc ) {
- case LDAP_REFERRAL:
- /* don't log: it's intended */
- if ( force >= 2 ) {
- if ( !first ) {
- break;
+ if ( rc ) {
+ unsigned first = tester_ignore_err( rc );
+ /* if ignore.. */
+ if ( first ) {
+ /* only log if first occurrence */
+ if ( force < 2 || first == 1 ) {
+ tester_ldap_error( ld, "ldap_search_ext_s", NULL );
}
- first = 0;
+ continue;
}
- tester_ldap_error( ld, "ldap_search_ext_s", NULL );
- /* fallthru */
- case LDAP_SUCCESS:
- break;
-
- default:
+ /* busy needs special handling */
snprintf( buf, sizeof( buf ),
"base=\"%s\" filter=\"%s\"\n",
sbase, filter );
tester_ldap_error( ld, "ldap_search_ext_s", buf );
if ( rc == LDAP_BUSY && do_retry > 0 ) {
ldap_unbind_ext( ld, NULL, NULL );
+ ld = NULL;
do_retry--;
goto retry;
}
- if ( rc != LDAP_NO_SUCH_OBJECT ) {
- goto done;
- }
break;
}
}
-done:;
if ( ldp != NULL ) {
*ldp = ld;
diff --git a/tests/progs/slapd-tester.c b/tests/progs/slapd-tester.c
index 13cbc00d50858681dd94574bb48ed6904e67270a..fdca62f2044f0cfae33ff3dbea2001e0c157858b 100644
--- a/tests/progs/slapd-tester.c
+++ b/tests/progs/slapd-tester.c
@@ -83,6 +83,7 @@ usage( char *name )
"-D <manager> "
"-w <passwd> "
"-d <datadir> "
+ "[-i <ignore>] "
"[-j <maxchild>] "
"[-l <loops>] "
"[-L <outerloops>] "
@@ -115,6 +116,7 @@ main( int argc, char **argv )
int friendly = 0;
int chaserefs = 0;
int noattrs = 0;
+ char *ignore = NULL;
/* search */
char *sfile = NULL;
char *sreqs[MAXREQS];
@@ -170,10 +172,12 @@ main( int argc, char **argv )
char bloops[] = "18446744073709551615UL";
char *friendlyOpt = NULL;
+ int pw_ask = 0;
+ char *pw_file = NULL;
- tester_init( "slapd-tester" );
+ tester_init( "slapd-tester", TESTER_TESTER );
- while ( (i = getopt( argc, argv, "ACD:d:FH:h:j:l:L:P:p:r:t:w:" )) != EOF ) {
+ while ( (i = getopt( argc, argv, "ACD:d:FH:h:i:j:l:L:P:p:r:t:w:Wy:" )) != EOF ) {
switch( i ) {
case 'A':
noattrs++;
@@ -203,6 +207,10 @@ main( int argc, char **argv )
host = strdup( optarg );
break;
+ case 'i':
+ ignore = optarg;
+ break;
+
case 'j': /* the number of parallel clients */
if ( lutil_atoi( &maxkids, optarg ) != 0 ) {
usage( argv[0] );
@@ -237,6 +245,15 @@ main( int argc, char **argv )
case 'w': /* the managers passwd */
passwd = ArgDup( optarg );
+ memset( optarg, '*', strlen( optarg ) );
+ break;
+
+ case 'W':
+ pw_ask++;
+ break;
+
+ case 'y':
+ pw_file = optarg;
break;
default:
@@ -254,11 +271,9 @@ main( int argc, char **argv )
#endif
/* get the file list */
if ( ( datadir = opendir( dirname )) == NULL ) {
-
fprintf( stderr, "%s: couldn't open data directory \"%s\".\n",
argv[0], dirname );
exit( EXIT_FAILURE );
-
}
/* look for search, read, modrdn, and add/delete files */
@@ -288,6 +303,19 @@ main( int argc, char **argv )
closedir( datadir );
+ if ( pw_ask ) {
+ passwd = getpassphrase( _("Enter LDAP Password: ") );
+
+ } else if ( pw_file ) {
+ struct berval pw;
+
+ if ( lutil_get_filed_password( pw_file, &pw ) ) {
+ exit( EXIT_FAILURE );
+ }
+
+ passwd = pw.bv_val;
+ }
+
/* look for search requests */
if ( sfile ) {
snum = get_search_filters( sfile, sreqs, sattrs, sbase );
@@ -375,6 +403,10 @@ main( int argc, char **argv )
if ( noattrs ) {
sargs[sanum++] = "-A";
}
+ if ( ignore ) {
+ sargs[sanum++] = "-i";
+ sargs[sanum++] = ignore;
+ }
sargs[sanum++] = "-b";
sargs[sanum++] = NULL; /* will hold the search base */
sargs[sanum++] = "-f";
@@ -423,6 +455,10 @@ main( int argc, char **argv )
if ( noattrs ) {
rargs[ranum++] = "-A";
}
+ if ( ignore ) {
+ rargs[ranum++] = "-i";
+ rargs[ranum++] = ignore;
+ }
rargs[ranum++] = "-e";
rargs[ranum++] = NULL; /* will hold the read entry */
@@ -466,6 +502,10 @@ main( int argc, char **argv )
if ( chaserefs ) {
margs[manum++] = "-C";
}
+ if ( ignore ) {
+ margs[manum++] = "-i";
+ margs[manum++] = ignore;
+ }
margs[manum++] = "-e";
margs[manum++] = NULL; /* will hold the modrdn entry */
margs[manum++] = NULL;
@@ -505,6 +545,10 @@ main( int argc, char **argv )
if ( chaserefs ) {
modargs[modanum++] = "-C";
}
+ if ( ignore ) {
+ modargs[modanum++] = "-i";
+ modargs[modanum++] = ignore;
+ }
modargs[modanum++] = "-e";
modargs[modanum++] = NULL; /* will hold the modify entry */
modargs[modanum++] = "-a";;
@@ -546,6 +590,10 @@ main( int argc, char **argv )
if ( chaserefs ) {
aargs[aanum++] = "-C";
}
+ if ( ignore ) {
+ aargs[aanum++] = "-i";
+ aargs[aanum++] = ignore;
+ }
aargs[aanum++] = "-f";
aargs[aanum++] = NULL; /* will hold the add data file */
aargs[aanum++] = NULL;
@@ -584,6 +632,10 @@ main( int argc, char **argv )
if ( chaserefs ) {
bargs[banum++] = "-C";
}
+ if ( ignore ) {
+ bargs[banum++] = "-i";
+ bargs[banum++] = ignore;
+ }
bargs[banum++] = "-D";
bargs[banum++] = NULL;
bargs[banum++] = "-w";
@@ -641,16 +693,24 @@ main( int argc, char **argv )
if ( DOREQ( bnum, j ) ) {
int jj = j % bnum;
- bargs[banum - 4] = breqs[jj];
- bargs[banum - 2] = bcreds[jj];
if ( battrs[jj] != NULL ) {
- bargs[banum - 1] = "-a";
- bargs[banum] = battrs[jj];
-
+ bargs[banum - 4] = manager ? manager : "";
+ bargs[banum - 2] = passwd ? passwd : "";
+
+ bargs[banum - 1] = "-b";
+ bargs[banum] = breqs[jj];
+ bargs[banum + 1] = "-f";
+ bargs[banum + 2] = bcreds[jj];
+ bargs[banum + 3] = "-a";
+ bargs[banum + 4] = battrs[jj];
} else {
- sargs[sanum - 1] = NULL;
+ bargs[banum - 4] = breqs[jj];
+ bargs[banum - 2] = bcreds[jj];
+ bargs[banum - 1] = NULL;
}
+
fork_child( bcmd, bargs );
+ bargs[banum - 1] = NULL;
}
}
diff --git a/tests/run.in b/tests/run.in
index 5fc0d4863bac8e128237183f63f54c04e0d91c90..966762280ac5eb4c7c21d2fc3028ba0435371404 100644
--- a/tests/run.in
+++ b/tests/run.in
@@ -52,13 +52,22 @@ AC_WITH_TLS=@WITH_TLS@
AC_WITH_MODULES_ENABLED=@WITH_MODULES_ENABLED@
AC_ACI_ENABLED=aci@WITH_ACI_ENABLED@
AC_THREADS=threads@BUILD_THREAD@
+AC_LIBS_DYNAMIC=lib@BUILD_LIBS_DYNAMIC@
+
+# sanitize
+if test "${AC_ldap}" = "ldapmod" -a "${AC_LIBS_DYNAMIC}" = "static" ; then
+ AC_ldap="ldapno"
+fi
+if test "${AC_meta}" = "metamod" -a "${AC_LIBS_DYNAMIC}" = "static" ; then
+ AC_meta="metano"
+fi
export AC_bdb AC_hdb AC_ldap AC_meta AC_monitor AC_relay AC_sql \
AC_accesslog AC_dynlist AC_pcache AC_ppolicy AC_refint AC_retcode \
AC_rwm AC_unique AC_syncprov AC_translucent AC_valsort \
AC_dds \
AC_WITH_SASL AC_WITH_TLS AC_WITH_MODULES_ENABLED AC_ACI_ENABLED \
- AC_THREADS
+ AC_THREADS AC_LIBS_DYNAMIC
if test ! -x ../servers/slapd/slapd ; then
echo "Could not locate slapd(8)"
@@ -180,6 +189,9 @@ fi
# disable LDAP initialization
LDAPNOINIT=true; export LDAPNOINIT
+$SLAPPASSWD -g -n >$CONFIGPWF
+echo "rootpw `$SLAPPASSWD -T $CONFIGPWF`" >configpw.conf
+
echo "Running ${SCRIPT}..."
$SCRIPT $*
RC=$?
diff --git a/tests/scripts/conf.sh b/tests/scripts/conf.sh
index c16ea0bb6800c483f0f0c31c155c45a07ab62496..7bef25a2a58305ba24b092cf063e056a5f98ebb6 100755
--- a/tests/scripts/conf.sh
+++ b/tests/scripts/conf.sh
@@ -69,7 +69,6 @@ sed -e "s/@BACKEND@/${BACKEND}/" \
-e "s;@PORT4@;${PORT4};" \
-e "s;@PORT5@;${PORT5};" \
-e "s;@PORT6@;${PORT6};" \
- -e "s/@CONFIGPW@/${CONFIGPW}/" \
-e "s/@SASL_MECH@/${SASL_MECH}/" \
-e "s/@CACHETTL@/${CACHETTL}/" \
-e "s/@ENTRY_LIMIT@/${CACHE_ENTRY_LIMIT}/" \
diff --git a/tests/scripts/defines.sh b/tests/scripts/defines.sh
index f4da57e0e5876b0a37511fbccdfd92e29fb8b50f..7a2a21235aaef52c2c2718bc83f63426b96f40c3 100755
--- a/tests/scripts/defines.sh
+++ b/tests/scripts/defines.sh
@@ -15,13 +15,16 @@
umask 077
+# backends
MONITORDB=${AC_monitor-no}
BACKLDAP=${AC_ldap-ldapno}
BACKMETA=${AC_meta-metano}
BACKRELAY=${AC_relay-relayno}
BACKSQL=${AC_sql-sqlno}
-RDBMS=${SLAPD_USE_SQL-rdbmsno}
-RDBMSWRITE=${SLAPD_USE_SQLWRITE-no}
+ RDBMS=${SLAPD_USE_SQL-rdbmsno}
+ RDBMSWRITE=${SLAPD_USE_SQLWRITE-no}
+
+# overlays
ACCESSLOG=${AC_accesslog-accesslogno}
DDS=${AC_dds-ddsno}
DYNLIST=${AC_dynlist-dynlistno}
@@ -34,12 +37,15 @@ SYNCPROV=${AC_syncprov-syncprovno}
TRANSLUCENT=${AC_translucent-translucentno}
UNIQUE=${AC_unique-uniqueno}
VALSORT=${AC_valsort-valsortno}
+
+# misc
WITH_SASL=${AC_WITH_SASL-no}
USE_SASL=${SLAPD_USE_SASL-no}
WITHTLS=${AC_WITHTLS-yes}
ACI=${AC_ACI_ENABLED-acino}
THREADS=${AC_THREADS-threadsno}
+# dirs
PROGDIR=./progs
DATADIR=${USER_DATADIR-./testdata}
TESTDIR=${USER_TESTDIR-./testrun}
@@ -59,6 +65,10 @@ DBDIR5=$TESTDIR/db.5.a
DBDIR6=$TESTDIR/db.6.a
SQLCONCURRENCYDIR=$DATADIR/sql-concurrency
+CLIENTDIR=../clients/tools
+#CLIENTDIR=/usr/local/bin
+
+# conf
CONF=$DATADIR/slapd.conf
CONFTWO=$DATADIR/slapd2.conf
MCONF=$DATADIR/slapd-master.conf
@@ -110,8 +120,11 @@ VALSORTCONF=$DATADIR/slapd-valsort.conf
DYNLISTCONF=$DATADIR/slapd-dynlist.conf
RSLAVECONF=$DATADIR/slapd-repl-slave-remote.conf
PLSRSLAVECONF=$DATADIR/slapd-syncrepl-slave-persist-ldap.conf
+PLSRMASTERCONF=$DATADIR/slapd-syncrepl-multiproxy.conf
DDSCONF=$DATADIR/slapd-dds.conf
+PASSWDCONF=$DATADIR/slapd-passwd.conf
+# generated files
CONF1=$TESTDIR/slapd.1.conf
CONF2=$TESTDIR/slapd.2.conf
CONF3=$TESTDIR/slapd.3.conf
@@ -120,14 +133,22 @@ CONF5=$TESTDIR/slapd.5.conf
CONF6=$TESTDIR/slapd.6.conf
ADDCONF=$TESTDIR/slapadd.conf
-TOOLARGS="-x $LDAP_TOOLARGS"
-TOOLPROTO="-P 3"
+LOG1=$TESTDIR/slapd.1.log
+LOG2=$TESTDIR/slapd.2.log
+LOG3=$TESTDIR/slapd.3.log
+LOG4=$TESTDIR/slapd.4.log
+LOG5=$TESTDIR/slapd.5.log
+LOG6=$TESTDIR/slapd.6.log
+SLAPADDLOG1=$TESTDIR/slapadd.1.log
+SLURPLOG=$TESTDIR/slurp.log
-PASSWDCONF=$DATADIR/slapd-passwd.conf
+CONFIGPWF=./configpw
-CLIENTDIR=../clients/tools
-#CLIENTDIR=/usr/local/bin
+# args
+TOOLARGS="-x $LDAP_TOOLARGS"
+TOOLPROTO="-P 3"
+# cmds
LDIFFILTER=$SRCDIR/scripts/acfilter.sh
CONFFILTER=$SRCDIR/scripts/conf.sh
@@ -136,8 +157,6 @@ SLAPCAT="../servers/slapd/slapd -Tc -d 0 $LDAP_VERBOSE"
SLAPINDEX="../servers/slapd/slapd -Ti -d 0 $LDAP_VERBOSE"
SLAPPASSWD="../servers/slapd/slapd -Tpasswd"
-CONFIGPWF=$TESTDIR/configpw
-
unset DIFF_OPTIONS
# NOTE: -u/-c is not that portable...
DIFF="diff -i"
@@ -173,6 +192,8 @@ URI3="ldap://${LOCALHOST}:$PORT3/"
URI4="ldap://${LOCALHOST}:$PORT4/"
URI5="ldap://${LOCALHOST}:$PORT5/"
URI6="ldap://${LOCALHOST}:$PORT6/"
+
+# LDIF
LDIF=$DATADIR/test.ldif
LDIFGLUED=$DATADIR/test-glued.ldif
LDIFORDERED=$DATADIR/test-ordered.ldif
@@ -207,6 +228,8 @@ LDIFTRANSLUCENTMERGED=$DATADIR/test-translucent-merged.ldif
LDIFMETA=$DATADIR/test-meta.ldif
LDIFVALSORT=$DATADIR/test-valsort.ldif
SQLADD=$DATADIR/sql-add.ldif
+
+# strings
MONITOR=""
REFDN="c=US"
BASEDN="dc=example,dc=com"
@@ -231,15 +254,7 @@ METAMANAGERDN="cn=Manager,$METABASEDN"
VALSORTDN="cn=Manager,o=valsort"
VALSORTBASEDN="o=valsort"
-LOG1=$TESTDIR/slapd.1.log
-LOG2=$TESTDIR/slapd.2.log
-LOG3=$TESTDIR/slapd.3.log
-LOG4=$TESTDIR/slapd.4.log
-LOG5=$TESTDIR/slapd.5.log
-LOG6=$TESTDIR/slapd.6.log
-SLAPADDLOG1=$TESTDIR/slapadd.1.log
-SLURPLOG=$TESTDIR/slurp.log
-
+# generated outputs
SEARCHOUT=$TESTDIR/ldapsearch.out
SEARCHOUT2=$TESTDIR/ldapsearch2.out
SEARCHFLT=$TESTDIR/ldapsearch.flt
@@ -269,6 +284,7 @@ MASTERFLT=$SERVER1FLT
SLAVEOUT=$SERVER2OUT
SLAVEFLT=$SERVER2FLT
+# original outputs for cmp
PROXYCACHEOUT=$DATADIR/proxycache.out
REFERRALOUT=$DATADIR/referrals.out
SEARCHOUTMASTER=$DATADIR/search.out.master
diff --git a/tests/scripts/sql-test000-read b/tests/scripts/sql-test000-read
index d55d56ae3e1da761787dee80374b487507588253..1d206cc9f34fe7edf214a0580db8c38e6dc2dc6d 100755
--- a/tests/scripts/sql-test000-read
+++ b/tests/scripts/sql-test000-read
@@ -326,6 +326,19 @@ if test $RC != 0 ; then
exit $RC
fi
+# ITS#4604
+echo "Testing undefined attribute in filter..."
+echo "# Testing undefined attribute in filter..." >> $SEARCHOUT
+$LDAPSEARCH -h $LOCALHOST -p $PORT1 -b "$BASEDN" \
+ "(|(o=example)(foobar=x))" >> $SEARCHOUT 2>&1
+
+RC=$?
+if test $RC != 0 ; then
+ echo "ldapsearch failed ($RC)!"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit $RC
+fi
+
echo "Testing objectClass inheritance in filter..."
echo "# Testing objectClass inheritance in filter..." >> $SEARCHOUT
$LDAPSEARCH -h $LOCALHOST -p $PORT1 -b "$BASEDN" \
diff --git a/tests/scripts/sql-test001-concurrency b/tests/scripts/sql-test001-concurrency
index f5e6655495ed865a4052fe455314ae7d71a74425..0c85c476e46c012c2943dd3af0627cfefe558096 100755
--- a/tests/scripts/sql-test001-concurrency
+++ b/tests/scripts/sql-test001-concurrency
@@ -26,6 +26,16 @@ if test $RDBMS = "rdbmsno" ; then
exit 0
fi
+if test "x$LOOPS" = "x" ; then
+ LOOPS=5
+fi
+
+if test "x$CHILDREN" = "x" ; then
+ CHILDREN="-j 4"
+else
+ CHILDREN="-j $CHILDREN"
+fi
+
SQLDATADIR=$TESTDIR/sql-concurrency
mkdir -p $TESTDIR $SQLDATADIR
@@ -74,7 +84,7 @@ echo "Filtering original ldif used to create database..."
if test "${RDBMSWRITE}" != "yes"; then
echo "write test disabled for ${RDBMS}; set SLAPD_USE_SQLWRITE=yes to enable"
cp $SQLCONCURRENCYDIR/do_read* $SQLCONCURRENCYDIR/do_search* \
- $SQLDATADIR
+ $SQLCONCURRENCYDIR/do_bind* $SQLDATADIR
else
case ${RDBMS} in
# list here the RDBMSes whose mapping allows writes
@@ -84,14 +94,15 @@ else
*)
echo "write is not supported for ${RDBMS}; performing read-only concurrency test"
cp $SQLCONCURRENCYDIR/do_read* $SQLCONCURRENCYDIR/do_search* \
- $SQLDATADIR
+ $SQLCONCURRENCYDIR/do_bind* $SQLDATADIR
;;
esac
fi
echo "Using tester for concurrent server access..."
$SLAPDTESTER -P "$PROGDIR" -d "$SQLDATADIR" \
- -h $LOCALHOST -p $PORT1 -D "$MANAGERDN" -w $PASSWD -l 5 -j 4
+ -h $LOCALHOST -p $PORT1 -D "$MANAGERDN" -w $PASSWD \
+ -l $LOOPS $CHILDREN -FF
RC=$?
if test $RC != 0 ; then
diff --git a/tests/scripts/test006-acls b/tests/scripts/test006-acls
index 6f131be1246c5edef5314f8ba8e07ca236de602c..d47ec025725498add308bf0f9c4ea51fb7aa29e0 100755
--- a/tests/scripts/test006-acls
+++ b/tests/scripts/test006-acls
@@ -103,6 +103,136 @@ $LDAPSEARCH -h $LOCALHOST -p $PORT1 \
-D "$BJORNSDN" -w bjorn \
-b "$BABSDN" -s base "(objectclass=*)" cn >> $SEARCHOUT 2>&1
+# check selfwrite access (ITS#4587). 6 attempts are made:
+# 1) delete someone else (should fail)
+# 2) delete self (should succeed)
+# 3) add someone else (should fail)
+# 4) add someone else and self (should fail)
+# 5) add self and someone else (should fail)
+# 6) add self (should succeed)
+#
+$LDAPMODIFY -D "$JAJDN" -h $LOCALHOST -p $PORT1 -w jaj >> \
+ $TESTOUT 2>&1 << EOMODS
+dn: cn=All Staff,ou=Groups,dc=example,dc=com
+changetype: modify
+delete: member
+member: $BABSDN
+EOMODS
+RC=$?
+case $RC in
+50)
+ ;;
+0)
+ echo "ldapmodify should have failed ($RC)!"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit -1
+ ;;
+*)
+ echo "ldapmodify failed ($RC)!"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit $RC
+ ;;
+esac
+
+$LDAPMODIFY -D "$JAJDN" -h $LOCALHOST -p $PORT1 -w jaj >> \
+ $TESTOUT 2>&1 << EOMODS
+dn: cn=All Staff,ou=Groups,dc=example,dc=com
+changetype: modify
+delete: member
+member: $JAJDN
+EOMODS
+RC=$?
+if test $RC != 0 ; then
+ echo "ldapmodify failed ($RC)!"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit $RC
+fi
+
+$LDAPMODIFY -D "$JAJDN" -h $LOCALHOST -p $PORT1 -w jaj >> \
+ $TESTOUT 2>&1 << EOMODS
+dn: cn=All Staff,ou=Groups,dc=example,dc=com
+changetype: modify
+add: member
+member: cn=Foo,ou=Bar
+EOMODS
+RC=$?
+case $RC in
+50)
+ ;;
+0)
+ echo "ldapmodify should have failed ($RC)!"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit -1
+ ;;
+*)
+ echo "ldapmodify failed ($RC)!"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit $RC
+ ;;
+esac
+
+$LDAPMODIFY -D "$JAJDN" -h $LOCALHOST -p $PORT1 -w jaj >> \
+ $TESTOUT 2>&1 << EOMODS
+dn: cn=All Staff,ou=Groups,dc=example,dc=com
+changetype: modify
+add: member
+member: cn=Foo,ou=Bar
+member: $JAJDN
+EOMODS
+RC=$?
+case $RC in
+50)
+ ;;
+0)
+ echo "ldapmodify should have failed ($RC)!"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit -1
+ ;;
+*)
+ echo "ldapmodify failed ($RC)!"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit $RC
+ ;;
+esac
+
+$LDAPMODIFY -D "$JAJDN" -h $LOCALHOST -p $PORT1 -w jaj >> \
+ $TESTOUT 2>&1 << EOMODS
+dn: cn=All Staff,ou=Groups,dc=example,dc=com
+changetype: modify
+add: member
+member: $JAJDN
+member: cn=Foo,ou=Bar
+EOMODS
+RC=$?
+case $RC in
+50)
+ ;;
+0)
+ echo "ldapmodify should have failed ($RC)!"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit -1
+ ;;
+*)
+ echo "ldapmodify failed ($RC)!"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit $RC
+ ;;
+esac
+
+$LDAPMODIFY -D "$JAJDN" -h $LOCALHOST -p $PORT1 -w jaj >> \
+ $TESTOUT 2>&1 << EOMODS
+dn: cn=All Staff,ou=Groups,dc=example,dc=com
+changetype: modify
+add: member
+member: $JAJDN
+EOMODS
+RC=$?
+if test $RC != 0 ; then
+ echo "ldapmodify failed ($RC)!"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit $RC
+fi
+
#
# Check group access. Try to modify Babs' entry. Two attempts:
# 1) bound as "James A Jones 1" - should fail
diff --git a/tests/scripts/test023-refint b/tests/scripts/test023-refint
index dddf79fad06cbd024fa6f2fb7adbf7d3bf69a730..d1c9103484fdf6c21aba24a90865882a50ed611a 100755
--- a/tests/scripts/test023-refint
+++ b/tests/scripts/test023-refint
@@ -92,6 +92,8 @@ if test $RC != 0 ; then
exit $RC
fi
+sleep 1;
+
echo "Using ldapsearch to check dependents new rdn..."
$LDAPSEARCH -S "" -b "o=refint" -h $LOCALHOST -p $PORT1 > $SEARCHOUT 2>&1
@@ -129,6 +131,8 @@ if test $RC != 0 ; then
exit $RC
fi
+sleep 1;
+
echo "Using ldapsearch to verify dependents have been deleted..."
$LDAPSEARCH -S "" -b "o=refint" -h $LOCALHOST -p $PORT1 > $SEARCHOUT 2>&1
diff --git a/tests/scripts/test034-translucent b/tests/scripts/test034-translucent
index 75ba8298687815faad611dfabbf335c736f79082..343528066a61d5a7e1a0b8fa871920676915ded5 100755
--- a/tests/scripts/test034-translucent
+++ b/tests/scripts/test034-translucent
@@ -196,41 +196,19 @@ if test $RC != 32 ; then
exit 1
fi
-echo "Shutting down local slapd..."
-kill -HUP $LOCALPID
-wait $LOCALPID
-
-echo "Configuring local slapd without translucent_no_glue..."
-. $CONFFILTER $BACKEND $MONITORDB < $TRANSLUCENTLOCALCONF | \
- grep -v translucent_no_glue > $CONF2
-
-echo "Restarting local slapd on TCP/IP port $PORT2..."
-$SLAPD -f $CONF2 -h $URI2 -d $LVL $TIMING >> $LOG2 2>&1 &
-PID=$!
-if test $WAIT != 0 ; then
- echo PID $PID
- read foo
-fi
-LOCALPID="$PID"
-KILLPIDS="$REMOTEPID $PID"
-
-sleep 1
-
-for i in 0 1 2 3 4 5; do
- $LDAPSEARCH -s base -b "$MONITOR" -H $URI2 \
- 'objectclass=*' > /dev/null 2>&1
- RC=$?
- if test $RC = 0 ; then
- break
- fi
- echo "Waiting 5 seconds for local slapd to start..."
- sleep 5
-done
+echo "Dynamically configuring local slapd without translucent_no_glue..."
+$LDAPMODIFY -D cn=config -H $URI2 -y $CONFIGPWF <<EOF
+dn: olcOverlay={0}translucent,olcDatabase={2}$BACKEND,cn=config
+changetype: modify
+replace: olcTranslucentNoGlue
+olcTranslucentNoGlue: FALSE
+EOF
+RC=$?
if test $RC != 0 ; then
- echo "ldapsearch failed ($RC)!"
- test $KILLSERVERS != no && kill -HUP $KILLPIDS
- exit $RC
+ echo "ldapmodify of dynamic config failed ($RC)"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit 1
fi
echo "Testing add: valid local record..."
@@ -619,40 +597,22 @@ if test "$ATTR" != "preferredLanguage: ISO8859-1" ; then
exit 1
fi
-echo "Shutting down local slapd..."
-kill -HUP $LOCALPID
-wait $LOCALPID
-
-echo "Configuring local slapd with translucent_strict..."
-echo translucent_strict >> $CONF2
-
-echo "Restarting slapd on TCP/IP port $PORT2..."
-$SLAPD -f $CONF2 -h $URI2 -d $LVL $TIMING >> $LOG2 2>&1 &
-PID=$!
-if test $WAIT != 0 ; then
- echo PID $PID
- read foo
-fi
-LOCALPID="$PID"
-KILLPIDS="$REMOTEPID $PID"
-
-sleep 1
-
-for i in 0 1 2 3 4 5; do
- $LDAPSEARCH -s base -b "$MONITOR" -H $URI2 \
- 'objectclass=*' > /dev/null 2>&1
- RC=$?
- if test $RC = 0 ; then
- break
- fi
- echo "Waiting 5 seconds for local slapd to start..."
- sleep 5
-done
+echo "Dynamically configuring local slapd with translucent_no_glue and translucent_strict..."
+$LDAPMODIFY -D cn=config -H $URI2 -y $CONFIGPWF <<EOF
+dn: olcOverlay={0}translucent,olcDatabase={2}$BACKEND,cn=config
+changetype: modify
+replace: olcTranslucentNoGlue
+olcTranslucentNoGlue: TRUE
+-
+replace: olcTranslucentStrict
+olcTranslucentStrict: TRUE
+EOF
+RC=$?
if test $RC != 0 ; then
- echo "ldapsearch failed ($RC)!"
- test $KILLSERVERS != no && kill -HUP $KILLPIDS
- exit $RC
+ echo "ldapmodify of dynamic config failed ($RC)"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit 1
fi
echo "Testing strict mode delete: nonexistent local attribute..."
diff --git a/tests/scripts/test042-valsort b/tests/scripts/test042-valsort
index 1e633e0c0859ad2042f35312ffacb15f6b75fd26..a8f5a64fdf6f726563e8792a66beddc582ce2480 100755
--- a/tests/scripts/test042-valsort
+++ b/tests/scripts/test042-valsort
@@ -23,14 +23,6 @@ fi
mkdir -p $TESTDIR $DBDIR1
-$SLAPPASSWD -g -n > $CONFIGPWF
-RC=$?
-if test $RC != 0 ; then
- echo "slappasswd failed ($RC)!"
- exit $RC
-fi
-read CONFIGPW < $CONFIGPWF
-
echo "Running slapadd to build slapd database..."
. $CONFFILTER $BACKEND $MONITORDB < $VALSORTCONF > $CONF1
$SLAPADD -f $CONF1 -l $LDIFVALSORT
diff --git a/tests/scripts/test048-syncrepl-multiproxy b/tests/scripts/test048-syncrepl-multiproxy
new file mode 100755
index 0000000000000000000000000000000000000000..00ee233cf4181fca49a1ea8559ad22ab245beb17
--- /dev/null
+++ b/tests/scripts/test048-syncrepl-multiproxy
@@ -0,0 +1,606 @@
+#! /bin/sh
+# $OpenLDAP$
+## This work is part of OpenLDAP Software <http://www.openldap.org/>.
+##
+## Copyright 1998-2006 The OpenLDAP Foundation.
+## All rights reserved.
+##
+## Redistribution and use in source and binary forms, with or without
+## modification, are permitted only as authorized by the OpenLDAP
+## Public License.
+##
+## A copy of this license is available in the file LICENSE in the
+## top-level directory of the distribution or, alternatively, at
+## <http://www.OpenLDAP.org/license.html>.
+
+echo "running defines.sh"
+. $SRCDIR/scripts/defines.sh
+
+if test $BACKLDAP = ldapno; then
+ echo "LDAP backend not available, test skipped"
+ exit 0
+fi
+
+if test $SYNCPROV = syncprovno; then
+ echo "Syncrepl provider overlay not available, test skipped"
+ exit 0
+fi
+
+if test $MONITORDB = no; then
+ echo "Monitor backend not available, test skipped"
+ exit 0
+fi
+
+mkdir -p $TESTDIR $DBDIR1 $DBDIR2 $DBDIR3
+
+#
+# Test replication:
+# - start master
+# - start slave
+# - populate over ldap
+# - perform some modifies and deleted
+# - attempt to modify the slave (referral or chain)
+# - retrieve database over ldap and compare against expected results
+#
+
+echo "Starting master slapd on TCP/IP port $PORT1..."
+. $CONFFILTER $BACKEND $MONITORDB < $PLSRMASTERCONF > $CONF1
+$SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING > $LOG1 2>&1 &
+MASTERPID=$!
+if test $WAIT != 0 ; then
+ echo MASTERPID $MASTERPID
+ read foo
+fi
+KILLPIDS="$MASTERPID"
+
+sleep 1
+
+echo "Using ldapsearch to check that master slapd is running..."
+for i in 0 1 2 3 4 5; do
+ $LDAPSEARCH -s base -b "$MONITOR" -h $LOCALHOST -p $PORT1 \
+ '(objectClass=*)' > /dev/null 2>&1
+ RC=$?
+ if test $RC = 0 ; then
+ break
+ fi
+ echo "Waiting 5 seconds for slapd to start..."
+ sleep 5
+done
+
+if test $RC != 0 ; then
+ echo "ldapsearch failed ($RC)!"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit $RC
+fi
+
+echo "Using ldapadd to create the context prefix entry in the master..."
+$LDAPADD -D "$MANAGERDN" -h $LOCALHOST -p $PORT1 -w $PASSWD < \
+ $LDIFORDEREDCP > /dev/null 2>&1
+RC=$?
+if test $RC != 0 ; then
+ echo "ldapadd failed ($RC)!"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit $RC
+fi
+
+echo "Starting P1 slave slapd on TCP/IP port $PORT2..."
+. $CONFFILTER $BACKEND $MONITORDB < $RSLAVECONF > $CONF2
+$SLAPD -f $CONF2 -h $URI2 -d $LVL $TIMING > $LOG2 2>&1 &
+P1SLAVEPID=$!
+if test $WAIT != 0 ; then
+ echo P1SLAVEPID $P1SLAVEPID
+ read foo
+fi
+KILLPIDS="$MASTERPID $P1SLAVEPID"
+
+sleep 1
+
+echo "Using ldapsearch to check that P1 slave slapd is running..."
+for i in 0 1 2 3 4 5; do
+ $LDAPSEARCH -s base -b "$MONITOR" -h $LOCALHOST -p $PORT2 \
+ '(objectClass=*)' > /dev/null 2>&1
+ RC=$?
+ if test $RC = 0 ; then
+ break
+ fi
+ echo "Waiting 5 seconds for slapd to start..."
+ sleep 5
+done
+
+if test $RC != 0 ; then
+ echo "ldapsearch failed ($RC)!"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit $RC
+fi
+
+echo "Starting R1 slave slapd on TCP/IP port $PORT3..."
+. $CONFFILTER $BACKEND $MONITORDB < $RSLAVECONF | sed -e 's;\.2\.;.3.;' > $CONF3
+$SLAPD -f $CONF3 -h $URI3 -d $LVL $TIMING > $LOG3 2>&1 &
+R1SLAVEPID=$!
+if test $WAIT != 0 ; then
+ echo R1SLAVEPID $R1SLAVEPID
+ read foo
+fi
+KILLPIDS="$MASTERPID $P1SLAVEPID $R1SLAVEPID"
+
+sleep 1
+
+echo "Using ldapsearch to check that R1 slave slapd is running..."
+for i in 0 1 2 3 4 5; do
+ $LDAPSEARCH -s base -b "$MONITOR" -h $LOCALHOST -p $PORT3 \
+ '(objectClass=*)' > /dev/null 2>&1
+ RC=$?
+ if test $RC = 0; then
+ break
+ fi
+ echo "Waiting 5 seconds for slapd to start..."
+ sleep 5
+done
+
+if test $RC != 0 ; then
+ echo "ldapsearch failed ($RC)!"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit $RC
+fi
+
+CHECK=1
+echo "$CHECK > Using ldapadd to populate the master directory..."
+$LDAPADD -D "$MANAGERDN" -h $LOCALHOST -p $PORT1 -w $PASSWD < \
+ $LDIFORDEREDNOCP > /dev/null 2>&1
+RC=$?
+if test $RC != 0 ; then
+ echo "ldapadd failed ($RC)!"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit $RC
+fi
+
+SLEEP=15
+echo "Waiting $SLEEP seconds for syncrepl to receive changes..."
+sleep $SLEEP
+
+#echo "Using ldapsearch to read all the entries from the master..."
+$LDAPSEARCH -S "" -b "$BASEDN" -h $LOCALHOST -p $PORT1 \
+ '(objectClass=*)' > "${MASTEROUT}.1" 2>&1
+RC=$?
+
+if test $RC != 0 ; then
+ echo "ldapsearch failed at master ($RC)!"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit $RC
+fi
+
+#echo "Using ldapsearch to read all the entries from the P1 slave..."
+$LDAPSEARCH -S "" -b "$BASEDN" -h $LOCALHOST -p $PORT2 \
+ '(objectClass=*)' > "${SLAVEOUT}.1" 2>&1
+RC=$?
+
+if test $RC != 0 ; then
+ echo "ldapsearch failed at P1 slave ($RC)!"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit $RC
+fi
+
+#echo "Filtering master results..."
+. $LDIFFILTER < "${MASTEROUT}.1" > $MASTERFLT
+#echo "Filtering slave results..."
+. $LDIFFILTER < "${SLAVEOUT}.1" > $SLAVEFLT
+
+echo "$CHECK < Comparing retrieved entries from master and P1 slave..."
+$CMP $MASTERFLT $SLAVEFLT > $CMPOUT
+
+if test $? != 0 ; then
+ echo "test failed - master and P1 slave databases differ"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit 1
+fi
+
+#echo "Using ldapsearch to read all the entries from the R1 slave..."
+$LDAPSEARCH -S "" -b "$BASEDN" -h $LOCALHOST -p $PORT3 \
+ '(objectClass=*)' > "${SLAVEOUT}.1" 2>&1
+RC=$?
+
+if test $RC != 0 ; then
+ echo "ldapsearch failed at R1 slave ($RC)!"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit $RC
+fi
+
+#echo "Filtering slave results..."
+. $LDIFFILTER < "${SLAVEOUT}.1" > $SLAVEFLT
+
+echo "$CHECK < Comparing retrieved entries from master and R1 slave..."
+$CMP $MASTERFLT $SLAVEFLT > $CMPOUT
+
+if test $? != 0 ; then
+ echo "test failed - master and R1 slave databases differ"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit 1
+fi
+
+CHECK=`expr $CHECK + 1`
+SLEEP=10
+echo "$CHECK > Stopping the provider, sleeping $SLEEP seconds and restarting it..."
+kill -HUP "$MASTERPID"
+wait $MASTERPID
+sleep $SLEEP
+
+echo "======================= RESTART =======================" >> $LOG1
+$SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING >> $LOG1 2>&1 &
+MASTERPID=$!
+if test $WAIT != 0 ; then
+ echo MASTERPID $MASTERPID
+ read foo
+fi
+KILLPIDS="$MASTERPID $P1SLAVEPID $R1SLAVEPID"
+
+sleep 1
+
+echo "Using ldapsearch to check that master slapd is running..."
+for i in 0 1 2 3 4 5; do
+ $LDAPSEARCH -s base -b "$MONITOR" -h $LOCALHOST -p $PORT1 \
+ '(objectClass=*)' > /dev/null 2>&1
+ RC=$?
+ if test $RC = 0 ; then
+ break
+ fi
+ echo "Waiting 5 seconds for slapd to start..."
+ sleep 5
+done
+
+if test $RC != 0 ; then
+ echo "ldapsearch failed ($RC)!"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit $RC
+fi
+
+echo "Using ldapmodify to modify master directory..."
+
+#
+# Do some modifications
+#
+
+$LDAPMODIFY -v -D "$MANAGERDN" -h $LOCALHOST -p $PORT1 -w $PASSWD > \
+ $TESTOUT 2>&1 << EOMODS
+dn: cn=James A Jones 1, ou=Alumni Association, ou=People, dc=example,dc=com
+changetype: modify
+add: drink
+drink: Orange Juice
+-
+delete: sn
+sn: Jones
+-
+add: sn
+sn: Jones
+
+dn: cn=Bjorn Jensen, ou=Information Technology Division, ou=People, dc=example,dc=com
+changetype: modify
+replace: drink
+drink: Iced Tea
+
+dn: cn=ITD Staff,ou=Groups,dc=example,dc=com
+changetype: modify
+delete: uniquemember
+uniquemember: cn=James A Jones 2, ou=Information Technology Division, ou=People, dc=example,dc=com
+uniquemember: cn=Bjorn Jensen, ou=Information Technology Division, ou=People, dc=example,dc=com
+-
+add: uniquemember
+uniquemember: cn=Dorothy Stevens, ou=Alumni Association, ou=People, dc=example,dc=com
+uniquemember: cn=James A Jones 1, ou=Alumni Association, ou=People, dc=example,dc=com
+
+dn: cn=Bjorn Jensen,ou=Information Technology Division,ou=People,dc=example,dc
+ =com
+changetype: modify
+delete: cn
+cn: Biiff Jensen
+
+dn: cn=Gern Jensen, ou=Information Technology Division, ou=People, dc=example,dc=com
+changetype: add
+objectclass: OpenLDAPperson
+cn: Gern Jensen
+sn: Jensen
+uid: gjensen
+title: Chief Investigator, ITD
+postaladdress: ITD $ 535 W. William St $ Ann Arbor, MI 48103
+seealso: cn=All Staff, ou=Groups, dc=example,dc=com
+drink: Coffee
+homepostaladdress: 844 Brown St. Apt. 4 $ Ann Arbor, MI 48104
+description: Very odd
+facsimiletelephonenumber: +1 313 555 7557
+telephonenumber: +1 313 555 8343
+mail: gjensen@mailgw.example.com
+homephone: +1 313 555 8844
+
+dn: ou=Retired, ou=People, dc=example,dc=com
+changetype: add
+objectclass: organizationalUnit
+ou: Retired
+
+dn: cn=Rosco P. Coltrane, ou=Information Technology Division, ou=People, dc=example,dc=com
+changetype: add
+objectclass: OpenLDAPperson
+cn: Rosco P. Coltrane
+sn: Coltrane
+uid: rosco
+description: Fat tycoon
+
+dn: cn=Rosco P. Coltrane, ou=Information Technology Division, ou=People, dc=example,dc=com
+changetype: modrdn
+newrdn: cn=Rosco P. Coltrane
+deleteoldrdn: 1
+newsuperior: ou=Retired, ou=People, dc=example,dc=com
+
+dn: cn=James A Jones 2, ou=Information Technology Division, ou=People, dc=example,dc=com
+changetype: delete
+EOMODS
+
+RC=$?
+if test $RC != 0 ; then
+ echo "ldapmodify failed ($RC)!"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit $RC
+fi
+
+SLEEP=15
+echo "Waiting $SLEEP seconds for syncrepl to receive changes..."
+sleep $SLEEP
+
+#echo "Using ldapsearch to read all the entries from the master..."
+$LDAPSEARCH -S "" -b "$BASEDN" -h $LOCALHOST -p $PORT1 \
+ '(objectClass=*)' > "${MASTEROUT}.2" 2>&1
+RC=$?
+
+if test $RC != 0 ; then
+ echo "ldapsearch failed at master ($RC)!"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit $RC
+fi
+
+#echo "Using ldapsearch to read all the entries from the P1 slave..."
+$LDAPSEARCH -S "" -b "$BASEDN" -h $LOCALHOST -p $PORT2 \
+ '(objectClass=*)' > "${SLAVEOUT}.2" 2>&1
+RC=$?
+
+if test $RC != 0 ; then
+ echo "ldapsearch failed at P1 slave ($RC)!"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit $RC
+fi
+
+#echo "Filtering master results..."
+. $LDIFFILTER < "${MASTEROUT}.2" > $MASTERFLT
+#echo "Filtering P1 slave results..."
+. $LDIFFILTER < "${SLAVEOUT}.2" > $SLAVEFLT
+
+echo "$CHECK < Comparing retrieved entries from master and P1 slave..."
+$CMP $MASTERFLT $SLAVEFLT > $CMPOUT
+
+if test $? != 0 ; then
+ echo "test failed - master and P1 slave databases differ"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit 1
+fi
+
+#echo "Using ldapsearch to read all the entries from the R1 slave..."
+$LDAPSEARCH -S "" -b "$BASEDN" -h $LOCALHOST -p $PORT3 \
+ '(objectClass=*)' > "${SLAVEOUT}.2" 2>&1
+RC=$?
+
+if test $RC != 0 ; then
+ echo "ldapsearch failed at R1 slave ($RC)!"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit $RC
+fi
+
+#echo "Filtering slave results..."
+. $LDIFFILTER < "${SLAVEOUT}.2" > $SLAVEFLT
+
+echo "$CHECK < Comparing retrieved entries from master and R1 slave..."
+$CMP $MASTERFLT $SLAVEFLT > $CMPOUT
+
+if test $? != 0 ; then
+ echo "test failed - master and R1 slave databases differ"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit 1
+fi
+
+CHECK=`expr $CHECK + 1`
+echo "$CHECK > Stopping slaves to test recovery..."
+kill -HUP $P1SLAVEPID $R1SLAVEPID
+wait $P1SLAVEPID
+wait $R1SLAVEPID
+
+echo "Modifying more entries on the master..."
+$LDAPMODIFY -v -D "$MANAGERDN" -h $LOCALHOST -p $PORT1 -w $PASSWD >> \
+ $TESTOUT 2>&1 << EOMODS
+dn: cn=Bjorn Jensen, ou=Information Technology Division, ou=People, dc=example,dc=com
+changetype: modify
+add: description
+description: r1 slave is down...
+
+dn: cn=James T. Kirk, ou=Retired, ou=People, dc=example,dc=com
+changetype: add
+objectclass: OpenLDAPperson
+sn: Kirk
+uid: jtk
+cn: James T. Kirk
+
+dn: cn=Tiberius J. Hooker, ou=Retired, ou=People, dc=example,dc=com
+changetype: add
+objectclass: OpenLDAPperson
+sn: Hooker
+uid: tjh
+cn: Tiberius J. Hooker
+
+EOMODS
+
+echo "Restarting P1 slave..."
+echo "======================= RESTART =======================" >> $LOG3
+$SLAPD -f $CONF2 -h $URI2 -d $LVL $TIMING >> $LOG2 2>&1 &
+P1SLAVEPID=$!
+if test $WAIT != 0 ; then
+ echo P1SLAVEPID $P1SLAVEPID
+ read foo
+fi
+
+echo "Restarting R1 slave..."
+echo "======================= RESTART =======================" >> $LOG3
+$SLAPD -f $CONF3 -h $URI3 -d $LVL $TIMING >> $LOG3 2>&1 &
+R1SLAVEPID=$!
+if test $WAIT != 0 ; then
+ echo R1SLAVEPID $R1SLAVEPID
+ read foo
+fi
+KILLPIDS="$MASTERPID $P1SLAVEPID $R1SLAVEPID"
+
+SLEEP=25
+echo "Waiting $SLEEP seconds for syncrepl to receive changes..."
+sleep $SLEEP
+
+#echo "Using ldapsearch to read all the entries from the master..."
+$LDAPSEARCH -S "" -b "$BASEDN" -h $LOCALHOST -p $PORT1 \
+ '(objectClass=*)' > "${MASTEROUT}.3" 2>&1
+RC=$?
+
+if test $RC != 0 ; then
+ echo "ldapsearch failed at master ($RC)!"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit $RC
+fi
+
+#echo "Using ldapsearch to read all the entries from the P1 slave..."
+$LDAPSEARCH -S "" -b "$BASEDN" -h $LOCALHOST -p $PORT2 \
+ '(objectClass=*)' > "${SLAVEOUT}.3" 2>&1
+RC=$?
+
+if test $RC != 0 ; then
+ echo "ldapsearch failed at slave ($RC)!"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit $RC
+fi
+
+#echo "Filtering master results..."
+. $LDIFFILTER < "${MASTEROUT}.3" > $MASTERFLT
+#echo "Filtering slave results..."
+. $LDIFFILTER < "${SLAVEOUT}.3" > $SLAVEFLT
+
+echo "$CHECK < Comparing retrieved entries from master and P1 slave..."
+$CMP $MASTERFLT $SLAVEFLT > $CMPOUT
+
+if test $? != 0 ; then
+ echo "test failed - master and slave databases differ"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit 1
+fi
+
+#echo "Using ldapsearch to read all the entries from the R1 slave..."
+$LDAPSEARCH -S "" -b "$BASEDN" -h $LOCALHOST -p $PORT3 \
+ '(objectClass=*)' > "${SLAVEOUT}.3" 2>&1
+RC=$?
+
+if test $RC != 0 ; then
+ echo "ldapsearch failed at slave ($RC)!"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit $RC
+fi
+
+#echo "Filtering slave results..."
+. $LDIFFILTER < "${SLAVEOUT}.3" > $SLAVEFLT
+
+echo "$CHECK < Comparing retrieved entries from master and R1 slave..."
+$CMP $MASTERFLT $SLAVEFLT > $CMPOUT
+
+if test $? != 0 ; then
+ echo "test failed - master and slave databases differ"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit 1
+fi
+
+CHECK=`expr $CHECK + 1`
+echo "$CHECK > Try updating the P1 slave slapd..."
+$LDAPMODIFY -v -D "$MANAGERDN" -h $LOCALHOST -p $PORT2 -w $PASSWD > \
+ $TESTOUT 2>&1 << EOMODS
+dn: cn=James A Jones 1, ou=Alumni Association, ou=People, dc=example, dc=com
+changetype: modify
+add: description
+description: This write must fail because directed to a shadow context,
+description: unless the chain overlay is configured appropriately ;)
+
+EOMODS
+
+RC=$?
+if test $RC != 0 ; then
+ echo "ldapmodify failed ($RC)!"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit $RC
+fi
+
+SLEEP=15
+echo "Waiting $SLEEP seconds for syncrepl to receive changes..."
+sleep $SLEEP
+
+#echo "Using ldapsearch to read all the entries from the master..."
+$LDAPSEARCH -S "" -b "$BASEDN" -h $LOCALHOST -p $PORT1 \
+ '(objectClass=*)' > "${MASTEROUT}.4" 2>&1
+RC=$?
+
+if test $RC != 0 ; then
+ echo "ldapsearch failed at master ($RC)!"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit $RC
+fi
+
+#echo "Using ldapsearch to read all the entries from the P1 slave..."
+$LDAPSEARCH -S "" -b "$BASEDN" -h $LOCALHOST -p $PORT2 \
+'(objectClass=*)' > "${SLAVEOUT}.4" 2>&1
+RC=$?
+
+if test $RC != 0 ; then
+ echo "ldapsearch failed at slave ($RC)!"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit $RC
+fi
+
+#echo "Filtering master results..."
+. $LDIFFILTER < "${MASTEROUT}.4" > $MASTERFLT
+#echo "Filtering slave results..."
+. $LDIFFILTER < "${SLAVEOUT}.4" > $SLAVEFLT
+
+echo "$CHECK < Comparing retrieved entries from master and P1 slave..."
+$CMP $MASTERFLT $SLAVEFLT > $CMPOUT
+
+if test $? != 0 ; then
+ echo "test failed - master and P1 slave databases differ"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit 1
+fi
+
+#echo "Using ldapsearch to read all the entries from the R1 slave..."
+$LDAPSEARCH -S "" -b "$BASEDN" -h $LOCALHOST -p $PORT3 \
+'(objectClass=*)' > "${SLAVEOUT}.4" 2>&1
+RC=$?
+
+if test $RC != 0 ; then
+ echo "ldapsearch failed at slave ($RC)!"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit $RC
+fi
+
+#echo "Filtering slave results..."
+. $LDIFFILTER < "${SLAVEOUT}.4" > $SLAVEFLT
+
+echo "$CHECK < Comparing retrieved entries from master and R1 slave..."
+$CMP $MASTERFLT $SLAVEFLT > $CMPOUT
+
+if test $? != 0 ; then
+ echo "test failed - master and R1 slave databases differ"
+ test $KILLSERVERS != no && kill -HUP $KILLPIDS
+ exit 1
+fi
+
+test $KILLSERVERS != no && kill -HUP $KILLPIDS
+
+echo ">>>>> Test succeeded"
+
+test $KILLSERVERS != no && wait
+
+exit 0