upstream/openldap
1
0
Fork 0
mirror of https://git.openldap.org/openldap/openldap.git synced 2026-02-18 18:18:06 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions

Sync with HEAD

Browse source
This commit is contained in:
Kurt Zeilenga 2003-12-15 23:05:08 +00:00
parent 7a49afff08
commit 7570f0cc0a
276 changed files with 13314 additions and 19461 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
INSTALL
View file

@ -67,7 +67,7 @@ Making and Installing the OpenLDAP Distribution
6. Test the standalone system
This step requires the standalone LDAP server, slapd(8), with
BDB and/or LDBM support.
BDB, HDB, and/or LDBM support.
% make test

13
acconfig.h
View file

@ -113,6 +113,19 @@
#define vsprintf ber_pvt_vsprintf
#endif
#ifdef OPENLDAP_FD_SETSIZE
/* assume installer desires to enlarge fd_set */
#ifdef HAVE_BITS_TYPES_H
#include <bits/types.h>
#endif
#ifdef __FD_SETSIZE
#undef __FD_SETSIZE
#define __FD_SETSIZE OPENLDAP_FD_SETSIZE
#else
#define FD_SETSIZE OPENLDAP_FD_SETSIZE
#endif
#endif
#include "ldap_cdefs.h"
#include "ldap_features.h"

3
build/openldap.m4
View file

@ -320,12 +320,11 @@ OL_BERKELEY_DB_TRY(ol_cv_db_db_4_dot_2,[-ldb-4.2])
OL_BERKELEY_DB_TRY(ol_cv_db_db_4_2,[-ldb-4-2])
OL_BERKELEY_DB_TRY(ol_cv_db_db_4,[-ldb-4])
OL_BERKELEY_DB_TRY(ol_cv_db_db4,[-ldb4])
OL_BERKELEY_DB_TRY(ol_cv_db_db,[-ldb])
OL_BERKELEY_DB_TRY(ol_cv_db_db41,[-ldb41])
OL_BERKELEY_DB_TRY(ol_cv_db_db_41,[-ldb-41])
OL_BERKELEY_DB_TRY(ol_cv_db_db_4_dot_1,[-ldb-4.1])
OL_BERKELEY_DB_TRY(ol_cv_db_db_4_1,[-ldb-4-1])
OL_BERKELEY_DB_TRY(ol_cv_db_db_4,[-ldb-4])
OL_BERKELEY_DB_TRY(ol_cv_db_db,[-ldb])
OL_BERKELEY_DB_TRY(ol_cv_db_db3,[-ldb3])
OL_BERKELEY_DB_TRY(ol_cv_db_db_3,[-ldb-3])
OL_BERKELEY_DB_TRY(ol_cv_db_db2,[-ldb2])

8
build/top.mk
View file

@ -152,10 +152,6 @@ LDAP_LIBLBER_LA = $(LDAP_LIBDIR)/liblber/liblber.la
LDAP_LIBLDAP_LA = $(LDAP_LIBDIR)/libldap/libldap.la
LDAP_LIBLDAP_R_LA = $(LDAP_LIBDIR)/libldap_r/libldap_r.la
LDAP_LIBLDBM_A_no =
LDAP_LIBLDBM_A_yes = $(LDAP_LIBDIR)/libldbm/libldbm.a
LDAP_LIBLDBM_A = $(LDAP_LIBLDBM_A_@BUILD_LDBM@)
LDAP_LIBREWRITE_A = $(LDAP_LIBDIR)/librewrite/librewrite.a
LDAP_LIBLUNICODE_A = $(LDAP_LIBDIR)/liblunicode/liblunicode.a
LDAP_LIBLUTIL_A = $(LDAP_LIBDIR)/liblutil/liblutil.a
@ -164,8 +160,7 @@ LDAP_L = $(LDAP_LIBLUTIL_A) \
$(LDAP_LIBLDAP_LA) $(LDAP_LIBLBER_LA)
SLURPD_L = $(LDAP_LIBLUTIL_A) \
$(LDAP_LIBLDAP_R_LA) $(LDAP_LIBLBER_LA)
SLAPD_L = $(LDAP_LIBLDBM_A) \
$(LDAP_LIBLUNICODE_A) $(LDAP_LIBREWRITE_A) \
SLAPD_L = $(LDAP_LIBLUNICODE_A) $(LDAP_LIBREWRITE_A) \
$(SLURPD_L)
WRAP_LIBS = @WRAP_LIBS@
@ -187,7 +182,6 @@ SECURITY_LIBS = $(SASL_LIBS) $(KRB_LIBS) $(TLS_LIBS) $(AUTH_LIBS)
MODULES_CPPFLAGS = @SLAPD_MODULES_CPPFLAGS@
MODULES_LDFLAGS = @SLAPD_MODULES_LDFLAGS@
MODULES_LIBS = @MODULES_LIBS@
TERMCAP_LIBS = @TERMCAP_LIBS@
SLAPD_PERL_LDFLAGS = @SLAPD_PERL_LDFLAGS@
SLAPD_SQL_LDFLAGS = @SLAPD_SQL_LDFLAGS@

50
clients/tools/common.c
View file

@ -95,7 +95,7 @@ tool_common_usage( void )
{
static const char *const descriptions[] = {
N_(" -c continuous operation mode (do not stop on errors)\n"),
N_(" -C chase referrals\n"),
N_(" -C chase referrals (anonymously)\n"),
N_(" -d level set LDAP debugging level to `level'\n"),
N_(" -D binddn bind DN\n"),
N_(" -e [!]<ctrl>[=<ctrlparam>] general controls (! indicates criticality)\n")
@ -650,35 +650,31 @@ tool_conn_setup( int not, void (*private_setup)( LDAP * ) )
#endif
if ( !not ) {
/* connect to server */
int rc;
if( ( ldaphost != NULL || ldapport ) && ( ldapuri == NULL ) ) {
if ( verbose ) {
fprintf( stderr, "ldap_init( %s, %d )\n",
ldaphost != NULL ? ldaphost : "<DEFAULT>",
ldapport );
}
/* construct URL */
LDAPURLDesc url;
memset( &url, 0, sizeof(url));
ld = ldap_init( ldaphost, ldapport );
if( ld == NULL ) {
char buf[20 + sizeof(": ldap_init")];
sprintf( buf, "%.20s: ldap_init", prog );
perror( buf );
exit( EXIT_FAILURE );
}
url.lud_scheme = "ldap";
url.lud_host = ldaphost;
url.lud_port = ldapport;
url.lud_scope = LDAP_SCOPE_DEFAULT;
} else {
int rc;
if ( verbose ) {
fprintf( stderr, "ldap_initialize( %s )\n",
ldapuri != NULL ? ldapuri : "<DEFAULT>" );
}
rc = ldap_initialize( &ld, ldapuri );
if( rc != LDAP_SUCCESS ) {
fprintf( stderr,
"Could not create LDAP session handle (%d): %s\n",
rc, ldap_err2string(rc) );
exit( EXIT_FAILURE );
}
ldapuri = ldap_url_desc2str( &url );
}
if ( verbose ) {
fprintf( stderr, "ldap_initialize( %s )\n",
ldapuri != NULL ? ldapuri : "<DEFAULT>" );
}
rc = ldap_initialize( &ld, ldapuri );
if( rc != LDAP_SUCCESS ) {
fprintf( stderr,
"Could not create LDAP session handle (%d): %s\n",
rc, ldap_err2string(rc) );
exit( EXIT_FAILURE );
}
if( private_setup ) private_setup( ld );

2545
configure vendored
View file

File diff suppressed because it is too large Load diff

103
configure.in
View file

@ -239,6 +239,15 @@ OL_ARG_ENABLE(sql,[ --enable-sql enable sql backend], no)dnl
OL_ARG_WITH(sql_module,[ --with-sql-module module type static|dynamic], static,
[static dynamic])
dnl ----------------------------------------------------------------
dnl SLAPD Overlay Options
AC_ARG_WITH(xxslapoverlays,[
SLAPD Overlay Options:])
OL_ARG_WITH(dyngroup,[ --with-dyngroup Dynamic Group overlay no|yes|mod], no,
[no yes mod])
OL_ARG_WITH(proxycache,[ --with-proxycache Proxy Cache overlay no|yes|mod], no,
[no yes mod])
dnl ----------------------------------------------------------------
dnl SLURPD OPTIONS
AC_ARG_WITH(xxslurpdoptions,[
@ -359,6 +368,12 @@ if test $ol_enable_slapd = no ; then
if test $ol_enable_rewrite = yes ; then
AC_MSG_WARN([slapd disabled, ignoring --enable-rewrite argument])
fi
if test $ol_with_dyngroup != no ; then
AC_MSG_WARN([slapd disabled, ignoring --with-dyngroup argument])
fi
if test $ol_with_proxycache != no ; then
AC_MSG_WARN([slapd disabled, ignoring --with-proxycache argument])
fi
# force settings to no
ol_enable_slapi=no
@ -380,7 +395,6 @@ if test $ol_enable_slapd = no ; then
ol_enable_rlookups=no
ol_enable_aci=no
ol_enable_wrappers=no
ol_enable_dynamic=no
ol_with_ldbm_api=no
ol_with_ldbm_type=no
@ -402,6 +416,9 @@ if test $ol_enable_slapd = no ; then
ol_enable_rewrite=no
ol_with_dyngroup=no
ol_with_proxycache=no
elif test $ol_enable_ldbm = no ; then
dnl SLAPD without LDBM
@ -540,7 +557,6 @@ BUILD_LDAP=no
BUILD_LDBM=no
BUILD_META=no
BUILD_MONITOR=no
BUILD_CACHE=no
BUILD_NULL=no
BUILD_PASSWD=no
BUILD_PERL=no
@ -560,6 +576,11 @@ BUILD_PERL_DYNAMIC=static
BUILD_SHELL_DYNAMIC=static
BUILD_SQL_DYNAMIC=static
BUILD_DYNGROUP=no
BUILD_PROXYCACHE=no
SLAPD_DYNAMIC_OVERLAYS=
SLAPD_MODULES_LDFLAGS=
SLAPD_MODULES_CPPFLAGS=
@ -577,7 +598,6 @@ SLAPD_SQL_INCLUDES=
KRB4_LIBS=
KRB5_LIBS=
SASL_LIBS=
TERMCAP_LIBS=
TLS_LIBS=
MODULES_LIBS=
SLAPI_LIBS=
@ -676,7 +696,7 @@ if test $ol_enable_perl != no ; then
else
PERL_CPPFLAGS="`$PERLBIN -MExtUtils::Embed -e ccopts`"
PERL_LDFLAGS="`$PERLBIN -MExtUtils::Embed -e ldopts|sed -e 's/ -lc / /'`"
PERL_LDFLAGS="`$PERLBIN -MExtUtils::Embed -e ldopts|sed -e 's/ -lc / /' -e 's/ -lc$//'`"
if test x"$ol_with_perl_module" = "xstatic" ; then
SLAPD_PERL_LDFLAGS="$PERL_LDFLAGS"
@ -786,6 +806,14 @@ else
ol_with_perl_module=static
ol_with_shell_module=static
ol_with_sql_module=static
if test $ol_with_dyngroup = mod ; then
AC_MSG_WARN([building static dyngroup overlay])
ol_with_dyngroup = yes
fi
if test $ol_with_proxycache = mod ; then
AC_MSG_WARN([building static proxycache overlay])
ol_with_proxycache = yes
fi
fi
dnl ----------------------------------------------------------------
@ -808,6 +836,7 @@ AC_CHECK_HEADERS( \
arpa/inet.h \
arpa/nameser.h \
assert.h \
bits/types.h \
conio.h \
crypt.h \
direct.h \
@ -2080,7 +2109,7 @@ hosts_access(req)
AC_DEFINE(HAVE_TCPD,1, [define if you have -lwrap])
WRAP_LIBS="-lwrap"
elif test $ol_enable_wrappers = yes ; then
AC_MSG_ERROR([could not find TCP wrappers, select apppropriate options ore disable])
AC_MSG_ERROR([could not find TCP wrappers, select apppropriate options or disable])
else
AC_MSG_WARN([could not find TCP wrappers, support disabled])
WRAP_LIBS=""
@ -2129,34 +2158,6 @@ if test $ol_enable_sql != no ; then
fi
fi
dnl ----------------------------------------------------------------
dnl ud needs termcap (should insert check here)
ol_link_termcap=no
AC_CHECK_HEADERS(termcap.h ncurses.h)
if test $ol_link_termcap = no ; then
AC_CHECK_LIB(termcap, tputs, [have_termcap=yes], [have_termcap=no])
if test $have_termcap = yes ; then
AC_DEFINE(HAVE_TERMCAP, 1, [define if you have -ltermcap])
ol_link_termcap=yes
TERMCAP_LIBS=-ltermcap
fi
fi
if test $ol_link_termcap = no ; then
AC_CHECK_LIB(ncurses, initscr, [have_ncurses=yes], [have_ncurses=no])
if test $have_ncurses = yes ; then
AC_DEFINE(HAVE_NCURSES, 1, [define if you have -lncurses])
ol_link_termcap=yes
TERMCAP_LIBS=-lncurses
fi
fi
if test $ol_link_termcap = no ; then
AC_DEFINE(NO_TERMCAP,1, [define if you have no termcap support])
TERMCAP_LIBS=
fi
dnl ----------------------------------------------------------------
dnl
dnl Check for Cyrus SASL
@ -2551,6 +2552,9 @@ if test "$ol_link_modules" != no ; then
SLAPD_MODULES_LDFLAGS="-dlopen self"
fi
AC_DEFINE(SLAPD_MOD_STATIC,1,[statically linked module])
AC_DEFINE(SLAPD_MOD_DYNAMIC,2,[dynamically linked module])
if test "$ol_enable_bdb" != no ; then
AC_DEFINE(SLAPD_BDB,1,[define to support BDB backend])
BUILD_SLAPD=yes
@ -2637,10 +2641,6 @@ if test "$ol_enable_meta" != no ; then
BUILD_SLAPD=yes
BUILD_META=yes
BUILD_REWRITE=yes
if test $ol_enable_ldbm = yes -o \
$ol_enable_bdb = yes ; then
BUILD_CACHE=yes
fi
if test "$ol_with_meta_module" != static ; then
AC_DEFINE(SLAPD_META_DYNAMIC,1,
[define to support dynamic LDAP Metadirectory backend])
@ -2745,6 +2745,28 @@ if test "$ol_link_sql" != no ; then
fi
fi
if test "$ol_with_dyngroup" != no ; then
BUILD_DYNGROUP=$ol_with_dyngroup
if test "$ol_with_dyngroup" = mod ; then
MFLAG=SLAPD_MOD_DYNAMIC
SLAPD_DYNAMIC_OVERLAYS="$SLAPD_DYNAMIC_OVERLAYS dyngroup.la"
else
MFLAG=SLAPD_MOD_STATIC
fi
AC_DEFINE_UNQUOTED(SLAPD_OVER_DYNGROUP,$MFLAG,[define for Dynamic Group overlay])
fi
if test "$ol_with_proxycache" != no ; then
BUILD_PROXYCACHE=$ol_with_proxycache
if test "$ol_with_proxycache" = mod ; then
MFLAG=SLAPD_MOD_DYNAMIC
SLAPD_DYNAMIC_OVERLAYS="$SLAPD_DYNAMIC_OVERLAYS pcache.la"
else
MFLAG=SLAPD_MOD_STATIC
fi
AC_DEFINE_UNQUOTED(SLAPD_OVER_PROXYCACHE,$MFLAG,[define for Proxy Cache overlay])
fi
if test "$ol_enable_slurpd" != no -a "$ol_link_threads" != no -a \
$BUILD_SLAPD = yes ; then
BUILD_SLURPD=yes
@ -2796,7 +2818,6 @@ AC_SUBST(BUILD_SLAPD)
AC_SUBST(BUILD_LDBM)
AC_SUBST(BUILD_META)
AC_SUBST(BUILD_MONITOR)
AC_SUBST(BUILD_CACHE)
AC_SUBST(BUILD_NULL)
AC_SUBST(BUILD_PASSWD)
AC_SUBST(BUILD_PERL)
@ -2814,6 +2835,8 @@ AC_SUBST(BUILD_SLAPD)
AC_SUBST(BUILD_PERL_DYNAMIC)
AC_SUBST(BUILD_SHELL_DYNAMIC)
AC_SUBST(BUILD_SQL_DYNAMIC)
AC_SUBST(BUILD_DYNGROUP)
AC_SUBST(BUILD_PROXYCACHE)
AC_SUBST(BUILD_SLURPD)
AC_SUBST(LDAP_LIBS)
@ -2830,6 +2853,7 @@ AC_SUBST(SLAPD_MODULES_LDFLAGS)
AC_SUBST(SLAPD_NO_STATIC)
AC_SUBST(SLAPD_STATIC_BACKENDS)
AC_SUBST(SLAPD_DYNAMIC_BACKENDS)
AC_SUBST(SLAPD_DYNAMIC_OVERLAYS)
AC_SUBST(PERL_CPPFLAGS)
AC_SUBST(SLAPD_PERL_LDFLAGS)
@ -2838,7 +2862,6 @@ AC_SUBST(MOD_PERL_LDFLAGS)
AC_SUBST(KRB4_LIBS)
AC_SUBST(KRB5_LIBS)
AC_SUBST(SASL_LIBS)
AC_SUBST(TERMCAP_LIBS)
AC_SUBST(TLS_LIBS)
AC_SUBST(MODULES_LIBS)
AC_SUBST(SLAPI_LIBS)
@ -2876,7 +2899,6 @@ libraries/Makefile:build/top.mk:libraries/Makefile.in:build/dir.mk \
libraries/liblber/Makefile:build/top.mk:libraries/liblber/Makefile.in:build/lib.mk:build/lib-shared.mk \
libraries/libldap/Makefile:build/top.mk:libraries/libldap/Makefile.in:build/lib.mk:build/lib-shared.mk \
libraries/libldap_r/Makefile:build/top.mk:libraries/libldap_r/Makefile.in:build/lib.mk:build/lib-shared.mk \
libraries/libldbm/Makefile:build/top.mk:libraries/libldbm/Makefile.in:build/lib.mk:build/lib-static.mk \
libraries/liblunicode/Makefile:build/top.mk:libraries/liblunicode/Makefile.in:build/lib.mk:build/lib-static.mk \
libraries/liblutil/Makefile:build/top.mk:libraries/liblutil/Makefile.in:build/lib.mk:build/lib-static.mk \
libraries/librewrite/Makefile:build/top.mk:libraries/librewrite/Makefile.in:build/lib.mk:build/lib-static.mk \
@ -2896,6 +2918,7 @@ servers/slapd/back-shell/Makefile:build/top.mk:servers/slapd/back-shell/Makefile
servers/slapd/back-sql/Makefile:build/top.mk:servers/slapd/back-sql/Makefile.in:build/mod.mk \
servers/slapd/shell-backends/Makefile:build/top.mk:servers/slapd/shell-backends/Makefile.in:build/srv.mk \
servers/slapd/slapi/Makefile:build/top.mk:servers/slapd/slapi/Makefile.in:build/lib.mk:build/lib-shared.mk \
servers/slapd/overlays/Makefile:build/top.mk:servers/slapd/overlays/Makefile.in:build/lib.mk \
servers/slapd/tools/Makefile:build/top.mk:servers/slapd/tools/Makefile.in \
servers/slurpd/Makefile:build/top.mk:servers/slurpd/Makefile.in:build/srv.mk \
tests/Makefile:build/top.mk:tests/Makefile.in:build/dir.mk \

6
doc/devel/template.c
View file

@ -20,7 +20,7 @@
* additional notices.
*/
/* ACKNOWLEDGEMENTS:
* This work was initially developed by John Doe (of FOO Corporation).
* Additional significant contributors include:
* Jane Doe of BAR, Inc. (added this and that)
* This work was initially developed by Jane Doe for inclusion in
* OpenLDAP Software. Additional significant contributors include:
* John Doe
*/

4
doc/devel/todo
View file

@ -43,7 +43,6 @@ Implement authPassword (RFC 3112)
Implement DIT Structure Rules and Name Forms
Implement LDAP Transactions extension
Implement native support for simple SASL mechanisms (e.g. EXTERNAL and PLAIN)
Implement LDAPprep
Redesign slapd memory allocation fault handling
Localize tools
@ -51,8 +50,7 @@ Localize tools
Small projects
--------------
Add dumpasn1 logging support
Implement SASLprep
Redesign test suite to use configure generated run script
Implement LDAPprep and SASLprep
Add tests to test suite
Convert utfconv.txt into man page(s).
Recode linked-list structs to use <ldap_queue.h> macros

24
doc/drafts/README
View file

@ -1,18 +1,18 @@
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 (I-Ds) are working documents of the Internet
Engineering Task Force (IETF), its areas, its working groups, and
individual contributors.
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."
I-Ds are only 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 I-Ds as reference material or to cite them
other than as "work in progress."
OpenLDAP maintains copies of drafts for which we find interesting.
Existance here does not necessarily imply any support nor any plans
to support for the I-D. The I-Ds found in this directory may be
stale, expired, or otherwise out of date.
The OpenLDAP Project maintains copies of I-D for which we find
interesting. Existance here does not necessarily imply any support
nor any plans to support for the I-D. The I-Ds found in this
directory may be stale, expired, or otherwise out of date.
Please refer to http://www.ietf.org/ for latest revisions (and
Please go to <http://www.ietf.org/> for latest revisions (and
status).
$OpenLDAP$

2058
doc/drafts/draft-ietf-ldapbis-authmeth-xx.txt
View file

File diff suppressed because it is too large Load diff

362
doc/drafts/draft-ietf-ldapbis-dn-xx.txt
View file

@ -6,12 +6,14 @@
INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 4 May 2003
Expires in six months 27 October 2003
Obsoletes: 2253
LDAP: String Representation of Distinguished Names
<draft-ietf-ldapbis-dn-10.txt>
<draft-ietf-ldapbis-dn-12.txt>
Status of Memo
@ -23,7 +25,7 @@ Status of Memo
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
Revision (LDAPBIS) Working Group mailing list
<ietf-ldapbis@openldap.org>. Please send editorial comments directly
to the document editor <Kurt@OpenLDAP.org>.
@ -40,10 +42,22 @@ Status of Memo
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
Copyright 2003, The Internet Society. All Rights Reserved.
Copyright (C) The Internet Society (2003). All Rights Reserved.
Please see the Copyright section near the end of this document for
more information.
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-12.txt 27 October 2003
Abstract
@ -52,14 +66,6 @@ Abstract
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
Zeilenga LDAP: Distinguished Names [Page 1]
INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
designed to give a clean representation of commonly used distinguished
names, while being able to represent any distinguished name.
@ -75,13 +81,14 @@ Conventions
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 a
directory entry [X.501][Models].
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 string form.
(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
@ -89,8 +96,8 @@ Conventions
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 one of the
local national languages).
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
@ -102,6 +109,13 @@ Conventions
from its ASN.1 structured representation to a string, all algorithms
MUST produce strings which adhere to the requirements of Section 3.
Zeilenga LDAP: Distinguished Names [Page 2]
INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
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].
@ -109,13 +123,6 @@ Conventions
This document is an integral part of the LDAP Technical Specification
[Roadmap].
Zeilenga LDAP: Distinguished Names [Page 2]
INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
This document obsoletes RFC 2253. Changes since RFC 2253 are
summarized in Appendix B.
@ -141,7 +148,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
This section defines the RECOMMENDED algorithm for converting a
distinguished name from an ASN.1 structured representation to an UTF-8
[RFC2279] encoded Universal Character Set (UCS) [ISO10646] character
[UTF-8] encoded Universal Character Set (UCS) [ISO10646] 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 MUST be produced by
@ -158,20 +165,19 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
2.2), starting with the last element of the sequence and moving
backwards toward the first.
Zeilenga LDAP: Distinguished Names [Page 3]
INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
The encodings of adjoining RelativeDistinguishedNames are separated by
a comma ("," U+002C) character.
2.2. Converting RelativeDistinguishedName
Zeilenga LDAP: Distinguished Names [Page 3]
INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
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.
@ -189,14 +195,14 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
encoding of the AttributeValue is given in Section 2.4.
If the AttributeType is defined to have a short name and that short
name is known to be registered [REGISTRY] as identifying the
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 dynamically update their knowledge of
registered short names. However, implementations SHOULD provide a
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.
@ -214,20 +220,20 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
desired (see Section 5.2).
Otherwise, if the AttributeValue is of a syntax which has a native
string encoding, the value is converted first to a UTF-8 encoded UCS
string according to its syntax specification (see for example Section
6 of [Syntaxes]). If that UTF-8 encoded UCS 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.
Zeilenga LDAP: Distinguished Names [Page 4]
INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
string encoding, the value is converted first to a UTF-8 encoded UCS
string according to its syntax specification (see for example Section
6 of [Syntaxes]). If that UTF-8 encoded UCS 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;
@ -259,7 +265,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
3. Parsing a String back to a Distinguished Name
The string representation of Distinguished Names is restricted to
UTF-8 [RFC2279] encoded characters from the Universal Character Set
UTF-8 [UTF-8] encoded characters from the Universal Character Set
(UCS) [ISO10646]. The structure of this string representation is
specified using the following Augmented BNF [RFC2234] grammar:
@ -271,19 +277,18 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
attributeTypeAndValue = attributeType EQUALS attributeValue
Zeilenga LDAP: Distinguished Names [Page 5]
INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
attributeType = descr / numericoid
attributeValue = string / hexstring
; The UTF-8 string shall not contain NULL, ESC, or
Zeilenga LDAP: Distinguished Names [Page 5]
INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
; one of escaped, shall not start with SHARP or SPACE,
; and shall must not end with SPACE.
string = [ (leadchar / pair)
@ -327,19 +332,19 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
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>.
One or more attribute values assertions, separated by <PLUS>, for a
Zeilenga LDAP: Distinguished Names [Page 6]
INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
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
@ -383,19 +388,19 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
OU=Sales+CN=J. Smith,DC=example,DC=net
This example shows the method of escaping of a comma in a common
name:
CN=John Smith\, III,DC=example,DC=net
An example name in which a value contains a carriage return
Zeilenga LDAP: Distinguished Names [Page 7]
INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
name:
CN=John Smith\, III,DC=example,DC=net
An example name in which a value contains a carriage return
character:
CN=Before\0dAfter,DC=example,DC=net
@ -439,17 +444,19 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
- 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.
Zeilenga LDAP: Distinguished Names [Page 8]
INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
- 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.
5.2. Use of Distinguished Names in Security Applications
@ -491,79 +498,97 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
8. Normative References
[X.501] "The Directory -- Models," ITU-T Rec. X.501(1993).
[X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) -
Specification of Basic Notation", X.680, 1994.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119).
[RFC2234] Crocker, D., and P. Overell, "Augmented BNF for Syntax
[X.501] International Telecommunication Union -
Telecommunication Standardization Sector, "The Directory
Zeilenga LDAP: Distinguished Names [Page 9]
INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
Specifications: ABNF", RFC 2234, November 1997.
-- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 2279, January 1998.
[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).
[Models] K. Zeilenga (editor), "LDAP: Directory Information
Models", draft-ietf-ldapbis-models-xx.txt, a work in
progress.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[Roadmap] K. Zeilenga, "LDAP: Technical Specification Road Map",
draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[Protocol] J. Sermersheim (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", draft-yergeau-rfc2279bis-xx.txt, a work in
progress.
[Syntaxes] S. Legg (editor), "LDAP: Syntaxes",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress.
[Models] Zeilenga, K. (editor), "LDAP: Directory Information
Models", draft-ietf-ldapbis-models-xx.txt, a work in
progress.
[Schema] K. Dally (editor), "LDAP: User Schema",
draft-ietf-ldapbis-user-schema-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.
[ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
Architecture and Basic Multilingual Plane, ISO/IEC
10646-1 : 1993.
[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.
[ISO10646] International Organization for Standardization,
"Universal Multiple-Octet Coded Character Set (UCS) -
Architecture and Basic Multilingual Plane", ISO/IEC
10646-1 : 1993.
[REGISTRY] IANA, Object Identifier Descriptors Registry,
<http://www.iana.org/...>.
9. Informative References
[X.500] "The Directory -- overview of concepts, models and
services," ITU-T Rec. X.500(1993).
[X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic,
Canonical, and Distinguished Encoding Rules", X.690,
1994.
[RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
RFC 3383), September 2002.
[RFC2849] G. Good, "The LDAP Data Interchange Format (LDIF) -
Technical Specification", RFC 2849, June 2000.
Appendix A. Presentation Issues
This appendix is provided for informational purposes only, it is not a
normative part of this specification.
[ASCII] Coded Character Set--7-bit American Standard Code for
Information Interchange, ANSI X3.4-1986.
Zeilenga LDAP: Distinguished Names [Page 10]
INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 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).
[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.
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
@ -587,6 +612,14 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
demonstrated in the final example of Section 4).
When a DN string is displayed in free form text, it is often necessary
Zeilenga LDAP: Distinguished Names [Page 11]
INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
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
@ -612,14 +645,6 @@ INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
so it has been line-wrapped for readability. The extra white
space is to be removed before the DN string is used in LDAP.
Zeilenga LDAP: Distinguished Names [Page 11]
INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
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.
@ -642,18 +667,27 @@ Appendix B. Changes made since RFC 2253
The following substantive changes were made to RFC 2253:
- Removed IESG Note. The IESG Note has been addressed.
- Clarified (in Section 1), that this document does not define a
- Clarified (in Section 1) that this document does not define a
Zeilenga LDAP: Distinguished Names [Page 12]
INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
canonical string representation.
- 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.
- Replaced specification of additional requirements for LDAPv2
implementations which also support LDAPv3 (RFC 2253, Section 4)
with a statement (in Section 3) allowing recognition of
alternative string representations.
- Clarified (in Section 2.3) that the "published" table of names
which may be appear in DNs is the table which Section 2.3
provides. Remove "as an example" language. Noted this table is
not extensible. Added statement (in Section 3) allowing
recognition of additional names. Added security considerations
(Section 5.3) regarding the use of other names.
- Updated Section 2.3 to indicate attribute type name strings are
case insensitive.
- Updated Section 2.4 to allow hex pair escaping of all characters
@ -669,21 +703,48 @@ Appendix B. Changes made since RFC 2253
- Added discussion of presentation issues (Appendix A).
- Added this appendix.
Zeilenga LDAP: Distinguished Names [Page 12]
INTERNET-DRAFT draft-ietf-ldapbis-dn-10.txt 4 May 2003
In addition, numerous editorial changes were made.
Copyright 2003, The Internet Society. All Rights Reserved.
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
Zeilenga LDAP: Distinguished Names [Page 13]
INTERNET-DRAFT draft-ietf-ldapbis-dn-12.txt 27 October 2003
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright
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
or assist in its implmentation 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
@ -694,15 +755,6 @@ Copyright 2003, The Internet Society. All Rights Reserved.
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 AUTHORS, 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.
@ -727,5 +779,9 @@ Copyright 2003, The Internet Society. All Rights Reserved.
Zeilenga LDAP: Distinguished Names [Page 13]
Zeilenga LDAP: Distinguished Names [Page 14]

268
doc/drafts/draft-ietf-ldapbis-filter-xx.txt
View file

@ -7,12 +7,12 @@
Network Working Group M. Smith, Editor
Request for Comments: DRAFT Netscape Communications Corp.
Obsoletes: RFC 2254 T. Howes
Expires: 28 August 2003 Opsware, Inc.
28 February 2003
Expires: 25 April 2004 Opsware, Inc.
25 October 2003
LDAP: String Representation of Search Filters
<draft-ietf-ldapbis-filter-04.txt>
<draft-ietf-ldapbis-filter-05.txt>
@ -57,7 +57,7 @@ Expires: 28 August 2003 Opsware, Inc.
Smith & Howes Intended Category: Standards Track [Page 1]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
INTERNET-DRAFT LDAP: String Repres. of Search Filters 25 October 2003
3. Table of Contents
@ -72,15 +72,16 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
8. Security Considerations........................................7
9. Normative References...........................................7
10. Informative References.........................................8
11. Acknowledgments................................................8
12. Authors' Address...............................................8
13. Full Copyright Statement.......................................9
14. Appendix A: Changes Since RFC 2254.............................9
14.1. Technical Changes...........................................9
14.2. Editorial Changes...........................................10
15. Appendix B: Changes Since Previous Document Revision...........11
15.1. Technical Changes...........................................11
15.2. Editorial Changes...........................................11
11. Intellectual Property Rights...................................8
12. Acknowledgments................................................8
13. Authors' Address...............................................8
14. Full Copyright Statement.......................................9
15. Appendix A: Changes Since RFC 2254.............................9
15.1. Technical Changes...........................................10
15.2. Editorial Changes...........................................10
16. Appendix B: Changes Since Previous Document Revision...........11
16.1. Technical Changes...........................................12
16.2. Editorial Changes...........................................12
4. Introduction
@ -110,10 +111,9 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
Smith & Howes Intended Category: Standards Track [Page 2]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
INTERNET-DRAFT LDAP: String Repres. of Search Filters 25 October 2003
Filter ::= CHOICE {
@ -160,7 +160,7 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
LDAPString ::= OCTET STRING -- UTF-8 encoded,
-- ISO 10646 characters
where the LDAPString above is limited to the UTF-8 encoding [RFC2279]
where the LDAPString above is limited to the UTF-8 encoding [UTF-8]
of the ISO 10646 character set [ISO10646]. The AttributeDescription
is a string representation of the attribute description and is
defined in [Protocol]. The AttributeValue and AssertionValue OCTET
@ -169,7 +169,7 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
Smith & Howes Intended Category: Standards Track [Page 3]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
INTERNET-DRAFT LDAP: String Repres. of Search Filters 25 October 2003
STRING have the form defined in [Syntaxes]. The Filter is encoded
@ -201,10 +201,10 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
extensible = attr [dnattrs] [matchingrule] COLON EQUALS assertionvalue
/ [dnattrs] matchingrule COLON EQUALS assertionvalue
/ COLON EQUALS assertionvalue
present = attr EQUALS ASTERIX
present = attr EQUALS ASTERISK
substring = attr EQUALS [initial] any [final]
initial = assertionvalue
any = ASTERIX *(assertionvalue ASTERIX)
any = ASTERISK *(assertionvalue ASTERISK)
final = assertionvalue
attr = attributedescription
; The attributedescription rule is defined in
@ -219,18 +219,18 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
escaped = ESC HEX HEX
UTF1SUBSET = %x01-27 / %x2B-5B / %x5D-7F
; UTF1SUBSET excludes 0x00 (NUL), LPAREN,
; RPAREN, ASTERIX, and ESC.
; RPAREN, ASTERISK, and ESC.
Smith & Howes Intended Category: Standards Track [Page 4]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
INTERNET-DRAFT LDAP: String Repres. of Search Filters 25 October 2003
EXCLAMATION = %x21 ; exclamation mark ("!")
AMPERSAND = %x26 ; ampersand (or AND symbol) ("&")
ASTERIX = %x2A ; asterix ("*")
ASTERISK = %x2A ; asterisk ("*")
COLON = %x3A ; colon (":")
VERTBAR = %x7C ; vertical bar (or pipe) ("|")
TILDE = %x7E ; tilde ("~")
@ -264,11 +264,11 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
As indicated by the valueencoding rule, implementations MUST escape
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. Since RFC 2254 does not clearly define the term
"string representation" (and in particular does mention that the
string representation of an LDAP search filter is a string of UTF-8
encoded ISO 10646-1 characters) implementations SHOULD accept as
input strings that include invalid UTF-8 octet sequences.
search filter. Implementations SHOULD accept as input a string that
includes invalid UTF-8 octet sequences. 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 ISO 10646-1 characters).
7. Examples
@ -281,7 +281,7 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
Smith & Howes Intended Category: Standards Track [Page 5]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
INTERNET-DRAFT LDAP: String Repres. of Search Filters 25 October 2003
(!(cn=Tim Howes))
@ -297,7 +297,6 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
(o:dn:=Ace Industry)
(:1.2.3:=Wilma Flintstone)
(:dn:2.4.6.8.10:=Dino)
(:=Fred Flintstone)
The first example shows use of the matching rule "1.2.3.4.5".
@ -316,13 +315,10 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
The fifth example is a filter that should be applied to any attribute
supporting the matching rule given (since the attr has been omitted).
The sixth example is also a filter that should be applied to any
attribute supporting the matching rule given. Attributes supporting
the matching rule contained in the DN should also be considered.
The seventh and final example is a filter that should be applied to
any attribute (since both the attr and matching rule have been
omitted).
The sixth and final example is also a filter that should be applied
to any attribute supporting the matching rule given. Attributes
supporting the matching rule contained in the DN should also be
considered.
The following examples illustrate the use of the escaping mechanism.
@ -333,16 +329,17 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
(sn=Lu\c4\8di\c4\87)
(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
Smith & Howes Intended Category: Standards Track [Page 6]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
INTERNET-DRAFT LDAP: String Repres. of Search Filters 25 October 2003
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
backslash character.
@ -388,33 +385,53 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
[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.
Smith & Howes Intended Category: Standards Track [Page 7]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
INTERNET-DRAFT LDAP: String Repres. of Search Filters 25 October 2003
[RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998.
[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.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
draft-yergeau-rfc2279bis-xx.txt, a work in progress.
10. Informative References
None.
11. Intellectual Property Rights
11. Acknowledgments
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.
12. Acknowledgments
This document replaces RFC 2254 by Tim Howes. Changes included in
this revised specification are based upon discussions among the
@ -424,15 +441,23 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
acknowledged.
12. Authors' Address
13. Authors' Address
Mark Smith, Editor
Smith & Howes Intended Category: Standards Track [Page 8]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 25 October 2003
Netscape Communications Corp.
360 W. Caribbean Drive
Sunnyvale, CA 94089
USA
+1 650 937-3477
mcs@netscape.com
MarkCSmithWork@aol.com
Tim Howes
Opsware, Inc.
@ -442,19 +467,9 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
+1 408 744-7509
howes@opsware.com
14. Full Copyright Statement
Smith & Howes Intended Category: Standards Track [Page 8]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
13. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
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
@ -481,9 +496,19 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
14. Appendix A: Changes Since RFC 2254
15. Appendix A: Changes Since RFC 2254
14.1. Technical Changes
Smith & Howes Intended Category: Standards Track [Page 9]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 25 October 2003
15.1. Technical Changes
The following technical changes were made to the contents of the
"String Search Filter Definition" section:
@ -501,13 +526,6 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
precisely reference productions from the [Models] and [Protocol]
documents.
Smith & Howes Intended Category: Standards Track [Page 9]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
Introduced the "valueencoding" and associated "normal" and "escaped"
rules to reduce the dependence on descriptive text. The "normal"
production restricts filter strings to valid UTF-8 sequences.
@ -519,7 +537,7 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
of a clear definition of "string representation."
14.2. Editorial Changes
15.2. Editorial Changes
Changed document title to include "LDAP:" prefix.
@ -529,14 +547,23 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
Header and "Authors' Addresses" sections: added Mark Smith as the
document editor and updated affiliation and contact information.
"Table of Contents" section: added.
"Table of Contents" and "Intellectual Property Rights" sections:
added.
Copyright: updated the year.
Copyright: updated per latest IETF guidelines.
"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
Smith & Howes Intended Category: Standards Track [Page 10]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 25 October 2003
this document (instead of RFC 1960). Added reference to the [Roadmap]
document.
@ -550,27 +577,19 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
escaped is replaced by a backslash and two hex digits, which
represent a single octet.
"Examples" section: added five additional examples: (seeAlso=),
(cn:=Betty Rubble), (:1.2.3:=Wilma Flintstone), (:=Fred Flintstone),
and (1.3.6.1.4.1.1466.0=\04\02\48\69). Replaced one occurrence of "a
"Examples" section: added four additional examples: (seeAlso=),
(cn:=Betty Rubble), (:1.2.3:=Wilma Flintstone), and
(1.3.6.1.4.1.1466.0=\04\02\48\69). Replaced one occurrence of "a
value" with "an assertion value".
"Security Considerations" section: added references to [Protocol] and
Smith & Howes Intended Category: Standards Track [Page 10]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
[AuthMeth].
"Normative References" section: renamed from "References" per new RFC
guidelines. Changed from [1] style to [Protocol] style throughout the
document. Added entries for [ISO10646], [RFC2119], [AuthMeth],
[Models], and [Roadmap] and updated UTF-8 reference to RFC 2279.
Replaced RFC 822 reference with a reference to RFC 2234.
[Models], and [Roadmap] and updated the UTF-8 reference. Replaced
RFC 822 reference with a reference to RFC 2234.
"Informative References" section: added for clarity.
@ -582,72 +601,53 @@ INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
added.
15. Appendix B: Changes Since Previous Document Revision
16. Appendix B: Changes Since Previous Document Revision
This appendix lists all changes relative to the last published
revision, draft-ietf-ldapbis-filter-03.txt. Note that when
This appendix lists all changes relative to the previously published
revision, draft-ietf-ldapbis-filter-04.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-03.txt. This section will be
reviewed draft-ietf-ldapbis-filter-04.txt. This section will be
removed before this document is published as an RFC.
15.1. Technical Changes
"String Search Filter Definition" section: Added statement that the
string representation is a string of UTF-8 encoded ISO 10646-1
characters and statement about expected behavior in light of RFC
2254's lack of a clear definition of "string representation."
"String Search Filter Definition" section: Revised all of the ABNF to
use common productions from [Models]. Revised the "normal"
production to restrict filter strings to valid UTF-8 sequences.
15.2. Editorial Changes
"Status of this Memo" section: updated boilerplate to match current
I-D guidelines.
"Examples" section: removed ;binary from an example.
"LDAP Search Filter Definition " section: updated section references
Smith & Howes Intended Category: Standards Track [Page 11]
INTERNET-DRAFT LDAP: String Repres. of Search Filters 28 February 2003
to match current LDAPBis drafts. Made minor changes to the ASN.1 so
it exactly matches that used in the Protocol document (added
comments).
"Normative References" section: added references to [ISO10646],
[RFC2119] and [Models].
"Informative References" section: added for clarity.
Updated copyright year to 2003.
This Internet Draft expires on 28 August 2003.
INTERNET-DRAFT LDAP: String Repres. of Search Filters 25 October 2003
16.1. Technical Changes
"Examples" section: Removed the (:=Fred Flintstone) example which is
not allowed by the protocol.
16.2. Editorial Changes
"String Search Filter Definition" section: Revised the last two
sentences in this section to improve clarity (the updated text now
begins with the text "Implementations SHOULD accept as input a string
that includes...."
Replaced all occurrences of "asterix" with the correctly spelled
"asterisk."
"Normative References" section: changed UTF-8 reference to point to
the UTF-8 Internet Draft.
"Intellectual Property Rights" section: added.
Author's Addresses section: New email address for Mark Smith.
"Full Copyright Statement" section: updated text to match latest IETF
guidelines.
This Internet Draft expires on 25 April 2004.

460
doc/drafts/draft-ietf-ldapbis-models-xx.txt
View file

@ -6,13 +6,13 @@
INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 1 March 2003
Expires in six months 27 October 2003
Obsoletes: RFC 2251, RFC 2252, RFC 2256
LDAP: Directory Information Models
<draft-ietf-ldapbis-models-07.txt>
<draft-ietf-ldapbis-models-09.txt>
@ -40,9 +40,10 @@ Status of this Memo
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
Copyright 2003, The Internet Society. All Rights Reserved. Please
see the Copyright section near the end of this document for more
information.
Copyright (C) The Internet Society (2003). All Rights Reserved.
Please see the Full Copyright section near the end of this document
for more information.
Abstract
@ -54,10 +55,9 @@ Abstract
Zeilenga LDAP Models [Page 1]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
Table of Contents
@ -67,53 +67,56 @@ Table of Contents
Table of Contents 2
1. Introduction 3
1.1. Relationship to Other LDAP Specifications
1.2. Relationship to ITU Specifications
1.3. Conventions 4
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
2.2. Naming of Entries 7
2.1. The Directory Information Tree 7
2.2. Naming of Entries
2.3. Structure of an Entry 8
2.4. Object Classes
2.4. Object Classes 9
2.5. Attribute Descriptions 11
2.6. Alias Entries 15
3. Directory Administrative and Operational Information 16
3. Directory Administrative and Operational Information 17
3.1. Subtrees
3.2. Subentries 17
3.3. The 'objectClass' attribute
3.4. Operational attributes 18
4. Directory Schema 20
4.1. Schema Definitions 21
4.2. Subschema Subentries 30
3.2. Subentries
3.3. The 'objectClass' attribute 18
3.4. Operational attributes
4. Directory Schema 21
4.1. Schema Definitions 22
4.2. Subschema Subentries 31
4.3. 'extensibleObject' 34
4.4. Subschema Discovery
4.4. Subschema Discovery 35
5. DSA (Server) Informational Model
5.1. Server-specific Data Requirements 35
6. Other Considerations 38
5.1. Server-specific Data Requirements 36
6. Other Considerations 39
6.1. Preservation of User Information
6.2. Short Names
6.3. Cache and Shadowing 39
7. Implementation Guidelines 40
6.3. Cache and Shadowing 40
7. Implementation Guidelines
7.1. Server Guidelines
7.2. Client Guidelines
8. Security Considerations 41
7.2. Client Guidelines 41
8. Security Considerations
9. IANA Considerations
10. Acknowledgments 42
11. Author's Address
12. References
12. References 43
12.1. Normative References
12.2. Informative References 43
12.2. Informative References 44
Appendix A. Changes
A.1 Changes to RFC 2251 44
A.2 Changes to RFC 2252 46
A.3 Changes to RFC 2256 47
Copyright
A.3 Changes to RFC 2256 48
Intellectual Property Rights
Zeilenga LDAP Models [Page 2]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
Full Copyright 49
1. Introduction
@ -161,20 +164,20 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
This document obsoletes RFC 2251 sections 3.2 and 3.4, as well as
portions of sections 4 and 6. Appendix A.1 summaries changes to these
sections. The remainder of RFC 2251 is obsoleted by the [Protocol],
[AuthMeth], and [Roadmap] documents.
Zeilenga LDAP Models [Page 3]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
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
summaries changes to these sections. The remainder of RFC 2252 is
obsoleted by [Syntaxes] and [Schema].
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
@ -184,8 +187,8 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
1.2. Relationship to X.501
This document includes material, with and without adaptation, from the
[X.501]. Due to the adaptation, the material included in this
document takes precedence.
[X.501]. The material in this document takes precedence over that in
[X.501].
1.3. Conventions
@ -217,17 +220,17 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
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 " "
Zeilenga LDAP Models [Page 4]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
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)
@ -254,36 +257,37 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
; Any UTF-8 character
UTF8 = UTF1 / UTFMB
UTFMB = UTF2 / UTF3 / UTF4 / UTF5 / UTF6
UTFMB = UTF2 / UTF3 / UTF4
UTF0 = %x80-BF
UTF1 = %x00-7F
UTF2 = %xC0-DF 1(UTF0)
UTF3 = %xE0-EF 2(UTF0)
UTF4 = %xF0-F7 3(UTF0)
UTF5 = %xF8-FB 4(UTF0)
UTF6 = %xFC-FD 5(UTF0)
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)
; Any octet
OCTET = %x00-FF
Object identifiers are represented in LDAP using a dot-decimal format
conforming to the ABNF:
Object identifiers (OIDs) [X.680] are represented in LDAP using a dot-
decimal format conforming to the ABNF:
numericoid = number *( 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 LDAP Models [Page 5]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
conform to the ABNF:
descr = keystring
Where either an object identifier or a short name may be specified,
the following production is used:
@ -329,17 +333,16 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
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).
Zeilenga LDAP Models [Page 6]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
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 naming of entries.
Section 2.3 discusses the structure of entries.
@ -386,16 +389,14 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
immediate subordinates of the entry's immediate superior (i.e., all
siblings).
The following are example string representations of RDNs [LDAPDN]:
Zeilenga LDAP Models [Page 7]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
The following are example string representations of RDNs [LDAPDN]:
UID=12345
OU=Engineering
CN=Kurt Zeilenga+L=Redwood Shores
@ -446,10 +447,9 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 8]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
Two values are considered equivalent if they would match according to
@ -505,7 +505,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 9]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
allowed to be present in entries belonging to the class. As an entry
@ -561,7 +561,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 10]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
Structural object classes are related to associated entries:
@ -617,7 +617,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 11]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
2.5.1) and a set of zero or more attribute options (see Section
@ -673,7 +673,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 12]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
syntax of its supertype. An attribute type cannot be a subtype of an
@ -695,7 +695,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Not all options can be associated with attributes held in the
directory. Tagging options can be.
Not all options can be use in conjunction with all attribute types.
Not all options can be used in conjunction with all attribute types.
In such cases, the attribute description is to be treated as
unrecognized.
@ -716,7 +716,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
conforming to the <option> production defined in Section 2.5 of this
document.
Procedures for registering options are detailed in BCP 64 [RFC3383].
Procedures for registering options are detailed in BCP 64 [BCP64bis].
2.5.2.1. Tagging Options
@ -729,7 +729,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 13]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
An attribute description with N tagging options is considered a direct
@ -785,7 +785,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 14]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
precisely one attribute description. The description is indicated
@ -841,7 +841,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 15]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
NOTE - The name within the 'aliasedObjectName' is said to be
@ -897,7 +897,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 16]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
( 2.5.4.1 NAME 'aliasedObjectName'
@ -953,7 +953,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 17]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
subentry (e.g., 'subschema' for subschema subentries) to mimic the
@ -987,7 +987,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
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 added (if is not already present).
'x-b' to be implicitly added (if is not already present).
Servers SHALL restrict modifications of this attribute to prevent a
superclasses of remaining 'objectClass' values from being deleted.
@ -1009,13 +1009,13 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 18]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
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
'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
@ -1065,7 +1065,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 19]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
@ -1121,7 +1121,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 20]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
( 2.5.18.2 NAME 'modifyTimestamp'
@ -1177,7 +1177,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 21]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
structural object classes of the entries;
@ -1233,7 +1233,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 22]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
qdstring = SQUOTE dstring SQUOTE
@ -1289,7 +1289,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 23]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"
@ -1317,7 +1317,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
[ SP "SUP" SP oid ] ; subtype
[ 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
@ -1345,7 +1345,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 24]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
EQUALITY, ORDERING, SUBSTRING provide the oid of the equality,
@ -1401,7 +1401,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 25]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
Attribute Type Description. This bound is not part of the syntax name
@ -1457,7 +1457,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 26]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
MatchingRuleUseDescription = LPAREN WSP
@ -1486,7 +1486,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
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 string of Universal Character Set (UCS)
[ISO10646] characters in UTF-8 [RFC2279] form.
[ISO10646] characters in UTF-8 [UTF-8] form.
Each LDAP syntax is identified by an object identifier (OID).
@ -1513,7 +1513,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 27]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
For DIT entries of a particular structural object class, a DIT content
@ -1569,7 +1569,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 28]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
<numericoid> is the object identifier of the structural object class
@ -1625,7 +1625,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 29]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
where:
@ -1681,7 +1681,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 30]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
<numericoid> is object identifier which identifies this name form;
@ -1737,7 +1737,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 31]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
Subschema is held in (sub)entries belonging to the subschema auxiliary
@ -1793,7 +1793,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 32]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
4.2.3. 'matchingRules'
@ -1849,7 +1849,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 33]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
SYNTAX 1.3.6.1.4.1.1466.115.121.1.16
@ -1905,7 +1905,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 34]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
Note that not all servers will implement this object class, and those
@ -1961,7 +1961,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Zeilenga LDAP Models [Page 35]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
5.1. Server-specific Data Requirements
@ -1996,7 +1996,8 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
- supportedLDAPVersion: LDAP versions supported; and
- supportedSASLMechanisms: recognized SASL mechnanisms.
- supportedSASLMechanisms: recognized Simple Authentication and
Security Layers (SASL) [SASL] mechanisms.
The values of these attributes provided may depend on session specific
and other factors. For example, a server supporting the SASL EXTERNAL
@ -2011,15 +2012,16 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Section 4.4.
5.1.1. 'altServer'
Zeilenga LDAP Models [Page 36]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
5.1.1. 'altServer'
The 'altServer' attribute lists URLs referring to alternative 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
@ -2065,17 +2067,16 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
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 [RFC3383].
( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
protocol mechanisms are detailed in BCP 64 [BCP64bis].
Zeilenga LDAP Models [Page 37]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
( 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 )
@ -2097,7 +2098,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
extended operation need not be listed.
Procedures for registering object identifiers used to discovery of
protocol mechanisms are detailed in BCP 64 [RFC3383].
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
@ -2123,15 +2124,15 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
5.1.6. 'supportedSASLMechanisms'
The 'supportedSASLMechanisms' attribute lists the SASL mechanisms
[RFC2222] which the server recognizes. The contents of this attribute
Zeilenga LDAP Models [Page 38]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
[RFC2222] which the server recognizes. 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.
@ -2179,15 +2180,15 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
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
Zeilenga LDAP Models [Page 39]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
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
@ -2196,24 +2197,7 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
in different subschemas.
Procedures for registering short names (descriptors) are detailed in
BCP 64 [RFC3383bis].
[[The remainder of this subsection will be included a subsequent
revision of RFC 3383.]]
To avoid interoperability problems, the following additional
considerations are stated:
Descriptors used to identify various schema elements SHOULD be
registered unless in private-use name space (e.g., they begin with
"x-"). Descriptors defined in RFCs MUST be registered.
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 registration requests require Expert Review.
BCP 64 [BCP64bis].
6.3. Cache and Shadowing
@ -2236,14 +2220,6 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
the names of attribute types and object classes defined in Section 3
and 4, respectively, of [Schema].
Zeilenga LDAP Models [Page 40]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Servers MUST ensure that entries conform to user and system schema
rules or other data model constraints.
@ -2260,6 +2236,14 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
Servers MAY implement additional schema elements. Servers SHOULD
provide definitions of all schema elements they support in subschema
Zeilenga LDAP Models [Page 40]
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
(sub)entries.
@ -2292,14 +2276,6 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
9. IANA Considerations
Zeilenga LDAP Models [Page 41]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
It is requested that the Internet Assigned Numbers Authority (IANA)
update the LDAP descriptors registry as indicated the following
template:
@ -2317,6 +2293,13 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
The following descriptors (short names) should be updated to refer
to RFC XXXX.
Zeilenga LDAP Models [Page 41]
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
NAME Type OID
------------------------ ---- -----------------
alias O 2.5.6.1
@ -2349,13 +2332,6 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
10. Acknowledgments
Zeilenga LDAP Models [Page 42]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
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
@ -2364,7 +2340,8 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
International Telephone Union (ITU). Additional text was borrowed
from RFC 2253 by Mark Wahl, Tim Howes, and Steve Kille.
This document is a product of the IETF LDAPBIS Working Group.
This document is a product of the IETF LDAP Revison (LDAPBIS) Working
Group.
11. Author's Address
@ -2373,69 +2350,91 @@ INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
E-mail: <kurt@openldap.org>
Zeilenga LDAP Models [Page 42]
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
12. References
12.1. Normative References
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2119] S. Bradner, "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.
[RFC2234] Crocker, D., and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[BCP64bis] Zeilenga, K., "IANA Considerations for LDAP", draft-
ietf-ldapbis-bcp64-xx.txt, a work in progress.
[RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
RFC 3383), September 2002.
[Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification
Road Map", draft-ietf-ldapbis-roadmap-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.
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
[Protocol] J. Sermersheim (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.
[AuthMeth] R. Harrison (editor), "LDAP: Authentication Methods and
Connection Level Security Mechanisms",
draft-ietf-ldapbis-authmeth-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.
[LDAPDN] K. Zeilenga (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.
[SASL] Melnikov, A. (Editor), "Simple Authentication and
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.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", draft-yergeau-rfc2279bis-xx.txt, a work in
Zeilenga LDAP Models [Page 43]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
[Filters] M. Smith (editor), LDAPbis WG, "LDAP: String Representation
of Search Filters", draft-ietf-ldapbis-filter-xx.txt, a
work in progress.
progress.
[LDAPURL] M. Smith (editor), "LDAP: Uniform Resource Locator",
draft-ietf-ldapbis-url-xx.txt, a work in progress.
[ISO10646] International Organization for Standardization,
"Universal Multiple-Octet Coded Character Set (UCS) -
Architecture and Basic Multilingual Plane", ISO/IEC
10646-1 : 1993.
[Syntaxes] S. Legg (editor), "LDAP: Syntaxes",
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.
[Schema] K. Dally (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).
[ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
Architecture and Basic Multilingual Plane, ISO/IEC 10646-1
: 1993.
[X.501] International Telecommunication Union -
Telecommunication Standardization Sector, "The Directory
-- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
[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.680] ITU-T Rec. X.680, "Abstract Syntax Notation One (ASN.1) -
Specification of Basic Notation", 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).
12.2. Informative References
@ -2463,9 +2462,10 @@ A.1 Changes to RFC 2251
Zeilenga LDAP Models [Page 44]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
A.1.1 Section 3.2 of RFC 2251
@ -2503,7 +2503,7 @@ A.1.2 Section 3.4 of RFC 2251
Changes:
- Clarify that attributes of the root DSE are subject to "other
restrictions" in addition to acccess controls.
restrictions" in addition to access controls.
- Clarify that only recognized extended requests need to be enumerated
'supportedExtension'.
@ -2521,7 +2521,7 @@ A.1.2 Section 3.4 of RFC 2251
Zeilenga LDAP Models [Page 45]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
- Remove inconsistent text regarding handling of the
@ -2577,7 +2577,7 @@ A.2.1 Section 4 of RFC 2252
Zeilenga LDAP Models [Page 46]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
specification "descr is the syntactic representation of an object
@ -2633,7 +2633,7 @@ A.2.3 Section 7 of RFC 2252
Zeilenga LDAP Models [Page 47]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
interacts with precluded attributes.
@ -2662,11 +2662,43 @@ A.3 Changes to RFC 2256
document.
Copyright 2003, The Internet Society. All Rights Reserved.
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.
Zeilenga LDAP Models [Page 48]
INTERNET-DRAFT draft-ietf-ldapbis-models-09 27 October 2003
Full Copyright
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
or assist in its implmentation 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
@ -2677,38 +2709,6 @@ Copyright 2003, The Internet Society. All Rights Reserved.
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 AUTHORS, 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
Zeilenga LDAP Models [Page 48]
INTERNET-DRAFT draft-ietf-ldapbis-models-07 1 March 2003
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

3894
doc/drafts/draft-ietf-ldapbis-protocol-xx.txt
View file

File diff suppressed because it is too large Load diff

212
doc/drafts/draft-ietf-ldapbis-roadmap-xx.txt
View file

@ -6,13 +6,13 @@
INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 1 March 2003
Expires in six months 30 June 2003
Obsoletes: RFC 2251-2256, 2829-2830, 3377
LDAP: Technical Specification Road Map
<draft-ietf-ldapbis-roadmap-02.txt>
<draft-ietf-ldapbis-roadmap-03.txt>
Status of this Memo
@ -39,10 +39,10 @@ Status of this Memo
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
Copyright 2003, The Internet Society. All Rights Reserved.
Copyright (C) The Internet Society (2003). All Rights Reserved.
Please see the Copyright section near the end of this document for
more information.
Please see the Full Copyright section near the end of this document
for more information.
Abstract
@ -57,7 +57,7 @@ Abstract
Zeilenga LDAP: TS Road Map [Page 1]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-02 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-03 30 June 2003
Conventions
@ -80,7 +80,8 @@ Conventions
LDAP: String Representation of Distinguished Names [LDAPDN],
LDAP: String Representation of Search Filters [Filters],
LDAP: Uniform Resource Locator [LDAPURL],
LDAP: Syntaxes [Syntaxes], and
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
@ -93,27 +94,26 @@ Conventions
this document but may be defined in some future document(s).
IANA (Internet Assigned Numbers Authority) considerations for LDAP
described in BCP 64 [RFC3383] apply fully to this revision of the LDAP
technical specification.
described in BCP 64 [BCP64bis] apply fully to this revision of the
LDAP technical specification.
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 Telephone Union (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 models
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.
Zeilenga LDAP: TS Road Map [Page 2]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-02 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-03 30 June 2003
This technical specification explicitly incorporates portions of
@ -137,10 +137,13 @@ INTERNET-DRAFT draft-ietf-ldapbis-roadmap-02 1 March 2003
[Models] replaces portions of RFC 2251, RFC 2252 and RFC 2256.
[Protocol] replaces the majority RFC 2251 and portions of RFC 2252.
[AuthMeth] replaces RFC 2829, RFC 2830, and portions of RFC 2251.
[Syntax] replaces the majority of RFC 2252 and portions of RFC 2256.
[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
@ -163,57 +166,75 @@ INTERNET-DRAFT draft-ietf-ldapbis-roadmap-02 1 March 2003
E-mail: <kurt@openldap.org>
7. References
Zeilenga LDAP: TS Road Map [Page 3]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-02 1 March 2003
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-03 30 June 2003
7. References
7.1. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
RFC 3383), September 2002.
[BCP64bis] Zeilenga, K., "IANA Considerations for LDAP", draft-
ietf-ldapbis-bcp64-xx.txt, a work in progress.
[Models] K. Zeilenga (editor), "LDAP: Directory Information Models",
draft-ietf-ldapbis-models-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] J. Sermersheim (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
[Protocol] Sermersheim, J. (editor), "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
[AuthMeth] R. Harrison (editor), "LDAP: Authentication Methods and
Connection Level Security Mechanisms",
draft-ietf-ldapbis-authmeth-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.
[LDAPDN] K. Zeilenga (editor), "LDAP: String Representation of
Distinguished Names", draft-ietf-ldapbis-dn-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.
[Filters] M. Smith (editor), LDAPbis WG, "LDAP: String Representation
of Search Filters", draft-ietf-ldapbis-filter-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] M. Smith (editor), "LDAP: Uniform Resource Locator",
draft-ietf-ldapbis-url-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] S. Legg (editor), "LDAP: Syntaxes",
draft-ietf-ldapbis-syntaxes-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] K. Dally (editor), "LDAP: User Schema",
draft-ietf-ldapbis-user-schema-xx.txt, a work in progress.
[LDAPprep] Zeilenga, K., "LDAP: Internationalized String
Preparation", draft-ietf-ldapbis-strpro-xx.txt, a work
in progress.
[X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
Models and Service", 1993.
[Schema] Dally, K. (editor), "LDAP: User Schema",
draft-ietf-ldapbis-user-schema-xx.txt, a work in
progress.
[X.501] ITU-T Rec. X.501, "The Directory: Models", 1993.
[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] ITU-T Rec. X.511, "The Directory: Abstract Service
Definition", 1993.
Zeilenga LDAP: TS Road Map [Page 4]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-03 30 June 2003
[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).
7.2. Informative References
@ -221,40 +242,67 @@ INTERNET-DRAFT draft-ietf-ldapbis-roadmap-02 1 March 2003
None.
Zeilenga LDAP: TS Road Map [Page 4]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-02 1 March 2003
Appendix A. Changes to Previous Documents
This appendix outlines changes this document makes relative
to the documents it replaces (in whole or in part).
This appendix outlines changes this document makes relative to the
documents it replaces (in whole or in part).
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.
These changes include defining the terms "LDAP" and
"LDAPv3" to refer to this revision of the technical
specification.
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.
The section was modified slightly (the word "document" was replaced
with "technical specification") to clarify that it applies to the
entire LDAP technical specification.
Copyright 2003, The Internet Society. All Rights Reserved.
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
Zeilenga LDAP: TS Road Map [Page 5]
INTERNET-DRAFT draft-ietf-ldapbis-roadmap-03 30 June 2003
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
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
or assist in its implmentation 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
@ -265,19 +313,27 @@ Copyright 2003, The Internet Society. All Rights Reserved.
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 AUTHORS, 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.
Zeilenga LDAP: TS Road Map [Page 5]
Zeilenga LDAP: TS Road Map [Page 6]

410
doc/drafts/draft-ietf-ldapbis-strprep-xx.txt
View file

@ -6,12 +6,12 @@
Internet-Draft Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 26 May 2003
Expires in six months 27 October 2003
LDAP: Internationalized String Preparation
<draft-ietf-ldapbis-strprep-00.txt>
<draft-ietf-ldapbis-strprep-02.txt>
Status of this Memo
@ -46,10 +46,10 @@ Status of this Memo
Abstract
The previous Lightweight Directory Access Protocol (LDAP) technical
specifications did not precisely define how string matching is to be
performed. This lead to a number of usability and interoperability
problems. This document defines string preparation algorithms for
matching rules defined for use in LDAP.
specifications did not precisely define how character string matching
is to be performed. This lead to a number of usability and
interoperability problems. This document defines string preparation
algorithms for character-based matching rules defined for use in LDAP.
@ -57,7 +57,7 @@ Abstract
Zeilenga LDAPprep [Page 1]
Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
Conventions
@ -113,7 +113,7 @@ Conventions
Zeilenga LDAPprep [Page 2]
Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
The caseIgnoreMatch matching rule [X.520], for example, is simply
@ -130,22 +130,24 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
(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 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
strings for matching.
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 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 character string preparation algorithms described in this document
are based upon the "stringprep" approach [StringPrep]. 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.
The approach used here is a refinement of the "stringprep"
[StringPrep] 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;
@ -154,24 +156,24 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
"stringprep", characters insignificant to the matching rules are
removed.
Hence, preparation of strings for X.500 matching involves the
following steps:
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 Removal
Zeilenga LDAPprep [Page 3]
Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
6) Insignificant Character Removal
These steps are described in Section 2.
@ -181,8 +183,8 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
[Roadmap] which obsoletes the previously defined LDAP technical
specification [RFC3377] in its entirety.
This document details new LDAP internationalized string preparation
algorithms used by [Syntaxes] and possible other technical
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.
@ -190,15 +192,17 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
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 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.
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 string match rule evaluation.
attribute value in preparation for character string matching rule
evaluation.
1) Transcode
2) Map
@ -207,11 +211,23 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
5) Check bidi
6) Insignificant Character Removal
Failure in any step is be cause the assertion to be Undefined.
Failure in any step causes the assertion to evaluate to Undefined.
This process is intended to act upon non-empty character strings. If
the string to prepare is empty, this process is not applied and the
assertion is evaluated to Undefined.
The character repertoire of this process is Unicode 3.2 [Unicode].
Zeilenga LDAPprep [Page 4]
Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
2.1. Transcode
Each non-Unicode string value is transcoded to Unicode.
@ -221,22 +237,11 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
PrintableString [X.680] value are transcoded directly to Unicode.
Zeilenga LDAPprep [Page 4]
Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
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).
If the implementation is unable or unwilling to perform the
transcoding as described above, or the transcoding fails, this step
fails and the assertion is evaluated to Undefined.
The transcoded string is the output string.
The output is the transcoded string.
2.2. Map
@ -259,44 +264,55 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
Zp) are mapped to SPACE (U+0020).
For case ignore, numeric, and stored prefix string matching rules,
characters are case folded per B.2 of [RFC3454].
characters are case folded per B.2 of [StringPrep].
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].
composed) as described in [UAX15]. The output is the normalized
string.
2.4. Prohibit
All Unassigned, Private Use, and non-character code points are
prohibited. Surrogate codes (U+D800-DFFFF) are prohibited.
The REPLACEMENT CHARACTER (U+FFFD) code point is prohibited.
The first code point of a string is prohibited from being a combining
Zeilenga LDAPprep [Page 5]
Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
2.4. Prohibit
All Unassigned code points are prohibited. Unassigned code points are
listed in Table A.1 of [StringPrep].
Private Use (U+E000-F8FF, F0000-FFFFD, 100000-10FFFD) code points are
prohibited.
All non-character code points (U+FDD0-FDEF, FFFE-FFFF, 1FFFE-1FFFF,
2FFFE-2FFFF, 3FFFE-3FFFF, 4FFFE-4FFFF, 5FFFE-5FFFF, 6FFFE-6FFFF,
7FFFE-7FFFF, 8FFFE-8FFFF, 9FFFE-9FFFF, AFFFE-AFFFF, BFFFE-BFFFF,
CFFFE-CFFFF, DFFFE-DFFFF, EFFFE-EFFFF, FFFFE-FFFFF, 10FFFE-10FFFF) are
prohibited.
Surrogate codes (U+D800-DFFFF) are prohibited.
The REPLACEMENT CHARACTER (U+FFFD) code point is prohibited.
The first code point of a string is prohibited from being a combining
character.
Empty strings are prohibited.
The step fails and the assertion is evaluated to Undefined if the
input string contains any prohibited code point. The output string is
the input string.
The step fails if the input string contains any prohibited code point.
The output is the input string.
2.5. Check bidi
There are no bidirectional restrictions. The output string is the
input string.
There are no bidirectional restrictions. The output is the input
string.
2.5. Insignificant Character Removal
@ -305,21 +321,31 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
removed. The characters to be removed differ 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
Section 2.5.1 applies to case ignore and exact string matching.
Section 2.5.2 applies to numericString matching.
Section 2.5.3 applies to telephoneNumber matching
2.6.1. Insignificant Space Removal
2.5.1. Insignificant Space Removal
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
Zeilenga LDAPprep [Page 6]
Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
code points in the separator class, other than SPACE (U+0020).
The following spaces are regarded as not significant and are to be
removed:
If the input string consists entirely of spaces or is empty, the
output is a string consisting of exactly one space (e.g. " ").
Otherwise, the following spaces are removed:
- 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
@ -327,19 +353,8 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
- multiple consecutive spaces (these are taken as equivalent to a
single space character).
A string consisting entirely of spaces is equivalent to a string
containing exactly one space.
For example, removal of spaces from the Form KC string:
"<SPACE><SPACE>foo<SPACE><SPACE>bar<SPACE><SPACE>"
Zeilenga LDAPprep [Page 6]
Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
would result in the output string:
"foo<SPACE>bar"
and the Form KC string:
@ -348,38 +363,61 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
"<SPACE>".
2.6.2. numericString Insignificant Character Removal
2.5.2. numericString Insignificant Character Removal
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 not significant and are to be removed.
All spaces are regarded as not significant. If the input string
consists entirely of spaces or is empty, the output is a string
consisting of exactly one space (e.g. " "). Otherwise, all spaces 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:
"<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 an empty output string.
would result in the output string:
"<SPACE>".
2.6.3. telephoneNumber Insignificant Character Removal
2.5.3. telephoneNumber Insignificant Character Removal
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
Zeilenga LDAPprep [Page 7]
Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
(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 regarded as not significant and are to be
All hyphens and spaces are considered insignificant. If the string
contains only spaces and hyphens or is empty, then the output is a
string consisting of one space. Otherwise, all hyphens and spaces are
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 output string:
"<SPACE>".
3. Security Considerations
"Preparation for International Strings ('stringprep')" [RFC3454]
"Preparation for International Strings ('stringprep')" [StringPrep]
security considerations generally apply to the algorithms described
here.
@ -388,14 +426,6 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
Appendix A and B of this document were authored by Howard Chu
<hyc@symas.com> of Symas Corporation (based upon information provided
Zeilenga LDAPprep [Page 7]
Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
in RFC 1345).
@ -403,14 +433,25 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
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
('stringprep')" [StringPrep] 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.
6. Author's Address
Kurt Zeilenga
Zeilenga LDAPprep [Page 8]
Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
E-mail: <kurt@openldap.org>
@ -421,14 +462,14 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
[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.
[StringPrep] Hoffman P. and 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.
@ -445,13 +486,6 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
"Unicode Standard Annex #28: Unicode 3.2"
(http://www.unicode.org/reports/tr28/).
Zeilenga LDAPprep [Page 8]
Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
[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>,
@ -466,6 +500,14 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
Character Sets for the International Teletex Service",
T.61, 1988.
Zeilenga LDAPprep [Page 9]
Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
7.2. Informative References
[X.500] International Telecommunication Union -
@ -491,7 +533,7 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
2000.
[XMATCH] Zeilenga, K., "Internationalized String Matching Rules
for X.500", draft-zeilenga-ldapbis-strmatch-xx.txt a
for X.500", draft-zeilenga-ldapbis-strmatch-xx.txt, a
work in progress.
[RFC1345] Simonsen, K., "Character Mnemonics & Character Sets",
@ -500,17 +542,9 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
Appendix A. Teletex (T.61) to Unicode
Zeilenga LDAPprep [Page 9]
Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
This appendix defines an algorithm for transcoding [T.61] characters
to [Unicode] characters for use in string preparation for LDAP
matching rules. This appendix is a normative.
matching rules. This appendix is normative.
The transcoding algorithm is derived from the T.61-8bit definition
provided in [RFC1345]. With a few exceptions, the T.61 character
@ -522,6 +556,14 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
The codes from x80 to x9f are also equivalent to the corresponding
Unicode code points. This is specified for completeness only, as
Zeilenga LDAPprep [Page 10]
Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
these codes are control characters, and will be mapped to nothing in
the LDAP String Preparation Mapping step.
@ -532,9 +574,9 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
Undefined matching result. For diagnostic purposes, this algorithm
does not fail for undefined input codes. Instead, undefined codes in
the input are mapped to the Unicode REPLACEMENT CHARACTER (U+FFFD).
As the LDAP String Preparation Probhibit step disallows the
REPLACEMENT CHARACTER from appearing in its output, this transcoding
yields the desired effect.
As the LDAP String Preparation Prohibit step disallows the REPLACEMENT
CHARACTER from appearing in its output, this transcoding yields the
desired effect.
Note: RFC 1345 listed the non-spacing accent codepoints as residing in
the range starting at (U+E000). In the current Unicode
@ -556,14 +598,6 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
e8| 0141 | 00d8 | 0152 | 00ba | 00de | 0166 | 014a | 0149 |
f0| 0138 | 00e6 | 0111 | 00f0 | 0127 | 0131 | 0133 | 0140 |
f8| 0142 | 00f8 | 0153 | 00df | 00fe | 0167 | 014b | ?? |
Zeilenga LDAPprep [Page 10]
Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
--+------+------+------+------+------+------+------+------+
Table A.1: Mapping of 8-bit T.61 codes to Unicode
@ -579,12 +613,19 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
Appendix B. Additional Teletex (T.61) to Unicode Tables
Zeilenga LDAPprep [Page 11]
Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
All of the accented characters in T.61 have a corresponding code point
in Unicode. For the sake of completeness, the combined character
codes are presented in the following tables. This is informational
only; for matching purposes it is sufficient to map the non-spacing
accent and exchange the order of the character pair as specified in
Appendix A.
Appendix A. This appendix is informative.
B.1. Combinations with SPACE
@ -612,14 +653,6 @@ B.2. Combinations for xc1: (Grave accent)
40| ?? | 00c0 | ?? | ?? | ?? | 00c8 | ?? | ?? |
48| ?? | 00cc | ?? | ?? | ?? | ?? | 01f8 | 00d2 |
50| ?? | ?? | ?? | ?? | ?? | 00d9 | ?? | 1e80 |
Zeilenga LDAPprep [Page 11]
Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
58| ?? | 1ef2 | ?? | ?? | ?? | ?? | ?? | ?? |
60| ?? | 00e0 | ?? | ?? | ?? | 00e8 | ?? | ?? |
68| ?? | 00ec | ?? | ?? | ?? | ?? | 01f9 | 00f2 |
@ -635,6 +668,14 @@ B.3. Combinations for xc2: (Acute accent)
C, L, N, R, S, and Z. Unicode also defines G, K, M, P, and W. All of
these combinations are present in Table B.3.
Zeilenga LDAPprep [Page 12]
Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
--+------+------+------+------+------+------+------+------+
40| ?? | 00c1 | ?? | 0106 | ?? | 00c9 | ?? | 01f4 |
@ -669,13 +710,6 @@ B.4. Combinations for xc3: (Circumflex)
Table B.4: Mapping of T.61 Circumflex Accent Combinations
Zeilenga LDAPprep [Page 12]
Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
B.5. Combinations for xc4: (Tilde)
T.61 has predefined characters for combinations with A, I, O, U, and
@ -690,6 +724,14 @@ B.5. Combinations for xc4: (Tilde)
58| ?? | 1ef8 | ?? | ?? | ?? | ?? | ?? | ?? |
60| ?? | 00e3 | ?? | ?? | ?? | 1ebd | ?? | ?? |
68| ?? | 0129 | ?? | ?? | ?? | ?? | 00f1 | 00f5 |
Zeilenga LDAPprep [Page 13]
Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
70| ?? | ?? | ?? | ?? | ?? | 0169 | 1e7d | ?? |
78| ?? | 1ef9 | ?? | ?? | ?? | ?? | ?? | ?? |
--+------+------+------+------+------+------+------+------+
@ -724,14 +766,6 @@ B.7. Combinations for xc6: (Breve)
Unicode also defines E, I, and O. All of these combinations are
present in Table B.7.
Zeilenga LDAPprep [Page 13]
Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
--+------+------+------+------+------+------+------+------+
40| ?? | 0102 | ?? | ?? | ?? | 0114 | ?? | 011e |
@ -746,6 +780,14 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
Table B.7: Mapping of T.61 Breve Accent Combinations
Zeilenga LDAPprep [Page 14]
Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
B.8. Combinations for xc7: (Dot Above)
T.61 has predefined characters for C, E, G, I, and Z. Unicode also
@ -780,14 +822,6 @@ B.9. Combinations for xc8: (Diaeresis)
58| 1e8c | 0178 | ?? | ?? | ?? | ?? | ?? | ?? |
60| ?? | 00e4 | ?? | ?? | ?? | 00eb | ?? | ?? |
68| 1e27 | 00ef | ?? | ?? | ?? | ?? | ?? | 00f6 |
Zeilenga LDAPprep [Page 14]
Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
70| ?? | ?? | ?? | ?? | 1e97 | 00fc | ?? | 1e85 |
78| 1e8d | 00ff | ?? | ?? | ?? | ?? | ?? | ?? |
--+------+------+------+------+------+------+------+------+
@ -802,6 +836,14 @@ B.10. Combinations for xca: (Ring Above)
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
--+------+------+------+------+------+------+------+------+
40| ?? | 00c5 | ?? | ?? | ?? | ?? | ?? | ?? |
Zeilenga LDAPprep [Page 15]
Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
48| ?? | ?? | ?? | ?? | ?? | ?? | ?? | ?? |
50| ?? | ?? | ?? | ?? | ?? | 016e | ?? | ?? |
58| ?? | ?? | ?? | ?? | ?? | ?? | ?? | ?? |
@ -836,14 +878,6 @@ B.11. Combinations for xcb: (Cedilla)
B.12. Combinations for xcd: (Double Acute Accent)
T.61 has predefined characters for O, and U. These combinations are
Zeilenga LDAPprep [Page 15]
Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
present in Table B.12.
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
@ -858,6 +892,14 @@ Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
B.13. Combinations for xce: (Ogonek)
Zeilenga LDAPprep [Page 16]
Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
T.61 has predefined characters for A, E, I, and U. Unicode also
defines the combination for O. All of these combinations are present
in Table B.13.
@ -892,20 +934,11 @@ B.14. Combinations for xcf: (Caron)
68| 021f | 01d0 | 01f0 | 01e9 | 013e | ?? | 0148 | 01d2 |
70| ?? | ?? | 0159 | 0161 | 0165 | 01d4 | ?? | ?? |
78| ?? | ?? | 017e | ?? | ?? | ?? | ?? | ?? |
Zeilenga LDAPprep [Page 16]
Internet-Draft draft-ietf-ldapbis-strprep-00 26 May 2003
--+------+------+------+------+------+------+------+------+
Table B.14: Mapping of T.61 Caron Accent Combinations
Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any
@ -915,6 +948,14 @@ Intellectual Property Rights
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
Zeilenga LDAPprep [Page 17]
Internet-Draft draft-ietf-ldapbis-strprep-02 27 October 2003
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
@ -951,5 +992,20 @@ Full Copyright
Zeilenga LDAPprep [Page 17]
Zeilenga LDAPprep [Page 18]

1556
doc/drafts/draft-ietf-ldapbis-syntaxes-xx.txt
View file

File diff suppressed because it is too large Load diff

484
doc/drafts/draft-ietf-ldapbis-url-xx.txt
View file

@ -7,13 +7,13 @@
Network Working Group Mark Smith, Editor
Request for Comments: DRAFT Netscape Communications Corp.
Obsoletes: RFC 2255 Tim Howes
Expires: 28 August 2003 Opsware, Inc.
Expires: 25 April 2004 Opsware, Inc.
28 February 2003
25 October 2003
LDAP: Uniform Resource Locator
<draft-ietf-ldapbis-url-03.txt>
<draft-ietf-ldapbis-url-04.txt>
@ -57,7 +57,7 @@ Copyright (C) The Internet Society (2003). All Rights Reserved.
Smith & Howes Intended Category: Standards Track [Page 1]
INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
3. Table of Contents
@ -67,20 +67,22 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
3. Table of Contents..............................................2
4. Introduction...................................................2
5. URL Definition.................................................2
5.1. Escaping Using the Method.................................4
6. Defaults for Fields of the LDAP URL............................5
7. Examples.......................................................5
8. Security Considerations........................................7
9. Acknowledgements...............................................8
10. Normative References...........................................9
11. Informative References.........................................9
12. Authors' Address...............................................9
13. Full Copyright Statement.......................................10
14. Appendix A: Changes Since RFC 2255.............................10
14.1. Technical Changes...........................................10
14.2. Editorial Changes...........................................11
15. Appendix B: Changes Since Previous Document Revision...........13
15.1. Technical Changes...........................................13
15.2. Editorial Changes...........................................13
7. Examples.......................................................6
8. Security Considerations........................................8
9. Normative References...........................................8
10. Informative References.........................................9
11. Intellectual Property Rights...................................9
12. Acknowledgements...............................................10
13. Authors' Address...............................................10
14. Full Copyright Statement.......................................11
15. Appendix A: Changes Since RFC 2255.............................11
15.1. Technical Changes...........................................11
15.2. Editorial Changes...........................................12
16. Appendix B: Changes Since Previous Document Revision...........13
16.1. Technical Changes...........................................14
16.2. Editorial Changes...........................................14
4. Introduction
@ -106,37 +108,42 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
5. 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].
Smith & Howes Intended Category: Standards Track [Page 2]
INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
the following grammar, following the ABNF notation defined in
[RFC2234].
ldapurl = scheme COLON SLASH SLASH [hostport] [SLASH dn
[QUESTION [attributes] [QUESTION [scope]
[QUESTION [filter] [QUESTION extensions]]]]]
scheme = "ldap"
hostport = <hostport from Section 3.2.2 of [RFC2396]>
; as updated by [RFC2732] to allow IPv6 literal addresses
; as updated by [RFC2732] to allow IPv6 literal addresses
dn = <distinguishedName from Section 3 of [LDAPDN]>
; see the "Escaping Using the % Method" section below.
attributes = attrdesc *(COMMA attrdesc)
attrdesc = <AttributeDescription from Section 4.1.4 of [Protocol]>
/ ASTERIX
/ ASTERISK
; see the "Escaping Using the % Method" section below.
scope = "base" / "one" / "sub"
filter = <filter from Section 4 of [Filters]>
; see the "Escaping Using the % Method" section below.
extensions = extension *(COMMA extension)
extension = [EXCLAMATION] extype [EQUALS exvalue]
extype = oid / oiddescr
exvalue = <LDAPString from section 4.1.2 of [Protocol]>
; see the "Escaping Using the % Method" section below.
oid = <LDAPOID from section 4.1.2 of [Protocol]>
oiddescr = <name from section 3.3 of [LDAPIANA]>
oiddescr = <name from section 3.3 of [RFC3383]>
EXCLAMATION = %x21 ; exclamation mark ("!")
ASTERIX = %x2A ; asterix ("*")
ASTERISK = %x2A ; asterisk ("*")
COLON = %x3A ; colon (":")
QUESTION = %x3F ; question mark ("?")
SLASH = %x5C; forward slash ("/")
@ -157,6 +164,14 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
The scope construct is used to specify the scope of the search to
perform in the given LDAP server. The allowable scopes are "base"
Smith & Howes Intended Category: Standards Track [Page 3]
INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
for a base object search, "one" for a one-level search, or "sub" for
a subtree search.
@ -164,14 +179,6 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
within the specified scope during the search. It has the format
specified in [Filters].
Smith & Howes Intended Category: Standards Track [Page 3]
INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
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
@ -199,18 +206,29 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
The extension type (extype) MAY be specified using the oid form
(e.g., 1.2.3.4) or the oiddesc form (e.g., myLDAPURLExtension). Use
of the oiddesc form SHOULD be restricted to registered object
identifier descriptive names. See [LDAPIANA] for registration
details and usage guidelines for descriptive names.
identifier descriptive names. See [RFC3383] 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.
5.1. Escaping Using the % Method
A generated LDAP URL MUST consist only of the restricted set of
characters included in the uric production that is defined in section
2 of [RFC2396]. Implementations SHOULD accept other valid UTF-8
strings as input. An octet MUST be escaped using the % method
described in section 2.4 of [RFC2396] in any of these situations:
strings [UTF-8] as input. An octet MUST be escaped using the %
method described in section 2.4 of [RFC2396] in any of these
Smith & Howes Intended Category: Standards Track [Page 4]
INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
situations:
The octet is not in the reserved set defined in section 2.2 of
[RFC2396] or in the unreserved set defined in section 2.3 of
@ -221,13 +239,6 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
It is a comma character ',' that occurs inside an extension value.
Smith & Howes Intended Category: Standards Track [Page 4]
INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
6. Defaults for Fields of the LDAP URL
Some fields of the LDAP URL are optional, as described above. In the
@ -263,6 +274,16 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
If extensions is omitted, no extensions are assumed.
Smith & Howes Intended Category: Standards Track [Page 5]
INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
7. Examples
The following are some example LDAP URLs using the format defined
@ -277,13 +298,6 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
ldap://ldap1.example.net/o=University%20of%20Michigan,c=US
Smith & Howes Intended Category: Standards Track [Page 5]
INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
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.
@ -318,28 +332,28 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
the LDAP entry named "o=Question?,c=US" is given below, illustrating
the use of the escaping mechanism on the reserved character '?'.
Smith & Howes Intended Category: Standards Track [Page 6]
INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
ldap://ldap2.example.com/o=Question%3f,c=US?mail
The next example illustrates the interaction between the LDAP string
representation of filters quoting mechanism and URL quoting
mechanisms.
ldap://ldap3.example.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.
ldap://ldap3.example.com/o=Babsco,c=US???(four-octet=%5c00%5c00%5c00%5c04)
IP 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 escaped as %5c in the
URL encoding.
The next example illustrates the interaction between the LDAP string
Smith & Howes Intended Category: Standards Track [Page 6]
INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
representation of DNs quoting mechanism and URL quoting mechanisms.
ldap://ldap.example.com/o=An%20Example%5c2c%20Inc.,c=US
@ -374,6 +388,14 @@ name extension (the value associated with the extension is an LDAP DN).
the e-bindname extension.
Smith & Howes Intended Category: Standards Track [Page 7]
INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
8. Security Considerations
General URL security considerations discussed in [RFC2396] are
@ -388,14 +410,6 @@ name extension (the value associated with the extension is an LDAP DN).
with this policy. If a client chooses to reuse an existing
connection when resolving one or more LDAP URL, it MUST ensure that
the connection is compatible with the URL and that no security
Smith & Howes Intended Category: Standards Track [Page 7]
INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
policies are violated.
Sending authentication information, no matter the mechanism, may
@ -427,7 +441,88 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
search, etc. The security implications of resolving an LDAP URL are
the same as those of resolving an LDAP search query.
9. Acknowledgements
9. Normative References
[LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of
Smith & Howes Intended Category: Standards Track [Page 8]
INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
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
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.
[RFC2396] Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC2732] Hinden, R., Carpenter, B., Masinter, L., "Format for
Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
[RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
Considerations for the Lightweight Directory Access Protocol
(LDAP)", RFC 3383, September 2002.
[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods",
draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. a work in
progress.
[Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road
Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
draft-yergeau-rfc2279bis-xx.txt, a work in progress.
10. Informative References
None.
11. 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
Smith & Howes Intended Category: Standards Track [Page 9]
INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
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.
12. Acknowledgements
The LDAP URL format was originally defined at the University of
Michigan. This material is based upon work supported by the National
@ -445,54 +540,7 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
Kurt Zeilenga, Jim Sermersheim, and Hallvard Furuseth deserve special
thanks for their contributions.
Smith & Howes Intended Category: Standards Track [Page 8]
INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
10. Normative References
[LDAPDN] Zeilenga, K. (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-iana-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
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.
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998.
[RFC2396] Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[RFC2732] Hinden, R., Carpenter, B., Masinter, L., "Format for
Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
[AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods",
draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. a work in
progress.
[Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road
Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress.
11. Informative References
None.
12. Authors' Address
13. Authors' Address
Mark Smith, Editor
Netscape Communications Corp.
@ -500,15 +548,7 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
Sunnyvale, CA 94089
USA
+1 650 937-3477
Smith & Howes Intended Category: Standards Track [Page 9]
INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
mcs@netscape.com
MarkCSmithWork@aol.com
Tim Howes
Opsware, Inc.
@ -516,9 +556,17 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
Sunnyvale, CA 94085
USA
+1 408 744-7509
Smith & Howes Intended Category: Standards Track [Page 10]
INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
howes@opsware.com
13. Full Copyright Statement
14. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
@ -546,48 +594,46 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
15. Appendix A: Changes Since RFC 2255
14. Appendix A: Changes Since RFC 2255
14.1. Technical Changes
15.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].
Smith & Howes Intended Category: Standards Track [Page 10]
INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
Added note and references to [RFC2732] to allow literal IPv6
addresses inside the hostport portion of the URL.
Added missing ASTERIX as an alternative for the attrdesc part of the
Added missing ASTERISK as an alternative for the attrdesc part of the
URL. It is believed that existing implementations of RFC 2255
already support this.
Added angle brackets around free-form prose in the "dn", "hostport",
"attrdesc", "filter", and "exvalue" rules.
Smith & Howes Intended Category: Standards Track [Page 11]
INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
Changed the ABNF for ldapurl to group the dn component with the
preceding slash.
Changed the extype rule to be an LDAPOID from [Protocol] or an OID
description from [LDAPIANA].
description from [RFC3383].
Changed the text about extension types so it references [LDAPIANA].
Changed the text about extension types so it references [RFC3383].
Reordered rules to more closely follow the order the elements appear
in the URL.
"Bindname Extension": removed due to lack of known implementations.
14.2. Editorial Changes
15.2. Editorial Changes
Changed document title to include "LDAP:" prefix.
@ -612,14 +658,6 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
"URL Definition" section: removed second copy of ldapurl grammar and
following two paragraphs (editorial error in RFC 2255). Fixed line
Smith & Howes Intended Category: Standards Track [Page 11]
INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
break within '!' sequence. Reworded last paragraph to clarify which
characters must be URL escaped. Added text to indicate that LDAP
URLs are used for references and referrals. Added text that refers
@ -630,6 +668,14 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
"URL Processing" section: clarified that connections MAY be reused
only if the open connection is compatible with the URL. Added text
Smith & Howes Intended Category: Standards Track [Page 12]
INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
to indicate that use of security services is encouraged and that they
SHOULD be used when updates are involved. Removed "dn" from
discussion of authentication methods. Added note that the client MAY
@ -639,9 +685,11 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
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.
Added an example that demonstrates the interaction between DN
escaping and URL escaping. Added some examples to show URL
equivalence with respect to the dn portion of the URL.
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 escaping.
Added some examples to show URL equivalence with respect to the dn
portion of the URL.
"Security Considerations" section: Added a note about connection
reuse. Added a note about using strong authentication methods for
@ -654,11 +702,11 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
"Normative References" section: renamed from "References" per new RFC
guidelines. Changed from [1] style to [Protocol] style throughout the
document. Added references to RFCs 2234 and 2829. Updated RFC 1738
references to the appropriate sections within RFC 2396. Updated the
references to refer to LDAPBis WG documents. Removed the reference to
the LDAP Attribute Syntaxes document and added references to the LDAP
IANA and Roadmap documents.
document. Added references to RFCs 2234, 2829, and 3383. Updated
RFC 1738 references to the appropriate sections within RFC 2396.
Updated the references to refer to LDAPBis WG documents. Removed the
reference to the LDAP Attribute Syntaxes document and added a
reference to the Roadmap document.
"Informative References" section: added for clarity.
@ -668,64 +716,72 @@ INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
Copyright: updated the year.
16. Appendix B: Changes Since Previous Document Revision
Smith & Howes Intended Category: Standards Track [Page 12]
INTERNET-DRAFT LDAP: Uniform Resource Locator 28 February 2003
15. Appendix B: Changes Since Previous Document Revision
This appendix lists all changes relative to the last published
revision, draft-ietf-ldapbis-url-02.txt. Note that when appropriate
This appendix lists all changes relative to the previously published
revision, draft-ietf-ldapbis-url-03.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-02.txt. This section will be removed before this
ietf-ldapbis-url-03.txt. This section will be removed before this
document is published as an RFC.
15.1. Technical Changes
"URL Definition" section: revised all of the ABNF to use common
productions from [Models] and added note and references to [RFC2732]
to allow literal IPv6 addresses inside the hostport portion of the
URL.
15.2. Editorial Changes
"Status of this Memo" section: updated boilerplate to match current
I-D guidelines.
"URL Definition" section: replaced misleading phrase "MAY define
other extensions" with "MAY define one or more extensions" (this
document no longer defines any extensions). Rewrote the last
paragraph of this section to more clearly describe the escaping rules
and to reference [RFC2396] accurately.
"Examples" section: added an example that demonstrates the
interaction between DN escaping and URL escaping and clarified the
text that introduces the LDAP filter escaping interaction example.
"Acknowledgements" section: added Hallvard Furuseth.
"Normative References" section: added a reference to [RFC2732].
"Informative References" section: added for clarity.
Copyright: updated the year to 2003.
"Authors' Address" section: updated Tim's contact information.
Appendix A: added an older editorial change that was accidently
overlooked (Changed document title to include "LDAP:" prefix).
This Internet Draft expires on 28 August 2003.
Smith & Howes Intended Category: Standards Track [Page 13]
INTERNET-DRAFT LDAP: Uniform Resource Locator 25 October 2003
16.1. Technical Changes
None.
16.2. Editorial Changes
"URL Definition" section: added comments in the ABNF to point the
reader to the "Escaping Using the % Method" section, which was
changed into a section of its own to highlight the importance of
escaping the URL components correctly.
"Examples" section: changed the name of an attribute used in one
example from "int" to "four-octet" to avoid potential confusion.
Replaced all occurrences of "asterix" with the correctly spelled
"asterisk."
"Normative References" section: changed UTF-8 reference to point to
the UTF-8 Internet Draft; replace [LDAPIANA] Internet Draft reference
with a reference to RFC 3383.
"Intellectual Property Rights" section: added.
Author's Addresses section: New email address for Mark Smith.
"Full Copyright Statement" section: updated text to match latest IETF
guidelines.
This Internet Draft expires on 25 April 2004.
Smith & Howes Intended Category: Standards Track [Page 14]

1277
doc/drafts/draft-ietf-ldapbis-user-schema-xx.txt
View file

File diff suppressed because it is too large Load diff

1298
doc/drafts/draft-ietf-ldup-lcup-xx.txt
View file

File diff suppressed because it is too large Load diff

176
doc/drafts/draft-zeilenga-ldap-adlist-xx.txt
View file

@ -6,11 +6,11 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Informational OpenLDAP Foundation
Expires in six months 20 December 2002
Expires in six months 26 October 2003
LDAP: Requesting Attributes by Object Class
<draft-zeilenga-ldap-adlist-04.txt>
<draft-zeilenga-ldap-adlist-06.txt>
Status of this Memo
@ -21,9 +21,9 @@ 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 Working Group
mailing list <ldapext@ietf.org>. Please send editorial comments
directly to the author <Kurt@OpenLDAP.org>.
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>.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
@ -38,10 +38,10 @@ Status of this Memo
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
Copyright 2002, The Internet Society. All Rights Reserved.
Copyright (C) The Internet Society (2003). All Rights Reserved.
Please see the Copyright section near the end of this document for
more information.
Please see the Full Copyright section near the end of this document
for more information.
Abstract
@ -57,7 +57,7 @@ Abstract
Zeilenga Requesting Attributes by Object Class [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-04 20 December 2002
INTERNET-DRAFT draft-zeilenga-ldap-adlist-06 26 October 2003
1. Overview
@ -82,14 +82,21 @@ INTERNET-DRAFT draft-zeilenga-ldap-adlist-04 20 December 2002
[RFC2256].
This extension is intended to be used where the user is in direct
control of the parameters of the LDAP search operation.
control of the parameters of the LDAP search operation, such as when
entering a LDAP URL [RFC2255] into a web browser.
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.
2. Return of all Attributes of an Object Class
3. Return of all Attributes of an Object Class
This extension allows object class identifiers is to be provided in
the attributes field of the LDAP SearchRequest [RFC2251]. For each
@ -101,6 +108,14 @@ INTERNET-DRAFT draft-zeilenga-ldap-adlist-04 20 December 2002
unrecognized attribute description.
This extension redefines the attributes field of the SearchRequest to
Zeilenga Requesting Attributes by Object Class [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-06 26 October 2003
be a DescriptionList described by the following ASN.1 [X.680] data
type:
@ -109,13 +124,6 @@ INTERNET-DRAFT draft-zeilenga-ldap-adlist-04 20 December 2002
The Description is string conforming to the ABNF [RFC2234]:
Zeilenga Requesting Attributes by Object Class [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-04 20 December 2002
Description = AttributeDescription | ObjectClassDescription.
ObjectClassDescription = "+" ObjectClass *( ";" options )
@ -129,9 +137,11 @@ INTERNET-DRAFT draft-zeilenga-ldap-adlist-04 20 December 2002
zero options in the attributes field of a SearchRequest. Other uses
may be defined in future specifications.
Servers supporting this feature SHOULD publish the Object Identifier
1.3.6.1.4.1.4203.1.11.2 as a value of the 'supportedFeatures'
[FEATURES] attribute in the root DSE.
Servers supporting this feature SHOULD publish the object identifier
(OID) 1.3.6.1.4.1.4203.1.11.2 as a value of the 'supportedFeatures'
[FEATURES] 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
@ -147,29 +157,30 @@ INTERNET-DRAFT draft-zeilenga-ldap-adlist-04 20 December 2002
4. IANA Considerations
This OID 1.3.6.1.4.1.4203.1.11.2 to identify the LDAP "OC AD List?
feature. This OID was assigned [ASSIGN] by OpenLDAP Foundation, under
its IANA-assigned private enterprise allocation [PRIVATE], for use in
this specification.
The OID 1.3.6.1.4.1.4203.1.11.2 is used to identify the LDAP "OC AD
List" feature. 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 mechansism is requested per BCP 64
Registration of this protocol mechanism is requested per BCP 64
[RFC3383].
Subject: Request for LDAP Protocol Mechansism 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: RFCxxxx
Author/Change Controller: Kurt Zeilenga <kurt@openldap.org>
Comments: none
Zeilenga Requesting Attributes by Object Class [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-04 20 December 2002
INTERNET-DRAFT draft-zeilenga-ldap-adlist-06 26 October 2003
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
5. Author's Address
@ -181,58 +192,66 @@ INTERNET-DRAFT draft-zeilenga-ldap-adlist-04 20 December 2002
6. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax
Definitions", RFC 2252, December 1997.
[RFC2252] Wahl, M., A. Coulbeck, T. Howes, and S. Kille,
"Lightweight Directory Access Protocol (v3): Attribute
Syntax Definitions", RFC 2252, December 1997.
[RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[FEATURES] K. Zeilenga, "Feature Discovery in LDAP",
draft-zeilenga-ldap-features-xx.txt (a work in progress).
[FEATURES] Zeilenga, K., "Feature Discovery in LDAP",
draft-zeilenga-ldap-features-xx.txt, a work in progress.
[X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) -
Specification of Basic Notation", X.680, 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).
7. Informative References
[RFC2256] M. Wahl, "A Summary of the X.500(96) User Schema for use
with LDAPv3", RFC 2256, December 1997.
[RFC3383] K. Zeilenga, "IANA Considerations for LDAP", RFC 3383,
September 2002.
[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 Requesting Attributes by Object Class [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-adlist-04 20 December 2002
INTERNET-DRAFT draft-zeilenga-ldap-adlist-06 26 October 2003
Copyright 2002, The Internet Society. All Rights Reserved.
[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.
[RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
(also RFC 3383), September 2002.
[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 (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
or assist in its implmentation 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
@ -243,25 +262,6 @@ Copyright 2002, The Internet Society. All Rights Reserved.
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 AUTHORS, 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.

106
doc/drafts/draft-zeilenga-ldap-assert-xx.txt
View file

@ -6,11 +6,11 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 11 May 2003
Expires in six months 25 October 2003
The LDAP Assertion Control
<draft-zeilenga-ldap-assert-00.txt>
<draft-zeilenga-ldap-assert-01.txt>
Status of this Memo
@ -22,8 +22,8 @@ Status of this Memo
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 Working Group mailing list <ldapext@ietf.org>. Please send
editorial comments directly to the author <Kurt@OpenLDAP.org>.
Extensions mailing list <ldapext@ietf.org>. Please send editorial
comments directly to the author <Kurt@OpenLDAP.org>.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
@ -48,30 +48,30 @@ 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 the assertion when applied to
the target entry of the operation. It can be used to construct "test
and set" and "test and clear" operations.
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.
Zeilenga LDAP Assertion Control [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
INTERNET-DRAFT draft-zeilenga-ldap-assert-01 25 October 2003
1. Overview
This document defines the Lightweight Directory Access Protocol (LDAP)
[RFC3377] assertion control. The assertion control allows the client
to specify a condition which allows the operation to be processed
normally only when true. Otherwise the operation fails.
to specify a condition which must be true for the operation to be
processed normally. Otherwise the operation fails.
The control can be used with the Modify operation [RFC2251] to perform
atomic "test and set" and "test and clear" operations as the the
asserted condition is evaluated as an integral part the operation.
The control may be attached to other update operations to support
conditional add, delete, and renaming of objects.
atomic "test and set" and "test and clear" operations as the asserted
condition is evaluated as an integral part the operation. The control
may be attached to other update operations to support conditional add,
delete, and renaming of objects.
The control may also be used with the search operation. Here the
assertion is applied to the base object of the search before searching
@ -83,13 +83,12 @@ INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
2. Terminology
Protocol elements are described using ASN.1 [X.680]. 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].
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].
DN stands for Distinguished Name.
DSA stands for Directory System Agent (i.e., a directory server).
DSA stands for Directory System Agent (or server).
DSE stands for DSA-specific Entry.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
@ -104,30 +103,25 @@ INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
[RFC2251, Section 4.5.1]. The criticality may be TRUE or FALSE.
There is no corresponding response control.
Servers implementing this technical specification SHOULD publish
IANA-ASSIGNED-OID as a value of the 'supportedControl' attribute
[RFC2252] in their root DSE.
The control is appropriate for both LDAP interrogation and update
operations [RFC2251] including Add, Compare, Delete, Modify, ModifyDN
(rename), and Search. It is inappropriate for Abandon, Bind nor
Unbind operations. It is also inappropriate for the Start TLS
[RFC2830] operation.
Zeilenga LDAP Assertion Control [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
INTERNET-DRAFT draft-zeilenga-ldap-assert-01 25 October 2003
The control is appropriate for both LDAP interrogation and update
operations [RFC2251] including Add, Compare, Delete, Modify, ModifyDN
(rename), and Search. It is not appropriate for Abandon, Bind nor
Unbind operations. Nor is it appropriate for the Start TLS [RFC2830]
operation.
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, then assertionFailed (IANA-ASSIGNED-CODE) resultCode is
returned and no further processing is performed.
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
@ -135,23 +129,29 @@ INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
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 SHALL be done as one atomic action.
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"
[RFC2251]. Hence, if the evaluation fails, no entries or
continuations references are returned.
Servers implementing this technical specification SHOULD publish the
object identifier IANA-ASSIGNED-OID as a value of the
'supportedControl' attribute [RFC2252] 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 how the target entry is
operations. In doing so, they must state how the target entry is
determined.
3. Security Considerations
4. Security Considerations
The filter may, like other values of the request, contain sensitive
information. When so, this information should be appropriately
protected.
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
determine directory content. Hence, the mechanism SHOULD be subject
@ -169,16 +169,16 @@ INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
Zeilenga LDAP Assertion Control [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
INTERNET-DRAFT draft-zeilenga-ldap-assert-01 25 October 2003
4. IANA Considerations
5. IANA Considerations
4.1. Object Identifier
5.1. Object Identifier
It is requested that IANA register upon Standards Action an LDAP
Object Identifier [RFC3383] to identify the LDAP Assertion Control
defined in this document.
It is requested that IANA assign upon Standards Action an LDAP Object
Identifier [RFC3383] 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:
@ -188,7 +188,7 @@ INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
Comments:
Identifies the LDAP Assertion Control
4.2 LDAP Protocol Mechanism
5.2 LDAP Protocol Mechanism
Registration of this protocol mechanism [RFC3383] is requested.
@ -203,7 +203,7 @@ INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
Comments: none
4.3 LDAP Result Code
5.3 LDAP Result Code
Assignment of an LDAP Result Code [RFC3383] called 'assertionFailed'
is requested.
@ -217,7 +217,7 @@ INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
Comments: none
5. Acknowledgments
6. Acknowledgments
The assertion control concept is attributed to Morteza Ansari.
@ -225,17 +225,17 @@ INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
Zeilenga LDAP Assertion Control [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
INTERNET-DRAFT draft-zeilenga-ldap-assert-01 25 October 2003
6. Author's Address
7. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
7. Normative References
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
@ -252,7 +252,7 @@ INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
September 2002.
8. Informative References
9. Informative References
[RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
(also RFC 3383), September 2002.
@ -281,7 +281,7 @@ Intellectual Property Rights
Zeilenga LDAP Assertion Control [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-assert-00 11 May 2003
INTERNET-DRAFT draft-zeilenga-ldap-assert-01 25 October 2003
copyrights, patents or patent applications, or other proprietary

188
doc/drafts/draft-zeilenga-ldap-authzid-xx.txt
View file

@ -6,12 +6,12 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 17 May 2002
Expires in six months 1 November 2002
LDAP "Who am I?" Operation
<draft-zeilenga-ldap-authzid-06.txt>
<draft-zeilenga-ldap-authzid-08.txt>
Status of this Memo
@ -23,8 +23,8 @@ Status of this Memo
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 Extension Working Group
mailing list <ietf-ldapext@netscape.com>. Please send editorial
comments directly to the author <Kurt@OpenLDAP.org>.
mailing list <ldapext@ietf.org>. Please send editorial comments
directly to the author <Kurt@OpenLDAP.org>.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
@ -57,7 +57,7 @@ Abstract
Zeilenga LDAP "Who am I?" [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
Conventions
@ -70,27 +70,20 @@ Conventions
1. Background and Intent of Use
This specification describes a Lightweight Directory Access Protocol
(LDAP) [RFC2251] extended 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.
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 to generally
read as "the primary authorization identity" and the "the primary
authzid", respectively.
(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 [AUTHCTL]
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 they are
transferred as part of. While it is possible to establish security
layers prior to the Bind operation, it is often desirable to only 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.
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
@ -101,26 +94,31 @@ Conventions
Control. The "Who am I?" operation can also be used prior to the Bind
operation.
The LDAP "Who am I?" operation is named after the UNIX whoami(1)
command. The whoami(1) command displays the effective user id.
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.
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
Zeilenga LDAP "Who am I?" [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
[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"
whoamiOID ::= "1.3.6.1.4.1.4203.1.11.3"
2.1. The whoami Request
@ -130,48 +128,54 @@ INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
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, if present, the response field is empty or an
field is absent and the response field, if present, is empty or an
authzId [RFC2829]. For example, a whoami response returning the
authzid "u:kurt@OPENLDAP.ORG" (in response to the example request)
authzId "u:kurt@OPENLDAP.ORG" (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 6b 75 72 74 40 4f 50 45 4e 4c 44 41 50 2e
4f 52 47
3. Operational Semantics
The function of the "Who am I?" operation is to request that the
server returns the authorization identity it currently associates with
the client. The client requests this authorization identity by
issuing a whoami Request. The server responds to this request with a
whoami Response.
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.
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 empty.
Otherwise the server is to provide the authzId [RFC2829] representing
the authorization identity it currently associates with the client in
the response field.
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.
Zeilenga LDAP "Who am I?" [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
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
@ -183,10 +187,10 @@ INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
4. Extending the "Who am I?" operation with controls
Future specifications may extend the "Who am I?" operation using the
control mechanism. 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.
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
@ -204,7 +208,7 @@ INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
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
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
@ -216,33 +220,50 @@ INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
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.
Zeilenga LDAP "Who am I?" [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
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 with any other extended operations, general LDAP considerations
apply. These are detailed in [RFC2251], [RFC2829], and [RFC2830].
As with any other extended operations, general LDAP security
considerations [RFC3377] apply.
6. IANA Considerations
No IANA assignments are requested.
This OID 1.3.6.1.4.1.4203.1.11.3 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.
This document uses the OID 1.3.6.1.4.1.4203.1.11.3 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 mechansism is requested [RFC3383].
Subject: Request for LDAP Protocol Mechansism 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: RFCxxxx
Author/Change Controller: IESG
Comments: none
7. Acknowledgment
@ -251,6 +272,17 @@ INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
"Authentication Response Control" [AUTHCTL] 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.
Zeilenga LDAP "Who am I?" [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
8. Author's Address
@ -274,18 +306,19 @@ INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
Access Protocol (v3): Extension for Transport Layer
Security", RFC 2830, May 2000.
[RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[PROXYCTL] R. Weltman, "LDAP Proxied Authentication Control", draft-
weltman-ldapv3-proxy-xx.txt (a work in progress).
Zeilenga LDAP "Who am I?" [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
10. Informative References
[RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
RFC 3383), September 2002.
[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
http://www.openldap.org/foundation/oid-delegate.txt.
@ -299,6 +332,14 @@ INTERNET-DRAFT draft-zeilenga-ldap-authzid-06 17 May 2002
Copyright 2002, The Internet Society. All Rights Reserved.
Zeilenga LDAP "Who am I?" [Page 6]
INTERNET-DRAFT draft-zeilenga-ldap-authzid-08 1 November 2002
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
@ -335,5 +376,20 @@ Copyright 2002, The Internet Society. All Rights Reserved.
Zeilenga LDAP "Who am I?" [Page 6]
Zeilenga LDAP "Who am I?" [Page 7]

254
doc/drafts/draft-zeilenga-ldap-cancel-xx.txt
View file

@ -6,11 +6,11 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 3 May 2003
Expires in six months 25 October 2003
LDAP Cancel Extended Operation
<draft-zeilenga-ldap-cancel-08.txt>
LDAP Cancel Operation
<draft-zeilenga-ldap-cancel-10.txt>
1. Status of this Memo
@ -21,9 +21,9 @@ Expires in six months 3 May 2003
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 Extension Working Group
mailing list <ldapext@ietf.org>. Please send editorial comments
directly to the author <Kurt@OpenLDAP.org>.
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>.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
@ -38,10 +38,10 @@ Expires in six months 3 May 2003
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
Copyright 2003, The Internet Society. All Rights Reserved.
Copyright (C) The Internet Society (2003). All Rights Reserved.
Please see the Copyright section near the end of this document for
more information.
Please see the Full Copyright section near the end of this document
for more information.
Abstract
@ -57,20 +57,23 @@ Abstract
Zeilenga LDAP Cancel [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
INTERNET-DRAFT draft-zeilenga-ldap-cancel-10 25 Octeboer 2003
Conventions
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 [RFC2251].
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].
Protocol elements are described using ASN.1 [X.680]. 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].
1. Background and Intent of Use
@ -83,10 +86,10 @@ Conventions
X.511 Directory Access Protocol (DAP) [X.511] provides an Abandon
operation which does have a response and also requires the abandoned
operation to return a response indicating it was canceled. The Cancel
operation is modeled after the DAP Abandon operation.
operation to return a response indicating it was canceled. The LDAP
Cancel operation is modeled after the DAP Abandon operation.
The Cancel operation SHOULD be used instead of the LDAP Abandon
The LDAP Cancel operation SHOULD be used instead of the LDAP Abandon
operation when the client needs an indication of the outcome. This
operation may be used to cancel both interrogation and update
operations.
@ -106,18 +109,17 @@ Conventions
2.1. Cancel Request
The Cancel request is an ExtendedRequest with the requestName field
containing the IANA-0IGNED-OID and a requestValue field which contains
Zeilenga LDAP Cancel [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
INTERNET-DRAFT draft-zeilenga-ldap-cancel-10 25 Octeboer 2003
a BER-encoded cancelRequestValue value. The cancelID field contains
the message id associated with the operation to be canceled.
The Cancel request is an ExtendedRequest with the requestName field
containing the IANA-ASSIGNED-OID and a requestValue field which
contains a BER-encoded cancelRequestValue value. The cancelID field
contains the message id associated with the operation to be canceled.
2.2. Cancel Response
@ -143,10 +145,10 @@ INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
cancel an outstanding operation issued within the same session.
The client requests the cancelation of an outstanding operation by
issuing a Cancel Response with a cancelID with the message id
identifying the outstanding operation. The Cancel Request itself has
a distinct message id. Clients SHOULD NOT request cancelation of an
operation multiple times.
issuing a Cancel Response with a cancelID set to the message id of the
outstanding operation. The Cancel Request itself has a distinct
message id. Clients SHOULD NOT request cancelation of an operation
multiple times.
If the server is willing and able to cancel the outstanding operation
identified by the cancelId, the server SHALL return a Cancel Response
@ -162,22 +164,24 @@ INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
knowledge of the operation requested to be canceled.
The cannotCancel resultCode is returned if the identified operation
does not support cancelation or the cancel operation could not be
performed. The following classes of operations are not cancelable:
Zeilenga LDAP Cancel [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
INTERNET-DRAFT draft-zeilenga-ldap-cancel-10 25 Octeboer 2003
does not support cancelation or the cancel operation could not be
performed. The following classes of operations are not cancelable:
- operations which have no response,
- operations which associate or disassociate authentication and/or
- operations which create, alter, or destroy authentication and/or
authorization associations,
- operations which establish or tear-down security services, and
- operations which establish, alter, or tear-down security services,
and
- operations which abandon or cancel other operations.
@ -187,20 +191,22 @@ INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
The tooLate resultCode is returned to indicate that it is too late to
cancel the outstanding operation. For example, the server may return
tooLate for a request to cancel an outstanding modify operation which
as already commited updates to the underlying datastore.
as already committed updates to the underlying data store.
Servers SHOULD indicate their support for this extended operation by
providing IANA-ASSIGNED-OID as a value of the supportedExtension
providing IANA-ASSIGNED-OID as a value of the 'supportedExtension'
attribute type in their root DSE. A server MAY choose to advertise
this extension only when the client is authorized to use this
operation.
this extension only when the client is authorized to use it.
4. Security Considerations
This operation is intended to allow a user to cancel operations they
previously issued. No user should be allowed to cancel an operation
issued by another user.
This operation is intended to allow user to cancel operations they
previously issued during the current LDAP association. In certain
cases, such as when the Proxy Authorization Control is in use,
different outstanding operations may be processed under different LDAP
associations. Servers MUST NOT allow a user to cancel an operation
belonging to another user.
Some operations should not be cancelable for security reasons. This
specification disallows cancelation of Bind operation and Start TLS
@ -215,28 +221,26 @@ INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
Registration of the following values [RFC3383] is requested.
5.1. Object Identifier
It is requested that IANA register upon Standards Action an LDAP
Object Identifier to identify the LDAP Cancel Extended Operation as
defined in this document.
Zeilenga LDAP Cancel [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
INTERNET-DRAFT draft-zeilenga-ldap-cancel-10 25 Octeboer 2003
The following registration template is suggested:
5.1. Object Identifier
It is requested that IANA register upon Standards Action an LDAP
Object Identifier to identify the LDAP Cancel 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: RFCXXXX
Specification: RFC XXXX
Author/Change Controller: IESG
Comments:
Identifies the LDAP Cancel Extended Operation
Identifies the LDAP Cancel Operation
5.2. LDAP Protocol Mechanism
@ -244,13 +248,13 @@ INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
It is requested that IANA register upon Standards Action the LDAP
Protocol Mechanism described in this document.
Subject: Request for LDAP Protocol Mechansism Registration
Subject: Request for LDAP Protocol Mechanism Registration
Object Identifier: IANA-ASSIGNED-OID
Description: LDAP Cancel Extended Operation
Description: LDAP Cancel Operation
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Extended Operation
Specification: RFCXXXX
Specification: RFC XXXX
Author/Change Controller: IESG
Comments: none
in 2
@ -268,78 +272,112 @@ INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
Result Code Name: noSuchOperation
Result Code Name: tooLate
Result Code Name: cannotCancel
Specification: RFCXXXX
Specification: RFC XXXX
Author/Change Controller: IESG
Comments: request four consecutive result codes be assigned
6. Acknowledgment
The LDAP Cancel operation is modeled after the X.511 DAP Abandon
Zeilenga LDAP Cancel [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
INTERNET-DRAFT draft-zeilenga-ldap-cancel-10 25 Octeboer 2003
6. Acknowledgment
The LDAP Cancel operation is modeled after the X.511 DAP Abandon
operation.
7. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[RFC2830] J. Hodges, R. Morgan, and M. Wahl, "Lightweight Directory
Access Protocol (v3): Extension for Transport Layer
Security", RFC 2830, May 2000.
[RFC2830] Hodges, J., R. Morgan, and M. Wahl, "Lightweight
Directory Access Protocol (v3): Extension for Transport
Layer Security", RFC 2830, May 2000.
[RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access Protocol
(v3): Technical Specification", RFC 3377, September 2002.
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) - Specification
of Basic Notation", X.680, 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).
[X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic,
Canonical, and Distinguished Encoding Rules", X.690, 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).
8. Informative References
[RFC3383] K. Zeilenga, "IANA Considerations for LDAP", RFC 3383,
September 2002.
[RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
(also RFC 3383), September 2002.
[X.511] ITU-T, "The Directory: Abstract Service Definition", X.511,
1993.
[X.511] International Telecommunication Union -
Telecommunication Standardization Sector, "The
Directory: Abstract Service Definition", X.511(1993).
9. Author's Address
Kurt D. Zeilenga
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
Copyright 2003, The Internet Society. 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
Zeilenga LDAP Cancel [Page 6]
INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
INTERNET-DRAFT draft-zeilenga-ldap-cancel-10 25 Octeboer 2003
OpenLDAP Foundation
<Kurt@OpenLDAP.org>
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
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 implmentation 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
@ -347,44 +385,6 @@ INTERNET-DRAFT draft-zeilenga-ldap-cancel-08 3 May 2003
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 AUTHORS, 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.

458
doc/drafts/draft-zeilenga-ldap-rfc2596-xx.txt
View file

@ -6,12 +6,12 @@
INTERNET-DRAFT Editor: Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 1 March 2002
Expires in six months 9 December 2002
Obsoletes: RFC 2596
Language Tags and Ranges in LDAP
draft-zeilenga-ldap-rfc2596-01.txt
draft-zeilenga-ldap-rfc2596-04.txt
Status of Memo
@ -23,9 +23,8 @@ Status of Memo
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 Working Group
(LDAPext) mailing list <ietf-ldapext@netscape.com>. Please send
editorial comments directly to the document editor
<Kurt@OpenLDAP.org>.
(LDAPext) mailing list <ldapext@ietf.org>. Please send editorial
comments directly to the document editor <Kurt@OpenLDAP.org>.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
@ -55,9 +54,10 @@ Abstract
Zeilenga Language Tags and Ranges in LDAP [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
Conventions
@ -69,7 +69,7 @@ Conventions
1. Background and Intended Use
The Lightweight Directory Access Protocol (LDAP) [Roadmap] provides a
The Lightweight Directory Access Protocol (LDAP) [RFC3377] provides a
means for clients to interrogate and modify information stored in a
distributed directory system. The information in the directory is
maintained as attributes of entries. Most of these attributes have
@ -79,8 +79,8 @@ Conventions
This document describes how language tags and ranges [RFC3066] are
carried in LDAP and are to be interpreted by LDAP implementations.
All implementations MUST be prepared to accept language tags and
ranges in the LDAP protocol.
All LDAP implementations MUST be prepared to accept language tags and
ranges.
This document replaces RFC 2596. Appendix A summaries changes made
since RFC 2596.
@ -88,8 +88,7 @@ Conventions
Appendix B discusses differences from X.500(1997) "contexts"
mechanism.
Appendix A and B are provided for information purposes and are not a
normative part of this specification.
Appendix A and B are provided for informational purposes only.
The remainder of this section provides a summary of Language Tags,
Language Ranges, and Attribute Descriptions.
@ -98,89 +97,81 @@ Conventions
1.1. Language Tags
Section 2 of BCP 47 [RFC3066] describes the language tag format which
is used in LDAP. Briefly, it is a string of ASCII alphabetic
characters and hyphens. Examples include "fr", "en-US" and "ja-JP".
Language tags are case insensitive. For example, the language tag
"en-us" is the same as "EN-US".
is used in LDAP. Briefly, it is a string of ASCII letters and
hyphens. Examples include "fr", "en-US" and "ja-JP". Language tags
are case insensitive. That is, the language tag "en-us" is the same
as "EN-US".
Section 2 of this document details use of language tags in LDAP.
1.2. Language Ranges
Section 2.5 of BCP 47 [RFC3066] describes the language ranges.
Zeilenga Language Tags and Ranges in LDAP [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
Section 2.5 of BCP 47 [RFC3066] describes the language ranges.
Language ranges are used to specify sets of language tags.
A language range matches a language tag if it exactly equals the tag,
or if it exactly equals a prefix of the tag such that the first
character following the prefix is "-". The special tag "*" matches
all tags.
A language range matches a language tag if it is exactly equal to the
tag, or if it is exactly equal to a prefix of the tag such that the
first character following the prefix is "-". That is, the language
range "de" matches the language tags "de" and "de-CH" but not "den".
The special language range "*" matches all language tags.
Due to restrictions upon option naming in LDAP, this document uses a
different language range syntax. However, the semantics of language
ranges in LDAP is consistent with BCP 47.
Due to attribute description option naming restrictions in LDAP, this
document defines a different language range syntax. However, the
semantics of language ranges in LDAP is consistent with BCP 47.
Section 3 of this document details use of language ranges in LDAP.
1.3. Attribute Descriptions
This section provides an overview of attributes in LDAP. LDAP
attributes are defined in [Models].
This section provides an overview of attribute descriptions in LDAP.
LDAP attributes and attribute descriptions are defined in [RFC2251].
An attribute consists of a type, a set of zero or more associated
tagging options, and a set of one or more values. The type and the
options are combined into the AttributeDescription.
AttributeDescriptions can also contain options which are not part of
the attribute, but indicate some other function such as the transfer
encoding.
the attribute, but indicate some other function (such as range
assertion or transfer encoding).
An attribute with one or more tagging options is a direct subtype of
each attribute of the same with all but one of the tagging options.
If the attribute's type is a direct subtype of some other type, then
the attribute is also a direct subtype of the attribute whose
description consists of the the supertype and all of the tagging
options. That is, CN;x-bar;x-foo is a direct subtype of CN;x-bar,
CN;x-foo, and name;x-bar;x-foo. Note that CN is a subtype of name.
If the attribute description contains an unrecognized option, the
attribute description is treated as an unrecognized attribute type.
As language tags are intended to stored with the attribute, they are
to treated as tagging options as described in Section 2. Language
range are used only to match against language ranges and are not
stored with the attribute. They are not treated tagging options (nor
as transfer options), but as described in Section 3.
An AttributeDescription with one or more tagging options is a direct
subtype of each AttributeDescription of the same type with all but one
of the tagging options. If the AttributeDescription's type is a
direct subtype of some other type, then the AttributeDescription is
also a direct subtype of the AttributeDescription which consists of
the supertype and all of the tagging options. That is,
"CN;x-bar;x-foo" is a direct subtype of "CN;x-bar", "CN;x-foo", and
"name;x-bar;x-foo". Note that "CN" is a subtype of "name".
2. Use of Language Tags in LDAP
This section describes how LDAP implementations MUST interpret
Zeilenga Language Tags and Ranges in LDAP [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
language tags in performing operations.
Servers which support storing attributes with language tag options in
the Directory Information Tree (DIT) SHOULD allow any attribute type
it recognizes that has the Directory String, IA5 String, or other
textual string syntax to have language tag options associated with it.
Servers MAY allow language options to be associated with other
textual string syntaxes to have language tag options associated with
it. Servers MAY allow language options to be associated with other
attributes types.
Zeilenga Language Tags and Ranges in LDAP [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
Clients SHOULD NOT assume servers are capable of storing attributes
with language tags in the directory.
@ -194,8 +185,8 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
2.1. Language Tag Options
A language tag option associates a natural language with values of an
attribute. An attribute description MAY contain multiple language tag
options. An entry MAY contain multiple attributes with same attribute
attribute. An attribute description may contain multiple language tag
options. An entry may contain multiple attributes with same attribute
type but different combinations of language tag (and other) options.
A language tag option conforms to the following ABNF [RFC2234]:
@ -216,17 +207,9 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
DIGIT = %x30-39 ; 0-9
A language tag option is a tagging option [Models]. A language tag
option has no effect on the syntax of the attribute's values nor their
transfer encoding.
Zeilenga Language Tags and Ranges in LDAP [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
A language tag option is a tagging option. A language tag option has
no effect on the syntax of the attribute's values nor their transfer
encoding.
Examples of valid AttributeDescription:
@ -237,6 +220,14 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
description;x-foobar
CN
Zeilenga Language Tags and Ranges in LDAP [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
Notes: The last two have no language tag options. The x-foobar option
is fictious and used for example purposes.
@ -249,13 +240,13 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
type or its subtypes and contains each of the presented (and possibly
other) options is to be matched.
Thus for example a filter of an equality match of type
Thus, for example, a filter of an equality match of type
"name;lang-en-US" and assertion value "Billy Ray", against the
following directory entry
following directory entry:
dn: SN=Ray,DC=example,DC=com
objectclass: top DOES NOT MATCH (wrong type)
objectclass: person DOES NOT MATCH (wrong type)
objectclass: extensibleObject DOES NOT MATCH (wrong type)
name;lang-en-US: Billy Ray MATCHES
name;lang-en-US: Billy Bob DOES NOT MATCH (wrong value)
CN;lang-en-US: Billy Ray MATCHES
@ -267,7 +258,7 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
SN: Ray DOES NOT MATCH (no lang-,
wrong value)
(Note that "CN" and "SN" are subtypes of "name".)
Note that "CN" and "SN" are subtypes of "name".
It is noted that providing a language tag option in a search filter
AttributeDescription will filter out desirable values where the tag
@ -276,14 +267,6 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
If the server does not support storing attributes with language tag
options in the DIT, then any assertion which includes a language tag
Zeilenga Language Tags and Ranges in LDAP [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
option will not match as such it is an unrecognized attribute type.
No error would be returned because of this; a presence assertion would
evaluate to FALSE and all other assertions to Undefined.
@ -292,12 +275,20 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
attribute type and the assertion value need match the value in the
directory.
Thus for example a filter of an equality match of type "name" and
assertion value "Billy Ray", against the following directory entry
Thus, for example, a filter of an equality match of type "name" and
dn: SN=Ray,DC=example,DC=net
objectclass: top DOES NOT MATCH (wrong type)
Zeilenga Language Tags and Ranges in LDAP [Page 5]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
assertion value "Billy Ray", against the following directory entry:
dn: SN=Ray,DC=example,DC=com
objectclass: person DOES NOT MATCH (wrong type)
objectclass: extensibleObject DOES NOT MATCH (wrong type)
name;lang-en-US: Billy Ray MATCHES
name;lang-en-US: Billy Bob DOES NOT MATCH (wrong value)
CN;lang-en-US;x-foobar: Billy Ray MATCHES
@ -310,19 +301,20 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
2.3. Requested Attributes in Search
Clients can provide language tag options in AttributeDescription in
the requested attribute list in a search request.
Clients can provide language tag options in each AttributeDescription
in the requested attribute list in a search request.
If language tag options are provided in an attribute description, then
only attributes in a directory entry whose attribute descriptions have
the same attribute type or its subtype and the provided language tags
options are to be returned. Thus if a client requests just the
attribute "name;lang-en", the server would return "name;lang-en" and
the same attribute type or its subtype and contains each of the
presented (and possibly other) language tag options are to be
returned. Thus if a client requests just the attribute
"name;lang-en", the server would return "name;lang-en" and
"CN;lang-en;lang-ja" but not "SN" nor "name;lang-fr".
Clients can provide in the attribute list multiple
AttributeDescription which have the same base attribute type but
different options. For example a client could provide both
AttributeDescriptions which have the same base attribute type but
different options. For example, a client could provide both
"name;lang-en" and "name;lang-fr", and this would permit an attribute
with either language tag option to be returned. Note there would be
no need to provide both "name" and "name;lang-en" since all subtypes
@ -333,13 +325,6 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
include language tag options are to be ignored, just as if they were
unknown attribute types.
Zeilenga Language Tags and Ranges in LDAP [Page 6]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
If a request is made specifying all attributes or an attribute is
requested without providing a language tag option, then all attribute
values regardless of their language tag option are returned.
@ -347,18 +332,24 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
For example, if the client requests a "description" attribute, and a
matching entry contains the following attributes:
Zeilenga Language Tags and Ranges in LDAP [Page 6]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
objectclass: top
objectclass: organization
O: Software GmbH
description: software
description: software products
description;lang-en: software products
description;lang-de: Softwareprodukte
postalAddress: Berlin 8001 Germany
postalAddress;lang-de: Berlin 8001 Deutschland
The server would return:
description: software
description: software products
description;lang-en: software products
description;lang-de: Softwareprodukte
@ -369,11 +360,12 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
a compare request AttributeValueAssertion. This is to be treated by
servers the same as the use of language tag options in a search filter
with an equality match, as described in Section 2.2. If there is no
attribute in the entry with the same subtype and language tag options,
the noSuchAttributeType error will be returned.
attribute in the entry with the same attribute type or its subtype and
and contains each of the presented (or possibly other) language tag
options, the noSuchAttributeType error will be returned.
Thus for example a compare request of type "name" and assertion value
"Johann", against an entry containing the following attributes:
Thus, for example, a compare request of type "name" and assertion
value "Johann", against an entry containing the following attributes:
objectclass: top
objectclass: person
@ -388,14 +380,6 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
would fail with the noSuchAttributeType error.
If the server does not support storing attributes with language tag
Zeilenga Language Tags and Ranges in LDAP [Page 7]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
options in the DIT, then any comparison which includes a language tag
option will always fail to locate an attribute, and
noSuchAttributeType will be returned.
@ -404,25 +388,30 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
2.5. Add Operation
Clients can provide language options in AttributeDescription in
Zeilenga Language Tags and Ranges in LDAP [Page 7]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
attributes of a new entry to be created.
A client can provide multiple attributes with the same attribute type
and value, so long as each attribute has a different set of language
tag options.
For example, the following is a legal request.
For example, the following is a valid request:
dn: CN=John Smith,DC=example,DC=com
objectclass: top
objectclass: person
objectclass: residentialPerson
name: John Smith
CN: John Smith
CN;lang-en: John Smith
SN: Smith
SN;lang-en;lang-en-US: Smith
SN;lang-en: Smith
streetAddress: 1 University Street
streetAddress;lang-en: 1 University Street
streetAddress;lang-en-US: 1 University Street
streetAddress;lang-fr: 1 rue Universite
houseIdentifier;lang-fr: 9e etage
@ -444,14 +433,6 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
"delete", then if the stored values to be deleted have language tag
options, then those language tag options MUST be provided in the
modify operation, and if the stored values to be deleted do not have
Zeilenga Language Tags and Ranges in LDAP [Page 8]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
any language tag option, then no language tag option is to be
provided.
@ -463,6 +444,14 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
3. Use of Language Ranges in LDAP
Zeilenga Language Tags and Ranges in LDAP [Page 8]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
Since the publication of RFC 2596, it has become apparent that there
is a need to provide a mechanism for a client to request attributes
based upon set of language tag options whose tags all begin with the
@ -479,20 +468,10 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
language-range-option = "lang-" [ Language-Tag "-" ]
where the Language-Tag production is as defined in BCP 47 [RFC3066].
This production and those it imports from [RFC2234] are provided here
for convenience:
This production and those it imports from [RFC2234] are provided in
Section 2.1 for convenience.
Language-Tag = Primary-subtag *( "-" Subtag )
Primary-subtag = 1*8ALPHA
Subtag = 1*8(ALPHA / DIGIT)
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
A language range option matches a language tag option if language
A language range option matches a language tag option if the language
range option less the trailing "-" matches exactly the language tag or
if the language range option (including the trailing "-") matches a
prefix of the language tag option. Note that the language range
@ -501,15 +480,9 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
Examples of valid AttributeDescription containing language range
options:
Zeilenga Language Tags and Ranges in LDAP [Page 9]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
givenName;lang-en-
CN;lang-
SN;lang-de-;lang-gem-
O;lang-x-;x-foobar
A language range option is not a tagging option. Attributes cannot be
@ -521,23 +494,32 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
the syntax of the attribute values.
Servers SHOULD support assertion of language ranges for any attribute
which they allow to stored with language tags.
type which they allow to be stored with language tags.
3.1. Search Filter
If a language range option is present in an AttributeDescription in an
Zeilenga Language Tags and Ranges in LDAP [Page 9]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
assertion, then for each entry within scope, the values of each
attribute whose AttributeDescription consists of the same attribute
type or its subtypes and contains a language tag option matching the
language range option are to be returned.
Thus for example a filter of an equality match of type "name;lang-en-"
and assertion value "Billy Ray", against the following directory entry
Thus, for example, a filter of an equality match of type
"name;lang-en-" and assertion value "Billy Ray", against the following
directory entry:
dn: SN=Ray,DC=example,DC=com
objectclass: top DOES NOT MATCH (wrong type)
objectclass: person DOES NOT MATCH (wrong type)
objectclass: extensibleObject DOES NOT MATCH (wrong type)
name;lang-en-US: Billy Ray MATCHES
name;lang-en-US: Billy Bob DOES NOT MATCH (wrong value)
CN;lang-en-US: Billy Ray MATCHES
@ -549,7 +531,7 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
SN: Ray DOES NOT MATCH (no lang-,
wrong value)
(Note that "CN" and "SN" are subtypes of "name".)
Note that "CN" and "SN" are subtypes of "name".
If the server does not support storing attributes with language tag
options in the DIT, then any assertion which includes a language range
@ -558,16 +540,11 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
evaluate to FALSE and all other assertions to Undefined.
Zeilenga Language Tags and Ranges in LDAP [Page 10]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
3.2. Requested Attributes in Search
Clients can provide language range options in AttributeDescription in
the requested attribute list in a search request.
Clients can provide language range options in each
AttributeDescription in the requested attribute list in a search
request.
If a language range option is provided in an attribute description,
then only attributes in a directory entry whose attribute descriptions
@ -578,7 +555,15 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
nor "name;lang-fr".
Clients can provide in the attribute list multiple
AttributeDescription which have the same base attribute type but
AttributeDescriptions which have the same base attribute type but
Zeilenga Language Tags and Ranges in LDAP [Page 10]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
different options. For example a client could provide both
"name;lang-en-" and "name;lang-fr-", and this would permit an
attribute whose type was name or subtype of name and with a language
@ -599,8 +584,9 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
is no attribute in the entry with the same subtype and a matching
language tag option, the noSuchAttributeType error will be returned.
Thus for example a compare request of type "name;lang-" and assertion
value "Johann", against the entry with the following attributes:
Thus, for example, a compare request of type "name;lang-" and
assertion value "Johann", against the entry with the following
attributes:
objectclass: top
objectclass: person
@ -612,14 +598,6 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
range option "lang-" matches any language tag option.)
However, if the client issued a compare request of type "name;lang-de"
Zeilenga Language Tags and Ranges in LDAP [Page 11]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
and assertion value "Sibelius" against the above entry, the request
would fail with the noSuchAttributeType error.
@ -632,13 +610,22 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
4. Discovering Language Option Support
A server SHOULD indicate that it supports storing attributes with
language tag options in the DIT by publishing OID.TDB as a value of
the supportedFeatures [FEATURES] attribute in the root DSE.
language tag options in the DIT by publishing 1.3.6.1.4.1.4203.1.5.4
as a value of the "supportedFeatures" [FEATURES] attribute in the root
Zeilenga Language Tags and Ranges in LDAP [Page 11]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
DSE.
A server SHOULD indicate that it supports language range matching of
attributes with language tag options stored in the DIT by publishing
OID.TDB as a value of the supportedFeatures [FEATURES] attribute in
the root DSE.
1.3.6.1.4.1.4203.1.5.5 as a value of the "supportedFeatures"
[FEATURES] attribute in the root DSE.
A server MAY restrict use of language tag options to a subset of the
attribute types it recognizes. This document does not define a
@ -653,51 +640,96 @@ INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
fulfill the user's language needed. These options are not known to
raise specific security considerations. However, the reader should
consider general directory security issues detailed in the LDAP
technical specification [Roadmap].
technical specification [RFC3377].
6. Acknowledgments
6. IANA Considerations
This document is a revision of RFC 2596 by Mark Wahl and Tim Howes.
RFC 2596 was a product of the IETF ASID and LDAPEXT working groups.
The OIDs 1.3.6.1.4.1.4203.1.5.4 and 1.3.6.1.4.1.4203.1.5.5 identify
the features described above. These OIDs were assigned [ASSIGN] by
OpenLDAP Foundation, under its IANA-assigned private enterprise
allocation [PRIVATE], for use in this specification.
This document borrows from a number of IETF documents including BCP
47.
Registration of these protocol mechanisms [RFC3383] is requested.
Subject: Request for LDAP Protocol Mechanism Registration
7. Normative References
Object Identifier: 1.3.6.1.4.1.4203.1.5.4
Description: Language Tag Options
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Object Identifier: 1.3.6.1.4.1.4203.1.5.5
Description: Language Range Options
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Feature
Specification: RFCxxxx
Author/Change Controller: IESG
Zeilenga Language Tags and Ranges in LDAP [Page 12]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
Comments: none
7. Acknowledgments
This document is a revision of RFC 2596 by Mark Wahl and Tim Howes.
RFC 2596 was a product of the IETF ASID and LDAPEXT working groups.
This document also borrows from a number of IETF documents including
BCP 47 by H. Alvestrand.
8. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax
[RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[RFC3066] Alvestrand, H., "Tags for the Identification of Languages",
BCP 47 (also RFC 3066), January 2001.
[Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road
Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
progress.
[Models] K. Zeilenga (editor), "LDAP: Directory Information Models",
draft-ietf-ldapbis-models-xx.txt, a work in progress.
[RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[FEATURES] K. Zeilenga, "Feature Discovery in LDAP",
draft-zeilenga-ldap-features-xx.txt (a work in progress).
8. Informative References
9. Informative References
[X.501] "The Directory: Models", ITU-T Recommendation X.501, 1997.
[X.501] ITU, "The Directory: Models", ITU-T Recommendation X.501,
1997.
[RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
RFC 3383), September 2002.
[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 Language Tags and Ranges in LDAP [Page 13]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
Appendix A. Differences from RFC 2596
@ -719,19 +751,13 @@ Appendix B. Differences from X.500(1997)
matches a value in the directory without a language code.
b) LDAP references BCP 47 [RFC3066], which allows for IANA
registration of new tags as well as unregistered tags.
c) LDAP supports language ranges.
c) LDAP supports language ranges (new in this revision).
d) LDAP does not allow language tags (and ranges) in distinguished
names.
e) X.500 describes subschema administration procedures to allow
language codes to be associated with particular attributes types.
Zeilenga Language Tags and Ranges in LDAP [Page 13]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-01.txt 1 March 2002
Copyright 2002, The Internet Society. All Rights Reserved.
This document and translations of it may be copied and furnished to
@ -754,6 +780,14 @@ Copyright 2002, The Internet Society. All Rights Reserved.
"AS IS" basis and THE AUTHORS, 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
Zeilenga Language Tags and Ranges in LDAP [Page 14]
INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-04.txt 9 December 2002
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
@ -783,5 +817,27 @@ Copyright 2002, The Internet Society. All Rights Reserved.
Zeilenga Language Tags and Ranges in LDAP [Page 14]
Zeilenga Language Tags and Ranges in LDAP [Page 15]

184
doc/drafts/draft-zeilenga-ldap-t-f-xx.txt
View file

@ -6,12 +6,12 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 3 May 2003
Expires in six months 25 October 2003
LDAP Absolute True and False Filters
<draft-zeilenga-ldap-t-f-05.txt>
<draft-zeilenga-ldap-t-f-07.txt>
Status of this Memo
@ -22,9 +22,9 @@ 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 Working Group
mailing list <ldapext@ietf.org>. Please send editorial comments
directly to the author <Kurt@OpenLDAP.org>.
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>.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
@ -39,10 +39,10 @@ Status of this Memo
Internet-Draft Shadow Directories can be accessed at
<http://www.ietf.org/shadow.html>.
Copyright 2003, The Internet Society. All Rights Reserved.
Copyright (C) The Internet Society (2003). All Rights Reserved.
Please see the Copyright section near the end of this document for
more information.
Please see the Full Copyright section near the end of this document
for more information.
Abstract
@ -57,10 +57,10 @@ Abstract
Zeilenga LDAP True & False Filters [Page 1]
INTERNET-DRAFT draft-zeilenga-ldap-t-f-05.txt 3 May 2003
INTERNET-DRAFT draft-zeilenga-ldap-t-f-07.txt 25 October 2003
1. Background and Intended Use
1. Background
The X.500 Directory Access Protocol (DAP) [X.511] supports absolute
True and False assertions. An 'and' filter with zero elements always
@ -69,17 +69,21 @@ INTERNET-DRAFT draft-zeilenga-ldap-t-f-05.txt 3 May 2003
specific Entries (DSEs) which do not necessarily have 'objectClass'
attributes. That is, where "(objectClass=*)" may evaluate to False.
While LDAPv2 [RFC1777] placed no restriction on the number of elements
in 'and' and 'or' filter sets, the LDAPv2 string representation
[RFC1960] could not represent empty 'and' and 'or' filter sets. Due
to this, absolute True or False filters were (unfortunately)
eliminated from LDAPv3 [RFC3377].
While LDAPv2 [RFC1777][RFC3494] placed no restriction on the number of
elements in 'and' and 'or' filter sets, the LDAPv2 string
representation [RFC1960] could not represent empty 'and' and 'or'
filter sets. Due to this, absolute True or False filters were
(unfortunately) eliminated from LDAPv3 [RFC3377].
This documents extends LDAPv3 to support absolute True and False
matches by allowing empty 'and' and 'or' in Search filters [RFC2251]
and extends the filter string representation [RFC2254] to allow empty
filter lists.
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].
@ -97,25 +101,26 @@ INTERNET-DRAFT draft-zeilenga-ldap-t-f-05.txt 3 May 2003
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 [FEATURES]
attribute in the root DSE.
(OID) 1.3.6.1.4.1.4203.1.5.3 as a value of the 'supportedFeatures'
[FEATURES] attribute in the root DSE.
Clients supporting this feature SHOULD NOT use the feature unless they
have knowledge the server supports it.
Zeilenga LDAP True & False Filters [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-t-f-07.txt 25 October 2003
3. Security Considerations
The (re)introduction of absolute True and False filters is not
believed to raise any new security considerations.
Zeilenga LDAP True & False Filters [Page 2]
INTERNET-DRAFT draft-zeilenga-ldap-t-f-05.txt 3 May 2003
Implementors of this (or any) LDAPv3 extension should be familiar with
general LDAPv3 security considerations [RFC3377].
@ -135,7 +140,7 @@ INTERNET-DRAFT draft-zeilenga-ldap-t-f-05.txt 3 May 2003
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
Usage: Feature
Specification: RFCxxxx
Specification: RFC XXXX
Author/Change Controller: IESG
Comments: none
@ -149,58 +154,102 @@ INTERNET-DRAFT draft-zeilenga-ldap-t-f-05.txt 3 May 2003
6. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[RFC2254] T. Howes, "A String Representation of LDAP Search Filters",
RFC 2254, December 1997.
[RFC2254] Howes, T., "A String Representation of LDAP Search
Filters", RFC 2254, December 1997.
[RFC3377] J. Hodges, R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[FEATURES] K. Zeilenga, "Feature Discovery in LDAP",
draft-zeilenga-ldap-features-xx.txt (a work in progress).
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Zeilenga LDAP True & False Filters [Page 3]
INTERNET-DRAFT draft-zeilenga-ldap-t-f-05.txt 3 May 2003
INTERNET-DRAFT draft-zeilenga-ldap-t-f-07.txt 25 October 2003
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[FEATURES] Zeilenga, K., "Feature Discovery in LDAP",
draft-zeilenga-ldap-features-xx.txt, a work in progress.
7. Informative References
[RFC1777] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory
Access Protocol", RFC 1777, March 1995.
[RFC1777] Yeong, W., Howes, T., and S. Kille, "Lightweight
Directory Access Protocol", RFC 1777, March 1995.
[RFC1960] T. Howes, "A String Representation of LDAP Search Filters",
RFC 1960, June 1996.
[RFC1960] Howes, T., "A String Representation of LDAP Search
Filters", RFC 1960, June 1996.
[RFC3383] K. Zeilenga, "IANA Considerations for LDAP", BCP 64 (also
RFC 3383), September 2002.
[RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
(also RFC 3383), September 2002.
[X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts,
Models and Service", 1993.
[RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol
version 2 (LDAPv2) to Historic Status", RFC 3494, March
2003.
[X.511] ITU-T Rec. X.511, "The Directory: Abstract Service
Definition", 1993.
[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).
[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
http://www.openldap.org/foundation/oid-delegate.txt.
[X.501] International Telecommunication Union -
Telecommunication Standardization Sector, "The Directory
-- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
[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.
[PRIVATE] IANA, "Private Enterprise Numbers",
http://www.iana.org/assignments/enterprise-numbers.
Copyright 2003, The Internet Society. All Rights Reserved.
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
Zeilenga LDAP True & False Filters [Page 4]
INTERNET-DRAFT draft-zeilenga-ldap-t-f-07.txt 25 October 2003
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
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
or assist in its implmentation 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
@ -211,17 +260,24 @@ Copyright 2003, The Internet Society. All Rights Reserved.
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 AUTHORS, 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.
Zeilenga LDAP True & False Filters [Page 4]
Zeilenga LDAP True & False Filters [Page 5]

1123
doc/drafts/draft-zeilenga-ldap-user-schema-xx.txt
View file

File diff suppressed because it is too large Load diff

192
doc/drafts/draft-zeilenga-ldap-uuid-xx.txt
View file

@ -6,11 +6,11 @@
INTERNET-DRAFT Kurt D. Zeilenga
Intended Category: Standard Track OpenLDAP Foundation
Expires in six months 11 May 2003
Expires in six months 25 October 2003
The LDAP entryUUID operational attribute
<draft-zeilenga-ldap-uuid-00.txt>
<draft-zeilenga-ldap-uuid-02.txt>
Status of this Memo
@ -21,9 +21,9 @@ 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 Extension Working Group
mailing list <ldapext@ietf.org>. Please send editorial comments
directly to the author <Kurt@OpenLDAP.org>.
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>.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
@ -55,9 +55,9 @@ Abstract
Zeilenga draft-zeilenga-ldap-uuid-00 [Page 1]
Zeilenga draft-zeilenga-ldap-uuid-02 [Page 1]
INTERNET-DRAFT LDAP entryUUID 11 May 2003
INTERNET-DRAFT LDAP entryUUID 25 October 2003
1. Background and Intended Use
@ -69,11 +69,11 @@ INTERNET-DRAFT LDAP entryUUID 11 May 2003
DN which previously identified another (now renamed or deleted)
object.
This document describes the 'entryUUID' operational attribute holds
the Universally Unique Identifier (UUID) [ISO11578] assigned to the
object by the server. Clients may use this attribute to distinguish
objects identified by a distinguished name or to locate an object
after renaming.
This document describes the 'entryUUID' operational attribute which
holds the Universally Unique Identifier (UUID) [ISO11578] assigned to
the object by the server. Clients may use this attribute to
distinguish objects identified by a distinguished name or to locate an
object after renaming.
This document defines the UUID syntax, the 'uuidMatch' and
'uuidOrderingMatch' matching rules, the 'entryUUID' attribute type.
@ -91,32 +91,42 @@ INTERNET-DRAFT LDAP entryUUID 11 May 2003
2.1 UUID Syntax
A Universally Unique Identifier (UUID) [ISO11578] is a 16-octet value
which identifies object. The ASN.1 [X.690] type UUID is defined to
represent UUIDs.
A Universally Unique Identifier (UUID) [ISO11578] is a 16-octet
(128-bit) value which identifies an object. The ASN.1 [X.690] type
UUID is defined to represent UUIDs.
UUID ::= OCTET STRING{16} -- constrained to an UUID [ISO 11578]
UUID ::= OCTET STRING (SIZE(16))
-- constrained to an UUID [ISO 11578]
In LDAP, values of the UUID are encoded using the string
representation described in [ISO11578]. For example,
597ae2f6-16a6-1027-98f4-d28b5365dc14.
In LDAP, values of the UUID type are encoded using the [ASCII]
character string representation described in [ISO11578]. For example,
"597ae2f6-16a6-1027-98f4-d28b5365dc14".
The following is a LDAP syntax description [RFC2252] suitable for
publication in the subschema.
( IANA-ASSIGNED-OID.1 DESC 'UUID' )
Zeilenga draft-zeilenga-ldap-uuid-02 [Page 2]
INTERNET-DRAFT LDAP entryUUID 25 October 2003
2.2 'uuidMatch' Matching Rule
The 'uuidMatch' matching rule compares an asserted UUID with a stored
UUID for equality. Its semantics are same as octetStringMatch
UUID for equality. Its semantics are same as the octetStringMatch
[X.520][RFC2252] 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.
Zeilenga draft-zeilenga-ldap-uuid-00 [Page 2]
INTERNET-DRAFT LDAP entryUUID 11 May 2003
[X.520][RFC2252].
The following is a LDAP matching rule description [RFC2252] suitable
for publication in the subschema.
( IANA-ASSIGNED-OID.2 NAME 'uuidMatch'
SYNTAX IANA-ASSIGNED-OID.1 )
@ -125,22 +135,43 @@ INTERNET-DRAFT LDAP entryUUID 11 May 2003
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
octetStringOrderingMatch [X.520][RFC2252].
with a stored UUID for ordering. Its semantics are the same as the
octetStringOrderingMatch [X.520][RFC2252] 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 [RFC2252] suitable
for publication in the subschema.
( IANA-ASSIGNED-OID.3 NAME 'uuidMatch'
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
The 'entryUUID' operational attribute provides the Universally Unique
Identifier (UUID) [ISO11578] assigned to the entry.
The following is a LDAP attribute type description [RFC2252] suitable
for publication in the subschema.
( IANA-ASSIGNED-OID.4 NAME 'entryUUID'
DESC 'UUID of the entry'
EQUALITY uuidMatch
ORDERING uuidOrderingMatch
Zeilenga draft-zeilenga-ldap-uuid-02 [Page 3]
INTERNET-DRAFT LDAP entryUUID 25 October 2003
SYNTAX IANA-ASSIGNED-OID.1
SINGLE-VALUE
NO-USER-MODIFICATION
@ -164,14 +195,6 @@ INTERNET-DRAFT LDAP entryUUID 11 May 2003
4.1. Object Identifier Registration
It is requested that IANA register upon Standards Action an LDAP
Zeilenga draft-zeilenga-ldap-uuid-00 [Page 3]
INTERNET-DRAFT LDAP entryUUID 11 May 2003
Object Identifier for use in this technical specification.
Subject: Request for LDAP OID Registration
@ -198,6 +221,13 @@ INTERNET-DRAFT LDAP entryUUID 11 May 2003
Author/Change Controller: IESG
Zeilenga draft-zeilenga-ldap-uuid-02 [Page 4]
INTERNET-DRAFT LDAP entryUUID 25 October 2003
4.3. Registration of the uuidOrderingMatch descriptor
It is requested that IANA register upon Standards Action the LDAP
@ -220,14 +250,6 @@ INTERNET-DRAFT LDAP entryUUID 11 May 2003
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): entryUUID
Zeilenga draft-zeilenga-ldap-uuid-00 [Page 4]
INTERNET-DRAFT LDAP entryUUID 11 May 2003
Object Identifier: IANA-ASSIGNED-OID.4
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
@ -239,7 +261,8 @@ INTERNET-DRAFT LDAP entryUUID 11 May 2003
5. Acknowledgments
This document is based upon discussions in the LDAP Update and
Duplication Protocols (LDUP) WG.
Duplication Protocols (LDUP) WG. Members of the concluded LDAP
Extensions (LDAPEXT) Working Group provided review.
6. Author's Address
@ -254,6 +277,13 @@ INTERNET-DRAFT LDAP entryUUID 11 May 2003
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14 (also RFC 2119), March 1997.
Zeilenga draft-zeilenga-ldap-uuid-02 [Page 5]
INTERNET-DRAFT LDAP entryUUID 25 October 2003
[RFC2252] Wahl, M., A. Coulbeck, T. Howes, and S. Kille,
"Lightweight Directory Access Protocol (v3): Attribute
Syntax Definitions", RFC 2252, December 1997.
@ -266,6 +296,9 @@ INTERNET-DRAFT LDAP entryUUID 11 May 2003
"Information technology - Open Systems Interconnection -
Remote Procedure Call", ISO/IEC 11578:1996.
[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).
@ -276,14 +309,6 @@ INTERNET-DRAFT LDAP entryUUID 11 May 2003
ISO/IEC 9594-6:1994).
[X.680] International Telecommunication Union -
Zeilenga draft-zeilenga-ldap-uuid-00 [Page 5]
INTERNET-DRAFT LDAP entryUUID 11 May 2003
Telecommunication Standardization Sector, "Abstract
Syntax Notation One (ASN.1) - Specification of Basic
Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
@ -294,16 +319,27 @@ INTERNET-DRAFT LDAP entryUUID 11 May 2003
[RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64
(also RFC 3383), September 2002.
[UUIDinfo] The Open Group, "Universally Unique Identifier" section
of "CDE 1.1: Remote Procedure Calls",
<http://www.opengroup.org/onlinepubs/9629399/apdxa.htm>,
April 1997.
[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.
Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any
Zeilenga draft-zeilenga-ldap-uuid-02 [Page 6]
INTERNET-DRAFT LDAP entryUUID 25 October 2003
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
@ -332,14 +368,6 @@ Full Copyright
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 implmentation may be prepared, copied, published and
Zeilenga draft-zeilenga-ldap-uuid-00 [Page 6]
INTERNET-DRAFT LDAP entryUUID 11 May 2003
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
@ -363,33 +391,5 @@ INTERNET-DRAFT LDAP entryUUID 11 May 2003
Zeilenga draft-zeilenga-ldap-uuid-00 [Page 7]
Zeilenga draft-zeilenga-ldap-uuid-02 [Page 7]

1011
doc/drafts/draft-zeilenga-ldapext-vlv-xx.txt
View file

File diff suppressed because it is too large Load diff

104
doc/man/man5/slapd.access.5
View file

@ -53,7 +53,9 @@ directives of the first backend (and any global directives) are
used.
.LP
Arguments that should be replaced by actual text are shown in
brackets <>. The structure of the access control directives is
brackets <>.
.SH THE ACCESS DIRECTIVE
The structure of the access control directives is
.TP
.B access to <what> "[ by <who> <access> [ <control> ] ]+"
Grant access (specified by
@ -62,7 +64,7 @@ to a set of entries and/or attributes (specified by
.BR <what> )
by one or more requestors (specified by
.BR <who> ).
.LP
.SH THE <WHAT> FIELD
The field
.BR <what>
specifies the entity the access control directive applies to.
@ -140,7 +142,7 @@ the provided value is used as a regular expression pattern.
The dn, filter, and attrs statements are additive; they can be used in sequence
to select entities the access rule applies to based on naming context,
value and attribute type simultaneously.
.LP
.SH THE <WHO> FIELD
The field
.B <who>
indicates whom the access rules apply to.
@ -344,7 +346,7 @@ The statements
and
.BR sasl_ssf=<n>
set the required Security Strength Factor (ssf) required to grant access.
.LP
.SH THE <ACCESS> FIELD
The field
.B <access> ::= [self]{<level>|<priv>}
determines the access level or the specific access privileges the
@ -470,6 +472,100 @@ or the (even more silly) example
.LP
which grants everybody search and compare privileges, and adds read
privileges to authenticated clients.
.SH OPERATION REQUIREMENTS
Operations require different privileges on different portions of entries.
The following summary applies to primary database backends such as
the LDBM, BDB, and HDB backends. Requirements for other backends may
(and often do) differ.
.LP
The
.B add
operation requires
.B write (=w)
privileges on the pseudo-attribute
.B entry
of the entry being added, and
.B write (=w)
privileges on the pseudo-attribute
.B children
of the entry's parent.
.LP
The
.B bind
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
operation requires
.B write (=w)
privileges on the pseudo-attribute
.B entry
of the entry being deleted, and
.B write (=w)
privileges on the
.B children
pseudo-attribute of the entry's parent.
.LP
The
.B modify
operation requires
.B write (=w)
privileges on the attibutes being modified.
.LP
The
.B modrdn
operation requires
.B write (=w)
privileges on the pseudo-attribute
.B entry
of the entry whose relative DN is being modified,
.B write (=w)
privileges on the pseudo-attribute
.B children
of the old and new entry's parents, and
.B write (=w)
privileges on the attributes that are present in the new relative DN.
.B Write (=w)
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
operation, for each entry, requires
.B search (=s)
privileges on the attributes that are defined in the filter.
Then, the resulting entries are tested for
.B read (=r)
privileges on the pseudo-attribute
.B entry
(for read access to the entry itself)
and for
.B read (=r)
access on each value of each attribute that is requested.
Also, for each
.B referral
object used in generating continuation references, the operation requires
.B read (=r)
access on the pseudo-attribute
.B entry
(for read access to the referral object itself),
as well as
.B read (=r)
access to the attribute holding the referral information
(generally the
.B ref
attribute).
.SH CAVEATS
It is strongly recommended to explicitly use the most appropriate
DN

15
doc/man/man5/slapd.conf.5
View file

@ -120,8 +120,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'.
RFC2251 reserves options beginning with `x-' for private experiments.
Other options should be registered with IANA, see RFC3383 section 3.4.
RFC 2251 reserves options beginning with `x-' for private experiments.
Other options should be registered with IANA, see RFC 3383 section 3.4.
OpenLDAP also has the `binary' option built in, but this is a transfer
option, not a tagging option.
.HP
@ -514,7 +514,7 @@ value "oid.xx" will be used.
.B password-hash <hash>
This option sets the hash to be used in generation of user
passwords, stored in userPassword, during processing of
LDAP Password Modify Extended Operations (RFC 3052).
LDAP Password Modify Extended Operations (RFC 3062).
The <hash> must be one of
.BR {SSHA} ,
.BR {SHA} ,
@ -1208,6 +1208,10 @@ The
parameter specifies the DN in the consumer site
which is allowed to make changes to the replica.
The DN should have read/write access to the replica database.
Generally, this DN
.I should not
be the same as the
.BR rootdn .
A
.B bindmethod
of
@ -1247,7 +1251,10 @@ This option is only applicable in a slave
It specifies the DN permitted to update (subject to access controls)
the replica (typically, this is the DN
.BR slurpd (8)
binds to update the replica).
binds to update the replica). Generally, this DN
.I should not
be the same as the
.BR rootdn .
.TP
.B updateref <url>
Specify the referral to pass back when

12
include/lber.h
View file

@ -582,16 +582,16 @@ LBER_F( struct berval * )
ber_bvdup LDAP_P((
struct berval *src ));
LBER_F( struct berval * )
ber_str2bv LDAP_P((
LDAP_CONST char *, ber_len_t len, int dup, struct berval *bv));
LBER_F( struct berval * )
ber_mem2bv LDAP_P((
LDAP_CONST char *, ber_len_t len, int dup, struct berval *bv));
#define ber_bvstr(a) ber_str2bv(a, 0, 0, NULL)
#define ber_bvstrdup(a) ber_str2bv(a, 0, 1, NULL)
LBER_F( struct berval * )
ber_str2bv LDAP_P((
LDAP_CONST char *, ber_len_t len, int dup, struct berval *bv));
#define ber_bvstr(a) ((ber_str2bv)((a), 0, 0, NULL))
#define ber_bvstrdup(a) ((ber_str2bv)((a), 0, 1, NULL))
LBER_F( char * )
ber_strdup LDAP_P((

190
include/ldap.h
View file

@ -66,6 +66,7 @@ LDAP_BEGIN_DECL
/* #define LDAP_API_OPERATION_SESSION_SAFE 1 */
#endif
#define LDAP_PORT 389 /* ldap:/// default LDAP port */
#define LDAPS_PORT 636 /* ldaps:/// default LDAP over TLS port */
@ -208,23 +209,28 @@ typedef struct ldapcontrol {
#define LDAP_CONTROL_SYNC_DONE "1.3.6.1.4.1.4203.666.5.8"
#define LDAP_SYNC_INFO "1.3.6.1.4.1.4203.666.10.2"
#define LDAP_SYNC_REFRESH_PRESENTS 0
#define LDAP_SYNC_REFRESH_DELETES 1
#define LDAP_SYNC_NONE 0x00
#define LDAP_SYNC_REFRESH_ONLY 0x01
#define LDAP_SYNC_RESERVED 0x02
#define LDAP_SYNC_REFRESH_AND_PERSIST 0x03
#define LDAP_SYNC_REFRESH_PRESENTS 0
#define LDAP_SYNC_REFRESH_DELETES 1
#define LDAP_TAG_SYNC_NEW_COOKIE ((ber_tag_t) 0x80U)
#define LDAP_TAG_SYNC_REFRESH_DELETE ((ber_tag_t) 0xa1U)
#define LDAP_TAG_SYNC_REFRESH_PRESENT ((ber_tag_t) 0xa2U)
#define LDAP_TAG_SYNC_ID_SET ((ber_tag_t) 0xa3U)
#define LDAP_TAG_SYNC_COOKIE ((ber_tag_t) 0x04U)
#define LDAP_TAG_REFRESHDELETES ((ber_tag_t) 0x01U)
#define LDAP_TAG_REFRESHDONE ((ber_tag_t) 0x01U)
#define LDAP_TAG_RELOAD_HINT ((ber_tag_t) 0x01U)
#define LDAP_TAG_SYNC_COOKIE ((ber_tag_t) 0x04U)
#define LDAP_TAG_REFRESHDELETES ((ber_tag_t) 0x01U)
#define LDAP_TAG_REFRESHDONE ((ber_tag_t) 0x01U)
#define LDAP_TAG_RELOAD_HINT ((ber_tag_t) 0x01U)
#define LDAP_SYNC_PRESENT 0
#define LDAP_SYNC_ADD 1
#define LDAP_SYNC_MODIFY 2
#define LDAP_SYNC_DELETE 3
#define LDAP_SYNC_PRESENT 0
#define LDAP_SYNC_ADD 1
#define LDAP_SYNC_MODIFY 2
#define LDAP_SYNC_DELETE 3
#define LDAP_CONTROL_SORTREQUEST "1.2.840.113556.1.4.473"
#define LDAP_CONTROL_SORTRESPONSE "1.2.840.113556.1.4.474"
@ -448,52 +454,51 @@ typedef struct ldapcontrol {
#define LDAP_OTHER 0x50
#define LDAP_API_ERROR(n) LDAP_RANGE((n),0x51,0x61) /* 81-97 */
#define LDAP_API_RESULT(n) (((n) == LDAP_SUCCESS) || \
LDAP_RANGE((n),0x51,0x61)) /* 0,81-97 */
/* Expermental result codes */
#define LDAP_X_ERROR(n) LDAP_RANGE((n),0x1000,0x3FFF) /* experimental */
#define LDAP_PVT_ERROR(n) LDAP_RANGE((n),0x4000,0xFFFF) /* private use */
/* reserved for APIs */
#define LDAP_SERVER_DOWN 0x51
#define LDAP_LOCAL_ERROR 0x52
#define LDAP_ENCODING_ERROR 0x53
#define LDAP_DECODING_ERROR 0x54
#define LDAP_TIMEOUT 0x55
#define LDAP_AUTH_UNKNOWN 0x56
#define LDAP_FILTER_ERROR 0x57
#define LDAP_USER_CANCELLED 0x58
#define LDAP_PARAM_ERROR 0x59
#define LDAP_NO_MEMORY 0x5a
#define LDAP_SYNC_RESOURCES_EXHAUSTED 0x4100
#define LDAP_SYNC_SECURITY_VIOLATION 0x4101
#define LDAP_SYNC_INVALID_COOKIE 0x4102
#define LDAP_SYNC_UNSUPPORTED_SCHEME 0x4103
#define LDAP_SYNC_CLIENT_DISCONNECT 0x4104
#define LDAP_SYNC_RELOAD_REQUIRED 0x4105
/* used but not reserved for APIs */
#define LDAP_CONNECT_ERROR 0x5b /* draft-ietf-ldap-c-api-xx */
#define LDAP_NOT_SUPPORTED 0x5c /* draft-ietf-ldap-c-api-xx */
#define LDAP_CONTROL_NOT_FOUND 0x5d /* draft-ietf-ldap-c-api-xx */
#define LDAP_NO_RESULTS_RETURNED 0x5e /* draft-ietf-ldap-c-api-xx */
#define LDAP_MORE_RESULTS_TO_RETURN 0x5f /* draft-ietf-ldap-c-api-xx */
#define LDAP_CLIENT_LOOP 0x60 /* draft-ietf-ldap-c-api-xx */
#define LDAP_REFERRAL_LIMIT_EXCEEDED 0x61 /* draft-ietf-ldap-c-api-xx */
#define LDAP_ASSERTION_FAILED 0x410f
#define LDAP_SYNC_RESOURCES_EXHAUSTED 0x100
#define LDAP_SYNC_SECURITY_VIOLATION 0x101
#define LDAP_SYNC_INVALID_COOKIE 0x102
#define LDAP_SYNC_UNSUPPORTED_SCHEME 0x103
#define LDAP_SYNC_CLIENT_DISCONNECT 0x104
#define LDAP_SYNC_RELOAD_REQUIRED 0x105
#define LDAP_ASSERTION_FAILED 0x10f
#ifdef LDAP_EXOP_X_CANCEL
/* resultCode for Cancel Response */
#define LDAP_CANCELLED 0x110
#define LDAP_NO_SUCH_OPERATION 0x111
#define LDAP_TOO_LATE 0x112
#define LDAP_CANNOT_CANCEL 0x113
#endif
#define LDAP_CANCELLED 0x4110
#define LDAP_NO_SUCH_OPERATION 0x4111
#define LDAP_TOO_LATE 0x4112
#define LDAP_CANNOT_CANCEL 0x4113
/* API Error Codes
*
* Based on draft-ietf-ldap-c-api-xx
* but with new (negative) codes
*/
#define LDAP_API_ERROR(n) ((n)<0)
#define LDAP_API_RESULT(n) ((n)<=0)
#define LDAP_SERVER_DOWN (-1)
#define LDAP_LOCAL_ERROR (-2)
#define LDAP_ENCODING_ERROR (-3)
#define LDAP_DECODING_ERROR (-4)
#define LDAP_TIMEOUT (-5)
#define LDAP_AUTH_UNKNOWN (-6)
#define LDAP_FILTER_ERROR (-7)
#define LDAP_USER_CANCELLED (-8)
#define LDAP_PARAM_ERROR (-9)
#define LDAP_NO_MEMORY (-10)
#define LDAP_CONNECT_ERROR (-11)
#define LDAP_NOT_SUPPORTED (-12)
#define LDAP_CONTROL_NOT_FOUND (-13)
#define LDAP_NO_RESULTS_RETURNED (-14)
#define LDAP_MORE_RESULTS_TO_RETURN (-15)
#define LDAP_CLIENT_LOOP (-16)
#define LDAP_REFERRAL_LIMIT_EXCEEDED (-17)
/* LDAP SYNC request type */
#define LDAP_SYNC_NONE 0x00
#define LDAP_SYNC_REFRESH_ONLY 0x01
#define LDAP_SYNC_REFRESH_AND_PERSIST 0x03
/*
* This structure represents both ldap messages and ldap responses.
@ -693,10 +698,12 @@ ldap_abandon_ext LDAP_P((
LDAPControl **serverctrls,
LDAPControl **clientctrls ));
#ifdef LDAP_DEPRECATED
LDAP_F( int )
ldap_abandon LDAP_P(( /* deprecated */
LDAP *ld,
int msgid ));
#endif
/*
@ -719,6 +726,7 @@ ldap_add_ext_s LDAP_P((
LDAPControl **serverctrls,
LDAPControl **clientctrls ));
#ifdef LDAP_DEPRECATED
LDAP_F( int )
ldap_add LDAP_P(( /* deprecated */
LDAP *ld,
@ -730,6 +738,7 @@ ldap_add_s LDAP_P(( /* deprecated */
LDAP *ld,
LDAP_CONST char *dn,
LDAPMod **attrs ));
#endif
/*
@ -792,6 +801,7 @@ ldap_parse_sasl_bind_result LDAP_P((
struct berval **servercredp,
int freeit ));
#ifdef LDAP_DEPRECATED
/*
* in bind.c:
* (deprecated)
@ -814,13 +824,13 @@ ldap_bind_s LDAP_P(( /* deprecated */
* in sbind.c:
*/
LDAP_F( int )
ldap_simple_bind LDAP_P((
ldap_simple_bind LDAP_P(( /* deprecated */
LDAP *ld,
LDAP_CONST char *who,
LDAP_CONST char *passwd ));
LDAP_F( int )
ldap_simple_bind_s LDAP_P((
ldap_simple_bind_s LDAP_P(( /* deprecated */
LDAP *ld,
LDAP_CONST char *who,
LDAP_CONST char *passwd ));
@ -854,6 +864,7 @@ LDAP_F( int )
ldap_kerberos_bind2_s LDAP_P(( /* deprecated */
LDAP *ld,
LDAP_CONST char *who ));
#endif
/*
@ -896,6 +907,7 @@ ldap_compare_ext_s LDAP_P((
LDAPControl **serverctrls,
LDAPControl **clientctrls ));
#ifdef LDAP_DEPRECATED
LDAP_F( int )
ldap_compare LDAP_P(( /* deprecated */
LDAP *ld,
@ -909,6 +921,7 @@ ldap_compare_s LDAP_P(( /* deprecated */
LDAP_CONST char *dn,
LDAP_CONST char *attr,
LDAP_CONST char *value ));
#endif
/*
@ -929,6 +942,7 @@ ldap_delete_ext_s LDAP_P((
LDAPControl **serverctrls,
LDAPControl **clientctrls ));
#ifdef LDAP_DEPRECATED
LDAP_F( int )
ldap_delete LDAP_P(( /* deprecated */
LDAP *ld,
@ -938,6 +952,7 @@ LDAP_F( int )
ldap_delete_s LDAP_P(( /* deprecated */
LDAP *ld,
LDAP_CONST char *dn ));
#endif
/*
@ -958,6 +973,7 @@ LDAP_F( char * )
ldap_err2string LDAP_P((
int err ));
#ifdef LDAP_DEPRECATED
LDAP_F( int )
ldap_result2error LDAP_P(( /* deprecated */
LDAP *ld,
@ -968,6 +984,7 @@ LDAP_F( void )
ldap_perror LDAP_P(( /* deprecated */
LDAP *ld,
LDAP_CONST char *s ));
#endif
/*
@ -990,6 +1007,7 @@ ldap_modify_ext_s LDAP_P((
LDAPControl **serverctrls,
LDAPControl **clientctrls ));
#ifdef LDAP_DEPRECATED
LDAP_F( int )
ldap_modify LDAP_P(( /* deprecated */
LDAP *ld,
@ -1001,6 +1019,7 @@ ldap_modify_s LDAP_P(( /* deprecated */
LDAP *ld,
LDAP_CONST char *dn,
LDAPMod **mods ));
#endif
/*
@ -1027,6 +1046,7 @@ ldap_rename_s LDAP_P((
LDAPControl **sctrls,
LDAPControl **cctrls ));
#ifdef LDAP_DEPRECATED
LDAP_F( int )
ldap_rename2 LDAP_P(( /* deprecated */
LDAP *ld,
@ -1068,13 +1088,15 @@ ldap_modrdn2_s LDAP_P(( /* deprecated */
LDAP_CONST char *dn,
LDAP_CONST char *newrdn,
int deleteoldrdn));
#endif
/*
* in open.c:
*/
#ifdef LDAP_DEPRECATED
LDAP_F( LDAP * )
ldap_init LDAP_P((
ldap_init LDAP_P(( /* deprecated */
LDAP_CONST char *host,
int port ));
@ -1082,6 +1104,7 @@ LDAP_F( LDAP * )
ldap_open LDAP_P(( /* deprecated */
LDAP_CONST char *host,
int port ));
#endif
LDAP_F( int )
ldap_create LDAP_P((
@ -1353,6 +1376,7 @@ LDAP_F( void )
ldap_value_free_len LDAP_P((
struct berval **vals ));
#ifdef LDAP_DEPRECATED
LDAP_F( char ** )
ldap_get_values LDAP_P(( /* deprecated */
LDAP *ld,
@ -1366,6 +1390,7 @@ ldap_count_values LDAP_P(( /* deprecated */
LDAP_F( void )
ldap_value_free LDAP_P(( /* deprecated */
char **vals ));
#endif
/*
* in result.c:
@ -1427,6 +1452,7 @@ ldap_search_ext_s LDAP_P((
int sizelimit,
LDAPMessage **res ));
#ifdef LDAP_DEPRECATED
LDAP_F( int )
ldap_search LDAP_P(( /* deprecated */
LDAP *ld,
@ -1456,19 +1482,12 @@ ldap_search_st LDAP_P(( /* deprecated */
int attrsonly,
struct timeval *timeout,
LDAPMessage **res ));
#endif
/*
* in unbind.c
*/
LDAP_F( int )
ldap_unbind LDAP_P(( /* deprecated */
LDAP *ld ));
LDAP_F( int )
ldap_unbind_s LDAP_P(( /* deprecated */
LDAP *ld ));
LDAP_F( int )
ldap_unbind_ext LDAP_P((
LDAP *ld,
LDAPControl **serverctrls,
@ -1480,6 +1499,16 @@ ldap_unbind_ext_s LDAP_P((
LDAPControl **serverctrls,
LDAPControl **clientctrls));
#ifdef LDAP_DEPRECATED
LDAP_F( int )
ldap_unbind LDAP_P(( /* deprecated */
LDAP *ld ));
LDAP_F( int )
ldap_unbind_s LDAP_P(( /* deprecated */
LDAP *ld ));
#endif
/*
* in filter.c
*/
@ -1524,9 +1553,9 @@ ldap_mods_free LDAP_P((
int freemods ));
#ifdef LDAP_DEPRECATED
/*
* in sort.c
* (deprecated)
* in sort.c (deprecated)
*/
typedef int (LDAP_SORT_AD_CMP_PROC) LDAP_P(( /* deprecated */
LDAP_CONST char *left,
@ -1552,7 +1581,7 @@ LDAP_F( int ) /* deprecated */
ldap_sort_strcasecmp LDAP_P((
LDAP_CONST void *a,
LDAP_CONST void *b ));
#endif
/*
* in url.c
@ -1582,12 +1611,14 @@ LDAP_F( void )
ldap_free_urldesc LDAP_P((
LDAPURLDesc *ludp ));
/*
* in sortctrl.c
*/
/*
* structure for a sort-key
* LDAP Server Side Sort
* in sortctrl.c
*/
#define LDAP_API_FEATURE_SERVER_SIDE_SORT 1000
/* structure for a sort-key */
typedef struct ldapsortkey {
char * attributeType;
char * orderingRule;
@ -1619,21 +1650,21 @@ ldap_parse_sort_control LDAP_P((
/*
* in vlvctrl.c
* LDAP Virtual List View
* in vlvctrl.c
*/
#define LDAP_API_FEATURE_VIRTUAL_LIST_VIEW 1000
/*
* structure for virtual list.
*/
/* structure for virtual list */
typedef struct ldapvlvinfo {
int ldvlv_version;
unsigned long ldvlv_before_count;
unsigned long ldvlv_after_count;
unsigned long ldvlv_offset;
unsigned long ldvlv_count;
struct berval *ldvlv_attrvalue;
struct berval *ldvlv_context;
void *ldvlv_extradata;
struct berval * ldvlv_attrvalue;
struct berval * ldvlv_context;
void * ldvlv_extradata;
} LDAPVLVInfo;
LDAP_F( int )
@ -1652,7 +1683,8 @@ ldap_parse_vlv_control LDAP_P((
int *errcodep ));
/*
* LDAP Who Am I? (whoami.c)
* LDAP Who Am I?
* in whoami.c
*/
LDAP_F( int )
@ -1675,7 +1707,8 @@ ldap_whoami_s LDAP_P((
LDAPControl **cctrls ));
/*
* in passwd.c
* LDAP Password Modify
* in passwd.c
*/
LDAP_F( int )
@ -1703,5 +1736,6 @@ ldap_passwd_s LDAP_P((
LDAPControl **sctrls,
LDAPControl **cctrls ));
LDAP_END_DECL
#endif /* _LDAP_H */

6
include/ldap_features.h.in
View file

@ -60,10 +60,4 @@
/* LDAP v2 Referrals */
#undef LDAP_API_FEATURE_X_OPENLDAP_V2_REFERRALS
/* LDAP Server Side Sort. */
#define LDAP_API_FEATURE_SERVER_SIDE_SORT 1000
/* LDAP Virtual List View. */
#define LDAP_API_FEATURE_VIRTUAL_LIST_VIEW 1000
#endif /* LDAP_FEATURES */

1
include/ldap_pvt_uc.h
View file

@ -24,6 +24,7 @@
#include <lber.h> /* get ber_slen_t */
#include <ac/bytes.h>
#include "../libraries/liblunicode/ucdata/ucdata.h"
LDAP_BEGIN_DECL

2
include/lutil.h
View file

@ -29,7 +29,7 @@ LDAP_BEGIN_DECL
/* Avoid floating point math through extra padding */
#define LUTIL_BASE64_ENCODE_LEN(n) (((n)+2)/3 * 4)
#define LUTIL_BASE64_DECODE_LEN(n) (((n)+3)/4 * 3)
#define LUTIL_BASE64_DECODE_LEN(n) ((n)/4*3)
/* ISC Base64 Routines */
/* base64.c */

43
include/portable.h.in
View file

@ -350,6 +350,9 @@
/* Define if you have the <assert.h> header file. */
#undef HAVE_ASSERT_H
/* Define if you have the <bits/types.h> header file. */
#undef HAVE_BITS_TYPES_H
/* Define if you have the <conio.h> header file. */
#undef HAVE_CONIO_H
@ -443,9 +446,6 @@
/* Define if you have the <memory.h> header file. */
#undef HAVE_MEMORY_H
/* Define if you have the <ncurses.h> header file. */
#undef HAVE_NCURSES_H
/* Define if you have the <ndbm.h> header file. */
#undef HAVE_NDBM_H
@ -581,9 +581,6 @@
/* Define if you have the <tcpd.h> header file. */
#undef HAVE_TCPD_H
/* Define if you have the <termcap.h> header file. */
#undef HAVE_TERMCAP_H
/* Define if you have the <termios.h> header file. */
#undef HAVE_TERMIOS_H
@ -797,15 +794,6 @@
/* define if you have -lwrap */
#undef HAVE_TCPD
/* define if you have -ltermcap */
#undef HAVE_TERMCAP
/* define if you have -lncurses */
#undef HAVE_NCURSES
/* define if you have no termcap support */
#undef NO_TERMCAP
/* define if you have Cyrus SASL */
#undef HAVE_CYRUS_SASL
@ -953,6 +941,12 @@
/* define to support modules */
#undef SLAPD_MODULES
/* statically linked module */
#undef SLAPD_MOD_STATIC
/* dynamically linked module */
#undef SLAPD_MOD_DYNAMIC
/* define to support BDB backend */
#undef SLAPD_BDB
@ -1025,6 +1019,12 @@
/* define to support dynamic SQL backend */
#undef SLAPD_SQL_DYNAMIC
/* define for Dynamic Group overlay */
#undef SLAPD_OVER_DYNGROUP
/* define for Proxy Cache overlay */
#undef SLAPD_OVER_PROXYCACHE
/* define to enable rewriting in back-ldap and back-meta */
#undef ENABLE_REWRITE
@ -1070,6 +1070,19 @@
#define vsprintf ber_pvt_vsprintf
#endif
#ifdef OPENLDAP_FD_SETSIZE
/* assume installer desires to enlarge fd_set */
#ifdef HAVE_BITS_TYPES_H
#include <bits/types.h>
#endif
#ifdef __FD_SETSIZE
#undef __FD_SETSIZE
#define __FD_SETSIZE OPENLDAP_FD_SETSIZE
#else
#define FD_SETSIZE OPENLDAP_FD_SETSIZE
#endif
#endif
#include "ldap_cdefs.h"
#include "ldap_features.h"

1
libraries/Makefile.in
View file

@ -18,6 +18,5 @@ SUBDIRS= \
liblber \
liblunicode \
libldap libldap_r \
libldbm \
librewrite

54
libraries/liblber/debug.c
View file

@ -32,12 +32,6 @@
#include "lber.h"
#include "ldap_pvt.h"
struct DEBUGLEVEL
{
char *subsystem;
int level;
};
int ldap_loglevels[LDAP_SUBSYS_NUM];
static FILE *log_file = NULL;
@ -60,26 +54,26 @@ static int debug2syslog(int l) {
}
#endif
static char *lutil_levels[] = {
static char *debug_levels[] = {
"emergency", "alert", "critical",
"error", "warning", "notice",
"information", "entry", "args",
"results", "detail1", "detail2",
NULL };
static char *lutil_subsys[LDAP_SUBSYS_NUM] = {
"global","operation", "transport",
"connection", "filter", "ber",
"config", "acl", "cache", "index",
"ldif", "tools", "slapd", "slurpd",
"backend", "back_bdb", "back_ldbm",
"back_ldap", "back_meta", "back_mon" };
static char *debug_subsys[LDAP_SUBSYS_NUM] = {
"GLOBAL", "OPERATION", "TRANSPORT",
"CONNECTION", "FILTER", "BER",
"CONFIG", "ACL", "CACHE", "INDEX",
"LDIF", "TOOLS", "SLAPD", "SLURPD",
"BACKEND", "BACK_BDB", "BACK_LDBM",
"BACK_LDAP", "BACK_META", "BACK_MON" };
int lutil_mnem2subsys( const char *subsys )
{
int i;
for( i = 0; i < LDAP_SUBSYS_NUM; i++ ) {
if ( !strcasecmp( subsys, lutil_subsys[i] ) ) {
if ( !strcasecmp( subsys, debug_subsys[i] ) ) {
return i;
}
}
@ -89,9 +83,8 @@ int lutil_mnem2subsys( const char *subsys )
void lutil_set_all_backends( int level )
{
int i;
for( i = 0; i < LDAP_SUBSYS_NUM; i++ ) {
if ( !strncasecmp( "back_", lutil_subsys[i], strlen("back_") ) ) {
if ( !strncasecmp( "BACK_", debug_subsys[i], sizeof("BACK_")-1 ) ) {
ldap_loglevels[i] = level;
}
}
@ -100,8 +93,8 @@ void lutil_set_all_backends( int level )
int lutil_mnem2level( const char *level )
{
int i;
for( i = 0; lutil_levels[i] != NULL; i++ ) {
if ( !strcasecmp( level, lutil_levels[i] ) ) {
for( i = 0; debug_levels[i] != NULL; i++ ) {
if ( !strcasecmp( level, debug_levels[i] ) ) {
return i;
}
}
@ -112,7 +105,7 @@ static int addSubsys( const char *subsys, int level )
{
int subsys_num;
if ( !strcasecmp( subsys, "backend" ) ) {
if ( !strcasecmp( subsys, "BACKEND" ) ) {
lutil_set_all_backends( level );
return level;
@ -154,15 +147,8 @@ void lutil_log_int(
struct tm *today;
#endif
size_t i;
char * t_subsys;
char * tmp;
t_subsys = strdup(subsys);
for(tmp = t_subsys, i = 0; i < strlen(t_subsys); i++, tmp++) {
*tmp = TOUPPER( (unsigned char) *tmp );
}
#ifdef LDAP_SYSLOG
/* we're configured to use syslog */
if( use_syslog ) {
@ -218,7 +204,7 @@ void lutil_log_int(
* format the output data.
*/
fprintf(file, "\n%s:: ", t_subsys );
fprintf(file, "\n%s:: ", subsys );
vfprintf( file, fmt, vl );
fflush( file );
}
@ -234,7 +220,7 @@ void lutil_log( const int subsys, int level, const char *fmt, ... )
va_list vl;
va_start( vl, fmt );
ber_get_option( NULL, LBER_OPT_LOG_PRINT_FILE, &outfile );
lutil_log_int( outfile, lutil_subsys[subsys], level, fmt, vl );
lutil_log_int( outfile, debug_subsys[subsys], level, fmt, vl );
va_end( vl );
}
@ -274,9 +260,9 @@ void lutil_log_initialize(int argc, char **argv)
global_level = atoi( optarg );
ldap_loglevels[0] = global_level;
/*
* if a negative number was used, make the global level the
* maximum sane level.
*/
* if a negative number was used, make the global level the
* maximum sane level.
*/
if ( global_level < 0 ) {
global_level = 65535;
ldap_loglevels[0] = 65535;
@ -305,16 +291,14 @@ void (lutil_debug)( int debug, int level, const char *fmt, ... )
ber_set_option( NULL, LBER_OPT_LOG_PRINT_FILE, log_file );
}
#endif
va_start( vl, fmt );
va_start( vl, fmt );
vsnprintf( buffer, sizeof(buffer), fmt, vl );
buffer[sizeof(buffer)-1] = '\0';
if( log_file != NULL ) {
fputs( buffer, log_file );
fflush( log_file );
}
fputs( buffer, stderr );
va_end( vl );
}

5
libraries/libldap/cyrus.c
View file

@ -499,6 +499,11 @@ ldap_int_sasl_open(
return ld->ld_errno;
}
if ( ldap_int_sasl_init() ) {
ld->ld_errno = LDAP_LOCAL_ERROR;
return ld->ld_errno;
}
#if SASL_VERSION_MAJOR >= 2
rc = sasl_client_new( "ldap", host, NULL, NULL,
NULL, 0, &ctx );

2
libraries/libldap/error.c
View file

@ -121,7 +121,7 @@ static struct ldaperror ldap_builtin_errlist[] = {
{LDAP_CANNOT_CANCEL, N_("Cannot Cancel")},
#endif
{-1, NULL}
{0, NULL}
};
static struct ldaperror *ldap_errlist = ldap_builtin_errlist;

2
libraries/libldap/init.c
View file

@ -611,6 +611,4 @@ void ldap_int_initialize( struct ldapoptions *gopts, int *dbglvl )
}
openldap_ldap_init_w_env(gopts, NULL);
ldap_int_sasl_init();
}

3
libraries/libldap/ldap-int.h
View file

@ -56,7 +56,7 @@
* Note: Deallocate structure when the process exits
*/
# define LDAP_INT_GLOBAL_OPT() ldap_int_global_opt()
struct ldapoptions *ldap_int_global_opt(void);
struct ldapoptions *ldap_int_global_opt(void);
#else
# define LDAP_INT_GLOBAL_OPT() (&ldap_int_global_options)
#endif
@ -84,6 +84,7 @@
#endif /* LDAP_DEBUG */
#define LDAP_DEPRECATED 1
#include "ldap.h"
#include "ldap_pvt.h"

36
libraries/libldap/sort.c
View file

@ -92,20 +92,36 @@ ldap_sort_entries(
int (*cmp) (LDAP_CONST char *, LDAP_CONST char *)
)
{
int i, count;
int i, count = 0;
struct entrything *et;
LDAPMessage *e, *last;
LDAPMessage *e, *ehead = NULL, *etail = NULL;
LDAPMessage *ohead = NULL, *otail = NULL;
LDAPMessage **ep;
assert( ld != NULL );
count = ldap_count_entries( ld, *chain );
/* Separate entries from non-entries */
for ( e = *chain; e; e=e->lm_chain ) {
if ( e->lm_msgtype == LDAP_RES_SEARCH_ENTRY ) {
count++;
if ( !ehead ) ehead = e;
if ( etail ) etail->lm_chain = e;
etail = e;
} else {
if ( !ohead ) ohead = e;
if ( otail ) otail->lm_chain = e;
otail = e;
}
}
if ( count < 0 ) {
return -1;
} else if ( count < 2 ) {
if ( count < 2 ) {
/* zero or one entries -- already sorted! */
if ( ehead ) {
etail->lm_chain = ohead;
*chain = ehead;
} else {
*chain = ohead;
}
return 0;
}
@ -115,7 +131,7 @@ ldap_sort_entries(
return( -1 );
}
e = *chain;
e = ehead;
for ( i = 0; i < count; i++ ) {
et[i].et_cmp_fn = cmp;
et[i].et_msg = e;
@ -131,7 +147,6 @@ ldap_sort_entries(
e = e->lm_chain;
}
last = e;
qsort( et, count, sizeof(struct entrything), et_cmp );
@ -142,7 +157,8 @@ ldap_sort_entries(
LDAP_VFREE( et[i].et_vals );
}
*ep = last;
*ep = ohead;
LDAP_FREE( (char *) et );
return( 0 );

25
libraries/libldbm/Makefile.in
View file

@ -1,25 +0,0 @@
# Makefile for -lldbm
# $OpenLDAP$
## This work is part of OpenLDAP Software <http://www.openldap.org/>.
##
## Copyright 1998-2003 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>.
LIBRARY = libldbm.a
SRCS = ldbm.c
OBJS = ldbm.o
LDAP_INCDIR= ../../include
LDAP_LIBDIR= ../../libraries
XLIBS = $(LIBRARY)
XXLIBS = $(LDBM_LIBS)

137
libraries/libldbm/libldbm.dsp
View file

@ -1,137 +0,0 @@
# Microsoft Developer Studio Project File - Name="libldbm" - Package Owner=<4>
# Microsoft Developer Studio Generated Build File, Format Version 5.00
# ** DO NOT EDIT **
# TARGTYPE "Win32 (x86) Static Library" 0x0104
CFG=libldbm - Win32 Single Debug
!MESSAGE This is not a valid makefile. To build this project using NMAKE,
!MESSAGE use the Export Makefile command and run
!MESSAGE
!MESSAGE NMAKE /f "libldbm.mak".
!MESSAGE
!MESSAGE You can specify a configuration when running NMAKE
!MESSAGE by defining the macro CFG on the command line. For example:
!MESSAGE
!MESSAGE NMAKE /f "libldbm.mak" CFG="libldbm - Win32 Single Debug"
!MESSAGE
!MESSAGE Possible choices for configuration are:
!MESSAGE
!MESSAGE "libldbm - Win32 Release" (based on "Win32 (x86) Static Library")
!MESSAGE "libldbm - Win32 Debug" (based on "Win32 (x86) Static Library")
!MESSAGE "libldbm - Win32 Single Debug" (based on "Win32 (x86) Static Library")
!MESSAGE "libldbm - Win32 Single Release" (based on\
"Win32 (x86) Static Library")
!MESSAGE
# Begin Project
# PROP Scc_ProjName ""
# PROP Scc_LocalPath ""
CPP=cl.exe
!IF "$(CFG)" == "libldbm - Win32 Release"
# PROP BASE Use_MFC 0
# PROP BASE Use_Debug_Libraries 0
# PROP BASE Output_Dir "Release"
# PROP BASE Intermediate_Dir "Release"
# PROP BASE Target_Dir ""
# PROP Use_MFC 0
# PROP Use_Debug_Libraries 0
# PROP Output_Dir "..\..\Release"
# PROP Intermediate_Dir "..\..\Release\libldbm"
# PROP Target_Dir ""
RSC=rc.exe
# ADD BASE CPP /nologo /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /YX /FD /c
# ADD CPP /nologo /MT /W3 /GX /O2 /I "..\..\include" /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /YX /FD /c
BSC32=bscmake.exe
# ADD BASE BSC32 /nologo
# ADD BSC32 /nologo
LIB32=link.exe -lib
# ADD BASE LIB32 /nologo
# ADD LIB32 /nologo /out:"..\..\Release\oldbm32.lib"
!ELSEIF "$(CFG)" == "libldbm - Win32 Debug"
# PROP BASE Use_MFC 0
# PROP BASE Use_Debug_Libraries 1
# PROP BASE Output_Dir "Debug"
# PROP BASE Intermediate_Dir "Debug"
# PROP BASE Target_Dir ""
# PROP Use_MFC 0
# PROP Use_Debug_Libraries 1
# PROP Output_Dir "..\..\Debug"
# PROP Intermediate_Dir "..\..\Debug\libldbm"
# PROP Target_Dir ""
RSC=rc.exe
# ADD BASE CPP /nologo /W3 /GX /Z7 /Od /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /YX /FD /c
# ADD CPP /nologo /MTd /W3 /GX /Z7 /Od /I "..\..\include" /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /FR /YX /FD /c
BSC32=bscmake.exe
# ADD BASE BSC32 /nologo
# ADD BSC32 /nologo
LIB32=link.exe -lib
# ADD BASE LIB32 /nologo
# ADD LIB32 /nologo /out:"..\..\Debug\oldbm32.lib"
!ELSEIF "$(CFG)" == "libldbm - Win32 Single Debug"
# PROP BASE Use_MFC 0
# PROP BASE Use_Debug_Libraries 1
# PROP BASE Output_Dir "libldbm_"
# PROP BASE Intermediate_Dir "libldbm_"
# PROP BASE Target_Dir ""
# PROP Use_MFC 0
# PROP Use_Debug_Libraries 1
# PROP Output_Dir "..\..\SDebug"
# PROP Intermediate_Dir "..\..\SDebug\libldbm"
# PROP Target_Dir ""
RSC=rc.exe
# ADD BASE CPP /nologo /MTd /W3 /GX /Z7 /Od /I "..\..\include" /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /YX /FD /c
# ADD CPP /nologo /W3 /GX /Z7 /Od /I "..\..\include" /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /FR /YX /FD /c
BSC32=bscmake.exe
# ADD BASE BSC32 /nologo
# ADD BSC32 /nologo
LIB32=link.exe -lib
# ADD BASE LIB32 /nologo /out:"..\Debug\oldbm32.lib"
# ADD LIB32 /nologo /out:"..\..\SDebug\oldbm32.lib"
!ELSEIF "$(CFG)" == "libldbm - Win32 Single Release"
# PROP BASE Use_MFC 0
# PROP BASE Use_Debug_Libraries 0
# PROP BASE Output_Dir "libldbm0"
# PROP BASE Intermediate_Dir "libldbm0"
# PROP BASE Target_Dir ""
# PROP Use_MFC 0
# PROP Use_Debug_Libraries 0
# PROP Output_Dir "..\..\SRelease"
# PROP Intermediate_Dir "..\..\SRelease\libldbm"
# PROP Target_Dir ""
RSC=rc.exe
# ADD BASE CPP /nologo /MT /W3 /GX /O2 /I "..\..\include" /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /YX /FD /c
# ADD CPP /nologo /W3 /GX /O2 /I "..\..\include" /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /YX /FD /c
BSC32=bscmake.exe
# ADD BASE BSC32 /nologo
# ADD BSC32 /nologo
LIB32=link.exe -lib
# ADD BASE LIB32 /nologo /out:"..\Release\oldbm32.lib"
# ADD LIB32 /nologo /out:"..\..\SRelease\oldbm32.lib"
!ENDIF
# Begin Target
# Name "libldbm - Win32 Release"
# Name "libldbm - Win32 Debug"
# Name "libldbm - Win32 Single Debug"
# Name "libldbm - Win32 Single Release"
# Begin Source File
SOURCE=.\ldbm.c
# End Source File
# Begin Source File
SOURCE=..\..\include\ldbm.h
# End Source File
# End Target
# End Project

186
libraries/liblunicode/ucdata/ucdata.c
View file

@ -65,7 +65,7 @@ typedef struct {
/*
* A simple array of 32-bit masks for lookup.
*/
static unsigned long masks32[32] = {
static ac_uint4 masks32[32] = {
0x00000001UL, 0x00000002UL, 0x00000004UL, 0x00000008UL,
0x00000010UL, 0x00000020UL, 0x00000040UL, 0x00000080UL,
0x00000100UL, 0x00000200UL, 0x00000400UL, 0x00000800UL,
@ -117,9 +117,9 @@ _ucopenfile(char *paths, char *filename, char *mode)
*
**************************************************************************/
static unsigned long _ucprop_size;
static unsigned short *_ucprop_offsets;
static unsigned long *_ucprop_ranges;
static ac_uint4 _ucprop_size;
static ac_uint2 *_ucprop_offsets;
static ac_uint4 *_ucprop_ranges;
/*
* Return -1 on error, 0 if okay
@ -128,7 +128,7 @@ static int
_ucprop_load(char *paths, int reload)
{
FILE *in;
unsigned long size, i;
ac_uint4 size, i;
_ucheader_t hdr;
if (_ucprop_size > 0) {
@ -169,7 +169,7 @@ _ucprop_load(char *paths, int reload)
/*
* Allocate all the storage needed for the lookup table.
*/
_ucprop_offsets = (unsigned short *) malloc(hdr.size.bytes);
_ucprop_offsets = (ac_uint2 *) malloc(hdr.size.bytes);
/*
* Calculate the offset into the storage for the ranges. The offsets
@ -177,15 +177,15 @@ _ucprop_load(char *paths, int reload)
* the header count field. This means the offset to the ranges must be
* calculated after aligning the count to a 4-byte boundary.
*/
if ((size = ((hdr.cnt + 1) * sizeof(unsigned short))) & 3)
if ((size = ((hdr.cnt + 1) * sizeof(ac_uint2))) & 3)
size += 4 - (size & 3);
size >>= 1;
_ucprop_ranges = (unsigned long *) (_ucprop_offsets + size);
_ucprop_ranges = (ac_uint4 *) (_ucprop_offsets + size);
/*
* Load the offset array.
*/
fread((char *) _ucprop_offsets, sizeof(unsigned short), size, in);
fread((char *) _ucprop_offsets, sizeof(ac_uint2), size, in);
/*
* Do an endian swap if necessary. Don't forget there is an extra node on
@ -200,7 +200,7 @@ _ucprop_load(char *paths, int reload)
* Load the ranges. The number of elements is in the last array position
* of the offsets.
*/
fread((char *) _ucprop_ranges, sizeof(unsigned long),
fread((char *) _ucprop_ranges, sizeof(ac_uint4),
_ucprop_offsets[_ucprop_size], in);
fclose(in);
@ -230,7 +230,7 @@ _ucprop_unload(void)
}
static int
_ucprop_lookup(unsigned long code, unsigned long n)
_ucprop_lookup(ac_uint4 code, ac_uint4 n)
{
long l, r, m;
@ -272,9 +272,9 @@ _ucprop_lookup(unsigned long code, unsigned long n)
}
int
ucisprop(unsigned long code, unsigned long mask1, unsigned long mask2)
ucisprop(ac_uint4 code, ac_uint4 mask1, ac_uint4 mask2)
{
unsigned long i;
ac_uint4 i;
if (mask1 == 0 && mask2 == 0)
return 0;
@ -298,9 +298,9 @@ ucisprop(unsigned long code, unsigned long mask1, unsigned long mask2)
*
**************************************************************************/
static unsigned long _uccase_size;
static unsigned short _uccase_len[2];
static unsigned long *_uccase_map;
static ac_uint4 _uccase_size;
static ac_uint2 _uccase_len[2];
static ac_uint4 *_uccase_map;
/*
* Return -1 on error, 0 if okay
@ -309,7 +309,7 @@ static int
_uccase_load(char *paths, int reload)
{
FILE *in;
unsigned long i;
ac_uint4 i;
_ucheader_t hdr;
if (_uccase_size > 0) {
@ -345,13 +345,13 @@ _uccase_load(char *paths, int reload)
_uccase_len[0] = hdr.size.len[0] * 3;
_uccase_len[1] = hdr.size.len[1] * 3;
_uccase_map = (unsigned long *)
malloc(_uccase_size * sizeof(unsigned long));
_uccase_map = (ac_uint4 *)
malloc(_uccase_size * sizeof(ac_uint4));
/*
* Load the case mapping table.
*/
fread((char *) _uccase_map, sizeof(unsigned long), _uccase_size, in);
fread((char *) _uccase_map, sizeof(ac_uint4), _uccase_size, in);
/*
* Do an endian swap if necessary.
@ -374,8 +374,8 @@ _uccase_unload(void)
_uccase_size = 0;
}
static unsigned long
_uccase_lookup(unsigned long code, long l, long r, int field)
static ac_uint4
_uccase_lookup(ac_uint4 code, long l, long r, int field)
{
long m;
@ -400,8 +400,8 @@ _uccase_lookup(unsigned long code, long l, long r, int field)
return code;
}
unsigned long
uctoupper(unsigned long code)
ac_uint4
uctoupper(ac_uint4 code)
{
int field;
long l, r;
@ -427,8 +427,8 @@ uctoupper(unsigned long code)
return _uccase_lookup(code, l, r, field);
}
unsigned long
uctolower(unsigned long code)
ac_uint4
uctolower(ac_uint4 code)
{
int field;
long l, r;
@ -454,8 +454,8 @@ uctolower(unsigned long code)
return _uccase_lookup(code, l, r, field);
}
unsigned long
uctotitle(unsigned long code)
ac_uint4
uctotitle(ac_uint4 code)
{
int field;
long l, r;
@ -490,8 +490,8 @@ uctotitle(unsigned long code)
*
**************************************************************************/
static unsigned long _uccomp_size;
static unsigned long *_uccomp_data;
static ac_uint4 _uccomp_size;
static ac_uint4 *_uccomp_data;
/*
* Return -1 on error, 0 if okay
@ -500,7 +500,7 @@ static int
_uccomp_load(char *paths, int reload)
{
FILE *in;
unsigned long size, i;
ac_uint4 size, i;
_ucheader_t hdr;
if (_uccomp_size > 0) {
@ -528,13 +528,13 @@ _uccomp_load(char *paths, int reload)
}
_uccomp_size = hdr.cnt;
_uccomp_data = (unsigned long *) malloc(hdr.size.bytes);
_uccomp_data = (ac_uint4 *) malloc(hdr.size.bytes);
/*
* Read the composition data in.
*/
size = hdr.size.bytes / sizeof(unsigned long);
fread((char *) _uccomp_data, sizeof(unsigned long), size, in);
size = hdr.size.bytes / sizeof(ac_uint4);
fread((char *) _uccomp_data, sizeof(ac_uint4), size, in);
/*
* Do an endian swap if necessary.
@ -568,7 +568,7 @@ _uccomp_unload(void)
}
int
uccomp(unsigned long node1, unsigned long node2, unsigned long *comp)
uccomp(ac_uint4 node1, ac_uint4 node2, ac_uint4 *comp)
{
int l, r, m;
@ -595,7 +595,7 @@ uccomp(unsigned long node1, unsigned long node2, unsigned long *comp)
}
int
uccomp_hangul(unsigned long *str, int len)
uccomp_hangul(ac_uint4 *str, int len)
{
const int SBase = 0xAC00, LBase = 0x1100,
VBase = 0x1161, TBase = 0x11A7,
@ -604,7 +604,7 @@ uccomp_hangul(unsigned long *str, int len)
SCount = LCount * NCount; /* 11172 */
int i, rlen;
unsigned long ch, last, lindex, sindex;
ac_uint4 ch, last, lindex, sindex;
last = str[0];
rlen = 1;
@ -613,9 +613,9 @@ uccomp_hangul(unsigned long *str, int len)
/* check if two current characters are L and V */
lindex = last - LBase;
if (lindex < (unsigned long) LCount) {
unsigned long vindex = ch - VBase;
if (vindex < (unsigned long) VCount) {
if (lindex < (ac_uint4) LCount) {
ac_uint4 vindex = ch - VBase;
if (vindex < (ac_uint4) VCount) {
/* make syllable of form LV */
last = SBase + (lindex * VCount + vindex) * TCount;
str[rlen-1] = last; /* reset last */
@ -625,11 +625,11 @@ uccomp_hangul(unsigned long *str, int len)
/* check if two current characters are LV and T */
sindex = last - SBase;
if (sindex < (unsigned long) SCount
if (sindex < (ac_uint4) SCount
&& (sindex % TCount) == 0)
{
unsigned long tindex = ch - TBase;
if (tindex <= (unsigned long) TCount) {
ac_uint4 tindex = ch - TBase;
if (tindex <= (ac_uint4) TCount) {
/* make syllable of form LVT */
last += tindex;
str[rlen-1] = last; /* reset last */
@ -646,10 +646,10 @@ uccomp_hangul(unsigned long *str, int len)
}
int
uccanoncomp(unsigned long *str, int len)
uccanoncomp(ac_uint4 *str, int len)
{
int i, stpos, copos;
unsigned long cl, prevcl, st, ch, co;
ac_uint4 cl, prevcl, st, ch, co;
st = str[0];
stpos = 0;
@ -680,13 +680,13 @@ uccanoncomp(unsigned long *str, int len)
*
**************************************************************************/
static unsigned long _ucdcmp_size;
static unsigned long *_ucdcmp_nodes;
static unsigned long *_ucdcmp_decomp;
static ac_uint4 _ucdcmp_size;
static ac_uint4 *_ucdcmp_nodes;
static ac_uint4 *_ucdcmp_decomp;
static unsigned long _uckdcmp_size;
static unsigned long *_uckdcmp_nodes;
static unsigned long *_uckdcmp_decomp;
static ac_uint4 _uckdcmp_size;
static ac_uint4 *_uckdcmp_nodes;
static ac_uint4 *_uckdcmp_decomp;
/*
* Return -1 on error, 0 if okay
@ -695,7 +695,7 @@ static int
_ucdcmp_load(char *paths, int reload)
{
FILE *in;
unsigned long size, i;
ac_uint4 size, i;
_ucheader_t hdr;
if (_ucdcmp_size > 0) {
@ -723,14 +723,14 @@ _ucdcmp_load(char *paths, int reload)
}
_ucdcmp_size = hdr.cnt << 1;
_ucdcmp_nodes = (unsigned long *) malloc(hdr.size.bytes);
_ucdcmp_nodes = (ac_uint4 *) malloc(hdr.size.bytes);
_ucdcmp_decomp = _ucdcmp_nodes + (_ucdcmp_size + 1);
/*
* Read the decomposition data in.
*/
size = hdr.size.bytes / sizeof(unsigned long);
fread((char *) _ucdcmp_nodes, sizeof(unsigned long), size, in);
size = hdr.size.bytes / sizeof(ac_uint4);
fread((char *) _ucdcmp_nodes, sizeof(ac_uint4), size, in);
/*
* Do an endian swap if necessary.
@ -750,7 +750,7 @@ static int
_uckdcmp_load(char *paths, int reload)
{
FILE *in;
unsigned long size, i;
ac_uint4 size, i;
_ucheader_t hdr;
if (_uckdcmp_size > 0) {
@ -778,14 +778,14 @@ _uckdcmp_load(char *paths, int reload)
}
_uckdcmp_size = hdr.cnt << 1;
_uckdcmp_nodes = (unsigned long *) malloc(hdr.size.bytes);
_uckdcmp_nodes = (ac_uint4 *) malloc(hdr.size.bytes);
_uckdcmp_decomp = _uckdcmp_nodes + (_uckdcmp_size + 1);
/*
* Read the decomposition data in.
*/
size = hdr.size.bytes / sizeof(unsigned long);
fread((char *) _uckdcmp_nodes, sizeof(unsigned long), size, in);
size = hdr.size.bytes / sizeof(ac_uint4);
fread((char *) _uckdcmp_nodes, sizeof(ac_uint4), size, in);
/*
* Do an endian swap if necessary.
@ -827,7 +827,7 @@ _uckdcmp_unload(void)
}
int
ucdecomp(unsigned long code, unsigned long *num, unsigned long **decomp)
ucdecomp(ac_uint4 code, ac_uint4 *num, ac_uint4 **decomp)
{
long l, r, m;
@ -859,7 +859,7 @@ ucdecomp(unsigned long code, unsigned long *num, unsigned long **decomp)
}
int
uckdecomp(unsigned long code, unsigned long *num, unsigned long **decomp)
uckdecomp(ac_uint4 code, ac_uint4 *num, ac_uint4 **decomp)
{
long l, r, m;
@ -891,15 +891,15 @@ uckdecomp(unsigned long code, unsigned long *num, unsigned long **decomp)
}
int
ucdecomp_hangul(unsigned long code, unsigned long *num, unsigned long decomp[])
ucdecomp_hangul(ac_uint4 code, ac_uint4 *num, ac_uint4 decomp[])
{
if (!ucishangul(code))
return 0;
code -= 0xac00;
decomp[0] = 0x1100 + (unsigned long) (code / 588);
decomp[1] = 0x1161 + (unsigned long) ((code % 588) / 28);
decomp[2] = 0x11a7 + (unsigned long) (code % 28);
decomp[0] = 0x1100 + (ac_uint4) (code / 588);
decomp[1] = 0x1161 + (ac_uint4) ((code % 588) / 28);
decomp[2] = 0x11a7 + (ac_uint4) (code % 28);
*num = (decomp[2] != 0x11a7) ? 3 : 2;
return 1;
@ -907,15 +907,15 @@ ucdecomp_hangul(unsigned long code, unsigned long *num, unsigned long decomp[])
/* mode == 0 for canonical, mode == 1 for compatibility */
static int
uccanoncompatdecomp(const unsigned long *in, int inlen,
unsigned long **out, int *outlen, short mode, void *ctx)
uccanoncompatdecomp(const ac_uint4 *in, int inlen,
ac_uint4 **out, int *outlen, short mode, void *ctx)
{
int l, size;
unsigned i, j, k;
unsigned long num, class, *decomp, hangdecomp[3];
ac_uint4 num, class, *decomp, hangdecomp[3];
size = inlen * 2;
*out = (unsigned long *) ber_memalloc_x(size * sizeof(**out), ctx);
*out = (ac_uint4 *) ber_memalloc_x(size * sizeof(**out), ctx);
if (*out == NULL)
return *outlen = -1;
@ -924,7 +924,7 @@ uccanoncompatdecomp(const unsigned long *in, int inlen,
if (mode ? uckdecomp(in[j], &num, &decomp) : ucdecomp(in[j], &num, &decomp)) {
if ( size - i < num) {
size = inlen + i - j + num - 1;
*out = (unsigned long *) ber_memrealloc_x(*out, size * sizeof(**out), ctx );
*out = (ac_uint4 *) ber_memrealloc_x(*out, size * sizeof(**out), ctx );
if (*out == NULL)
return *outlen = -1;
}
@ -944,7 +944,7 @@ uccanoncompatdecomp(const unsigned long *in, int inlen,
} else if (ucdecomp_hangul(in[j], &num, hangdecomp)) {
if (size - i < num) {
size = inlen + i - j + num - 1;
*out = (unsigned long *) ber_memrealloc_x(*out, size * sizeof(**out), ctx);
*out = (ac_uint4 *) ber_memrealloc_x(*out, size * sizeof(**out), ctx);
if (*out == NULL)
return *outlen = -1;
}
@ -955,7 +955,7 @@ uccanoncompatdecomp(const unsigned long *in, int inlen,
} else {
if (size - i < 1) {
size = inlen + i - j;
*out = (unsigned long *) ber_memrealloc_x(*out, size * sizeof(**out), ctx);
*out = (ac_uint4 *) ber_memrealloc_x(*out, size * sizeof(**out), ctx);
if (*out == NULL)
return *outlen = -1;
}
@ -976,15 +976,15 @@ uccanoncompatdecomp(const unsigned long *in, int inlen,
}
int
uccanondecomp(const unsigned long *in, int inlen,
unsigned long **out, int *outlen, void *ctx)
uccanondecomp(const ac_uint4 *in, int inlen,
ac_uint4 **out, int *outlen, void *ctx)
{
return uccanoncompatdecomp(in, inlen, out, outlen, 0, ctx);
}
int
uccompatdecomp(const unsigned long *in, int inlen,
unsigned long **out, int *outlen, void *ctx)
uccompatdecomp(const ac_uint4 *in, int inlen,
ac_uint4 **out, int *outlen, void *ctx)
{
return uccanoncompatdecomp(in, inlen, out, outlen, 1, ctx);
}
@ -995,8 +995,8 @@ uccompatdecomp(const unsigned long *in, int inlen,
*
**************************************************************************/
static unsigned long _uccmcl_size;
static unsigned long *_uccmcl_nodes;
static ac_uint4 _uccmcl_size;
static ac_uint4 *_uccmcl_nodes;
/*
* Return -1 on error, 0 if okay
@ -1005,7 +1005,7 @@ static int
_uccmcl_load(char *paths, int reload)
{
FILE *in;
unsigned long i;
ac_uint4 i;
_ucheader_t hdr;
if (_uccmcl_size > 0) {
@ -1033,12 +1033,12 @@ _uccmcl_load(char *paths, int reload)
}
_uccmcl_size = hdr.cnt * 3;
_uccmcl_nodes = (unsigned long *) malloc(hdr.size.bytes);
_uccmcl_nodes = (ac_uint4 *) malloc(hdr.size.bytes);
/*
* Read the combining classes in.
*/
fread((char *) _uccmcl_nodes, sizeof(unsigned long), _uccmcl_size, in);
fread((char *) _uccmcl_nodes, sizeof(ac_uint4), _uccmcl_size, in);
/*
* Do an endian swap if necessary.
@ -1061,8 +1061,8 @@ _uccmcl_unload(void)
_uccmcl_size = 0;
}
unsigned long
uccombining_class(unsigned long code)
ac_uint4
uccombining_class(ac_uint4 code)
{
long l, r, m;
@ -1088,8 +1088,8 @@ uccombining_class(unsigned long code)
*
**************************************************************************/
static unsigned long *_ucnum_nodes;
static unsigned long _ucnum_size;
static ac_uint4 *_ucnum_nodes;
static ac_uint4 _ucnum_size;
static short *_ucnum_vals;
/*
@ -1099,7 +1099,7 @@ static int
_ucnumb_load(char *paths, int reload)
{
FILE *in;
unsigned long size, i;
ac_uint4 size, i;
_ucheader_t hdr;
if (_ucnum_size > 0) {
@ -1127,7 +1127,7 @@ _ucnumb_load(char *paths, int reload)
}
_ucnum_size = hdr.cnt;
_ucnum_nodes = (unsigned long *) malloc(hdr.size.bytes);
_ucnum_nodes = (ac_uint4 *) malloc(hdr.size.bytes);
_ucnum_vals = (short *) (_ucnum_nodes + _ucnum_size);
/*
@ -1146,7 +1146,7 @@ _ucnumb_load(char *paths, int reload)
* Determine the number of values that have to be adjusted.
*/
size = (hdr.size.bytes -
(_ucnum_size * (sizeof(unsigned long) << 1))) /
(_ucnum_size * (sizeof(ac_uint4) << 1))) /
sizeof(short);
for (i = 0; i < size; i++)
@ -1167,7 +1167,7 @@ _ucnumb_unload(void)
}
int
ucnumber_lookup(unsigned long code, struct ucnumber *num)
ucnumber_lookup(ac_uint4 code, struct ucnumber *num)
{
long l, r, m;
short *vp;
@ -1196,7 +1196,7 @@ ucnumber_lookup(unsigned long code, struct ucnumber *num)
}
int
ucdigit_lookup(unsigned long code, int *digit)
ucdigit_lookup(ac_uint4 code, int *digit)
{
long l, r, m;
short *vp;
@ -1227,7 +1227,7 @@ ucdigit_lookup(unsigned long code, int *digit)
}
struct ucnumber
ucgetnumber(unsigned long code)
ucgetnumber(ac_uint4 code)
{
struct ucnumber num;
@ -1244,7 +1244,7 @@ ucgetnumber(unsigned long code)
}
int
ucgetdigit(unsigned long code)
ucgetdigit(ac_uint4 code)
{
int dig;
@ -1343,7 +1343,7 @@ void
main(void)
{
int dig;
unsigned long i, lo, *dec;
ac_uint4 i, lo, *dec;
struct ucnumber num;
ucdata_setup(".");

47
libraries/liblunicode/ucdata/ucdata.h
View file

@ -120,8 +120,7 @@ LDAP_BEGIN_DECL
* call this function with some set of masks.
*/
LDAP_LUNICODE_F (int)
ucisprop LDAP_P((unsigned long code, unsigned long mask1,
unsigned long mask2));
ucisprop LDAP_P((ac_uint4 code, ac_uint4 mask1, ac_uint4 mask2));
#define ucisalpha(cc) ucisprop(cc, UC_LU|UC_LL|UC_LM|UC_LO|UC_LT, 0)
#define ucisdigit(cc) ucisprop(cc, UC_ND, 0)
@ -210,9 +209,9 @@ ucisprop LDAP_P((unsigned long code, unsigned long mask1,
*
**************************************************************************/
LDAP_LUNICODE_F (unsigned long) uctoupper LDAP_P((unsigned long code));
LDAP_LUNICODE_F (unsigned long) uctolower LDAP_P((unsigned long code));
LDAP_LUNICODE_F (unsigned long) uctotitle LDAP_P((unsigned long code));
LDAP_LUNICODE_F (ac_uint4) uctoupper LDAP_P((ac_uint4 code));
LDAP_LUNICODE_F (ac_uint4) uctolower LDAP_P((ac_uint4 code));
LDAP_LUNICODE_F (ac_uint4) uctotitle LDAP_P((ac_uint4 code));
/**************************************************************************
*
@ -225,20 +224,20 @@ LDAP_LUNICODE_F (unsigned long) uctotitle LDAP_P((unsigned long code));
* If it returns 0, there is no composition. Any other value indicates a
* composition was returned in comp.
*/
LDAP_LUNICODE_F (int) uccomp LDAP_P((unsigned long node1, unsigned long node2,
unsigned long *comp));
LDAP_LUNICODE_F (int) uccomp LDAP_P((ac_uint4 node1, ac_uint4 node2,
ac_uint4 *comp));
/*
* Does Hangul composition on the string str with length len, and returns
* the length of the composed string.
*/
LDAP_LUNICODE_F (int) uccomp_hangul LDAP_P((unsigned long *str, int len));
LDAP_LUNICODE_F (int) uccomp_hangul LDAP_P((ac_uint4 *str, int len));
/*
* Does canonical composition on the string str with length len, and returns
* the length of the composed string.
*/
LDAP_LUNICODE_F (int) uccanoncomp LDAP_P((unsigned long *str, int len));
LDAP_LUNICODE_F (int) uccanoncomp LDAP_P((ac_uint4 *str, int len));
/**************************************************************************
*
@ -252,24 +251,24 @@ LDAP_LUNICODE_F (int) uccanoncomp LDAP_P((unsigned long *str, int len));
* returned.
*/
LDAP_LUNICODE_F (int)
ucdecomp LDAP_P((unsigned long code, unsigned long *num,
unsigned long **decomp));
ucdecomp LDAP_P((ac_uint4 code, ac_uint4 *num,
ac_uint4 **decomp));
/*
* Equivalent to ucdecomp() except that it includes compatibility
* decompositions.
*/
LDAP_LUNICODE_F (int)
uckdecomp LDAP_P((unsigned long code, unsigned long *num,
unsigned long **decomp));
uckdecomp LDAP_P((ac_uint4 code, ac_uint4 *num,
ac_uint4 **decomp));
/*
* If the code is a Hangul syllable, this routine decomposes it into the array
* passed. The array size should be at least 3.
*/
LDAP_LUNICODE_F (int)
ucdecomp_hangul LDAP_P((unsigned long code, unsigned long *num,
unsigned long decomp[]));
ucdecomp_hangul LDAP_P((ac_uint4 code, ac_uint4 *num,
ac_uint4 decomp[]));
/*
* This routine does canonical decomposition of the string in of length
@ -278,16 +277,16 @@ ucdecomp_hangul LDAP_P((unsigned long code, unsigned long *num,
* of the decomposed string if okay, and -1 on error.
*/
LDAP_LUNICODE_F (int)
uccanondecomp LDAP_P((const unsigned long *in, int inlen,
unsigned long **out, int *outlen, void *ctx));
uccanondecomp LDAP_P((const ac_uint4 *in, int inlen,
ac_uint4 **out, int *outlen, void *ctx));
/*
* Equivalent to uccanondecomp() except that it includes compatibility
* decompositions.
*/
LDAP_LUNICODE_F (int)
uccompatdecomp LDAP_P((const unsigned long *in, int inlen,
unsigned long **out, int *outlen, void *ctx));
uccompatdecomp LDAP_P((const ac_uint4 *in, int inlen,
ac_uint4 **out, int *outlen, void *ctx));
/**************************************************************************
*
@ -299,7 +298,7 @@ uccompatdecomp LDAP_P((const unsigned long *in, int inlen,
* This will return the combining class for a character to be used with the
* Canonical Ordering algorithm.
*/
LDAP_LUNICODE_F (unsigned long) uccombining_class LDAP_P((unsigned long code));
LDAP_LUNICODE_F (ac_uint4) uccombining_class LDAP_P((ac_uint4 code));
/**************************************************************************
*
@ -313,16 +312,16 @@ struct ucnumber {
};
LDAP_LUNICODE_F (int)
ucnumber_lookup LDAP_P((unsigned long code, struct ucnumber *num));
ucnumber_lookup LDAP_P((ac_uint4 code, struct ucnumber *num));
LDAP_LUNICODE_F (int)
ucdigit_lookup LDAP_P((unsigned long code, int *digit));
ucdigit_lookup LDAP_P((ac_uint4 code, int *digit));
/*
* For compatibility with John Cowan's "uctype" package.
*/
LDAP_LUNICODE_F (struct ucnumber) ucgetnumber LDAP_P((unsigned long code));
LDAP_LUNICODE_F (int) ucgetdigit LDAP_P((unsigned long code));
LDAP_LUNICODE_F (struct ucnumber) ucgetnumber LDAP_P((ac_uint4 code));
LDAP_LUNICODE_F (int) ucgetdigit LDAP_P((ac_uint4 code));
/**************************************************************************
*

248
libraries/liblunicode/ucdata/ucgendat.c
View file

@ -55,7 +55,7 @@
* A header written to the output file with the byte-order-mark and the number
* of property nodes.
*/
static unsigned short hdr[2] = {0xfeff, 0};
static ac_uint2 hdr[2] = {0xfeff, 0};
#define NUMPROPS 50
#define NEEDPROPS (NUMPROPS + (4 - (NUMPROPS & 3)))
@ -92,9 +92,9 @@ static _prop_t props[NUMPROPS] = {
};
typedef struct {
unsigned long *ranges;
unsigned short used;
unsigned short size;
ac_uint4 *ranges;
ac_uint2 used;
ac_uint2 size;
} _ranges_t;
static _ranges_t proptbl[NUMPROPS];
@ -102,20 +102,20 @@ static _ranges_t proptbl[NUMPROPS];
/*
* Make sure this array is sized to be on a 4-byte boundary at compile time.
*/
static unsigned short propcnt[NEEDPROPS];
static ac_uint2 propcnt[NEEDPROPS];
/*
* Array used to collect a decomposition before adding it to the decomposition
* table.
*/
static unsigned long dectmp[64];
static unsigned long dectmp_size;
static ac_uint4 dectmp[64];
static ac_uint4 dectmp_size;
typedef struct {
unsigned long code;
unsigned short size;
unsigned short used;
unsigned long *decomp;
ac_uint4 code;
ac_uint2 size;
ac_uint2 used;
ac_uint4 *decomp;
} _decomp_t;
/*
@ -124,70 +124,70 @@ typedef struct {
* compatibility mappings.
*/
static _decomp_t *decomps;
static unsigned long decomps_used;
static unsigned long decomps_size;
static ac_uint4 decomps_used;
static ac_uint4 decomps_size;
static _decomp_t *kdecomps;
static unsigned long kdecomps_used;
static unsigned long kdecomps_size;
static ac_uint4 kdecomps_used;
static ac_uint4 kdecomps_size;
/*
* Composition exclusion table stuff.
*/
#define COMPEX_SET(c) (compexs[(c) >> 5] |= (1 << ((c) & 31)))
#define COMPEX_TEST(c) (compexs[(c) >> 5] & (1 << ((c) & 31)))
static unsigned long compexs[2048];
static ac_uint4 compexs[2048];
/*
* Struct for holding a composition pair, and array of composition pairs
*/
typedef struct {
unsigned long comp;
unsigned long count;
unsigned long code1;
unsigned long code2;
ac_uint4 comp;
ac_uint4 count;
ac_uint4 code1;
ac_uint4 code2;
} _comp_t;
static _comp_t *comps;
static unsigned long comps_used;
static ac_uint4 comps_used;
/*
* Types and lists for handling lists of case mappings.
*/
typedef struct {
unsigned long key;
unsigned long other1;
unsigned long other2;
ac_uint4 key;
ac_uint4 other1;
ac_uint4 other2;
} _case_t;
static _case_t *upper;
static _case_t *lower;
static _case_t *title;
static unsigned long upper_used;
static unsigned long upper_size;
static unsigned long lower_used;
static unsigned long lower_size;
static unsigned long title_used;
static unsigned long title_size;
static ac_uint4 upper_used;
static ac_uint4 upper_size;
static ac_uint4 lower_used;
static ac_uint4 lower_size;
static ac_uint4 title_used;
static ac_uint4 title_size;
/*
* Array used to collect case mappings before adding them to a list.
*/
static unsigned long cases[3];
static ac_uint4 cases[3];
/*
* An array to hold ranges for combining classes.
*/
static unsigned long *ccl;
static unsigned long ccl_used;
static unsigned long ccl_size;
static ac_uint4 *ccl;
static ac_uint4 ccl_used;
static ac_uint4 ccl_size;
/*
* Structures for handling numbers.
*/
typedef struct {
unsigned long code;
unsigned long idx;
ac_uint4 code;
ac_uint4 idx;
} _codeidx_t;
typedef struct {
@ -199,22 +199,22 @@ typedef struct {
* Arrays to hold the mapping of codes to numbers.
*/
static _codeidx_t *ncodes;
static unsigned long ncodes_used;
static unsigned long ncodes_size;
static ac_uint4 ncodes_used;
static ac_uint4 ncodes_size;
static _num_t *nums;
static unsigned long nums_used;
static unsigned long nums_size;
static ac_uint4 nums_used;
static ac_uint4 nums_size;
/*
* Array for holding numbers.
*/
static _num_t *nums;
static unsigned long nums_used;
static unsigned long nums_size;
static ac_uint4 nums_used;
static ac_uint4 nums_size;
static void
add_range(unsigned long start, unsigned long end, char *p1, char *p2)
add_range(ac_uint4 start, ac_uint4 end, char *p1, char *p2)
{
int i, j, k, len;
_ranges_t *rlp;
@ -247,12 +247,12 @@ add_range(unsigned long start, unsigned long end, char *p1, char *p2)
*/
if (rlp->used == rlp->size) {
if (rlp->size == 0)
rlp->ranges = (unsigned long *)
malloc(sizeof(unsigned long) << 3);
rlp->ranges = (ac_uint4 *)
malloc(sizeof(ac_uint4) << 3);
else
rlp->ranges = (unsigned long *)
rlp->ranges = (ac_uint4 *)
realloc((char *) rlp->ranges,
sizeof(unsigned long) * (rlp->size + 8));
sizeof(ac_uint4) * (rlp->size + 8));
rlp->size += 8;
}
@ -312,10 +312,10 @@ add_range(unsigned long start, unsigned long end, char *p1, char *p2)
}
static void
ordered_range_insert(unsigned long c, char *name, int len)
ordered_range_insert(ac_uint4 c, char *name, int len)
{
int i, j;
unsigned long s, e;
ac_uint4 s, e;
_ranges_t *rlp;
if (len == 0)
@ -355,12 +355,12 @@ ordered_range_insert(unsigned long c, char *name, int len)
*/
if (rlp->used == rlp->size) {
if (rlp->size == 0)
rlp->ranges = (unsigned long *)
malloc(sizeof(unsigned long) << 3);
rlp->ranges = (ac_uint4 *)
malloc(sizeof(ac_uint4) << 3);
else
rlp->ranges = (unsigned long *)
rlp->ranges = (ac_uint4 *)
realloc((char *) rlp->ranges,
sizeof(unsigned long) * (rlp->size + 8));
sizeof(ac_uint4) * (rlp->size + 8));
rlp->size += 8;
}
@ -437,12 +437,12 @@ ordered_range_insert(unsigned long c, char *name, int len)
}
static void
add_decomp(unsigned long code, short compat)
add_decomp(ac_uint4 code, short compat)
{
unsigned long i, j, size;
ac_uint4 i, j, size;
_decomp_t **pdecomps;
unsigned long *pdecomps_used;
unsigned long *pdecomps_size;
ac_uint4 *pdecomps_used;
ac_uint4 *pdecomps_size;
if (compat) {
pdecomps = &kdecomps;
@ -496,12 +496,12 @@ add_decomp(unsigned long code, short compat)
size = dectmp_size + (4 - (dectmp_size & 3));
if ((*pdecomps)[i].size < size) {
if ((*pdecomps)[i].size == 0)
(*pdecomps)[i].decomp = (unsigned long *)
malloc(sizeof(unsigned long) * size);
(*pdecomps)[i].decomp = (ac_uint4 *)
malloc(sizeof(ac_uint4) * size);
else
(*pdecomps)[i].decomp = (unsigned long *)
(*pdecomps)[i].decomp = (ac_uint4 *)
realloc((char *) (*pdecomps)[i].decomp,
sizeof(unsigned long) * size);
sizeof(ac_uint4) * size);
(*pdecomps)[i].size = size;
}
@ -511,7 +511,7 @@ add_decomp(unsigned long code, short compat)
(*pdecomps)[i].code = code;
(*pdecomps)[i].used = dectmp_size;
(void) AC_MEMCPY((char *) (*pdecomps)[i].decomp, (char *) dectmp,
sizeof(unsigned long) * dectmp_size);
sizeof(ac_uint4) * dectmp_size);
/*
* NOTICE: This needs changing later so it is more general than simply
@ -522,9 +522,9 @@ add_decomp(unsigned long code, short compat)
}
static void
add_title(unsigned long code)
add_title(ac_uint4 code)
{
unsigned long i, j;
ac_uint4 i, j;
/*
* Always map the code to itself.
@ -562,9 +562,9 @@ add_title(unsigned long code)
}
static void
add_upper(unsigned long code)
add_upper(ac_uint4 code)
{
unsigned long i, j;
ac_uint4 i, j;
/*
* Always map the code to itself.
@ -609,9 +609,9 @@ add_upper(unsigned long code)
}
static void
add_lower(unsigned long code)
add_lower(ac_uint4 code)
{
unsigned long i, j;
ac_uint4 i, j;
/*
* Always map the code to itself.
@ -656,16 +656,16 @@ add_lower(unsigned long code)
}
static void
ordered_ccl_insert(unsigned long c, unsigned long ccl_code)
ordered_ccl_insert(ac_uint4 c, ac_uint4 ccl_code)
{
unsigned long i, j;
ac_uint4 i, j;
if (ccl_used == ccl_size) {
if (ccl_size == 0)
ccl = (unsigned long *) malloc(sizeof(unsigned long) * 24);
ccl = (ac_uint4 *) malloc(sizeof(ac_uint4) * 24);
else
ccl = (unsigned long *)
realloc((char *) ccl, sizeof(unsigned long) * (ccl_size + 24));
ccl = (ac_uint4 *)
realloc((char *) ccl, sizeof(ac_uint4) * (ccl_size + 24));
ccl_size += 24;
}
@ -728,10 +728,10 @@ ordered_ccl_insert(unsigned long c, unsigned long ccl_code)
* Adds a number if it does not already exist and returns an index value
* multiplied by 2.
*/
static unsigned long
static ac_uint4
make_number(short num, short denom)
{
unsigned long n;
ac_uint4 n;
/*
* Determine if the number already exists.
@ -758,9 +758,9 @@ make_number(short num, short denom)
}
static void
add_number(unsigned long code, short num, short denom)
add_number(ac_uint4 code, short num, short denom)
{
unsigned long i, j;
ac_uint4 i, j;
/*
* Insert the code in order.
@ -811,7 +811,7 @@ add_number(unsigned long code, short num, short denom)
static void
read_cdata(FILE *in)
{
unsigned long i, lineno, skip, code, ccl_code;
ac_uint4 i, lineno, skip, code, ccl_code;
short wnum, neg, number[2], compat;
char line[512], *s, *e;
@ -1096,7 +1096,7 @@ read_cdata(FILE *in)
}
static _decomp_t *
find_decomp(unsigned long code, short compat)
find_decomp(ac_uint4 code, short compat)
{
long l, r, m;
_decomp_t *decs;
@ -1119,7 +1119,7 @@ find_decomp(unsigned long code, short compat)
static void
decomp_it(_decomp_t *d, short compat)
{
unsigned long i;
ac_uint4 i;
_decomp_t *dp;
for (i = 0; i < d->used; i++) {
@ -1137,7 +1137,7 @@ decomp_it(_decomp_t *d, short compat)
static void
expand_decomp(void)
{
unsigned long i;
ac_uint4 i;
for (i = 0; i < decomps_used; i++) {
dectmp_size = 0;
@ -1171,10 +1171,10 @@ cmpcomps(const void *v_comp1, const void *v_comp2)
static void
read_compexdata(FILE *in)
{
unsigned short i, code;
ac_uint2 i, code;
char line[512], *s;
(void) memset((char *) compexs, 0, sizeof(unsigned long) << 11);
(void) memset((char *) compexs, 0, sizeof(ac_uint4) << 11);
while (fgets(line, sizeof(line), in)) {
if( (s=strchr(line, '\n')) ) *s = '\0';
@ -1207,7 +1207,7 @@ read_compexdata(FILE *in)
static void
create_comps(void)
{
unsigned long i, cu;
ac_uint4 i, cu;
comps = (_comp_t *) malloc(comps_used * sizeof(_comp_t));
@ -1229,8 +1229,8 @@ write_cdata(char *opath)
{
FILE *out;
ac_uint4 bytes;
unsigned long i, idx, nprops;
unsigned short casecnt[2];
ac_uint4 i, idx, nprops;
ac_uint2 casecnt[2];
char path[BUFSIZ];
/*****************************************************************
@ -1273,10 +1273,10 @@ write_cdata(char *opath)
* Calculate the byte count needed and pad the property counts array to a
* 4-byte boundary.
*/
if ((bytes = sizeof(unsigned short) * (NUMPROPS + 1)) & 3)
if ((bytes = sizeof(ac_uint2) * (NUMPROPS + 1)) & 3)
bytes += 4 - (bytes & 3);
nprops = bytes / sizeof(unsigned short);
bytes += sizeof(unsigned long) * idx;
nprops = bytes / sizeof(ac_uint2);
bytes += sizeof(ac_uint4) * idx;
/*
* Write the header.
@ -1286,19 +1286,19 @@ write_cdata(char *opath)
/*
* Write the byte count.
*/
fwrite((char *) &bytes, sizeof(unsigned long), 1, out);
fwrite((char *) &bytes, sizeof(ac_uint4), 1, out);
/*
* Write the property list counts.
*/
fwrite((char *) propcnt, sizeof(unsigned short), nprops, out);
fwrite((char *) propcnt, sizeof(ac_uint2), nprops, out);
/*
* Write the property lists.
*/
for (i = 0; i < NUMPROPS; i++) {
if (proptbl[i].used > 0)
fwrite((char *) proptbl[i].ranges, sizeof(unsigned long),
fwrite((char *) proptbl[i].ranges, sizeof(ac_uint4),
proptbl[i].used, out);
}
@ -1327,12 +1327,12 @@ write_cdata(char *opath)
/*
* Write the header.
*/
fwrite((char *) hdr, sizeof(unsigned short), 2, out);
fwrite((char *) hdr, sizeof(ac_uint2), 2, out);
/*
* Write the upper and lower case table sizes.
*/
fwrite((char *) casecnt, sizeof(unsigned short), 2, out);
fwrite((char *) casecnt, sizeof(ac_uint2), 2, out);
if (upper_used > 0)
/*
@ -1375,14 +1375,14 @@ write_cdata(char *opath)
/*
* Write the header.
*/
hdr[1] = (unsigned short) comps_used * 4;
fwrite((char *) hdr, sizeof(unsigned short), 2, out);
hdr[1] = (ac_uint2) comps_used * 4;
fwrite((char *) hdr, sizeof(ac_uint2), 2, out);
/*
* Write out the byte count to maintain header size.
*/
bytes = comps_used * sizeof(_comp_t);
fwrite((char *) &bytes, sizeof(unsigned long), 1, out);
fwrite((char *) &bytes, sizeof(ac_uint4), 1, out);
/*
* Now, if comps exist, write them out.
@ -1415,44 +1415,44 @@ write_cdata(char *opath)
/*
* Write the header.
*/
fwrite((char *) hdr, sizeof(unsigned short), 2, out);
fwrite((char *) hdr, sizeof(ac_uint2), 2, out);
/*
* Write a temporary byte count which will be calculated as the
* decompositions are written out.
*/
bytes = 0;
fwrite((char *) &bytes, sizeof(unsigned long), 1, out);
fwrite((char *) &bytes, sizeof(ac_uint4), 1, out);
if (decomps_used) {
/*
* Write the list of decomp nodes.
*/
for (i = idx = 0; i < decomps_used; i++) {
fwrite((char *) &decomps[i].code, sizeof(unsigned long), 1, out);
fwrite((char *) &idx, sizeof(unsigned long), 1, out);
fwrite((char *) &decomps[i].code, sizeof(ac_uint4), 1, out);
fwrite((char *) &idx, sizeof(ac_uint4), 1, out);
idx += decomps[i].used;
}
/*
* Write the sentinel index as the last decomp node.
*/
fwrite((char *) &idx, sizeof(unsigned long), 1, out);
fwrite((char *) &idx, sizeof(ac_uint4), 1, out);
/*
* Write the decompositions themselves.
*/
for (i = 0; i < decomps_used; i++)
fwrite((char *) decomps[i].decomp, sizeof(unsigned long),
fwrite((char *) decomps[i].decomp, sizeof(ac_uint4),
decomps[i].used, out);
/*
* Seek back to the beginning and write the byte count.
*/
bytes = (sizeof(unsigned long) * idx) +
(sizeof(unsigned long) * ((hdr[1] << 1) + 1));
fseek(out, sizeof(unsigned short) << 1, 0L);
fwrite((char *) &bytes, sizeof(unsigned long), 1, out);
bytes = (sizeof(ac_uint4) * idx) +
(sizeof(ac_uint4) * ((hdr[1] << 1) + 1));
fseek(out, sizeof(ac_uint2) << 1, 0L);
fwrite((char *) &bytes, sizeof(ac_uint4), 1, out);
fclose(out);
}
@ -1469,44 +1469,44 @@ write_cdata(char *opath)
/*
* Write the header.
*/
fwrite((char *) hdr, sizeof(unsigned short), 2, out);
fwrite((char *) hdr, sizeof(ac_uint2), 2, out);
/*
* Write a temporary byte count which will be calculated as the
* decompositions are written out.
*/
bytes = 0;
fwrite((char *) &bytes, sizeof(unsigned long), 1, out);
fwrite((char *) &bytes, sizeof(ac_uint4), 1, out);
if (kdecomps_used) {
/*
* Write the list of kdecomp nodes.
*/
for (i = idx = 0; i < kdecomps_used; i++) {
fwrite((char *) &kdecomps[i].code, sizeof(unsigned long), 1, out);
fwrite((char *) &idx, sizeof(unsigned long), 1, out);
fwrite((char *) &kdecomps[i].code, sizeof(ac_uint4), 1, out);
fwrite((char *) &idx, sizeof(ac_uint4), 1, out);
idx += kdecomps[i].used;
}
/*
* Write the sentinel index as the last decomp node.
*/
fwrite((char *) &idx, sizeof(unsigned long), 1, out);
fwrite((char *) &idx, sizeof(ac_uint4), 1, out);
/*
* Write the decompositions themselves.
*/
for (i = 0; i < kdecomps_used; i++)
fwrite((char *) kdecomps[i].decomp, sizeof(unsigned long),
fwrite((char *) kdecomps[i].decomp, sizeof(ac_uint4),
kdecomps[i].used, out);
/*
* Seek back to the beginning and write the byte count.
*/
bytes = (sizeof(unsigned long) * idx) +
(sizeof(unsigned long) * ((hdr[1] << 1) + 1));
fseek(out, sizeof(unsigned short) << 1, 0L);
fwrite((char *) &bytes, sizeof(unsigned long), 1, out);
bytes = (sizeof(ac_uint4) * idx) +
(sizeof(ac_uint4) * ((hdr[1] << 1) + 1));
fseek(out, sizeof(ac_uint2) << 1, 0L);
fwrite((char *) &bytes, sizeof(ac_uint4), 1, out);
fclose(out);
}
@ -1533,19 +1533,19 @@ write_cdata(char *opath)
/*
* Write the header.
*/
fwrite((char *) hdr, sizeof(unsigned short), 2, out);
fwrite((char *) hdr, sizeof(ac_uint2), 2, out);
/*
* Write out the byte count to maintain header size.
*/
bytes = ccl_used * sizeof(unsigned long);
fwrite((char *) &bytes, sizeof(unsigned long), 1, out);
bytes = ccl_used * sizeof(ac_uint4);
fwrite((char *) &bytes, sizeof(ac_uint4), 1, out);
if (ccl_used > 0)
/*
* Write the combining class ranges out.
*/
fwrite((char *) ccl, sizeof(unsigned long), ccl_used, out);
fwrite((char *) ccl, sizeof(ac_uint4), ccl_used, out);
fclose(out);
@ -1566,18 +1566,18 @@ write_cdata(char *opath)
* The count part of the header will be the total number of codes that
* have numbers.
*/
hdr[1] = (unsigned short) (ncodes_used << 1);
hdr[1] = (ac_uint2) (ncodes_used << 1);
bytes = (ncodes_used * sizeof(_codeidx_t)) + (nums_used * sizeof(_num_t));
/*
* Write the header.
*/
fwrite((char *) hdr, sizeof(unsigned short), 2, out);
fwrite((char *) hdr, sizeof(ac_uint2), 2, out);
/*
* Write out the byte count to maintain header size.
*/
fwrite((char *) &bytes, sizeof(unsigned long), 1, out);
fwrite((char *) &bytes, sizeof(ac_uint4), 1, out);
/*
* Now, if number mappings exist, write them out.

7
libraries/liblunicode/ucstr.c
View file

@ -15,6 +15,7 @@
#include "portable.h"
#include <ac/bytes.h>
#include <ac/ctype.h>
#include <ac/string.h>
#include <ac/stdlib.h>
@ -109,7 +110,7 @@ struct berval * UTF8bvnormalize(
{
int i, j, len, clen, outpos, ucsoutlen, outsize, last;
char *out, *outtmp, *s;
unsigned long *ucs, *p, *ucsout;
ac_uint4 *ucs, *p, *ucsout;
static unsigned char mask[] = {
0, 0x7f, 0x1f, 0x0f, 0x07, 0x03, 0x01 };
@ -302,7 +303,7 @@ int UTF8bvnormcmp(
{
int i, l1, l2, len, ulen, res = 0;
char *s1, *s2, *done;
unsigned long *ucs, *ucsout1, *ucsout2;
ac_uint4 *ucs, *ucsout1, *ucsout2;
unsigned casefold = flags & LDAP_UTF8_CASEFOLD;
unsigned norm1 = flags & LDAP_UTF8_ARG1NFC;
@ -382,7 +383,7 @@ int UTF8bvnormcmp(
/*
* XXYYZ: we convert to ucs4 even though -llunicode
* expects ucs2 in an unsigned long
* expects ucs2 in an ac_uint4
*/
/* convert and normalize 1st string */

3
libraries/liblunicode/ure/urestubs.c
View file

@ -36,6 +36,9 @@
*/
/* $Id: urestubs.c,v 1.2 1999/09/21 15:47:44 mleisher Exp $" */
#include "portable.h"
#include <ac/bytes.h>
#include "ure.h"
#ifdef _MSC_VER

7
libraries/liblutil/csn.c
View file

@ -57,6 +57,9 @@ lutil_csnstr(char *buf, size_t len, unsigned int replica, unsigned int mod)
time_t t;
unsigned int op;
struct tm *ltm;
#ifdef HAVE_GMTIME_R
struct tm ltm_buf;
#endif
int n;
time( &t );
@ -66,7 +69,11 @@ lutil_csnstr(char *buf, size_t len, unsigned int replica, unsigned int mod)
}
op = ++csnop;
#ifdef HAVE_GMTIME_R
ltm = gmtime_r( &t, &ltm_buf );
#else
ltm = gmtime( &t );
#endif
n = snprintf( buf, len,
"%4d%02d%02d%02d%02d%02dZ#%06x#%02x#%06x",
ltm->tm_year + 1900, ltm->tm_mon + 1, ltm->tm_mday, ltm->tm_hour,

27
libraries/liblutil/passwd.c
View file

@ -1,5 +1,4 @@
/* $OpenLDAP$ */
/* $OpenLDAP$ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1998-2003 The OpenLDAP Foundation.
@ -102,6 +101,8 @@ struct pw_slist {
/* password check routines */
#define SALT_SIZE 4
static LUTIL_PASSWD_CHK_FUNC chk_md5;
static LUTIL_PASSWD_CHK_FUNC chk_smd5;
static LUTIL_PASSWD_HASH_FUNC hash_smd5;
@ -484,7 +485,8 @@ static int chk_ssha1(
unsigned char *orig_pass = NULL;
/* safety check */
if (LUTIL_BASE64_DECODE_LEN(passwd->bv_len) <= sizeof(SHA1digest)) {
if (LUTIL_BASE64_DECODE_LEN(passwd->bv_len) <
sizeof(SHA1digest)+SALT_SIZE) {
return -1;
}
@ -496,7 +498,7 @@ static int chk_ssha1(
rc = lutil_b64_pton(passwd->bv_val, orig_pass, passwd->bv_len);
if (rc < 0 || (unsigned)rc <= sizeof(SHA1digest)) {
if (rc < (int)(sizeof(SHA1digest)+SALT_SIZE)) {
ber_memfree(orig_pass);
return -1;
}
@ -527,6 +529,11 @@ static int chk_sha1(
int rc;
unsigned char *orig_pass = NULL;
/* safety check */
if (LUTIL_BASE64_DECODE_LEN(passwd->bv_len) < sizeof(SHA1digest)) {
return -1;
}
/* base64 un-encode password */
orig_pass = (unsigned char *) ber_memalloc( (size_t) (
LUTIL_BASE64_DECODE_LEN(passwd->bv_len) + 1) );
@ -565,7 +572,8 @@ static int chk_smd5(
unsigned char *orig_pass = NULL;
/* safety check */
if (LUTIL_BASE64_DECODE_LEN(passwd->bv_len) <= sizeof(MD5digest)) {
if (LUTIL_BASE64_DECODE_LEN(passwd->bv_len) <
sizeof(MD5digest)+SALT_SIZE) {
return -1;
}
@ -577,7 +585,7 @@ static int chk_smd5(
rc = lutil_b64_pton(passwd->bv_val, orig_pass, passwd->bv_len);
if (rc < 0 || (unsigned)rc <= sizeof(MD5digest)) {
if (rc < (int)(sizeof(MD5digest)+SALT_SIZE)) {
ber_memfree(orig_pass);
return -1;
}
@ -609,6 +617,11 @@ static int chk_md5(
int rc;
unsigned char *orig_pass = NULL;
/* safety check */
if (LUTIL_BASE64_DECODE_LEN(passwd->bv_len) < sizeof(MD5digest)) {
return -1;
}
/* base64 un-encode password */
orig_pass = (unsigned char *) ber_memalloc( (size_t) (
LUTIL_BASE64_DECODE_LEN(passwd->bv_len) + 1) );
@ -1174,7 +1187,7 @@ static struct berval *hash_ssha1(
{
lutil_SHA1_CTX SHA1context;
unsigned char SHA1digest[LUTIL_SHA1_BYTES];
char saltdata[4];
char saltdata[SALT_SIZE];
struct berval digest;
struct berval salt;
@ -1224,7 +1237,7 @@ static struct berval *hash_smd5(
{
lutil_MD5_CTX MD5context;
unsigned char MD5digest[LUTIL_MD5_BYTES];
char saltdata[4];
char saltdata[SALT_SIZE];
struct berval digest;
struct berval salt;

33
libraries/librewrite/config.c
View file

@ -1,26 +1,21 @@
/******************************************************************************
/* $OpenLDAP$ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright (C) 2000 Pierangelo Masarati, <ando@sys-net.it>
* Copyright 2000-2003 The OpenLDAP Foundation.
* All rights reserved.
*
* Permission is granted to anyone to use this software for any purpose
* on any computer system, and to alter it and redistribute it, subject
* to the following restrictions:
* Redistribution and use in source and binary forms, with or without
* modification, are permitted only as authorized by the OpenLDAP
* Public License.
*
* 1. The author is not responsible for the consequences of use of this
* software, no matter how awful, even if they arise from flaws in it.
*
* 2. The origin of this software must not be misrepresented, either by
* explicit claim or by omission. Since few users ever read sources,
* credits should appear in the documentation.
*
* 3. Altered versions must be plainly marked as such, and must not be
* misrepresented as being the original software. Since few users
* ever read sources, credits should appear in the documentation.
*
* 4. This notice may not be removed or altered.
*
******************************************************************************/
* 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>.
*/
/* ACKNOWLEDGEMENT:
* This work was initially developed by Pierangelo Masarati for
* inclusion in OpenLDAP Software.
*/
#include <portable.h>

33
libraries/librewrite/context.c
View file

@ -1,26 +1,21 @@
/******************************************************************************
/* $OpenLDAP$ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright (C) 2000 Pierangelo Masarati, <ando@sys-net.it>
* Copyright 2000-2003 The OpenLDAP Foundation.
* All rights reserved.
*
* Permission is granted to anyone to use this software for any purpose
* on any computer system, and to alter it and redistribute it, subject
* to the following restrictions:
* Redistribution and use in source and binary forms, with or without
* modification, are permitted only as authorized by the OpenLDAP
* Public License.
*
* 1. The author is not responsible for the consequences of use of this
* software, no matter how awful, even if they arise from flaws in it.
*
* 2. The origin of this software must not be misrepresented, either by
* explicit claim or by omission. Since few users ever read sources,
* credits should appear in the documentation.
*
* 3. Altered versions must be plainly marked as such, and must not be
* misrepresented as being the original software. Since few users
* ever read sources, credits should appear in the documentation.
*
* 4. This notice may not be removed or altered.
*
******************************************************************************/
* 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>.
*/
/* ACKNOWLEDGEMENT:
* This work was initially developed by Pierangelo Masarati for
* inclusion in OpenLDAP Software.
*/
#include <portable.h>

33
libraries/librewrite/info.c
View file

@ -1,26 +1,21 @@
/******************************************************************************
/* $OpenLDAP$ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright (C) 2000 Pierangelo Masarati, <ando@sys-net.it>
* Copyright 2000-2003 The OpenLDAP Foundation.
* All rights reserved.
*
* Permission is granted to anyone to use this software for any purpose
* on any computer system, and to alter it and redistribute it, subject
* to the following restrictions:
* Redistribution and use in source and binary forms, with or without
* modification, are permitted only as authorized by the OpenLDAP
* Public License.
*
* 1. The author is not responsible for the consequences of use of this
* software, no matter how awful, even if they arise from flaws in it.
*
* 2. The origin of this software must not be misrepresented, either by
* explicit claim or by omission. Since few users ever read sources,
* credits should appear in the documentation.
*
* 3. Altered versions must be plainly marked as such, and must not be
* misrepresented as being the original software. Since few users
* ever read sources, credits should appear in the documentation.
*
* 4. This notice may not be removed or altered.
*
******************************************************************************/
* 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>.
*/
/* ACKNOWLEDGEMENT:
* This work was initially developed by Pierangelo Masarati for
* inclusion in OpenLDAP Software.
*/
#include <portable.h>

34
libraries/librewrite/ldapmap.c
View file

@ -1,29 +1,25 @@
/******************************************************************************
/* $OpenLDAP$ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright (C) 2000 Pierangelo Masarati, <ando@sys-net.it>
* Copyright 2000-2003 The OpenLDAP Foundation.
* All rights reserved.
*
* Permission is granted to anyone to use this software for any purpose
* on any computer system, and to alter it and redistribute it, subject
* to the following restrictions:
* Redistribution and use in source and binary forms, with or without
* modification, are permitted only as authorized by the OpenLDAP
* Public License.
*
* 1. The author is not responsible for the consequences of use of this
* software, no matter how awful, even if they arise from flaws in it.
*
* 2. The origin of this software must not be misrepresented, either by
* explicit claim or by omission. Since few users ever read sources,
* credits should appear in the documentation.
*
* 3. Altered versions must be plainly marked as such, and must not be
* misrepresented as being the original software. Since few users
* ever read sources, credits should appear in the documentation.
*
* 4. This notice may not be removed or altered.
*
******************************************************************************/
* 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>.
*/
/* ACKNOWLEDGEMENT:
* This work was initially developed by Pierangelo Masarati for
* inclusion in OpenLDAP Software.
*/
#include <portable.h>
#define LDAP_DEPRECATED 1
#include "rewrite-int.h"
#include "rewrite-map.h"

33
libraries/librewrite/map.c
View file

@ -1,26 +1,21 @@
/******************************************************************************
/* $OpenLDAP$ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright (C) 2000 Pierangelo Masarati, <ando@sys-net.it>
* Copyright 2000-2003 The OpenLDAP Foundation.
* All rights reserved.
*
* Permission is granted to anyone to use this software for any purpose
* on any computer system, and to alter it and redistribute it, subject
* to the following restrictions:
* Redistribution and use in source and binary forms, with or without
* modification, are permitted only as authorized by the OpenLDAP
* Public License.
*
* 1. The author is not responsible for the consequences of use of this
* software, no matter how awful, even if they arise from flaws in it.
*
* 2. The origin of this software must not be misrepresented, either by
* explicit claim or by omission. Since few users ever read sources,
* credits should appear in the documentation.
*
* 3. Altered versions must be plainly marked as such, and must not be
* misrepresented as being the original software. Since few users
* ever read sources, credits should appear in the documentation.
*
* 4. This notice may not be removed or altered.
*
******************************************************************************/
* 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>.
*/
/* ACKNOWLEDGEMENT:
* This work was initially developed by Pierangelo Masarati for
* inclusion in OpenLDAP Software.
*/
#include <portable.h>

33
libraries/librewrite/params.c
View file

@ -1,26 +1,21 @@
/******************************************************************************
/* $OpenLDAP$ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright (C) 2000 Pierangelo Masarati, <ando@sys-net.it>
* Copyright 2000-2003 The OpenLDAP Foundation.
* All rights reserved.
*
* Permission is granted to anyone to use this software for any purpose
* on any computer system, and to alter it and redistribute it, subject
* to the following restrictions:
* Redistribution and use in source and binary forms, with or without
* modification, are permitted only as authorized by the OpenLDAP
* Public License.
*
* 1. The author is not responsible for the consequences of use of this
* software, no matter how awful, even if they arise from flaws in it.
*
* 2. The origin of this software must not be misrepresented, either by
* explicit claim or by omission. Since few users ever read sources,
* credits should appear in the documentation.
*
* 3. Altered versions must be plainly marked as such, and must not be
* misrepresented as being the original software. Since few users
* ever read sources, credits should appear in the documentation.
*
* 4. This notice may not be removed or altered.
*
******************************************************************************/
* 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>.
*/
/* ACKNOWLEDGEMENT:
* This work was initially developed by Pierangelo Masarati for
* inclusion in OpenLDAP Software.
*/
#include <portable.h>

33
libraries/librewrite/parse.c
View file

@ -1,26 +1,21 @@
/******************************************************************************
/* $OpenLDAP$ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright (C) 2000 Pierangelo Masarati, <ando@sys-net.it>
* Copyright 2000-2003 The OpenLDAP Foundation.
* All rights reserved.
*
* Permission is granted to anyone to use this software for any purpose
* on any computer system, and to alter it and redistribute it, subject
* to the following restrictions:
* Redistribution and use in source and binary forms, with or without
* modification, are permitted only as authorized by the OpenLDAP
* Public License.
*
* 1. The author is not responsible for the consequences of use of this
* software, no matter how awful, even if they arise from flaws in it.
*
* 2. The origin of this software must not be misrepresented, either by
* explicit claim or by omission. Since few users ever read sources,
* credits should appear in the documentation.
*
* 3. Altered versions must be plainly marked as such, and must not be
* misrepresented as being the original software. Since few users
* ever read sources, credits should appear in the documentation.
*
* 4. This notice may not be removed or altered.
*
******************************************************************************/
* 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>.
*/
/* ACKNOWLEDGEMENT:
* This work was initially developed by Pierangelo Masarati for
* inclusion in OpenLDAP Software.
*/
#include <portable.h>

33
libraries/librewrite/rewrite-int.h
View file

@ -1,26 +1,21 @@
/******************************************************************************
/* $OpenLDAP$ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright (C) 2000 Pierangelo Masarati, <ando@sys-net.it>
* Copyright 2000-2003 The OpenLDAP Foundation.
* All rights reserved.
*
* Permission is granted to anyone to use this software for any purpose
* on any computer system, and to alter it and redistribute it, subject
* to the following restrictions:
* Redistribution and use in source and binary forms, with or without
* modification, are permitted only as authorized by the OpenLDAP
* Public License.
*
* 1. The author is not responsible for the consequences of use of this
* software, no matter how awful, even if they arise from flaws in it.
*
* 2. The origin of this software must not be misrepresented, either by
* explicit claim or by omission. Since few users ever read sources,
* credits should appear in the documentation.
*
* 3. Altered versions must be plainly marked as such, and must not be
* misrepresented as being the original software. Since few users
* ever read sources, credits should appear in the documentation.
*
* 4. This notice may not be removed or altered.
*
******************************************************************************/
* 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>.
*/
/* ACKNOWLEDGEMENT:
* This work was initially developed by Pierangelo Masarati for
* inclusion in OpenLDAP Software.
*/
#ifndef REWRITE_INT_H
#define REWRITE_INT_H

33
libraries/librewrite/rewrite-map.h
View file

@ -1,26 +1,21 @@
/******************************************************************************
/* $OpenLDAP$ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright (C) 2000 Pierangelo Masarati, <ando@sys-net.it>
* Copyright 2000-2003 The OpenLDAP Foundation.
* All rights reserved.
*
* Permission is granted to anyone to use this software for any purpose
* on any computer system, and to alter it and redistribute it, subject
* to the following restrictions:
* Redistribution and use in source and binary forms, with or without
* modification, are permitted only as authorized by the OpenLDAP
* Public License.
*
* 1. The author is not responsible for the consequences of use of this
* software, no matter how awful, even if they arise from flaws in it.
*
* 2. The origin of this software must not be misrepresented, either by
* explicit claim or by omission. Since few users ever read sources,
* credits should appear in the documentation.
*
* 3. Altered versions must be plainly marked as such, and must not be
* misrepresented as being the original software. Since few users
* ever read sources, credits should appear in the documentation.
*
* 4. This notice may not be removed or altered.
*
******************************************************************************/
* 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>.
*/
/* ACKNOWLEDGEMENT:
* This work was initially developed by Pierangelo Masarati for
* inclusion in OpenLDAP Software.
*/
#ifndef MAP_H
#define MAP_H

33
libraries/librewrite/rewrite.c
View file

@ -1,26 +1,21 @@
/******************************************************************************
/* $OpenLDAP$ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright (C) 2000 Pierangelo Masarati, <ando@sys-net.it>
* Copyright 2000-2003 The OpenLDAP Foundation.
* All rights reserved.
*
* Permission is granted to anyone to use this software for any purpose
* on any computer system, and to alter it and redistribute it, subject
* to the following restrictions:
* Redistribution and use in source and binary forms, with or without
* modification, are permitted only as authorized by the OpenLDAP
* Public License.
*
* 1. The author is not responsible for the consequences of use of this
* software, no matter how awful, even if they arise from flaws in it.
*
* 2. The origin of this software must not be misrepresented, either by
* explicit claim or by omission. Since few users ever read sources,
* credits should appear in the documentation.
*
* 3. Altered versions must be plainly marked as such, and must not be
* misrepresented as being the original software. Since few users
* ever read sources, credits should appear in the documentation.
*
* 4. This notice may not be removed or altered.
*
******************************************************************************/
* 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>.
*/
/* ACKNOWLEDGEMENT:
* This work was initially developed by Pierangelo Masarati for
* inclusion in OpenLDAP Software.
*/
#include <portable.h>

33
libraries/librewrite/rule.c
View file

@ -1,26 +1,21 @@
/******************************************************************************
/* $OpenLDAP$ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright (C) 2000 Pierangelo Masarati, <ando@sys-net.it>
* Copyright 2000-2003 The OpenLDAP Foundation.
* All rights reserved.
*
* Permission is granted to anyone to use this software for any purpose
* on any computer system, and to alter it and redistribute it, subject
* to the following restrictions:
* Redistribution and use in source and binary forms, with or without
* modification, are permitted only as authorized by the OpenLDAP
* Public License.
*
* 1. The author is not responsible for the consequences of use of this
* software, no matter how awful, even if they arise from flaws in it.
*
* 2. The origin of this software must not be misrepresented, either by
* explicit claim or by omission. Since few users ever read sources,
* credits should appear in the documentation.
*
* 3. Altered versions must be plainly marked as such, and must not be
* misrepresented as being the original software. Since few users
* ever read sources, credits should appear in the documentation.
*
* 4. This notice may not be removed or altered.
*
******************************************************************************/
* 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>.
*/
/* ACKNOWLEDGEMENT:
* This work was initially developed by Pierangelo Masarati for
* inclusion in OpenLDAP Software.
*/
#include <portable.h>

33
libraries/librewrite/session.c
View file

@ -1,26 +1,21 @@
/******************************************************************************
/* $OpenLDAP$ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright (C) 2000 Pierangelo Masarati, <ando@sys-net.it>
* Copyright 2000-2003 The OpenLDAP Foundation.
* All rights reserved.
*
* Permission is granted to anyone to use this software for any purpose
* on any computer system, and to alter it and redistribute it, subject
* to the following restrictions:
* Redistribution and use in source and binary forms, with or without
* modification, are permitted only as authorized by the OpenLDAP
* Public License.
*
* 1. The author is not responsible for the consequences of use of this
* software, no matter how awful, even if they arise from flaws in it.
*
* 2. The origin of this software must not be misrepresented, either by
* explicit claim or by omission. Since few users ever read sources,
* credits should appear in the documentation.
*
* 3. Altered versions must be plainly marked as such, and must not be
* misrepresented as being the original software. Since few users
* ever read sources, credits should appear in the documentation.
*
* 4. This notice may not be removed or altered.
*
******************************************************************************/
* 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>.
*/
/* ACKNOWLEDGEMENT:
* This work was initially developed by Pierangelo Masarati for
* inclusion in OpenLDAP Software.
*/
#include <portable.h>

33
libraries/librewrite/subst.c
View file

@ -1,26 +1,21 @@
/******************************************************************************
/* $OpenLDAP$ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright (C) 2000 Pierangelo Masarati, <ando@sys-net.it>
* Copyright 2000-2003 The OpenLDAP Foundation.
* All rights reserved.
*
* Permission is granted to anyone to use this software for any purpose
* on any computer system, and to alter it and redistribute it, subject
* to the following restrictions:
* Redistribution and use in source and binary forms, with or without
* modification, are permitted only as authorized by the OpenLDAP
* Public License.
*
* 1. The author is not responsible for the consequences of use of this
* software, no matter how awful, even if they arise from flaws in it.
*
* 2. The origin of this software must not be misrepresented, either by
* explicit claim or by omission. Since few users ever read sources,
* credits should appear in the documentation.
*
* 3. Altered versions must be plainly marked as such, and must not be
* misrepresented as being the original software. Since few users
* ever read sources, credits should appear in the documentation.
*
* 4. This notice may not be removed or altered.
*
******************************************************************************/
* 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>.
*/
/* ACKNOWLEDGEMENT:
* This work was initially developed by Pierangelo Masarati for
* inclusion in OpenLDAP Software.
*/
#include <portable.h>

33
libraries/librewrite/var.c
View file

@ -1,26 +1,21 @@
/******************************************************************************
/* $OpenLDAP$ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright (C) 2000 Pierangelo Masarati, <ando@sys-net.it>
* Copyright 2000-2003 The OpenLDAP Foundation.
* All rights reserved.
*
* Permission is granted to anyone to use this software for any purpose
* on any computer system, and to alter it and redistribute it, subject
* to the following restrictions:
* Redistribution and use in source and binary forms, with or without
* modification, are permitted only as authorized by the OpenLDAP
* Public License.
*
* 1. The author is not responsible for the consequences of use of this
* software, no matter how awful, even if they arise from flaws in it.
*
* 2. The origin of this software must not be misrepresented, either by
* explicit claim or by omission. Since few users ever read sources,
* credits should appear in the documentation.
*
* 3. Altered versions must be plainly marked as such, and must not be
* misrepresented as being the original software. Since few users
* ever read sources, credits should appear in the documentation.
*
* 4. This notice may not be removed or altered.
*
******************************************************************************/
* 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>.
*/
/* ACKNOWLEDGEMENT:
* This work was initially developed by Pierangelo Masarati for
* inclusion in OpenLDAP Software.
*/
#include <portable.h>

34
libraries/librewrite/xmap.c
View file

@ -1,26 +1,21 @@
/******************************************************************************
/* $OpenLDAP$ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright (C) 2000 Pierangelo Masarati, <ando@sys-net.it>
* Copyright 2000-2003 The OpenLDAP Foundation.
* All rights reserved.
*
* Permission is granted to anyone to use this software for any purpose
* on any computer system, and to alter it and redistribute it, subject
* to the following restrictions:
* Redistribution and use in source and binary forms, with or without
* modification, are permitted only as authorized by the OpenLDAP
* Public License.
*
* 1. The author is not responsible for the consequences of use of this
* software, no matter how awful, even if they arise from flaws in it.
*
* 2. The origin of this software must not be misrepresented, either by
* explicit claim or by omission. Since few users ever read sources,
* credits should appear in the documentation.
*
* 3. Altered versions must be plainly marked as such, and must not be
* misrepresented as being the original software. Since few users
* ever read sources, credits should appear in the documentation.
*
* 4. This notice may not be removed or altered.
*
******************************************************************************/
* 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>.
*/
/* ACKNOWLEDGEMENT:
* This work was initially developed by Pierangelo Masarati for
* inclusion in OpenLDAP Software.
*/
#include <portable.h>
@ -30,6 +25,7 @@
#include <pwd.h>
#endif
#define LDAP_DEPRECATED 1
#include "rewrite-int.h"
#include "rewrite-map.h"

17
servers/slapd/Makefile.in
View file

@ -14,9 +14,11 @@
## <http://www.OpenLDAP.org/license.html>.
PROGRAMS=slapd
XPROGRAMS=sslapd libbackends.a .backend
XPROGRAMS=sslapd libbackends.a .backend liboverlays.a
XSRCS=version.c
SUBDIRS=back-* shell-backends slapi overlays tools
NT_SRCS = nt_svc.c
NT_OBJS = nt_svc.o ../../libraries/liblutil/slapdmsg.res
@ -52,7 +54,7 @@ LDAP_INCDIR= ../../include -I$(srcdir)/slapi
LDAP_LIBDIR= ../../libraries
SLAP_DIR=
SLAPD_STATIC_DEPENDS=@SLAPD_NO_STATIC@ libbackends.a
SLAPD_STATIC_DEPENDS=@SLAPD_NO_STATIC@ libbackends.a liboverlays.a
SLAPD_STATIC_BACKENDS=@SLAPD_STATIC_BACKENDS@
SLAPD_DYNAMIC_BACKENDS=@SLAPD_DYNAMIC_BACKENDS@
@ -297,6 +299,9 @@ libbackends.a: .backend
fi
@ls -l libbackends.a; echo ""
liboverlays.a: FORCE
@cd overlays; $(MAKE) $(MFLAGS) all
version.c: Makefile
@-$(RM) $@
$(MKVERSION) -s -n Versionstr slapd > $@
@ -304,7 +309,7 @@ version.c: Makefile
version.o: version.c $(OBJS) $(SLAPD_LIBDEPEND)
depend-local-srv: FORCE
@for i in back-* shell-backends slapi tools; do \
@for i in $(SUBDIRS); do \
if test -d $$i -a -f $$i/Makefile ; then \
echo; echo " cd $$i; $(MAKE) $(MFLAGS) depend"; \
( cd $$i; $(MAKE) $(MFLAGS) depend ); \
@ -317,7 +322,7 @@ clean-local:
rm -f *.exp *.def *.base *.a *.objs symdummy.c
clean-local-srv: FORCE
@for i in back-* shell-backends slapi tools; do \
@for i in $(SUBDIRS); do \
if test -d $$i -a -f $$i/Makefile ; then \
echo; echo " cd $$i; $(MAKE) $(MFLAGS) clean"; \
( cd $$i; $(MAKE) $(MFLAGS) clean ); \
@ -327,7 +332,7 @@ clean-local-srv: FORCE
rm -f *.tmp all-cffiles
veryclean-local-srv: FORCE
@for i in back-* shell-backends slapi tools; do \
@for i in $(SUBDIRS); do \
if test -d $$i -a -f $$i/Makefile ; then \
echo; echo " cd $$i; $(MAKE) $(MFLAGS) clean"; \
( cd $$i; $(MAKE) $(MFLAGS) veryclean ); \
@ -341,7 +346,7 @@ install-slapd: FORCE
-$(MKDIR) $(DESTDIR)$(localstatedir)
$(LTINSTALL) $(INSTALLFLAGS) -s -m 755 \
slapd$(EXEEXT) $(DESTDIR)$(libexecdir)
@for i in back-* shell-backends slapi tools; do \
@for i in $(SUBDIRS); do \
if test -d $$i -a -f $$i/Makefile ; then \
echo; echo " cd $$i; $(MAKE) $(MFLAGS) install"; \
( cd $$i; $(MAKE) $(MFLAGS) install ); \

41
servers/slapd/add.c
View file

@ -588,15 +588,15 @@ int
slap_entry2mods(
Entry *e,
Modifications **mods,
const char **text
)
const char **text,
char *textbuf, size_t textlen )
{
Modifications *modhead = NULL;
Modifications *mod;
Modifications **modtail = &modhead;
Attribute *a_new;
AttributeDescription *a_new_desc;
int i, count, rc;
int i, count;
a_new = e->e_attrs;
@ -604,12 +604,9 @@ slap_entry2mods(
a_new_desc = a_new->a_desc;
mod = (Modifications *) malloc( sizeof( Modifications ));
if ( a_new_desc != slap_schema.si_ad_queryid )
mod->sml_op = LDAP_MOD_REPLACE;
else
mod->sml_op = LDAP_MOD_ADD;
mod->sml_op = LDAP_MOD_REPLACE;
ber_dupbv( &mod->sml_type, &a_new_desc->ad_cname );
mod->sml_type = a_new_desc->ad_cname;
for ( count = 0; a_new->a_vals[count].bv_val; count++ );
@ -675,16 +672,20 @@ static int doPreAddPluginFNs( Operation *op )
* entire operation.
*/
#ifdef NEW_LOGGING
LDAP_LOG( OPERATION, INFO, "do_add: add preoperation plugin failed\n",
0, 0, 0);
LDAP_LOG( OPERATION, INFO,
"do_add: add preoperation plugin failed\n",
0, 0, 0);
#else
Debug(LDAP_DEBUG_TRACE, "do_add: add preoperation plugin failed.\n",
0, 0, 0);
if ( ( slapi_pblock_get( op->o_pb, SLAPI_RESULT_CODE, (void *)&rc ) != 0 ) ||
rc == LDAP_SUCCESS ) {
Debug(LDAP_DEBUG_TRACE,
"do_add: add preoperation plugin failed.\n",
0, 0, 0);
#endif
if (( slapi_pblock_get( op->o_pb, SLAPI_RESULT_CODE,
(void *)&rc ) != 0 ) || rc == LDAP_SUCCESS )
{
rc = LDAP_OTHER;
}
#endif
} else {
rc = LDAP_SUCCESS;
}
@ -699,11 +700,13 @@ static void doPostAddPluginFNs( Operation *op )
rc = doPluginFNs( op->o_bd, SLAPI_PLUGIN_POST_ADD_FN, op->o_pb );
if ( rc < 0 ) {
#ifdef NEW_LOGGING
LDAP_LOG( OPERATION, INFO, "do_add: add postoperation plugin failed\n",
0, 0, 0);
LDAP_LOG( OPERATION, INFO,
"do_add: add postoperation plugin failed\n",
0, 0, 0);
#else
Debug(LDAP_DEBUG_TRACE, "do_add: add postoperation plugin failed.\n",
0, 0, 0);
Debug(LDAP_DEBUG_TRACE,
"do_add: add postoperation plugin failed\n",
0, 0, 0);
#endif
}
}

14
servers/slapd/ava.c
View file

@ -80,6 +80,13 @@ get_ava(
rc = slap_bv2ad( &type, &aa->aa_desc, text );
if( rc != LDAP_SUCCESS ) {
#ifdef NEW_LOGGING
LDAP_LOG( FILTER, ERR,
"get_ava: unknown attributeType %s\n", type.bv_val, 0, 0 );
#else
Debug( LDAP_DEBUG_FILTER,
"get_ava: unknown attributeType %s\n", type.bv_val, 0, 0 );
#endif
op->o_tmpfree( aa, op->o_tmpmemctx );
return rc;
}
@ -89,6 +96,13 @@ get_ava(
usage, &value, &aa->aa_value, text, op->o_tmpmemctx );
if( rc != LDAP_SUCCESS ) {
#ifdef NEW_LOGGING
LDAP_LOG( FILTER, ERR,
"get_ava: illegal value for attributeType %s\n", type.bv_val, 0, 0 );
#else
Debug( LDAP_DEBUG_FILTER,
"get_ava: illegal value for attributeType %s\n", type.bv_val, 0, 0 );
#endif
op->o_tmpfree( aa, op->o_tmpmemctx );
return rc;
}

4
servers/slapd/back-bdb/Makefile.in
View file

@ -15,14 +15,14 @@
SRCS = init.c tools.c config.c \
add.c bind.c compare.c delete.c modify.c modrdn.c search.c \
extended.c passwd.c referral.c operational.c \
extended.c referral.c operational.c \
attr.c index.c key.c dbcache.c filterindex.c \
dn2entry.c dn2id.c error.c id2entry.c idl.c \
nextid.c cache.c trans.c ctxcsn.c
OBJS = init.lo tools.lo config.lo \
add.lo bind.lo compare.lo delete.lo modify.lo modrdn.lo search.lo \
extended.lo passwd.lo referral.lo operational.lo \
extended.lo referral.lo operational.lo \
attr.lo index.lo key.lo dbcache.lo filterindex.lo \
dn2entry.lo dn2id.lo error.lo id2entry.lo idl.lo \
nextid.lo cache.lo trans.lo ctxcsn.lo

14
servers/slapd/back-bdb/add.c
View file

@ -497,6 +497,14 @@ retry: /* transaction retry */
}
}
if ( rs->sr_err == LDAP_SUCCESS && !noop && !op->o_no_psearch ) {
ldap_pvt_thread_rdwr_rlock( &bdb->bi_pslist_rwlock );
LDAP_LIST_FOREACH ( ps_list, &bdb->bi_psearch_list, o_ps_link ) {
bdb_psearch( op, rs, ps_list, op->oq_add.rs_e, LDAP_PSEARCH_BY_ADD );
}
ldap_pvt_thread_rdwr_runlock( &bdb->bi_pslist_rwlock );
}
if(( rs->sr_err=TXN_COMMIT( ltid, 0 )) != 0 ) {
rs->sr_text = "txn_commit failed";
} else {
@ -538,12 +546,6 @@ retry: /* transaction retry */
return_results:
send_ldap_result( op, rs );
if ( rs->sr_err == LDAP_SUCCESS && !noop && !op->o_no_psearch ) {
LDAP_LIST_FOREACH ( ps_list, &bdb->bi_psearch_list, o_ps_link ) {
bdb_psearch( op, rs, ps_list, op->oq_add.rs_e, LDAP_PSEARCH_BY_ADD );
}
}
if( rs->sr_err == LDAP_SUCCESS && bdb->bi_txn_cp ) {
ldap_pvt_thread_yield();
TXN_CHECKPOINT( bdb->bi_dbenv,

2
servers/slapd/back-bdb/back-bdb.h
View file

@ -171,7 +171,7 @@ struct bdb_info {
ID bi_lastid;
ldap_pvt_thread_mutex_t bi_lastid_mutex;
LDAP_LIST_HEAD(pl, slap_op) bi_psearch_list;
ldap_pvt_thread_mutex_t bi_pslist_mutex;
ldap_pvt_thread_rdwr_t bi_pslist_rwlock;
LDAP_LIST_HEAD(se, slap_session_entry) bi_session_list;
#ifdef SLAP_IDL_CACHE
int bi_idl_cache_max_size;

4
servers/slapd/back-bdb/config.c
View file

@ -252,9 +252,7 @@ bdb_db_config(
/* anything else */
} else {
fprintf( stderr, "%s: line %d: "
"unknown directive \"%s\" in bdb database definition (ignored)\n",
fname, lineno, argv[0] );
return SLAP_CONF_UNKNOWN;
}
return 0;

14
servers/slapd/back-bdb/delete.c
View file

@ -521,6 +521,14 @@ retry: /* transaction retry */
}
}
if ( rs->sr_err == LDAP_SUCCESS && !noop && !op->o_no_psearch ) {
ldap_pvt_thread_rdwr_rlock( &bdb->bi_pslist_rwlock );
LDAP_LIST_FOREACH( ps_list, &bdb->bi_psearch_list, o_ps_link ) {
bdb_psearch( op, rs, ps_list, e, LDAP_PSEARCH_BY_DELETE );
}
ldap_pvt_thread_rdwr_runlock( &bdb->bi_pslist_rwlock );
}
rs->sr_err = TXN_COMMIT( ltid, 0 );
}
ltid = NULL;
@ -560,12 +568,6 @@ retry: /* transaction retry */
return_results:
send_ldap_result( op, rs );
if ( rs->sr_err == LDAP_SUCCESS && !noop && !op->o_no_psearch ) {
LDAP_LIST_FOREACH( ps_list, &bdb->bi_psearch_list, o_ps_link ) {
bdb_psearch( op, rs, ps_list, e, LDAP_PSEARCH_BY_DELETE );
}
}
if(rs->sr_err == LDAP_SUCCESS && bdb->bi_txn_cp ) {
ldap_pvt_thread_yield();
TXN_CHECKPOINT( bdb->bi_dbenv,

1
servers/slapd/back-bdb/extended.c
View file

@ -27,7 +27,6 @@ static struct exop {
struct berval *oid;
BI_op_extended *extended;
} exop_table[] = {
{ (struct berval *)&slap_EXOP_MODIFY_PASSWD, bdb_exop_passwd },
{ NULL, NULL }
};

8
servers/slapd/back-bdb/index.c
View file

@ -164,7 +164,6 @@ static int indexer(
const char *text;
DB *db;
struct berval *keys;
void *mark;
assert( mask );
@ -183,10 +182,6 @@ static int indexer(
return LDAP_OTHER;
}
#if 0 /* No longer needed, our frees are in order so nothing accumulates */
mark = sl_mark(op->o_tmpmemctx);
#endif
if( IS_SLAP_INDEX( mask, SLAP_INDEX_PRESENT ) ) {
rc = bdb_key_change( op->o_bd, db, txn, &presence_key, id, opid );
if( rc ) {
@ -260,9 +255,6 @@ static int indexer(
}
done:
#if 0
sl_release( mark, op->o_tmpmemctx );
#endif
return rc;
}

8
servers/slapd/back-bdb/init.c
View file

@ -104,6 +104,7 @@ bdb_db_init( BackendDB *be )
ldap_pvt_thread_mutex_init( &bdb->bi_database_mutex );
ldap_pvt_thread_mutex_init( &bdb->bi_lastid_mutex );
ldap_pvt_thread_rdwr_init ( &bdb->bi_pslist_rwlock );
ldap_pvt_thread_mutex_init( &bdb->bi_cache.lru_mutex );
ldap_pvt_thread_mutex_init( &bdb->bi_cache.c_dntree.bei_kids_mutex );
ldap_pvt_thread_rdwr_init ( &bdb->bi_cache.c_rwlock );
@ -411,14 +412,14 @@ bdb_db_open( BackendDB *be )
path,
/* bdbi_databases[i].name, */ NULL,
bdbi_databases[i].type,
bdbi_databases[i].flags | flags | DB_AUTO_COMMIT,
bdbi_databases[i].flags | flags,
bdb->bi_dbenv_mode );
#else
rc = DB_OPEN( db->bdi_db,
bdbi_databases[i].file,
/* bdbi_databases[i].name, */ NULL,
bdbi_databases[i].type,
bdbi_databases[i].flags | flags | DB_AUTO_COMMIT,
bdbi_databases[i].flags | flags,
bdb->bi_dbenv_mode );
#endif
@ -548,6 +549,7 @@ bdb_db_destroy( BackendDB *be )
ldap_pvt_thread_rdwr_destroy ( &bdb->bi_cache.c_rwlock );
ldap_pvt_thread_mutex_destroy( &bdb->bi_cache.lru_mutex );
ldap_pvt_thread_mutex_destroy( &bdb->bi_cache.c_dntree.bei_kids_mutex );
ldap_pvt_thread_rdwr_destroy ( &bdb->bi_pslist_rwlock );
ldap_pvt_thread_mutex_destroy( &bdb->bi_lastid_mutex );
ldap_pvt_thread_mutex_destroy( &bdb->bi_database_mutex );
#ifdef SLAP_IDL_CACHE
@ -590,9 +592,7 @@ bdb_initialize(
LDAP_CONTROL_ASSERT,
LDAP_CONTROL_MANAGEDSAIT,
LDAP_CONTROL_NOOP,
#ifdef LDAP_CONTROL_PAGEDRESULTS
LDAP_CONTROL_PAGEDRESULTS,
#endif
#ifdef LDAP_CONTROL_SUBENTRIES
LDAP_CONTROL_SUBENTRIES,
#endif

36
servers/slapd/back-bdb/modify.c
View file

@ -488,9 +488,11 @@ retry: /* transaction retry */
}
if ( rs->sr_err == LDAP_SUCCESS && !op->o_noop && !op->o_no_psearch ) {
ldap_pvt_thread_rdwr_rlock( &bdb->bi_pslist_rwlock );
LDAP_LIST_FOREACH ( ps_list, &bdb->bi_psearch_list, o_ps_link ) {
bdb_psearch(op, rs, ps_list, e, LDAP_PSEARCH_BY_PREMODIFY );
}
ldap_pvt_thread_rdwr_runlock( &bdb->bi_pslist_rwlock );
}
if( op->o_preread ) {
@ -626,6 +628,24 @@ retry: /* transaction retry */
}
}
if ( rs->sr_err == LDAP_SUCCESS && !op->o_noop ) {
/* Loop through in-scope entries for each psearch spec */
ldap_pvt_thread_rdwr_rlock( &bdb->bi_pslist_rwlock );
LDAP_LIST_FOREACH ( ps_list, &bdb->bi_psearch_list, o_ps_link ) {
bdb_psearch( op, rs, ps_list, e, LDAP_PSEARCH_BY_MODIFY );
}
ldap_pvt_thread_rdwr_runlock( &bdb->bi_pslist_rwlock );
pm_list = LDAP_LIST_FIRST(&op->o_pm_list);
while ( pm_list != NULL ) {
bdb_psearch(op, rs, pm_list->ps_op,
e, LDAP_PSEARCH_BY_SCOPEOUT);
LDAP_LIST_REMOVE ( pm_list, ps_link );
pm_prev = pm_list;
pm_list = LDAP_LIST_NEXT ( pm_list, ps_link );
ch_free( pm_prev );
}
}
rs->sr_err = TXN_COMMIT( ltid, 0 );
}
ltid = NULL;
@ -667,22 +687,6 @@ retry: /* transaction retry */
return_results:
send_ldap_result( op, rs );
if ( rs->sr_err == LDAP_SUCCESS && !op->o_noop ) {
/* Loop through in-scope entries for each psearch spec */
LDAP_LIST_FOREACH ( ps_list, &bdb->bi_psearch_list, o_ps_link ) {
bdb_psearch( op, rs, ps_list, e, LDAP_PSEARCH_BY_MODIFY );
}
pm_list = LDAP_LIST_FIRST(&op->o_pm_list);
while ( pm_list != NULL ) {
bdb_psearch(op, rs, pm_list->ps_op,
e, LDAP_PSEARCH_BY_SCOPEOUT);
LDAP_LIST_REMOVE ( pm_list, ps_link );
pm_prev = pm_list;
pm_list = LDAP_LIST_NEXT ( pm_list, ps_link );
ch_free( pm_prev );
}
}
if( rs->sr_err == LDAP_SUCCESS && bdb->bi_txn_cp ) {
ldap_pvt_thread_yield();
TXN_CHECKPOINT( bdb->bi_dbenv,

36
servers/slapd/back-bdb/modrdn.c
View file

@ -883,9 +883,11 @@ retry: /* transaction retry */
}
if ( rs->sr_err == LDAP_SUCCESS && !op->o_noop && !op->o_no_psearch ) {
ldap_pvt_thread_rdwr_rlock( &bdb->bi_pslist_rwlock );
LDAP_LIST_FOREACH ( ps_list, &bdb->bi_psearch_list, o_ps_link ) {
bdb_psearch( op, rs, ps_list, e, LDAP_PSEARCH_BY_PREMODIFY );
}
ldap_pvt_thread_rdwr_runlock( &bdb->bi_pslist_rwlock );
}
/* modify entry */
@ -997,6 +999,24 @@ retry: /* transaction retry */
}
}
if ( rs->sr_err == LDAP_SUCCESS && !op->o_noop ) {
/* Loop through in-scope entries for each psearch spec */
ldap_pvt_thread_rdwr_rlock( &bdb->bi_pslist_rwlock );
LDAP_LIST_FOREACH ( ps_list, &bdb->bi_psearch_list, o_ps_link ) {
bdb_psearch( op, rs, ps_list, e, LDAP_PSEARCH_BY_MODIFY );
}
ldap_pvt_thread_rdwr_runlock( &bdb->bi_pslist_rwlock );
pm_list = LDAP_LIST_FIRST(&op->o_pm_list);
while ( pm_list != NULL ) {
bdb_psearch(op, rs, pm_list->ps_op,
e, LDAP_PSEARCH_BY_SCOPEOUT);
pm_prev = pm_list;
LDAP_LIST_REMOVE ( pm_list, ps_link );
pm_list = LDAP_LIST_NEXT ( pm_list, ps_link );
ch_free( pm_prev );
}
}
if(( rs->sr_err=TXN_COMMIT( ltid, 0 )) != 0 ) {
rs->sr_text = "txn_commit failed";
} else {
@ -1036,22 +1056,6 @@ retry: /* transaction retry */
return_results:
send_ldap_result( op, rs );
if ( rs->sr_err == LDAP_SUCCESS && !op->o_noop ) {
/* Loop through in-scope entries for each psearch spec */
LDAP_LIST_FOREACH ( ps_list, &bdb->bi_psearch_list, o_ps_link ) {
bdb_psearch( op, rs, ps_list, e, LDAP_PSEARCH_BY_MODIFY );
}
pm_list = LDAP_LIST_FIRST(&op->o_pm_list);
while ( pm_list != NULL ) {
bdb_psearch(op, rs, pm_list->ps_op,
e, LDAP_PSEARCH_BY_SCOPEOUT);
pm_prev = pm_list;
LDAP_LIST_REMOVE ( pm_list, ps_link );
pm_list = LDAP_LIST_NEXT ( pm_list, ps_link );
ch_free( pm_prev );
}
}
if( rs->sr_err == LDAP_SUCCESS && bdb->bi_txn_cp ) {
ldap_pvt_thread_yield();
TXN_CHECKPOINT( bdb->bi_dbenv,

330
servers/slapd/back-bdb/passwd.c
View file

@ -1,330 +0,0 @@
/* passwd.c - bdb backend password routines */
/* $OpenLDAP$ */
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 2000-2003 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 "portable.h"
#include <stdio.h>
#include <ac/string.h>
#include "back-bdb.h"
#include "external.h"
#include "lber_pvt.h"
int
bdb_exop_passwd( Operation *op, SlapReply *rs )
{
struct bdb_info *bdb = (struct bdb_info *) op->o_bd->be_private;
int rc;
Entry *e = NULL;
EntryInfo *ei;
struct berval hash = { 0, NULL };
DB_TXN *ltid = NULL, *lt2;
struct bdb_op_info opinfo;
char textbuf[SLAP_TEXT_BUFLEN];
size_t textlen = sizeof textbuf;
struct berval id = { 0, NULL };
struct berval new = { 0, NULL };
struct berval dn = { 0, NULL };
struct berval ndn = { 0, NULL };
u_int32_t locker = 0;
DB_LOCK lock;
int num_retries = 0;
assert( ber_bvcmp( &slap_EXOP_MODIFY_PASSWD, &op->oq_extended.rs_reqoid ) == 0 );
rc = slap_passwd_parse( op->oq_extended.rs_reqdata,
&id, NULL, &new, &rs->sr_text );
#ifdef NEW_LOGGING
LDAP_LOG ( ACL, ENTRY,
"==>bdb_exop_passwd: \"%s\"\n", id.bv_val ? id.bv_val : "", 0, 0 );
#else
Debug( LDAP_DEBUG_ARGS, "==> bdb_exop_passwd: \"%s\"\n",
id.bv_val ? id.bv_val : "", 0, 0 );
#endif
if( rc != LDAP_SUCCESS ) {
goto done;
}
if( new.bv_len == 0 ) {
slap_passwd_generate(&new);
if( new.bv_len == 0 ) {
rs->sr_text = "password generation failed.";
rc = LDAP_OTHER;
goto done;
}
rs->sr_rspdata = slap_passwd_return( &new );
}
slap_passwd_hash( &new, &hash, &rs->sr_text );
if( hash.bv_len == 0 ) {
if( !rs->sr_text ) rs->sr_text = "password hash failed";
rc = LDAP_OTHER;
goto done;
}
if( id.bv_len ) {
dn = id;
} else {
dn = op->o_dn;
}
#ifdef NEW_LOGGING
LDAP_LOG ( ACL, DETAIL1, "bdb_exop_passwd: \"%s\"%s\"\n",
dn.bv_val, id.bv_len ? " (proxy)" : "", 0 );
#else
Debug( LDAP_DEBUG_TRACE, "bdb_exop_passwd: \"%s\"%s\n",
dn.bv_val, id.bv_len ? " (proxy)" : "", 0 );
#endif
if( dn.bv_len == 0 ) {
rs->sr_text = "No password is associated with the Root DSE";
rc = LDAP_UNWILLING_TO_PERFORM;
goto done;
}
rc = dnNormalize( 0, NULL, NULL, &dn, &ndn, op->o_tmpmemctx );
if( rc != LDAP_SUCCESS ) {
rs->sr_text = "Invalid DN";
goto done;
}
if( 0 ) {
retry: /* transaction retry */
if ( e != NULL ) {
bdb_unlocked_cache_return_entry_w(&bdb->bi_cache, e);
}
#ifdef NEW_LOGGING
LDAP_LOG ( ACL, DETAIL1, "bdb_exop_passwd: retrying...\n", 0, 0, 0 );
#else
Debug( LDAP_DEBUG_TRACE, "bdb_exop_passwd: retrying...\n", 0, 0, 0 );
#endif
rc = TXN_ABORT( ltid );
ltid = NULL;
op->o_private = NULL;
op->o_do_not_cache = opinfo.boi_acl_cache;
if( rc != 0 ) {
rc = LDAP_OTHER;
rs->sr_text = "internal error";
goto done;
}
ldap_pvt_thread_yield();
bdb_trans_backoff( ++num_retries );
}
/* begin transaction */
rc = TXN_BEGIN( bdb->bi_dbenv, NULL, &ltid,
bdb->bi_db_opflags );
rs->sr_text = NULL;
if( rc != 0 ) {
#ifdef NEW_LOGGING
LDAP_LOG ( ACL, ERR,
"bdb_exop_passwd: txn_begin failed: %s (%d)\n",
db_strerror(rc), rc, 0 );
#else
Debug( LDAP_DEBUG_TRACE,
"bdb_exop_passwd: txn_begin failed: %s (%d)\n",
db_strerror(rc), rc, 0 );
#endif
rc = LDAP_OTHER;
rs->sr_text = "internal error";
goto done;
}
locker = TXN_ID ( ltid );
opinfo.boi_bdb = op->o_bd;
opinfo.boi_txn = ltid;
opinfo.boi_locker = locker;
opinfo.boi_err = 0;
opinfo.boi_acl_cache = op->o_do_not_cache;
op->o_private = &opinfo;
/* get entry */
rc = bdb_dn2entry( op, ltid, &ndn, &ei, 0 , locker, &lock );
switch(rc) {
case DB_LOCK_DEADLOCK:
case DB_LOCK_NOTGRANTED:
goto retry;
case DB_NOTFOUND:
case 0:
break;
case LDAP_BUSY:
rs->sr_text = "ldap server busy";
goto done;
default:
rc = LDAP_OTHER;
rs->sr_text = "internal error";
goto done;
}
if ( ei ) e = ei->bei_e;
if ( e == NULL || is_entry_glue( e )) {
/* FIXME: dn2entry() should return non-glue entry */
rs->sr_text = "could not locate authorization entry";
rc = LDAP_NO_SUCH_OBJECT;
goto done;
}
#ifdef BDB_SUBENTRIES
if( is_entry_subentry( e ) ) {
/* entry is a subentry, don't allow operation */
rs->sr_text = "authorization entry is subentry";
rc = LDAP_OTHER;
goto done;
}
#endif
#ifdef BDB_ALIASES
if( is_entry_alias( e ) ) {
/* entry is an alias, don't allow operation */
rs->sr_text = "authorization entry is alias";
rc = LDAP_ALIAS_PROBLEM;
goto done;
}
#endif
if( is_entry_referral( e ) ) {
/* entry is an referral, don't allow operation */
rs->sr_text = "authorization entry is referral";
rc = LDAP_OTHER;
goto done;
}
/* nested transaction */
rc = TXN_BEGIN( bdb->bi_dbenv, ltid, &lt2,
bdb->bi_db_opflags );
rs->sr_text = NULL;
if( rc != 0 ) {
#ifdef NEW_LOGGING
LDAP_LOG ( OPERATION, ERR,
"bdb_exop_passwd: txn_begin(2) failed: %s (%d)\n",
db_strerror(rs->sr_err), rs->sr_err, 0 );
#else
Debug( LDAP_DEBUG_TRACE,
"bdb_exop_passwd: txn_begin(2) failed: %s (%d)\n",
db_strerror(rs->sr_err), rs->sr_err, 0 );
#endif
rc = LDAP_OTHER;
rs->sr_text = "internal error";
goto done;
}
{
Modifications ml;
struct berval vals[2];
Entry dummy, *save;
save = e;
dummy = *e;
e = &dummy;
vals[0] = hash;
vals[1].bv_val = NULL;
ml.sml_desc = slap_schema.si_ad_userPassword;
ml.sml_values = vals;
ml.sml_nvalues = NULL;
ml.sml_op = LDAP_MOD_REPLACE;
ml.sml_next = NULL;
rc = bdb_modify_internal( op, lt2,
&ml, e, &rs->sr_text, textbuf, textlen );
if ( (rc == LDAP_INSUFFICIENT_ACCESS) && opinfo.boi_err ) {
rc = opinfo.boi_err;
}
switch(rc) {
case DB_LOCK_DEADLOCK:
case DB_LOCK_NOTGRANTED:
rs->sr_text = NULL;
goto retry;
case 0:
rs->sr_text = NULL;
break;
default:
rc = LDAP_OTHER;
rs->sr_text = "entry modify failed";
goto done;
}
/* change the entry itself */
rc = bdb_id2entry_update( op->o_bd, lt2, e );
if( rc != 0 ) {
switch(rc) {
case DB_LOCK_DEADLOCK:
case DB_LOCK_NOTGRANTED:
goto retry;
}
rs->sr_text = "entry update failed";
rc = LDAP_OTHER;
}
if ( TXN_COMMIT( lt2, 0 ) != 0 ) {
rc = LDAP_OTHER;
rs->sr_text = "txn_commit(2) failed";
}
if( rc == 0 ) {
if( op->o_noop ) {
rc = TXN_ABORT( ltid );
} else {
bdb_cache_modify( save, e->e_attrs,
bdb->bi_dbenv, locker, &lock );
rc = TXN_COMMIT( ltid, 0 );
}
ltid = NULL;
}
op->o_private = NULL;
if( rc == LDAP_SUCCESS ) {
op->o_req_dn = e->e_name;
op->o_req_ndn = e->e_nname;
op->oq_modify.rs_modlist = &ml;
replog( op );
op->oq_extended.rs_reqoid = slap_EXOP_MODIFY_PASSWD;
}
}
done:
if( e != NULL ) {
bdb_unlocked_cache_return_entry_w( &bdb->bi_cache, e );
}
if( hash.bv_val != NULL ) {
free( hash.bv_val );
}
if( ndn.bv_val != NULL ) {
op->o_tmpfree( ndn.bv_val, op->o_tmpmemctx );
}
if( ltid != NULL ) {
TXN_ABORT( ltid );
op->o_private = NULL;
}
return rc;
}

7
servers/slapd/back-bdb/proto-bdb.h
View file

@ -379,13 +379,6 @@ int bdb_modify_internal(
char *textbuf,
size_t textlen );
/*
* passwd.c
*/
#define bdb_exop_passwd BDB_SYMBOL(exop_passwd)
BI_op_extended bdb_exop_passwd;
/*
* cache.c

56
servers/slapd/back-bdb/search.c
View file

@ -437,12 +437,12 @@ bdb_do_search( Operation *op, SlapReply *rs, Operation *sop,
/* psearch needs to be registered before refresh begins */
/* psearch and refresh transmission is serialized in send_ldap_ber() */
if ( !IS_PSEARCH && sop->o_sync_mode & SLAP_SYNC_PERSIST ) {
ldap_pvt_thread_mutex_lock( &bdb->bi_pslist_mutex );
ldap_pvt_thread_rdwr_wlock( &bdb->bi_pslist_rwlock );
LDAP_LIST_INSERT_HEAD( &bdb->bi_psearch_list, sop, o_ps_link );
ldap_pvt_thread_mutex_unlock( &bdb->bi_pslist_mutex );
ldap_pvt_thread_rdwr_wunlock( &bdb->bi_pslist_rwlock );
} else if ( !IS_PSEARCH && sop->o_sync_mode & SLAP_SYNC_REFRESH_AND_PERSIST
&& sop->o_sync_slog_size >= 0 ) {
ldap_pvt_thread_mutex_lock( &bdb->bi_pslist_mutex );
ldap_pvt_thread_rdwr_wlock( &bdb->bi_pslist_rwlock );
LDAP_LIST_FOREACH( ps_list, &bdb->bi_psearch_list, o_ps_link ) {
if ( ps_list->o_sync_slog_size >= 0 ) {
if ( ps_list->o_sync_state.sid == sop->o_sync_state.sid ) {
@ -476,7 +476,7 @@ bdb_do_search( Operation *op, SlapReply *rs, Operation *sop,
} else {
sop->o_sync_state.sid = -1;
}
ldap_pvt_thread_mutex_unlock( &bdb->bi_pslist_mutex );
ldap_pvt_thread_rdwr_wunlock( &bdb->bi_pslist_rwlock );
}
null_attr.an_desc = NULL;
@ -733,19 +733,23 @@ dn2entry_retry:
}
e = NULL;
rs->sr_err = bdb_get_commit_csn( sop, rs, &search_context_csn, locker, &ctxcsn_lock );
if ( !IS_PSEARCH ) {
rs->sr_err = bdb_get_commit_csn( sop, rs, &search_context_csn, locker, &ctxcsn_lock );
if ( rs->sr_err != LDAP_SUCCESS ) {
send_ldap_error( sop, rs, rs->sr_err, "error in csn management in search" );
goto done;
}
if ( rs->sr_err != LDAP_SUCCESS ) {
send_ldap_error( sop, rs, rs->sr_err, "error in csn management in search" );
goto done;
}
if ( sop->o_sync_mode != SLAP_SYNC_NONE && sop->o_sync_state.ctxcsn &&
sop->o_sync_state.ctxcsn->bv_val &&
ber_bvcmp( &sop->o_sync_state.ctxcsn[0], search_context_csn ) == 0 )
{
bdb_cache_entry_db_unlock( bdb->bi_dbenv, &ctxcsn_lock );
goto nochange;
if ( sop->o_sync_mode != SLAP_SYNC_NONE && sop->o_sync_state.ctxcsn &&
sop->o_sync_state.ctxcsn->bv_val &&
ber_bvcmp( &sop->o_sync_state.ctxcsn[0], search_context_csn ) == 0 )
{
bdb_cache_entry_db_unlock( bdb->bi_dbenv, &ctxcsn_lock );
goto nochange;
}
} else {
search_context_csn = ber_dupbv( NULL, &op->o_sync_csn );
}
/* select candidates */
@ -758,8 +762,10 @@ dn2entry_retry:
rs->sr_err = search_candidates( op, sop, rs, &base, locker, candidates, scopes );
}
if ( sop->o_sync_mode != SLAP_SYNC_NONE ) {
bdb_cache_entry_db_unlock( bdb->bi_dbenv, &ctxcsn_lock );
if ( !IS_PSEARCH ) {
if ( sop->o_sync_mode != SLAP_SYNC_NONE ) {
bdb_cache_entry_db_unlock( bdb->bi_dbenv, &ctxcsn_lock );
}
}
/* start cursor at beginning of candidates.
@ -812,7 +818,6 @@ dn2entry_retry:
tentries = BDB_IDL_N(candidates);
}
#ifdef LDAP_CONTROL_PAGEDRESULTS
if ( get_pagedresults(sop) ) {
if ( sop->o_pagedresults_state.ps_cookie == 0 ) {
id = 0;
@ -844,7 +849,6 @@ dn2entry_retry:
}
goto loop_begin;
}
#endif
if ( (sop->o_sync_mode & SLAP_SYNC_REFRESH) || IS_PSEARCH )
{
@ -1184,7 +1188,6 @@ id2entry_retry:
goto done;
}
#ifdef LDAP_CONTROL_PAGEDRESULTS
if ( get_pagedresults(sop) ) {
if ( rs->sr_nentries >= sop->o_pagedresults_size ) {
send_pagerequest_response( sop, rs,
@ -1193,7 +1196,6 @@ id2entry_retry:
}
lastid = id;
}
#endif
if (e) {
/* safe default */
@ -1410,7 +1412,7 @@ nochange:
} else {
if ( !no_sync_state_change ) {
int slog_found = 0;
ldap_pvt_thread_mutex_lock( &bdb->bi_pslist_mutex );
ldap_pvt_thread_rdwr_rlock( &bdb->bi_pslist_rwlock );
LDAP_LIST_FOREACH( ps_list, &bdb->bi_psearch_list, o_ps_link ) {
if ( ps_list->o_sync_slog_size > 0 ) {
if ( ps_list->o_sync_state.sid == sop->o_sync_state.sid ) {
@ -1426,7 +1428,7 @@ nochange:
rs->sr_ctrls = NULL;
slap_send_session_log( op, ps_list, rs );
}
ldap_pvt_thread_mutex_unlock( &bdb->bi_pslist_mutex );
ldap_pvt_thread_rdwr_runlock( &bdb->bi_pslist_rwlock );
}
rs->sr_err = LDAP_SUCCESS;
rs->sr_rspoid = LDAP_SYNC_INFO;
@ -1452,7 +1454,7 @@ nochange:
} else {
if ( !no_sync_state_change ) {
int slog_found = 0;
ldap_pvt_thread_mutex_lock( &bdb->bi_pslist_mutex );
ldap_pvt_thread_rdwr_rlock( &bdb->bi_pslist_rwlock );
LDAP_LIST_FOREACH( ps_list, &bdb->bi_psearch_list,
o_ps_link ) {
if ( ps_list->o_sync_slog_size > 0 ) {
@ -1467,7 +1469,7 @@ nochange:
if ( slog_found ) {
slap_send_session_log( op, ps_list, rs );
}
ldap_pvt_thread_mutex_unlock( &bdb->bi_pslist_mutex );
ldap_pvt_thread_rdwr_runlock( &bdb->bi_pslist_rwlock );
}
slap_build_sync_done_ctrl( sop, rs, ctrls,
num_ctrls++, 1, &cookie, LDAP_SYNC_REFRESH_DELETES );
@ -1547,6 +1549,8 @@ static int oc_filter(
{
int rc = 0;
assert( f );
if( cur > *max ) *max = cur;
switch(f->f_choice) {
@ -1735,7 +1739,6 @@ static int search_candidates(
return rc;
}
#ifdef LDAP_CONTROL_PAGEDRESULTS
static void
send_pagerequest_response(
Operation *op,
@ -1790,4 +1793,3 @@ send_pagerequest_response(
done:
(void) ber_free_buf( ber );
}
#endif

5
servers/slapd/back-dnssrv/config.c
View file

@ -47,10 +47,7 @@ dnssrv_back_db_config(
/* no configuration options (yet) */
{
fprintf( stderr,
"%s: line %d: unknown directive \"%s\""
" in DNSSRV database definition (ignored)\n",
fname, lineno, argv[0] );
return SLAP_CONF_UNKNOWN;
}
return 0;
}

4
servers/slapd/back-hdb/Makefile.in
View file

@ -19,13 +19,13 @@ XXDIR = $(srcdir)/../back-bdb
XXSRCS = init.c tools.c config.c \
add.c bind.c compare.c delete.c modify.c modrdn.c search.c \
extended.c passwd.c referral.c operational.c \
extended.c referral.c operational.c \
attr.c index.c key.c dbcache.c filterindex.c trans.c \
dn2entry.c dn2id.c error.c id2entry.c idl.c nextid.c cache.c ctxcsn.c
SRCS = $(XXSRCS)
OBJS = init.lo tools.lo config.lo \
add.lo bind.lo compare.lo delete.lo modify.lo modrdn.lo search.lo \
extended.lo passwd.lo referral.lo operational.lo \
extended.lo referral.lo operational.lo \
attr.lo index.lo key.lo dbcache.lo filterindex.lo trans.lo \
dn2entry.lo dn2id.lo error.lo id2entry.lo idl.lo nextid.lo cache.lo ctxcsn.lo

121
servers/slapd/back-ldap/Changes
View file

@ -1,121 +0,0 @@
Copyright 2000, Pierangelo Masarati, All rights reserved. <ando@sys-net.it>
The backend back-ldap has been modified as follows:
* The LDAP handlers have been put under an avl tree, in an attempt
to improve the access to connections in heavy loaded environments
(many clients connecting simultaneously for long times, e.g.
authenticators that make successive searches and binds without
renewing the handler).
This required to change the lcs member of struct ldapinfo into
an (Avlnode *) member called conntree.
The member next in the ldapconn struct has been eliminated because
it is no longer needed.
* The ldap_back_dobind function has been forced to return the value
of the bound flag instead of void; there is no longer need to test
for the flag outside the function as a test was already in.
Now the function can be called as
if ( !ldap_back_dobind( lc, op ) ) {
/* handle error */
}
* The suffix of the operations can be "massaged", i.e. changed to
a different suffix to implement what has been termed a
"virtual naming context": an incoming request with a certain
base or related to a certain dn is turned into a request to a different
server with the base or the dn changed in its terminal part (the naming
context). The resulting entries, if any, have the real naming context
changed back into the virtual naming context.
This required to add a suffixMassage configuration line of the form
suffix "virtual naming context"
suffixMassage "virtual naming context" "real naming context"
(the name of the configuration parameter will be changed to something
more appropriate as will result from a debate in the -devel mailing
list).
The "virtual naming context" must appear in a suffix configuration line
so the server can select the appropriate backend; then the suffixMassage
configuration line maps the "virtual" and the "real" naming contexts
back and forth.
This allows one to map multiple real naming contexts as branches
of a single naming context, provided these reside on the same server:
suffix "ou=Branch 1, o=My Org, c=IT"
suffixMassage "ou=Branch 1, o=My Org, c=IT" "o=Org 1, c=IT"
suffix "ou=Branch 2, o=My Org, c=IT"
suffixMassage "ou=Branch 2, o=My Org, c=IT" "dc=host, dc=net"
suffix "o=My Org, c=IT"
suffixMassage "o=My Org, c=IT" "dc=host, dc=it"
Note that the "same server" limitation can be overcome by using
multiple back-ldap databases, each pointing to the appropriate
server.
Another choice, which would not allow multiple naming contexts
being served by the same database, is to use the "dn" part of the
"uri" configuration parameter, e.g.:
suffix "virtual naming context"
uri "ldap://ldap.my.org:port/real naming context"
This has not been implemented yet.
A possible future enhancement will allow the ldap backend to handle
multiple servers within a single naming context.
Two functions, ldap_back_dn_massage and ldap_back_dn_restore, have
been added. The former changes the bind dn or the search base,
in case its terminal portion matches the "virtual naming context"
of a suffixMassage entry, to the corresponding "real naming context"
suffixed value.
The latter turns the entry's dn back to the "virtual naming context"
suffixed form if the real dn terminal portion matches any "real naming
context" part of a suffixMassage configuration line.
The deferred bind required to add the bound_dn member to the ldapconn
struct.
As of the time of this writing, all the backend operations that
require writing (add, delete, modify, modrdn) have been added the
massaging capability; it can be safely turned off by turning on
the readonly mode at the backend level. The massaging is performed
only on the dn of the entry that is modified, and in the modrdn
operation it affects both the old and the newSuperior dn.
* Cleanup/minor bug fixes/software enhancements:
- the suffix member (unused) has been eliminated (commented out)
from the ldapinfo struct.
- bind.c:ldap_back_op_result: a check of the value of "match" and
"msg" variables is added before freeing them (got a NULL "match"
when the server the backend points to was restarted).
- search.c:ldap_send_entry: the member a_desc in the (Attribute *)
"attr" must be set to NULL before calling slap_str2ad, otherwise
an assertion fails (ITS #919).
- search.c:ldap_send_entry: the entry's ent.e_dn and ent.e_ndn members
need be freed before returning because they were allocated inside
the routine.
- modify.c:ldap_back_modify: the Modifications member sml_op needs be
ORed with LDAP_MOD_BVALUES to force the ldap_modify_s routine
handle the modifications as bervals:
mods[i].mod_op = ml->sml_op | LDAP_MOD_BVALUES;
* Notes:
- there a possible memory leak in the backend, because the memory
occupation of the slapd processes steadily grows when it is
repeatedly accessed.
- when writing (add/modify) lastmod must be set to OFF otherwise
the lastmod attributes will be added to the entry mods and the
target server will complain about
ldap_modify: Constraint violation
ldap_modify: additional info: no user modification allowed

45
servers/slapd/back-ldap/Copyright
View file

@ -1,45 +0,0 @@
Copyright 1999-2003 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>.
---
This is an "altered version".
---
Portions Copyright 1999, Howard Chu, All rights reserved.
<hyc@highlandsun.com>
Permission is granted to anyone to use this software for any purpose
on any computer system, and to alter it and redistribute it, subject
to the following restrictions:
1. The author is not responsible for the consequences of use of this
software, no matter how awful, even if they arise from flaws in it.
2. The origin of this software must not be misrepresented, either by
explicit claim or by omission. Since few users ever read sources,
credits should appear in the documentation.
3. Altered versions must be plainly marked as such, and must not be
misrepresented as being the original software. Since few users
ever read sources, credits should appear in the documentation.
4. This notice may not be removed or altered.
---
Portions Copyright 2000, Pierangelo Masarati, All rights reserved.
<ando@sys-net.it>
This software is being modified by Pierangelo Masarati.
The previously reported conditions apply to the modified code as well.
Changes in the original code are highlighted where required.
Credits for the original code go to the author, Howard Chu.

7
servers/slapd/back-ldap/Makefile.in
View file

@ -30,9 +30,12 @@ BUILD_MOD_DYNAMIC = @BUILD_LDAP_DYNAMIC@
mod_DEFS = -DSLAPD_IMPORT
MOD_DEFS = $(@BUILD_LDAP@_DEFS)
mod_REWRITE = $(LDAP_LIBREWRITE_A)
REWRITE = $(@BUILD_META@_REWRITE) $(@BUILD_LDAP@_REWRITE)
shared_LDAP_LIBS = $(LDAP_LIBLDAP_R_LA) $(LDAP_LIBLBER_LA)
NT_LINK_LIBS = -L.. -lslapd $(@BUILD_LIBS_DYNAMIC@_LDAP_LIBS)
UNIX_LINK_LIBS = $(@BUILD_LIBS_DYNAMIC@_LDAP_LIBS)
NT_LINK_LIBS = -L.. -lslapd $(@BUILD_LIBS_DYNAMIC@_LDAP_LIBS) $(REWRITE)
UNIX_LINK_LIBS = $(@BUILD_LIBS_DYNAMIC@_LDAP_LIBS) $(REWRITE)
LIBBASE = back_ldap

66
servers/slapd/back-ldap/add.c
View file

@ -3,6 +3,8 @@
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1999-2003 The OpenLDAP Foundation.
* Portions Copyright 2000-2003 Pierangelo Masarati.
* Portions Copyright 1999-2003 Howard Chu.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@ -18,36 +20,6 @@
* in OpenLDAP Software and subsequently enhanced by Pierangelo
* Masarati.
*/
/* This is an altered version */
/*
* Copyright 1999, Howard Chu, All rights reserved. <hyc@highlandsun.com>
*
* Permission is granted to anyone to use this software for any purpose
* on any computer system, and to alter it and redistribute it, subject
* to the following restrictions:
*
* 1. The author is not responsible for the consequences of use of this
* software, no matter how awful, even if they arise from flaws in it.
*
* 2. The origin of this software must not be misrepresented, either by
* explicit claim or by omission. Since few users ever read sources,
* credits should appear in the documentation.
*
* 3. Altered versions must be plainly marked as such, and must not be
* misrepresented as being the original software. Since few users
* ever read sources, credits should appear in the documentation.
*
* 4. This notice may not be removed or altered.
*
*
*
* Copyright 2000, Pierangelo Masarati, All rights reserved. <ando@sys-net.it>
*
* This software is being modified by Pierangelo Masarati.
* The previously reported conditions apply to the modified code as well.
* Changes in the original code are highlighted where required.
* Credits for the original code go to the author, Howard Chu.
*/
#include "portable.h"
@ -73,6 +45,10 @@ ldap_back_add(
struct berval mdn = { 0, NULL };
ber_int_t msgid;
dncookie dc;
#ifdef LDAP_BACK_PROXY_AUTHZ
LDAPControl **ctrls = NULL;
int rc = LDAP_SUCCESS;
#endif /* LDAP_BACK_PROXY_AUTHZ */
#ifdef NEW_LOGGING
LDAP_LOG( BACK_LDAP, ENTRY, "ldap_back_add: %s\n", op->o_req_dn.bv_val, 0, 0 );
@ -149,8 +125,29 @@ ldap_back_add(
}
attrs[i] = NULL;
#ifdef LDAP_BACK_PROXY_AUTHZ
rc = ldap_back_proxy_authz_ctrl( lc, op, rs, &ctrls );
if ( rc != LDAP_SUCCESS ) {
goto cleanup;
}
#endif /* LDAP_BACK_PROXY_AUTHZ */
rs->sr_err = ldap_add_ext(lc->ld, mdn.bv_val, attrs,
op->o_ctrls, NULL, &msgid);
#ifdef LDAP_BACK_PROXY_AUTHZ
ctrls,
#else /* ! LDAP_BACK_PROXY_AUTHZ */
op->o_ctrls,
#endif /* ! LDAP_BACK_PROXY_AUTHZ */
NULL, &msgid);
#ifdef LDAP_BACK_PROXY_AUTHZ
cleanup:
if ( ctrls && ctrls != op->o_ctrls ) {
free( ctrls[ 0 ] );
free( ctrls );
}
#endif /* LDAP_BACK_PROXY_AUTHZ */
for (--i; i>= 0; --i) {
ch_free(attrs[i]->mod_vals.modv_bvals);
ch_free(attrs[i]);
@ -159,7 +156,12 @@ ldap_back_add(
if ( mdn.bv_val != op->o_req_dn.bv_val ) {
free( mdn.bv_val );
}
#ifdef LDAP_BACK_PROXY_AUTHZ
if ( rc != LDAP_SUCCESS ) {
send_ldap_result( op, rs );
return -1;
}
#endif /* LDAP_BACK_PROXY_AUTHZ */
return ldap_back_op_result( lc, op, rs, msgid, 1 ) != LDAP_SUCCESS;
}

45
servers/slapd/back-ldap/back-ldap.h
View file

@ -3,6 +3,8 @@
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1999-2003 The OpenLDAP Foundation.
* Portions Copyright 2000-2003 Pierangelo Masarati.
* Portions Copyright 1999-2003 Howard Chu.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@ -18,36 +20,6 @@
* in OpenLDAP Software and subsequently enhanced by Pierangelo
* Masarati.
*/
/* This is an altered version */
/*
* Copyright 1999, Howard Chu, All rights reserved. <hyc@highlandsun.com>
*
* Permission is granted to anyone to use this software for any purpose
* on any computer system, and to alter it and redistribute it, subject
* to the following restrictions:
*
* 1. The author is not responsible for the consequences of use of this
* software, no matter how awful, even if they arise from flaws in it.
*
* 2. The origin of this software must not be misrepresented, either by
* explicit claim or by omission. Since few users ever read sources,
* credits should appear in the documentation.
*
* 3. Altered versions must be plainly marked as such, and must not be
* misrepresented as being the original software. Since few users
* ever read sources, credits should appear in the documentation.
*
* 4. This notice may not be removed or altered.
*
*
*
* Copyright 2000, Pierangelo Masarati, All rights reserved. <ando@sys-net.it>
*
* This software is being modified by Pierangelo Masarati.
* The previously reported conditions apply to the modified code as well.
* Changes in the original code are highlighted where required.
* Credits for the original code go to the author, Howard Chu.
*/
#ifndef SLAPD_LDAP_H
#define SLAPD_LDAP_H
@ -111,6 +83,10 @@ struct ldapinfo {
char *url;
struct berval binddn;
struct berval bindpw;
#ifdef LDAP_BACK_PROXY_AUTHZ
struct berval proxyauthzdn;
struct berval proxyauthzpw;
#endif /* LDAP_BACK_PROXY_AUTHZ */
ldap_pvt_thread_mutex_t conn_mutex;
int savecred;
Avlnode *conntree;
@ -210,6 +186,15 @@ extern int ldap_dnattr_result_rewrite( dncookie *dc, BerVarray a_vals );
extern int ldap_chain_setup();
#ifdef LDAP_BACK_PROXY_AUTHZ
extern int
ldap_back_proxy_authz_ctrl(
struct ldapconn *lc,
Operation *op,
SlapReply *rs,
LDAPControl ***pctrls );
#endif /* LDAP_BACK_PROXY_AUTHZ */
LDAP_END_DECL
#endif /* SLAPD_LDAP_H */

160
servers/slapd/back-ldap/bind.c
View file

@ -3,6 +3,8 @@
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 1999-2003 The OpenLDAP Foundation.
* Portions Copyright 2000-2003 Pierangelo Masarati.
* Portions Copyright 1999-2003 Howard Chu.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@ -18,36 +20,6 @@
* in OpenLDAP Software and subsequently enhanced by Pierangelo
* Masarati.
*/
/* This is an altered version */
/*
* Copyright 1999, Howard Chu, All rights reserved. <hyc@highlandsun.com>
*
* Permission is granted to anyone to use this software for any purpose
* on any computer system, and to alter it and redistribute it, subject
* to the following restrictions:
*
* 1. The author is not responsible for the consequences of use of this
* software, no matter how awful, even if they arise from flaws in it.
*
* 2. The origin of this software must not be misrepresented, either by
* explicit claim or by omission. Since few users ever read sources,
* credits should appear in the documentation.
*
* 3. Altered versions must be plainly marked as such, and must not be
* misrepresented as being the original software. Since few users
* ever read sources, credits should appear in the documentation.
*
* 4. This notice may not be removed or altered.
*
*
*
* Copyright 2000, Pierangelo Masarati, All rights reserved. <ando@sys-net.it>
*
* This software is being modified by Pierangelo Masarati.
* The previously reported conditions apply to the modified code as well.
* Changes in the original code are highlighted where required.
* Credits for the original code go to the author, Howard Chu.
*/
#include "portable.h"
@ -404,13 +376,51 @@ ldap_back_getconn(Operation *op, SlapReply *rs)
int
ldap_back_dobind( struct ldapconn *lc, Operation *op, SlapReply *rs )
{
struct ldapinfo *li = (struct ldapinfo *)op->o_bd->be_private;
int rc;
ber_int_t msgid;
ldap_pvt_thread_mutex_lock( &lc->lc_mutex );
if ( !lc->bound ) {
rs->sr_err = ldap_sasl_bind(lc->ld, lc->bound_dn.bv_val,
LDAP_SASL_SIMPLE, &lc->cred, NULL, NULL, &msgid);
#ifdef LDAP_BACK_PROXY_AUTHZ
int gotit = 0;
#if 0
/*
* 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 saslAuthzTo directive of the "proxyauthzdn".
*/
/*
* NOTE: current Proxy Authorization specification
* and implementation do not allow proxy authorization
* control to be provided with Bind requests
*/
gotit = op->o_proxy_authz;
#endif
/*
* 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.
*/
if ( ( lc->bound_dn.bv_val == NULL || lc->bound_dn.bv_len == 0 )
&& ( op->o_conn && op->o_conn->c_dn.bv_val != NULL && op->o_conn->c_dn.bv_len != 0 )
&& ( li->proxyauthzdn.bv_val != NULL && li->proxyauthzdn.bv_len != 0 )
&& ! gotit ) {
rs->sr_err = ldap_sasl_bind(lc->ld, li->proxyauthzdn.bv_val,
LDAP_SASL_SIMPLE, &li->proxyauthzpw, NULL, NULL, &msgid);
} else
#endif /* LDAP_BACK_PROXY_AUTHZ */
{
rs->sr_err = ldap_sasl_bind(lc->ld, lc->bound_dn.bv_val,
LDAP_SASL_SIMPLE, &lc->cred, NULL, NULL, &msgid);
}
rc = ldap_back_op_result( lc, op, rs, msgid, 0 );
if (rc == LDAP_SUCCESS) {
lc->bound = 1;
@ -550,3 +560,89 @@ ldap_back_op_result(struct ldapconn *lc, Operation *op, SlapReply *rs,
return( (rs->sr_err == LDAP_SUCCESS) ? 0 : -1 );
}
#ifdef LDAP_BACK_PROXY_AUTHZ
/*
* ldap_back_proxy_authz_ctrl() prepends a proxyAuthz control
* to existing server-side controls if required; if not,
* the existing server-side controls are placed in *pctrls.
* The caller, after using the controls in client API
* operations, if ( *pctrls != op->o_ctrls ), should
* free( (*pctrls)[ 0 ] ) and free( *pctrls ).
* The function returns success if the control could
* be added if required, or if it did nothing; in the future,
* it might return some error if it failed.
*
* if no bind took place yet, but the connection is bound
* and the "proxyauthzdn" is set, then bind as "proxyauthzdn"
* and explicitly add proxyAuthz the control to every operation
* with the dn bound to the connection as control value.
*
* If no server-side controls are defined for the operation,
* simply add the proxyAuthz control; otherwise, if the
* proxyAuthz control is not already set, add it as
* the first one (FIXME: is controls order significant
* for security?).
*/
int
ldap_back_proxy_authz_ctrl(
struct ldapconn *lc,
Operation *op,
SlapReply *rs,
LDAPControl ***pctrls )
{
struct ldapinfo *li = (struct ldapinfo *) op->o_bd->be_private;
LDAPControl **ctrls = NULL;
*pctrls = NULL;
if ( ( lc->bound_dn.bv_val == NULL || lc->bound_dn.bv_len == 0 )
&& ( op->o_conn && op->o_conn->c_dn.bv_val != NULL && op->o_conn->c_dn.bv_len != 0 )
&& ( li->proxyauthzdn.bv_val != NULL && li->proxyauthzdn.bv_len != 0 ) ) {
int i = 0;
if ( !op->o_proxy_authz ) {
ctrls = ch_malloc( sizeof( LDAPControl * ) * (i + 2) );
ctrls[ 0 ] = ch_malloc( sizeof( LDAPControl ) );
ctrls[ 0 ]->ldctl_oid = LDAP_CONTROL_PROXY_AUTHZ;
ctrls[ 0 ]->ldctl_iscritical = 1;
ctrls[ 0 ]->ldctl_value.bv_len = op->o_conn->c_dn.bv_len + 3;
ctrls[ 0 ]->ldctl_value.bv_val = ch_malloc( ctrls[ 0 ]->ldctl_value.bv_len + 1 );
AC_MEMCPY( ctrls[ 0 ]->ldctl_value.bv_val, "dn:", sizeof( "dn:" ) - 1 );
AC_MEMCPY( ctrls[ 0 ]->ldctl_value.bv_val + sizeof( "dn:") - 1,
op->o_conn->c_dn.bv_val, op->o_conn->c_dn.bv_len + 1 );
if ( op->o_ctrls ) {
for ( i = 0; op->o_ctrls[ i ]; i++ ) {
ctrls[ i + 1 ] = op->o_ctrls[ i ];
}
}
ctrls[ i + 1 ] = NULL;
} else {
/*
* FIXME: we do not want to perform proxyAuthz
* on behalf of the client, because this would
* be performed with "proxyauthzdn" privileges.
*
* This might actually be too strict, since
* the "proxyauthzdn" saslAuthzTo, and each entry's
* saslAuthzFrom attributes may be crafted
* to avoid unwanted proxyAuthz to take place.
*/
#if 0
rs->sr_err = LDAP_UNWILLING_TO_PERFORM;
rs->sr_text = "proxyAuthz not allowed within namingContext";
#endif
}
}
if ( ctrls == NULL ) {
ctrls = op->o_ctrls;
}
*pctrls = ctrls;
return rs->sr_err;
}
#endif /* LDAP_BACK_PROXY_AUTHZ */

22
servers/slapd/back-ldap/chain.c
View file

@ -3,6 +3,7 @@
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 2003 The OpenLDAP Foundation.
* Portions Copyright 2003 Howard Chu.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@ -17,27 +18,6 @@
* This work was initially developed by the Howard Chu for inclusion
* in OpenLDAP Software.
*/
/* This is an altered version */
/*
* Copyright 2003, Howard Chu, All rights reserved. <hyc@highlandsun.com>
*
* Permission is granted to anyone to use this software for any purpose
* on any computer system, and to alter it and redistribute it, subject
* to the following restrictions:
*
* 1. The author is not responsible for the consequences of use of this
* software, no matter how awful, even if they arise from flaws in it.
*
* 2. The origin of this software must not be misrepresented, either by
* explicit claim or by omission. Since few users ever read sources,
* credits should appear in the documentation.
*
* 3. Altered versions must be plainly marked as such, and must not be
* misrepresented as being the original software. Since few users
* ever read sources, credits should appear in the documentation.
*
* 4. This notice may not be removed or altered.
*/
#include "portable.h"

73
servers/slapd/back-ldap/compare.c
View file

@ -3,6 +3,8 @@
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 2003 The OpenLDAP Foundation.
* Portions Copyright 1999-2003 Howard Chu.
* Portions Copyright 2000-2003 Pierangelo Masarati.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@ -18,36 +20,6 @@
* in OpenLDAP Software and subsequently enhanced by Pierangelo
* Masarati.
*/
/* This is an altered version */
/*
* Copyright 1999, Howard Chu, All rights reserved. <hyc@highlandsun.com>
*
* Permission is granted to anyone to use this software for any purpose
* on any computer system, and to alter it and redistribute it, subject
* to the following restrictions:
*
* 1. The author is not responsible for the consequences of use of this
* software, no matter how awful, even if they arise from flaws in it.
*
* 2. The origin of this software must not be misrepresented, either by
* explicit claim or by omission. Since few users ever read sources,
* credits should appear in the documentation.
*
* 3. Altered versions must be plainly marked as such, and must not be
* misrepresented as being the original software. Since few users
* ever read sources, credits should appear in the documentation.
*
* 4. This notice may not be removed or altered.
*
*
*
* Copyright 2000, Pierangelo Masarati, All rights reserved. <ando@sys-net.it>
*
* This software is being modified by Pierangelo Masarati.
* The previously reported conditions apply to the modified code as well.
* Changes in the original code are highlighted where required.
* Credits for the original code go to the author, Howard Chu.
*/
#include "portable.h"
@ -66,11 +38,15 @@ ldap_back_compare(
{
struct ldapinfo *li = (struct ldapinfo *) op->o_bd->be_private;
struct ldapconn *lc;
struct berval mapped_at, mapped_val;
struct berval mapped_at = { 0, NULL }, mapped_val = { 0, NULL };
struct berval mdn = { 0, NULL };
ber_int_t msgid;
int freeval = 0;
dncookie dc;
#ifdef LDAP_BACK_PROXY_AUTHZ
LDAPControl **ctrls = NULL;
int rc = LDAP_SUCCESS;
#endif /* LDAP_BACK_PROXY_AUTHZ */
lc = ldap_back_getconn(op, rs);
if (!lc || !ldap_back_dobind( lc, op, rs ) ) {
@ -119,18 +95,47 @@ ldap_back_compare(
} else if (mapped_val.bv_val != op->orc_ava->aa_value.bv_val) {
freeval = 1;
}
} else {
mapped_val = op->orc_ava->aa_value;
}
}
rs->sr_err = ldap_compare_ext( lc->ld, mdn.bv_val, mapped_at.bv_val,
&mapped_val, op->o_ctrls, NULL, &msgid );
#ifdef LDAP_BACK_PROXY_AUTHZ
rc = ldap_back_proxy_authz_ctrl( lc, op, rs, &ctrls );
if ( rc != LDAP_SUCCESS ) {
goto cleanup;
}
#endif /* LDAP_BACK_PROXY_AUTHZ */
rs->sr_err = ldap_compare_ext( lc->ld, mdn.bv_val,
mapped_at.bv_val, &mapped_val,
#ifdef LDAP_BACK_PROXY_AUTHZ
ctrls,
#else /* ! LDAP_BACK_PROXY_AUTHZ */
op->o_ctrls,
#endif /* ! LDAP_BACK_PROXY_AUTHZ */
NULL, &msgid );
#ifdef LDAP_BACK_PROXY_AUTHZ
cleanup:
if ( ctrls && ctrls != op->o_ctrls ) {
free( ctrls[ 0 ] );
free( ctrls );
}
#endif /* LDAP_BACK_PROXY_AUTHZ */
if ( mdn.bv_val != op->o_req_dn.bv_val ) {
free( mdn.bv_val );
}
if ( freeval ) {
free( mapped_val.bv_val );
}
#ifdef LDAP_BACK_PROXY_AUTHZ
if ( rc != LDAP_SUCCESS ) {
send_ldap_result( op, rs );
return -1;
}
#endif /* LDAP_BACK_PROXY_AUTHZ */
return( ldap_back_op_result( lc, op, rs, msgid, 1 ) );
}

60
servers/slapd/back-ldap/config.c
View file

@ -3,6 +3,8 @@
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 2003 The OpenLDAP Foundation.
* Portions Copyright 1999-2003 Howard Chu.
* Portions Copyright 2000-2003 Pierangelo Masarati.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@ -18,36 +20,6 @@
* in OpenLDAP Software and subsequently enhanced by Pierangelo
* Masarati.
*/
/* This is an altered version */
/*
* Copyright 1999, Howard Chu, All rights reserved. <hyc@highlandsun.com>
*
* Permission is granted to anyone to use this software for any purpose
* on any computer system, and to alter it and redistribute it, subject
* to the following restrictions:
*
* 1. The author is not responsible for the consequences of use of this
* software, no matter how awful, even if they arise from flaws in it.
*
* 2. The origin of this software must not be misrepresented, either by
* explicit claim or by omission. Since few users ever read sources,
* credits should appear in the documentation.
*
* 3. Altered versions must be plainly marked as such, and must not be
* misrepresented as being the original software. Since few users
* ever read sources, credits should appear in the documentation.
*
* 4. This notice may not be removed or altered.
*
*
*
* Copyright 2000, Pierangelo Masarati, All rights reserved. <ando@sys-net.it>
*
* This software is being modified by Pierangelo Masarati.
* The previously reported conditions apply to the modified code as well.
* Changes in the original code are highlighted where required.
* Credits for the original code go to the author, Howard Chu.
*/
#include "portable.h"
@ -127,7 +99,29 @@ ldap_back_db_config(
return( 1 );
}
ber_str2bv( argv[1], 0, 1, &li->bindpw );
#ifdef LDAP_BACK_PROXY_AUTHZ
/* name to use for proxyAuthz propagation */
} else if ( strcasecmp( argv[0], "proxyauthzdn" ) == 0 ) {
if (argc != 2) {
fprintf( stderr,
"%s: line %d: missing name in \"proxyauthzdn <name>\" line\n",
fname, lineno );
return( 1 );
}
ber_str2bv( argv[1], 0, 1, &li->proxyauthzdn );
/* password to use for proxyAuthz propagation */
} else if ( strcasecmp( argv[0], "proxyauthzpw" ) == 0 ) {
if (argc != 2) {
fprintf( stderr,
"%s: line %d: missing password in \"proxyauthzpw <password>\" line\n",
fname, lineno );
return( 1 );
}
ber_str2bv( argv[1], 0, 1, &li->proxyauthzpw );
#endif /* LDAP_BACK_PROXY_AUTHZ */
/* save bind creds for referral rebinds? */
} else if ( strcasecmp( argv[0], "rebind-as-user" ) == 0 ) {
if (argc != 1) {
@ -262,9 +256,7 @@ ldap_back_db_config(
/* anything else */
} else {
fprintf( stderr, "%s: line %d: unknown directive \"%s\" "
"in ldap database definition (ignored)\n",
fname, lineno, argv[0] );
return SLAP_CONF_UNKNOWN;
}
return 0;
}

69
servers/slapd/back-ldap/delete.c
View file

@ -3,6 +3,8 @@
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 2003 The OpenLDAP Foundation.
* Portions Copyright 1999-2003 Howard Chu.
* Portions Copyright 2000-2003 Pierangelo Masarati.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@ -18,36 +20,6 @@
* in OpenLDAP Software and subsequently enhanced by Pierangelo
* Masarati.
*/
/* This is an altered version */
/*
* Copyright 1999, Howard Chu, All rights reserved. <hyc@highlandsun.com>
*
* Permission is granted to anyone to use this software for any purpose
* on any computer system, and to alter it and redistribute it, subject
* to the following restrictions:
*
* 1. The author is not responsible for the consequences of use of this
* software, no matter how awful, even if they arise from flaws in it.
*
* 2. The origin of this software must not be misrepresented, either by
* explicit claim or by omission. Since few users ever read sources,
* credits should appear in the documentation.
*
* 3. Altered versions must be plainly marked as such, and must not be
* misrepresented as being the original software. Since few users
* ever read sources, credits should appear in the documentation.
*
* 4. This notice may not be removed or altered.
*
*
*
* Copyright 2000, Pierangelo Masarati, All rights reserved. <ando@sys-net.it>
*
* This software is being modified by Pierangelo Masarati.
* The previously reported conditions apply to the modified code as well.
* Changes in the original code are highlighted where required.
* Credits for the original code go to the author, Howard Chu.
*/
#include "portable.h"
@ -68,6 +40,10 @@ ldap_back_delete(
struct ldapconn *lc;
ber_int_t msgid;
dncookie dc;
#ifdef LDAP_BACK_PROXY_AUTHZ
LDAPControl **ctrls = NULL;
int rc = LDAP_SUCCESS;
#endif /* LDAP_BACK_PROXY_AUTHZ */
struct berval mdn = { 0, NULL };
@ -93,13 +69,40 @@ ldap_back_delete(
send_ldap_result( op, rs );
return -1;
}
rs->sr_err = ldap_delete_ext( lc->ld, mdn.bv_val, op->o_ctrls,
#ifdef LDAP_BACK_PROXY_AUTHZ
rc = ldap_back_proxy_authz_ctrl( lc, op, rs, &ctrls );
if ( rc != LDAP_SUCCESS ) {
goto cleanup;
}
#endif /* LDAP_BACK_PROXY_AUTHZ */
rs->sr_err = ldap_delete_ext( lc->ld, mdn.bv_val,
#ifdef LDAP_BACK_PROXY_AUTHZ
ctrls,
#else /* ! LDAP_BACK_PROXY_AUTHZ */
op->o_ctrls,
#endif /* ! LDAP_BACK_PROXY_AUTHZ */
NULL, &msgid );
#ifdef LDAP_BACK_PROXY_AUTHZ
cleanup:
if ( ctrls && ctrls != op->o_ctrls ) {
free( ctrls[ 0 ] );
free( ctrls );
}
#endif /* LDAP_BACK_PROXY_AUTHZ */
if ( mdn.bv_val != op->o_req_dn.bv_val ) {
free( mdn.bv_val );
}
#ifdef LDAP_BACK_PROXY_AUTHZ
if ( rc != LDAP_SUCCESS ) {
send_ldap_result( op, rs );
return -1;
}
#endif /* LDAP_BACK_PROXY_AUTHZ */
return( ldap_back_op_result( lc, op, rs, msgid, 1 ) );
}

34
servers/slapd/back-ldap/extended.c
View file

@ -18,7 +18,6 @@
* in OpenLDAP Software and subsequently enhanced by Pierangelo
* Masarati.
*/
/* This is an altered version */
#include "portable.h"
@ -48,7 +47,40 @@ ldap_back_extended(
for( i=0; exop_table[i].extended != NULL; i++ ) {
if( ber_bvcmp( exop_table[i].oid, &op->oq_extended.rs_reqoid ) == 0 ) {
#ifdef LDAP_BACK_PROXY_AUTHZ
struct ldapconn *lc;
LDAPControl **oldctrls = NULL;
int rc;
/* FIXME: this needs to be called here, so it is
* called twice; maybe we could avoid the
* ldap_back_dobind() call inside each extended()
* call ... */
lc = ldap_back_getconn(op, rs);
if (!lc || !ldap_back_dobind(lc, op, rs) ) {
return -1;
}
oldctrls = op->o_ctrls;
if ( ldap_back_proxy_authz_ctrl( lc, op, rs, &op->o_ctrls ) ) {
op->o_ctrls = oldctrls;
send_ldap_result( op, rs );
rs->sr_text = NULL;
return rs->sr_err;
}
rc = (exop_table[i].extended)( op, rs );
if ( op->o_ctrls && op->o_ctrls != oldctrls ) {
free( op->o_ctrls[ 0 ] );
free( op->o_ctrls );
}
op->o_ctrls = oldctrls;
return rc;
#else /* ! LDAP_BACK_PROXY_AUTHZ */
return (exop_table[i].extended)( op, rs );
#endif /* ! LDAP_BACK_PROXY_AUTHZ */
}
}

1
servers/slapd/back-ldap/external.h
View file

@ -17,7 +17,6 @@
* in OpenLDAP Software and subsequently enhanced by Pierangelo
* Masarati.
*/
/* This is an altered version */
#ifndef _LDAP_EXTERNAL_H
#define _LDAP_EXTERNAL_H

49
servers/slapd/back-ldap/init.c
View file

@ -3,6 +3,8 @@
/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
*
* Copyright 2003 The OpenLDAP Foundation.
* Portions Copyright 1999-2003 Howard Chu.
* Portions Copyright 2000-2003 Pierangelo Masarati.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
@ -18,36 +20,6 @@
* in OpenLDAP Software and subsequently enhanced by Pierangelo
* Masarati.
*/
/* This is an altered version */
/*
* Copyright 1999, Howard Chu, All rights reserved. <hyc@highlandsun.com>
*
* Permission is granted to anyone to use this software for any purpose
* on any computer system, and to alter it and redistribute it, subject
* to the following restrictions:
*
* 1. The author is not responsible for the consequences of use of this
* software, no matter how awful, even if they arise from flaws in it.
*
* 2. The origin of this software must not be misrepresented, either by
* explicit claim or by omission. Since few users ever read sources,
* credits should appear in the documentation.
*
* 3. Altered versions must be plainly marked as such, and must not be
* misrepresented as being the original software. Since few users
* ever read sources, credits should appear in the documentation.
*
* 4. This notice may not be removed or altered.
*
*
*
* Copyright 2000, Pierangelo Masarati, All rights reserved. <ando@sys-net.it>
*
* This software is being modified by Pierangelo Masarati.
* The previously reported conditions apply to the modified code as well.
* Changes in the original code are highlighted where required.
* Credits for the original code go to the author, Howard Chu.
*/
#include "portable.h"
@ -133,6 +105,13 @@ ldap_back_db_init(
li->bindpw.bv_val = NULL;
li->bindpw.bv_len = 0;
#ifdef LDAP_BACK_PROXY_AUTHZ
li->proxyauthzdn.bv_val = NULL;
li->proxyauthzdn.bv_len = 0;
li->proxyauthzpw.bv_val = NULL;
li->proxyauthzpw.bv_len = 0;
#endif /* LDAP_BACK_PROXY_AUTHZ */
#ifdef ENABLE_REWRITE
li->rwmap.rwm_rw = rewrite_info_init( REWRITE_MODE_USE_DEFAULT );
if ( li->rwmap.rwm_rw == NULL ) {
@ -207,6 +186,16 @@ ldap_back_db_destroy(
ch_free(li->bindpw.bv_val);
li->bindpw.bv_val = NULL;
}
#ifdef LDAP_BACK_PROXY_AUTHZ
if (li->proxyauthzdn.bv_val) {
ch_free(li->proxyauthzdn.bv_val);
li->proxyauthzdn.bv_val = NULL;
}
if (li->proxyauthzpw.bv_val) {
ch_free(li->proxyauthzpw.bv_val);
li->proxyauthzpw.bv_val = NULL;
}
#endif /* LDAP_BACK_PROXY_AUTHZ */
if (li->conntree) {
avl_free( li->conntree, ldap_back_conn_free );
}

Some files were not shown because too many files have changed in this diff Show more