ANNOUNCEMENT

+A N N O U N C E M E N T -- OpenLDAP 2.4
+
+    The OpenLDAP Project is pleased to announce the availability
+    of OpenLDAP Software 2.4, a suite of the Lightweight Directory
+    Access Protocol (v3) servers, clients, utilities, and
+    development tools.
+
+    This release contains the following major enhancements:
+
+        * Slapd(8) enhancements
+            - Syncrepl enhancements, including push-mode and
+              Multi-Master support
+            - Dynamic configuration enhancements, including
+              online schema editing and full access control
+            - Dynamic monitoring enhancements, including
+              cache usage information
+        * New overlays
+            - Attribute value constraints
+            - Dynamic Directory Services (RFC2589)
+            - Reverse Group Membership maintenance (memberof)
+        * Clients and tools
+            - Full support of request/response controls
+            - New ldapexop tool for arbitrary extend operations
+            - Support of DNS SRV records for default server
+        * Significant performance enhancements throughout
+            the client and server code base
+        * Multiple new features in libldap and liblber
+        * Expanded documentation
+            - Function-complete manual pages
+            - Numerous new examples in the Admin Guide
+
+    This release includes the following major components:
+
+        * slapd - a stand-alone LDAP directory server
+        * -lldap - a LDAP client library
+        * -llber - a lightweight BER/DER encoding/decoding library
+        * LDIF tools - data conversion tools for use with slapd
+        * LDAP tools - A collection of command line LDAP utilities
+        * Admin Guide, Manual Pages - associated documentation
+
+    In addition, there are some contributed components:
+
+        * LDAPC++ - a LDAP C++ SDK
+        * Various slapd modules and slapi plugins
+
+
+ACKNOWLEDGEMENTS
+
+    OpenLDAP Software is developed by the OpenLDAP Project.  The
+    Project consists of a team of volunteers who use the
+    Internet to coordinate their activities.  The Project is
+    an organized activity of the OpenLDAP Foundation.
+
+    OpenLDAP Software is derived from University of Michigan LDAP,
+    release 3.3.
+
+
+AVAILABILITY
+
+    This software is available under the OpenLDAP Public License,
+    an non-restrictive, "free", open-source license.  Download
+    information is available at:
+
+        http://www.OpenLDAP.org/software/download/
+
+
+SUPPORT
+
+    OpenLDAP Software is user supported:
+
+        http://www.openldap.org/support/
+
+    The OpenLDAP Administrator's Guide, which includes quick
+    start instructions, is available at:
+
+        http://www.openldap.org/doc/admin/
+
+    The project maintains a FAQ which you may find useful:
+
+        http://www.openldap.org/faq/
+
+    In addition, there are also a number of discussion lists
+    related to OpenLDAP Software.  A list of mailing lists is
+    available at:
+
+        http://www.OpenLDAP.org/lists/
+
+    To report bugs, please use project's Issue Tracking System:
+
+        http://www.openldap.org/its/
+
+    The OpenLDAP home page containing lots of interesting information
+    and online documentation is available at this URL:
+
+        http://www.OpenLDAP.org/
+
+
+SUPPORTED PLATFORMS
+
+    This release has been ported to many UNIX (and UNIX-like)
+    platforms including Darwin, FreeBSD, Linux, NetBSD, OpenBSD
+    and most commercial UNIX systems.  The release has also been
+    ported (in part or in whole) to other platforms including
+    Apple MacOS X, IBM zOS, and Microsoft Windows NT/2000/etc.
+
+---
+OpenLDAP is a registered trademark of the OpenLDAP Foundation.
+
+Copyright 1999-2008 The OpenLDAP Foundation, Redwood City,
+California, USA.  All Rights Reserved.  Permission to copy and
+distribute verbatim copies of this document is granted.

CHANGES

+OpenLDAP 2.4 Change Log
+
+OpenLDAP 2.4.10 Engineering
+	Fixed libldap file descriptor leak with SELinux (ITS#5507)
+	Fixed slapd missing termination of integerFilter keys (ITS#5503)
+	Fixed slapd multiple attrs in URI (ITS#5516)
+	Fixed slapd-bdb/hdb MAXPATHLEN (ITS#5531)
+	Fixed slapd-ldap entry_get() op-dependent behavior (ITS#5513)
+	Fixed slapd-meta quarantine crasher (ITS#5522)
+	Fixed slapo-syncprov csn update with delta-syncrepl (ITS#5493)
+	Fixed slapo-syncprov op2.o_extra reset (ITS#5501, #5506)
+	Fixed slapo-syncprov sending ops without queued CSNs (ITS#5465)
+	Documentation
+		Add search privileges documentation (ITS#5512)
+
+OpenLDAP 2.4.9 Release (2008/05/07)
+	Fixed libldap to use unsigned port (ITS#5436)
+	Fixed libldap error message for missing close paren (ITS#5458)
+	Fixed libldap_r tpool pause checks (ITS#5364, #5407)
+	Fixed slapcat error checking (ITS#5387)
+	Fixed slapd abstract objectClass inheritance check (ITS#5474)
+	Fixed slapd add operations requiring naming attrs (ITS#5412)
+	Fixed slapd connection handling (ITS#5469)
+	Fixed slapd delta-syncrepl resync (ITS#5378)
+	Fixed slapd frontendDB backend selection (ITS#5419)
+	Fixed slapd pagedresults stale state (ITS#5409)
+	Fixed slapd pointer dereference (ITS#5388)
+	Fixed slapd null argument dereference (ITS#5435)
+	Fixed slapd REP_ENTRY flags (ITS#5340)
+	Fixed slapd sets attribute description parsing (ITS#5402)
+	Fixed slapd syncrepl hang on back-config (ITS#5407)
+	Fixed slapd syncrepl compare_csns crash (ITS#5413)
+	Fixed slapd syncrepl contextCSN update clash (ITS#5426)
+	Fixed slapd syncrepl/glue failure (ITS#5430)
+	Fixed slapd syncrepl crash on empty CSN (ITS#5432)
+	Fixed slapd syncrepl refreshAndPersist (ITS#5454)
+	Fixed slapd syncrepl modrdn processing (ITS#5397)
+	Fixed slapd syncrepl MMR partial refresh (ITS#5470)
+	Fixed slapd value list termination (ITS#5450)
+	Fixed slapd/slapo-accesslog rq mutex usage (ITS#5442)
+	Fixed slapd-bdb ID_NOCACHE handling (ITS#5439)
+	Fixed slapd-bdb entryinfo state if db_lock fails (ITS#5455)
+	Fixed slapd-bdb referral rewrite (ITS#5339)
+	Fixed slapd-config overlay stacking (ITS#5346)
+	Fixed slapd-config attribute publishing (ITS#5383)
+	Fixed slapd-ldap connection handler (ITS#5404)
+	Fixed slapd-ldif file name handling & multi-suffix/dir catch (ITS#5408)
+	Fixed slapd-meta connections on error (ITS#5440)
+	Fixed slapd-meta crash on search (ITS#5481)
+	Fixed slapo-accesslog null callback stack crash (ITS#5490)
+	Fixed slapo-auditlog unnecessary syscall (ITS#5441)
+	Added slapo-dynlist mapping to dynamic attrs generation (ITS#5466)
+	Fixed slapo-refint dnSubtreeMatch (ITS#5427)
+	Fixed slapo-refint global referential integrity (ITS#5428)
+	Fixed slapo-syncprov psearch on closed connection (ITS#5401)
+	Fixed slapo-syncprov psearch task delay (ITS#5405)
+	Fixed slapo-syncprov psearch filter identity (ITS#5418, #5486)
+	Fixed slapo-syncprov/glue contextCSN update (ITS#5433)
+	Fixed slapo-syncprov/glue search ops (ITS#5434)
+	Fixed slapo-syncprov null cookie (ITS#5437,#5444)
+	Fixed slapo-syncprov double-free (ITS#5445)
+	Fixed slapo-syncprov free syncop correctly (ITS#5484)
+	Fixed slapo-syncprov glue deadlock (ITS#5451)
+	Build Environment
+		Fixed leave function naming for OSF1 (ITS#5411)
+	Documentation
+		Fixed slapd.access(5) authz-regexp documented behavior (ITS#5400)
+		Fixed slapd.meta(5) idassert-* documentation (ITS#5406)
+		admin24 delta-syncrepl documentation (ITS#5476)
+		admin24 set documentation (ITS#5278,ITS#5279,ITS#5281)
+		admin24 slapo-ppolicy documentation (ITS#5479)
+		admin24 syncrepl directives update (ITS#5425)
+
+OpenLDAP 2.4.8 Release (2008/02/19)
+	Fixed ldapmodify verbose logging (ITS#5247)
+	Fixed ldapdelete with sizelimit (ITS#5294)
+	Fixed ldapdelete with subentries control (ITS#5293)
+	Fixed ldapsearch exit code init (ITS#5317)
+	Fixed libldap extended decoding (ITS#5304)
+	Fixed libldap filter abort (ITS#5300)
+	Fixed libldap ldap_parse_sasl_bind_result (ITS#5263)
+	Fixed libldap result codes for open (ITS#5338)
+	Fixed libldap search timeout crash (ITS#5291)
+	Fixed libldap paged results crash (ITS#5315)
+	Fixed libldap cipher suite with GnuTLS (ITS#5341)
+	Fixed slapd support for 2.1 CSN (ITS#5348)
+	Fixed slapd include handling (ITS#5276)
+	Fixed slapd modrdn check for valid new DN (ITS#5344)
+	Fixed slapd multi-step SASL binds (ITS#5298)
+	Fixed slapd non-atomic signal variables (ITS#5248)
+	Fixed slapd overlay ordering when moving to slapd.d (ITS#5284)
+	Fixed slapd NULL printf (ITS#5264)	
+	Fixed slapd NULL set values (ITS#5286)
+	Fixed slapd segv with SASL/OTP (ITS#5259)
+	Fixed slapd timestamp race condition (ITS#5370)
+	Fixed slapd cn=config crash on delete (ITS#5343)
+	Fixed slapd cn=config global acls (ITS#5352)
+	Fixed slapd truncated cookie (ITS#5362)
+	Fixed slapd sasl with CLEARTEXT (ITS#5368)
+	Fixed slapd str2entry with no attrs (ITS#5308)
+	Fixed slapd TLSVerifyClient default (ITS#5360)
+	Fixed slapd HAVE_TLS dependency (ITS#5379)
+	Fixed slapd delta-syncrepl refresh mode (ITS#5376)
+	Fixed slapd ACL sets URI attrs (ITS#5384)
+	Fixed slapd invalid entryUUID filter (ITS#5386)
+	Fixed slapd-bdb idlcache on adds (ITS#5086)
+	Fixed slapd-bdb crash with modrdn (ITS#5358)
+	Fixed slapd-bdb segv with bdb4.6 (ITS#5322)
+	Fixed slapd-bdb modrdn to same dn (ITS#5319)
+	Fixed slapd-bdb MMR (ITS#5332)
+	Added slapd-bdb/slapd-hdb DB encryption (ITS#5359)
+	Fixed slapd-ldif delete (ITS#5265)
+	Fixed slapd-meta link to slapd-ldap (ITS#5355)
+	Fixed slapd-meta setting of sm_nvalues (ITS#5375)
+	Fixed slapd-monitor crash (ITS#5311)
+	Fixed slapd-relay compare (ITS#4937)
+	Added slapd-sock (ITS#4094)
+	Fixed slapo-accesslog cleanup on successful response (ITS#5374)
+	Added slapo-autogroup contrib module (ITS#5145)
+	Added slapo-constraint cross-attribute constraints (ITS#4987)
+	Fixed slapo-memberof objectClass inheritance (ITS#5299)
+	Added slapo-memberof global overlay support (ITS#5301)
+	Fixed slapo-memberof leak (ITS#5302)
+	Fixed slapo-ppolicy only password check with policy (ITS#5285)
+	Fixed slapo-ppolicy del/replace password without new one (ITS#5373)
+	Fixed slapo-syncprov hang on checkpoint (ITS#5261)
+	Added slapo-translucent local searching (ITS#5283)
+	Removed lint
+	Build Environment
+		Fixed libldap_r threaded library linking (ITS#4982)
+		Fixed libldap use of %n (ITS#5324)
+		Fixed test047 to skip if rwm is not available (ITS#5292)
+	Documentation
+		DB_CONFIG.example URL wrong in comments (ITS#5288)
+		Add cn=config example for auditlog (ITS#5245)
+		ldapmodify(1) clarification for RFC2849 (ITS#5312)
+
+OpenLDAP 2.4.7 Release (2007/12/14)
+	Added slapd ordered indexing of integer attributes (ITS#5239)
+	Fixed slapd paged results control handling (ITS#5191)
+	Fixed slapd sasl-host parsing (ITS#5209)
+	Fixed slapd filter normalization (ITS#5212)
+	Fixed slapd multiple suffix checking (ITS#5186)
+	Fixed slapd paged results handling when using rootdn (ITS#5230)
+	Fixed slapd syncrepl presentlist handling (ITS#5231)
+	Fixed slapd core schema 'c' definition for RFC4519 (ITS#5236)
+	Fixed slapd 3-way Multi-Master Replication (ITS#5238)
+	Fixed slapd hash collisions in index slots (ITS#5183)
+	Fixed slapd replication of dSAOperation attributes (ITS#5268)
+	Fixed slapadd contextCSN updating (ITS#5225)
+	Fixed slapd-bdb/hdb to report and fail on internal errors (ITS#5232)
+	Fixed slapd-bdb/hdb dn2entry lock bug (ITS#5257)
+	Fixed slapd-bdb/hdb dn2id lock bug (ITS#5262)
+	Fixed slapd-hdb caching on rename ops (ITS#5221)
+	Fixed slapo-accesslog abandoned op cleanup (ITS#5161)
+	Fixed slapo-dds deleting from nonexistent db (ITS#5267)
+	Fixed slapo-memberOf deleted values saving (ITS#5258)
+	Fixed slapo-pcache op->o_abandon handling (ITS#5187)
+	Fixed slapo-ppolicy single password check on modify (ITS#5146)
+	Fixed slapo-ppolicy internal search (ITS#5235)
+	Fixed slapo-syncprov refresh and persist cookie sending (ITS#5210)
+	Fixed slapo-syncprov ignore invalid cookies (ITS#5211)
+	Fixed slapo-translucent interaction with slapo-rwm (ITS#4889)
+	Updated contrib addpartial module (ITS#3593)
+	Build Environment
+		Fixed liblber socket library linking (ITS#5224)
+		Fixed Windows slapd.def rules (ITS#5215)
+	Documentation
+		Fixed grammar errors (ITS#5223)
+		Refint overlay doc contribution (ITS#5217)
+		Dynamic Lists doc contribution to the admin guide (ITS#5216)
+		Fixed ldappasswd(1) and ldapmodify(1) typos (ITS#5269)
+		Fixed domain factor typos (ITS#5237)
+		Fixed slapd.conf(5) maxderefdepth default value typo (ITS#5200)
+		Clarified slapd.conf(5) limits issues in syncrepl (ITS#5243)
+		Fixed slapd-config(5) maxderefdepth default value typo (ITS#5200)
+		Patches for minor typos in man pages (ITS#5228)
+		admin24/replication.sdf spelling (ITS#5270)
+
+
+OpenLDAP 2.4.6 Release (2007/10/31)
+	Initial release for "general use".

README

-OpenLDAP Devel README
-	This software was obtained from the development branch (HEAD) of
-	the OpenLDAP Software Repository.  This copy is likely already
-	not current, the development branch changes frequently.  These
-	changes include code implementing experimental features and
-	unproven bug fixes.  Please do NOT redistribute copies of the
-	development branch.
-
-	The OpenLDAP Developer's FAQ is available at:
-		<http://www.openldap.org/faq/index.cgi?file=4>
-
-	Client developers seeking a suitable development platform
-	should use "release" or "stable" versions.
-		<http://www.openldap.org/software/>
-
-Contributing
-	See <http://www.openldap.org/devel/contributing.html> for how to
-	contribute code or documentation to OpenLDAP.  Use the Issue Tracking
-	System <http://www.openldap.org/its/> to submit contributions.
-	While you are encouraged to coordinate and discuss the development
-	activities on the openldap-devel@openldap.org mailing list prior
-	to submission, it is noted that contributions must be submitted
-	using the Issue Tracking System to be considered.
+OpenLDAP 2.4 README
+    For a description of what this distribution contains, see the
+    ANNOUNCEMENT file in this directory.  For a description of
+    changes from previous releases, see the CHANGES file in this
+    directory.
+
+    This is 2.4 release, it includes significant changes from prior
+    releases.
+
+REQUIRED SOFTWARE
+    Building OpenLDAP Software requires a number of software packages
+    to be preinstalled.  Additional information regarding prerequisite
+    software can be found in the OpenLDAP Administrator's Guide.
+
+    Base system (libraries and tools):
+        Standard C compiler (required)
+        Cyrus SASL 2.1.21+ (recommended)
+        OpenSSL 0.9.7+ (recommended)
+        POSIX REGEX software (required)
+
+    SLAPD:
+        BDB and HDB backends require Oracle Berkeley DB 4.2, 4.4,
+        4.5, or 4.6.  It is highly recommended to apply the patches
+        from Oracle for a given release.
+
+    CLIENTS/CONTRIB ware:
+        Depends on package.  See per package README.
+
+
+MAKING AND INSTALLING THE DISTRIBUTION
+    Please see the INSTALL file for basic instructions.  More
+    detailed instructions can be found in the OpenLDAP Admnistrator's
+    Guide (see DOCUMENTATION section).
+
+
+DOCUMENTATION
+    The OpenLDAP Administrator's Guide is available in the
+    guide.html file in the doc/guide/admin directory.  The
+    guide and a number of other documents are available at
+    <http://www.openldap.org/doc/admin/guide.html>.
+
+    The distribution also includes manual pages for most programs
+    and library APIs.  See ldap(3) for details.
+
+    The OpenLDAP website is available and contains the latest LDAP
+    news, releases announcements, pointers to other LDAP resources,
+    etc..  It is located at <http://www.OpenLDAP.org/>.
+
+    The OpenLDAP Software FAQ is available at
+    <http://www.openldap.org/faq/>.
+
+
+SUPPORT / FEEDBACK / PROBLEM REPORTS / DISCUSSIONS
+    OpenLDAP Software is user supported.  If you have problems, please
+    review the OpenLDAP FAQ <http://www.openldap.org/faq/> and
+    archives of the OpenLDAP-software and OpenLDAP-bugs mailing lists
+    <http://www.openldap.org/lists/>.  If you cannot find the answer,
+    please enquire on the OpenLDAP-software list.
+
+    Issues, such as bug reports, should be reported using our our
+    Issue Tracking System <http://www.OpenLDAP.org/its/>.  Do not
+    use this system for software enquiries.  Please direct these
+    to an appropriate mailing list.
+
+
+CONTRIBUTING
+    See <http://www.openldap.org/devel/contributing.html> for
+    information regarding how to contribute code or documentation
+    to the OpenLDAP Project for inclusion in OpenLDAP Software.
+    While you are encouraged to coordinate and discuss the development
+    activities on the <openldap-devel@openldap.org> mailing list
+    prior to submission, it is noted that contributions must be
+    submitted using the Issue Tracking System
+    <http://www.openldap.org/its/> to be considered.
 
 ---
 $OpenLDAP$

build/version.var

@@ -14,10 +14,10 @@
 ## <http://www.OpenLDAP.org/license.html>.
 ol_package=OpenLDAP
 ol_major=2
-ol_minor=X
+ol_minor=4
 ol_patch=X
-ol_api_inc=000000
-ol_api_current=0
-ol_api_revision=0
+ol_api_inc=20409
+ol_api_current=2
+ol_api_revision=5
 ol_api_age=0
-ol_release_date="0000/00/00"
+ol_release_date="2008/05/07"

configure

 #! /bin/sh
-# From configure.in OpenLDAP: pkg/ldap/configure.in,v 1.660 2007/09/07 10:02:43 hyc Exp .
+# From configure.in OpenLDAP: pkg/ldap/configure.in,v 1.631.2.9 2008/02/11 23:26:37 kurt Exp .
 # Guess values for system-dependent variables and create Makefiles.
 # Generated by GNU Autoconf 2.59.
 #

contrib/ldapc++/src/LDAPAttrType.cpp

@@ -19,17 +19,6 @@ LDAPAttrType::LDAPAttrType(){
     usage = 0;
 }
 
-LDAPAttrType::LDAPAttrType (const LDAPAttrType &at){
-    DEBUG(LDAP_DEBUG_CONSTRUCT,
-            "LDAPAttrType::LDAPAttrType( )" << endl);
-
-    oid = at.oid;
-    desc = at.desc;
-    names = at.names;
-    single = at.single;
-    usage = at.usage;
-}
-
 LDAPAttrType::LDAPAttrType (string at_item) { 
 
     DEBUG(LDAP_DEBUG_CONSTRUCT,
@@ -46,6 +35,11 @@ LDAPAttrType::LDAPAttrType (string at_item) {
 	this->setOid( a->at_oid );
 	this->setSingle( a->at_single_value );
 	this->setUsage( a->at_usage );
+        this->setSuperiorOid( a->at_sup_oid );
+        this->setEqualityOid( a->at_equality_oid );
+        this->setOrderingOid( a->at_ordering_oid );
+        this->setSubstringOid( a->at_substr_oid );
+        this->setSyntaxOid( a->at_syntax_oid );
     }
     // else? -> error
 }
@@ -58,17 +52,17 @@ void LDAPAttrType::setSingle (int at_single) {
     single = (at_single == 1);
 }
     
-void LDAPAttrType::setNames (char **at_names) {
-    names = StringList (at_names);
+void LDAPAttrType::setNames ( char **at_names ) {
+    names = StringList(at_names);
 }
 
-void LDAPAttrType::setDesc (char *at_desc) {
+void LDAPAttrType::setDesc (const char *at_desc) {
     desc = string ();
     if (at_desc)
 	desc = at_desc;
 }
 
-void LDAPAttrType::setOid (char *at_oid) {
+void LDAPAttrType::setOid (const char *at_oid) {
     oid = string ();
     if (at_oid)
 	oid = at_oid;
@@ -78,23 +72,48 @@ void LDAPAttrType::setUsage (int at_usage) {
     usage = at_usage;
 }
 
-bool LDAPAttrType::isSingle () {
-    return single;
+void LDAPAttrType::setSuperiorOid( const char *oid ){
+    if ( oid )
+        superiorOid = oid;
+}
+
+void LDAPAttrType::setEqualityOid( const char *oid ){
+    if ( oid )
+        equalityOid = oid;
+}
+
+void LDAPAttrType::setOrderingOid( const char *oid ){
+    if ( oid )
+        orderingOid = oid;
+}
+
+void LDAPAttrType::setSubstringOid( const char *oid ){
+    if ( oid )
+        substringOid = oid;
+}
+
+void LDAPAttrType::setSyntaxOid( const char *oid ){
+    if ( oid )
+        syntaxOid = oid;
 }
 
-string LDAPAttrType::getOid () {
+bool LDAPAttrType::isSingle() const {
+    return single;
+} 
+
+string LDAPAttrType::getOid() const {
     return oid;
 }
 
-string LDAPAttrType::getDesc () {
+string LDAPAttrType::getDesc() const {
     return desc;
 }
 
-StringList LDAPAttrType::getNames () {
+StringList LDAPAttrType::getNames() const {
     return names;
 }
 
-string LDAPAttrType::getName () {
+string LDAPAttrType::getName() const {
 
     if (names.empty())
 	return "";
@@ -102,6 +121,28 @@ string LDAPAttrType::getName () {
 	return *(names.begin());
 }
 
-int LDAPAttrType::getUsage () {
+int LDAPAttrType::getUsage() const {
     return usage;
 }
+
+std::string LDAPAttrType::getSuperiorOid() const {
+    return superiorOid;
+}
+
+std::string LDAPAttrType::getEqualityOid() const {
+    return equalityOid;
+}
+
+std::string LDAPAttrType::getOrderingOid() const {
+    return orderingOid;
+}
+
+std::string LDAPAttrType::getSubstringOid() const {
+    return substringOid;
+}
+
+std::string LDAPAttrType::getSyntaxOid() const {
+    return syntaxOid;
+}
+
+

contrib/ldapc++/src/LDAPAttrType.h

@@ -23,10 +23,11 @@ using namespace std;
 class LDAPAttrType{
     private :
 	StringList names;
-	string desc, oid;
+	std::string desc, oid, superiorOid, equalityOid;
+        std::string orderingOid, substringOid, syntaxOid;
 	bool single;
 	int usage;
-	
+
     public :
 
         /**
@@ -34,11 +35,6 @@ class LDAPAttrType{
          */   
         LDAPAttrType();
 
-        /**
-         * Copy constructor
-         */   
-	LDAPAttrType (const LDAPAttrType& oc);
-
         /**
 	 * Constructs new object and fills the data structure by parsing the
 	 * argument.
@@ -58,40 +54,50 @@ class LDAPAttrType{
 	/**
 	 * Returns attribute description
 	 */
-	string getDesc ();
+	string getDesc() const;
 	
 	/**
 	 * Returns attribute oid
 	 */
-	string getOid ();
+	string getOid() const;
 
 	/**
 	 * Returns attribute name (first one if there are more of them)
 	 */
-	string getName ();
+	string getName() const;
 
 	/**
 	 * Returns all attribute names
 	 */
-	StringList getNames();
+	StringList getNames() const;
 	
 	/**
 	 * Returns true if attribute type allows only single value
 	 */
-	bool isSingle();
+	bool isSingle() const;
 	
 	/**
  	 * Return the 'usage' value:
  	 * (0=userApplications, 1=directoryOperation, 2=distributedOperation, 
 	 *  3=dSAOperation)
  	 */
- 	int getUsage ();
+ 	int getUsage () const;
+        std::string getSuperiorOid() const;
+        std::string getEqualityOid() const;
+        std::string getOrderingOid() const;
+        std::string getSubstringOid() const;
+        std::string getSyntaxOid() const;
 
-	void setNames (char **at_names);
-	void setDesc (char *at_desc);
-	void setOid (char *at_oid);
-	void setSingle (int at_single_value);
-	void setUsage (int at_usage );
+	void setNames( char **at_names);
+	void setDesc(const char *at_desc);
+	void setOid(const char *at_oid);
+	void setSingle(int at_single_value);
+	void setUsage(int at_usage );
+        void setSuperiorOid( const char *oid );
+        void setEqualityOid( const char *oid );
+        void setOrderingOid( const char *oid );
+        void setSubstringOid( const char *oid );
+        void setSyntaxOid( const char *oid );
 };
 
 #endif // LDAP_ATTRTYPE_H

contrib/ldapc++/src/LDAPModList.cpp

 // $OpenLDAP$
 /*
- * Copyright 2000-2007, OpenLDAP Foundation, All Rights Reserved.
+ * Copyright 2000, OpenLDAP Foundation, All Rights Reserved.
  * COPYING RESTRICTIONS APPLY, see COPYRIGHT file
  */
 

contrib/ldapc++/src/LDAPObjClass.cpp

@@ -91,31 +91,31 @@ void LDAPObjClass::setOid (char *oc_oid) {
 	oid = oc_oid;
 }
 
-string LDAPObjClass::getOid () {
+string LDAPObjClass::getOid() const {
     return oid;
 }
 
-string LDAPObjClass::getDesc () {
+string LDAPObjClass::getDesc() const {
     return desc;
 }
 
-StringList LDAPObjClass::getNames () {
+StringList LDAPObjClass::getNames() const {
     return names;
 }
 
-StringList LDAPObjClass::getMust () {
+StringList LDAPObjClass::getMust() const {
     return must;
 }
 
-StringList LDAPObjClass::getMay () {
+StringList LDAPObjClass::getMay() const {
     return may;
 }
 
-StringList LDAPObjClass::getSup () {
+StringList LDAPObjClass::getSup() const {
     return sup;
 }
 
-string LDAPObjClass::getName () {
+string LDAPObjClass::getName() const {
 
     if (names.empty())
 	return "";
@@ -123,7 +123,7 @@ string LDAPObjClass::getName () {
 	return *(names.begin());
 }
 
-int LDAPObjClass::getKind () {
+int LDAPObjClass::getKind() const {
      return kind;
 }
 

contrib/ldapc++/src/LDAPObjClass.h

@@ -56,42 +56,42 @@ class LDAPObjClass{
 	/**
 	 * Returns object class description
 	 */
-	string getDesc ();
+	string getDesc() const;
 	
 	/**
 	 * Returns object class oid
 	 */
-	string getOid ();
+	string getOid() const;
 
 	/**
 	 * Returns object class name (first one if there are more of them)
 	 */
-	string getName ();
+	string getName() const;
 
 	/**
 	 * Returns object class kind: 0=ABSTRACT, 1=STRUCTURAL, 2=AUXILIARY
 	 */
-	int getKind ();
+	int getKind() const;
 
 	/**
 	 * Returns all object class names
 	 */
-	StringList getNames();
+	StringList getNames() const;
 	
 	/**
 	 * Returns list of required attributes
 	 */
-	StringList getMust();
+	StringList getMust() const;
 	
 	/**
 	 * Returns list of allowed (and not required) attributes
 	 */
-	StringList getMay();
+	StringList getMay() const;
 	
         /**
 	 * Returns list of the OIDs of the superior ObjectClasses
 	 */
-	StringList getSup();
+	StringList getSup() const;
 
 	void setNames (char **oc_names);
 	void setMay (char **oc_may);

contrib/ldapc++/src/LdifReader.cpp

-// $OpenLDAP$
 /*
  * Copyright 2008, OpenLDAP Foundation, All Rights Reserved.
  * COPYING RESTRICTIONS APPLY, see COPYRIGHT file

contrib/ldapc++/src/LdifReader.h

-// $OpenLDAP$
 /*
  * Copyright 2008, OpenLDAP Foundation, All Rights Reserved.
  * COPYING RESTRICTIONS APPLY, see COPYRIGHT file

contrib/slapd-modules/usn/README

-Copyright 2007 Howard Chu, Symas Corp. 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 directory contains a slapd overlay, usn, that extends slapd
-to maintain the usnCreated and usnChanged operational attributes
-normally used by Microsoft ActiveDirectory.
-
-To use the overlay, add:
-
-	moduleload <path to>usn.so
-	...
-
-	database bdb
-	...
-	overlay usn
-
-to your slapd configuration file. The schema definitions for the
-two USN attributes are hardcoded in this overlay.
-
-No Makefile is provided. Just compile with an invocation like
-	gcc -c -I ../../include/ -I ../../servers/slapd -DSLAPD_OVER_USN=SLAPD_MOD_DYNAMIC usn.c
-	gcc -shared -o usn.so usn.o
-
-This overlay is only set up to be built as a dynamically loaded module.
-On most platforms, in order for the module to be usable, all of the 
-library dependencies must also be available as shared libraries.
-
-If you need to build the overlay statically, you will have to move it into the
-slapd/overlays directory and edit the Makefile and overlays.c to reference
-it. You will also have to define SLAPD_OVER_USN to SLAPD_MOD_STATIC,
-and add the relevant libraries to the main slapd link command.

contrib/slapd-modules/usn/usn.c

-/* usn.c - Maintain Microsoft-style Update Sequence Numbers */
-/* $OpenLDAP$ */
-/* This work is part of OpenLDAP Software <http://www.openldap.org/>.
- *
- * Copyright 2007-2008 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>.
- */
-/* ACKNOWLEDGEMENTS:
- * This work was initially developed by Howard Chu for inclusion in
- * OpenLDAP Software.
- */
-
-#include "portable.h"
-
-#ifdef SLAPD_OVER_USN
-
-#include <stdio.h>
-
-#include <ac/string.h>
-#include <ac/socket.h>
-
-#include "slap.h"
-#include "config.h"
-
-/* This overlay intercepts write operations and adds a Microsoft-style
- * USN to the target entry.
- */
-
-typedef struct usn_info {
-	int ui_current;
-	ldap_pvt_thread_mutex_t ui_mutex;
-} usn_info_t;
-
-static AttributeDescription *ad_usnCreated, *ad_usnChanged;
-
-static struct {
-	char *desc;
-	AttributeDescription **adp;
-} as[] = {
-	{ "( 1.2.840.113556.1.2.19 "
-	    "NAME 'uSNCreated' "
-	    "SYNTAX '1.2.840.113556.1.4.906' "
-		"SINGLE-VALUE "
-		"NO-USER-MODIFICATION )",
-		&ad_usnCreated },
-	{ "( 1.2.840.113556.1.2.120 "
-		"NAME 'uSNChanged' "
-		"SYNTAX '1.2.840.113556.1.4.906' "
-		"SINGLE-VALUE "
-		"NO-USER-MODIFICATION )",
-		&ad_usnChanged },
-	{ NULL }
-};
-
-static int
-usn_func( Operation *op, SlapReply *rs )
-{
-	slap_overinst		*on = (slap_overinst *) op->o_bd->bd_info;
-	usn_info_t		*ui = on->on_bi.bi_private;
-	int my_usn;
-	char intbuf[64];
-	struct berval bv[2];
-
-	ldap_pvt_thread_mutex_lock( &ui->ui_mutex );
-	ui->ui_current++;
-	my_usn = ui->ui_current;
-	ldap_pvt_thread_mutex_unlock( &ui->ui_mutex );
-
-	BER_BVZERO(&bv[1]);
-	bv[0].bv_val = intbuf;
-	bv[0].bv_len = snprintf( intbuf, sizeof(intbuf), "%d", my_usn );
-	switch(op->o_tag) {
-	case LDAP_REQ_ADD:
-		attr_merge( op->ora_e, ad_usnCreated, bv, NULL );
-		attr_merge( op->ora_e, ad_usnChanged, bv, NULL );
-		break;
-	case LDAP_REQ_DELETE:
-		/* Probably need to update root usnLastObjRem */
-		break;
-	default: {
-		/* Modify, ModDN */
-		Modifications *ml, *mod = ch_calloc( sizeof( Modifications ), 1 );
-		for ( ml = op->orm_modlist; ml && ml->sml_next; ml = ml->sml_next );
-		ml->sml_next = mod;
-		mod->sml_desc = ad_usnChanged;
-		mod->sml_numvals = 1;
-		value_add_one( &mod->sml_values, &bv[0] );
-		mod->sml_nvalues = NULL;
-		mod->sml_op = LDAP_MOD_REPLACE;
-		mod->sml_flags = 0;
-		mod->sml_next = NULL;
-		break;
-		}
-	}
-	return SLAP_CB_CONTINUE;
-}
-
-static int
-usn_operational(
-	Operation *op,
-	SlapReply *rs )
-{
-	slap_overinst		*on = (slap_overinst *)op->o_bd->bd_info;
-	usn_info_t		*ui = (usn_info_t *)on->on_bi.bi_private;
-
-	if ( rs->sr_entry &&
-		dn_match( &rs->sr_entry->e_nname, op->o_bd->be_nsuffix )) {
-
-		if ( SLAP_OPATTRS( rs->sr_attr_flags ) ||
-			ad_inlist( ad_usnChanged, rs->sr_attrs )) {
-			Attribute *a, **ap = NULL;
-			char intbuf[64];
-			struct berval bv;
-			int my_usn;
-
-			for ( a=rs->sr_entry->e_attrs; a; a=a->a_next ) {
-				if ( a->a_desc == ad_usnChanged )
-					break;
-			}
-
-			if ( !a ) {
-				for ( ap = &rs->sr_operational_attrs; *ap;
-					ap=&(*ap)->a_next );
-
-					a = attr_alloc( ad_usnChanged );
-					*ap = a;
-				}
-
-			if ( !ap ) {
-				if ( !rs->sr_flags & REP_ENTRY_MODIFIABLE ) {
-					rs->sr_entry = entry_dup( rs->sr_entry );
-					rs->sr_flags |=
-						REP_ENTRY_MODIFIABLE|REP_ENTRY_MUSTBEFREED;
-					a = attr_find( rs->sr_entry->e_attrs,
-						ad_usnChanged );
-				}
-				ber_bvarray_free( a->a_vals );
-				a->a_vals = NULL;
-				a->a_numvals = 0;
-			}
-			ldap_pvt_thread_mutex_lock( &ui->ui_mutex );
-			my_usn = ui->ui_current;
-			ldap_pvt_thread_mutex_unlock( &ui->ui_mutex );
-			bv.bv_len = snprintf( intbuf, sizeof(intbuf), "%d", my_usn );
-			bv.bv_val = intbuf;
-			attr_valadd( a, &bv, NULL, 1 );
-		}
-	}
-	return SLAP_CB_CONTINUE;
-}
-
-/* Read the old USN from the underlying DB. This code is
- * stolen from the syncprov overlay.
- */
-static int
-usn_db_open(
-	BackendDB *be,
-	ConfigReply *cr)
-{
-	slap_overinst   *on = (slap_overinst *) be->bd_info;
-	usn_info_t *ui = (usn_info_t *)on->on_bi.bi_private;
-
-	Connection conn = { 0 };
-	OperationBuffer opbuf;
-	Operation *op;
-	Entry *e = NULL;
-	Attribute *a;
-	int rc;
-	void *thrctx = NULL;
-
-	thrctx = ldap_pvt_thread_pool_context();
-	connection_fake_init( &conn, &opbuf, thrctx );
-	op = &opbuf.ob_op;
-	op->o_bd = be;
-	op->o_dn = be->be_rootdn;
-	op->o_ndn = be->be_rootndn;
-
-	rc = overlay_entry_get_ov( op, be->be_nsuffix, NULL,
-		slap_schema.si_ad_contextCSN, 0, &e, on );
-
-	if ( e ) {
-		a = attr_find( e->e_attrs, ad_usnChanged );
-		if ( a ) {
-			ui->ui_current = atoi( a->a_vals[0].bv_val );
-		}
-		overlay_entry_release_ov( op, e, 0, on );
-	}
-	return 0;
-}
-
-static int
-usn_db_init(
-	BackendDB *be,
-	ConfigReply *cr
-)
-{
-	slap_overinst	*on = (slap_overinst *)be->bd_info;
-	usn_info_t	*ui;
-
-	if ( SLAP_ISGLOBALOVERLAY( be ) ) {
-		Debug( LDAP_DEBUG_ANY,
-			"usn must be instantiated within a database.\n",
-			0, 0, 0 );
-		return 1;
-	}
-
-	ui = ch_calloc(1, sizeof(usn_info_t));
-	ldap_pvt_thread_mutex_init( &ui->ui_mutex );
-	on->on_bi.bi_private = ui;
-	return 0;
-}
-
-static int
-usn_db_close(
-	BackendDB *be,
-	ConfigReply *cr
-)
-{
-	slap_overinst	*on = (slap_overinst *)be->bd_info;
-	usn_info_t	*ui = on->on_bi.bi_private;
-	Connection conn = {0};
-	OperationBuffer opbuf;
-	Operation *op;
-	SlapReply rs = {REP_RESULT};
-	void *thrctx;
-
-	Modifications mod;
-	SlapReply rsm = { 0 };
-	slap_callback cb = {0};
-	char intbuf[64];
-	struct berval bv[2];
-
-	thrctx = ldap_pvt_thread_pool_context();
-	connection_fake_init( &conn, &opbuf, thrctx );
-	op = &opbuf.ob_op;
-	op->o_bd = be;
-	BER_BVZERO( &bv[1] );
-	bv[0].bv_len = snprintf( intbuf, sizeof(intbuf), "%d", ui->ui_current );
-	bv[0].bv_val = intbuf;
-	mod.sml_numvals = 1;
-	mod.sml_values = bv;
-	mod.sml_nvalues = NULL;
-	mod.sml_desc = ad_usnChanged;
-	mod.sml_op = LDAP_MOD_REPLACE;
-	mod.sml_flags = 0;
-	mod.sml_next = NULL;
-
-	cb.sc_response = slap_null_cb;
-	op->o_tag = LDAP_REQ_MODIFY;
-	op->o_callback = &cb;
-	op->orm_modlist = &mod;
-	op->orm_no_opattrs = 1;
-	op->o_dn = be->be_rootdn;
-	op->o_ndn = be->be_rootndn;
-	op->o_req_dn = op->o_bd->be_suffix[0];
-	op->o_req_ndn = op->o_bd->be_nsuffix[0];
-	op->o_bd->bd_info = on->on_info->oi_orig;
-	op->o_managedsait = SLAP_CONTROL_NONCRITICAL;
-	op->o_no_schema_check = 1;
-	op->o_bd->be_modify( op, &rs );
-	if ( mod.sml_next != NULL ) {
-		slap_mods_free( mod.sml_next, 1 );
-	}
-	return 0;
-}
-
-static int
-usn_db_destroy(
-	BackendDB *be,
-	ConfigReply *cr
-)
-{
-	slap_overinst	*on = (slap_overinst *)be->bd_info;
-	usn_info_t	*ui = on->on_bi.bi_private;
-
-	ldap_pvt_thread_mutex_destroy( &ui->ui_mutex );
-	ch_free( ui );
-	on->on_bi.bi_private = NULL;
-	return 0;
-}
-
-/* This overlay is set up for dynamic loading via moduleload. For static
- * configuration, you'll need to arrange for the slap_overinst to be
- * initialized and registered by some other function inside slapd.
- */
-
-static slap_overinst usn;
-
-int
-usn_init( void )
-{
-	int i, code;
-
-	memset( &usn, 0, sizeof( slap_overinst ) );
-	usn.on_bi.bi_type = "usn";
-	usn.on_bi.bi_db_init = usn_db_init;
-	usn.on_bi.bi_db_destroy = usn_db_destroy;
-	usn.on_bi.bi_db_open = usn_db_open;
-	usn.on_bi.bi_db_close = usn_db_close;
-
-	usn.on_bi.bi_op_modify = usn_func;
-	usn.on_bi.bi_op_modrdn = usn_func;
-	usn.on_bi.bi_op_add = usn_func;
-	usn.on_bi.bi_op_delete = usn_func;
-	usn.on_bi.bi_operational = usn_operational;
-
-	for ( i = 0; as[i].desc; i++ ) {
-		code = register_at( as[i].desc, as[i].adp, 0 );
-		if ( code ) {
-			Debug( LDAP_DEBUG_ANY,
-				"usn_init: register_at #%d failed\n", i, 0, 0 );
-			return code;
-		}
-	}
-	return overlay_register( &usn );
-}
-
-#if SLAPD_OVER_USN == SLAPD_MOD_DYNAMIC
-int
-init_module( int argc, char *argv[] )
-{
-	return usn_init();
-}
-#endif /* SLAPD_OVER_USN == SLAPD_MOD_DYNAMIC */
-
-#endif /* defined(SLAPD_OVER_USN) */

doc/drafts/draft-zeilenga-ldap-txn-xx.txt

@@ -5,12 +5,13 @@
 
 
 INTERNET-DRAFT                                         Kurt D. Zeilenga
-Intended Category: Standard Track                   OpenLDAP Foundation
-Expires in six months                                      5 March 2006
+Intended Category: Standard Track                         Isode Limited
+Expires in six months                                  18 November 2007
+
 
 
                             LDAP Transactions
-                     <draft-zeilenga-ldap-txn-07.txt>
+                     <draft-zeilenga-ldap-txn-11.txt>
 
 
 Status of Memo
@@ -20,7 +21,7 @@ Status of Memo
   Standard.  Distribution of this memo is unlimited.  Technical
   discussion of this document will take place on the IETF LDAP
   Extensions mailing list <ldapext@ietf.org>.  Please send editorial
-  comments directly to the author <Kurt@OpenLDAP.org>.
+  comments directly to the author <Kurt.Zeilenga@Isode.COM>.
 
   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware have
@@ -37,56 +38,58 @@ Status of Memo
   or to cite them other than as "work in progress."
 
   The list of current Internet-Drafts can be accessed at
-  http://www.ietf.org/1id-abstracts.html
+  http://www.ietf.org/1id-abstracts.html.
 
   The list of Internet-Draft Shadow Directories can be accessed at
-  http://www.ietf.org/shadow.html
+  http://www.ietf.org/shadow.html.
 
 
-  Copyright (C) The Internet Society (2006).  All Rights Reserved.
+  Copyright (C) The IETF Trust (2007).
 
   Please see the Full Copyright section near the end of this document
   for more information.
 
 
-Abstract
 
-  Lightweight Directory Access Protocol (LDAP) update operations, such
+
 
 
 
 Zeilenga                    LDAP Transactions                   [Page 1]
 
-INTERNET-DRAFT         draft-zeilenga-ldap-txn-07           5 March 2006
+INTERNET-DRAFT         draft-zeilenga-ldap-txn-11       18 November 2007
+
 
+Abstract
 
+  Lightweight Directory Access Protocol (LDAP) update operations, such
   as Add, Delete, and Modify operations, have atomic, consistency,
   isolation, durability (ACID) properties.  Each of these update
-  operations act upon an entry.  However, It is often desirable to
-  update two or more entries in a single unit of interaction, a
-  transaction.  Transactions are necessary to support a number of
-  applications including resource provisioning and information
-  replication.  This document defines an LDAP extension to support
-  transactions.
+  operations act upon an entry.  It is often desirable to update two or
+  more entries in a single unit of interaction, a transaction.
+  Transactions are necessary to support a number of applications
+  including resource provisioning.  This document extends LDAP to
+  support transactions.
 
 
 1. Overview
 
   This document extends the Lightweight Directory Access Protocol (LDAP)
-  [Roadmap] to allow clients to group a number of related update
-  operations [Protocol] and have them preformed as one unit of
-  interaction, a transaction.  As with distinct update operations, each
-  transaction has atomic, consistency, isolation, and durability
-  ([ACID]) properties.
+  [RFC4510] to allow clients to relate a number of update operations
+  [RFC4511] and have them performed as one unit of interaction, a
+  transaction.  As with distinct update operations, each transaction has
+  atomic, consistency, isolation, and durability (ACID) properties
+  [ACID].
 
   This extension consists of two extended operations, one control, and
   one unsolicited notification message.  The Start Transaction operation
   is used to obtain a transaction identifier.  This identifier is then
   attached to multiple update operations to indicate that they belong to
-  transaction using the Transaction Specification control.  The End
+  the transaction using the Transaction Specification control.  The End
   Transaction is used to settle (commit or abort) the transaction.  The
-  Aborted Tranaction Notice is used notify the client the server is no
-  longer willing or able to process an outstanding transaction.
+  Aborted Transaction Notice is provided by the server to notify the
+  client that the server is no longer willing or able to process an
+  outstanding transaction.
 
 
 1.1. Conventions and Terminology
@@ -98,7 +101,7 @@ INTERNET-DRAFT         draft-zeilenga-ldap-txn-07           5 March 2006
   Protocol elements are described using ASN.1 [X.680] with implicit
   tags.  The term "BER-encoded" means the element is to be encoded using
   the Basic Encoding Rules [X.690] under the restrictions detailed in
-  Section 5.2 of [Protocol].
+  Section 5.1 of [RFC4511].
 
   DSA stands for "Directory System Agent" (a server).  DSE stands for
   "DSA-specific entry".
@@ -106,42 +109,47 @@ INTERNET-DRAFT         draft-zeilenga-ldap-txn-07           5 March 2006
 
 2.  Elements of an LDAP Transaction
 
-2.1.  Start Transaction Request and Response
-
-
 
 
 Zeilenga                    LDAP Transactions                   [Page 2]
 
-INTERNET-DRAFT         draft-zeilenga-ldap-txn-07           5 March 2006
+INTERNET-DRAFT         draft-zeilenga-ldap-txn-11       18 November 2007
 
 
+2.1.  Start Transaction Request and Response
+
   A Start Transaction Request is an LDAPMessage of CHOICE extendedReq
   where the requestName is IANA-ASSIGNED-OID.1 and the requestValue is
   absent.
 
   A Start Transaction Response is an LDAPMessage of CHOICE extendedRes
-  sent in response to a Start Transaction Request.  Its responesName is
-  absent.  When the resultCode is success, responseValue is present and
-  contains a transaction identifier.  Otherwise, the responseValue is
-  absent.
+  sent in response to a Start Transaction Request.  Its responseName is
+  absent.  When the resultCode is success (0), responseValue is present
+  and contains a transaction identifier.  Otherwise, the responseValue
+  is absent.
 
 
 2.2.  Transaction Specification Control
 
-  A Transaction Specification Control is an LDAPControl where the
+  A Transaction Specification control is an LDAPControl where the
   controlType is IANA-ASSIGNED-OID.2, the criticality is TRUE, and the
-  controlValue is a transaction identifer.  The control is appropriate
+  controlValue is a transaction identifier.  The control is appropriate
   for update requests including Add, Delete, Modify, and ModifyDN
-  requests [Protocol].
+  (Rename) requests [RFC4511], as well as the Password Modify requests
+  [RFC3062].
+
+  As discussed in Section 4, the Transaction Specification control can
+  be used in conjunction with request controls appropriate for the
+  update request.
+
 
 2.3.  End Transactions Request and Response
 
   An End Transaction Request is an LDAPMessage of CHOICE extendedReq
   where the requestName is IANA-ASSIGNED-OID.3 and the requestValue is
-  present and contains a BER-encoded settlementValue.
+  present and contains a BER-encoded txnEndReq.
 
-       settlementValue ::= SEQUENCE {
+       txnEndReq ::= SEQUENCE {
             commit         BOOLEAN DEFAULT TRUE,
             identifier     OCTET STRING }
 
@@ -151,10 +159,45 @@ INTERNET-DRAFT         draft-zeilenga-ldap-txn-07           5 March 2006
 
   An End Transaction Response is an LDAPMessage sent in response to a
   End Transaction Request.  Its response name is absent.  The
-  responseValue when present contains a BER-encoded MessageID.
+  responseValue when present contains a BER-encoded txnEndRes.
+
+       txnEndRes ::= SEQUENCE {
+            messageID MessageID OPTIONAL,
+                 -- msgid associated with non-success resultCode
+
+
+
+Zeilenga                    LDAP Transactions                   [Page 3]
+
+INTERNET-DRAFT         draft-zeilenga-ldap-txn-11       18 November 2007
+
+
+            updatesControls SEQUENCE OF updateControls SEQUENCE {
+                 messageID MessageID,
+                      -- msgid associated with controls
+                 controls  Controls
+            } OPTIONAL
+       }
+       -- where MessageID and Controls are as specified in RFC 4511
+
+  The txnEndRes.messageID provides the message id of the update request
+  associated with a non-success response.  txnEndRes.messageID is absent
+  when resultCode of the End Transaction Response is success (0).
 
+  The txnEndRes.updatesControls provides a facility for returning
+  response controls that normally (i.e., in absence of transactions)
+  would be returned in an update response.  The updateControls.messageID
+  provides the message id of the update request associated with the
+  response controls provided in updateControls.controls.
 
-2.5. Aborted Transaction Notice
+  The txnEndRes.updatesControls is absent when there are no update
+  response controls to return.
+
+  If both txnEndRes.messageID and txnEndRes.updatesControl are absent,
+  the responseValue of the End Transaction Response is absent.
+
+
+2.4. Aborted Transaction Notice
 
   The Aborted Transaction Notice is an Unsolicited Notification message
   where the responseName is IANA-ASSIGNED-OID.4 and responseValue is
@@ -165,51 +208,51 @@ INTERNET-DRAFT         draft-zeilenga-ldap-txn-07           5 March 2006
 
 3.1. Extension Discovery
 
-
-
-Zeilenga                    LDAP Transactions                   [Page 3]
-
-INTERNET-DRAFT         draft-zeilenga-ldap-txn-07           5 March 2006
-
-
   To allow clients to discover support for this extension, servers
   implementing this specification SHOULD publish IANA-ASSIGNED-OID.1 and
   IANA-ASSIGNED-OID.3 as values of the 'supportedExtension' attribute
-  [Models] within the Root DSE, and publish the IANA-ASSIGNED-OID.2 as a
-  value of the 'supportedControl' attribute [Models] of the Root DSE.
+  [RFC4512] within the Root DSE, and publish the IANA-ASSIGNED-OID.2 as
+  a value of the 'supportedControl' attribute [RFC4512] of the Root DSE.
 
   A server MAY choose to advertise this extension only when the client
   is authorized to use it.
 
 
-3.2. Starting an Transactions
+3.2. Starting a Transaction
+
 
-  A client wishing to preform a sequence of directory updates as an
+
+
+Zeilenga                    LDAP Transactions                   [Page 4]
+
+INTERNET-DRAFT         draft-zeilenga-ldap-txn-11       18 November 2007
+
+
+  A client wishing to perform a sequence of directory updates as an
   transaction issues a Start Transaction Request.  A server which is
   willing and able to support transactions responds to this request with
   a Start Transaction Response providing a transaction identifier and
-  with a resultCode of success.  Otherwise, the server responds with a
-  Start Transaction Response wth a result code other than success
+  with a resultCode of success (0).  Otherwise, the server responds with
+  a Start Transaction Response with a result code other than success
   indicating the nature of the failure.
 
   The transaction identifier provided upon successful start of a
-  transaction is used in subseqent protocol messages to identify this
+  transaction is used in subsequent protocol messages to identify this
   transaction.
 
 
 3.3. Specification of a Transaction
 
-  The client then may issue may issue one or more update (add, delete,
-  modify, modifyDN) requests, each with a Transaction Specification
-  control containing the transaction identifier indicating the updates
-  are to processed as part of the transaction.  Each of these update
-  request MUST have a different MessageId value.  If the server is
-  unwilling or unable to attempt to process the requested update
-  operation as part of the transaction, the server immediately returns
-  the approrpiate response to the request with a resultCode indicating
-  the nature of the failure.  Otherwise, the server immediately returns
-  success and the defers further processing of the operation is then
-  deferred until settlement.
+  The client then can issue one or more update requests, each with a
+  Transaction Specification control containing the transaction
+  identifier indicating the updates are to processed as part of the
+  transaction.  Each of these update request MUST have a different
+  MessageID value.  If the server is unwilling or unable to attempt to
+  process the requested update operation as part of the transaction, the
+  server immediately returns the appropriate response to the request
+  with a resultCode indicating the nature of the failure.  Otherwise,
+  the server immediately returns success (0) and the defers further
+  processing of the operation is then deferred until settlement.
 
   If the server becomes unwilling or unable to continue the
   specification of a transaction, the server issues an Aborted
@@ -222,12 +265,6 @@ INTERNET-DRAFT         draft-zeilenga-ldap-txn-07           5 March 2006
   containing a non-success resultCode.
 
 
-
-Zeilenga                    LDAP Transactions                   [Page 4]
-
-INTERNET-DRAFT         draft-zeilenga-ldap-txn-07           5 March 2006
-
-
 3.4. Transaction Settlement
 
   A client requests settlement of transaction by issuing an End
@@ -237,20 +274,29 @@ INTERNET-DRAFT         draft-zeilenga-ldap-txn-07           5 March 2006
   Upon receipt of a request to abort the transaction, the server is to
   abort the identified transaction (abandoning all operations which are
   part of the transaction) and indicate that it has done so by returning
-  an End Transaction response with a resultCode of success.
+  an End Transaction Response with a resultCode of success (0).
+
+
+
+
+Zeilenga                    LDAP Transactions                   [Page 5]
+
+INTERNET-DRAFT         draft-zeilenga-ldap-txn-11       18 November 2007
+
 
   Upon receipt of a request to commit the transaction, the server
   processes all update operations of the transaction as one atomic,
-  isolated action with each requested update being processed in turn.
-  Either all of the requested updates are to be successfully applied or
-  none of the requested are to be applied.  The server returns an End
-  Transaction Response with a resultCode of success and no responseValue
-  to indicate all the requested updates were applied.  Otherwise, the
-  server returns an End Transaction with an non-success resultCode
-  indicating the nature of the failure.  If the failure is associated
-  with a particular update request, a responseValue containing its
-  MessageID is returned.  If the failure was not associated with any
-  particular update request, no responseValue is returned.
+  durable, isolated, and consistent action with each requested update
+  being processed in turn.  Either all of the requested updates are to
+  be successfully applied or none of the requested are to be applied.
+  The server returns an End Transaction Response with a resultCode of
+  success (0) and no responseValue to indicate all the requested updates
+  were applied.  Otherwise, the server returns an End Transaction with
+  an non-success resultCode indicating the nature of the failure.  If
+  the failure is associated with a particular update request, the
+  txnEndRes.messageID in the responseValue is the messageID of this
+  update request.  If the failure was not associated with any particular
+  update request, no txnEnd.messageID is provided.
 
   There is no requirement that a server serialize transactions, or
   updates requested outside of a transaction.  That is, a server MAY
@@ -259,13 +305,130 @@ INTERNET-DRAFT         draft-zeilenga-ldap-txn-07           5 March 2006
   deadlock.
 
 
-4. Distributed Directory Considerations
+3.5. Miscellaneous Issues
+
+  Transactions cannot be nested.
+
+  Each LDAP transaction should be initiated, specified, and settled
+  within a stable security context.   Between the Start request and the
+  End response, the peers SHOULD avoid negotiating new security
+  associations and/or layers.
+
+  Upon receipt of a Bind or Unbind request, the server SHALL abort any
+  and all outstanding transactions without notice and nullify their
+  identifiers.
+
+
+4. Interaction with Other Extensions
+
+  The LDAP Transaction extension may be used with many but not all LDAP
+  control extensions designed to extend Update (and possibly other)
+  operations.  The remainder of this subsection discusses interaction
+  with a number of control extensions.  Interaction with other control
+  extensions may be discussed in other documents, in particular in
+  control extension specifications.
+
+
+4.1. Assertion Control
+
+  The Assertion [RFC4528] control is appropriate for use with update
+
+
+
+Zeilenga                    LDAP Transactions                   [Page 6]
+
+INTERNET-DRAFT         draft-zeilenga-ldap-txn-11       18 November 2007
+
+
+  requests specified as part of a transaction.  The evaluation of the
+  assertion is performed as part of the transaction.
+
+  The Assertion control is inappropriate for use with either the
+  Transaction Start or End extended operations.
+
+
+4.2. ManageDsaIT Control
+
+  The ManageDsaIT [RFC3296] control is appropriate for use with update
+  requests specified as part of a transaction.
+
+  The ManageDsaIT control is inappropriate for use with either the
+  Transaction Start or End extended operations.
+
+
+4.3. No-Op Control
 
-  The LDAP/X.500 models provide for distributed directory operations
-  including server-side chaining and client-side chasing of operations.
+  The No-Op [NO-OP] control is appropriate for use with the Transaction
+  Start or End extended operations.
+
+  The No-Op control is not appropriate for update requests specified as
+  part of a transaction.  A server supporting both the No-Op control
+  extension and this extension SHALL regard a request containing both
+  controls as a protocol violation.  As both of the No-Op and
+  Transaction Specification request controls are required to be marked
+  as critical, a server implementing one of these request controls, or
+  neither, is expected to return unavailableCriticalExtension as
+  prescribed by [RFC4511].
+
+
+4.4. Proxied Authorization Control
+
+  The Proxied Authorization [RFC4370] control is appropriate for use
+  with the Transaction Start extended operation, but not the Transaction
+  End extended operation or any update request specified as part of a
+  transaction.
+
+  To request that a transaction be performed under a different
+  authorization, the client provides a Proxied Authorization control
+  with the Transaction Start request.  If the client is not authorized
+  to assume the requested authorization identity, the server is to
+  return the authorizationDenied (123) resultCode in its response.
+  Otherwise, further processing of the request and transaction is
+  performed under the requested authorization identity.
+
+  Any proxied authorization request attached to an update request
+  specified as part of a transaction, or attached to a Transaction end
+
+
+
+Zeilenga                    LDAP Transactions                   [Page 7]
+
+INTERNET-DRAFT         draft-zeilenga-ldap-txn-11       18 November 2007
+
+
+  request, is to be regarded as a protocol error.
+
+
+4.5. Read Entry Controls
+
+  The Pre- and Post-Read Entry [RFC4527] request control are appropriate
+  for use with update requests specified as part of a transaction.
+
+  The response control produced in response to a Pre- or Post-Read Entry
+  request control is returned in the txnEndRes.updatesControls field of
+  responseValue of the End Transaction Response.
+
+  The Pre- and Post-Read Entry controls are inappropriate for use in the
+  LDAPMessage.controls field of the Transaction Start and End request
+  and response messages.
+
+
+4.6. Relax Rules Control
+
+  The Relax Rules [RELAX] control is appropriate for use with update
+  requests specified as part of a transaction.
+
+  The Relax Rules control is inappropriate for use with either the
+  Transaction Start or End extended operations.
+
+
+5. Distributed Directory Considerations
+
+  The LDAP/X.500 models provide for distributed directory operations,
+  including server-side chaining and client-side chasing of referrals.
 
   This document does not preclude servers from chaining operations which
-  are part of a transaction.  However, if a server does allow such
+  are part of a transaction.  However, if a server does attempt such
   chaining, it MUST ensure that transaction semantics are provided.
 
   This mechanism defined by this document does not support client-side
@@ -273,128 +436,145 @@ INTERNET-DRAFT         draft-zeilenga-ldap-txn-07           5 March 2006
   specific to a particular client/server session.
 
   The LDAP/X.500 models provide for a single-master/multiple-shadow
-  replication architecture.  This document states no requirement that
-  changes made to the directory based upon processing a transaction be
-  replicated as one atomic action.  That is, the client SHOULD NOT
+  replication architecture.  There is no requirement that changes made
+  to the directory based upon processing a transaction be replicated as
+  one atomic action.  Hence, clients SHOULD NOT assume tight data
+  consistency nor fast data convergence of shadow copies unless they
+  have prior knowledge that these properties are provided.  Note that
+  DontUseCopy control [DONTUSECOPY] control may be used in conjunction
+  with the LDAP search request to ask for the return of the
+  authoritative copy of the entry.
 
 
 
-Zeilenga                    LDAP Transactions                   [Page 5]
+Zeilenga                    LDAP Transactions                   [Page 8]
 
-INTERNET-DRAFT         draft-zeilenga-ldap-txn-07           5 March 2006
-
+INTERNET-DRAFT         draft-zeilenga-ldap-txn-11       18 November 2007
 
-  assume tight data consistency nor fast data convergence at shadow
-  servers unless they have prior knowledge that such service is
-  provided.  Though this mechanism could be used to support replication,
-  use in replication is not described in this document.
 
-  The LDAP/X.500 models do not currently support a multi-master
-  replication architecture and, hence, not considered by this
-  specification.
+6. Security Considerations
 
+  Transactions mechanisms may be the target of denial-of-service
+  attacks, especially where implementation lock shared resources for the
+  duration of a transaction.
 
-5. Security Considerations
+  General security considerations [RFC4510], especially those associated
+  with update operations [RFC4511], apply to this extension.
 
-  Transactions mechanisms may be the target of denial of service
-  attacks.  Implementors should provide safeguards to ensure these
-  mechanisms are not abused.
 
-  General security considerations [Roadmap], especially associated with
-  update operations [Protocol], apply to this extension.
+7. IANA Considerations
 
+  It is requested that Internet Assigned Numbers Authority (IANA) make
+  the following assignments.
 
-6. IANA Considerations
 
-  In accordance with [BCP64bis], it is requested that Internet Assigned
-  Numbers Authority (IANA) make the following assignments.
+7.1.  Object Identifier
 
-
-6.1.  Object Identifier
-
-  Assignment of an LDAP Object Identifier to identify the protocol
-  elements specified in this document this document is requested.
+  Assignment of an LDAP Object Identifier [RFC4520] to identify the
+  protocol elements specified in this document this document is
+  requested.
 
       Subject: Request for LDAP Object Identifier Registration
       Person & email address to contact for further information:
-          Kurt Zeilenga <kurt@OpenLDAP.org>
+          Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
       Specification: RFC XXXX
       Author/Change Controller: IESG
       Comments: Identifies protocol elements for LDAP Transactions
 
 
-6.2.  LDAP Protocol Mechanism
+7.2.  LDAP Protocol Mechanism
 
-  Registration of the protocol mechanisms specified in this document is
-  requested.
+  Registration of the protocol mechanisms [RFC4520] specified in this
+  document is requested.
 
-  Subject: Request for LDAP Protocol Mechanism Registration
-  Object Identifier: see table
-  Description: see table
-  Person & email address to contact for further information:
+      Subject: Request for LDAP Protocol Mechanism Registration
+      Object Identifier: see table
+      Description: see table
+      Person & email address to contact for further information:
+          Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
+      Specification: RFC XXXX
+      Author/Change Controller: IESG
+      Comments:
 
+      Object Identifier   Type  Description
+      ------------------- ----  ----------------------------------
+      IANA-ASSIGNED-OID.1 E     Start Transaction Extended Request
+      IANA-ASSIGNED-OID.2 C     Transaction Specification Control
 
 
-Zeilenga                    LDAP Transactions                   [Page 6]
+
+Zeilenga                    LDAP Transactions                   [Page 9]
 
-INTERNET-DRAFT         draft-zeilenga-ldap-txn-07           5 March 2006
+INTERNET-DRAFT         draft-zeilenga-ldap-txn-11       18 November 2007
 
 
-       Kurt Zeilenga <kurt@openldap.org>
-  Specification: RFC XXXX
-  Author/Change Controller: IESG
-  Comments:
+      IANA-ASSIGNED-OID.3 E     End Transaction Extended Request
+      IANA-ASSIGNED-OID.4 N     Aborted Transaction Notice
 
-  Object Identifier   Type  Description
-  ------------------- ----  -----------------------------------------
-  IANA-ASSIGNED-OID.1 E     Start Transaction Extended Request
-  IANA-ASSIGNED-OID.2 C     Transaction Specification Control
-  IANA-ASSIGNED-OID.3 E     End Transaction Extended Request
+      Legend
+      ------------------------
+      C => supportedControl
+      E => supportedExtension
+      N => Unsolicited Notice
 
 
-7. Acknowledgments
+8. Acknowledgments
 
-  The author gratefully acknowledges the contributions made by members
-  of the Internet Engineering Task Force.
+  The author gratefully acknowledges the contributions made by Internet
+  Engineering Task Force participants.
 
 
-8. Author's Address
+9. Author's Address
 
   Kurt D. Zeilenga
-  OpenLDAP Foundation
+  Isode Limited
 
-  Email: Kurt@OpenLDAP.org
+  Email: Kurt.Zeilenga@Isode.COM
 
 
-9. References
+10. References
 
   [[Note to the RFC Editor: please replace the citation tags used in
   referencing Internet-Drafts with tags of the form RFCnnnn where
   possible.]]
 
 
-9.1. Normative References
+10.1. Normative References
 
   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14 (also RFC 2119), March 1997.
 
-  [Roadmap]     Zeilenga, K. (editor), "LDAP: Technical Specification
-                Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in
-                progress.
+  [RFC3062]     Zeilenga, K., "LDAP Password Modify Extended Operation",
+                RFC 3062, February 2000.
 
-  [Protocol]    Sermersheim, J. (editor), "LDAP: The Protocol",
-                draft-ietf-ldapbis-protocol-xx.txt, a work in progress.
+  [RFC3296]     Zeilenga, K., "Named Subordinate References in
+                Lightweight Directory Access Protocol (LDAP)
+                Directories", RFC 3296, July 2002.
 
-  [Models]      Zeilenga, K. (editor), "LDAP: Directory Information
-                Models", draft-ietf-ldapbis-models-xx.txt, a work in
-                progress.
+  [RFC4370]     Weltman, R., "LDAP Proxied Authentication Control", RFC
+                4370, Feb. 2006.
 
+  [RFC4510]     Zeilenga, K. (editor), "LDAP: Technical Specification
+                Road Map", RFC 4510, June 2006.
 
 
-Zeilenga                    LDAP Transactions                   [Page 7]
+
+Zeilenga                    LDAP Transactions                  [Page 10]
 
-INTERNET-DRAFT         draft-zeilenga-ldap-txn-07           5 March 2006
+INTERNET-DRAFT         draft-zeilenga-ldap-txn-11       18 November 2007
+
+
+  [RFC4511]     Sermersheim, J. (editor), "LDAP: The Protocol", RFC
+                4511, June 2006.
 
+  [RFC4512]     Zeilenga, K. (editor), "LDAP: Directory Information
+                Models", RFC 4512, June 2006.
+
+  [RFC4527]     Zeilenga, K., "LDAP Read Entry Controls", RFC 4527, June
+                2006.
+
+  [RFC4528]     Zeilenga, K., "LDAP Assertion Control", RFC 4528, June
+                2006.
 
   [X.680]       International Telecommunication Union -
                 Telecommunication Standardization Sector, "Abstract
@@ -408,29 +588,38 @@ INTERNET-DRAFT         draft-zeilenga-ldap-txn-07           5 March 2006
                 Encoding Rules (DER)", X.690(2002) (also ISO/IEC
                 8825-1:2002).
 
+  [NO-OP]       Zeilenga, K., "LDAP No-Operation Control", draft-
+                zeilenga-ldap-noop-xx.txt, a work in progress.
 
-9.2. Informative References
+  [RELAX]       Zeilenga, K., "LDAP Relax Rules Control", draft-
+                zeilenga-ldap-relax-xx.txt, a work in progress.
 
-  [ACID]        Section 4 of ISO/IEC 10026-1:1992.
 
-  [BCP64bis]    Zeilenga, K., "IANA Considerations for LDAP",
-                draft-ietf-ldapbis-bcp64-xx.txt, a work in progress.
+10.2. Informative References
 
-  [X.500]       International Telecommunication Union -
-                Telecommunication Standardization Sector, "The Directory
-                -- Overview of concepts, models and services,"
-                X.500(1993) (also ISO/IEC 9594-1:1994).
+  [RFC4520]     Zeilenga, K., "Internet Assigned Numbers Authority
+                (IANA) Considerations for the Lightweight Directory
+                Access Protocol (LDAP)", RFC 4520, BCP 64, June 2006.
+
+  [ACID]        Section 4 of ISO/IEC 10026-1:1992.
 
-  [X.501]       International Telecommunication Union -
-                Telecommunication Standardization Sector, "The Directory
-                -- Models," X.501(1993) (also ISO/IEC 9594-2:1994).
+  [DONTUSECOPY] Zeilenga, K., "LDAP Don't Use Copy Control", draft-
+                zeilenga-ldap-dontusecopy-xx.txt, a work in progress.
 
 
 
-Intellectual Property Rights
+Intellectual Property
 
   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
+
+
+
+Zeilenga                    LDAP Transactions                  [Page 11]
+
+INTERNET-DRAFT         draft-zeilenga-ldap-txn-11       18 November 2007
+
+
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
@@ -445,13 +634,6 @@ Intellectual Property Rights
   can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.
 
-
-
-Zeilenga                    LDAP Transactions                   [Page 8]
-
-INTERNET-DRAFT         draft-zeilenga-ldap-txn-07           5 March 2006
-
-
   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
@@ -462,7 +644,7 @@ INTERNET-DRAFT         draft-zeilenga-ldap-txn-07           5 March 2006
 
 Full Copyright
 
-  Copyright (C) The Internet Society (2006).
+  Copyright (C) The IETF Trust (2007).
 
   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
@@ -470,10 +652,10 @@ Full Copyright
 
   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
-  OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
-  ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
-  INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
-  INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+  OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+  THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+  OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+  THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 
 
@@ -489,19 +671,5 @@ Full Copyright
 
 
 
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga                    LDAP Transactions                   [Page 9]
+Zeilenga                    LDAP Transactions                  [Page 12]
 

doc/guide/admin/access-control.sdf

@@ -137,7 +137,9 @@ attribute name and also using a value selector:
 There are two special {{pseudo}} attributes {{EX:entry}} and
 {{EX:children}}.  To read (and hence return) a target entry, the
 subject must have {{EX:read}} access to the target's {{entry}}
-attribute.  To add or delete an entry, the subject must have
+attribute.  To perform a search, the subject must have
+{{EX:search}} access to the search base's {{entry}} attribute.
+To add or delete an entry, the subject must have
 {{EX:write}} access to the entry's {{EX:entry}} attribute AND must
 have {{EX:write}} access to the entry's parent's {{EX:children}}
 attribute.  To rename an entry, the subject must have {{EX:write}}
@@ -552,7 +554,9 @@ attribute name and also using a value selector:
 There are two special {{pseudo}} attributes {{EX:entry}} and
 {{EX:children}}.  To read (and hence return) a target entry, the
 subject must have {{EX:read}} access to the target's {{entry}}
-attribute.  To add or delete an entry, the subject must have
+attribute.  To perform a search, the subject must have
+{{EX:search}} access to the search base's {{entry}} attribute.
+To add or delete an entry, the subject must have
 {{EX:write}} access to the entry's {{EX:entry}} attribute AND must
 have {{EX:write}} access to the entry's parent's {{EX:children}}
 attribute.  To rename an entry, the subject must have {{EX:write}}

doc/guide/admin/appendix-upgrading.sdf

@@ -37,6 +37,22 @@ entries like below, just remove them from the relevant ldif file.
 
 >           olcReplicationInterval: value #0: <olcReplicationInterval> keyword is obsolete (ignored)
 
+H2: ACLs: searches require privileges on the search base
+
+Search operations now require "search" privileges on the "entry" pseudo-attribute of the search
+base. While upgrading from 2.3.x, make sure your ACLs grant such privileges to all desired search
+bases.
+
+For example, assuming you have the following ACL:
+
+>           access to dn.sub="ou=people,dc=example,dc=com" by * search
+
+Searches using a base of "dc=example,dc=com" will only be allowed if you add the following ACL:
+
+>           access to dn.base="dc=example,dc=com" attrs=entry by * search
+
+Note: The {{slapd.access}}(5) man page states that this requirement was introduced
+with OpenLDAP 2.3. However, it is the default behavior only since 2.4.
 
 
 

doc/guide/admin/preface.sdf

@@ -9,7 +9,7 @@ P1: Preface
 # document's copyright
 P2[notoc] Copyright
 
-Copyright 1998-2008, The {{ORG[expand]OLF}}, {{All Rights Reserved}}.
+Copyright 1998-2007, The {{ORG[expand]OLF}}, {{All Rights Reserved}}.
 
 Copyright 1992-1996, Regents of the {{ORG[expand]UM}}, {{All Rights Reserved}}.
 

doc/guide/images/src/README.fonts

 # $OpenLDAP$
-# Copyright 2007-2008 The OpenLDAP Foundation, All Rights Reserved.
+# Copyright 2007 The OpenLDAP Foundation, All Rights Reserved.
 # COPYING RESTRICTIONS APPLY, see COPYRIGHT.
 #
 # README.fonts 

doc/man/man5/slapd-config.5

@@ -1585,6 +1585,8 @@ with the inner suffix must come first in the configuration file.
 .B [sizelimit=<limit>]
 .B [timelimit=<limit>]
 .B [schemachecking=on|off]
+.B [network-timeout=<seconds>]
+.B [timeout=<seconds>]
 .B [bindmethod=simple|sasl]
 .B [binddn=<dn>]
 .B [saslmech=<mech>]
@@ -1687,6 +1689,17 @@ consumer site by turning on the
 .B schemachecking
 parameter. The default is off.
 
+The
+.B network-timeout
+parameter sets how long the consumer will wait to establish a
+network connection to the provider. Once a connection is
+established, the
+.B timeout
+parameter determines how long the consumer will wait for the initial
+Bind request to complete. The defaults for these parameters come
+from 
+.BR ldap.conf (5).
+
 A
 .B bindmethod
 of